A Land is a single instance of the TreeOS application. Your own server, your own database, your own users, your own trees. It contains it own LLM connections, its own background jobs, its own orchestration processes, its own Skills/Tools, and manages its own energy limits.

Think of it like email. Your Land is your mail server. You can communicate with anyone on any other Land, but your data stays on yours. No central authority owns the network.

Each Land generates a unique cryptographic identity on first boot (an Ed25519 keypair). When two Lands connect, they exchange public keys. After that, all requests between them are signed and verified. No one can impersonate your Land.

Inviting someone from another Land works like inviting a local user. Type username@domain in the invite field. That's it. Your Land handles the rest: peering with the remote Land if needed, resolving the user, sending the invite through the Canopy protocol.

When the remote user accepts, a "ghost user" is created on your Land. This is a lightweight record (just their ID and isRemote: true) that gets added to the tree's contributor list. The existing permission system works unchanged. No special cases.

The remote user interacts with your tree through their own Land's API. Their Land proxies the request to yours with a signed token. They never create an account on your server. They never see your frontend. They just use their own tools, their own Land, and the tree shows up in their list alongside their local trees.

When a user interacts with a remote tree, the request chain is:

The user's client (browser, CLI, mobile app, script) never needs to know about Canopy. It talks to one URL. The proxy is invisible. This works with any client that speaks the API.

A ghost user is a User record with isRemote: true and a homeLand field pointing to their home domain. It has the same UUID as the real user on their home Land. No password, no email, no settings.

Ghost users exist so the API doesn't need special cases. Every route checks req.userId against the tree's owner and contributor list. Ghost users are in that list. The permission check is identical for local and remote users.

If you remove a remote user from your tree's contributors, they lose all access instantly. If you block their entire Land, all ghost users from that Land are locked out because CanopyToken verification fails.

The REST API under /api/v1/ and the Canopy protocol under /canopy/ are the contract. Every Land that speaks this contract is compatible. The nodes, trees, values, contributions, notes, all of the context structure stays the same across every Land.

Everything deeper (how AI places nodes, how dreams work, how orchestrators run, what frontend you build) is yours. You can build completely custom AI systems, custom UIs, custom pipelines. As long as the context structure and API stay consistent, it all connects. This is a network for context, and the API is the glue.

Lands don't need to be pre-connected. The network grows organically from collaboration. The first time a user invites someone from another Land, the two Lands peer automatically (via the directory or direct URL). After that, they stay connected and monitor each other's health.

The directory service is optional. It's a phonebook that makes discovery easier. If it goes down, peered Lands keep working. Eventually, Lands could discover each other peer to peer without any central service at all.

Everything behind the API is yours. Lands in the network can run completely different code internally. The API shape and the Canopy protocol are the contract that holds the network together. Everything else is customizable.

All cross-land requests are signed with Ed25519 keypairs. The tree's Land is always authoritative: it controls permissions and validates access. A remote Land can prove its users' identity but cannot grant itself permissions. Tokens expire after 5 minutes. Lands can block peers and remove remote contributors at any time.

Clone the repo, set your domain and MongoDB connection, and runnode server.js. Your Land generates its identity on first boot and is ready to go. Connect to the directory to be discoverable, or peer manually with other lands you know.