फोर्ज की फेडरेशन की ज़रूरत

• open source collaboration को ऐसे ढांचे की बजाय, जो किसी एक प्रदाता पर बहुत अधिक निर्भर हो, distributed protocols के ऐसे संयोजन पर आधारित होना चाहिए जो code transfer और communication की ज़िम्मेदारियाँ अलग-अलग संभालें
• code collaboration मूल रूप से git और email के संयोजन से होती थी, बाद में यह git और GitHub website के संयोजन में बदल गई, और अब ForgeFed, git और ActivityPub के संयोजन की ओर, जबकि Tangled, git और AT protocol के संयोजन की ओर बढ़ रहा है
• Tangled, git servers के बीच events को federate करता है, और हर server को knot कहता है; server अलग होने पर भी repository collaboration, cross-server fork, और किसी दूसरे server पर मौजूद repository के लिए pull request को support करता है
• code के आसपास होने वाले Authenticated Transfer के लिए यह AT का उपयोग करता है, और issues, pull requests, event timeline, follows, stars को साथ संभालता है; collaborator invites और SSH public key sharing में भी इसका उपयोग होता है
• यह अपने cgit instance को सीधे चलाने और email से patch भेजने वाले flow जैसा महसूस होता है, लेकिन साथ ही GitHub monoculture से बाहर निकलकर collaboration की सामाजिकता और मज़ा बनाए रखने की दिशा भी दिखाता है

---

फोर्ज फेडरेशन की ज़रूरत

• open source collaboration का बड़ा हिस्सा किसी एक प्रदाता पर निर्भर होना वांछनीय नहीं है, और इसके पीछे यह दृष्टिकोण है कि centralized systems की तुलना में distributed protocols अधिक समय तक टिकते हैं
• code collaboration हमेशा दो protocols के साथ मिलकर चलती रही है; एक code transfer के लिए और दूसरा communication के लिए
  • शुरुआती flow git और email का संयोजन था
  • बाद में यह git और GitHub website के संयोजन में बदल गया
  • ForgeFed, git और ActivityPub के संयोजन की संभावना पर काम करता है
  • Tangled, git और AT protocol के संयोजन पर बनाया जा रहा है
• Tangled, git servers के बीच events को federate करता है, और हर server को knot कहता है
  • repository किसी भी server पर हो, collaboration संभव है
  • servers के पार fork को support करता है
  • अपने server की repository में push करने के बाद, किसी पूरी तरह अलग server पर hosted repository के लिए pull request खोली जा सकती है
• यह तरीका अपने cgit instance को सीधे चलाने और email से patch भेजने वाले flow से कई मायनों में मिलता-जुलता है

Tangled की भूमिका

• Tangled, code के आसपास होने वाले events के Authenticated Transfer के लिए AT का उपयोग करता है
  • इसका उपयोग issues और pull requests जैसे events को पहुँचाने में होता है
  • event timeline, follows, stars जैसे social features भी साथ संभाले जाते हैं
  • vouches भी जल्द जोड़े जाने वाले हैं
• AT का उपयोग collaborator invites और SSH public key sharing के लिए भी होता है, जबकि बाकी हिस्सों में मौजूदा git को ही वैसे का वैसा उपयोग किया जाता है
• open source को GitHub जैसी monoculture से बाहर निकलने की ज़रूरत है, और साथ ही code collaboration की सामाजिकता और मज़ा भी बनाए रखना चाहिए
• tangled alpha
• docs
• source
• discord
• bluesky
• twitter (x)
• feed

[GN⁺]

Hacker News की रायें

