nostr-protocol
Adds Nostr Naming System (NNS)
This offers a potential solution to the widespread use of the easily-capturable DNS-based references inside of Nostr.
This is a long shot. It's not the only way to solve it, but it is a starting point.
Read: here
Do I assume correctly that all the NIPs currently working with standard domain names would have to also accept NNS? Probably NIP-05 is the exception because the ownership of a classical domain is expected.
I wonder if this strengthens the case for NIP-85 (https://github.com/nostr-protocol/nips/pull/1210) using a chain of NNS addresses.
This raises the problem of TLS certificate chains. Issuing certs to IP addresses is iffy in the first place, but it's also a centralization factor of the same kind DNS is. Maybe we should take this a step further and allow insecure connections to IPs using this scheme, and protect traffic based on the server's advertised public key? I'm sure there are gotchas there, but the idea doesn't seem unreasonable.
This does not solve anything because clients will connect with one or more nostr relays to use this internal naming system. These nostr relays will use normal domains or onion addresses.
However it adds lot of complexity and potential security issues. Nostr works better being simple.
@staab You should be able to get a Cert for a public IP (try curl -I https://1.1.1.1), but yes it is more complicated and for example, Let's Encrypt will not issue it. But we are on Nostr and a set of keys is already involved... So @vitorpamplona time for NTLS?
You guys are really trying to reinvent GNUNet / I2P / LokiNet / any other overlay network.
Looks like DHT is unavoidable in the long run.
You guys are really trying to reinvent GNUNet / I2P / LokiNet / any other overlay network.
Yeah, agreed, we should use those instead if possible. How difficult would that be to implement from web/mobile?
@staab I2P already exists as Android/Linux/Windows app. But don't forget that the I2P protocol is currently very overcomplicated, there is a lot of legacy code from old encryption algorithms.
It might be much easier to implement it from scratch, just adopting their experience. I'm not completely sure, but can IPFS help here? I haven't worked with it, but IPNS seems to be able to help.
time for NTLS?
Yes. That's where we are going anyway. I don't want to trust a cert chain that includes people I do not trust.
Looks like DHT is unavoidable in the long run.
Nostr IS already a DHT. It just doesn't look like it.
This proposal leads down a dead end for reasons mentioned here
The beauty of Nostr is that it's already a workaround for TLS dependence by making the certificate irrelevant with keypairs and commoditized relays. Names -> IP's is the wrong problem, whats ultimately needed is Name -> Key (or ideally Name -> nprofile that contains multiple relays for talking with the key.
This proposal is particularly backwards in its mention of HTTP media urls... is the expectation that everyone runs a non-standard browser or some hacky extension? WebTorrent has already solved the media problem
DHT
Torrents still use trackers for a reason, DHT doesn't work
Torrents still use trackers for a reason, DHT doesn't work
We also have trackers. They are called relay hints. @fiatjaf loves them. And that's why they work. :)
Question: I like the general idea of using Nostr to look up "names", but I do have to wonder: What problem does it solve? It's a nice NIP and all, but so far, I don't know what it is supposed to "do". o.o
This proposal leads down a dead end for reasons mentioned here
It is good that you have thought this through, but I disagree with most of those conclusions.
- Parler had it's DNS rugged by GoDaddy simultaneous to it's AWS stack and Joyent stuff. That was enough for me to lose faith in DNS (and to permanently boycott those companies). If it can be rugged when it matters most, it doesn't matter that Iran and Alex Jones have working DNS during normal times. Parler did nothing wrong.
- You don't have to ride a non-DNS system on top of a DNS system.
- SSL can operate without DNS using DH_anon or ECDH_anon (I remember another way I can't find it right now)
However I don't think this proposal is worth it. If relays had pubkey identities and were addressed as such, and published their current IP addresses like we publish our relay lists, THEN this would start to offer value. But that would be nostr2.
Parler was de-platformed in general from their hosting, not specifically a rug on DNS... they always had control of their domain name and had transferred registrars. The extended outage was operational.
That's not to say DNS isn't an attack vector, Zuck has seemed like a different person ever since that day Facebook was mysteriously null routed... but obviously the bar for it is extremely high, and Nostr has already mitigated by decentralizing relays to where there's no SPOF unlike Facebook/Parler.
The dependence on SSL's has nothing to do with the cryptography, but rather what CA's are whitelisted in every browser and operating system.
Sure, there's a no challenge (or fun) in replacing DNS if you can simply modify every users operating environment... but that's not the real world where bootstrapping must work on the web. We wouldn't be here discussing Nostr at all if it didn't work in the common browser.
Sorry to butt in with this but what does "SPOF" mean @shocknet-justin ?
If relays had pubkey identities and were addressed as such, and published their current IP addresses like we publish our relay lists, THEN this would start to offer value. But that would be nostr2.
This is what this PR is proposing. Relays have their NNS records published with their keys. The only difference is that I don't think it makes sense to reference relays only by the public key directly. The naddr has the public key, but also a kind and dtag to provide flexibility within a single signing key. The fallback IP inside the naddr adds an extra layer of redundancy to help clients figure out how to resolve it.
Yes. That's where we are going anyway. I don't want to trust a cert chain that includes people I do not trust.
But the wss connection is also base on a cert chain
I think there should be a tag to represent this address to a domain. Just like the cname value in dns system.
{
"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
["cname", "nostr.com"] // represents a domain
],
// ...
}
Why still use domain ?
- Many services are using cloudflare or other waf to hide there ip.
- Use domain is friendly for nginx or caddy.