Il primo harness per agenti AI nativo del browser. Un'estensione del browser che esegue un ciclo completo di agenti dove già lavori: gestisce le tue schede, avvia risorse di calcolo in sandbox (notebook JS, VM Linux WASM, app lato client) e condivide ciò che costruisce peer-to-peer. BYOK, nessun backend, nessuna telemetria.
<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) # Il primo harness per agenti AI nativo del web peerd è il primo runtime per agenti generici costruito direttamente sui primitivi del browser: Workers, origins, sandboxing, OPFS, WASM/WASI, WebRTC, WebAuthn e WebExtensions. Funziona completamente dentro Chrome e Firefox, con le tue schede, le sessioni con accesso effettuato, le web app e la potenza di calcolo locale. **Mentre le piattaforme per agenti cercano di trascinare il browser nell'harness, peerd porta l'harness nel browser.** Per l'inferenza vera e propria puoi scegliere un provider di modelli ospitato supportato, un modello locale tramite localhost, oppure dare un'occhiata al supporto preliminare per modelli WebGPU locali (teniamo d'occhio anche WebNN). Non è richiesto alcun account peerd, browser ospitato o connessione a un tool-server. Le build attuali non inviano telemetria di prodotto a peerd. [Installazione](#install) · [peerd.ai](https://peerd.ai) · [Architettura](#architecture) · [Sicurezza](https://github.com/notasithlord/peerd/blob/main/SECURITY.md) ## Funzionalità - **Funziona nel browser che già usi.** L'agente può leggere e pilotare le tue schede, le web app, le sessioni con accesso effettuato e il contenuto delle pagine. - **Costruisce client di sito riutilizzabili.** L'attore web può imparare un sito una volta e riusare quel client in attività successive. - **Esegue codice dentro i confini del browser.** Script, JavaScript Notebook sigillati, strumenti WASI compilati, App del browser e WebVM Linux danno all'agente potenza di calcolo locale senza accesso al sistema operativo host. - **Delega ad attori separati.** Ogni pagina e ambiente di calcolo ha il proprio attore senza chiavi con strumenti limitati a quell'ambiente. - **Conserva il contesto utile.** Sessioni, memoria, competenze, obiettivi, revisione e checkpoint vivono nell'estensione. - **Usa il modello che scegli.** L'inventario live dei provider è definito in [`registry.js`](https://github.com/notasithlord/peerd/blob/main/extension/peerd-provider/registry.js), inclusi adattatori cloud BYOK e opzioni locali senza chiavi. - **Collega i browser direttamente.** Le build di anteprima aggiungono identità firmata, discovery browser-to-browser, dwapp e comunicazione agente-agente su WebRTC; i pacchetti dello store li eliminano completamente. ## Perché il browser Gli agenti locali possono accedere a tutto il tuo computer. Gli agenti remoti vivono nel computer di qualcun altro. Il browser è l'alternativa: capacità locale dietro confini di sicurezza temprati per tre decenni. peerd usa quei confini. Il lavoro sulle pagine va ad attori separati con solo gli strumenti per quella scheda o ambiente. Credenziali, regole di rete, conferme e audit restano nell'estensione. Il suo design di difesa in profondità presuppone che contenuti non sicuri prima o poi superino un filtro. ## Supporto browser peerd supporta Chromium e Firefox. Firefox esegue gli attori in worker dedicati e usa Notebook visibili per il calcolo JavaScript. Le funzionalità che richiedono l'host del documento offscreen di Chrome vengono rimosse dai controlli di Firefox e dagli strumenti dei modelli prima dell'uso. Le build di anteprima per Firefox omettono dweb finché Firefox non ha un host mesh. Le App e le WebVM girano su Chrome. Le App non hanno accesso di rete ambientale. Le risorse remote, i fetch, WebRTC, i moduli e la navigazione verso documenti esterni sono bloccati. I link HTTP e HTTPS esterni richiedono conferma dell'utente. I gap concreti di capacità del browser, i relativi problemi a monte e i test richiesti per rimuovere ogni protezione sono tracciati in [`docs/BROWSER-COMPATIBILITY.md`](https://github.com/notasithlord/peerd/blob/main/docs/BROWSER-COMPATIBILITY.md). Il codice è la fonte di verità per il comportamento attuale. Inizia da [`CLAUDE.md`](https://github.com/notasithlord/peerd/blob/main/CLAUDE.md), poi leggi il modulo pertinente sotto `extension/`. ## Modello di sicurezza peerd usa isolamento del browser, esposizione ristretta degli strumenti, gate di policy del service worker e controlli espliciti di egress. L'agente principale delega il lavoro sugli ambienti ad attori senza chiavi. Su Chrome e Firefox, i loop di agenti non orchestratori girano in heap di worker dedicati separati. Se il browser non può dimostrare quel confine, la richiesta dell'attore non viene eseguita e non svolge alcun lavoro sul suo target. Il comportamento di rete dipende dall'operazione. Le chiamate ai modelli, le letture web, i caricamenti di asset runtime, il traffico sandbox e il traffico dweb di anteprima usano percorsi e policy con ambiti diversi. Vedi [`SECURITY.md`](https://github.com/notasithlord/peerd/blob/main/SECURITY.md) e il [`modello di minaccia`](https://github.com/notasithlord/peerd/blob/main/docs/security/THREAT-MODEL.md) per i confini attuali e le limitazioni note. ## Installazione ### Chrome da sorgente 1. Clona il repository. 2. Apri `chrome://extensions`. 3. Attiva la Modalità sviluppatore. 4. Scegli **Carica estensione non pacchettizzata** e seleziona la directory `extension/`. Ricarica l'estensione da `chrome://extensions` dopo le modifiche al sorgente. ### Firefox da sorgente Firefox richiede un pacchetto specifico per Firefox. Non caricare il manifest di sviluppo Chrome incluso nel repository. Usa una versione di Firefox uguale o superiore al minimo dichiarato nella patch del canale sotto `manifests/`. Quel minimo segue il supporto di scripting legato al documento usato dagli strumenti del browser. ```sh bun run package -- --channel=preview --browser=firefox --no-sign ``` Apri `about:debugging#/runtime/this-firefox`, scegli **Carica componente aggiuntivo temporaneo** e seleziona `artifacts/peerd-preview-firefox.xpi`. I componenti aggiuntivi temporanei devono essere ricaricati dopo il riavvio di Firefox. Le trasformazioni di browser e canale sono definite dagli script di packaging. ### Pacchetti di rilascio Vedi [GitHub Releases](https://github.com/NotASithLord/peerd/releases) per gli artefatti attuali. Le build dello store e di anteprima differiscono. Le build dello store omettono dweb. Le build di anteprima lo includono e possono abilitare funzionalità di automazione aggiuntive. Il codice di packaging è l'autorità per ogni browser e canale. ## Primo avvio 1. Apri peerd dalla barra degli strumenti del browser. 2. Crea e sblocca il vault locale. Lo sblocco con passphrase è sempre disponibile. Lo sblocco con passkey dipende dal supporto WebAuthn PRF nel browser e nel dispositivo. 3. Completa il breve onboarding del profilo. 4. Apri Impostazioni, poi aggiungi una chiave del provider o scegli un provider locale supportato. 5. Seleziona un modello e avvia una chat. Solo i segreti del vault e i record di sicurezza protetti sono coperti dal confine di crittografia del vault. Altro stato locale dell'estensione segue le regole di archiviazione nella documentazione di sicurezza. ## Architettura L'estensione ha cinque moduli principali. Ogni modulo espone la sua API pubblica tramite il suo `index.js`. | Modulo | Ruolo | |---|---| | [`peerd-provider`](https://github.com/notasithlord/peerd/blob/main/extension/peerd-provider) | Adattatori di modelli e formattazione delle risposte | | [`peerd-egress`](https://github.com/notasithlord/peerd/blob/main/extension/peerd-egress) | Vault, policy di rete, denylist e audit | | [`peerd-engine`](https://github.com/notasithlord/peerd/blob/main/extension/peerd-engine) | WebVM, Notebook, App ed esecuzione headless | | [`peerd-runtime`](https://github.com/notasithlord/peerd/blob/main/extension/peerd-runtime) | Loop dell'agente, attori, strumenti, sessioni, memoria e permessi | | [`peerd-distributed`](https://github.com/notasithlord/peerd/blob/main/extension/peerd-distributed) | Rete peer-to-peer e dwapp solo anteprima | Il telaio dell'estensione vive in `background/`, `offscreen/`, `sidepanel/`, `engine-tabs/`, `permissions/`, `shared/` e directory di supporto correlate. Il posizionamento degli host e la regola del worker freddo sono documentati in [`docs/EXTENSION-HOSTS.md`](https://github.com/notasithlord/peerd/blob/main/docs/EXTENSION-HOSTS.md). ## Sviluppo L'estensione sorgente è JavaScript vanilla con moduli ES e gira direttamente quando viene caricata non pacchettizzata. Non c'è bundler di sviluppo, transpiler, watcher o albero runtime generato. Il packaging di rilascio usa Bun solo sulla sua copia di staging usa e getta per rimuovere spazi bianchi/commenti dai moduli autori nei grafi freddi statici del service worker e dell'offscreen di Chrome. Preserva i confini dei moduli, i nomi dei binding, gli import lazy e ogni byte venduto. Passa `--no-minify` a `bun run package -- ...` quando un artefatto diagnostico leggibile è utile. ```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 ``` Ci sono tre superfici di test: - Test Bun per la logica pura. - Test in-browser per l'integrazione di estensione e browser. Girano headless sotto Chrome e, in shard, sotto Gecko contro il pacchetto Firefox Store installato. Ogni corsia esegue ogni test che registra; i totali differiscono leggermente perché alcuni test si registrano solo dove un service worker live risponde. - E2E Chrome live e verifica visiva per i flussi completi. Accanto a questi, la suite red-team in [`tests/red-team/`](https://github.com/notasithlord/peerd/blob/main/tests/red-team) guida ogni avversario del modello di minaccia contro il codice di difesa reale e registra se ogni sonda ostile è stata bloccata. La sua matrice è [`docs/security/RED-TEAM-RESULTS.md`](https://github.com/notasithlord/peerd/blob/main/docs/security/RED-TEAM-RESULTS.md). Ogni corsia pubblica il proprio conteggio come badge sopra. Il JSON dei badge sotto [`badges/`](https://github.com/notasithlord/peerd/blob/main/badges) è generato dal job CI che ha eseguito la corsia e poi confrontato, quindi un conteggio su questa pagina è sempre prova di un'esecuzione avvenuta piuttosto che un numero digitato da qualcuno. Rigenerane uno con `bun run gen:badge:functional`, `bun run gen:badge:red-team`, `bun run gen:badge:inbrowser`, `bun run gen:badge:gecko` (richiede Firefox e geckodriver), o `bun run gen:badge:e2e`, e committa il risultato. `bun run check:badges` verifica che gli endpoint siano ben formati senza avviare un browser. Per le modifiche UI, esegui `bun run e2e:verify`, ispeziona `scripts/cdp/artifacts/result.json` e ispeziona gli screenshot generati. I file generati non devono essere modificati a mano. In particolare, `extension/manifest.json` e `extension/shared/channel-config.js` provengono dal manifest e dalle sorgenti di packaging. CI li controlla per rilevare derive. Leggi [`CONTRIBUTING.md`](https://github.com/notasithlord/peerd/blob/main/CONTRIBUTING.md) prima di modificare il codice. ## Documentazione - [`CLAUDE.md`](https://github.com/notasithlord/peerd/blob/main/CLAUDE.md): struttura del progetto, convenzioni e postura attuale - [`SECURITY.md`](https://github.com/notasithlord/peerd/blob/main/SECURITY.md): policy di sicurezza e segnalazione - [`docs/security/THREAT-MODEL.md`](https://github.com/notasithlord/peerd/blob/main/docs/security/THREAT-MODEL.md): confini di fiducia e rischi residui - [`docs/security/LIFECYCLE-CONTRACT.md`](https://github.com/notasithlord/peerd/blob/main/docs/security/LIFECYCLE-CONTRACT.md): comportamento di interruzione e limiti di recupero - [`docs/security/RED-TEAM-RESULTS.md`](https://github.com/notasithlord/peerd/blob/main/docs/security/RED-TEAM-RESULTS.md): copertura red-team - [`docs/APP-ACTORS.md`](https://github.com/notasithlord/peerd/blob/main/docs/APP-ACTORS.md): attori App definiti dal manifest, adattatori semantici live e UX co-pilota in scheda - [`docs/DWAPP-BUNDLE.md`](https://github.com/notasithlord/peerd/blob/main/docs/DWAPP-BUNDLE.md): trasporto dwapp compresso, alberi di lavoro decodificati e asset binari - [`docs/store/`](https://github.com/notasithlord/peerd/blob/main/docs/store): packaging dello store, permessi, privacy e note per i revisori - [`scripts/cdp/states.mjs`](https://github.com/notasithlord/peerd/blob/main/scripts/cdp/states.mjs): stati E2E e visivi ## Dipendenze e licenza L'estensione distribuita non ha dipendenze runtime npm. `package.json` non ne dichiara nessuna, e il packaging non risolve mai un percorso `node_modules` nell'artefatto di staging, quindi l'albero degli strumenti di sviluppo non può raggiungere un browser installato. Il codice runtime di terze parti è invece venduto sotto `extension/vendor/`. La sua sorgente, versione e licenza vivono nei file `SOURCE.txt` adiacenti, e ogni byte venduto è ancorato tramite SHA-256 in [`extension/vendor/vendor.lock.json`](https://github.com/notasithlord/peerd/blob/main/extension/vendor/vendor.lock.json), che `bun run check:vendor` verifica in CI e preflight. Altre due posizioni della supply chain portano i propri badge sopra, entrambi rigenerati da `bun run gen:dev` e controllati per derive in CI. Ogni GitHub Action di terze parti gira a un commit SHA completo, protetto da [`check:actions`](https://github.com/notasithlord/peerd/blob/main/packaging/check-action-pins.ts): un tag major è un ref mutabile che il suo editore può spostare, il che significherebbe codice arbitrario in un job che detiene questo checkout e, nel workflow di rilascio, i segreti di firma. Le dipendenze appena risolte restano anche in una finestra di quarantena prima di poter entrare nel lock, impostata da `minimumReleaseAge` in [`bunfig.toml`](https://github.com/notasithlord/peerd/blob/main/bunfig.toml), insieme a una scansione malware all'installazione. peerd è concesso in licenza sotto la [Apache License 2.0](https://github.com/notasithlord/peerd/blob/main/LICENSE). I componenti venduti mantengono le proprie licenze. CheerpX è un runtime proprietario fornito da Leaning Technologies e non è coperto dalla licenza Apache di peerd.
