A1 - Relay Keypairs, nred:// URLs, and TLS

[mikedilger]

This has been suggested in other forums but I thought it needed a NIP PR.

[fiatjaf]

Looks good to me as an experiment although it's hard to imagine this catching on at least in the short term.

[arthurfranca]

Browser clients can't connect to Mainline DHT =(
There's an infinite discussion over WebRTC based DHT going on.

[mikedilger]

Looks good to me as an experiment although it's hard to imagine this catching on at least in the short term.

I agree it is unlikely to catch on until it is needed. I want to get one implementation ready though (client and server).

Browser clients can't connect to Mainline DHT =(

Pkarr resolves through a relay (not a nostr relay) that the browser can access. Or through DNS lookups. Clients would have to be configured to use such a relay.

[vitorpamplona]

Does this mean that every nostr client must include 3 new dependencies?

• ed25519
• Mainline DHT
• pkarr

[fiatjaf]

Clients would have to be configured to use such a relay.

Stupid question, but since this is the case wouldn't it be better to use a well-known Nostr relay directly in order to fetch the address records of other relays (that do not use DNS)?

[vitorpamplona]

The nred could be a bech32 address with pubkey + IP. In that way, every Nostr client becomes a DNS resolver and can immediately hit the server without further resolutions. Just build a table with the latest IP for each relay pubkey and hit it with wss://<IP>. Then a simple DNS record on Nostr could provide IP updates in the same way we update NIP-65 lists.

The resolution could be quite similar to what we were trying before on this #1330

Event 30053 defines a DNS record for Nostr. ip4 and ip6 tags represent DNS's A records.

{
  "kind": 30053,
  "tags": [
    ["d", "<subdomain-like-name or empty for root>"],

    ["ip4", "230.22.120.232", "<time-to-live in seconds>"],
    ["ip4", "230.22.120.233", "<time-to-live in seconds>"], // mirrored servers / client-based load balancing
    ["ip4", "230.22.120.234", "<time-to-live in seconds>"], // mirrored servers / client-based load balancing

    ["ip6", "FE80:0000:0000:0000:0202:B3FF:FE1E:8329"] // same content as ipv4
  ],
  // ...
}

[mikedilger]

Does this mean that every nostr client must include 3 new dependencies?

* ed25519

* Mainline DHT

* pkarr

Not every client.

Not both Mainline DHT and pkarr, just one or the other, preferrably just a DNS configuration (pkarr interfaces on the back end to Mainline DHT). @Nuhvi

One other thing though is that the TLS client needs to both accept self-signed certificate and also extract the TLS public key and verify it matches the public key in the URL. That functionality might not be exposed in every TLS stack.

So to support this a client needs: (1) a configuration pointing DNS at a pkarr relay, (2) a TLS stack that allows self-signed certificate and certificate inspection, and (3) ed25519.

[mikedilger]

Clients would have to be configured to use such a relay.

Stupid question, but since this is the case wouldn't it be better to use a well-known Nostr relay directly in order to fetch the address records of other relays (that do not use DNS)?

I don't think a "well-known Nostr relay" is a good idea. But information can be picked up from anywhere.

[mikedilger]

The nred could be a bech32 address with pubkey + IP. In that way, every Nostr client becomes a DNS resolver and can immediately hit the server without further resolutions. Just build a table with the latest IP for each relay pubkey and hit it with wss://<IP>. Then a simple DNS record on Nostr could provide IP updates in the same way we update NIP-65 lists.

The resolution could be quite similar to what we were trying before on this #1330

Event 30053 defines a DNS record for Nostr. ip4 and ip6 tags represent DNS's A records.

{
  "kind": 30053,
  "tags": [
    ["d", "<subdomain-like-name or empty for root>"],

    ["ip4", "230.22.120.232", "<time-to-live in seconds>"],
    ["ip4", "230.22.120.233", "<time-to-live in seconds>"], // mirrored servers / client-based load balancing
    ["ip4", "230.22.120.234", "<time-to-live in seconds>"], // mirrored servers / client-based load balancing

    ["ip6", "FE80:0000:0000:0000:0202:B3FF:FE1E:8329"] // same content as ipv4
  ],
  // ...
}

I'm trying to solve the "how do you get started" problem too. I don't think we should all rely on wss://purplepag.es as a critical starting point. Sure, DNS could be in nostr and updated in nostr, but then it too needs to get started somehow.

Say somebody in Bangladesh wants to get on nostr. He doesn't know any of us. He downloads a nostr client which has hardcoded some starting points, but unfortunately Russia/China/Israel/USA has destroyed the data centers where those servers were hosted in some wartime operation. How can he find anything to get started? Alternatively lets say there are 50,000 relays. And DNS for my server gets stored into 20 of them. What are the odds he is going to find those?

And putting the IP address in the URL just abstracts the problem back one layer. It rots, or becomes critical itself.

I think the DHT solves this problem elegantly. It assigns 20 servers to host this data based on how close their IP address is to the data (using some functions we won't get into the details of). Some of those servers just popped online to download a movie and are now gone, so the DHT has to be refreshed every hour IIRC. But the point is that there is an algorithm that tells you where the data is, and a way to find which 20 servers are closest, throuth iterative querying of routing tables. Could we replicate that in nostr? Yes but it is not straightforward.

I'm not suggesting using the DHT directly. I'm suggesting pointing your DNS at a pubky aware DNS resolver.

[mikedilger]

I mostly put this here to feed back work from Mosaic into nostr. I don't expect nostr to embrace this widely. But I will make at least one implementation so that in the event that the Internet goes war crazy with cyberattacks we have a bomb shelter to retreat into. I think the bomb shelter analogy is pretty apt: lots of cost for probably zero benefit, but if the bombs ever fall you will appreciate it being there.

[mikedilger]

Clients would have to be configured to use such a relay.

Stupid question, but since this is the case wouldn't it be better to use a well-known Nostr relay directly in order to fetch the address records of other relays (that do not use DNS)?

I don't think a "well-known Nostr relay" is a good idea. But information can be picked up from anywhere.

The DHT also needs hardcoded on-ramps. So I can't be against something with enough hard coded relays to work. But is all the DNS data copied to all of them? Maybe it is a small enough dataset that this works.

[arthurfranca]

Pkarr resolves through a relay (not a nostr relay) that the browser can access.

This isn't a problem as long as nostr relays are still willing to announce some regular address for browser clients to connect to directly (without the self signed certs part). Or else browser clients would have to delegate their ws connections to a centralized server. Such server could end up being rate-limited among other problems.

[mikedilger]

@arthurfranca Browsers are very problematic. Can't accept self-signed certs. Can't do network layer stuff. Originally javascript in the browser wasn't supposed to talk to anything except the server that delivered it. But user demand has a way of bending security models and messing up clean architectures. So now we have CSP and CORS and such, and still don't have all that we need.

I think relays offering this kind of endpoint MUST also offer a websockets one with a CA issued certificate.

There could quite easily be services that do DHT lookups for browsers, either REST or within nostr. But I don't think it makes sense for browser clients to offload all the nostr connections to a server, who has to do that for many browser clients simultaneously.