Round 12 review, finding 2 — filed as P2, and the interesting part is
that its author retracted it to P3 once we had measurements, while the
remedy it originally proposed would have been a fail-open.
The finding was that our validator rejects nesting `spa-json-dump -s`
accepts, and the suggested fix was a recursive sub-iterator walk to
match the dump tool. Both halves rest on the dump tool being the
reference. It is not. Nothing reads `PIPEWIRE_PROPS` or `PIPEWIRE_ALSA`
with `spa-json-dump`; `pw_properties_update_string` does, in the client
process.
Measured live on this host, against the real ALSA plugin:
depth 513 dump accept plugin accept ours accept
depth 514 dump accept plugin accept ours REJECT
depth 515 dump accept plugin REJECT ours reject
depth 1000 dump accept plugin REJECT ours reject
At 515 the plugin discards the whole object: the node came back as
`alsa_playback.aplay` with no properties at all. So matching the dump
tool would have made us splice carriers into values the consumer throws
away wholesale — losing both, which is the echo this feature exists to
prevent. Over-rejecting costs a routing preference; over-accepting costs
a carrier. Those are not the same price.
What was genuinely wrong is narrower: we sat exactly one level below the
consumer. `pw_properties_update_string` calls `spa_json_container_len`
on a container value, which enters one more sub-iterator before its flat
walk, and that single level is the entire discrepancy. Doing the same
puts the boundaries on the same number.
Codex reached the same three numbers independently by calling
`pw_properties_update_string_checked(NULL, ...)` directly, having
disassembled both call sites; I measured through the live plugin. Two
methods, one table.
The dump differential stays, but it is now labelled a *grammar* oracle
with a warning not to add deep values — it would fail by design. The
acceptance oracle is the new boundary test.
Mutation-verified: removing the container step fails the 514 assertion.
622 -> 623 lib tests, fmt clean, clippy clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
PeerSpeak
Decentralized, peer-to-peer voice chat — full-mesh, NAT-traversing, with no central server. Built in Rust on iroh (QUIC), PipeWire audio, the Opus codec, and an iced GUI.
Create a room, share the join ticket, and talk. Everyone connects directly to everyone else; relays are only used to punch through NATs when a direct path isn't available.
Screenshots
| Launch screen | In a room |
|---|---|
![]() |
![]() |
| Settings |
|---|
![]() |
Features
Rooms & sessions
- Create a room → shareable join ticket; join by pasting a ticket.
- Full-mesh multi-peer rooms with live presence.
- Recent-rooms list to hop back into a room someone's still in.
- Remembered nickname and in-call duration timer.
Audio
- PipeWire capture/playback, selectable input and output devices, per-app gain.
- Opus codec (48 kHz mono, 20 ms frames) with an adaptive jitter buffer + packet-loss concealment.
- Noise gate with a draggable threshold on a live mic meter (test your mic off-call too).
- Mix-bus soft limiter and opt-in echo cancellation (PipeWire WebRTC AEC + noise suppression).
Voice controls
- Self-mute, deafen, and rebindable push-to-talk.
- Per-peer volume, local mute, and speaking indicators.
Text chat
- In-room text chat over the gossip plane, with clickable links and inline image/audio attachments.
- Drag-selectable, copyable messages; right-click context menu on all text fields.
Shared music listening
- Build a personal playlist of local audio files with a full transport (play/pause, seek, reorder).
- Let others tune in: peers stream your current track, timeline-synced and gapless, sitting under voice at their own volume.
Screen share (via pixelpass)
- Share your screen; peers click 👁 Watch to open the stream in mpv (vlc fallback).
- Live badges on sharing peers; per-app audio capture.
Recording & notifications
- Local call recording (mic + incoming mix → WAV in
~/peerspeak-recordings/). - Desktop notifications and event chimes with per-event custom sound overrides.
UI & networking
- Selectable room layouts (3-Column, Bottom Dock, Drawer) with draggable, persisted dividers.
- 10 built-in themes (Catppuccin, Dracula, Nord, Tokyo Night, Gruvbox, Solarized…), all WCAG-AA checked.
- Network mode picker (relay-no-discovery default, full n0, or direct-only); retained-address reconnect.
- Config, window size/position, and all preferences persisted to
~/.config/peerspeak/.
See docs/FEATURES.md for the full inventory and field-test status, and docs/ARCHITECTURE.md for internals.
Roadmap
- Contacts & invites — friends list with invite-notification one-click join (design in
docs/contacts-plan.md). - Spatial audio & per-peer EQ.
- Soundboard — play short clips into the call mix.
- Room persistence / invite links beyond the raw ticket.
- Windows support — cross-compiles and launches under Wine today; needs a real WASAPI audio pass (see
docs/WINDOWS.md).
Building
PeerSpeak builds with a stable Rust toolchain (edition 2024). Install the system dependencies below, then:
cargo build --release
./target/release/peerspeak
System dependencies
Arch Linux
sudo pacman -S --needed rust pipewire opus pkgconf git
Debian / Ubuntu
sudo apt install build-essential pkg-config clang libclang-dev \
libpipewire-0.3-dev libopus-dev libasound2-dev libxcb1-dev
Plus a Rust toolchain via rustup. clang/libclang are needed for the PipeWire bindings (bindgen).
At runtime you need a running PipeWire server. Screen sharing additionally requires pixelpass on your PATH, and mpv (or vlc) to watch a peer's share.
Packaging
- Arch:
cd packaging && makepkg -si(usespackaging/PKGBUILD). - Debian/Ubuntu:
.debis built withcargo-debfrom the[package.metadata.deb]block inCargo.toml. Build inside a Debian/Ubuntu environment so the binary links that distro's glibc. - Windows: see
docs/WINDOWS.md.
License
PeerSpeak is licensed under the MIT License, © 2026 mollusk.
Third-party components bundled with PeerSpeak (the Rust dependency tree, the
statically bundled Opus codec on some builds, and embedded fonts) are all under
permissive licenses; their texts and a full dependency manifest are collected in
THIRD_PARTY_LICENSES.


