Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Immich 3.0

github.com

Post reply on HN
Print view View original

111–120 of 313 posts

Re: Immich 3.0

#111

Post by sylens »

cevn wrote: post #98
WillDaSilva wrote: post #78

Earlier quoted context omitted.

For what it's worth, Immich supports this too. You can create an album (for each event), create a shared link, allow public anonymous uploads for the shared link, and then give the link to everyone at the event, and ask them to upload their photos. It can be done from any web browser.

I would love to know if there's a way to secure this though. I'm not prepared to have people constantly trying to login to my immich instance so it's only accessible via VPN

You can use something like Immich Public Proxy to only expose the /share path of your server and keep the main /api path that has everything else behind VPN

Re: Immich 3.0

#112

Post by eddythompson80 »

AussieWog93 wrote: post #82

So many comments here about missing end to end encryption, but seriously - why would anyone want this? Lets say burglars break in and steal your homelab. Because you don't have e2ee, they can see all the photos you saved of your dead grandmother! Oh no! Or, in the more likely scenario that something happens to your phone, the lack of e2ee means that even if you lost your keys you didn't lose the only memories that re…

It would make hosting a "Family and/or friends" instance possible.

I do go back and forth on the accessibility tradeoffs of E2EE for average people though. In this scenario, lose or forget your key/password and you lose ALL of your photos which are very important to some people. Losing them is pretty catastrophic. Google Photos or iPhotos really gives people a sense of security about their photos.

ps: It would also make it easier to host cloud instances for Immich without encrypting the file system of a remote server/VPS. Especially when renting servers from small-time sellers, I'm always weary about how much I can really trust their employees access control. I know some level of trust is unavoidable with physical access, but how do they handle those disks during maintenance would also be relevant.

Re: Immich 3.0

#113

Post by ctippett »

Panda4 wrote: post #56
oliyoung wrote: post #41

Immich is such a no-brainer replacement for Apple Photos or Google Photos, combined with VPN like Tailscale, it's almost a drop in replacement

Is there any side effects of leaving the phone connected to Tailscale VPN all day?

I have a static route configured on my home's gateway that enables any device on my network to access Tailscale. I have Tailscale turned on my iPhone pretty much all the time anyway, but even if I didn't I'd still be able to access services I have hosted that are only accessible on my tailnet.

Re: Immich 3.0

#114

Post by gchamonlive »

drdaeman wrote: post #110
gchamonlive wrote: post #106

Earlier quoted context omitted.

If they steal your homelab, e2ee doesn't help, it's encryption at rest. E2ee is for rogue devices sniffing the network, which is more or less of a concern depending on your setup. I'd not have unencrypted traffic in my network if I had for instance those shady TV boxes.

That’s incorrect. E2EE means encrypted data leaves the device, stored encrypted, and server(s) have no keys to decrypt it, only your (or other) client software does.

It's encryption both at rest and on transit. At rest there are levels of encryption, at object level or at filesystem level. E2ee for immich would mean the objects are encrypted and transmitting the data is encrypted. If the scenario is the server is stolen, you need encryption at rest. Even at FS level is enough.

Re: Immich 3.0

#115

Post by drdaeman »

Cider9986 wrote: post #26

When I was switching to GrapheneOS from iOS, I decided to self host my photos. I considered Immich, but I settled on Ente because of the encryption. Ente Photos is extremely polished and it's comparable quality to Apple photos. It's cool they keep the server open and selfhostable instead of only open clients like many e2ee projects do. I like how you can share an album and anyone can contribute to it without an accou…

> Ente Photos is extremely polished and it's comparable quality to Apple photos.

If only. It can’t even upload photos any reliably (I self-host). I had it simply fail to upload anything for days (it doesn’t provide any diagnostics, gotta figure out how to build and debug it myself), with no apparent reason. That’s despite keeping app in the foreground, on a charger, for hours, with video uploads and ML features all disabled so it was supposed to focus on just the photos. Server side is fine, web-based uploads work without any issues, app just doesn’t. I haven’t figured it out yet.

Re: Immich 3.0

#116

Post by enoint »

KomoD wrote: post #76
Panda4 wrote: post #56

Earlier quoted context omitted.

Is there any side effects of leaving the phone connected to Tailscale VPN all day?

