3 ms·

>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 ev

>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.

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.