atproto में instances नहीं हैं

 (overreacted.io)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • “Bluesky instance” खोजने वाला सवाल, Mastodon के instance model को atproto पर ज्यों का त्यों लागू करता है, जबकि atproto को hosting और app aggregation को अलग रखकर डिज़ाइन किया गया है
  • RSS और Google Reader की तरह डेटा किसी app के अंदर बंद नहीं रहता, बल्कि hosted repository में होता है, और कई apps उस डेटा को लेकर दिखाने के तरीके से काम करते हैं
  • Mastodon instance में hosting·app·identity·federation relation एक ही डिब्बे में बंधे होते हैं, इसलिए admin के फ़ैसले या instance failure का सीधा असर user experience पर पड़ता है
  • atproto में user hosting बदल सकते हैं या नया app बनाकर आज़मा सकते हैं, और Tangled, Semble, Sidetrail जैसे apps Bluesky से अलग काम करते हैं
  • atproto की decentralization को समझने के लिए “Bluesky instances की संख्या” से ज़्यादा यह देखना चाहिए कि alternative hosting migration और नया app ecosystem वास्तव में काम कर रहे हैं या नहीं

RSS और Google Reader के ज़्यादा क़रीब मॉडल

  • RSS के दौर में user अपने ब्लॉग पर पोस्ट करते थे, और Google Reader या Feedly जैसे apps कई ब्लॉगों की पोस्ट को aggregate करते थे
  • पोस्ट Google Reader के अंदर “रहती” नहीं थी, बल्कि अपने-अपने ब्लॉग या hosting location पर बनी रहती थी
  • असली बात hosting और aggregation के अलगाव की है
    • hosting वह जगह है जहाँ वास्तविक content मौजूद होता है
    • aggregation app कई sources के content को दिखाने वाली projection के ज़्यादा क़रीब होती है

केंद्रीकृत social media और Mastodon की प्रतिक्रिया

  • पारंपरिक social media सभी users को एक ही app और एक ही जगह में इकट्ठा करके चलती है
  • इस संरचना में centralization और मज़बूत network effects पैदा होते हैं, और decentralized social network की चर्चा यहीं से शुरू होती है कि इस समस्या को कैसे बाँटा जाए
  • Mastodon का तरीका यह है कि हर community अपनी “छोटी Facebook” या “छोटी Twitter” चलाए, और यही डिब्बा instance कहलाता है

Mastodon instance किन चीज़ों को बाँधता है

  • user किसी खास instance “के अंदर” होते हैं
    • Mastodon login format [email protected] होने की वजह भी यही है कि identity में instance शामिल होता है
    • user कोई अमूर्त “Alice” नहीं, बल्कि “instance #1 की Alice” बन जाती है
  • अलग-अलग instances के users को बातचीत करनी हो, तो instances को एक-दूसरे से messages भेजने-पाने पड़ते हैं
    • अगर Alice instance #1 पर है और Bree instance #2 पर है, और Alice, Bree को follow करती है, तो Bree की पोस्ट instance #1 तक पहुँचाई जाती है
    • इस तरह के delivery relation को federation कहा जाता है
  • hosting और app साथ में बंधे होने के कारण users की instance पर निर्भरता बहुत मज़बूत हो जाती है

instance coupling से बनने वाली सीमाएँ

  • अगर instance admins के बीच टकराव हो जाए, तो वे आपस में federation बंद कर सकते हैं
    • ऐसे में users अपने दोस्तों की पोस्ट देखना बंद कर सकते हैं
  • अगर user का instance बंद हो जाए, तो उस instance से बंधी identity भी गायब हो जाती है
    • क्योंकि followers ने “उस instance के user” को follow किया होता है
  • instances के बीच connection arrows की संख्या O(n²) की दर से बढ़ती है
    • अभी यह बड़ा मुद्दा न हो, लेकिन अगर यह social networking तरीका लोकप्रिय हुआ तो यह महत्वपूर्ण हो सकता है

