A Sovereign Mesh|sovereign, manifest-driven agentic runtime container that orchestrates DID Nostr Identity|DID Nostr agents across a decentralised Peer-to-Peer Network|peer-to-peer network, enabling autonomous agents to operate with verifiable credentials, pluggable adapters, and cont…
Semantic Classification
Content
VisionClaw is a sovereign agentic runtime designed for autonomous agent orchestration at the infrastructure layer. Unlike centralised AI agent platforms that depend on a single provider’s API, VisionClaw operates as a decentralised mesh where agents are peers, each with cryptographic identity and the ability to issue, verify, and exchange credentials independently.
Architectural Vision
The container is structured around four core principles:
-
Sovereignty: Each agent holds its own Schnorr keypair and operates under a did:nostr identity. No central authority controls keys or mediates communication.
-
Manifest-Driven: Agent behaviour is specified by a machine-readable manifest file—akin to a Kubernetes deployment or NixOS system declaration—allowing agents to be reproducible, auditable, and introspectable.
-
Federation Through Standards: State is emitted as JSON-LD 1.1 against pinned contexts. This enables semantic federation across heterogeneous agent systems, even when they don’t share code or trust anchors.
-
Content-Addressed Provenance: Every artefact produced by an agent (credentials, events, state snapshots) is given a canonical urn:visionclaw: URI computed from its content hash, enabling tamper detection and permanent referenceability.
Runtime Bootstrap and Lifecycle
VisionClaw agents start from an immutable bootstrap (ADR-006). A manifest declares the agent’s initial configuration: which adapters to load, which MCPs to trust, memory constraints, and security policies. On start, the runtime:
- Loads the manifest from a content-addressed source
- Verifies the manifest’s signature (if required)
- Initialises pluggable adapters for storage, memory, events, beads, and orchestration
- Contacts configured Nostr relays to discover peers
- Begins accepting work through the Agent Event Stream
The runtime is containerised: it runs in a sandbox with constrained resource access, mediated by the Adapter Slot architecture. This isolation boundary is non-negotiable, enforcing the principle that no agent can directly access the host filesystem or network without explicit adapter permission.
Operational Surfaces
VisionClaw exposes five standardised JSON-LD surfaces (see Federation Surface):
-
S1: Pod Index — listing available Solid pods and their permissions
-
S3: Verifiable Credentials — W3C VC 2.0 credentials with JCS canonicalisation for signature verification
-
S6: Agent Events — telemetry stream (birth, activity, termination) via WebSocket
-
S9: Memory Snapshots — periodic agent memory state encoded as JSON-LD
-
S11: Bead Catalogue — catalogue of work units (beads) and their completion status
Each surface is queryable, linkable, and introspectable. An external system can follow URIs to discover agent state, credentials, and work history without requiring direct access to the container.
Integration with Broader Ecosystems
VisionClaw is designed to interoperate with:
-
Blockchain: Agents can issue verifiable credentials that anchor to blockchain-backed DID registries, enabling on-chain verification of off-chain agent claims.
-
SPARC Methodology: The manifest and lifecycle integrate cleanly with SPARC task planning, mode switching, and adaptive orchestration.
-
Model Context Protocol: MCPs are declared as trusted consultation MCPs in the manifest, allowing agents to delegate reasoning to external LLM endpoints.
-
Solid Pod Storage: Agent state can be stored in Solid pods, respecting LDP conventions and enabling third-party tooling to query agent-emitted data.
Security and Privacy Model
All inter-agent communication is authenticated via did:nostr DIDs. Sensitive outputs are filtered through the PII redaction sidecar before emission. Credentials are signed using Schnorr signatures over JCS-canonicalised payloads, making attestation tamper-evident.
The adapter isolation boundary means that even if a malicious agent gains execution, its ability to exfiltrate data or modify state is constrained by the adapter’s permission model. An agent cannot change its own keypair, cannot forge credentials under another agent’s DID, and cannot bypass the Privacy Filter on outputs.