AAA
01821ae7ac
Public invitations could stop after an early tunnel-process exit, and connection progress and Viewer status did not consistently describe the current attempt or Host state. This maintenance release adds bounded startup retries, aligns enhanced NAT retry feedback across entry paths, and fixes camera-preview and room-entry layout. The existing route owner and published contracts remain in place. Four-attempt progress is advertised and opted into; older readers retain supported messages. Interaction/chat experiments are outside this PR. Validation: npm run check (74 files, 1072 tests and production build), npm run check:go (including Windows capture compile), documentation/repository hygiene, 10 production Viewer-entry discovery cases, and a real public-link gate with remote HTTP/WebSocket access and shutdown cleanup all passed. Existing device/network evidence limits remain documented. ## Release notes ### 中文 这是一次维护更新，重点改善公网邀请启动、连接重试反馈和分享状态提示，并修正两处界面布局问题。 - 公网邀请服务在连接就绪前意外退出时，会自动重试，最多重试 3 次；所有尝试仍共用 30 秒启动预算。 - 增强穿透连接在首次尝试失败后最多重试 3 次，重试进度显示为 1/3、2/3、3/3。邀请链接和房间号加入都支持新版进度提示。 - 修正观众状态提示：房主离线时不再误报“没有可用的媒体线路”，服务器连接恢复与媒体恢复也会分别呈现。 - 修正电视内房间号输入界面的居中位置，以及摄像头选择预览被裁切的问题。 - 尚未确认来源声音状态时，不再提前提示“未分享来源声音”。 本次保持现有版本兼容；新版重试进度需要页面与服务端均支持。额外重试不能保证所有网络都能直连。 ### English This maintenance update improves public invitation startup, connection retry feedback, and sharing status messages, with two layout fixes. - If the public invitation service exits before connecting, Piik retries up to three times within the existing shared 30-second startup budget. - Enhanced NAT traversal now allows up to three retries after the initial attempt, shown as 1/3, 2/3, and 3/3. Both invitation links and room-code entry support the updated progress display. - Viewer status now distinguishes an offline host from an unavailable media route, and reports server reconnection separately from media recovery. - Fixed the alignment of room-code entry inside the TV and cropping in camera-selection previews. - The missing-source-audio notice now waits until the source's audio availability is known. Existing version compatibility is preserved. Updated retry progress requires support from both the page and server. Additional retries cannot guarantee a direct connection on every network.
6.5 KiB
Current Status
Last updated: 2026-09-22
This is the compact execution/deployment index. Product modules own behavior, verification status owns unresolved physical limits, and Git/PRs own completed history.
Accepted Release Contract
- Browser/server v23, Native control v9 and capture v7 form the current contract. Versioning owns compatibility between published Web/App/Server versions.
- Hosted Server defaults to SQLite schema 2. Room authority has no inactivity expiry; explicit replacement/deletion or grant rotation/revocation ends the corresponding authority. Explicit memory mode and App Local end rooms at process exit. Site access retains its separate 24-hour idle lifetime.
- Browser/App entry lifecycle and current-edge reconnect ownership repairs are implemented. Browser node-local pooling and detailed local Debug export remain part of the accepted media surface. Product modules own their behavior; configuration owns Debug activation, report contents and disclosure.
- Shared feedback composition is implemented: generic loading uses the wink mascot, concrete media waits use their owning comic, and waiting captions are secondary to literal status. Website reduced-motion preference and player tooltip placement follow the same presentation owners.
- Camera sharing and Host microphone commentary are accepted product features. Both Browser and native App audio use the existing media routes; device selection and sharing settings keep their current resource owners. The capture assessment owns platform behavior and the remaining physical evidence limits.
Website delivery includes a bilingual reader documentation center generated from the repository's guides alongside the homepage, with search and detailed troubleshooting separate from the homepage FAQ.
Deployment
Source, package identity, GitHub repository and local worktree paths use Piik.
Runtime code keeps only the Piik wire labels and stored keys.
The immutable release descriptor, runtime REVISION and operator deployment
record own exact identity and postflight results.
The existing deployment uses one Go process for Web, room authority/signaling, Binding-only STUN on UDP 3478/3479/3480 and optional SFU on UDP 7882. nginx owns HTTPS; external LiveKit/coturn services remain disabled. Participants, routes and media remain process-only. This private service is not a public demonstration.
The separate US public demo is deployed with open site entry, persistent room authority and P2P-only media. Cloudflare fronts HTTP/WSS and caches static bundles; STUN uses a separate DNS-only hostname. Caddy owns origin HTTPS, and the standard systemd service runs the published Server package. Public DNS, HTTPS, runtime assets, all three STUN listeners and a bounded browser P2P sharing/stop check passed; the browser check used synthetic video on one network. The operator record owns exact identity and postflight evidence.
TODO owns remaining verification and follow-up work. The owner declared the first
public release on 2026-09-12. Source is public, main protection is active, and
piik.tv runs on GitHub Pages behind Cloudflare with HTTPS. The private service
remains a separate deployment. Release descriptors and GitHub deployment records
identify published artifacts and website revisions.
The matching Server and three App packages are published on GitHub and Gitee; anonymous mirror downloads match the original checksums. Public-repository CI and native packaging passed. App entry, update links and bounded two-build interoperability have acceptance evidence. Accepted product changes publish automatically; standalone website and documentation changes validate and deploy the website without creating App/Server versions. GitHub/Gitee release comparison, mirror publishing and PR-sourced notes follow versioning. Verification status owns the remaining physical limits; shared lessons live in engineering.
Media Evidence And Limits
- Compatible Native consumers share one complete stock WebRTC encoding and adaptation pipeline per local output. Different weak demands stay independent; suitable received media can be forwarded without decoding/re-encoding. Pion/LiveKit retain transport, estimation, pacing and forwarding ownership.
- Windows H264/VP8 have bounded encoding/adaptation evidence. Actual Native relay checks cover compatible sharing, weak-budget separation and rejoining, source retirement and large encoded-frame delivery. These results do not establish a universal encoder count, CPU saving or Browser-equivalent quality.
- Windows Host acceptance covers live and paused settings, quiet-source preparation/restore, source changes and subsequent sharing. The owner confirmed Windows 10 whole-display capture resolved. Specific new game/device failures should be reopened from new evidence.
- Native Host publication through embedded SFU retains video/audio; Browser to App fanout and App-exit fallback have bounded physical checks. Two independent Native sessions have simultaneous media/retirement evidence.
- The Linux runtime container has non-root/read-only, memory/SQLite, diagnostic export, STUN and listener-lifecycle evidence. This does not establish every operator's proxy/firewall or public-media configuration.
- The independent Browser producer in ADR-0014 is integrated. Bounded H264/VP8 checks cover direct and received-track sharing, weak-child isolation/recovery, live/quiet settings, pause, source change and ordinary fallback. Its native allocation and complete-frame output replace the earlier payload-only Worker path. Fewer full encodes are established; total CPU gains depend on codec/hardware. Browser research owns these measurements and failed controls. The owner accepted this scoped Browser composition for release; actual deployment identity stays in the runtime descriptor.
- Slow adaptation recovery, the extreme CPU-overload sampling limit and missing broad device/network/endurance results remain explicit in encoder research and verification status. macOS/Linux physical capture is deferred by the owner; Windows App and Browser are this phase's primary targets.