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.
Replies (4)
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?
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.
