Actually, I just realized that it would be simple to sync the state of a reply path option because the client can decrypt them. Then the only issue is the privacy leak. Thus Tor gets my first mention.
Discussion
Looking forward to your solution. We have been working on a new DM scheme for over 9 months. What I can say is that we went through a bunch of ideas and they all felt short of their initial expectations. In my mind, even new things like SimpleX is not good enough. We must find a way to do better.
Just curious, what’s the main issue with SimpleX?
You have to trust the SimpleX server operator you are using: servers can track you if they decide (or are compelled by the court) to do so. They documented it here: https://github.com/simplex-chat/simplexmq/blob/master/protocol/overview-tjr.md
Are they saying the server can track? Or a hypothetical “passive adversary” who’s able to monitor the users network?
Is there anything more secure than simplex that exists? I’m mostly happy with this.
‘Cannot: see who sends messages to the user and who the user sends the messages to’.
> ‘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.
The correlation between user and IP is kind of hard though. IPs are very dynamic for residential and mobile internet. In the end if bugs you you can use VPN, Onion, or whatever but that's on the network level and not the apps/server's job.
Works in theory but in practice it’s impossible to vet the servers and who’s even interested enough to check whether anything has changed on the server side since you last checked.
Easy to fool people with malintentions like fake wifi spots etc.
Needs to be a lazy (easy) enough solution that you set up once and forget.
Nostr has the potential with the relay structure.
The same will apply to nostr chat relays too for the same reasons most likely. The only way around it is onion routing.
Lightning uses onion routing. I adapted the same technique for Indra, with the use of providing return routes in the forward messages. Essentially the same principle applies to the encryption.
If it were possible to add a simple multi-hop forwarding message and wrap three or more in one message they could be forwarded.
The reason why it won't work is because there has to be a limit on how much traffic goes through or it WILL be abused..
https://github.com/indra-labs/indra btw.
I need to mainly preface any viewing of that code with two things - it is in the midst of a change to make variable length paths (not only 3 hops of a fixed size) and it uses libp2p, which has a serious scalability problem due to the DHT it uses (same back end used for ipfs btw).
I would continue the work and bring something forward if I had the resources to do so. It needs a connectionless p2p system that tolerates nodes not having a complete picture of the network, a "connectionless" relaying scheme, mainly because it needs to be possible for a client to ask a relay to forward a message to a relay it may not know, and to just fuggin send it whatever fuck you.
The variable length, potentially padded path headers are important because to do this correctly you have to have relays told where the header stops and where the message starts, so they apply the correct keys, it uses two keys to perform this.
What's wrong with SimpleX. Asking for a friend.
Too much trust on the server operator. It's better than anything else but there is still too much trust. https://github.com/simplex-chat/simplexmq/blob/master/protocol/overview-tjr.md
I've replied elsewhere that it's only about IP addresses. Anything else would need application layer epidemic routing (send everything everywhere). Can you really pull that off. I don't see nostr scaling well the way it is, and this will overload relays even sooner than nostr's growth will eventually do anyways.
I see lots of naiveté here building a decentralized system. It's a Hard Problem (tm) and one of the last great unsolved problems of computer science if you ask me.
We've discussed this before also: nostr:nevent1qqspdczflthsq9zmz9awe2fy8a9tgr5lqknx6rmasexrd40pp74ywuqpz3mhxue69uhhyetvv9ujumn0wd68ytnzvupzq3svyhng9ld8sv44950j957j9vchdktj7cxumsep9mvvjthc2pjuqvzqqqqqqy6fv73p