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
well now we have to do 2 calls, one to fetch the language, one to make the post. now posting takes twice as long in a flow that should be as low-friction as possible
2 1
Samuel
and re: #2, wouldn’t fix the problem of semi-invalid posts getting written to your PDS if your system clock is wrong (it does happen!)
1 1
Ms Boba (rebuilding community era)
Oooh that's interesting, I hadn't thought about that. Damn, this decentralization thing got hands. I'd love to hear more what issues that causes. When I did the exploration of lexicons out there they all had a createdAt field.
3
Ms Boba (rebuilding community era)
Eheh, yeah, that's true for images too though, right? Those need to be updated separately. I don't think you can do true low-friction posting without a good SDK tbh. For low friction, I'd support some sort of "prepare record" call that does a bunch of augmentation before posting.
1 1
Samuel
yeah, not much you can do with images :/ with videos we start uploading immediately, which we could try - however blobs are immediately public so that’d be pretty weird too without some deeper thought into the media pipeline (maybe unpublished blobs aren’t list-able?)