Twitter के संस्थापक Jack Dorsey ने टीम चैट, AI एजेंट और Git होस्टिंग को जोड़ने वाला Buzz लॉन्च किया

 (runtimewire.com)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Block ने ओपन-सोर्स वर्कस्पेस Buzz लॉन्च किया है, जो कर्मचारियों, AI एजेंटों, बातचीत और सॉफ्टवेयर repositories को एक ही पहचान व्यवस्था से जोड़ता है, ताकि Slack और GitHub पर निर्भरता घटाई जा सके
  • messages, reactions, workflow steps, code events और approvals को signed Nostr events के रूप में स्टोर किया जाता है, और लोगों व एजेंटों को समान रूप से key pairs, channel membership और audit trails दिए जाते हैं
  • एजेंट बातचीत खोजने से लेकर patches सबमिट करने, code review करने और workflows चलाने तक काम कर सकते हैं, जबकि Goose, Codex और Claude Code harnesses workspace को underlying models से अलग रखते हैं
  • self-hosting और data ownership उपलब्ध है, लेकिन सभी reads/writes एक single central relay से गुजरते हैं, इसलिए availability, backup, security और upgrades की जिम्मेदारी operator की होती है
  • chat, code hosting, automation, search और agent orchestration को एक जगह जोड़ा गया है, लेकिन mobile app और push notifications अभी अधूरे हैं, और adoption rate, pricing व बाहरी ग्राहकों की संख्या सार्वजनिक नहीं की गई है

लोगों और एजेंटों को जोड़ने वाला unified workspace

  • Buzz एक self-hostable open-source workspace है, जो कर्मचारियों, AI एजेंटों, बातचीत और software repositories को एक ही identity system के तहत रखता है
    • Jack Dorsey इसके जरिए Block की Slack और GitHub पर निर्भरता कम करना चाहते हैं
    • Block के public repository में internal relay और agent providers के लिए तैयार अलग internal build का भी documentation है
  • self-hosted Nostr relay के केंद्र में messages, reactions, workflow steps, code events और approvals को cryptographically signed events के रूप में स्टोर किया जाता है
    • कर्मचारियों और एजेंटों, दोनों के पास unique key pairs, channel memberships और audit trails होते हैं
    • shared identity और signed events के कारण एजेंट पारंपरिक chatbots से आगे बढ़कर ऐसे members के रूप में भाग लेते हैं जिनकी accountability track की जा सकती है
  • एजेंट पिछली बातचीत खोज सकते हैं, repositories देख सकते हैं, patches सबमिट कर सकते हैं, code reviews कर सकते हैं, workflows चला सकते हैं, shared canvases edit कर सकते हैं और channels बना सकते हैं
    • एजेंटों के लिए CLI और Goose, Codex व Claude Code harnesses दिए जाते हैं, जिससे underlying models को workspace से अलग रखा जाता है
  • Project specification standard Git Smart HTTP का उपयोग करने वाला built-in software forge परिभाषित करता है
    • feature branches को dedicated channels के रूप में बनाया जाता है, और patches, continuous integration results, review comments व merge decisions को उसी record में सुरक्षित रखा जाता है
    • repositories, conversations और workflow history एक shared search index इस्तेमाल करते हैं
  • फिलहाल channels, threads, direct messages, shared canvases, media, search, audit logs, desktop app और YAML-based workflows काम कर रहे हैं
    • macOS, Windows और Linux के लिए package builds उपलब्ध हैं और Apache 2.0 license लागू है

