I understand, appreciate, and share the desire for a decentralized and censorship-resistant social graph. I'm just not sure what problem the new URL scheme solves. Is DNS not already decentralized? It's not that I don't see the value in what you're trying to do --- it's that don't understand what problem you're solving that we can't solve with hypertext, RSS, and data attributes.
> The advantage of storing structured app-specific entities, such as posts and likes, instead of HTML documents is obvious.
Agreed.
> This allows you to create many projections of the same data—a profile page, a list of posts, an individual post with comments.
WE HAD THIS! In some sense, we still do. XSLT exists. The dream was always that XML documents linked together with defined schemas would be the source of truth for an information web and we'd style them dynamically to provide for different UIs.
I mean, look. Maybe the XML-centric semantic web was just an idea before its time. Maybe at:// will succeed where it didn't due to timing, real-world social context, or just the force of will of its proponents.
But from a technical POV, I'm just not seeing why I'd want to use this instead of reviving those older but proven technologies.
For identity, you want some kind of a global login, or a "handle", that you can remember. at:// uses domains for that (e.g. my "handle" is danabra.mov). That is literally DNS.
However, you also want somebody to hold your data. Most people don't want to host their own data. (I don't.) So that's where the notion of hosting comes into play. My current host, as explained in the article, is https://morel.us-east.host.bsky.network. (That's also resolved through DNS.)
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 ("links between JSON" is how we represent "reply to a post", "like to a reply", "follow of a person", etc). This is why links are tied to an identity rather than to hosting or to handle. The identity document also contains my public key which is important to allow trustless caching and retransmission of the data.
That's about it.
>But from a technical POV, I'm just not seeing why I'd want to use this instead of reviving those older but proven technologies.
I think everything being signed is a big one. There is no need to trust anyone retransmitting the data because it's transferring signed commits. But yes, this is essentially a fusion of something like Git with something like RSS, but for JSON and on top of DNS, HTTPS, CBOR, and WebSocket.
Compared to RSS, the novel parts is that you don't need to trust the retransmitters, that it's pushed via WebSockets, that it scales to real-time communication for millions of users (in production today), and that it's application-agnostic but the data formats are application-controlled. E.g. we have different apps like Tangled.org (GitHub on atproto), Leaflet.pub (Medium on atproto), etc, all able to "see" each other's data and interop.
> 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.
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?
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.)
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!)
>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....), 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.
>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.
> 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?
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.
>why do I want a global login? that sounds like hell.
You can still have many distinct identities if you want to, the point is just that you also don't have to for cases when you want to have shared data flowing and interlinking between apps.
>How is websockets better than XHR in this case?
Websockets are used for retransmitting changes from millions of repositories to a bunch of apps that want to aggregate over that data and create app-specific indexes. I'm not sure what XHR has to do with that or how it helps there. Have a look at the data stream: https://pdsls.dev/jetstream?instance=wss%3A%2F%2Fjetstream1....
> why do I want a global login? that sounds like hell
Ask social media users if they would like one account or separate accounts for every platform, they think that later is the hell
OAuth is one piece of evidence that confirms this general pattern among online users. Fewer accounts are easier to manage, just give me a click to login button on your site for an account I already have and manage elsewhere
I don't socialize with other nerds IRL. I know what you're getting at, but I think it's at the point right now where "normal people" have paranoia of getting locked out of their google/apple accounts, because it has happened to pretty much everyone I know at least once.
They both send you through the loop of assuming you have a device, so if you lose your device you're screwed.
For example, you can even see memes like this are very popular:
I'm the goto person in my friends/family for things like this and not one has ever asked about being locked out of a google/apple account. I don't know anyone this has ever happened to, so when people say it's some widespread problem at top of mind, forgive me for being extremely skeptical. These stories tend to be told by people it has happened to and extended beyond the bounds they are actually a worry for most people.
I'm with you this seems to be reimplementing the wheel but, recently XSLT has been widely deprecated. And the (sole?) maintainer of some very core infrastructure for that is paused or archived or something that will slow/block features and fixes.
So, is a revamp, new code with less baggage, doing the same-ish thing. Then in 20 years it will have the baggage and we'll get a new one.
> The advantage of storing structured app-specific entities, such as posts and likes, instead of HTML documents is obvious.
Agreed.
> This allows you to create many projections of the same data—a profile page, a list of posts, an individual post with comments.
WE HAD THIS! In some sense, we still do. XSLT exists. The dream was always that XML documents linked together with defined schemas would be the source of truth for an information web and we'd style them dynamically to provide for different UIs.
I mean, look. Maybe the XML-centric semantic web was just an idea before its time. Maybe at:// will succeed where it didn't due to timing, real-world social context, or just the force of will of its proponents.
But from a technical POV, I'm just not seeing why I'd want to use this instead of reviving those older but proven technologies.