BlueSky कैसे काम करता है

 (steveklabnik.com)
2 पॉइंट द्वारा GN⁺ 2024-02-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • BlueSky, Twitter·Mastodon जैसा एक माइक्रोब्लॉगिंग ऐप है, लेकिन इसका बड़ा उद्देश्य AT Protocol(atproto) पर बड़े पैमाने के distributed social applications संभव हैं या नहीं, यह सत्यापित करना है
  • atproto blockchain·DAO·NFT नहीं है, बल्कि encryption और Merkle tree जैसी तकनीकों का उपयोग करने वाला एक federated protocol है, जिसमें उपयोगकर्ता द्वारा signed records को PDS, Relay और App View मिलकर प्रोसेस करते हैं
  • scalability उस संरचना से आती है जिसमें उपयोगकर्ता का Personal Data Server(PDS) हर follower को सीधे पोस्ट नहीं भेजता, बल्कि Relay नेटवर्क डेटा इकट्ठा करके firehose के रूप में उपलब्ध कराता है
  • moderation को “speech vs reach” मॉडल में बाँटा गया है, जहाँ content replication और exposure control अलग किए जाते हैं, और labeler, feed generator, App View filtering और blocking लागू करते हैं
  • स्थिर DID और domain-आधारित handle account portability देते हैं, लेकिन BlueSky द्वारा चलाया जाने वाला did:plc resolution service अब भी centralization की बहस का विषय है

BlueSky और atproto का संबंध

  • BlueSky इस समय माइक्रोब्लॉगिंग एप्लिकेशन के रूप में काम करता है, लेकिन बड़े विज़न में यह Authenticated Transfer Protocol, यानी atproto की संभावनाओं को साबित करने वाला शुरुआती एप्लिकेशन है
  • BlueSky वेबसाइट कहती है कि “सोशल मीडिया इतना महत्वपूर्ण है कि उसे कुछ कंपनियों के नियंत्रण में नहीं होना चाहिए, और हम social internet की एक open foundation बना रहे हैं ताकि हर कोई उसका भविष्य बना सके”
  • क्योंकि BlueSky एक कंपनी है, इसलिए यह संशय हो सकता है कि “जिस चीज़ पर कंपनियों का नियंत्रण नहीं होना चाहिए, उसे एक कंपनी ही बना रही है”, लेकिन डिज़ाइन का केंद्र ऐप से ज़्यादा atproto है
  • atproto बड़े पैमाने के distributed social applications के लिए एक federated protocol है

क्रिप्टोकरेंसी नहीं, एक distributed protocol

  • “distributed network” और “protocol” जैसे शब्दों के कारण atproto क्रिप्टोकरेंसी जैसा लग सकता है, लेकिन यह क्रिप्टोकरेंसी नहीं है
  • यह blockchain, DAO, NFT नहीं है, और केवल encryption तथा Merkle tree जैसी कुछ तकनीकों का उपयोग करता है

atproto की बुनियादी संरचना

  • atproto एक federated architecture अपनाता है, जिसमें कई पक्ष सिस्टम के अलग-अलग हिस्से चलाते हैं और आपस में संवाद करते हैं
  • इसे बड़े user base को ध्यान में रखकर डिज़ाइन किया गया है, ताकि जो पक्ष लोड संभाल सकते हैं वे ज़्यादा भूमिका निभाएँ और जो नहीं संभाल सकते, उनका बोझ कम रहे
  • लेख लिखे जाने के सप्ताह तक BlueSky 50 लाख users पार कर चुका था, और इसे शुरुआती Twitter की तुलना में कहीं अधिक स्थिर माना गया
  • अभी atproto 100% public आधार पर है, और इसमें private message जैसी सुविधा नहीं है
    • क्योंकि federated system में private features को सही ढंग से लागू करना कठिन है, इसलिए गंभीर कमियों वाली सुविधा देने के बजाय उसे ठीक से लागू करने का विकल्प चुना गया है
    • फिलहाल इसका उपयोग केवल उसी सामग्री के लिए उपयुक्त है जो public रहने पर भी ठीक हो

