OmniBox: Wissensablage mit Agent, WeChat-Bot und Submodul-Architektur

Vier Repositories, ein Produkt

Das Repository import-ai/omnibox enthält nicht die Anwendung selbst, sondern eine Sammlung von Submodulen. Die README verlinkt vier separate Release-Kanäle: omnibox-web, omnibox-backend, omnibox-wizard und omnibox-browser-extension. Jedes dieser Teile hat eigene Versionsnummern und eigene Release-Zyklen. Das Klon-Kommando verlangt deshalb ausdrücklich git clone --recurse-submodules. Wer das Flag vergisst, bekommt ein Verzeichnis mit leeren Unterordnern und wird beim Start Fehler sehen, die nicht nach fehlenden Submodulen aussehen. Die eigentliche Python-Logik liegt im Backend-Submodul, nicht im Wurzelverzeichnis. Diese Struktur ist eine bewusste Entscheidung: Frontend, Backend, Installationsassistent und Browser-Erweiterung lassen sich unabhängig versionieren. Der Preis ist, dass ein einzelner Commit im Hauptrepository selten den vollständigen Stand beschreibt. Die Release-Historie zeigt v0.1.48 vom 8. September 2026, davor v0.1.48-beta.1 und v0.1.47. Der Abstand zwischen den Tags liegt bei Tagen, nicht bei Monaten. Wer auf einem festen Stand aufsetzen will, sollte nicht den Hauptbranch verfolgen, sondern einen Tag auswählen und die Submodul-Commits mit git submodule status festhalten.

Was gesammelt wird und wer davon profitiert

Die README beschreibt den Ablauf in einem Satz: collect, then ask. Konkret bedeutet das, dass Inhalte zuerst in die Ablage wandern und erst danach abgefragt werden. Die Quellen sind vielfältig. Eine Browser-Erweiterung speichert den Hauptinhalt einer Webseite. Dateien in Formaten wie PDF, Word, PPT und MP3 werden laut README vollständig geparst und indexiert. Auf iOS gibt es Flash für kurze Notizen und Sprachaufnahmen sowie eine Teilen-Funktion. Ein WeChat-Bot nimmt Dateien, Webseiten, Videos, Sprachnachrichten, Text und Chatverläufe entgegen. Dazu kommt ein Markdown-Editor mit Formeln, Mindmaps, Flussdiagrammen, Sequenzdiagrammen, Gantt-Diagrammen und Notensatz. Die Zielgruppe ist damit klar umrissen: Menschen, die ohnehin viel lesen und Notizen machen und diese Bestände nicht in einem Chatfenster verlieren wollen. Das ist kein Werkzeug für einmalige Recherche. Der Nutzen entsteht erst, wenn über Wochen ein Bestand wächst, den man später durchsuchen kann. Wer nur gelegentlich eine PDF zusammenfassen will, trägt hier mehr Installationsaufwand als Nutzen.

Ende-zu-Ende-Parsing als Kernmechanismus

Der einzige Mechanismus, den die README explizit benennt, ist das end-to-end Parsing und Indexing für Dateien. Das heißt: Der Parser läuft im eigenen System, nicht in einem externen Dienst, und das Ergebnis wird indexiert, bevor es abfragbar ist. Die Abfrage erfolgt laut README sowohl gegen das Internet als auch gegen die lokale Datenbank. Das ist eine Zwei-Quellen-Suche, und sie erklärt, warum ein Agent im Topic-Set auftaucht. Der Agent entscheidet offenbar, ob eine Frage aus dem eigenen Bestand oder aus dem Netz beantwortet wird. Die README lässt offen, wie diese Entscheidung getroffen wird, welches Retrieval-Verfahren zum Einsatz kommt und wie die Indexstruktur aussieht. Wer plant, OmniBox in eine bestehende Suche zu integrieren, muss das im Backend-Submodul selbst nachlesen. Ein weiterer Punkt, den die README nur streift: Das System ist mandantenfähig, mit Benutzer- und Teamverwaltung, Berechtigungen und Freigabeverwaltung. Das ist für Einzelnutzer irrelevant, für Teams aber der Grund, überhaupt ein eigenes Deployment zu erwägen. Die Roadmap listet Agent-, Ordner- und Dokumentfreigabe als erledigt, ebenso Open API, Mobile App und WeChat Bot. Offen ist nur RSS Subscription.

Start über Docker Compose oder gehosteter Dienst

Die README nennt zwei Wege. Der erste ist der gehostete Dienst unter omnibox.pro mit Anmeldung per E-Mail, Google oder WeChat. Der zweite ist das lokale Entwicklungssetup. Dessen Befehle stehen vollständig in der README: git clone --recurse-submodules https://github.com/import-ai/omnibox.git, dann cd omnibox, dann cp example.env .env, dann bash scripts/dev.sh up -d --build. Bemerkenswert ist, dass die Konfiguration über eine einzelne .env-Datei läuft, die aus example.env kopiert wird. Welche Schlüssel darin stehen, gibt die README nicht an. Der Aufruf scripts/dev.sh up -d --build ist an Docker Compose angelehnt, und das Skript wird die Submodule mitbauen. Das bedeutet: Der erste Start dauert, weil mehrere Images entstehen. Für Produktivbetrieb verweist die README auf eine separate Seite unter omnibox.pro/docs/deploy. Wer das Repository nur überfliegt, sollte diesen Unterschied nicht übersehen. Der Dev-Pfad ist kein Deployment-Pfad. Die .env aus example.env enthält mit hoher Wahrscheinlichkeit Entwicklungsvorgaben, nicht gehärtete Produktionswerte. Die README sagt dazu nichts, was als Warnung gelesen werden kann: Es gibt keine dokumentierte Trennung zwischen Entwicklungs- und Produktionskonfiguration im Repository selbst.

