Skip to content

Every choice that is yours

Quo asks, and every kit answers.

KIT-SPEC.md is every choice SPEC.md leaves to a kit, put as a question, and Quo answers none of them. Under each question here, the five example kits' answers stand folded, so you can decide with five worked answers in view and still owe none of them.

KIT-SPEC.md on GitHub
GoZigPythonJavaScriptRust
01

The same wall, a different house.

SPEC.md fixes the bytes and leaves 28 choices to a kit. A kit answers every one in a document of its own, beside its code. A question a kit leaves unanswered is a hole in that kit and not in Quo.

The wall and its gap are the same in every kit, because that is all Quo says. What lives inside is each house's own, and these are its choices.

Under each question below, the 5 example kits' answers are folded, each from the kit's own ANSWERS.md. Where two kits answer differently and still speak to each other, the difference is the kit's, and Quo allows it.

KIT-SPEC

This is every choice SPEC.md leaves to a kit. Each is a question. A kit answers every one in a document of its own, beside its code. A question a kit leaves unanswered is a hole in that kit and not in Quo.

An answer below is never a departure from Quo. The verifier accepts every answer below.

Every term is the term SPEC.md defines. A chapter named here is a chapter of SPEC.md.

What stands behind a door

  • Question 1. What stands behind a door, and how does the kit hand it an arrival? The opening of SPEC.md leaves what stands behind a door outside Quo. It may be nothing, one thing, or many.
    How the 5 example kits answer question 1
    Go

    What stands behind a door. One Target per heir and one per ward for the zero head. A target is a Go function handed the method and the args’ bytes as they arrived. It answers silence, or an object with its seen and any addresses its reply’s at carries. The kit provides five, echo, marked, moved, null and silent, the names vectors/HARNESS.md sends. Reason: a function is the smallest thing that can stand behind a door, and the harness names nothing more.

    Zig

    A Reach, one of the five behaviours the harness names: echo, marked, moved, null and silent. The door hands it two things: whether the ask is named, and the bytes of args as they arrived, if present. It gives back a reply text, or null for a chosen silence. Reason: this kit exists to be judged, and the harness names nothing else. A hook for arbitrary code would add a second interface with no second user.

    Python

    What stands behind a door. A reach: a function from the well-formed payload to a reply text, or to None for silence. The kit holds five, echo, marked, moved, null and silent. It hands the reach the payload after the door has chosen to answer. Reason: the harness names these five, and one function shape is enough for all of them.

    JavaScript

    Behind a door stands one synchronous function per heir, and one for the zero head. The door hands it { method, args (raw JSON text), unread, by, heir }, and the function returns { object: raw JSON text, seen, at? } or null for silence (lib/quo.js, reaches). unread is true where this kit does not read args (question 27).

    Rust

    Behind each ward’s door stands one reach for each heir, and at most one more for the zero head, named when the heir or the ward is made. A reach is one of the five of vectors/HARNESS.md: echo, marked, moved, null and silent. An arrival is handed over as named, whether method is present, with the raw bytes of args and their depth. The reach returns a reply text or silence, and never sees the relation’s number or keys. The reason is that the harness names these five and nothing more. A reach is the least a door can stand behind it and still be driven.

  • Question 2. How is what constructed a ward reached, and can that edge be taken away? Whatever makes a ward holds its seed. How the kit gives the things behind the door a way back to what made them, and whether any path removes that way, is the kit’s. None of it crosses a door.
    How the 5 example kits answer question 2
    Go

    The way back to what made the ward. None. A target is a plain function, holds no reference to the ward or the kit, and nothing removes what was never given. Reason: no target here needs one.

    Zig

    The stand program constructs every ward and holds it in one map, keyed by the raw ward pk. What stands behind a door has no way back to it. A reach is a pure function of the arrival. Nothing needs to be taken away because nothing is given.

    Python

    The way back to what made a ward. None. A reach gets the payload and nothing else. The Ward object holds its own seed, and only the program that built it can reach it. Reason: nothing behind the door here needs a way back.

    JavaScript

    The ward holds its own keys. The things behind the door get no handle back to the ward, and nothing removes one because none is given.

    Rust

    Nothing behind a door has a way back to what made the ward, so no path takes that edge away. The seed is hashed once when the ward is stood and dropped. Only the derived keys stay in the Door, and the program that stood the ward holds the door in its map. The reason is that a reach needs no such edge, and what is never made needs no removal.

  • Question 3. What answers the zero head, and does anything? What may answer there, where the same sealed bytes are answered every time they arrive? The zero head chapter leaves both to the door. With nothing answering it, an ask on the zero head is case 4.
    How the 5 example kits answer question 3
    Go

    The zero head. The target named by reach on ward, one per ward. Without it nothing answers, and every zero-head ask is case 4. The door keeps nothing for the zero head: no signing key, no edge key, no number. So the same sealed bytes presented twice are answered twice, each answer sealed to the one lid those bytes carry. Reason: the harness fixes the target, and a head that names no relation has nothing to keep.

    Zig

    The reach given on ward, if there is one. With no reach, nothing answers the zero head, and every ask on it is case 4. The zero head keeps nothing: no key, no count and no record of any box. So the same sealed bytes presented twice are answered twice, and the second answer is written from the arrival alone. Reason: a reach is a pure function of the arrival, so there is nothing a second presentation could be weighed against.

    Python

    What answers the zero head, and does anything. The reach named by reach on ward answers it. With none named, nothing answers, and an ask on the zero head is case 4. The zero head holds no relation, so the door keeps no number for it and reads none. The same sealed bytes presented twice are answered twice, each under a fresh reply ephemeral. Reason: the harness names the reach. A door that kept a number for the zero head would keep one for every stranger who ever sent one.

    JavaScript

    Nothing answers the zero head unless the ward is made with a zero function, and then that one function answers every zero head ask. The harness sets it from reach on ward. A ward made without one refuses every zero head ask as case 4, because this kit gives no way to add one later. The zero head keeps no relation. So the same sealed bytes presented twice are answered twice, each time from a fresh reply ephemeral.

    Rust

    The reach given on ward answers the zero head, and a ward holds at most one. Without one, nothing answers, and a zero-head ask is case 4. The same sealed bytes presented twice are answered twice, because the zero head keeps nothing: no key, no number and no record of an arrival. The reason is that the zero head is the one head a door holds no relation for. It has nowhere to remember a box it saw before.

  • Question 4. How many asks does a door judge at once? Whatever the number, the door admits by what holds when it makes its choice. A knock is admitted only on an heir still fresh. An ask is admitted only under a key the door holds or vouches for. The keys move as the move chapter says.
    How the 5 example kits answer question 4
    Go

    Asks judged at once. One. A single mutex holds every door and every standing, so each arrival, from arrive or from any listener, is judged alone and checked once. Reason: the second check buys nothing when nothing races.

    Zig

    One. One process-wide mutex covers every door, every standing, and every listener thread. So one check is enough. Reason: correctness is simple to see, and the harness never measures throughput.

    Python

    How many asks judged at once. One. One lock guards every door and every standing in the program, whether the ask comes from arrive, from the TCP listener or from the post. The door therefore checks once. Reason: this is the simplest correct choice, and Python’s crypto here is fast enough.

    JavaScript

    One. Ward.arrive is synchronous from opening the box to moving the keys. Two arrivals at one moment are so judged one after the other, and the key a choice is made under is the key the door held when it made it. This is the cheapest answer that keeps the move’s tables true, and it needs no lock.

    Rust

    One at a time. Every arrival runs under one mutex, so the door checks once and the keys move once. The reason is that this is the least that keeps the move chapter true. A kit that judges one at a time answers two sent together as it answers two sent apart.

  • Question 5. What does the kit call its parts, and its relations? No name a kit gives crosses a door.
    How the 5 example kits answer question 5
    Go

    Names. Kit, Ward, Heir (the occupant’s relation), Standing (the standing’s relation), Sent (one sealed ask), Target, Read. A relation at the door is named by the name invite gave; at the standing by the asking ward, the far ward pk and the heir pk. The carriers’ parts are address, frame, dialed (a line a dialer holds) and wsConn (one end of a held line).

    Zig

    Door is a ward’s door. Heir is one relation at the occupant’s end. Standing is one relation at the standing’s end. WardKeys is the key material derived from the seed. Stand is the harness program. The harness’s heir names are only strings in a map beside the heirs, which are keyed by heir pk.

    Python

    Names. Ward, Heir, Kept (the keys kept at removal), Standing, Listener and dial for TCP, PostListener and post for the post, and Address for an address it stands. A heir is named by the harness string, and a relation by its heir pk. Reason: they mirror SPEC.md’s words.

    JavaScript

    The parts are Ward, Standing, arrive, invite, release. A relation is keyed by its heir pk in hex.

    Rust

    Door, Standing, Invitation, Reach and Read. A relation is a Heir entry keyed by heir pk on the door’s side, and a Standing keyed by the asking ward with the whole invitation on the asker’s side. The reason is that no name a kit gives crosses a door. Each name is chosen for the reader of this code.

