- व्यक्तिगत portfolio site से IRC-आधारित AI agent जोड़ा गया है, ताकि विज़िटर वास्तविक GitHub repository code analysis के आधार पर सवालों के जवाब पा सकें
- यह सिर्फ़ résumé summary देने वाला chatbot नहीं, बल्कि repository clone करना, test count निकालना, और code verification करने वाला execution-capable agent है
- सिस्टम को public nullclaw और private ironclaw दो agents में बाँटा गया है, जो Tailscale network के जरिए सुरक्षित रूप से संवाद करते हैं
- IRC protocol को transport layer के रूप में अपनाकर self-hosting, standardization, और low cost एक साथ हासिल किए गए हैं, और Haiku 4.5 व Sonnet 4.6 models को भूमिकानुसार अलग रखकर लागत को रोज़ $2 तक सीमित किया गया है
- पूरा सिस्टम 10MB से कम binaries और 5MB से कम memory में चलता है, और इसे security, cost, और transparency तीनों सुनिश्चित करने वाले lightweight AI infrastructure के उदाहरण के रूप में पेश किया गया है
डिजिटल doorman बनाना
- $7/माह VPS पर AI agent तैनात किया गया है और transport layer के रूप में निजी IRC server का उपयोग करते हुए इसे GitHub repositories से जोड़ा गया है
- विज़िटर portfolio site पर AI से सवाल पूछ सकते हैं और वास्तविक code के आधार पर जवाब पा सकते हैं
- यह सिर्फ़ résumé summary chatbot नहीं, बल्कि code analysis के जरिए ठोस जवाब देने वाली व्यवस्था है
"résumé पूछने वाले chatbot" की सीमाएँ
- अधिकांश portfolio chatbots सिर्फ़ résumé content को model में inject करके उसे दोबारा लिखने तक सीमित रहते हैं
- यह तरीका कोई नई जानकारी नहीं देता और सिर्फ़ औपचारिक बातचीत बनकर रह जाता है
- “test coverage को कैसे manage करते हैं?” जैसे सवालों के लिए repository clone करके test count निकालने जैसे ठोस जवाब चाहिए
- इसी वजह से सीधे code access और analysis करने वाली infrastructure बनाई गई
सिस्टम आर्किटेक्चर
- यह दो agents, दो servers, और दो security boundaries से बना है
- nullclaw: public doorman, 678KB Zig binary, लगभग 1MB RAM उपयोग
- विज़िटर का स्वागत करता है, project से जुड़े सवालों के जवाब देता है, GitHub repository clone करता है और code-आधारित verification करता है
- ironclaw: private backend agent, अलग सिस्टम पर चलता है
- email, schedule, और personal context तक पहुँच रखता है
- nullclaw से जटिल requests को #backoffice IRC channel के जरिए प्राप्त करता है
- दोनों सिस्टम Tailscale के जरिए जुड़े हैं, और public server को personal data तक पहुँच नहीं है
IRC क्यों चुना गया
- सौंदर्यगत एकरूपता: portfolio site terminal UI पर आधारित है, इसलिए IRC client स्वाभाविक लगता है
- पूरी तरह self-hosted: Ergo IRC server, gamja web client, और nullclaw सभी अपनी infrastructure पर चलते हैं
- सरल और standardized protocol: 30 साल पुराना IRC vendor lock-in से मुक्त है और API बदलाव का जोखिम नहीं है
- वही agent web client के साथ-साथ irssi terminal client में भी एक जैसा काम करता है
model चयन और डिज़ाइन
- बड़े models का उपयोग अलाभकारी है, इसलिए भूमिका के अनुसार अलग-अलग models चुने गए हैं
-
Haiku 4.5**: बातचीत और सरल queries के लिए,** बहुत कम latency वाला response
- Sonnet 4.6: सिर्फ़ code analysis और जटिल reasoning के समय उपयोग
- cost ceiling: रोज़ $2, महीने में $30 तक सीमित
- malicious use या अत्यधिक बातचीत से लागत बढ़ने से बचाव
- layered reasoning structure के जरिए speed और cost efficiency दोनों हासिल किए गए
security डिज़ाइन
- SSH: root login बंद, सिर्फ़ key authentication की अनुमति, non-standard port का उपयोग
- firewall: सिर्फ़ SSH, IRC(TLS), और HTTPS(WebSocket) खुले
- Cloudflare proxy: TLS termination, rate limiting, और bot filtering करता है
- agent sandbox: सिर्फ़ read-only tools की अनुमति, प्रति घंटे 10 actions की सीमा
- cost control: रोज़ $2, महीने का $30 hard cap
- audit logs और automatic updates सक्षम
- attack surface minimization: सिर्फ़ ergo और nullclaw दो services चलती हैं, web content सीधे serve नहीं किया जाता
- compromise होने पर नुकसान की सीमा $2/दिन वाले IRC bot तक सीमित रहती है
communication stack की संरचना
- सभी components छोटे, self-hosted, और replaceable रूप में हैं
- Ergo: IRC server, single Go binary, 2.7MB RAM
- gamja: web IRC client, 152KB static page, Cloudflare के पीछे serve किया जाता है
- nullclaw: AI agent runtime, 4MB Zig binary, लगभग 1MB memory उपयोग
- पूरा सिस्टम 10MB से कम binaries और 5MB से कम idle memory में चलता है
- सबसे सस्ते VPS tier पर भी इसे आराम से चलाया जा सकता है
nully (public agent) वास्तव में क्या करता है
- programming language पहचानना: preloaded context और repository verification के जरिए पुष्टि करता है
- test structure analysis: repository clone करके test files सीधे पढ़ता है और नतीजे बताता है
- project explanation: उदाहरण के लिए Fracture project का विवरण code के आधार पर देता है
- contact guidance: सिर्फ़ सही contact information देता है, कोई झूठी जानकारी नहीं बनाता
- meeting scheduling requests: Google A2A protocol के जरिए ironclaw को भेजता है और structured result लौटाता है
- विज़िटर को backend handoff का पता भी नहीं चलता
A2A implementation
- Google A2A protocol(v0.3.0) समर्थित है और JSON-RPC आधारित task status management किया जाता है
a2a_call tool remote agent को message भेजता है और task status (completed/failed/in progress) को parse करता है- HTTPS अनिवार्य है, लेकिन Tailscale internal network में debugging की सुविधा के लिए HTTP की अनुमति है
-
ironclaw पक्ष की संरचना
- nullclaw instance अपनी API key रखने के बजाय ironclaw के LLM gateway को proxy के रूप में उपयोग करता है
- सिर्फ़ एक API key और एक billing relationship बनाए रखे जाते हैं
- ironclaw सभी inference requests को संभालता है और लागत वहन करता है
handoff security
- A2A endpoint में prompt injection risk मौजूद है, इसलिए सख्त सीमाएँ लगाई गई हैं
- ironclaw को भेजी जाने वाली requests सिर्फ़ schedule, contact, availability से संबंधित हो सकती हैं
- arbitrary commands अस्वीकार किए जाते हैं
- ironclaw का A2A endpoint Tailscale-only firewall से सुरक्षित है
- दोनों agents monitoring mode और limited command allowlist के साथ चलते हैं
- nully तय करता है कि request को escalate करना है या नहीं, ताकि अंधाधुंध command execution न हो
निर्माण प्रक्रिया से मिली सीख
- model selection सिस्टम डिज़ाइन का हिस्सा है और इसका सीधा असर cost, latency, और experience पर पड़ता है
- agent से ज़्यादा समय communication, security, और infrastructure setup में लगा
- IRC की सरलता और openness इसे AI agent transport layer के लिए आदर्श बनाती है
- nullclaw–ironclaw separation security model की कुंजी है
- A2A protocol और IRC log channels का संयोजन structured communication और real-time visibility दोनों देता है
- credentials duplication से बचाव: ironclaw के gateway को proxy की तरह इस्तेमाल कर single API key और single billing relationship बनाए रखा गया
इसे कैसे आज़माएँ
- georgelarson.me/chat पर जाएँ या homepage terminal में
irc टाइप करें
- IRC client उपयोग करते समय:
irc.georgelarson.me, port 6697(TLS), channel #lobby
- nully उपलब्ध है और विज़िटर्स से real-time बातचीत कर सकता है
1 टिप्पणियां
Hacker News की राय
अगर OpenClaw एजेंट को, जिसे ईमेल और निजी डेटा तक पहुंच है, compromise कर लिया जाए, तो नुकसान का दायरा बहुत बड़ा हो सकता है
यह सिर्फ IRC bot के स्तर की बात नहीं है; attacker पासवर्ड reset करके API limits हटा सकता है, या यहां तक कि इसे illegal content sharing hub के रूप में भी दुरुपयोग कर सकता है
मैं सोच रहा था कि Haiku/Sonnet ही क्यों चुना गया। OpenRouter पर इससे कहीं सस्ते मॉडल मौजूद हैं
उदाहरण के लिए Haiku 4.5 की कीमत input के लिए प्रति 10 लाख tokens पर $1 और output के लिए $5 है, जबकि MiniMax M2.7 input के लिए $0.30, output के लिए $1.20, और Kimi K2.5 input के लिए $0.45, output के लिए $2.20 के आसपास है
मेरे अनुभव में M2.7 और K2.5 भी Haiku जितना या उससे बेहतर प्रदर्शन करते हैं
मैं भी हाल में एजेंट बनाते समय इसी वजह से Anthropic models का उपयोग कर रहा हूँ। Haiku तब भी अच्छी तरह control में रहता है जब user अजीब requests डालता है, और emotional बातचीत को भी स्थिरता से संभालता है
transport layer के रूप में IRC ठीक है, लेकिन इसमें delivery guarantee नहीं है। अगर connection टूट जाए, तो उस दौरान के messages गायब हो जाते हैं
real-time chat के लिए यह ठीक है, लेकिन अगर agent वास्तविक काम संभाल रहा हो तो at-least-once delivery चाहिए
SSE(Server-Sent Events) बीच का अच्छा विकल्प है। इसमें persistent connection रखा जा सकता है, और retry logic भी जोड़ी जा सकती है
मैंने टोक्यो से ओसाका जाने वाली ट्रेन में इसी तरह के आइडिया वाला एक bot बनाया था
web-support-claw.oncanine.run — यह GitHub repo पढ़कर वेबसाइट के लिए intercom bot बनाने वाला प्रोजेक्ट था
यह visitors के सवालों के जवाब देता था, इसलिए अलग से knowledge base बनाने की ज़रूरत नहीं पड़ती थी
आगे के लिए मैं monitoring के लिए एक Haiku instance रखने की सलाह दूँगा। ntfy से notifications भी मिल सकती हैं
अभी chat room पूरी तरह नियंत्रण से बाहर है
अगर उद्देश्य “interactive resume” है, तो अनिश्चित संख्या में लोगों के साथ interaction ज़रूरी नहीं है
हमारी टीम भी इसी तरह की संरचना इस्तेमाल करती है। FastAPI + SQLite आधारित message board पर 4 agents (sales, social, finance, strategy) आपस में communicate करते हैं
daily budget limit की जगह हम governance layer में cost ceiling manage करते हैं
IRC का pub/sub structure multi-agent communication के लिए अच्छा है, लेकिन हम HTTP polling + deduplication तरीका इस्तेमाल करते हैं। यह कम elegant है, पर agents बार-बार crash हों तब भी recovery आसान रहती है
मैं भी coding agent में IRC को interface के रूप में इस्तेमाल करता हूँ
rooms बदलकर prompts switch करता हूँ, और remote तरीके से project को control करता हूँ
किसी ने कहा था, “public box private data तक पहुंच नहीं रखता”, लेकिन इसे CTF challenge में बदलना मज़ेदार हो सकता है
private box में एक flag छिपा दो, और जो कोई पहुंचकर उसे निकाल लाए उसे 50 डॉलर दे दो
nully का रवैया थोड़ा खुरदरा है, लेकिन मुझे कुल मिलाकर system architecture पसंद आई
मैं भी layered structure इस्तेमाल करता हूँ, और सबसे निचला स्तर Qwen local bot है
मुझे Haiku से Opus तक की escalation logic जानने में दिलचस्पी है
यह आइडिया वाकई बहुत दिलचस्प है। इससे hiring process को automate करने वाला bot बनाने का मन होता है
यह interview के जरिए candidate की प्रवृत्ति समझे, उसके हिसाब से jobs ढूँढे, और apply तक अपने-आप कर दे
अगर company-side bots भी उसी तरह candidates का मूल्यांकन करें, तो दोनों पक्षों की preferences के आधार पर matching संभव हो सकती है
इसे पूरी तरह open source self-hosting के रूप में बनाया जा सकता है, और यह resume की तुलना में कहीं बेहतर signal दे सकता है