NIP-28 ====== Public Chat ----------- `draft` `optional` `author:ChristopherDavid` `author:fiatjaf` `author:jb55` `author:Cameri` 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. ## Kind 40: Create channel Create a public chat channel. In the channel creation `content` field, Client SHOULD include basic channel metadata (`name`, `about`, `picture` as specified in kind 41). ```json { "content": "{\"name\": \"Demo Channel\", \"about\": \"A test channel.\", \"picture\": \"https://placekitten.com/200/200\"}", ... } ``` ## Kind 41: Set channel metadata Update a channel's public metadata. Clients and relays SHOULD handle kind 41 events similar to kind 0 `metadata` events. Clients SHOULD ignore kind 41s from pubkeys other than the kind 40 pubkey. Clients SHOULD support basic metadata fields: - `name` - string - Channel name - `about` - string - Channel description - `picture` - string - URL of channel picture Clients MAY add additional metadata fields. Clients SHOULD use [NIP-10](10.md) marked "e" tags to recommend a relay. ```json { "content": "{\"name\": \"Updated Demo Channel\", \"about\": \"Updating a test channel.\", \"picture\": \"https://placekitten.com/201/201\"}", "tags": [["e", , ]], ... } ``` ## Kind 42: Create channel message Send a text message to a channel. Clients SHOULD use [NIP-10](10.md) marked "e" tags to recommend a relay and specify whether it is a reply or root message. Clients SHOULD append [NIP-10](10.md) "p" tags to replies. Root message: ```json { "content": , "tags": [["e", , , "root"]], ... } ``` Reply to another message: ```json { "content": , "tags": [ ["e", , , "root"], ["e", , , "reply"], ["p", , ], ... ], ... } ``` ## Kind 43: Hide message 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.) ```json { "content": "{\"reason\": \"Dick pic\"}", "tags": [["e", ]], ... } ``` ## Kind 44: Mute user 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. ```json { "content": "{\"reason\": \"Posting dick pics\"}", "tags": [["p", ]], ... } ``` ## NIP-10 relay recommendations For [NIP-10](10.md) relay recommendations, clients generally SHOULD use the relay URL of the original (oldest) kind 40 event. Clients MAY recommend 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. Motivation ---------- 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. Additional info --------------- - [Chat demo PR with fiatjaf+jb55 comments](https://github.com/ArcadeCity/arcade/pull/28) - [Conversation about NIP16](https://t.me/nostr_protocol/29566)