Buzz Mesh: जब समुदाय मॉडल चलाता है

कुछ सप्ताह पहले मैंने हमारे आसपास बेकार पड़ी कंप्यूटिंग क्षमता के बारे में लिखा था। विचार एक compute smart grid जैसा था: लोग, टीमें या क्षेत्रीय समुदाय अपनी खाली क्षमता स्वेच्छा से उपलब्ध कराएँ, दूसरे उसका उपयोग करें, और हर AI अनुरोध उन्हीं बड़े प्रदाताओं के data center में न पहुँचे।

तब यह मुख्यतः एक architecture idea था। अब Buzz दिखाता है कि इसका पहला ठोस हिस्सा कैसा हो सकता है। यह इंसानों और AI agents के साझा workspace को Nostr identities तथा समुदाय के compute pool से जोड़ता है। एक सदस्य local model उपलब्ध कराता है और दूसरे सदस्यों के agents उसे उपयोग करते हैं। आगे चलकर कई devices ऐसे model के अलग हिस्से भी रख सकते हैं जो किसी एक मशीन में न समाए।

यह हमारी पुरानी कल्पना के बहुत करीब है। लेकिन Buzz न तो वैश्विक AI supercomputer है, न ही खाली RAM जादुई shared memory बन जाती है। यह पहले भरोसे पर आधारित एक छोटी cell बनाता है। शायद यही समझदार शुरुआत है।

Buzz वास्तव में क्या है

Buzz, Jack Dorsey के नेतृत्व वाली Square की कंपनी Block का open-source project है। इसे केवल “Jack Dorsey का नया app” कहना सही नहीं होगा। इसे Block project के रूप में विकसित किया जाता है और सार्वजनिक code GitHub पर Apache 2.0 license के तहत उपलब्ध है।

पहली नज़र में यह Slack, GitHub और agent platform का मिश्रण लगता है। इंसान और AI agents एक ही channels में काम करते हैं, tasks पर चर्चा करते हैं, code संभालते हैं और workflows चलाते हैं। हर agent को अलग cryptographic identity और सीमित permissions मिलती हैं। इससे उस व्यक्ति को, जिसने action अधिकृत किया, उस agent से अलग पहचाना जा सकता है जिसने उसे किया।

यह केवल cosmetic user management नहीं है। कई systems में bot साझा service account या अत्यधिक शक्तिशाली API key उपयोग करता है। बाद में पता रहता है कि “automation” ने कुछ किया, पर यह नहीं कि किस instance ने किस निर्देश पर किया। Buzz authorization और authorship को अलग दिखाना चाहता है।

Workspace को self-host किया जा सकता है। प्रकाशित architecture में Buzz Relay, events और search के लिए PostgreSQL, Pub/Sub और presence के लिए Redis तथा media के लिए S3-compatible storage हैं। संचालन की वास्तविकता छिपाने से decentralization अधिक विश्वसनीय नहीं होता।

Nostr इसकी नींव है

Nostr का अर्थ Notes and Other Stuff Transmitted by Relays है। Users cryptographic key pair रखते हैं, events sign करते हैं और उन्हें relays पर publish करते हैं। Clients एक या अधिक relays के माध्यम से आवश्यक events subscribe करते हैं।

Event में sender की public identity, timestamp, type, content, references और signature होते हैं। Private key user के पास रहती है; public key identity और verification के लिए है। Nostr secp256k1 पर Schnorr signatures उपयोग करता है, वही elliptic curve जो Bitcoin में केंद्रीय है।

Signed log, blockchain नहीं

Nostr blockchain नहीं है। इसमें mining, global consensus या ऐसी single chain नहीं है जिसका हर relay इंतजार करे। Relay अपने rules के अनुसार events स्वीकार और store करता है और clients को देता है। दूसरे relays पर वही या अलग events हो सकते हैं।

Buzz इस model को messages, reactions, agent tasks, workflow steps और Git events के लिए उपयोग करता है। Community में relay केंद्रीय source रहता है: membership जाँचता, events बाँटता और state रखता है। Protocol identity और formats को portable बनाता है, लेकिन operator, database, backups, retention rules या failure risk को खत्म नहीं करता।

Signature साबित करता है कि किसी key ने event sign किया, यह नहीं कि relay उसे हमेशा देगा। Self-hosting में backups, exports, monitoring और key management जरूरी हैं। खोई private key साधारण password नहीं जिसे administrator reset कर सके; चोरी हुई key attacker को वैध signature वाली identity देती है।

Bitcoin से संबंध

