5 ms·

This is some newfangled shit to be sure. I guess it’s time for some old dogs to learn some new tricks of this new web..

by indigodaddy 1y ago

quotemstr 1y ago
I fail to see what problem this thing solves.
- robmccoll 1y ago
  Data sovereignty and distributed identity. It's trying to avoid a centralized authority on where data is stored or how to resolve and trust an identity other than DNS and using signatures to validate data that you didn't get directly from the author.
- danabramov 1y ago
  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?
- doytch 1y ago
  Listen I'm not a crazy huge fan of a lot of new tech, but this is pretty transformational. When reading the first article [1] I was struck by the fact that it granted so much new freedom to your "social identity" on the internet. The comparison to hosting providers was incredible, because imagine you building a website and posting your thoughts there or starting a business there...and then immediately being shut down and all your data lost because of some arbitrary change of policy at your "host". Everyone always talks about how your Google account being tied to logins is scary because you can get arbitrarily locked out. This protocol makes something like functionally impossible since /you/ control your data. [1] https://overreacted.io/open-social/ https://overreacted.io/open-social/
  - card_zero 1y ago
    > Bob, however, isn’t technical. He doesn’t even know that there is a “repository” with his “data”. He got a repository behind the scenes when he signed up for his first open social app. > Bob uses a free hosting service that came by default with his first open social app. > If she owns alice.com, she can point at://alice.com at any server. But does Bob own bob.com? That sounds beyond Bob's abilities and interest level. So Bob is stuck on one platform, in practice, and it's full other Bobs who are also stuck. The "free hosting service" (why is it free?) is now the gatekeeper. It may let him switch platforms.
    - beeflet 1y ago
      Even if bob "owned" bob.com, that amounts to a row in some centralized database somewhere.
      - card_zero 1y ago
        It seems to mean that Bob's free hosting service has to be a relatively benign and permanent institution like ICANN, and not some ropey old operation like Photobucket. Others on this thread are talking about Decentralized IDs, https://en.wikipedia.org/wiki/Decentralized_identifier https://en.wikipedia.org/wiki/Decentralized_identifier . Looks like those are stored in several competing systems. There's a blockchain one, a Chinese one that wants to know your real name, and a Microsoft one that wants to store your photo. This all has, uh, implications, which sound much less liberating than this at:// protocol does at first.
- tolerance 1y ago
  It’s Web3 reanimated.
  - danabramov 1y ago
    I like to think of it as Web3, the good parts.
- skybrian 1y ago
  You could do it with top-level domain names alone, but that would require users to buy domain names and retain control over them forever. It means you have to trust your domain registrar and pay them fees. This is too big a burden for new Bluesky users. You could do it more cheaply with subdomains, but then you have to trust the owner of the parent domain. So instead, they created a new registry and a way for users to cryptographically sign their registry documents. Since this is all done behind the scenes, most users are still fully trusting the central Bluesky infrastructure. But in theory, they could migrate off of it.

This is some newfangled shit to be sure. I guess it’s time for some old dogs to learn some new tricks of this new web..

quotemstr 1y ago

I fail to see what problem this thing solves.

robmccoll 1y ago
Data sovereignty and distributed identity. It's trying to avoid a centralized authority on where data is stored or how to resolve and trust an identity other than DNS and using signatures to validate data that you didn't get directly from the author.
danabramov 1y ago
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?
doytch 1y ago
Listen I'm not a crazy huge fan of a lot of new tech, but this is pretty transformational. When reading the first article [1] I was struck by the fact that it granted so much new freedom to your "social identity" on the internet. The comparison to hosting providers was incredible, because imagine you building a website and posting your thoughts there or starting a business there...and then immediately being shut down and all your data lost because of some arbitrary change of policy at your "host". Everyone always talks about how your Google account being tied to logins is scary because you can get arbitrarily locked out. This protocol makes something like functionally impossible since /you/ control your data. [1] https://overreacted.io/open-social/ https://overreacted.io/open-social/
- card_zero 1y ago
  > Bob, however, isn’t technical. He doesn’t even know that there is a “repository” with his “data”. He got a repository behind the scenes when he signed up for his first open social app. > Bob uses a free hosting service that came by default with his first open social app. > If she owns alice.com, she can point at://alice.com at any server. But does Bob own bob.com? That sounds beyond Bob's abilities and interest level. So Bob is stuck on one platform, in practice, and it's full other Bobs who are also stuck. The "free hosting service" (why is it free?) is now the gatekeeper. It may let him switch platforms.
  - beeflet 1y ago
    Even if bob "owned" bob.com, that amounts to a row in some centralized database somewhere.
    - card_zero 1y ago
      It seems to mean that Bob's free hosting service has to be a relatively benign and permanent institution like ICANN, and not some ropey old operation like Photobucket. Others on this thread are talking about Decentralized IDs, https://en.wikipedia.org/wiki/Decentralized_identifier https://en.wikipedia.org/wiki/Decentralized_identifier . Looks like those are stored in several competing systems. There's a blockchain one, a Chinese one that wants to know your real name, and a Microsoft one that wants to store your photo. This all has, uh, implications, which sound much less liberating than this at:// protocol does at first.
tolerance 1y ago
It’s Web3 reanimated.
- danabramov 1y ago
  I like to think of it as Web3, the good parts.
skybrian 1y ago
You could do it with top-level domain names alone, but that would require users to buy domain names and retain control over them forever. It means you have to trust your domain registrar and pay them fees. This is too big a burden for new Bluesky users. You could do it more cheaply with subdomains, but then you have to trust the owner of the parent domain. So instead, they created a new registry and a way for users to cryptographically sign their registry documents. Since this is all done behind the scenes, most users are still fully trusting the central Bluesky infrastructure. But in theory, they could migrate off of it.