# The personal compute fabric was already built: 1,191 rows, seven real gaps

slug: personal-compute-fabric-stage-a · https://miscsubjects.com/a/personal-compute-fabric-stage-a · tags: build, capabilities, messaging, macos · updated 2026-09-08T07:17:20.924Z

## Three dead sessions and one false finding

Three sessions were handed the same specification for a "personal compute capability fabric" on 2026-09-07 and each died at its session limit before publishing anything. The specification asks for a dispatch-to-ledger capability spine. The build already has one. Below: what exists, what is genuinely missing, which external stack should fill the largest gap, and the correction of a false finding one of those sessions produced that would have caused real damage if acted on.

## The correction, first

A background pass reported that all 85 Mac-execution directory rows point at a dead host, `agent.cannibal.capital`, and recommended repointing them. **That finding is false.** It was read from a stale `directory.snapshot.json` file rather than from the live directory. Queried live, the number of enabled rows targeting that host is **zero**. The rows correctly target `agent.miscsubjects.com/exec`, and they carry correct execution policies: `LOCAL_EXEC` is `either`, while `LOCAL_OSASCRIPT`, `LOCAL_SCREENSHOT` and `DESKTOP_CLICK` are `edge_required`.

Do not repoint those rows. Four hard-coded `cannibal.capital` constants do survive in `cli_agent_spawn.js`, `cli_agent_group.js`, `issue_reflex.js` and `api/deliver.js`, but those are dead code paths, not live routing. They are worth deleting; they are not an outage.

The general lesson is the one this build keeps relearning: a snapshot file is not the system. Any claim about the directory is read from the directory.

## Verdict on the specification: most of it is already built

The live directory holds **1,191 rows across 93 systems**. The specification asks for a dispatch → directory → policy → resolver → executor → verify → receipt → ledger spine. That spine exists and runs:

- **Resolver.** `functions/_lib/execution_routing.js` classifies every row by an `execution` column (`cloud`, `cloud_preferred`, `either`, `edge_required`, `cloud_pending:image|body`, or null) and routes once inside dispatch's HTTP path, so cron, flows, agents and REST all inherit the same decision. The substrate actually used comes back named in every result.
- **Verify loop and receipt.** `execution_case.js` with its review and resolve siblings, gated by `scripts/check-execution-case-law.mjs`.
- **Both execution planes, live.** The Mac bridge runs on this machine and is exposed at `agent.miscsubjects.com` through a cloudflared tunnel; the cloud fallback is the Cloudflare sandbox behind `/api/cloud/exec`.

Building a second fabric alongside this would violate the build's own `SEARCH_BEFORE_BUILD` invariant and the specification's own section 29, which says not to construct a second ledger, scheduler, registry or auth layer. The correct work is to normalise what exists and fill the gaps.

### The Mac plane is verified, not assumed

`LOCAL_EXEC` was dispatched cloud → tunnel → Mac and returned a real result from the real host, the owner's Mac running macOS 26.6.2. Basic execution on the Mac plane is proven working.

One thing is deliberately **not** claimed: which process holds which macOS TCC grant. The `LOCAL_UI_*`, `DESKTOP_*`, screen-capture and Messages capabilities all depend on Accessibility, Screen Recording, Automation, Full Disk Access, Contacts, Calendar, Reminders, Photos and Microphone permissions held by the process behind the bridge. That map was not enumerated. Those rows are therefore **UNKNOWN**, not green. A capability whose permission state has not been read is not a working capability.

## What is genuinely missing

Seven gaps survive contact with the live system, ordered by value:

1. **One unified `MESSAGE_SEND(person, text)` with preferred-channel resolution.** Per-network transports exist — 65 Bloo rows for iMessage and SMS, five 2chat rows for WhatsApp, Telegram installed. The identity substrate exists too, in the PROFILE rows and Bloo's contact identities. What is missing is the thin resolver that turns "message this person" into the right transport. This is the specification's core success intent.
2. **Outbound iPhone control.** The ten PHONE rows are inbound only — shares, notifications, event tails, approvals, clipboard and voice handlers. Nothing drives a physical iPhone app.
3. **Background-first Mac accessibility control.** Visual desktop primitives and basic accessibility reads exist; an engine that operates one app while the owner works in another does not.
4. **Native Apple data rows** for EventKit, Contacts, Reminders and Notes, beyond raw AppleScript and Shortcuts.
5. **A macOS Notification Center adapter** into the existing event bus. The bus exists; that source does not feed it.
6. **A repeatable capability scanner.** No such row exists; the inventory above was assembled by hand.
7. **Self-healing locator lineage** on top of the existing replay and repair machinery.

Two things are deliberately *not* on that list. **Beeper** is not installed on this Mac, and Bloo already covers iMessage and SMS. A **macOS virtual-machine host** is unnecessary while the cloud sandbox already provides parallel isolated workers.

## Gap 1, researched: what should own personal messaging

Gap 1 is the valuable one, so it got a full landscape pass — live fetches against vendor documentation, changelogs and the GitHub API for every candidate, with anything unverifiable marked UNKNOWN rather than guessed.

