Sabidrome

This is the first world reveal of this somewhat ambitious project.

Word meaning

Sabidrome is a play on words between Navidrome and Wabi-Sabi, aiming at providing the straightforwardness of Navidrome on a technical level and retaining Wabi-Sabi on its content —that is books. The word is a reminder of the project’s original motivation, stating *drome as a form of adressing a solution just like the *arr stack does on Piracy.

Inspiration

This project is completely inspired on Navidrome by Deluan Quintao. As stated on its GitHub’s mainpage, Navidrome is a “Music Server and Streamer compatible with Subsonic/Airsonic.”

That service does exactly two things, and does them really well:

• Create an internal database of the music files’s metadata present inside a directory.
• Provide the music files under a coherent interface, using well-established standards.

The first point is a critical design point that makes Navidrome such a characteristic project. From a server perspective, it must keep track of all files inside a directory, watch for changes, update its internal database with their metadata information and provide that information to the Subsonic/Airsonic API requests or to its website front-end. On the other hand, from a user’s perspective… it just works.

You configure usability, not the library. You can have a disastrous mess of a directory, but as long as its metadata is consistent it will serve the music under an organized API or interface. How you configure the metadata? That is out of the project’s scope, leaving room for improvement in the usability rather than the modification of files.

Why not Kavita

The are a couple of points about Kavita that I personally dislike:

• It is really well designed for comics and mangas, seeing Ebooks as an extension of such.
• It requires a specific directory layout for files to be scanned correctly.
• It’s deployment without docker failed on me multiple times.

All of the previous points are related to my perceptions of how Kavita works and personal experiences rather than flaws on it. I look for something simple that picks up my already existent book collection and allows me to read it or ‘stream’ it on a device using a well known protocol. Instead of criticize it for what it cannot do, I decided to understand what I would like it to do.

Kavita works. I do have an instance for both comics and ebooks, it works as intended and each update bring performance improvements and new features. I just want something simpler, limited by design to reduce maintainance and appeal to a ebook-only userbase.

Why not Calibre-Web

I tried Calibre Web and I did not like the following design choices:

• It depends on a valid Calibre database rather than on files’ metadata.
• It is not intended to be read-only, being capable of editing the library.
• There’s discrepance between the community and the creator about how different libraries should work.
• It has python as a dependency, using Django mainly if I am not mistaken (because of the interface).

The project surely must have been refined since I tested it many years ago, but I’ve seen on multiple forums that this is the definitive choice to provide a reading service. I disagree. I feel that this appeals to a specific audience, hiding Calibre’s complexity behind it.

I don’t want to build a service from Calibre. Instead, I want Calibre to be used as the metadata editor for the service —job at which it excels. I want to separate how Calibre does its things to how the Book Service handles its data.

Goals

The following are the main—highly opinionated—goals of Sabidrome:

Only eBooks

• Kavita already aims to be an all-in-one solution for your reading needs and their team is working hard on making that happen.

• Komga comes from a time before Kavita—if I’m not mistaken—and it provides comic/manga-first support. eBook support was requested to be added.

• Audiobookshelf is focused on Audiobooks and Podcasts. Linking to it would be a nice QoL.

I am indeed reinventing the wheel since each of the above solutions provides eBook support. But I don’t want eBook support, I want eBook reading as the one and only intended feature.

Multiple libraries

Navidrome did not support multiple libraries, and yet almost everybody fell into the same problem of wanting them. It was never an opinionated decision but a limitation of the metadata.

My wife keeps her music on her phone, I keep my music on my phone, my child keeps her music on her phone.

Metadata does not understand about mine and yours, it just describes the file. Setting folders as the mines and yours just makes sense.

Single binary

This is probably the coolest aspect about Navidrome from a sysadmin perspective. It’s a single binary, a single configuration file and a single systemd unit. It is not scary at all to try it. It does have dependencies, but requesting ffmepg is more than reasonable. Docker is convenient and safe, but being able to just install it from the package manager to try it out is awesome.

I don’t seek Mastodon-levels of architecture for deployment, I only aim at making the program to be complete enough to provide its service as intended. My language of choice will be Go, since I’ve been wanting to try it out for a long time but never found a fitting project for it.

API

The well known protocol for this is OPDS, although there are some variations to it. I aim to cover:

• OPDS
• OPDS-PS (extension that supports progress sync)
• OPDS-PSE

Sabidrome will not have its own API.

MVP

Server side

• Parse epub’s metadata from a file and save it on a sqlite database.
• Query the database to obtain list of books, list of authors and book’s path.
• Create a watcher that updates the database based on filesystem changes.

Client side

• Display a list of books.
• Display a list of authors.
• Select a file and download it.

Want to help?

You can reach me out through email or open a GitHub Issue.