Oddbean

dreaming of the option in Amethyst 🔥 nostr:nprofile1qqsyvrp9u6p0mfur9dfdru3d853tx9mdjuhkphxuxgfwmryja7zsvhqpzamhxue69uhhv6t5daezumn0wd68yvfwvdhk6tcpz9mhxue69uhkummnw3ezuamfdejj7qgwwaehxw309ahx7uewd3hkctcscpyug

Oof. I'm sorry you feel that way. I consider SimpleX to be far superior. And it has been independently audited. NIP-17 is no where near as private or secure as SimpleX which is far more robust as a dedicated privacy message system. I am curious, why do you think that? Was it your NIP?

We saw the flaws on SimpleX when building NIP-17. Basically, with SimpleX you have to trust the server you are using (both sides) to not log anything down. And they are upfront about this in their docs. For instance, their recommendation is to use a different server and different IP address for each contact in your list. But their app just bundles everything as one. So, servers can see a LOT. They have promised to not log things down, but if they want, they can (I run a server for a while to test these tracking capabiltiies out). Ideally, you should never user their default servers because if they can see both the receiver and the server channels in the same machine they can link a lot of people together and slowly figure out who is who. NIP-17's goal was to reduce the metadata leaks to the relay you are using such that you don't need to trust to not track you down. With the help of broadcasting relays, it's virtually impossible for relays, including your own inbox DM relays, to figure out who you are talking to.

Thank you for the reply. I understand your point. What do you say about their "private message routing" that was added earlier this month? https://simplex.chat/blog/20240604-simplex-chat-v5.8-private-message-routing-chat-themes.html

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.

Means I have some idea as to what works and what doesn't. What you propose there is called epidemic forwarding and the usual first attempt by all those that can't be bothered to make even the slightest attempt at learning from past failures.

I know on nostr you can't ban people but can we make an exception please and ban this horrible "BitTorrent mainline" nostr:nprofile1qqsfxrxw7y3h9hf0zczhelz57rdajse4mz63kn38xu3kkqx2kuv0ekgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3vamnwvaz7tmzd96xxmmfdejhytnnda3kjctvqyvhwumn8ghj7erpwd5zumt0vd4kjmn809hh2tnrdaksrej4w0 person from liking my notes please. 😮

Yes it was his NIP. @Vitor Pamplona and @hodlbod and with NIP-44 @paulmillr as well as some other people providing lesser contributions. NIP-44 was audited, but NIP-17 wasn't. I thought it was a great idea and put initial GiftWrap support into gossip very early (9 months ago). But NIP-17 DMs don't do everything SimpleX does. Neither is strictly better than the other. Still I think NIP-17 DMs are good enough. They use ephemeral keypairs so just like SimpleX it is like there are no IDs. And I don't think forward secrecy is really worth it.