Problem
A phone and TV can reach the same Silo deployment through different addresses, such as a network plugin origin and the configured public URL. Clients currently compare URL-derived registry IDs, so they cannot reliably recognize that both addresses refer to the same server. Companion pairing sends the phone's saved URL, which may be unreachable from the TV.
Provide the server contract needed for clients to recognize the deployment across addresses and offer a usable connection during TV setup. This is follow-up work to #1096, related to #1001, #1169 and #1192; it does not expand SiloRemote beyond its same-LAN scope.
Source evidence
Source inspection, not a physical-device reproduction:
internal/apiv2/system.go: the discovery document reports build and contract information, not a stable deployment identity.internal/apiv2/network_access.go: authenticated capability discovery lists provider identifiers and display names. Provider origins are in the admin status API; it is not a client connection-discovery contract.- Apple
ServerRegistry and Android AndroidServerRegistry derive local registry IDs from normalized URLs. Both remote-only pickers filter using those IDs.
Required outcome
- Expose a stable native server identity shared by the deployment's supported addresses and API processes, surviving restarts and hostname changes. Define provisioning and restore/clone behavior.
- Define how a client verifies that an alternate endpoint belongs to the expected server before authorizing pairing or sending credentials. Matching display names or a self-asserted ID alone must not authorize a handoff.
- Expose only connection information appropriate for a signed-in client: configured API server addresses, provider identity/display name, and network requirements or setup help where supported. Keep enrollment URLs, node backend addresses, and admin status private.
- Let the TV test an offered endpoint and explicitly choose an available public address when plugin access fails. A public address may be absent; do not manufacture one or enable public exposure.
- Use additive
/api/v2 contract work and a capability for feature detection. Agree the endpoint and fields with both client implementations before coding; the public system-info document currently promises build-wide fixed content.
- Keep server identity separate from client credential-storage keys and preserve existing authorization/profile confirmation rules.
Validation and coordination
Verify the same deployment through public and plugin addresses, different deployments, unreachable/mismatched alternatives, absent public URL, restarts, and the supported API topology. A connected server plugin does not prove that a TV can reach it. Native Apple and Android need coordinated consumers; assess Jellyfin compatibility without changing its authentication contract as an incidental effect.
Client implementation follow-ups: Silo-Server/silo-apple#341 and Silo-Server/silo-android#352. Existing acceptance tasks remain #1170, #1193 and #1194; physical combinations belong to the linked client tasks under #1169 and #1192.
Rough server scope: M; this defines connection identity and discovery, not automatic mid-playback route switching.
AI disclosure
AI-assisted issue drafting and source inspection: gpt-6 in Codex through T3 Code, using GitHub CLI and the repository unslop skill. No implementation or physical-device acceptance is claimed. Independent review: n/a for this follow-up proposal.
Problem
A phone and TV can reach the same Silo deployment through different addresses, such as a network plugin origin and the configured public URL. Clients currently compare URL-derived registry IDs, so they cannot reliably recognize that both addresses refer to the same server. Companion pairing sends the phone's saved URL, which may be unreachable from the TV.
Provide the server contract needed for clients to recognize the deployment across addresses and offer a usable connection during TV setup. This is follow-up work to #1096, related to #1001, #1169 and #1192; it does not expand SiloRemote beyond its same-LAN scope.
Source evidence
Source inspection, not a physical-device reproduction:
internal/apiv2/system.go: the discovery document reports build and contract information, not a stable deployment identity.internal/apiv2/network_access.go: authenticated capability discovery lists provider identifiers and display names. Provider origins are in the admin status API; it is not a client connection-discovery contract.ServerRegistryand AndroidAndroidServerRegistryderive local registry IDs from normalized URLs. Both remote-only pickers filter using those IDs.Required outcome
/api/v2contract work and a capability for feature detection. Agree the endpoint and fields with both client implementations before coding; the public system-info document currently promises build-wide fixed content.Validation and coordination
Verify the same deployment through public and plugin addresses, different deployments, unreachable/mismatched alternatives, absent public URL, restarts, and the supported API topology. A connected server plugin does not prove that a TV can reach it. Native Apple and Android need coordinated consumers; assess Jellyfin compatibility without changing its authentication contract as an incidental effect.
Client implementation follow-ups: Silo-Server/silo-apple#341 and Silo-Server/silo-android#352. Existing acceptance tasks remain #1170, #1193 and #1194; physical combinations belong to the linked client tasks under #1169 and #1192.
Rough server scope: M; this defines connection identity and discovery, not automatic mid-playback route switching.
AI disclosure
AI-assisted issue drafting and source inspection: gpt-6 in Codex through T3 Code, using GitHub CLI and the repository unslop skill. No implementation or physical-device acceptance is claimed. Independent review: n/a for this follow-up proposal.