How is this not a valid response. The web can’t make dns requests. This was #[5] ‘s original concern as well if I remember correctly. Generally I try to not add features that web clients can’t take advantage of to not further fracture nostr.
Discussion
It’s a straw man? The web isn’t a thing. And surely you’re not trying to put that off on me like I am misunderstanding something fundamentally, right?
Whatever limitation you have failed to articulate may not be valid and that’s why the question was asked.
Looking forward to more professional nostr implementations where the developers don’t shoe people away and who can keep up and not settle for a hodgepodge twitter clone.
What do you mean the web isn’t a thing ? Web clients can’t make dns requests so they would not be able to use this core identification mechanism you keep suggesting. Just because non-web clients can doesn’t mean we should fracture nostr clients around a core mechanism.
I’d love to hear why this is the case.
I wonder if you can with https://en.m.wikipedia.org/wiki/DNS_over_HTTPS #[4] can you make dns requests on the web these days ?
Yea should be possible with DoH, but probably CORS will be an issue
This is cool! I guess you can as long as you hardcode some default public resolvers.
Seems to work, just replaced my nip5 code with txt resolver: {name}._nostr.v0l.io
which is the same as kieran@v0l.io
very cool. There you go #[3] ! It’s doable. I have less of an issue adding it to damus now if someone wants to PR it. Although seems a bit niche.
Generally the web is sandboxed and can’t access the full networking stack. I can’t tell if I’m talking to an engineer that understands the technical tradeoffs or if you genuinely didn’t know this. Sorry if it sounded dismissive, that was not the intention. It’s just a technical reality that web clients can’t make dns requests so the idea wouldn’t work.
Web clients. You’ll notice that this has near zero browser compatibility. And I don’t think it can even do DNSSEC.
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/dns/resolve
Web browsers are still heavily sandboxed today.
OpenAlias does it just fine and is capable of fetching arbitrary data (including Bitcoin addresses) from DNSSEC records right now and has for years.
Electrum has supported it since version 2.0.
The centralisation and privacy issues are solved by using a network of DNSCrypt resolvers. Anyone with a VPS can fire up one of those. If configured correctly they don't log DNS requests.
To go a step further you can even use ODoH which proxies your DNS requests though multiple servers in an onion routing type design so the server resolving the name doesn't know your IP, and such a setup is by nature decentralised.
You can even go a step further and run all your DNS requests through a Tor hidden service. Not hypothetical, this already exists, Cloudflare does it.
There's plenty of ways that already exist to overcome the centralisation and privacy concerns of DNS resolution so dismissing the idea offhand seems premature.
I forgot about DoH existing 🙃
By all means write up a NIP and see how far it’s possible to get. Key signing is likely the next major issue. A less stateful lookup approach would be interesting.
I’m already wondering if NIP-05 is the best approach for people long term. Likely not. Businesses maybe. I think something else can replace it in future.
Yeah I think NIP-05 works for now, but for mass adoption it will confuse newbies. And obviously the same goes for the DNS approach.
Like you say it's useful for businesses, or really any individual who has a well known presence under a certain domain, but for most people they just want some kind of username.
I'm not sure what better implementation exists that could actually be implemented in the near term through.
I personally like the .btc domains and they have their own TXT records so shouldn't be hard to implement, but they don't solve the core issues of domain based authentication, just move them to a different platform, and arguably make things even more difficult for the new joiners.
No easy answers here but I suspect what'll end up happening is basically this...
You sound like a super fun guy. 👍🏼
nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 's main concern was to keep it simple.
We already have one way of NIP-05 checking through HTTPS/json, so he didn't want to add a new way through DNS:
My concern was that there were two ways of doing the same thing and supporting both would just double the work for everybody, so we had to pick one.
The /.well-known/nostr.json HTTP request is better because
1. a single provider can host infinite names
2. it's still simple and free to host a static site once you have your own domain
3. it could be expanded with more metadata if necessary
Web support was a thing but I've implemented it with DoH which was good enough before deciding to switch to the HTTP.
Interesting… so a web based AT Protocol client would have to rely on a backend api for verification?
they host all the did documents right now... If you hosted the did document you would feel like it was exactly like nip 05
You can't host anything, they have a centralized trusted server that hosts all identities and you cannot opt-out of that. The DNS part is just a hint that you give to this central server.
Kinda seems like they just want to be another twitter and are using decentralized/sovereign/freedom/etc type language as a marketing tactic.
As of today yes... But my understanding was once production ready anyone could self host this... Sure they might decide post closed beta to only index bluesky hosted did or bluesky hosted repos, although I think a lot of their beta testers would love this, the team seems to dismiss this notion, unless I'm missing something about how did works.
I know nothing about AT tbh