Nostr सांस्कृतिक और तकनीकी रूप से Bitcoin समुदाय के करीब है। NIP-57 Lightning Zaps परिभाषित करता है, जिनसे clients लोगों या events को satoshi भेजते हैं और payment receipts को events के रूप में दिखाते हैं।

फिर भी Bitcoin अनिवार्य नहीं है। Nostr blockchain या coin के बिना चलता है। Buzz Shared Compute भी अभी ऐसा खुला बाजार नहीं जहाँ अनजान computers हर token पर satoshi कमाएँ। Capacity समुदाय में स्वेच्छा से साझा होती है। Lightning भविष्य में compensation या quotas में मदद कर सकता है, लेकिन बिजली, wear और operations का आर्थिक उत्तर अभी नहीं है।

Shared Compute कैसे काम करता है

Buzz Mesh community membership को compute pool access से जोड़ता है। सदस्य sharing चालू करता है, hardware के अनुकूल model चुनता है और दूसरों को inference देता है। Agent बाहरी AI service की API key के बिना “Buzz shared compute” को provider की तरह चुन सकता है।

Relay trust और coordination layer है। वह members तथा models देने वाले nodes जानता है। असली request machines के बीच सीधे और encrypted जाती है। Prompt Buzz server से नहीं गुजरता, पर requester के device से निकलकर दूसरे सदस्य की मशीन पर पहुँचता है।

Transport encryption रास्ते को बचाता है, endpoint को अंधा नहीं करता। दूसरे का hardware उपयोग करने पर उसके operator पर भरोसा जरूरी है। Mesh vision साफ कहता है: community उतनी ही private है जितने उसके members भरोसेमंद हैं।

Remote inference और distributed inference अलग हैं

सरल स्थिति में पूरा model एक शक्तिशाली workstation पर चलता है और अन्य devices requests भेजते हैं। Network पर मुख्यतः prompts, tokens और protocol overhead जाते हैं; calculation एक मशीन पर रहता है।

कठिन स्थिति में model कई computers में विभाजित होता है। हर node कुछ weights या calculation रखता है और token generation के दौरान intermediate results लगातार भेजता है। Bandwidth, latency, topology और failures सीधे speed निर्धारित करते हैं।

Buzz दोनों दिशाएँ बताता है। Public development guide app से local या remote inference तक वास्तविक path दिखाता है। कई devices पर एक model बाँटना Mesh vision है: संभव लक्ष्य, लेकिन अभी arbitrarily scalable production platform नहीं। कुछ functions feature flag के पीछे हैं।

Mac Studio cluster नेटवर्क समस्या दिखाता है

NetworkChuck चार Mac Studio जोड़ता है, हर एक में 512 GB Unified Memory, यानी GPU-accessible 2 TB local cluster। लेकिन पाँच Macs वाले पिछले प्रयोग में उसकी तुलना के अनुसार inference 91 प्रतिशत धीमा हुआ।

Video pipeline और tensor parallelism का अंतर बताता है। Pipeline में एक Mac layers process कर अगली मशीन को result देता है। बड़ा model fit होता है, पर nodes प्रतीक्षा करते हैं। Tensor में सभी Macs एक layer पर साथ काम करते और बार-बार छोटे data exchange करते हैं। Latency निर्णायक बनती है।

NetworkChuck लगभग 300 से 3 microseconds तक कमी दिखाता है। Llama 70B में output pipeline के करीब 5 tokens per second से tensor और RDMA के करीब 16 तक पहुँचता है। पूरा cluster 100 गुना तेज नहीं होता; connection latency उस factor से घटती है, model throughput केवल तीन गुना से थोड़ा अधिक बढ़ता है।

macOS 26.2 से Thunderbolt 5 वाले Apple silicon Macs RDMA over Thunderbolt support करते हैं। RDMA registered memory regions के बीच कम overhead से data ले जाता है; Apple ने इसे MLX Distributed और JACCL के साथ समन्वित किया।

Physics फिर भी रहती है। Apple minimum latency के लिए fully meshed topology सुझाता है: दो Macs के लिए एक link, तीन के लिए तीन cables और चार के लिए छह। पाँच nodes से port limits ring को जरूरी बना सकती हैं, जहाँ data intermediate nodes से गुजरता है। Current implementation अधिकतम दस UC Queue Pairs और two-sided send/receive तक सीमित है।

Community internet पर अलग machines में कई complete models दे सकती है। एक model को Zurich, Berlin और New York में विभाजित करना अलग समस्या है। हर hop token generation धीमा करता है, और एक slow node पूरी pipeline रोक सकता है।

RAM सीधे नहीं जुड़ती

