The service requests chat permissions, even when "Enable without message previews" is selected. Ideally, it should request more restricted permissions in this case.
Something went wrong. Try again.
Something went wrong. Try again.
Service always asks for chat permissions #4
Correction to my earlier comment, which was wrong on the main point. I said a hosted authorization server rejects the DID-audience chat scope. It does not: bsky.social and a self-hosted PDS both accept it, and it is what your current grant holds. The aud=permission-set spelling I switched to is the one that breaks. The request is accepted, the scope does not parse, and the server leaves it out of the grant, so chat calls on that grant answer 403 ScopeMissingError. That is reverted on main (0dc2dbe) and deployed. Please ignore the fix/counts-tier-chat-permission branch.
What is still true: the counts tier asks only for chat.bsky.convo.getUnreadCounts, which is read-only. But the consent screen shows any chat.bsky method as "Chat: Read and send messages" (oauth-provider-ui scope-description.tsx, scopeEnablesChat), whatever the scope, and I found no spelling that changes that. I do not see a fix on the service side, so I am leaving this open for you to judge.
Audit follow-up: the original permission-set scope change was wrong and has been reverted; please continue to ignore fix/counts-tier-chat-permission. The current counts tier requests only chat.bsky.convo.getUnreadCounts with the chat service DID as audience. It does not request getLog or sendMessage, so there is no additional chat-content or send permission to remove in courier.
The remaining problem is the consent UI description: Bluesky oauth-provider-ui labels any chat.bsky scope as reading and sending messages, even the count-only method. I have not found a supported service-side spelling that preserves the count read and changes that label. The scope-substitution attempts broke the grant rather than fixing the copy. I agree this should stay open as a UI/protocol issue, not be marked fixed by courier.
Fixed on the fix/counts-tier-chat-permission branch. The chat.bsky.convo.getUnreadCounts scope on the counts tier is what renders that line on the consent screen - the grant is still read-only, but the screen says chat either way. Worse, a hosted-PDS authorization server rejects the DID-audience form of either chat scope outright (its permission broker does not proxy them), so the grant was failing with invalid_scope rather than merely looking alarming. Both chat scopes now carry aud=permission-set with the fragment naming the resolved set (include:app.bsky.authReadChat for the counts, include:app.bsky.authFullChat for the log), which the broker resolves to exactly the method named - nothing is widened, and the consent copy improves from a raw method name to reading your direct messages. CHAT_PERMISSION_AUD=0 restores the DID form for a PDS that predates the broker. Deployed live on courier.7778777.online.