Comment by mholt
6 days ago
Great comment, thanks for the questions.
> unless it's a machine at home,
This is, in fact, the intended model.
The problem with any other model, AFAIK, is that someone else has access to your data unless I implement an encrypted live database, like with homomorphic encryption, but even then, I'm sure at some places it would have to be decrypted in memory in places (like, transcoding videos or encoding images, for starters), and the physical owner of the machine will always have access to that.
I just don't think any other way of doing it is really feasible to truly preserve your privacy. I am likely wrong, but if so, I also imagine it's very tedious, nuanced, error-prone, and restrictive.
(Or maybe I'm just totally wrong!)
> - Could index and storage backend be decoupled, so that I can host my photos etc. elsewhere and, in particular, prevent data duplication?
I know this is contentious for some, but part of the point is to duplicate/copy your data into the timeline. It acts as a backup, and it ensures consistency, reliability, and availability.
Apps like PhotoStructure do what you describe -- and do a good job of indexing external content. I just think that's going to be hard to compel in Timelinize.
> Support for importing Polarsteps trips, and for importing Signal backups (e.g. via https://github.com/bepaald/signalbackup-tools ) would be nice!
Agreed! I played with Signal exports for a while but the format changed enough that it was difficult to rely on this as a data source. Especially since it's not just obvious what changes, it's encryption so it's kind of a black box.
That said, anyone is welcome to contribute more data sources. I will even have an import API at some point, so the data sources don't have to be compiled in. Other scripts or programs could push data to Timelinize.
Just to reiterate, one of the main goals of Timelinize is to have your data. It may mean some duplication, but I'm OK with that. Storage is getting cheap enough, and even if it's expensive, it's worth it.
Thanks for your thoughtful response!
> I just don't think any other way of doing it is really feasible to truly preserve your privacy. I am likely wrong, but if so, I also imagine it's very tedious, nuanced, error-prone, and restrictive.
It's certainly not easy but I wouldn't go as far as saying it requires homomorphic encryption. Have you had a look at what the Ente.io people do? Even though everything is E2E-encrypted, they have (purely local) facial recognition, which to me sounds an order of magnitude harder (compute-intensive) than building a chronological index/timeline. But maybe I'm missing something here, which isn't unlikely, given that I'm not the person who just spent a decade building this very cool tool.
> It acts as a backup, and it ensures consistency, reliability, and availability.
Hmmm, according to you[0],
> Timelinize is an archival tool, not a backup utility. Please back up your timeline(s) with a proper backup tool.
;)
I get your point, though, especially when it comes to reliability & availability. Maybe the deduplication needs to happen at a different level, e.g. at the level of the file system (ZFS etc.) or at least at the level of backups (i.e. have restic/borgbackup deduplicate identical files in the backed-up data).
Then again, I can't say I have not had wet dreams once or twice of a future where apps & their persistent data simply refer to user files through their content hashes, instead of hard-coding paths & URLs. (Prime example: Why don't m3u playlist files use hashes to become resistant against file renamings? Every music player already indexes all music files, anyway. Sigh.)
> Especially since it's not just obvious what changes, it's encryption so it's kind of a black box.
Wouldn't you rather diff the data after decrypting the archive?
> Just to reiterate, one of the main goals of Timelinize is to have your data. It may mean some duplication, but I'm OK with that. Storage is getting cheap enough, and even if it's expensive, it's worth it.
I suspect it will lead to duplication of pretty much all user data (i.e. original storage requirements × 2), at least if you're serious about your timeline. However, I see your point, it might very well be a tradeoff that's worth it.
[0]: https://timelinize.com/docs/importing-data
Correct, Timelinize is not a backup utility, but having the copy of your data in your timeline acts as a backup against losing access to your data sources, such as Google Photos, or your social media account(s), etc. As opposed to simply displaying data that is stored elsewhere.
But yes, I think the likes of what Ente is doing is interesting, though I don't know the technical details.
Data content hashes are pretty appealing too! But they have some drawbacks and I decided not to lean heavily on them in this application, at least for now.