OpenLore

📜 OpenLore

Gesponsert von

Stellen Sie Ihre Dokumentation KI-Agenten über SSH bereit.

OpenLore ist eine minimale, erweiterbare, agenten-native Wissensdatenbank, die gemeinsamen Kontext aktuell und überprüfbar hält.

---

Über

KI-Codierungsagenten wissen bereits, wie sie Dateien mit ls, cat, grep, find, Pipes und Shell-Schleifen durchsuchen. OpenLore bietet ihnen dieselbe Schnittstelle über SSH, unterstützt durch Ihre Dokumentation anstelle einer echten Maschine.

Agent ──SSH or MCP──▶ OpenLore ──▶ docs, knowledge, and artifacts

Es beginnt als ein Ein-Binär-, Null-Konfigurations-, Nur-Lese-Dokumentationsserver. Wenn Sie eine Live-Wissensdatenbank benötigen, können Sie identitätsbezogenen Zugriff, kontrolliertes Veröffentlichen, atomare Schreibvorgänge, Validierung und menschliche Genehmigung hinzufügen, ohne zu ändern, wie Agenten Inhalte lesen oder navigieren.

Markdown speichern und abrufen

Legen Sie Dokumentation, Runbooks, Projektkontext oder von Agenten verfasste Notizen in gewöhnlichen Markdown-Dateien ab. Es gibt keine Aufnahmepipeline: Weisen Sie OpenLore auf ein Verzeichnis hin und es bedient die vorhandene Hierarchie direkt. Organisieren Sie Dokumente mit Ordnern, verbinden Sie sie mit standardmäßigen Markdown-Links und gruppieren Sie sie in Docsets, wenn verschiedene Personen oder Agenten unterschiedlichen Zugriff benötigen. OpenLore ist standardmäßig schreibgeschützt; aktivieren Sie das Schreiben, wenn Agenten auch Markdown erstellen und aktualisieren sollen.

Schnellstart

Der schnellste Weg ist, Ihren Agenten OpenLore einrichten zu lassen:

# Teach your agent how to install, configure, and bundle OpenLore
ssh openlore.sh teach | your-agent-cli

# Add documentation access instructions to AGENTS.md
ssh openlore.sh agents >> AGENTS.md

Oder installieren und führen Sie es direkt aus:

go install github.com/aakarim/go-openlore/cmd/openlore@latest

openlore ./docs

ssh -p 2222 localhost
ssh -p 2222 localhost "grep -r 'authentication' /docs"

Standardmäßig startet dies:

• SSH auf localhost:2222
• die für Menschen gedachte Webansicht auf http://localhost:8080
• MCP über HTTP auf http://localhost:8080/mcp

Weitere Installations- und Paketierungsmöglichkeiten für OpenLore finden Sie unter Installation.

Funktionen

• Agenten-nativer Abruf — Agenten verwenden die Shell-Werkzeuge und Kompositionsmuster, die sie bereits verstehen, anstatt eine maßgeschneiderte Abruf-API zu erlernen.
• Eine Wissensoberfläche, mehrere Transporte — Stellen Sie dasselbe virtuelle Dateisystem über SSH, SFTP/SSHFS, MCP und eine für Menschen freundliche Webansicht bereit.
• Live, verwaltetes Wissen — Halten Sie Inhalte schreibgeschützt, erlauben Sie eingeschränktes Veröffentlichen oder aktivieren Sie vollständige Schreibvorgänge pro Docset. Schreibvorgänge sind atomar, konfliktbewusst und können menschliche Genehmigung erfordern.
• Identitätsbezogene Ansichten — Geben Sie jeder Person oder jedem Agenten nur die Docsets, die sie benötigen, mit rollenbasierten ro, publish und rw Berechtigungen, Pfad-Aliasen und privaten Home-Verzeichnissen.
• Sicher durch Konstruktion — Die Shell ist ein In-Memory-Go-Interpreter, keine echte Betriebssystem-Shell. Es gibt keinen Shell-Escape, keine beliebige Prozessausführung oder uneingeschränkten Netzwerkzugriff in einer normalen Sitzung.
• Tragbare Wissensbündel — Betten Sie Dokumente in ein eigenständiges Binärpaket ein, erstellen Sie plattformübergreifende Bündel mit der GitHub Action oder paketieren Sie sie als Desktop-MCP-Erweiterung.
• Strukturiertes Wissen ohne neue Abfragesprache — Untersuchen Sie Frontmatter als NDJSON mit lore meta, fragen Sie es mit jq ab und validieren Sie Googles Open Knowledge Format (OKF) Bündel und Agent Skills nahe am Schreibpfad.
• Erweiterbare Richtlinien und Verarbeitung — Plugins können Validierung, Berechtigungen, Lese-/Schreib-Middleware, Metadaten und Post-Commit-Verarbeitung hinzufügen, während dieselbe Dateisystemschnittstelle erhalten bleibt.

