cstream

Version	2026.243.1053
Repo	box/github.com/opencharly/pod-cstream:v2026.243.1805

The cstream transport spine: the Wayland parent that IS the streamer, the browser-facing gateway, the PAM login broker, and the gates that prove the stack is actually STREAMING rather than merely started.

Three of those gates exist because the obvious checks are not evidence. A service check proves a process is up; measured, charly’s own service: verb even reports PASS for a supervisord program parked in FATAL (opencharly/charly#456). A grim screenshot proves the compositor draws, but says nothing about whether the encoder and transport carry those pixels. And “the frame is not uniform” passes on a wallpaper, so a frozen pipeline serving one static frame forever satisfies it.

So the streaming gate compares frames pulled THROUGH the pipeline before and after a real client window maps: a dead, frozen or placeholder pipeline yields identical frames and fails. The encoder gate fails when a VA-capable node is present but hardware encode is not actually producing H.264 – the spec’s named silent fallback to CPU.

Packages

Installed on every distro:

• go
• rust
• git
• pam
• shadow
• socat
• foot
• ttf-dejavu
• gst-plugins-good
• gst-plugin-rswebrtc
• gst-plugins-bad
• gst-plugin-pipewire

Services

• cstream-parent
• cstream-gateway

Acceptance plan

This candy’s plan: — the runnable spec charly check executes against a live deployment. check: steps are idempotent probes; run: steps change state.

Intent	Step
run	build the gateway and the session leader from the pinned streamer
run	stage the Wayland parent
run	stage the streaming gate probes
run	stage the encoder probe
run	stage the cstream audio endpoints
run	stage the login probe the bed drives
run	stage the frame probe that pulls back through the WebRTC track
run	stage the streamer’s own PAM service
run	stage the cstream session target
check	the cstream audio endpoints EXIST as live PipeWire nodes
check	the streamer captures the speaker’s MONITOR, not its input
check	the gateway binary is installed
check	the session leader is installed
check	the streamer is installed
check	the installed streamer carries the WP5 lock path, so the pin bump really took
check	webrtcsink is present – the ONLY element that can carry the stream
check	webrtcbin is present – webrtcsink builds one PER SESSION and is inert without it
check	pipewiresrc is present – the streamer ABORTS at startup without it
check	WP4 the control socket applies a resize and REPORTS what it applied
check	WP4 the nested compositor really reconfigured to the applied size
check	WP4 a second distinct size applies, so the first was not a coincidence
check	WP4 the compositor followed the second resize down
check	the streamer has its OWN PAM service, not a borrowed login stack
check	the streaming probes are installed