Daniel's been wrestling with something I think a lot of people feel but can't quite name. He uses Google Photos constantly — not just for snapshots, but as a working visual knowledge base. He photographs his engravings, organizes them into albums, and pulls them up mid-conversation with ChatGPT. It works beautifully, right up until he remembers he can't actually back any of it up. Not properly. Not incrementally. Not without scripts that break every time Google sneezes.
And he's asking whether there's a replacement. Something with folder-based organization, thumbnail gallery navigation, voice-first note input, and — this is the kicker — an actual API for incremental backup, without requiring him to self-host the production instance. Plus a side question about whether using a photo tool this way is even a legitimate use, and a separate frustration about Google Docs lobbing images out into CDN links with no programmatic way to retrieve the originals.
So we've got a stack of questions here. The one underneath all of them is: can you have both the convenience and the control, or does the API requirement automatically push you into enterprise or self-hosted territory?
Let's start with why Google Photos is the way it is, because once you see the structural reasons, the backup problem stops looking like an oversight and starts looking like the point.
The point.
Google Photos is not a storage product. It's an engagement product. The AI search, the automatic face clustering, the "this day last year" notifications — all of it is designed to keep you inside the ecosystem, scrolling, sharing, generating more data for their models. Programmatic access undermines that. If you can incrementally sync your entire library to a NAS, you can leave. And leaving is the one thing the product is architected to prevent.
So the friction isn't accidental.
It's structural. Let me walk through the technical specifics. Google Takeout exists — it's the full-archive export tool — but it's a blunt instrument. You request a dump, you wait hours or days, you get a set of zip files. It's not incremental, it doesn't preserve album structure reliably, and it's not something you can schedule. It's designed for account closure, not ongoing backup.
Which is a different use case entirely.
Then there's the Google Photos Library API. This was the programmatic interface that third-party developers could use. It's still technically available but it's been effectively frozen since twenty nineteen — read-only for albums, no write operations, and critically, no support for incremental sync of changes. You can list albums, you can list media items, but you can't ask "what changed since last Tuesday." You'd have to re-enumerate everything and diff it yourself.
Which is how you end up with tools like gphotos-sync.
Right. gphotos-sync is a Python tool that tries to do exactly this — it uses the Library API to pull down your Google Photos library. But because the API doesn't support incremental sync natively, the tool has to reconstruct it. And it breaks. If you look at the GitHub issues, there are persistent problems with album structure corruption and duplicate detection. Users report albums getting flattened, photos appearing in the wrong folders, the same image downloaded multiple times under different names. It's a fragile house of cards.
And rclone?
rclone has a Google Photos backend, but it's read-only, no upload, and no album sync. It can pull your photos, but it can't reconstruct the organizational structure you built. So you get a flat folder of images with none of the album metadata that made them useful in the first place.
Which defeats the purpose for Daniel's workflow. The albums are the organization.
That's the core mismatch. Google Photos is built on what you might call a "moment" model — everything is timeline-first, AI-tagged, with albums as lightweight collections of references rather than directory structures. There's no filesystem underneath to sync against. Any backup tool has to reverse-engineer the organization from metadata that Google doesn't expose cleanly. It's like trying to reconstruct a library catalog by looking at the books through a window.
So you've got a product whose data model is fundamentally incompatible with the concept of incremental backup. And no incentive to fix it.
None. The business model depends on you staying. Simon Griffiths wrote a piece back in May that framed this perfectly. He pointed out that the three-two-one backup rule — three copies, two different media, one offsite — is violated the moment your "offsite" copy is the same service you use day to day. If Google Photos is both your primary and your backup, you have one copy. And because sync propagates deletes, if you delete a photo on your phone, it vanishes from Google Photos too. A real backup is independent, versioned, and under your control. Cloud sync is none of those things.
"The cloud is not a backup" sounds like a slogan, but Griffiths is naming something specific. It's not that the cloud can't be part of a backup strategy — it's that mistaking sync for backup gives you the illusion of protection without the substance.
And Daniel's workflow makes this concrete in a way that's almost painful. He's photographing engravings, organizing them into albums, then referencing them in ChatGPT. That's a visual knowledge base. It's structured data he depends on for creative work. If Google decides his account violated terms of service — or if he just fat-fingers a deletion — years of organized reference material could vanish. And because there's no incremental export, his only recovery option is a months-old Takeout dump that doesn't preserve the album structure he spent all that time building.
That's the fragility. The tool is too good to leave and too closed to trust.
So let's talk about what's out there that might actually work. Daniel laid out four criteria: folder-based organization, gallery and thumbnail navigation, voice-first note input, and an API for incremental backup without self-hosting. That's a surprisingly tall order.
Where do you even start?
The most interesting candidate is a service called Ente — that's E-N-T-E dot I-O. It's end-to-end encrypted photo storage with desktop and mobile apps, album support, and a documented export API that actually supports incremental sync. Pricing is around six to ten dollars a month for a hundred to five hundred gigabytes. The API is designed for data portability from the ground up — it's not an afterthought bolted onto an engagement product.
So it's the counterexample to the Google model.
It is. And it proves something important: you don't have to be enterprise or self-hosted to offer a real API. Ente is a consumer SaaS product. The difference is that they market on privacy and data ownership rather than convenience and AI features. Their value proposition is "your photos belong to you," not "we'll organize your photos for you."
Which is a different pitch entirely. Does it handle the voice notes?
Not natively, as far as I can tell. It's primarily a photo app. You could pair it with a separate notes tool that supports image embedding, but that fractures the workflow. And Daniel's asking for something integrated — photograph, organize, dictate a note, all in one place.
That's where the notes-app angle comes in. Tools like Notion, Obsidian, Capacities — they all let you embed images and attach voice notes. But their image handling is document-first, not photo-first. You're scrolling through pages, not thumbnails. If you want to browse a hundred photos of engravings, a notes app is going to feel like you're looking at them through a keyhole.
The gallery view is the missing piece. Notes apps are built around text; images are illustrations. Daniel wants images to be the primary objects, with notes attached to them. That's a digital asset management paradigm, not a document paradigm.
Which pushes you toward tools like PhotoPrism.
PhotoPrism is a self-hosted DAM — digital asset management — tool with gallery navigation, AI tagging, album support, and a proper API. It's good at what it does. But it requires self-hosting, and Daniel explicitly doesn't want the production instance on his home network. He's been clear about that: for anything he depends on for productivity, he wants it decoupled from his home infrastructure.
Which is reasonable. Home internet goes down, you still need to work.
So the SaaS equivalent would be something like Cloudinary, which is an enterprise-focused media management platform with APIs, transformations, CDN delivery — the works. But it's priced for developers and companies, not individuals managing a personal photo library. And it's not consumer-friendly. You're not going to browse your engravings in a nice thumbnail grid on your phone.
So we've got a gap. On one side, privacy-first photo services like Ente that nail the backup and API requirements but lack the notes integration. On the other, notes apps that handle voice and organization but lack gallery-first image browsing. And in the middle, enterprise DAM tools that do everything but are priced and designed for teams.
The pattern I keep seeing is that companies marketing on privacy and data ownership — Ente, Proton Drive, Tresorit — tend to build export tooling as a feature. Companies marketing on convenience and AI — Google, Apple — do not. It's not a technical limitation; it's a product philosophy. If your selling point is that you'll organize everything for me, you don't want me thinking about how to take my organized data elsewhere.
So the answer to Daniel's question about whether the API requirement pushes you into enterprise or self-hosted is: no, but it narrows the field dramatically. You're limited to a small set of privacy-first providers who've made data portability part of their pitch.
And none of them quite nail the full workflow he described. Ente plus a separate voice notes app might be the closest practical combination right now.
Let's talk about the other side of this — the Google Docs image problem. Daniel mentioned lobbing out links into CDNs, and that's a specific frustration worth unpacking.
When you upload an image to Google Docs, it's stored in Google's infrastructure but exposed through a CDN URL that's tied to the document's access permissions. There's no API to retrieve the original image file programmatically. You can't say "give me all the images from this document with their metadata intact." The image is treated as a rendering asset — something to display — not a first-class data object you might want to extract and use elsewhere.
So it's the same structural problem in a different domain. The image exists to serve the document, not to be a portable piece of data in its own right.
And that design philosophy runs deep. If you want to get the original images out of a Google Doc programmatically, you're looking at scraping the document or using Google Apps Script to extract them — both of which are brittle, neither of which preserves metadata reliably. The image was never meant to leave.
Which brings us to the meta-question Daniel raised. Is using Google Photos as an organizational and AI-interaction tool a bad use?
I'd say no, and I think the framing is wrong. Any tool that supports a workflow is being used correctly. The problem isn't misuse — it's that Google Photos' design assumptions conflict with Daniel's use case. It's built for timeline-first browsing and social sharing. He's using it for knowledge-base-first organization and AI interaction. Both are valid; they just pull in opposite directions.
The conflict shows up at the seams. The moment you try to do something the designers didn't anticipate — like incrementally backing up your albums — you hit a wall. That's not user error. That's a design philosophy that treats unanticipated uses as threats rather than opportunities.
And the real question is whether a tool built for one paradigm can be repurposed without pain. The answer is: only until the provider changes the rules. Google could deprecate the Library API entirely tomorrow — it's already frozen — and every script-based workaround would break. You're building on sand.
So where does that leave someone in Daniel's position? The tool works perfectly for the daily workflow. The backup problem is real but not urgent — until it suddenly is.
I think the pragmatic answer is layered. Short term, you accept the fragility and run periodic Takeout dumps as a disaster recovery measure, knowing they won't preserve album structure. Medium term, you start migrating the most important albums to something like Ente and testing whether the workflow holds up. Long term, you watch whether the privacy-first ecosystem grows to fill the gap — or whether the AI integration features of the big platforms become so compelling that the backup question gets answered differently.
The other variable is that Daniel's use case — images as structured data for AI interaction — is only going to become more common. As tools like ChatGPT get better at referencing uploaded images, more people are going to build visual knowledge bases. And they're going to discover, exactly as Daniel has, that the platforms that make this easiest are the ones that make it hardest to leave.
Which creates a market pressure. If enough users demand portable, API-accessible image storage because their AI workflows depend on it, either Google and Apple open up or new entrants fill the gap. Ente is promising but small. The question is whether it can scale without compromising the principles that make it attractive in the first place.
Scale has a way of eating principles for breakfast.
It does. But I think there's a version of this where the AI revolution actually strengthens the case for data portability. When your photos aren't just memories but working materials — inputs to creative and analytical processes — the cost of lock-in goes way up. You're not just losing snapshots; you're losing your source material.
That's a different value proposition entirely. And it might be what shifts the market.
Hilbert: He's right.
About which part?
Hilbert: The whole thing. I spent eighteen months as a photo archivist for a small museum in Vermont. This would have been... ninety-eight, ninety-nine. We had a custom DAM system — digital asset management — built on top of a SQLite database and a folder structure on a Windows NT server. About forty thousand images. Scanned photographs, documents, the works. The vendor was a two-person shop in Burlington.
And they went under.
Hilbert: They went under. And their "export" feature — I use the word loosely — exported thumbnails. Thumbnails. We discovered this when we tried to migrate to a new system. Three years of digitization work, forty thousand images, and all we had were postage-stamp-sized versions. The originals were locked in a proprietary blob format that nothing else could read.
How did you recover?
Hilbert: We didn't. We had the original physical materials for about two-thirds of the collection, so we re-scanned. The other third — photographs loaned from families, documents that had been returned to donors — gone. The museum director had to write letters. It was not a good summer.
You got religion about data portability.
Hilbert: I got obsessive. The replacement system we built was a folder structure on a Synology NAS with a custom web frontend. Every image stored as a TIFF with embedded metadata. The database was just a cache — if it died, you could rebuild it from the files. And we ran exports to external drives every Friday. I still have the script.
That's the thing, though. You had the discipline to actually run the exports. Most people don't. Ente's export API is great, but it's only as good as the user's commitment to using it regularly.
Hilbert: That's the part nobody wants to hear. The most reliable backup system I ever saw was a guy who printed his photos and put them in a fireproof safe. He had a system — every month, he'd order prints of anything new, swap them into binders. Absurd, right? But those binders are still there. Twenty years later. No API, no subscription, no vendor bankruptcy. Just paper in a box.
Paper doesn't deprecate.
Hilbert: Paper doesn't deprecate. And it doesn't change its terms of service. My brother-in-law — he's a wedding photographer, has been for thirty years — he still keeps negatives. Digital files on three drives, sure, but the negatives are in sleeves in a cabinet. He says the drives are for convenience; the negatives are for when the drives fail. And he doesn't trust any of the cloud services. "They're all one acquisition away from ruining my archive," he says. He's not wrong, but he's also — how do I put this — he's the kind of person who keeps his own bees. So take his opinion with that in mind.
A beekeeper with a negative archive. That's a specific type of redundancy.
Hilbert: The point is, the API is only half the answer. The other half is the person who remembers to use it. And most people won't remember until it's too late. That museum I worked at — we had the export feature right there in the menu. Nobody had clicked it in three years. Why would they? The system worked fine. Until it didn't.
The real problem isn't just technical — it's that backup requires ongoing attention, and attention is the scarcest resource.
Hilbert: Always has been. The tools are better now. But the human part hasn't changed. You still have to care enough to do the thing before you need it.
Most people discover they care about three seconds after they needed it.
Hilbert: That's about right.
The cutting-room floor detail I keep coming back to is the XMP metadata tags. When you're dealing with images as structured data — which is what Daniel is doing, even if he doesn't frame it that way — the highest-leverage thing you can do is embed your organizational metadata directly in the file. Keywords, descriptions, album membership. If the metadata travels with the image, the backup format matters less. You can reconstruct the organization from the files themselves.
Which is exactly what Hilbert's museum replacement system did. The files were the source of truth.
Right. And it's what almost no consumer photo service does well. Google Photos strips most metadata or stores it server-side. Apple Photos keeps it in a proprietary database. Ente preserves it, which is another point in its favor. If I were building a visual knowledge base today, I'd be writing descriptions into the IPTC caption field and keywords into the XMP subject tags. That way, even if the platform disappears, the intelligence is in the pixels.
That's a good discipline. But it's also extra steps. And extra steps are the first thing to go when you're actually trying to get work done.
Which brings us full circle. The tension between convenience and control isn't resolvable — it's a tradeoff you manage. Daniel's current setup maximizes convenience at the cost of control. The alternatives we've discussed increase control at the cost of convenience. The question is which tradeoff you can live with.
Whether the market is going to narrow that gap. Ente and similar services suggest it might. But they're small, and the network effects of Google Photos and Apple Photos are enormous. Most people aren't going to switch photo platforms because of an API they'll never use.
Most people aren't building visual knowledge bases for AI interaction either. But the number who are is growing. And that's the open question I'd leave this on: as AI tools become more integrated with personal media libraries, will the demand for portable, programmatically accessible image storage push the big platforms to open up? Or will it push the people who care toward self-hosted and privacy-first solutions, creating a two-tier market where convenience and control don't overlap?
I suspect we're heading toward the two-tier outcome. The mass market will stay with Google and Apple because the AI features are useful and the friction of switching is high. The people who depend on their images as working materials will gravitate toward tools that treat portability as a feature rather than a threat.
In the meantime, anyone in Daniel's position should probably run a Takeout dump this weekend, just in case.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop for keeping the show running — and apparently for maintaining a folder structure that could survive the apocalypse.
If you enjoyed this episode, rate us five stars and tell a friend who's also frustrated by their photo backup situation. Email us at show at my weird prompts dot com.
We'll be back soon.