Could impact battery usage, possibly? But the way I do access Immich externally is not with Tailscale directly on my phone but involves exposing a caddy instance, running on a $1 VPS, to the internet. If requests include a specific very long header (which I randomly made up), it then forwards those requests to my real Immich instance, which runs on my NAS. Headers can be configured within the mobile app. It has worke…

On an older iPhone, my Settings shows 3% going toward Tailscale.

Re: Immich 3.0

#117

Post by drdexebtjl »

AussieWog93 wrote: post #82

So many comments here about missing end to end encryption, but seriously - why would anyone want this? Lets say burglars break in and steal your homelab. Because you don't have e2ee, they can see all the photos you saved of your dead grandmother! Oh no! Or, in the more likely scenario that something happens to your phone, the lack of e2ee means that even if you lost your keys you didn't lose the only memories that re…

I think the point of E2E encryption is that you could host it with a cloud provider and the provider would not be able to see your data. Kind of like how Proton Drive claims it does not know which files you have.

This would force features like semantic search, face detection, video transcoding and thumbnail generation into the clients instead.

Immich assumes trusting the server to have access to your photos is fine. That is always the case when you’re self-hosting.

And I think that’s reasonable, since most users give that trust to Google and Apple.

Re: Immich 3.0

#118

Post by luke_s »

brewtide wrote: post #24

Does anyone have any pointers on the best way to import roughly 14 Google takeout chunks into immich? I've downloaded all the chunks once, only to find them corrupted due to... Their 50gb size and using a browser in theory. One also cannot seem to use wget or alternatives because of the auth / session cookies required via Google takeout. I've yet to even broach the aspect of importing each giant bundle into immich be…

I went through the same path as you - I think I even landed up with 14 takeout files as well!

Its a bit of a trial, but quite doable. Its likely that things have improved since I did it about 6 months ago.

*Getting the files from takeout* I tried downloading the files onto my laptop via a browser, and then copying them over to my NAS, but quickly gave up. The best approach is to download them directly to the NAS. As you pointed out auth/cookies is an issue. There are multiple ways of solving the issue, but for me I found the best way was to use chromes dev console network view to identify the network request for each file, then right click on it and select "Copy cURL". SSH into my nas and use that command to download the file. There is a bit more info on how to do this here:

https://trog.qgl.org/20241001/downloading-a-google-takeout-f...

*Importing them into immich*

Once I had all my takeout files on the nas, I used immich-go to import them: https://github.com/simulot/immich-go

This took a bit of tweaking to get the right set of command line args that worked well for what I wanted it to do. I also found immich errored out a few times during the import. Fortunately immich-go can just pick up the import where it left of, so I kept re-running it until everything was imported.

*Cleaning it all up* If you just want a huge flat dump of your files your probably good. In my case there were various things I wasn't quite happy about. The default handling of stacking edited images with the originals in albums wasn't what I was after. I wanted to replicate sharing of albums with immich users to match what I had in google photos. For all this kind of cleanup work, I found it quite helpful to work with an AI agent. Give it an API key for your server + the url and get it to help you write cleanup scripts.

Re: Immich 3.0

#119

Post by saintfire »

ivanjermakov wrote: post #53
oliyoung wrote: post #41

Immich is such a no-brainer replacement for Apple Photos or Google Photos, combined with VPN like Tailscale, it's almost a drop in replacement

Beware that migrating back from Immich to iCloud/Google is not something Immich cares about. There is no "download all" anywhere, best way is to go to the server and get raw files from there. https://github.com/immich-app/immich/discussions/14365

Maybe I'm missing something but the linked discussion has a link to a closed issue that links a PR that added the feature you say is missing.

Re: Immich 3.0

#120

Post by AussieWog93 »

gchamonlive wrote: post #114
drdaeman wrote: post #110

Earlier quoted context omitted.

That’s incorrect. E2EE means encrypted data leaves the device, stored encrypted, and server(s) have no keys to decrypt it, only your (or other) client software does.

It's encryption both at rest and on transit. At rest there are levels of encryption, at object level or at filesystem level. E2ee for immich would mean the objects are encrypted and transmitting the data is encrypted. If the scenario is the server is stolen, you need encryption at rest. Even at FS level is enough.

Not sure why you're continuing to argue, GP's right.

e2ee means that the encryption keys are stored client-side by the intended recipient. It's not just in transit and in rest.

Post reply on HN