single relay architecture और शुरुआती product की सीमाएं

  • Dorsey ने Buzz को decentralized और self-sovereign product के रूप में पेश किया, लेकिन architecture documentation के अनुसार फिलहाल relays के बीच P2P event exchange, gossip layer या replication features नहीं हैं
    • सभी reads और writes single relay से होकर गुजरते हैं, जो users को authenticate करता है, signatures verify करता है और events को store व distribute करता है
    • organizations अपना relay, domain और data own कर सकते हैं और portable Nostr key pairs इस्तेमाल कर सकते हैं, लेकिन हर community के भीतर वही relay authoritative server बना रहता है
    • hosting providers shared infrastructure पर एक-दूसरे से isolated कई communities चला सकते हैं
  • self-hosting infrastructure और data location पर control देती है, लेकिन इसके बदले availability, backup, security और upgrades की जिम्मेदारी operator पर डालती है
    • signed events action attribution और audit trails को support करते हैं, लेकिन server operation से जुड़े risks को खत्म नहीं करते
  • Buzz को testing और development के लिए इस्तेमाल किया जा सकता है, लेकिन documentation में इसे बार-बार unfinished product के रूप में वर्गीकृत किया गया है
    • mobile client development में है और push notifications अभी उपलब्ध नहीं हैं
    • workflow approval gates में database, API और interface components हैं, लेकिन पूरा execution path तैयार नहीं है
    • desktop version 0.4.21 21 जुलाई को release हुआ, जिसमें agent control, authentication और workspace onboarding से जुड़े feature additions व fixes शामिल हैं
  • एक event system के जरिए chat, code hosting, workflow automation, project search और agent orchestration के कुछ हिस्सों को replace करने की कोशिश है
    • integrated architecture एजेंटों को जरूरी context और limited access permissions देने के लिए integration work कम कर सकता है
    • दूसरी ओर, role-specific मौजूदा products development stack को पूरी तरह migrate किए बिना सिर्फ एक tool बदलने की सुविधा देते हैं
  • Block, Buzz documentation में शामिल पहला customer case है, लेकिन adoption rate, pricing और external customers की संख्या का खुलासा नहीं किया गया है; फिलहाल यह open-source build और contribution request चरण में है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • वह स्क्रीनशॉट किसी David Lynch-स्टाइल हॉरर जैसा लगता है। “#engineering. नई दिशा है। Prototype को Flutter में ले जा रहे हैं” कहने पर इंसान और agent bots प्यारे नामों और emoji के साथ “Physics वाला काम खत्म कर दिया, UI shell कैसा है @Honeybot?” जैसी बातचीत कर रहे हैं
    ऐसी दुनिया की कल्पना करना मुश्किल है जहाँ software development को इस तरह organize करना स्वाभाविक लगे, और यह बात भी typical लगती है कि इसमें blockchain जैसा कुछ इस्तेमाल होता है
    https://github.com/block/buzz/blob/main/docs/assets/screensh...

    • लगता है भविष्य की programming Ian McKellen की green screen shooting जैसी निराशा दे सकती है। यह उस स्थिति जैसी हो सकती है जहाँ Shakespeare theatre के veteran ने वास्तविक actors के बिना 《The Hobbit》 शूट करते हुए महसूस किया था, “मेरा काम दूसरे लोगों के साथ acting करना है, अकेले acting करना नहीं”
      https://www.theguardian.com/film/2013/nov/20/the-hobbit-gand...
    • बचपन में AI research में आने की एक वजह यह उम्मीद थी कि किसी दिन इंसानों की तरह बातचीत और interaction कर सकने वाली intelligent entities होंगी। अब यह सचमुच संभव हो गया है और लगता है सब इसे नापसंद कर रहे हैं, लेकिन मुझे अब भी यह अच्छा लगता है और AI agents को team members बनाने की कोशिश शानदार लगती है
      हालांकि सिर्फ चापलूसी करने वाले clones की जगह उन्हें असली personality दी जानी चाहिए, ताकि capabilities और behavior दोनों में हर agent का अंतर साफ हो
    • वह screen असल में कई लोगों और agents की activity को real time में coordinate करना मुश्किल होने के कारण बनाया गया script-based demo है, और repository में वह PR भी देखा जा सकता है
      मूल रूप से अनजान चीज़ को intuitive महसूस कराने के लिए playful presentation को कम करके नहीं आंकना चाहिए। हर bot का managing entity, capabilities और permissions अलग हैं, इसलिए names और images instances को अलग पहचानने के convenient shorthand हैं; उन्हें cute बनाना optional है
    • इसमें blockchain नहीं है। Nostr सिर्फ signed message format standard है जो simple store-and-forward relay servers से गुजरता है
    • सभी messages का समय 5:42 दिख रहा है, इससे लगता है कि यह पहले से डाला गया test data वाला capture है या उस capture पर आधारित mockup

  • “5 साल के बच्चे को समझाने जैसा” कहते हुए “Buzz एक open-source self-hosted workspace है जो signed Nostr events के जरिए team chat, AI agents और Git hosting को जोड़ता है” समझाया जा रहा है, तो अपेक्षित 5 साल के बच्चे का level काफी अलग है

    • यह दिलचस्प है कि ELI5, जो मूल AskReddit thread से निकले subreddit का नाम था, अब tech industry का आम marketing phrase बन गया है। आजकल इसका मतलब लगभग “expected reader को जिन first principles की जरूरत है, वहाँ से समझाओ” जैसा shorthand है, और लगता है industry के कई लोग 2010s Reddit को nostalgia से याद करते हैं
    • कभी agent को eli5 (task) कहते हुए चिंता हुई थी कि कहीं वह सचमुच 5 साल के बच्चे की तरह समझाने न लगे। यह बेवजह की चिंता थी; agents आम तौर पर HN comments section के उलट असली intent समझ लेते हैं
    • कल मिला ELI5 भी समझ नहीं आया, इसलिए logical next step के रूप में “ELI4” मांगा
    • इसका मतलब कुछ ऐसा है: “मुझे ऐसे समझाओ जैसे TechCrunch Disrupt में announce कर रहे हो”
    • Buzz पढ़ने पर भी सिर्फ buzzwords और corporate jargon की परतें दिखती हैं, इसलिए यह असल में क्या करता है समझना मुश्किल है

  • Slack में काम करता हूँ, लेकिन यह निजी राय है। Agent का वह सब देख पाना जो मैं और मेरे colleagues देखते हैं, बढ़िया है, लेकिन जैसे ही कुछ जानकारी केवल कुछ लोगों तक सीमित करनी हो, बात मुश्किल हो जाती है
    Multi-user agents से data leak न हो, इसके लिए resource-by-resource access rules को जटिल रूप से लिखना और maintain करना पड़ता है। इसके उलट single-user agent एक user की ओर से काम करता है, इसलिए structure सरल है; मुख्य बात यह है कि explicit permission के बिना private data को shared space में बाहर न ले जाने दिया जाए

    • सचमुच collaborative environment में private groups सबसे खराब हैं। अच्छा हो अगर Slack में पूरे thread को public channel में publish करने का button हो
    • Asana से होने के कारण bias हो सकता है, लेकिन मैं सहमत हूँ कि single-user agents आसान हैं। फिर भी पूरे workflow को समझने वाले multi-user agents बहुत powerful होते हैं
      Privacy के प्रति जागरूक रहने और गलत लोगों तक जानकारी leak न हो, इसके लिए बहुत सोच-विचार और समय लगा। Buzz अभी इस्तेमाल नहीं किया है, लेकिन अलग तरह से सोचकर दिलचस्प चीज़ बनाने की कोशिश की सराहना करता हूँ
    • Buzz में लगता है कि agent app integration नहीं, बल्कि खुद first-class user है। अगर Claude नाम का user बनाया जाए और सामान्य ACL लागू हो, तो शायद यह चिंता करने की जरूरत न हो कि वह इंसान है या bot
    • हमारा cloud execution environment shared secrets और personal secrets में फर्क करता है। shared secret से authenticated चीजें public environment में इस्तेमाल हो सकती हैं, और personal items केवल trusted channel से access हो सकते हैं; यह Slack या Telegram आदि पर भी लागू होता है
      Slack agent इस हिस्से में मजबूत है और सुनिश्चित करता है कि private information बिल्कुल leak न हो
    • Conversation key के रूप में group chat ID और अतिरिक्त जानकारी इस्तेमाल कर लें तो नहीं चलेगा?

  • अब कोई नया software project देखता हूँ तो पहले यही सोचता हूँ कि उसका कितना हिस्सा agents से बना होगा, और उसके साथ आने वाली instability और आसानी से छोड़ देने की प्रवृत्ति दिमाग में आती है। 10 साल पहले होता तो product quality का कुछ अंदाजा लगाया जा सकता था, लेकिन यह Buzz के बारे में खास तौर पर नहीं कह रहा

    • पहले कुछ बनाने की friction अपने-आप में इस बात का संकेत थी कि कुछ सोच-विचार हुआ है, लेकिन अब लगता है user के सामने फेंक दिया जाता है और उनसे ही तय करवाया जाता है कि इसमें value है या नहीं
      ऐसे products में early adoption के फायदे से ज्यादा risk होता है, इसलिए कुछ महीने इंतजार करना बेहतर है। अगर product sustainable है तो कुछ महीने देर होने से खास फर्क नहीं पड़ेगा
    • ज्यादातर software, agents इस्तेमाल हो या न हो, आखिरकार गायब हो जाते हैं, इसलिए इस सोच में कमी है। Google ने भी LLM से पहले, 2010 में इसी तरह का social product Google Buzz launch किया था, लेकिन 16 महीनों में बंद कर दिया
      मुख्य बात यह है कि project market fit पाता है या नहीं; दो साल बाद भी वह मौजूद रहेगा या नहीं, यह code quality से उतना मजबूत संबंध नहीं रखता जितना engineers मानना चाहते हैं
    • अब early adopter नहीं बनना चाहता, और कम से कम 6 महीने की validation के बाद ही देखना चाहिए कि यह सिर्फ temporary hype है या नहीं
    • यह मान लेना safer है कि सब कुछ LLM से generate हुआ है
    • आसानी से छोड़ देने की प्रवृत्ति सच है। Flow यह हो जाता है: AI से functions और tests बनाओ, AI से functions modify करो, फिर tests टूटें तो सब delete करके AI से फिर tests generate कराओ

  • पहले Slack में काम किया था। चैट की मौजूदा स्थिति को चुनौती देना अच्छी बात है, लेकिन मुझे संदेह है कि Slack और Teams एजेंट युग में भी टिक पाएंगे या उस स्तर तक विकसित हो पाएंगे
    हालांकि यह जानने की उत्सुकता है कि Nostr सच में सही protocol है या नहीं। बड़ी कंपनियों में फोन और local agents समेत ढेरों clients और हर team के agents को संभालना पड़ता है। Central-hosted agents के लिए मौजूदा identity structure फिट बैठता है, लेकिन personal agents user credentials को reuse करते हैं या अलग से पहचाने जाते हैं, यह साफ नहीं है
    यह भी सवाल है कि Git को अनिवार्य dependency होना चाहिए या नहीं। Block के लिए यह जरूरी हो सकता है, लेकिन इससे complexity बढ़ती है, इसलिए version-control host events को Buzz event log में merge करने के तरीके से इसे अलग भी किया जा सकता है
    Sol और Claude जैसे chat window में native components render करके design changes को ठोस रूप देते हैं, वैसे नए features आने पर कौन-सी समस्याएं पैदा होंगी, यह भी जानना चाहूंगा। Rust चुनने की वजह और जिन alternatives पर विचार किया गया, वे भी जानना चाहूंगा

    • Signal जैसा compromise बेहतर लगता है। Slack white-collar business relationships से अलग करना मुश्किल चीज बन गया है, लेकिन 24 घंटे cyber attacks के exposure में, कंपनी के वादों से ज्यादा अच्छा होगा अगर zero-knowledge systems के जरिए confidentiality और security सुनिश्चित हो
      Signal उन clients में सबसे अच्छा cross-platform messaging experience रहा है जिन्हें मैंने friend groups में इस्तेमाल किया है, और मौजूदा structure में Slack जैसी व्यवस्था जोड़ने से noisy channels की समस्या घटाने में मदद मिलेगी
    • code और files जैसी shared information इंसानों और agents को aligned रखने के लिए लगातार ज्यादा महत्वपूर्ण होती जा रही है, और AI-native companies की code पर dependency और ज्यादा होगी, इसलिए Git integration समझ में आता है
    • यह जानना चाहूंगा कि Rust खराब choice क्यों लगता है। medical-device software release करने के अनुभव से, team द्वारा लिखे गए code को cohesive और correct बनाए रखने में यह बेहतरीन था

  • Google Buzz और Wave इस दुनिया में बहुत जल्दी आ गए थे
    https://en.wikipedia.org/wiki/Google_Buzz

    • अब भी Gmail में Buzz label नहीं बना सकते
    • देखते ही Google+ और Buzz याद आ गए

  • team chat में bots डालना बुरा नहीं है; कई महीनों से experiment कर रहा हूं। Slack काम तो करता है, लेकिन ढेरों permissions सही करना दर्दनाक है और हर नए bot के लिए दोहराना पड़ता है
    self-hosted alternative के रूप में Matrix आजमाया, लेकिन end-to-end encryption इतना सख्त था कि bots के साथ information share करने में बाधा बना। कुछ हफ्ते पहले Zulip पर चला गया, और install करना, bot users बनाना और automation सब आसान था। Openclaw से बनाई automation को Haystack-based code से replace किया, जिसकी state कम बिगड़ी हुई थी
    install करने के बाद पता चला कि Zulip leadership को Anthropic ने hire कर लिया है। लगता है Jack Dorsey ने पहले announce किया, लेकिन Anthropic की भी मिलती-जुलती योजना हो सकती है
    team-level agents काफी तार्किक हैं। जैसे-जैसे organization बड़ी होती है, collaboration cost बढ़ती है और AI से optimize करना अच्छा target बनता है; और AI usage जितना बढ़ेगा, public channels में यह share और coordinate करने की जरूरत भी उतनी बढ़ेगी कि क्या किया जा रहा है। common guardrails और human-agent handoff वाले complex processes के लिए भी team chat अच्छी तरह fit बैठती है

    • XMPP कैसा रहेगा, यह जानने की उत्सुकता है

  • यह एक useful niche भर सकता है, लेकिन Anthropic और OpenAI के 6–12 महीनों के अंदर अपने products से इसे push करने की संभावना ज्यादा है
    agent swarms के लिए Git forge देखते हुए, Radicle में identity layer की कमी लगी लेकिन federated COB model अच्छा लगा, और Tangled में private repositories support नहीं था लेकिन social layer मजबूत थी। हालांकि issues को repository-owned objects के बजाय posts के रूप में model करना अटपटा लगा
    इसलिए private agent-first forge के लिए जगह है। Anthropic पहले से इसी दिशा में जा रहा है, और इसका latest product Tag Slack के अंदर agents को async चलाने के लिए authentication model है
    अगला कदम स्वाभाविक रूप से forge हो सकता है। जब agent UI GitHub को intermediary नहीं बनाएगा, तो Anthropic internal implementation को स्वतंत्र रूप से बदल सकेगा, और multi-user chat तथा repository/project management अगले platform components लगते हैं

    • नया code forge https://juju.bi बना रहा हूं। यह agent-first product नहीं है, लेकिन scalability के अलावा agents को खास तौर पर चाहिए ऐसे features मेरे दिमाग में नहीं आते

  • Slack के अस्तित्व का बड़ा कारण यह था कि IRC में channel history और search जैसी चीजें default रूप से support नहीं थीं, इसलिए वह कम पड़ता था। AI agents को फलने-फूलने के लिए Slack को network को protocol के रूप में पूरी तरह खोलना होगा, या अंततः उसे replace होना पड़ेगा
    अच्छा होगा अगर Slack AT Protocol-based chat अपनाए और Buzz जैसे apps इसे implement करें। users @yourname.com और agents @agent1.yourname.com जैसे domain handles इस्तेमाल करते हुए पूरा control रख सकते हैं

    • मुझे समझ नहीं आता कि agents को फलने-फूलने देना Slack की जिम्मेदारी क्यों है। पूरी industry में AI के हिसाब से workflows बदलने की उलटी प्राथमिकता मैं खुद देख रहा हूं; tools को इंसानों के लिए काम करना चाहिए, उलटा नहीं
    • Matrix के bot/puppet accounts जैसा है
    • शुरुआत में Slack पसंद आने की वजह यह थी कि वह “modern convenience features वाला IRC” था। Microsoft से पिछड़ने और Salesforce को बेचे जाने के बाद से यह मूलतः ठहर गया है, और ज्यादातर बदलावों ने product को और खराब ही बनाया है
    • अभी final न हुई ATProto permissions system में enterprises को चाहिए वैसा fine-grained control नहीं है। groups जैसी features app view में implement होंगी और व्यावहारिक रूप से centralized हो जाएंगी, और ACL identity तथा access management के इतिहास में दो पीढ़ी पुराना तरीका है
      chat भी PDS/ATP के लिए अच्छी fit वाली format नहीं है। Roomy ने भी यह समझ लिया है और dedicated protocol और bridge बना रहा है
    • Slack से ज्यादा यह HipChat के करीब है, और समय का अंदाजा करीब 15 साल गलत लगा है

  • website पर cursor movement में 0.5 सेकंड की देरी जैसा अप्रिय experience पहली बार हुआ