Oddbean

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.

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.

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.