Please check the build logs for more information.
See Builds for ideas on how to fix a failed build, or Metadata for how to configure docs.rs builds.
If you believe this is docs.rs' fault, open an issue.
Tear WebSocket bridge — turns the typed CBOR wire that
tear-daemon speaks (over UDS or TCP) into a ws:// endpoint
that browsers / wasm renderers can attach to without speaking
UDS / TCP directly.
Wire
Each WebSocket binary message is a single length-prefixed CBOR
frame — the same shape tear-types::wire::write_msg produces
and read_msg consumes. A browser-side client just needs to
length-prefix its CBOR Requests in WS binary frames and decode
Responses the same way. No protocol translation.
Architecture
For each incoming WS connection the bridge opens a fresh
connection to the local tear-daemon (via [tear_client::Transport])
and pipes bytes both directions. Reader threads on each side
shuttle frames; the bridge itself is mostly a pair of byte
pumps with one small framing concern: the WS layer is
message-framed (one binary message = one frame), while the
UDS/TCP wire is stream-of-bytes with embedded length prefixes.
The bridge re-frames in both directions.
Why a separate crate
tear-daemon deliberately doesn't pull in tungstenite —
daemon footprint stays tight; WS is an opt-in surface
operators activate when they want browser/wasm access. The
bridge runs as a sidecar daemon, gating the WS port through
its own systemd unit / launchd plist so it can be enabled or
disabled independently.