Then you know you can just add trackers to the many parts of the code in order to store who is creating Queues and how and when both Bob and Alice connect to the same Queue, map to their IPs and capture their rough locations. Over time the amount of data allows you to de-noise any IP re-use and specify which locations talk to which other locations. By roughly knowing locations over time, you can pin-point an exact user (for instance, if you roughly know where I work and roughly know where I live, you can easily filter your data set to get my exact queues). Knowing an exact user and some rough knowledge of my contacts (say through Nostr or other spaces), it allows you to start mapping out other users in the network. Soon enough, you can safely identify the owner of every single queue. 

It's work, but the metadata is there. 

Clients can make that work harder by using Tor and other tricks but most people are not doing that today. 

Now picture a similar server but without the creation of queues and each time Bob and Alice connect to send a message, they use a separate random key you have no knowledge about. You know IP X is receiving stuff using pubkey A, but the stuff is coming from everywhere. Everywhere can be another client or a relay that is just re-broadcasting the message, which can be old or new.  You don't know if it is the same conversation or not. You can track IPs of each sender and try to group messages by pairs of IPs, but when the IP changes, there is nothing you can use to link the two IP pairs used by the same person. I will look like a new user. Because you have less information, you will need to rely on more external data to identify each conversation thread, which creates more uncertainty on the outcomes. 

Now add Tor on top of that. 

 I wouldn't have the slightest idea which queues are Alice and Bob.

I can log IP addresses for what it's worth but I think hiding IP is a job for a different layer.

I also can't see groups or group membership as groups only exist on the client. 

  @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. 

 Would be good to look at the spec. 

 Brace yourself for the crypto heresy of using the same EC keys for encryption and digital signatures. 😋 

 I think GiftWraps are more like individual Tor messages that can include DMs inside them. 

They have the "next node" address that is visible (a pubkey which can be the real one, an alias or a new key every time), but everything else is either random or encrypted. 

The GiftWrap event can encrypt other GiftWrap events that together assemble be a full onion route with the benefit being that the final node is the client, not the relay. It would be like never hiting an exit node in Tor.

But we are on early days. I am still wanting for a real cryptographer to make sure our thinking doesnt have any holes in it.  

 Not yet  

 Technically nothing prevents them from storing metadata on servers - only contents of messages are encrypted, same with Matrix. So, you have to trust Signal servers.
They also know your phone number 😅. 
Signal is so much celebrated because it has great UX, large userbase, battle-tested encryption (WhatsApp is based on the Signal protocol) and it was the first.