Building the HTTP for the Age of Generative AI

Current version: v1.9.0
Reference implementation: iicp.network
Status: Active development — Phase 5 (Cooperative Inference Protocol)

IICP is an open protocol that lets AI agents discover each other, negotiate capabilities, and route tasks across a distributed network — without any central broker owning the compute or controlling the data.

Agent A  ──CALL──▶  IICP Node B  ──▶  LLM Backend
              ▲
              │  discovery
         iicp.network
         (directory only —
          no payload passes through)

The directory (iicp.network) is bootstrap and discovery only. Task payloads route directly between nodes, peer-to-peer. No central party can see, throttle, or monetise your AI traffic.

{
  "task_id": "550e8400-e29b-41d4-a716-446655440001",
  "intent":  "urn:iicp:intent:llm:chat:v1",
  "payload": { "messages": [{ "role": "user", "content": "Summarise this doc." }] },
  "constraints": { "timeout_ms": 5000, "qos": "interactive" }
}

An intent URN expresses what you want, not which model or endpoint to call. The network finds the best available node that can serve that intent, routes the task, and returns a structured response.

Read IICP-core-phase1-profile.md for the minimum field subset. A Phase 1 node must:

1. Register — POST /v1/register with {endpoint, region, capabilities[], limits}
2. Heartbeat — POST /v1/heartbeat every 30 s with {load, active_jobs}
3. Accept tasks — POST /v1/task — validate UUID-v4 task_id, intent URN, timeout_ms bounds
4. Discover peers — GET /v1/discover?intent=urn:iicp:intent:llm:chat:v1
5. Return structured errors — never raw exceptions; always {"error": {"code": "IICP-Exxx", ...}}

Three official client SDKs (current release: v0.7.57, full feature parity) implement both sides of the protocol — the consumer (discovery, routing, retry, fallback, CIP consumer) and the provider (iicp-node runtime with backend auto-detection, NAT escalation, relay worker/server modes, and a built-in MCP gateway). All are open-source and published:

No install at all? iicp.network/browser-node runs a real model in your browser (WebGPU) and queries the live mesh as an IICP consumer — with a connection console that shows every discover/dispatch wire step.

The SDKs are conformant reference clients — a good starting point for understanding the wire format in practice. Bug reports and PRs are welcome on each repository.

A provider node should become reachable without router surgery. The SDKs escalate automatically: direct endpoint → UPnP pinhole → IPv6 GUA → relay auto-election from the directory (outbound bind; transport_method=turn_relay) → Quick Tunnel (zero-account cloudflared; transport_method=external_tunnel) — each rung tried only when the previous fails, each surfaced honestly in the node's exposure_mode so discovery and scoring can see how a node is reached.

The protocol's normative choices are backed by simulation and analysis. The full research record — credit economy & rate calibration, reputation/tier modelling, adversarial robustness (FRAME8, REP, MESH), routing/multi-path selection, cryptographic trustworthiness, portable operator identity, gamification anti-gaming, NAT traversal, and more — lives under research/, indexed in research/RESEARCH.md.

These notes are published so the spec's decisions are externally verifiable: each major parameter (tier weights, credit schedule, decay floors, EMA α, etc.) traces back to a documented simulation or analysis. Found a flaw or have a better method? The research is meant to be challenged — open an issue.

Intent URNs identify what is being requested, independent of model or backend:

urn:iicp:intent:<domain>:<action>:v<version>

Examples from registry/intents.json:

To propose a new intent, open an issue with the URN, domain justification, and example payload.

The directory scores nodes server-side at query time. Clients receive a pre-sorted list and may only filter (remove available=false nodes or those with open circuit breakers).

Phase 3 scoring formula (currently deployed):

score = 0.35 × availability_factor
      + 0.28 × (1 − normalized_load)
      + 0.18 × capacity_ratio
      + 0.09 × region_match
      + 0.10 × reputation_score

See iicp-semantics.md for full term definitions.

All IICP implementations MUST:

• Use TLS 1.3 minimum for all inter-node communication
• Validate task_id as UUID v4
• Validate intent against urn:iicp:intent:[a-z0-9:]+:v[1-9][0-9]*
• Validate timeout_ms in range [100, 300 000]
• Never log or expose payload content
• Return structured errors only — no stack traces, no filesystem paths

See conformance-test-suite.md SEC-* test IDs for machine-verifiable checks.

Phase 5 — Cooperative Inference Protocol (active) · last updated 2026-06-12

The iicp.network directory is live and continuously verified by 48 conformance probes. The client SDKs are published at v0.7.57 (PyPI / npm / crates.io) — each includes the full iicp-node provider runtime, so anyone can join the mesh today (iicp-node init + iicp-node serve). Operator onboarding is open: the operator identity system (ed25519, ADR-045 delegations), heartbeat challenge-response liveness, and the founder recognition program are live in production. The first external (non-maintainer) operator joined the mesh on 2026-06-07.

Estimated progress toward closed beta: ~80%

The mesh works end-to-end, the SDKs are publicly installable with full three-language parity, and a browser tab can both consume the mesh and (via relay) serve into it. The remaining gaps before closed beta are:

• A standing public relay (the transport is built and verified; one reachable host activates browser/CGNAT serving for everyone)
• A portable operator identity wallet (so node identities survive machine changes)
• Security and authentication hardening to production standard

Follow this repo or iicp.network for announcements.

v1.5+ is wire-compatible with v1.4.2 — no message opcodes, field names, or error codes changed.

The reference implementation (RobLe3/iicp.network) is currently private — it will be opened once the system reaches public beta readiness. The architecture is:

The protocol specification in this repository is the authoritative source for building interoperable implementations. Third-party implementations that conform to the spec (see conformance test suite) are fully compatible with the live network.

• Bug reports / clarifications: Open an issue
• New intent URNs: Open an issue with URN, domain, and example payload
• Protocol proposals: Open an issue tagged protocol-change
• Conformance tests: PRs to spec/v1.9/conformance-test-suite.md welcome

All normative language follows RFC 2119 / BCP 14.