TauriTavern: SillyTavern als native Tauri-Anwendung mit Rust-Backend

Welches Problem TauriTavern löst und für wen

SillyTavern ist im Kern eine Node.js-Anwendung. Wer sie benutzen will, installiert Node.js, klont ein Repository, führt ein Installationsskript aus und startet danach einen Serverprozess, den man im Browser aufruft. Das funktioniert, verlangt aber von jedem Nutzer dieselben Schritte, die sonst nur Entwickler gehen. Auf Mobilgeräten ist dieser Weg praktisch versperrt.

TauriTavern setzt genau dort an. Das Projekt beschreibt sich selbst als Portierung von SillyTavern in eine native Anwendung, bei der das Backend von Node.js auf Rust umgestellt und die Oberfläche über Tauri v2 ausgeliefert wird. Der Nutzen liegt nicht in neuen Chat-Funktionen, sondern in der Verpackung: eine Installationsdatei pro Plattform, kein Node.js, kein Terminal. Adressiert sind Anwender, die ihre Charakterkarten, Chatverläufe, Presets und Weltbücher weiterverwenden wollen, ohne sich mit der Laufzeitumgebung zu befassen. Für Entwickler, die den Frontend-Code ohnehin schon angepasst haben, ist der Reiz ein anderer: der Upstream-Frontend-Stand bleibt erhalten, nur die Serverseite ist ausgetauscht.

Rust-Workspace mit Clean Architecture und ABI-Grenze

Das Repository beschreibt den Rust-Teil als Cargo-Workspace unter src-tauri/crates/, gegliedert nach Clean Architecture. Die Crates sind tt-domain für die Domänenmodelle, tt-ports für die Schnittstellen, tt-application für die Anwendungsfälle und tt-contracts für die crate-übergreifenden Verträge. Konkrete Implementierungen stecken in tt-adapter-*, benannt nach ihrer Zuständigkeit: Speicher, HTTP, Medien, Synchronisation, Erweiterungen, Tokenisierung. Der Host und die Kommandoebene liegen im Crate tauritavern.

Diese Trennung ist keine Selbstverständlichkeit für ein Projekt dieser Größe. Sie hat einen praktischen Preis: jede neue Fähigkeit muss durch Ports und Contracts definiert werden, bevor ein Adapter sie umsetzen darf. Wer schnell einen Endpunkt nachrüsten will, arbeitet gegen die Struktur. Der Nutzen zeigt sich erst, wenn mehrere Plattformen dieselbe Logik brauchen, und genau das ist hier der Fall.

Die Grenze zum Frontend ist explizit gezogen. Der Frontend-Teil besteht laut README aus dem Upstream-Frontend von SillyTavern plus einer modularen Tauri-Injektionsschicht unter src/tauri/main/. Die Kommunikation läuft über window.__TAURITAVERN__ als Plattform-ABI. Das erklärt, warum Erweiterungen, die ausschließlich im Browserkontext laufen, weiter funktionieren, während alles, was einen Node-Prozess erwartet, keinen Gegenpart mehr hat.

Installation über Paketmanager oder Skript

Für Windows nennt das README ein Scoop-Bucket. Nach dem Hinzufügen des Buckets installiert der Befehl scoop install Darkatse/TauriTavern die Anwendung. Unter macOS läuft die Installation über Homebrew Cask mit brew install --cask tauritavern. Auf Arch Linux existiert mit tauritavern-bin ein AUR-Paket, das laut README von einem externen Maintainer gepflegt wird, installierbar über einen AUR-Helfer wie yay. Für Debian, Ubuntu, Fedora, openSUSE und NixOS stellt das Projekt ein Skript bereit, das die Distribution erkennt und den passenden Weg wählt.

Für Nix-Nutzer gibt es einen Flake-Einstieg: nix profile add github:Darkatse/TauriTavern#tauritavern. Flatpak ist ebenfalls vorgesehen, mit einem eigenen Remote unter flatpak.tauritavern.com und der Anwendungs-ID com.tauritavern.client. Wer die Canary-Version will, hängt beim Linux-Skript den Schalter --channel canary an oder verwendet den Flake-Pfad github:Darkatse/TauriTavern/Canary#canary. iOS läuft über TestFlight und verlangt iOS 16 oder höher.

