Nip-17 "Chat Room" definition is too restrictive : clients and users need more flexibility.

[manimejia]

The "Chat Room" section is unnecessarily specific in what "defines a chat room". Clients and users SHOULD be given more flexibility to VIEW and interact with message threads as they see fit.

nips/17.md

Lines 38 to 44 in 604ab3c

	## Chat Rooms
	The set of `pubkey` + `p` tags defines a chat room. If a new `p` tag is added or a current one is removed, a new room is created with clean message history.
	Clients SHOULD render messages of the same room in a continuous thread.
	An optional `subject` tag defines the current name/topic of the conversation. Any member can change the topic by simply submitting a new `subject` to an existing `pubkey` + `p`-tags room. There is no need to send `subject` in every message. The newest `subject` in the thread is the subject of the conversation.

As written, this specification currently REQUIRES a client to display an empty "room" EVERY TIME a new user is added or removed from a message 'reply'. Given the permissionless nature of "being added" to a "thread" (any user can ad or remove another at any time) such a rigid "chat room definition" will likely result in fractured and hard to follow conversations. Users and clients should have the flexibility to adapt.

Here's an idea of how this could be rewritten :

---

Chat Rooms

A "Chat Room" is a rendering of private messages as a single thread. Clients SHOULD render private messages this way, and SHOULD offer users flexibility in how (each) room is defined. A "Chat Room" MAY be defined by any number of tags found in theKind 14 messages retrieved for a given user. Clients MAY display a new room (with a clean message history) when any ONE or MORE of these tags in a single message are DIFFERENT from other messages.

• p tags : Required p tags define the participants "viewers" of a single message. Any "member" of a current message MAY "add" or "remove" participants from a message reply.
• e tags : An optional e tag MAY refer to another (decrypted kind:14) event id as an ancestor (that this message is a 'reply' to). A user MAY receive a reply to an ancestor message that IS NOT available, depending on 'Chat Room' settings.
• subject tags : An optional subject tag defines the current name/topic of the conversation for any given message. Any member can change the subject for a message sent. Clients SHOULD NOT add a subject tag if the user has not changed it.

Some EXAMPLES of possible rules which MAY define a new "Chat Room" :

• message has a single differing (added or removed) a p tag
• message has a different subject tag
• message is NOT a reply (e tag) to a message in the room.
• user XXX has changed subject tag
• user XXX has added or removed a p tag
• user XXX who set subject tag is not included in message p tags

Clients and users SHOULD have the freedom to adapt "Chat Room" definitions to suit their individual needs.

[alexgleason]

See also: #1229

[vitorpamplona]

The main issue is how to make sure users understand which user received which message. When you add a new user to a chat, it's assumed that the user can see all past conversations, which is not true for NIP-17. Similarly, if a user replies with a sub-group of the group and the message is shown in the same thread, there is no clear visual for which users can see which messages create a bunch of confused users, especially in 5+ groups. The group itself becomes a bunch of branched conversions with separate subgroups not being able to see each other even though their messages appear in the same conversation flow.

To simplify this mess, we made everyone change rooms when new users are added or removed. In that way, it becomes clear which conversations are visible to which users at all times.

This is very similar to how Slack does group DMs.

[manimejia]

To simplify this mess, we made everyone change rooms when new users are added or removed. In that way, it becomes clear which conversations are visible to which users at all times.

This is very similar to how Slack does group DMs.

These decisions should NOT be part of NIP specifications. UX matters like this SHOULD be ironed out by implementers, with the NIP specifying ONLY guidelines for such experiments.

[vitorpamplona]

These decisions should NOT be part of NIP specifications. UX matters like this SHOULD be ironed out by implementers, with the NIP specifying ONLY guidelines for such experiments.

Most NIPs offer a specific type of implementation with semantical decisions built-in. It helps any new implementer to become interoperable without having to figure out how other clients do.... Chat rooms... in this case.

However, we are happy to change the NIP if an implementation can solve this without confusing everyone.

[manimejia]

AS AN EXAMPLE :
I am developing a "Social Onboarding" client, where Nostr advocates may create custom "Nostr Invites" that result in new profiles "following" them (and their recommendations) and automatically "joining" in private chats (of the advocate's choosing) upon profile creation. This client will have some facility to create a single chat room for each invite created (if specified in the invite settings). New profiles created by that invite will ONLY see the messages from the time of profile creation onward, and ANY profile may opt out of the group chat at any time. This allows a more "real world" experience for an advocate to invite an existing "group of friends" to Nostr.

My client should have the flexibility to organize "Chat Rooms" in this manner, while being in compliance with this NIP.

[vitorpamplona]

What happens when other Clients start replying to those chat rooms, adding and removing people, and changing the subject at random?

Keep in mind that for larger group chats, say the advocate wants to add all of his invites into a single group, @staab has created #875, which does include the idea of an admin and moderation to add and remove people from groups. In those cases, the chat group is whatever the advocate wants it to be and it doesn't allow the invitees to interfere with the group, like NIP-17 does.

[manimejia]

It helps any new implementer to become interoperable without having to figure out how other clients do.... Chat rooms... in this case.

Nip-17 is a specification for stand alone private (possibly multi-recipient) single message events. This it does well. It doesn't need to do more.

Client 'interoperability' (regarding private messages according to this NIP) will not be effected by how messages threads are presented. Regardless of how "chat rooms" are defined, any client user will receive and be able to reply to every message addressed to their npub, according the this NIP. Indeed, interoperability may be improved by allowing clients (and users) the flexibility to "be creative with this novel architecture" to "see what works".

[vitorpamplona]

Indeed, interoperability may be improved by allowing clients (and users) the flexibility to "be creative with this novel architecture" to "see what works".

Flexibility generally doesn't improve interoperability. The direction generally goes in the opposite way: the more specific, the easier it is to interoperate.

Now, NIPs don't block "be creative with this novel architecture" to "see what works". You can still do what you want, just keep in mind that other clients will remap your chatrooms in the way they see fit. So, if things are shown as a chatroom in your client but as separate rooms in other clients, users might be very confused.

The NIP is just a guide to what you should expect to see out there. If you can create your client in your way and still make it so users are not confused when they switch to other clients, go for it. We can adapt the NIP when we see how your client actually works.

[manimejia]

What happens when other Clients start replying to those chat rooms, adding and removing people, and changing the subject at random?

The onboarding "Chat Room" display in my client MIGHT be configured (as described in OP) to:

1. ONLY show posts where ALL p tags (recipient pubkeys) were generated by the given invite (this is tracked privately)
2. ONLY show posts where the subject tag has not been changed (maybe this could be improved in the NIP?)

I think you may be conflating "Chat Room" with something that exists in hard data. It does not. A "Chat Room" is simply a client side presentation for an 'arbitrary' collection of private notes addressed to the current user. Nothing more. Let the client decide how these are presented.

Now, NIPs don't block "be creative with this novel architecture" to "see what works".

But the way that this NIP is worded does inhibit creativity and exploration.

We can adapt the NIP when we see how your client actually works.

I will build out my client. If I have time, I'll circle back. But this seems a rather "long way about" just relaxing some overly specific rules.

[vitorpamplona]

NIPs don't dictate anything. They just reflect the implemented reality out there. They change as new clients come in.

So, never feel like you can't do something just because a NIP is saying so. Develop your client and the NIP will have to change to make sure other devs know who things are being used.