Nostr Web Client

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.

Vitor Pamplona 1y ago

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.

Reply to this note

Please Login to reply.

Discussion

JeffG 1y ago

Yeah, funny you picked up on the derived IDs for groups. I talked about that with nostr:npub1klkk3vrzme455yh9rl2jshq7rc8dpegj3ndf82c3ks2sk40dxt7qulx3vt 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.

Vitor Pamplona 1y ago

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.

JeffG 1y ago

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