mirror of
https://github.com/nostr-protocol/nips.git
synced 2024-12-22 16:35:52 -05:00
first draft of NIP-78 Nostr Relay Chat
This commit is contained in:
parent
97bf5266d7
commit
ddacd7c859
87
79.md
Normal file
87
79.md
Normal file
|
@ -0,0 +1,87 @@
|
||||||
|
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.
|
Loading…
Reference in New Issue
Block a user