Scoping a Local-First Image Archive
13 comments
·March 19, 2025pscanf
Hurray for this approach! I want most software that works with my personal data to work like that. And I'm actually working on a hobby project to make it possible: a local database + platform to run "local" apps on it.
I haven't gotten to implementing the data layer yet, but my idea was indeed to go for "simple files in folders". But I'm wondering, what format should I use for files containing structured data used by a specific app? For a photo app, using image formats is the obvious and easy choice. But what about, for example, a meal tracking app? What file format would you use to store nutrition facts about a certain food?
My first thought is JSON, but that's not really user-friendly. For a non-technical user a JSON file is basically useless without the app that generated it. YAML is maybe a bit less cryptic for a non-technical user, but still mostly useless. A TXT with a specific, more user-friendly format? Then you risk the app breaking because the user changed its content. And still, as a user what would I do with a bunch of TXT files containing nutrition facts? Without the app that generated them, there's a high chance they become useless.
My project also wants to solve that issue actually, ensuring that you always retain access to the apps that generated those files. But I would love to find a way to store data so that it keeps being useful and accessible even "app-less".
20after4
IMO the best file format for this set of requirements is SQLite. It's the world's most widely deployed database engine, the file format is simple and the spec is public domain. The entire database engine has been re-implemented in multiple languages. SQLite is a "recommended storage format"² (along with XML, JSON, and CSV) of the library of congress because of it's long term sustainability, among other factors³.
1. https://sqlite.org/mostdeployed.html 2. https://sqlite.org/locrsf.html 3. https://www.loc.gov/preservation/digital/formats/fdd/fdd0004...
wlesieutre
I remember a Mac app years ago that had nearly this exact same pitch, but stopped development because it wasn't making enough sales and the developer didn't want to pursue it just as a hobby project.
Just now I found FlowVision which looks like a similar concept, but I don't think that was the one I'm thinking of.
https://github.com/netdcy/FlowVision?tab=readme-ov-file
Anybody know what app I'm trying to remember?
stog
I don't know the project you mentioned first, but it's a shame they stopped developing due to sales.
FlowVision looks brilliant and an almost perfect client for my needs - thanks for sharing. It's a very similar concept to what I'm trying to acheive with my project but with mine I'm trying to focus on having the output suitable for archiving with no dependecies/app installs - all the user would need is a web browser.
The idea is that as long as browsers are about, you (or anyone) can use the viewer. The general idea is that once it's built it would be put on an SSD or something and in years to come can be plugged in and viewed by clicking a .html file. Sticking to plain old HTML and CSS in the output has proved pretty resilent over the last 30 years.
I'll be sticking the code on GitHub shortly under MIT and people can do what they want with it (hopefully make it faster, and more reliable without bloating it).
wlesieutre
Love the concept, I missed that you were outputting HTML galleries from the folder structure.
Similar reason that I bailed from OneNote to Obsidian even though it's not good with tablets/handwriting/drawing. I'm just tired of my stuff being tied up in someone else's service where at any time they can alter the deal and all I can do is pray they don't alter it any further. Sure, I pay for Obsidian Sync, but worst case it's a folder of Markdown files and a little bit of special syntax that someone else could knock off in a day if Obsidian went bad.
clueless
I've been thinking on working on something exactly like this for months and happy to see the work started here.
The big thing I'd love to add is smarter llm based searching ability (using face-detection, lon/lat based location data extracted from photos, overall image description based on AI, etc) similar to how google photo does it.
Now the question is, what local/small llm would be best for this?
eviks
Laudable goal!
> No database, no external dependencies—just files.
Your plain text file is a database, and a bad one at that in keeping things in sync/batch-editable since you now have hundreds of little databases. What if you merge two folders?
Also, your file manager can already preview images, why bring the whole browser to the table?
kingo55
I love the idea of having access to your own personal data in plain formats like this. Just like with plain text note taking, and being able to run local AI models against your personal notes, I imagine one day running local AI models over your image data.
apopapo
This reminded me of a static site generator called thumbsup: https://github.com/thumbsup/thumbsup
It does require nodejs, but there is no database other than the native file system.
paradox460
Databases aren't the enemy. Databases you don't control are. I'd much rather have any structured data in a sqlite db than a quasi-bespoke format, even if that format is "plain text"
xela79
interesting why nobody mentioned https://immich.app/ yet?
mentalgear
Lo-fi for the win! Also markdown or JSON pairs nicely.
> A plain text file (meta.md) can store optional metadata and is readable simply by opening it
To me, "readable" is not enough. Entering this data-augmentation text is time consuming: it should be as easy as possible. Including "augmenting" in batches (for this photo and that one and these 200 others).
Markdown in particular is not it - augmenting is not about presentation but about something like unstructured input of structured data. Or unstructured input of data which is systematic enough that it can be exploited by structured data retrieval. For example, "my finished art" or "my clothing inspiration" even when there is not strictly one way that these are tagged (yet).
To me, this means that super-efficient input of "somewhat structured" data is the missing link. It's a user-interface issue (NOT database screens) and a data language issue (NOT json or markdown).
"Selection" by contrast does not seem too hard. Provide an independent selection mechanism. Add this image to selection list A, that image to selection list B, those 200 images to selection list C. (That's kinda the iOS Album approach). Tag or data-augment selections A,B,C asynchronously when time allows.
By all means "AI" help is welcome - if it can be local.