explore-truchet #1

Open
solene wants to merge 10 commits from explore-truchet into main
Owner
No description provided.
Exploration of a screen -> camera alternative to the audio channel,
reusing the fountain code, packets and convolutional code. The goal is
a picture that looks pleasant and never flashes, unlike animated QR
codes.

Each frame carries one packet (rate 2/3) as the orientation of the
tiles of a 56x34 Truchet grid, with bullseye markers in the corners
for alignment. A changing bit turns its tile a quarter turn. Rotation
keeps the light inside each tile, and all strokes share one luminance,
so no area flashes; a new invariant and its test (no_flash) guard
this, as nothing_audible does for the audio band.

`airgap truchet render|svg|sim` draws PNG pictures, writes the
animation as one SVG file, or films it with a simulated camera
(perspective, blur, noise, exposure, white balance) and decodes it.
Simulation only: never tried with a real camera. Not part of the
audio on-air protocol, which is unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The maintainer asked for a browser version of the Truchet channel, so
that a computer screen can show a file and a phone camera receive it.

visual.html draws the tiles with canvas arcs (truchet.js, same geometry
and timing as src/truchet.rs), full screen where allowed, and decodes
back-camera pictures (getUserMedia, scaled to at most 1280 px wide)
with the wasm module, which gains WebVtx/WebVrx and vis_*/vtx_*/vrx_*
exports. Picture sizes are bounded before any allocation.

The Node test draws frames with truchet.js on a fake canvas that
records and rasterizes the arcs, then decodes them with the wasm
receiver: this checks the JS geometry without a browser. The page
itself has not been run in a browser yet.

nginx now allows the camera for the site's own origin; the Containerfile
copies the new files and stamp.sh stamps both pages. The audio protocol
is unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Plain `cargo test` at the root only tests the root package (the
workspace has no default-members), so the airgap-web tests were not
run by the documented command. The Containerfile already uses
--workspace.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On an iPhone, "Start the camera" on a page served over plain http
failed with "undefined is not an object (evaluating
navigator.mediaDevices.getUserMedia)": browsers only expose
navigator.mediaDevices on secure pages. The audio page had the same
problem with the microphone.

mediaProblem() in airgap.js now says what is wrong (insecure page and
its protocol, or no media access at all). Both pages show it in the
banner and when the start button is pressed, instead of throwing. The
Node test covers the three cases.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The maintainer found the visual channel pretty but slow (128 B/s) and
asked for more speed and color, as options.

Pace: 1 to 4 frames per second. Turn and wave keep the same share of
each period, so faster means brisker turns, never brighter ones.

Color mode: each tile is also teal or pink, carrying a second packet
(its own interleaver and filling) next to the one in the orientations.
The two colors have the same luminance and fade in linear light, so the
no-flash invariant holds; no_flash now also checks the fastest pace and
the color mode. They lie on the green-magenta axis, across the
blue-amber axis of white balance errors, and the decoder subtracts the
median of that opponent channel. If colors are not read, the
orientation packet still is: the transfer just runs at plain speed.

In simulation (now with chroma at lower resolution and saturation, as
in phone video), 4 frames/s with colors rebuilds a 3 KB file at about
1 KB/s, against 135 B/s before.

The CLI (`--period`, `--color`) and the web page announce the speed and
the expected transfer time before sending; the page also counts down
while showing. Receivers need no setting. Not tried with a real camera
yet. The audio protocol is unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The maintainer asked how much slower the Truchet channel is than
libcimbar, and to mention that project on the web page.

libcimbar announces about 106 KB/s from a monitor to a phone camera;
the visual channel reaches about 1 KB/s at its fastest in simulation,
about 100 times less. The docs compare the two from libcimbar's own
documentation (tiles, bits per tile, bytes per picture) and explain
where the gap comes from: picture content and pace, both limited here
by the calm, flash-free design. The page links to it for users who
need speed rather than calm.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The maintainer reported on 2026-11-02 that an iPhone received a file
through the web page at the fastest pace (4 frames/s) with colors. The
status in AGENTS.md, the docs and the page said "simulation only".

Only what was reported is recorded: the sending screen, file size,
transfer time and checksum comparison are not known, and every
measured number in the docs still comes from simulation.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The maintainer plans to merge the visual channel, so it is no longer an
experiment. The docs, pages, CLI help, code comments and package
descriptions now present airgap as two channels, sound and screen to
camera, over the same fountain code.

AGENTS.md freezes the screen frame format as "screen protocol version
1" (grid, markers, tile bit mapping, code rate, seeds, colors, packet
numbering), with the same rule as the sound protocol; animation timing
and decorative colors stay free. SECURITY.md covers line-of-sight
receivers, camera pictures as untrusted input, and treats a flashing
pattern like a security bug. README gains the screen channel's usage,
speeds, camera tips and frame format.

No code behaviour changes; the audio protocol is unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The maintainer reports that the screen-to-camera channel was validated
on many devices by the maintainer and friends, the fastest pace with
colors included, not only on one iPhone. AGENTS.md, the visual channel
doc and the web README said "one iPhone so far".

The devices were not listed, so none are named. The speeds and limits
in the docs stay labelled as simulation measurements.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The maintainer describes airgap as a teaching project: sending a file
through ultrasound or a screen is rarely the practical choice, but it
shows a fountain code at work, which is what makes it interesting.

- docs/fountain-code.md: the problem (one-way, lossy, late
  receivers), the idea, how src/fountain.rs builds and decodes packets
  with a worked K=3 example, the K + 1.6 overhead, experiments to try
  (`airgap sim --drop 0.5 --skip 20` rebuilds 24 blocks from 24 packets
  out of 71 sent), and how LT, Raptor and RaptorQ go further.
- README opens with the data fountain and a "Why a data fountain?"
  section; both web pages say they are built on one and explain it in
  a "What is a data fountain?" box.
- AGENTS.md records the teaching goal and keeps the in-tree fountain
  code readable on purpose (no swap for a crate).

Documentation and page text only.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This pull request can be merged automatically.
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin 'explore-truchet:explore-truchet'
git switch 'explore-truchet'
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
public/data-fountain-over-audio!1
No description provided.