What a kit keeps

  • Question 6. How are a ward’s seed and its lock handed in and held? How and when is the lock made, and how many locks does a ward hold? Does the ward keep an heir’s secret after it gives the invitation? The lock’s encapsulation key travels in every invitation, and a knock’s ciphertext is to the lock in the invitation it came from.
    How the 5 example kits answer question 6
    Go

    Seed and lock. The seed is text from ward, hashed with SHA-256, and is not kept once the ward’s keys are derived. The lock is drawn with mlkem.GenerateKey768 when the ward stands, once. The ward keeps the heir pk and never the heir secret: it is drawn, put in the invitation, and dropped. Reason: what is not kept cannot leak.

    Zig

    The seed arrives as text on ward. It is hashed and derived at once, and only the derived keys are kept, in memory. The lock is made at the ward’s first invite, from sixty-four drawn bytes, and is held in memory for as long as the process runs. A ward holds one lock, and every invitation it gives carries that lock’s encapsulation key. Reason: one lock is all a door needs to open every knock, and a second would be a second key to keep. The heir secret is not kept. The door keeps only the heir pk. Reason: the relation chapter asks for no more, and keeping the secret would let the occupant sign as its own standing.

    Python

    Seed, lock, heir secret. A text seed is hashed with SHA-256, and the ward keeps the derived signing seed and X25519 scalar in memory. The lock is sixty-four drawn bytes, d || z of FIPS 203, made at the ward’s first invitation and kept in memory. The ward does not keep a heir’s secret after it builds the invitation. Reason: a ward has one lock, and drawing it lazily costs nothing. The heir secret travels to the standing inside the invitation; a ward keeping it could knock on its own heir as the standing, and its occupant needs only the heir pk.

    JavaScript

    The seed is handed in as 32 bytes, or as text or bytes that get hashed. It is held in memory as derived key objects only. The lock is drawn when the Ward is constructed and is held in memory. The ward does not keep a heir’s secret after giving the invitation.

    Rust

    The seed arrives as text on the ward request and is hashed to thirty-two bytes. The lock is made from drawn bytes when the ward is stood, one lock per ward, and is held in memory alone. The ward does not keep an heir’s secret after it gives the invitation. The reason is that a knock’s ciphertext is to the lock of the invitation it came from. One lock per ward therefore answers every invitation that ward minted. The heir secret is the holder’s from then on.

  • Question 7. Where do drawn bytes come from? An heir secret, an ephemeral secret, a lock and an encapsulation each draw bytes. The source is the kit’s.
    How the 5 example kits answer question 7
    Go

    Drawn bytes. crypto/rand for heir secrets, ephemeral secrets, lids nobody holds and the lock; crypto/mlkem draws its own for encapsulation. Reason: the operating system is the only honest source.

    Zig

    arc4random_buf from libc. The kit’s own tests use a fixed SplitMix64 stream instead, so their runs repeat.

    Python

    Drawn bytes. os.urandom, for heir secrets, ephemeral secrets and the lock seed. The library draws its own bytes for encapsulation. Reason: the operating system’s source is the right source.

    JavaScript

    node:crypto randomBytes, and Node’s ML-KEM for the lock and each encapsulation.

    Rust

    /dev/urandom, read with the standard library. ML-KEM key generation and encapsulation take those bytes through the crate’s deterministic entry points. The reason is that the operating system is the one source this kit trusts without carrying a generator of its own.

  • Question 8. What does a door keep for a relation, and in what? What it holds is fixed by the keys of a relation. Where it holds it, and whether it survives a restart, is the kit’s.
    How the 5 example kits answer question 8
    Go

    What a door keeps. In memory, per heir: its pk, fresh or spent, released or not, the key held, the key vouched for, the open and offered edge keys, the highest number honoured and its target. Nothing survives a restart. Reason: the harness names no restart, and a door that forgets departs from nothing.

    Zig

    Per heir: the heir pk, its reach, whether it is fresh, whether it was removed, the held key, the vouched key (optional), the open and offered edge keys, and the highest honoured number. It is all in a hash map in process memory. Nothing survives a restart.

    Python

    What a door keeps. For each heir, in a Python object in memory: the key held, the key vouched for, the open and offered edge keys, and the highest number honoured. Nothing survives a restart. Reason: this is an example kit, and SPEC.md fixes what is held but not where.

    JavaScript

    In memory, in a Map, per heir: fresh, or H, V, O, F and the highest honoured number. Nothing survives a restart.

    Rust

    For each heir, in a map in process memory: fresh, or spent with the held key, the vouched key, the open and offered edge keys, and the highest number honoured. None of it survives a restart. The reason is that the keys of a relation fix what is held. A program the harness starts and stops has nothing to gain from a store on disk.

  • Question 9. When does a door stop holding an heir, and what asks it to? The relation chapter says only that a door may.
    How the 5 example kits answer question 9
    Go

    When a door stops holding a heir. Only on release. The name is freed at once and may be invited again as a new heir.

    Zig

    Only release. A fresh heir is forgotten entirely. A spent heir is marked removed, and its keys become the keys kept at removal.

    Python

    When a door stops holding a heir. Only on the harness’s release. Reason: nothing else in this kit asks for it.

    JavaScript

    A door stops holding a heir when release is called (the harness release op).

    Rust

    A door stops holding an heir when release names it. A fresh heir is forgotten entirely, since it bound nothing and no ask under it could hear removed. A spent heir’s keys move to a map of keys kept at removal, so an ask signed by one still hears removed.

  • Question 10. How long are keys kept at removal kept? Until then, an ask signed by one hears removed. Afterwards it hears silence.
    How the 5 example kits answer question 10
    Go

    Keys kept at removal. For as long as the program runs. Every ask by one of them, under a kept edge key, hears removed.

    Zig

    For the life of the process. So a removed relation hears removed until the program exits.

    Python

    How long keys kept at removal are kept. For as long as the program runs. Reason: removed is more useful to the other end than silence.

    JavaScript

    Keys kept at removal are kept for the life of the process.

    Rust

    For the life of the process. The reason is that the process is the whole life of every relation this kit keeps. Nothing outlives it, and a shorter term would answer no question the verifier asks.

  • Question 11. Which count numbers below the highest honoured does a door still honour? None, some, or all that were not seen. A number the door does not honour hears repeated.
    How the 5 example kits answer question 11
    Go

    Numbers below the highest. None. Every number at or below the highest honoured hears repeated. Reason: one integer per relation, no window to keep.

    Zig

    None. Every number at or below the highest is answered repeated. Reason: this needs one integer per relation, and so no choice is ever made on a number below the highest, the choice that moves no key.

    Python

    Numbers below the highest honoured. None. A number at or below the highest honoured hears repeated. A knock’s number, any count number, sets the highest. The door therefore never makes a choice below the highest, and every choice moves the keys. Reason: this keeps one integer per relation and makes a replay plainly visible.

    JavaScript

    None. Only a number above the highest honoured is honoured, so every choice this door makes on a spent heir moves the keys.

    Rust

    None. Only a number above the highest honoured is honoured, and every other hears repeated. The reason is that the highest is one number to hold. The set of numbers seen would grow without bound.

