Oddbean

It's their response to NIP-17. They basically created their own "GiftWrap", like we have. They shouldn't have forced the 2-hop step though. It's important that the forwarding relay ALSO can't track who you are sending things to. I would never use SimpleX without that setting on and I would NEVER use their own servers. Too bad those are optional things and not a required part of the protocol. In the same way, never use Nostr with the default relays of any client. Educating users on the power of relays and allowing them to pick relays has to become a key part of using the protocol. Otherwise, we are just going to centralize again, which defeats the whole purpose of Nostr. BTW, they could have used Nostr relays to be routing nodes. They would have tapped a much bigger network of servers for their user's to choose from.

I hear you. I never use the internet without Tor or VPN. You mentioned they shouldn't have implemented a 2-hop step like Tor. Maybe I am misunderstanding. How are you saying the forwarding relay can track who you are sending things too? There is an additional layer of e2e encryption between the sender and the destination relay. In addition, "each message forwarded to the destination relay is additionally encrypted with one-time ephemeral key, to be independent of messages sent to different connections." ---- "Private message routing is, effectively, a 2-hop onion routing protocol inspired by Tor design, but with one important difference - the first (forwarding) relay is always chosen by message sender and the second (destination) - by the message recipient. In this way, neither side of the conversation can observe IP address or transport session of another. At the same time, the relays chosen by the sending clients to forward the messages cannot observe to which connections (messaging queues) the messages are sent, because of the additional layer of end-to-end encryption between the sender and the destination relay, similar to how onion routing works in Tor network, and also thanks to the protocol design that avoids any repeated or non-random identifiers associated with the messages, that would otherwise allow correlating the messages sent to different connections as sent by the same user. Each message forwarded to the destination relay is additionally encrypted with one-time ephemeral key, to be independent of messages sent to different connections. The routing protocol also prevents the possibility of MITM attack by the forwarding relay, which provides the certificate the session keys of the destination server to the sending client that are cryptographically signed by the same certificate that is included in destination server address, so the client can verify that the messages are sent to the intended destination, and not intercepted."

It's similar to how gifwraps work. The forwarding relay knows your IP (because you connected to it) AND knows to which server to send your message to. So, if you are talking to somebody for a while, the server has mapped your encryption key + IP + location with the "next hop", which they forced to be the final hop. It knows how many messages where sent, and when, to that specific destination. If you are following their guides and using a different server for each receiver, then the forwarding server can map out how many different people you are talking to. Ideally, these forwarding servers should be randomized per message so that they can't assemble a conversation, and if the app can add more hops, it becomes even better. It's kinda where we are going with NIP-17, using random DVMs to forward content to the next relay/DVM. The starting IP is obfuscated by randomness. But in order to do so, the community must have 1000s of forwarding relays out there so that the app can randomize them per message.