Replying to Avatar fiatjaf

Well, inbox relays like that were that required AUTH for reading were my proposed solution for DMs and other secretive things since a long time. It's not only safer and more private, it's also more efficient for all the clients involved if they only read DMs from one place and publish to one or two places.

I was trying to get nostr:npub1jlrs53pkdfjnts29kveljul2sm0actt6n8dxrrzqcersttvcuv3qdjynqn and nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z to care about it and put it on the NIPs and get the clients to enforce a tag like "dms" on kind 10002, but I'm not sure I succedeed.

Avatar
hodlbod 2y ago

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.

Reply to this note

Please Login to reply.

Discussion

Avatar
Mazin 2y ago

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

Avatar
hodlbod 2y ago

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.

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.

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)