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:

- `40`: Channel Creation
- `30041`: Channel Metadata
- `42`: Channel Message
- `43`: Hide Nessage
- `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: Channel Creation

Create a public chat channel.

The `id` of a kind 40 event is regarded as an identifier of the channel by other public chat related event kinds.

In the channel creation `content` field, Client SHOULD include basic channel metadata (`name`, `about`, `picture` as specified in kind 30041).

```json
{
    "content": "{\"name\": \"Demo Channel\", \"about\": \"A test channel.\", \"picture\": \"https://placekitten.com/200/200\"}",
    ...
}
```


## Kind 30041: Channel Metadata

A parameterized replaceable event for updating a channel's public metadata.

The value of "d" tag MUST be the `id` of the channel creation event for the channel to be updated. In addition, clients MAY use "e" tags to recommend a relay.

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 ignore kind 30041s from pubkeys other than the creator of the channel to be updated.

```json
{
    "content": "{\"name\": \"Updated Demo Channel\", \"about\": \"Updating a test channel.\", \"picture\": \"https://placekitten.com/201/201\"}",
    "tags": [
        ["d", <kind_40_event_id>],
        ["e", <kind_40_event_id>, <relay-url>],
    ],
    ...
}
```

### Deprecation of kind 41 

kind 41, formerly used to update channel metadata, is now deprecated in favor of kind 30041.


## Kind 42: 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": <string>,
    "tags": [["e", <kind_40_event_id>, <relay-url>, "root"]],
    ...
}
```

Reply to another message:

```json
{
    "content": <string>,
    "tags": [
        ["e", <kind_40_event_id>, <relay-url>, "root"],
        ["e", <kind_42_event_id>, <relay-url>, "reply"],
        ["p", <pubkey>, <relay-url>],
        ...
    ],
    ...
}
```


## 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_42_event_id>]],
    ...
}
```

## 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", <pubkey>]],
    ...
}
```

## 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)