first draft of NIP-79 Nostr Relay Chat

[mleku]

Starting discussion of this idea for synchronous instant messaging a la IRC style leveraging ephemeral events and subscriptions.

oops on the commit comment... i meant 79, it's a currently free number anyhow.

Note that this is specifically for only synchronous messaging using ephemeral message kinds. Relays should support this facility and it has not been much used by anything, but it essentially enables exactly the same protocol mechanics as used in IRC.

It includes stuff about a protocol to acquire and update missing user data required to implement features also. Most of the elements of this proposal are already implemented in https://realy.lol aside from the spidering, which I am implementing now before starting on the client (s).

[fiatjaf]

This is pretty similar to the design @staab had in #1589 and I think it can be served pretty well by NIP-29 in its current form.

We could perhaps add another kind for an online status indicator.

[staab]

This sounds very similar in many ways to what I'm building with flotilla — basically a version of NIP 29, but more focused on relays themselves as hosts, potentially without additional protocol support. At any rate, things like kind 9 chat messages could be borrowed.

[mleku]

@staab it is quite substantially different in that it is deliberately synchronous, events cease to exist once they have been bounced from the relay, and for that reason i used 23514/23515 as the kind numbers as these are ephemeral events in the 20k range

there is far less complexity than that protocol because it does not require any consideration of deleting events as they are not saved, nor does it need any other message type, this is effectively like IRC messages but with signatures

i'd be happy to see this appended as a "synchronous only mode" for nip-29, of course, i like that number more than 79 actually, not that it matters what i like...

i think that it would be a bit of a muddle to mash the two things together though, as this protocol is exclusively syrchronous, there is no delivery guarantee beyond the reliability of TCP sockets and senders can't count on the online status of would-be recipients aside from their liveness as indicated by the status online message

we already have relay exclusive async, persistent message chats in nip-29, and relay agnostic async persistent direct messaging in nip-04/44, this is ephemeral messaging both subject-public and direct message-private and simply uses the subscription mechanism in nip-01 as the relaying scheme, meaning filters for clients are very simple to create and take no extra code to implement

what does take extra code is the complicated part, which is avoiding sending messages that are not interesting to the subscribers... i have implemented that already in normal message relaying and perhaps it belongs in a separate NIP... since it is both a bandwidth side, relay-processing-side and data-completeness-side issue for which reason i have the spider stuff in there

i wanted to have that stuff anyway, as part of paid service systems that make use of follow lists to create an access whitelist, and use the users mute lists to filter out unwanted messages, but it was too complicated to apply this beyond that to actually syncing users interesting events beyond the "directory" events that enable this filtering, so i was trying to keep my spec contained to what effectively is a near zero config scheme for what amounts to basically old school IRC chats

so i think it does deserve its own nip.

but it does fit in with nip-29 "relay exclusive" category

i will carry on with the implementation as i have specified it, in any case, this will be my first ... well, second... rodeo doing UI stuff, and i designed it so i didn't have to make much changes to either my relay or do a lot of complex processing on the client as i would like to try and have this in a PoC by end of january if i can

i feel that nostr's biggest hinderance to adoption is adoption and the simplest possible IRC style chat would solve this problem as well as creating a great deal more privacy for DMs when they are synchronous, and very small amount of code to enable it for clients in general

[staab]

I just finished three months of resisting NIP 29's inexorable pull for similar reasons, but I think there's room in the spec for things like this. At any rate, do look at https://github.com/nostr-protocol/nips/blob/master/C7.md, which covers chat messages — for approximating ephemerality, you could just append an expiration tag to the existing kind.

[fiatjaf]

If you want ephemerality you'll need a relay that ensures ephemerality, that should be very easy to achieve with khatru, but that is weird because the ephemerality of IRC was always an annoyance to me and definitely to many others, because there are all sorts of workarounds people have invented to try to not lose messages.

Here's a nice little TUI IRC-like client for NIP-29 to get you inspired: https://github.com/Galaxoid-Labs/seer_tui

[mleku]

for me the annoyance of irc was not the ephemerality, it was how complicated it was to just set up, the auth, the spam control, the channel ownership and moderation, everything was so over the top

the relays have to support the features for this to work and the reason for the relay to support the features is about, fundamentally, supporting private ownership of relays whether that's paid membership, operation by an employer or organisation, or informal social groups

scaling to multiple relays isn't really necessary, i think, or at least, a user can be subscribing to multiple relays and simply sees all of the combined message stream, and yes that could mean that there will be an unfamiliar fragmentation where there is often parallel conversations going on, so i think the importance of being able to have quoting mean re-posting and a few other similar kinds of semantics, and mechanisms of persistence that live entirely client side, are all things that the main relaying protocol should not have to define

thanks for the tui client link @fiatjaf i will look at that one

@staab i'm happy to be the champion of this somewhat retarded and simple form of chat implementation, i think that the world is a darker place without an IRC like protocol, and the super simplicity of this will help it proliferate again... the excessive cognitive burden of managing IRC servers was the biggest reason for them to fade, IMO, and be replaced by Zuck and co reading all your DMs

[mleku]

just a heads up i have added a third message type that is a relay-forwarding kind that allows multiple relays to join and become a group and propagate messages using a binary tree epidemic pattern.