10 पॉइंट द्वारा hongminhee 2025-03-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें

मुख्य आर्किटेक्चर अंतर: message passing बनाम shared heap

  • fediverse: ईमेल जैसी “message passing” पद्धति का उपयोग

    • संदेश सीधे किसी विशेष प्राप्तकर्ता तक पहुंचते हैं
    • संदेश केवल आवश्यक servers को भेजे जाते हैं, इसलिए यह अधिक efficient है
    • व्यक्ति सस्ते hardware पर भी node चला सकते हैं
  • Bluesky: “shared heap” पद्धति का उपयोग

    • सभी संदेश एक केंद्रीय “relay” में संग्रहित होते हैं
    • उपयोगकर्ता relay से संबंधित जानकारी को filter करते हैं
    • बड़े पैमाने पर centralized infrastructure की आवश्यकता होती है
    • relay चलाने की लागत तेज़ी से बढ़ती है (सिर्फ 4 महीनों में 1TB→5TB)

global view और centralization की समस्या

  • Bluesky: पूरे network का एकसमान view बनाए रखने पर केंद्रित

    • हर appview को पूरे block data जैसी जानकारी चाहिए
    • block lists सार्वजनिक होने से privacy समस्याएं पैदा होती हैं
    • central control के बिना इसे लागू करना कठिन है
  • fediverse: हर server स्वतंत्र रूप से अपनी policy लागू करता है

    • उपयोगकर्ताओं को अधिक autonomy देता है
    • block information को सार्वजनिक न करने के लिए डिज़ाइन किया गया है

protocol openness की तुलना

  • fediverse/ActivityPub: W3C द्वारा अपनाया गया open standard

    • कोई भी इसे स्वतंत्र रूप से implement कर सकता है
    • अलग-अलग software के बीच interoperability सुनिश्चित होती है
    • FEP के माध्यम से community-led development
  • Bluesky/AT Protocol: company-led protocol

    • अभी तक open standard के रूप में इसकी स्थिति स्थापित नहीं हुई है
    • scalability और sustainability सीमित हैं

direct message (DM) का centralization

  • Bluesky: सभी DM एक केंद्रीय server से होकर गुजरते हैं

    • उपयोगकर्ता के PDS या relay से अलग, वे Bluesky कंपनी के जरिए भेजे जाते हैं
    • Bluesky कंपनी सभी DM तक पहुंच सकती है
    • यह “credible exit” की अवधारणा के विपरीत है
  • fediverse: servers के बीच direct delivery mechanism

    • केवल आपके अपने server admin को संदेशों तक पहुंच हो सकती है

portable identity के implementation की समस्याएं

  • Bluesky: DID का उपयोग करता है, लेकिन फिर भी centralization पर निर्भर है

    • did:web और did:plc DNS तथा central registry पर निर्भर हैं
    • शुरुआत में सभी accounts एक ही rotationKeys का उपयोग करते थे
    • उपयोगकर्ता keys को Bluesky द्वारा manage किया जाता है
  • fediverse: nomadic identity की अवधारणा अभी विकसित हो रही है

    • Zot protocol आदि अधिक व्यापक portability प्रदान करते हैं
    • FEP-ef61 जैसे प्रयासों के जरिए लगातार सुधार जारी है

commercial pressure और sustainability

  • Bluesky: venture capital funding पर निर्भर

    • “संस्था भविष्य की दुश्मन है” जैसी सोच मौजूद है
    • paid accounts और ads लाने से commercial pressure बढ़ता है
    • investors के return का दबाव decentralization को कमजोर कर सकता है
  • fediverse: अलग-अलग operators और funding models

    • commercial, non-commercial और personal nodes से बना ecosystem
    • कोई single point of failure नहीं

निष्कर्ष

  • Bluesky, user-friendly interface और Twitter जैसी experience के कारण X का एक अच्छा alternative हो सकता है
  • लेकिन centralized design, operational cost, privacy कमजोरियों और company dependency के कारण यह fediverse का alternative नहीं है
  • दोनों systems के लक्ष्य और design philosophy मूल रूप से अलग हैं, और आदर्श रूप से वे एक-दूसरे के पूरक रूप में विकसित हो सकते हैं

1 टिप्पणियां

 
hongminhee 2025-03-25

ऐसा एक प्रतिवाद भी है: https://hackers.pub/@yurume/0195cc17-b1ed-712e-9ecf-dcc49158220a