Owning and Selling a Post

*Part 10 of An OS Where the AI Is Never a Principal.*

The previous post made a claim that should have felt a little too easy: that sharing — the thing every social platform is built around — is *just* capability propagation. A boost is an introduction. You hold a reference to a post, you pass a copy onward, and now someone else can reach it too. Sharing is delegation. Done.

It *is* that easy, and that is exactly the trap. Because the same mechanism that makes sharing effortless makes *selling* impossible — and almost every platform that has ever tried to let you "own" a post has gotten the philosophy quietly, structurally wrong.

This post is about formalizing ownership. It's the deepest part of the microblog, and it's the part where an AI agent turns out to own property by the exact same mechanism a human does — no special case, no asterisk. Let me build up to why that's true.

Sharing is copy. Ownership is exclusive.

Here is the distinction the whole post turns on:

Capability-passing is copy-by-default. When you hand someone a reference, you still hold yours. That is perfect for sharing — and wrong for selling.

Think about what sharing *wants*. Alice boosts her post to Bob; Bob now reaches it; Alice still reaches it; the post is in two streams at once. Nobody lost anything. Copy is the correct semantics, and the ocap model gives it to you for free — references are values, and passing a value doesn't consume it.

Now think about what *selling* wants. Alice sells the post to Bob. After the sale, Bob owns it and Alice does not. Alice must lose something. Selling is exclusive transfer: a thing that was in one place is now in another place and *no longer in the first.*

You cannot get that from capability-passing. There is no "move" primitive hiding in "copy." If I give you a reference and keep mine, we both have it — that is the definition of the operation. Exclusivity is not a property you can *discover* in the capability model. It is a property you have to manufacture. This is Mark Miller's exclusive-transfer problem, and it's the seam where naive "everything is a capability" gets honest.

A deed is the root; a share-cap is a leaf

So what does it even mean to *own* a post, as opposed to merely hold a reference to one?

In Aegis, owning a post means holding its deed. The deed is not a read-cap or a share-cap. It is the mint — the thing that *issues* all the share and read caps for that post — plus the right to transfer the mint itself. From examples/moimoi/ownership.ts:

export interface Deed {
  readonly postId: string;
  readonly owner: string;        // a label — human or agent
  mintShareCap(opts?: { delegable?: boolean }): PostRef;
  isLive(): boolean;
}

A share-cap is a *leaf*: it lets you read the post, maybe re-share it, and that's the end of its authority. The deed is the *root*: every leaf descends from it, because every leaf was minted by it. The previous post's Alice-Bob-Eve spread was a tree of leaves. The deed is what they all hang from.

That distinction is the whole reason ownership can be exclusive when sharing can't. You don't transfer a leaf — leaves are copies, they're everywhere by design. You transfer the root.

Money is a mint and a purse

Before the sale, a detour through money — because the mechanism is the same one, and it's worth seeing twice.

How do you represent value in a system where references are copyable? If a dollar is just a reference, I copy it and now I have two. Forgery is a Ctrl-C. The naive answer is broken before you start.

Miller's answer, carried over from E and ERTP, is the mint-and-purse pattern, and it's beautiful precisely because it refuses to put the value *in the reference*. A mint issues purses. The balance of a purse does not live in the purse object you're holding. It lives in a closure-private ledger, inside the issuer, keyed by the purse's identity. The purse reference is just a *name* the issuer recognizes; the *amount* is a number only the issuer can read or change.

Two consequences fall out immediately:

• You can't forge money by copying a purse. Copy the reference all you like — the ledger still says that purse identity holds $5. There's no second $5 because there's no $5 *in* the reference to duplicate.
• Payment conserves value. A transfer is the issuer decrementing one ledger entry and incrementing another, in one step. Money is neither created nor destroyed; it moves. Value is conserved by construction, not by audit.

This is the same trick the deed uses. The authority that matters never lives in the copyable thing. It lives behind something only the issuer controls.

The sale: an escrow swap that revokes and re-mints

Now the sale itself — pnpm demo:ownership.

A sale is an escrow swap: Alice gives up the deed, Bob gives up the money, and either *both* happen or *neither* does. In a single-threaded vat this is almost embarrassingly clean. There are no interleavings to defend against, no half-states a concurrent observer can catch. One turn: verify the buyer's funds, move the payment across the ledger, transfer the deed — and if any step can't complete, refund. Atomic because the turn is atomic. (We'll meet the general version of this — running an *untrusted* contract that still can't steal — in the next post.)

The interesting half is what "transfer the deed" actually does, and here the copy-vs-exclusive problem finally gets solved. The deed is held behind a caretaker — a revocable membrane — from birth. So transfer is not a hand-off. It is two operations:

transfer(deed) := revoke(seller's deed)        // cascading: severs every copy
                + mint a fresh deed for buyer

Read the comment in the source carefully: the revoke is *cascading*. It doesn't just kill Alice's deed reference. Because every share-cap Alice ever minted descended from that deed through the membrane, revoking the root severs the whole subtree at once. After the sale, Alice's deed throws when touched, and so do the leaves she'd handed out. Bob holds a freshly minted deed — the only live one. Alice's is inert.

Exclusivity is *produced by revocation*, not assumed. You don't move the authority. You kill the seller's copy and mint the buyer a new one.

That is the manufactured exclusivity I promised. The copy model never gave us "move." So we built "move" out of "revoke, then issue" — two operations the ocap model *does* have, composed into the one it doesn't. The deed feels like a thing that changed hands. Underneath, one was destroyed and another was born.

The corollary: an agent owns exactly like a person does

Here is the part I find genuinely striking, and it's why this post sits where it does in the series.

Look back at the Deed interface. The owner field is a label — a string. The deed does not know, and does not care, whether that label names a human or an autonomous agent. mintShareCap works the same. transfer works the same. The cascading revoke works the same. Nothing in ownership.ts branches on *what kind of principal* holds the deed.

So transferring a post to brand-agent-7 is not a different operation than selling it to a person. It is *the same operation.* An agent that holds a deed is an owner — full stop. It can mint share-caps, set their delegability, sell the post onward, all by the identical mechanism a human uses. There is no "agents can't own property" special case to write, because there was never a place to write it.

This matters far past microblogs. The entire series has argued that the model is never a *principal* for the purposes of security — it's a subject, confined, holding only what it was handed, structurally unable to escalate. That's the confinement story from the thesis post. But confinement and *ownership* are different axes. A confined agent can still hold a deed deliberately granted to it — and when it does, it owns, with all the rights a deed carries, exactly as a person would. The capability graph doesn't have a citizenship test.

That's not a feature I added for agents. It's what you get *for free* when authority is uniform reference-passing all the way down — the same uniformity that, in the companion Endo and Agoric series, lets a mint, a purse, and a car key all be the same kind of object. Build ownership as a transferable mint behind a caretaker, and human ownership and AI ownership stop being two problems. They were always one.

The credit here is Miller's, twice over: the mint-and-purse pattern for money, and the exclusive-transfer construction for the deed. I just pointed both at a social post and noticed the buyer could be a robot.

End of Transmission.