Willem Dantuma
@willem.dobs.nl
Software architect/developer, interested in precision agriculture, IOT, linked data, data spaces, ATProto and sailing
You can grant the already consented ( in a code flow ) permissions
December 2, 2025 at 4:32 PM
You can grant the already consented ( in a code flow ) permissions
I know the difference between boh flows and is exactly what i would want, identify as an app( view).
December 2, 2025 at 3:04 PM
I know the difference between boh flows and is exactly what i would want, identify as an app( view).
On boarding and consenting the app is done through the normal code flow. Authorizing requests against a granted scope / client-id combination
December 2, 2025 at 1:59 PM
On boarding and consenting the app is done through the normal code flow. Authorizing requests against a granted scope / client-id combination
In short,simplify token management ( reuse a token for multiple users on the same PDS ). I have a use case where lots of records have to be created for a lot of users divided over a few PDSes, using a client_credentials grant ( with private_key_jwt ) you don't need a new token for every user.
December 2, 2025 at 1:56 PM
In short,simplify token management ( reuse a token for multiple users on the same PDS ). I have a use case where lots of records have to be created for a lot of users divided over a few PDSes, using a client_credentials grant ( with private_key_jwt ) you don't need a new token for every user.
Somewhat related, Support for the client_credentials grant for confidential clients in the AT-Proto OAuth profile would also be nice to have.
December 2, 2025 at 6:13 AM
Somewhat related, Support for the client_credentials grant for confidential clients in the AT-Proto OAuth profile would also be nice to have.
I see you already succeeded
December 1, 2025 at 3:12 PM
I see you already succeeded
What does a call to com.atproto.server.checkAccountStatus say using the same session you use for the plc operation ?
December 1, 2025 at 2:46 PM
What does a call to com.atproto.server.checkAccountStatus say using the same session you use for the plc operation ?
1st monday of the month
December 1, 2025 at 12:02 PM
1st monday of the month
I agree for the same reason, DX
November 28, 2025 at 12:11 PM
I agree for the same reason, DX
As speced in the PR it is invalid see atproto-website-pr-465.onrender.com/specs/lexico...
Lexicon - AT Protocol
A schema definition language.
atproto-website-pr-465.onrender.com
November 19, 2025 at 6:06 PM
As speced in the PR it is invalid see atproto-website-pr-465.onrender.com/specs/lexico...
I fully agree, but think its a broader problem
November 17, 2025 at 10:27 AM
I fully agree, but think its a broader problem
It was here github.com/bluesky-soci...
Progress on Auth Scopes Implementation (August 2025) · bluesky-social atproto · Discussion #4118
Since our last update on Auth Scopes, the Bluesky team has been hard at work adding support to our reference PDS implementation. Aspects of this work are starting to roll out in the production netw...
github.com
November 16, 2025 at 7:18 AM
It was here github.com/bluesky-soci...
I've remember asking the same question once, I think we need it. At least if we want to reuse the scopes in a private/permission data scenario. E.g a PDS wants to forward only records a client is allowed to see on a specific channel ( arena )
November 16, 2025 at 7:15 AM
I've remember asking the same question once, I think we need it. At least if we want to reuse the scopes in a private/permission data scenario. E.g a PDS wants to forward only records a client is allowed to see on a specific channel ( arena )
No ( as far as I've seen )
November 13, 2025 at 11:04 AM
No ( as far as I've seen )
Both options should be possible, its for the app to choose, depending on how complex it is. Most apps start with option 1 and as features are added ( money comes in) migrate more to option 2.
An app/appview should always do its best to process records comming from both channels ( firehose or API )
An app/appview should always do its best to process records comming from both channels ( firehose or API )
November 13, 2025 at 7:41 AM
Both options should be possible, its for the app to choose, depending on how complex it is. Most apps start with option 1 and as features are added ( money comes in) migrate more to option 2.
An app/appview should always do its best to process records comming from both channels ( firehose or API )
An app/appview should always do its best to process records comming from both channels ( firehose or API )
we need a label for that
November 1, 2025 at 7:19 AM
we need a label for that
what's the current state of atgeo ? are there already some lexicons defined ?
October 22, 2025 at 4:25 PM
what's the current state of atgeo ? are there already some lexicons defined ?
It doesn't hurt, but personally i'll prefer clickable $type nsid's for the record view. Its a more direct way of navigating, certainly in case of unions ,less tab switching (no need to remember the type used).
October 20, 2025 at 5:31 PM
It doesn't hurt, but personally i'll prefer clickable $type nsid's for the record view. Its a more direct way of navigating, certainly in case of unions ,less tab switching (no need to remember the type used).
Works great, of course i already have some new wishes but i'll keep them for later
October 20, 2025 at 1:45 PM
Works great, of course i already have some new wishes but i'll keep them for later
Hopefully @bnewbold.net comes with an answer soon
October 20, 2025 at 1:42 PM
Hopefully @bnewbold.net comes with an answer soon
i'am allready testing it
October 20, 2025 at 1:26 PM
i'am allready testing it