§ Plattform / Local-first
Deine Daten bleiben auf deinem Gerät.
Lokal zu arbeiten ist der Normalfall, kein Modus: Daten liegen im Browser-Speicher deines eigenen Rechners, gerechnet wird auf deiner eigenen GPU, und nichts geht ins Netz, ohne dass ein Block darum gebeten und du es freigegeben hast. Der Server macht Teilen und gemeinsames Arbeiten besser; zum Rechnen wird er nie gebraucht.
Nichts überquert die Grenze ohne dein Ja
Jeder Workflow läuft innerhalb einer Grenze, auf die du zeigen kannst: das Gerät vor dir. Datasets gelangen über Konnektoren in den Speicher deines Browsers, Transformationen und Training laufen auf deiner eigenen GPU, und Ergebnisse landen in einer Datenbank, die auf deiner Maschine liegt — ein vollständiger wissenschaftlicher Kreislauf ohne Server darin.
Die Engine ist standardmäßig pur: Ein Block, der ins Netz will, muss das sagen, und du wirst genau in dem Moment gefragt, in dem es zählt. Es gibt keine Telemetrie im Hintergrund, keinen leisen Upload, kein Kleingedrucktes. Das Gerät verlässt exakt das, was du freigegeben hast — und sonst nichts.
Ein erster Besuch, dann so lange du willst
| Aktivität | Netz | Anmerkung |
|---|---|---|
| Der erste Besuch | einmal, Sekunden | Füllt deine lokale Datenbank mit der Engine und den Inhalten, die du nutzt. |
| Rechnen & Training | nie | WebGPU auf deinem Gerät — keine Cloud-GPU, keine Warteschlange, kein Zähler. |
| Alles, was du schon hast | nie | Es wird aus der Datenbank auf deiner eigenen Maschine gelesen, so lange du willst. |
| Neue veröffentlichte Inhalte finden | online | Aus dem Katalog geholt, wenn du danach fragst — nie ein Komplett-Download. |
| Teilen & gemeinsames Arbeiten | online, optional | Der Server koordiniert Sessions; er führt deine Arbeit nie aus. |
Offline ist der getestete Normalfall, kein degradierter Notbehelf — eine fehlende Verbindung ist hier ein gewöhnlicher Betriebszustand.
Der erste Besuch lädt ein minimales Arbeitspaket — die Engine plus die Inhalte, die du wirklich nutzt — und füllt eine vollständige Datenbank in deinem Browser, in Sekunden über eine gewöhnliche Verbindung. Ab dann läuft alles, was du hast, komplett offline, so lange du willst: zeichnen, ausführen, trainieren, inspizieren, versionieren.
Nur das Finden neuer veröffentlichter Inhalte braucht das Netz. Der Abgleich nimmt jede Gelegenheit, die er kriegt — lokale Änderungen warten lokal und gleichen sich ab, sobald wieder eine Verbindung da ist. Ein Zug, ein Flugzeug oder ein abgeschottetes Labornetz ist damit ein normaler Arbeitsort, kein Fehlerzustand.
Standardmäßig pur, sonst ausdrücklich
Alles, was über das Gerät hinausgreift — eine URL laden, einen Bucket lesen, eine Nachricht senden — ist ein Effekt: Was ihn nutzt, muss ihn deklarieren, und die Deklaration wird durch alles hinaufgetragen, was es aufruft. Vor einem Lauf siehst du die vollständige Menge der Effekte, die der ganze Workflow erzeugen kann — ein Block, der behauptet, pur zu sein, kann also keinen Netzaufruf über eine Abhängigkeit einschmuggeln.
Freigegeben ist genau das, worum gebeten wurde — und du kannst es später zurücknehmen. Workspace-Richtlinien können für ein ganzes Team strengere Regeln festschreiben — nützlich, wenn die Daten im Raum nicht dir gehören. Dieselbe Disziplin gilt für alles, was Nutzende selbst schreiben, denn was du schreibst und was wir ausliefern, laufen durch einen identischen Pfad.
Schlüssel, die deine Hände nie verlassen
Konnektor-Zugangsdaten — Tokens, API-Keys, Bucket-Secrets — werden mit einem gerätegebundenen Schlüssel verschlüsselt und nur dort gespeichert. Sie werden nie synchronisiert, nie in die Aufzeichnung eines Laufs geschrieben, sind für uns nie sichtbar. Scellis kann keinen Token verlieren, den es nie sieht.
Selbst die Art, wie ein Dienst angebunden wird, ist gewöhnlicher Content: Die Login-Anbieter sind geschriebene Spezifikationen, deren Berechtigungen vor dem Katalog auf Sparsamkeit geprüft werden — wie Daten hinein- und hinausgelangen, ist ein lesbarer Teil des Substrats, keine Blackbox. Die Details stehen bei Daten und Konnektoren.
Privatsphäre zum Nachprüfen, nicht nur zum Glauben
Scellis entsteht in Deutschland, unter europäischem Datenschutzrecht, und die stärkste Eigenschaft, die es hat, ist strukturell: Was das Gerät nie verlässt, braucht keinen Auftragsverarbeitungsvertrag. Auskunft, Export und Löschung sind Produktfunktionen statt Support-Tickets — persönliche Artefakte sind mit einem Schlüssel verschlüsselt, der zur Person gehört; Löschen löscht also wirklich.
Wir sagen präzise, was wir sehen können und was nicht: Die gehosteten Teile — Konten, Teilen, Session-Relays — laufen bei benannten Infrastruktur-Anbietern, und deine Rohdaten fließen nicht hindurch. Wo eine Garantie eine Grenze hat — bei gebündeltem Rechnen verlassen Modell-Updates das Gerät bauartbedingt —, veröffentlichen wir die Grenze in den ehrlichen Grenzen, statt sie aufzurunden. Die vollständige Haltung steht unter Sicherheit.
Wo sich Local-first auszahlt
Auf verwalteten Flotten und abgeschotteten Instituts-Rechnern ist ein Browser-Tab oft das Einzige, was du starten darfst. Scellis macht aus dieser Einschränkung die Art der Auslieferung: keine Installation, keine Admin-Rechte, keine Daten, die das Haus verlassen — während Training trotzdem auf der GPU der Maschine läuft.
Es verändert, woran du überhaupt arbeiten kannst: Daten, die du nicht hochladen darfst, bleiben analysierbar. Wenn mehrere Menschen einen Workflow bearbeiten, teilt die Live-Zusammenarbeit die Änderungen und wer gerade wo ist — nicht deine Datasets. Und wenn Geräte ihre Rechenleistung bündeln, steht genau da, was ein Pool austauscht, Kohorte für Kohorte. Weil die Arbeit auf Hardware läuft, die dir schon gehört, wird sie nie gezählt — in jedem Tarif, auch ganz ohne.