Oddbean new post about login | logout @Vitor Pamplona @fiatjaf @PABLOF7z @Kieran @Stuart Bowman @hzrd149 @miljan Do you guys have any opinions on what kind to use for MLS chat messages? Looks like kind 14 (from NIP-17) is specifically private DMs, which works for 1-1 MLS conversations but not for groups (it's also got tags we don't need). And kind 9 (from NIP-29) also requires lots of other tags that MLS groups don't need or want. Two easiest options are either just go with kind: 1 (unsigned) or create another new kind... Eventually MLS groups will support the full range of kinds in groups (reactions, replies, classified ads, whatever) but the base chat kind is obviously the most important.
Are they always going to be unsigned?
Yup. Everything in MLS conversations are unsigned.
then you could re-use every kind used in the open "normal" nostr. A calendar event, or a coinjoin event is the same kind, inside or outside the group. There is no issue that such events will be displayed outside the group because they are encrypted, and unsigned, right?
you could view the MLS group as an unsigned mini nostr, if you are in. and a bunch of encrypted stuff if you are not in.
Exactly right! @Vitor Pamplona @Silberengel, this is why I was waffling on using Kind: 1 or not. Since everything inside is unsigned (and encrypted until it's decrypted by group participants) it does function very much like a private feed of it's own.
Oh so relays are going to need to be modified to not check for a signature then? How will a relay know that a given event is meant to be unsigned? I think having a dedicated kind would simplify this.
In that case, why not mimic what relay-based groups do? 💬 Chat message: kind 9 🧵 Post/thread: kind 1 📰 Article: kind 30032 🗳️ Polls: 1068 Etc... ↩ Reply on any of the above: kind 1111
Don't use kind 1 for chats. Never. They are feed posts and should always be rendered as such. If MLS is just for chat messages, we can have a new chat kind just for it. But if anything can be transferred inside if it, then reusing kind 14 makes sense. But we need to figure out a way to encode the group info in every event kind.
It's not for just chat. but since the messages inside a group are all just nostr events we can use any kinds we'd like. I'd like to at least standardize the base chat message kind. then we can use generic replies/reactions/etc. We specifically don't want to have any group related info on the actual messages in a chat to help with deniability though. Hence my point on not wanting to have tags pointing to the group, etc.
If it's unsigned, you can put whatever you want in the event. It just helps the client find events for each group in regular Nostr databases.
Hmm, that's an interesting one. I hadn't really thought about how these events would be cached on the client side other than storing them in the group object itself. The idea being that each group should be completely partitioned from other groups. In white noise, I'm not storing these internal group messages alongside my main nostr events cache, it's a totally separate data store.
One of the goals for NIP 17 was to not require separate datastores. You can just save the decrypted events in the store the client already uses. It's much easier. I would suggest doing the same on MLS.
Makes sense, but that basically guarantees that those events are insecurely treated by clients. My method doesn't make it inherently more secure but it certainly makes it easier to make it more secure...
Why does it guarantee insecurity? Clients have to store events privately already (many use hardware-kept keys), so I don't think the extra encryption from MLS payloads will make a difference. Plus, chat screens tend to require lots of secondary cache/storage to make sure screens load fast, like the last message of each person to build the chat's home screen, pre-parsing markdown/quotes into their own cache, etc. There is no way the protocol can protect from a lousy client.
Since everything is unsigned anyway the client can inject extra tags in the event after decrypting and before storing it for that purpose, no? Is that what you mean?
Yep, or the event already comes with the group id... But since it is unsigned, the client can fix stuff up or add more notes.
I think you can reuse kind:9. NIP-29 only talks about an "h" tag, but I think you can easily just skip that part. Making a new kind is also reasonable, but I like the idea of 9 becoming "the chat kind", even if the context differs completely.