Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NIP-29 unleashed #1716

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

NIP-29 unleashed #1716

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 13 additions & 7 deletions 29.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -122,23 +122,29 @@ Each moderation action uses a different kind and requires different arguments, w

| kind | name | tags |
| --- | --- | --- |
| 9000 | `put-user` | `p` with pubkey hex and optional roles |
| 9001 | `remove-user` | `p` with pubkey hex |
| 9002 | `edit-metadata` | fields from `kind:39000` to be modified |
| 9005 | `delete-event` | `e` with event id hex |
| 9007 | `create-group` | |
| 9008 | `delete-group` | |
| 9009 | `create-invite` | |

It's expected that the group state (of who is an allowed member or not, who is an admin and with which permission or not, what are the group name and picture etc) can be fully reconstructed from the canonical sequence of these events.

### Metadata / Group creation

Admins of a group can publish a `kind:39000` event to edit a group metadata. Relays may allow using this event to create a new group when an non-existing `d` tag is used. Relays should copy the payload of this event AS-IS and resign it with their key.

The metadata event may include extra metadata about the group, for example, it may include `k` tags for the type of kinds this group is centered around.

Relays SHOULD reject `kind:39000` events from non-admins and MUST not re-sign the event with their own key.

### Membership events

Admins of a group should publish `kind:39001` and `kind:39002` to modify the admin and members list respectively. Just like with `kind:39000`, relays should re-sign with their own key when they receive an event from an admin pubkey and MUST not re-sign the event when receiving the event from an unauthorized list.

### Group metadata events

These events contain the group id in a `d` tag instead of the `h` tag. They MUST be created by the relay master key only and a single instance of each (or none) should exist at all times for each group. They are merely informative but should reflect the latest group state (as it was changed by moderation events over time).

- *group metadata* (`kind:39000`) (optional)

This event defines the metadata for the group -- basically how clients should display it. It must be generated and signed by the relay in which is found. Relays shouldn't accept these events if they're signed by anyone else.
This event defines the metadata for the group -- basically how clients should display it. It must be generated and signed by the relay in which is found. Relays shouldn't accept these events if they're signed by anyone else other than admins.

If the group is forked and hosted in multiple relays, there will be multiple versions of this event in each different relay and so on.

Expand Down