Otter 0.1.0

Part of the Otter series

Although life’s been busy with university, I’ve found some time to finish things up with the current codebase and release a first version. This version’s been running on my Raspberry Pi for a couple of months without problems, so it seems to be fairly stable.

For context, Otter is a lightweight implementation of the gpodder.net API, specifically the parts required for synchronizing subscriptions between clients. Its goal is to be an easy-to-install alternative to gpodder.net, allowing self-hosters to easily use the various Gpodder-based clients available across devices.

Version 0.1.0 has a fairly complete implementation of the parts of the Gpodder API that’s required for synchronizing clients. I’ve currently got no plans to implement the more social media-related API routes, as these aren’t necessary for the goal of this project.

Supported features

Otter 0.1.0 implements the following API sections:

This includes both the basic routes and the “advanced” sections, as described in the API documentation. OPML and text output formats aren’t supported yet, so currently the API only supports JSON. I am planning on adding support for the other output types later.

In terms of client compatibility, Otter definitely works with AntennaPod and Kasts. Kasts does have the strange bug where it crashes if you agree to the “synchronize with all devices” popup when adding a new device. However, after manually marking the devices as being synchronized on the server, all syncing functionality works as expected. The Gpodder client also does not work, as it strangely uses a different form of authentication.

Both of these issues should get fixed in a following release, as I’d like Otter to be generally usable with any client.

Ease of use

Otter is distributed as a single binary configurable via a configuration file, environment variables and CLI arguments. Everything can be set up via any of these three methods (or a combination), allowing Otter to be easily used in both Docker containers and directly as a background service. For fun, I’ve also added support for listening on a Unix socket instead of a TCP socket.

The goal is to always keep this setup, as a single binary is by far the easiest way this type of software can be distributed. I currently publish binaries for x86_64 and arm64, as these are the platforms that I use. It should be possible however to compile Otter for any build target supported by Rust.

Plans

Before Otter reaches version 1.0, there are still some features I’d like to add.

UI

The biggest feature would definitely be a web UI. This UI will contain everything required to manage an Otter server, both as a user and an admin. Users should be able to see and remove sessions, manage their synced devices, and view and edit their subscriptions and other stored data. Admins also require the ability to add, remove and edit accounts, as well as seeing other global service data. The goal is to have an easy-to-use UI that contains everything you’d need to effectively use an Otter server.

Important here is that I don’t have any plans to recreate any of the social media-related aspects of Gpodder. Otter is just a sync server; it’s not meant as a full-on replacement of the gpodder.net website.

In terms of technology, I’m using HTMX and PicoCSS to develop the frontend, combined with a templating system in the backend. In my opinion, these two are the perfect combination for developing simple frontends, especially for someone like me that isn’t the best at creating UIs.

CLI

It’s always useful to have a more technical CLI-focused way of accessing the data of an application. For this, I want to add a full CLI interface that allows an admin to interact with the server through the same abstractions used by the API. There’s already some very basic functionality available right now on which I’d like to build to expose the full functionality of the API in CLI form.

Database support

Otter currently only support SQLite as it’s easy to develop with and install on the server. I do however know lots of people prefer running PostgreSQL, so support for this will be added. Due to the way the codebase is structured, this shouldn’t be too hard, as all database-related functionality is hidden behind an abstraction that can simply be implemented for PostgreSQL as well.

Those are my plans for this project! I’m hoping I can keep up the development pace, as I should be having a lot more free time the next couple of months. I’ve grown quite fond of this project, as it solves a specific problem I had while allowing me to screw around with some design patterns I hadn’t used before. I hope to continue developing it into a mature application.

As always, thank you for reading, and have a nice day.