What a kit answers

  • Question 12. Does the door answer, and when does it give nothing? Silence is bytes the door wrote. Nothing is no reply, and means not delivered.
    How the 5 example kits answer question 12
    Go

    Does the door answer. Always, with a reply. A listener gives nothing only for a ward pk the program does not stand: a nothing frame on tcp and the held line, status 204 on the post.

    Zig

    The door always answers. Every arrival gets a reply box: a stranger’s silence, a word, or a choice. Nothing is given only by the carrier: a nothing frame for a ward pk this program does not stand.

    Python

    Does the door answer. Always, with a reply box. The door gives nothing only when there is no ward under the pk, which on TCP is a 02 frame and on the post status 404. Reason: silence is bytes, and the kit has no cause to withhold them.

    JavaScript

    The door always answers with bytes. It never gives nothing, because silence already says nothing and costs the asker no retry. A carrier gives nothing only where no door answered: an unknown ward pk, or a door that throws. Over TCP and the held line that is a 02 frame with the ask’s id. On the post it is status 404 for an unknown ward pk and 204 for a door that throws. A post that is not an ask hears 405, 400 or 413.

    Rust

    The door always answers, with a reply for every arrival. A stranger’s silence and a box that does not open are answered too. A reply to an ask whose lid takes no seal is sealed to a lid nobody holds. The carrier gives nothing only where the listener stands no ward under the pk, and writes frame 02 there. The reason is that a door which answers everything puts no case on the wire.

  • Question 13. How is seen made, and when does it change? Only the answering side makes it, and null is one mark among the rest. A seen different from the one its asker heard before means the describe that asker would hear has moved.
    How the 5 example kits answer question 13
    Go

    seen. null, except behind marked, which writes "1" on every ask, the empty ask included, as the harness fixes. Neither ever changes, and neither does the describe.

    Zig

    The kit does not make one. seen is null, except under the marked reach, where every ask gets "1", the empty ask included, as the harness fixes. No seen ever changes, and no describe here ever moves.

    Python

    seen. Always null, except "1" from marked on every ask, the empty ask included, as the harness fixes. Reason: nothing behind these doors moves, so no seen ever changes.

    JavaScript

    seen is whatever the function behind the door returns: null for echo, moved and null, and "1" on every ask for marked, the empty ask included. None of them ever changes it, and none changes its describe.

    Rust

    The kit writes null, except for the marked reach, which writes "1" on every ask, the empty ask included. The reason is that the harness fixes the seen of every reach. No reach ever changes its seen, and no describe here ever moves.

  • Question 14. What does the empty ask answer, and to whom? A describe as the object, or silence. Which entries it lists, whether two askers hear two describes, and which lang it names, if any, are the kit’s. So is what an entry’s description and args say, and what a door answers a named ask that no entry names.
    How the 5 example kits answer question 14
    Go

    The empty ask. Behind echo, marked, moved and null, the describe {"asks":[]}, the same to every asker and with no lang. Behind silent, silence. So no entry names any named ask, and each target answers one as the harness fixes. echo, marked and moved answer its args, null the object null, silent silence.

    Zig

    Under echo, marked, moved and null: the describe {"asks":[]}, the same to every asker and with no lang. Under silent: silence. So no entry names any named ask, and each reach answers one as the harness fixes: echo, marked and moved its args, null the object null, silent silence.

    Python

    The empty ask. echo, marked, moved and null answer the describe {"asks":[]}, the same to every asker and with no lang. silent answers silence. So no entry names any named ask, and each reach answers one as the harness fixes: echo, marked and moved its args, null the object null, silent silence. Reason: the harness says so.

    JavaScript

    For echo, marked, moved and null, the describe {"asks":[]}, the same to every asker and with no lang. For silent, silence. So no entry names any named ask, and each function answers one as the harness fixes: echo, marked and moved its args, null the object null, silent silence.

    Rust

    With echo, marked, moved and null, the object is the describe {"asks":[]}. It is the same to every asker and names no lang. With silent, silence. The reason is that the harness lists no method a reach answers, so the describe lists none. So no entry names any named ask, and each reach answers one as the harness fixes: echo, marked and moved its args, null the object null, silent silence.

  • Question 15. How is a reply text other than silence written? The field order of { object, seen, at? } and the whitespace between tokens are the kit’s. Silence alone is fixed to sixteen bytes.
    How the 5 example kits answer question 15
    Go

    Reply text. {"object":<value>,"seen":<seen>}, in that order, with no whitespace of its own. Where the target hands addresses, ,"at":[...] follows seen, each address quoted, in the target’s order. echo writes the args’ bytes exactly as they arrived, whitespace included. A word is {"quo":"<word>"}.

    Zig

    {"object":…,"seen":…}, in that order, with no whitespace of the kit’s own. Under moved, ,"at":[…] follows seen. Under echo, marked and moved, the object is the bytes of args exactly as they arrived, inner whitespace included. A word is {"quo":"…"}.

    Python

    Reply text. {"object":<object>,"seen":<seen>} with no whitespace between the kit’s own tokens, and ,"at":[...] before the closing brace where the reach gives an at. From echo, marked and moved, object is the bytes of args exactly as they arrived. A word is {"quo":"<word>"}. Reason: the shortest form, and echo keeps the bytes.

    JavaScript

    {"object":<raw>,"seen":<seen>}, or {"object":<raw>,"seen":<seen>,"at":[...]} where the function gives an at, with no whitespace outside the raw object, and words as {"quo":"<word>"}. The raw object is written as it arrived or as the function made it, and is not parsed again.

    Rust

    {"object":<value>,"seen":<seen>}, object first, with no whitespace between tokens. Under the moved reach, ,"at":[...] follows seen. A word is {"quo":"<word>"}. The reason is that the order and the spacing are the kit’s. The shortest spelling leaves least to write and least to get wrong.

  • Question 16. Does the kit pad what it seals with whitespace, and how much? Every kit reads padding.
    How the 5 example kits answer question 16
    Go

    Padding. None is written. Every text is read with the whitespace RFC 8259 allows.

    Zig

    No. The kit writes no padding and reads any padding RFC 8259 allows.

    Python

    Padding. None when writing. Padding is read everywhere. Reason: the kit hides no lengths.

    JavaScript

    No padding.

    Rust

    The kit pads nothing. The reason is that padding hides a length this kit has no call to hide. Every kit reads padding whether or not it writes any.

  • Question 17. Does every refusal take the same time? The time a case takes is on no wire.
    How the 5 example kits answer question 17
    Go

    Time of a refusal. Not equalised. Every stranger’s case seals the same sixteen bytes, but cases that end earlier return earlier. Reason: this kit is an example, and a timing floor is a deployment’s choice.

    Zig

    No. The door returns at the first case met, so a garbage box is answered faster than a bad signature. The length and text of every stranger’s silence are the same.

    Python

    Time per refusal. No effort is made. Refusals that fail earlier return earlier. Reason: this is an example kit, and time is on no wire.

    JavaScript

    No. Refusals take whatever time they take. Case 1 is cheaper than case 8.

    Rust

    No. Every stranger’s case returns as soon as it is found, and no timing is equalised. The reason is that the time a case takes is on no wire, so the spec asks nothing of it.

  • Question 18. What does the kit keep for its own eyes? Which case refused an arrival, and which rule a reply broke, never cross a door.
    How the 5 example kits answer question 18
    Go

    Its own eyes. Nothing is logged per arrival. stderr carries only a failure to write an answer or to open a listener, and what Go’s HTTP server says of its own connections.

    Zig

    Nothing. The door does not log which case refused an arrival, and the standing does not log which rule a reply broke. Nothing is written to stderr.

    Python

    What the kit keeps for its own eyes. The door logs the case number of each stranger’s reply on stderr. Faults in the program also go to stderr. Nothing else is kept. Reason: it is enough to debug.

    JavaScript

    The refusing case and the word said go to a log function, which the harness sends to stderr.

    Rust

    The case number of the last arrival, written to stderr on each arrive. The reason is that stderr crosses no door. A case named there says nothing to a stranger.

