Thread - Nostr Hypermedia

I’m not sure this is a great solution. The paid authenticated user could effectively spam your relay with infinite pubkeys and you would need to monitor usage and block users. That’s a good bit more administration than is currently required for single pubkey users. The way I see it there are two paths for “hiding” DM metadata. 1) AUTH and trusting the relay. Send your DMs to a small list of trusted relays that properly implement AUTH for private events and do not leak those events to anyone outside of authorized recipients. 2) Giftwrap everything on public relays and make sure you DON’T AUTH to any relays you don’t explicitly trust. Relays you’re connected to can still track you by IP but less public metadata is leaked. I’m not sure combining the two makes a ton of sense. AUTH + giftwraps doesn’t accomplish any relay facing privacy, right? If it only helps externally, is it not the same trade offs as option 1?

↑ Parent

Replies (3)

Shawn 2 years ago

For #1, how do relays “not leak those events to anyone outside of authorized recipients” if the recipient npub is itself encrypted or otherwise obfuscated?

1 replies ↓

Mazin _@mazinkhoury.com 2 years ago

As you know, this is basically why we made inbox.nostr.wine. I really don’t think it works out of the box with a typical paid relay. It combines I think the best two properties of 1&2 in a way that works. Anyone can write to inbox WITHOUT AUTH as long as the note tags an inbox subscriber. Then any inbox subscriber can query for their giftwraps only after AUTH so we never leak that event outside its intended recipients. Lastly, we address spam by letting kind 1984 reports from any subscribed user automatically delete any note they are tagged in.

1 replies ↓

Vitor Pamplona _@vitorpamplona.com 2 years ago

Agree. What I wrote is explicitly about testing the pubkey of the event against the allow list. The pubkey is the signer and that should not happen. The p-tag can be used like you guys do to run the allow list. That's fine. You don't even need auth in those cases. My answer to @Shawn was explicitly about the use of the pubkey and mixing signing and auth roles in one key.