Daniel A Cummings's avatar
Daniel A Cummings 2 weeks ago
Nostr is amazing, but it still relies on centralized DNS to connect to relays rather than DNS being optional. You mentioned a while ago that you were considering a P2P layer for Amethyst. What about 1st implementing a simpler solution which 1. Allows for connecting to relays by IP address & port number, & 2. Sets a standard for relays to broadcast their IP address & port number to other relays so that they can be found by clients? Relays would, of course, broadcast this information to other relays that do use DNS & to those that don't for maximum discoverability. That would make running relays simpler since relay operators wouldn't need to set up domains. Domain registration is privacy invasive, costs money, & adds a hurdle to setting up a relay which I think is a significant hurdle to Nostr adoption. It would also get rid of the single biggest censorship weakness of Nostr & could be a simple, gradually adopted standard since it's backwards compatible with current Nostr architecture. Imagine anyone being able to freely set up their own relay in minutes by downloading a relay, broadcasting their IP address & port number, then telling their friends to add their relay to their client's relay list? It would help a lot in getting more people onboarded to Nostr, I think.
↑ Parent

Replies (4)

Default avatar
Mad Philosopher 2 weeks ago
BitTorrent originally had the same problem you describe, with their trackers analogous to Nostr’s relays: centralized and censorable. In response to the threat, they invented the Distributed Hash Table as a decentralized database for finding peers for each torrent. Nostr will have to come up with some similar solution in order to survive, I think.
1 replies ↓
Daniel A Cummings's avatar
Daniel A Cummings 2 weeks ago
I go into a little more detail about the idea in the note below. But I would change what I said about relays signing all the content they send to clients. Instead, once per WSS connection, some sort of proof could be sent by the relay to the client to show it's the relay belonging to the public key that the client is using to track it.
Daniel A Cummings's avatar Daniel A Cummings
Hi, @npub180cv...h6w6. I have an idea for using Nostr's existing network architecture to allow for optionally DNS-free relays. It would ideally be applied to Nostr & Blossom. Relays could have their own Nostr pubkey which they would use to 1. Send a new, IP address location event type to Nostr relays containing their current IPv6 or IPv4 address & port number, & 2. Sign the data they send to clients so that clients can verify that they're receiving the data from the expected relays. With this setup, for a client to find their DNS-free relays, they would 1. Attempt to connect to their last known IP locations 2. If this fails, they would query all relays they know the location of for the most recent location broadcasts they have 3. Reattempt to connect using the new location data This way, a relay could run without a domain name of any kind on a non-static IP address that could change at any time. As soon as the relay detects that its IP address has changed, it could broadcast its new location so it could be quickly connected to again. What are your thoughts?
View quoted note →
1 replies ↓
Daniel A Cummings's avatar
Daniel A Cummings 2 weeks ago
What about this?
Daniel A Cummings's avatar Daniel A Cummings
I go into a little more detail about the idea in the note below. But I would change what I said about relays signing all the content they send to clients. Instead, once per WSS connection, some sort of proof could be sent by the relay to the client to show it's the relay belonging to the public key that the client is using to track it. View quoted note →
View quoted note →
↑