What a kit asks

  • Question 19. How does an invitation reach its holder, and does the minting kit keep a copy? A door reads no route from an invitation.
    How the 5 example kits answer question 19
    Go

    Invitations. Handed in and out as the harness’s JSON object. The minting ward keeps no copy. The standing checks the four fields’ hex, that the secret gives the heir pk, that the lock passes FIPS 203’s encapsulation key check, which crypto/mlkem makes, and that the padlock takes a seal, and refuses anything else as bad request. at is read as question 25 says, and nothing in it refuses an invitation.

    Zig

    The invite answer carries it, and the harness takes it from there. The minting door keeps no copy: it keeps the heir pk and the name only. The asking side keeps what it needs in its Standing, keyed by the invitation’s ward pk and heir pk. That is the heir key pair (the secret included), the ward’s signing key and padlock, and the lock. Every request that reads an invitation reads it through one function, which holds the lock to 2368 lowercase hex and to the modulus check of FIPS 203 section 7.2, every twelve-bit coefficient of the first 1152 bytes below q = 3329. A lock that check refuses is no invitation, and the kit answers bad request to the ask or send that hands it one.

    Python

    How an invitation reaches its holder. It is returned to the caller as a dict, and the harness carries it. It carries at once the program holds a listener, as question 25 says. The minting ward keeps only the heir pk and the harness name. An invitation whose lock the library’s FIPS 203 check refuses is no invitation, and ask, read or send on it answers bad request. Reason: a door reads no route from an invitation, and the harness is the only holder here.

    JavaScript

    The kit returns the invitation to its caller and keeps no copy. How it travels is the caller’s business. An invitation whose lock fails FIPS 203’s encapsulation key check (lockOk) is refused before anything is sealed to it.

    Rust

    The invitation is returned on the invite answer and nowhere else. The minting kit keeps no copy, only the heir pk. The reason is that a door reads no route from an invitation. The ward needs nothing of it but the name of the heir.

  • Question 20. How does a standing recover a knock that brought no object back? It may ask under its own key and the knock’s edge key, or send the knock again as the same bytes. Which first, how often, and how long between are the kit’s.
    How the 5 example kits answer question 20
    Go

    A knock that brought no object back. After nothing, the knock is sent again as the same bytes. After silence, a word or a reply that did not open, the standing asks under the key the knock announced and the knock’s edge key. After each further non-object it alternates between the two. Each retry happens only when asked to ask again.

    Zig

    It alternates. After the knock, the next ask is sealed under the standing’s own announced key and the knock’s edge key, with no ciphertext and a new number. If that also brings no object back, the next ask sends the knock again as the same bytes, with the same lid secret, whatever method and args ask. The two alternate until an object comes back. There is no timer: an ask happens only when the program is asked. Reason: the probe succeeds when the door bound the heir, and the resend succeeds when it did not. Only an object tells the standing which case it is in, so alternating covers both.

    Python

    Recovering a knock that brought no object back. The next ask on the relation goes under the announced key and the knock’s edge key, with no ciphertext, and carries the new method and args. If that ask also brings no object, the ask after it is the knock sent again as the same bytes. The two alternate until an object comes back. Each ask is tried once, with no timer. Reason: the recovery ask succeeds where the door bound the heir. The resent knock succeeds where the door did not, and it is harmless where the heir is spent.

    JavaScript

    After a knock that brought no object: if the reply was nothing, the same knock bytes go again. If it was silence or a word, the next ask is a probe under the own key and the knock’s edge key. After that, knock and probe alternate until an object comes back. A word on a probe marks the relation as bound.

    Rust

    After a knock that brought no object back, the next ask is a recovery ask. It is signed by the announced key, under the knock’s edge key, with no ciphertext. Where that ask brings back silence or nothing, the ask after it is the knock again as the same bytes. The two alternate. A word on a recovery ask proves the knock bound, and recovery goes on under the announced key. A knock whose frame never left, or that was answered 02, is undone as if never sealed. The reason is that the two asks tell the two worlds apart. The recovery ask is heard only where the knock bound, and the knock again only where it did not.

  • Question 21. How long does an asker wait for a reply? No time is on the wire.
    How the 5 example kits answer question 21
    Go

    How long an asker waits. Five seconds to reach an address, TLS and the WebSocket handshake included, then ten seconds for the reply to an ask, then nothing. A closed connection is nothing at once. Each address in at is given the same, one after another.

    Zig

    Over TCP, send waits up to eight seconds for each address it dials, from the moment its frame is written. After that it closes that connection and takes the address as having delivered nothing. On the harness’s ask and read, the harness decides.

    Python

    How long an asker waits. Thirty seconds for each read on the socket, over TCP and over the post alike. After that the read is nothing. A closed connection is nothing at once. Reason: this is long enough for a Python door and short enough for a harness.

    JavaScript

    Five seconds per address, on every carrier: a TCP frame, a held-line message and a post each read as nothing when no answer came by then, and a closed connection reads as nothing at once. An ask tried at three addresses may so wait up to fifteen seconds. Part one does not wait, because read hands the reply in.

    Rust

    Five seconds from each dial. Where at is tried, each address it dials gets its own five seconds. The reason is that no time is on the wire. Five seconds is long enough for a listener on one machine, and short enough that a run does not hang.

  • Question 22. How does a standing number its asks, which keys does it announce and when, and how does it keep two sends on one relation apart? What does it keep of the keys it moved from, and what does it do when the asks after a move meet silence? A knock carries any count number. A standing moves on an object to an ask above every ask it has moved on, and on nothing else. A door admits the key held and the key vouched for, and takes the open key and the offered key.
    How the 5 example kits answer question 22
    Go

    Numbering, announcing, and two sends on one relation. Numbers come from one counter per relation, raised once per sealed ask and never reused, and the knock carries the number one. Every ask announces in next a signing key drawn for that ask alone. A knock sent again as the same bytes carries the same number and the same announced key. Each send keeps its own box, lid secret, number, signing key, announced key and edge key, so two sends in flight read their replies apart. The standing keeps the highest number it moved on, so a late object to an older ask moves nothing. Of the keys it moved from it keeps nothing: the ask that moved it replaces the signing key and the edge key, and the knock is dropped. When the asks after a move meet silence, a word or nothing, the standing keeps sending under the key and edge key it moved to. Reason: the door admits the key held and the key vouched for, so the key just announced is admitted next, unless a later ask moved the door past it. That happens when two replies in flight are lost and the first is read late. The kit then hears silence on that relation, which SPEC.md allows, and keeps no older key.

    Zig

    The numbers count up from one, one number per ask sealed, whatever came back. The knock announces the one key the standing ever announces, drawn at the knock. Every ask after it announces nothing, so its next is null. Reason: a relation with one key needs no second, and a key announced is a key that must then be kept.

    It keeps two sends on one relation apart by holding one. A relation holds the last ask alone: its lid secret, its edge key, its signing key and its number. Every ask replaces it, and read opens the reply under that ask’s lid. Sends on one relation are serial, because stand runs one request at a time. So a late reply to an earlier ask does not open under the current lid, and reads as silence.

    Of the keys it moved from it keeps nothing. A move takes the key the ask was signed with and the edge key that follows the one it was sent under. What stood before is dropped, and the kept knock is dropped with it. Reason: this standing is only ever the key the door holds, so an older key would open no box.

    When the asks after a move meet silence, the standing does nothing. It moves on an object alone. Silence, a word and nothing leave the signing key, the edge key and the highest number where they stand. The next ask goes out under the same two keys with the next number. Reason: the door moves on a choice too, so a refusal leaves both ends together. An object the standing did not hear leaves it one ask behind, and the ask after it arrives under the door’s open key, which still opens.

    The standing also keeps the highest number it has moved on. An object to an ask at or below it is read and moves nothing. The one ask that can meet that is the knock sent again, number 1, and it only moves a standing that has not moved.

    Python

    Numbering, announcing, two sends, and the keys moved from. The count goes up by one on every box sealed, whatever comes back. The knock is numbered 1, and a resent knock keeps its number. Every ask announces a newly drawn key, on the knock and on every ask after it. One lock per relation keeps two sends apart: each send seals, dials, waits and reads before the next begins. The standing keeps the highest number it moved on, and moves on an object to a higher number only. Of the keys it moved from it keeps nothing. The signing key and the edge key it moved to replace what stood before. When the asks after a move meet silence, the standing stays where it moved to. It keeps asking under that key and that edge key, with the count going up, and it never falls back. Reason: a standing moves only on an object, so asks that overlap would race on its keys. The door admits the key moved from as the key held, so the standing needs no copy of it. Silence is a choice the door made, so it says the ask was read.

    JavaScript

    Each ask draws a fresh key and announces it in next, and takes the next count number, starting at 1 for the knock. Every ask announces, because a key costs little and a standing that always announces has one path. Two sends on one relation are kept apart by a chain of promises (Standing.chain), so the second is sealed only after the first has been read. The standing moves only when an object comes back to an ask numbered above every ask it has moved on (Standing.moved). Of the keys it moved from it keeps nothing. The signing key and the edge key are dropped at the move, because no reply to an older ask can move the standing again. The knock’s bytes alone are kept, for question 20’s resend. When the asks after a move meet silence, a word or nothing, the standing stands where it is. It sends the next ordinary ask, numbered one higher, under the same keys. It does not knock again and it does not probe, because the move bound the relation and only a knock is ever in doubt.

    Rust

    An ask carries the next count number, one above the ask before it, starting at one. A knock again as the same bytes carries the number and the key of the knock it repeats. Every other ask announces a newly drawn key in next, so it offers a move whether or not it gets one. The standing is held for the whole of a send, from sealing until the read. That is how two sends on one relation stay apart.

    The standing moves only where an object is read, once per ask. It moves to the key that ask announced and to the edge key that follows the reply. Of the keys it moved from it keeps nothing, since the former signing key and the former edge key are dropped as the move is made. Where the asks after a move meet silence, the standing stays where it moved to. It asks again under the same keys with the next number. The reason is that a door admits the key held and the key vouched for. An object read means the door made the move, and one send at a time leaves no later move past it. So an ask under the key just announced is admitted.

  • Question 23. What does the kit tell its own code on silence, on a word, and on nothing? The three words cross a door. The kit’s own spelling for them does not.
    How the 5 example kits answer question 23
    Go

    What the kit tells its own code. A Read whose Kind is object, silence, quo (with Word) or nothing.

    Zig

    The union Read, with four tags: object (the raw object text and the seen token), silence, word (one of the three strings), and nothing.

    Python

    What the kit tells its own code. Standing.take returns ("object", value, raw, seen, at), ("silence",), ("word", w) or ("nothing",), where at is the addresses kept from the reply’s at or None where it reads as absent. The harness gets {object, seen, at?}, {silence: true}, {quo: w} or {nothing: true}, with at present wherever the reply’s at is an array, even one from which nothing was kept. Reason: four outcomes, four tags.

    JavaScript

    { kind: "object" | "silence" | "word" | "nothing" }, with word holding the word as spelled on the wire.

    Rust

    A Read enum: Object{object, seen, at}, Silence, Word(String) and Nothing. The reason is that the three words cross a door and the kit’s own spelling for them does not. An enum says them to Rust alone.