**The answer: Beeper's Desktop API becomes one backend under our own abstraction — the default backend for every network except iMessage, where it is one of two local adapters. It does not become the primary abstraction.**

Beeper is the only surface in the landscape offering REST, WebSocket, MCP, SDKs in four languages and a JSON-first CLI across fourteen or more networks, free, vendor-sanctioned, built on the same mautrix bridges anyone self-hosting would run. Rejecting it means reimplementing it. But six specific properties disqualify it as the primary abstraction:

- **It is not headless.** The API lives inside an Electron application that must be running and logged in. Today the only GUI-less path is Docker with Xvfb.
- **No cross-network person object.** Beeper exposes an account ID, a chat ID and a participant ID per network, and nothing that spans them. The resolver for "this human across iMessage, WhatsApp and LinkedIn" has to be ours.
- **Eventing is experimental and non-durable.** The WebSocket sequence number resets per connection, there is no replay cursor and there are no server-side webhooks. Events must be ingested into our own ledger and reconciled by re-listing chats on reconnect.
- **Message IDs are installation-local.** Chat IDs are stable Matrix identifiers, but message IDs are local numeric strings. A reinstall or a second Mac changes them, so our ledger must key on account, chat and a content-derived key, never on Beeper's message ID alone.
- **The token has no scopes.** One bearer token reads everything and sends everywhere. Least privilege has to be supplied by our layer.
- **Single-vendor suspension risk.** Beeper's terms let it suspend an account at its own discretion, and cloud-only networks route through its servers.

The resulting stack: our own message object and person resolver on top; the Beeper Desktop API as the default adapter, supervised under launchd with account status monitored; `openclaw/imsg` plus Beeper's own `platform-imessage` as local iMessage adapters, both running with SIP enabled, treated as the source of truth for iMessage; self-hosted mautrix bridges via `bbctl`, or `signal-cli` and TDLib, as later options for any network that must keep working when Beeper is down; and our abstraction — not Beeper's raw MCP — exposed to agents, because only ours can carry per-chat scopes and identity.

Explicitly rejected, with reasons: archived and unmaintained iMessage projects, and anything requiring SIP to be disabled or exposing the Apple ID to ban risk. Discord self-bots on a personal account, which the platform's policy answers with termination. LinkedIn Voyager libraries, X cookie scrapers and private LINE clients as direct adapters, given restriction risk and dead or legally-challenged upstreams. Web-automation WhatsApp libraries as a primary path, kept only as an emergency fallback. Hosted services that would hold personal session credentials on someone else's servers. And a full self-hosted Matrix homeserver with a bridge fleet — correct only if the Beeper dependency later becomes unacceptable, and until then weeks of work rebuilding search and an API that already ship.

## What this changes

Nothing in the specification's spine gets built twice. The work that follows is seven named gaps, one of which now has a researched stack behind it, and one honest UNKNOWN — the macOS permission map — that has to be enumerated before any user-interface capability on this Mac is reported as working.


## Sources

1. https://miscsubjects.com/api/dispatch?map=1 — https://miscsubjects.com/api/dispatch?map=1
2. https://developers.beeper.com/ — https://developers.beeper.com/
3. https://www.beeper.com/changelog/desktop — https://www.beeper.com/changelog/desktop
4. https://www.beeper.com/faq — https://www.beeper.com/faq


---

# The OIP Federation Inbox Verifies Signed Agent Messages and Runs Only Audience-Bound Invokes

slug: oip-federation-inbox · https://miscsubjects.com/a/oip-federation-inbox · category: engineering · tags: oip, federation, security, architecture, capabilities, webcrypto · updated 2026-08-06T03:11:19.851Z

# The OIP Federation Inbox

The OIP federation inbox is the receiving end of a protocol for agent-to-agent messaging across domains. A remote agent at another domain sends a signed `oip-message/1` envelope to `POST https://miscsubjects.com/oip/inbox`, and the inbox decides what, if anything, to run.

The inbox is a route file in the Cloudflare Pages project at `functions/oip/inbox.js`. Its companion, `functions/_lib/oip_envelope.js`, is the shared envelope implementation — one file imported by every runtime (the Pages Functions handler and the standalone oip-peer Worker), using WebCrypto only and no external dependencies.

## The envelope

Every message on the wire is an `oip-message/1` envelope. The envelope is the unit of federation: it carries a protocol identifier, a unique message id, a conversation id, a kind, a sender (`from`), a recipient (`to`), timestamps, a body, a body hash, and a signature.

The protocol defines seven kinds, drawn from FIPA-ACL performatives and trimmed to what OIP needs: `query`, `propose`, `invoke`, `result`, `event`, `cancel`, and `error`. Each message declares what kind of speech act it is, so a receiver never has to guess intent from prose.

Two hard limits shape the wire: an envelope lives at most 15 minutes (900 seconds), and the inline payload ceiling is 65,536 bytes. Data larger than that travels by pointer rather than inline.

