K-7.1 Being Found: The Registry and the Well-Known File

"Building got cheap. Getting noticed did not." The Field Manual's opening line is truer for a Kindling builder than for most. The repository ships a validator, a parser, a reference handshake server and a reference registry server. A working client is weeks of work, and so is the next one. What a builder cannot generate is a reason for curators to point their members at it.

The spec tells you how Pools are found, and therefore how the things that read them get found too. Spec references are to v0.1.1, as of October 4, 2026.

Why builders under-invest in it

The Field Manual's causes apply without changes:

• "Building feels like progress and selling feels like rejection." A parser either passes the tests or it doesn't. A curator who never answers gives no feedback at all.
• "Distribution work compounds slowly."
• "AI makes the imbalance worse. When a feature takes an afternoon, the temptation is to ship another feature."

So does its rule, from Weinberg and Mares's Traction: "spend about half your time on getting traction and half on product, starting before launch."

The surfaces the spec defines

A Pool is a file, and §8 says how the file is found. "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)

Figures checked October 2026.

The protocol site states the builder's half of the story: "Build a Kindling client in your stack. A list, a search view, a printed zine. Send the link and the registry lists it." The last sentence describes a registry endpoint that did not exist on October 4, 2026. Plan around the surfaces that work.

What the well-known file gives a builder

The well-known file is the most useful thing in §8 for anyone writing a client. "It MUST list, for each discoverable Pool on the domain, its manifest_url, visibility and status (active, dormant, archived)." (§10.2) A client that reads well-known files can find every Pool a host lists as discoverable without anyone submitting anything, and can see which are dormant.

Read it politely. "Crawlers and registries MUST respect Cache-Control headers on the well-known file, MUST back off on 429/5xx responses, and MUST identify themselves via a User-Agent that identifies both the software and a contact URL." (§10.3) A crawler that ignores those rules gets blocked, and a blocked client has no distribution at all.

Some Pools are left out of it. The registry view on the protocol site says so: "Unlisted and invite-only Pools do not appear here." "Their addresses travel by hand." A client that can open a Pool from a pasted URL reaches those Pools too.

What compounds

The Field Manual's fourth filter: "Some channels rent attention and some build an asset." On Kindling three things build an asset for a builder:

• Being one of the doors. Each invented library site carries an "Open in" row naming the apps that can read its Pools. The Why page calls this "One room, many doors": "The same Pool can be read as a list, a map, a zine, an email digest or by an agent." A curator adds your client to that row because it treats their members well. That listing stays as long as you keep earning it.
• A registry you run. §8.5 makes third-party registries "first-class." A registry of the Pools your client serves best is useful to curators and points straight at you. The spec calls "a Pool's inclusion in or exclusion from any registry" a "curator decision," so list only Pools whose curators asked.
• A record of conformance. Show, section by section, which §11 class your client meets. K.1 maps each class to the sections that bind it. A curator choosing which door to recommend can check that in an afternoon.

Worked example: Hollis Grant's client

Hollis Grant is invented. The kindling.foundation handshake page describes him: "He builds a Kindling client for rural libraries." Consider how a client like his would be found.

1. Read the well-known files of the libraries it serves. The invented Board at Port Ellery Free Library keeps its Pools on its own domain. A client that reads well-known files finds them on its own (§8.3, §10.2) and shows dormant ones as dormant (§9.1).
2. Ask each curator to name it in their "Open in" row. That is a conversation with a librarian, and it is the main channel. It takes the time the Field Manual says distribution takes: "ten hours on distribution, every week."
3. Run a small registry of the rural library Pools whose curators asked to be listed (§8.5), and publish the client's conformance claims beside it.
4. Submit to the project's registry when it opens, and date the day you check (§8.4).

Nothing in that sequence buys placement or pays anyone per introduction. Kindling defines no chargeable surface between two people (§1.3, a stated non-goal).

The Field Manual's nineteen-channel Bullseye and its price-to-channel filter are in the full Chapter 7.1, on solo.joshwolf.net. The price filter assumes the product has a price. On Kindling the introduction has none, and the thing sold beside it is priced in Chapter K-3.6.

Field exercises

1. Publish a well-known file for an invented Pool on a domain you control, and validate it inside a clone with kindling-validate. Done when it validates and lists manifest_url, visibility and status.
2. Check the project registry's status. Done when you have written down what registry-data/ holds and the date you looked.
3. List the surfaces where your client can be found, with the section that allows each. Done when every surface has a section number and a status in one word.
4. Write the crawler rules of §10.3 into your client's fetch code. Done when a test against a server that returns 429 shows your client backing off, and your User-Agent names your software and a contact URL.
5. Block ten hours a week on the calendar for distribution. Done when the recurring blocks exist and the first one has a named curator to write to.

---

Rewritten for the Kindling edition from Chapter 7.1 of The Solo Operator's Field Manual. The full chapter is on solo.joshwolf.net. © 2026 Josh Wolf, licensed under CC BY 4.0. Quotations from the Kindling Protocol Specification v0.1.1: © 2026 TranquilTech and Kindling spec contributors, CC BY 4.0, marked where shortened.