draft
optional
This NIP defines new event kinds for public chat channels, channel messages, and basic client-side moderation.
It reserves five event kinds (40-44) for immediate use:
40 - channel create
41 - channel metadata
42 - channel message
43 - hide message
44 - mute user
Client-centric moderation gives client developers discretion over what types of content they want included in their apps, while imposing no additional requirements on relays.
Create a public chat channel.
In the channel creation content
field, Client SHOULD include basic channel metadata (name
, about
, picture
and relays
as specified in kind 41).
{
"content": "{\"name\": \"Demo Channel\", \"about\": \"A test channel.\", \"picture\": \"https://placekitten.com/200/200\", \"relays\": [\"wss://nos.lol\", \"wss://nostr.mom\"]}",
...
}
Update a channel's public metadata.
Kind 41 is used to update the metadata without modifying the event id for the channel. Only the most recent kind 41 per e
tag value MAY be available.
Clients SHOULD ignore kind 41s from pubkeys other than the kind 40 pubkey.
Clients SHOULD support basic metadata fields:
name
- string - Channel nameabout
- string - Channel descriptionpicture
- string - URL of channel picturerelays
- array - List of relays to download and broadcast events to
Clients MAY add additional metadata fields.
Clients SHOULD use NIP-10 marked "e" tags to recommend a relay.
{
"content": "{\"name\": \"Updated Demo Channel\", \"about\": \"Updating a test channel.\", \"picture\": \"https://placekitten.com/201/201\", \"relays\": [\"wss://nos.lol\", \"wss://nostr.mom\"]}",
"tags": [["e", <channel_create_event_id>, <relay-url>]],
...
}
Send a text message to a channel.
Clients SHOULD use NIP-10 marked "e" tags to recommend a relay and specify whether it is a reply or root message.
Clients SHOULD append NIP-10 "p" tags to replies.
Root message:
{
"content": <string>,
"tags": [["e", <kind_40_event_id>, <relay-url>, "root"]],
...
}
Reply to another message:
{
"content": <string>,
"tags": [
["e", <kind_40_event_id>, <relay-url>, "root"],
["e", <kind_42_event_id>, <relay-url>, "reply"],
["p", <pubkey>, <relay-url>],
...
],
...
}
User no longer wants to see a certain message.
The content
may optionally include metadata such as a reason
.
Clients SHOULD hide event 42s shown to a given user, if there is an event 43 from that user matching the event 42 id
.
Clients MAY hide event 42s for other users other than the user who sent the event 43.
(For example, if three users 'hide' an event giving a reason that includes the word 'pornography', a Nostr client that is an iOS app may choose to hide that message for all iOS clients.)
{
"content": "{\"reason\": \"Dick pic\"}",
"tags": [["e", <kind_42_event_id>]],
...
}
User no longer wants to see messages from another user.
The content
may optionally include metadata such as a reason
.
Clients SHOULD hide event 42s shown to a given user, if there is an event 44 from that user matching the event 42 pubkey
.
Clients MAY hide event 42s for users other than the user who sent the event 44.
{
"content": "{\"reason\": \"Posting dick pics\"}",
"tags": [["p", <pubkey>]],
...
}
Clients SHOULD use the relay URLs of the metadata events.
Clients MAY use any relay URL. For example, if a relay hosting the original kind 40 event for a channel goes offline, clients could instead fetch channel data from a backup relay, or a relay that clients trust more than the original relay.
If we're solving censorship-resistant communication for social media, we may as well solve it also for Telegram-style messaging.
We can bring the global conversation out from walled gardens into a true public square open to all.