← projects

Mother Child Toy (MCT) Network: WASI + Patina

Core thesis

A MCT is a P2P network that can make WASI useful as a portable, vendor-neutral execution fabric for agent-safe components.

The goal is not to build another cloud runtime. The goal is to prove that WebAssembly components can become portable, capability-scoped building blocks that run across local machines, peer networks, hosted infrastructure, and edge adapters without changing the component itself.

same child.wasm
  -> local Mother
  -> peer Mother
  -> hosted Mother
  -> edge-adapted Mother

Why this matters

WASI and the WebAssembly Component Model already provide a foundation for portable interfaces and language-neutral components. What is still missing is the practical distributed host story:

discovery
routing
trust
capability grants
replication
replay
peer execution
agent-safe composition

A P2P Mother network can fill that gap by acting as a distributed component host model built around explicit capabilities, reusable children, and portable WIT-defined contracts.

Vocabulary

Mother

A Mother is a host/control-plane node.

It can:

  • install children
  • grant toys
  • route commands
  • supervise execution
  • record runs
  • coordinate with peer Mothers
  • expose children through local, hosted, or edge adapters

In the long-term vision, Mothers form a peer network rather than relying on one vendor-owned runtime.

Child

A child is a reusable WebAssembly component with a typed contract.

It is not just a plugin. It is a locked, portable computation unit that exposes specific commands and imports only the toys granted to it.

Child = WIT contract + WASM component + fixed imported toy surface

Examples:

  • folder watcher child
  • git status child
  • slate/spec manager child
  • indexer child
  • summarizer child
  • sync child
  • proof receipt child

Toy

A toy is a capability interface.

Toys are usually either:

  • WASI Preview 2 interfaces
  • custom WIT interfaces
  • host-provided service interfaces

A toy becomes part of the child’s imported world. The child does not dynamically grab arbitrary tools. It is born with a fixed capability surface.

child.wasm
  imports:
    wasi:filesystem
    wasi:clocks
    patina:git
    patina:measure
    patina:log

Agent

An agent is a planner/composer, not an unconstrained executor.

Instead of giving an agent shell access, broad filesystem access, and raw internet access, the agent composes locked children.

bad:
  agent gets shell + filesystem + internet

better:
  agent invokes folder-watcher child
  agent invokes git child
  agent invokes indexer child
  each child has fixed toys and a typed contract

What the P2P Mother network can contribute

1. Prove portable components outside the cloud

Most component demos look like this:

component -> one host

The P2P Mother network should demonstrate this:

same child.wasm
  -> local Mother
  -> peer Mother
  -> Rivet-backed Mother
  -> Cloudflare-edge-adapted Mother
  -> self-hosted Mother

This proves WASI as a portable app substrate, not just a serverless packaging format.

2. Standardize reusable capability packs

Toys can become practical WIT capability bundles.

Possible toy packs:

patina:fs-watch
patina:git
patina:knowledge
patina:agent-log
patina:proof-receipt
patina:p2p-sync
patina:measure
patina:query
patina:blob
patina:event-log

The important contribution is not Patina-specific branding. The important contribution is reusable WIT interfaces that other hosts can implement.

3. Build the missing distributed host story

WASI gives us component boundaries. The Component Model gives us typed composition. But the ecosystem still needs patterns for distributed execution:

Where is the component installed?
Who is allowed to invoke it?
What capabilities does it have?
Can another peer run it?
Can the run be replayed?
Can the output be verified?
Can the same component move between hosts?

A P2P Mother network can answer those questions.

4. Make agents safer by construction

The strongest near-term value may be agent safety.

Agents should not improvise infrastructure every time. They should compose known, typed, reusable parts.

watch-folder
index-docs
query-sqlite
emit-facts
sync-peer
summarize-changes
write-report

Each child should be:

  • typed
  • constrained
  • portable
  • replaceable
  • inspectable
  • testable
  • replayable where possible

This turns agent work into portable, capability-scoped building blocks.

5. Create conformance pressure

A high-impact contribution would be a practical portability test suite.

Questions to test:

Can this child run unchanged across multiple Mothers?
Do these WIT toys behave the same across hosts?
Can a recorded run replay?
Can capability denial be deterministic?
Can the same command produce the same transcript?
Can a child be moved between local, peer, and hosted environments?

This creates pressure toward real interoperability.

Cloudflare and Rivet positioning

Cloudflare and Rivet should be deployment surfaces, not the architecture.

Cloudflare

Cloudflare is useful as:

  • public edge adapter
  • static web app host
  • auth/session gateway
  • cache layer
  • Worker-based request router
  • D1/KV/R2-backed toy implementation
  • Durable Object coordinator

Cloudflare should make Patina reachable, but it should not become the thing Patina has to trust.

Browser
  -> Cloudflare Worker / Pages
  -> Bridge Child
  -> Mother / P2P Mother network
  -> Target Child

Rivet

Rivet may be useful as:

  • hosted stateful runtime
  • actor/session substrate
  • realtime backend
  • workflow/queue layer
  • self-hosted or BYOC execution surface

Rivet may be a stronger fit for hosted children than Cloudflare, but it should still be treated as one possible target.

Mother
  -> deploy child to local
  -> deploy child to peer
  -> deploy child to Rivet
  -> expose child through Cloudflare

Bridge Child pattern

A bridge child is a normal child whose job is to connect an outside environment to the Patina world.

Examples:

web-gateway child
cloudflare-bridge child
rivet-bridge child
tailscale-bridge child
local-lan-bridge child

The bridge child should not be special magic. It should be just another child with a typed contract and locked toys.

Cloudflare Worker
  -> Bridge Child
  -> Mother routing
  -> Target Child

This keeps Cloudflare thin and replaceable.

Determinism and proof direction

The proof-friendly framing is:

Child = bounded WASM component
Toys = imported environment
Mother = authority that instantiates the child with that environment
Event log = replay/proof substrate

A child’s pure computation may be provable. A toy call is interaction with the outside world.

Therefore toys may need execution modes:

normal toy:
  execute for real

recorded toy:
  execute and log input/output

replay toy:
  return logged output

proof toy:
  expose deterministic or precommitted data

The toy interface stays stable. The toy implementation can vary by execution mode.

same child.wasm
same WIT imports
real toy backend OR replay toy backend OR proof-safe toy backend

Strategic distinction

This is not mainly about being a better serverless platform.

The real distinction is:

a zero-lock-in operating layer for deterministic agent legos.

Or:

a P2P agent runtime with locked reusable children.

Or:

a distributed WASI component host for capability-scoped, replayable, agent-safe computation.

Minimum valuable slice

The first useful proof should be small.

1 child: folder watcher
1 child: git status or slate manager
1 child: indexer
1 toy pack: log + measure + fs + git
2 hosts: local Mother + remote Mother
1 bridge: Cloudflare or simple HTTP bridge
1 receipt: every run has a replayable transcript

Success criteria:

  • same child runs unchanged on two Mothers
  • child imports are fixed and visible
  • toy grants are explicit
  • commands are typed
  • runs emit receipts
  • at least one run can be replayed
  • the edge adapter can be replaced without changing the child

One-line thesis

Patina’s P2P Mother network turns WASI components into portable, capability-locked legos that agents can safely compose across local, peer, hosted, and edge environments without vendor lock-in.