nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-12-22 08:25:53 -05:00
Code Issues Actions Packages Projects Releases Wiki Activity

remove invites, simplify group metadata edits, rework fine-grained "permissions" into unspecified "roles".

Browse Source
This commit is contained in:
fiatjaf 2024-09-18 22:27:03 -03:00
parent e61651ac06
commit 765daceaa1
1 changed files with 43 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

77
29.md
View File

@ -144,7 +144,7 @@ These are events expected to be sent by the relay master key or by group admins
- *moderation events* (`kinds:9000-9020`) (optional)
Clients can send these events to a relay in order to accomplish a moderation action. Relays must check if the pubkey sending the event is capable of performing the given action. The relay may discard the event after taking action or keep it as a moderation log.
Clients can send these events to a relay in order to accomplish a moderation action. Relays must check if the pubkey sending the event is capable of performing the given action based on its role and the relay's internal policy (see also the description of `kind:39003`).
```json
{
@ -161,22 +161,21 @@ Each moderation action uses a different kind and requires different arguments, w
| kind | name | tags |
| --- | --- | --- |
| 9000 | `add-user` | `p` (pubkey hex) |
| 9001 | `remove-user` | `p` (pubkey hex) |
| 9002 | `edit-metadata` | `name`, `about`, `picture` (string) |
| 9003 | `add-permission` | `p` (pubkey), `permission` (name) |
| 9004 | `remove-permission` | `p` (pubkey), `permission` (name) |
| 9005 | `delete-event` | `e` (id hex) |
| 9006 | `edit-group-status` | `public` or `private`, `open` or `closed` |
| 9000 | `add-user` | `p` with pubkey hex |
| 9001 | `remove-user` | `p` with pubkey hex |
| 9002 | `edit-metadata` | fields from `kind:39000` to be modified |
| 9003 | | |
| 9004 | | |
| 9005 | `delete-event` | |
| 9006 | `set-role` | `p` with pubkey hex and roles |
| 9007 | `create-group` | |
| 9008 | `delete-group` | |
| 9009 | `create-invite` | `code`, `uses` (how many times it can be used) |
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.
### Group metadata events
These events contain the group id in a `d` tag instead of the `h` tag. They are expected to 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).
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)
@ -206,43 +205,29 @@ When this event is not found, clients may still connect to the group, but treat
- *group admins* (`kind:39001`) (optional)
Similar to the group metadata, this event is supposed to be generated by relays that host the group.
Each admin is listed along with one or more roles. These roles SHOULD have a correspondence with the roles supported by the relay, as advertised by the `kind:39003` event.
Each admin gets a label that is only used for display purposes, and a list of permissions it has are listed afterwards. These permissions can inform client building UI, but ultimately are evaluated by the relay in order to become effective.
The list of capabilities, as defined by this NIP, for now, is the following:
- `add-user`
- `edit-metadata`
- `delete-event`
- `remove-user`
- `add-permission`
- `remove-permission`
- `edit-group-status`
- `delete-group`
```json
```jsonc
{
"kind": 39001,
"content": "list of admins for the pizza lovers group",
"tags": [
["d", "<group-id>"],
["p", "<pubkey1-as-hex>", "ceo", "add-user", "edit-metadata", "delete-event", "remove-user"],
["p", "<pubkey2-as-hex>", "secretary", "add-user", "delete-event"]
]
["p", "<pubkey1-as-hex>", "ceo"],
["p", "<pubkey2-as-hex>", "secretary", "gardener"],
// other pubkeys...
],
// other fields...
}
```
- *group members* (`kind:39002`) (optional)
Similar to *group admins*, this event is supposed to be generated by relays that host the group.
It's a list of pubkeys that are members of the group. Relays might choose to not to publish this information, to restrict what pubkeys can fetch it or to only display a subset of the members in it.
It's a list of pubkeys that are members of the group. Relays might choose to not to publish this information or to restrict what pubkeys can fetch it.
Clients should not assume this will always be present or that it will contain a full list of members.
Clients should not assume this will always be present or that it will contain a full list of members, as relays may opt to not publish it or publish a shortened version.
```json
```jsonc
{
"kind": 39002,
"content": "list of members for the pizza lovers group",
@ -251,7 +236,31 @@ Clients should not assume this will always be present or that it will contain a
["p", "<admin1>"],
["p", "<member-pubkey1>"],
["p", "<member-pubkey2>"],
]
// other pubkeys...
],
// other fields...
}
```
- *group roles* (`kind:39003`) (optional)
This is an event that MAY be published by the relay informing users and clients about what are the roles supported by this relay according to its internal logic.
For example, a relay may choose to support the roles `"admin"` and `"moderator"`, in which the `"admin"` will be allowed to edit the group metadata, delete messages and remove users from the group, while the `"moderator"` can only delete messages (or the relay may choose to call these roles `"ceo"` and `"secretary"` instead, the exact role name is not relevant).
The process through which the relay decides what roles to support and how to handle moderation events internally based on them is specific to each relay and not specified here.
```jsonc
{
"kind": 39003,
"content": "list of roles supported by this group",
"tags": [
["d", "<group-id>"],
["role", "<role-name>", "<optional-description>"],
["role", "<role-name>", "<optional-description>"],
// other roles...
],
// other fields...
}
```