Tangled - atproto-आधारित Git सहयोग प्लेटफ़ॉर्म

• Tangled एक AT Protocol-आधारित सोशल फीचर्स वाला Git सहयोग प्लेटफ़ॉर्म है, जिसे इस तरह डिज़ाइन किया गया है कि डेवलपर अपने कोड पर पूरा स्वामित्व बनाए रखें, जबकि open source कम्युनिटी स्वायत्त रूप से संचालित हो सके
• यह मौजूदा ActivityPub(Forgejo)-केंद्रित federation मॉडल और Radicle के पूरी तरह P2P मॉडल, दोनों के फ़ायदे मिलाकर बना वितरित code collaboration ढांचा अपनाता है
• इसका मुख्य कॉन्सेप्ट ‘Knot’ एक हल्का headless Git server है, जो व्यक्तिगत self-hosting और कम्युनिटी-स्तर के multi-tenant environment दोनों को सपोर्ट करता है
• App View(tangled.sh) पूरे नेटवर्क के repositories का एक unified view देता है, जिससे अलग-अलग Knot पर मौजूद repositories को आसानी से ब्राउज़, clone और contribute किया जा सकता है
• यह फिलहाल beta चरण में है, और data ownership, low entry barrier, और user experience को बनाए रखना इसके मुख्य सिद्धांत हैं; आगे चलकर इसका लक्ष्य पूरी तरह open distributed Git ecosystem बनाना है

---

Tangled का परिचय

• Tangled एक नया प्लेटफ़ॉर्म है जो डेवलपर्स को कोड और पहचान पर स्वामित्व बनाए रखते हुए सामाजिक इंटरैक्शन वाला Git collaboration environment देता है
• यह AT Protocol पर आधारित है और decentralized social app architecture को Git collaboration में लागू करता है
• इसका उद्देश्य code collaboration को फिर से खुली और आनंददायक प्रक्रिया बनाना है

वितरित मॉडल और AT Protocol

• मौजूदा वितरित code collaboration मॉडलों में ये तरीके शामिल हैं
  • Forgejo(ActivityPub): सर्वरों के बीच federation के ज़रिए सहयोग
  • Radicle: पूरी तरह P2P(peer-to-peer) संरचना
• Tangled इन दोनों मॉडलों के फ़ायदे मिलाकर केंद्रीय identity management की सुविधा वाले atproto को अपनाता है
• इससे उपयोगकर्ता वितरित नेटवर्क के भीतर भी सुसंगत ID और authentication structure बनाए रख सकते हैं

Knot संरचना

• Knot Tangled का मुख्य घटक है, एक हल्का server जो उपयोगकर्ताओं को खुद Git repository host करने देता है
  • यह single या multi-tenant configuration दोनों को सपोर्ट करता है
  • Raspberry Pi जैसे छोटे डिवाइस पर भी self-hosting संभव है
• Tangled डिफ़ॉल्ट रूप से मुफ़्त managed Knot service प्रदान करता है
• इस संरचना की वजह से व्यक्तिगत user server और community server स्वाभाविक रूप से जुड़कर वितरित Git network बनाते हैं

App View और एकीकृत नेटवर्क

• tangled.sh पर उपलब्ध App View पूरे नेटवर्क की repositories को एक unified view में दिखाता है
• उपयोगकर्ता किसी दूसरे Knot पर मौजूद repository को भी आसानी से clone और contribute कर सकते हैं
• यह डिज़ाइन Git के मौजूदा workflow को बनाए रखते हुए भी वितरित environment की बाधाएँ हटाता है

विकास सिद्धांत

• Tangled टीम ने विकास दिशा के लिए ये तीन सिद्धांत तय किए हैं
  • 1. Data ownership — हर उपयोगकर्ता अपने बनाए कोड और metadata का सीधे स्वामी हो
  • 2. Low entry barrier — कोई भी आसानी से शामिल हो सके, इसके लिए सरल संरचना और interface दिया जाए
  • 3. User experience की consistency — वितरित संरचना होने के बावजूद centralized service-स्तर का UX सुनिश्चित किया जाए
