How Face Up is built on Kindling

Three layers, one Pool

Belay Partners, three ways

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 it. Every Face Up card links back to the other two, and any Pool opens here: this one in the Climbing deck, a seed swap under its own name.

{
  "schema_version": "0.1",
  "id": "drip-line-belay",
  "name": "Belay Partners",
  "intent_tags": [
    "climbing",
    "belay",
    "partners"
  ],
  "visibility": "public",
  "consent_model": "vouching-required",
  "charter": "Climbers who passed a staff belay check at Drip Line and would like to be asked to climb, most often on Saturday mornings. …",
  "curator": [
    {
      "display_name": "Pilar Echeverría",
      "verification_level": "oauth"
    },
    {
      "display_name": "Emil Kowalczyk",
      "verification_level": "oauth"
    }
  ],
  "entries": "6 entries; one of them:"
}
{
  "profile_url": "https://beto-aguilar.carrd.example",
  "verification_level": "curator-vouched",
  "parsed_profile": {
    "display_name": "Roberto “Beto” Aguilar",
    "pronouns": "he/him",
    "location": {
      "city": "Seattle",
      "region": "Washington",
      "country": "United States"
    },
    "intent_tags": [
      "bouldering",
      "climbing",
      "belay",
      "friendship"
    ],
    "about": "Electrician. At the bouldering wall most Tuesday nights, and glad to catch anyone on a rope on Saturdays. Leads 5.10 and falls off 5.11 cheerfully.",
    "messaging_preferences": {
      "accept_from": "shared-pool",
      "no_cold_messages": false,
      "minimum_curator_verification": "email"
    }
  },
  "consent_proof": {
    "handshake_id": "hs-drip-line-drip-line-belay-beto",
    "accepted_at": "2025-10-15T02:10:00Z",
    "method": "curator-vouching"
  }
}

Decks

Shortcuts, and what each gathers

Every Pool in the library, and where it opens in Face Up, is in the table on our About page.

How a Pool opens under its own name

1. Open a Pool from “Open a Pool”, beside the decks, or load a product, or paste an unlisted Pool’s address. The address bar says what is open: #pool-seed-swap, or #load-board.
2. Face Up puts each of its Pools in the deck that gathers it. The rest go together into one deck named for what you opened: the Pool, or the product.
3. Each card still names its own Pool, a line of its charter and its tags. The yes names the Pool, in its own verb where its charter gives one, and never in a dating word unless the Pool is tagged dating.
4. A resting Pool opens and says it is resting. Nobody in it is hidden for it.

Rules

Two rules

These are the only rules Face Up claims. What else a reader owes a Pool is in the spec, cited below, and in each Pool’s own words.

1. Every card shows the Pool’s name, charter and tags. Every card, in every deck and under every own name, carries the Pool it came from: its name, one line of its charter and its tags, with its visibility, its curator and links to the Pool on its own site and to its JSON. So does every card on “Yes to you”, and the two cards that turn when you both say yes.
2. No one is shown as open to dating unless their own tags say so. The Dating deck deals only people whose own intent_tags include dating: the tag itself, not a Pool they are in. So Tamsin and Anouk in Harbor Counties, who are friends first, and Nadia, a matchmaker, are never in it. It holds for you too: if your own tags don’t say dating, the Dating deck deals you nobody and deals you to nobody. The build checks this against the deck the app actually deals, and stops if it fails.

What the spec asks of every reader

• Visibility. An invite-only Pool is never read. An unlisted Pool is read for someone who is in it, or who pastes its address; Drip Line’s Thursday Pool asks members to add it themselves, so we wait for the paste. §3.2
• Messaging and introductions. KindlingDemo.canMessage runs Pool by Pool, with each Pool’s address, its members and its own sender floor, against each person’s own rules, and the card shows every answer in words. consent_model says how people join; where a Pool’s charter or governance says introductions go through a curator or steward (Midspan Mentors, Late Supper’s tables, Hearthhold’s stewards, Seen Work’s Harbor Trades, Meals When It’s Hard), a yes is a request to them. §7
• A Pool’s own words. Correo Lento’s Pools are slow letters, by email, one a week at most, and the co-op holds every first letter until both people say they would like to write: there a yes is “Write a letter”. The Orchard Street Household is listed “so the people we date can see how we are connected”, so Face Up shows it for context only, with no yes. Foul Weather Friends asks apps not to read the Check-In Circle, so we don’t. §3.2
• Pictures. Drawn from each person’s own page by the shared portrait renderer, seeded by their id, and never copied. A page with no picture is dealt as a letter, the way its Pool’s own site shows it. §2.5

Settings

What we chose, and why

Our Pool

Face Up: Cascadia

Face Up is for people dating in Cascadia, from Eugene to Vancouver, who like to see a face first. Right if you would like to hear from someone, left if you would not, and when you both go right, you can write. Every face here has been checked by our trust desk against a live selfie, so the person in the photos is the person who said yes. Photos stay on your own page and we show them from there. Nobody pays to be seen, and nobody pays to see who liked them.

