Replies (15)
It's a lot simpler than in a twitter context. Since the relay + identifier is the full id of the group, forking happens explicitly by copying data and using a new qualified id. The outbox model in the narrow sense is irrelevant, and in a broader sense it's barely visible (unless nostr:nprofile1qythwumn8ghj7un9d3shjtnswf5k6ctv9ehx2ap0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7qg6waehxw309ac8junpd45kgtnxd9shg6npvchxxmmd9uqs6amnwvaz7tmxxaazu6t09uq32amnwvaz7tmpv4nkjueww468smewdahx2tcqyrafsj7hmweg9ur7zmn6apajdg48hxuskujx53rhrux0ttjcqx84y4vxupk starts building multi-relay groups, then all bets are off).
I guess I thought NIP-29 left the door open to multi-relay groups, but rereading it I see that it doesn’t really. It says “fork the group so it exists in different forms -- still using the same id -- across different relays”.
Still I think having backup relays or something seems necessary to deliver on the Nostr promise of being able to take your people and data and go to another server.
I still use the outbox model when you poast content from public nostr into a NIP-29 group. The group list itself is also stored on your outbox relays.
Backup relays are something I've thought about some. I even had them in some revisions of my relay-based groups:
https://github.com/coracle-social/nips/blob/379b69c42b9db641e0c8383d5bfbd891ef4abaf4/29.md#federation
https://github.com/coracle-social/nips/blob/60179dfba2a51479c569c9192290bb4cefc660a8/xx.md#federation
But in most cases, the backups don't even need to be specified, since anyone with access to the main relay can sync events to their backup. Then, when the original relay goes away you just manually move to the new one.
I think we need to find a solution to automatically move, at least once, if a group gets banned from a relay. Based on the user interviews we have been doing this is a huge concern for stewards of Facebook groups and other big tech platform. Many of them have had their groups shut down before with no explanation and no recourse. Being able to give them an answer like “on Nostr the relay can boot you off but generally all your groups members will move over to your back just fine” would be a big sell.
Having a backup relay that you hit when the main relay is down or your group data disappears doesn’t seem like it’s too much to ask. Like on app launch if you can’t refresh data from the main relay grab the kind 39000 from the backup relay, see if it still has the main relay listed as the main relay. If it does, great, it must just be an outage. But if an admin has updated the metadata to indicate a new main relay you can just update your local group state to point to the new relay. The user doesn’t necessarily even need to know it has happened.
I think it's important for the user to know since now they have to trust a new server. And the group may have forked while moving (it may have moved to two different conflicting places, for example). I also think in many cases the migration will happen manually and integrants will rearrange by word-of-mouth.
Maybe we can define a kind:29 event that any group member can publish signaling where is (are) the canonical location(s) of the group "xyhdffqa". If before it existed on groups.telegram.org and now it exists on groups.discord.com. Then clients may try to fetch these events from outbox relays of previous members when they can't connect to a specific relay or when a group is behaving weird for any reason?
That kind:29 would be published to the outbox relay of each person manually.
I think that's better than requiring group managers to agree on a fallback relay before being banned, because
1) they may not do it because everybody is lazy;
2) the fallback relay may pre-ban them;
3) they may choose it at the time they're creating the group and then years will pass and the fallback relay will be offline at the time they're banned from the primary relay.
This is why I built flotilla the way I did — encouraging "relays as groups" rather than "relay-based groups" means a thinner distribution of groups across hosts. In other words, admins are encouraged to self-host, which converts deplatforming (a bug) into banning (a feature). I strongly disagree with the approach most NIP 29 groups take of many groups, one relay.
Not to say that I disagree. A federation event on the relay level seems like a better way to do it than directly within NIP 29 though, since it can be used for a million other use cases related to relays.
Maybe the group tag in 10009 should be indexable so you could look up which relay the people you are interested in are using; yes, the random id can have conflicts but who cares; you can pull the 39000 and show it and the user can decide which one they meant
Agree. My preference is going towards Communities as Keys, not Relays.
A Community can then publish:
- their main relay
- their back up relays
- their blossom set up
- their price lists, guidelines, roles for people, ...
I forgot about 10009, no need for it to be indexable. You can just fetch that event from other people that were in the group and see how they have updated it. Well, you can just fetch the one from the group owner.
Yeah
That works except for the fact that most people won't run servers. And even the ones that do can still lose their servers, lose their domain names etc.