Anwendungsfälle

• Continuous-Learning-Repository – Speichern Sie Sitzungen und Erkenntnisse in einem gemeinsamen Server. Fügen Sie Metriken hinzu, um zu optimieren. Erlauben Sie Agenten, Erkenntnisse untereinander zu teilen, während die Benutzerisolation erhalten bleibt.
• Team-Artefakt-Repository – Teilen Sie Markdown-, HTML-, JSON-, Excel- usw. Dokumente, die Sie erstellt haben, unter Beibehaltung der Zugriffskontrollen. Viel natürlicher als Git, agenten-nativer als Confluence/Notion.
• Dokumentation für Codierungsagenten — Stellen Sie interne API-Dokumente, Runbooks, Produktkontext und Architekturnotizen hinter einer vertrauten, durchsuchbaren Schnittstelle bereit.
• Ein gemeinsames Live-Gedächtnis für Agententeams — Geben Sie Agenten separate oder gemeinsame Docsets, damit sie Ergebnisse veröffentlichen, Arbeit übergeben und dauerhaften Kontext über Sitzungen hinweg ansammeln können.
• Öffentliche Dokumentationsseite – Fügen Sie beliebige Dateien zu Ihrem öffentlichen Docset hinzu, aktivieren Sie öffentlichen Zugriff, und es wird jedem Agenten angezeigt, der auf Ihre Seite stößt. Verbessert AEO/GEO, ohne Ihre vorhandenen Dokumente bearbeiten zu müssen.
• Skills-Austausch — Veröffentlichen Sie Agent Skills in gemeinsamen Sammlungen, damit jeder autorisierte Agent dieselben verwalteten Verfahren entdecken und nutzen kann.
• Agent-Plugins-Repository — Pinnen Sie Agent Plugins Repos von GitHub per Version und stellen Sie sie den Agenten Ihres Teams bereit. Skills, die im offenen Standard verpackt sind, bleiben automatisch aktuell.
• Verwalteter Wissensbeitrag — Lassen Sie Mitwirkende in Posteingänge veröffentlichen, während sensible Pfade für Genehmiger reserviert bleiben und versehentliche Überschreibungen verhindert werden.
• Remote-Überprüfung von Agent-Artefakten — Stellen Sie Berichte, Protokolle, Screenshots und generierte Dateien über den Browser oder SSH bereit, ohne einen benutzerdefinierten Artefakt-Viewer zu erstellen oder Zugriff auf die Maschine des Agenten zu gewähren.
• Identitätsspezifische Arbeitsbereiche — Mounten Sie ein privates Home für jeden Agenten plus gemeinsames Teamwissen, alles über einen Server und ein Autorisierungsmodell.
• Tragbares Kunden- oder Projektwissen — Liefern Sie eine versionierte ausführbare Datei mit den relevanten eingebetteten Dokumenten aus oder verteilen Sie dasselbe Wissen als MCPB Desktop-Erweiterung.
• Validierte Wissenskataloge — Erzwingen Sie Frontmatter- und Bündelkonventionen, untersuchen Sie Metadaten kostengünstig und stoppen Sie fehlerhaftes Wissen beim Aufnahmepunkt.

So funktioniert es

OpenLore basiert auf Wish für den SSH-Transport. Eine Verbindung wird vollständig gegen ein virtuelles Dateisystem behandelt:

1. Authentifizieren — Verbinden Sie sich schlüssellos oder lösen Sie einen SSH-Schlüssel, ein Zertifikat, einen Passkey oder einen OAuth-Login in eine Identität auf.
2. Eine Ansicht zusammenstellen — Mounten Sie nur die Docsets und Pfade, die dieser Identität gewährt wurden.
3. Erkunden — Führen Sie Shell-Befehle aus, die als reine Go-Funktionen über diese Ansicht implementiert sind, oder verwenden Sie das äquivalente MCP shell Werkzeug.
4. Sicher beitragen — Wenn Schreiben aktiviert ist, autorisieren und validieren Sie eine Änderung der gesamten Datei, bevor Sie sie atomar committen oder zur Genehmigung weiterleiten.

OAuth-Clients verwenden delegierte Identitäten, sodass eine dauerhafte Schreibherkunft direkte Arbeit von adil von Arbeit unterscheidet, die als adil/claude@claude.ai ausgeführt wird. Delegierte können nicht mehr Autorität erben als ihr Auftraggeber und können durch Docset- und Fähigkeits-Denylists eingeschränkt werden. CIMD-Clients können sich zusätzlich mit vom Anbieter gehosteten Metadaten und private_key_jwt authentifizieren; siehe Authentifizierte OAuth-Clients.

