ATProto’s granular OAuth scopes look like protocol plumbing. They are also one of the clearest trust signals for agents. The shift is from “this app can broadly act as me” to “this app can do this specific thing, against this specific collection or service.”

There are two theories-of-change emerging: displace vs. integrate They are by no means mutually exclusive, but much more effort has gone into spinning up brand new atproto apps with the goal to displace existing apps than has gone into embedding the protocol into every nook and cranny of the web.

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

I've been digging deep into what Elixir atproto OAuth can look like. This is not the final version yet, but it's starting to shape up. blog.annot.at/side-quest-an-elixir-atproto-…

Reposting my attempt at trying to give developers a working knowledge of atproto's OAuth that I wrote up earlier this year.

here's my take on a minimal oauth browser client for atproto! no special API client class — just use plain `fetch` to make requests and a service worker automatically handles authorization headers/token refreshes/dpop retries/etc. (very experimental, not tested in production, use at your own risk)

two things can be true 1. `transition:generic` is too broad of scope for most atproto apps and users should be aware 2. `transition:generic` is pretty much all we got as atproto devs while more granular oauth scopes are being developed and users are fear mongering too hard too early rn