3 ms·

Here's a TLDR on the problem it solves: https://overreacted.io/open-social/#the-big-picture https://overreacted.io/open-social/#the-big-picture. I've linked to

Here's a TLDR on the problem it solves: https://overreacted.io/open-social/#the-big-picture https://overreacted.io/open-social/#the-big-picture. I've linked to this article in the intro. In short, it's a different model where apps participate host user data on the web under user's control. This enables some interesting use cases, like all apps can deeply interoperate by default. It's hard to explain this concisely, the article I linked to is my best attempt.

quotemstr 1y ago
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.
- danabramov 1y ago
  This is building on top of DNS. At the center of at:// is a question of identity. 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 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.
  - quotemstr 1y ago
    > 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.
- edoceo 1y ago
  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. Queue the Xkcd about infrastructure.

quotemstr 1y ago

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.

danabramov 1y ago
This is building on top of DNS. At the center of at:// is a question of identity. 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 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.
- quotemstr 1y ago
  > 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.
edoceo 1y ago
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. Queue the Xkcd about infrastructure.