Live-Zusammenarbeit

Scellis ist local-first: Dein Gerät ist die Quelle der Wahrheit, und nichts am Komponieren oder Ausführen eines Workflows braucht einen Server. Kollaboration kommt oben auf diesen Kern, nicht an seine Stelle — Multiplayer im Figma-Stil auf dem Workflow-Canvas, Live-Runs, denen ein ganzes Team zusieht, Kommentar-Threads direkt am Graphen. Zwei Eigenschaften gelten durchgehend, und um die geht es hier eigentlich. Kollaboration ist strikt additiv: Allein zu arbeiten wird nie langsamer oder fragiler. Und was du teilst, ist ein Entwurf — was du zitierst, ist ein Commit.

Präsenz — bis hinunter in die Layer#

Öffnest du eine geteilte Session, siehst du die anderen bei der Arbeit: Live-Cursor, die über den Canvas wandern, die Selektionen, die sie halten, den Viewport, durch den jede Person gerade schaut. Präsenz ist bewusst flüchtig — Cursor und Selektionen werden nie persistiert und nie gehasht, sodass Zuschauen keine Spur im Artefakt hinterlässt. Und sie endet nicht am obersten Graphen.

Ein Modell ist selbst ein Graph in einem Knoten, deshalb zeigt ein Modell-Knoten auf dem Canvas ein aggregiertes Badge — „3 bearbeiten darin“ — und der Schritt hinein in Model View löst dieses Badge in Cursor pro Layer auf. Du siehst nicht nur, wer im Dokument ist, sondern wer in welchem Modell an welchem Layer arbeitet. Brush- und Hover-Hervorhebungen sind pro Peer und momentan gedacht; sie gehören zur Session, nicht zum gespeicherten Graphen.

Jede Änderung wird validiert, dann sequenziert#

Ein Workflow ist keine Zeichnung — er ist ein typisierter, ausführbarer Graph, und ein ausführbarer Graph braucht Gültigkeit, nicht bloß Konvergenz. Deshalb setzt Scellis auf ein Server-Authoritative-with-Rebase-Modell statt auf ein Dokument-CRDT: Ein CRDT garantiert, dass am Ende alle dieselben Bytes haben — nicht, dass diese Bytes ein lauffähiges Programm ergeben. Also wird jede Änderung in einer Live-Session serverseitig validiert, bevor sie sequenziert und verteilt wird: Das Ziel existiert noch, die neue Verbindung erzeugt keinen Zyklus, die Typen passen. Erst dann tritt die Änderung in die geteilte Reihenfolge ein.

Dein eigener Client wartet nie auf diesen Umlauf. Er wendet deine Änderung optimistisch an und rebast sie, falls die sequenzierte Historie widerspricht — der Canvas bleibt unter deinen Händen unmittelbar, während der Server der einzige Schiedsrichter darüber bleibt, was das geteilte Dokument tatsächlich ist.

Undo respektiert Urheberschaft#

In einer Live-Session nimmt Cmd+Z deine letzte Änderung zurück — nie die eines Peers. Undo ist pro Prinzipal: Kein Undo greift über den Tisch, und eine Kollegin kann Arbeit, die du nicht gemacht hast, nie still zurückrollen.

Geteilte Runs: der Run selbst ist Multiplayer#

Gemeinsam editieren ist die halbe Geschichte. Startet jemand in der Session einen Run, wird der Run live übertragen: sein Lebenszyklus, die Loss- und Accuracy-Kurven, die sich Punkt für Punkt füllen, Output-Deltas, sobald sie landen. Alle in der Session sehen der Berechnung beim Entstehen zu — „Google Docs, für die GPU“ — nicht bloß den Änderungen drumherum. Dieselbe Live-Telemetrie treibt einen Trainingslauf genauso an wie einen verteilten Sweep.

Die Run-Kontrolle folgt der Grant-Rolle. Nur Editoren dürfen einen geteilten Run starten, pausieren oder abbrechen; Viewer und Commenter schauen zu, mit deaktivierten Controls und benanntem Grund. Und eine eingefrorene Kurve liest sich nie als live: Der Runner sendet einen Heartbeat, und reißt er ab, wird der Stream entsprechend markiert — ein stehengebliebenes Chart darf keinen Fortschritt vortäuschen.

