Replying to Avatar hodlbod

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.
Avatar
fiatjaf 2y ago

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.

Reply to this note

Please Login to reply.

Discussion

Avatar
hodlbod 2y ago

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

Avatar
fiatjaf 2y ago

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.

Avatar
hodlbod 2y ago

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)