NIP-29 groups are not necessarily single-relay. They are called relay-based groups because some of the events are issued by relays.
Again, with that NIP, groups are single relay, and there’s no transparent migration path. A group should be defined by its owner, not by the relay it is on.
Also, all of these approaches are horrible for clients like nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s's Damus as they maintain a local DB. There is no way to sync event deletions by admins, and local caches lose all benefit as they need to make round trips to the centralized community relay to get the latest state of everything.
Relays were designed as data stores, a subset of all events. The construction of views on top of these relays were and always have been the responsibility of a client on top.
A deletion for example, it should still function in clients even when relays don’t give a shit and do the bare minimum of storing events.
Relays support it because there’s no reason for them to store deleted events.
Discussion
No replies yet.