What a kit carries

  • Question 24. Which carriers does the kit stand, and in which forms? Does it carry them inside TLS, and with which checks? Where does it listen on the web, at which path and for which origins? With which status when it does not carry an ask? Quo over TCP and Quo over the web, its post and its held line, are published. Any other is the kit’s.
    How the 5 example kits answer question 24
    Go

    Carriers. Both published ones, and no other, with Go’s standard library alone: Quo over TCP, and Quo over the web in both forms, the post on net/http and the held line written by hand on RFC 6455.

    • As a listener, one per scheme, tcp, http and ws, each on 127.0.0.1 at a port the system chooses, plain. A web listener answers at every path, and its address is written with the path /. The post answers 405 to a method other than POST, 400 to a body under sixty-five bytes, 413 to one over 1,048,640, 204 for nothing and 200 with the reply’s box. It sends no CORS headers, so it answers no page of another origin. The held line refuses a handshake that does not offer quo, and closes with status 1002 on bytes RFC 6455 refuses, 1003 on a text message, 1009 on a message longer than the largest body, and 1008 on any other message that is no frame. It answers pings and never pings.
    • As a dialer, tcp, http, https, ws and wss, the secure two inside TLS under the system’s roots, since the harness counts them as the same carrier. It keeps one line per address on tcp and the held line, dials it again after it closes, and numbers its asks per line. Each post is one request that follows no redirect. Reason: the standard library holds HTTP and TLS, and RFC 6455 is small enough to write where the library has none.
    Zig

    Quo over TCP alone, as listener and as dialer, from libc sockets, plain and never inside TLS. It listens nowhere on the web, so no path, origin or status is its to choose. It stands neither form of Quo over the web: listen of http or ws, and a route to an address of either, answer bad request. The listener binds to 127.0.0.1 on a port the system chooses, and serves every accepted connection on a thread of its own, one frame at a time. The dialer resolves the address’s host with getaddrinfo, so a name, an IPv4 address and a bracketed IPv6 address are all dialled, and opens one connection per address per send, closed after the answer. Reason: one carrier proves the frames, and the web’s two forms would each be a second listener and dialer that no other part of this kit uses.

    Python

    Carriers. Quo over TCP, and the post of Quo over the web, each as listener and as dialer, with the standard library alone. The kit does not stand the held line: listen of ws and a ws or wss route answer bad request. A program holds at most one listener of each, on 127.0.0.1 at a port the system chooses. The TCP listener answers asks on one connection concurrently. The post listener answers any path, one thread per request. It answers 204 when the door gives nothing, 404 for a ward it does not stand, 400 or 413 for a body too short or too long, 411 without a Content-Length, and 405 to any method but POST. It sends no CORS headers, so it answers no page of another origin. The dialer opens a fresh connection for each ask, TCP or HTTP, and closes it after the answer. It posts to https addresses as well, under the system’s default TLS checks. Reason: TCP and the post need nothing beyond the standard library, while the held line would need a WebSocket written by hand. A connection per ask means ids never collide.

    JavaScript

    Both published carriers, in all three forms, as listener and as dialer, on Node alone. Quo over TCP (lib/tcp.js), scheme tcp, with one connection per address. Quo over the web (lib/web.js): the post, scheme http, listened on with node:http and dialed with fetch, one request per ask, redirects not followed; and the held line, scheme ws, listened on with a WebSocket server of RFC 6455 written in the kit and dialed with Node’s WebSocket, one line per address. The dialer also takes https and wss, because fetch and WebSocket carry TLS themselves. Their checks are Node’s defaults: the certificate chain against Node’s bundled roots, and the host name against the certificate. TCP is never dialed inside TLS. The listeners speak no TLS, so the kit listens on tcp, http and ws alone, on 127.0.0.1 at a port the system chooses. Every web listener answers on any path, and its address is written with the path /. The post listener sends no CORS headers, so a page of another origin cannot read its answers. A post it does not carry hears a status other than 200 and 204: 405 for a method other than POST, 400 for a body under sixty-five bytes, 413 for one over 1,048,640, and 404 for a ward pk it does not stand. A door that throws hears 204, as nothing. The held-line listener answers a plain request with 426, and a handshake without quo with 400.

    Rust

    Quo over TCP alone, plain and never inside TLS, as a listener on 127.0.0.1 and as a dialer, one connection for each send. It listens nowhere on the web, so no path, origin or status is its to choose. It stands neither form of Quo over the web. So listen of http or ws, and a route to an address of either, are bad request. The reason is that a box carries its own seal and its own signature, so TCP needs nothing under it. One carrier is enough to be judged as a carrier.

  • Question 25. How does the kit learn where a ward is reached? Does it write at in its invitations and in its replies, and with which addresses? What does it do with an at a reply carries? How does it try the addresses it reads, and which does it refuse to try? A ward’s name is its public key. An invitation goes anywhere, and whoever carried it may have written its at. An invitation may carry addresses in at, the first the minting side’s preference, and a kit may learn others its own way. A reply may carry at too, signed by the ward with the reply. These are the kit’s. Which source it trusts first. When its door writes at in a reply. Which replies it takes an at from, whether that at replaces or joins the addresses it held, and what a later reply with none means. Whether it tries addresses one after another or at once. How long it gives each. Whether it carries a box to the next address after one that gave nothing or may have heard it. A door honours a number once, whichever address carried it.
    How the 5 example kits answer question 25
    Go

    Where a ward is reached. From route, and from an invitation’s at; the kit learns no address any other way.

    • Where a ward has a route, the kit dials the route alone.
    • Where it has none, the kit reads at in its order, skips every entry that is not a string, not a URI with a scheme, of a scheme it does not dial, or not written as that scheme’s carrier writes it, and tries the rest one after another, never two at once, each given the waits of question 21. It stops at the first that answers with a reply, whatever the reply says. Reason: the first entry is the minting side’s preference, and this kit trusts no other source over it.
    • The kit carries the same box to the next address after every nothing. It draws no line between an address it never reached and one that may have heard the box before the line closed. Reason: a door honours a number once, whichever address carried it, so a box that may have been heard costs at worst a repeated and never a second choice. The ask reads nothing when no address answered.
    • An at that is not an array is read as absent.
    • The kit keeps nothing from the at a reply carries. Whatever that at holds, the reply reads as an object, and read answers no at. It never replaces or adds to a route or an invitation’s addresses. Reason: a reply that came back already reached the ward, and this kit learns addresses from route and the invitation alone.
    • The door writes at in a reply only where its target hands addresses. Of the five, only moved does, writing ["tcp://127.0.0.1:9"] on every object as the harness fixes. The door never writes its listeners’ addresses in a reply. Reason: its invitations already carry them, and no ward here moves.
    • Once the program holds listeners, every invitation it mints carries at with each listener’s address, tcp first, then http, then ws. With no listener, it writes no at. Reason: TCP carries the bytes with the least around them, and a reader that stands only the web still finds its own scheme further on.
    Zig

    Two ways. A route names one tcp address for a far ward, and replaces the one before. An invitation’s at names the rest. Where a ward has a route, send dials the route alone. Where it has none, send reads the invitation’s at in order and takes each string that is a tcp://host:port address as CARRIER-TCP.md writes it.

    It refuses to try four kinds of entry, and skips each where it stands. An entry that is not a string. A string that is no URI with a scheme. A string whose scheme is not tcp, this kit standing no other carrier. A tcp string that CARRIER-TCP.md does not write, a missing port or a path among them. The scheme is read without regard to case. An at that is not an array is read as absent. None of this makes the invitation no invitation.

    The kit tries the addresses it kept one after another, the same box to each, and stops at the first that answers with a reply. A nothing frame, a closed connection, a refused dial or eight seconds without an answer moves it to the next. So a box does go on to the next address after one that may have heard it, and the door honours its number once whichever address carried it. With no route and no tcp address, nothing is delivered. Once the program holds its listener, every invitation it gives carries at with that listener’s one address, tcp://127.0.0.1:<port>. Before then it writes no at. Reason: the listener is the one place this program is reached, and trying in order keeps the minting side’s preference and sends each box to one address at a time.

    The door writes at in a reply under the moved reach alone, on every object, as the one address tcp://127.0.0.1:9 the harness fixes. Under every other reach, and on silence and on a word, it writes none. Reason: the listener’s address already travels in the invitation. This kit never moves a ward to another address, so an at of its own would repeat what its asker holds.

    A reply’s at is read for the shape alone. Whatever value it holds, an object read with it is still an object and moves the standing as any object does. The standing keeps no address from it, and read and send report no at. Nothing a reply carries replaces a route or an invitation’s at. Reason: every send is handed its invitation and looks up its route afresh, so a kept address would have no reader.

    Python

    Where a ward is reached. From the harness’s route, a table from ward pk to one address held in memory, from an invitation’s at, and from the at of an object reply. The kit learns no address any other way. It reads either at only when it is an array, and skips every entry that is not a string, not a URI, or not a tcp, http or https address as its carrier writes it. Where a route names the ward, the kit dials the route alone. Otherwise it tries the addresses the standing kept from a reply, then the invitation’s that are not among them, one after another in the order written. A standing keeps a reply’s addresses only from an object it moves on. They replace the ones it kept from an earlier reply and stand ahead of the invitation’s, which they never replace. It moves to the next when an address gives nothing, of any kind, and stops at the first reply. Each try waits as question 21 says. With no address left, the read is nothing. It carries the same box to the next address after one that gave nothing, whether or not that address may have heard it. Once the program holds listeners, every invitation it mints carries their addresses in at, the post first, then TCP. The door writes at in a reply only where its reach gives one, which moved alone does, on every object. It never writes its listeners there. Reason: a route is the harness’s own word and beats what an invitation carries, since whoever carried the invitation may have written its at. A reply’s at is signed by the ward, and the latest object the standing moved on is the freshest word it has, so it goes first. A reply to an ask it did not move on may be late, so its at is not kept. The invitation’s addresses stay behind it, so a reply address that fails costs one try and loses nothing. The order in at is the preference of the side that wrote it, so trying in that order honours it. A door honours a number once, whichever address carried it, so a second address costs nothing but the wait. The post goes first because it reaches where TCP cannot. Every holder of an invitation already has the listeners’ addresses, so the door has no cause to repeat them in a reply.

    JavaScript

    A ward is reached by a route the caller gives (route, ward pk to one address), or by the invitation’s at. The route is the source trusted first: when there is one it is dialed alone, because the caller named it. With none, the kit reads at (lib/address.js): it reads a scheme without regard to case. It skips every entry that is not a string, is not an address as its carrier writes it, or names a scheme it does not dial. It tries the rest one after another in the order written, since the first is the minting side’s preference. It stops at the first reply. After an address that gave nothing, or that may have heard the box (a closed connection, or five seconds with no answer), it carries the same box to the next. A door honours a number once, so the second hearing of a box is a refusal or a choice on a number already honoured, and moves nothing. An at that is not an array is absent. With neither, the ask is not delivered. The kit remembers nothing of which address answered, so every ask tries at from its start. Once the program holds listeners, every invitation it mints carries their addresses in at, ws first, then http, then tcp: the held line carries many asks on one connection and reaches where TCP cannot, the post reaches where a line cannot be held, and TCP is last because the web reaches further. An invitation minted before any listener carries no at.

    The door writes at in a reply only where the function behind it gives one, and writes it as given. Of the harness’s functions, moved alone gives one: ["tcp://127.0.0.1:9"] on every object. The door knows no address itself, because its listeners belong to the program around it. The kit reads a reply’s at as SPEC.md reads it. A reply carrying one is still an object, and moves the standing. Silence or a word with at is none of the three shapes. The kit keeps nothing of a reply’s at, which replaces and adds nothing. The next send dials the route or the invitation’s at as before. Keeping it would make an address the far ward chose a source this kit trusts, and nothing the kit does needs one. So its read carries no at.

    Rust

    The kit learns a ward’s address three ways. The first is the route request, a map from ward pk to one tcp://host:port held in memory. The second is the at of a reply, kept on the relation’s standing. The third is the at of the invitation a send is made on. A route is trusted first and is dialed alone. Next come the addresses of the last reply that gave any, and last the invitation’s. The reason for that order is that a route is the kit’s own word, and a reply’s at is signed by the ward. An invitation’s at may have been written by whoever carried it.

    Once the program holds its listener, every invitation it mints carries that listener’s tcp://127.0.0.1:port as the one address in at. Before that it writes no at. Its door writes at in a reply only under the moved reach, which writes ["tcp://127.0.0.1:9"] on every object. No other reach writes one. The reason is that the harness fixes what moved writes, and a door that answers its own ward’s listener gives an asker no address it lacked.

    A reply’s at is read as an invitation’s is. One that is no array reads as absent, and the reply is still an object. Of an array, the kit keeps the tcp addresses in their order and skips every other entry. Where it keeps at least one, those addresses replace the ones it dials for that relation. Where it keeps none, it dials what it dialed before. The reason is that a reply’s at says where the ward that signed it is reached now. An at that names no address this kit dials tells it nowhere to go, so it forgets nothing for it.

    With no route, the kit tries the tcp addresses it holds one after another, in the order written. It skips every other scheme, every string that is no tcp://host:port, and every element that is not a string. It moves to the next address only where the one before delivered nothing for certain: the connection never opened, the frame never left, or 02 came back. Once a frame has left, the kit waits for that address alone and tries no other. The reason is that a door honours a number once, whichever address carried it. A box carried on after an address that may have heard it would spend the number for nothing.

