Hi everyone! Today I am releasing Backtick API, an unofficial Tildes API. I originally wrote it to power Backtick but quickly realized that it could be useful for other clients and projects that require Tildes data. The project is open-sourced, both because I would love community contributions and because I want to make the project as transparent as possible.

Q: Does it require or store any user credentials?

No. All the endpoints that are implemented scrape publicly available data that do not require any user credentials.

Q: Will this overload Tildes?

To prevent Backtick API from being a nuisance to Tildes, the code caches calls to Tildes for a short period of time. Depending on usage, it should reduce the number of calls to Tildes (vs a client querying Tildes directly).

Q: How can I use it?

A hosted version of the code is available through RapidAPI here: https://rapidapi.com/asnewman/api/backtick-api

Q: Are there any limitations?

To prevent the project from being abused and becoming a financial burden on myself, I'm using RapidAPI to manage usage. There is a generous free tier and a reasonably priced paid tier which will be used to cover server costs. In addition, I will be donating a portion of the paid plan revenue (my goal is 50% but will depend on load and subscription count) directly to Tildes via Github Sponsors. It's really important to me to keep this project and Tildes as sustainable as possible. I really would love to provide everything for free, but unfortunately, there are countless examples where that doesn't work out down the road.

Of course, if you do not want to use the hosted version, you are welcome to deploy the code yourself!

Q: Isn't scraping prone to breaking?

Yes! Users beware! Obviously, I will try my best to fix things if the Tildes code changes in a way that breaks Backtick API, but it's definitely a possibility.

Q: Why not just work on and contribute to creating an official Tildes API?

An official Tildes API will always be better than something like this and I look forward to when/if it gets implemented. That being said, I'm choosing the route that would be the quickest to continue the development of the Backtick mobile app. In addition, it's also the choice that is most fun for me. To work on a Tildes API, if the powers that be even want to have one, would require lots of coordination and codebase learning, something that will take a lot of time. I highly commend anyone who chooses to take on that task, but I do too much of that kind of work for my real job 😂

Please report any issues or feature requests through Github, this post, or the Backtick Discord server. Finally, I just want to thank everyone in the community for all the great conversations I've had, for providing helpful feedback for Backtick, and for creating a place on the internet that I very much enjoy being a part of 😊

Hello!

Some of you may know that I have been developing an iOS client for Tildes.

I’ve seen other devs like @wababa and @talklittle also working on awesome apps, and have seen some discussion there around collaborating on some of the core parts (scraping the website, etc.).

I’ve also been in touch with @efraimbart, who is working on the awesome Everything protocol project.

I’m sure there are other devs out there that I haven’t seen, and this post is a call-out for all of you.

Until an API is available, any similar project will face the same initial blocker: needing to scrape the website for data.

Is there any interest from the community on collaborating on that part? For example, developing a public library that encapsulates all of the interactions with Tildes and any client can talk to with a consistent API. Or, even better, collaborating on an official API for Tildes (which is, of course, itself an open-source project).

To that end, I’ve released some of the code I use to accomplish this in Surfboard. Maybe it can help someone build an iOS client, or inspire some of us to build a more generic solution :D. It’s far from perfect or complete, and isn’t even an actual package you can just import and use at this time, but at the very least it documents many of the endpoints and interactions.

Have a great weekend :)

I understand there are no plans to develop an official app, which is understandable to me as that would require a lot of time and resources for a project like this.

But it's clear that there are lots of devs eager to chime in and create an app by themselves, just like they did for Reddit. There's even one iOS app already in progress, although it relies on HTML parsing to retrieve the data obviously.

So is there any official stance on this? Why not publish the API and let the community do its magic? Any thoughts?

Hello,

I saw in another thread being mentioned that there is no use for API for real users other than bots. So wanted to voice some real API uses that I would be interested in:

1. When I post a new blog post, if I find it worthy of sharing here, it would be nice to mirror the comments I get here back on my blog post. I can imagine using API to fetch all the comments from a tildes thread, including the hierarchy relationship. The API would return a JSON with Markdown and/or HTML like the XML that Disqus exports (but JSON). When people want to comment on that post, they can come to tildes to do so, or if they don't want to create an account here, or if they don't have an invite, they can comment via other means that I have (Webmentions, Twitter, email).
2. Second use is make something like hnrss possible.

If it's too early in development for these questions, let me know.

1. Is the source available yet? If so, where is it hosted? If not, when will it be dropped?
2. Third party API: I know the docs say that the browser should be the client. However, after using tildes for awhile on mobile, it's quite... interesting. The site does really well on mobile, don't get me wrong, but it's missing the system feel that makes the experience pleasant. Honestly, one of the big reasons I was drawn to reddit was the ample support (by the third party) for mobile clients. I'd love to get started on a client for ~.