People complaining about the menus and UI to not be intuitive made me chuckle...
I remember a long time ago, the thing that frustrated me most was that some options are not *visible* when you're in the "file manager" versus inside the "reader" (while reading a book) - and the other way around.
That's so confusing. Would be much better if these options would be *disabled* instead of being *invisible*...
You need to first provide a passport image + 5 angled selfies + bank statement + proof of employment to the Peoples Democratic European Union before you can sign.
Yeah, I thought so too, but surprise surprise; some months ago one of the "minor" updates "broke" ("upgraded") something that made my CI/CD setup stop working, that's when I dropped the idea that Apple even do "minor" updates anymore.
Yep, i do the same thing. The trick is to increase the barrier to entry.
For the same reason, i don't install ANY apps on my smartphone and tablet, like social apps and news apps. If you have to grab your laptop to check them, it takes way more effort.
And, if you really need to access something "urgently", you can always use the web browser (which is annoying) where i always use Private Mode (no easy logging in.)
Okay? So don't use it, use a managed service like Google Photos, Apple Photos, Dropbox, etc where your photos and files might be arbitrarily removed or your access to them limited while they are scanned for disavowed content.
You can also just use a secure transport layer (like WireGuard or a VPN) instead of relying on every project to implement end-to-end encryption.
Yes but magical homomorphic encryption aside, the person has conflicting requests at that point. They are asking for an image app that can’t view their images.
That’s not an image app anymore, that’s just encrypted storage.
I think the idea is that the images are decrypted by the client. See how Ente does it: https://ente.com/architecture
Of course - this sacrifice quite a bit of functionality since more or less all functions which require looking at the pixels need to be client-side. But to be fair - the client is part of the "app", so it's not "just" encrypted storage.
You can have immich on truenas that has the whole pool encrypted, same goes with opencloud for other docs/files. Plus all nas backup features, I think it’s a better approach than dealing with each app encryption.
Edit: regarding cloud based backup, besides the usual privacy and security concerns, you can’t guarantee the fixed price, you might subscribe now and pay for a year, next year you have the typical “oops, operation cost are high we have to raise the prices or shutdown” blog post and now you’re stuck again, download, find another, upload, etc.
That's the objective answer. There's no mystery here. That's exactly how you get what you want and it's not too hard. Not trying to dunk on you or anyone one but this is an easily solved problem, and I think I want to highlight it like this to make sure everyone understands.
Anything web/internet/network service thing, you can add this on. This composability is important to remember in software, this even goes back to "The Unix Way" type stuff.
It's also a kind of funny thing how HN has the attitude of "never implement your own encrypted anything" but then demand their apps build in e2e encryption. It may be one abstraction higher, but it's still fundamentally the same problem. With the unfortunate exception of web browsers, if I'm going to use something that performs encryption, then I want encryption to be the only job it has.
When we talk about "E2EE" messenger apps, that usually means more than just using HTTPS. VPNs can certainly help with encryption in transit, but that's a very different concept.
Unfortunately this comes up a lot, with people asking if Immich supports end-to-end encryption and getting told to use LUKS or Tailscale.
So if you don't want a self hosted service there are tons of cloud providers. Google photos, iCloud, etc. Some people don't want to pay a monthly fee to store their photos or don't want to risk losing something with sentimental value just because a company decides to ban you
Lessons from using self hosted image services years ago:
- Upgrade breaks things. Need to restore from DB, install previous version, etc.
- Need to update frequently (i.e. if I wait 2 years, the upgrade script doesn't work).
- Discovering a corruption months/years later. Some data just lost by that point.
- Backward incompatible changes
Of course, if you need the features, by all means use it. I just want to back up my photos and use FolderSync daily. I have a separate workflow for pruning. As long as FolderSync (or some similar app) exists, I know this flow will work 10 years from now (heck, I've been using it for almost as long). No time spent worrying about upgrading, etc.
I'm saying your contribution is outdated and irrelevant, and my primary intention in commenting is to label it as such for any passers-by who might think you're talking about the current state Immich.
That sad, I'm happy to answer your questions. I've run Immich in docker for 3 years with automatic updates through watchtower. Updates are frequent but require no effort from me and have never broken anything, nor is there an "update script" to fail. Nor have I encountered "corruption" at any point. I do back up the database and my photo library.
I'm glad you're happy with your solution, you can share it without disparaging other solutions you're unfamiliar with.
I'm glad you're happy with it, and perhaps Immich will continue to remain secure. 3 years is comforting.
I will note that the last solution I used was fine for over a decade before it broke (and eventually the project died). For much of the time I was using it, it was the primary open source self hosting solution.
So one of my criteria is: "If the project dies, can I maintain it?" Obviously, I can't use that approach for everything (limited skills and time) - I do use NextCloud, for instance (which, BTW, is fairly painful for some of the reasons I listed above). But wherever I can (and wherever it's important), it's best to develop your own stack.
Best to think in the long term. But yes, for sure, there are down sides to my approach.
However, i also want the availability of my photos to be reliable, just like e-mail. It always has to work, wherever i am.
When i'm on the road, and there's some random issue due to power outage, database corruption, or whatever else, i don't want to have to wait until i get back home and make the time to fix things.
On the other hand, when i'm self hosting something like an RSS reader or Jellyfin to stream videos, it's less of an issue. That can wait a few days or weeks until i can fix it.
Valid points. But I see self-hosting even as renting a VPS from someone and running the service there. Which solves most of the dev ops problems that I dont wanna bother with.
Maybe it's not "actual" self-hosting, but concenient enough to use it
S3 has many open implementations you can self host. Some are quite lean even. Unless you need really complex IAM stuff it's a solid and rather simple experience to run it.
Wouldn't it then be reasonable to focus on those many features, instead of storage? I would enjoy using with S3, as expanding S3 storage is easier than expanding the storage of a virtual machine: usually it happens automatically.
Perfect is the enemy of the good. While there's an ideal case where you're hosting it on a box in your house, that's not for everybody. So while hosting it on AWS doesn't remove every dependency on big tech, at least it's not a full on Google hosted SaaS product.
I think "perfect is the enemy of good" is actually an argument against AWS integration. Using S3 as a backend is a lot more complex than using local storage so it would take a lot more time to implement, that's why local storage is good enough
Only if we look at resources it takes to implement features as limited and we're in starvation mode. With AI writing code these days, if they choose to use it, it's less about the resources to make the features and more about what having the features enables.
I think I dug my own grave by not being explicit that I thought S3 as a protocol and not the AWS product. :)
To elaborate a bit further, the S3 layer makes sense once you self-host S3 yourself. This allows clusterization of multiple hosts to offer redundancy in self-hosted setting -- for example, a friend of mine and I run S3 instances and "seed" each others' buckets for photo storage, but also for package manager (Nix). Having this kind of sane object storage just expands in use-cases, like with Matrix, etc., which all then inherit the clusterization hence redundancy for free.
The E2E encryption is also very useful when you are backing up or hosting photo galleries for friends and family -- because you cannot do metadata analysis on encrypted files, they have to do that on their own devices. This makes self-hosting much more "fearless" because I do not have to account for the fact that when/if my nodes are becoming a sauna-stoves for doing inference when someone dumps an album in.
The datasets that I have are terabytes. At some point it's just cheaper (accounting your time as free) to buy a 20tb drives and get yourself a runway for 5 years or more + space to do other stuff.
I bet he said this because it made many Europeans realize the threats are real: Trump can block the EU from using any US service, whenever he feels like it.
I remember a long time ago, the thing that frustrated me most was that some options are not *visible* when you're in the "file manager" versus inside the "reader" (while reading a book) - and the other way around.
That's so confusing. Would be much better if these options would be *disabled* instead of being *invisible*...
reply