If you are interested in exploring it..
This PR seems clean enough, but adds a little complexity with multiple relays and multiple keys per conversation pair. It works even for group chats, since users can have access to separate aliases even inside the same group.
In the end, you can always simply use a Private Inbox relay (like inbox.nostr.wine) and no one will see your DMs, even if your keys are listed there.
It's hard to beat that simplicity.
The solutions you mentioned for mitigating the issue of NIP-17 exposing the recipient's identity do not completely solve the problem.
A better solution would be to automate the updating of the recipient's address.
nostr:note1ck7kjmlmcfwjl6cp4wwne9nneg2nzw484w4l3gwrjjhlysjvcxjq5tx62j
NIP-17 exposes the recipient's identity and lacks both forward and backward secrecy. However, its advantage lies in better multi-device synchronization capabilities. Because the encryption key and receiving address remain unchanged, users can receive and decrypt all messages simply by importing their nsec. NIP-17 is designed for DM in microblogging applications, not as a standalone chat application. It prioritizes multi-device synchronization over enhanced encryption security. This is not a flaw, as it has suitable application scenarios.
Nothing completely solves the problem since any app will always have to ask the relay or a server for messages that match a given query. That query is the public identifier of the user and can be simply traced over time and mapped out with IP and other actions in the protocol.
You are mixing up issues from different layers.
Yep, because the reality includes all these layers. And they break each other constantly. You can't truly claim any privacy without considering all these layers combined.
If we can solve an issue on a specific layer, such as the metadata privacy of recipients and senders at the application layer, that is definitely progress.
IP issue is a network layer issue and needs to be resolved at the network layer.
Moreover, the solution to the recipient's metadata privacy issue is the same as the solution for the sender's metadata privacy issue: both are addressed by continuously updating addresses.
Sure, it's progress. But if you have progress in one, but doesn't solve the other layer, you can't claim being better. Sorry. I have seen too much of these BS with "private" comms in the last 20 years. people love to fool users into more complicated stacks and then leaving IP all there to be fully traced by servers.
Exactly 💯
If playing with relays and keys like this already solves the "super secret activist" use case, then why bother with MLS?
What does it add? Except for the bad UX for everyone that's not a secret agent.
I guess cryptographic forward & backward secrecy would be the most important addition, along with hiding the recipient metadata. I see Jeff started double ratchet at https://github.com/nostr-protocol/nips/pull/1206 and moved on to MLS. I'll take a look.
I think forward and backward secrecy are unachievable in Nostr. You can either be able to load your DMs in many clients and not have any type of real forward and backward secrecy OR you can have DMs that are only visible in the originating client, and thus "broken UXs" everywhere else and then yes with forward and backward secrecy.
There is no way to do both.
