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.
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".
1. https://sqlite.org/mostdeployed.html 2. https://sqlite.org/locrsf.html 3. https://www.loc.gov/preservation/digital/formats/fdd/fdd0004...
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?
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).
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.
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?
> 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?
It does require nodejs, but there is no database other than the native file system.
