Radicle: ओपन सोर्स आधारित peer-to-peer GitHub विकल्प

 (app.radicle.xyz)
2 पॉइंट द्वारा GN⁺ 2024-03-06 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Radicle Heartwood Radicle Protocol का तीसरा implementation है, जो centralized code forge के बिना peer-to-peer तरीके से code collaboration और publishing stack प्रदान करता है
  • repository में developers के सीधे उपयोग के लिए command-line tool rad और network daemon radicle-node शामिल हैं
  • इसे GitHub·GitLab जैसे code forge के विकल्प के रूप में डिज़ाइन किया गया है, और security व decentralization, साथ ही user sovereignty को सुरक्षित रखना इसका मुख्य लक्ष्य है
  • installation environment के लिए Linux या Unix आधारित operating system, Git 2.34 या उससे ऊपर, और ssh-agent सहित OpenSSH 9.1 या उससे ऊपर आवश्यक है
  • यह binary installation और Rust source installation दोनों को support करता है, लेकिन feedback email public Zulip channel पर अपने-आप पोस्ट हो जाती है, जिससे नाम और email address उजागर हो सकते हैं

Radicle Heartwood क्या प्रदान करता है

  • Heartwood Radicle Protocol का तीसरा iteration version है, और peer-to-peer code collaboration व publishing के लिए एक full stack है
  • repository में Heartwood implementation के लिए आवश्यक मुख्य components शामिल हैं
    • rad: user-friendly command-line interface
    • radicle-node: network daemon
  • Radicle को GitHub और GitLab जैसे code forge के विकल्प के रूप में डिज़ाइन किया गया है
    • इसका लक्ष्य security, decentralization, और user sovereignty व freedom को संरक्षित रखना है
  • सामान्य जानकारी Radicle home page पर देखी जा सकती है
  • project discussion Zulip chat में की जा सकती है
  • Radicle कैसे काम करता है, यह Protocol Guide में विस्तार से व्यवस्थित है

इंस्टॉलेशन और रन करना

  • installation requirements इस प्रकार हैं
    • Linux या Unix आधारित operating system

    • Git 2.34 या उससे ऊपर

      • ssh-agent सहित OpenSSH 9.1 या उससे ऊपर
      • binary installation के लिए curl और tar की आवश्यकता है, और latest release निम्न command से install की जाती है
curl -sSf https://radicle.dev/install | sh

