Le harnais d'agents natif au navigateur

peerd exécute des agents polyvalents dans votre propre Chrome ou Firefox.

Il fonctionne avec les onglets, les sessions connectées, les applications web et la capacité de calcul intégrée au navigateur que vous avez déjà. Vous choisissez un fournisseur de modèles cloud ou local pris en charge. Aucun compte Peerd ni navigateur hébergé n'est requis, et les versions actuelles n'envoient aucune télémétrie produit à Peerd.

Les agents locaux peuvent accéder à l'ensemble de votre ordinateur. Les agents distants vivent dans celui de quelqu'un d'autre. peerd s'exécute dans votre navigateur.

Install · peerd.ai · Architecture · Sécurité

Pourquoi le navigateur comme environnement natif

Votre navigateur possède déjà vos applications, vos sessions, votre identité, votre réseau, votre interface et une capacité de calcul locale utile. Il dispose également de frontières conçues pour les pages hostiles.

peerd utilise ces frontières. Le travail sur les pages est confié à des acteurs séparés disposant uniquement des outils propres à cet onglet ou à cet environnement. Les identifiants, les règles réseau, les confirmations et l'audit restent dans l'extension. Cette conception de défense en profondeur part du principe qu'un contenu non sûr finira par passer au travers d'un filtre.

Ce qui rend peerd différent

• Votre navigateur est l'espace de travail. L'agent travaille avec les onglets, les applications, les sessions et le contenu de page déjà présents devant vous.
• Le travail sur les pages reste séparé. Les acteurs Web, WebVM, Notebook, App et dweb d'aperçu reçoivent chacun des outils pour leur propre environnement.
• Les connaissances sur les sites sont réutilisables. L'acteur web peut créer un client adaptatif pour un site et le réutiliser lors de tâches ultérieures.
• La capacité de calcul reste dans les frontières du navigateur. peerd peut exécuter des scripts, des Notebooks JavaScript scellés, des outils WASI compilés, des Apps navigateur et des WebVMs Linux sur Chromium.
• Vous choisissez le modèle. L'inventaire à jour des fournisseurs est défini dans registry.js, avec notamment des adaptateurs cloud BYOK et des options locales sans clé.
• Le P2P est facultatif. Les versions d'aperçu ajoutent une identité signée, la découverte navigateur-à-navigateur, les dwapps et la communication agent-à-agent via WebRTC ; les paquets du store le suppriment entièrement.

Status

peerd est une bêta expérimentale 0.x. Des changements cassants sont probables. Les formats de stockage et le comportement du produit peuvent changer. Il peut piloter des pages du navigateur et utiliser des clés API ; examinez donc le modèle de sécurité avant de l'utiliser avec des données sensibles.

Chromium est la cible produit principale. La prise en charge de Firefox est expérimentale. Il exécute les acteurs dans des workers dédiés et utilise des Notebooks visibles pour le calcul JavaScript. Les fonctionnalités qui nécessitent l'hôte de document hors écran (offscreen) de Chrome sont retirées des contrôles Firefox et des outils du modèle avant utilisation. Le paquet d'aperçu Firefox omet également dweb tant que Firefox ne dispose pas d'un hôte mesh.

Le code est la source de vérité pour le comportement actuel. Commencez par CLAUDE.md, puis lisez le module concerné sous extension/.

Ce qu'il fait

• Exécute une boucle d'agent dans Chrome et un paquet Firefox expérimental.
• Lit et pilote les onglets du navigateur via des acteurs par environnement.
• Exécute des WebVMs Linux, des Notebooks JavaScript, des Apps navigateur et, lorsque l'hôte d'exécution les prend en charge, des scripts headless.
• Prend en charge les fournisseurs de modèles cloud et locaux. La liste à jour se trouve dans extension/peerd-provider/registry.js.
• Stocke les secrets des fournisseurs dans un coffre-fort chiffré local.
• Inclut un dweb pair-à-pair facultatif dans les versions d'aperçu.

Les Apps et les WebVMs s'exécutent actuellement uniquement sur Chrome. Les Apps n'ont aucun accès réseau ambiant. Les ressources distantes, les requêtes fetch, WebRTC, les formulaires et la navigation vers des documents externes sont bloqués. Les liens HTTP et HTTPS externes nécessitent une confirmation de l'utilisateur.

Modèle de sécurité

peerd utilise l'isolation du navigateur, une exposition étroite des outils, des contrôles de politique par service worker et des contrôles de sortie explicites. L'agent principal délègue le travail lié à l'environnement à des acteurs sans clé. Sur Chrome et Firefox, les boucles d'agent autres que l'orchestrateur s'exécutent dans des tas de workers dédiés distincts. Si le navigateur ne peut pas prouver cette frontière, la requête de l'acteur ne s'exécute pas et n'effectue aucun travail sur sa cible.