Zwei Einschränkungen stehen direkt im Text. Die portable Windows-Version setzt eine installierte WebView2-Laufzeit voraus. Und die TestFlight-Variante unterliegt den Regeln von Apple, was laut README mit Nutzungsbeschränkungen einhergeht. Beides sind keine Nebensätze, sondern Bedingungen, die vor der Wahl des Installationswegs geklärt sein sollten.

Entwicklungsumgebung und der Pilot-Modus

Wer aus dem Quellcode baut, braucht Rust stable mit Unterstützung für Edition 2024, Node.js in Version 20.19.x oder ab 22.12, pnpm und die Tauri CLI. Nach dem Klonen und pnpm install stehen Skripte bereit: pnpm run check prüft Frontend-Guardrails, Typen und Verträge und ruft zusätzlich den Rust-Dev-Check auf. pnpm run web:build erzeugt das Frontend-Bundle über Rspack, pnpm run tauri:dev startet den Desktop-Entwicklungsmodus, pnpm run tauri:build das Release-Paket. Für Android und iOS existieren android:dev und ios:dev.

Bemerkenswert ist die Integration von Tauri Pilot, einem Werkzeug, das einem KI-Agenten erlaubt, den WebView über Barrierefreiheits-Snapshots zu inspizieren und zu bedienen. Das ist ausdrücklich ein Entwicklungs-Feature: normale Entwicklungs- und Release-Befehle aktivieren es nicht. Wer es nutzen will, installiert einmalig tauri-pilot-cli per cargo, startet pnpm run tauri:dev:pilot und arbeitet dann in einem zweiten Terminal mit Befehlen wie tauri-pilot ping, tauri-pilot snapshot -i und tauri-pilot click @e3.

Das ist ein ehrlicher Umgang mit einem Werkzeug, das sonst leicht in Produktionsbuilds landet. Die Trennung über einen eigenen Startbefehl ist nachvollziehbar, auch wenn sie bedeutet, dass man sich den Befehl merken muss.

Erweiterungen: die Frontend-Grenze als Bruchstelle

Das README ist an dieser Stelle eindeutig: Erweiterungen für das Frontend werden unterstützt, Node-only-Backend-Plugins nicht. Ein natives Git ist eingebaut, sodass Installation, Aktualisierung und Branchwechsel im Interface stattfinden. Für Anwender, die ihre Erweiterungen aus einem Git-Repository beziehen, ändert sich damit wenig.

Für alle anderen ist es die wichtigste Einschränkung des Projekts. Wer ein Plugin nutzt, das serverseitig läuft, also eigene Node-Module lädt oder einen Prozess außerhalb des Browsers erwartet, wird es hier nicht betreiben können. Das ist keine Frage der Reife, sondern eine Folge der Architektur: der Node-Prozess existiert nicht mehr. Wer auf solche Plugins angewiesen ist, für den ist TauriTavern das falsche Werkzeug, unabhängig davon, wie gut die Portierung sonst gelungen ist.

Das Projekt benennt die Grenze selbst und nicht in einem Nebensatz. Das ist der richtige Ort dafür, denn die Prüfung, ob die eigene Erweiterungsliste betroffen ist, muss vor der Migration stattfinden und nicht danach.

Datenmigration und Synchronisation zwischen Geräten

Für den Umstieg nennt das README zwei Bausteine: ein Export-Skript auf der SillyTavern-Seite und einen Import innerhalb der Anwendung. Das Datenformat und die Verzeichnisstruktur bleiben laut Projekt kompatibel, sodass Charakterkarten, Chats, Presets, Weltbücher und Frontend-Erweiterungen übernommen werden können. Eine Garantie für jede Sonderkonfiguration ist das nicht, und das README formuliert es auch nicht so.

Für mehrere Geräte gibt es zwei Wege. Der eine ist eine verschlüsselte Paarung im lokalen Netzwerk, der andere ein Upload über einen entfernten Dienst namens TT-Sync v2. Damit ist die Synchronisation ausdrücklich nicht auf das lokale Netz beschränkt, was die Frage aufwirft, wohin die Daten im zweiten Fall gehen. Das README nennt den Dienst, beschreibt aber weder Betreiber noch Speicherort der Daten. Wer diesen Weg wählt, sollte das vorher klären. Die Aussage des Projekts, dass Daten lokal bleiben und ein Portabmodus existiert, gilt für den lokalen Betrieb, nicht automatisch für den Remote-Sync.