• यह Mastodon से कितना बेहतर होगा, इस पर मुझे ज़्यादा भरोसा नहीं है

  • ATproto कई सर्वरों के बीच संदेश भेजने-लेने वाली संरचना नहीं है, बल्कि RSS के ज़्यादा करीब है
    इसमें app से अलग एक hosting layer होती है, और कोई भी अपना data खुद host कर सकता है, जबकि apps उन सभी hosts से data इकट्ठा करके दिखाती हैं
    इसलिए Mastodon-शैली की defederation जैसी कोई अवधारणा ही नहीं है
    और जानना हो तो https://overreacted.io/open-social/ और https://overreacted.io/a-social-filesystem/ देख सकते हैं
  • ATproto का federation मॉडल Mastodon से काफ़ी अलग है, और इसमें instance जैसी कोई अवधारणा नहीं है
    accounts PDS पर host होते हैं और records भी वहीं जाते हैं, लेकिन app में दिखने वाला content कई PDS के data को जोड़ने वाले AppView से आता है
    इसलिए आप किसी भी PDS पर हों, app का अनुभव एक centralized service जैसा लगता है, और कई AppView हो सकते हैं, जिन्हें आप खुद भी host कर सकते हैं
  • AppView fediverse से काफ़ी अलग है, और explicit federation की बजाय shared relay पर निर्भर करता है
    अभी जैसी लगभग global discoverability मिलती है, उसकी लागत पर सोचना चाहिए, लेकिन इसे बस एक और Mastodon कहना ठीक नहीं होगा
  • समझ नहीं आता कि ज़रूरी क्यों है कि किसी एक पक्ष में खड़ा हुआ जाए या सही जवाब वाले पक्ष को ही चुना जाए
    चाहे तो कोई पक्ष ही मत चुनो, या फिर जिस दिशा को खुद सही समझो उसी तरफ़ जाओ
  • थोड़ा बढ़ा-चढ़ाकर कहा गया है, लेकिन मान भी लें तो भी यह मौजूदा उस ढाँचे से बेहतर लगता है जहाँ मौजूदगी बनाने के लिए GitHub और GitLab पर निर्भर रहना पड़ता है

• मैं atprotocol पक्ष में काफ़ी सक्रिय हूँ, इसलिए थोड़ा पक्षपाती हो सकता हूँ, लेकिन Tangled का इस्तेमाल मुझे सच में बहुत संतोषजनक लगा है
  यह GitHub के विकल्प के रूप में मेरी चाहत के सबसे करीब है; features ज़्यादा सरल हैं, लेकिन पिछले 1 साल से यह मेरे personal open source projects के लिए मुख्य social/git service रही है
  मेरा account है https://tangled.org/did:plc:rnpkyqnmsw4ipey6eotbdnnf
  Bluesky से मिला social graph यहाँ भी जारी रहता है, इसलिए commits, PRs और issues के पीछे के लोगों को सहज रूप से जोड़कर देख पाना अच्छा लगता है, और login भी दूसरी atproto services जैसा ही है, इसलिए सुविधाजनक है
  हाल ही में built-in static site support भी आया है, इसलिए client-side websites या साधारण index.html को repo से सीधे host करना आसान हो गया है
  Spindles build system/actions की भूमिका निभाता है; मैं Nix का बड़ा fan नहीं हूँ, फिर भी मेरी ज़रूरतों के लिए यह काफ़ी ठीक बैठा
  open API भी अच्छा है, इसलिए atproto-आधारित standards का उपयोग करके information rendering आसानी से बना सका, bots भी बनाए और npmx.dev में कुछ features भी जोड़े
  आप खुद knot (git server) और runner (Spindles) चला सकते हैं या hosted version इस्तेमाल कर सकते हैं, लेकिन मुख्य बात यह है कि social features अलग किए गए हैं, इसलिए git server अलग होने पर भी issues या PR conversations shared social layer पर जारी रहती हैं
  यह perfect नहीं है, और navbar में लगा alpha टैग यूँ ही नहीं है, लेकिन open source काम के लिए मैं इसे आगे भी इस्तेमाल करता रहूँगा, इसकी संभावना काफ़ी है

  • मुझे थोड़ी चिंता है कि atproto कहीं Bluesky की कमज़ोर मौजूदगी के साथ खिंच न जाए
    यह चिंता कितनी जायज़ है, अभी कहना मुश्किल है

