It sounds more like they are referring to the prior atproto transition:* scope that had no restrictions, which was horrible, re: every app needs a new account
Today, apps can limit the permissions they request during login. I don't see the dynamic, assuming they mean something where during approval you can deselect options, as a horrible situation. That's something very few apps do even outside of atproto.
No I am talking about users not being able to change the app permissions. App developers are not the ones to set my permissions, they can reccomend what their apps could need but any platform not giving users final say cannot be taken seriously.
You must not use very many apps, or must have a ton of accounts. Plenty of apps taken seriously that don't have this dynamic feature. (speaking generally, not specific to atproto)
Not aware of many apps that force oauth and don't allow email signup... The only exception some github centric apps that request too much and then are mostly let down by github not getting their auth screens up to standards for years, but who is surprised there. I just don't try those unless i already trust the company and really need to.
But all that aside i think a protocol aiming to liberate users and be an open app platform cannot be held to the same standards as corporate garbage that we don't expect to behave differently. Atproto needs to show some commitment to the values of putting users first, its so close.
> Atproto needs to show some commitment to the values of putting users first, its so close.
I think the Bluesky domination and recent "funding" from Bain Capital move it away from these goals. I've left the app and ecosystem. "user" growth is negative and they are misleading about how many "accounts" there are.
I believe what they are referring to is custom permissions set by the person logging in, regardless of what the app itself requested.
e.g. login, disable all writes, all attempted repo writes using that oauth token fail.