A client with no Pools of its own

Settings, mapped to the spec

What we chose, and why

The Pools we read, and how

Discovery, step by step

1. Fetch every .well-known/kindling-pool file we know of, and the Kindling registry’s list of them §8.3 §8.4. Nobody needs to give us permission to read these, and nobody pays to be in them. The files for the hosts below: Many Moons · Late Supper · Second Tide Books · Wren’s List · Card Catalog · Heartwood · Face Up · Sundial · Queer Harbor.
2. Keep the Pools that are public, active and tagged dating, whoever keeps them. That is 8 Pools today: four kept by curators, and four that other apps keep for their own people (Card Catalog, Heartwood, Face Up and Sundial).
3. Fetch each manifest, check it against pool_manifest.schema.json, and check its major version §12.2.
4. Drop anyone whose page says noindex §2.7, and anyone on a block list we subscribe to §7.3.
5. For a person who gives us an unlisted Pool’s address, read that Pool for them alone, and keep the address with their settings.
6. Show each person once, behind the first door in the room’s order, and name their other Pools on their card §3.5.
7. Read each person’s age, gender, who they’re looking for and portraits from their own page, which the parsed profile has no field for, and show a viewer only the people whose page and theirs fit each other, with everyone else one choice away §2.1 §2.5.
8. Be polite to hosts: respect Cache-Control, back off on 429 and 5xx, and send a User-Agent with a contact URL §10.3.

The discovery files of other hosts list 50 more public Pools, from 15 hosts including Ada Quillon, Cape Tarrow Alumni, Correo Lento and Drip Line. We read their entries in the discovery files and leave them alone: none is tagged dating.

For readers of this library only: to check our arithmetic, the unlisted manifests are here as files: Queer Harbor: queer-harbor-dating.json · Many Moons: orchard-street-household.json · Late Supper: tuesday-table.json · Late Supper: second-chapters.json. A real Roomful would never print those addresses, and in this example’s world it doesn’t.

Safety that travels

The block lists we subscribe to

The same two lists every Pool we read subscribes to §7.3.

The messages this site shows are sample files, validated against the schema: an ask, a yes, a no, a first letter. The handshake Wren’s List sends Jonah: demo-request.json.

Honest limits

What the v0.1 schema can’t say yet

Where the spec text and a schema disagree, our JSON follows the schema. These are the gaps that touch a client like us.

1. Verification level names (§4.5). The spec text names email-verified, oauth-verified, curator-vouched and unverified. The schemas use email, oauth, curator-vouched, unverified and cryptographic, and a curator is only ever email, oauth or cryptographic. Our JSON follows the schema; the screen shows words.
2. Where a field came from (§2.3). The spec asks parsers to record which fields came from h-card and which were inferred, in an extraction_source field. parsed_profile.schema.json has no such field and forbids extra ones. For date-me docs, which rarely carry h-card, this matters: we can show a person their own provenance, and can’t pass it on.
3. Age, gender and who someone is looking for (§2.4). parsed_profile.schema.json has no field for age, gender, who a person is looking for or what for, and forbids extra ones. It has photo_hints, image URLs only, with no alt text (§2.4, §2.5), and the Pools we read leave it empty. So a Pool can’t carry any of these, and every client reads them from the person’s own page, each time, in its own way. That keeps them where the person wrote them, but no Pool can vouch for them, and two clients may read the same page differently. We show what the page says in its own words, filter only on what it says, and never guess a blank.
4. Mutual interest has no message (§7.2, §6.3). no-cold-messages means “require confirmed mutual interest”, but no message type says “I’d like to hear from you”. We send a system message with fixed text and no words from the sender, and treat a reply as the answer. Another client could do it differently.
5. Message types (§6.3). The spec lists four types. kindling_message.schema.json has six, adding withdrawal and system. We use both.
6. The Pool reference (§6.2). The spec calls it pool_ref; the schema calls it via_pool. Our messages use via_pool.
7. The messaging rule names (§7.2). The spec names open-to-all, pool-mates-only, vouched-only, no-cold-messages and minimum-sender-verification. The profile schema has accept_from (anyone, verified, shared-pool, vouched, none) and a no_cold_messages flag, and no per-person minimum sender level; only a Pool can set one. We read the schema’s names.
8. The discovery file (§10.2). The spec says it lists, for each Pool on a domain, pool_url and curator_contact among others. The schema has manifest_url, an optional operator for the whole file, and lists only discoverable Pools, so unlisted ones are left out. That suits a client: we learn nothing about an unlisted Pool from a discovery file.
9. The version field (§12.1). The spec names kindling_version; every schema uses schema_version.
10. Noindex is not privacy (§2.7). kindling_noindex: true means “don’t put me in any Pool”. Privacy inside a Pool comes from its visibility. A client must never treat noindex as “hide me from apps”, or visibility as consent.
11. Thanks (v0.2 draft). Gratitude after an introduction is planned for v0.2 and has no field or message yet. Ours happens outside the protocol until it does.