Skip to content
Inhuman Docs

Replication boundaries

Plexus models live on a Yjs document and use MobX for local reactivity. Defining a synced accessor is not the same as connecting two peers. The models describe what is shared; a provider and transport determine how document updates reach another process.

Keep the responsibilities separate

Section titled “Keep the responsibilities separate”
  • Model layer: @here.build/plexus tracks decorated fields, child ownership, identity, and derived MobX views. See Models and ownership.
  • Replication substrate: Yjs holds the document state and CRDT operations. Plexus does not replace Yjs.
  • Transport/server: the repo includes y-messageport and y-control-channel for MessagePort routing and plexus-do for a Cloudflare Durable Object sync server. Pick an integration appropriate to your application; creating a model by itself does not deploy a server.

For a small first experiment, use Plexus.bootstrap(...) to create a root and inspect local mutation/reactivity before choosing a transport. Once peers are connected, changes to synced fields can arrive from another peer and invalidate local MobX computations. Keep application-specific network configuration in the provider layer rather than inventing it in model classes.

Section titled “What to read next”

The existing Plexus docs have dedicated pages for fields, awareness, errors, and the model lifecycle. They are the appropriate source for API and failure details; this page is a map, not a substitute for transport instructions.

Source contracts: plexus/README.md; plexus/packages/plexus/README.md; plexus/docs/src/guide/fields.md; plexus/docs/src/laws/lifecycle.md. Package descriptions for plexus-do, y-messageport, and y-control-channel are in plexus/README.md.