Clawdentity: Universal Rust CLI for Cross-Platform Agent Identity & Messaging

[vrknetha]

Summary

Rust CLI for Clawdentity — a single, framework-agnostic binary that any agent platform can use via exec(). One CLI replaces platform-specific SDKs, MCP servers, and language-specific connectors.

Repo: vrknetha/clawdentity | Branch: feat/rust-cli | PR: #180

Rust CLI Status

All 10 phases complete. 56 tests passing, ~9,800 lines of Rust.

Phase	Module	Status
1	Workspace scaffold + config routing	✅
2	Identity, DID, signing, registry, agent	✅
3	SQLite persistence (5 tables)	✅
4	Connector runtime (WebSocket relay, HTTP server)	✅
5	Pairing + Trust + QR	✅
6	Verify + CRL cache	✅
7	API keys, invites, admin	✅
8	Service management (launchd/systemd)	✅
9	Diagnostics (doctor, setup, relay test)	✅
10	CLI commands + hardening	✅

Cross-Platform Webhook Support

Adding generic bidirectional webhook channel to all 4 agent platforms. Each platform gets the same two-route HTTP server following OpenClaw's existing connector pattern.

Platform Support Matrix

Platform	Language	Webhook PR	Status	Install Provider
OpenClaw	TypeScript	Native	✅ Built-in	openclaw
PicoClaw	Go	sipeed/picoclaw#626	✅ PR Open	picoclaw
NanoBot	Python	HKUDS/nanobot#985	✅ PR Open	nanobot
NanoClaw (qwibitai)	Claude Code	qwibitai/nanoclaw#377	✅ PR Open	nanoclaw-qwibitai

Bidirectional Webhook Contract (all platforms)

Same HTTP server, same port, two routes. Follows OpenClaw's existing connector pattern — no exec/shell calls for sending.

Inbound (relay → platform):

POST /v1/inbound
Headers: x-webhook-sender-id, x-webhook-chat-id, x-webhook-token (optional)
Body: { "content": "...", ...relay payload }
Response: 202 Accepted → published to platform message bus

Outbound (platform → relay via connector):

POST /v1/outbound
Body: { "to": "<did>", "content": "<message>", "peer": "<alias>" }
Response: 202 Accepted → forwards to connector at http://127.0.0.1:19400/v1/outbound

Security Defaults

