Under the hood: any Pool, five shortcuts

Settings, mapped to the spec

What we chose, and why

One Pool, three layers

Ada Quillon’s Listeners: the site, the JSON and our card

The same Pool is a page on its host’s own site, a JSON file anyone can read, and a card in any app that reads the file. Every card in Heartwood links back to the other two. Here is one person, Consuelo “Connie” Arroyo, in all three, as Theo Lindqvist sees her in Music.

{
  "profile_url": "https://connie-arroyo.carrd.example",
  "parsed_profile": {
    "schema_version": "0.1",
    "profile_url": "https://connie-arroyo.carrd.example",
    "display_name": "Consuelo “Connie” Arroyo",
    "pronouns": "she/her",
    "location": {
      "city": "Port Ellery",
      "country": "United States"
    },
    "intent_tags": [
      "music",
      "listening",
      "friendship"
    ],
    "about": "Sells tickets at the ferry terminal. First heard Ada play at Fix-It Friday while someone rewired her amp. Would like a few people to sit with at shows.",
    "contact_methods": [
      {
        "type": "email",
        "value": "consuelo@mail.example",
        "label": "Kindling identity"
      }
    ],
    "verification": {
      "level": "email",
      "verified_at": "2026-06-21T09:30:00Z"
    },
    "messaging_preferences": {
      "accept_from": "shared-pool",
      "no_cold_messages": false,
      "minimum_curator_verification": "email"
    },
    "kindling_noindex": false,
    "parsed_at": "2026-06-21T09:30:00Z",
    "parser": "kindling-parser/0.1.1"
  },
  "verification_level": "email",
  "added_at": "2026-06-21T09:30:00Z"
}

Every line on the card is in the entry above, or says it is blank. Consuelo has no page fields we read, so the card draws no face and shows no age, gender or answers. Her tags came from her own page; the level beside her name came from the entry.

Our manifests

Two Pools, one discovery file

The request Friends nearby sends Simone: handshake/demo-request.json.

Rooms, layers and own names

Where each Pool opens

We find Pools through well-known files and registries §8.3 §8.4. Every Pool an app may open, opens: a public one for anyone, an unlisted one for a member or for someone who has its address §3.2. A room is every Pool whose tags fit it, and the last column says which layers are on when you open the app. A resting Pool opens and says it is resting §9.1. We drop anyone whose page says noindex §2.7 or who is on a block list we subscribe to §7.3. Cards come from the layers that are on, taking turns between layers, newest first in each. Nothing is sorted by a score.

Under its own name

These 27 Pools fit none of the five rooms, so each opens as a room of its own, named for the Pool. Load a product and its own-name room, named for the product, holds together those of its Pools that fit no room. Every card still names its Pool, a line of its charter and its tags.

Rule 2 in Dating

“No one is shown as open to dating unless their own tags say so.” Dating reads each person’s own intent_tags, in the entry of the Pool they joined, and shows them only when dating is there. Being in a dating Pool is not enough, and a page is not read for it. Where both pages say who they are looking for, Dating also shows people only to someone they are looking for, who is looking for them; where a page does not say, the card says so.

The build checks this on the Dating room as the app itself deals it, for each of the 5 viewers whose own tags say dating, with every layer on and every unlisted address added: 60 different people are dealt, and none of them lacks dating in their own tags. Anywhere else, a card lists a person’s own tags as theirs, and that may include dating, because that is them saying so; it never adds a “looking for” line, dating answers or “Yes, a date”.

How a yes travels

The Pool’s way, and each person’s

The reading

Compatibility, in full

Dating: the eighteen questions

For every question you both answered: the same answer earns its full weight, a close answer earns half, a different answer earns nothing. A lot counts 3, a little counts 1, not at all counts 0. Your reading is what you earned out of what was possible. A question either of you left blank is skipped and never guessed. You set the weights; the other person sees their own reading, with theirs.

Every other room: only what both of you have

Outside Dating, most people have no answers, no age and no gender anywhere. So the reading uses only fields both people actually have, one line each, and prints every blank line with its reason. Each line earns 1, ½ or 0; what you share is points divided by the lines you both have.

Safety that travels

The block lists we honor

Both of our Pools subscribe to the same two lists, and every message and request you send is checked against them §7.3.

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 an app like ours.

1. No message for interest. v0.1 has handshake, intro, reply, withdrawal and system messages, and nothing for “I would like to hear from you”. So a yes is app-local: a yes given in Heartwood stays in Heartwood, and yeses made in other apps cannot reach us. A note sent with a yes is an intro, and it goes only if the recipient’s rules allow it.
2. No message for asking a curator to introduce you. Where a Pool introduces through its curator, Heartwood sends an ordinary intro addressed to the curator, through the Pool. Nothing in v0.1 marks it as a request, or lets the curator answer with a proposal the app can read.
3. No field for a room. Intent tags are free words, so which room a Pool fits is our reading of its tags. The table above prints that reading, Pool by Pool. A Pool whose tags fit none of our rooms still opens, under its own name.
4. No field for a verb. A Pool cannot say what a yes in it is for. Where a charter says it (“ask to borrow”, “write a letter”), our yes uses its words; elsewhere it says hello.
5. No field for pace. Correo Lento’s one letter a week, and its co-op holding every first letter, live in its charter and rules. We honor them by reading the words, because no field carries them.
6. No way to prove a membership an app cannot read. Midspan Students is invite-only, so no app can know who is in it. A student’s yes to a mentor goes to a coordinator, who checks. Heartwood never asks, and never guesses.
7. Age, gender, seeking and answers are not in the parsed profile. parsed_profile.schema.json has no fields for them and forbids extra properties. Where a page has them, we read them from the page §2.5. The eighteen questions are a shared convention among the apps, not part of v0.1. Most people outside Dating have none of these, and their cards say so.
8. Several pages, one person. A person may keep a separate page for one Pool, as Priya Raman and Wes Adeyemi do for mentoring. v0.1 links them only by identity. A card shows the page the person joined that Pool with, and lists other rooms only from that same page.
9. Compatibility has no standard. What counts as close is our convention, printed here and on every reading. Another app may read the same fields differently, and should say how.
10. Linked partners. v0.1 cannot say two profiles are partners. A household keeps its own unlisted Pool, with every member as a curator, and a member may link it on their card. Only a curator can vouch, so partners cannot vouch for each other elsewhere.
11. Four names for levels. §4.5 names email-verified, oauth-verified, curator-vouched and unverified. The schemas use email, oauth, curator-vouched, unverified and cryptographic. Our JSON follows the schemas.
12. The handshake window. §5.2 says the 14 days are “configurable per Pool”. The manifest has no field for it, so each request carries expires_at, and our governance rules say 14 days.
13. Extraction provenance. §2.3 names an extraction_source field. The parsed profile schema has none and forbids extra properties.
14. Six message types, not four. §6.3 lists four types. kindling_message.schema.json has six, adding withdrawal and system. We send withdrawals as withdrawals.
15. The version field. §12.1 names kindling_version; every schema uses schema_version. Our files follow the schemas.
16. Noindex is not privacy. kindling_noindex: true keeps a page out of every Pool §2.7. Privacy inside a Pool comes from visibility, which is how Queer Harbor and Intentional Co-Parents stay unlisted.
17. Thanks after it works. Gratitude after an introduction is a v0.2 draft with no field or message yet. Our support comes once a year, outside the protocol.