Who manages the managers users?
I don't hang out with technical people. My friends are scattered throughout industries and fields; the most technology-forward among them are product managers or PhDs. So when I go to talk about the ATProtocol and all the cool stuff going on in the Atmosphere, inevitably I must talk about Bluesky.
This is uncomfortable for several reasons:
I don't like social media, particularly the microblogging format
In the (American) cultural discourse, using Bluesky can be interpreted as partisan posturing. Depending on who you talk to it's the place where the left-wing loonies went or it's the place that went completely fascist once it cracked 30 million users.
I want to talk about data ownership and decentralization. So why do I need to talk about another VC-backed tech company?
I power through, and usually manage to get into the good stuff. The Default Always Wins was the last time I had a go at this for the wider internet. The point (I eventually got there) was that ATProto as a standard has the inherent advantage that users don't have to know the first thing about it to use it. The existing internet mental model works just as well with ATProto apps as it does with legacy apps.
Except... appview developers are sold on ATProto by the fact they don't have to manage user data. Which means I must talk about Bluesky again.
The tension is a classic UX versus infrastructure one. On the one hand, it is a miserable user experience to ask someone to create a Bluesky account to use my book-sharing app. I don't care how nice the Bluesky sign-in page is. Why should I have to create a Bluesky account? I want to sign up for GrahameReads, not Bluesky.
On the other hand, you cannot make GrahameReads, Inc. responsible for the arbitrary data someone might put on their servers if you force them to be GrahamePDS as well. I just want to have some lists and some reviews, but now you're telling me I have to host VODs from stream.place? I can't afford the storage costs. Not to mention unscrupulous users who might start putting actually illegal materials on their PDS—I don't want "going to jail" to be on the table because I wanted to compare notes on Tress of the Emerald Sea with my friends.
Bluesky sticks their nose in here because they are the only realistic PDS provider on the market. Yes, [WORD]sky exists, yes selfhosted.social exists, yes plenty of nerds have their data on a Raspberry Pi next to their N64. But for someone standing up a new app, if you need a way for someone to sign up for your app? You're going with Bluesky. They're the biggest, best funded, and least likely to go anywhere—valuable traits when you're making business partners.
Assuming or don't build these businesses before I finish writing this article, there's a business opportunity here in removing Bluesky from the loop. It all comes down to the tension of user management on the protocol.
IdentityKit
Originally, I had thought to solve the "make an account where?" pain point by writing a library to make it easy for the appview developer to set up PDS auth for their users. You pull in my identity-kit dependency, connect your database and some blob storage somewhere, set a domain to base new handles on (@*.grahamereads.com) and you're off to the races.
I very quickly gave up on this because doing so involves creating a "multi-tenanted server in a can" dependency, something which is certainly possible but is beyond the likes of me. I only just managed to figure out how to stand up a Jellyfin server on an old PC; simultaneous server orchestration was never going to be my thing. Plus there's a whole lot of other things to consider...
I never made the library. I did start working out how it would be packaged, what it would do, how it would compare to existing JS/TS libraries that do similar things, etc. Auth is an area I've never really dug into before, so it was a fun way to spend an afternoon, understanding the different strategies employed to deal with user management.
More importantly, I don't think it's the right way to resolve the ATProto tension. From the user's point of view, this model is great. I want to sign up for GrahameReads? I sign up for GrahameReads. Depending on my know-how and my preferences, one of the following things happen:
I know nothing of the Atmosphere. I make an account on GrahameReads and I can use the service. Yes, my username looks a bit funny, but what of it? The only place it's exposed is in the settings anyway.
I start to make an account, but I notice the "sign into the Atmosphere" link. Since I use leaflet.pub, I remember I have a handle and connect GrahameReads to that. I can now share my leaflet posts with friends in GrahameReads and we can discuss them in there. Plus my subscribers are already in my followers list! This is great!
I make an account on GrahameReads, not knowing or caring that I already have a Bluesky account. They remain unconnected graphs, just as my Google account and my Reddit accounts are unconnected. Sure, I have to set some stuff up, but it's a digital model I'm comfortable with as I've been doing it most of my life.
From the point of view of the CTO of GrahameReads, this sucks. Data hosting isn't wildly expensive, but I haven't budgeted for video, or 3D models, or whatever other data is out there on the web. I certainly haven't budgeted for CSAM filters in my text-only application. The ATProtocol was supposed to make my life easier—I just define my lexicons and let someone else worry about storage, hosting, and all the rest of that complicated backend junk. Now you're telling me I have to monitor the entire internet?
The middle ground
The current state of the ecosystem (Bluesky for everyone) is too far on the "easy-infrastructure" end of the spectrum. A library that puts PDS hosting on the shoulders of the app developer swings too far in the other direction. The middle ground should be something a developer can "plug-and-play" with minimal effort that provides all the advantages of using Bluesky PDS hosting as your sign-up without confusing users.
We need:
OKTAPDS!
OktaPDS (a name which will definitely not cause any copyright issues) is a PDS-as-a-service (PDSaaS? PDSPS? PDSS?) provider. Its customers are those whose data it hosts, and the developers whose lives it makes easier. It provides the following features:
Multi-tenanted PDS hosting, similar to selfhosted.social or Bluesky
PDS data explorer, to make it easy for a user to browse, download, and even edit their data
Data storage, some amount free to start with the option to purchase more
Customizable login/signup widgets, to make it easy for developers to connect to their service. Just wire up your "login/signup" button to OktaPDS' API or have them host your login page.
Existing OktaPDS user signs up to your app? We email them a magic link and they're done
New user? The page has your branding and your messaging. We just provide some info and some links to OktaPDS and about the Atmosphere
Existing Atmosphere user signs up? We automatically redirect to them for OAuth or password login. No sweat.
Plus we handle all of that "important" infrastructure stuff: scaling, backups, failover, etc., so you don't have to. Can you imagine being a developer who doesn't have to worry about accidentally deleting production data? This could be you:
Essentially, this service ends up as a Google Account/Okta hybrid. There are a few ways to make money to support it, the most obvious being data storage packages, custom domain registration/management, consulting for apps looking to join the Atmosphere, and so on. Monetization is probably the trickiest piece of all of this: finding an ethical business model to allow people to store or manage arbitrary data seems like it should be possible. Maybe you're the one to do it.
I didn't invent this concept; PDS providers as an idea already exist. But there's not a whole lot of discussion I've seen around a business that is so fundamental to the entire ATProtocol project. If someone is doing this, let me know—I'd love to hear about what you've been up to. And if this is new to you, feel free to steal it and go stand up the next great piece of internet infrastructure.
Maybe just send me a bottle of scotch once you've made it big.
Image credit: Евгения from Pixabay