🦫 alert! We published the second episode of "Teach the Web new Tricks", featuring native support for @atproto.com ! Learn more how we improve user agency and privacy at webbeef.org/atproto.html : - Native at:// protocol support. - Log in your PDS and forget OAuth ! - Authorize 3rd parties

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

🧵 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.

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

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.

🧵 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.

Who is writing this idea up? I think we’re going to need it. There are a lot of objects out there being created as regular database entries or associated with the PDS of person who first entered them, but ideally we want to allow the creator or publisher to claim them and redirect without recreating

Once you experience shared lexicons and the benefits of a single portable identity, it feels like a new open network. But the most important part is that it practically works as an extension of the web. We can add social features to our websites without even mentioning atproto. Frictionless adoption

1/X I made an atproto proposal around PDS to PDS repo migration that gets around all of the pain points of account migration today and intentionally builds a migration flow for users to go to the PDS that they want to move to and commence the migration from there.

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?

We're very pumped to announce that the reference PDS now has an account management page! atproto.com/blog/pds-account-management You can now manage permissions, update your password, or deactivate your account directly from your PDS, as a regular user — no command line tools or Bluesky interfaces required!