Relay chat

[staab]

This is an alternative to NIP 29. Here's why I'm going this direction:

• NIP 29 is over-prescriptive in several ways. The most obvious example is that it has a rigid model for moderation, whereas moderation is highly community-specific and dynamic. It think it's better to let people send 1984 reports to relays and let relays/clients deal with them as desired. No moderation is specified in this nip.
• NIP 29 encourages group admins to run their groups on a third-party relay. This results in centralization, since if a single relay goes down, many groups go with it. Making groups equivalent to relays compares favorably with Discord's "servers", and encourages users to run their own relays.
• Moving group-like features to relays means we don't need separate specs for each. For example, join requests for relays already exist: Add relay access requests #1079. There's no need for NIP 29's version. Same thing with access control, querying for user permissions (LIMITS), user roles, etc. These are all useful concepts for many kinds of relays.
• Group metadata is also redundant, since relays already have a nip 11 information document and a pubkey with which they can publish additional information.
• Admins and moderators can be handled implicitly, out of band, or by querying feature support using LIMITS. This allows the base spec to be small, and add things like moderator lists as an optional extension.
• Member lists are managed by the members themselves. This way they can choose whether to publish their membership in a group. This allows for web-of-trust based community recommendations.

Additional notes:

• kind 209 chat messages are similar to kind 9, and kind 309 threads are similar to NIP 29's kind 11` threads. We could probably merge the two, but I wasn't certain enough about the details to potentially overload them. Plus, the kinds in this PR are more prescriptive, in that they encourage flat reply hierarchies, and MUST be sent to a room. Ultimately those use cases should probably live in a different NIPs anyhow.

To see this PR in action, visit https://flotilla.social. To try it out, join the relay.nostrtalk.org space (relay).

[fiatjaf]

NIP 29 is over-prescriptive in several ways. The most obvious example is that it has a rigid model for moderation, whereas moderation is highly community-specific and dynamic.

NIP-29 is changed and is not very prescriptive anymore, so this is false.

NIP 29 encourages group admins to run their groups on a third-party relay. This results in centralization, since if a single relay goes down, many groups go with it.

NIP-29 is designed specifically to allow groups to move seamlessly between relays. How do you handle this here?

You will not get random people to run their own relays just to make a group, if this NIP is successful there will eventually be providers renting subdomains to people that just want a group but don't want to run a server.

And then how do you migrate your group to a different provider? Or more generally what happens if the group owner decides to not host a server anymore because he is stressed and wants to become a carpenter, or maybe the domain name is too expensive and they don't want to keep paying for it -- how does the group move to somewhere else?

[staab]

NIP-29 is changed and is not very prescriptive anymore, so this is false.

Still overly prescriptive. Just because you can do nothing doesn't make the things you can opt-in to overly-opinionated. The thing I have in my mind here is NIP 72 moderation, which was rigid, and ultimately killed a lot of groups that tried to adopt it. NIP 29 has lots of things like this, although maybe not as bad.

NIP-29 is designed specifically to allow groups to move seamlessly between relays. How do you handle this here?
And then how do you migrate your group to a different provider?

Multi-relay introduces consistency problems. Kind 30209 allows for multi-relay, but requires that relays validate their participating in hosting the group. In practice, this will probably require federation in order to work. It's a pull-based model, so anyone can mirror the group.

You will not get random people to run their own relays just to make a group, if this NIP is successful there will eventually be providers renting subdomains to people that just want a group but don't want to run a server.

Yes they will, but also yes that will happen. But it does surface relays in a way that NIP 29 doesn't, which I think will help people to think about nostr more clearly.

[fiatjaf]

Multi-relay

I wasn't talking about multi-relay, I was talking about migration.

But I give up, we already tried to have this conversation for way too long.

[staab]

Migration is covered by the same mechanism

[vitorpamplona]

I would make it even simpler:

• Remove "any event MAY be posted to a room using a ~ tag". Keep chats only.
• Delete threads.
• Delete federation.

Let it flourish before adding more stuff.