nostr/nips
1
0
Fork 0
mirror of https://github.com/nostr-protocol/nips.git synced 2024-09-19 22:35:50 -04:00
Code Issues Actions Packages Projects Releases Wiki Activity

saner approach with multiple kinds for moderation.

Browse Source
This commit is contained in:
fiatjaf 2023-11-10 22:24:11 -03:00
parent 513644d920
commit 5551f1f57a
1 changed files with 33 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
29.md
View File

@ -28,6 +28,10 @@ In order to not be used out of context, events sent to these groups may contain
This is a hack to prevent messages from being broadcasted to external relays that have forks of one group out of context. Relays are expected to reject any events that contain timeline references to events not found in their own database. Clients must also check these to keep relays honest about them.
## Late publication
Relays should prevent late publication (messages published now with a timestamp from days or even hours ago) unless they are open to receive a group forked or moved from another relay.
## Trimmed signatures
Relays must strip the signature of messages in groups that are `private` so they do not leak.
@ -62,6 +66,33 @@ Similar to `kind:11`, this is the basic unit of a chat message sent to a group.
...
```
- *moderation events* (`kinds:5;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.
```js
{
"kind": 90xx,
"content": "",
"tags": [
["h", "<group-id>"],
["alt", "optional action description and/or reason"],
["previous", ...]
]
}
```
Each moderation action uses a different kind and requires different arguments, which are given as tags. These are defined in the following table:
| kind | name | tags |
| --- | --- | --- |
| 5 | `delete-event` | `e` (id hex) |
| 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) |
- *group metadata* (`kind:39000`) (optional)
If this event does not exist, the group should be identified in the client UI by its identifier (i.e. "/flavors" or "pizza.com/flavors"). All tags are optional. Having the `"private"` tag means the group cannot be read and relays will use [NIP-42](42.md) `AUTH` messages to control who can read from it. The `"closed"` tag means the group can be read by anyone but only explicitly whitelisted pubkeys are allowed to post, again these enforcements happen at the relay level.
@ -92,7 +123,7 @@ The list of capabilities, as defined by this NIP, for now, is the following:
- `add-user`
- `edit-metadata`
- `delete-event`
- `ban-user`
- `remove-user`
- `add-permission`
- `remove-permission`
@ -102,32 +133,9 @@ The list of capabilities, as defined by this NIP, for now, is the following:
"content": "list of admins for the pizza lovers group",
"tags": [
["d", "<group-id>"],
["<pubkey1-as-hex>", "ceo", "add-user", "edit-metadata", "delete-event", "ban-user"],
["<pubkey1-as-hex>", "ceo", "add-user", "edit-metadata", "delete-event", "remove-user"],
["<pubkey2-as-hex>", "secretary", "add-user", "delete-event"]
]
...
}
```
- *deletion event* (`kind:5`) (optional)
This is the same event as described in [NIP-09](09.md), the difference is that if there are admins with `delete-event` capability for the relevant group their `kind:5` events must be honored by the relays.
- *moderation event* (`kind:9000`) (optional)
An event sent from a client to the relay in order to accomplish a moderation action (except `delete-event`, as that is the job of `kind:5`). The relay should read this event and act on it if the user sending the event has the required permissions and the date is close to the current date. The relay may discard the event after taking action or keep it as a way to expose a moderation log.
```js
{
"kind": 9000,
"content": "action description and/or reason",
"tags": [
["h", "<group-id>"],
["action", "add-user", "<pubkey-to-add>"],
["action", "ban-user", "<pubkey-to-ban>"],
["action", "edit-metadata", "<field-name>", "<field-value>"],
["action", "add-permission", "<pubkey>", "<permission>"],
["action", "remove-permission", "<pubkey>", "<permission>"],
]
}
```