We believe the biggest problem with NIP-29 is that it only supports a single relay, which goes against one of Nostr’s core features — the ability to use multiple relays.
Login to reply
Replies (15)
Au contraire, that's what I like most about it. NIP 28 will allow me to use less opinionated relays (that don't rely on RPC calls that have to be supported by the implementation).
I think this is a problem with fiatjaf's implementation, not a problem with NIP-29 itself.
Then by that logic, should we just use a single relay for Short Text Notes as well?
Can 0xChat’s NIP-29 group work with multiple relays?
By the way, do you prefer group support for a single relay or multiple relays?
“ Normally a group will originally belong to one specific relay, but the community may choose to move the group to other relays or even fork the group so it exists in different forms -- still using the same id -- across different relays.”
It seems that NIP-29 was designed specifically to support only a single relay.
Currently, it's not supported. Personally, I prefer using a single relay for group chats. The main advantage is message stability and consistency.
The downside is the single point of failure — but I believe this can be addressed by implementing a backup and migration mechanism to move the chat history to a new relay if needed.
> The main advantage is message stability and consistency.
🤔🤔🤔 Don’t think so.
Unlike notes, group messages rely on group management, and keeping group state in sync across multiple relays is very difficult — if not impossible.
If the user opens the group client, it only needs to fetch messages from multiple relays—specifically, messages from the last timestamp up to the current time. The client then uses the messages from whichever relay responds the fastest.
Pulling group messages from multiple relays is technically fine. But can we really say these relays represent the same group? For example, relay1 might show 3 members, relay2 has 4, and relay3 might already consider the group disbanded. In this case, the group messages you receive are unreliable.
The relay implementation is the main problem. But NIP 29 also requires relay support (translating group create/edit into metadata) when it could have been incidental (as it is in NIP 28 as it happens).
The relay is only responsible for forwarding messages; everything else is outside its concern. The group member list is determined by the group owner.
A NIP-29 relay not only forwards messages, but also maintains and synchronizes group state.
That seems to be a design limitation of NIP-29.
Agree. Community needs overlap :90percent: with a Profile's needs.
- multiple relays
- same for blossom
- same for mints
- unique identifier with agency
#communikeys acknowledges this