record, repository, App View, Relay

  • उपयोगकर्ता cryptographically signed record बनाते हैं, और यह signature लेखक को प्रमाणित करता है
  • record, Lexicon नाम के schema का पालन करता है
  • record को repository में रखा जाता है, और यह repository HTTP तथा WebSocket उपलब्ध कराने वाली service की तरह काम करती है
    • ऐसी service को आमतौर पर PDS(Personal Data Server) कहा जाता है
    • उपयोगकर्ता अपना PDS खुद चला सकते हैं, या किसी और द्वारा hosted PDS का उपयोग कर सकते हैं
  • एप्लिकेशन नेटवर्क में संग्रहित record पढ़ते हैं और उनके ऊपर features बनाते हैं
    • ऐसी service, क्योंकि यह जानकारी का एक विशेष दृष्टिकोण दिखाती है, App View कहलाती है
    • एप्लिकेशन बनाना मतलब Lexicon परिभाषित करना, उस Lexicon का उपयोग करने वाले records पढ़ना, और बाकी को अनदेखा करना
  • PDS के बीच सीधे notifications भेजने की विधि में scalability की बड़ी समस्या है
    • अगर हर नई पोस्ट को सीधे सभी followers की repository तक भेजना पड़े, तो यह अक्षम होगा और लोकप्रिय repository चलाने की लागत बढ़ जाएगी
  • Relay इस समस्या को कम करने के लिए नेटवर्क की जानकारी इकट्ठा करके firehose के रूप में उपलब्ध कराता है
    • वास्तविक App View सीधे repository देखने के बजाय Relay को देखता है
    • जब publisher पोस्ट करता है, repository Relay को सूचित करती है, और followers वह परिणाम देखते हैं जिसे App View ने Relay output को filter करके तैयार किया हो
    • Relay बड़ा हो सकता है और उसकी operating cost भी अधिक हो सकती है, लेकिन ऐसे छोटे Relay की भी कल्पना की जा सकती है जो केवल कुछ विशेष users के subset को propagate करें

“speech vs reach” moderation model

  • atproto social applications के लिए protocol है, इसलिए यह सिर्फ लोगों को जोड़ने के तरीकों पर नहीं, बल्कि कनेक्शन तोड़ने के तरीकों पर भी विचार करता है
  • BlueSky का moderation model speech vs reach में विभाजित है
    • speech layer, सामग्री के अर्थ की परवाह किए बिना उसे नेटवर्क पर replicate करने का काम करती है
    • reach layer ऐसे tools देती है जो उस चीज़ की पहुँच सीमित करें जिसे उपयोगकर्ता नहीं देखना चाहते
  • BlueSky “moderation नहीं करता” या “सिर्फ free speech को महत्व देता है”, यह कहना सटीक नहीं है
    • moderation tools protocol में ही शामिल हैं, और वे BlueSky के अलावा अन्य applications की content पर भी काम कर सकते हैं
    • उपयोगकर्ता किसी और के moderation choices या moderation की अनुपस्थिति पर निर्भर नहीं होते, बल्कि अपने moderator चुन सकते हैं

Feed generator

  • atproto में feed को एक अलग service feed generator के रूप में अलग किया गया है
  • feed generator, Relay द्वारा बनाए गए firehose को लेकर अपनी पसंद के मानदंडों के आधार पर content को filter और sort करके सूची दिखाता है
  • उपयोगकर्ता अपने बनाए feed को दूसरे users के साथ साझा कर सकते हैं
  • उदाहरण feed:
    • Quiet Posters: उन लोगों की पोस्ट दिखाता है जो बहुत कम लिखते हैं
    • the ‘Gram: केवल वे पोस्ट दिखाता है जिनमें फोटो संलग्न हों
    • My Bangers: अपनी लोकप्रिय पोस्ट दिखाता है
  • BlueSky की एक बड़ी ताकत यह है कि उपयोगकर्ता अपने algorithmic feed खुद बना सकते हैं और उन्हें आसानी से साझा कर सकते हैं
  • feed, atproto में अपेक्षाकृत हाल में जोड़ा गया feature है, इसलिए यह अभी पूरी तरह परिपक्व न हो और आगे बदल भी सकता है