Wo OmniBox an Grenzen stößt

Die wichtigste Einschränkung steht in der Repository-Struktur selbst. Das Hauptrepository enthält laut Beschreibung Python als primäre Sprache, aber der Großteil des Produkts liegt in Submodulen mit eigenen Release-Kanälen. Ein Fehlerbericht gegen das Hauptrepository ist damit oft am falschen Ort. Wer ein Problem im Frontend findet, muss im Submodul omnibox-web suchen, wer eines im Parser findet, in omnibox-backend. Dass die README keine Architekturbeschreibung, kein Datenbankschema und keine Beschreibung des Retrieval-Verfahrens enthält, ist für ein System dieser Art eine echte Lücke. Zweitens: Das Projekt ist auf Version 0.1.x. Die Release-Kadenz ist hoch, die Versionsnummer sagt aber, dass die Schnittstellen noch nicht als stabil zugesichert sind. Ein Upgrade von v0.1.47 auf v0.1.48 kann Änderungen enthalten, die die README nicht auflistet. Drittens: Die Anbindung an WeChat und iOS ist für einen Teil der Zielgruppe der Hauptgrund zur Nutzung, bindet das System aber an Plattformen mit eigenen Regeln und Verfügbarkeiten. Wer diese Kanäle nicht braucht, trägt Komplexität ohne Gegenwert. Viertens: Die README bewirbt Dark Mode, Mehrsprachigkeit und mobile Responsivität als Funktionen. Das sind Eigenschaften der Oberfläche, keine Argumente für den Datenbestand. Wer nach inhaltlichen Fähigkeiten sucht, findet in der README nur den einen Satz zum Parsing und Indexing.

Alternative: Obsidian mit lokalem Suchindex

Der naheliegende Vergleich ist Obsidian. Beide sammeln Notizen und Dateien in einem eigenen Bestand, beide setzen auf Markdown. Der Unterschied liegt im Ablauf. Obsidian arbeitet dateibasiert: Ein Vault ist ein Verzeichnis auf der Festplatte, jede Notiz ist eine Datei, und Plugins wie ein Vektorsuch-Plugin legen einen Index daneben. Man kann den Vault ohne Obsidian lesen, synchronisieren und versionieren. OmniBox arbeitet dienstbasiert: Inhalte landen über Erweiterung, Bot oder App in einer Datenbank, und der Zugriff läuft über die Anwendung. Das macht das Sammeln bequemer, besonders auf Mobilgeräten und über WeChat, und es macht den Bestand schwerer portabel. Wer den Datenbestand mitnehmen will, muss einen Exportweg finden, den die README nicht beschreibt. Der zweite Unterschied ist der Agent. Obsidian beantwortet Fragen nicht aus sich heraus, dafür braucht es ein Plugin oder einen externen Dienst. OmniBox bringt die Abfrage mit. Wer also primär ein lesbares, versionierbares Dateisystem will, ist mit Obsidian besser bedient. Wer primär schnelles Einsammeln aus vielen Quellen und eine eingebaute Abfrage will, findet das hier. Ein dritter Kandidat wäre eine Kombination aus Nextcloud für die Ablage und einem separaten Suchdienst. Das ist mehr Arbeit, trennt aber Speicherung und Abfrage sauber, was OmniBox nicht tut.

Lizenz, Wartung und Aktualisierungsaufwand

OmniBox steht unter Apache-2.0. Das erlaubt kommerzielle Nutzung, Änderung und Weitergabe, verlangt aber, dass Lizenz- und Urheberrechtshinweise erhalten bleiben und geänderte Dateien gekennzeichnet werden. Wer das System als eigenen Dienst betreibt, sollte die NOTICE-Datei prüfen, falls eine vorhanden ist. Das Repository wurde nicht archiviert, der letzte Push stammt vom 8. September 2026, demselben Tag wie das Release v0.1.48. Die Wartung ist also aktiv. Der Aufwand für Aktualisierungen liegt weniger im Backend als in den Submodulen. Ein Upgrade bedeutet, im Hauptrepository einen neuen Stand zu wählen und die Submodul-Zeiger mitzuziehen. Wer die Submodule selbst auf neuere Stände zieht, verlässt den getesteten Stand und sollte das bewusst tun. Dazu kommt, dass vier Komponenten vier Upgrade-Pfade bedeuten. Die Browser-Erweiterung muss im Browser aktualisiert werden, die iOS-App im App Store, das Backend über den Container. Ein einheitlicher Versionsstand über alle vier ist nicht garantiert, weil die Release-Kanäle getrennt sind. Das ist der Preis für unabhängige Versionierung, und wer das nicht regelmäßig nachhält, betreibt schnell eine Mischung aus Ständen, die niemand getestet hat.

Redaktionelles Fazit

Wer eine selbst gehostete Ablage für Webseiten, PDFs und Notizen mit LLM-Abfrage sucht und Docker Compose sowie den Umgang mit Submodulen akzeptiert, findet in OmniBox eine Apache-2.0-lizenzierte Basis. Wer eine einzelne installierbare Anwendung ohne Container erwartet, ist hier falsch. Prüft zuerst, ob der gehostete Dienst unter omnibox.pro die eigenen Datenanforderungen erfüllt, bevor ihr den lokalen Weg über scripts/dev.sh up -d --build wählt.

Offizielle Quellen

1. import-ai/omnibox on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases