jkap

CEO of posting

butch jewish dyke
part of @staff, cohost user #1
married to @kadybat

This user can say it
osu stats


🐘 mastodon
xoxo.zone/@jkap
🖼️ icon credit
twitter.com/osmoru
🐦 twitter
not anymore lol

i don't really have a ton to say beyond "this sucks!!!!!!"

i realize it might be a bit silly for me to talk about how important a public API is when we don't have one ourselves (although we're working on it) but man having a public API is vital.

i wish i knew more about twitter bot development. if i did, i'd try to put together a migration guide using one of the many sanctioned but officially unsupported third-party libraries that people have put together. if someone else is writing that guide and has questions about anything, you can hit me up. my email is in my bio.


You must log in to comment.

in reply to @jkap's post:

I am incredibly excited for the official api to come! The trpc api is already super powerful, and having docs for it and better flexibility will be amazing!

side question in the staff update 48 you mentioned sometbinf about render caching and how that would effect the api, is that server side rendering of posts that the api can get the html from?

i really need to figure out all the work still required for the public API. unfortunately a very large amount of it is "documentation" which is hard! i'm torn on whether it's worth shipping something with minimal documentation to be improved over time, or if that's just a waste of time for everyone. who knows!

also of note: we won't be shipping the tRPC api directly, but a layer on top of it that maps the procedures to standard rest calls, which would also let us ship and openapi definition with no issues.

we might implement server-side HTML rendering as well at some point, but right now it's us caching the AST after every pre-processing step (sanitization, filtering, custom emoji processing, etc) that doesn't require user display settings so that we don't have to re-do this work every time. the caching is still in a sort of proof-of-concept stage, but right now we're just sending this AST down as part of the post view model object for direct rendering by the client. this impacts the API because it lets us ship a less-complex Reference Implementation of a post renderer.

A bit of a long shot but if there’s documentation work needed this summer, I’ve been looking for some sort of summer internship software dev thing, and it would be super cool to work for cohost

happy to answer any questions you have about Twitterbots! i have all this knowledge in my head and it all expires in a week's time.

i was just thinking about what would be needed to make a Cheap Bots, Done Quick-like for Cohost. I think the tricky thing from the unofficial libraries is that I would feel leery about asking people for the passwords for their account to sign in - OAuth, although annoying in almost every single way, is the right setup for this. Other than that, well, for a simple bot that just posts & doesn't have to read data, the tweeting part is pretty straightforward. See here for an example: https://github.com/v21/tracerybot/blob/master/bot.js#L108

The complicated parts for Twitterbot dev are auth/API setup (I'm sure you feel this pain on the other side), and running a script repeatedly without it falling over or getting stuck somehow.

agreed that a better auth story is sorely needed for something like cheap bots done quick. for now, when people ask, i've been advising them to setup a second account just for their bots so that they don't have to login with their main and risk issues there.

we're not sure if we're gonna have oauth at launch (it's hard!) but bare minimum we'll have a Personal Access Token system (much less hard!)

but yeah auth is the Big Missing Thing for adoption of even the un-official APIs (also them being technically unsupported lol)

Yeah, like 95% of accounts on CBDQ were setup for that purpose, so it's not as uncomfy as something like an auto-blocker or something that wants to run on a main account. And I guess the way that pages work means you can create a new account & then give it the limited permissions it'd need, which is useful (although I'm sure the accounts/pages stuff makes everything a load more complex on your side).

but yeah, a PAT would enable it just fine, a tiny bit more friction in the signup process, but still very manageable.

(oh, also i should say: i am totally not going to set up a CBDQ for Cohost! but someone should. happy to answer questions, give tech support, etc to anyone who takes on that worthy task. your prize is: giving it an even more torturous and unwieldy name)

good luck in the auth mines!!

i will absolutely use a cheap bots done quick like thing for cohost as soon as somebody makes one!! i have many robots waiting in the wings. one of them makes sandwiches

Went to go figure out which apps I still had logged in to Twitter so I could log them out. Noticed my Playstation and my Switch were still plugged in there.

Wondering which outcome we're gonna get with the Twitter API and the video game consoles: They drop their Twitter share features, or Twitter successfully strong-arms them into paying a small stipend for each system. The latter sounds deeply uncomfortable. I'll basically be required to log out if I want to achieve my goal of not giving Elon Musk money.