Simplify nip 29 even further #1495

staab · 2024-09-12T21:27:31Z

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 add NIP-86: Relay Management API #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.

pablof7z · 2024-09-18T00:03:28Z

29.md


-Membership lists can contain two types of tags: relay memberships (indicated by `r`), and room memberships (indicated by `h`, and including the relay url):
+Group IDs are identified by `group`, with each value being the relay url and the group id joined by a `'`. Group id MAY be omitted if bare relay membership is desired.


why not just another argument?

[ "group", "group-id", "relay" ]

See the note below, that would be my preference.

pablof7z · 2024-09-18T00:05:24Z

29.md


-Rooms are defined by an arbitrary string containing any text. Names SHOULD be human-readable, and less than 30 characters.
+If a group needs to be moved from one relay to another, this can be done by publishing a `kind 9009`, with the following tags:


what's the goal of this? to indicate to clients that the old relay is going offline?

Yeah, this is an escape hatch for:

Rogue admins

Admins who disappear

Deplatforming

Group forks

pablof7z · 2024-09-18T00:08:54Z

29.md

+
+By default, the same group id on different relays does not mean that the same content will exist in both places. However, relays MAY choose to actively federate with others by aggressively replicating content between the two, or cooperating in some other way.
+
+If a group is federated, this should be indicated on the `kind:39000` group metadata event using one or more `peer` tags indicating another relay url. The peer SHOULD NOT be considered valid unless the designation is mutual.


maybe a non-moderator user might want to announce their federating fork/replica, which perhaps clients can display to users "user X is replicating this group to relay B, <event-content-explaining-the-fork/replica>, do you want to also join that relay?"

Because of this, I think this should be a specific event published to the group relay or other relays.

I would use a migration for that. If it's not mutual, it should be considered hostile, or at least non-consensual.

pablof7z · 2024-09-18T00:10:11Z

29.md

+
+If a group is federated, this should be indicated on the `kind:39000` group metadata event using one or more `peer` tags indicating another relay url. The peer SHOULD NOT be considered valid unless the designation is mutual.
+
+Clients should take care when supporting simultaneous relay use, since missing context is possible if the federation is not implemented correctly.


Maybe explicit mention relay hints for this particular situations.

I address this a bit more at the very end of the document. Relay hints are ok for bringing in note parents, but that's only one kind of context. Stuff like chat rooms has implicit context that would be hard to directly link, even if we used the previous tag

staab · 2024-09-18T00:10:25Z

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 add NIP-86: Relay Management API #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

staab requested a review from fiatjaf September 12, 2024 21:27

staab force-pushed the fix-nip-29 branch from b7aa144 to 8667e2d Compare September 12, 2024 21:27

staab marked this pull request as draft September 12, 2024 21:29

staab force-pushed the fix-nip-29 branch 2 times, most recently from 49a9b95 to b471201 Compare September 12, 2024 21:44

Simplify nip 29 even further

6f2327c

staab force-pushed the fix-nip-29 branch from b471201 to 6f2327c Compare September 12, 2024 23:29

fiatjaf mentioned this pull request Sep 13, 2024

nip29: support for unmanaged groups, top-level relay-local groups and invite codes #1496

Open

Take another pass at nip 29

eac3077

pablof7z reviewed Sep 18, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Simplify nip 29 even further #1495

Simplify nip 29 even further #1495

staab commented Sep 12, 2024 •

edited

Loading

pablof7z Sep 18, 2024

staab Sep 18, 2024

pablof7z Sep 18, 2024

staab Sep 18, 2024

pablof7z Sep 18, 2024

staab Sep 18, 2024

pablof7z Sep 18, 2024

staab Sep 18, 2024

staab commented Sep 18, 2024 •

edited

Loading


		Membership lists can contain two types of tags: relay memberships (indicated by `r`), and room memberships (indicated by `h`, and including the relay url):
		Group IDs are identified by `group`, with each value being the relay url and the group id joined by a `'`. Group id MAY be omitted if bare relay membership is desired.


		Rooms are defined by an arbitrary string containing any text. Names SHOULD be human-readable, and less than 30 characters.
		If a group needs to be moved from one relay to another, this can be done by publishing a `kind 9009`, with the following tags:


		By default, the same group id on different relays does not mean that the same content will exist in both places. However, relays MAY choose to actively federate with others by aggressively replicating content between the two, or cooperating in some other way.

		If a group is federated, this should be indicated on the `kind:39000` group metadata event using one or more `peer` tags indicating another relay url. The peer SHOULD NOT be considered valid unless the designation is mutual.


		If a group is federated, this should be indicated on the `kind:39000` group metadata event using one or more `peer` tags indicating another relay url. The peer SHOULD NOT be considered valid unless the designation is mutual.

		Clients should take care when supporting simultaneous relay use, since missing context is possible if the federation is not implemented correctly.

Simplify nip 29 even further #1495

Are you sure you want to change the base?

Simplify nip 29 even further #1495

Conversation

staab commented Sep 12, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

staab commented Sep 18, 2024 • edited Loading

staab commented Sep 12, 2024 •

edited

Loading

staab commented Sep 18, 2024 •

edited

Loading