3 ms·

> Finally, the important bit is that I (as an identity) should be able to change both my handle (i.e. how people refer to me) and my hosting (i.e. where my data

> Finally, the important bit is that I (as an identity) should be able to change both my handle (i.e. how people refer to me) and my hosting (i.e. where my data is stored) without breaking any links to my data from other data But that's how the web already works. If I own example.com I can change its target from, say, 1.2.2.2 to 2.3.3.3 any time I want. My identity doesn't change even while my host does. What's the difference? If you want another layer of indirection, add a CNAME or a 30X redirect. > The identity document also contains my public key which is important to allow trustless caching and retransmission of the data. Sure. That's what DANE (https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...) is for! > on top of CBOR, and WebSocket We have a perfectly good web built out of normal, boring stateless HTTP requests and text formats. I'm skeptical of switching to stateful sockets and binary formats. I prefer my technologies to be minimal deltas built atop stable, proven foundations, and my NIH spidey sense is tingling when I read about stuff like this. Why wouldn't adding per-update signature data to RSS (including previous entries, blockchain-style, in the hash) do exactly what this stack does but without all the new technology?

danabramov 1y ago
>But that's how the web already works. If I own example.com I can change its target from, say, 1.2.2.2 to 2.3.3.3 any time I want. My identity doesn't change even while my host does. What's the difference? To clarify, we're talking about generalizing the notion of a "username" or a "handle". E.g. I started with `danabramov.bsky.social` (given out to me) and then moved to `danabra.mov`. I might move to some other domain later. The idea is you should be able to do this as many times as you like without a chain of redirects where losing one domain in the chain loses all your links. (Also, "normal" people don't know what a redirect even is, much less how to set one up.) Hence, an indirection is "above" the chain rather than a part of the chain. The DID points at the domain. In other words, "normal" people don't want their social media reply chains, or social media mentions, or their GitHub issues, or their Medium articles, to break when someone else swaps their user handle. We're using handles for domains so we need to add an affordance so they "act like handles". >Sure. That's what DANE is for Not familiar with it so can't comment unfortunately! But hopefully the above gives some context. We want to stay decoupled both from the handle and from the concrete hosting. Changing the handle and changing the hosting should be doable with zero cooperation from whoever holds your previous domain or previous hosting. >We have a perfectly good web built out of normal, boring stateless HTTP requests and text formats. Yes, and that still works — you can pull it on demand with plain HTTP as I show in the article. The CBOR/WebSocket stuff is for the high scale use case (have a look at https://pdsls.dev/jetstream?instance=wss%3A%2F%2Fjetstream1.us-east.bsky.network%2Fsubscribe https://pdsls.dev/jetstream?instance=wss%3A%2F%2Fjetstream1....), i.e. realtime large-scale social aggregation. >I prefer my technologies to be minimal deltas built atop stable, proven foundations, and my NIH spidey sense is tingling when I read about stuff like this. I hear ya! Someday it might become boring too. (See https://datatracker.ietf.org/doc/draft-newbold-at-architecture/ https://datatracker.ietf.org/doc/draft-newbold-at-architectu..., https://datatracker.ietf.org/doc/draft-holmgren-at-repository/ https://datatracker.ietf.org/doc/draft-holmgren-at-repositor...). I personally find the additions tasteful and minimal for what they try to accomplish. >Why wouldn't adding per-update signature data to RSS (including previous entries, blockchain-style, in the hash) do exactly what this stack does but without all the new technology? I'm not sure how you'd represent arbitrary application data in RSS (e.g. Tangled.org is essentially "GitHub on atproto"), how you'd do high-scale fanout with RSS (realtime to millions of users), or how you'd have properties like ability to move hosting with no disruption to user-visible experience in downstream apps, and no reduction in trust in the data.
- quotemstr 1y ago
  Ah. Thanks for the explanation > To clarify, we're talking about generalizing the notion of a "username" or a "handle". Name registries are hard. How do you handle collision avoidance and impersonation resistance? You can do registration centrally and hierarchically like DNS. You can generate collision-resistant tokens (e.g. GUIDs) and do some kind of content-addressed metadata lookup thing, perhaps via a DHT or something. These names are opaque though. You could allow people to generate names consisting of a recognizable name _paired_ with an opaque token, but if you do that, you open yourself up to impersonation attacks --- quotemstr-B87FAEAB-9D34-418D-A6E9-B95BEBC9DD0B vs C243F0B4-AF9A-4F48-9880-8436B1C15293. AIUI, the concept here is that DNS names can point to opaque tokens and that the token can remain stable without requiring continuity of DNS registration? What do you think of Namecoin, which seems like what you get when you follow this line of thinking to its logical conclusion? Without something like NC, isn't any registration scheme not centrally gated subject to infinity sybil attacks?
  - danabramov 1y ago
    There’s a bidirectional link between a user handle (domain) and their identity (a DID). But the data is logically rooted in the DID. Domain handle is an alias that can change over time — but your DID never changes. Links are stored with DID so that changing your handle doesn’t break existing links.
rmccue 1y ago
DID is basically one extra level of abstraction, allowing for different methods. did:web: eg is literally HTTP, did:dns: is DNS, and there’s loads of others. This extra level of abstraction allows of arbitrary IDs, which is what the PLC DIDs were created for. Let’s say that I am currently known as rmccue.com.au. I move overseas and now want to be rmccue.scot - or worse, because I am no longer in .au, I can’t even keep my old domain name. How do you persist this identity? With PLC, I can instead be an abstract did:plc:hv27plmlx6zkuv7bnzbqb6xr (an arbitrary hash of the genesis entry for my DID). I associate rmccue.com.au with this via a TXT record, and back the other direction by recording the domain as an alias. If I change my handle, I’m still the same arbitrary handle everywhere, everyone keeps following me, and in theory old references to my alias could even continue resolving. (Similarly, this solves the issue for trademark changes, name changes throughout a person’s life, and changing job roles.) The core of it is basic tech: 1. Look up _atproto.rmccue.io for a TXT record 2. If it’s did:plc:… send a HTTP request to the directory - eg https://plc.directory/hv27plmlx6zkuv7bnzbqb6xr https://plc.directory/hv27plmlx6zkuv7bnzbqb6xr 3. Parse the JSON response to get my signing keys and where I’m hosted.
- quotemstr 1y ago
  Ah, thanks. Might you consider going full DHT for name lookup then?
  - rmccue 1y ago
    There’s some DHT-based DID methods so it’s possible - one of the nice things about the DID abstraction layer is that could be added. As I understand, atproto is intentionally limiting to PLC and Web for now, and monitoring the ecosystem. Every method has to be implemented by every client, so you naturally want to be cautious in how many you support. (I don’t work for or represent Bluesky, so can’t speak to any plans other than what they’ve stated publicly!)

danabramov 1y ago

>But that's how the web already works. If I own example.com I can change its target from, say, 1.2.2.2 to 2.3.3.3 any time I want. My identity doesn't change even while my host does. What's the difference? To clarify, we're talking about generalizing the notion of a "username" or a "handle". E.g. I started with `danabramov.bsky.social` (given out to me) and then moved to `danabra.mov`. I might move to some other domain later. The idea is you should be able to do this as many times as you like without a chain of redirects where losing one domain in the chain loses all your links. (Also, "normal" people don't know what a redirect even is, much less how to set one up.) Hence, an indirection is "above" the chain rather than a part of the chain. The DID points at the domain. In other words, "normal" people don't want their social media reply chains, or social media mentions, or their GitHub issues, or their Medium articles, to break when someone else swaps their user handle. We're using handles for domains so we need to add an affordance so they "act like handles". >Sure. That's what DANE is for Not familiar with it so can't comment unfortunately! But hopefully the above gives some context. We want to stay decoupled both from the handle and from the concrete hosting. Changing the handle and changing the hosting should be doable with zero cooperation from whoever holds your previous domain or previous hosting. >We have a perfectly good web built out of normal, boring stateless HTTP requests and text formats. Yes, and that still works — you can pull it on demand with plain HTTP as I show in the article. The CBOR/WebSocket stuff is for the high scale use case (have a look at https://pdsls.dev/jetstream?instance=wss%3A%2F%2Fjetstream1.us-east.bsky.network%2Fsubscribe https://pdsls.dev/jetstream?instance=wss%3A%2F%2Fjetstream1....), i.e. realtime large-scale social aggregation. >I prefer my technologies to be minimal deltas built atop stable, proven foundations, and my NIH spidey sense is tingling when I read about stuff like this. I hear ya! Someday it might become boring too. (See https://datatracker.ietf.org/doc/draft-newbold-at-architecture/ https://datatracker.ietf.org/doc/draft-newbold-at-architectu..., https://datatracker.ietf.org/doc/draft-holmgren-at-repository/ https://datatracker.ietf.org/doc/draft-holmgren-at-repositor...). I personally find the additions tasteful and minimal for what they try to accomplish. >Why wouldn't adding per-update signature data to RSS (including previous entries, blockchain-style, in the hash) do exactly what this stack does but without all the new technology? I'm not sure how you'd represent arbitrary application data in RSS (e.g. Tangled.org is essentially "GitHub on atproto"), how you'd do high-scale fanout with RSS (realtime to millions of users), or how you'd have properties like ability to move hosting with no disruption to user-visible experience in downstream apps, and no reduction in trust in the data.

quotemstr 1y ago
Ah. Thanks for the explanation > To clarify, we're talking about generalizing the notion of a "username" or a "handle". Name registries are hard. How do you handle collision avoidance and impersonation resistance? You can do registration centrally and hierarchically like DNS. You can generate collision-resistant tokens (e.g. GUIDs) and do some kind of content-addressed metadata lookup thing, perhaps via a DHT or something. These names are opaque though. You could allow people to generate names consisting of a recognizable name _paired_ with an opaque token, but if you do that, you open yourself up to impersonation attacks --- quotemstr-B87FAEAB-9D34-418D-A6E9-B95BEBC9DD0B vs C243F0B4-AF9A-4F48-9880-8436B1C15293. AIUI, the concept here is that DNS names can point to opaque tokens and that the token can remain stable without requiring continuity of DNS registration? What do you think of Namecoin, which seems like what you get when you follow this line of thinking to its logical conclusion? Without something like NC, isn't any registration scheme not centrally gated subject to infinity sybil attacks?
- danabramov 1y ago
  There’s a bidirectional link between a user handle (domain) and their identity (a DID). But the data is logically rooted in the DID. Domain handle is an alias that can change over time — but your DID never changes. Links are stored with DID so that changing your handle doesn’t break existing links.

rmccue 1y ago

DID is basically one extra level of abstraction, allowing for different methods. did:web: eg is literally HTTP, did:dns: is DNS, and there’s loads of others. This extra level of abstraction allows of arbitrary IDs, which is what the PLC DIDs were created for. Let’s say that I am currently known as rmccue.com.au. I move overseas and now want to be rmccue.scot - or worse, because I am no longer in .au, I can’t even keep my old domain name. How do you persist this identity? With PLC, I can instead be an abstract did:plc:hv27plmlx6zkuv7bnzbqb6xr (an arbitrary hash of the genesis entry for my DID). I associate rmccue.com.au with this via a TXT record, and back the other direction by recording the domain as an alias. If I change my handle, I’m still the same arbitrary handle everywhere, everyone keeps following me, and in theory old references to my alias could even continue resolving. (Similarly, this solves the issue for trademark changes, name changes throughout a person’s life, and changing job roles.) The core of it is basic tech: 1. Look up _atproto.rmccue.io for a TXT record 2. If it’s did:plc:… send a HTTP request to the directory - eg https://plc.directory/hv27plmlx6zkuv7bnzbqb6xr https://plc.directory/hv27plmlx6zkuv7bnzbqb6xr 3. Parse the JSON response to get my signing keys and where I’m hosted.

quotemstr 1y ago
Ah, thanks. Might you consider going full DHT for name lookup then?
- rmccue 1y ago
  There’s some DHT-based DID methods so it’s possible - one of the nice things about the DID abstraction layer is that could be added. As I understand, atproto is intentionally limiting to PLC and Web for now, and monitoring the ecosystem. Every method has to be implemented by every client, so you naturally want to be cautious in how many you support. (I don’t work for or represent Bluesky, so can’t speak to any plans other than what they’ve stated publicly!)