Die Datenbank ersetzt das Dateisystem

Die meisten wissenschaftlichen Werkzeuge leben auf einem Dateisystem: ein Installationsverzeichnis, eine Umgebung voller Pakete, ein Ordner mit Skripten, deren genaue Versionen niemand mehr so recht weiß. Scellis entfernt diese Schicht. Es gibt kein Installationsverzeichnis — jeder Block, jede Op, jeder Kernel, jedes Modell, jeder Workflow und jeder Viewer ist eine Katalog-Entität, zur Laufzeit aus einer Datenbank geliefert und auf deiner Maschine gecacht. Dieser Artikel handelt von diesem Rückgrat und davon, warum ein einziger Lieferweg, Hash-Identität und die strikte Trennung von Wahrheit und Auslieferung die Arbeit haltbar und teilbar machen. Die Engine liest es; sonst niemand.

Eine Quelle, ein Weg#

Zur Laufzeit wird jede Katalog-Entität ausschließlich aus der Datenbank geholt — die lokale Datenbank in deinem Browser, die Cloud-Datenbank auf der Plattform. Die kompilierte App bündelt keinen Katalog: kein statisches JSON, keine eingebackene Blockliste, kein Datei-Fallback, das im App-Bundle still altert. Was du benutzen kannst, kam durch die Datenbank. Diese Strenge ist der Punkt: Zwei Quellen der Wahrheit driften immer, und „welche Kopie läuft hier eigentlich?“ ist eine Frage, die sich wissenschaftliche Arbeit nicht leisten kann. Ein einziger Weg bedeutet auch: Jede Entität — builtin oder von Nutzern verfasst — durchläuft auf dem Weg zu dir dieselbe Sichtbarkeits-, Vertrauens- und Sync-Maschinerie, weshalb frisch veröffentlichter Content per Hot-Plug in einer laufenden Session auftauchen kann — ohne App-Update.

Vier konzeptionelle Schichten#

Darunter ist das Rückgrat vier Schichten, jede mit einer anderen Mutabilitätsregel. Write-once-Objects sind große unveränderliche Bytes, abgelegt unter einem Content-Hash. Veränderliche References sind die menschenlesbaren Namen — „die aktuelle Version dieses Workflows“ —, die auf Objekte zeigen. Append-only-Events sind das Sync-Log: Nichts wird je umgeschrieben, nur angehängt. Und Derived-Views — Suchindizes, Kataloglisten — sind wiederherleitbare Projektionen, die man jederzeit wegwerfen und neu berechnen kann. Zu wissen, in welcher Schicht etwas lebt, sagt dir genau, was sich daran ändern kann und was nie.

Identität ist ein Hash#

Die Objektschicht ist inhaltsadressiert. Große unveränderliche Bytes — Gewichte, Datensätze, kompilierte Implementierungen — werden unter dem SHA-256-Hash ihres Inhalts abgelegt, und die Bytes unter einem Hash ändern sich nie. Ein gecachter Blob, der die Verifikation nicht besteht, gilt nicht als veraltet, sondern als Korruption — und wird neu geholt. Um diese Objekte herum sind veröffentlichte Entitäten pro Version unveränderlich: Eine semantische Änderung ist eine neue Version, und Versionen koexistieren.

json

{
  "block_id": "user/normalize",
  "version": 2,
  "spec_hash": "3f61c0a94b7e58d2…"     // the machine's name for the bytes
}

Zwei Namen für eine Entität#

Eine Katalogzeile benennt eine Entität zweimal: einmal für Menschen (Id plus Version) und einmal für Maschinen (der Hash ihres Inhalts). Der Name ist zum Finden da; der Hash ist das, worauf die Maschine vertraut. Zusammen ergibt das ein hartes Versprechen: Nichts, worauf du gebaut hast, kann unter dir umgeschrieben werden. Verbessert jemand einen Block, von dem du abhängst, erscheint das als neue Version — die, die du gepinnt hast, löst weiterhin exakt zu ihren Bytes auf. Es ist dieselbe Hash-Identität, die einen Lauf reproduzierbar macht.

Git ist die Wahrheit; die Datenbank ist die Auslieferung#

Für den Builtin-Katalog ist die Quelle der Wahrheit gar nicht die Datenbank — sondern ein Git-Repository voller Spezifikationen. Eine Auslieferungs-Pipeline liest diese Specs, kompiliert Implementierungen zu inhaltsadressierten Blobs und schreibt Zeilen und Objekte in die Datenbank, idempotent: Zweimal ausführen ergibt denselben Zustand. Für Builtin-Content ist die Datenbank reine Auslieferung — nie ein zweiter Autor. Diese Trennung macht Wiederherstellung langweilig — der Builtin-Katalog lässt sich jederzeit exakt aus Git rekonstituieren — und sie hält die Plattform ehrlich, was Gleichbehandlung angeht: ab der Datenbank läuft Builtin-Content über dieselbe Straße wie alles, was Nutzer veröffentlichen. Ein Katalog, ein Weg, keine privilegierte Seitentür.

