Oddbean new post about login | logout 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 😀
I2P could really be more interesting to adopt. Especially on the client side to communicate with relays since it would keep the IP private, including for info received on the relay side. This would remove possibility to punish nostr users.
nostr:nevent1qqspw60p5zppxgc65zrsklctgnx9u6am3sgjxsgwnmawjqr6ufxektcppemhxue69uhkummn9ekx7mp0qgs8d3c64cayj8canmky0jap0c3fekjpzwsthdhx4cthd4my8c5u47srqsqqqqqpqxk8af
Good call, @Rabble. I run a @Start9 and their built in marketplace’s #Nostr #relay application with a private relay set up. I’ve whitelisted my npub for my app usage to allow writing to it. But, I can’t seem to use it. I use @Nos.social , @Primal , and @Nostur on iOS, and @NoStrudel on the Start9. Among the iOS clients I can’t get the ws:://***.onion address to work in my relay settings, nor do I know where my iOS apps will default write my posts to. I also want my relay to permanently store my content. But I don’t know how it can be configured to do that. Would love more clarification on how to set this up.
As far as I know Amethyst has support for accessing onion services via orbot’s tor service but the rest of the nostr apps don’t yet.
some apps work with orbot running and the app tunneled tunneled through orbots VPN, like 0xChat for the start9 private relay.
I have the same problem and posted about it previously. I cannot access my relay on Start9 while using iOS Primal because it won’t accept the ws:// address. If you try iOS Damus you will be able to add the ws:// address then use your relay with Orbot running. I hope that changes are made in Primal because it’s still my preferred client right now. My work around is to use Damus and Orbot when I want to post then go back to Primal when just looking around.
It's all about the Relays and then "concepts" about relays so newbies like myself can GROK them and help create narratives for others to "get it" and adopt #Nostr
Get in touch with me now via simpleX🔗 Text me now with your name and location, I'm available for a 1-1 convo. https://simplex.chat/contact#/?v=2-7&smp=smp%3A%2F%2FenEkec4hlR3UtKx2NMpOUK_K4ZuDxjWBO1d9Y4YXVaA%3D%40smp14.simplex.im%2FSEKmN13uyX4OJlUxco0z9Nm9bPd4pK_K%23%2F%3Fv%3D1-3%26dh%3DMCowBQYDK2VuAyEA7kBBMVqOcbeghKMFplSPoiLQ903hkK3qBKtF_C1-LEo%253D%26srv%3Daspkyu2sopsnizbyfabtsicikr2s4r3ti35jogbcekhm3fsoeyjvgrid.onion
Going a level up, it's as if the internet its self could be reimagined. It's a network of private networks controlling and managing access and routing. Imagine if it wasn't. Community built networks running a shared broadband and providing access to all. Everyone hooking up to it on thie own. Likely, the private sectors could move faster and is why the internet looks like it does today. Nostr is the same. Doing this as a hobbyist is difficult. UX of just using it is a challenge, let alone running relays.
Sumate a la tormenta de ideas que propone @rabble #grownostr #growstr #brainstorm nostr:nevent1qvzqqqqqqypzqak8r2hr5jglrk0wc37t59lz98x6gyf6pwaku6hpwakhvslznjh6qyt8wumn8ghj7un9d3shjtnddaehgu3wwp6kytcpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsqgqhd8s6pqsnyvd2ppct0u95fnz7dwaccyfrgy8fa7hfqpawynvm9ujlw53h
Identify relays by pubkey, map that to an address. Integrate with NIP66 (cc @sandwich) Use relay's pubkey to encrypt requests. Subscriptions can be encrypted to the pubkey making the request.
Only issue I've always been hung on with relay pubkeys is that the relay has to somewhat consistently provide proofs for its pubkey which adds additional overhead (on top of everything else) for both the relay and the client. Additionally, this requires that the relay have a hot-signer, which adds new requirements for relays in both implementation and security vectors. That said, when relays have pubkeys that can be discovered in some way, I would add them to `30166` events with `p` tags shortly after. This would be in addition to the `p` tag that is already added when any relay has valid pubkey set in their NIP-11.
The best solution I can see for practically everything you mention is Namecoin/BitDNS for Nostr names (xxxxx.bit). The protocol is under-utilitized but this is a blessing since it reduces the load clients and relays need to run. If clients packaged a light node with their offering and relays ran full nodes (~6.8Gb), Nostr would simultaneously get a global consensus mechanism for: i) Human readable/uncensorable names ii) Proof-of-Work attached to those names (reducing the potential for spambots to operate without cost) iii) Ability to register names anonymously iv) Deep integrations with Tor for both domains and TLS v) A key management system so users can have different keys sign different notes (and avoid burning your nsec) and vi) A far better way to discover and build a social graph than Web of Trust can ever provide on its own Yes, there's a shitcoin attached to it but the relays could handle everything to do with that so that users wouldnt be encumbered by another token (ie. paying for name operations in sats to relays). So think of it like a shitcoin without shitcoinery. Namecoin is a serious project with significant miner support (~400ExaHash/s). It has kept current with its development despite a severe lack of interest/funding. Maybe its time Bitcoin embrace its younger brother?
Isn't NWS (Nostr Web Services) developing an alternative to DNS?🤔
I know people keep proposing alternative dns systems for Nostr, but I don’t see much value. If relays can easily be replicated and accessible via Tor, then is it really a big deal that the domain name the relay is using disppears. It seems to me folks advocating from alternative dns systems are all in to it because they want to collect the domain name taxes instead of it going to ICANN. Feels like rent seeking to me. ICANN’s not perfect, but it’s an example of internet governance which has done the minimal thing needed to keep nation states away from the internet. Even the way DNS seizures are tied to countries and not across the entire system, lose a .af domain and you can register .co. And there’s a decent process by which you’re not losing your domain names when the dns keys are lost the way a blockchain dns system would happen. So if somebody figures it out, gets all of Nostr to adopt it, then sure, if we need to we’ll support it, because why not, but this seems like such a silly thing to focus on.
Thanks for the detailed response...🙏🏻😃 As a hardcore voluntariest myself, I have no interest in rent seeking; I like the idea of human-readable addresses, and I see a well designed DNS replacement as the antidote to cancellation by ANY central authority. Details of a functional, decentralized DNS aren't on my personal radar, and I don't know how it might be administered, but (as someone who's experienced arbitrary abuse at the hand of the state) it seems to me worth exploring.
This is incredible!!! We still need unconfiscatable cryptographically unique human-readable names and Namecoin is the best solution for this specific purpose as I see it. Again, running a client is super lightweight and it gives us Proof of Work to impose a cost (however small it may be) to spinning up a new ID.
i agree with if the protocol could go looking for known alternative routes to a relay if first one is blocked. smart and in amethyst i couod see that being very easy with their orbot integration for example. user can run client over orbot, and they put say relay.damus.io as a relay, but they wont know if connecting via an onion route or not its all just fogured out for them in order to allow interaction with the relay 🤙
Each relay having an npub seems like an obvious start.
@rabble relays should be behind lokinet
Y procuremos compartir contenido interesante 😅 nostr:nevent1qqspw60p5zppxgc65zrsklctgnx9u6am3sgjxsgwnmawjqr6ufxektcprdmhxue69uhhyetvv9ujumtpva5kxcmfw3ujumrfwejj7q3qwmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqxpqqqqqqzncwerc
If current nostr got as big as Twitter in Brazil, would it be able to make nostr unusable? What would their government have to do differently against nostr vs Twitter?
I'm more partial to peer to peer without tor. If I know the IP (or domain...) of just ONE "gateway" that helps me with discovery of peers and other gateways I care about, I can hop out from there. Plus this de-globalizes DNS: *this* gateway has abc.com registered at IP 1234 while *that* gateway has abc.com registered at IP 9876. So different voluntary communities can have their own little darknet of domains and peer to peer networking. If there happens to arise a very large and reliable gateway that "everyone uses", it could be considered something like "global", but Exit would *always* be on the table.
I mean sure but we’re talking about nostr tor that doesn’t use exit nodes at all and running things at known ip addresses doesn’t exactly help with either privacy or censorship resistance if your adversary is a nation state. But you do you.
True, but this protocol I'm describing could use proxys by default (the proxy could be on the same machine by default for those without privacy concerns, or on a remote machine if one is willing to add a bit of complexity in order to gain more privacy). Definitely a different strategy than Tor, with some weaknesses, but much more "normal" and easier to slot into existing networking paradigms. Like all this orbot stuff wouldn't be necessary.
To me it sounds like the relays need a verifiable identity! Users who currently find their relays via DNS and talk to them over cleaner TCP-IP need a way to identify their relays in a post DNS environment. How about we create an NPUB for each relay and that NPUB publishes a note with its Tor address and its cleanet data. Now nostr clients can scrape this data before it's too late...
I get the part we need privacy by default. my only question how do we mitigate that using tor can be slow 🤔
If it's just notes in the microblog style, it shouldn't be all that slow. Plus, this move could grow the tor network, which also helps.
At that point, couldn't we use a distributed p2p-like nostr specific dns? There would have to be some sort of trust mechanism, but dns is already an open concept. Each node could be it's own dns server. If one node is comprimised, the others reject it. We just need to figure out how to prevent the well from being poisoned.
For people don't even notice any slow, clients can display videos and images without Tor. That way the only thing that exposes are the file servers
NIP-66.
I looked to the git repo and see no NIP-66 docs. Do tell?