Oddbean new post about login | logout @Vitor Pamplona Thanks for the suggestions. We did indeed consider various ideas about how to reduce the persistence queue ID, but the to rotate the queues to another server periodically seemed simpler and providing better metadata protection. The current approach also allows some basic protection from resource exhaustion attacks. What I don't quite follow - if the same key A is used to retrieve the messages how it is any better than having queue ID from the perspective of correlating messages to the users? Wouldn't it still identify the user any better, and now instead of mapping IP addresses to queues, the server could map IP addresses to the messages... Maybe I don't understand what you propose? The ideas we considered were about trying to avoid any persistent IDs entirely, e.g. via some kind of DHT tables, and something like this might happen in "v3" of the protocols (we are currently still moving to "v2").
The difference is that each client can create as many rotating keys to receive the message as needed, including a new one per message if it is really necessary. These are created by the client, the server doesnt know about them. But the main component is that you can encrypt the already encrypted message to a separate pubkey as many times as you need. You can basically create an onion route using multiple queue IDs where every server only knows where the which node is coming from and going to but not the author and the receiver. Messages can use complely separate routes, making it impossible to track a conversation sequence. On top of that, dates and times are random. Servers don't know which messages are new and which are not. Many payloads might contain the same messages, adding noise to the network. All of that is done with a single message type: A GiftWrap event.
> What I don't quite follow - if the same key A is used to retrieve the messages how it is any better than having queue ID from the perspective of correlating messages to the users? You need to collect metadata over time to get some value out of it. SimpleX durable queue IDs help with that. His scheme somehow only has ephemeral per-message keys where I don't know where they come from. He may be alluding to https://github.com/nostr-protocol/nips/blob/master/44.md . I suspect the idea is to post DMs to relays without a specific recipient coded into the message. A large number of *potential* recipients all download all DMs from the sender and attempt to decrypt them. This will succeed for those that were intended for them. The security comes from a large number of potential recipients connecting with their IP for download out of which the actual recipient is but one. I doubt this will scale well, in line with nostr's overall hail mary approach to distributed systems architecture.