Gates
An approval or a choice a stage is waiting on. Approve, request changes or reject from the room; a choice of versions names the one you pick.
Board work, in chat
SuperExchange is a Matrix application service. It carries SuperPipeline’s gates, questions and waiting cards into the board’s encrypted room, and when a person answers there, the board acts on it as that person.
Early: v0.0.2 · MIT · runs in production, no production board moved to it yet
Approval needed — “Launch post” at stage review. Approve, request changes, or reject.
Approve “Launch post”?
Approve
Approved by Ana — the board has it.
One path per board, one message per event, one receipt per answer. The steps below are a gate; questions, follow-ups and waiting cards go the same way.
SuperPipeline publishes gate.pending to the suite’s event relay, which delivers it to SuperExchange signed. It is kept only for boards an operator has opted in.
SuperExchange makes the board’s room once, invites the board’s people, waits until one has joined, then posts the gate exactly once. Rooms are end-to-end encrypted with SuperExchange’s own keys.
Accounts says who the Matrix sender is. Only a person may answer, and only with an option the gate offered. An agent’s answer, or one from another room, is ignored.
The gate is resolved at SuperPipeline as the person who answered, and one receipt is posted. A repeat is told it was already decided. A gate decided on the web is settled in the room by the next sweep.
Everything a board waits on a person for, posted in the board’s room and answered there. The event formats are treaty’s: SuperExchange carries them, it does not define them.
An approval or a choice a stage is waiting on. Approve, request changes or reject from the room; a choice of versions names the one you pick.
An agent blocked on a person, or a SuperToolkit approval request. Answer with the card, or type the number or label of an option. A typed reply can decline an approval, never grant it.
A post approved for manual delivery still owes the board its live link. Record the link, or switch to automatic delivery when the whole post could be shown.
A card parked for a person after repeated failures, a block or a missing permission. Resume it here or at an earlier stage, with an instruction for the next attempt, or archive it.
Reminders, escalations to the workspace’s admins, quorum progress, held approvals and failed or overridden checks, each said once, in reply to its card.
Pull a gate back, or override a failed check, from the room. Each needs a comment, and acts as the person who sent it.
supi.From source, with Bun. Every setting is in the README; a missing or malformed one stops it before it listens, naming the setting, never its value.
$ bun install
$ MATRIX_HOMESERVER_URL=… MATRIX_SERVER_NAME=… MATRIX_AS_TOKEN=… MATRIX_HS_TOKEN=… \
TREATY_RELAY_DELIVERY_SECRET=… SUPEREXCHANGE_OPERATOR_TOKEN_SHA256=… \
ORG_PLANE_URL=… ORG_PLANE_SERVICE_CREDENTIAL=… SUPERPIPELINE_URL=… \
SUPEREXCHANGE_CRYPTO_PASSPHRASE="$(openssl rand -base64 32)" SUPEREXCHANGE_DATA_DIR=$PWD/.data \
bun apps/exchange/src/main.ts
$ curl http://127.0.0.1:8080/healthz
An operator then opts a board in through PUT /v1/boards/:boardId. Back up the crypto store with the database: lose it and the room keys go with it.The full setup is in the README.
Early, and honest about it. This is v0.0.2.
Source on GitHub, mirrored from the forge (where pull requests are made; it needs a forge account). What changed in each release is in thechangelog.
Captain Jack's notes, from the lab's claims ledger. Every claim here is one the ledger lets the lab make. Solid means verified against public source. Hollow means true, with a caveat. Open one to see the caveat.
SuperExchange isn't in the claims ledger yet, so this page makes no checked claims. Ask Captain Jack what he can say, and he'll tell you where his knowledge stops.