How two names meet

Every .aint answers a stranger with silence. So how do two people who were never introduced actually find each other, prove who they are, and become known — without a directory, without leaking, and without trusting too soon? They agree on a word, knock on a hatch only they can find, and consent face to face.

The lifecycle

A meeting is not one event; it is a short walk through states. Nothing is a relationship until both sides say yes — and if either doesn't, everything falls back to nothing.

  t-1  no relation ................ two strangers, not routable to each other
   │
  t0   BEAMER ..................... one side opens a temporary hatch ("beam me up")
   │       a blind meeting point, alive only while their attestation is fresh
   │
  t1   KNOCKER .................... the other knocks with the code + a fresh proof
   │       posture = .paint:knocker  →  proven, but NOT admitted, and NO route yet
   │
  t2   CONSENT ..................... both see a 6-digit confirm + who is at the door
   │       "henk.aint wil connecten — mutually wanted?"   accept / reject
   │
  t3   RELATION .................... both accept → a private lane materialises,
   │       sealed as a Causal Action Receipt (the meeting becomes a fact)
   │
   └─ reject / timeout / wrong proof → back to t-1: the hatch closes, nothing lingers

The rendezvous — a hatch only you two can find

You don't publish an address. You and the person you want to meet agree, out of band, on a short phrase — "yes aardbeien". Each device derives the same blind hatch from it, mixed with a fresh, high-entropy value the attestation carries and a time window:

rendezvous = Hash( fresh_attested_nonce ‖ spoken_code ‖ time_window ‖ domain )

To the world that hatch is noise. The two devices know exactly where to knock; nobody else can tell it is even there. The high-entropy nonce — not the weak phrase — is the real anchor, so the hatch can't be walked with a dictionary. And because the nonce lives only as long as the attestation is fresh, the meeting point self-expires: stop being live and the address simply dies. Beam me up, Scotty — findable exactly while you are present.

idPACE — the word proves itself without being shown

The phrase is never sent. It is the password to a balanced PAKE (a password-authenticated key exchange — the same family that protects passport chips): both sides do a little elliptic-curve maths seeded by the word and arrive at the same secret without that secret, or the word, ever crossing the wire.

We call the reference build strawberry-hellman; the production target is the CPace / PACE family (the standard balanced PAKE, and the very crypto used in electronic passports). Same shape, named primitive underneath.

Role, posture, identity — three different things

The handshake keeps strictly separate what most systems blur together. That separation is the whole reason a guessed code can't promote a stranger.

Consent — the human moment

Crypto proves who; it cannot decide whether you want them. Before any route exists, both sides see a short 6-digit code (read it aloud — if they match, there is no one in the middle) and who is at the door:

  ┌─────────────────────────────────────────┐
  │  henk.aint wil connecten                  │
  │  confirm code:  041 829                   │
  │  device attestation:  fresh ✓             │
  │                                           │
  │        [ reject ]      [ accept ]         │
  └─────────────────────────────────────────┘

Accept and the lane is born. Reject — or just wait — and it all returns to t-1. No half-trust, no lingering route, no "we sort of connected once."

The meeting becomes a fact

When both accept, the relationship is sealed as a Causal Action Receipt — a signed step that extends a grounded parent, so the meeting isn't a loose handshake but a provable point in each party's history. Every later action on that lane extends the chain from there.

What can be public

The shape is safe to publish — it is the property other implementers need to build against, not a secret.

What a verifier checks

• The knocker's proof verifies against an attested key, inside the PAKE channel.
• The attestation is live (not a stored token) and binds the presented .aint.
• The key resolves to the claimed name — and, if expected, it is the name you meant.
• Both sides confirm the same SAS; both explicitly accept.
• Only then is a route key derived and a receipt sealed; otherwise: 0x0000.

For AI agents

This page is the human "why & how". The machine map — what to read, which minimal package path fits the job, and the operating rules — is one safe curl away:

curl -s https://ainternet.org/ai-scan.json
curl -s https://ainternet.org/upip.json

The shortest rule for any actor — human, AI or device:

find at the hatch -> prove the word (PAKE) -> exchange .aint -> consent (SAS) -> seal receipt