Topics in group chats

[alexgleason]

There are two major issues with Nostr chat clients that prevent them from replacing Telegram/Slack/Discord:

1. You can't do private chats.
2. You can't separate by topics.

Private chats is a whole other can of worms. It is probably even the more important issue. But it's a harder problem to solve. So for now I just have thoughts about topics.

There are two main ways I've seen it done by other clients.

Telegram's way

On Telegram, a single room can be sub-divided into topics. You can view all messages from all topics in a single stream, or you can view individual topic views. On Nostr, a kind 42 message could use t tags to distinguish the topic.

{
  "kind": 42,
  "content": "we meeting or what?",
  "tags": [
    ["e", /* ROOM_ID */],
    ["t", "meeting"] // this is what groups messages into different "sub-rooms"!
  ],
  ...
}

This would allow separating a single room into a list of topics, that can be filtered individually. Here's how a single room with topics looks on Telegram:

The kind 40 "channel creation" event should also include a list of "t" tags, of all the possible topics the room admin endorses for use, eg:

{
  "kind": 40,
  "content": "json_data",
  "tags": [
    // this is what determines which topics show up in the chat UI:
    ["t", "general"],
    ["t", "random"],
    ["t", "meeting"],
    ["t", "nostr"],
    ["t", "bitcoin"],
    ["t", "soapbox"]
  ]
  ...
}

Matrix way

On Matrix, rather than subdividing a single room, each room stands entirely on its own. Instead, a space is used to group multiple rooms together.

Each room stands on its own. It has a separate member list. There are trade-offs to each approach.

For spaces, I would propose a kind 45 "space creation" event, which is used to group multiple channels together:

{
  "kind": 45,
  "content": "json_metadata? or perhaps tags",
    ["e", "CHANNEL_1"],
    ["e", "CHANNEL_2"],
    ["e", "CHANNEL_3"]
  ]
  ...
}

In Matrix, the "Spaces" UI looks like this:

You can join a space, and then filter your rooms by the spaces you're a part of.

Kind 40 would also be extended to refer back to any "space" it is part of:

{
  "kind": 40,
  "content": "json_data",
  "tags": [
    ["e", "SPACE_ID"],
    ["e", "OTHER_SPACE_ID? (possibly multiple spaces?)"],
  ]
  ...
}

I haven't fully thought this one through. On Matrix, there are also privacy settings that let you dictate access to rooms you own within spaces. Eg you can grant all users of a space access to private rooms within that space.

[staab]

The matrix approach makes more sense to me, and could fit really well with a slack/discord alternative as well, although in those cases I would make the "space" correlated to one or more relays instead. Private chats are a can of worms, but I think they're basically solved (in a low-security way) with NIP 17 and #875.

[vitorpamplona]

I think each topic should be a separate kind:40, so the "matrix way" seems better.

https://www.nostrchat.io/ supports NIP-28 chats. The project doesn't seem that active anymore, but an interface like that would be awesome. Maybe we can get @BlowaterNostr to add them to https://blowater.app/

I spent a few hours yesterday trying to see if I can quickly vomit a webchat interface for NIP-28 + NIP-17, but I think my lack of knowledge in these newer web stacks are blocking me from getting it done.

[BlowaterNostr]

@vitorpamplona Recently I am busy with redesign (product level) of Blowater so I don't have enough time to investigate into this issue. Blowater is at least 3 steps away from building any kinds of "topics" in group chat. If you are talking about encrypted group chat, it's even further away from it.