March 5, 2025

AT Protocol, OAuth, and well, decentralization

I've been very happy with how Bluesky and AT Protocol as a whole is going, except for one thing: OAuth.

OAuth in itself isn't a bad thing. while I do have gripes over AT Protocol implementing OAuth 2.1, mainly because it hasn't been widely adopted yet and introduces complex ideas like DPoP, OAuth would finally allow permissioned controls around clients/frontends accessing and manipulating user data.

what I'm concerned about though? OAuth allowing services to be built around backend-for-frontend architecture, and the subsequent encouragement of them.

for people that have been following me, this post provides no additional insights whatsoever. I've just decided to consolidate it into one long post for me to sum up my thoughts better.

a quick side note here: AppView is a fancy term for a backend. they listen to records broadcasted by your personal data server (to a relay service), and they provide endpoints that'd let you view those records in a digestible manner (e.g. "I want to see posts from people I follow" and "how many people liked this posts?").

a potential lock-in concern

with backend-for-frontend, the AppView is now positioned as an intermediary between clients and personal data servers, and AppView now gains significant control around how data gets written.

there's two problems I envision:

• AppView can bake in attestation signatures into the records written to the personal data server, and it would only accept records that have been signed by itself.

  • this approach effectively locks out third-party AppViews from proliferating and being used by clients, not unless said AppView are granted a way to sign "verified" records.

  • sure, you technically own your data, but what else can you do with it?

• or, why do all that when AppView could just not write any records to begin with?

  • this effectively undermines the protocol's vision.

  • sure, it's not a "decentralized service," but they can still claim that it's a Bluesky or AT Protocol-adjacent service. it's not a good look regardless if it gains traction.

sure, these are all "future adversaries" and "what-ifs." but that doesn't mean it won't happen. so much of a decentralized protocol is designed around envisioning these kinds of worst case scenarios, and this is what I think could happen.

services and its third-party developer ecosystem

there's currently a decent selection of Bluesky clients, and while I'm not fond of some of these apps relying on Bluesky to do something it wasn't designed or intended to do (and the literal fact that they will also fall if Bluesky were to tumble), I think it's great that these apps even exist at all as they demonstrate that there is some intent of being open.

thing is, these clients communicates directly with the user's personal data server. how are they meant to exist afterwards if Bluesky's AppView were to sit in between?

okay, sure, AppViews can tack on an API that allows third-party clients to authenticate with it, but the problem I see is:

• this is now a boilerplate that every AppView of every service has to implement if they want a third-party ecosystem to exist and flourish.

• services can decide on the shape of the API however they want, whether it'll be REST, GraphQL or completely unstandardized. this is more of a nitpick, but we already have XRPC, so why can't we just stick to it? I think it's great to have a lingua franca that everyone can use.

• there is some discussion around private records, this is a great thing because clients can now store its own private settings and other sorts of data on the user's personal data server. but how should AppViews expose this functionality to clients?

reality about your data, and the need for seamless post-fail transition

AT Protocol places great importance on the idea of owning your data, and while this is a great thing. this is only meaningful to services that don't involve social interactions. you own your likes and replies to someone else's posts, but they don't mean much on their own.

it's true, take a look at this Bluesky post record. although PDSls allows you to click on the references that it contains to other records, it stands clear that this isn't a convenient way of viewing the post or thread.

this is why I don't believe owning your data is enough. these data are essentially junk if there isn't a possibility of someone, a third-party, being able to spin up an alternate AppView after a service's unfortunate demise, and have everything like existing clients work as if nothing had happened.

an (imperfect) decentralization lock-in mechanism

I'll have to admit, I believed in AT Protocol mostly because of its current topology.

it's not perfect, mainly in the sense that the same problem currently exists in the form of services using app passwords on their server-side rendered apps.

but app passwords aside (since they'll be gone anyway once OAuth is fully settled), the fact that services have to authenticate to the user's personal data server to make authenticated requests to their AppView, and that records have to be created by the client to the PDS, means that services are guaranteed to be locked open.

sure, this is reliant on the hope that services bother publishing lexicon schemas, whether it's the records or XRPC endpoints to the AppView. but even without, this is already a step-up from before where it's a literal black box between you and your data.

yes, this means that services can't properly solve the issue of "read-after-write," where users might encounter the issue where they find their posts missing because the AppView haven't yet picked up on the records, and where the solution would've been to write to the user's personal data server and the AppView's database at the same time since the AppView can directly make authenticated requests.

but is that truly something worth risking decentralization for? I don't think so. I think we should look for other answers.

conclusion

the conclusion? I'm extremely serious about AT Protocol and Bluesky, precisely because I don't think we have second chances. Twitter has gone to shit, Mastodon hasn't exactly been a hit, and for one reason or another people landed on a service that just so happens to also be decentralized.

it's worth reiterating that people do not care about decentralization, they didn't come to Bluesky for this aspect, and they will not care about this until it is too late.

I'm being obnoxious for the sake of the protocol, and if it helps at all with decentralization, then I'm more than willing to play that role.