patricktree.me
forked from
danabra.mov/overreacted
my blog https://overreacted.io
wip
danabra.mov
+8
-8
public/where-its-at/index.md
+8
-8
public/where-its-at/index.md
···
28
28
29
29
In most protocols, including `https://`, the authority part points at whoever's *hosting* the data. Whoever *created* this data is either not present, or is in the path:
30
30
31
-
31
+
32
32
33
33
**The `at://` protocol flips that around.**
34
34
35
35
In `at://` URIs, whoever *created* the data is the authority, in the most literal sense:
36
36
37
-
37
+
38
38
39
39
**The user is the authority for their own data.** Whoever's *hosting* the data could change over time, and is *not* directly included in an `at://` URI. To find out the actual physical server hosting that JSON, you're gonna need to take a few steps.
40
40
···
44
44
45
45
Let's try to resolve this `at://` URI to the piece of JSON it represents:
46
46
47
-
47
+
48
48
49
49
An easy way to resolve an `at://` URI is using an [SDK](https://sdk.blue/) or a client app. Let's try an online client, for example, [pdsls](https://pdsls.dev/at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z) or [Taproot](https://atproto.at/viewer?uri=at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z) or [atproto-browser](https://atproto-browser.vercel.app/at/ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z). They'll figure out the physical server where its JSON is currently hosted, and show that JSON for you.
50
50
···
127
127
128
128
The `ruuuuu.de` handle *claims* to be owned by `did:web:iam.ruuuuu.de`, whoever that may be. That's all that we wanted to know at this point:
129
129
130
-
130
+
131
131
132
132
**Note this doesn't *prove* their association yet.** We'll need to verify that whoever controls the `did:web:iam.ruuuuu.de` identity "agrees" with `ruuuuu.de` being their handle. The mapping is bidirectional. But we'll confirm that in a later step.
133
133
···
146
146
147
147
That also worked! The `danabra.mov` handle claims to be owned by the `did:plc:fpruhuo22xkm5o7ttr2ktxdo` identity, whoever that may be:
148
148
149
-
149
+
150
150
151
151
This DID looks a bit different than what you saw earlier but it's also a valid DID. Again, it's important to emphasize we've not confirmed the association yet.
152
152
···
174
174
175
175
That worked! This means that `barackobama.bsky.social` handle claims to be owned by the `did:plc:5c6cw3veuqruljoy5ahzerfx` identity, whoever that is:
176
176
177
-
177
+
178
178
179
179
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'll 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'll ask for the JSON.
180
180
···
202
202
203
203
So, really, this is the "true form" of an `at://` URI:
204
204
205
-
205
+
206
206
207
207
**Think of `at://` links with DIDs as "permalinks".** Any application *storing* `at://` URIs should store them in this canonical form so that logical links between our pieces of JSON don't break when we change our handles or change our hosting.
208
208
···
219
219
220
220
### From Identities to Hosting
221
221
222
-
Currently, there are two kinds of DIDs, known as *DID methods*, supported by the AT protocol: `did:web` (a W3C standard) and `did:plc` ([specified](https://github.com/did-method-plc/did-method-plc) by Bluesky).
222
+
Currently, there are two kinds of DIDs, known as *DID methods*, supported by the AT protocol: `did:web` (a [W3C draft](https://w3c-ccg.github.io/did-method-web/)) and `did:plc` ([specified](https://github.com/did-method-plc/did-method-plc) by Bluesky).
223
223
224
224
Let's compare them.
225
225