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.

Reply to this note

Please Login to reply.

Discussion

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.

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

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

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.

A more complete explanation of my position: https://habla.news/u/hodlbod@coracle.social/1732313518416

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.