Der Agent-Rahmen mit Werkzeugaufrufen, Skills, Subagenten und einer Zeitleiste wird im README als fortlaufend entwickelt beschrieben. Das ist eine Selbstauskunft über den Reifegrad, keine Zusage über Stabilität.

Wartung, Releases und Lizenz

Das Projekt pflegt zwei Kanäle. Stabile Releases erscheinen in größeren Abständen, die jüngsten Einträge im Material sind v2.1.1, v2.2.0 und ein Canary-Build. Der Canary-Kanal wird laut README täglich aktualisiert und enthält neuere Funktionen und Korrekturen, ist aber möglicherweise weniger stabil. Das README empfiehlt Canary ausdrücklich als ersten Schritt, wenn in der stabilen Version ein Problem auftritt, um zu prüfen, ob es bereits behoben ist. Das ist ein sinnvoller Umgang mit einem schnellen Kanal, verlangt aber vom Anwender, zwischen zwei Installationswegen zu wechseln.

Lizenzseitig steht das Projekt unter AGPL-3.0. Das ist dieselbe Lizenzfamilie wie beim Upstream und bedeutet für die meisten privaten Anwender nichts Einschränkendes. Wer die Anwendung verändert und über ein Netzwerk zugänglich macht, sollte die Bedingungen der AGPL selbst prüfen. Eine Rechtsberatung ist das hier nicht und soll es nicht sein.

Wartungskosten entstehen für Anwender vor allem durch den Canary-Kanal und durch die Frontend-Synchronisation: das Projekt folgt dem Upstream-Frontend, derzeit auf Stand 1.18.0. Wer eigene Anpassungen am Frontend vorgenommen hat, muss diese bei jedem Nachziehen erneut prüfen.

Alternative: der Upstream selbst

Die naheliegende Alternative ist SillyTavern ohne TauriTavern. Der Unterschied liegt nicht im Funktionsumfang, sondern im Betriebsmodell. Beim Upstream läuft ein Node.js-Prozess, den man selbst startet und aktualisiert, mit vollem Zugriff auf das serverseitige Plugin-Ökosystem. Man bezahlt das mit dem Setup: Node.js installieren, Repository klonen, Abhängigkeiten einspielen, Prozess starten. Updates sind ein git pull plus erneutes Installieren der Abhängigkeiten.

TauriTavern tauscht diesen Aufwand gegen eine Installationsdatei und verliert dabei die serverseitigen Erweiterungen. Das ist ein klarer Tausch, kein Qualitätsunterschied. Wer den Node-Prozess ohnehin auf einem Server laufen lässt und von mehreren Geräten per Browser darauf zugreift, hat mit dem Upstream ein Modell, das TauriTavern nicht abbildet: dort ist die Anwendung das Gerät, nicht der Server.

Für Anwender auf Android oder iOS ist der Vergleich ohnehin entschieden, weil der Upstream diesen Weg praktisch nicht anbietet. Wer dagegen einen kleinen Heimserver betreibt und die Oberfläche nur im Browser braucht, findet in TauriTavern keinen Vorteil, der den Verlust der Backend-Plugins aufwiegt.

Redaktionelles Fazit

Wer SillyTavern bisher über Node.js und ein Terminal gestartet hat und diesen Schritt loswerden will, findet in TauriTavern den passenden Ersatz, vorausgesetzt, die genutzten Erweiterungen sind reine Frontend-Erweiterungen. Wer Node-only-Backend-Plugins braucht, bleibt beim Upstream. Vor dem Umstieg sollte man den eigenen Erweiterungsordner gegen die Liste der Node-abhängigen Plugins abgleichen, ein Backup der Daten anlegen und die Migration mit dem im README genannten Export-Skript plus In-App-Import einmal an einer Kopie durchspielen, statt direkt auf dem produktiven Datenbestand zu arbeiten.

Offizielle Quellen

1. Darkatse/TauriTavern on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases