That being said, if it works for your use case, then I think that using Zod is a great idea !
November 10, 2025 at 5:58 PM
That being said, if it works for your use case, then I think that using Zod is a great idea !
I'm actually working on something very similar right now (cli to generate runtime schemas that can be used to infer types).
It's not going to be based on Zod though as it reduces our capability to represent some things (e.g. `params` can only be used as xrpc method parameters, etc.).
It's not going to be based on Zod though as it reduces our capability to represent some things (e.g. `params` can only be used as xrpc method parameters, etc.).
November 10, 2025 at 5:57 PM
I'm actually working on something very similar right now (cli to generate runtime schemas that can be used to infer types).
It's not going to be based on Zod though as it reduces our capability to represent some things (e.g. `params` can only be used as xrpc method parameters, etc.).
It's not going to be based on Zod though as it reduces our capability to represent some things (e.g. `params` can only be used as xrpc method parameters, etc.).
Just had to deal with something similar today. I learned that this method will not cover imports using node16 "exports" -_-
November 5, 2025 at 6:02 PM
Just had to deal with something similar today. I learned that this method will not cover imports using node16 "exports" -_-
I obviously meant "community devs" 😅
Where is that "edit post" button ?!
Where is that "edit post" button ?!
November 3, 2025 at 7:03 PM
I obviously meant "community devs" 😅
Where is that "edit post" button ?!
Where is that "edit post" button ?!
If that's the worst, then we did a pretty good job 🥳
Note that that screen might (finally) get a designer's attention soon.
Note that that screen might (finally) get a designer's attention soon.
November 3, 2025 at 2:28 PM
If that's the worst, then we did a pretty good job 🥳
Note that that screen might (finally) get a designer's attention soon.
Note that that screen might (finally) get a designer's attention soon.
Don't forget to implement a retry strategy for failing concurrent writes tho.
October 28, 2025 at 7:32 AM
Don't forget to implement a retry strategy for failing concurrent writes tho.
Bluesky PDS's use WAL mode, and are written to by multiple processes. It's pretty safe to use ;-)
October 28, 2025 at 7:30 AM
Bluesky PDS's use WAL mode, and are written to by multiple processes. It's pretty safe to use ;-)
That's awesome. A (minimal) UI would improve UX quite a bit!
October 26, 2025 at 7:37 AM
That's awesome. A (minimal) UI would improve UX quite a bit!
I've got something in the works with this exact focus
October 10, 2025 at 5:02 AM
I've got something in the works with this exact focus
Great news! Awesome work you guys did there 💙
October 9, 2025 at 4:30 AM
Great news! Awesome work you guys did there 💙
We have something else in mind for bots/cli/etc.
October 7, 2025 at 5:18 AM
We have something else in mind for bots/cli/etc.
What incompatibilities did you encounter with the official implementation that made you fork it?
September 29, 2025 at 6:11 AM
What incompatibilities did you encounter with the official implementation that made you fork it?
You should definitely try and use the OAuthClient and OAuthSession provided by "@atproto/oauth-client" instead of re-implementing all that logic. You'll basically need to provide your storage logic and the crypto utils supported by CF (look at the node & browser pkgs for examples)
September 29, 2025 at 6:10 AM
You should definitely try and use the OAuthClient and OAuthSession provided by "@atproto/oauth-client" instead of re-implementing all that logic. You'll basically need to provide your storage logic and the crypto utils supported by CF (look at the node & browser pkgs for examples)
An entryway in that setup is essentially an oauth provider. There are some legacy behaviors on our prod entryway that don't need to be ported here (such as proxying to the right PDS, when client issue xrpc requests towards the entryway instead of the pds)
September 27, 2025 at 8:39 AM
An entryway in that setup is essentially an oauth provider. There are some legacy behaviors on our prod entryway that don't need to be ported here (such as proxying to the right PDS, when client issue xrpc requests towards the entryway instead of the pds)
At first glance (and looking on my phone) looks like you are indeed on the right track!
Getting rid of that dependency on the old pds version as well as being able to simulate a setup with a pds service with entryway has been a long standing goal of mine.
Getting rid of that dependency on the old pds version as well as being able to simulate a setup with a pds service with entryway has been a long standing goal of mine.
September 27, 2025 at 8:36 AM
At first glance (and looking on my phone) looks like you are indeed on the right track!
Getting rid of that dependency on the old pds version as well as being able to simulate a setup with a pds service with entryway has been a long standing goal of mine.
Getting rid of that dependency on the old pds version as well as being able to simulate a setup with a pds service with entryway has been a long standing goal of mine.
I've been wanting to do that for a loooong time! This is so awesome!!
September 27, 2025 at 5:26 AM
I've been wanting to do that for a loooong time! This is so awesome!!
This was fixed to work like it always was meant to.
Storing the preferences on the PDS was actually a "hack" we put in place to avoid storing user data in *our* appview.
Because of that hack, third party appviews were not able to receive pref calls. This is what this change is about.
Storing the preferences on the PDS was actually a "hack" we put in place to avoid storing user data in *our* appview.
Because of that hack, third party appviews were not able to receive pref calls. This is what this change is about.
September 3, 2025 at 6:14 AM
This was fixed to work like it always was meant to.
Storing the preferences on the PDS was actually a "hack" we put in place to avoid storing user data in *our* appview.
Because of that hack, third party appviews were not able to receive pref calls. This is what this change is about.
Storing the preferences on the PDS was actually a "hack" we put in place to avoid storing user data in *our* appview.
Because of that hack, third party appviews were not able to receive pref calls. This is what this change is about.