Or a sickle.

FCKGW, but yes.

Ahahaha, nice. Loosely reminds me of how we looked at implementing share-to-app (when that was a novel thing) in a mobile OS circa 2011 and we looked at how iOS did it. It was a list of hardcoded targets - Facebook, Twitter. No pluggability no nothing. Our product team was like - if no pluggability is good enough for Apple, it’s good enough for us!

deleted by creator

What is it, restricted access? Am an Android user since 2008 and never had an iOS device so I’m clueless.

Wait for 3.0.3 and then the emergency 3.0.4. 😅

That’s probably coming too. This is the first preview of the feature.

Sounds like you should self-host Nextcloud with Tasks and Tasks.org on your phone. 😄

Upgrade guide from Immich v2 - https://immich.app/blog/v3-migration.

zpool create and docker compose up to you too!

That’s like threatening a dog with a sausage.

RAIDz2 for 5.5TB with 2-disk redundancy.

All of a sudden USB becomes important. 😅

https://en.wikipedia.org/wiki/Steam_generator_(nuclear_power)?wprov=sfla1

Times must be tough at Meta.

Coud probably be done. Find publicly shared Immich albums -> sync to Google Photos -> share publicly -> write the public Google Photos URL to the metadata of the Immich album.

Another could be an insulated public facing Immich instance that gets publicly shared albums pushed to it, the same way as with the other scheme. No reverse access to the private Immich instance. Then if that gets hacked, only those photos leak, attacker can’t get their hands on other server data. Assuming it’s really well isolated. A public VPS would probably be best for this.

It is but it requires public internet access to the Immich instance, or everyone involved being on our VPN. Reusing someone else’s publicly facing service to share photos from a private Immich instance is a clever workaround.

Time to setup an arr stack.