atproto का मुख्य अंतर

  • atproto, Mastodon-जैसे instance concept को आधार नहीं मानता, बल्कि RSS और Google Reader मॉडल पर लौटता है
  • यह network level पर hosting और aggregation को अलग करता है
    • data hosting में होता है
    • apps कई लोगों की hosting से data aggregate करते हैं
  • इसलिए atproto में instances नहीं हैं
    • hosting बदली जा सकती है
    • apps कई hostings के data को aggregate करते हैं
  • यह संरचना “एक ही app की कई copies चलाने” से कहीं अधिक समृद्ध distributed structure के रूप में देखी जा सकती है

user खुद कैसे decentralize कर सकते हैं

  • user hosting बदल सकते हैं
    • लेखक ने बताया कि उसने अपना atproto data Eurosky पर migrate किया, और कुछ UX समस्याओं को छोड़ दें तो यह अपने-आप हो गया
    • अगर आप और सक्रिय होना चाहें, तो Cloudflare पर मुफ़्त में खुद host भी कर सकते हैं
  • आप नए apps आज़मा सकते हैं या खुद बना सकते हैं
    • Tangled और Semble Bluesky से असंबंधित atproto apps के उदाहरण हैं
    • लेखक ने Sidetrail नाम का app बनाया है, और यह open source है
    • atproto में app बनाने के लिए Statusphere tutorial भी है

“Bluesky instances की संख्या” भटकाने वाली क्यों है

  • Mastodon में decentralization को instances की संख्या से मापना स्वाभाविक है
    • क्योंकि Mastodon में decentralize करने का मुख्य तरीका hosting और app से बंधे ऐसे डिब्बों की संख्या बढ़ाना और उन्हें आपस में बात करने देना है
  • atproto में सभी apps पूरे Atmosphere की projection के ज़्यादा क़रीब हैं
    • यह वैसा ही ढाँचा है जैसा Feedly और Google Reader पूरे Blogosphere को दिखाते थे
  • पूरे Bluesky database server की कई full copies चलाना संभव है, लेकिन यह आम तौर पर उतना उपयोगी नहीं है जितना Google Reader की कई copies चलाना नहीं होता
  • कुछ copies खास ज़रूरतों के लिए मौजूद होती हैं
    • Blacksky अलग moderation philosophy जैसी खास ज़रूरत के लिए एक उदाहरण है
    • reddwarf.app client अपना dedicated database रखे बिना, community द्वारा चलाए जा रहे मुफ़्त cache constellation का इस्तेमाल करता है
  • relay जैसी shared network infrastructure को एक साल तक कम लागत में चलाया गया है

atproto में क्या देखना चाहिए

  • atproto की decentralization को समझने के लिए “Bluesky instances की संख्या” नहीं, बल्कि यह देखना चाहिए
    • क्या लोग alternative hosting पर जा रहे हैं
    • क्या लोग नए apps बना और इस्तेमाल कर रहे हैं
  • hosting और app को अलग करने से closed social और federated social दोनों में टूटे हुए incentives को सुधारा जा सकता है
  • users का data app के बाहर रखना, और apps का उस data के ऊपर aggregate करना ही atproto का मूल है

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