Labeler और network-level moderation

  • Labeler वह service है जो content या account पर label लगाती है
  • उपयोगकर्ता किसी खास labeler को subscribe कर सकते हैं, और पोस्ट के label के आधार पर उनका अनुभव बदल सकता है
  • labeler operator की इच्छा के अनुसार काम कर सकता है
    • पोस्ट पर automatic algorithm चला सकता है
    • इंसान सीधे approve या reject कर सकते हैं
    • blocklist या NSFW filter के रूप में इस्तेमाल हो सकता है
  • label feature मौजूद है, लेकिन लेख लिखे जाने के समय यह स्पष्ट नहीं था कि users खुद labeler चला सकते हैं या नहीं
    • BlueSky अपना खुद का labeler चलाता है
    • external release के बारे में अभी जानकारी नहीं है
  • feed, App View और labeler को मिलाकर उपयोगकर्ता एप्लिकेशन के अंदर और बाहर moderation experience चुन सकते हैं
    • एक feed में केवल SFW देख सकते हैं, और कहीं और NSFW content की अनुमति दे सकते हैं
    • blocklist बनाकर साझा कर सकते हैं
  • क्योंकि moderation tools एप्लिकेशन में नहीं बल्कि protocol level पर काम करते हैं, इसलिए atproto पर बने दूसरे applications में भी वही labeler इस्तेमाल किए जा सकते हैं
    • अगर atproto पर Instagram clone बनता है, तब भी वही blocklist labeler उपयोग किया जा सकता है
    • किसी उपयोगकर्ता को अगर एक जगह block किया है, तो चाहें तो उसे हर जगह block किया जा सकता है

Mastodon-style instance model से अंतर

  • atproto का मॉडल Mastodon की तरह किसी खास “instance” पर “account” होने वाले तरीके से अलग है
  • “अगर मेरा instance defederate हो जाए तो क्या होगा” जैसे सवाल यहाँ उसी रूप में लागू करना कठिन है
  • हाँ, किसी खास PDS से आई पोस्ट पसंद न होने पर उन्हें ignore करके मिलता-जुलता लक्ष्य हासिल किया जा सकता है
  • लेकिन यह निर्णय server owner उपयोगकर्ता के account की तरफ़ से नहीं लेता, बल्कि यह स्वयं उपयोगकर्ता का चुनाव होता है

DID, handle, account portability

  • atproto की पहचान का मूल DID(Decentralized Identifier) है
    • उदाहरण DID, did:plc:3danwc67lo7obz2fmdg6jxcr जैसा दिखता है
  • उपयोगकर्ता जो वास्तविक पहचान देखते हैं, उसमें handle भी साथ होता है, और handle एक domain name होता है
    • उदाहरण: @steveklabnik.com
    • BlueSky पर sign up करने वालों को @username.bsky.social जैसे handle मिल सकते हैं
  • क्योंकि DID स्थिर होता है, इसलिए handle को @steveklabnik.bsky.social से @steveklabnik.com में बदलने पर followers के लिए कोई रुकावट नहीं आती और UI में केवल handle बदलता है
  • domain को handle के रूप में उपयोग करने के लिए, PDS द्वारा बनाया गया DID लेकर उस domain के DNS में TXT record जोड़ना होता है
  • जो users DNS नहीं जानते, वे भी BlueSky और NameCheap की partnership के ज़रिए बिना तकनीकी जानकारी के domain register करके उसे handle के रूप में सेट कर सकते हैं
  • account portability, DID और cryptographic signatures पर आधारित है
    • किसी खास DID वाले व्यक्ति द्वारा बनाई गई content signed होती है और नेटवर्क पर replicate होती है
    • किसी “account” को बंद करने के लिए उस key के उपयोग को जबरन रोकना होगा जो उपयोगकर्ता के पास है, लेकिन नेटवर्क के डिज़ाइन में दूसरे पक्षों को उस key तक पहुँच नहीं होती
    • PDS बंद हो जाने पर भी नेटवर्क से content backfill की जा सकती है और यह बताया जा सकता है कि account नए PDS पर चला गया है

