§ Platform / Collaboration
Multiplayer science, on your own GPUs.
Work on a workflow the way you work on a shared document — live cursors, co-editing, comments, runs your colleagues watch fill in — with one difference that changes the architecture: there is no cloud runtime underneath. The computing stays on each person's own device; the server only puts the edits in order. And none of it holds your work hostage: offline, or with the server down, everything you own still runs.
One canvas, many cursors, nothing uploaded
Open a session and your colleagues are simply there, on the same canvas of the Studio: named live cursors, selections, a participant list showing each person's role and a click to jump to whatever they are looking at. Presence is deliberately fleeting — cursors and viewports are broadcast, never stored, never part of the document. Even undo is per person: your Cmd+Z reverts your last edit, never a colleague's.
What crosses the wire is coordination, not data. Edits, presence, and the progress of a run go through the session; datasets, credentials, and the computing itself stay where local-first puts them — on each device. That is the inversion that makes working together in Scellis different: not a hosted workspace wrapped around a cloud runtime, but a thin coordination layer over machines the participants already own.
Watch the run happen, together
| What | Live to others | Afterwards |
|---|---|---|
| Document edits | checked, ordered, broadcast | durable — a local queue and committed versions |
| Presence — cursors, selection, viewport | yes, fleeting | discarded; never stored |
| A run's progress — curves, state | yes, streamed live | discarded; a committed run is what gets cited |
| Notes & comments | yes, live in the session | go with the document — without changing what a result is |
| Datasets · credentials · computing | never go through the session | stay on each participant's device |
What is missing is missing by construction: the session has no channel for raw data or secrets — the coordinator puts your workflow in order, it never runs it.
Start training and everyone in the session watches it happen: the loss curve filling in, the run's progress, the output updating — streamed live from the GPU of whoever started it to everyone else. Someone who joins late receives the whole curve from the first step, never a fragment. And who may do what follows the roles: editors can start, pause, or cancel a shared run; viewers and commenters watch with the controls disabled and the reason stated. Afterwards the run lands on your shelf, with its history intact.
The honesty is engineered in. Someone watching can always tell a finished run from a runner who vanished: when the heartbeat stops, the curve is marked as detached rather than pretending to make progress. And watching is all this is — sharing the progress of a run never moves the work itself. When you want peers to carry parts of the computation, that is distributed compute: a separate, explicit decision with its own levels of trust.
A draft that is always a valid program
A workflow is not prose; it is a typed, runnable graph — and that rules out the usual answer for shared documents. The standard machinery guarantees that everyone's simultaneous edits converge: you all end up with the same file. But converging on a program that contains a loop, or a wire whose types do not match, is still converging. Scellis checks instead. Every proposed edit is tested against the rules the graph must obey — the thing you edited still exists, no loop is formed, the wires still fit, the versions stay pinned — and only then does it get one canonical position in the order and go out to everyone.
You see your own edit land instantly and it is then re-applied on top of the canonical order, so the canvas feels immediate while the document never passes through a broken state. And that order is all the server owns: the identity of a version is computed exactly the same way by someone committing alone and offline — the live session puts edits in order, it never becomes the source of truth. A free-text field is the one place where character-by-character merging survives, because prose wants merging and programs want validity.
You collaborate on a draft; you cite a commit
A live session is for thinking together, and it is deliberately temporary: the churn of the draft, the cursors, the curve of a run in progress — none of it is ever part of what a version is. Commit is the moment a fluid draft becomes a fixed reference; identity begins at the commit, which is why a link in a paper can never dangle from a draft that is still moving.
The two kinds of share link carry that split. A session link lets someone into the live head: signed in, limited by role, able to edit — even a visitor without an account edits under a stable name you can attribute. A snapshot link hands over frozen bytes: no login, unchangeable, safe to put in a paper. Which door you open decides which promise you are making — and where sharing needs governance at team scale, roles and policies live with workspaces.
The discussion happens on the work itself
Notes attach where the thinking happens — to a block, a wire, a region, or the document itself — by what they point at, never by pixel coordinates. They go with the document and are versioned with it, yet stay outside what a version is, so a comment never changes what a result means. If what a note points at is later deleted, the note becomes a detached pin with guided re-attach: the writing is never lost. Threads carry mentions and a resolved flag, and in a live session a comment appears for everyone the moment it is written.
Anything you publish gets the public counterpart: a discussion in the shape of a bug tracker, open to any reader, no edit access required — someone who hits a problem reports it where the author and every future user can see it. That is part of what makes the marketplace two-way. The full choreography of sessions, roles, and links is walked through in the live-collaboration guide.
Solo never breaks — by design, not by luck
| Situation | The session | Your work |
|---|---|---|
| Alone, server down | there is none to lose | everything works, offline |
| A live session loses the coordinator | the ordering pauses, gracefully | you keep editing; the local queue holds it |
| Rejoining after editing offline | catch up, then re-apply | simple conflicts resolve themselves, with attribution |
| A real structural conflict | escalates, visibly | a guided three-way merge — never a silent overwrite |
| Your edit targets something deleted | the edit is set aside | orphaned edits collect in a tray with guided re-attach — nothing is lost |
Failure states are designed and tested behavior, not error screens — each row is part of what collaboration promises.
Live collaboration is a layer on top; take it away and everything still works. That is a rule of the architecture rather than a fallback: every collaborative feature must degrade to a fully working solo, offline experience, and an automatic check keeps it that way. The session coordinator is a cache, not the truth — durability lives in your device's own queue and in committed versions — and it sits, verifiably, off the paths that compute, author, and commit.
When a live session does lose its coordinator, the behavior is a graceful pause, not a pretence: everyone keeps editing with full local durability, the shared ordering stops, and clients that reconnect catch up. Simple conflicts resolve themselves, with attribution; a hard structural conflict is escalated to a guided three-way merge — never a silent last-write-wins, never lost work. This is also exactly what a paid plan buys: hosted collaboration capacity is a service — the computing never is.