• ये सिद्धांत Tangled के तकनीकी विकल्पों और पूरे UI/UX डिज़ाइन में दिखाई देते हैं

एक्सेस और कम्युनिटी

• शुरुआत में यह invite-only access के साथ चलाया गया था, और डेवलपर्स #tangled IRC चैनल(libera.chat) के ज़रिए इसमें शामिल हो सकते थे
• अब यह public login open स्थिति में है, और कोई भी tangled.sh/login पर इसका उपयोग कर सकता है
• Tangled अभी शुरुआती चरण में है, लेकिन यह internal dogfooding के ज़रिए फीचर्स को परखते हुए आगे बढ़ रहा है

निष्कर्ष

• Tangled, Git collaboration को सोशल नेटवर्क जैसी जुड़ी हुई experience तक विस्तार देने की कोशिश है
• स्वायत्तता, सुलभता, और आनंददायक development culture को जोड़ने वाले नए वितरित Git platform ecosystem के रूप में यह ध्यान आकर्षित कर रहा है

[lamanus]

आधिकारिक container नहीं होने की वजह से शुरुआती setup थोड़ा झंझटभरा था।

[GN⁺]

Hacker News राय

• Tangled के सह-संस्थापक के रूप में, हाल में OAuth लाइब्रेरी बदलते समय एक समस्या आई थी जिसके कारण नए उपयोगकर्ता डिफ़ॉल्ट knot और spindle (आंतरिक git hosting server और CI runner) में नहीं जुड़ रहे थे। अभी-अभी fix patch लागू किया है, इसलिए logout करके फिर login करने पर अब सामान्य रूप से repository बनाई जा सकेगी। कोई भी सवाल हो तो मैं कभी भी जवाब दे सकता हूँ।
  • पहला सवाल यह है कि क्या tngl.sh PDS पर handle बदला जा सकता है या account delete किया जा सकता है। दूसरा यह है कि नया AppView बनाकर चलाने के लिए कितने resources चाहिए होते हैं। उदाहरण के लिए, अगर Cloudflare Pages की तरह कोई static website folder upload करके वैसा ही serve करने वाला PDS-आधारित AppView बनाया जाए, तो क्या AppView operator को भारी traffic cost पूरी तरह खुद उठानी पड़ेगी? ऐसे architecture में operational burden कैसे होता है, यह जानना चाहता हूँ।
  • Tangled ने “social-enabled” शब्द का इस्तेमाल किया है, जो शायद AT protocol से जुड़ा है। जानना चाहता हूँ कि क्या Tangled आगे और तरह-तरह के social features लाने की योजना बना रहा है, या इसका मतलब सिर्फ AT protocol support है।
