Replying to Avatar JeffG

GM Nostr 🌞

🆘 I need feedback on an idea related to private group messages.

I'm working on the format for sending group messages via relays and had an idea on how to encrypt messages in a way that saves a lot of work for both relays and clients. But it has some tradeoffs. Here's how it works:

1. Imagine you have a group of n people. The group has an ID value (random string) and each group has shared context that means they will know how to decrypt messages but if you're not in the group, you won't be able to decrypt. This shared context rotates regularly, ensuring forward and PCS security.

2. To avoid having to send each participant a gift-wrapped message, we encrypt the message content using shared group secrets and put that in the content of a Nostr event. This is an encrypted blob that is NOT using NIP-04 or NIP-44 encryption, instead it will be using MLS native encryption which has information about the sender as well as the message content itself. This event is published to group relays using a disposable identity, not the user's main nostr identity.

3. We put the Group ID value in cleartext in an indexable tag on the Nostr event.

This last point is important. Let's break it down:

– Clients only have to publish a single event to send a message to all participants (nice) ,

– It's trivial for members of a group to watch for messages they care about via a tag filter (very nice) and ;

– (the tradeoff) Observers can see how many messages are being sent within a group and when they're being sent but they can't tell who is in the group or who is sending the messages.

I think that this is a fairly reasonable tradeoff. I'd love to hear thoughts or — even better — suggestions on how to improve this.

This is almost exactly how my proposed NIP 87 works, except the group is recognized by p-tagged recipient, so members check directly for all keys for the group that have been shared with them. But I thought MLS solved this through the hierarchical key derivation stuff? My impression was that MLS made it possible to make the number of messages that need to be sent scale logarithmically with the number of recipients, without resorting to shared keys.

Reply to this note

Please Login to reply.

Discussion

Yes. This is true for crypto operations, and ratchets. But since nostr is the delivery service we need to make sure everyone has access to the messages they need. When they need them.

P tagging shows basically the whole group membership publicly no?!

No, messages are signed and sent by the shared key, to the shared key, so it leaks very little. The shared key acts as a proxy for group id here.