Update 'Chatrooms' in 17.md

[manimejia]

Specifies updated conventions for Direct Message Chatrooms in NIP-17.

addresses issue #1297

implemented in recent PR for NDK

[vitorpamplona]

I don't think the notion of a "thread" is beneficial to the spec. There are no actual threads. Just groups of people and the name of the group can change at anytime by setting the subject line. There are no multiple threats in the same chatroom, for instance.

[manimejia]

There MAY be multiple threads in a chatroom... this is the power of having 'thread' (or whatever you wanna call this thing that is a distinct set of direct message 'members') separated from the end user 'chatroom' experience.

For example, when onboarding a group of IRL friends to Nostr (maybe all at once, or maybe one at a time in separate meetings), a single customized QR invite COULD be used to start a new DM thread with each new user (having newly created pubkeys), but for the advocate who invited them, these threads all render in a single "my invited IRL friends" chatroom. This is one example where having multiple "threads" in a chatroom COULD make it easier for end users to manage multiple (related) conversations.

Change the terminology... fine. Tweak the specs... OK. But this underlying architecture (the ability to customize the message 'threads' within and the topic/name of 'chatrooms') will make for better end user experiences across all clients.

[manimejia]

In fact ... i wonder if this simple decoupling of "fixed DM threads" from "user configurable chatroom" might lead us closer to a solution for @alexgleason 's issue #1229 ?

Hear me out ...

WHAT IF each "thread" had a unique ID generated for it, being the sorted and hashed array of 'member' pubkeys ... ?

AND what if there was a parameterized replaceable event kind for DM chatrooms, where any user could 'publish' their own chatroom configs, containing an array of thread IDs and a name for the chatroom ... ?

AND what if these 'chatroom' events were published as gift wrap encrypted events (by the chatroom author and only for 'invited' thread members) alongside the chatroom messages themselves ... ?

THEN any user could 'subscribe' (within their own client, or as another gift wrapped event to pass between clients?) to any user published 'chatroom' for any of the threads that they are a member of.

AND, the members list for any given thread in any chatroom would ONLY be visible to the invited members of THAT thread. (because thread IDs are one way hashes, that can only be matched by hashing the complete and sorted array of member pubkeys)

This starts to resemble a solution for "topics in group chats", does it not? Or am I missing something?

This PR might be suitable "as is" for the above to be specified in a separate NIP...
OR this PR could be updated to specify these new "chatroom" kinds, in NIP-17 itself.

[vitorpamplona]

I think @staab tried to make that system but ended up migrating to NIP-29 groups instead because it is very complicated to keep an active member list in private channels.

A few days ago, @jb55 was picturing emails on Nostr. And that system could use GiftWraps and Seals but a separate event kind for the messages themselves. Because it is a separate kind, it could create the notion of a thread by subject and ignore group members. Interfaces then need to show who received each reply (similar to how email does it) and stack them correctly. Users can then add and remove people as they go.

I think there are a lot of lessons that we can learn from emails. Quoting > other folk's text directly in your reply so that you can forward it to a new person in the chat is one of them.