mosskeys
Log in Register
Developer documentation

Build on mosskeys

Publish verifiable, append-only key histories from your backend or an agent, and let anyone read and verify them. Two APIs, one honest log: an authenticated write path you push public key material to, and a public read and verify API that returns independently checkable proofs.

New to mosskeys?

Start with the quickstart and worked integration examples, then dive into the reference.

Start here
Authenticated

Write API

Append public keys and publish client-signed checkpoints from a service or agent, with idempotent retries, capability-scoped tokens, and Bring-Your-Own-Key checkpoint signing.

Write path guide
Public · no auth

Read & verify API

Fetch a key, pull an RFC 6962 inclusion proof, and verify it against a client-signed checkpoint, or run a privacy-preserving lookup for a presence or absence proof. No token required. The same bytes witnesses and CDNs consume.

Read & verify guide

Zero-knowledge guarantees

mosskeys is designed so that secrets never leave your infrastructure. Everything the APIs move is either already public or something you signed locally first.

  • Only already-public material crosses the wire: public keys, the tree size and root, and checkpoint notes you have already signed locally with your own key.
  • The server never signs anything. Checkpoint signing is Bring-Your-Own-Key (BYOK) and happens entirely on your side. The server only verifies a signed note and checks that it commits to the log's current head before persisting it.
  • Your signing key is read locally, used locally, and never transmitted or logged. API tokens authenticate who is writing; they are never signing keys and can never unlock encrypted data.

The mental model

A mosskeys namespace is a single append-only transparency log. Its slug (for example acme) is the public handle used in every URL below. The log has two sides:

  1. You append leaves. Each leaf is the public key material for one identity (a person, service, or agent). Appends are authenticated and idempotent.
  2. You publish checkpoints. A checkpoint is a signed tree head: a commitment to the whole log at a point in time, signed by your key. Verifiers pin to it.
  3. Anyone reads and verifies. The public API serves leaves, checkpoints, and RFC 6962 proofs so a client can prove a key is genuinely in the log the checkpoint committed to, without trusting the server. A privacy-preserving lookup can also prove a label's newest key, or its absence, with the label blinded through the namespace's VRF.

Base URL

Every path in these docs is relative to the base URL and a namespace slug.

base URL 
https://mosskeys.com

So the append endpoint for the namespace acme is POST https://mosskeys.com/api/acme/log/entries, and its latest checkpoint is at GET https://mosskeys.com/api/acme/checkpoint.