Samuel
to add to this, there’s a few product-y reasons why I would really like a createPost API 1. we could run a server-side language detection model that actually works, so we wouldn’t need the language select in the client (it sucks) 2. you wouldn’t need to specify a createdAt time anymore (cont.)
P(aul) Frazee@pfrazee.com· 13 Nov 2025
Nerding out about the question of whether the client or the server should be the one who speaks to the PDS
The politics of purely client-side apps
There's a surprisingly nuanced discussion in development about the political economy of clients and servers in the Atmosphere
pfrazee.leaflet.pub
7 3 43
Samuel
@samuel.fm
3. for more casual API users, i.e. people doing integrations, we could do stuff like auto-detecting facets. 1000x better DX 4. we could force people to specify aspect ratios on their images 😈 5. we could check if the post is actually gonna be valid - i.e. throw an error if it would fail a threadgate
3 2 19
Samuel
lotta product reasons here! it’s so weird from an outside perspective that our GET APIs are nice and normal, and our POST APIs are extremely unergonomic protocol-y jank. creating a post is the core feature of the app and for some reason we’re out here calculating our own TIDs 😵‍💫
1 1 18
Samuel
how do you think we get the replyRef CIDs when posting a thread in one applyWrites call 😉
1 11
Bossett
I think you can get the DX without sacrificing the sovereignty part, though it may need some kind of tweaking if you are considering proxying anyway, the blunt way would be a validator endpoint and then make the client do the commit (obv this could be wrapped by a library)
1 1
Bossett
this kinda sucks from a 'multiple calls' POV, but it depends on how seriously you want to take the user-is-sovereign position and would allow the PDS to run locally and only expose the firehose socket to the internet
2
geesawra
auto-detecting facets would be so goooood, creating a post atm is non-trivial