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.
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.
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!
No! Wrong! Try again! Your data is just your data. Conversations have relationships. Relationships have links. Disconnected data points are fucking useless!
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.
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.