• comments का माहौल काफ़ी नकारात्मक है, लेकिन मैं खुद भी VC funding से सावधान रहने वालों में हूँ और फिर भी मानता हूँ कि इस क्षेत्र में competition को बढ़ावा देना चाहिए
  इस समय ऐसी चीज़ को bootstrap करके शुरू करना बहुत मुश्किल, बल्कि लगभग असंभव लगता है; और यह भी सही है कि कल HN के top पर आए GitHub-विरोधी पोस्ट्स के साथ timing अच्छी बैठी, फिर भी ऐसी कोशिशों का समर्थन करने का मन है
  उम्मीद है कि यह meaningful scale तक पहुँचे

  • मेरी नज़र में यह सिर्फ़ निराशावाद नहीं, बल्कि वास्तविक चिंता है
    सिर्फ़ title देखकर उत्साहित हुआ था, लेकिन जैसे ही पता चला कि इसमें VC funding है, यह तुरंत मेरी consideration list से बाहर हो गया
    अगर मैं अपने उस प्रिय project को, जो अभी कोई कमाई भी नहीं करता, किसी platform पर रखूँगा, तो मैं ऐसी जगह चुनना चाहूँगा जहाँ 5 साल बाद rug pull होने की संभावना कम हो
    VC projects को investment वापस करना ही होता है, इसलिए मुझे लगता है कि आख़िरकार किसी न किसी रूप में rug pull आएगा
    इसलिए अभी मैं या तो paying customer बनकर services लेना पसंद करता हूँ, या फिर ऐसे cooperative-style models जहाँ सदस्य fee दें और decision-making पर vote का अधिकार भी हो
  • VC वाला project आख़िरकार rug pull, ads, privacy invasion, या जबरन paid features की तरफ़ जाने की आशंका रखता है
    इसलिए users के लिए इस संभावना को पहले से जानना ज़रूरी है
    जब आने वाली हक़ीक़त ऐसी हो, तब ज़रूरत से ज़्यादा idealism दिखाने वाली services मुझे पसंद नहीं
    बेहतर है कि service सीधे fee ले, या अगर सच में आदर्शवाद है तो non-profit के रूप में शुरू हो, या कम-से-कम monetization plan साफ़-साफ़ बताए
  • समझ नहीं आता कि bootstrap को असंभव क्यों माना जा रहा है
    मुश्किल होना तो स्वाभाविक है, लेकिन खासकर अगर federation लक्ष्य है, तो क्या इसे उतने ही या उससे भी ज़्यादा cost वाले नहीं, बल्कि सस्ते infrastructure पर बन पाना चाहिए?

• अगर atproto data model में दिलचस्पी है, तो https://overreacted.io/a-social-filesystem/ में मैंने एक introductory post लिखी है
  थोड़ी लंबी है, लेकिन पूरा picture काफ़ी साफ़ कर देती है

  • यह तो कम करके कहना होगा
    अब तक देखी गई ATProto introductory posts में यह सबसे अच्छी थी
    क्या इन लेखों को एक जगह इकट्ठा करने वाला कोई tag या list भी है?

• मेरी नज़र में ज़रूरत forge federation की नहीं, बल्कि और समृद्ध git repo की है
  Fossil लगभग 90% वहाँ तक पहुँच चुका है, क्योंकि यह tickets, forum और wiki को repository के हिस्से के रूप में जोड़ता है; और जब आप clone करते हैं, तो वे सब भी साथ आ जाते हैं ताकि उन्हें offline भी देख सकें
  आप विमान में भी reply लिख सकते हैं और सही permissions हों तो तुरंत, या बाद में connection लौटने पर sync कर सकते हैं
  लेकिन VCS में किसी खास artifact type को hardcode करने के बजाय, बेहतर दिशा यह लगती है कि repo के अंदर app रखी जाए और वही तय करे कि कौन-से artifacts मान्य होंगे, कौन-से rules लागू होंगे, और कौन कब upload/download कर सकता है
  फिर forge बस उस policy को execute करे और web users के लिए मनचाहे तरीके से render कर दे
  ऐसा होने पर किसी दूसरे forge में जाना भी बस repo push करने भर का काम रह जाएगा

  • इसके लिए सच में धन्यवाद
    मैं इन दिनों ticket systems और agents जैसी चीज़ें git repo के अंदर flat files के रूप में बना रहा था, और अब लग रहा है कि इसे repo management तक भी बढ़ाना चाहिए
    यह बहुत शानदार हो सकता है