Model weights, KV cache, runtime data और लंबे contexts की reserve को कहीं रहना पड़ता है। दो सदस्य 64 GB RAM में अलग models चलाते हैं तो दो inference nodes बनते हैं, 128 GB shared memory वाली एक machine नहीं। केवल real model sharding सीमा बदलता है, बदले में communication, complexity और failure risk बढ़ते हैं।

2026 में DRAM market भी कठिन है। TrendForce तीसरी तिमाही को बहुत tight बताता है और AI server demand record prices बनाए रखती है। Shared Compute existing hardware को अधिक उपयोगी बनाता है, लेकिन ज्यादा RAM वाले नए local systems सस्ते नहीं करता।

पहले से मौजूद तीन workstations साझा करना समझदारी हो सकता है। केवल cloud bill बचाने के लिए तीन महंगी machines खरीदना खराब investment हो सकता है। बिजली, cooling, parts, internet, administration और outage risk नहीं मिटते।

Buzz Mesh में वास्तव में क्या अच्छा है

Buzz की ताकत नई distributed-inference technique नहीं, बल्कि existing components को जोड़ना है। Community के पास members, identities और permissions हैं; agents और local models पहले से चलते हैं। Buzz sharing को product setting और compute को agent का सामान्य provider बनाता है।

Trust zone भी उचित है: लाखों अनजान पक्षों के बजाय पहले से साथ काम करने वाले लोग। Agency, small business, research project या developer group के लिए यह अधिक realistic है।

Model independence भी लाभ है। Open-weight models में weights, configuration और runtime नियंत्रित रहते हैं, लेकिन “model का मालिक होना” shorthand है। Open weights public domain नहीं; licenses use, redistribution या commercial operation सीमित कर सकती हैं। Sovereignty का अर्थ weights उपलब्ध होना, license समझना, runtime नियंत्रित करना, data export करना और original provider के बिना चलना है।

जो अभी आश्वस्त नहीं करता

Compensation अधूरा है। Small team में voluntary sharing चल सकती है; एक व्यक्ति दस users के लिए हमेशा hardware और बिजली दे तो limits, priorities, metrics और fair accounting चाहिए। Nostr और Lightning components देते हैं, पूरा economic model नहीं।

Operations भी प्रश्न है: models और licenses कौन update और verify करेगा, sensitive prompts कौन देखेगा, overload, sleep, यात्रा में notebook या उत्तर के बीच node गायब होने पर क्या होगा। Cloud महँगा है, पर बहुत सा नीरस काम संभालता है।

Buzz arbitrary code नहीं, model requests forward करता है, जो समझदार सीमा है। फिर भी prompts confidential, models manipulated और agents जरूरत से अधिक context भेज सकते हैं। Membership access control है, अच्छे व्यवहार की guarantee नहीं। Companies को classification, logging, quotas, model approvals, endpoint hardening और local-only jobs के rules भी चाहिए।

Buzz अभी युवा है। Public code, architecture और concrete test path slides से अधिक हैं, लेकिन feature flags, तेज releases और बदलते documents बताते हैं कि system चलायमान है। Non-critical data के experiment ठीक हैं; exit plan बिना core process निर्भर करना नहीं।

वास्तव में क्या लागू हो रहा है

Buzz पुरानी compute smart grid पूरी नहीं बनाता, पर उसका सबसे समझदार पहला layer लागू करता है: existing social trust structure पर सीमित, voluntary compute cell।

Open market, stable credits, hardware attestation, independent verification और हजारों unknown nodes का operating model अभी नहीं है। बदले में स्पष्ट interface और immediate use case है: agent को model चाहिए, member के पास computer है, relay coordinate करता है और machines calculate करती हैं।

यदि छोटा circle reliably चलता है तो quotas, credits, Lightning payments, regional federation और verifiable jobs बाद में आ सकते हैं। पहले छोटे circle को भरोसेमंद होना होगा।

इस लेख का आधार और सीमाएँ

मैंने Buzz Mesh को multi-computer setup में स्वयं test नहीं किया। आकलन public code, architecture, Mesh vision, development guide, Nostr specifications और Apple RDMA documentation पर आधारित है, जिन्हें 21 अगस्त 2026 को जाँचा गया। Stability, throughput और real load के दावे मेरे measurements नहीं हैं।

फिर भी Buzz distributed compute idea को उपयोगी product में बदलने का सबसे स्पष्ट उदाहरण है। अभी छोटा, शुरुआती और बिना सुलझी economy, लेकिन अब केवल theory नहीं।

अगली बार तक,
Joe