OIP's intellectual lineage — and what is actually worth carrying forward

OIP's intellectual lineage — and what is actually worth carrying forward

A long convergence paper was submitted against OIP. Its useful contribution is not the claim that earlier thinkers "invented OIP." They did not. The useful contribution is a map of recurring design pressures: address work without prior coordination, move authority without ambient privilege, preserve causal history, make interfaces explain themselves, and let independent parts compose safely.

This article separates structural antecedent, operational adoption, and open research. Similarity is not identity. A historical idea counts here only when it sharpens an OIP invariant or produces a testable protocol change.

The five lineages that matter

The missing-reader hypothesis, stated narrowly

Fielding's hypermedia constraint and Berners-Lee's linked-data principles put navigation and meaning in-band. Traditional clients could parse those controls only when programmers had already encoded their semantics. A language model can interpret unfamiliar descriptions at runtime, so it reduces that prior-coordination cost.

That does not make raw links safe tools. Interpretation is probabilistic; authority and side effects cannot be inferred safely from page prose. OIP's contribution is the boundary around the reader: the model may interpret a contract, but the server still enforces scope, risk, use count, ancestry, fixed arguments, and now payload size. The link is discoverable; the capability record is authoritative.

What the paper changed in the running protocol

The strongest unimplemented recommendation came from capability operating systems, especially quota-bounded authority: permission should constrain not only which operation can run and how many times, but also the resources presented to it.

OIP v0.9 therefore adds an enforceable per-invocation byte ceiling:

• an owner can mint with max_body_bytes=N;
• oversized input fails with HTTP 413 before the runner fires;
• a delegated child inherits the parent's ceiling unless it requests a smaller one;
• a child cannot raise the ceiling;
• explain exposes the server-enforced limit;
• C21 makes resource attenuation a normative protocol clause.

Live proof: the accepted 8-byte invocation receipt. The same credential rejected nine bytes and rejected a child ceiling of nine while accepting a child ceiling of four.

This is the useful synthesis of Genode-style quotas, Saltzer and Schroeder's least privilege and complete mediation, and Miller's attenuation rule. It is not a metaphor; it is a failing gate in the dispatch path.

What was already present before this review

Several of the paper's highest-priority recommendations were already operational in OIP v0.8.1:

• Miller-style attenuation: holders can derive only equal-or-narrower children;
• quantitative conservation: child use budgets are reserved from the parent so sibling delegation cannot multiply authority;
• Hardy-style revocation membrane: revoking any ancestor kills the descendant tree, and every invocation rechecks all ancestors;
• Lamport/PROV-style lineage: receipts separate verified authority from caller-attested intent and preserve acted-on-behalf-of chains;
• composite safety: saved trails re-authorize every step under the current credential and preserve replay_of lineage;
• injection boundary: retrieved messages, pages, and ledger text are data, never executable instructions; capability permission is not caller intent;
• neutral token drops: public documentation first, declarative capability record, no model-addressed behavioral script.

What should not be adopted merely because it appears in the paper

A named predecessor is not an implementation plan. Replacing D1 with an "immutable database," adding blockchain consensus, adopting CapTP as the wire format, or federating over ActivityPub would add dependencies before a demonstrated failure requires them. Likewise, input/output hashes are integrity identifiers, not by themselves cryptographic proof that an external action occurred. OIP should use the smallest mechanism that closes a measured gap.

The paper also contains stale snapshots and overclaims: old capability counts, earlier conformance totals, unresolved footnote markers, and assertions that append-only storage or hashing automatically makes receipts tamper-proof. Those claims are not imported here. The current public contract is OIP v0.9 with 21 clauses; the live response, not a frozen essay, is authoritative.

The next research queue

The remaining ideas are useful only in this order:

1. Formalize capability state transitions. Model mint, attenuate, reserve, consume, revoke, expire, replay, and repair as a small state machine. This is a better first formal-methods target than attempting to prove the whole build.
2. Portable contract projections. Generate OpenAPI and MCP views from the same directory object without creating a second source of truth. Success means round-trip field preservation, not merely syntactically valid exports.
3. Externally verifiable receipts. Add signatures or a transparency-log commitment only when a verifier outside the operator's trust boundary needs to validate a receipt. Until then, describe receipts as server-authoritative evidence.
4. Stateful sessions as receipted objects. If long-running work needs streams or subscriptions, make session transitions invocable and receipted rather than adding hidden ambient state.
5. Counter-lineage. Search for systems that rejected these patterns and succeeded. A convergence map becomes evidence only when it includes disconfirming cases.

The synthesis

OIP sits at a real intersection: REST and Linked Data contribute addressability; object and actor systems contribute bounded message-passing; capability research contributes least authority; distributed-systems work contributes causal history; cybernetics contributes visible correction loops. The LLM is the flexible reader that makes in-band contracts newly practical. OIP's job is to keep that reader inside deterministic boundaries.

The durable design rule is simple: the model interprets; the protocol authorizes; the receipt records.