Samuel
@samuel.fm
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
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
Samuel
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?)
mary🐇
seems to me that you can just process the post's language right after plucking it off from the firehose yeah
2 1
Samuel
ok fair. but now everyone’s gotta figure out all the post languages themselves
1
mary🐇
probably something you'd have to account for anyway given the importance of having the correct language declared on post though honestly language detection is pretty tough on short form posts to begin with :p
2
Antti Rasinen
Yea. Google Translate doesn’t understand my friends slangy Russian, mixes Ukrainian and Russian awkwardly often and gets short Finnish phrases wrong. I just don’t trust the automatics
1 2
Samuel
very reasonable. it’s just the current state of things is extremely dire - barely anyone changes it, so a huge % of posts are in the wrong language
1 2
Antti Rasinen
Related but unrelated. My Finnish feed occasionally has pictures of men naked although the language is English. I’m suspecting they’re selecting Finnish as a tribute to Tom of Finland 🤷🏻‍♂️
1
Tynan Purdy ⁂
You can just do things. If you wanna offer fancy features on your api do it. If someone is building something simple enough that PDS as API works for them, great no backend needed.
1
Emelia
You'll always need language selection in the client. Models very often get it wrong
1
Samuel
this is more just a case of "we need more signal". the overwhelming majority of peope are not gonna be clicking that button, so it mostly just tells you what they have their phone set to
1 2
Emelia
You could do a "detectedLanguage" in API responses & possibly send the post content to a service for language detection before sending to PDS for storage.