I might be coming around to this position soon. I'm going to do some experimentation with supporting private groups with encryption vs AUTH'd relays.
The one thing that needs to be solved (if we assume relays can protect content) is leakage of content to the wider network through re-publishing. Gift wraps do this, but require decryption. Here's my idea for a lighter-weight method, I'm curious what you think of it:
When publishing a "private event", the signature is calculated based on the normal hash + the relay's url. But the relay's url isn't included in the event. This way, even if an event gets re-published to other relays, the signature will fail naive validation and be rejected. Relays could brute-force the signature by attempting validation using every known url, but this would have to be re-done every time the event was validated.
So, it basically works the same way paywalls do, not by making it impossible to share private content, but by making it too annoying to bother with.
Interesting idea. The good news with DMs specifically on an AUTH relay is that the republishing can only be done by the author or the recipient since nobody else can see the note anyway.
With private chats as you mentioned, it’s a bit trickier as the group grows. But, I would think there is some level of trust in a “private” chat anyway so perhaps you can rely on those users not to rebroadcast the event (if the original publishing of said event is made to an AUTH relay)?
You could, I just wouldn't really want to. A misbehaving (buggy or malicious) client could easily re-broadcast private data, users could export/import private data, etc. Having a hurdle to jump through seems helpful.
Thread collapsed
Thread collapsed
Instead of doing that, which would require rewriting all existing Nostr libraries, you could do some math with your keys such that users of that relay still know it's you, but everybody else don't.
That's the whole point, everything currently has assumptions about what is a valid event. This breaks those assumptions, which means unless implementations opt-in, these events will not be propagated
Thread collapsed
I'm not sure I got the use case correctly, but if you hash the relay URL, turn that into a scalar and add the number to your private key you'll get a new private key.
The receiver can check who is the actual sender of that event by hashing the same relay URL, multiplying that with G and subtracting that from the pubkey that is written in the event.
Right, but what I want is for relays to reject the event as invalid unless they're specially configured. Because regardless of which key is used, the content may be something that shouldn't be shared (think patreon content, which is usually shared with a static access token)
Thread collapsed
Thread collapsed
Thread collapsed