{
  "schema_version": "0.1",
  "pools": [
    {
      "manifest_url": "https://faceup.example/pools/face-up-cascadia.json",
      "name": "Face Up: Cascadia",
      "intent_tags": [
        "dating"
      ],
      "visibility": "public",
      "status": "active",
      "geographic_scope": {
        "region": "Cascadia"
      },
      "last_updated": "2026-09-27T21:40:00Z"
    }
  ],
  "operator": {
    "name": "Face Up, an app that plays its cards face up",
    "contact": "hello@faceup.example",
    "url": "https://faceup.example"
  }
}

Discovery

How a deck is dealt

1. Read every .well-known/kindling-pool file we know of §8.3, and keep every public Pool, resting ones too. Add an unlisted Pool only for someone who is in it or pastes its address §3.2. Never an invite-only one, and never one its site asks apps not to read.
2. Fetch each manifest, check it against the schema, and check its major version §12.2.
3. Drop anyone whose page says noindex §2.7, anyone on a block list we honor §7.3, and anyone you blocked.
4. Put each Pool in the deck that gathers it by its tags, and the rest under their own names. For the Dating deck, keep only people whose own tags say dating, and read each one’s own page for age, gender, pictures, prompts and answers. Everywhere else, use the parsed profile in the Pool file, and a page’s job, languages and interests only where the Pool lists that page. Keep none of it.
5. For dating, filter by who you’re looking for (and who’s looking for you), age and distance between rough city centers, and never on a field a page leaves blank. Elsewhere, choose which of the deck’s Pools to read. Every filter is free.
6. Put them in the order you chose for that deck, with the count of cards left on the screen.

Safety that travels

The block lists we honor

Sample messages this app sends, validated against the schema: hello-simone-to-tomas.json · withdrawal-keisha.json · hello-fatima-to-beto.json · request-ruben-to-fina.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.

1. A yes has no message (§6.3, §7.2). The spec’s message types are handshake-request, handshake-response, intro and reply; the schema adds withdrawal and system. None says “yes, let’s climb” or “I like you”. So a Face Up yes lives only in Face Up, in one deck: other apps can’t see it, and we can’t see theirs. Two yeses are ours to record, and we treat them as the confirmed mutual interest that no_cold_messages asks for.
2. A request to a curator has no message of its own (§6.3). Where a Pool’s curator introduces people, Face Up sends the curator an intro message through that Pool, with the person’s name in the words. Nothing in the envelope says “please introduce me to this entry”, so the curator reads it as a person would.
3. Intent tags are free text (§3.2). Our decks gather Pools by their intent_tags, which have no shared vocabulary. We publish the tags each deck gathers, above. A Pool none of them names still opens, under its own name, so a free-text tag never keeps a Pool out of Face Up.
4. A site’s word about its own Pool has no field (§3.2, §10). Foul Weather Friends asks apps not to read the Check-In Circle. A manifest can say unlisted, not “please don’t read this”; the request lives in its governance rules, and we honor it the way a browser leaves a site alone that asks not to be read.
5. “For context only” has no field (§3.2). The Orchard Street Household is listed “so the people we date can see how we are connected”. Nothing in the manifest says a Pool takes no introductions; its charter says it, and we read the charter.
6. “Members add it themselves” has no field (§3.2). Drip Line’s Thursday Pool is unlisted and asks members to add its address to an app themselves. The manifest can say unlisted, not that; it lives in the governance rules, and we read them.
7. A curator route has no field (§5.4). Whether a yes should go to the curator is in each Pool’s charter and governance rules, in words. vouching-required sometimes means a check at the door and sometimes an introducer for every meeting. We read the words, Pool by Pool, and say what we decided in the About page’s table.
8. A personal block can’t travel yet (§7.3). Block lists are for known abuse, published by the project or a third party, and every client subscribes. A person’s own block has no message and no list of its own. We keep yours on the other person’s Kindling identity, and point out that your email can hold it too.
9. Pages say more than the parsed profile (§2.4). Age, gender, pictures, prompts and answers aren’t fields in parsed_profile.schema.json. We read them from each person’s own page at display time and never copy them, which is also what §2.5 asks for pictures. Outside dating we show only a page’s job, languages and interests, and only when the Pool lists that very page.
10. Verification level names (§4.5). The spec text says email-verified, oauth-verified, curator-vouched and unverified. The schemas use email, oauth, curator-vouched, unverified and cryptographic. Our JSON follows the schema; the screen shows words.
11. A vouch is per Pool, and the entry says so (§4.4). Entries carry curator-vouched for our face check and for Drip Line’s belay check, but a parsed profile’s own verification repeats it without naming the Pool. An app that copied that field into another deck would overstate it. We show the level only beside the Pool it belongs to.
12. The handshake window (§5.2). The spec says 14 days, “configurable per Pool”. The manifest has no field for it, so our requests carry it in expires_at and our governance rules say so.
13. Where a field came from (§2.3). The spec asks parsers to record h-card versus inferred fields in extraction_source. The parsed-profile schema has no such field and forbids extra ones.
14. The Pool reference and the version field (§6.2, §12.1). The spec says pool_ref and kindling_version; the schemas say via_pool and schema_version. We use the schema’s names.
15. 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 and a no_cold_messages flag, and only a Pool can set a sender minimum.