vrek: remote access stays on the VPN, no internet-facing video
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
parent
2667967cf0
commit
5886c010ea
@ -1113,3 +1113,5 @@
|
||||
{"id":"evt-teap5q282n28","type":"verification.recorded","subject":"ver-nah7fyr","actor":"prn-q80g8mz","actor_kind":"agent","session":null,"payload":{"result":"pass","evidence":"The config pointer now remembers binDir alongside dataDir, merging rather than overwriting; install-video calls rememberBinDir() and installs there; applyEnvironment feeds it back to later commands, with CAMERAS_BIN_DIR still winning. src/lib/first-run.test.ts covers remembering, keeping the data folder, and environment-over-remembered. Checked by hand: installed from /tmp/od5/here, then read back from /tmp/od5/elsewhere as /private/tmp/od5/here/bin."},"at":"2026-09-20T01:00:15.665Z","parents":["evt-ek7eke0zxksj"],"hash":"40a4b4122f6b2c48ed3ee8bf93ba9b5f4dda7e9c10fdf8526633ef1a4aef8e72"}
|
||||
{"id":"evt-fj77a4q216h5","type":"node.status_changed","subject":"iss-jwdt0pw","actor":"prn-q80g8mz","actor_kind":"agent","session":null,"payload":{"from":"open","to":"done"},"at":"2026-09-20T01:00:16.813Z","parents":["evt-teap5q282n28"],"hash":"73a72c267bdf0504d269e6380884aadd3d121f82ebd05365680e9f12d9001515"}
|
||||
{"id":"evt-954awzf35t82","type":"node.status_changed","subject":"iss-n8yz5cy","actor":"prn-q80g8mz","actor_kind":"agent","session":null,"payload":{"from":"open","to":"done"},"at":"2026-09-20T01:00:17.828Z","parents":["evt-fj77a4q216h5"],"hash":"98b76ddba2a716012a86e7b526e82dadd9f7b3af6f0b0351b0c60965af4a24c2"}
|
||||
{"id":"evt-rz1v74g035zs","type":"node.created","subject":"dec-s4pec5x","actor":"prn-q80g8mz","actor_kind":"agent","session":null,"payload":{"kind":"decision","title":"Remote access is over the user's VPN; no internet-facing video","body":"Asked and decided on 2026-09-20. Watching from outside the house goes over the VPN the user already runs, so the app stays a LAN service: no ports opened, no public URL, and nothing to change in the code. What was considered and rejected for now: forwarding UDP 8189 with webrtcAdditionalHosts set to a public name (lowest latency, but a second public entrance and it breaks where UDP is blocked); ICE over TCP through a stream proxy; serving HLS through our own session-checked routes, which needs no extra ports and would be the only option keeping video behind the admin login, at two to six seconds of latency; and a TURN server, which works nearly everywhere but is another service to run and secure. Worth remembering if this is ever revisited: with WebRTC as built, only the signaling is behind the admin session, while the media itself is reachable by anyone holding a session description, which is acceptable on a private network and would not be on a public one.","status":"recorded","owner":"prn-q80g8mz","attrs":{}},"at":"2026-09-20T01:21:16.094Z","parents":["evt-954awzf35t82"],"hash":"a9a3f359844d787da4eff3069660c1d3e196bdebf3d1a8dde62358f686fa1089"}
|
||||
{"id":"evt-xsejqxb5hpfy","type":"edge.added","subject":"dec-s4pec5x","actor":"prn-q80g8mz","actor_kind":"agent","session":null,"payload":{"kind":"serves","from":"dec-s4pec5x","to":"gol-9jctv92"},"at":"2026-09-20T01:21:16.097Z","parents":["evt-rz1v74g035zs"],"hash":"bd47d1b2e8ac5dce3947f39bdd1bd11cbf03889c9e9af87f06e2ed4dbf6fc934"}
|
||||
|
||||
Loading…
Reference in New Issue
Block a user