Nostr Web Client

nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 nostr:npub1l2vyh47mk2p0qlsku7hg0vn29faehy9hy34ygaclpn66ukqp3afqutajft nostr:npub1v0lxxxxutpvrelsksy8cdhgfux9l6a42hsj2qzquu2zk7vc9qnkszrqj49 nostr:npub1lunaq893u4hmtpvqxpk8hfmtkqmm7ggutdtnc4hyuux2skr4ttcqr827lj nostr:npub1ye5ptcxfyyxl5vjvdjar2ua3f0hynkjzpx552mu5snj3qmx5pzjscpknpr nostr:npub16c0nh3dnadzqpm76uctf5hqhe2lny344zsmpm6feee9p5rdxaa9q586nvr

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.

Reply to this note

Please Login to reply.

Discussion

PABLOF7z 1y ago

Are they always going to be unsigned?

JeffG 1y ago

Yup. Everything in MLS conversations are unsigned.

Vitor Pamplona 1y ago

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.

Silberengel 1y ago

Yes, Kind 01 is specifically microblogging, not chat.

JeffG 1y ago

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.

Vitor Pamplona 1y ago

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.

JeffG 1y ago

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.

Vitor Pamplona 1y ago

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.

JeffG 1y ago

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...

Vitor Pamplona 1y ago

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.

JeffG 1y ago

Yeah. I came to the same conclusion. But I still don’t know if I’m going to add group metadata to the events themselves.

“We kill based on metadata”

In any case, there are other ways to keep pointers to the right events around if you need.

fiatjaf 1y ago

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?

Vitor Pamplona 1y ago

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.

hzrd149 1y ago

Maybe you could co-opt the kind for NIP-28 channel messages? Although I don't see any harm in making a new kind just for basic MLS messages

JeffG 1y ago

Yea, I hadn't looked at those but something similar could work well. Since kind 42 (from NIP-28) wants to have a pointer to the channel create message it might not be a good fit but I could easily create something similar with it's own kind.

fiatjaf 1y ago

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.

JeffG 1y ago

So we’d update kind 9 docs to be a bit more clear that they don’t always need the tags?