Wer später dazukommt, bekommt das ganze Bild. Ein Session-Link liefert einem frischen Teilnehmer einen Snapshot des Dokuments, ein Replay der Änderungen und die aktuelle Präsenz — und läuft gerade ein Run, den Metrik-Stream ab t = 0. Wer neu dazustößt, sieht die gesamte Loss-Kurve, nicht nur das Stück nach dem eigenen Beitritt. Diesen Run über Geräte zu poolen ist ein eigener Schritt — Thema von verteiltem Rechnen.

Notes, Kommentare und Mentions#

Diskussion wohnt dort, wo die Arbeit wohnt. Eine Note ist Markdown, logisch verankert an einem Knoten, einer Kante, einer Region des Canvas oder am Dokument als Ganzem — nie an Pixelkoordinaten. Kommentar-Threads tragen Antworten und ein Resolved-Flag und erscheinen für alle in der Session live, während sie geschrieben werden. Mit @Mention erreichst du jede Person, die einen Grant auf dem Dokument hält; eine Mention erzeugt eine Benachrichtigung, die sie erreicht — ob online oder nicht.

Anker sind widerstandsfähig statt spröde. Wird der Knoten gelöscht, auf den eine Note zeigt, verschwindet die Note nicht mit ihm — sie wird zu einem losgelösten Pin mit geführtem Wieder-Anheften. Prosa geht durch einen Edit nie verloren. Und Note-Inhalte bleiben außerhalb des Content-Hashes: Eine Annotation ändert die Identität eines Workflows nicht — ein viel diskutiertes Artefakt hasht genauso wie ein undiskutiertes, und seine Reproduzierbarkeit bleibt vom Gespräch drumherum unberührt.

Grants: konkrete Personen, explizite Rollen#

Geteilt wird über einen Grant: Du lädst eine bestimmte Person ein — als Viewer, Commenter oder Editor, optional mit Ablaufdatum. Ein Grant ist die personenbezogene Berechtigung, die eine Live-Session regelt; wie er in den größeren Sharing-Graphen passt — Sichtbarkeitsgitter, Share-Links, Workspaces — ist Thema von Workspaces und Repositories.

Ein Widerruf wirkt sofort nach vorn — ab diesem Moment fließen die nächste Änderung, der nächste Sync, das nächste Run-Ereignis nicht mehr zum widerrufenen Gerät. Die ehrliche Grenze steht direkt daneben: Bytes, die ein Gerät bereits synchronisiert hat, lassen sich nicht zurückrufen. Widerruf kontrolliert die Zukunft, nicht die Vergangenheit — und Scellis tut nicht so, als wäre es anders.

Additiv per Konstruktion: nie blockiert, nichts verloren#

Die Regel, die das alles ehrlich hält: Kollaboration ist strikt additiv — ein Dekorator über dem offline-first-Kern, nie eine Abhängigkeit von ihm. Für dich allein ist ein Server-Ausfall ein echtes No-op — du komponierst, führst aus und committest uneingeschränkt, weil keiner dieser Pfade je von einem Koordinator abhing. In einer Session mit mehreren Beteiligten setzt der Verlust des Koordinators die Reihenfolgebildung sanft aus: Alle behalten volle lokale Persistenz, editieren weiter und rebasen beim Reconnect. Nie ein Spinner zwischen dir und deinem eigenen Dokument; nie verlorene Arbeit.

Offline gilt dieselbe Disziplin. Offline gemachte Änderungen landen in einer lokalen Queue und werden beim Reconnect zusammengeführt. Einfache Konflikte lösen sich automatisch, mit Attribution — es bleibt sichtbar, wessen Änderung wo gelandet ist. Harte strukturelle Divergenz eskaliert in einen expliziten Drei-Wege-Merge — nie ein stilles Last-write-wins. Und eine Änderung, deren Ziel in der Zwischenzeit verschwunden ist, landet in einer Ablage für verwaiste Änderungen, mit geführtem Neu-Verdrahten, statt still verworfen zu werden.

Entwurf versus Commit#

Das ganze Modell ruht auf einer klaren Linie. Eine Live-Session ist ein Entwurf: fließend, Multiplayer, flüchtig — und nie gehasht. Ein Commit ist eine eingefrorene, inhaltsadressierte Version — und nur ein Commit ist zitierbar, per URL reproduzierbar und sicher, um darauf aufzubauen. Willst du eine Kollegin, ein Paper oder dein künftiges Ich auf ein exaktes Ergebnis zeigen, committest du und teilst den Snapshot, nicht die Session.