पहला वेब-नेटिव AI एजेंट हार्नेस

peerd पहला सामान्य-उद्देश्य एजेंट रनटाइम है जो सीधे ब्राउज़र प्रिमिटिव पर बनाया गया है: Workers, origins, sandboxing, OPFS, WASM/WASI, WebRTC, WebAuthn, और WebExtensions। यह पूरी तरह से Chrome और Firefox के अंदर चलता है, आपके टैब, साइन-इन किए गए सत्रों, वेब ऐप्स और स्थानीय कंप्यूट के साथ।

जबकि एजेंट प्लेटफ़ॉर्म ब्राउज़र को हार्नेस में खींचने की कोशिश कर रहे हैं, peerd हार्नेस को ब्राउज़र में खींचता है।

वास्तविक inference के लिए आप एक समर्थित होस्टेड मॉडल प्रदाता, localhost का उपयोग करने वाला एक स्थानीय मॉडल चुन सकते हैं, या स्थानीय WebGPU मॉडल के लिए प्रारंभिक समर्थन देख सकते हैं (हम WebNN पर भी नज़र रख रहे हैं)।

कोई peerd खाता, होस्टेड ब्राउज़र, या टूल-सर्वर कनेक्शन आवश्यक नहीं है। वर्तमान बिल्ड peerd को कोई उत्पाद टेलीमेट्री नहीं भेजते हैं।

Install · peerd.ai · Architecture · Security

विशेषताएँ

• उस ब्राउज़र में काम करता है जिसे आप पहले से उपयोग करते हैं। एजेंट आपके टैब, वेब ऐप्स, साइन-इन किए गए सत्रों और पेज सामग्री को पढ़ और चला सकता है।
• पुन: प्रयोज्य साइट क्लाइंट बनाता है। वेब अभिनेता किसी साइट को एक बार सीख सकता है और बाद के कार्यों पर उस क्लाइंट का फिर से उपयोग कर सकता है।
• ब्राउज़र सीमाओं के अंदर कोड चलाता है। स्क्रिप्ट, सीलबंद JavaScript Notebooks, संकलित WASI टूल, ब्राउज़र Apps, और Linux WebVMs एजेंट को आपके होस्ट ऑपरेटिंग सिस्टम तक पहुँच के बिना स्थानीय कंप्यूट देते हैं।
• अलग-अलग अभिनेताओं को प्रत्यायोजित करता है। प्रत्येक पेज और कंप्यूट वातावरण को उस वातावरण के लिए स्कोप किए गए टूल के साथ अपना स्वयं का keyless अभिनेता मिलता है।
• उपयोगी संदर्भ रखता है। सत्र, मेमोरी, कौशल, लक्ष्य, समीक्षा और चेकपॉइंट एक्सटेंशन में रहते हैं।
• आपके द्वारा चुने गए मॉडल का उपयोग करता है। लाइव प्रदाता सूची registry.js में परिभाषित है, जिसमें BYOK क्लाउड एडेप्टर और keyless स्थानीय विकल्प शामिल हैं।
• ब्राउज़रों को सीधे जोड़ता है। पूर्वावलोकन बिल्ड साइन किए गए पहचान, ब्राउज़र-से-ब्राउज़र खोज, dwapps, और WebRTC पर एजेंट-से-एजेंट संचार जोड़ते हैं; स्टोर पैकेज इसे पूरी तरह से हटा देते हैं।

ब्राउज़र क्यों

स्थानीय एजेंट आपके पूरे कंप्यूटर तक पहुँच सकते हैं। दूरस्थ एजेंट किसी और के कंप्यूटर में रहते हैं। ब्राउज़र विकल्प है: तीन दशकों से कठोर सुरक्षा सीमाओं के पीछे स्थानीय क्षमता।

peerd उन सीमाओं का उपयोग करता है। पेज का काम अलग-अलग अभिनेताओं को जाता है जिनके पास केवल उस टैब या वातावरण के लिए टूल होते हैं। क्रेडेंशियल, नेटवर्क नियम, पुष्टिकरण और ऑडिट एक्सटेंशन के साथ रहते हैं। इसका defense-in-depth डिज़ाइन मानता है कि असुरक्षित सामग्री अंततः फ़िल्टर से निकल जाएगी।

