5 ms·

Oh this is not mine actually — Paul wrote this one :) atproto does use DNS under the hood for domain verification but atproto itself is a bit higher-level. It

Oh this is not mine actually — Paul wrote this one :) atproto does use DNS under the hood for domain verification but atproto itself is a bit higher-level. It builds on top of DNS, HTTP, JSON, web sockets, and a few other specs.

danabramov 2y ago
If you’re specifically asking why the identity system is not “rooted” in DNS (i.e. why at://danabra.mov resolves to another host than my website) — it’s because we want users to be able to change their hosting over time without breaking links between records. The actual identity system is “rooted” in a stable identifier (which is a hash of the first version of your identity record). That’s your global immutable ID in the entire network. The identity record for your ID specifies your current public key, your current domain name (which acts as a human-readable handle), and your current host (which actually contains your data). This extra level of indirection ensures you’re always able to change your user-readable handle (eg if you get a new domain or your domain expires etc), and that you’re always able to change your host (eg if your host goes down or you don’t like its services or you want to host data yourself). The key piece allowing this is the identity registry of course. Think of it similar to npm registry. We run a centralized one, but all records are signed so you can always recursively verify that we haven’t tampered with any of the records. This layer is already very thin but in longer term we’d like to move this layer outside the company to be governed independently, similar to ICANN.
- str4d 2y ago
  Additionally, a user _can_ root their identity in DNS if they want, by using did:web instead of did:plc [0]. The main Bluesky client doesn't expose this (presumably because did:web cannot provide a mechanism for automatic migration between PDSs (due to the PDS having no control over the DID document) or recovering from loss of control of the domain name, so it requires more technical expertise), but there are users successfully using this method for their identities. [0] https://atproto.com/specs/did#blessed-did-methods https://atproto.com/specs/did#blessed-did-methods

danabramov 2y ago

If you’re specifically asking why the identity system is not “rooted” in DNS (i.e. why at://danabra.mov resolves to another host than my website) — it’s because we want users to be able to change their hosting over time without breaking links between records. The actual identity system is “rooted” in a stable identifier (which is a hash of the first version of your identity record). That’s your global immutable ID in the entire network. The identity record for your ID specifies your current public key, your current domain name (which acts as a human-readable handle), and your current host (which actually contains your data). This extra level of indirection ensures you’re always able to change your user-readable handle (eg if you get a new domain or your domain expires etc), and that you’re always able to change your host (eg if your host goes down or you don’t like its services or you want to host data yourself). The key piece allowing this is the identity registry of course. Think of it similar to npm registry. We run a centralized one, but all records are signed so you can always recursively verify that we haven’t tampered with any of the records. This layer is already very thin but in longer term we’d like to move this layer outside the company to be governed independently, similar to ICANN.

str4d 2y ago
Additionally, a user _can_ root their identity in DNS if they want, by using did:web instead of did:plc [0]. The main Bluesky client doesn't expose this (presumably because did:web cannot provide a mechanism for automatic migration between PDSs (due to the PDS having no control over the DID document) or recovering from loss of control of the domain name, so it requires more technical expertise), but there are users successfully using this method for their identities. [0] https://atproto.com/specs/did#blessed-did-methods https://atproto.com/specs/did#blessed-did-methods