Bluesky Protocol Services

---

There are at least three parts that you'd need to solve:

1. AFAIK there is no single globally canonical Firehose. Different relays aggregate different sets of PDSes, and some might decide not to include your PDS if they don't like your content. The Firehose also isn't really the authority here. It transports signed updates from account repositories.

2. In theory you could make up a new kind of DNS record instead of NS, called PDS, PLC, or something. You'd ask your TLD registry to publish something like `PLC ` instead of the NS records for your DNS server.

The value should probably be the account DID (that's the PLC mentioned above), rather than the address of its PDS. The account DID is the stable identity that signs the repository updates. The PDS is just the server currently hosting that account's repository, and its address can change.

3. You then have a bootstrap problem. To get from an account DID to its PDS, you resolve the DID document and look for its `#atproto_pds` service entry. But `did:web` resolution uses HTTPS and therefore DNS. `did:plc` uses the PLC directory, but reaching that directory and then reaching the PDS URL also normally requires DNS.

So the DNS replacement would depend on the old DNS system to discover the server containing its DNS records.

---

Then, as an example, Google's DNS resolver at 8.8.8.8 would subscribe to one or more Firehoses, index DNS records from account repositories, and verify that their updates were signed by the DID named in the registry record.

Querying would then be something like: you look at the top-level record for the domain, see that there is no NS entry, find the PDS or DID entry, and look in your local Firehose-derived database for DNS entries signed by that account.

If the records aren't there, you might resolve the DID, find the current PDS, and fetch the repository directly. But that brings you back to the bootstrap problem.

Maybe the registry record would need to include both the DID and some kind of glue-like PDS address. Or perhaps the new system would need an independent way of resolving DIDs and locating PDSes without using DNS. I'm not sure what that would look like, especially once you include PDS migration and key rotation, but I think this is an additional part the proposal would need to solve.

/shrug

I think that’s the key of it for me. Usually this criticism of Bluesky users is part of a justification to stay on Twitter. When the exact same problem exists on there, just with a different type of user.