your app can run its own pds - keith.is
if you’re building on atproto, you’ve probably reached for “sign in with bluesky” as your auth story. it works! the OAuth flow is fine. but every time a user shows up without a bluesky account, you have to send them to bluesky first, watch them get confused by a totally different brand, and hope they come back. that’s a weird seam in your own product.
Who Actually Owns Your ATProto Identity? Hint: It's Probably Not You
ATProto gives your PDS operator full control of your signing and rotation keys, letting them impersonate you across every app in the ecosystem or kill
Internet Handle
Every time you sign up for a new social app, you have to rush to claim your username. If someone else got there first, too bad. And that username only works on that one app anyway.
Internet Handle
Every time you sign up for a new social app, you have to rush to claim your username. If someone else got there first, too bad. And that username only works on that one app anyway.
earnest question for @pfrazee.com + anyone else: Why does deactivating your bsky social account deactivate your PDS data repo altogether, inhibiting your ability to sign into other atproto apps?
Sep 17, 2026 at 5:02 PM
The frustrating thing about this is that when you "Login with Bluesky", you're not even actually logging in with Bluesky The App. You may be using a Bluesky PBC-hosted PDS, but it has nothing to do with @bsky.app, other than it's the PDS you're assigned when you create an account on their client.
It would be great to get some transparency in here. @janlindblad.bsky.social: 1. will users be able to use the w social app with any #atproto account? 2. will users be able to verify themselves (to be able to post) with any atproto account or do you require users to move their accounts to your pds?
My recollection of this is that even if you just pop a new ATProto account into existence and start spitting out `app.bsky.feed.post` records, they don't show up unless you actually go through a Bluesky onboarding & agreeing to ToS, so they should have an email for you through that process.
reminder that you can always revoke oauth access at bsky.social/account (also a good place to check for apps you forgot you logged in to !)
Blacksky was one of the 1st PDSs to allow open sign ups We are also now the largest PDS deployment that doesn't run any of bsky's code Sorry for the turbulence. It was the one-time price to pay for being able to build features like private accounts or sign-in via phone number w/o waiting on Bluesky
also it is completely bonkers that @bsky.app requires you to select a "Hosting Provider" on login and i have to remember whatever @eurosky.social's address is. guys, if you want this decentralization thing to happen, it should not suck so much to use! the Bluesky app should just read it from my DID
Any other atproto app devs run into this UX snafu? User already has a bsky account; uses it to login to your app. User was only logged in to bsky.app, not bsky.social and doesn’t have a password saved there. User is very confused why their browser doesn’t remember their bsky password.
Claude is inheriting a centralized app-centric bias here (which existing OAuth profiles may share) To wind up in a decentralized world where all "my data" lives on "my PDS" -- regardless of how many atproto apps I authorize to store stuff there for me (see 🧵) -- we should invert that paradigm
Paul Rohr
TL/DR = yes, it's a subtle conceptual shift: - from app-centric (apps control identity/data, delegating access to you at signin) - to identity-centric (you control identity/data, delegating access to apps at signin) Really looking forward to how the team evolves the OAuth UX to address this! /END
