Operators are what assemble the bindings in the trie. Anyone can become an operator by bidding in an auction. You can read more about it at https://spacesprotocol.org
they don't have much power besides adding your name -> pubkey binding in the tree.
> The append-only, distributed nature of the traditional SKS PGP keyserver network seems to provide the same sort of thin
> most of them would have to conspire to forge a mapping.
The mapping is recorded in an immutable ledger (bitcoin) so forging is not feasible without breaking Bitcoin's proof of work. its a stronger guarantee than a key server.
> They instead want to be sure that they are securely exchanging messages with an particular flesh and blood person
comparing fingerprints doesn't verify a flesh-and-blood human either. "is this the specific person I mean" problem is still real and separate though.
`grace@key` binding gives you a stable, human-readable identifier you can hand out like an email address, build reputation on, and that anyone can use to verify posts made by you and message you without having to meet you in person. It solves the UX of using public keys as your identity. You can post online with a public key as your id (e.g. nostr) but its harder to build your online identity around it.
you can rotate the key underneath the name. with a bare key it becomes your identity, so rotating means becoming a new person and re-verifying with everyone.
> you are back in the realm of ridiculously long numbers.
not really. the long number is a disposable part, and there's a name above it. You can still exchange "grace@key" in person, and be sure you're talking to "grace@key"
I have addressed key transparency in the post :) Key transparency does help with detection (still requires trusting third parties or having to check yourself) but the proposed protocol makes it not possible to forge the mapping to begin with.
> This is better! Because essentially no clients (phones) have a local copy of the bitcoin chain, so you still have to trust a server to tell you what was posted in the bitcoin block.
Not quite :) also addressed in the post. look at the end of "The CA of all CAs
" section.
there's nothing wrong with a keychain or password manager holding your keys. passkeys already work exactly this way, completely transparent to the user. it's fine for most users.
Key loss is hard but not insurmountable. Social recovery / split-key custody seem like the right direction. Apple uses "recovery contacts" if you have advanced data protection enabled. A friend holds one share, Apple holds another but neither can recover alone. that's social recovery + split-key shipping to hundreds of millions of devices today
> That, and general name confusion attacks, I suppose: "I'm lxgr17@key...
pre-registering the obvious typo neighbors (lxrg, 1xgr ... etc) and it's cheap since handles batch-issue off-chain under a fixed 32-byte root, and strict ascii only charset ... etc could help mitigate some of this.
> Cloudflare Workers and Deno Deploy are ephemeral, as in, the process that serves client request is not long-lived, and in fact, two back-to-back requests may be served by two different isolates (processes)
I suspect this would impact latency. Any benchmarks done to compare Cloudflare workers, Deno and fly.io for this specific application (i don't think ping alone is fair)? I'm guessing fly.io is more suitable here. Also, DoH clients generally maintain a pool of connections to the DoH server i'm not completely sure how this is handled with something like Cloudflare workers.
We already built a separate application and wanted to avoid making a browser for a while. The idea for Beacon started when we wanted decent support for iOS and android, which nowadays is like the majority of users.
It's easy to install an app and start browsing. No hacks or workarounds and the UX can be much more tailored (even for desktop).
> Why are you swallowing "error" from invoking the "reall" tool? That seems like a great way to make contributors really frustrated
Glad you're looking at the code! There's still some refactoring needed for butil. It will get more polished soon ;)
> This trend of "I'm going to invent some build tool because there are not enough build tools in the world" is evidently leaking out of the node ecosystem
butil applies string replacements, patches and overrides all under one tool using a statically typed language but still usable like a scripting lang since it can rebuild the actual tool as needed. You can technically do something similar with various python scripts I suppose and use chromium's GN build system . GN would just end up calling various scripts so I think i prefer this more unless you have some other ideas.
yeah the initial standard was dropped by tls-wg. RFC9102 is more recent/an independent submission.
> 3. An attacker with a valid certificate can strip dnssec-chain-extension out of a TLS handshake.
That's true but decentralized namespaces are at least starting with a clean slate they could require this extension no CA is issuing names for those anyway.
For names that rely on WebPKI this standard could be less strict about pinning initially (treating DNSSEC as just another CA). Once there's more adoption in a few years browsers should look for it and fallback to querying the DNSSEC chain (could be included with an edns option RFC7901).
Something to consider in the future is implementing RFC9102[0] which is an experimental TLS extension for embedding the DNSSEC chain this should significantly improve TTFB. It'll still need to request the DS record/trust anchor from the p2p client.
It uses WKNavigationDelegate[0] it allows responding to authentication challenges by accepting/rejecting certificates or continuing with default handling. This is used to do certificate pinning. DS records are stored on chain and requested via the P2P client. The DS record is used to verify DNSSEC and to obtain a certificate hash/TLSA record.
I have been following Gio development for quite some time, and it's still in the early stages. Text selection was added recently. It could be better but it's a good start.
Double click to select a word and triple click to select paragraph doesn't work for me either but can't reproduce some of the other issues running it natively.
I think the analogy here is weak. A blockchain-based naming system is different, though. It's governed by consensus. The majority of users must agree on who owns a particular name or at least that's how it should work.
Don't know of any other way to create a decentralized name system without doing something similar (regardless if it's top level or secondary level names)
yeah that's the thing who owns the bridge? some may argue that control of ownership should be decentralized and some may disagree. but like I said it wouldn't be too bad if users ended up using it under some TLD but that's my opinion
I believe they distributed around 70% of the coin supply to open source developers (I think only a small percentage claimed so far). The names are sold in auctions and the coins are burned after the winner is declared (I understand that early adopters will still benefit from that).
It's decentralized, and ultimately, users will decide how they value those names, though. So, for example, they can put them under dot-hns or prioritize ICANN TLDs in case of a name collision. Some existing TLDs may decide to claim their name if they disagree with a centralized root. IMO, It's flexible and pretty experimental for now
> The central KSK is a reason for normal users to dislike DNSSEC, but it's not why virtually nobody in the industry has deployed it, even though we're rapidly closing in on 3 decades of standardization effort for it.
I'm aware of the complexity DNSSEC adds and your opinions on it ;) it's getting easier to deploy with modern resolvers (also ed25519 is now more widely supported)
I still think it makes sense to cut the middleman (certificate authorities) one day and rely directly on DNS (whether its DNSSEC, DNSCurve, or some other way).
> Handshake is a deeply silly idea; literally, the Internet analog of selling the Brooklyn Bridge.
I think seeing whether a blockchain (specifically made for DNS) is suitable for this problem is more important at this point. At the end of the day, if you don't like name collisions with ICANN, you can add a suffix to the namespace like `.hns` (using some proxy) or just prefer ICANN TLDs in the resolver.
Creating an alternative or an extension to the DNS root is pretty ambitious. If they had chosen a TLD similar to .eth, .bit ... etc., it would have been more manageable, and they could've avoided issues with name collisions.
However, there are some advantages to decentralizing trust in the root since there won't be a need for a root KSK[0] or a central entity that manages the root zone making DNSSEC + DANE more appealing even for existing TLDs.
I checked an archive of root zone data from June 1999 to May 2021[0], and there don't seem to be A records for any TLD. Not sure why you're having this issue, but I'm curious to know which Linux distro/software doesn't resolve ai.
they don't have much power besides adding your name -> pubkey binding in the tree.