K.4 Curation as a Craft

"If you already introduce people, you are a curator." The How page at kindling.foundation says it, and the protocol site admits what is missing: "The first curators are deciding what curation is as a craft." CONTRIBUTING.md calls curation "the most important and least understood role in the network" and promises that "a written curator playbook will be published alongside v0.1.1." On October 4, 2026, the v0.1.1 text was published (though not yet tagged as a release). No playbook was in the repository or on either site.

Until the playbook exists, this chapter gathers what the specification already requires of a curator, by section, adds the questions a new curator has to answer for themselves, and points to the manual's chapters on contracts and risk. Every example is invented and labeled so. A Pool is a mechanism for people who want to be found to say yes. It does not promise that anyone will meet, and nothing here should be read as a promise of connection.

What a curator does, in the spec's terms

You never list anyone silently. §5.1: "A Profile MUST NOT be added to a Pool without the owner's explicit consent. Silent inclusion is forbidden. There is no exception."

Inside that rule the specification names 4 things a curator does. You write a manifest with a charter (§3.2). You submit profile URLs, and the handshake does the asking (§5.2). You answer removal requests, complaints and disputes at the address in curator_contact, which the schema describes as "How a profile owner can reach the curator about removal, complaints, disputes." And you keep acting, because "A Curator is considered inactive if they have taken no curation action (handshake review, manifest edit, removal response) for 90 days." (§9.1)

The charter

An owner reads the charter before anything else about you. §5.2 puts it in every handshake, and the confirmation step must show "the Pool's name, charter, curator and visibility." Write it for the person deciding whether to say yes.

§3.2 makes it a required field and says only "free-text description." The schema says more: at least 20 characters, and "Free-text description of what the Pool is for and what it isn't. Required, plain text in v0.1." The How page gives the curator's version: "Name the Pool, say what it is for and what it is not, and choose who can see it."

Six questions a charter can answer, in this order:

1. Who is it for? Name roles and situations, not demographics.
2. What is it for?
3. What is it not for? Put the negative before the positive if that is the line people most need to see.
4. How do people come in? Name the consent model in words.
5. How does someone leave? The answer is always the same: any time, processed within 60 seconds (§5.3).
6. What do you, the curator, do with the list, and what do you never do with it?

An invented example, for illustration only:

Invented example. "Night Shift Neighbors (an invented Pool). For people in and around an invented town who work nights and would like company at hours when most places are closed: a walk at 7 a.m., breakfast after a shift, someone to text on a long night. Not for dating, recruiting, selling or promotion. The curator asks each person by email before listing them; nobody is added without a yes. Leave any time from any message. The list is never sold, shared outside this Pool, or ranked."

Visibility

Pick by who should be able to find the list, and know what each value does not do. §3.2 offers 3: public, unlisted and invite-only.

Figures checked October 2026.

RFC 0002 says "the README and CONTRIBUTING.md say so" about unlisted Pools. On the research date neither file did. Tell your members yourself.

Choosing a consent model

The floor never moves. Stricter Pools "MAY add pre-handshake steps but MUST NOT remove the owner's ability to decline or withdraw." (§5.4) RFC 0002 states it from the other side: the stricter models "never let the Curator skip consent entirely."

The manifest names one of 3 models. The spec leaves what the stricter two add undefined, so the middle column below follows the sites' examples: the Pools page's "Only the curators may propose names," and the invented Drip Line's belay-check vouch. In each, the floor is the same.

A vouch stays where it was given. §4.4: "The identity is local to that Pool and MUST NOT automatically apply to other Pools."

The rules you enforce

These bind the Pool, which in practice means they bind you. Your software applies most of them. Your part is noticing when it does not.

Figures checked October 2026.

Block lists

