Files
wristivo/Adapters/TVTransport/MANUAL-PAIRING.md
T

3.3 KiB

Wristivo physical pairing and TLS feasibility spike

Status: owner run pending. This procedure is evidence collection, not a compatibility claim.

Record the exact iPhone model/iOS build, TV model from Settings and firmware/Tizen version, Wi-Fi topology, build commit, and whether a debugger is attached. The current QA85Q8FAAUXZN model report is unverified until the TV label and Settings are checked. Redact the TV address, pairing token, certificate details that identify the household, and client lists before saving evidence. Keep raw captures outside git.

Pair, deny and timeout

  1. Put the iPhone and TV on the same LAN. Keep the existing TV remote available and turn the TV on. Enter only the host name or address in the Wristivo setup screen.
  2. Grant Local Network access when the setup flow explains why it is needed. Start pairing explicitly. The candidate endpoint is TLS wss on port 8002; do not try port 8001 or a plaintext fallback.
  3. Confirm that the TV prompt/device list identifies the controller as Wristivo. Record the exact prompt text and firmware. Approve once, then issue one supported direction from the iPhone and record that a socket submission is only a transport receipt until the TV visibly responds.
  4. Repeat with Deny. Confirm the app enters a recoverable denied state and sends no command. Repeat with no TV approval until the 30-second pairing timeout; confirm it does not become ready.

TLS policy

First run with normal platform certificate and hostname validation. Record whether the TV presents a publicly trusted chain, a self-signed certificate, or another failure; capture only a redacted fingerprint and trust result. A failed trust check must remain failed. Do not install a global ATS exception or accept-all challenge handler.

If the device presents a self-signed certificate and a product experiment is still warranted, stop and obtain explicit user approval for that specific TV fingerprint. Only a stored, per-TV leaf SHA-256 pin may be tested with the scoped policy; a pin learned from the same unauthenticated first connection does not prove first-contact identity. A changed certificate must require reapproval/re-pairing.

Reconnect, revoke and lifecycle cases

After approval, terminate/relaunch the app and reboot the phone once. Verify a stored token reconnects without pairing, including the locked/first-unlock behavior that the chosen Keychain accessibility permits. Revoke the controller in the TV's device list, then reconnect: the app must become unauthorized, delete the rejected token, and ask for explicit pairing again. The app's Forget TV action must delete both token and trust record; removing the controller on the TV is a separate TV-menu action.

Run a TV-off case, a LAN interruption, a selected-TV switch, and a phone suspend/reopen. No command may be replayed or drained after reconnect. A command whose deadline expires while disconnected must be reported unavailable/expired and discarded.

Record every offered directional, Select, Back, Home, playback and volume key separately. Hide or disable any key without evidence. Do not test service-menu, factory, power or purchase actions. Do not mark this TV or any Samsung model compatible from a simulator, fake socket, unit test or successful WebSocket write alone.