nips/79.md

NIP-79
======

Nostr Relay Chat
----------------

`draft` `optional`

IRC is a very old style of instant messaging that has been used on the internet since 1988 when the first form was
written and deployed at University of Oulu in Finland by Jarkko Oikarinen.

There has been numerous additions to the protocol and the latest version is 3. This NIP is for something that is a
lot more like the original, and will be primarily for a purely synchronous, and asynchronous messaging will be possible
only via clients implementing a message cache and uploading them to their follows when they connect, so the relay is by
default never retaining the message stream (saving data storage and query processing).

If users want asynchronous message delivery, there is existing kinds for this purpose, this NIP only concerns itself
with synchronous messaging, and only defines ephemeral message kinds. It is a bare minimal specification, there is no
explicit moderation capability, only user's own mute lists to have the relay not send them spam, and the use of hashtags
as a channel specifier.

## Message Kinds

There are two new message kinds defined for this protocol:

- NRCMessage - a message posted by the user to be broadcast to active subscribers.
- NRCStatus - a message indicating that a specific user is connected or is about to disconnect.

### NRCMessage 23514

This message type simply contains a text message in an optionally minimalistic Markdown format, suggested to implement
the following basic markdown features:

- Bold, Italic, Underline, Strikethrough, Monospace `backticks`
- Hyperlinks (though http/s prefixes SHOULD also cause the client to render a hyperlink)
- Headers 1 to 6
- Double linefeed paragraph separation
- Images/embeds - but also optionally render them if the file extension is recognised
- Preformatted monospaced via either indentation or optionally syntax labeled backtick fences

The reason for supporting these features is to facilitate use of the chat for technical discussions. It is OPTIONAL to
actually implement (since for a TTY or speech based client this may not be practical to render).

Mentions should use the same syntax as kind 1 notes, with the `nostr:` protocol prefix and the bech32 entity reference.
Special handling for replies in the context of the ephemeral messages should be used as described below regarding
replies and quotes, so that anyone who has connected since a replied to message can still see the message.

### NRCStatus 23515

This message type is simply an "online/offline" text in the "content" field, and is used to facilitate "join/part"
messages to be rendered. This also facilitates the ability for direct messages to be resent if the receiver was offline.
This message should be sent periodically, like once every 60 seconds or so, in order to function as a dead man switch if
the offline message fails to send.

## Chatrooms via Hashtags

The simple use of `t` tags and a hashtag MUST be recognised as meaning a message is sent to subscribers interested in
this specific chatroom. `#general` will be a default in clients for the initial room that is rendered in an not yet
configured client, clients should receive all events in the background and populate a hashtag list to enable favourites.

## Automatic Filtering

Follow lists include hashtags, and relays should only send messages that are on the user's follow list OR are tagged
with a hashtag they follow AND NOT users or hashtags on their mute list. This is additionally facilitated by Directory
Spidering to gather the available user information required. Additionally, active subscriptions for hashtags should be
considered a temporary white list for allowed events, AND NOT those the user has designated a mute for.

## Directory Spidering

Relays supporting this NIP should include a "directory spider" feature that periodically polls all the relays that it
can find from user's relay lists [NIP-65](65.md) and [NIP-17](17.md) Direct Messaging relays all following event kinds:

- 10002 Relay List Metadata
- 10050 Direct Message Relay Lists

in order to gather all relevant relays to the users who are permitted to use the relay (this is most easily implemented
by designated relay "owners" whose follow lists designate first level allowed users and the lists of these follows are
additionally permitted in order to facilitate easy access, this can be informal, or on a paid subscription basis).

Further, to facilitate necessary user interface features, all following kinds of users permitted to use the relay should
be sought and cached:

- ProfileMetadata 0
- FollowList 3
- MuteList 10000

The relay lists can be used to acquire a set of sources to interrogate, and from there these event kinds are needed in
order to implement the features of this NIP.

## Direct Messages

Contain `P` (private) tags that designate the recipient,and are only sent to the users authed with the designated public
key, and are additionally encrypted using [NIP-44](44.md). These may only be sent to a user with the matching pubkey as
the one designated in the `P` tag. If the user is not online, the message will be dropped, and resending will be the
responsibility of the client, which may also give the user the option to send a standard 1059/1060 gift wrapped
persistent private message, which is specified elsewhere.

## Resending, Quoting and Replying

Clients should enable the feature for users to resend events that are cached in their client, which will be the original
event stringified in the content field, signed with a new, current timestamp.

To keep things simple, making a reply should wrap the replied to message in a prior message, and the reply itself is a
subsequent message with an "e" tag marked "reply" in the same way as used for kind 1 text notes.

## Denial of Service Countermeasures

The main kind of DoS attack on a relay hosting a chat service as described here is that of channel stuffing. This can be
mitigated by using a reasonable averaging window that simply drops messages that exceed a volume of characters beyond
the capability of a human to input, which would be around 1kb/minute maximum bytes of text, measured by the size of the
content field of the events. A further limit could cap individual event content size to equivalent to about the same as
a printed page of text, or about 4096 characters max for a post size.