buffrr

> 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.

> not address recovery of lost keys/identities

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).

> but I wanted to make sure you were choosing the contribution path you wanted to build upon

> that goes double because it already has tight coupling to GN due to Chromium

Interesting i'll experiment with moving this to GN. I have more high priority things to deal with atm but i'll get to that.

> 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).