Music and photo syncing

Around the time Google dropped “Do no evil” as a core value, I started making serious efforts to excise it from my life. One of the hardest (the second[^1] hardest) has been Photos.

Google Photos is a spectacular example of a user ecosystem done right. Synchronizing was – if you were already in the Google ecosystem – effortless; on an Android it is more work to have Google not sync your photos than it is to enable it. The web user interface is quite nice, and sharing photos via URLs is as easy as sending them as attachments. And it wasn’t just “as easy as,” it was actually better, because there was a whole slew of things you could do that attachments couldn’t: share whole photo albums, set access control, share larger videos easily, and manage all of this as easily from a computer as a phone. The native Photos app was a wonderful photo management tool; for a time, casual photographers didn’t need a different Plus, Android would delete old photos that had been backed up, clearing space on your phone. All of this was so automatic and well implemented that I sincerely think it should be a study model on user service ecosystems.

How do you replace this? Here are the various bits you need:

That “photo manager” part is somewhat hard. There are several OSS offerings; I personally like Photoprism. It doesn’t only have to be a web-based photo browser; to match Google Photos, it has to also:

Photoprism does this, and can accept uploads, but hooking it up to a mobile device is harder. The authors are focused on the web UI, which is unfortunate for those of us who prefer to use native apps. There is a third-party mobile app, but there’s some disagreement around the API; the mobile app dev has asked for API changes and is maintaining a fork of the server with the changes, as the Photoprism author(s) haven’t accepted the API changes. This has been going on for a year, at least, so if you want a reliable connection from your phone you have to set up a side-channel for the uploads.

There’s a quite good solution for Android for the photo backup part called PhotoBackup. You can run a Python or a Go server to receive the files. After that, it’s just a matter of automating having Photoprism import the files from where-ever you had PhotoBackup put them. This can be done by calling the Photoprism CLI tool; if you’re running Photoprism in a container, it’d be something like:

  /usr/bin/podman exec -ti photoprism photoprism import

I stuck that in a cron job every 15 minutes, and it does the trick. I may change that to an fswatch trigger to avoid the unnecessary calls.

I don’t have a solution for auto-purging images from the phone, and while I haven’t looked into it, I think it’s not something I’m likely to be able to solve. Any solution would require knowing that images are replicated onto the remote server, and I doubt I’m going to find an app that will do that. It’s not high on my priority list, so I will probably not write a solution, either.

The developers at Google obviously thought through this whole process: they made it so simple it’s automatic, with no configuration or extraneous complication, and they made it complete – an end-to-end solution that did what most people wanted from phone photos. It was so well written, most of the time most of the complexity was utterly hidden from the users.

I won’t talk too much about the downfall. It started with the deprecation of Picasa, but the ecosystem has only gotten worse over the years. Google was at their peak in the early 2000’s, and looking at their offerings, their developers were in top form. We can still learn a lot from 2010-era Photos.

[^1] The first is Maps. OpenStreetMaps is getting much better, and Maps is getting worse, and they’ll probably meet somewhere in the middle.