Abb. 1 — Eine Straße, keine Seitentür. Die Wahrheit liegt in den Specs; das Veröffentlichen schreibt sie in die Datenbank; und die Datenbank — in der Cloud, auf deinem Gerät gespiegelt — liefert sie an die Engine. Builtin-Content und deiner nehmen dieselbe Straße.

Auf Abruf, nie im Ganzen#

Der Katalog ist darauf ausgelegt, über eine Million von Nutzern erstellte Entitäten hinaus zu wachsen — „alles herunterladen“ kann also nicht das Modell sein. Was auf deiner Maschine lebt, ist bewusst in zwei Stufen geteilt:

Garantiert lokal: die Engine plus alles, was du benutzt, installiert oder gepinnt hast — einschließlich der vollständigen transitiven Hülle jedes gespeicherten Workflows und Modells. Hash-verifiziert, dauerhaft und ohne Netz für immer ausführbar.
Discovery: der Rest des globalen Katalogs. Stöbern und Suchen — im Marketplace — brauchen das Netz; einzelne Entitäten werden auf Abruf geholt, genau wenn du sie brauchst.

Abb. 2 — Was du hast, läuft offline; was die Welt veröffentlicht hat, ist eine Suche entfernt. Etwas zu öffnen zieht es — samt allem, was es braucht — auf dein Gerät. Dein Fußabdruck folgt deiner Arbeit, nicht der Größe des Katalogs.

Benutzung befördert Content: Etwas öffnen, ausführen, forken oder installieren zieht es — samt allem, wovon es abhängt — in deine lokale Arbeitsmenge. Bevor ein Workflow speichert, ist seine vollständige Hülle garantiert lokal; deshalb läuft ein gespeicherter Workflow immer offline. Abruf auf Verlangen bleibt auf Stöber- und Autorenzeit beschränkt und sitzt nie auf dem Ausführungspfad. Dein lokaler Fußabdruck ist durch deine eigene Aktivität begrenzt, nicht durch die Größe des globalen Katalogs.

Offline-first-Writes, die im Hintergrund synchronisieren#

Reads kommen aus der lokalen Datenbank; Writes auch. Jede Mutation wird zuerst optimistisch auf deinen lokalen Store angewandt und im Hintergrund über eine Sync-Warteschlange zur Plattform synchronisiert — du wartest nie auf einen Roundtrip, um weiterzuarbeiten. Ändern zwei Leute dieselbe geteilte Entität, taucht der Konflikt explizit auf und bietet Server-übernehmen, Rebase oder Merge. Stilles Last-Write-Wins auf geteiltem Content gilt als Anti-Pattern, nicht als Bequemlichkeit: Die Plattform fragt lieber, als jemandes Edit still zu verwerfen.

Einmal Bootstrap, dann unbegrenzt offline#

Dein erster Besuch ist der eine Moment, in dem das Netz nötig ist: Ein Bootstrap von wenigen Sekunden befüllt die lokale Datenbank mit einer minimalen Arbeitsmenge — der Engine, deinem eigenen und installierten Content und der Hülle von allem, was du öffnest. Von da an läuft alles, was du hast, vollständig offline — unbegrenzt. Das ist kein abgespeckter Offline-Modus; es ist dieselbe Engine, die dieselbe lokale Datenbank liest, die sie immer liest. Nur die Entdeckung neuen globalen Contents braucht eine Verbindung, und die Offline-Suche sagt das klar — sie degradiert zu einem deutlich gekennzeichneten Index dessen, was du schon hast.

Hinweis

Scheitern ist laut, mit Absicht. Öffnest du offline einen Workflow, dessen Abhängigkeiten du nie geholt hast, schlägt das mit der exakten Liste des fehlenden Contents fehl — nie durch stilles Weglassen eines Knotens oder das Unterschieben einer „nächstbesten“ Version.

Du kollaborierst an einem Entwurf; du zitierst einen Commit#

Teilen fährt direkt auf der Hash-Identität. Ein geteilter Link benennt die inhaltsadressierten Artefakte eines Commits — das Programm, die Gewichte, den Datensatz —, also löst er überall, wo er geöffnet wird, zu identischen Bytes auf, bei Ankunft hash-verifiziert. Genau das heißt hier reproduzierbar per URL: Die Artefakte selbst sind überall identisch. Das letzte Stück ist Absicht — eine live geteilte Session wird nie gehasht. Während du mit anderen editierst, ist der Entwurf beweglich, und so zu tun, als wäre er es nicht, würde jeden Link vergiften, der auf ihn zeigt. Ist die Arbeit ein Zitat wert, machst du daraus einen Commit, und dieser Commit ist das unveränderliche Artefakt, zu dem ein Link auflöst. Du kollaborierst an einem Entwurf; du zitierst einen Commit — ein Zitat zeigt in Scellis nie auf ein bewegliches Ziel.