Okay, sold. This is also my setup and I was being held back by thinking that the experience would be bad due to it. But this will work for me!

Edit: wait I'm dumb, I just checked mobile Facebook and the upload button shows a pop up with choices for "Photo Library", "Take a Photo", or "Files".

When I checked half a year ago memories (with the nc ecosystem) was still ahead in terms of features (gallery specific), albeit object tagging is rather crap in nc (faces better)

I store my pictures on a NAS jail. That directory is mounted read-only on another jail with NC and Memories. I like the guarantee that my gallery app cannot alter my files.

Also, many gallery apps don't allow browsing a directory tree. You have one level of "albums" and that's it. Memories support it. I have pictures 5-6 directories deep, following a system that makes sense to me.

Ouch. One feature I love with Immich is that I can run it as Docker containers (I think it requires four containers) and pass the drive/volume with my photos as read-only, so I'm sure Immich cannot possibly modify my files.

The last thing I want is the latest solution du jour modifying my files.

Choosing the photos to include, plus doing the scrapbooking bits to decorate the photos, and including all the bits and bobs you might have acquired from whatever even you're memorializing, this locks the memories in far better than a carefully architected storage system that, in the end, is just a giant wad of binary data.

This goes double (or triple) when you have young children.

By all means maintain some kind of digital storage, but make your primary physical.

Make an album, print to Walmart on their pro printer, grab it a little later for a few bucks.

But yes, there are some other limitations that would be much harder to solve. But it's a tradeoff I've decided to make - if I can't figure out an EXIF-based solution then I'm not going to invest time using it because it will likely be lost in 5-10 years.

If you still miss it, note that Nitro (macOS, iPad, iPhone) is Aperture's spiritual successor, created by its former Sr. Director of Engineering. https://www.gentlemencoders.com/nitro-for-macos/

You could manually do it with Google Takeout -> <S3 backed service> before letting your phone sync handle it going forward if that’s a big backlog.

For example, I use Apple and Google on my phone to do this, I think you’d just need to find some app/service combo.

One of the many reasons I finally moved off Google Photos.

This was the biggest reason I also had to move away from Google Photos when all I really wanted was protection from getting my account accidentally G-structed with zero way to contact a human to get my files back.

I've solved that by materializing every photo to a deterministic folder path. So it's not possible to have the same exact photo in my library.

https://github.com/immich-app/immich/issues/24581

I not only urge you to try it, but to buy the "supporter" pack, Immich really deserves it.

Mine is something like "Album_Name/YEAR/MONTH/day-hour-minute-sec.jpg".

I'd recommend you try Immich (there's a docker compose version) and if you don't like it, you can just remove it and move on.

I've got the solution to this. I'm like you: files on disk. But I also use Immich: and here's the kicker... I pass the drive/volume with my photos to Immich as read-only (I use containers so it's easy: the drive itself is read-write, but Immich only has read-only access to it).

When I'm pissed off by Immich or something better comes along, I destroy the Immich containers and it's gone.

And I still my files on disk (with checksums as part of the filenames, moreover, seen that family JPG pictures aren't files that happen to change a lot and if they change, they can be renamed).

Also: you should try out the latest build! https://photostructure.com/about/v2026.1/

FWIW all of these projects rely on ExifTool (which people should donate to!) and my open-source node.js wrapper (that adds concurrency, does a ton of extra parsing work, and makes things a bit more ergonomic to live with): https://github.com/photostructure/exiftool-vendored.js

Downloading the takeout files is miserable through, the download link is only valid when being downloaded via human interaction in a web browser.

There is a silly trick. Start the download, pause it. Get the cookies from the page (only need to do that once for the session). Then copy the download link. Now you can curl on your server. When the file is downloaded, you can then cancel the download in your web browser. And do the same for the next file. One at a time.

Warning: google will cancel downloads if you run more than one or two at a time. After 3 download (failed or not) of a file google will delete the whole takeout.

The amount of engineering they must have deployed to purposefully crimple takeout with plausible deniability must be significant.

Mine is so old that it doesn’t and it’s also under powered - else I’d be running Immich on it.

I include video [1] and audio (.m4a) [2] files via EXIF.

For text files [3], I add a JSON block at the top to mimic EXIF.

I don’t want to deal with an additional sidecar file per asset. The risk of losing one during a transfer between systems is too high. It’s a conscious decision and not an oversight.

[1] https://github.com/jmathai/elodie/blob/2645bf25b81c63f65d6f1...

[2] https://github.com/jmathai/elodie/blob/master/elodie/media/a...

[3] https://github.com/jmathai/elodie/blob/master/elodie/media/t...

Without Claude Code, the plugin would probably only exist in my imagination.

I don’t personally care who writes the code. There’s plenty of contributors already.