[Feature] Add an instance parameter to my.immich.app deep links, and make the link type selectable when sharing

[towerplease]

I have searched the existing feature requests, both open and closed, to make sure this is not a duplicate request.

• Yes

The feature

The feature

Two related changes that would make album links work the way people expect when they send them to others:

1. Allow an instance hint on my.immich.app links, e.g.
   https://my.immich.app/albums/<uuid>?instance=https://photos.example.com
2. When sharing an album (web and mobile), let the user choose which kind of
   link is copied: the direct instance URL (current behaviour, default) or the
   my.immich.app deep link.

Why

Today a my.immich.app/albums/<uuid> link is the only way to open an album in
the app instead of the browser. It works well — but only under a condition the
sender cannot see: the recipient must be signed in to that specific instance.

That leads to a link that is worse than the plain URL when the condition isn't
met. Because the deep link carries no information about which server it refers
to, the app resolves the UUID against whatever instance the user happens to be
signed in to. If that's a different instance — or none — _buildAlbumDeepLink
returns null and the app silently opens on the home screen. The OS has
already intercepted the link at that point, so there is no fallback to the
browser either.

The result is that anyone sharing with a mixed group (some with an account on
my server, some without) has to pick one link and accept that it breaks for
half the recipients. The web fallback on my.immich.app has the same gap from
the other side: it asks the visitor for an instance URL that they usually
don't know.

Passing the instance in the link closes both gaps with information the sender
already has.

Proposed behaviour

Recipient state	Today	With ?instance=
App installed, signed in to that instance	Opens album ✅	Opens album ✅
App installed, signed in elsewhere	Lands on home screen, no explanation	App detects the mismatch and opens the instance URL in the browser
App installed, not signed in	Lands on home screen	Browser fallback, or a prompt to sign in to that instance
No app	my.immich.app asks for an instance URL	Redirects straight to the album

The parameter is a hint, not a trust boundary: authorization is unchanged and
still enforced server-side by the target instance. A link only works for
someone who has been granted access to the album, exactly as today.

Part 2: choosing the link type when sharing

The deep link should not become the default, and existing behaviour should not
change. Plenty of setups are reachable only over LAN IP or a VPN hostname,
where a my.immich.app link is useless or actively misleading.

Suggested handling:

• Keep the direct instance URL as the default everywhere.
• Offer the my.immich.app variant as an explicit second option in the share
  dialog / share sheet (e.g. "Copy link" vs "Copy app link").
• Only offer it when a publicly resolvable address is available — for example
  when External Domain is configured — and use that value for the
  instance parameter rather than whatever host the client happens to be
  talking to.
• Optionally a per-user preference for which one is offered first.

This matters most on mobile, where there is no URL to edit: the share sheet
hands off immediately, so today the only way to produce a deep link on a phone
is to copy the URL, paste it somewhere editable and rewrite the host by hand.

Implementation notes

The pieces already exist and the change looks small:

• mobile/android/app/src/main/AndroidManifest.xml matches on
  pathPrefix="/albums/", so query parameters need no manifest change. Same for
  applinks:my.immich.app in Runner.entitlements.
• DeepLinkService.handleMyImmichApp currently parses only the path
  (mobile/lib/services/deep_link.service.dart). It would read the parameter,
  compare it against the active session's server URL, and on mismatch launch
  the browser with the reconstructed instance URL instead of returning null.
• The my.immich.app proxy would prefer the parameter over the locally stored
  instance URL.
• Links without the parameter keep working exactly as they do now.

Naturally the same applies to the other deep-linkable paths (/photos/,
/people/, /memory), not just albums.

What this is not

This is not federation and not multi-server switching. Nothing is shared or
synced between instances, and the app still has exactly one active session. The
link merely states which server it refers to, so the app can tell whether it
can handle it and degrade gracefully when it

Platform

• Server
• Web
• Mobile

[bo0tzz]

my.immich.app already supports the instanceUrl parameter. Making that an option when generating a shared link is reasonable, but the choice might not be intuitive and making it the default has privacy implications. It also would break things like link previews, would make the QR codes bigger/denser, etc, so it's not a simple choice.

Ultimately though, I think we should track this as a duplicate of #2327. The core ask aligns closely, and in practice much of the work would end up overlapping.