Architektur

Wie LastBrowser aufgebaut ist — Electron-Shell, Python-Backend, IPC-Schicht, Datenfluss und Moduldesign.

Überblick auf hoher Ebene

LastBrowser ist eine Zwei-Prozess-Anwendung, die eine Electron-Shell (Frontend-UI, native OS-Integration) mit einem Python-Backend (KI-Agentenlogik, WebUI-Server) kombiniert. Die beiden Prozesse kommunizieren über HTTP und einen lokalen Port.

┌─────────────────────────────────────────────────────────────────┐ │ LastBrowser Electron App │ │ ┌─────────────┐ ┌─────────────┐ ┌──────────────────────────┐ │ │ │ Main Proc │ │ Renderer(s) │ │ WebContentsViews (Tabs) │ │ │ │ (Node.js) │◄─┤ (Browser) │ │ (Isoliert pro Tab) │ │ │ │ Manager │ │ Sidebar │ │ │ │ │ │ IPC Router │ │ Workspace │ │ ┌──────┐ ┌──────┐ │ │ │ │ System Tray│ │ UI │ │ │Tab 1 │ │Tab 2 │ │ │ │ └──────┬──────┘ └─────────────┘ │ └──────┘ └──────┘ │ │ │ │ └──────────────────────────┘ │ │ │ HTTP (localhost:7889) │ │ ▼ │ │ ┌──────────────────────────────────────────────────────────────┤ │ │ Python Backend (server.py) │ │ │ ┌──────────┐ ┌──────────┐ ┌────────┐ ┌──────────────────┐ │ │ │ │Hermes │ │ API │ │ Static │ │ WebSocket │ │ │ │ │Agent Core│ │ Handler │ │ Dateien │ │ Sitzungen │ │ │ │ └──────────┘ └──────────┘ └────────┘ └──────────────────┘ │ │ └──────────────────────────────────────────────────────────────┘ └─────────────────────────────────────────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────────┐ │ Lokaler Speicher (SQLite via sql.js im Hauptprozess) │ │ Tabs, Arbeitsbereiche, Agenten, Einstellungen, Kanban, │ │ Sitzungen, Aufgaben │ └──────────────────────────────────────────────────────────────────┘

Electron-Hauptprozess

Der Hauptprozess (native/main.js) ist der Anwendungsorchestrator. Er verwaltet:

  • Fenstererstellung: Erstellt das BrowserWindow mit versteckter Titelleiste (benutzerdefiniert rahmenlos), Seitenleistenintegration und WebContentsView-Verwaltung.
  • Server-Lebenszyklus: Startet/stoppt den Python-WebUI-Backend-Server über server-launcher.js. Handhabt das saubere Herunterfahren beim Beenden der App.
  • System Tray: Verwaltet Tray-Symbol, Kontextmenü (Anzeigen, Server neu starten, Beenden) und das Verhalten beim Minimieren in die Taskleiste.
  • IPC-Router: Die gesamte Kommunikation zwischen Renderer und Hauptprozess erfolgt über einen zentralisierten IPC-Router (src/main/ipc/router.js).
  • Globale Tastenkürzel: Registriert Strg+K (Befehlspalette), Strg+Umschalt+M (Alle stummschalten), Strg+B (Seitenleiste umschalten).
  • WebViews: Verwaltet WebContentsView-Instanzen für Browser-Tabs mit Erstellungs-/Lösch-/Anhäng-Lebenszyklus.

Modulsystem

Der Hauptprozess organisiert die Funktionalität durch ein Manager-Muster. Jeder Manager ist ein eigenständiges Modul:

workspaceManagerSitzungsisolierung, CRUD, Neuordnung, Export/Import
tabManagerTab-Lebenszyklus, Aussetzen, Anheften, Schließverlauf (50)
agentManagerAgenten-CRUD, Rollensystem, Aufgabenverfolgung, Dashboard
kanbanManagerBoards, Spalten, Karten, WIP-Limits, Drag & Drop
splitViewManagerMehrfachpanel-Layouts, Größenänderung, Panel-Verwaltung
focusManagerPomodoro, Ablenkungsblockierung, Timer-Status
commandPaletteUnscharfe Suche über alle Datentypen, Schnellaktionen
appManagerAngepinnte Web-Apps, Mehrfachkonten, Kategorien
settingsManagerDauerhafte Einstellungen, Standardwerte, Laufzeit-Updates
privacyManagerWerbeblocker, Cookie-Steuerung, Cache-Leerung
resourceSaverTab-Aussetzung, Speicherstatistiken, Ausnahmeliste
sessionManagerSitzungs-CRUD, Agentenzuweisungen
taskManagerAufgabenverwaltung, Statusverfolgung
workerManagerHintergrund-Worker-Pool, Jobplanung
cronManagerGeplante Aufgaben, wiederkehrende Jobs
pipelineManagerWorkflow-Pipeline, mehrstufige Automatisierung
notificationManagerOS-Benachrichtigungen, Badge-Updates
accountManagerMehrfachkonten pro App, Sitzungswechsel
compactManagerKompaktes UI-Modus-Umschalten
appDefinitionManagerApp-Definitionsbibliothek (Slack, Gmail, usw.)
gitManagerGit-Integration, Commit, Diff, Branch-Verwaltung

