🧵 I've been wracking my brain around ATProto onboarding. Why do all ATProto apps make you create a new account before you can do anything interesting? Why don't we let people start with an email address or phone #? Then claim your identity if/when the need actually arises.

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.

its actually really cool that instead of having my own account system i can now just integrate atproto oauth into whatever project i'm making and instantly have everything i need in terms of user identity

why does every little atproto app being cooked up rn have to have a frontend Designed By Claude ™️ why are we so hyped about social data and an open internet and then turning to ai when its time to create and play

The vector for new signups of atproto accounts is apps. Adoption is unlikely to come through just one app. A “drive” app would actually make sense and I have some ideas there but I think it will be varied. A lot of different apps can get big - from recipes to events to whatever.

So this is one of the cool things about apps in the Atmosphere. They have to declare what stuff in your account they're going to touch.

this is kinda another reason im starting to think more and more that there would be worth in splitting atprotos identity layer out as its own spec and standard. building up handles and oauth around a DID makes for a really flexible cross platform (and potentially cross ecosystem) identity system

i think it's time someone made a google suite alternative in atproto, have that be the "default" PDS; literally just replace sign in with google then everyone understands the concept of oauth and we can move on with our happy atmospheric lives