vi/websocat

Websocat is a command-line utility for establishing and managing WebSocket and TCP connections. It provides extensive data transformation capabilities through overlays for encryption, JSON-RPC formatting, and length-prefixed framing. The system supports various authentication methods, flow control, and multi-client broadcasting, with official Docker support and cross-platform build configurations.

A new shell script, misc/prebuilt\_release\_settings.sh, has been introduced to configure build flags for various target platforms. It sets specific Cargo features (such as vendored OpenSSL, signal handlers, and compression) for architectures like i686, ARM, LoongArch64, and RISC-V, while skipping the build for wasm32-wasip1.

misc · high confidence

Websocat is now available as version 1.14.0, introducing official Docker container support via new Dockerfiles for Alpine and Debian builds. This release adds several new capabilities including SOCKS5 authentication, a \--ua\ shortcut for setting the User-Agent header, and a \drop\_on\_backpressure:\ overlay to handle flow control. It also prioritizes ping requests over normal traffic, adds \--basic-auth-file\ and \WEBSOCAT\_BASIC\_AUTH\ for basic authentication, and introduces the \lengthprefixed:\ overlay as an alternative to base64 mode. The project now includes comprehensive documentation in \doc.md\ and \moreexamples.md\, along with automated tests for help messages and functional behavior.

(repo-wide) · high confidence

Websocat adds several new specifier overlays that transform data or connection behavior. The \crypto:\ overlay (available with the \crypto\_peer\ feature) encrypts and decrypts messages using ChaCha20-Poly1305. The \foreachmsg:\ overlay executes a sub-specifier for each incoming message, useful for logging or state updates. The \jsonrpc:\ overlay converts simple text messages into JSON-RPC 2.0 format. The \lengthprefixed:\ overlay adds or removes length-prefixed framing from byte streams. Additionally, the \broadcast:\ overlay allows a single connection to serve multiple clients by duplicating replies to all of them.

src · high confidence

Added a new integration test suite (\tests/test.rs\) that validates websocat's ability to establish and transfer data over various connection types, including literal string assertions, TCP sockets, and WebSocket connections (both standard and low-level). The tests cover basic connectivity, persistence, and error handling scenarios using the \WebsocatConfiguration3\ API.

tests · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 53 → 59 (+6.2)
• Rubric changed (rubric-2026.09.9 → rubric-2026.09.17) — scores are not directly comparable.

• Code Health 82 → 82 (+0.0)
• Architecture 100 → 90 (-10.4)
• Maturity 55 → 55 (-0.7)
• Readiness 49 → 69 (+19.5)
• Security 43 → 53 (+9.5)

• Documentation: no installation or build instructions (README.md)

• Duplicate intent with different names. DropOnBackpressure and DropOnBackpressureWriter appear to be duplicates.
• Duplicate intent with different names. ExitOnSpecificByte and ExitOnSpecificByteReader appear to be duplicates.
• Duplicate intent with different names. Literal and LiteralPeer both appear to represent a peer that outputs a literal byte. The existence of both suggests either a legacy type (Literal) and a new one (LiteralPeer), or a confusion between the concept and the implementation. The module trivial_peer contains both Literal and LiteralPeer as well as Clogged and CloggedPeer.
• Duplicate intent with different names. Random and RandomReader likely represent the same functionality (generating random data). The suffix 'Reader' is redundant if the type itself is a Peer (which implies reading/writing).
• Inconsistent naming convention for file operations. 'ReadFile' and 'WriteFile' follow a Verb-Noun pattern, while 'AppendFile' uses a Verb-Noun pattern but semantically 'Append' is a mode of writing, not a distinct noun like 'Read'. More importantly, 'AppendFile' breaks the symmetry with 'WriteFile' if the intent is to represent file access modes. If these are distinct peer types, they should likely be unified or named consistently (e.g., FileRead, FileWrite, FileAppend or FilePeer with a mode enum).
• Inconsistent naming for WebSocket client connections. WsClient and WsClientSecure are named as nouns (the client itself), while WsConnect is named as a verb/action. If WsConnect is a peer type, it should be named WsClientPeer or similar to match WsClient. If WsClient is the high-level API and WsConnect is the low-level peer, the naming distinction is confusing without clear documentation, but structurally they look like overlapping concepts in the same module.
• Outdated: flate2
• Outdated: libc
• Outdated: log
• Outdated: native-tls
• Outdated: tempfile
• Poor naming convention for configuration stages. Using numeric suffixes (1, 2, 3) implies a temporal or sequential state that is not immediately obvious from the type name. It is unclear what distinguishes them other than the fields (addr1/addr2 vs s1/s2 vs Rc). This makes the API hard to use correctly without reading the source.
• Projects may be oversized for their cohesion

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

vi/websocat was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.