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

slug: object-invocation-protocol-intellectual-lineage · https://miscsubjects.com/a/object-invocation-protocol-intellectual-lineage · tags: oip, object-invocation-protocol, protocol-history, capability-security, hateoas, linked-data, formal-methods · updated 2026-07-17T02:40:47.335Z

# 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

| lineage | thinkers and systems | recurring idea | OIP expression |
|---|---|---|---|
| Addressability and discovery | Ted Nelson; Roy Fielding; Tim Berners-Lee | stable addresses and in-band links let a reader discover the next move | public object URLs, three views, machine-readable affordances |
| Messages and objects | Kristen Nygaard and Ole-Johan Dahl; Alan Kay; Carl Hewitt; Barbara Liskov; Robin Milner | computation is interaction among bounded objects with explicit interfaces | one dispatch door, directory objects, typed contracts, runner boundaries |
| Authority as an object | Jack Dennis; Norm Hardy; Mark Miller; Jerome Saltzer and Michael Schroeder | possession of a narrow reference conveys authority; authority can be attenuated and revoked | scoped capability records, parent-child delegation, risk ceilings, use budgets, revocation membrane |
| Causality and proof | Leslie Lamport; Pat Helland; event-sourcing systems; W3C PROV | distributed work needs causal ordering, durable evidence, and explicit correction | invocation receipts, replay_of, repairs/repaired_by, authority-preserving trails |
| Self-description and recursion | Douglas Engelbart; Norbert Wiener; Ross Ashby; Gordon Pask; Heinz von Foerster | a system improves when its operation and correction loop are visible to itself | self-describing payloads, live contracts, conformance clauses, revision and objection surfaces |

## 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](https://miscsubjects.com/api/dispatch?confirm=inv_sooi304em9). 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.**

## Sources

1. Architectural Styles and the Design of Network-based Software Architectures — https://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm
2. Linked Data — https://www.w3.org/DesignIssues/LinkedData
3. Robust Composition: Towards a Unified Approach to Access Control and Concurrency Control — https://papers.agoric.com/papers/robust-composition/full-text/
4. The Protection of Information in Computer Systems — https://www.cs.virginia.edu/~evans/cs551/saltzer/
5. Time, Clocks, and the Ordering of Events in a Distributed System — https://lamport.azurewebsites.net/pubs/time-clocks.pdf
6. OIP v0.9 accepted payload-ceiling invocation — https://miscsubjects.com/api/dispatch?confirm=inv_sooi304em9