1 टिप्पणियां

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

  • “Bluesky instance कहाँ है?” वाले सवाल को जानबूझकर गलत समझकर ATProto को बढ़ावा देने और ActivityPub को नीचा दिखाने जैसा लगता है
    ऐसा करने से ATProto के relay और उसके फायदे-नुकसान, ActivityPub के account migration और उसके फायदे-नुकसान जैसे दिलचस्प तकनीकी तथ्य छूट जाते हैं या तोड़-मरोड़ दिए जाते हैं, और समान समस्याएँ हल करने वाले दो प्लेटफ़ॉर्म के बीच अनावश्यक टकराव पैदा होता है
    “instance” शब्द का इस्तेमाल server, चल रहे software, virtual machine, container जैसे सामान्य अर्थों में करने वाले लोग भी हो सकते हैं, तो फिर इसे ज़बरदस्ती सिर्फ Mastodon-शैली के कॉन्सेप्ट के रूप में ही क्यों लिया जाए, समझ नहीं आता
    diagram और explanation अच्छे थे, लेकिन ActivityPub पर की गई हल्की-सी चुभन जानकारी देने से ज़्यादा शत्रुता से प्रेरित लगी, इसलिए थोड़ा खटका

    • लेख का tone जानबूझकर थोड़ा playful रखा गया था, लेकिन मेरा मानना है कि “Bluesky instance कहाँ है?” वाला सवाल अक्सर इस architectural misunderstanding से आता है कि app instance की संख्या को decentralization का पैमाना मान लिया जाता है
      “Google Reader instance कहाँ है?” से तुलना करने पर उस सवाल की अटपटी प्रकृति अच्छी तरह सामने आती है, और लेख के अंत के दो diagrams भी शुरुआती atproto/ActivityPub चर्चाओं में अक्सर छूट जाने वाली बातों को काफ़ी अच्छी तरह समझाते हैं
      relay को शामिल न करने की वजह यहाँ लिखी थी: https://news.ycombinator.com/item?id=48600963
      relay मॉडल का मूल हिस्सा कम और performance optimization ज़्यादा है, इसलिए लेख में मैं खुद मॉडल पर फोकस रखना चाहता था
    • यह संदर्भ पर निर्भर करता है, लेकिन ATProto, ActivityPub और Mastodon के आसपास की चर्चाओं में “instance” का मतलब अक्सर user data और profile URL host करने वाला ActivityPub node होता है, और लगता है कि लेख भी उसी संदर्भ को निशाना बना रहा था
      जब किसी शब्द से एक खास कॉन्सेप्ट और संरचना जुड़ने लगती है, तो “decentralized social media” देखते ही बहुत से लोग ActivityPub-शैली की federation structure सोचने लगते हैं, और ATProto को देखकर पूछते हैं, “जिस Bluesky instance में लोग sign up करते हैं, वह सिर्फ एक ही क्यों है?”
      यह पूरी तरह नया दृष्टिकोण भले न हो, लेकिन जिन लोगों के दिमाग में ये पुरानी धारणाएँ जम चुकी हैं, उनके लिए बाद में फिर से लिंक करने लायक एक उपयोगी लेख लगता है
    • ATProto बनाम ActivityPub, शायद Fediverse के पूर्व-पश्चिम चर्च महाविभाजन जैसा लगे
      “filioque” फ़रमान की जगह “federation” की परिभाषा पर दोनों तरफ़ अलग-अलग बातें करने वाले blog post एक-दूसरे के पास जा रहे हों, कुछ ऐसा
    • Mastodon और ATProto के बीच फर्क और तुलना ज़रूरी है
      Fediverse मॉडल मौजूदा social network के नज़रिए से समझना आसान है, लेकिन ATProto एक नया कॉन्सेप्ट है जो user को data sovereignty देते हुए centralized social network की scalability हासिल करना चाहता है

  • मुझे यहाँ की analogy टूटी हुई लगती है
    RSS बिल्कुल भी Google Reader पर निर्भर नहीं था, और अपने चरम दौर में भी उतना निर्भर नहीं था जितना आज email, Gmail पर है
    ATProto में AppView के उपयोगी बनने के लिए relay पर काफ़ी निर्भर रहना पड़ता है, और relay चलाने की लागत भी काफ़ी है
    साथ ही, RSS diagram में पीले घेरे blog को दिखाते हैं, जबकि Facebook post को दिखाने वाले घेरे की प्रकृति अलग है। blog अपने आप में स्वतंत्र होता है
    मेरा मतलब यह नहीं कि ATProto बुरा है, लेकिन यह लेख चीज़ों को साफ़ करने से ज़्यादा उलझाता हुआ लगता है

    • relay अब वास्तव में काफ़ी सस्ते हो गए हैं
      पहले सभी traffic को store करना पड़ता था इसलिए थोड़ा महंगा था, लेकिन sync 1.1 में वह हिस्सा हटा दिया गया, और अब इसे $20 प्रति माह वाले virtual machine पर भी काफ़ी आसानी से चलाया जा सकता है
    • relay, AT Protocol infrastructure के अपेक्षाकृत भारी हिस्सों में से एक है, लेकिन इसकी running cost अभी लगभग $30 प्रति माह है, इसलिए ज़्यादातर लोगों के लिए यह वहन करने लायक है
      सच में महँगी और कठिन चीज़, चाहे centralized हो या decentralized, हमेशा की तरह moderation ही है
      इस लेख के लेखक ने 9 महीने पहले relay के बारे में होने वाली आम ग़लतफ़हमियों पर लिखा था: https://news.ycombinator.com/item?id=45077291#45078223

  • मेरी नज़र में relay वह गोंद है जो ATProto को अच्छी performance के साथ चलाता है
    यह content से निरपेक्ष रहते हुए data ढोता है, और हर AppView को जिन services की जानकारी रखनी होती है उनकी संख्या कम करता है
    जैसा लेख में भी कहा गया है, Mastodon की तुलना में बड़ा सुधार यह है कि relay, AppView और PDS अलग-अलग scaling needs वाले separate services हैं, और यह system design की समस्या का काफ़ी सुंदर समाधान है
    [1] https://atproto.com/guides/glossary

    • सही है, relay ऐसा करने का एक तरीका है
      लेकिन यह एक अदृश्य optimization है, और दूसरी strategies भी हैं, इसलिए लेख में इसे ज़्यादातर छोड़ दिया गया था
      उदाहरण के लिए, आज कई छोटे apps अपना database index खुद नहीं बनाते और Constellation(https://constellation.microcosm.blue/) पर निर्भर रहते हैं, इसलिए वे relay का बिल्कुल इस्तेमाल नहीं करते
    • relay पर content को सीधे हटाया भी जाता है
      दावा यह किया जाता है कि सिर्फ वही content हटाया जाता है जिसे host करना गैरकानूनी हो, लेकिन यह कितना सच है पता नहीं, और आगे चलकर बदलने का जोखिम हमेशा रहता है
      https://docs.bsky.app/blog/blueskys-moderation-architecture#...

  • दोनों तरीकों के अंतर को समझाया गया, यह अच्छा था
    लेकिन “instances जिन समस्याओं को हल करते हैं, ATProto उन्हें कैसे हल करता है” इस सवाल का जवाब नहीं दिया गया, इसलिए खीझ हुई
    उदाहरण के लिए, अगर defederation को बस इतना कहकर टाल दिया जाए कि कभी-कभी किसी अज्ञात वजह से दोस्त की पोस्ट नहीं दिखती, तो “फिर atproto, defederation जिन समस्याओं को हल करता है, उन्हें कैसे हल करता है” इसका जवाब नहीं दिया जा सकता
    इस framing में स्वाभाविक बुनियादी जवाब है: “यह उन्हें हल नहीं करता”

    • अगर सवाल moderation का है, तो यह लगभग वैसे ही काम करता है जैसा आप ऐसी दुनिया में उम्मीद करेंगे जहाँ सब कुछ RSS हो
      hosting स्तर पर, जैसे blogspot.com या Cloudflare कुछ मामलों में block करते हैं, वैसे ही साफ़ तौर पर गैरकानूनी चीज़ों की वजह से hosting provider अकाउंट रोक सकता है
      application स्तर पर, app admin और moderator user-generated content को वैसे ही संभालते हैं जैसे दूसरी web services करती हैं
      यह app developer का चुनाव है; Reddit की तरह user-space moderation के बुनियादी तत्व दिए जा सकते हैं, या Bluesky की तरह अलग moderation service जोड़ी जा सकती है
      ऐसी कोई “community instance” नहीं है जो आपस में लड़ सके, इसलिए defederation भी नहीं है। बस hosting, app, और app developer की पसंद के अनुसार app-level moderation है
    • मेरे हिसाब से बेहतर सवाल है, “ActivityPub, defederation से पैदा होने वाली समस्याओं को कैसे हल करता है?”
      यह मूल रूप से वैसा ही है जैसा Microsoft email में करता है। सबसे बड़े providers को छोड़कर बाकी के messages गिरा देना, और federate तो करना लेकिन व्यवहार में users को message पहुँचाने के लिए Microsoft या किसी दूसरे बड़े स्थापित provider का इस्तेमाल करने पर मजबूर करना
      फिर नया instance messages पहुँचा नहीं पाता और users हासिल नहीं कर पाता। बड़े स्थापित providers के पास नए instance से federation न करने की विकृत प्रोत्साहन संरचना बन जाती है
      लंबे समय में इस तरह की architecture choice oligopoly को और मजबूत करती है
      कहा जाता है कि spam रोकने के लिए यह ज़रूरी है, लेकिन कुछ providers ऐसा नहीं करते, और DKIM व reverse DNS आदि ठीक से सेट हों तो Gmail तक आम तौर पर delivery हो ही जाती है; ऐसा भी नहीं कि वे spam की समस्या ज़्यादा झेलते हों
      साफ़ विकल्प है client-side filtering। अगर Microsoft जैसे operator की जगह uBlock जैसी प्रकृति वाले filter-list provider filters दें, तो वे कोई खास instance नहीं चलाते, इसलिए सबको अपने instance पर खींच लाने का incentive नहीं होता
    • वह उन समस्याओं को हल नहीं करता
      हाँ, अगर ऐसा कोई वैकल्पिक ब्रह्मांड हो जहाँ पूरे firehose को consume कर सकने वाले AppView बहुत ज़्यादा हों, उनके बीच स्वतंत्र रूप से चुना जा सके, और उन्हें सीधे सस्ते में चलाया भी जा सके, तो बात अलग है
      ATProto उस RSS के ज़्यादा करीब है जहाँ RSS को desktop या mobile RSS reader से नहीं, बल्कि सिर्फ़ Google Reader या उसी पैमाने की किसी clone service से पढ़ा जा सकता हो

  • अगर वह बत्तख की तरह quack करता है, तो वह बत्तख ही है
    account के साथ एक single PDS जुड़ा होता है, और DID उसी PDS की ओर इशारा करता है जो user का canonical data feed भी है और write target भी
    data replicate किया जा सकता है, लेकिन PDS को authoritative source माना जाता है
    यह distributed architecture की तुलना में client/server architecture के कहीं ज़्यादा करीब है
    न कोई P2P database है, न DHT है, न peers पर write किया जाता है। write PDS पर होता है, और उस write को चुनिंदा रूप से mirror किया जाता है
    discovery भी DNS से होती है, इसलिए peers से data नहीं पूछा जाता
    relay से connection peer की तरह नहीं, बल्कि PDS पर canonical रूप से hosted data की copy माँगने वाले client की तरह होता है
    PDS को instance और relay को mirror कहना मुझे ज़बरदस्ती नहीं लगता

    • ऐसा कहना ठीक है
      बस यह उस अर्थ से अलग है जिसमें Mastodon की बात करने वाले लोग आम तौर पर “instance” कहते हैं
      Mastodon में instance data hosting, app, community, और moderation का मिला-जुला अविभाज्य bundle होता है

  • मेरी समझ में ATproto consistency के लिए असली decentralization से समझौता करता है, और Mastodon व ActivityPub ज़्यादा सुलभ decentralization के लिए असली consistency से समझौता करते हैं
    क्योंकि सामान्य self-hosting उपयोगकर्ता के लिए ActivityPub node चलाना, AT का content relay चलाने की तुलना में कहीं ज़्यादा सुलभ है
    AT में आख़िरकार जिस चीज़ को “decentralize” किया जा सकता है, वह केवल अपना data है, और यह network के किसी हिस्से के साझा स्वामित्व से ज़्यादा अपने data के स्वामित्व के क़रीब है
    HN पर भी यह बात पहले कई बार दोहराई जा चुकी है

    • दिलचस्प नज़रिया है, लेकिन मेरी मौजूदा समझ के हिसाब से AtProto ज़्यादा सुलभ और ज़्यादा decentralized लगता है
      ActivityPub में instance चलाने का मतलब data, application, और आगे की scaling समस्याओं तक सब कुछ संभालना है, इसलिए या तो आपको खुद संचालन की ज़िम्मेदारी लेनी पड़ती है या किसी और के instance से बँधना पड़ता है
      और अगर चुना हुआ instance पसंद न आए और आप वहाँ से जाना चाहें, तो अगर चीज़ें अभी तक नहीं बदली हैं, तो लगभग शून्य से फिर शुरू करना पड़ता है
      AtProto में वही पहचान बनाए रखते हुए किसी दूसरे application platform पर जाना आसान है, और platform से data export करके self-host करना भी, भले user experience कठिन हो, कम से कम संभव तो है
      उदाहरण के लिए, मैंने हाल ही में पहली बार Tangled इस्तेमाल किया और अपने मौजूदा bsky-आधारित domain (h14h.com) से login कर सका। नया account या नया username बनाने की ज़रूरत नहीं पड़ी; लगा जैसे मैं पहले से वहीं था
      VPS पर git repository को self-host करने की सेटिंग भी ज़्यादा से ज़्यादा आधे दिन का काम था, और यह लगभग बिना ध्यान दिए backend service की तरह चलती है
      सबसे बुरे हाल में tangled.org पर “repository पुरानी है और शायद नवीनतम Tangled के साथ compatible न हो” जैसा banner दिखेगा, और नवीनतम version के साथ Docker image को फिर से build करके deploy कर देने से बात बन जाएगी
      architecture के लिहाज़ से AtProto को समझना निश्चित रूप से दिमाग़ में बिठाना ज़्यादा कठिन है, लेकिन असली उपयोगकर्ताओं तक पहुँचाने के मामले में यह कहीं ज़्यादा सरल लगता है
    • मुझे नहीं पता कि “असली” decentralization जैसा कुछ होता भी है या नहीं
      मेरे दिमाग़ में यह किसी एक slider से ज़्यादा trade-offs का buffet है
      वैसे, AP दुनिया में भी व्यक्ति और छोटी टीमें relay, mirror, cache, AppView वगैरह चला रही हैं। बस यह बात सही है कि scale बढ़ने पर यह ज़्यादा महँगा हो सकता है
    • वह बात आंशिक रूप से सही है, लेकिन पूरी तस्वीर नहीं बताती
      AT केवल consistency ही नहीं, बल्कि apps के पार shared data model भी देता है
      इसी वजह से apps दूसरे apps के content को refer और render कर सकते हैं। यह typed JSON के web जैसा कुछ है, और अलग-अलग apps उसी network को देखने के अलग lenses हैं
      कोई भी मौजूदा data के ऊपर नया experience बना सकता है, और AP में इसके बराबर की चीज़ लगभग नहीं है
      AP में data app से बँधा होता है, जबकि AT में यह ज़्यादा ऐसा है जैसे दुनिया भर का data रखने वाले एक global database को सभी apps query कर रहे हों
      समझ नहीं आता कि चर्चा हमेशा relay पर आकर क्यों अटक जाती है। आजकल चाहें तो relay लगभग $30 प्रति माह में चलाया जा सकता है, और Bluesky या community relays को मुफ़्त में भी इस्तेमाल किया जा सकता है
      कई apps relay का बिल्कुल इस्तेमाल नहीं करते और Constellation(https://constellation.microcosm.blue/) जैसे community index पर निर्भर रहते हैं। कुछ apps तो अपना server या database तक नहीं चलाते
    • Mastodon में भी content relay होते हैं
      लेकिन मैं उल्टा यह कहना चाहूँगा कि ATproto ज़्यादा decentralized है, या कम से कम उस दिशा में जाने की कोशिश करता है
      ActivityPub की दुनिया में identity, application, और hosting मूल रूप से आपस में जुड़े हुए हैं
      Lemmy इस्तेमाल करने के लिए या तो आपको उस Lemmy instance पर दूसरा स्थायी रूप से अलग ActivityPub account बनाना पड़ता है, या फिर आप Lemmy को केवल उतनी हद तक इस्तेमाल कर सकते हैं जितनी हद तक आपका Mastodon instance ऐसे messages भेजना जानता हो जिन्हें Lemmy समझ सके
      हर नया ActivityPub app एक नई interoperability समस्या पैदा करता है। क्योंकि हर app अपनी identity और hosting खुद own करता है
      ऐसा कोई तरीका नहीं है जिससे मेरा self-hosted Mastodon instance किसी Lemmy server को मेरी identity दे सके, और वह Lemmy server फिर मेरे instance से कह सके कि वह मेरी तरफ़ से content host करे
      ATProto जिस स्तर की बात करता है, उसके बराबर आने के लिए कम से कम इतना तो चाहिए। हालाँकि यह नहीं पता कि यह वास्तव में मौजूद ATProto पर कितनी हद तक लागू होता है, और वास्तव में मौजूद ActivityPub भी अपने समर्थकों के दावों जितना interoperable नहीं है

  • यह ब्लॉग architecture को अच्छी तरह समझाता है
    लेकिन व्यवहार में मुझे लगा कि “समस्या” यह है कि Bluesky कंपनी ही मुख्य app चलाती है और ज़्यादातर user data को host करती है
    protocol स्तर पर यह decentralized है, लेकिन वास्तविक system नियंत्रण के नज़रिए से अब भी बहुत centralized है
    इसका मतलब यह नहीं कि यह ज़रूर Bluesky की गलती है, लेकिन अब तक चीज़ें कुछ इसी तरह चली हैं, ऐसा लगता है

    • “समस्या” यह है कि लोग समस्या ढूँढ रहे हैं
      यह Bluesky या ATProto की कोई ख़ास बात नहीं है; चाहे लाभ कमाने वाला संगठन हो, non-profit हो, या volunteers का समूह, कोई न कोई हमेशा कुछ न कुछ समस्या बनाने के लिए ढूँढ ही लेता है
      मैं न तो investor हूँ, और Bluesky के साथ मेरा कोई conflict of interest भी नहीं है, सिवाय इसके कि मैं शुरुआती users में था। अपनी सीमाओं के भीतर मैं protocol, company, और website—तीनों को समझता हूँ
      site और app अच्छे से काम करते हैं। लोग बड़ी और बेहतर solution बनाने से ज़्यादा समस्या ढूँढने में लगे रहते हैं
      ज़्यादातर लोग Lemmy या Mastodon जैसे अस्थायी P2P solution नहीं चाहते। वे चाहते हैं कि content एक ही जगह हो, और उस entity को जवाबदेह ठहराया जा सके
      इसलिए मुझे नहीं लगता कि P2P social networks कभी mass adoption तक पहुँचेंगे। Lemmy और Mastodon के आसपास का drama, Twitter, Reddit, और Facebook—तीनों को मिलाकर जितना है उससे भी ज़्यादा रहा है
      यही मेरी 2 cents है, और लगता है मेरे spouse और दोस्त भी ऐसा ही सोचते हैं
    • दूसरे apps, अलग user data hosting, personal hosting, और अलग backend services मौजूद हैं
      सिद्धांत और व्यवहार—दोनों में यह decentralized है
      हाँ, क्योंकि Bluesky सबसे बड़ा हिस्सा चलाता है, इसलिए community या mindshare के स्तर पर इसे decentralized न कहना समझ में आता है, लेकिन वह भी बदल रहा है
    • क्या यह सच में अच्छी तरह समझाता है?
      यह बस कहता है कि “instances नहीं हैं”, लेकिन यह नहीं बताता कि वह architecture authentication, synchronization, और discovery जैसी समस्याओं को कैसे पार करता है

  • Google Reader का उदाहरण चुनना अशुभ सा लगता है
    RSS, Google Reader बंद होने के बाद भी बचा रहा, लेकिन RSS का इस्तेमाल करने वाले सभी कम्युनिटी नहीं बचे, और उनमें से बहुतों को आज भी नहीं पता कि RSS क्या है
    इसे विकेंद्रीकृत बताने का दावा करते हुए, विकेंद्रीकृत इकोसिस्टम के विशाल सामाजिक केंद्रीकरण की ओर एक अच्छे उदाहरण की तरह बार-बार इशारा करना लगभग फ्रॉयडियन जैसा लगता है
    खासकर क्योंकि हम उसका अंत पहले से जानते हैं
    Google Reader ने कई RSS घरों को एक जगह जोड़ा, social graph और comments जैसी वैल्यू जोड़ी, लेकिन Google executives की मनमर्जी से ढह गया, RSS को लगभग मार दिया और एक प्रभावशाली social graph को नष्ट कर दिया
    ऐसी तुलना से ATProto पर ज्यादा भरोसा नहीं बनता

    • atproto का सार यह है कि social graph भी “blog/RSS” वाली तरफ रहता है
      apps बस उसे index करते हैं
      इसलिए इस तुलना में, कोई भी उसी graph का उपयोग करके Google Reader को फिर से जगा सकता है या उससे प्रतिस्पर्धा कर सकता है
      अगर जिज्ञासा हो, तो अभी http://leaflet.pub वास्तव में इसी तरह काम कर रहा है
    • अशुभ है, लेकिन सटीक है
      बस यह कल्पना कीजिए कि आप desktop या mobile RSS reader इस्तेमाल नहीं कर सकते, और RSS केवल Google Reader या उसी पैमाने की किसी clone service से ही पढ़ सकते हैं
    • लेकिन अब हमारे पास शानदार RSS readers बहुत हैं
      हाल ही में भी किसी ने NetNewsWire का जिक्र किया था

  • अहम फर्क यह है कि blogs की अपनी website होती है, और RSS feed में पूरा लेख देना जरूरी नहीं होता
    Bluesky आमतौर पर ऐसे काम नहीं करता। PDS में जो कुछ भी है, उसकी replication होती है
    और आसान replication के लिए पूरे blog post को PDS में डालने के लिए प्रोत्साहित भी किया जा रहा है
    फिर जो भी उसे index करना चाहे, वह उसकी copy ले सकता है, और वे उसके साथ जो चाहें करें, उस पर आपका कोई नियंत्रण नहीं रहता
    ऐसा करना जरूरी भी नहीं है। आप अपनी website पर blog डाल सकते हैं और Bluesky पर सिर्फ link पोस्ट कर सकते हैं

    • यह सीधे blogs को scrape करने वाले scrapers से अलग कैसे है?
    • ईमानदारी से कहूँ तो, यह इसलिए भी है क्योंकि atproto एक raw data protocol है
      atproto account के ऊपर HTTP frontend रखना अनुशंसित तरीका है, और वास्तव में बहुत लोग ऐसा करते भी हैं
      मैं भी pfrazee.com पर ऐसा ही करता हूँ, और atproto में मौजूद मेरे leaflet blog posts भी मेरे blog पर render होते हैं

  • RSS वाली तुलना गलतफहमी पैदा करती है
    Atproto apps, user के कंप्यूटर पर चलने वाले और content source से सीधे जुड़ने वाले RSS readers जैसे नहीं हैं
    Atproto apps ऐसे servers हैं जो यह नियंत्रित करते हैं, फ़िल्टर करते हैं और आकार देते हैं कि पाठक को कौन-सा content दिया जाएगा
    Atproto apps अपनी मर्जी से censorship, shadowban, ad exposure, और algorithmic feed बना सकते हैं
    user बेबस हो जाता है, और creator सिर्फ चिल्लाने के अलावा कुछ न कर सकने वाला पीड़ित बन जाता है
    यह तथ्य कि कोई भी data को कहीं भी host कर सकता है, पूरी तरह बेमानी है अगर उस data को distribute करने का कोई तरीका ही न हो

    • यह सही नहीं है
      सबसे पहले, आप कोई दूसरा AppView इस्तेमाल कर सकते हैं जो ऐसा न करता हो
      feeds को user की पसंद के अनुसार algorithmic बनाया जा सकता है, और अगर कई apps हों, तो आप किसी एक केंद्रीय निर्माता की मनचाही algorithm से बंधे नहीं रहते