did:web और did:plc पर बहस

  • BlueSky दो तरह के DID methods को support करता है
    • did:web: domain name आधारित तरीका
    • did:plc: BlueSky द्वारा लागू किया गया स्वयं का तरीका
  • did:plc में plc का अर्थ “placeholder” है, और BlueSky इसे आगे भी support करने की योजना रखता है
  • did:plc की कमजोरी यह है कि सही जानकारी resolve करने के लिए BlueSky द्वारा चलाए जाने वाले service पर निर्भर रहना पड़ता है
    • उदाहरण lookup plc.directory पर किया जा सकता है
    • इसी संरचना के कारण BlueSky पर यह आलोचना होती है कि वह नेटवर्क डिज़ाइन की मूल सीमाओं से अधिक ताकत के साथ users को ban कर सकता है
  • कुछ कारण ऐसे भी हैं जिनसे इसे घातक समस्या नहीं माना जाता
    • अगर न चाहें तो did:web का उपयोग किया जा सकता है
    • बेहतर system आने पर migrate करने लायक डिज़ाइन रखा गया है
    • भविष्य में did:plc governance को consensus model में ले जाया जा सकता है
    • दूसरे पक्ष भी did:plc service चलाकर उसका उपयोग करा सकते हैं

BlueSky का atproto पर निर्मित होना

  • BlueSky, atproto नेटवर्क के ऊपर बना एक एप्लिकेशन है
  • BlueSky App View और उसे उपयोग करने वाला web application चलाता है
  • वह web app से sign up करने वाले users के लिए PDS भी चलाता है, और उन PDS के बीच संवाद कराने वाला Relay भी चलाता है
  • BlueSky दो तरह के Lexicon जारी करता है
    • com.atproto.*: नेटवर्क के किसी भी एप्लिकेशन के लिए आवश्यक low-level tasks
    • app.bsky.*: BlueSky-विशेष tasks
  • BlueSky का product goal यह है कि users इन तकनीकी विवरणों को जाने बिना भी इसे उपयोग कर सकें
    • क्योंकि इसमें instance नहीं हैं, इसलिए account creation के लिए instance चुनने जैसा flow नहीं है
    • host बंद हो जाए तो भी migrate किया जा सकता है, और followers को इसकी चिंता भी नहीं करनी पड़ती

atproto पर नया एप्लिकेशन बनाना

  • atproto एप्लिकेशन Lexicon बनाने से शुरू होता है
  • उसके बाद नेटवर्क के डेटा में से उस Lexicon से संबंधित डेटा को प्रोसेस करने वाला App View चलाया जाता है
  • एप्लिकेशन को यह भी सुनिश्चित करना होता है कि users अपने PDS पर उस Lexicon का उपयोग करके डेटा लिख सकें

डिज़ाइन में मुख्य विभाजन

  • atproto और BlueSky की भूमिका का विभाजन एक महत्वपूर्ण डिज़ाइन तत्व है
  • BlueSky जैसी “killer app” नेटवर्क का उपयोग करने का कारण देती है
  • BlueSky स्वयं भी atproto पर वास्तव में एप्लिकेशन बनाया जा सकता है या नहीं, यह सत्यापित करने वाली dogfooding की भूमिका निभाता है

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

