Oddbean

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.

Sorry, I'm just Doug and this is beyond me. But I'm sure others with more brain cells will be able to weigh in on your innovative thought. Gonna go rip some bongs and try not to cry about being so foolish

I know and agree... To give you my thoughts... It seems the tradeoff is worth it. One thing worth asking from my perspective is : how necessary is it to actually save the work for clients and relays? Are they already, or presumably will be taxed for resources?

I think it is important. Less for relays and more for clients. Using gift wraps means that you're open to the possibility of getting DDOS'ed which messages that you have to decrypt to see if you're even interested in the content. Having to send messages to many users (fanout) defeats one of the main reasons for using MLS in the first place. We want big groups to scale really well and be easy and fast for clients to update. In this way, they pull down only the events that they care about (for the groups that they're in) and only have to do a single decryption to get all the data they need to properly process the message content.

It's pretty similar to the concept behind lowent.xyz , but with a fancier twist. I still like the idea of a double signature in a message, where the 'room' encrypts messages to itself, and users inside the room can decrypt and verify the signature of the second signer, who is the actual author of the note. The rotation of the room pubkey is a great enhancement

tldr: the MLS encrypted payload is in a nostr event which has a tag for the group ID. It's clear that a message was posted to the group, but not by whom, and thus it's unclear of how many participants are in the group. This sounds like a OK tradeoff.

Feels like it's what nostr:nprofile1qqsf03c2gsmx5ef4c9zmxvlew04gdh7u94afnknp33qvv3c94kvwxgspr3mhxue69uhksmmyd33x7epwvdhhyctrd3jjuar0dak8xtcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhszxnhwden5te0wpuhyctdd9jzuenfv96x5ctx9e3k7mf0ss9zgs and nostr:nprofile1qqs84k6jpsav0jmdeqjn2zxlpnsajaw6f8l0m2d4e9t8gjsyn53s4nspzemhxue69uhhyetvv9ujuvrcvd5xzapwvdhk6qgdwaehxw309aukzcn49ekk2qghwaehxw309aex2mrp0yh8x6tpd4ehgu3wvdhk6pw0r8j have been doing in their group impls. They just use NIP-44 instead of MLS. IMHO Large Groups do not need the same level of privacy that DMs or smaller groups need. It all depends on the size and expectations. It would be nice to have the group ID derived from a seed so that the group can be split into as many subgroups as necessary. Clients would just derive... say 300 ids... and subscribe to all of them. Similarly, they would also randomly choose an ID out of the 300 to send each new message.

Yeah, funny you picked up on the derived IDs for groups. I talked about that with @Max Hillebrand earlier today. I think that's mostly a client implementation detail instead of a protocol level thing but it's a cool idea to make it harder to triangulate on the size or membership of groups.

We made the DM spec thinking on protections for activists. Making sure people can't bundle them as a group is key. I don't know if it is possible, but it would be great if the same protections were also available in large groups. Keep in mind that if it is not in the protocol, it is going to be hard to get any traction. Giving options to clients just breaks interoperability.

I agree. But the only thing an observer can see is the relative activity level of the group. They don’t know if that activity is spread over a small number of users or a large number. These group ids can be rotated as often as the client wants as well. Talking through it earlier, I felt like trying to do some complicate group id derivation and then publishing to multiple group ids was more security theatre rather than real security. Spec will be ready this week. We can hash out the details then. 🤝

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.

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?!

If I understand this right, the relay would be able to see the public IP of every client and correlate that to the group IDs that they are downloading? In the worst case of a note being published to a single malicious relay, that relay would know the public IP of every client that downloaded the note and know that they where a member of the group (or at least have high confidence of it)?