If we want Nostr to truly protect privacy and resist censorship—like when X faced a government ban—we need to stop relying on relays with known IPs or domain names.
We need encrypted traffic between clients and servers by default. That means Tor (and networks like I2P and Nym) should just work right out of the box, ideally without leaving the mixnet where traffic could be exposed at the exit node.
💡 A lot of relay operators are already running Tor onion services, which is awesome—but we need to make them easier to discover and use. If a public relay becomes unavailable, we should be able to switch to the Onion service version seamlessly.
What do we need to do to make this happen? First, it’s about getting Nostr relay software to publish the Onion address when it’s set up. Then, it’s about getting clients to handle alternative transports like Tor or I2P natively, letting users choose between IP (TCP/IP), Tor, or other options.
We could also explore mapping DNS records to onion addresses or including the info in HTTP headers. But maybe the most straightforward approach is extending NIP-11 to include alternate transport details so that everything's baked into the protocol.
What do you all think? How can we push this forward? Let’s brainstorm and figure out the best way to support these privacy-preserving networks and keep Nostr resilient. I think we need Tor support in native clients where users can turn it on with a single click. Or maybe even have it attempt Tor as a fallback when the normal way of connecting fails.
This isn’t a big change current relay info ospec here: NIP-11 https://github.com/nostr-protocol/nips/blob/master/11.md
I don't disagree at all. The tor issue is its just so slow. There is no quality of service there at all.
Reticulum network is intriguing with the built in encryption, route finding, addresses, etc...
Ideas like that seem like a good idea. Or similar to bitcoin core, self discovery and propogation based on just a few known and trusted systems.
.
Thumbs up whenever possible to use reticulum. The obstacle is that it still won't solve the issue. Underneath reticulum the same IP addresses are used, therefore easy to bring down the relays.
TOR or similar VPN are still needed to keep the node safe. These nodes are already acting as VPN that isolate messages from the user IP addresses but I'm still in doubt how to make them reasonably untraceable even if slower.
To me it seems like reticulum is an overlay network - like nostr, but it comes with more complexity because it tries to address problems like path finding.
I think it would be a mistake to make one overlay network (nostr) depend on another overlay network (reticulum) which still depends on TCP-IP. Tor gives relays cryptographic addresses, but it's inefficient and unreliable as a transport layer.
I guess there is no harm in relays supporting multiple deferent protocols / technologies. Time will tell what works best...
RN isn’t just an overlay network. It is a network. With encryption and route finding, plus multiple interface types like radio, Lora, and tcp,
Nostr relies on the domain name system for relays currently. A major issue potentially in hostile environments.
RN and tor perhaps are more similar, but adding access to relays over RN is intriguing.
nostr:nprofile1qqsw8tha4zrj22njem340rfnktwdjr5lu5achmtrglh4ufhhggg6mwcppemhxue69uhkummn9ekx7mp0qythwumn8ghj7un9d3shjtnwdaehgu3wvfskuep0qy2hwumn8ghj7un9d3shjtnyv9kh2uewd9hj7y38t66 I must confess that I commented on something I don't sufficiently understand. Reticulum has a lot of moving parts, but I appreciate the fact that it supports multiple interface types.
My hope is that adding other interface types (like radio & LoRa) to nostr relays could allow nostr relays to serve as glue between the interfaces without requiring that we find consensus on "details" like route finding.
Perhaps this hope is naive so I'm keen on getting further insights from people who know about reticulum 😀
