I think we need a "PDS as a Service". There are a bunch of little apps I'd love to make, but I don't want to have to host a PDS for each of them for anyone who doesn't already have an account. But I'd be fine with allowing them to register to a PDS with my app's domain and pay a fee per sign up.
Aug 31, 2026 at 3:42 AM
Non-bluesky Public Hosted PDSs - Hilary's Leaflet
Existing public hosted PDS options. This also has some things I hope that anyone hosting a PDS will look at. (Backups, account creation and migration will be covered separately.)
Non-bluesky Public Hosted PDSs - Hilary's Leaflet
Existing public hosted PDS options. This also has some things I hope that anyone hosting a PDS will look at. (Backups, account creation and migration will be covered separately.)
Proposal: OAuth-based account creation · bluesky-social atproto · Discussion #4587
We recently added to the reference PDS (and underlying OAuth Provider) implementation support for Initiating User Registration via OpenID Connect 1.0, however, what I wasn't aware of when I add...
Public Hosted PDS options - created by HilaryBaumann.com
Manton Reece - Introducing the Micro.blog PDS
I’ve started rolling out an AT Protocol PDS — personal data server — for new Micro.blog users. In the Bluesky world, a PDS is what stores your posts, follows, photos, and other data from apps. In the same way that creating an account on Micro.blog automatically gives you a fediverse handle, I wanted people to be able to create a Micro.blog account and have everything they needed to sign into Bluesky.
Spinning Up Your Own Corner of the ATmosphere - Mostly Protocols
How to set up your own PDS from scratch - server, domain, email, migration, and all the little details that actually matter when you're trying to run your own piece of the ATmosphere.
Self-hosting a Bluesky PDS and using your domain as your handle
Rafael Eyng's tech blog
PDS: review existing oauth scopes via connected apps list · Issue #4838 · bluesky-social/atproto
Scenario I want to stay on top of which apps are messing with what in my PDS. To do so, it's not enough to just make a granular Goldilocks decision once per app. (The more apps I use, the fewer...
According to @mackuba.eu, blue.mackuba.eu/directory/pdses hosting atmosphere accounts. fedidb.com, popular software has this many servers: * Mastodon 9116 * Peertube 1529 * Misskey 1154 * Pixelfed 693 * Writefreely 573 * Sharkey 510 * Lemmy 431 * Pleroma 346 * Akkoma 331 Are we decentralized yet?
Shower thought idea: What about expanding the role of the PDS for account management? E.g. when signing up on atproto with any app/service for the first time, redirect to the already existing account interface (`/account/`) already present on reference PDS, making this flow mandatory to support.
We’ve been working on an Admin API. Programmatically manage your PDS servers, issue new invite codes, take down accounts, create accounts for automation. Great things are now possible with Protobase managed PDS hosting 👀 📓 -> protobase.at/docs/api/introduction
Admin API
protobase.atGreat question. My biggest takeaway: we need to come to an agreement on how to advertise PDS/service capabilities. MOST of the PDS implementations I'm testing support community.lexicon.service.describe, which works v well. #atproto
Scooter
So what were your major takeaways?
Since I don’t have time to dig into this yet, question: if I build a service that relies on this (say, @squire.quest) what happens to users with a PDS that doesn’t support this implantation yet. What’s the planned experience?
dad (aka miguel)
oh shit, offprints about to pop off atproto.com/blog/atproto-spaces-alpha
