feat(web): PR 2 - Relay

[paul-nechifor]

• Added the code for an initial relay, which handles connections from the robot (DimOS) and the frontend (cockpit).
• This is just a start. I definitely want to break up web/relay/server.ts into smaller more cohesive parts.
• Added a cockpit stub in a single file: web/relay/static/debug.html. This will be replaced.

[greptile-apps]

Greptile Summary

This PR adds the initial WebTransport relay. The main changes are:

• Relay startup, HTTP endpoints, and WebTransport sessions.
• Robot-to-viewer forwarding with delivery policies.
• Ephemeral certificate generation and loopback tests.
• A browser-based relay debug page.

Confidence Score: 4/5

This should be fixed before merging.

• Any reachable client can become a viewer and receive forwarded robot data.
• The forwarding, certificate, and loopback test paths otherwise cover the main relay flow.

web/relay/server.ts

Security Review

A reachable relay can register an unauthenticated WebTransport client as a viewer and send it all forwarded robot data.

Important Files Changed

Filename	Overview
web/relay/server.ts	Adds relay startup, session routing, HTTP APIs, and robot/viewer handling; viewer admission lacks an authorization check.
web/relay/forward.ts	Adds frame parsing and per-viewer forwarding policies for reliable and latest-wins channels.
web/relay/cert.ts	Adds short-lived self-signed certificate generation and a certificate hash for local WebTransport clients.
web/relay/static/debug.html	Adds a browser diagnostic page for connecting to the relay and displaying forwarded data.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
  R[Robot] -->|WebTransport frames| Relay[Relay]
  Relay -->|Forwarded frames| V[Viewer]
  D[Debug page] -->|HTTP API info| Relay
  D -->|WebTransport viewer session| Relay

Loading

_{Reviews (4): Last reviewed commit: "feat(web): WebTransport relay server (De..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

@@            Coverage Diff             @@
##             main    #3043      +/-   ##
==========================================
+ Coverage   73.33%   73.43%   +0.10%     
==========================================
  Files        1044     1050       +6     
  Lines       94523    94939     +416     
  Branches     8550     8702     +152     
==========================================
+ Hits        69319    69721     +402     
+ Misses      22854    22839      -15     
- Partials     2350     2379      +29     

Flag	Coverage Δ
OS-ubuntu-24.04-arm	66.34% <ø> (+0.14%)	⬆️
OS-ubuntu-latest	68.89% <ø> (+0.13%)	⬆️
Py-3.10	68.88% <ø> (+0.12%)	⬆️
Py-3.11	68.88% <ø> (+0.13%)	⬆️
Py-3.12	68.89% <ø> (+0.13%)	⬆️
Py-3.13	68.88% <ø> (+0.13%)	⬆️
Py-3.14	68.88% <ø> (+0.13%)	⬆️
Py-3.14t	68.88% <ø> (+0.13%)	⬆️
SelfHosted-Large	30.08% <ø> (+0.02%)	⬆️
SelfHosted-Linux	37.03% <ø> (-0.05%)	⬇️
SelfHosted-macOS	35.95% <ø> (-0.04%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.
see 26 files with indirect coverage changes

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Dreamsorcerer]

This is perfect example of where we could have used a stacked PR.

[leshy]

Code looks clean in both PRs (#3044) but just to understand the architectural approach - why do we have (zenoh) -> python -> (webtransport) -> deno -> (webtransport) -> clients

why not either connect deno directly to zenoh (idk if possible) or serve clients directly from python? (hoping to get rid of the middle guy)

[leshy]

had an arch chat in private