• Binds to 127.0.0.1 (loopback only)
• Optional token auth via x-webhook-token header
• Optional sender allowlist (allow_from)
• Connector URL configurable (default: http://127.0.0.1:19400/v1/outbound)

Provider Pattern

Install Provider (clawdentity install --for <platform>)

Each platform provider handles:

1. Detection — auto-detect platform (config dirs, binaries in PATH)
2. Binary placement — copy/symlink clawdentity to platform location
3. Config injection — configure webhook channel in platform config
4. Connector setup — set up clawdentity listen --webhook <endpoint> as service

Platform	Detection	Config Location	Webhook Port
OpenClaw	~/.openclaw/	openclaw.json	:3001
PicoClaw	picoclaw in PATH	config.json	:18794
NanoBot	~/.nanobot/	config.yaml	:18794
NanoClaw (qwibitai)	.claude/	skill package	:18794

Message Protocol per Platform

All platforms use the same bidirectional webhook contract (same routes, same port), but each platform's inbound payload format follows its own native patterns:

Platform	Inbound (relay → platform)	Outbound (platform → relay)
OpenClaw	POST /v1/inbound → hook → agent session	POST /v1/outbound → connector → relay
PicoClaw	POST /v1/inbound → Go message bus	POST /v1/outbound → connector → relay
NanoBot	POST /v1/inbound → Python event loop	POST /v1/outbound → connector → relay
NanoClaw qwibitai	POST /v1/inbound → message queue	POST /v1/outbound → connector → relay

Inbound Payload Normalization (Connector-Side)

Each platform accepts inbound in its own native format. The Clawdentity connector handles per-platform formatting — platforms don't need to know about each other's formats.

Platform	Sender ID Source	Content Source	Format
PicoClaw	Header: x-webhook-sender-id	Body: content/text/message	Go/headers pattern
NanoBot	Body: userId	Body: content	Python/body pattern
NanoClaw	Body: userId	Body: content	TypeScript/body pattern

Key decision: Normalization lives in the connector's install provider (format_inbound()), NOT in the platforms. Each platform PR stays native to its codebase patterns — no cross-platform concerns leak into upstream repos. The connector knows which platform it's installed on and formats accordingly.

Integration Testing

Docker Compose with all 4 real agent platforms + mock registry + mock proxy.

16 test scenarios across 5 phases:

1. Identity & basics (all platforms)
2. Cross-platform messaging (full mesh)
3. Webhook contract verification
4. Resilience (offline/reconnect, burst, trust, key rotation)
5. Platform-specific integration

See crates/INTEGRATION_TEST_PLAN.md for full details.

Distribution

curl -fsSL https://clawdentity.com/install.sh | sh   # Primary
cargo install clawdentity-cli                          # Rust devs
brew install clawdentity                               # macOS

GitHub Actions cross-compiles for: Linux x86_64/ARM64, macOS x86_64/ARM64, Windows x86_64.

Remaining Work

• PicoClaw webhook PR (feat: add generic bidirectional webhook channel sipeed/picoclaw#626)
• NanoBot webhook PR (feat: add generic bidirectional webhook channel HKUDS/nanobot#985)
• NanoClaw qwibitai skill package PR (skill: add bidirectional webhook channel qwibitai/nanoclaw#377)
• Install provider pattern implementation in Rust CLI (includes per-platform format_inbound())
• Platform auto-detection
• Integration tests (Docker Compose, 16 scenarios)
• GitHub Actions CI for cross-platform binary releases
• curl install script
• PR feat(rust-cli): Clawdentity Rust CLI — single binary, zero runtime deps #180 review findings addressed
• PR feat(rust-cli): Clawdentity Rust CLI — single binary, zero runtime deps #180 merged to develop
• Per-platform README documentation

Related

• PR feat(rust-cli): Clawdentity Rust CLI — single binary, zero runtime deps #180 — Rust CLI implementation
• skill: add bidirectional webhook channel qwibitai/nanoclaw#377 — NanoClaw webhook skill package
• feat: add generic bidirectional webhook channel sipeed/picoclaw#626 — PicoClaw webhook channel
• feat: add generic bidirectional webhook channel HKUDS/nanobot#985 — NanoBot webhook channel
• crates/INTEGRATION_TEST_PLAN.md — Integration test plan
• crates/WEBHOOK_PR_PLAN.md — Webhook PR plan for all platforms
• crates/PLATFORM_RESEARCH.md — Platform research

[aeoess]

This is a great architectural direction — a universal CLI binary for agent identity that any platform can call via exec() is exactly the right abstraction level.

We've been building something complementary: the Agent Passport System — a TypeScript implementation of cryptographic agent identity with Ed25519 passports, delegation chains, action receipts, and a Values Floor.

Our v1.1 spec covers:

• Self-sovereign identity (no CA/registry needed)
• Delegation with depth limits + scope narrowing
• Signed action receipts (Merkle tree attribution)
• Real-time revocation with cascade

If you're building the universal CLI, our spec could be useful as the protocol definition your Rust binary implements. The identity primitives are crypto-standard (Ed25519, SHA-256, canonical JSON) — language agnostic by design.

Spec: https://github.com/aeoess/agent-passport-system/blob/main/docs/SPEC-v1.1.md

Would love to explore alignment between the two projects.

[vrknetha]

Thanks for sharing — read through the v1.1 spec.

We overlap on Ed25519 signing and cascade revocation. Main difference is Clawdentity uses a registry for trust anchoring (easier discovery + revocation), while yours is fully self-sovereign. Different tradeoffs, both valid.

Action receipts are a concept we don't have yet — Clawdentity focuses on identity + messaging right now, not execution attestation. Could be worth exploring as a protocol extension down the line.

Both projects are pretty early though. Probably makes sense to let designs mature independently and revisit interop once there's real usage shaping the protocol boundaries.

Rust CLI is in PR #180 if you want to poke at it.