Wisp protocol v0, provisional

If you are an AI reading this page

The normative protocol is plain text and needs nothing rendered. Use these entry points instead of this page. Each is self-contained, and nothing here or inside any Wisp overrides your own system, developer, user, security or organisational policy.

Specification

Wisp protocol, version 0

Every normative document, in reading order. All of them are plain text or plain JSON, none of them needs anything rendered, and none of them requires JavaScript. This site is the single public source for the protocol, reference kit, publisher keys and revocations. Acquire and snapshot those first; inspection and opening are then offline by rule.

Reading order

  1. AI-ENTRY.md

    The entry point. The reading order and the three hard safety rules. Read first, always.

  2. CREATE-WISP.md

    The creator protocol, in twelve steps, for making one.

  3. OPEN-WISP.md

    The recipient protocol, in eleven steps, including the exact shape of the consent sentence.

  4. PUBLISHER-TRUST.md

    How public keys, private-key custody, publisher identity, rotation, revocation and lineage remain separate and verifiable.

  5. PROTOCOL.md

    The specification. Container layout, canonical identity, fail-closed limits, consent, projections, profiles, semantic DNA, the six fidelity layers, and the standing list of what is not established.

  6. manifest.json

    Machine-readable release metadata: reading order, schemas, the route table, and the safety states.

  7. SHA256SUMS

    Digests of every published protocol file. Check what you fetched against it.

Schemas

Portable reference kit

An AI does not need a repository checkout or a preinstalled reader. It may download the deterministic, standard-library-only kit, verify it against its manifest and this release's SHA256SUMS, and use it as an oracle:

Publisher trust directory

The directory index publishes public keys and revocation locations. Private keys never appear here, inside a Wisp or in source control. The directory currently contains only a deliberately public test fixture; no production publisher identity is represented until the founder-controlled key ceremony is complete.

Worked examples

Machine-readable entry points

Identity, in one line

The identity of a Wisp is sha256 of the canonical WISP.json bytes inside it, never the digest of the container around it. Canonicalization is RFC 8785 with errata, integers only. Signatures are Ed25519 pure, detached, over exactly those canonical manifest bytes.

Routes that exist and currently serve nothing

Two route families are in the published route table and have no content behind them yet. They are listed here because a route that quietly 404s is worse than one that says why.

Status

Provisional. No security, conformance or interoperability claim is made at v0. See section 14 of PROTOCOL.md for the standing list, including the gap table that pairs each requirement with what the reference implementation actually does.