Die normale Shell kann bash, exec, curl oder beliebige Host-Prozesse nicht aufrufen. Eingebettete Dokumentation ist immer schreibgeschützt. Explizit vertrauenswürdige Identitäten können eng begrenzte asynchrone Verarbeitung über die spawn Fähigkeit erhalten.

Verwaltetes Schreiben

OpenLore ist standardmäßig schreibgeschützt. Beschreibbare Bereitstellungen halten einen einzigen, richtliniengesteuerten Schreibpfad für Weiterleitungen, Anhängen, tee, patch, sed -i, Dateiverschiebungen, Veröffentlichungen und genehmigte externe Aufträge.

echo "# Research" | publish backend findings.md
cat change.diff | patch /backend/api.md
sed -i 's/old/new/g' /backend/runbook.md

Schreibvorgänge sind atomare Austausche ganzer Objekte. Compare-and-Swap-Schutz lehnt veraltete Bearbeitungen standardmäßig ab, Docset-Berechtigungen begrenzen das Ziel, und ausgewählte Pfade können überprüfbare Änderungssätze unter /requests erzeugen, anstatt direkt zu committen.

Siehe Schreiben und Veröffentlichen für die benutzerorientierte Einrichtung und Interna des Schreibsystems für das Implementierungsmodell.

Installation

Mit Go installieren

Erfordert Go 1.26 oder höher:

go install github.com/aakarim/go-openlore/cmd/openlore@latest

Aus dem Quellcode erstellen

git clone https://github.com/aakarim/go-openlore.git
cd go-openlore
go build -o openlore ./cmd/openlore

Dokumente in ein Binärpaket einbetten

Platzieren Sie die Dokumentation in assets/lore/ und erstellen Sie. Das resultierende Binärpaket enthält die Dokumente und stellt sie schreibgeschützt unter /docs bereit, wenn es ohne Verzeichnisargument ausgeführt wird:

go build -o my-docs ./cmd/openlore

Mit der GitHub Action erstellen

Erstellen Sie plattformübergreifende Binärpakete mit Ihren eingebetteten Dokumenten:

- uses: aakarim/openlore@v1
  with:
    docs-dir: ./docs
    config: ./openlore.yml

Siehe Möglichkeiten zur Verwendung von OpenLore für MCP stdio, MCPB-Desktop- Paketierung, SSHFS und Go-Bibliotheksnutzung.

Eine angepasste Bereitstellung erstellen

Verwenden Sie die gebündelte setup Fähigkeit, um <team>-lore zu erstellen, ein kleines, kundeneigenes Repository, das openlore.yml, ein schlankes Containerfile, das auf eine offizielle OpenLore-Version gepinnt ist, und Bereitstellungsartefakte enthält. Es erstellt einen funktionierenden lokalen Server und überprüft HTTP, MCP, authentifiziertes SSH, Schreibvorgänge und Persistenz vor der Bereitstellung:

ssh openlore.sh setup | amp

Das generierte Repository hält die anfängliche lore.json Richtlinie und SSH-sichtbare Dateien unter gitignoriertem .local/. Die erste Bereitstellung initialisiert ein leeres persistentes Volume aus diesem Zustand. Root openlore.yml bleibt die Git/IaC-Autorität und wird separat auf /var/lib/openlore/config/openlore.yml bereitgestellt; es ist nicht in das Image eingebacken. Spätere lore.json und Dateisystembearbeitungen auf dem Server sind maßgeblich und werden niemals durch Image-Updates überschrieben.

Zusätzliche Anweisungsbefehle unterstützen den vollständigen Lebenszyklus:

• onboarding fügt anfängliche Identitäten, Rollen, Homes und Ordner lokal hinzu;
• deploy wählt Fly.io, Railway, AWS, Google Cloud, Azure, DigitalOcean oder eine benutzerdefinierte Bereitstellung und überprüft einen gemeinsamen Persistenz-/Netzwerkvertrag;
• upgrade bereitet nur die Änderung der gepinnten Basis-Image-Version vor, damit vorhandenes CD sie bereitstellen kann.

Anbieterbereitstellungen erfordern HTTPS/MCP, authentifiziertes OpenLore-SSH, administrativen Shell-Zugriff und ein persistentes /var/lib/openlore Volume. Wo der Anbieter es unterstützt, konfiguriert die Bereitstellung den öffentlichen Port 22 zur Weiterleitung an den OpenLore-Port 2222. Andernfalls meldet sie den zugewiesenen Port und empfiehlt ein externes TCP-Weiterleitungssystem.

Das veröffentlichte Container-Image enthält nur OpenLore. Es enthält bewusst keine Onboarding-Richtlinie oder Serverkonfiguration. Bevor der Dienst startet, muss die Bereitstellung openlore.yml und lore.json in das persistente Konfigurationsverzeichnis legen und ausführen:

