Matt Lorentz

2mo ago

What even is the gossip model in a NIP-29 context? Is it important? It seems like idea of a user-defined relay list is somewhat moot. The group needs to more or less say "we're using this relays" and unless you want to migrate or fork the group you maybe only need to read from one and publish to all of them? Have you thought about this yet? @fiatjaf @ hodlbod @Stuart Bowman @hzrd149

See translation

15
2
0
0
0


Do you have thoughts?

Log in to leave a comment


Replies

verbiricha

@verbiricha

2mo ago

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.

See translation

0

0
0
0
0

hodlbod

@ hodlbod

2mo ago

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 @PABLOF7z starts building multi-relay groups, then all bets are off).

See translation

0

0
0
0
0

Matt Lorentz

@mplorentz

2mo ago

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.

See translation

0

0
0
0
0

Niel Liesmons

@nielliesmons

2mo ago

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, ...

See translation

0

0
0
0
0

hodlbod

@ hodlbod

2mo ago

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.

See translation

0

0
0
0
0

Matt Lorentz

@mplorentz

2mo ago

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

... See more

See translation

0

0
0
0
0

hodlbod

@ hodlbod

2mo ago

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.

See translation

0

0
0
0
0

03 more reply(ies)

fiatjaf

@fiatjaf

2mo ago

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?

See translation

0

0
0
0
0

04 more reply(ies)