1 टिप्पणियां

 
GN⁺ 2024-02-26
Hacker News की राय

  • यह काफी अच्छी तरह डिज़ाइन किया हुआ लगता है, और ActivityPub की बड़ी समस्याओं में से कुछ को हल करता दिखता है
    पहले मुझे Bluesky में दिलचस्पी नहीं थी, लेकिन अब अकाउंट बनाने का मन हो रहा है

    • Bluesky और AT Protocol की मुख्य समस्या तकनीकी खूबियों से ज्यादा उसके मजबूत NIH (Not invented here) रवैये में है
      सबके इस्तेमाल वाले user@host और WebFinger जैसे मौजूदा protocols के बजाय इसने “डोमेन को पहचान के रूप में इस्तेमाल करने” का रास्ता चुना, और certificates में ACME पहले से जिस तरीके को संभालता है उससे सीख नहीं ली, इसलिए किसी ने Bluesky पर s3.amazon.com डोमेन claim कर लिया https://www.reddit.com/r/programming/comments/138hlf2/s3_dom...
      साथ ही एक नया remote call protocol XRPC बनाया, और code generation-आधारित data schema Lexicon भी इस्तेमाल करता है, जिसका protobuf या jsonld से नया होने के अलावा फायदा स्पष्ट नहीं है
      ऐसे “open network” पर भरोसा करना मुश्किल है जो लगातार दूसरे ecosystems का सम्मान करने या उनसे बात करने की इच्छा नहीं दिखाता, और यह भी शक होता है कि साझा ज्ञान को ठुकराते हुए इसके design में कितनी और आम गलतियां घुस गई होंगी
    • AT Protocol तकनीकी रूप से बेहतर दिखता है, लेकिन सामाजिक रूप से असफल होने में आसान ढांचा लगता है
      असली communities से अलग relay और moderation services को कोई install और maintain करे, इसके लिए सामाजिक प्रोत्साहन नहीं है; इसलिए बचते हैं सिर्फ पैसों वाले incentives—paid services, ads डालना, data mining, और information manipulation
      जब data distribution और moderation centralized हो जाते हैं, तो hosting cost और human cost दोनों ही बड़े business बन जाते हैं, और यह दिशा असल में Bluesky के अलावा किसी और के लिए अपना relay या moderation service चलाना रोकने जैसी हो जाती है
      ActivityPub की कमियों के बावजूद, “gate वाली community” जैसा approach users को server से जुड़ाव महसूस कराता है, और operators व moderators को users को service देने पर गर्व महसूस कराता है
      AT Protocol तकनीकी रूप से कई relays और moderation services की अनुमति देता है, लेकिन असल दुनिया में कितने बनेंगे, यह सवाल है
      social network protocol को सिर्फ शुद्ध तकनीकी और adversarial नजरिए से आंकना गलती है। server पर निर्भरता न रहने के बदले आप घनिष्ठ community से भी अलग हो जाते हैं, और फिर कुछ भी दांव पर नहीं रहता
      data, identity और community के लिहाज से खोने को कुछ न होना दो धार वाली तलवार है

  • मेरी जानकारी में अभी सिर्फ एक relay है
    कई relays बनने पर हर relay network को अलग तरह से देखेगा, और जो relay ज्यादा posts शामिल करेगा वही बेहतर relay होगा
    एक dominant relay के बजाय relay diversity सुनिश्चित करना काफी मुश्किल हो सकता है, और यह कुछ-कुछ वैसा लगता है जैसे alternative DNS systems traction पाने की कोशिश करते हैं। ऐसे में अगर मेरी post dominant relay में capture नहीं हुई, तो कोई रास्ता नहीं दिखता
    अभी बहुत शुरुआती दौर है, इसलिए शायद ऐसा न हो; और dominant relay हो भी तो GitHub भी इतना बुरा नहीं है, और alternatives भी हैं

    • पहले मुझे Bluesky काफी confusing लगता था, लेकिन हाल में समझ आया कि confusion मुख्यतः terminology की वजह से था
      system को [microblog] -> [indexer] -> [client] कहें तो समझना आसान हो जाता है
      असल में और भी ज्यादा components हैं, लेकिन Bluesky का basic कामकाज मोटे तौर पर ऐसा ही है; बस नाम उम्मीद से अलग रखे गए लगते हैं
      indexer की जरूरत इसलिए है क्योंकि user ID system में static नहीं रहती। DID:PLC hash के substring से शुरू होता है और फिर “key rotation” की वजह से समय के साथ user को पता चले बिना user ID बदलने जैसा अजीब cryptographic rearrangement होता है
      इसे LiveJournal जैसे system की तरह सोचें, जहां handles लगातार बदलते रहते हैं और उस बदलाव को track करने के लिए किसी authority की जरूरत होती है। बेशक, title या Markdown support के बिना सिर्फ छोटे messages post किए जा सकते हैं
      निजी तौर पर मैं एक नए DID:PLC का इंतजार कर रहा हूं जो static public key ले और private key से messages sign करे। track करने वाली चीजें बहुत कम हो जाएंगी, और self-hosting व local-first development काफी आसान हो जाएंगे
    • जरूरत पड़ने पर client यानी App View शायद कई relays को parallel में इस्तेमाल कर सके
      यह ऐसी local GitHub UI जैसी संरचना है जो कई GitHub instances से data लाती है, जहां अलग-अलग लेकिन overlap कर सकने वाले repository sets host होते हैं
      यह कई NNTP servers से newsgroups जोड़कर दिखाने वाले Usenet client जैसा भी है
    • मेरा अनुमान है कि illegal content पर फैसले के अंतर को छोड़ दें तो सभी relays के पास पूरा data होगा
      जिज्ञासा है कि आपको क्यों लगता है कि हर relay network को अलग तरह से देखेगा

  • मेरा सवाल यह है कि BlueSky भरोसेमंद तरीके से कैसे वादा कर सकता है कि वह protocol के सिर्फ खुले हिस्सों का इस्तेमाल करेगा
    BlueSky असल में काफी centralized दिखता है, इसलिए first-party client के ATProto client ही होने की कोई तकनीकी वजह नहीं दिखती
    short या medium term में ऐसा करना user trust के साथ बड़ा विश्वासघात होगा, लेकिन ActivityPub की वास्तविक distributed संरचना यहां ज्यादा मजबूत safeguard जैसी लगती है

    • first-party BlueSky client से आपका क्या मतलब है, समझ नहीं आया
      अगर मतलब यह है कि first-party relay और PDS किसी दूसरे protocol से communicate कर सकते हैं, तो आपकी चिंता ठीक से समझ नहीं आ रही
      दो ActivityPub clients भी आपस में non-ActivityPub protocol से बात कर सकते हैं
    • सारा code open source है, इसलिए भरोसा किया जा सकता है
      वे असल में ऐसा कर भी रहे हैं, और अगर वे ऐसा न करने की दिशा में बदलना शुरू करेंगे तो लोगों को बहुत जल्दी पता चल जाएगा

  • “बोलने और reach” के फर्क तक जाना अच्छा है, लेकिन लंबे समय में simplicity की वजह से Mastodon ज्यादा समझदार विकल्प जैसा लगता है
    अल्पकाल में Mastodon की feed curation निश्चित तौर पर ज्यादा कठिन है, इसलिए वह कम मजेदार या कम उपयोगी हो सकता है
    मुख्य सवाल यह है कि अगर कोई काल्पनिक, शायद अमीर या ताकतवर दुर्भावनापूर्ण actor यहां खेल बिगाड़ना चाहे, तो वह कैसे कर सकता है
    लेख में “feed कैसे काम करती है, यह ठीक से नहीं पता” जैसे अंदाज में इस हिस्से को बहुत सतही तौर पर टाल दिया गया है, जो काफी संदिग्ध लगता है। ऐसा लगता है कि उन्हें अच्छी तरह पता है कि feed कैसे काम करेगी, और यह भी पता है कि वहीं शक्ति और पैसा है, इसलिए वे उसे अपने पास रखना चाहते हैं

    • “feed कैसे काम करती है, यह ठीक से नहीं पता” वाला सारांश उचित नहीं लगता
      लेखक ऐसा कहते हैं: “feeds atproto में हाल ही में जोड़ी गई सुविधा हैं, इसलिए वे मौजूद तो हैं, लेकिन शायद अभी feature-complete नहीं हैं, और आगे बदल भी सकती हैं। देखते हैं। मेरे नज़रिए से वे अच्छी तरह काम करती हैं, लेकिन मैं low-level technical details तक follow नहीं कर रहा हूं।”
      ठीक ऊपर वाले पैराग्राफ में यह संदर्भ भी है: “दूसरे microblog tools की तुलना में BlueSky की killer feature में से एक पूरी user choice है। अगर मैं अपना feed algorithm बनाना चाहूं, तो बना सकता हूं और उसे दूसरों के साथ आसानी से share कर सकता हूं।”
    • मुझे नहीं पता कि किस हिस्से से यह मतलब निकला कि feed के काम करने का तरीका नहीं पता
      feeds open source हैं, अभी मौजूद हैं, और आप उन्हें खुद run भी कर सकते हैं
      “खेल बिगाड़ना” से किस खेल को किस अर्थ में कहा जा रहा है, यह भी साफ नहीं है। यहां बहुत सारे moving parts हैं

  • यह idea अच्छा लगता है कि अगर user hosting provider से अलग moderation provider चुन सके, तो instance चुनने की चिंता कम करनी पड़ेगी
    हालांकि instance को अब भी स्थानीय रूप से illegal content host न करने के लिए moderation करनी पड़ेगी
    आखिर में instance चलाने वालों के लिए यह काफी मुश्किल काम बन सकता है, और काफी बड़ी उलझन पैदा कर सकता है। हो सकता है मैं गलत समझ रहा हूं

    • content host करने वाले व्यक्ति को अपने host किए गए content के कानूनी परिणामों को संभालना ही होगा, और अंततः इससे बचा नहीं जा सकता
      हालांकि कोई भी protocol इस्तेमाल करें, यह बात समान ही है
    • आपने गलत नहीं समझा। मेरे हिसाब से Bluesky की decentralization लगभग नकली है
      PDS के लिए एक ठीक-ठाक Ubuntu box काफी है, लेकिन यह लेख भी मानता है कि relay महंगा और विशाल central control point है
      Bluesky की spam response योजना क्या है? शायद relay पर block करने जैसा कुछ होगा
      DID server भी एक और central control point है
      फिर भी PDS आप अपनी मर्जी से चला सकेंगे

  • Bluesky के बारे में एक मजेदार trivia, जिसे कुछ समय पहले वाले लेख से जोड़कर देखें तो यह भी एक इंसान के नाम से लिया गया कहा जा सकता है
    CEO का नाम चीनी में सचमुच blue sky है

    • मजेदार बात यह है कि मेरे जुड़ने से पहले ही Twitter ने project का नाम bluesky रख दिया था
      यह संयोग है। हालांकि मेरा middle name चीनी में bluesky का मतलब रखता है

  • यह छोटा comic भी अच्छा है: https://bsky.social/about/welcome-to-bluesky-comic

  • अगर Bluesky did:plc support बंद कर दे, तो क्या मौजूदा PLC identities सब टूट जाएंगी?
    PLC उस service को ping करने वाली structure है, इसलिए जिज्ञासा है

    • https://plc.directory को mirror किया जा सकता है, और अगर ऐसा होता है तो नया mirror authoritative server बन सकता है

  • third-party labelers को लेकर मैं skeptical हूं
    misuse को कैसे रोका जा सकता है?

    • user चुनता है कि कौन-से third-party labelers subscribe करने हैं
      अगर labeler service अपनी position का misuse शुरू करती है, तो user उसे disconnect कर सकता है
      Bluesky labelers को ecosystem में कैसे fit करना चाहता है, इसका विस्तृत explanation https://github.com/bluesky-social/proposals/tree/main/0002-l... पर है
    • यह इस बात पर निर्भर करता है कि आप किस तरह के misuse की बात कर रहे हैं
      मैं अपनी राय दे सकता हूं, लेकिन सवाल इतना broad है कि समझ नहीं आ रहा कहां से जवाब शुरू करूं
    • हम जल्द ही moderation के बारे में काफी ज्यादा publish करने वाले हैं, लेकिन labelers की basics यह हैं
      network में कोई भी किसी भी चीज को label कर सकता है, जिसमें दूसरे labelers भी शामिल हैं
      apps users को subscribe करने के लिए labelers दिखा सकते हैं, ठीक वैसे जैसे अभी Bluesky की custom feeds दिखती हैं
      apps यह भी curate कर सकते हैं कि labelers कैसे दिखें और rank हों, ठीक वैसे जैसे वे popularity के आधार पर custom feeds दिखाते और rank करते हैं, जिसे अभी likes और saves से व्यक्त किया जाता है

  • “मॉडरेशन टूल reach layer का हिस्सा हैं। वे सभी speech को लाते हैं, लेकिन मुझे जो नहीं देखना है उसकी reach को सीमित करने का तरीका देते हैं” वाला approach आखिरकार “देखना नहीं चाहते तो आंखें बंद कर लो” जैसी moderation लगती है
    मुझे पता है कि यह Silicon Valley में पसंद की जाने वाली philosophy है, लेकिन मुझे यह मूल रूप से flawed लगती है
    कुछ मामलों में ऐसे जायज़ हालात होते हैं जहां असंबंधित दूसरे लोगों को किसी विषय पर बात करने या कुछ content पाने से रोकना चाहिए
    इसका typical उदाहरण cyber harassment, doxxing और revenge porn है। दो या उससे ज्यादा लोग किसी तीसरे व्यक्ति को नुकसान पहुंचाने के तरीके पर बात करते हैं, या निजी, अपमानजनक या झूठी जानकारी public करते हैं
    पीड़ित के feed से यह जानकारी हटाना पूरी तरह बेकार है, और संभव है कि वह शुरुआत में पीड़ित के feed में दिखे ही नहीं। नुकसान इस बात से होता है कि दूसरे लोग उस content को देखते हैं या चर्चा में शामिल होते हैं, और वह नुकसान वास्तविक होता है
    पारंपरिक moderation systems में moderator पोस्ट को सबके लिए delete कर सकता है या offender को block कर सकता है, ताकि ऐसा व्यवहार रुक जाए। “सिर्फ content छिपाने” वाले system में यह संभव नहीं है
    shared block lists या “labels” भी काम नहीं करते। content consumers के पास उसे block करने की प्रेरणा नहीं होती, बल्कि वे revenge porn देखना चाहते हैं
    block करना पीड़ित चाहता है, लेकिन पीड़ित के पास सभी को किसी खास block list का इस्तेमाल करने के लिए मजबूर करने की ताकत नहीं है। क्योंकि इस system का मूल विचार ही यह है कि कोई भी किसी दूसरे पर block list थोप नहीं सकता

    • इस क्षेत्र में आगे और भी चीजें आएंगी। इस लेख में सामान्य मामलों पर ध्यान दिया गया है, बुरे मामलों को नहीं संभाला गया है
      टीम ने इन समस्याओं की समीक्षा की है और “experts से भी सलाह ली” है, लेकिन यह अभी ongoing work है, इसलिए मुझे नहीं लगता कि मैं इस पर बोलने का अधिकारी हूं
      “क्योंकि लोग उसे रोकने के बजाय देखना चाहते हैं, इसलिए labels काम नहीं करते” वाला हिस्सा उस problem space में शामिल है जिसे टीम ने स्पष्ट रूप से स्वीकार किया है
      अतिरिक्त रूप से, यहां देखें: https://lobste.rs/s/shseqz/how_does_bluesky_work#c_vjvmei