Identity Switching

How OctoMY™ lets you keep multiple identities and robots on one device and switch between them at any moment — without losing data, without restarting the app.

Why this exists

One person may operate several robots, and one machine may host several people's identities — a workshop computer, a shared family hub, a developer's laptop with both a personal and a work identity. OctoMY™ treats identity as something you can change while the app is running, the same way you'd switch a window or a profile.

The mount stack

At any moment OctoMY™ has up to two identities active, layered on top of each other:

The Sentient's data lives in an encrypted hive named SID-<your-id>. When you select a Node, its hive (NID-<node-id>) is mounted on top of the Sentient hive. Switching either layer is what we mean by "identity switching."

See also: Sentient Identity for what a Sentient is, and Personality for what a Node Personality is.

When you switch

A Sentient switch is the heavier of the two: every subsystem that depended on the old Sentient (vault, contacts, keystore, mounted hive) is torn down and rebuilt against the new one. A Node switch reuses the active Sentient and only swaps the Node layer.

Where the switch happens in the UI

The Lanyard is the everyday surface. The selection activities are what the Lanyard pushes when you have more than one option, and they're also where you go when you want to create a new Sentient or Node.

What happens during a switch

Switching is one operation made of six steps. You see a spinner; behind it the app is making sure nothing gets corrupted by the change.

The order is deliberate. Save before Teardown is what prevents data loss — and after spec Phase 11b it's not just an attempt, it's a guarantee. The Save phase fires save() on every dirty subsystem (AddressBook, SentientVault, KeyStore, SentientRegistry, HiveRegistry) and runs the UI event loop for up to 5 seconds so the background AsyncStore workers can drain their queues before the volume tears down. Earlier versions used a fire-and-forget pattern that raced with the worker thread and could lose writes; the bounded-wait pump closes that gap.

Teardown reverses the Mount order so dependencies unwind correctly. If anything fails during Mount, the service automatically rolls back and restores the previous Sentient/Node — you never end up in a half-switched state.

Safety: open files and unsaved work

Before a switch begins, the app checks two things:

• Save pending — is any subsystem still flushing writes? If so, the switch waits a moment for them to finish.
• Open files — does any activity currently have a file open on the hive that's about to unmount? If so, the switch pauses and shows you the Open Files activity. You can:
  • Close each file (the owning activity gets a chance to save and shut down cleanly), or
  • Force continue (skip the cleanup — only use this if you accept that the open activity may lose its current state).

This is why a switch is safe even mid-edit: the app refuses to pull the rug out from under you without asking.

Switching vs creating

Switching only moves you between identities that already exist on this device. Creating a new identity is a separate flow:

A successful import lands the imported Sentient hive alongside your existing ones — the same selection activity now lists one more entry. From your point of view it's just another switch target.

What stays vs what resets

When you switch identities mid-session:

If you had a long-running OPAL task in flight, the switch will wait for it to finish (or fail if it can't), since tasks run in the context of the Sentient that started them.

Common questions

Can two Sentients be active at the same time? No — at most one Sentient is mounted at a time, and at most one Node on top of it. Multiple identities exist on the device; only one is active.

What if my Sentient has no Nodes yet? You can still operate as that Sentient — you just have no Node-specific data (no robot personality, no per-Node config). The Lanyard shows your Sentient with no Node selected. Create one from the Node Selection activity when you need it.

Is switching the same as logging out? Closer to "switching profiles." There's no central account, no log-out / log-in dance — switching simply unmounts one identity and mounts another, all locally.

Can I switch while a robot is connected? Yes; the Comms layer tears down cleanly during Teardown and reconnects under the new identity during Reconfigure. The peer on the other end sees you as a different identity afterwards (because you are).

Component reference