update meta events description.

This commit is contained in:
fiatjaf 2023-11-11 14:46:59 -03:00
parent 94da86a3e7
commit 3e638eac5f

15
29.md
View File

@ -10,7 +10,7 @@ This NIP defines a standard for groups that are only writable by a closed set of
Groups are identified by a random string of any length that serves as an _id_.
There is no way to create a group, what happens is just that relays (most likely when asked by users) create rules around some specific ids so these ids can serve as an actual group, henceforth messages sent to that group will be subject to these rules.
There is no way to create a group, what happens is just that relays (most likely when asked by users) will create rules around some specific ids so these ids can serve as an actual group, henceforth messages sent to that group will be subject to these rules.
Normally a group will originally belong to one specific relay, but the community may choose to move the group to other relays or even fork the group so it exists in different forms -- still using the same _id_ -- across different relays.
@ -36,7 +36,7 @@ Relays should prevent late publication (messages published now with a timestamp
Relays must strip the signature of messages in groups that are `private` so they do not leak.
### Event definitions
## Event definitions
- *text note* (`kind:11`)
@ -95,18 +95,19 @@ Each moderation action uses a different kind and requires different arguments, w
- *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.
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.
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.
```js
{
"kind": 39000,
"content": "a nip-29 chat group for debating pizza flavors and other topics",
"content": "",
"tags": [
["d", "<group-id>"],
["name", "Pizza Lovers"],
["picture", "https://pizza.com/pizza.png"],
["private"],
["closed"]
["about", "a group for people who love pizza"]
]
...
}
@ -116,6 +117,8 @@ The [NIP-19](19.md) `naddr` pointer for this event including with a mandatory re
- *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 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: