Scoping a Local-First Image Archive
7 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".
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).
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?
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.
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.