YazSes XR — transport comparison (XR-R03) and threat review (XR-R04)¶

Status: PROPOSED, 2026-11-06. Documentation only, hardware-unverified, not reviewed by a maintainer. No XR code exists in YazSes and none is planned: the one implementation attempt, PR #732, was closed unmerged by the owner on 2026-11-02 (see section 0). Nothing here lifts or scopes the ADR-030 breadth freeze, amends ADR-019 or ADR-020, or chooses a transport. It records what each candidate transport would cost if the entry gate in ROADMAP.md ever opened, so that the decision memo (XR-R05) does not have to start from the 2026-05 capability card.

It builds on EVIDENCE.md (XR-R02, the platform documentation audit) and inherits its limits: no VRChat client, headset or XR runtime was run for this note either.

Method. Code is cited as path:line at commit 8a72bbc6 (main, 2026-11-06). Platform facts come from EVIDENCE.md, which cites its primary sources with URLs and read dates; the one external standard cited directly (RFC 6455) was re-read on 2026-11-06 at its URL, and one general protocol fact from prior knowledge is labelled where used. Anything phrased "should" or "must" in sections 3 and 4 is a proposal for XR-R05, not a decision.

0. What changed since the evidence log¶

1. The five candidates¶

The task in TASKS.md names three transports. Two more are added because a decision memo that omitted them would be incomplete: the one YazSes already has (keystroke injection), and the local IPC socket that already exists.

• T0 — no new transport. The user dictates with ordinary YazSes into whatever window has focus, as today. For VRChat on a desktop this would mean typing into the client's own text field or keyboard. Whether VRChat's keyboard accepts injected keystrokes was not tested and is unknown.
• T1 — in-process callbacks. A Python function registered inside the daemon receives the final transcript.
• T2 — OSC over UDP to 127.0.0.1:9000. One datagram per draft to VRChat's documented input port, /chatbox/input with b = false (EVIDENCE.md section 1).
• T3 — loopback WebSocket server. The 2026-05 card's design: a listener on localhost:8765 streaming JSON events to any local client.
• T4 — a scoped method on the existing IPC socket. The daemon's JSON-RPC over AF_UNIX, created owner-only (src/yazses/ipc/server.py:74-87).

2. Comparison (XR-R03)¶

What the comparison suggests (proposal for XR-R05, not a decision)¶

1. Try T0 first, as evidence, not code. If dictating into VRChat's own text field already works on a real PC client, the case for any new transport weakens sharply, and XR-R01 should ask what T0 fails to do before asking for a bridge. This needs an owner-run test on a real client; it was not done.
2. T1 is the only option compatible with today's ADRs that needs no amendment, and it reaches only a mock. That matches ROADMAP P0 and ARCHITECTURE.md line 41.
3. T2 is the narrowest path to VRChat, and its cost is governance rather than code: a third SEND under ADR-019. If ever proposed, the destination should be a hard-coded loopback literal, refusing VRChat's --osc= remote-IP form, by the same reasoning as is_loopback_endpoint() (tests/test_egress_inventory.py:407-425).
4. T3 is the most expensive option on every row: a new dependency, a listener, a browser-reachable surface, an ADR-019 amendment and an ADR-020 supersession. The card's own justification (several engines and WebXR) has no evidenced consumer today. It should not be the default answer to "which transport".
5. T4 before T3 for native multi-consumer use, but only after the IPC gains per-client scopes. Granting an XR app the socket today grants it injection and every other method.

3. Threat review (XR-R04)¶

Assets¶

Trust boundaries¶

• B1, daemon to local consumer. T1 has none (same process). T2 crosses to whoever holds port 9000, unauthenticated. T3 crosses to every connected client, including browser pages. T4 crosses to same-user processes.
• B2, consumer to shared world. The real external action. Once VRChat publishes a chatbox message, other participants have seen it. No transport can make this reversible, so the only control is that the publish is the user's own act in the host app.
• B3, this machine to another device (a standalone headset, a second PC). Out of scope for every option here; it is a separate, authenticated-transport design (DECISIONS.md D7).

Threats and proposed mitigations¶

Revocation, per transport¶

Revocation must take effect before the next send, and it cannot recall what was already published (B2).

• T1: unregister the callback; the next transcript reaches no consumer.
• T2: turning the feature off must stop the next datagram. There is no session to end. Text already sent stays in the world.
• T3: invalidate the token, close every open session, stop the listener when the last permission is removed.
• T4: today there is nothing finer than the socket's file permission, so per-client revocation does not exist and would have to be built with the scopes in X5.

External-action policy (proposal)¶

These rules would bind any future adapter. They are written as testable statements on purpose, and per ADR-021 they add no new YazSes prompt: the confirmation is the host application's own send control, so there is no guard to learn to dismiss.

1. YazSes never sends. For VRChat it emits /chatbox/input with b = false only. No config key, CLI flag, voice command or IPC parameter can produce b = true, and a negative test checks the emitted bytes on every code path.
2. Draft, sent and delivered are three different states, and the user is never told "delivered" (OSC cannot confirm it).
3. One reviewed draft, at most one prefill. No automatic retry.
4. Avatar actions follow the same rule as text: allowlisted, explicit, and nothing on a guess.
5. Off means off mid-flight: pause or disable stops the next send, including one already queued.
6. The destination is a loopback literal. A remote IP, a hostname, or VRChat's --osc= form is refused, not honoured.
7. Only the user's own reviewed text leaves. Never audio, the corpus, voiceprints, recall results or another speaker's words (ADR-019 §3).
8. The text is never logged.

4. Status of the tasks this note serves¶

ADR-030 freeze: unchanged. No transport is chosen, no ADR is amended, and no feature-registry entry, config key or source change is proposed by this file.