Le comportement réseau dépend de l'opération. Les appels de modèles, les lectures web, les chargements de ressources d'exécution, le trafic sandbox et le trafic dweb d'aperçu utilisent des chemins et des politiques de portées différentes. Consultez SECURITY.md et le modèle de menace pour connaître les frontières actuelles et les limitations connues.

Install

Chrome à partir des sources

1. Clonez le dépôt.
2. Ouvrez chrome://extensions.
3. Activez le mode développeur.
4. Choisissez Charger l'extension non empaquetée et sélectionnez le répertoire extension/.

Rechargez l'extension depuis chrome://extensions après toute modification des sources.

Firefox à partir des sources

Firefox nécessite un paquet spécifique à Firefox. Ne chargez pas le manifeste de développement Chrome inclus dans le dépôt. Utilisez une version de Firefox au moins égale au minimum déclaré dans le correctif de canal sous manifests/. Ce plancher suit la prise en charge du scripting lié aux documents utilisée par les outils du navigateur.

bun run package -- --channel=preview --browser=firefox --no-sign

Ouvrez about:debugging#/runtime/this-firefox, choisissez Charger un module temporaire et sélectionnez artifacts/peerd-preview-firefox.xpi. Les modules temporaires doivent être rechargés après un redémarrage de Firefox. Les transformations navigateur et canal sont définies par les scripts d'empaquetage.

Paquets de publication

Consultez GitHub Releases pour les artefacts actuels. Les versions Store et aperçu diffèrent. Les versions Store omettent le dweb. Les versions d'aperçu l'incluent et peuvent activer des fonctionnalités d'automatisation supplémentaires. Le code d'empaquetage fait autorité pour chaque navigateur et canal.

Premier lancement

1. Ouvrez peerd depuis la barre d'outils du navigateur.
2. Créez et déverrouillez le coffre-fort local. Le déverrouillage par phrase de passe est toujours disponible. Le déverrouillage par passkey dépend de la prise en charge de WebAuthn PRF par le navigateur et l'appareil.
3. Terminez le court onboarding du profil.
4. Ouvrez les Paramètres, puis ajoutez une clé de fournisseur ou choisissez un fournisseur local pris en charge.
5. Sélectionnez un modèle et démarrez une conversation.

Seuls les secrets du coffre-fort et les enregistrements de sécurité protégés sont couverts par la frontière de chiffrement du coffre-fort. Le reste de l'état local de l'extension suit les règles de stockage définies dans la documentation sur la sécurité.

Architecture

L'extension comprend cinq modules principaux. Chaque module expose son API publique via son index.js.

Le châssis de l'extension se trouve dans background/, offscreen/, sidepanel/, engine-tabs/, permissions/, shared/ et les répertoires de support associés.

Développement

L'extension livrée est du JavaScript vanilla avec des modules ES, sans bundling ni transpilation. Bun est utilisé pour les tests, la génération, l'empaquetage et les vérifications de publication.

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

Il existe trois surfaces de test :

• Des tests Bun pour la logique pure.
• Des tests dans le navigateur pour l'intégration de l'extension et du navigateur.
• Des tests E2E Chrome en direct et une vérification visuelle pour les flux complets.

Pour les modifications d'interface, exécutez bun run e2e:verify, inspectez scripts/cdp/artifacts/result.json et examinez les captures d'écran générées.

Les fichiers générés ne doivent pas être modifiés à la main. En particulier, extension/manifest.json et extension/shared/channel-config.js proviennent des sources du manifeste et de l'empaquetage. Le CI vérifie qu'ils ne dérivent pas.

Lisez CONTRIBUTING.md avant de modifier le code.

Documentation

• CLAUDE.md : structure du projet, conventions et posture actuelle
• SECURITY.md : politique de sécurité et signalement
• docs/security/THREAT-MODEL.md : frontières de confiance et risques résiduels
• docs/security/LIFECYCLE-CONTRACT.md : comportement en cas d'interruption et limites de récupération
• docs/security/RED-TEAM-RESULTS.md : couverture red team
• docs/store/ : empaquetage pour le store, permissions, confidentialité et notes de relecture
• scripts/cdp/GALLERY.md : états E2E et visuels

Les notes de conception sous docs/design/ sont des propositions à un instant donné. Elles expliquent les décisions passées et les travaux planifiés. Elles ne remplacent pas le code actuel.

Dépendances et licence

Les dépendances d'exécution sont intégrées (vendored) sous extension/vendor/. Leur code source, version, licence et enregistrements d'intégrité se trouvent dans les fichiers SOURCE.txt adjacents et dans extension/vendor/vendor.lock.json.

peerd est distribué sous la licence Apache 2.0. Les composants intégrés conservent leurs propres licences. CheerpX est un runtime propriétaire fourni par Leaning Technologies et n'est pas couvert par la licence Apache de peerd.