• मुझे यह project सच में बहुत शानदार लगता है। मौजूदा code forge services की monopoly structure को तोड़ने की कोशिश मुझे पसंद है। मेरी इस क्षेत्र में दिलचस्पी का कारण यह है कि code forge एक साथ बहुत सारी समस्याएँ हल करने की कोशिश में उल्टा inefficient हो जाता है। ज़्यादातर forge git repository, web viewer, collaboration tools, CI/CD pipeline, work management जैसी कई सुविधाएँ एक साथ बाँध देते हैं। लेकिन मुझे नहीं लगता कि इन सबको ज़रूरी रूप से एक ही जगह बाँधना चाहिए। उदाहरण के लिए, अगर git repository की direct access की ज़रूरत न हो, तो https://pgit.pico.sh की तरह पूरी तरह static web viewer दिया जा सकता है, या collaboration के लिए patch बाँटकर local में review और manage करने वाला अलग server (https://pr.pico.sh) हो सकता है। VPS पर सिर्फ bare git repository डाल देना भी काफ़ी है और यह बहुत आसान काम है। Git पहले से ही distributed system है, इसलिए दूसरी auxiliary services की वजह से उसका फिर centralize हो जाना मुझे anti-pattern लगता है।
  • लोग अक्सर कहते हैं कि “Git पहले से distributed है”, लेकिन असल में distribution की अवधारणा में कुछ अस्पष्टता है। Git खुद distribution पर केंद्रित होने के बजाय आम तौर पर master-slave protocol आधारित (जैसे HTTP) ढाँचे पर चलता है, इसलिए आख़िर में centralization फिर लौट आता है।
  • जब services कई हो जाती हैं तो trust की समस्या पैदा होती है। सवाल यह होता है कि 80% ज़रूरतें पूरी करने वाली एक service को verify किया जाए, या अलग-अलग 10 services को अलग से जाँचा जाए। साथ ही infrastructure की economies of scale और कई features को integrate करने से मिलने वाले फ़ायदे भी नज़रअंदाज़ नहीं किए जा सकते। इसी वजह से अब भी बहुत से लोग monolith को पसंद करते हैं। मतलब developer experience के trade-off पर सोचना पड़ता है।
  • VPS पर git remote repository set up करना वास्तव में बहुत आसान है। ssh access हो तो यह तुरंत काम करने लगता है। दरअसल मुख्य मुद्दा 'lock-in' है। GitHub जैसी services service देने से ज़्यादा lock-in पर इतना ध्यान क्यों देती हैं? इसके पीछे funding और business model है। centralization → lock-in → revenue की कड़ी कई services में बार-बार दिखाई देती है। अगर service खुद revenue generate करने की स्थिति में न हो, तो लगता है कि इस तरह की प्रवृत्ति से बचना मुश्किल है।
  • तकनीकी रूप से features को अलग करना असंभव नहीं है, लेकिन economics की समस्या है (हर feature के लिए अलग maintenance का revenue model टिकाऊ नहीं होता), और usability की भी समस्या है (लोगों को 'batteries included' वाली सुविधा चाहिए)। open source में भी अक्सर economics को नज़रअंदाज़ किया जाता है, लेकिन अंत में ज़्यादातर चीज़ें इसलिए ख़त्म हो जाती हैं क्योंकि एक maintainer की ऊर्जा समाप्त हो जाती है। सबसे सफल open source projects भी अधिकतर corporate sponsor या engineers के support से चलते हैं।
  • अलग करना ज़रूरी नहीं है, लेकिन integrated होना फिर भी कहीं ज़्यादा सुविधाजनक है।
• हाल में JJ Con में Jujutsu support की खबर मिली। संबंधित जानकारी https://blog.tangled.org/stacking पर देखी जा सकती है।
  • यह service वास्तव में stacked PR को support करती है। GitHub इतने दशकों में भी यह नहीं कर पाया। अगर इसे कंपनी के अंदर private तौर पर इस्तेमाल करना हो, तो Tangled instance को external network से disconnected रखने की setting कैसे की जाए, यह स्पष्ट नहीं है, जो थोड़ा खटकता है।
• मुझे लगता है कि GitHub पर अब भरोसा नहीं किया जा सकता। कम से कम oss stack को AT protocol या किसी और open network पर ले जाना बड़ी कंपनियों, censorship वगैरह के risk से बचाने का अच्छा तरीका है। इसलिए ऐसी कोशिश देखकर अच्छा लगता है।
  • लेकिन ज़्यादातर लोग अपना server खुद चलाना नहीं चाहेंगे। शायद सिर्फ बड़े OSS संगठन ही यह वहन कर पाएँगे। यहाँ तक कि email के अलावा PR देना भी मुश्किल हो सकता है।
