Broad concept

Librarian is intended as an rpg file organiser, conceptually somewhere between Steam and Plex. A typical user has a big pile of pdfs, epubs, and various other files, scattered around in various folders on their computer, and they would hopefully find some utility in something that can scan those folders and present the user with a meaningful structure.

Let's put that in the form of a user story.

Linda can never remember what stuff she's bought over the years, and when she goes back to a system she hasn't used in a while, finds it awkward as flip to find things. She hears about Librarian and she installs it.

When she opens Librarian, it asks her if she'd like to select any folders. She picks her "Big RPG folder of Doom" folder and clicks "Scan". Librarian takes a minute to look at the files in this folder and compares file properties against a database.

After this, the UI of Librarian updates. She can now see a library-like interface, populated with all the nice things she's collected over the years. She can click on Dungeon World and see everything she has for that system. She can browse a list of publishers behind the things she owns, and see what she owns by each one. She can click on the name of a publisher, and see that they have something new that she doesn't have already.

Every property and relationship becomes a way of delving through her Library. She can view a page within librarian relating to an rpg she owns. Publisher, author, and artist are all clickable links. In every case, she can click through to a related page, listing everything she has by these parties, and sometimes what she doesn't have, but that Librarian 'HQ' has seen and can share information for.

Such an application could grow in many directions but that's all academic until you get the bare bones working.

Practical Considerations

The core feature of this is really the matching system. Without, that you don't have much. While there's a lot of ways to try and do it, for prototyping this will be a process that creates a set of hashes based on properties of each file, and compares it against previously seen files as referenced in a database.

For storing and managing the relationships, how each entry relates to different parts of the taxonomy and so on, it doesn't really need to be anything too fancy, a MySQL database is fine. Rather than building it from scratch, fun and all as that might be, Strapi 5 would be sufficient for both constructing, and doing data entry for, a prototype-quality backend, at the very least.

As well as making setting up the relationship structure a bit faster - concerns about ORMs notwithstanding - it gives a web UI for adding and updating entries out of the box.

Prototype Client

For the moment, this will be built in Electron. It's a bit resource-greedy, Electron ships a browser. If it was worth a rewrite later on, something like Tauri could be good, or something closer to native.

Neutralino was looked into but it's not really appropriate, being intended as web UI packager more than anything heavier.

Current status is that an Electron app is in place which can generate thumbnails and sets of hashes based on folders of pdfs. The next step is to get a sample API endpoint set up using the aforementioned Strapi database. The task would go as follows:

1. generate sample hashes based on local folders
2. populate two tables in the Strapi DB
   1. sources - rows for every publication
   2. impressions - rows of properties generated from files, related to a source
3. set up an endpoint that does "closest match" for a file, given impressions
4. have the client locally associate the file with a known source, and reflect this in the DB

Adding more relationships later on for publisher, author, etc will be possible. First though, having gotten the basic pipeline running, the job would be accumulate as much data as possible to generate a large set of impressions such that the average user will find the application useful enough.