KindlingProtocol · v0.1

Requests for comments · Kindling v0.1

RFCs

Seven seed RFCs anchor the v0.1 design, one for each part of the protocol. Each one records a design that landed in v0.1. Changes to the specification land through new RFCs, in a process modeled on Rust’s.

  1. RFC 0001 · Profile standard

    Defines the Profile layer of Kindling: a self-hosted page, parsed on consent into a structured JSON document. IndieWeb h-card is the baseline schema; AI-assisted extraction fills gaps. Photos are referenced by URL only, never cached at the protocol level. Re-parsing is trigger-based with a 24-hour debounce.

    Accepted (landed in v0.1) · Created 2026-04-23 · Spec §2 · Related 0002 (Pool standard), 0003 (Identity)

  2. RFC 0002 · Pool standard

    Defines the Pool layer: a manifest plus a list of consented Profile entries, hosted as JSON either in a public Git repo or behind an API returning the same shape. Manifests declare curator, charter, intent, visibility, and consent model. Pool continuity handles curator inactivity via a 90-day dormancy threshold and a 14-day transition window.

    Accepted (landed in v0.1) · Created 2026-04-23 · Spec §3, §9 · Related 0001 (Profile), 0004 (Handshake), 0007 (Discovery)

  3. RFC 0003 · Identity

    Defines a layered identity model: email verification (baseline), OAuth via existing providers (familiar shortcut), and curator vouching (Pool-local). Verification level is always surfaced to Askers. Cryptographic identity and cross-Pool portability are explicitly deferred to v0.2.

    Accepted (landed in v0.1) · Created 2026-04-23 · Spec §4 · Related 0001 (Profile), 0004 (Handshake), 0006 (Spam filtering)

  4. RFC 0004 · Consent and the handshake

    Defines the consent exchange that precedes any Profile's inclusion in a Pool. A Curator submits a URL; the Pool pre-fetches a contact; the Pool sends a handshake message with accept/decline links; inclusion only happens on accept. Withdrawal is always available. Auto-accept rules are opt-in, capped at five per Profile, always notified, and revocable retroactively.

    Accepted (landed in v0.1) · Created 2026-04-23 · Spec §5 · Related 0002 (Pool), 0003 (Identity), 0005 (Messaging)

  5. RFC 0005 · Native messaging

    Defines the minimal native messaging contract. Transport in v0.1 is structured email over existing email infrastructure. Messages validate against schemas/kindling_message.schema.json. Four message types are defined: handshake-request, handshake-response, intro, reply. Implementations are free to render conversations as threads, chat, or anything else.

    Accepted (landed in v0.1) · Created 2026-04-23 · Spec §6 · Related 0004 (Handshake), 0006 (Spam filtering)

  6. RFC 0006 · Spam filtering

    Defines a three-layer spam-filtering model that every v1-conforming implementation MUST support: (1) identity-based gating, (2) per-profile preferences, and (3) shared block lists. Layers compound. Block lists validate against schemas/block_list.schema.json and are modeled after how email blocklist services work today.

    Accepted (landed in v0.1) · Created 2026-04-23 · Spec §7 · Related 0003 (Identity), 0004 (Handshake), 0005 (Messaging)

  7. RFC 0007 · Discovery

    Defines four discovery surfaces for Pools: social sharing, a .well-known/kindling-pool convention, the Kindling public registry, and third-party registries. A spec-compliant Pool MUST be reachable through at least one surface and SHOULD publish a well-known file. No surface is privileged — the public registry is one consumer of the well-known convention, never the only one.

    Accepted (landed in v0.1) · Created 2026-04-23 · Spec §8, §10 · Related 0002 (Pool standard)

RFC 0000 is the template for new proposals. It lives in the repository with the others, at RFCs/0000-template.md. To propose a change, read the template and open a pull request on GitHub.