What is not the kit’s either

  • Question 26. What do method and args mean, and what does a lang name? Quo reads neither, and reads of a lang only that it is a string. A named ask names an entry of a describe. What that entry does is agreed between the two ends of a relation, and a lang may name where the agreement is written.
    How the 5 example kits answer question 26
    Go

    method and args. The kit reads them only to hand them to a target. The five targets ignore method except to tell a named ask from the empty one. Its describe names no lang, so its asks mean what SPEC.md says of them and nothing more.

    Zig

    Nothing to the door. The reach looks only at whether method is present. echo and marked return args as they arrived. Its describe names no lang, so its asks mean what SPEC.md says of them and nothing more.

    Python

    method and args. This kit gives them no meaning. The reaches echo args or ignore both. Its describe names no lang, so its asks mean what SPEC.md says of them and nothing more. Reason: their meaning belongs to the two ends.

    JavaScript

    They mean nothing to the kit. echo sends args back as it arrived. Its describe names no lang, so its asks mean what SPEC.md says of them and nothing more.

    Rust

    The kit gives them no meaning. method is sent as the JSON string text the caller gave, and args as the object text the caller gave, byte for byte. The reason is that their meaning is agreed between the two ends of a relation. A kit that read them would be one of those ends. Its describe names no lang, so its asks mean what SPEC.md says of them and nothing more.

