K.1 The Protocol as a Reader Meets It

Kindling is two open standards and a handshake, written down before anything was built on them. The specification is v0.1.1, an errata release dated 1 October 2026, and its own status line reads "Stable for v0.1." Nothing runs on it at TranquilTech yet. The protocol site says so in a chip: "Nothing yet." Mycelial, the first implementation, is "Opening by invitation. Its Kindling version ships in early 2027." All of this is as of October 4, 2026.

Each part of the specification asks something of you, and its section number says where. Read the asks here and choose what to build before you clone anything. The protocol site's five-step quick start ("Build on it"), its glossary, its RFC index and its schema pages are not repeated; go there for those. Every section number below is from spec/SPEC.md at commit e4eb787 of github.com/IntelliBotique/kindling, and the copy served as protocol.kindling.foundation/spec.md was byte-identical on the research date.

Two standards, stacked

§1.2 names the layers: "Layer 1, Profile standard (§2). A freeform self-hosted page becomes a structured profile" and "Layer 2, Pool standard (§3). A Pool is a manifest of structured profiles with a declared curator, intent, visibility, and consent model." Then: "UIs are implementation-defined. The two layers underneath are the protocol."

The negative comes next, and every builder should know it. §1.3 is a list of non-goals that carries no keyword: "Kindling does not define a hosted consumer product, a single canonical UI, a federation transport (v0.1 uses email under the hood for messaging), or a chargeable surface at the connection layer." Chapter K.3 takes up that last clause.

Layer 1: any URL is a profile

You own the page; the protocol reads it. "A Profile is whatever the owner publishes at a URL. There is no required format. The protocol parses what is present." (§2.1)

A parser meets the page in a fixed order, h-card first. §2.2: "Parsers MUST read h-card fields where present and MUST NOT infer values that contradict explicit h-card markup." Where markup is missing it may infer, and it must say so. §2.3 puts that on the implementation: "Implementations MUST record which fields were h-card-derived and which were inferred." The record lives in extraction_source, which maps each field to one of 3 values, h-card, inferred or owner-declared, and "A parser MUST fill extraction_source whenever it infers any field." (§2.3)

Four more rules decide what a parser may keep:

Figures checked October 2026.

§2.7 also draws a line a builder can miss: "Noindex is not a privacy setting inside a Pool. Privacy inside a Pool comes from the Pool's visibility (§3.2)."

Layer 2: the Pool manifest

A Pool is a file before it is anything else. §3.1: "A Pool MUST be retrievable as a JSON document, either from a public Git repository or from a Pool API endpoint that returns the same shape. The document MUST validate against schemas/pool_manifest.schema.json."

The 9 required fields are §3.2's. The schema adds the constraints in the right-hand column.

Figures checked October 2026.

Under §3.4 each entry "MUST contain" 4 fields: profile_url, consent_proof ("reference to the handshake response authorizing inclusion"), verification_level and added_at. Once the page is parsed, an entry "SHOULD also contain" parsed_profile and parsed_at. Two closing rules matter: "An entry's verification_level is never unverified" and "An entry MUST NOT hold a parsed profile with kindling_noindex: true (§2.7)." The coupling is loose by design. "A Profile MAY appear in many Pools. A Pool MAY list many Profiles." (§3.5)

Identity, shown every time

"A Profile owner MUST be able to prove they control the URL they published. Verification level MUST be visible to Askers." (§4.1)

Email is the baseline. §4.2: "The first time a Profile is brought into any Pool, Kindling MUST send a verification link to the declared contact email." OAuth is optional (§4.3). A curator may vouch inside a Pool, and §4.4 keeps that identity at home: it "MUST NOT automatically apply to other Pools." The wire values sit in §4.5 (email, oauth, curator-vouched, unverified, and cryptographic, "Reserved for v0.2"), beside the rule every interface inherits: "a v1-conforming UI MUST render it alongside every Profile."

The handshake and the 6 message types

Nobody enters a Pool without saying yes. §5.1 in full: "A Profile MUST NOT be added to a Pool without the owner's explicit consent. Silent inclusion is forbidden. There is no exception."

§5.2 gives 6 steps. A curator submits a URL; the Pool pre-fetches a contact method; the Pool sends a handshake carrying the Pool's name, charter, curator identity, intent tags, visibility, an accept link and a decline link. Since v0.1.1 the links decide nothing by themselves: "Each link MUST open a confirmation step that shows the Pool's name, charter, curator and visibility and asks the owner to confirm. Only an explicit action on that step, such as a button that sends a POST request, records a decision. A GET request to either link alone MUST NOT record a decision." The reason takes one line: "email security scanners open every link in a message." A decline "MUST be recorded as declined for that Pool and MUST NOT be re-submitted by the same Curator without owner permission." Silence expires. The window is the manifest's handshake_window_days, literally a default of 14, and "A request's expires_at MUST equal its sent_at plus the window."

Leaving is faster than joining. §5.3: "Implementations MUST process withdrawal within 60 seconds of receipt." Stricter Pools "MAY add pre-handshake steps but MUST NOT remove the owner's ability to decline or withdraw." (§5.4) Auto-accept stays off until the owner turns it on, and §5.5 caps it: "Auto-accept defaults to off. A Profile MUST NOT have more than five active auto-accept rules. Every auto-accept event MUST produce a notification to the owner; silent acceptance is forbidden." It "never applies to an invite-only Pool."

Messages ride on email. "In v0.1, Kindling messaging is delivered as structured email over standard email infrastructure." (§6.1) Envelopes "MUST validate against schemas/kindling_message.schema.json" and name the Pool in via_pool (§6.2). The 6 types are §6.3's:

Figures checked October 2026.