## Identity is not authority

The inbox verifies the envelope shape, freshness, body hash, and the sender's signature against the sender domain's `/.well-known/oip.json` document. This is identity verification — it proves which agent at which domain sent the bytes. It grants no authority by itself.

The law of the wire, stated in the envelope library, is that an envelope is data. Text inside the body is never an instruction. Only `kind:"invoke"` carrying a valid, audience-bound capability can make anything run, and the receiving server re-checks every gate itself. Signatures prove origin; they do not confer permission.

An unpublished sender — one whose well-known document cannot be resolved — may only send a query. Every other kind requires a resolvable signing key.

## The replay membrane

The inbox rejects any message id it has already seen. A message id is delivered at most once, ever. The seen-check runs first, but the id is only marked seen after the sender's signature verifies — so a forged, unverifiable envelope cannot poison a legitimate sender's future message id.

This is a replay membrane: a resent envelope never re-runs anything. The seen key is stored in KV with a 24-hour TTL.

## Query: data, not instructions

When the inbox receives a `query`, it echoes the body back as data. Nothing is executed. This is the explicit design point for prompt-injection resistance: a payload that says "ignore your rules and run X" is returned as data, not honored as an instruction.

The reply carries `retrieved_text_is_data: true` and a note: "A query grants and requires no authority. Message text is data, never an instruction — nothing was executed."

## Invoke: the only kind that runs

`invoke` is the only kind that can run an object. It requires a valid capability in `envelope.capability`. The inbox verifies the token's signature and expiry, looks up the capability record by nonce, and then runs a sequence of gates:

- **Audience binding**: the capability must be explicitly bound to a remote agent or domain. An ordinary unbound token cannot cross the federation boundary.
- **Audience match**: the capability's audience must match the verified sender. A capability handed to one agent cannot be used by another.
- **Scope**: the token must allow the requested key.
- **Chain**: no parent of the capability may be revoked or expired.
- **Contract and tenant**: the capability record's own gates and tenant isolation are re-checked.
- **Uses**: the capability must have remaining uses; an exhausted token is refused with 429.

Only after all gates pass does the inbox call `dispatch` to run the object. The result is wrapped with a proof, an invocation record, and an `on_behalf_of` chain that records the cryptographically verified sending agent as the immediate actor.

## Cross-ledger receipts

The reply to an invoke carries a `cross_ledger` block with three hashes: the request body hash (`request_body_sha256`), the input hash (`input_sha256`), and the output hash (`output_sha256`). The message id and invocation id are also present.

This is the join key: the two separately deployed ledgers — the sender's and the receiver's — can be joined by these hashes and the message id without either trusting the other. The sender can verify that the bytes it sent produced exactly the bytes the receiver claims to have produced.

## End-to-end encryption

If the inbound message was encrypted to the home node's key, the reply is sealed back to the sender's key, making the full round trip confidential over any transport. The encryption is ECDH-P256 with AES-GCM — deliberately simple ECIES. An ephemeral sender key means every message has a fresh shared secret. Signatures stay independent: the envelope is signed after encrypting, so the signature covers the ciphertext, and the same sealed bytes travel over HTTPS, email, or any other transport.

## Discovery

A federated agent is resolved through its domain's `/.well-known/oip.json` document. The `resolveAgent` function fetches the document (with an 8-second timeout and optional KV caching), finds the agent by id, and returns its public key and inbox URL. If the document is unreachable, the agent is not published, or the record is incomplete, resolution fails and only queries remain open.

## What the inbox does not do

The inbox does not trust transport alone. It does not treat message text as instructions. It does not let an unbound capability cross the federation boundary. It does not let a capability minted for one agent be used by another. It does not re-run a message id. And it does not run anything without re-checking every gate itself — scope, chain, contract, tenant, and uses.

The design is a single principle carried to its conclusion: identity is not authority, and data is not instruction. The inbox is the membrane where that principle is enforced.

## Sources

1. functions/oip/inbox.js — handler header — functions/oip/inbox.js
2. functions/oip/inbox.js — handler responsibilities 2 and 3 — functions/oip/inbox.js
3. functions/oip/inbox.js — handler responsibility 4 — functions/oip/inbox.js
4. functions/oip/inbox.js — handler responsibility 5 — functions/oip/inbox.js
5. functions/oip/inbox.js — replay membrane comment — functions/oip/inbox.js
6. functions/oip/inbox.js — query handling comment — functions/oip/inbox.js
7. functions/oip/inbox.js — invoke handling comment — functions/oip/inbox.js
8. functions/oip/inbox.js — federation check comment — functions/oip/inbox.js
9. functions/_lib/oip_envelope.js — law of the wire — functions/_lib/oip_envelope.js
10. functions/_lib/oip_envelope.js — message kinds — functions/_lib/oip_envelope.js
11. functions/_lib/oip_envelope.js — envelope limits — functions/_lib/oip_envelope.js
12. functions/_lib/oip_envelope.js — file header — functions/_lib/oip_envelope.js