JeffG on Nostr: GM Nostr 🌞 🆘 I need feedback on an idea related to private group messages. I'm ...
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.
🆘 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.