v0.1.4 — roadmap link, three-engine CI

A demo-only release. The published package is unchanged — @le-space/libp2p-webrtc-qr@0.1.0 remains current on npm, and no file under packages/webrtc-qr was touched.

Live: https://webrtc-qr.le-space.de

The roadmap is reachable from the demo

Where the project is going was only visible from the repository — a step further than most visitors take. There is now a Roadmap link beside GitHub in the nav, and a plain text link in the footer.

Both nav links collapse to icons on phones, as the GitHub one already did.

An accessibility defect that collapse was hiding

display: none on the label removes it from the accessibility tree, not only from view. On a phone the GitHub link therefore had no accessible name at all — a screen reader announced an unlabelled link — and the new Roadmap link would have inherited exactly the same problem.

Both now carry an explicit aria-label, and the spec asserts that every nav link has one, so it cannot quietly regress the next time a link is added.

Firefox and WebKit run in CI

Both example suites now run on Chromium, Firefox and WebKit on every push, closing #10. The Playwright container CI already uses ships all three, so no install step was needed.

Nothing broke. CompressionStream, RTCPeerConnection and negotiated data channels behave the same in Firefox and WebKit as in Chromium, and the signed handshake, the chat protocol and the bitswap file transfer all pass unchanged. WebKit was the expected risk and handled the whole path, including the negotiated init data channel and the DataChannel muxer.

Two findings recorded rather than assumed:

• BarcodeDetector is exposed by none of the three Playwright builds, Chromium included. The jsQR fallback is the only path CI takes regardless of engine count.
• The camera path is still untested everywhere. Every automated test exchanges payloads by copy/paste or programmatically, so getUserMedia and live scanning are only verified by hand. More browsers did not close that gap, because it was never a browser-coverage gap.

The README used to list "Chromium only in CI" as the limitation. That line is replaced with the accurate one, so the document no longer implies coverage that does not exist.

Verified by hand

Reported by @NiKrause against the live demo:

• real camera scanning works in Chrome and Brave
• a phone on mobile data connects to a laptop on wifi — real ICE across separate networks, with STUN and no TURN server
• drag-and-drop of a real file transfers and downloads correctly

The mobile-to-wifi result is the significant one. It moves #11 (TURN) from "possibly necessary" to a convenience for edge cases.

Roadmap and issues

Every roadmap item now has a tracking issue, all labelled roadmap — the file keeps the reasoning, the issues carry the work. Added as item 8: multi-peer sessions and mesh bootstrapping (#14), including why a full mesh is the wrong target and why the replay window (#9) is a prerequisite rather than a refinement once signaling travels over the wire instead of across a camera.

Tests

60 tests: 18 unit, 36 browser end-to-end across three engines, 6 Helia.