| ▲ | DavideNL 8 hours ago |
| I don't want yet another self hosted service to manage (update, backups, possible hardware failures, energy costs, ups, etc.). Unfortunately Immich is not end-to-end encrypted. If that would have be the case i'd use https://pixelunion.eu/ Seems like a great app though. So... i'm still pondering what to do :-) |
|
| ▲ | mcsniff 8 hours ago | parent | next [-] |
| 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. |
|
| ▲ | FabCH 5 hours ago | parent | prev | next [-] |
| What do you mean Immich is not end-to-end encrypted? You control both ends, you can encrypt it any way you want… |
| |
| ▲ | olejorgenb 4 hours ago | parent [-] | | They said they only want to control one of the ends | | |
| ▲ | FabCH 4 hours ago | parent [-] | | Fair enough, but the Immich provider they link to also uses SSL and claims to encrypt at rest. It they don’t consider that e2e encrypted, literally nothing is then… | | |
| ▲ | NikxDa 4 hours ago | parent [-] | | Encryption at rest means they have the key. End to end means they don‘t. Huge difference! |
|
|
|
|
| ▲ | Grombobulous 2 hours ago | parent | prev | next [-] |
| If you don’t want self-hosted and you want E2EE, Ente Photos is the best solution on the market that I have found. |
|
| ▲ | gonzalohm 7 hours ago | parent | prev | next [-] |
| 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 |
|
| ▲ | brokensegue 4 hours ago | parent | prev | next [-] |
| it's really not much to manage assuming you are already doing backups. you ~ pay the energy cost either way. |
| |
| ▲ | BeetleB 4 hours ago | parent [-] | | 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. | | |
| ▲ | hamdingers 3 hours ago | parent [-] | | > Lessons from using self hosted image services years ago: Alternate title: "Outdated lessons I haven't re-evaluated" | | |
| ▲ | BeetleB 2 hours ago | parent [-] | | Are you saying there are never backward incompatible changes? Are you saying there's no need to back up the underlying DB? Are you saying I can keep an insurance running for, say, three years and it'll be trivial to upgrade after that? | | |
| ▲ | hamdingers 2 hours ago | parent [-] | | 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. |
|
|
|
|
|
| ▲ | Jhsto 8 hours ago | parent | prev | next [-] |
| You can use https://ente.com/ (it's open-source). It also makes the seemingly much better decision of storing photos in S3. |
| |
| ▲ | Grombobulous 2 hours ago | parent | next [-] | | Ente’s cloud-hosted solution does not use S3: https://ente.com/reliability/ For self-hosting, “S3” usually just means “S3-compatible.” Although maybe that’s exactly what you meant. | |
| ▲ | gonzalohm 7 hours ago | parent | prev | next [-] | | The point of Immich is self hosting. Using AWS defeats that purpose | | |
| ▲ | jasonvorhe 6 hours ago | parent | next [-] | | 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. | | |
| ▲ | MoonWalk 4 hours ago | parent | next [-] | | This is a good point. I'd rather have something with the S3 option, so I can serve the pages from my house but the images from a speedier source. | |
| ▲ | gonzalohm 6 hours ago | parent | prev [-] | | Yeah but Immich provides a lot more features than just storage |
| |
| ▲ | fragmede 6 hours ago | parent | prev [-] | | 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. | | |
| ▲ | gonzalohm 6 hours ago | parent [-] | | 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 |
|
| |
| ▲ | buster 7 hours ago | parent | prev [-] | | +1 for Ente. Replaced Google photos for me |
|
|
| ▲ | amelius 5 hours ago | parent | prev | next [-] |
| > I don't want yet another self hosted service to manage Isn't system administration a solved problem now with LLMs? At least for these simple problem domains? |
|
| ▲ | tamimio 5 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | jrm4 8 hours ago | parent | prev | next [-] |
| VPN (or other) Tunnel. 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. |
| |
| ▲ | ravenstine 6 hours ago | parent | next [-] | | 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. | |
| ▲ | PhilipRoman 5 hours ago | parent | prev | next [-] | | How are VPNs related to end-to-end encryption? | | |
| ▲ | nicce 4 hours ago | parent [-] | | Their primary purpose is usually encrypt the connection between different endpoints… by creating virtual private networks… |
| |
| ▲ | tamimio 5 hours ago | parent | prev [-] | | I believe OP meant at rest encryption, meaning, just because someone had an access to your physical drive doesn’t mean they can browse your pics. |
|
|
| ▲ | slipperybeluga 5 hours ago | parent | prev [-] |
| [dead] |