- binaries [download](https://radicle.dev/download) page से भी प्राप्त की जा सकती हैं
- source से install करने के लिए **Rust toolchain** की आवश्यकता होती है, और repository के भीतर निम्न commands चलाए जाते हैं

cargo install --path crates/radicle-cli --force --locked --root ~/.radicle
cargo install --path crates/radicle-node --force --locked --root ~/.radicle
cargo install --path crates/radicle-remote-helper --force --locked --root ~/.radicle

- सीधे seed node से भी install किया जा सकता है

cargo install --force --locked --root ~/.radicle \
    --git https://seed.radicle.dev/z3gqcJUoA1n9HaHKufZs5FCSGazv5.git \
    crates/radicle-cli crates/radicle-node crates/radicle-remote-helper

- node के लिए **systemd unit** files `/systemd` folder में हैं, और इन्हें अतिरिक्त customization की शुरुआत के बिंदु के रूप में उपयोग किया जा सकता है
- debug mode में चलाने के लिए [HACKING.md](https://radicle.network/nodes/iris.radicle.network/rad%3Az3gqcJUoA1n9HaHKufZs5FCSGazv5/tree/HACKING.md) देखें

फीडबैक, योगदान, लाइसेंस

  • feedback rad issue, Zulip, या feedback@radicle.dev पर भेजा जा सकता है
  • email से भेजा गया feedback Zulip के public #feedback channel में अपने-आप पोस्ट हो जाता है
    • पोस्टिंग प्रक्रिया में From header सार्वजनिक हो जाता है, जिसमें आमतौर पर नाम और email address शामिल होते हैं
  • योगदान मार्गदर्शिका CONTRIBUTING.md और HACKING.md में है
  • Radicle को MIT License और Apache License 2.0 की शर्तों के तहत वितरित किया जाता है
  • विस्तृत जानकारी LICENSE-APACHE और LICENSE-MIT में है

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

1 टिप्पणियां

 
GN⁺ 2024-03-06
Hacker News की रायें

  • मैं Radicle का सह-संस्थापक हूँ। अगर प्रोटोकॉल की अंदरूनी कार्यप्रणाली के बारे में जानना हो, तो पहले docs देखें: https://docs.radicle.xyz/
    docs अभी लिखे जा रहे हैं

    • docs पढ़ने पर “Radicle repositories public/private हो सकती हैं और source code, documents, arbitrary datasets रख सकती हैं” वाला हिस्सा ध्यान खींचता है।
      अगर यह मूल रूप से P2P file sharing app है, तो abuse को protocol के किस हिस्से में handle किया जाता है, यह जानना चाहूँगा। वरना यह BitTorrent या Winny जैसी पिछली पीढ़ी की file sharing apps से कैसे अलग है, जिनमें लोग movies, music, software जैसी copyrighted content मनमाने ढंग से share करते थे, यह समझ नहीं आता। लगता है कुछ malicious users इसे खराब कर देंगे, और यह भी जानना चाहूँगा कि क्या “private” network अलग किए जा सकते हैं ताकि यह भरोसा हो सके कि हम किसी illegal चीज़ में शामिल नहीं हैं
    • दिलचस्प project है। business model के बारे में जानना चाहूँगा।
      Crunchbase पर लिखा है कि इन्हें 12 million dollars funding मिली है, तो शायद monetization की कोई योजना होगी
    • मैं GitHub या GitLab जैसी proprietary services के replacement को actively नहीं खोज रहा, लेकिन कभी-कभी alternatives के बारे में requests आती हैं। Distributed self-hosting solutions मुझे पसंद हैं, इसलिए Radicle की direction सही लगती है, पर requirements में Linux या Unix-based operating system लिखा होना खटकता है।
      जिन प्रकार के projects में मैं मदद करता हूँ, उनके लिए यह fatal हो सकता है। Code Rust में दिखता है, तो जानना चाहूँगा कि MS Windows support की कोई योजना है या नहीं। Mac OS को Unix family में शामिल मान सकते हैं, है न? Official Windows support न भी हो, तो क्या MSYS2 port संभव है?
      थोड़ा background जोड़ूँ तो, मैं service provider selection जैसे फैसले लेने की position में नहीं हूँ, और एक semi-government organization से जुड़ा हूँ जिसने GitHub पर काफी open source codebase रखा हुआ है। कभी-कभी कुछ ideas suggest करने का मौका मिलता है, लेकिन adoption मेरे अधिकार में नहीं है। इस organization की motivation private provider policies के प्रभाव से बचने वाली resilience बनाने की है, और sustainability या broad accessibility जैसे “अच्छे काम” भी करना चाहती है। एक typical European government organization होने के कारण GitHub ऐसी policies से टकराता है।
      Archiving या network support संभालने वाली दूसरी government agencies भी हैं, लेकिन उनकी capabilities कम हैं या वे पुराने तरीकों में अटकी हैं, और providers द्वारा बिछाए गए traps में भी अक्सर फँसती हैं। उदाहरण के लिए, archiving service ने यह जाने बिना ही DataBricks को पूरी तरह अपना लिया कि वह commercial closed-source product है। इसलिए उस organization से self-hosting solution का अच्छा उपयोग करने की उम्मीद कम है, और distributed solution बेहतर दिखता है। लेकिन कोई tool जो major consumer PC environments पर न चले, इस्तेमाल नहीं किया जा सकता
    • Radicle में कितना budget लगा, कितने लोगों ने कितने समय तक इसे बनाया, और कौन इसका उपयोग कर रहा है, यह जानना चाहूँगा
    • website और application design पसंद आया। कई open source projects visual design में पूरी तरह टूट जाते हैं, और भले ही यह बाहरी चीज़ हो, सुंदर design project के साथ और interact करने की इच्छा जगाता है।
      यह भी जानना चाहूँगा कि पहले और अब adoption के किस level की उम्मीद थी, और actual results उन expectations से मेल खाते हैं या नहीं

  • Radicle पिछले करीब 5 सालों में कैसे evolve हुआ है, यह देखना दिलचस्प रहा। मैंने Protocol Berg 2023 workshop attend की थी, और मुझे लगता है कि उन्होंने काफी powerful और नया कुछ बनाया है।
    खास तौर पर दिलचस्प बात यह है कि collaboration features भी local-first हैं। Internet न होने पर भी patches और issues submit किए जा सकते हैं, और GitHub में कोई समस्या आते ही पूरी team को HN से चिपके रहने की जरूरत नहीं पड़ती

  • उद्देश्य के हिसाब से यह ठीक project लगता है, लेकिन मुझे लगता है कि Git खुद भी पहले से open source और P2P है। Binaries को sh <(curl) से लेने की जरूरत नहीं; किसी दूसरे Git server से connect करके Git commands से सीधे code ला या merge कर सकते हैं।
    Git में जो नहीं है, वह code issues, wiki, discussions, GitHub Pages, और सबसे बढ़कर developer profiles का network है। ऐसा तरीका चाहिए जिसमें project metadata को .git में ही रखा जा सके, ताकि source code commits wiki या issues के साथ mix न हों। git notes जैसे independent references शायद काम आ सकते हैं।
    https://git-scm.com/docs/git-notes

    • Git को कुछ हद तक P2P interaction को ध्यान में रखकर design किया गया था, लेकिन असल में इस तरह distribute होने का कोई तरीका नहीं है। सारी distribution client-server model का उपयोग करती है, क्योंकि सिर्फ Git में P2P network पर सीधे distribute करने की functionality नहीं है।
      उदाहरण के लिए, git clone से मिली repository वही है जो मैंने मांगी थी, इसे verify करने का कोई तरीका नहीं है। इसलिए किसी trusted source, यानी known server से clone करना पड़ता है। यह practical P2P से मेल नहीं खाता।
      Radicle इस समस्या को locally verifiable stable repository identifier[0] देकर हल करता है, और untrusted entities को repositories provide करने देता है।
      [0]: https://docs.radicle.xyz/guides/protocol#trust-through-self-...
    • Radicle issue tracking और pull requests जोड़ता है। शायद कुछ और features भी शामिल होंगे।
      Mobile पर original link के नीचे दिए buttons दबाने पर issue tracking tab, pull request tab आदि दिख सकते हैं
    • Fossil(https://fossil-scm.org) issues, wiki आदि को project repository के अंदर रखता है
    • “सबसे बढ़कर developer profiles का network” — दुनिया को क्या हो गया है, ऐसा लगता है।
      मुझे याद है कि Gerrit पहले code reviews को Git में store करता था
    • Traditional Git हाल की Nintendo-related खबरों जैसी censorship से बच नहीं पाता। यह idea मेरे दिमाग में घूम रहा था, और सचमुच खुशी है कि किसी ने यह मुश्किल काम कर दिखाया

  • दस्तावेज़ में लिखा है कि “केवल वही repository publish करना ज़रूरी है जिसके आप owner या maintainer हैं, और दूसरे maintainers से communicate करना ज़रूरी है ताकि duplicate repository identifiers न बनें”
    मैंने ऐसे लोगों को देखा है जो मेरा code उठाकर GitHub पर डाल देते हैं, और product docs या बीच की UI में “कृपया X न करें, इससे दूसरे users को समस्या होगी” जैसी सूचना डालने पर भी बहुत लोग उसे पढ़ते नहीं, सोचते नहीं, परवाह नहीं करते और सीधे X कर देते हैं। इसलिए लगता है कि बहुत से लोग docs की इस request का पालन नहीं करेंगे; ऊपर से homepage सिर्फ code push करने का तरीका बताता है, और यह “महत्वपूर्ण” request user guide में है जिसे लोग शायद ही पढ़ते हैं
    अंत में, homepage के निर्देशों के मुताबिक जिस open source code पर काम चल रहा है उसे बस push कर देना—जो काफी तर्कसंगत लगने वाला व्यवहार है—protocol और storage के तरीके की वजह से समय के साथ किसी महत्वपूर्ण चीज़ को बिगाड़ या confusing बना सकता है, यही बात काफी चिंताजनक है

    • इसमें कोई खास समस्या लगती नहीं। आज भी repository की आधिकारिक location किसी अलग social network या website जैसे external route से ही मिलती है
      GitHub पर stars की संख्या से अतिरिक्त भरोसा मिल सकता है, और Radicle में उसका equivalent किसी specific repository के seeds की संख्या है
    • docs या instructions ignore करने पर लोगों से चिढ़ने की बात नहीं है। यह बहुत logical व्यवहार है
      आम तौर पर एक दिन की computing में हम दर्जनों prompts देखते हैं, और दर्जनों tools इस्तेमाल करते हैं। उन सभी prompts को पढ़ने और हर tool के docs को ध्यान से पढ़ने में लगने वाले समय के बारे में सोचें तो वह बहुत ज़्यादा होगा
      इसलिए न पढ़कर heuristics इस्तेमाल करना कहीं बेहतर है। उदाहरण के लिए, अगर आप unsaved changes वाले document को बंद करते हैं, तो पता होता है कि dialog “discard?” जैसा होगा, इसलिए उसे पढ़ने की ज़रूरत नहीं। यह अच्छी बात है
      निष्कर्ष यह है कि software design करते समय यह मानकर चलना चाहिए कि लोग ऐसे ही behave करते हैं। आम तौर पर यह संभव होता है। अगर कोई specific example हो, तो “कृपया करें और उम्मीद करें कि लोग पढ़ेंगे” वाली approach से बेहतर solution सुझाया जा सकता है
    • GitHub-style में code में copyright notice डालकर यह बताना कि आपकी repository original है, और copyright notice बदलना illegal बना देना—ऐसा नहीं है क्या? यह यहाँ भी लागू हो सकता है

  • release के लिए बधाई। मैं इस project को देखता आया हूँ और यह काफी mature हो गया है, यह देखकर सच में उत्साह है। अभी GitHub पर मौजूद project को migrate करने का सबसे अच्छा तरीका क्या है, यह जानना चाहता हूँ। यह भी जानना चाहता हूँ कि try करने के लिए कोई mirror mode है या नहीं

    • अभी built-in mirroring नहीं है, लेकिन हम इसे देख रहे हैं। theoretically, हर घंटे GitHub से fetch करके Radicle पर push करने वाला cron job set करना इतना simple होना चाहिए
      git pull github master
      git push rad master

  • आम users के लिए ये repositories कितनी discoverable होंगी, यह जानना चाहता हूँ। https://app.radicle.xyz/robots.txt नहीं दिख रहा, इसलिए लगता है कि search engines इसे fetch कर सकते हैं, और सच में Google और DDG पर site:app.radicle.xyz से search करने पर results आते हैं
    अभी site filter के बिना top पर नहीं आते, लेकिन ranking बेहतर हो सकती है
    CI support और integration करने वाले tools भी हों तो अच्छा होगा। ultimately यह while true; do wait_repo_update; git pull && ./run_ci.sh; done जैसे loop जैसा होगा, लेकिन इसका बेहतर रूप चाहिए जो सिर्फ trusted identifiers के pushes तक limited हो सके
    अंत में artifact storage भी चाहिए। हालांकि Radicle को हर चीज़ solve करने की ज़रूरत शायद न हो। खासकर बड़े binaries share करने वाला distributed network काफी जल्दी unwanted uses के लिए इस्तेमाल होने लगेगा

    • अभी हम कई CI integrations पर काम कर रहे हैं, और अपनी ज़रूरतों के हिसाब से अपना native CI भी बना रहे हैं
    • अच्छा point है। app.radicle.xyz जैसे gateways को शायद crawlers को network की पूरी repository set index करने की अनुमति देनी चाहिए

  • “P2P” या ज्यादा आम तौर पर कहें तो “distributed” का ठीक-ठीक मतलब क्या है, लोग इसे साफ define करें तो अच्छा होगा। अभी यह इतना अस्पष्ट buzzword बन गया है कि इसे किसी भी मतलब में इस्तेमाल किया जा सकता है

    • मैंने इस term का बहुत ज्यादा misuse होते नहीं देखा। Radicle और ज्यादातर P2P systems में इस्तेमाल की जाने वाली definition Wikipedia वाली definition[0] जैसी ही है, खासकर यह हिस्सा कि “peers network में समान अधिकार और capabilities वाले participants होते हैं”
      इसलिए P2P system वह system है जिसमें सभी participants के पास “network के भीतर समान अधिकार” होते हैं। आम तौर पर इसका मतलब यह भी होता है कि सभी वही software run करते हैं
      [0]: https://en.wikipedia.org/wiki/Peer-to-peer

  • इंस्टॉलेशन निर्देश curl -sSf [https://radicle.xyz/install](<https://radicle.xyz/install>;) | sh हैं—उम्मीद तुरंत curl-bash कचरे में ढह गई
    इस तरह का इंस्टॉलेशन तरीका बिना सोचे-समझे development का मजबूत संकेत है। अगर यह project लोकप्रिय हुआ तो शायद हमें एक security disaster देखने को मिलेगा। उम्मीद है कि किसी दिन “open-source P2P GitHub alternative” आएगा जो सबसे खराब इंस्टॉलेशन तरीके से शुरू नहीं होगा

    • यह लगभग बेतुकी हद तक overreaction है
      pipe installer के जोखिम बहुत से लोगों को अच्छी तरह पता हैं। उस logic से तो Homebrew [1](GitHub पर 38 हजार से अधिक stars), PiHole [2](46 हजार से अधिक), Chef [3], RVM [4] और bash में pipe करने वाले 1-step automatic installer इस्तेमाल करने वाले अनगिनत open-source projects को छोड़ देना चाहिए
      ज्यादा उचित प्रतिक्रिया यह होगी कि developers के साथ मिलकर docs में alternative installation methods दिए जाएँ या risks को बेहतर ढंग से समझाया जाए, न कि एक छोटे मुद्दे के लिए पूरा घर जला दिया जाए
      [1] https://brew.sh/
      [2] https://github.com/pi-hole/pi-hole
      [3] https://docs.chef.io/chef_install_script/#run-the-install-sc...
      [4] https://rvm.io/rvm/install
    • यह थोड़ा dramatic reaction नहीं है?
      transfer बीच में रुक जाने वाली समस्या के बारे में, जब तक आपके system में ^(t(e(m(p(d(ir?)?)?)?)?|a(r(g(et?)?)?)?)?|i(n(_(p(a(th?)?)?)?|fo?)?)?|s(u(c(c(e(s?s)?)?)?)?)?|f(a(t(al?)?)?)?|m(a(in?)?)?|w(a(rn?)?)?|u(rl?)?) से match करने वाली कोई खतरनाक command नहीं है, script safe है
      उसे handle करने के बाद, मुझे समझ नहीं आता कि सिर्फ script देना और run command न देना—इनमें फर्क क्या है। अगर review करना है तो script download करके अलग से चला सकते हैं। शायद piped script और downloaded script को detect करने का कोई तरीका था, लेकिन इतनी छोटी script पर शायद काम नहीं करेगा
    • यह रहा [0]। project अभी release से पहले की स्थिति में है, इसलिए कुछ हिस्से अभी संभालने बाकी हैं, और इस समय focus थोड़ा अलग जगह पर है। Rust के cargo से source से build भी किया जा सकता है [1]
      [0] https://files.radicle.xyz/latest/
      [1] https://app.radicle.xyz/nodes/seed.radicle.garden/rad:z3gqcJ...
    • बात यह है कि आप लें या न लें, maintainers पर भरोसा करें या न करें। इंस्टॉलेशन तरीका यह तय करने की चीज़ नहीं है कि maintainers भरोसेमंद हैं या नहीं, और curl-bash होने पर भी यही बात लागू होती है

  • crypto market जब भी ऊपर जाता है, मुझे Radicle की चर्चा सुनाई देती है। क्या कोई इसे seriously इस्तेमाल कर रहा है?
    यह तो झट से downvote हो गया। मैं सच में पूछ रहा हूँ—Radicle में कितना budget लगा, कितने लोगों ने इस पर काम किया, और इसे कौन इस्तेमाल कर रहा है?

    • यह जायज़ सवाल है
      मैं crypto industry में काम करता हूँ और मुझे भी यही impression मिला। Radicle के बारे में आखिरी बार पिछले bull market में सुना था, और bear market में यह शांत रहा। सब कहते हैं कि bear market बनाने का समय होता है, और Radicle तो साफ तौर पर developer tool है, इसलिए यह काफी अजीब है

  • उत्सुक हूँ कि क्या सिर्फ खास nodes के set को repository उपलब्ध कराने वाले use case को support करने की योजना है। शायद ऐसे लोग होंगे जो GitHub पर नहीं रहना चाहते, लेकिन private collaboration करना चाहते हैं

    • है। Radicle में इसे private repository कहा जाता है। यह बाकी network को दिखाई नहीं देता और सिर्फ trusted peers के बीच share होता है
      हालांकि storage के समय यह encrypted नहीं होता, इसलिए इसे trust set में शामिल न होने वाले intermediary nodes पर store नहीं किया जा सकता