Richer transports may come later. §6.4 holds them to one condition: they "MUST preserve email as a fallback through v1.x."

Spam, discovery and continuity, in one pass

Spam protection comes in 3 layers, and §7 says "A v1-conforming implementation MUST support all three layers." Identity gates first: "Messages from unverified senders MUST be quarantined or rejected per the recipient's per-profile preference." (§7.1) The owner's own rules come second, accept_from (anyone, verified, shared-pool, vouched, none; verified is the literal default) and no_cold_messages, and "Implementations MUST honor the declared rules." (§7.2) Shared block lists come third. §7.3: "The Kindling project MUST publish a public block list" and "Implementations MUST be able to subscribe to one or more lists and filter accordingly."

Discovery asks little: "A spec-compliant Pool MUST be findable through at least one of these surfaces, and SHOULD be findable through the well-known convention (§8.3)." (§8.1) The public registry "MUST NOT be the only way a Pool is discoverable" (§8.4), and anyone may run another (§8.5). The well-known file at /.well-known/kindling-pool "MUST list, for each discoverable Pool on the domain, its manifest_url, visibility and status" (§10.2). Crawlers "MUST respect Cache-Control headers," "MUST back off on 429/5xx responses," and must send a User-Agent naming the software and a contact URL (§10.3).

Continuity protects the people in a Pool from its curator's calendar. After 90 days without a curation action, "the Pool MUST enter dormant status. Pool members MUST see a notice. The well-known file MUST reflect dormancy." (§9.1) Active members may elect a new curator by two-thirds of those responding, within 14 days (§9.3). Failing that, "the Pool MUST archive," and it stays readable (§9.4).

Every document "MUST carry a schema_version field," and the value stays "0.1" through v0.1.x (§12.1). A parser meeting a newer major version "MUST refuse to consume the document and MUST surface a clear error." (§12.2)

The 10 lines the site leads with

The protocol site says "The character of the protocol is in its MUSTs" and lists 10. Eight rest on a MUST in the section cited. Two do not. §1.3 is a non-goal, and §6.1 describes the transport while the binding MUST sits in §6.4. Know which is which before you quote them.

Figures checked October 2026.

The site's own gloss on line 5 is accurate: "That is a stated non-goal, not a pricing decision." Quote §1.3 as a non-goal. Do not upgrade it to a MUST, and do not soften the 8 that are.

Four conformance classes

§11 defines 4 things you can build that conform. Each binds a different set of sections.

Figures checked October 2026.

From "I want to build" to the sections that bind it

Figures checked October 2026.

The last three rows are useful and permitted, and §11 names no conformance class for any of them. Say "built on Kindling" for them; "Kindling-conformant" belongs to the 4 classes until a later version names more.

What ships, and what does not

The repository ships the specification, 6 JSON Schema 2020-12 files, 5 Node command-line tools (kindling-validate, kindling-parse, kindling-discover, kindling-handshake, kindling-blocklist), a file-backed Express registry, example manifests and profiles, and a vitest suite. That is the list as of October 4, 2026. On the research date, inside a fresh clone on Node 22, npm test passed 43 of 43 tests and kindling-validate accepted all 5 example documents.

No SDK ships, and no client library, hosted API or consumer app. The repository calls the last deliberate: "It does not contain a consumer experience. Consumer experiences belong to implementations." The registry's own README lists what v0.1 leaves out: curator authentication ("currently we trust the submitted email"), scheduled re-validation, block-list subscription management, search and analytics. The well-known crawler "is not in v0.1," so "curator self-submission is the only path into the registry." And the registry-data/ folder that §8.4 names as the public registry held only its README on the research date.

Before you clone: 5 things the repository gets wrong today

Each holds for commit c3e24cd on October 4, 2026, after that day's fixes.

1. The quick start works only inside a clone. npx kindling-validate resolved inside the cloned folder after npm install and returned a 404 from npm everywhere else. Nothing named kindling-validate is published to npm.
2. The npm name "kindling" belongs to someone else. It is an unrelated project ("Project bootstrapping with an emphasis on simplicity," version 1.1.0). npm install kindling will not install this protocol's tools.
3. The README is out of date. It says v0.1 "is in pre-launch review, targeting public release as v0.1.1 in late spring 2026," and points at kindling.tranquiltech.com and registry.kindling.tranquiltech.com. The live sites are kindling.foundation and protocol.kindling.foundation.
4. v0.1.1 has no release. CHANGELOG.md marks its 0.1.1 section "Unreleased," GitHub showed "There aren't any releases here," and the repository has no tags, so the changelog's link to a v0.1.1 tag leads nowhere.
5. The roster is unfinished. MAINTAINERS.md names one person, the project lead, and says no Spec Reviewers or Code of Conduct Committee members are named yet. CODE_OF_CONDUCT.md still lists its committee as three placeholder rows. Chapter K.2 says what that means for how a change is accepted.

Field exercises

1. Pick one thing from the build table and write the list of sections that bind it, with the MUSTs quoted. Done when every MUST in your list carries its section number and none is paraphrased.
2. Clone the repository, run npm install and npm test, then validate one example manifest. Done when you have the test count, the validator's output and the commit hash in one note, dated.
3. Write an invented Pool manifest for a group you could plausibly keep, label it invented, and run npx kindling-validate on it inside the clone. Done when it validates and you can explain every warning.
4. Read §5.2 step 3 aloud and sketch the confirmation page your implementation will show. Done when the sketch shows the Pool's name, charter, curator and visibility, and nothing is recorded until a button sends a POST.
5. For each of the 10 lines in the table, find the sentence in spec/SPEC.md it rests on. Done when you can say which 2 do not rest on a MUST in the section cited and quote what they rest on instead.