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

update meta events description.

Browse Source
This commit is contained in:
fiatjaf 2023-11-11 14:46:59 -03:00
parent 94da86a3e7
commit 3e638eac5f
1 changed files with 9 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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_. 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. 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. 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`) - *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) - *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 ```js
{ {
"kind": 39000, "kind": 39000,
"content": "a nip-29 chat group for debating pizza flavors and other topics", "content": "",
"tags": [ "tags": [
["d", "<group-id>"], ["d", "<group-id>"],
["name", "Pizza Lovers"], ["name", "Pizza Lovers"],
["picture", "https://pizza.com/pizza.png"], ["picture", "https://pizza.com/pizza.png"],
["private"], ["about", "a group for people who love pizza"]
["closed"]
] ]
... ...
} }
@ -116,6 +117,8 @@ The [NIP-19](19.md) `naddr` pointer for this event including with a mandatory re
- *group admins* (`kind:39001`) (optional) - *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. 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: The list of capabilities, as defined by this NIP, for now, is the following: