This post takes a look at ATProto from a different angle, and explores the value of some possibly less-noticed pieces of it.

The “Login with Google” button has been so useful and yet so horrible for the freedom of the web. Why does google get to be the gatekeeper to all of our web logins?

We need an alternative, but it also needs to be easy, and by making handles domains, and making it so that normal people can use and understand it, they have made it possible for an actually decentralized social login button.

Linking Identity to your Personal Data Store and using Domains as Handles is a crucialcombination that is really starting to unlock web freedom.

A lot of what I’m trying to get at with this post is that there is more than one way to leverage ATProto, and that there are some pretty major things it has started to do right that we really need right now.

We’re used to the idea that there’s more than one way to make a web app, and the same is true even if you are building it on ATProto. It hasn’t set a lot in stone, it’s just given us some bricks that we can all share.

The “AppView” is a component of the ATProto architecture that you are given nearly free rein on. It can be any kind of thing you want, and I think there’s all kinds of unexplored possibilities there.

You might even be able to make an AppView with a meaningful ActivityPub integration, or possibly borrow ideas about inboxes and outboxes as an alternative to relays.

  • JubilantJaguar@lemmy.world
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    1
    ·
    3 days ago

    So. Nobody gonna push back? It’s quite a convincing article. Especially this bit:

    This is something I want to put a bit more focus on: how important the PDS is.

    Giving people their own PDS is soooo crucial to having a free ( as in freedom ) internet. This needs to be something that I can:

    • Self host or have somebody else host for me
    • Download all of my data from, whenever I want to, and
    • Grant other apps read and write access to

    That last piece is crucial to the existence of all of these different ATProto apps. We are giving people their own data store and then letting them connect that to all kinds of different tools and experiences.

    It does at least seem like the protocol is more sophisticated, and so perhaps carries more potential, than (say) the one powering this site.

    • P03 Locke@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      1
      ·
      12 hours ago

      I don’t really like the use of a strawman to argument against in the article. I don’t care that it has a name and looks like an owl. It’s still a strawman, and it’s rather condescending.

      Getting back to the whole PDS bit, I don’t really get the importance, given our current scenarios. We are protecting against the enshittification of communication mediums that people use on a regular basis, by giving them a chance to jump ship and move to somewhere else. Or to somehow prevent the enshittification from happening in the first place.

      That’s it. Don’t add to this massive scope creep, by inventing other goals.

      While the app is centralized, the data isn’t completely centralized. In ATProto your data is written to your own PDS ( Personal Data Server ), and that PDS can be hosted by anyone. So if the app goes down, you can still have your data on your PDS.

      What good is this PDS when the app goes down? Let’s say that Bluesky gets bought out and everybody wants to get rid of it. You have your own PDS, fine. You find this cool new ATProto-compatible service that a lot of people are jumping on.

      Problem: Your PDS is useless. It’s not like you can link these disconnected replies in your data stream to the new service. Not everybody in the reply chain moved over, or they didn’t move over at the same time as you. What the hell in this PDS is actually useful to a new service? Start time? Number of replies? Block lists that no longer apply? And this new service is actually going to trust all of those numbers? Fuck no! Never trust user data!

      Well, if Omnivore was an ATProto app, and they shut down their server, all of the users would still have their data on their PDS in a standardized format. At that point, any other developers can come in and run another app, or even the same app if it was Open Source like omnivore, and access all of the existing data already on your PDS when you login.

      No! Wrong! Try again! Your data is just your data. Conversations have relationships. Relationships have links. Disconnected data points are fucking useless!

      When somebody lets you “Login with ATProto”, unlike the “Login with Google” button, it actually lets you login with your very own PDS.

      Oh, great… we’ve introduced login poisoning potential. Yes, trust this random user that they authenticated properly with a session token. I did not see the word “security” once in this article, which makes me think they haven’t even considered it.

      The “Login with Google” button has been so useful and yet so horrible for the freedom of the web. Why does google get to be the gatekeeper to all of our web logins?

      Because Google at least understands session security and login practices. What’s the one absolute law on the internet that OWASP hammers home over and over again?

      Never trust user input!

      You can’t decentralize authentication to such a degree that it’s personalized. There has to be a semi-centralized authority. With Lemmy, it’s the Lemmy instance that we choose.

      Gah, there is so much wrong here that I don’t feel like trying to comment on every single point here. This article is trying to answer the wrong questions and literally using a strawman to pretend that they know what the public is asking about.

    • poVoq@slrpnk.net
      link
      fedilink
      English
      arrow-up
      12
      arrow-down
      1
      ·
      edit-2
      3 days ago

      Hosting your own PDS would be like hosting your own email, but with the caveat that you can only access it through the Gmail interface and need to use the Gmail relay to communicate with others. In other words: completely pointless.

      • JubilantJaguar@lemmy.world
        link
        fedilink
        English
        arrow-up
        6
        ·
        3 days ago

        There’s a lot of debate around the Bluesky relay and whether or not it’s posible to “scale down” ATProto.

        Luckily, with all the attention that Bluesky and ATProto have gotten lately, there’s a lot of interest in running alternative relays just in case things go bad, and I think it may be possible that funding for a public good relay might materialize to protect from the potential failure or compromise of the Bluesky relay.

        But I also want to draw attention to another non-obvious thing about ATProto: the relay is not required.

        Let’s do a thought experiment. […]

        Etc. But I’m certain everyone here has actually read the article so they’ll already be familiar with that thought experiment.

        • poVoq@slrpnk.net
          link
          fedilink
          English
          arrow-up
          5
          ·
          edit-2
          3 days ago

          First of all that’s all hypothetical and secondly that thought experiment only talks about an app that uses the PDS as an auth source and data storage. It does not talk about your PDS communicating with another PDS, for which AFAIK a relay is needed.

    • flamingos-cant@feddit.uk
      link
      fedilink
      English
      arrow-up
      9
      ·
      3 days ago

      It ignores what happens if your PDS provider goes down. While currently Bluesky can repopulate a new PDS with your old data, I don’t see how that’s going to survive them adding stuff to the AT proto that isn’t public and therefore not kept persistently in Bkuesky’s servers (e.g. E2EE DMs).