./out --config /var/lib/openlore/config/openlore.yml

Dies hält die Konfiguration unabhängig bereitstellbar: Eine einfache Bereitstellung kann openlore.yml auf das Volume kopieren, während Kubernetes dieselbe Datei aus einem ConfigMap projizieren kann. Verwenden Sie die deploy Fähigkeit für Fly.io, Railway, AWS, Google Cloud, Azure, DigitalOcean oder benutzerdefinierte Infrastruktur. Die Railpack- und Fly-Dateien des Repositorys bieten das Image, das persistente Volume und die Port-Verdrahtung; sie seeden oder ändern die Konfiguration beim Prozessstart nicht.

Railway weist seinem SSH-TCP-Proxy einen öffentlichen Hostnamen und Port zu. Standard-SSH-Port 22 erfordert einen externen Raw-TCP-Lastausgleicher. Fly.io kann den öffentlichen Port 22 auf den internen Port 2222 von OpenLore mit einer dedizierten Adresse abbilden. Raw-SSH hat keinen Hostnamen oder SNI-Routing, sodass ein Listener keine mehreren Domains auf Port 22 routen kann.

Der Container-Workflow veröffentlicht latest aus main; Releases veröffentlichen auch VERSION, vVERSION, Major- und Minor-Image-Tags.

HTTP-Posteingang-Uploads

Konfigurieren Sie ein Docset inbox und eine Rolle mit ihrer publish Berechtigung, erstellen Sie dann eine Berechtigung für eine vorhandene Identität (die Serverkonfiguration muss auth_file benennen, damit die CLI sie validieren kann):

openlore inbox token create --identity alice --label webhook --config openlore.yml
curl -H 'Authorization: Bearer olin_ID_SECRET' -H 'Content-Type: text/markdown' \
  --data-binary @note.md 'https://docs.example.com/inbox/docs?name=note.md'

POST /inbox/{docset} akzeptiert Bearer-Berechtigungen oder einen Exakt-Body-HMAC mit X-OpenLore-Token-Id und X-OpenLore-Signature. OAuth-Zugriffstoken werden nur für POST/GET /inbox/tokens und DELETE /inbox/tokens/{id} verwendet; Posteingangs- Berechtigungen sind separat und widerrufbar. Siehe Konfiguration und Identität.

Dokumentation

Leitfaden	Inhalt
Möglichkeiten zur Nutzung von OpenLore	SSH, MCP, Web, SSHFS, eingebettete Binärdateien, GitHub Action, MCPB und Bibliotheksnutzung
Befehlsreferenz	Vollständige Shell-, Introspections-, Veröffentlichungs-, Syntax-, CLI-Befehls- und Flag-Referenz
Konfiguration und Identität	openlore.yml, Authentifizierung, Rollen, Docsets, Aliase, Homes und Host-Verifizierung
Workload-Identitätsverbund	Authentifizieren Sie CI und Agents mit kurzlebigen externen Identitätstokens
Schreiben und Veröffentlichen	Schreibmodi, Posteingänge, Konfliktbehandlung, Genehmigungen und Jobs
Plugins und Wissensformate	Plugin-Installation, Schnittstellen, OKF-Validierung, lore validate und lore meta
Interna des Schreibsystems	Dateisystem-Schichtung, Schreibnaht, Änderungssätze, Hooks und asynchrone Jobs
Sicherheitsbewertung	Bedrohungsmodell und Sicherheitseigenschaften

Sicherheit

• Befehle werden in einem reinen Go-Interpreter ausgeführt, nicht über os/exec.
• Das virtuelle Dateisystem bereinigt Pfade und erzwingt Docset-Grenzen.
• Zulässige Dateimuster und ignorierte Verzeichnisse halten Geheimnisse aus der Ansicht fern.
• RBAC steuert Lesezugriffe, Veröffentlichung, Schreibvorgänge, Genehmigungen und vertrauenswürdige Fähigkeiten.
• Der Web-Endpunkt kann den SSH-Hostschlüssel über TLS veröffentlichen, um blindes Vertrauen bei der ersten Nutzung zu vermeiden; SSH-Benutzer- und Host-Zertifikate werden ebenfalls unterstützt.

Siehe SECURITY.md für die vollständige Sicherheitsbewertung.

Lizenz

MIT — Adil Karim

OpenLore bündelt Open-Source-Komponenten von Drittanbietern. Deren Lizenzen und erforderliche Hinweise sind in assets/legal/THIRD_PARTY_NOTICES.md aufgeführt, mit vollständigen Lizenztexten in assets/legal/licenses/. Diese sind in der Binärdatei eingebettet und werden vom laufenden Dienst unter /legal bereitgestellt.