Cross-Machine

Stallari runs natively on the user’s own Apple devices. A user with one Mac runs one instance. A user with two Macs, an iPhone, and an Apple TV runs the same instance reaching across all of them. There is no web app the user logs into from different browsers, and no vendor cloud holding the platform together. The substrate that ties the devices into one platform is the Stallari fabric.

The Stallari Fabric

The fabric is the across-device substrate that lets one user’s instance live on multiple machines as one thing. Each device runs the platform locally. The fabric is what makes them feel like one platform rather than several installations of the same app.

The user’s vault is the same vault on every device, replicated through whichever sync the user picks (Obsidian Sync, iCloud, Syncthing).
A scheduled job runs on one device at a time, not duplicated.
A capability installed on one Mac (a pack, an on-device model, a local-corpus index) is invokable from another Mac under the same identity.
A presence signal — which devices are awake, which are on power — surfaces so routing decisions can prefer the right device.

The fabric is peer-to-peer. Bearer tokens authenticate one of the user’s devices to another. No central coordinator. No platform-operated relay.

One Daemon, Multiple Instances

Multi-instance is optional. Most users — including most side-hustles — never need it. A single instance is the default and a single instance handles personal vault, side-hustle work, and most “two hats on one Mac” cases without complication.

Multi-instance exists for users who require hard partitioning of data and audit between contexts: a regulated profession that cannot mix client work with personal use, a household where multiple adults each need their own vault on a shared Mac, or a contractor running an instance per client engagement.

The contractor case makes the partitioning concrete. A freelance bookkeeper, lawyer, fractional CTO, or consulting solo can run one instance per client: each holds the client’s vault, the client-specific packs and credentials, and an audit trail bounded to that engagement. The contractor’s own instance — personal mail, household admin, side projects — stays separate from all of them. A skill running for Client A cannot read Client B’s vault, see Client B’s API keys, or contaminate Client B’s audit log. Provider spend is attributable per instance, so the contractor can pass costs through cleanly. When an engagement ends, eviction localises the cleanup to one instance — there is no scan across the contractor’s whole platform looking for client residue. When the requirement is partitioning rather than convenience, the platform supports it.

When two instances coexist on one Mac, each has its own vault, its own packs, its own scope tags, its own audit trail. They share the underlying daemon: one process, multi-tenant, scheduling each instance’s work against its own quotas. The daemon is multi-tenant by construction. It does not collapse one instance’s state into another’s. A skill running in one instance cannot see the other instance’s vault. An identity bearer presented to the daemon names which instance the caller is operating against; the daemon refuses to cross-route.

The vocabulary matters: an instance is the per-user surface (one vault, one identity, one set of packs). A Mac is the hardware. The fabric is the reach an instance has across the user’s own devices. One instance can span devices; one Mac can host many instances; one fabric is bounded by one identity’s reach.

Identity And Personal Trust

Identity in Stallari is per-person. The user holds a personal identity bearer that proves “this caller is the user, on this device, in this instance”. Role attestations layer on top: “this user, on this device, with this scope”. The substrate evaluates the bearer plus the attestation at every cross-device call.

The bearer is rotatable. Revoking a device’s bearer takes that device out of the fabric without touching the rest. The trust posture is symmetric: Mac A and Mac B trust each other because both bear credentials the user authorised. Neither trusts a third device by default. A new device joins the fabric only after the user explicitly enrolls it from an existing device. There is no auto-pairing.

What Is Shipped Today

Surface	Status
Single-Mac multi-instance	Shipped. Two or more instances on one Mac coexist with isolated state. Optional — most users run a single instance.
Multi-tenant daemon	Shipped. The underlying daemon process hosts multiple instances when the user opts into them; identity bearer routes cross-instance calls.
Personal identity across the fabric	Shipped. The user’s bearer + role attestations propagate across their devices.
System lifecycle choreography	Shipped. Boot, sleep, restart, shutdown are observable; Stallari cooperates with macOS rather than racing against it.
Device eviction	Shipped. The user can revoke a device’s bearer and remove it from the fabric without touching other devices. Eviction is a trust action, not a data wipe — see below.
Local discovery	Shipped. Per-instance Bonjour-style discovery; the user’s devices find each other on the same network without a vendor lookup.

The user with one Mac sees none of this — it is invisible plumbing. The user with two or more devices gets cross-machine reach for free once both run the platform under the same identity.

What Is Still Building

The aspirational shape — agents you can see, an always-on Apple TV in the household, a spare Mac that just hosts — is under way. The substrate is being built; the user-facing surfaces will follow.

Visual agent presence — agents get a persistent visual presence across your devices. Encrypted at rest, served from your hardware, not a vendor cloud. Substrate in design.
Apple TV companion — a tvOS app that keeps Stallari present on the household’s always-on screen. Notifications, status, glanceable reach while the Macs sleep. Phase 0 substrate in place; app shell next.
Always-on host profile — a deployment shape for a Mac mini (or equivalent) running an instance with no interactive user logged in. For households or small teams that want one device permanently online. Design phase.

The honest framing: cross-machine reach is the most aspirational of Stallari’s differentiation axes at v1. The fabric works today for the multi-Mac case under one identity. The “Stallari spans every Apple device you own” pitch lands cleanly once visual agent presence and the Apple TV companion ship.

Apple-Platform-Native

Cross-device coordination on Apple platforms means cooperating with the OS, not papering over it. The fabric uses:

TCC for granular consent (Full Disk Access for mail indexing, App Management for binary updates, Reminders / Calendar / Contacts grants per integration).
Keychain for credential storage; encryption keys never leave the keychain.
App Groups for inter-process state sharing between the app, the daemon, and helper binaries.
Sparkle for in-app update delivery, with EdDSA-signed appcasts on first-party infrastructure.
Foundation Models for on-device LLM inference where the OS provides one.
System lifecycle hooks for sleep / wake / restart / shutdown coordination.

This is what lets Stallari be a citizen of the user’s Mac rather than a guest.

Resetting A Device

The cross-machine posture comes with a reset path. A user who wants to evict a device — sold Mac, lost iPhone, retired instance — can wipe its presence from the fabric. The system revokes the device’s bearer, rotates affected secrets, and removes the device from the active manifest. Other devices stop trusting it. The reset is an explicit user action with a visible audit record. There is no quiet device pruning, no platform-driven eviction.

Eviction is a trust action, not a data wipe. The evicted device stops being part of the fabric — it can no longer answer for the user, present a valid bearer, or join cross-device coordination. But Stallari’s local data on the evicted device — vault files synced through Obsidian Sync / iCloud / Syncthing, the encrypted SQLite stores under the user’s profile, cached models, accumulated traces — remains on disk under the user’s control until the user removes it directly. If the goal is to recover a lost or sold Mac’s worth of data, the user revokes the bearer here and wipes the disk through the OS. If the goal is to retire a Mac that stays in the household, the user revokes the bearer here and the data sits inert until the user reuses or removes the machine. The two actions are decoupled by design: the fabric trust decision is reversible (re-enroll the device); a disk wipe is not.

Federation Is A Different Thing

Cross-machine is one user’s fabric reaching across that user’s own devices. Federation is something else: joining one user’s fabric to another user’s fabric. A household sharing a family layer, an organisation onboarding members, a guild forming around a shared interest — each is a federation between fabrics, not a stretching of one fabric.

Federation has its own identity story (who-is-who across fabrics), its own trust posture (what each party may see), and its own deployment shapes. It will get its own concept page when the surfaces ship. For now, the practical line is this: anything within the user’s own devices is cross-machine; anything that crosses to another user’s devices is federation.

Agency model — how the audit trail spans device boundaries.
Local vs cloud — how provider routing is fabric-aware.
Legibility and continuity — how cross-machine activity surfaces in first-party inspection panes.