Replying to Avatar Daniel A Cummings

Hi, nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9us2xuyp. 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?

Avatar
cipres 6mo ago

Hello. I wrote a wrapper for a nostr relay (called ssnrelay) that publishes the relay's IP address as a pkarr domain record (doesn't use DNS). pkarr uses the mainline DHT (bittorrent's DHT). A nostr client i'm working on can resolve pkarr addresses to connect to such relays: https://pazstr.codeberg.page/features.html#pkarr-support

Your idea is interesting but since the relay has to push those IP address events to other relays that are only resolvable via DNS, you're still locked in DNS land. And the client will have to do step 2, which requires using DNS to connect to the relays which store the IP address events.

Reply to this note

Please Login to reply.

Discussion

No replies yet.