Every visitor, before they identify
For visitors who are strangers to the protocol. No signed-in identity anywhere. A regular stance, not a protocol special case. Every land that speaks IBP runs one, with permissions configured per land. That single configuration surface covers the full spectrum from a fully closed personal land to a fully open public space.
Note. Arrival is not what happens when an identified visitor reaches a different land. Identities carry across lands; the receiving land's policy assigns the visitor a stance other than arrival. How the layer handles that →
IBP makes exactly two structural commitments about arrival. Beyond these, every land decides for itself what an arrival can see, do, or say.
That's it. SEE, DO, SUMMON, and every other BE operation are land-configured. Permission for an arrival to do any of them is whatever metadata the land has set for the arrival stance.
One configuration surface (the arrival stance's permissions per verb) covers the full range from "completely closed" to "fully open." Land owners pick where on the spectrum their land sits.
visibility: public (introduction, what kind of place it is, what beings live here, public artifacts). To do anything beyond viewing requires BE-register or BE-claim. Common pattern for community sites that want discoverability without anonymous interaction.allowed_targets (a greeter, help desk, guide). Still can't reach private beings. The land has public beings as part of its surface for unauthenticated visitors.allowed_actions: "*", SUMMON with allowed_targets: "*". Sign-in is optional and just for persistence and identity. Useful for very open community spaces.The arrival stance's permissions live in the land's metadata under the role namespace. Each verb gets its own simple allow rule. The kernel checks them on every request from an arrival.
// at the Land Position
metadata.beings.arrival.permissions = {
see: { allowed_visibility: ["public"] },
do: { allowed_actions: [] },
summon: { allowed_targets: [] },
be: { allowed_operations: ["register", "claim"] }
}
// land-level BE flags read by the auth-being
metadata.auth.register_enabled = true
metadata.auth.claim_enabled = trueWhat this shape supports. SEE on positions whose visibility field is in the allow list (the Node schema already carries visibility). DO actions restricted to a named list, or "*" for all, or [] for none. SUMMON targeted at a named role list ("@auth", "@guide"), or "*", or []. BE operations restricted to a subset of register / claim / release / switch.
The shape extends in place as lands surface needs for richer rule semantics: glob path matching, conflict resolution between overlapping rules, per-action scope-and-namespace constraints. Same metadata namespace, richer rule shape.
Most lands fall into a small number of recognizable patterns. The TreeOS reference implementation ships templates so installers don't have to author arrival permissions from scratch. The defaults are conservative; pick a template to open up.
The arrival stance is not a special protocol concept. It is just a stance whose permissions a land happens to configure for "someone who has arrived but hasn't been welcomed." The same authorization layer that checks any other stance's permissions checks the arrival stance.
This means the protocol commits to almost nothing about arrivals (two rules, see above) and pushes all the variation to the land's configuration. The web's flexibility comes partly from HTTP being minimal and HTML/CSS/JS handling all the expressiveness above. IBP follows the same pattern. The substrate stays small; the lands handle their own character.
The same architectural move applies to other stances a land might define. A "guest" stance for recognized visitors with ongoing presence. A "member" stance for full participants. A "moderator," "contributor," "owner." Each is a role with permissions. Land owners shape the taxonomy that fits their land's character. The protocol stays uniform underneath.
Different lands feel different because they configure differently, not because the protocol has different modes.