> Clients had to generate an alternate key pair to encrypt the message, so it looked like the message was posted by some random npub.
This is the correct way to implement private messages. The relay should not use the pubkey in the signed message to test against an allow list. Private relays CAN use an NIP-42 AUTH method to authenticate the connecting user (and not the signing user) and make the allow list about the connecting user. The signed message itself must hide the real user as much as possible because it can be easily broadcasted outside of this relay.
Needless to say that private relays that authenticate the user can track everything about the user and thus, by definition, are not very strong in privacy.
Login to reply
Replies (1)
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?