• मेरे हिसाब से federated solution की मुख्य समस्या आखिरकार cold start है
  अगर आप किसी बड़े existing server में जाते हैं, तो आप उसी centralization को फिर गले लगा लेते हैं जिससे निकलना चाहते थे, लेकिन बदले में शुरू से बड़ा network मिल जाता है
  दूसरी तरफ़ अगर आप अपना server खुद चलाते हैं, तो network शून्य, discoverability शून्य, feed खाली, और ऊपर से दूसरे sites को मनाना पड़ता है कि वे federate करें या सिर्फ़ one-person server होने की वजह से block न करें
  पता नहीं सिर्फ़ मुझे ऐसा लगता है, या मैं federation को गलत समझ रहा हूँ
  शायद यह बस Mastodon की खास समस्या हो

  • शायद इसी वजह से Tangled ने ActivityPub की बजाय ATproto चुना
    इसे इस तरह design किया गया है कि अलग-अलग servers को central AppView इकट्ठा करके centralized network जैसी consistent single view दें
    AppView कोई भी host कर सकता है
  • यह बात ज़्यादा Mastodon पर लागू होती है
    atproto में हर server आधा-अधूरा अलग-थलग इलाका बनकर काम नहीं करता
    distributed systems नज़रिए से इसकी अच्छी व्याख्या https://atproto.com/articles/atproto-for-distsys-engineers में है
  • मुझे लगता है फ़ायदा बीच के रास्ते में है
    अगर कोई बड़ा server moderation, policy, content या technical समस्याओं के कारण संदिग्ध हो जाए, तो वहाँ से निकलकर किसी दूसरे काफ़ी बड़े server को बढ़ाना या वहाँ migrate करना अपेक्षाकृत आसान हो सकता है
    यानी शुरू से ही कुछ reputation और scale वाला refuge बनाया जा सकता है
    GitLab, Codeberg, freedesktop, Fedora, Debian जैसे alternative forges पहले से मौजूद हैं, इसलिए अगर project visibility और discoverability बनी रहे तो ये काफ़ी सुरक्षित शरणस्थल हो सकते हैं
  • अब तक मेरा भी अनुभव बिल्कुल ऐसा ही था, इसलिए मैं federated services से दूर रहा
    लेकिन कुछ दिन पहले इस project को देखकर लगा कि यह सच में काम कर सकता है
    क्योंकि इसके target users और self-hosting के अभ्यस्त लोगों के बीच काफ़ी overlap है
    मेरी पूरी network का यहाँ आना ज़रूरी नहीं; वास्तव में उस subset का आना ही काफ़ी उपयोगी होगा जिसके यहाँ आने की संभावना सच में है
  • यहाँ आकर्षण की बात यह है कि self-host करना भी संभव है और बड़े providers के बीच migration भी
    frontend server की लागत बहुत कम होगी, इसलिए यह लगभग स्थायी रूप से चल सकने जैसा लगता है, और असली data दूसरे hosts उपलब्ध कराते हैं

