Tom Sherman
@tom.sherman.is
Yeah I think this is a fine solution!
The complexity has to exist somewhere, client tooling is very good at optimistic writes nowadays. I guess the aggregate complexity is greater for an app like Bluesky that has multiple clients though.
To be clear I'm pro BFF, it's how Frontpage works. But I think there's value in both solutions
To be clear I'm pro BFF, it's how Frontpage works. But I think there's value in both solutions
November 13, 2025 at 4:04 PM
Yeah I think this is a fine solution!
It's now a distributed transaction, there are n^2 (not sure if that's the right scaling factor lol sorry I'm bad at maths) more ways for the transaction to fail and all of those states need proper handling
November 13, 2025 at 3:54 PM
It's now a distributed transaction, there are n^2 (not sure if that's the right scaling factor lol sorry I'm bad at maths) more ways for the transaction to fail and all of those states need proper handling
The problem then is how do you read your own writes? ie. How do you do optimistic updates?
November 13, 2025 at 3:49 PM
The problem then is how do you read your own writes? ie. How do you do optimistic updates?
The complexity has to exist somewhere, client tooling is very good at optimistic writes nowadays. I guess the aggregate complexity is greater for an app like Bluesky that has multiple clients though.
To be clear I'm pro BFF, it's how Frontpage works. But I think there's value in both solutions
To be clear I'm pro BFF, it's how Frontpage works. But I think there's value in both solutions
November 13, 2025 at 3:48 PM
The complexity has to exist somewhere, client tooling is very good at optimistic writes nowadays. I guess the aggregate complexity is greater for an app like Bluesky that has multiple clients though.
To be clear I'm pro BFF, it's how Frontpage works. But I think there's value in both solutions
To be clear I'm pro BFF, it's how Frontpage works. But I think there's value in both solutions
In this model the client wouldn't do the write to the app, it'd do it to their PDS (like bsky does today). The difference would be instead of the PDS containing bsky-specific code inside getPostThread on the PDS, that code would exist only on the Bluesky client
November 13, 2025 at 3:45 PM
In this model the client wouldn't do the write to the app, it'd do it to their PDS (like bsky does today). The difference would be instead of the PDS containing bsky-specific code inside getPostThread on the PDS, that code would exist only on the Bluesky client
But you could do the optimistic update on the client for a lot of apps, even bsky could have this for most writes.
November 13, 2025 at 3:36 PM
But you could do the optimistic update on the client for a lot of apps, even bsky could have this for most writes.
Yeah it's crazy, especially since this React 19 so it's rendering concurrently
November 13, 2025 at 1:56 PM
Yeah it's crazy, especially since this React 19 so it's rendering concurrently
Perhaps a small abuse of resetAfterCommit? haha
November 13, 2025 at 1:32 PM
Perhaps a small abuse of resetAfterCommit? haha
Ohhhhh, imgui calls renderTree every frame. Wild lol
November 13, 2025 at 1:30 PM
Ohhhhh, imgui calls renderTree every frame. Wild lol
I was looking at the host config recently and couldn't for the life of me understand how the UI actually get's updated. It mutates the nodes directly but where does this actually call out to imgui??
November 13, 2025 at 1:28 PM
I was looking at the host config recently and couldn't for the life of me understand how the UI actually get's updated. It mutates the nodes directly but where does this actually call out to imgui??
Ohhh, via the mod service env var? And the mod service signs the request i assume so the pds can verify it
November 13, 2025 at 1:13 PM
Ohhh, via the mod service env var? And the mod service signs the request i assume so the pds can verify it
How? Doesn't it need a pds admin password?
November 13, 2025 at 1:12 PM
How? Doesn't it need a pds admin password?
But I don't think an appview can even make use of sendEmail today, they don't have the auth required on a third party PDS. They should have the ability to though, via an additional oauth scope
November 13, 2025 at 12:54 PM
But I don't think an appview can even make use of sendEmail today, they don't have the auth required on a third party PDS. They should have the ability to though, via an additional oauth scope
I think the solution is the one you alluded to up thread, just get the PDS to configure moderation email. Perhaps by reusing the existing email configuration by default.
Changing an email shouldn't be observable by the outside world and the session may have expired anyway so an event might not help
Changing an email shouldn't be observable by the outside world and the session may have expired anyway so an event might not help
November 13, 2025 at 12:51 PM
I think the solution is the one you alluded to up thread, just get the PDS to configure moderation email. Perhaps by reusing the existing email configuration by default.
Changing an email shouldn't be observable by the outside world and the session may have expired anyway so an event might not help
Changing an email shouldn't be observable by the outside world and the session may have expired anyway so an event might not help
"retention cliff" 😭 slack has done irreparable damage to our world
November 13, 2025 at 10:05 AM
"retention cliff" 😭 slack has done irreparable damage to our world
Node.js won't run typescript inside of node_modules and the Node.js team have said that they specifically will not add support for that
It opens up too many cans of worms with regards to module resolution
It opens up too many cans of worms with regards to module resolution
November 13, 2025 at 10:03 AM
Node.js won't run typescript inside of node_modules and the Node.js team have said that they specifically will not add support for that
It opens up too many cans of worms with regards to module resolution
It opens up too many cans of worms with regards to module resolution
I also have no idea what you mean by "it won't work". I've been using type stripping in Node.js for some time now and it works perfectly
November 13, 2025 at 10:01 AM
I also have no idea what you mean by "it won't work". I've been using type stripping in Node.js for some time now and it works perfectly
It also allows for different type systems to emerge without having a huge barrier for adoption (their syntax will already be supported in build tools)
November 13, 2025 at 10:00 AM
It also allows for different type systems to emerge without having a huge barrier for adoption (their syntax will already be supported in build tools)
There is value in adding it to the standard outside of "no serious app will serve TS in prod". It allows the tools that you refer to to be more compatible and more predictable.
November 13, 2025 at 10:00 AM
There is value in adding it to the standard outside of "no serious app will serve TS in prod". It allows the tools that you refer to to be more compatible and more predictable.
You could but it makes the app overall less resilient, it's not some silver bullet that all apps would want to use.
November 13, 2025 at 9:55 AM
You could but it makes the app overall less resilient, it's not some silver bullet that all apps would want to use.
"the Atmosphere community is going to need to align on one of these two methods"
Why not both?
Why not both?
November 13, 2025 at 9:52 AM
"the Atmosphere community is going to need to align on one of these two methods"
Why not both?
Why not both?
Appreciate the transparency 🙏
November 12, 2025 at 5:03 PM
Appreciate the transparency 🙏
Best explanation of why atproto uses merkle trees yet
November 12, 2025 at 3:57 PM
Best explanation of why atproto uses merkle trees yet
Really you probably should be measuring the actual payload downloaded on the client if you're doing any form of code splitting or dynamic code load/import 😅
November 12, 2025 at 3:53 PM
Really you probably should be measuring the actual payload downloaded on the client if you're doing any form of code splitting or dynamic code load/import 😅