Shared lists are the third spam layer, and §7.3 spells out who publishes and who subscribes: "The Kindling project MUST publish a public block list of known abusers, identified by Kindling identity. Third parties MAY publish their own block lists. Implementations MUST be able to subscribe to one or more lists and filter accordingly." A Pool subscribes in its manifest, under messaging_preferences.block_list_subscriptions, a list of URLs (§3.3).

Read a list before you subscribe to it. On October 4, 2026 the project's own, at protocol.kindling.foundation/blocklist.json, described itself as "The block list the Kindling project will publish under SPEC.md §7.3," and said "The entries here are illustrative until the registry opens." Its 2 entries are illustrative. For any list, find out who publishes it, what its reason categories are, and how someone is removed. The framework leaves the hardest part as future work: a convention for "getting a person onto a block list in the first place."

Your own exposure

The specification makes you the person an owner writes to. It stops there. It does not make you a lawyer, an insurer or a moderator of anyone's conduct outside the Pool. This is not legal advice; the manual's chapters cover what to check.

What you hold is personal data: profile URLs, cached parsed profiles (§3.4), consent proofs with times, decline records, and the email addresses verification and messaging run on (§4.2, §6.1). Ch 4.7 covers privacy law, and a Pool open to people in several places can reach more than one regime.

What you promise is the charter. It is not a contract. If you run Pools for an organization, the arrangement between you and the organization is one, and Ch 4.3 covers the clauses to put in writing: scope, liability, confidentiality and what happens to the Pool when the arrangement ends. If you charge for something beside the Pool (Chapter K.3), Ch 4.3's terms-of-service section applies to that thing.

What can go wrong fits on Ch 4.8's one-page risk register. An invented example:

Figures checked October 2026.

Review it quarterly, and when the Pool changes shape, as Ch 4.8 says.

Leaving well

Name a co-curator on the day you start, and show them where the decline records and consent proofs live. The Pool will outlive you by design. After 90 days the Pool goes dormant; "Any active member MAY nominate themselves or another active member"; success needs "at least two-thirds of responding active members" within 14 days; "Co-curators listed in the manifest are first in line." (§9.1, §9.3) Failing that, it archives and stays readable (§9.4).

The Founding Curators Pool

Status on October 4, 2026: Planned. The project means it for its first curators, and its own charter reads: "People who already do introduction work, invited by the maintainers to run the first Pools and write down what curation is as a craft. Maintainers propose; every person still accepts or declines, and can leave within a minute. This Pool is not a waiting list for anything and nobody pays to be in it." Its consent model is curator-only-adds.

The Pools page says "They are not open yet, and nobody is in them," and every member shown is invented. The project's own well-known file at kindling.foundation/.well-known/kindling-pool lists none of them, so no crawler will read a planned Pool as live.

The How page gives the way in: "If you would like to be one of the real ones, write to hello@kindling.foundation." And: "It is not a waiting list for anything, and nobody pays to take part." The same page sends anyone who wants to run a Pool now to maintainers@kindling.foundation.

Chapter 10.4 leads Volume 10 in this edition. Read it for yourself first. Introduction work is still work, and Ch 10.4 is plain that you can be "surrounded by people and lonely."

Field exercises

1. Write your Pool's charter answering the 6 questions. Label any example people invented. Done when it is at least 20 characters, says what the Pool is not for, and a stranger can say yes or no from it alone.
2. Choose a consent model and a visibility, and write one sentence for each saying why. Done when both sentences name what the choice cannot do.
3. Run an invented profile through your whole handshake: ask, confirm on the page, decline, re-ask, accept, withdraw. Done when the re-ask is refused, and the withdrawal is processed within 60 seconds by the clock.
4. Read every block list you plan to subscribe to. Done when you can name each publisher, its reason categories and its removal process, or you have decided not to subscribe.
5. Fill in a 4-row risk register for your Pool. Done when every row names what covers it and a co-curator is in the manifest.
6. Write to hello@kindling.foundation if you want to be a founding curator, saying what introduction work you already do. Done when the message is sent, or you have written down why not yet.