ZeroClaw drafts networked plugins with host grants and durable state

ZeroClaw's open plugin proposal would let sandboxed tool and channel components use more than HTTP while keeping connection authority with the host. It also retains encrypted per-instance state, a detail easy to miss if the change is reduced to sockets and TLS. The rebuilt proposal follows the project's newer egress model rather than simply porting an old stack. Its operator consequence is straightforward: more useful networked plugins, with explicit limits on what a destination grant and a TLS profile actually authorize.

The facts

- PR #11081 remains open and includes durable state as well as socket, WebSocket and TLS-profile work. - The proposed socket_client and websocket_client capabilities are linked only for instances holding the corresponding grants. - TLS profiles select trust material within the allowed destinations; they do not authorize an additional host. - Memory plugins receive no network surface, and the protocol does not give plugins ambient listening sockets. - Reported IRC and Nostr tests used local endpoints; the author explicitly excludes live public networks and real-plugin mTLS acceptance. - The state identity is tied to the admitted package, capability and binding, not to publisher provenance.

Why it matters

The design separates identity, encryption and reach. A private certificate authority can make a destination's certificate acceptable without making the destination authorized. An encrypted database can protect stored bytes without proving that a later package installed under the same instance identity should inherit them. Those distinctions matter when operators replace plugins or reduce access. The protocol keeps state across removal because upgrades use remove-and-install semantics; treating uninstall as a data purge would therefore be a dangerous assumption, not a documented safety property.

Current

This is branch-level capability work, not a released network surface. The detailed real-plugin results are tied to revision 8e7abad4c4; the later inspected head 0aa08823c8 changes WebSocket unit tests and reports their narrower rerun. The author distinguishes those revisions instead of presenting every earlier end-to-end result as newly repeated. The protocol document read here is pinned to that later head and must not be confused with the installed stable version's documentation.

Evidence

Primary: zeroclaw-labs/zeroclaw PR #11081 (https://github.com/zeroclaw-labs/zeroclaw/pull/11081). Supporting context: zeroclaw-labs — plugin-protocol.md (https://raw.githubusercontent.com/zeroclaw-labs/zeroclaw/0aa08823c8d87f148602166e6070f2ab4bf986a9/docs/book/src/developing/plugin-protocol.md); zeroclaw-labs/zeroclaw PR #11081 — implementation diff (https://github.com/zeroclaw-labs/zeroclaw/pull/11081/files). Source pages and available diffs were inspected; test and live-account results remain attributed to their authors, not independently repeated measurements.

Operator take

A pilot should test refusal as carefully as connection success: an ungranted host, a missing capability and a TLS profile outside the destination list should fail without granting useful reach. Also test what happens to a long-lived connection when an operator removes its host. The proposal authorizes each new connection but leaves an existing one open until it closes; instant revocation would require a different control. Before replacing a plugin package, review retained state and instance identity explicitly rather than relying on encryption to solve provenance or deletion.

Caveat

Local loopback tests and source review are not production network acceptance or an independent security audit. Grants are host-based rather than port-based, state survives removal, and database-write attackers remain outside the stated guest threat model. These are disclosed limits of the proposal, not guarantees this brief extends.