ब्राउज़र समर्थन

peerd Chromium और Firefox का समर्थन करता है। Firefox समर्पित workers में अभिनेताओं को चलाता है और JavaScript कंप्यूट के लिए दृश्यमान Notebooks का उपयोग करता है। Chrome के offscreen document host की आवश्यकता वाली सुविधाएँ उपयोग से पहले Firefox नियंत्रणों और मॉडल टूल से हटा दी जाती हैं। Firefox पूर्वावलोकन बिल्ड dweb को तब तक छोड़ देते हैं जब तक Firefox के पास mesh host न हो।

Apps और WebVMs Chrome पर चलते हैं। Apps के पास कोई ambient नेटवर्क पहुँच नहीं है। दूरस्थ संसाधन, fetches, WebRTC, फ़ॉर्म और बाहरी दस्तावेज़ नेविगेशन अवरुद्ध हैं। बाहरी HTTP और HTTPS लिंक के लिए उपयोगकर्ता पुष्टिकरण की आवश्यकता होती है।

ठोस ब्राउज़र क्षमता अंतराल, उनके upstream मुद्दे, और प्रत्येक गार्ड को हटाने के लिए आवश्यक परीक्षण docs/BROWSER-COMPATIBILITY.md में ट्रैक किए जाते हैं।

कोड वर्तमान व्यवहार के लिए सत्य का स्रोत है। CLAUDE.md से शुरू करें, फिर extension/ के अंतर्गत प्रासंगिक मॉड्यूल पढ़ें।

सुरक्षा मॉडल

peerd ब्राउज़र अलगाव, संकीर्ण टूल एक्सपोज़र, service-worker नीति गेट और स्पष्ट egress नियंत्रण का उपयोग करता है। मुख्य एजेंट पर्यावरण कार्य को keyless अभिनेताओं को सौंपता है। Chrome और Firefox पर, गैर-ऑर्केस्ट्रेटर एजेंट लूप अलग समर्पित worker heaps में चलते हैं। यदि ब्राउज़र उस सीमा को साबित नहीं कर सकता है, तो अभिनेता अनुरोध नहीं चलता है और अपने लक्ष्य पर कोई कार्य नहीं करता है।

नेटवर्क व्यवहार ऑपरेशन पर निर्भर करता है। मॉडल कॉल, वेब रीड, रनटाइम एसेट लोड, सैंडबॉक्स ट्रैफ़िक और पूर्वावलोकन dweb ट्रैफ़िक विभिन्न स्कोप किए गए पथ और नीतियों का उपयोग करते हैं। वर्तमान सीमाओं और ज्ञात सीमाओं के लिए SECURITY.md और threat model देखें।

इंस्टॉल करें

स्रोत से Chrome

1. रिपॉजिटरी को क्लोन करें।
2. chrome://extensions खोलें।
3. डेवलपर मोड सक्षम करें।
4. Load unpacked चुनें और extension/ निर्देशिका चुनें।

स्रोत परिवर्तनों के बाद chrome://extensions से एक्सटेंशन को पुनः लोड करें।

स्रोत से Firefox

Firefox को Firefox-विशिष्ट पैकेज की आवश्यकता होती है। चेक-इन किए गए Chrome विकास manifest को लोड न करें। manifests/ के अंतर्गत चैनल पैच में घोषित न्यूनतम से ऊपर या उसके बराबर Firefox संस्करण का उपयोग करें। वह फ़्लोर ब्राउज़र टूल द्वारा उपयोग किए जाने वाले document-bound scripting समर्थन को ट्रैक करता है।

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

about:debugging#/runtime/this-firefox खोलें, Load Temporary Add-on चुनें, और artifacts/peerd-preview-firefox.xpi चुनें। अस्थायी add-ons को Firefox पुनः आरंभ होने के बाद फिर से लोड किया जाना चाहिए। ब्राउज़र और चैनल परिवर्तन पैकेजिंग स्क्रिप्ट द्वारा परिभाषित किए जाते हैं।

रिलीज़ पैकेज

वर्तमान artifacts के लिए GitHub Releases देखें। स्टोर और पूर्वावलोकन बिल्ड भिन्न होते हैं। स्टोर बिल्ड dweb को छोड़ देते हैं। पूर्वावलोकन बिल्ड इसे शामिल करते हैं और अतिरिक्त स्वचालन सुविधाओं को सक्षम कर सकते हैं। पैकेजिंग कोड प्रत्येक ब्राउज़र और चैनल के लिए प्राधिकरण है।

