Der erste KI-Agenten-Harness, der nativ im Browser läuft. Eine Browser-Erweiterung, die eine vollständige Agentenschleife genau dort ausführt, wo Sie bereits arbeiten: Sie steuert Ihre Tabs, startet abgesicherte Rechenumgebungen (JS-Notebooks, WASM-Linux-VMs, clientseitige Apps) und teilt das, was sie erstellt, Peer-to-Peer. BYOK, kein Backend, keine Telemetrie.
<p align="center"> <br> <img src="https://raw.githubusercontent.com/notasithlord/peerd/HEAD/docs/store/assets/peerd-wordmark.svg" alt="peerd" width="240" height="48"> <br> <br> </p> [](https://github.com/NotASithLord/peerd/actions/workflows/package-and-release.yml) [](packaging/check-tscheck.ts) [](tests) [](scripts/cdp/run-inbrowser-tests.mjs) [](scripts/firefox/run-runtime-tests.mjs) [](scripts/cdp/run-e2e-verify.mjs) [](docs/security/RED-TEAM-RESULTS.md) [](CONTRIBUTING.md) [](extension/vendor/vendor.lock.json) [](packaging/check-action-pins.ts) [](LICENSE) [](#install) [](SECURITY.md) # Das erste web-native KI-Agenten-Framework peerd ist die erste universelle Agenten-Laufzeitumgebung, die direkt auf Browser-Primitiven aufbaut: Workers, Origins, Sandboxing, OPFS, WASM/WASI, WebRTC, WebAuthn und WebExtensions. Sie läuft vollständig in Chrome und Firefox, mit deinen Tabs, angemeldeten Sitzungen, Web-Apps und lokaler Rechenleistung. **Während Agenten-Plattformen versuchen, den Browser in das Framework zu ziehen, zieht peerd das Framework in den Browser.** Für die eigentliche Inferenz kannst du einen unterstützten gehosteten Modellanbieter wählen, ein lokales Modell über localhost verwenden oder dir die vorläufige Unterstützung für lokale WebGPU-Modelle ansehen (wir behalten auch WebNN im Auge). Kein peerd-Konto, gehosteter Browser oder Tool-Server-Verbindung ist erforderlich. Aktuelle Builds senden keine Produkt-Telemetrie an peerd. [Installation](#install) · [peerd.ai](https://peerd.ai) · [Architektur](#architektur) · [Sicherheit](https://github.com/notasithlord/peerd/blob/main/SECURITY.md) ## Funktionen - **Funktioniert in dem Browser, den du bereits verwendest.** Der Agent kann deine Tabs, Web-Apps, angemeldeten Sitzungen und Seiteninhalte lesen und steuern. - **Erstellt wiederverwendbare Site-Clients.** Der Web-Actor kann eine Site einmal lernen und diesen Client bei späteren Aufgaben erneut verwenden. - **Führt Code innerhalb der Browser-Grenzen aus.** Skripte, versiegelte JavaScript-Notebooks, kompilierte WASI-Tools, Browser-Apps und Linux-WebVMs geben dem Agenten lokale Rechenleistung ohne Zugriff auf dein Host-Betriebssystem. - **Delegiert an separate Actors.** Jede Seite und jede Rechenumgebung erhält ihren eigenen schlüssellosen Actor mit auf diese Umgebung begrenzten Tools. - **Behält nützlichen Kontext.** Sitzungen, Speicher, Fähigkeiten, Ziele, Überprüfung und Checkpoints leben in der Erweiterung. - **Verwendet das Modell deiner Wahl.** Das Live-Anbieterverzeichnis ist in [`registry.js`](https://github.com/notasithlord/peerd/blob/main/extension/peerd-provider/registry.js) definiert, einschließlich BYOK-Cloud-Adapter und schlüsselloser lokaler Optionen. - **Verbindet Browser direkt.** Preview-Builds fügen signierte Identität, Browser-zu-Browser-Erkennung, dwapps und Agent-zu-Agent-Kommunikation über WebRTC hinzu; Store-Pakete entfernen dies vollständig. ## Warum der Browser Lokale Agenten können auf deinen gesamten Computer zugreifen. Remote-Agenten leben auf dem Computer eines anderen. Der Browser ist die Alternative: lokale Fähigkeiten hinter Sicherheitsgrenzen, die über drei Jahrzehnte gehärtet wurden. peerd nutzt diese Grenzen. Seitenarbeit geht an separate Actors mit nur den Tools für diesen Tab oder diese Umgebung. Anmeldedaten, Netzwerkregeln, Bestätigungen und Audit bleiben bei der Erweiterung. Das Defense-in-Depth-Design geht davon aus, dass unsichere Inhalte irgendwann einen Filter passieren werden. ## Browser-Unterstützung peerd unterstützt Chromium und Firefox. Firefox führt Actors in dedizierten Workern aus und verwendet sichtbare Notebooks für JavaScript-Berechnungen. Funktionen, die den Offscreen-Document-Host von Chrome benötigen, werden vor der Verwendung aus Firefox-Steuerelementen und Modell-Tools entfernt. Firefox-Preview-Builds lassen dweb weg, bis Firefox einen Mesh-Host hat. Apps und WebVMs laufen auf Chrome. Apps haben keinen Ambient-Netzwerkzugriff. Remote-Ressourcen, Fetches, WebRTC, Formulare und externe Dokumentnavigation sind blockiert. Externe HTTP- und HTTPS-Links erfordern eine Benutzerbestätigung. Konkrete Browser-Funktionslücken, ihre Upstream-Probleme und die Tests, die zum Entfernen jeder Absicherung erforderlich sind, werden in [`docs/BROWSER-COMPATIBILITY.md`](https://github.com/notasithlord/peerd/blob/main/docs/BROWSER-COMPATIBILITY.md) verfolgt. Der Code ist die Quelle der Wahrheit für das aktuelle Verhalten. Beginne mit [`CLAUDE.md`](https://github.com/notasithlord/peerd/blob/main/CLAUDE.md) und lies dann das relevante Modul unter `extension/`. ## Sicherheitsmodell peerd verwendet Browser-Isolation, enge Tool-Exposition, Service-Worker-Policy-Gates und explizite Egress-Kontrollen. Der Hauptagent delegiert Umgebungsarbeit an schlüssellose Actors. In Chrome und Firefox laufen Nicht-Orchestrator-Agenten-Schleifen in separaten dedizierten Worker-Heaps. Wenn der Browser diese Grenze nicht nachweisen kann, wird die Actor-Anfrage nicht ausgeführt und verrichtet keine Arbeit an ihrem Ziel. Das Netzwerkverhalten hängt von der Operation ab. Modellaufrufe, Web-Lesevorgänge, Laufzeit-Asset-Ladevorgänge, Sandbox-Verkehr und Preview-dweb-Verkehr verwenden unterschiedliche begrenzte Pfade und Richtlinien. Siehe [`SECURITY.md`](https://github.com/notasithlord/peerd/blob/main/SECURITY.md) und das [`Bedrohungsmodell`](https://github.com/notasithlord/peerd/blob/main/docs/security/THREAT-MODEL.md) für die aktuellen Grenzen und bekannte Einschränkungen. ## Installation ### Chrome aus dem Quellcode 1. Klone das Repository. 2. Öffne `chrome://extensions`. 3. Aktiviere den Entwicklermodus. 4. Wähle **Entpackte Erweiterung laden** und wähle das Verzeichnis `extension/`. Lade die Erweiterung nach Quellcode-Änderungen von `chrome://extensions` neu. ### Firefox aus dem Quellcode Firefox benötigt ein Firefox-spezifisches Paket. Lade nicht das eingecheckte Chrome-Entwicklungsmanifest. Verwende eine Firefox-Version, die mindestens dem im Kanal-Patch unter `manifests/` deklarierten Minimum entspricht. Diese Untergrenze verfolgt die dokumentgebundene Skripting-Unterstützung, die von Browser-Tools verwendet wird. ```sh bun run package -- --channel=preview --browser=firefox --no-sign ``` Öffne `about:debugging#/runtime/this-firefox`, wähle **Temporäres Add-on laden** und wähle `artifacts/peerd-preview-firefox.xpi`. Temporäre Add-ons müssen nach einem Firefox-Neustart erneut geladen werden. Browser- und Kanal-Transformationen werden von den Packaging-Skripten definiert. ### Release-Pakete Siehe [GitHub Releases](https://github.com/NotASithLord/peerd/releases) für aktuelle Artefakte. Store- und Preview-Builds unterscheiden sich. Store-Builds lassen dweb weg. Preview-Builds enthalten es und können zusätzliche Automatisierungsfunktionen aktivieren. Der Packaging-Code ist die Autorität für jeden Browser und Kanal. ## Erster Start 1. Öffne peerd über die Browser-Symbolleiste. 2. Erstelle und entsperre den lokalen Tresor. Die Entsperrung per Passphrase ist immer verfügbar. Die Entsperrung per Passkey hängt von der WebAuthn-PRF-Unterstützung in Browser und Gerät ab. 3. Schließe das kurze Profil-Onboarding ab. 4. Öffne die Einstellungen und füge einen Anbieterschlüssel hinzu oder wähle einen unterstützten lokalen Anbieter. 5. Wähle ein Modell aus und starte einen Chat. Nur Tresorgeheimnisse und geschützte Sicherheitsdatensätze sind durch die Tresor-Verschlüsselungsgrenze abgedeckt. Anderer lokaler Erweiterungsstatus folgt den Speicherregeln in der Sicherheitsdokumentation. ## Architektur Die Erweiterung hat fünf Hauptmodule. Jedes Modul stellt seine öffentliche API über seine `index.js` bereit. | Modul | Rolle | |---|---| | [`peerd-provider`](https://github.com/notasithlord/peerd/blob/main/extension/peerd-provider) | Modell-Adapter und Antwortformatierung | | [`peerd-egress`](https://github.com/notasithlord/peerd/blob/main/extension/peerd-egress) | Tresor, Netzwerkrichtlinie, Denylist und Audit | | [`peerd-engine`](https://github.com/notasithlord/peerd/blob/main/extension/peerd-engine) | WebVM, Notebook, App und Headless-Ausführung | | [`peerd-runtime`](https://github.com/notasithlord/peerd/blob/main/extension/peerd-runtime) | Agenten-Schleife, Actors, Tools, Sitzungen, Speicher und Berechtigungen | | [`peerd-distributed`](https://github.com/notasithlord/peerd/blob/main/extension/peerd-distributed) | Nur-Preview Peer-to-Peer-Netzwerk und dwapps | Das Erweiterungs-Chassis lebt in `background/`, `offscreen/`, `sidepanel/`, `engine-tabs/`, `permissions/`, `shared/` und zugehörigen Support-Verzeichnissen. Host-Platzierung und die Cold-Worker-Regel sind in [`docs/EXTENSION-HOSTS.md`](https://github.com/notasithlord/peerd/blob/main/docs/EXTENSION-HOSTS.md) dokumentiert. ## Entwicklung Die Quell-Erweiterung ist Vanilla-JavaScript mit ES-Modulen und läuft direkt, wenn sie entpackt geladen wird. Es gibt keinen Entwicklungs-Bundler, Transpiler, Watcher oder generierten Laufzeitbaum. Release-Packaging verwendet Bun nur auf seiner wegwerfbaren Staging-Kopie, um Leerzeichen/Kommentare aus den erstellten Modulen in den statischen Service-Worker- und Chrome-Offscreen-Cold-Graphen zu entfernen. Es bewahrt Modulgrenzen, Bindungsnamen, Lazy-Imports und jedes vendored Byte. Übergib `--no-minify` an `bun run package -- ...`, wenn ein lesbares Diagnose-Artefakt nützlich ist. ```sh bun install bun run gen:dev bun test ./tests bun scripts/cdp/run-inbrowser-tests.mjs bun run typecheck bun run lint bun run e2e:verify bun run preflight ``` Es gibt drei Testoberflächen: - Bun-Tests für reine Logik. - In-Browser-Tests für Erweiterungs- und Browser-Integration. Sie laufen headless unter Chrome und, sharded, unter Gecko gegen das installierte Firefox-Store-Paket. Jede Lane führt jeden Test aus, den sie registriert; die Gesamtzahlen unterscheiden sich leicht, weil einige Tests nur registrieren, wo ein Live-Service-Worker antwortet. - Live-Chrome-E2E- und visuelle Verifizierung für vollständige Abläufe. Daneben treibt die Red-Team-Suite in [`tests/red-team/`](https://github.com/notasithlord/peerd/blob/main/tests/red-team) jeden Gegner aus dem Bedrohungsmodell gegen den echten Verteidigungscode und zeichnet auf, ob jede feindliche Sonde blockiert wurde. Ihre Matrix ist [`docs/security/RED-TEAM-RESULTS.md`](https://github.com/notasithlord/peerd/blob/main/docs/security/RED-TEAM-RESULTS.md). Jede Lane veröffentlicht ihre eigene Anzahl als Badge oben. Das Badge-JSON unter [`badges/`](https://github.com/notasithlord/peerd/blob/main/badges) wird vom CI-Job generiert, der die Lane ausgeführt hat, und dann diffed, sodass eine Anzahl auf dieser Seite immer ein Beweis aus einem tatsächlich stattgefundenen Lauf ist und keine Zahl, die jemand getippt hat. Generiere eine neu mit `bun run gen:badge:functional`, `bun run gen:badge:red-team`, `bun run gen:badge:inbrowser`, `bun run gen:badge:gecko` (benötigt Firefox und geckodriver) oder `bun run gen:badge:e2e` und committe das Ergebnis. `bun run check:badges` verifiziert, dass die Endpunkte wohlgeformt sind, ohne einen Browser zu starten. Für UI-Änderungen führe `bun run e2e:verify` aus, inspiziere `scripts/cdp/artifacts/result.json` und inspiziere die generierten Screenshots. Generierte Dateien dürfen nicht von Hand bearbeitet werden. Insbesondere stammen `extension/manifest.json` und `extension/shared/channel-config.js` aus den Manifest- und Packaging-Quellen. CI prüft sie auf Abweichungen. Lies [`CONTRIBUTING.md`](https://github.com/notasithlord/peerd/blob/main/CONTRIBUTING.md), bevor du Code änderst. ## Dokumentation - [`CLAUDE.md`](https://github.com/notasithlord/peerd/blob/main/CLAUDE.md): Projektstruktur, Konventionen und aktuelle Haltung - [`SECURITY.md`](https://github.com/notasithlord/peerd/blob/main/SECURITY.md): Sicherheitsrichtlinie und Meldung - [`docs/security/THREAT-MODEL.md`](https://github.com/notasithlord/peerd/blob/main/docs/security/THREAT-MODEL.md): Vertrauensgrenzen und Restrisiken - [`docs/security/LIFECYCLE-CONTRACT.md`](https://github.com/notasithlord/peerd/blob/main/docs/security/LIFECYCLE-CONTRACT.md): Unterbrechungsverhalten und Wiederherstellungsgrenzen - [`docs/security/RED-TEAM-RESULTS.md`](https://github.com/notasithlord/peerd/blob/main/docs/security/RED-TEAM-RESULTS.md): Red-Team-Abdeckung - [`docs/APP-ACTORS.md`](https://github.com/notasithlord/peerd/blob/main/docs/APP-ACTORS.md): Manifest-definierte App-Actors, Live-Semantik-Adapter und die In-Tab-Co-Pilot-UX - [`docs/DWAPP-BUNDLE.md`](https://github.com/notasithlord/peerd/blob/main/docs/DWAPP-BUNDLE.md): komprimierter dwapp-Transport, dekomprimierte Arbeitsobäume und Binär-Assets - [`docs/store/`](https://github.com/notasithlord/peerd/blob/main/docs/store): Store-Packaging, Berechtigungen, Datenschutz und Reviewer-Hinweise - [`scripts/cdp/states.mjs`](https://github.com/notasithlord/peerd/blob/main/scripts/cdp/states.mjs): E2E- und visuelle Zustände ## Abhängigkeiten und Lizenz Die ausgelieferte Erweiterung hat keine npm-Laufzeitabhängigkeiten. `package.json` deklariert keine, und Packaging löst niemals einen `node_modules`-Pfad in das gestufte Artefakt auf, sodass der Entwicklungstool-Baum keinen installierten Browser erreichen kann. Drittanbieter-Laufzeitcode wird stattdessen unter `extension/vendor/` vendored. Seine Quelle, Version und Lizenz leben in den angrenzenden `SOURCE.txt`-Dateien, und jedes vendored Byte ist per SHA-256 in [`extension/vendor/vendor.lock.json`](https://github.com/notasithlord/peerd/blob/main/extension/vendor/vendor.lock.json) gepinnt, was `bun run check:vendor` in CI und Preflight verifiziert. Zwei weitere Supply-Chain-Positionen tragen ihre eigenen Badges oben, beide von `bun run gen:dev` neu generiert und in CI auf Abweichungen geprüft. Jede Drittanbieter-GitHub-Action läuft mit einem vollständigen Commit-SHA, abgesichert durch [`check:actions`](https://github.com/notasithlord/peerd/blob/main/packaging/check-action-pins.ts): Ein Major-Tag ist ein veränderbarer Ref, den sein Publisher verschieben kann, was beliebigen Code in einem Job bedeuten würde, der dieses Checkout hält, und im Release-Workflow die Signing-Secrets. Neu aufgelöste Abhängigkeiten sitzen außerdem eine Quarantänefrist ab, bevor sie in den Lock aufgenommen werden können, festgelegt durch `minimumReleaseAge` in [`bunfig.toml`](https://github.com/notasithlord/peerd/blob/main/bunfig.toml), zusammen mit einem Malware-Scan bei der Installation. peerd ist unter der [Apache License 2.0](https://github.com/notasithlord/peerd/blob/main/LICENSE) lizenziert. Vendored Komponenten behalten ihre eigenen Lizenzen. CheerpX ist eine proprietäre Laufzeitumgebung von Leaning Technologies und wird nicht von peerd's Apache-Lizenz abgedeckt.
