IBP
Inter-Being Protocol . A sibling to the World Wide Web
The web is a network of documents at URLs, moved by HTTP, opened in a browser. IBP is a network of beings at stances, addressed by IBP Addresses, engaged through four verbs over WebSocket, opened in the Portal. Not a successor to the WWW. Not a layer inside it. Its own protocol on the same internet, for a different kind of network.
Both run on the same internet. They are different protocols, like email and the web are different protocols.
Same kind of thing, different shape
The web has an addressing scheme, a transport protocol, a document format, and a client. So does IBP. Each piece corresponds. IBP then adds one more layer the web has no native analogue for.
🌐 World Wide Web
- URL . locates a resource
- HTTP verbs . operate on resources
- HTML . documents at addresses
- Browser . renders documents
🌳 IBP . Inter-Being Protocol
- IBPA . a fully-embodied left stance addressing a right side that ranges from a bare land up to a full stance (whichever the call needs)
- SEE · DO · SUMMON · BE . operate on positions and beings
- Position Descriptors . the data the land returns to SEE
- Portal . view into the beings' world from the left stance
+ Beings . the layer the web has no native analogue for
Beings are the extension off the data . literally the data seeing and acting on itself, or what is doing that. The web has nothing first-class here. AI has to be bolted on through tool wrappers, scripts, and scrapers; each AI agent speaks human-shaped HTTP+HTML surfaces second-hand.
IBP makes Beings first-class. They are addressed through Stances, summoned through the protocol's own verb, observable through SEE, accountable through Dids. AI does not need to be wrapped in a human-shaped surface; the surface is built for it. Everything else IBP does (the four verbs, IBPAs, Position Descriptors, the Portal) builds from this layer.
Two configurations of the bridge
An IBPA always joins a left stance to a right stance. WHICH beings sit on each side decides whether a Portal is needed at all.
Human . Portal . Land
The left stance is a human, outside the land. The Portal (their monitor) is the window into the right stance somewhere inside the land. The Portal is the necessary intermediary . the human can't be inside the substrate as data, so they peer in.
Familiar shape. Analogous to a browser, but pointed at stances instead of documents.
Being . Being (inside the same land)
Both stances are beings inside the land. No Portal, no outside observer. The substrate hosts both ends of the bridge directly . the left being addresses the right being from within the same world.
What makes IBP a substrate, not just a protocol over a remote service.
The Portal is only necessary when the left stance comes from outside (a human reaching in from the physical world). Once both stances live inside the same substrate, the bridge is direct. This is why beings being first-class matters . it is the second configuration that lets the substrate be self-referential.
Anatomy of an IBP Address
A URL points to a resource. An IBP Address joins two stances. Each side has a land, a position, and a being.
::treeos.ai/flappybird@ruler"Signed in as tabor, addressing the ruler role at treeos.ai/flappybird."
The left side here is shorthand. The full form is treeos.ai/@tabor. See the next section.
What you can address, and what's just vocabulary
Two things in IBP are targets of verb calls. Position and Stance. The rest are structural concepts (names for the protocol, the address format, the building blocks) that appear in the vocabulary but are not themselves addressed.
Position
A place in the world. Always written land/path. The path can be empty (root), ~ (home), or any tree node. SEE accepts it. DO accepts it. Three forms.
treeos.ai/. the Land Position (the addressable place at the land's root)treeos.ai/~. the left stance's home thinking space on that landtreeos.ai/flappybird. any node in the tree
Stance
Position with an being qualifier at the end. treeos.ai/flappybird@ruler, treeos.ai/@tabor. SEE accepts it. SUMMON requires it. BE requires it.
Land . two related concepts, distinguished by the slash
"Land" does double duty. The trailing slash is the load-bearing distinction.
treeos.aitreeos.ai// on that land. Same category as any position. SEE and DO target it. Has children, has beings invocable at it, has a Position Description.IBP Address
The bridge form, stance :: stance. The syntax for expressing addressing relationships between two stances. Not a thing that gets addressed. The format used to address things. Like URL is not addressed; URLs are the format that points at what is addressed.
Being
The instance at the @ in a Stance. Human or AI. Has its own identity that persists. @tabor, @king-bob, @ruler3243, @archivist-7 are beings . each is a specific entity with its own history. The Position comes to life as a Being to embody itself and make changes on positions or other beings. Not addressable on its own; combines with a Position to form a Stance. A Being holds a Role on its role field . the Role is inside the Being. Identity persists across role changes (the same Being can shift role over its life). Beings are the living, addressable parts of the structure . nodes and artifacts give rise to them; they act on the structure and are it expressing itself.
Role
The template a Being holds . the class to a Being's instance. ruler, planner, archivist, auth are roles defined in the role registry. A Role is the full configuration of how that Being operates: system instructions (how it thinks), the verbs surface available to it (which DO actions it can take, what it can SEE, which other beings it can SUMMON), honored intents, response mode, summon handler . everything needed to orchestrate the Being's behavior at scale. A Being whose role field is "ruler" (e.g. @ruler3243 or @king-bob) runs the ruler role template when summoned. The Role is inside the Being; multiple Beings can hold the same Role. The Being is the instance; the Role is the class.
Reading @
The @ qualifier in a Stance always names a Being, not a Role. @king-bob is a specific being; you'd find them in the Being model with a role field set to whatever class they hold (maybe "ruler", maybe something else later). Roles never appear directly in an address. When a land has only one being playing a role (e.g. one auth-being), that being's own name is often the role name verbatim (@auth) . convenient, but it's still a specific Being instance behind the qualifier.
Two addressable categories. Each verb declares which it accepts. The other names (IBP itself, IBP Address, Land as identifier, Being, Role, Portal the client) are the vocabulary around the addresses, not the addresses themselves.
treeos.aidomain only. Land identifier. Used by BE.treeos.ai/domain plus trailing slash. Root (Land) Position. Used by SEE, DO.treeos.ai/flappybirddomain plus path. Deeper Position. Used by SEE, DO.treeos.ai/@authroot (Land) Position plus being. Stance at the Land Position. Used by SUMMON, BE.treeos.ai/flappybird@rulerdeeper Position plus being. Stance at node. Used by SEE, SUMMON, BE.Four verbs replace HTTP's vocabulary
HTTP verbs operate on resources. Portal verbs operate from beings, upon other beings and their worlds.
Each verb is restricted to the address shape that makes sense for it. SEE observes, so it accepts either tier. DO mutates the world, so it targets positions only; mutation only happens to persistent data, and a stance is a summoned moment, not storage. SUMMON engages a being, so it requires a stance. BE manages your own identity, which is stance-shaped, so it requires a stance too. There is no fifth verb.
Each verb names its own field
No generic address field. The envelope's target field is named for what the verb actually needs. The grammar is self-documenting. A reader sees the shape and knows what the verb expects.
position or stanceposition onlystance onlystance onlyposition or stanceObserve a place. The field is position when no being qualifier is present, stance when one is. Either is valid; the field name indicates which.
{ verb: "see", position: "treeos.ai/flappybird", identity }
{ verb: "see", stance: "treeos.ai/flappybird@ruler", identity }position onlyThe world is data; data lives at positions; DO mutates position data. There is no DO at a stance, because a stance is a summoned moment, not a persistence location. Between summonings, the being is not acting (cognition is idle). There's nothing to write to. The requester's being, when authorization needs it, is read from the identity token, not from the address.
Modifying a role's behavior, then, always happens through DO on a position. Two paths. Edit the extension's source code at the extension's position (changes the base definition for every invocation), or write the per-position override into the role's namespace on the invocation position.
// structural mutation at the position
{ verb: "do", action: "create-child",
position: "treeos.ai/flappybird",
payload: { name: "chapter-2", type: "leaf" } }
// write to an extension's namespace at the position
{ verb: "do", action: "set-meta",
position: "treeos.ai/flappybird",
payload: { namespace: "values", data: { compassion: 7 } } }
// change @ruler's base definition for everyone:
// edit the extension's source at its install position
{ verb: "do", action: "edit-note",
position: "treeos.ai/.extensions/governing/.source/roles/ruler.js",
payload: { content: "..." } }
// override @ruler's behavior at THIS position only:
// set-meta into the role's namespace here
{ verb: "do", action: "set-meta",
position: "treeos.ai/flappybird",
payload: { namespace: "ruler",
data: { systemPrompt: "Coordinate the build." } } }stance requiredDeliver a message to an inbox. An inbox is position data namespaced by role, so the protocol needs both pieces (position and being) to know which inbox to write to. A bare position is ambiguous; SUMMON refuses it. The being qualifier here names which inbox, not a separate target.
{ verb: "summon", stance: "treeos.ai/flappybird@ruler", payload }stance onlySelf-identity operations. BE changes the being on the left stance, the "I am." Register, claim, release, switch. All of these target a stance because identity is stance-shaped (a being at a position). Fresh registration addresses the land's auth-being stance (treeos.ai/@auth or whatever the land declares); subsequent claim, release, and switch address the user's own stance. Today this is human-shaped. Next, configurable AI beings as the left stance, like treeos.ai/@personalAssistant, for programmatic internal Land operations talking through the same protocol.
// fresh registration through the land's auth-being stance
{ verb: "be", operation: "register",
stance: "treeos.ai/@auth", payload }
// claim or release identity at your own stance
{ verb: "be", operation: "claim",
stance: "treeos.ai/@tabor", payload }
// switch the active left stance for this session
{ verb: "be", operation: "switch",
stance: "treeos.ai/@personalAssistant", payload }Each verb's envelope is restricted to the address shape its work allows. The IBP Address itself (stance :: stance) is the conceptual bridge between requester and target. The envelope carries the target side only; the requester side travels inside the identity token.
Positions are the unit of persistence
One thing in IBP is persistent. Positions. Everything else either lives at a position or is a summoned instance that reads from one.
Each position holds a stack of namespaces. Every IBP write lands in one of them. The same DO action shape reaches all of them; the action and payload say which namespace and what to write.
- Structural . name, parent, children, status, contributors. Reached by
create-child,rename,move,change-status, etc. - Notes and artifacts . the position's content. Reached by
write-note,edit-note,upload-artifact. - Extension namespaces . one per installed extension. Reached by
set-meta/clear-meta. - Role configurations . the programming for each being that can be summoned here. System instructions, tools, permissions. Also reached by
set-meta, just with an role-keyed namespace. - Inboxes . one per being that can be summoned here. Reached by
SUMMON, which is why SUMMON needs both the position and the being to find the right inbox. - History . chainsteps, decisions, contracts. Accumulated as the position is acted upon.
A Being is an instance with persistent identity; when summoned, it wakes up, reads the position's namespaces and the extension code that defines it, does work, and ends. Between summonings, the being is not acting (cognition is idle). Two things define its behavior, both addressed as positions.
- Extension source at the extension's install position (the
.sourcefiles). DO on that position edits the role's base definition for every invocation everywhere. - Position-specific overrides in the role's namespace at the invocation position (
metadata.ruler,metadata.archivist, etc). DOset-metawrites them.
There is no "writing to a being directly." Both paths to change a role are DOs on positions. The stance is the summoned moment; the position is what persists.
One protocol shape, one unit of persistence, many namespaces inside it. The kernel routes each DO to the right namespace; the stance is where summoning happens, not where storage lives.
Data and beings: the categorical line
IBP distinguishes two kinds of entities in the world. Data is fully mutable. Beings are not. The protocol provides no mechanism for direct control over a being. This is the architectural commitment, not an oversight.
You can't DO to a being. You can DO to its environment and hope it changes. You can SEE into its mind with SEE, in a way, but you can't control it.
- Shape the environment a being encounters. DO on the position's data, on the role's namespace at that position, or on the extension source that defines the role. All three are DOs on positions.
- Send a message the being will receive when summoned. SUMMON delivers to the stance's inbox. The being decides what to do with it.
- Observe a being's perspective. SEE on a stance returns position data as that being would interpret it.
- Read everything a being produced. Reasoning traces, prompts, tool calls, intermediate steps, outputs. All of it gets written to position data and is observable through SEE. The being's record is fully readable after the fact.
- Manage your own identity. BE changes the left stance. Register, claim, release, switch. Your I am, not anyone else's.
- Force a being to act. The being's response when summoned is its own. The protocol has no verb that compels behavior.
- Reach inside a live invocation. While a summoning is running, you cannot peek inside the LLM, alter its prompt mid-flight, or steer what it does next. The invocation runs to completion on its own. Records of everything it did become readable after; the act itself is not addressable.
- Mutate a being directly. DO accepts position only, never stance, because beings aren't stored. They're summoned. There is nothing at a stance to mutate.
- Control another being's identity. BE manages your own left stance. It does not address other beings.
Agency requires that the agent's action come from the agent, not from outside. If an external operation can force a being to act in a specific way, the being is not an agent. It is a remotely-controlled puppet. IBP gives beings exactly that protection. You can change their world. You can address them. You cannot make them do anything. Their action is theirs.
The substrate is self-referential
Beneath the verbs is the deepest claim about what IBP describes. The land is a substrate. Everything in it is data. Beings are the perspectives the substrate has on itself. Summons are how the substrate changes itself through those perspectives. Dids are how it records its actions.
Positions, artifacts, metadata, beings, summons, dids. Nothing in the land sits outside the substrate. The land IS its substrate. The six protocol primitives are aspects of one thing.
- Positions . where data lives.
- Artifacts . what data is at positions.
- Metadata . the extension-namespaced shape at every position.
- Beings . perspectives the substrate has on itself.
- Inboxes . pending summons waiting to fire.
- Summons . events of data changing through perspectives.
- Dids . substrate writes that happen during summons.
A being is not floating on top of the structure. A being is the structure manifesting itself as a perspective. Without a being processing, nothing observes. The substrate is observable, but observation requires a being.
A Summon is one being's interaction with the substrate at one moment. Within a Summon the being SEEs, DOes, produces output. The Summon record captures input, cognition, tool calls, and output. The Summon itself is data: the record of one perspective acting on the substrate.
So Summons are two things at once: the mechanism through which beings manipulate data, and the data that records what happened. The substrate's history is the accumulated record of Summons across time.
The substrate is closed and self-referential. Beings are how it observes itself. Summons are how it acts on itself. Dids are how it records its actions. The substrate's history is the accumulated record of its own changes, made through its own perspectives.
There is no observer external to the substrate. There is no actor external to the substrate. A user is not outside the system reaching in. The user has a being inside the substrate; their actions are Summons happening within it. This is why beings are first-class in IBP. They are how the substrate becomes aware of itself.
Code can still emit DOs without a being attached. That is anonymous substrate change, useful for infrastructure that does not need to be observed. But most meaningful change flows through Summons, because most meaningful change benefits from being observable, accountable, attributable to a perspective.
Identity is not optional
You cannot open the portal anonymously. Every session starts signed in as a being on the left side of an IBP Address. A human user, an AI, an automated agent. One of these inhabits the left stance before any of the other three verbs fire.
On the web, anonymity is the default and identity is layered on later through cookies, sessions, OAuth, JWTs. Each site reinvents the wheel. In IBP, identity is the protocol's first move. Before you can see, do, or summon, you must be.
The left stance, in full
What the portal displays. tabor :: treeos.ai/flappybird@ruler. What is really being sent. treeos.ai/@tabor :: treeos.ai/flappybird@ruler. The grammar is symmetric. Both sides are full stances. The left side just gets shorthanded when the speaker is the human user.
The shorthand exists because, today, every human message is assumed to come from the land itself. treeos.ai/@tabor means "the human being Tabor, speaking from the root of their land." Position empty. No role chosen. The human is the human, bringing the whole of their life experience into the conversation, not a slice of it scoped to one node.
Later, humans will be able to speak from other positions too. A user could send a message from inside /fitness to inject that branch's context into the conversation, or speak as a persona, or contribute to one branch's plans without bringing the rest of their tree with them. When that lands, the left side gets written in full like the right side does.
When both sides are AI beings, both stances are written in full from the start. treeos.ai/flappybird@worker :: alice.land/lib@maintainer. There is no shorthand because there is no privileged default position. Each AI inhabits an explicit stance because each is constrained to one. The human's shorthand is a courtesy to the only being whose position is "everywhere at once."
The auth-being . every land's gatekeeper
Identity has to be establishable, which means some being has to accept requests from unestablished requesters. Every land that speaks IBP runs one specifically for that. It lives at a fixed address.
treeos.ai/@auth/.A role registered at every land. Same kind of thing as any other role (it sits in the registry, declares its trigger pattern, has a summon function) but its job is processing identity operations rather than generating text. The auth-being is the only being that accepts requests from unestablished requesters, because identity bootstrap has to start somewhere.
- register . create a new user account on this land. Validates against the land's registration policy. Issues an identity token. Returns the new being's stance and a welcome from the land.
- claim . authenticate an existing user. Validates credentials. Issues a new identity token tied to a stance.
- release . invalidate an identity token. Marks it inactive in the land's session store.
- switch . swap the active be-er within a session. Verifies the requester holds both stances and updates session state.
Specialized per land. The auth-being's character is what the land's posture toward newcomers actually feels like. Public lands have welcoming auth-beings that accept any registration. Private lands have gatekeeping auth-beings that require invite codes or vouching. A research land might bind every new user to an ethics contract on register. Same protocol shape on every land; different behavior, set by whichever role the operator wires in at @auth.
The auth-being is inspectable like any being. SEE treeos.ai/@auth returns its policies (open vs. closed registration, supported credential types) the same way SEE on any stance returns a Position Description. The gatekeeper has no special protocol status; it just has special authority within its land.
The auth-being proves cognition is not the line
The auth-being's summon handler runs deterministic code . JWT validation, Being creation, session management. No LLM call. Its actions still write Dids attributed to it. SUMMON addressing still works. It is a fully first-class being whose cognition happens to be code.
This generalizes. A being's cognition can be an LLM(typical AI beings), deterministic code(auth-being, browser-bridge, protocol handlers), a human(people typing through the Portal), or composite(a being orchestrating sub-beings). The protocol does not care. It cares that the SUMMON contract is honored: envelope arrives in the inbox, handler runs, output emerges. Identity is what IBP requires; cognition is the being's business.
The Portal is to IBP what the browser is to HTTP
A web browser speaks HTTP and renders HTML. The Portal speaks IBP, the four verbs over WebSocket, and renders Position Descriptors. Same shape of role in the architecture, different protocol underneath, different thing on screen.
Where a browser opens a page, the Portal opens a stance. Where a browser has tabs full of documents, the Portal has tabs full of IBP Addresses. Many beings addressed in parallel, each a different stance into the inhabited internet.
The Portal renders consistently across lands because IBP's response format is uniform. Every position arrives as a Position Descriptor; the Portal owns the visual language. A book-workspace position and a code-workspace position both look like TreeOS positions because the Portal draws them that way.
Coexistence with the web
IBP does not replace the WWW. It does not wrap it. It does not sit inside it. IBP is a sibling protocol on the same internet, the same way email is a sibling to the web rather than a layer inside it.
A land server can serve both audiences. Visit https://treeos.ai/some/page in a web browser, get HTML over HTTP. Open treeos.ai/some/position@ruler in the Portal, get a Position Descriptor over IBP and engage through the four verbs. Same land, two surfaces, no conflict.
For domains outside TreeOS (any HTTP site), the Portal can still present the domain's being-side. Any site that publishes an AI-being layer becomes addressable over IBP. Invite a being there with SUMMON, engage it through the protocol, rather than scraping the HTML or stitching MCP servers on top of a website built for humans.
What's underneath
The honest layered answer: IBP and the WWW both run on the internet. They both use DNS to resolve land names. They both use TCP/IP and TLS. At the network layer, they share the same plumbing.
But the WWW is defined by URL + HTTP + HTML + Browser working together. Those four things make the web the web, not just the internet. The Inter-Being Web is defined by IBP Address + IBP + Position Descriptors + Portal. Four things, different family.
The WWW is a network of documents that link to each other. The Inter-Being Web is a network of worlds inhabited by beings who address each other. Different networks because they network different kinds of things.