पहला रन

1. ब्राउज़र टूलबार से peerd खोलें।
2. स्थानीय vault बनाएं और अनलॉक करें। Passphrase अनलॉक हमेशा उपलब्ध है। Passkey अनलॉक ब्राउज़र और डिवाइस में WebAuthn PRF समर्थन पर निर्भर करता है।
3. संक्षिप्त प्रोफ़ाइल onboarding पूरा करें।
4. Settings खोलें, फिर एक प्रदाता कुंजी जोड़ें या एक समर्थित स्थानीय प्रदाता चुनें।
5. एक मॉडल चुनें और चैट शुरू करें।

केवल vault रहस्य और संरक्षित सुरक्षा रिकॉर्ड vault एन्क्रिप्शन सीमा द्वारा कवर किए जाते हैं। अन्य स्थानीय एक्सटेंशन स्थिति सुरक्षा दस्तावेज़ीकरण में भंडारण नियमों का पालन करती है।

आर्किटेक्चर

एक्सटेंशन में पाँच मुख्य मॉड्यूल हैं। प्रत्येक मॉड्यूल अपने index.js के माध्यम से अपनी सार्वजनिक API प्रदर्शित करता है।

एक्सटेंशन चेसिस background/, offscreen/, sidepanel/, engine-tabs/, permissions/, shared/, और संबंधित समर्थन निर्देशिकाओं में रहता है। होस्ट प्लेसमेंट और cold-worker नियम docs/EXTENSION-HOSTS.md में प्रलेखित हैं।

विकास

स्रोत एक्सटेंशन ES मॉड्यूल के साथ वेनिला JavaScript है और अनपैक्ड लोड होने पर सीधे चलता है। कोई विकास bundler, transpiler, watcher, या उत्पन्न रनटाइम ट्री नहीं है। रिलीज़ पैकेजिंग केवल अपनी disposable स्टेजिंग कॉपी पर Bun का उपयोग करती है ताकि स्थिर service-worker और Chrome offscreen cold graphs में authored मॉड्यूल से whitespace/comments हटाए जा सकें। यह मॉड्यूल सीमाओं, बाइंडिंग नामों, lazy imports और प्रत्येक vendored बाइट को संरक्षित करता है। जब एक पठनीय डायग्नोस्टिक artifact उपयोगी हो तो bun run package -- ... को --no-minify पास करें।

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

तीन परीक्षण सतहें हैं:

• शुद्ध तर्क के लिए Bun परीक्षण।
• एक्सटेंशन और ब्राउज़र एकीकरण के लिए इन-ब्राउज़र परीक्षण। वे Chrome के तहत headless और, sharded, स्थापित Firefox Store पैकेज के विरुद्ध Gecko के तहत चलते हैं। प्रत्येक लेन हर पंजीकृत परीक्षण निष्पादित करता है; कुल थोड़े भिन्न होते हैं क्योंकि कुछ परीक्षण केवल वहाँ पंजीकृत होते हैं जहाँ एक लाइव service worker उत्तर देता है।
• पूर्ण प्रवाह के लिए लाइव Chrome E2E और दृश्य सत्यापन।

उनके साथ, tests/red-team/ में red-team सुइट threat model से प्रत्येक adversary को वास्तविक रक्षा कोड के विरुद्ध चलाता है और रिकॉर्ड करता है कि क्या हर शत्रुतापूर्ण जांच अवरुद्ध की गई थी। इसका मैट्रिक्स docs/security/RED-TEAM-RESULTS.md है।

प्रत्येक लेन अपनी गिनती ऊपर एक बैज के रूप में प्रकाशित करता है। badges/ के अंतर्गत बैज JSON उस CI कार्य द्वारा उत्पन्न होता है जो लेन चलाता है और फिर diff किया जाता है, इसलिए इस पृष्ठ पर एक गिनती हमेशा एक ऐसे रन से साक्ष्य है जो हुआ था, न कि कोई संख्या जो किसी ने टाइप की थी। bun run gen:badge:functional, bun run gen:badge:red-team, bun run gen:badge:inbrowser, bun run gen:badge:gecko (Firefox और geckodriver की आवश्यकता है), या bun run gen:badge:e2e के साथ एक को पुनः उत्पन्न करें, और परिणाम commit करें। bun run check:badges ब्राउज़र लॉन्च किए बिना endpoints की अच्छी तरह से गठित जाँच करता है।

