Willem Dantuma
@willem.dobs.nl
Software architect/developer, interested in precision agriculture, IOT, linked data, data spaces, ATProto and sailing
That's why I think we should pursue an interoperability system without mappings this time. Maintaining them is too expensive.
December 25, 2025 at 6:54 AM
That's why I think we should pursue an interoperability system without mappings this time. Maintaining them is too expensive.
device, an ATProto app presents a user with three options The single button variant "Atproto wallet on this device" the "Atproto wallet on other device" one presenting a QR code to scan with the app and the already exist handle variant.
December 24, 2025 at 7:21 AM
device, an ATProto app presents a user with three options The single button variant "Atproto wallet on this device" the "Atproto wallet on other device" one presenting a QR code to scan with the app and the already exist handle variant.
I'am thinking in this direction for a longer time now but didn't get much response. See discord.com/channels/109...
For a short description, terminology used is something we need to discus.
But the core concept is a user maintains his own credentials ( rotation keys ) in an app on his mobile ...
For a short description, terminology used is something we need to discus.
But the core concept is a user maintains his own credentials ( rotation keys ) in an app on his mobile ...
Discord - Group Chat That’s All Fun & Games
Discord is great for playing games and chilling with friends, or even building a worldwide community. Customize your own space to talk, play, and hang out.
discord.com
December 24, 2025 at 7:21 AM
I'am thinking in this direction for a longer time now but didn't get much response. See discord.com/channels/109...
For a short description, terminology used is something we need to discus.
But the core concept is a user maintains his own credentials ( rotation keys ) in an app on his mobile ...
For a short description, terminology used is something we need to discus.
But the core concept is a user maintains his own credentials ( rotation keys ) in an app on his mobile ...
I see a rivivel of ipfs on the horizon
December 20, 2025 at 7:05 PM
I see a rivivel of ipfs on the horizon
I don't think so, all we need are a (replacement ?) set of com.atproto.repo.*blob* interfaces with offset size gets and resumable uploads support.
You can always have multiple repo's.
You can always have multiple repo's.
December 19, 2025 at 8:48 AM
I don't think so, all we need are a (replacement ?) set of com.atproto.repo.*blob* interfaces with offset size gets and resumable uploads support.
You can always have multiple repo's.
You can always have multiple repo's.
how about something like "internet storage account" or "storage account", "storage ID" right now the ATproto core concepts are about a central place where you store youre stuff and have control.
December 19, 2025 at 8:38 AM
how about something like "internet storage account" or "storage account", "storage ID" right now the ATproto core concepts are about a central place where you store youre stuff and have control.
There's also this coredns plugin I did in alpha state github.com/custorium/co...
GitHub - custorium/coredns-atproto-plugin: An coredns plugin to translate _atproto TXT queries to an HTTP call to a /xrpc/com.atproto.repo.describeRepo endpoint
An coredns plugin to translate _atproto TXT queries to an HTTP call to a /xrpc/com.atproto.repo.describeRepo endpoint - custorium/coredns-atproto-plugin
github.com
December 8, 2025 at 7:59 PM
There's also this coredns plugin I did in alpha state github.com/custorium/co...
I know, that's why i added ( provider) , but in it's simplest form a PDS ( set of API defining a PDS ) is likely a single executable somewhere on an Rpi. So I think we agree.
December 8, 2025 at 9:50 AM
I know, that's why i added ( provider) , but in it's simplest form a PDS ( set of API defining a PDS ) is likely a single executable somewhere on an Rpi. So I think we agree.
switching authentication provider. I see PDS implementations emerge supporting something like SIOP so you can authenticate with a rotation key in youre wallet
December 8, 2025 at 8:46 AM
switching authentication provider. I see PDS implementations emerge supporting something like SIOP so you can authenticate with a rotation key in youre wallet
I agree that private data and PLC replication are more important right now. About unbundling auth i'am not yet convinced depends on what you mean by that, I like the clear role of the PDS as it is, you already have the possibility to switch PDS provider and with that potentially ..
December 8, 2025 at 8:46 AM
I agree that private data and PLC replication are more important right now. About unbundling auth i'am not yet convinced depends on what you mean by that, I like the clear role of the PDS as it is, you already have the possibility to switch PDS provider and with that potentially ..
I also think this is one of the most important aspects of ATProto
December 8, 2025 at 8:33 AM
I also think this is one of the most important aspects of ATProto
We already trust the PDS (provider) as the party we delegate signing ( repo and service tokens ) to, so i don't see any gain in putting a separate AS in the DID. At the PDS level you probably could configure another idP to federate with (SIOP ? ).
December 8, 2025 at 6:50 AM
We already trust the PDS (provider) as the party we delegate signing ( repo and service tokens ) to, so i don't see any gain in putting a separate AS in the DID. At the PDS level you probably could configure another idP to federate with (SIOP ? ).
2/2 but they should support a single core API ( profile ) to best support a creditable exit.
December 7, 2025 at 4:22 PM
2/2 but they should support a single core API ( profile ) to best support a creditable exit.
1/2 I think the differentiation ( API wise ) should happen at the Appview level and not at the data storage ( PDS ) side, sure there will be more PDS implementations ( there already are ) and some will implement different authentication mechanisms
December 7, 2025 at 4:21 PM
1/2 I think the differentiation ( API wise ) should happen at the Appview level and not at the data storage ( PDS ) side, sure there will be more PDS implementations ( there already are ) and some will implement different authentication mechanisms
2/2 is in a users PDS. Otherwise we end up with a service endpoint for every app in a users DID, which will be the beginning of the end i'am afraid.
December 7, 2025 at 10:02 AM
2/2 is in a users PDS. Otherwise we end up with a service endpoint for every app in a users DID, which will be the beginning of the end i'am afraid.
1/2 We still need creditable exit for all user data ( public,private ,shared ). So please don't differentiate on the API and tools ( a published lexicon) which supports that but work together in defining the interfaces to use for private and shared data to ensure all the canonical users data ..
December 7, 2025 at 10:02 AM
1/2 We still need creditable exit for all user data ( public,private ,shared ). So please don't differentiate on the API and tools ( a published lexicon) which supports that but work together in defining the interfaces to use for private and shared data to ensure all the canonical users data ..
Is there already a more clear idea which direction this goes / which scheme will be the first to be implemented ?
December 6, 2025 at 8:52 AM
Is there already a more clear idea which direction this goes / which scheme will be the first to be implemented ?
It's a matter of interpretation i guess ( section 1.3.3 of the OAuth 2.1 spec ), but what i actually want is app passwords based on an app (client) identity (did, pub key) with more scoped behavior ( consent ), and thought the client_credentials grant would be a possible solution.
December 3, 2025 at 6:37 AM
It's a matter of interpretation i guess ( section 1.3.3 of the OAuth 2.1 spec ), but what i actually want is app passwords based on an app (client) identity (did, pub key) with more scoped behavior ( consent ), and thought the client_credentials grant would be a possible solution.
I'am almost sure I've once read something similar what I described somewhere in the specs.
December 2, 2025 at 7:47 PM
I'am almost sure I've once read something similar what I described somewhere in the specs.
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