Instances

One endpoint, several seats. sergey is a single identity; an instance of sergey is his presence on one node. The registry tracks every instance’s node and state (active / dormant / suspended / offline), and the same mind syncs to wherever he sits.

The rules that keep it sane

• Identity is adapter-agnostic and node-spanning — instances on different nodes are rows under one endpoint id; renaming (spt endpoint rename) ripples everywhere, collision-checked.
• Bare-id resolution never guesses — sergey resolves locally first, then to the sole live instance; with several live nodes (or several subnets) it refuses and makes you qualify (sergey@desktop, home:sergey). Per-node recency is not comparable across nodes, so there’s no silent “most recently active” pick.
• Home subnet is immutable — assigned at creation. Moving an endpoint into another subnet is spt endpoint fork: a new identity seeded with a one-time copy of the mind, diverging immediately. Copy-then-diverge, never re-home — history stays honest.
• Visibility is per-(endpoint, subnet) — hidden means neither advertised nor routable there, and hidden gates sync too.
• Rest states are first-class — dormant (warm) and suspended (cold) instances stay addressable; deferred messages are held and released exactly once on wake. Remote spt endpoint suspend sergey@desktop / spt endpoint wake sergey@desktop work across paired nodes.

Commands

spt endpoint list · endpoint rename · endpoint fork · endpoint suspend · endpoint wake · endpoint description — CLI reference.

Cold-launching an endpoint on a node that has no instance (“instantiate-anywhere”) is deliberately deferred behind the consent framework; the gate exists and refuses today.