• मैं tangled पर sign up करने वाले पहले 100 लोगों में से एक हूँ। stacked patch style PR review का roadmap और feature improvement की गति बहुत प्रभावशाली लगी, और community की ऊर्जा से भी सकारात्मक भावना मिली। आगे यह कैसे विकसित होगा, इसे लेकर मैं बहुत उत्साहित हूँ। अगर यह इसी तरह लगातार आगे बढ़ता रहा, तो मुझे लगता है कि इससे कहीं बेहतर experience, बुनियादी control और long-term sustainability भी हासिल की जा सकती है।
• मुझे ज़्यादा distributed git collaboration में बहुत दिलचस्पी है। आपकी नज़र में इसके फैलने में सबसे बड़ी बाधा क्या है? server operations, private key management, या आख़िरकार network effects? इस पर आपकी राय जानना चाहता हूँ।
  • सबसे बड़ी बाधा spam, illegal content और कुल मिलाकर moderation की समस्या है। PDS कोई भी domain हो सकता है, और एक PDS असीमित users को रख सकता है, इसलिए trust टूटने जैसे अनुभव बहुत होते हैं। अगर लोग git repo में ebook या TV show जैसी चीज़ें बड़ी मात्रा में upload करने लगें तो क्या किया जाएगा, या अगर किसी project पर political issue की वजह से spam attack हो जाए तो उसका हल क्या होगा—ये सवाल सामने आते हैं। AppView की अच्छी बात यह है कि BlueSky की तरह एक central moderation team consistent policy लागू कर सकती है। हर कोई कुछ भी upload कर सकता है, लेकिन आख़िरकार frontend में selective curation संभव है। लेकिन central moderation decisions भी हमेशा विवादास्पद होते हैं। यही वजह है कि मैं पूरी तरह distributed network का बोझ और ज़िम्मेदारी उठाना नहीं चाहता। AT protocol की openness, Twitter जैसी services की तुलना में फ़ायदा है, लेकिन इसके साथ रोज़मर्रा के management और concentrated authorization वाली व्यवस्था की ज़रूरत भी होती है। व्यक्तिगत रूप से, अभी मैं यह सोचता हूँ कि क्या कोई “उदार” radicle seed node operator (जो anonymous git upload की अनुमति दे) बनने के लिए तैयार होगा।
  • GitHub मुफ़्त है, और decentralization की कीमत चुकानी पड़ती है।
  • Tangled से बिना खुद server चलाए भी git को स्वतंत्र रूप से इस्तेमाल कर पाना मुझे बहुत पसंद है। सबसे बड़ा नुकसान यह है कि यह अभी बहुत नई service है। अभी इसकी आम पहचान नहीं है, और बहुत से लोग यह भी नहीं जानते कि Bsky और PDS क्या देते हैं। अगर और features और alternate clients हों तो अच्छा होगा। फिर भी, मुझे लगता है कि शुरुआती users पहले से ही काफ़ी अच्छा अनुभव पा रहे हैं। मैं उस दिन का इंतज़ार कर रहा हूँ जब और ज़्यादा developers इस अनुभव से परिचित होंगे।
• CI pipeline support देखकर अच्छा लगा, लेकिन यह GitHub Actions जैसा दिखता है, जो थोड़ा निराशाजनक है। मुझे नहीं लगता कि सिर्फ साधारण sequential execution के लिए YAML की ज़रूरत है; bash script भी काफ़ी है। pipeline YAML तब मायने रखता है जब वह program flow नहीं बल्कि dependency (DAG) व्यक्त कर रहा हो। इस मामले में Buildkite कहीं बेहतर है।
• कल “Spaghetti” नाम का no-code business platform और “Lock-in” नाम की एक अहम data storage vault service आने वाली है।
• कंपनी में मजबूरी में GitHub public org इस्तेमाल करना पड़ता है। क्या code review (CR) tangled में करके बाद में GitHub से sync किया जा सकता है? और क्या jj tool का review experience वैसा ही बनाए रखा जा सकता है?
  • mirroring किया जा सकता है, और merge के समय GitHub पर push करने वाली spindle pipeline भी बनाई जा सकती है। संदर्भ दस्तावेज़: https://tangled.org/@tangled.org/core/blob/master/docs/spindle/pipeline.md
• जानना चाहता हूँ कि enterprise/private use के लिए Tangled अपनाया जा सकता है या नहीं। stacked diff review flow corporate work के लिए बहुत उपयुक्त लगता है।
  • इसकी संभावना है। पूरी तरह airgapped और AT से अलग Tangled version पर चर्चा हो रही है। यह काफ़ी बड़ा काम है, इसलिए तुरंत आगे बढ़ाना मुश्किल है।
  • फ़िलहाल अलग enterprise solution स्पष्ट रूप से मौजूद है, ऐसा नहीं कहा जा सकता। संबंधित issue discussion https://tangled.org/@tangled.org/core/issues/60 पर देखी जा सकती है।