Jeder Manager folgt einem einheitlichen Muster:

  • Speichert Daten über die Datenbank-Store-Abstraktion
  • Exportiert eine saubere API von Funktionen
  • Handhabt die auf den Arbeitsbereich bezogene Isolierung, wo zutreffend

IPC-Kommunikation

Die gesamte Kommunikation zwischen Renderer und Hauptprozess verwendet das contextBridge + ipcMain.handle / ipcRenderer.invoke-Muster von Electron. Das IPC-Kanalsystem ist in src/shared/constants.js mit ~150+ Kanälen definiert, die nach Domänen organisiert sind:

// IPC-Kanalorganisation (aus src/shared/constants.js)
IPC.WORKSPACE_LIST, .WORKSPACE_CREATE, .WORKSPACE_DELETE...
IPC.TAB_CREATE, .TAB_CLOSE, .TAB_SUSPEND, .TAB_RESTORE...
IPC.AGENT_LIST, .AGENT_INVOKE, .AGENT_RESPONSE...
IPC.APP_LIST, .APP_CREATE, .APP_MUTE, .APP_SLEEP...
IPC.SPLIT_VIEW_CREATE, .SPLIT_VIEW_RESIZE...
IPC.FOCUS_START, .FOCUS_STOP, .FOCUS_STATUS...
IPC.KANBAN_CREATE, .KANBAN_MOVE, .KANBAN_WIP...
IPC.TAB_EXEC_JS, .TAB_SCREENSHOT, .TAB_GET_CONTENT

Sicherheit: contextIsolation: true, nodeIntegration: false. Alle Node.js-APIs werden über preload.js mit expliziter Whitelist freigegeben.

Datenspeicherung

LastBrowser verwendet sql.js (SQLite kompiliert zu WebAssembly via Emscripten) für alle persistenten Daten:

  • Sammlungen: Tabs, Arbeitsbereiche, Agenten, Einstellungen, Kanban-Boards/Spalten/Karten, Fokus-Sitzungen, geschlossene Tabs, App-Konten, Worker-Jobs, Aufgaben, Ablenkungsregeln.
  • Datenbank-Speicherort: Gespeichert im App-Datenverzeichnis des Benutzers (Electrons app.getPath('userData')).
  • Schema: Sammlungsbasierter Dokumentenspeicher auf Basis von SQLite. Jede "Sammlung" ist entweder eine Tabelle oder eine JSON-Dokumentspalte.
  • Migrationen: Verwaltet von src/main/database/migrations.js für die Schemaentwicklung zwischen Versionen.

Python-Backend

Das Python-Backend (server.py) stellt die Hermes-WebUI bereit – die KI-Agenten-Schnittstelle, die LastBrowser umschließt:

  • Framework: Python-HTTP-Server (FastAPI oder ähnlich), der die WebUI auf localhost:7889 bereitstellt.
  • Server-Start: server-launcher.js startet den Python-Prozess, wartet auf seine Bereitschaft und verwaltet seinen Lebenszyklus. Im Entwicklungsmodus befindet er sich im Projektstamm; in der Produktion wird er als extraResources/webui/ gebündelt.
  • HTTP-API: REST-Endpunkte für Agenteninteraktion, Sitzungsverwaltung, Skill-Operationen usw.
  • Statische Dateien: Das WebUI-Frontend wird aus dem static/-Verzeichnis bereitgestellt.

Build & Paketierung

LastBrowser verwendet electron-builder v25 für die Paketierung und Verteilung:

native/
├── package.json          # Abhängigkeiten + Build-Skripte
├── electron-builder.config.js  # electron-builder-Konfiguration
├── main.js               # App-Einstiegspunkt
├── preload.js            # Sicherheitsbrücke
├── server-launcher.js    # Python-Backend-Lebenszyklus
├── assets/               # Symbole (PNG, ICO, SVG)
└── src/                  # Quellmodule

Windows-Build:

  • Ziel: NSIS-Installer (x64) oder portable .exe
  • Python-Backend gebündelt als extraResources/webui/
  • Auto-Updater konfiguriert für GitHub-Releases
  • GitHub Actions CI baut auf windows-latest

Sicherheitsmodell

LastBrowser befolgt durchgängig die bewährten Sicherheitspraktiken von Electron.
  • Kontextisolierung: Aktiviert. Der Renderer hat keinen direkten Zugriff auf Node.js- oder Electron-APIs.
  • Preload-Brücke: Nur explizit auf die Whitelist gesetzte IPC-Kanäle werden über contextBridge.exposeInMainWorld freigegeben.
  • Sandbox: Deaktiviert (erforderlich für die WebContentsView-Funktionalität), aber durch Kontextisolierung abgemildert.
  • Sitzungspartitionen: Jeder Arbeitsbereich und jede App erhält eine eigene persist:-Sitzungspartition, um Cross-Origin-Datenlecks zu verhindern.
  • Navigationskontrolle: Externe Links werden im Systembrowser geöffnet, niemals im App-Fenster.
  • Werbeblocker: Optionaler integrierter Werbeblocker mit Filterlisten.
  • Cache: Vom Benutzer initiierte Cache-Leerung pro App oder global. Cookie-Steuerung (Drittanbieter blockieren).

Weiter: FAQ →