UI परिवर्तनों के लिए, bun run e2e:verify चलाएं, scripts/cdp/artifacts/result.json का निरीक्षण करें, और उत्पन्न स्क्रीनशॉट का निरीक्षण करें।

उत्पन्न फ़ाइलों को हाथ से संपादित नहीं किया जाना चाहिए। विशेष रूप से, extension/manifest.json और extension/shared/channel-config.js manifest और पैकेजिंग स्रोतों से आते हैं। CI उन्हें drift के लिए जाँचता है।

कोड बदलने से पहले CONTRIBUTING.md पढ़ें।

दस्तावेज़ीकरण

• CLAUDE.md: परियोजना संरचना, परंपराएँ और वर्तमान स्थिति
• SECURITY.md: सुरक्षा नीति और रिपोर्टिंग
• docs/security/THREAT-MODEL.md: विश्वास सीमाएँ और शेष जोखिम
• docs/security/LIFECYCLE-CONTRACT.md: रुकावट व्यवहार और पुनर्प्राप्ति सीमाएँ
• docs/security/RED-TEAM-RESULTS.md: red-team कवरेज
• docs/APP-ACTORS.md: manifest-परिभाषित App अभिनेता, लाइव सिमेंटिक एडेप्टर और in-tab co-pilot UX
• docs/DWAPP-BUNDLE.md: संपीड़ित dwapp परिवहन, डिकोड किए गए कार्यशील ट्री और बाइनरी एसेट
• docs/store/: स्टोर पैकेजिंग, अनुमतियाँ, गोपनीयता और समीक्षक नोट
• scripts/cdp/states.mjs: E2E और दृश्य स्थितियाँ

निर्भरताएँ और लाइसेंस

शिप किए गए एक्सटेंशन में कोई npm रनटाइम निर्भरता नहीं है। package.json कोई घोषित नहीं करता है, और पैकेजिंग कभी भी staged artifact में node_modules पथ को हल नहीं करती है, इसलिए विकास-टूल ट्री स्थापित ब्राउज़र तक नहीं पहुँच सकता है। तृतीय-पक्ष रनटाइम कोड इसके बजाय extension/vendor/ के अंतर्गत vendored है। इसका स्रोत, संस्करण और लाइसेंस आसन्न SOURCE.txt फ़ाइलों में रहते हैं, और प्रत्येक vendored बाइट extension/vendor/vendor.lock.json में SHA-256 द्वारा पिन किया जाता है, जिसे bun run check:vendor CI और preflight में सत्यापित करता है।

दो और supply-chain स्थितियाँ ऊपर अपने स्वयं के बैज रखती हैं, दोनों bun run gen:dev द्वारा पुनः उत्पन्न और CI में drift-जाँच की जाती हैं। प्रत्येक तृतीय-पक्ष GitHub Action पूर्ण commit SHA पर चलता है, जो check:actions द्वारा गेट किया जाता है: एक प्रमुख टैग एक परिवर्तनशील ref है जिसे इसका प्रकाशक स्थानांतरित कर सकता है, जिसका अर्थ इस checkout को रखने वाले कार्य में मनमाना कोड होगा, और रिलीज़ वर्कफ़्लो में, हस्ताक्षर रहस्य। नई हल की गई निर्भरताएँ भी lock में प्रवेश करने से पहले एक संगरोध विंडो के बाहर बैठती हैं, जो bunfig.toml में minimumReleaseAge द्वारा निर्धारित होती है, साथ ही इंस्टॉल पर एक मैलवेयर स्कैन भी होता है।

peerd Apache License 2.0 के अंतर्गत लाइसेंस प्राप्त है। Vendored घटक अपने स्वयं के लाइसेंस बनाए रखते हैं। CheerpX Leaning Technologies द्वारा प्रदान किया गया एक स्वामित्व रनटाइम है और peerd के Apache लाइसेंस द्वारा कवर नहीं है।