What a kit reads

  • Question 27. How deep, how long and how strange a JSON text does the kit read where Quo reads nothing, and what does it answer beyond that? Where Quo reads nothing is inside args, inside object beyond what a describe names, and the string of method. So is an entry of at that is not a string, and every field the spec does not name. Nesting, lone surrogates, noncharacters and repeated keys there are JSON’s to allow and the kit’s to take or refuse. What a door answers there is a choice, and silence is one.
    How the 5 example kits answer question 27
    Go

    JSON inside args, and inside object beyond what a describe names. Any JSON text RFC 8259’s grammar allows, of any length the size admits and any nesting: containers there are checked against the grammar without recursion and never parsed further. Lone surrogates, noncharacters and repeated keys there are taken. echo, marked and moved answer every such args with its bytes as they arrived; nothing is refused beyond the grammar. A read object is handed on as its bytes as they arrived. Among a payload’s or a reply text’s own keys, a lone surrogate is kept as its code unit, so two keys are one name exactly when their code units are equal. Reason: reading nothing is the least code and the fewest refusals.

    Zig

    Any depth and any length the size allows. The kit reads into nodes only the outer object of a payload or a reply text (and two levels of a harness line). Inside args, and inside object beyond what a describe names, it holds the text to the RFC 8259 grammar with a loop and a stack of brackets, not recursion, so depth costs one byte of heap per level. Numbers are carried as written, whatever their size. Lone surrogates, noncharacters and repeated keys there are taken and carried as written. A lone surrogate escape in a key the kit does read is kept as its own three bytes, so two different lone surrogates are two names. One choice beyond that: echo and marked answer silence, a choice that moves the keys, to args whose own keys repeat a name. The standing reads any object it is given, repeated keys included, and hands it back as written with the whitespace between tokens taken out. Reason: the kit reads nothing it does not use, and a bound it does not need is a bound it would have to answer for.

    Python

    What is read inside args, and inside object beyond what a describe names. The kit reads only a payload’s or a reply text’s own keys, and the items of a reply’s at array, each a string or skipped. Every other container below them is checked against the grammar of RFC 8259, iteratively, with no bound on depth or length beyond the size, and its lone surrogates, noncharacters, repeated keys and numbers are taken as written. The door answers such an args as its reach chooses. null and silent never look at it. echo and marked answer silence, a choice, when two of args’ own keys are one name, and otherwise echo args whatever lies deeper. The asker hands any object it read to its own code as the bytes that arrived. Reason: SPEC.md reads nothing there, so the kit builds nothing there, and echo declines only a shape it would not itself write as a payload’s args.

    JavaScript

    Inside args, inside object beyond what a describe names, and in any field beside a payload’s six, the kit reads any JSON text the grammar allows, at any depth up to the box’s size: below the second level a container is checked with an explicit stack, not recursion, and kept as raw text. Lone surrogates and noncharacters are taken as written. A repeated key inside a nested value is taken, and the last one wins where the kit looks. The one text the kit does not read is args that repeats a key among its own keys: echo, marked and moved answer that ask with silence, a choice that moves the keys. On the asking side, an object of any depth and any repeats is read and handed on as written, whitespace between tokens removed.

    Rust

    The door reads args, and a field beside the six, by the grammar of RFC 8259 alone, at any depth. The scan is a loop over a stack of brackets. Only the duplicate-key check recurses, on a text already known to nest sixty-four containers deep at most. Any number the grammar allows, lone surrogates, noncharacters and repeated keys are all taken there. None of them makes a box a stranger’s.

    The echo and marked reaches echo args only where it nests sixty-four containers deep or fewer and no object in it repeats a key. Past that the reach chooses silence, and the choice moves the keys. The asker reads object the same way, at any depth, lone surrogates and repeated keys included. It hands it on as the text that came, with whitespace outside strings removed. On the channel, method and args are taken by the same grammar and sent byte for byte. The reason is that Quo reads nothing there. Refusing a text the grammar allows would put the kit’s taste in front of the spec’s silence.