• Tangled को VC support मिलना मुझे stability से ज़्यादा हर हाल में बढ़ना ही होगा वाले दबाव जैसा लगता है
  इसकी appeal समझ नहीं आती
  चाहे यह federated ही क्यों न हो, अगर development रुक गया तो bugs ठीक करने और maintenance करने वाला कौन होगा?

  • Tangled पूरी तरह public में develop हो रहा है https://tangled.org/tangled.org/core, और इसका goal permanent software है
    यानी सब कुछ पूरी तरह reproducible हो और न्यूनतम लागत पर पूरा stack self-host किया जा सके
    VC funding मकसद नहीं, सिर्फ़ साधन है; और यूरोप में रहने वाले दो भारतीय founders के लिए grants व्यवहारिक नहीं थे, क्योंकि उन्हें वास्तव में मिलने में 4–12 महीने या उससे ज़्यादा लग जाते
    team बनाना, infrastructure खड़ा करना और development तेज़ करना — इन सबके लिए VC सबसे तेज़ रास्ता था, और उन्होंने investors के साथ goals का मज़बूत alignment सुनिश्चित करने में 6 महीने से ज़्यादा लगाए
  • जो लोग इसे इस्तेमाल करेंगे, वही maintenance कर सकते हैं
    Tangled में architecturally काफ़ी दिलचस्प choices हैं, लेकिन codebase खुद अपेक्षाकृत सरल है, और मैंने जितना देखा उससे maintenance मुश्किल नहीं लगती
    ज़्यादातर हिस्सा loosely connected Go modules का है, जिसके ऊपर static HTML+CSS, थोड़ा-सा TypeScript, और orchestration के लिए Nix है
    अगर मुझे सही याद है, तो hardware requirements भी बहुत छोटी हैं, इसलिए मौजूदा scale पर एक व्यक्ति भी इसे खुद host कर सकता है
    असली infrastructure burden का बड़ा हिस्सा users के knots, spindles, PDS और पूरे atproto ecosystem पर होता है
  • यह comment भी आप एक ऐसे news aggregation site पर लिख रहे हैं जिसे VC funding मिली है, तो उस नज़र से देखें तो बात इतनी सीधी नहीं लगती
  • VC ठीक है, बस YC funding न हो तो बेहतर
  • ऐसे VC-backed setup को देखकर मेरे मन में दो सवाल आते हैं
    आखिर VC की ज़रूरत क्यों है, और Ladybird की तरह corporate sponsorship क्यों नहीं ली जाती?
    और जब investors 10x return चाहते हैं, तो मैं उस developer tool पर समय क्यों लगाऊँ जो बाद में enshittification की ओर जा सकता है?

• वह मज़ाक याद आता है कि 4 standards हों और आप एक unified standard बनाने जाएँ, तो नतीजे में 5 standards हो जाते हैं
  मज़ाक अपनी जगह, लेकिन मुझे लगता है कि ActivityPub क्यों पर्याप्त नहीं है, इसके लिए और मज़बूत तर्क चाहिए
  इससे पहले कि decentralized communication की समस्या को फिर से किसी नए तरीके से हल करने की कोशिश की जाए

  • ActivityPub और atproto की बनावट ही अलग है
    इन्हें आमने-सामने रखना कुछ वैसा है जैसे पूछना कि email मौजूद है तो web की क्या ज़रूरत है
    ActivityPub में servers inbox की तरह काम करते हैं और एक-दूसरे को messages भेजते हैं
    जबकि atproto में user repositories data host करती हैं, और apps उन repositories से data इकट्ठा करके दिखाती हैं
    topology के इसी फ़र्क की वजह से इनके गुण भी अलग हो जाते हैं; atproto में user hosting बदलने पर भी app experience नहीं टूटता, और existing data के आधार पर कोई भी नई app बना सकता है
    ActivityPub ऐसा नहीं होने देता, और अंत में यह उन छोटे centralized services जैसा बन जाता है जहाँ hosting और app आपस में जुड़े होते हैं और वे बस एक-दूसरे को messages भेजते हैं
  • यह भी देखना चाहिए कि Tangled funding जुटाने से पहले ही ATProto पर product ship कर सका, लेकिन ForgeFed कई सालों से इतनी धीमी प्रगति क्यों कर रहा है
  • source post में link है, लेकिन क्यों ActivityPub इस समस्या के लिए उपयुक्त नहीं है, यह ForgeFed के authors ने खुद https://forgefed.org/blog/actor-programming/ में समझाया है

