If I need to `formatCode` I will.
epic tutorial
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
NIP-66.
Identify relays by pubkey, map that to an address. Integrate with NIP66 (cc nostr:npub1uac67zc9er54ln0kl6e4qp2y6ta3enfcg7ywnayshvlw9r5w6ehsqq99rx)
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.
Lobby to add a new field to NIP-11 that infers you don't want your relay crawled. I would ignore these relays by default. But be aware, relays are public, and if someone can find your relay then they don't need your permission to publish its existence.
consensus is antithetical to the value proposition of nostr. consensus requires relays know of one another to be useful. the value of dumb relays it he ability to stand up a relay and post notes to it without any consensus requirements. Unless I am misunderstood ding you, this is akin to throwing the baby out with the bathwater. web of trust is the way forward, not trustlessness, social graphs are not finance.
Interesting font, might be cool for hiding content on a client https://fonts.google.com/specimen/Flow+Block
content generator + this font could make for more dynamic and organic UI loading skeletons.
You will likely need to sanitize, nostr.wine, nostr.band and nostr.mom make things less simple.
yep, excrutiatingly familiar with the complexity.
yes. this is basically what nostr:nprofile1qqspw5udc2nzw6wsj3plrrphe0343744h0ucz9e4g248chl3w8kh03qpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3gamnwvaz7tmwdaehgu3wdau8gu3wv3jhvqgjwaehxw309amk7apww468smewdahx2falfwt did in late 2022. one day he just appeared and started submitting bug reports.
Yeah, this is glorious. Got it up and running in about 20m. https://trusted.sandwich.farm/
Rate my first door hinge!
#diy
https://files.v0l.io/e4f721ddab710f1e40d0ff73639b47233af9fba1a4da983c756ded190425918e.webp
I have seen worse and done worse.
Nope. Nostream lets you charge per note, but not with that granular of a policy. Strfry policies would get you halfway there, but to actually make it work as described would be pretty difficult.