What a kit shows

  • Question 28. Does the kit read a domain’s vouch? Which domain does it check for a ward, and where does it learn that domain? When does it read the file again, and how does it show a person what it found? DOMAIN.md says how a domain vouches for a ward, and a door reads none of it. A domain may come with an invitation, from the host of an address in at, or from the person. A reply over https or wss shows the host that carried it, as CARRIER-WEB.md says, and that is not a vouch.
    How the 5 example kits answer question 28
    Go

    A domain’s vouch. The kit reads none and shows none. stand answers the harness alone, and has no person to show a domain to. Reason: a vouch is read for a person, and here there is none.

    Zig

    The kit reads no vouch and shows none. The stand program answers the harness alone, and has no person to show a domain to. Reason: a vouch is read for a person, and here there is none.

    Python

    A domain’s vouch. The kit reads none and shows none. The stand program answers the harness alone, and has no person to show a domain to. Reason: a vouch is read for a person, and here there is none.

    JavaScript

    The kit reads no domain’s vouch and shows none. The stand program answers the harness alone, and has no person to show a domain to. A vouch is read for a person, and here there is none.

    Rust

    The kit reads no domain’s vouch and shows none. The stand program answers the harness alone, and has no person to show a domain to. The reason is that a vouch is read for a person, and here there is none.

Everything a kit may choose is asked above. Everything else is SPEC.md, and this document decides none of it.