• Nostr पर चलने वाले अपेक्षाकृत mature GitHub alternatives में https://gitworkshop.dev/ भी है
  इसका मुख्य विचार यह है कि repositories को कई GRASP-compatible nostr relays पर रखा जा सकता है, और अगर एक server बंद हो जाए तो दूसरे के ज़रिए transparently sync हो सकता है
  इसलिए अगर आप भरोसेमंद servers चुनें, तो यह व्यावहारिक रूप से लगभग 100% uptime जैसा हो सकता है, और repositories, activity, issues वगैरह भी cryptographically signed होते हैं

  • यह इतना mature नहीं लगता
    नाम से ही git की trademark policy का उल्लंघन होता हुआ दिखता है
    https://git-scm.com/about/trademark
  • उम्मीद है मैं गलत हूँ, लेकिन वह project closed source जैसा लगता है
  • उस site पर मैं कोई भी repository ठीक से खोल नहीं पाया
    कुछ में browser कहता है कि ssh या https URL support नहीं करता, और कुछ में सिर्फ़ Failed to load file tree दिखता है और endless loading चलती रहती है
    इसलिए इसे fairly mature कहना मुझे ठीक नहीं लगता

• मैं federation का मज़बूत समर्थक हूँ, लेकिन federation of forges का उपयोग मुझे हमेशा अस्पष्ट लगा है
  आखिर forges को आपस में कौन-सा data exchange करना है?
  Blender के forge को Ubuntu के forge से क्यों जुड़ना चाहिए?
  GitHub से मुझे सबसे बड़ा value single login का मिलता है, जिससे projects के बीच घूमना आसान हो जाता है; मेरा मानना है कि independent forges भी बिना जटिल forge federation के सिर्फ़ social login देकर उस value का बड़ा हिस्सा दे सकते हैं

  • लोग software ढूँढने के लिए आखिरकार GitHub search से ही शुरू करते हैं
    अगर आप अपना forge खुद host करते हैं, तो Blender जैसे पहले से बड़े नाम न हों तो कोई आपका software ढूँढ ही नहीं पाएगा
    इसलिए code को शून्य में गुम होने से बचाने के लिए कम-से-कम GitHub mirroring लगभग अनिवार्य हो जाता है
    अगर इससे बचना है और छोटे forges को एक समूह के रूप में प्रतिस्पर्धी बनाना है, तो ऐसा single network चाहिए जहाँ software किसी भी host पर हो, फिर भी मिल सके — और ForgeFed का लक्ष्य यही है
    इससे नए contributors के लिए हर बार अलग forge login बनाने की friction भी घटती है; वह secondary बात है, लेकिन जुड़ी हुई है
  • Git design के स्तर पर decentralized है
    GitHub ने UI, issues और PRs को अच्छी तरह solve करके beginners को भी screen से काम करने लायक बनाया, लेकिन उसी प्रक्रिया में centralization बढ़ा
    federation, Git की philosophy के ज़्यादा करीब है, लेकिन इसका मतलब यह नहीं कि हमें इतनी extreme distribution चाहिए कि किसी node के बंद होते ही upstream गायब हो जाए या खोजा भी न जा सके
    Git availability की समस्या हल नहीं करता, और federation decentralization की philosophy को बनाए रखते हुए availability को बेहतर कर सकता है
  • सबसे बड़ी समस्या आखिरकार discoverability ही है
    बिखरे हुए servers पर मौजूद open source projects को आसानी से ढूँढने का तरीका चाहिए
    GitHub project search सिर्फ़ GitHub के अंदर ही काम करती है
  • interoperable identity provider निश्चित रूप से उपयोगी होगा
    इसके अलावा project host के गायब हो जाने, policy बदल देने, या किसी सरकार द्वारा block किए जाने की स्थिति में भी चीज़ें ज़्यादा resilient हो सकती हैं
  • यहाँ फ़ायदा यह है कि data एक ही जगह, यानी PDS में रहता है, और चाहें तो आप उसे self-host भी कर सकते हैं
    फिर AppView कई PDS के data को एक स्क्रीन पर जोड़कर दिखाता है
    अगर tangled.org enshittify भी हो जाए, तो भी आप किसी दूसरे AppView से बिल्कुल वहीं से आगे बढ़ सकते हैं, और tangled.org को कोई विशेषाधिकार प्राप्त स्थिति नहीं मिलती
    independent forges का social login भी मददगार है, लेकिन व्यक्तिगत रूप से मेरे लिए एक ही account संभालना बेहतर है, और AT protocol की वजह से किसी एक forge के गायब होने पर भी data दूसरे AppView के माध्यम से उपलब्ध रहता है