oauth-feedback.md

1. So we're adding a new feature to Streamplace via a place.stream.example.record, which then obviously needs to be in the place.stream.authFull permission set. Am I correct in understanding that the best practice is: release the change to the permission-set, wait 30 minutes, release the feature? And then everything should just work? It's kind of a bummer to add a 30-minute timer to our release process; currently the latest version of the schemas go out automatically with new versions of the software.

2. How the heck do I hack on a permission set in development? If I want to add, say, permissions to create/update/delete place.stream.example.record to the permission set, I can't validate the permission set works until it gets rolled out to production. The only option I can think of is allow the Streamplace dev environment to operate in a fully parallel universe where every record created and indexed is e.g. com.elis-dev-environment.chat.message; but that's a pretty massive change.

(Note: allowing our permission set to do create/update/delete for place.stream.* would solve 1 and 2 at the same time really well. I mean, I still couldn't dev on it, but we could be pretty confident that it wouldn't break.)

3. Filed this separately as bluesky-social/atproto#4424 but that one's rough because our motivation to move off of transition:generic is that users are asking us why we're asking for permissions to access their Bluesky account and we aren't.

1. In the original proposal we discussed caching in more detail, as well as a mechanism for purging the cache in a predictable way (https://github.com/bluesky-social/proposals/tree/main/0011-auth-scopes#permission-set-resolution-caching-and-aggregators). We ended up not writing that in to the initial version of the specification and (forthcoming) developer guides, because everything is already so complex. But if this becomes friction for more devs we can look at getting it in.

2. Also in the original proposal, we have the concept of "Lexicon Overrides" as a way to publish patches (https://github.com/bluesky-social/proposals/tree/main/0011-auth-scopes#lexicon-resolution-overrides). That isn't supported in the current PDS or SDKs though. There are a number of options you could export right now: publish work-in-progress permission sets (place.stream.devAuthFull); run a full staging environment as you mention; patch the PDS to allow overrides.

3. I think that message is getting triggered by the ability to mutate any app.bsky.* records. It is not correct in that it is talking about more permissions than are actually requested, but it is more accessible/legible.