NIP-76
======

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.

## 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.
- NRCConnect - a message indicating that a specific user has 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) 

### NRCConnect 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.

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

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.

## 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 and are only sent to the users authed with the designated public key, and are additionally
encrypted using [NIP-44](44.md).

Optionally clients can implement the ability to resend direct messages that the recipient may not have seen due to the
client having seen a NRCConnect offline message signalling the user is not receiving messages thereafter.