> ‘Cannot: see who sends messages to the user and who the user sends the messages to’.
That is just for any other user in the network. In practice, Alice will share a receiving queue and a server with Bob. Alice then will connect to that server to download her messages. Bob will connect with the same server to send a message. At that time, the server knows the two IPs that are using the same queue and can start mapping people talking to one another, the more they reuse servers and IPs with different conversations, the worse it gets.
One of the designs we explored for DMs in Nostr is to use multiple relays and our broadcasting capabilities to send and receive your messages with rotating pubkeys (akin to queues) for the same user (but not for each conversation) in a way that it reduces the correlation factor / the power of a single receiving server. A Nostr-native onion routing for events, if you wish. The server should not be able to identify when the same two people are talking to one another.
Also, the network should not choose the server for you. That can lead to additional enforcement options by the court.
If it's not client side control there's gonna be a problem (see Tor's PoW solution for hidden services). If the cost for sending messages is zero, there's gonna be a problem.
Thread collapsed