{"id":8134,"date":"2025-10-04T16:27:00","date_gmt":"2025-10-04T16:27:00","guid":{"rendered":"https:\/\/pokecon.jp\/job\/?p=8134"},"modified":"2025-10-04T16:27:00","modified_gmt":"2025-10-04T16:27:00","slug":"where-its-at-overreacted","status":"publish","type":"post","link":"https:\/\/pokecon.jp\/job\/8134\/","title":{"rendered":"Where It’s at:\/\/ \u2014 overreacted"},"content":{"rendered":"\n<\/p>\n
\n

You might have heard about the AT protocol (if not, read this!<\/a>)<\/p>\n

Together, all servers speaking the AT protocol comprise the atmosphere<\/em>\u2014a web of hyperlinked JSON. Each piece of JSON on the atmosphere has its own at:\/\/<\/code> URI:<\/p>\n

But where do they point, exactly?<\/p>\n

Given an at:\/\/<\/code> URI, how do you locate the corresponding JSON?<\/p>\n

In this post, I\u2019ll show you the exact process of resolving an at:\/\/<\/code> URI step by step. Turns out, this is also a great way to learn the details of how at:\/\/<\/code> works.<\/p>\n

Let\u2019s start with the structure of a URI itself.<\/p>\n\n

The User as the Authority<\/a><\/h3>\n

As you might know, a URI often contains a scheme (for example, https:\/\/<\/code>), an authority<\/em> (like wikipedia.com<\/code>), a path (like \/Main_Page<\/code>), and maybe a query.<\/p>\n

In most protocols, including https:\/\/<\/code>, the authority part points at whoever\u2019s hosting<\/em> the data. Whoever created<\/em> this data is either not present, or is in the path:<\/p>\n

<\/p>\n

https:\/\/<\/text><\/g>\/profile\/<\/text><\/g>\/post\/3lzy2ji4nms2z<\/text><\/g>bsky.app<\/text><\/g>ruuuuu.de<\/text><\/g><\/g>the app<\/text><\/g><\/g>the user<\/text><\/g><\/svg><\/span><\/p>\n

The at:\/\/<\/code> protocol flips that around.<\/strong><\/p>\n

In at:\/\/<\/code> URIs, whoever created<\/em> the data is the authority, in the most literal sense:<\/p>\n

<\/p>\n

the format<\/text><\/g><\/g>the user<\/text><\/g><\/g>.feed.post\/3lzy2ji4nms2z<\/text><\/g>at:\/\/<\/text><\/g>\/<\/text><\/g>app.bsky<\/text><\/g>ruuuuu.de<\/text><\/g><\/svg><\/span><\/p>\n

The user is the authority for their own data.<\/strong> Whoever\u2019s hosting<\/em> the data could change over time, and is not<\/em> directly included in an at:\/\/<\/code> URI. To find out the actual physical server hosting that JSON, you\u2019re gonna need to take a few steps.<\/p>\n\n

A Post in the Atmosphere<\/a><\/h3>\n

Let\u2019s try to resolve this at:\/\/<\/code> URI to the piece of JSON it represents:<\/p>\n

<\/p>\n

the format<\/text><\/g><\/g>the user<\/text><\/g><\/g>.feed.post\/3lzy2ji4nms2z<\/text><\/g>at:\/\/<\/text><\/g>\/<\/text><\/g>app.bsky<\/text><\/g>ruuuuu.de<\/text><\/g><\/svg><\/span><\/p>\n

An easy way to resolve an at:\/\/<\/code> URI is to use an SDK<\/a> or a client app. Let\u2019s try an online client, for example, pdsls<\/a> or Taproot<\/a> or atproto-browser<\/a>. They\u2019ll figure out the physical server where its JSON is currently hosted, and show that JSON for you.<\/p>\n

The above at:\/\/<\/code> URI points at this JSON, wherever it is currently being hosted:<\/strong><\/p>\n

\n
{<\/span><\/span>\n  \"<\/span>uri<\/span>\"<\/span>: <\/span>\"<\/span>at:\/\/did:web:iam.ruuuuu.de\/app.bsky.feed.post\/3lzy2ji4nms2z<\/span>\"<\/span>,<\/span><\/span>\n  \"<\/span>cid<\/span>\"<\/span>: <\/span>\"<\/span>bafyreiae4ehmkk4rtajs5ncagjhrsv6rj3v6fggphlbpyfco4dzddp42nu<\/span>\"<\/span>,<\/span><\/span>\n  \"<\/span>value<\/span>\"<\/span>: <\/span>{<\/span><\/span>\n    \"<\/span>text<\/span>\"<\/span>:<\/span> \"<\/span>posting from did:web, like a boss<\/span>\"<\/span>,<\/span><\/span>\n    \"<\/span>$type<\/span>\"<\/span>:<\/span> \"<\/span>app.bsky.feed.post<\/span>\"<\/span>,<\/span><\/span>\n    \"<\/span>langs<\/span>\"<\/span>:<\/span> [<\/span>\"<\/span>en<\/span>\"<\/span>],<\/span><\/span>\n    \"<\/span>createdAt<\/span>\"<\/span>:<\/span> \"<\/span>2025-09-29T12:53:23.048Z<\/span>\"<\/span><\/span>\n  }<\/span><\/span>\n}<\/span><\/span><\/code><\/pre>\n<\/figure>\n
You can guess by the $type<\/code> field being \"app.bsky.feed.post\"<\/code> that this is some kind of a post (which might explain why it has fields like text<\/code> and langs<\/code>).<\/p>\n
A careful reader might notice that the uri<\/code> in the JSON block is also<\/em> an at:\/\/<\/code> URI but it\u2019s slightly different from the original at:\/\/<\/code> URI we requested:<\/p>\n
\n
\/\/ What's at:\/\/ruuuuu.de\/app.bsky.feed.post\/3lzy2ji4nms2z ?<\/span><\/span>\n{<\/span><\/span>\n  \"<\/span>uri<\/span>\"<\/span>: <\/span>\"<\/span>at:\/\/did:web:iam.ruuuuu.de\/app.bsky.feed.post\/3lzy2ji4nms2z<\/span>\"<\/span>,<\/span><\/span>\n  \/\/ ...<\/span><\/span>\n}<\/span><\/span><\/code><\/pre>\n<\/figure>\n
In particular, the short ruuuuu.de<\/code> authority has expanded into a longer did:web:iam.ruuuuu.de<\/code> authority. Maybe that\u2019s the physical host?<\/p>\n
Actually, no, that\u2019s not the physical host either<\/strong>\u2014it\u2019s something called an identity<\/em>. Turns out, resolving an at:\/\/<\/code> URI is done in three distinct steps:<\/p>\n
    \n
  1. Resolve the handle to an identity (\u201cwho are you?\u201d)<\/em><\/li>\n
  2. Resolve that identity to a hosting (\u201cwho holds your data?\u201d)<\/em><\/li>\n
  3. Request the JSON from that hosting (\u201cwhat is the data?\u201d)<\/em><\/li>\n<\/ol>\n
    Let\u2019s go through each of these steps and see how they work.<\/p>\n\n
    From Handles to Identities<\/a><\/h3>\n
    The at:\/\/<\/code> URIs you\u2019ve seen earlier are fragile because they use handles.<\/p>\n
    Here, ruuuuu.de<\/code>, danabra.mov<\/code>, and tessa.germnetwork.com<\/code> are handles:<\/p>\n
    (Read more about domains as \u201cinternet handles\u201d here.<\/a>)<\/em><\/p>\n
    The user may choose to change their at:\/\/<\/code> handle later, and it is important for that not to break any links between pieces of JSON already on the network.<\/p>\n
    This is why, before you store<\/em> an at:\/\/<\/code> URI, you should turn it into a canonical form by resolving the handle to something that never changes\u2014an identity<\/em>. An identity is like an account ID, but global and meant for the entire web. There are two mechanisms to resolve a handle to an identity (also known as a \u201cDID<\/a>\u201d):<\/p>\n
      \n
    1. Query the DNS TXT record at _atproto.<\/code> looking for did=???<\/code><\/li>\n
    2. Make an HTTPS GET to https:\/\/\/.well-known\/atproto-did<\/handle><\/code><\/li>\n<\/ol>\n
      The thing you\u2019re looking for, the DID, is going to have a shape like did:something:whatever<\/code>. (We\u2019ll revisit what that means later.)<\/p>\n\n
      For example, let\u2019s try to resolve ruuuuu.de<\/code> via the DNS mechanism:<\/p>\n
      \n
      $<\/span> nslookup<\/span> -type=TXT<\/span> _atproto.ruuuuu.de<\/span><\/span>\nServer:<\/span>\t\t192.168.1.254<\/span><\/span>\nAddress:<\/span>\t192.168.1.254#53<\/span><\/span>\n <\/span>\nNon-authoritative<\/span> answer:<\/span><\/span>\n_atproto.ruuuuu.de<\/span>\ttext<\/span> =<\/span> \"<\/span>did=did:web:iam.ruuuuu.de<\/span>\"<\/span><\/span><\/code><\/pre>\n<\/figure>\n
      Found it!<\/p>\n
      The ruuuuu.de<\/code> handle claims<\/em> to be owned by did:web:iam.ruuuuu.de<\/code>, whoever that may be. That\u2019s all that we wanted to know at this point:<\/p>\n
      <\/p>\n
      at:\/\/<\/text><\/g>at:\/\/<\/text><\/g>did:web:iam.ruuuuu.de<\/text><\/g>\/…<\/text><\/g>\/…<\/text><\/g>ruuuuu.de<\/text><\/g><\/g><\/g><\/g><\/g><\/svg><\/span><\/p>\n
      Note this doesn\u2019t prove<\/em> their association yet.<\/strong> We\u2019ll need to verify that whoever controls the did:web:iam.ruuuuu.de<\/code> identity \u201cagrees\u201d with ruuuuu.de<\/code> being their handle. The mapping is bidirectional. But we\u2019ll confirm that in a later step.<\/p>\n\n
      Now let\u2019s try to resolve danabra.mov<\/code> using the DNS route:<\/p>\n
      \n
      $<\/span> nslookup<\/span> -type=TXT<\/span> _atproto.danabra.mov<\/span><\/span>\nServer:<\/span>\t\t192.168.1.254<\/span><\/span>\nAddress:<\/span>\t192.168.1.254#53<\/span><\/span>\n <\/span>\nNon-authoritative<\/span> answer:<\/span><\/span>\n_atproto.danabra.mov<\/span>\ttext<\/span> =<\/span> \"<\/span>did=did:plc:fpruhuo22xkm5o7ttr2ktxdo<\/span>\"<\/span><\/span><\/code><\/pre>\n<\/figure>\n
      That also worked! The danabra.mov<\/code> handle claims to be owned by the did:plc:fpruhuo22xkm5o7ttr2ktxdo<\/code> identity, whoever that may be:<\/p>\n
      <\/p>\n
      at:\/\/<\/text><\/g>at:\/\/<\/text><\/g>did:plc:fpruhuo22xkm5o7ttr2ktxdo<\/text><\/g>\/…<\/text><\/g>danabra.mov<\/text><\/g><\/g><\/g><\/g><\/g>\/…<\/text><\/g><\/svg><\/span><\/p>\n
      This DID looks a bit different than what you saw earlier but it\u2019s also a valid DID. Again, it\u2019s important to emphasize we\u2019ve not confirmed the association yet.<\/p>\n\n
      Subdomains like barackobama.bsky.social<\/code> can also be handles.<\/p>\n
      Let\u2019s try to resolve it:<\/p>\n
      \n
      $<\/span> nslookup<\/span> -type=TXT<\/span> _atproto.barackobama.bsky.social<\/span><\/span>\nServer:<\/span>\t\t192.168.1.254<\/span><\/span>\nAddress:<\/span>\t192.168.1.254#53<\/span><\/span>\n <\/span>\nNon-authoritative<\/span> answer:<\/span><\/span>\n***<\/span> Can<\/span>'<\/span>t find _atproto.barackobama.bsky.social: No answer<\/span><\/span><\/code><\/pre>\n<\/figure>\n
      The DNS mechanism didn\u2019t work, so let\u2019s try with HTTPS:<\/p>\n
      \n
      $<\/span> curl<\/span> https:\/\/barackobama.bsky.social\/.well-known\/atproto-did<\/span><\/span>\ndid:plc:5c6cw3veuqruljoy5ahzerfx<\/span><\/span><\/code><\/pre>\n<\/figure>\n
      That worked! This means that barackobama.bsky.social<\/code> handle claims to be owned by the did:plc:5c6cw3veuqruljoy5ahzerfx<\/code> identity, whoever that is:<\/p>\n
      <\/p>\n
      at:\/\/<\/text><\/g>at:\/\/<\/text><\/g>did:plc:5c6cw3veuqruljoy5ahzerfx<\/text><\/g>\/…<\/text><\/g>\/…<\/text><\/g>barackobama.bsky.social<\/text><\/g><\/g><\/g><\/g><\/g><\/svg><\/span><\/p>\n
      So you get the idea. When you see a handle, you can probe it with DNS and HTTPS to see if it claims to be owned by some identity (a DID). If you found a DID, you\u2019ll then be able to (1) verify it actually owns that handle, and (2) locate the server that hosts the data for that DID. And that will be the server you\u2019ll ask for the JSON.<\/p>\n
      In practice<\/a>, if you\u2019re building with AT, you\u2019ll likely want to either deploy your own handle\/did resolution cache or hit an existing one. (Here\u2019s one implementation.<\/a>)<\/p>\n\n
      AT Permalinks<\/a><\/h3>\n
      Now you know how handles resolve to identities, also known as DIDs. Unlike handles, which change over time, DIDs never change\u2014they\u2019re immutable.<\/p>\n
      These at:\/\/<\/code> links, which use handles, are human-readable but fragile:<\/p>\n
      They will break if one of us changes a handle again.<\/p>\n
      In contrast, the at:\/\/<\/code> links below, which use DIDs, will not break until we either delete our accounts, delete these records, or permanently take down our hosting:<\/p>\n
      So, really, this is the \u201ctrue form\u201d of an at:\/\/<\/code> URI:<\/p>\n
      <\/p>\n
      the format<\/text><\/g>the user<\/text><\/g><\/g>.feed.post\/3lzy2ji4nms2z<\/text><\/g>at:\/\/<\/text><\/g>\/<\/text><\/g>app.bsky<\/text><\/g>did:web:iam.ruuuuu.de<\/text><\/g><\/g><\/svg><\/span><\/p>\n
      Think of at:\/\/<\/code> links with DIDs as \u201cpermalinks\u201d.<\/strong> Any application storing<\/em> at:\/\/<\/code> URIs should store them in this canonical form so that logical links between our pieces of JSON don\u2019t break when we change our handles or change our hosting.<\/p>\n
      Now that you know how to resolve a handle to a DID, you want to do two things:<\/p>\n
        \n
      1. Verify that whoever owns this DID actually goes by that handle.<\/li>\n
      2. Find the server that hosts all the data for this DID.<\/li>\n<\/ol>\n
        You can do both of these things by fetching a piece of JSON called the DID Document<\/em>. You can think of it as sort of a \u201cpassport\u201d for a given DID.<\/p>\n
        How you do that depends on what kind of DID it is.<\/p>\n\n
        From Identities to Hosting<\/a><\/h3>\n
        Currently, there are two kinds of DIDs, known as DID methods<\/em>, supported by the AT protocol: did:web<\/code> (a W3C draft<\/a>) and did:plc<\/code> (specified<\/a> by Bluesky).<\/p>\n
        Let\u2019s compare them.<\/p>\n
        did:web<\/code><\/a><\/h4>\n
        The ruuuuu.de<\/code> handle claims to be owned by did:web:iam.ruuuuu.de<\/code>:<\/p>\n
        <\/p>\n
        at:\/\/<\/text><\/g>at:\/\/<\/text><\/g>did:web:iam.ruuuuu.de<\/text><\/g>\/…<\/text><\/g>\/…<\/text><\/g>ruuuuu.de<\/text><\/g><\/g><\/g><\/g><\/g><\/svg><\/span><\/p>\n
        To check this claim, let\u2019s find the DID Document for did:web:iam.ruuuuu.de<\/code>. The did:web<\/code> method<\/a> is a specification that specifies an algorithm<\/a> for that.<\/p>\n
        In short, you cut off the did:web:<\/code> from the DID, append \/.well-known\/did.json<\/code> to the end, and run an HTTPS GET request:<\/p>\n
        \n
        $<\/span> curl<\/span> https:\/\/iam.ruuuuu.de\/.well-known\/did.json<\/span> |<\/span> jq<\/span><\/span>\n{<\/span><\/span>\n  \"@context\"<\/span>:<\/span> [<\/span><\/span>\n    \"https:\/\/www.w3.org\/ns\/did\/v1\"<\/span>,<\/span><\/span>\n    \"https:\/\/w3id.org\/security\/multikey\/v1\"<\/span>,<\/span><\/span>\n    \"https:\/\/w3id.org\/security\/suites\/secp256k1-2019\/v1\"<\/span><\/span>\n  ],<\/span><\/span>\n  \"id\"<\/span>:<\/span> \"<\/span>did:web:iam.ruuuuu.de<\/span>\",<\/span><\/span>\n  \"alsoKnownAs\"<\/span>:<\/span> [<\/span><\/span>\n    \"at:\/\/ruuuuu.de\"<\/span><\/span>\n  ],<\/span><\/span>\n  \"verificationMethod\"<\/span>:<\/span> [<\/span><\/span>\n    {<\/span><\/span>\n      \"id\"<\/span>:<\/span> \"<\/span>did:web:iam.ruuuuu.de#atproto<\/span>\",<\/span><\/span>\n      \"type\"<\/span>:<\/span> \"<\/span>Multikey<\/span>\",<\/span><\/span>\n      \"controller\"<\/span>:<\/span> \"<\/span>did:web:iam.ruuuuu.de<\/span>\",<\/span><\/span>\n      \"publicKeyMultibase\"<\/span>:<\/span> \"<\/span>zQ3shWHtz9QMJevcGBcffZBBqBfPo55jJQaVDuEG7ZwerALGk<\/span>\"<\/span><\/span>\n    }<\/span><\/span>\n  ],<\/span><\/span>\n  \"service\"<\/span>:<\/span> [<\/span><\/span>\n    {<\/span><\/span>\n      \"id\"<\/span>:<\/span> \"<\/span>#atproto_pds<\/span>\",<\/span><\/span>\n      \"type\"<\/span>:<\/span> \"<\/span>AtprotoPersonalDataServer<\/span>\",<\/span><\/span>\n      \"serviceEndpoint\"<\/span>:<\/span> \"<\/span>https:\/\/blacksky.app<\/span>\"<\/span><\/span>\n    }<\/span><\/span>\n  ]<\/span><\/span>\n}<\/span><\/span><\/code><\/pre>\n<\/figure>\n
        This DID Document looks sleep-inducing but it tells us three important things:<\/p>\n
However, note that this piece of JSON represents a certain social media post itself<\/em>, not a web page or a piece of some app. It\u2019s pure data as a piece of JSON<\/strong>, not a piece of UI. You may think of the $type<\/code> stating the data format<\/em>; the app.bsky.*<\/code> prefix tells us that the bsky.app<\/code> application might know something about what to do with it. Other applications may also<\/a> consume and produce data in this format.<\/p>\n