staab
commented
2 months ago Ok, I took another pass at this after @fiatjaf suggested that passive support was possible. I was skeptical at first, but I actually think I got it to work.
This version is compatible with the current version, with the following exceptions:
- I've removed chat/forum event definitions because it should be possible to post events of any kind to a group. Defining new chat/forum kinds is valuable, but adds a lot of noise to the basic NIP, and should probably be added separately like any other kind (there's no need for them to be scoped to nip 29).
- I've changed the join/leave events to use a new verb instead of event kinds. This is so that non-compliant relays don't allow subscribers to request invite codes mistakenly sent to them, and so that relays that don't implement NIP 29 can still implement join/leave behavior. Ultimately, this should probably be in its own NIP, although the group id part of it will still be NIP 29 specific.
- I've removed moderation events, since I think they're over-specified and too rigid to support all models for moderation. As we saw with NIP 72, it's difficult to get moderation right, and expensive to get it wrong. 1984s leave lots of room for interpretation.
- I've removed some of the admin-rpc functionality, which can be re-introduced via #1325 if desired, and moderator permissions. Again, this isn't necessarily bad, but banning/deleting use cases can be covered by relay-interpreted 1984s, and add/remove permission seem too over-specified to me. I'm mostly trying to reduce scope to make things clear, because this NIP has a lot of stuff going on as it is.
I've also left some Note: comments in the text in places where I think things could be simplified at the expense of backwards compatibility, like with group metadata events and group lists.
Friendly view here
The goal here is to establish conventions for using standard relays as lightweight "groups", rather than creating highly stateful group protocol objects which require relay support to work.
Summary of changes (obsolete, see comment below on new revision):
- Access control is broadened to the entire relay, rather than to an individual group. This mostly is just a restatement of NIP 42, but introduces a new `ACCESS` command (which should probably be moved to NIP 42). - Admin RPC is removed, and should be handled by #1325 - Moderation RPC is removed in favor of kind 1984 reports, which don't need special handling, but may be used to inform relay policy. - Use of `-` tags is encouraged to support a weak form of privacy. - Room membership can be tracked as well as relay membership. - Anyone can publish member lists or indexes of `h` tags on a relay. This underscores the fact that they are only for convenience, and shouldn't be relied upon — this allows interoperability with standard relays, because relays aren't expected or required to do anything special. - Some policy stuff like open/closed is removed in favor of using existing NIP 11 metadata. - Relay backups and migration are supported. This can be used to advertise migration to another relay, even if the relay goes down before a migration is published (by posting to well known indexes, or DMing them to members). This PR is just an RFC for now, not necessarily a serious PR. It could replace NIP 29, which doesn't have any mature implementations yet, or it could be a separate standard. Friendly view [here](https://github.com/nostr-protocol/nips/blob/b471201653216f154a9cc866b651eccc0d4ba5f1/29.md).