ओपन सोशल

 (overreacted.io)
7 पॉइंट द्वारा GN⁺ 2025-09-27 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • जैसे open source सॉफ्टवेयर इंफ्रास्ट्रक्चर का मानक बन गया है, वैसे ही सोशल ऐप्स में भी 'open social' पैरेडाइम उभर रहा है
  • AT Protocol उपयोगकर्ताओं को अपने social data का सीधा स्वामित्व और नियंत्रण देता है, जिससे यह मौजूदा social platforms से अलग एक अवधारणा पेश करता है
  • Social data अब किसी एक खास सेवा के भीतर बंद नहीं रहता, बल्कि उपयोगकर्ता द्वारा प्रबंधित personal storage में संग्रहीत होता है
  • इससे ऐप्स के बीच data reuse और remix संभव होता है, और सेवा बंद हो जाने पर भी डेटा गायब नहीं होता बल्कि बना रहता है
  • open social के विस्तार के साथ उपयोगकर्ता-नेतृत्व वाला data ownership और flexible scalability प्रमुख मूल्य के रूप में उभरने की संभावना है

परिचय: open source की सफलता और नई धारा

  • Open source ने बहुत विरोध के बावजूद आज common infrastructure की नींव के रूप में अपनी जगह बना ली है
  • पहले की तुलना में अब open source चुनना समस्या नहीं माना जाता, और महत्वपूर्ण software क्षेत्रों में open source डिफ़ॉल्ट बन चुका है
  • अब हम social apps के क्षेत्र में 35 साल पहले के open source जैसे एक मोड़ का सामना कर रहे हैं
  • 'Open social' नाम की नई धारा सामने आई है, और Bluesky का AT Protocol इसकी सबसे प्रभावशाली implementation माना जा रहा है

वेब की बुनियादी संरचना और personal data ownership

  • पहले के web में alice.com, bob.com जैसे व्यक्तिगत पते होते थे, और हर उपयोगकर्ता अपनी अलग जगह का स्वामी होता था, जिस पर वह स्वतंत्र रूप से content प्रकाशित करता था
  • यदि hosting पसंद न आए तो किसी और जगह जाना संभव था, और पता वही बना रहता था, इसलिए पुराने links भी नहीं टूटते थे
  • इसी वजह से उपयोगकर्ता किसी खास hosting provider पर निर्भर नहीं होते थे, और providers को प्रतिस्पर्धा करनी पड़ती थी
  • यानी web की decentralized design की वजह से डेटा उपयोगकर्ता के हाथ में था, और providers केवल सेवा प्रदाता की भूमिका में थे

आधुनिक social network: data ownership का खोना

  • आज लोग अपनी साइट चलाने के बजाय कंपनियों द्वारा दिए गए @alice, @bob जैसे IDs लेकर social media apps पर पोस्ट करना ज़्यादा सामान्य मानते हैं
  • पोस्ट, comments, likes जैसी डेटा एक खास social company के database में store होती है
  • इसी संरचना की वजह से search, feed, recommendations, notifications जैसी social aggregation सुविधाएँ संभव हुईं
  • लेकिन इसके साथ मुख्य डेटा हमारे स्वामित्व में नहीं रहने का दुष्प्रभाव भी पैदा हुआ
  • उपयोगकर्ता अपने बनाए डेटा और रिश्तों को आज़ादी से साथ लेकर बाहर नहीं जा सकते

समस्या: platform में बंद उपयोगकर्ता

  • उपयोगकर्ता यदि चला जाए तो उसे अपने बनाए पूरे connection graph को पीछे छोड़ना पड़ता है
  • hosting provider बदलना आसान नहीं है, और platform छोड़ते ही connections और data दोनों खो देने की समस्या पैदा होती है
  • platform यह जानते हैं, इसलिए वे उपयोगकर्ताओं पर हानिकारक बदलाव (विज्ञापनों की भरमार, algorithm में विकृति, features हटाना आदि) भी थोप सकते हैं
  • data backup या export होने पर भी वह अक्सर social context खो चुका 'dead data' ही होता है, जिसे कहीं और फिर से जीवित करना मुश्किल है

Open social: data ownership और network की वापसी

  • open social में @alice.com जैसे domain-based handles के माध्यम से social data का वास्तविक स्वामित्व उपयोगकर्ता को दिया जाता है
    • नाम @alice.com की तरह मेरे अपने domain से जुड़ा होता है
  • उपयोगकर्ता personal storage (repository) के माध्यम से अपने द्वारा बनाए गए सभी social data को सीधे प्रबंधित करता है
    • पोस्ट, comments, follows जैसी गतिविधियाँ personal repository (repo) में दर्ज होती हैं
    • storage एक साधारण web server होता है, जो JSON format के records को सुरक्षित रखता है
    • पता at://alice.com/... के रूप में होता है, इसलिए इन्हें एक-दूसरे से जोड़ा जा सकता है
  • AT Protocol आधारित storage DNS, HTTP, JSON पर काम करता है, और हर डेटा hyperlinked JSON के रूप में संग्रहीत होता है
  • तकनीक न जानने वाले लोगों के लिए भी ऐप में साइन-अप करते समय storage अपने-आप बन सकता है, और डेटा ऐप से अलग उपयोगकर्ता के स्वामित्व में बना रहता है
  • डेटा उपयोगकर्ता के storage में रहता है, इसलिए service provider बदल जाने पर भी data ownership और connectivity बनी रहती है

Open social apps की संरचना और उपयोग

  • हर open social app CMS की तरह उपयोगकर्ता के social storage के किसी हिस्से को प्रबंधित करता है, और अब ऐप केवल उपयोगकर्ता के storage में read/write करने वाला tool बन जाता है
  • उदाहरण के लिए Bluesky, Tangled, Leaflet जैसे अलग-अलग apps का data एक ही उपयोगकर्ता के storage में साथ मौजूद रह सकता है
    • Bluesky पर पोस्ट लिखने से उसका record मेरे storage में रहता है, और Tangled में किसी project को star करने पर वह भी मेरे storage में जुड़ जाता है
    • data formats को टकराव से बचाने के लिए namespaces (जैसे app.bsky.post, sh.tangled.star) से अलग किया जाता है
    • समय के साथ मेरा storage कई apps से आए डेटा का संग्रह बन जाता है

Data openness से ecosystem में बदलाव

  • क्योंकि डेटा खुले रूप में store होता है, इसलिए apps के बीच integration, नई services का development, एक-दूसरे के data को संदर्भित करना, reuse करना, remix करना आसान हो जाता है
  • कोई app बंद हो जाए तब भी डेटा उपयोगकर्ता के storage में रहता है और दूसरी services में दोबारा इस्तेमाल हो सकता है
  • नए apps मौजूदा network के संबंधों और data का इस्तेमाल करके 'cold start' (शुरुआती network बनाने की समस्या) को पार कर सकते हैं
  • चूँकि यह data कोई भी पढ़ सकता है, इसलिए दूसरा app इसे लाकर profile photo दिखा सकता है या मौजूदा follow relationships का वैसा ही उपयोग कर सकता है
  • app बंद हो जाने पर भी डेटा user storage में रहता है, और कोई दूसरा app उसे फिर से निकालकर इस्तेमाल कर सकता है

Aggregation और तकनीकी चुनौतियाँ

  • उपयोगकर्ताओं का data अलग-अलग storages में बँटा रहता है, लेकिन WebSocket subscriptions के ज़रिए data change event streams लेकर उन्हें local database में reflect किया जा सकता है
  • बड़े relay (मध्यस्थ server) के माध्यम से पूरे network के events प्राप्त किए जाते हैं और ज़रूरी events को filter किया जाता है
  • data records cryptographic signatures से सुरक्षित होते हैं, जिससे भरोसेमंदता और consistency सुनिश्चित होती है
  • उदाहरण के तौर पर Graze, Slices जैसी infrastructure सेवाएँ open social aggregation को support करती हैं

Aggregation functions कैसे काम करती हैं?

  • हर उपयोगकर्ता का storage अलग होता है, लेकिन apps उपयोगकर्ता storage से आने वाले real-time event streams को लेकर अपने database में लिखते हैं
  • Bluesky जैसे relay servers पूरे stream को इकट्ठा करके भेजते हैं, और apps अपनी रुचि वाले events चुनकर store करते हैं
  • इस तरह बना database search, feed, recommendation जैसी सुविधाएँ तेज़ी से दे सकता है
  • data records cryptographic signatures से सुरक्षित होते हैं, जिससे भरोसेमंदता और consistency सुनिश्चित होती है: relay पर भरोसा किए बिना भी data की सत्यता जाँची जा सकती है
  • Graze, Slices जैसी infrastructure सेवाएँ open social aggregation को support करती हैं

बड़ा परिप्रेक्ष्य

  • पुराना web: उपयोगकर्ता अपनी content और address पर नियंत्रण रखते थे
  • आज के social apps: aggregation सुविधाएँ हैं, लेकिन डेटा company-owned databases में बंद है
  • open social: aggregation बनाए रखते हुए भी डेटा उपयोगकर्ता के हाथ में रहता है
  • apps अब सिर्फ उपयोगकर्ता के data को इकट्ठा करके दिखाने वाली खिड़की बन जाते हैं
  • service खत्म हो जाए तब भी डेटा रहता है, और दूसरा app उसे नए संदर्भ में फिर से दिखा सकता है

निष्कर्ष

  • Personal web के फ़ायदे (data ownership, hosting की स्वतंत्रता, links का बने रहना) और closed social networks की ताकत (aggregation, scalability) को जोड़ना ही open social का मूल है
  • open social उपयोगकर्ता-नेतृत्व वाला data ownership, apps के बीच स्वतंत्र data mobility, और service continuity सुनिश्चित करता है
    • जैसे open source ने कहा था, “code उपयोगकर्ता का होना चाहिए”, वैसे ही “data भी उपयोगकर्ता का होना चाहिए”
    • यह closed platforms में उपयोगकर्ताओं के data और connectivity खोने की समस्या का समाधान करता है
  • अगर अधिक open social products सामने आते हैं, तो apps के बीच की सीमाएँ धुंधली होंगी और data स्वाभाविक रूप से बहने वाला ecosystem विकसित होगा
    • अंततः ऐसा भविष्य आ सकता है जहाँ उपयोगकर्ता वास्तव में data और network को नियंत्रित कर सकें
  • शुरुआती दौर में इसे कुछ उत्साही developers और users आगे बढ़ाएँगे, लेकिन साझा बुनियाद मज़बूत होने पर एक दिन खुला मॉडल जीत सकता है
    • decentralized systems या federation जैसे technical concepts जाने बिना भी लोग व्यावहारिक लाभ (data interop, आसान migration, continuity) महसूस कर पाएँगे
    • open social समर्पित community की दीर्घकालिक मेहनत और cumulative effect के साथ धीरे-धीरे फैलता जाएगा

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

3 टिप्पणियां

 
shakespeares 2025-10-05

Instagram भी यादों को संजोने की जगह है, यह सही है, लेकिन अपनी मर्ज़ी से उससे बाहर निकलना मुश्किल लगता है.
डेटा को साझा करने और इस्तेमाल करने के मामले में, मुझे लगता है कि कुछ हद तक समझौता करना पड़ता है.
 
kimjoin2 2025-09-27

KakaoTalk... ss
 
GN⁺ 2025-09-27
Hacker News की राय

  • AT Protocol, Bluesky का सिस्टम है, इसलिए शुरू में मुझे लगा कि यह ActivityPub का कॉर्पोरेट वर्ज़न होगा, लेकिन यह लेख पढ़ने के बाद मुझे यह बात काफ़ी पसंद आई कि डेटा मेरी चुनी हुई repository में स्टोर होता है। यह मेरे सामान्य सिद्धांतों से भी मेल खाता है: मेरा मानना है कि फ़िल्टरिंग जैसी चीज़ें लिखते समय करने की बजाय पढ़ते समय करना बेहतर है। इसलिए जो कुछ मैं चाहता हूँ, वह सब अपनी repository में डालूँ और दूसरे लोग उसे पढ़कर इस्तेमाल कर सकें — यह संरचना अच्छी लगती है। तीरों को देखकर ऐसा लगता है जैसे कमेंट मेरी repository में जा रहे हों, लेकिन शायद यह सिर्फ़ आइडिया समझाते समय आई थोड़ी-सी अशुद्धि है। कुल मिलाकर यह बहुत बढ़िया और decentralised संरचना लगती है। लेकिन जब मैंने वास्तव में AT में अलग PDS खुद चलाने की कोशिश की, तो पता चला कि यह काफ़ी polished और अच्छी तरह पैक किया गया है, फिर भी कुछ prerequisites हैं:

    1. SSL जैसी चीज़ों को अपने-आप हैंडल करता है
    2. HTTPS/WSS सर्वर चलाकर कई RPC प्रोसेसिंग को सपोर्ट करता है इसकी वजह से, भले ही मैं व्यवहार में https://roshangeorge.dev और at://roshangeorge.dev दोनों इस्तेमाल करना चाहूँ, दूसरे वाले मामले में https://roshangeorge.dev/xrpc और wss://roshangeorge.dev चाहिए। इसलिए आख़िर में मुझे https://roshangeorge.dev और at://at.roshangeorge.dev, साथ ही https://at.roshangeorge.dev, wss://at.roshangeorge.dev के रूप में चलाना पड़ा। बेशक यह छोटी-सी बात है और पूरी दिशा में कोई समस्या नहीं बनती। फिर भी इसका ज़िक्र करना चाहूँगा।

    • लगता है मैंने दो तरह के तीर इस्तेमाल करके भ्रम पैदा कर दिया। ठोस तीर (@alice.com से नीचे जाने वाला) ownership दिखाता है। यह रंग-आधारित grouping जैसा ही है। नीला रंग मतलब सब कुछ Alice का है। डॉटेड तीर records के बीच link है। यह <a href> जैसा है; कोई भी record, चाहे किसी भी repository में हो, किसी और से लिंक कर सकता है। अगर कोई मेरी post पर comment करता है, तो वह comment comment करने वाले की repository में जाता है और मूल पोस्ट से जुड़ जाता है। डेटा मॉडल को ऐसे डिज़ाइन करने की वजह यह है कि अगर index करने वाले के पास दोनों records हों, तो वह इस relation को आसानी से reconstruct कर सके। उदाहरण के लिए, अगर Bob, Alice की पोस्ट पर comment करता है, तो Bob का comment Bob की repository में होगा और Alice की पोस्ट Alice की repository में। मेरी पोस्ट पर कोई comment लिखे, तो वह comment हमेशा उसी व्यक्ति की repository में रहेगा। मुख्य धारणा यह है कि आप किसी दूसरे की repository में record बना ही नहीं सकते।

    • डिफ़ॉल्ट PDS packaging, SSL handling को अपने-आप सपोर्ट करती है, लेकिन यह अनिवार्य नहीं है; बस डेवलपर्स के लिए आसानी से लागू करने लायक बनाया गया है। at:// URI, at://DID/... के रूप में होता है, और इंसानों के पढ़ने लायक handle को DNS TXT record (_atproto.roshangeorge.dev) के ज़रिए DID से map किया जाता है। DID, एक ऐसे document से जुड़ता है जो सर्वर की location बताता है, इसलिए HTTPS/WSS routes कहीं भी रखे जा सकते हैं। साथ ही, मेरी पोस्ट पर likes, replies वगैरह, वह action करने वाले व्यक्ति की repository में जाते हैं, मेरी repository में नहीं। इस हिस्से पर आपकी intuition सही थी।

  • मुझे लगता था कि ActivityPub बेहतर protocol है और AT सिर्फ़ उसका सस्ता नक़ल संस्करण है, लेकिन यह लेख देखकर समझ आया कि AT काफ़ी बेहतर है। असली बात यह है कि कई programs एक ही identity शेयर कर सकते हैं। यह सच में बहुत बड़ी क्षमता है, और इससे मेरा नज़रिया सचमुच खुल गया।

    • ATProto की ज़्यादातर व्याख्याएँ data ownership पर फोकस करती हैं, लेकिन असल में data processing के मामले में ActivityPub ज़्यादा ताकतवर है। ATProto दुनिया को public रूप में देखने वाली संरचना है, इसलिए हर event एक trusted global AppServer को दिखता है और उसे खुद फ़ैसला करना पड़ता है; इस वजह से feed generation, access permissions वगैरह सब trusted intermediaries पर निर्भर हो जाते हैं। ActivityPub उल्टा RSS या email जैसा है: मेरा सर्वर सिर्फ़ उन्हीं feeds को मैनेज करता है जिन्हें मैंने subscribe किया है, और inbox सीधे उन्हीं posts से बनता है जिन तक मेरी पहुँच है। Bluesky में Twitter की तरह "private likes" संभव नहीं होने की वजह भी यही है। हर AppView को नेटवर्क की सभी posts के likes की संख्या खुद track करनी पड़ती है, जो बहुत झंझट भरा है। लंबी अवधि में मुझे लगता है कि ActivityPub की संरचना ज़्यादा फ़ायदेमंद होगी। और "कई programs एक ही identity शेयर करते हैं" — यह तो शुरुआती ActivityPub डिज़ाइन में भी था। बस शुरुआती लोकप्रिय implementations ने अपनी मौजूदा संरचना में फिट करने के लिए इसे हटा दिया।

    • AT बनाम AP बहस बहुत जटिल है। हमारे community में भी इस पर कई बार चर्चा हो चुकी है, इसलिए संदर्भ के लिए एक thread छोड़ रहा हूँ: https://github.com/bevyengine/bevy/discussions/18302

    • यह सुनकर खुशी हुई कि यह पहलू आपसे जुड़ा। हमेशा AP से तुलना होना थोड़ा थकाऊ है, क्योंकि दोनों का scope ही अलग है।

    • distributed systems engineer के नज़रिए से इसी तरह का एक लेख भी दिलचस्प हो सकता है। https://atproto.com/articles/atproto-for-distsys-engineers

    • तो क्या इसका मतलब यह है कि कोई centralised identity service मौजूद है?

  • कौन-सा distributed protocol जीते, इससे मुझे फ़र्क नहीं पड़ता, लेकिन ATProtocol सैद्धांतिक रूप से अच्छा लगने के बावजूद, व्यवहार में ActivityPub मुझे धीरे-धीरे ज़्यादा आकर्षक लगने लगा है। मैं Lemmy पर काफ़ी सक्रिय रहता हूँ, और यह काफ़ी जीवंत और मज़ेदार है।

    1. AT users में 99.99% Bluesky पर ही केंद्रित हैं। यह एक कंपनी-चालित सेवा है। वे भले कहें कि वे protocol को नियंत्रित नहीं करते, लेकिन व्यवहार में वही protocol का dominant instance हैं, इसलिए इसमें अपने हिसाब से बदलाव करने का जोखिम है। यहाँ तक कि यह चिंता भी है कि 5 साल बाद वे तय कर लें कि migration संभव नहीं होगी। ऐसा कई social media सेवाओं में बार-बार हो चुका है।
    2. users को protocol जैसी चीज़ों से कोई मतलब नहीं होता; inertia और user base कहीं ज़्यादा मायने रखते हैं। AP इस्तेमाल करने वाली Reddit alternatives में भी users लाना बहुत मुश्किल है, और बाद में उन्हें फिर से switch करने के लिए मनाना भी कठिन है। मुझे डर है कि ऐसे प्रयास पहले से छोटी communities को और बाँट देंगे, और आख़िर में सब लोग हार मानकर बड़े platforms पर वापस चले जाएँगे। account migration का आसान होना अच्छी सुविधा है, लेकिन settings backup/restore और नए instance पर account बनाने की प्रक्रिया पहले से ही काफ़ी आसान है। यह कोई बहुत बड़ा game changer नहीं है। संदर्भ साइट: https://arewedecentralizedyet.online/ Lemmy, programming.dev, Piefed आदि भी आजकल अच्छे माने जा रहे हैं

    • Mastodon से अलग, AT में instance की अवधारणा ही अलग है। Bluesky infrastructure के भीतर भी कई PDS हैं, और संरचनात्मक रूप से यह अलग तरह की layered व्यवस्था में काम करता है (संबंधित लेख देखें)। इसे एक dominant instance कहना सही नहीं होगा। बेशक, कंपनी के protocol को अपने हिसाब से मोड़ देने की आशंका एक वास्तविक चिंता है। लेकिन अभी तक उसने अच्छे steward की भूमिका निभाई है। ecosystem बढ़ेगा तो यह बात धीरे-धीरे सुलझ सकती है। और यह चिंता भी है कि अगर Bluesky सेवा बंद कर दे और migration असंभव हो जाए, तो protocol में backup और migration पहले से built-in हैं। आपके पास CAR file हो तो आप कभी भी किसी और host पर जा सकते हैं। Mastodon में account migration के दौरान बहुत कुछ खो जाता है, लेकिन atproto में 100% transparent migration संभव है।

    • आख़िरकार Bluesky हो या Mastodon, अंदर जाइए तो बस अमेरिकी राजनीति की बातें ही दिखती हैं। मुझे साप्ताहिक political drama में ज़्यादा दिलचस्पी नहीं है, इसलिए शायद Tumblr, Pinterest, या TikTok जैसे ज़्यादा विविध platforms मेरे लिए बेहतर हैं।

    • Mastodon, ActivityPub के बिल्कुल बराबर नहीं है, लेकिन replies का अचानक गायब हो जाना मुझे उस पर भरोसा नहीं करने देता। कुछ posts कभी रहती हैं, फिर गायब हो जाती हैं, और यही उन दो वजहों में से एक थी जिनकी वजह से मैंने Mastodon छोड़ दिया।

  • यह थोड़ा अफ़सोसजनक है कि हर app अपनी collection types इस्तेमाल करती है, और भले वे collections आपस में शेयर कर सकें, फिर भी यह साफ़ नहीं है कि apps वास्तव में एक-दूसरे के साथ interoperable होंगी या नहीं। ActivityPub की एक खूबसूरत बात यह है कि Mastodon user, Pixelfed user को बिना किसी ख़ास चिंता के subscribe कर सकता है। जैसे Twitter, Instagram, Reddit, YouTube, और Substack बिना किसी अतिरिक्त सेटअप के अपने-आप जुड़े हों।

    • AP में मूल रूप से Status और Question types पर कई services अच्छी तरह interoperate करती हैं। Mastodon, Pixelfed, Misskey, Pleroma आदि सब इसी ढाँचे पर चलते हैं। लेकिन इसके बाहर वाले types का support बहुत सीमित है, इसलिए दूसरे तरह के content को ठीक से समर्थन नहीं मिलता। समस्या यह है कि standards के बाहर extensions के लिए community organisation कमज़ोर है। ATproto में data collections के lexicon/schema definitions का पालन करना ज़रूरी है, और reference व third-party implementations schema validation भी देती हैं। इसलिए बुनियादी interoperability ज़्यादा साफ़-सुथरे ढंग से संरचित है, लेकिन मुझे लगता है कि इसे कुछ additional fields जैसी चीज़ों के optional support की अनुमति देकर थोड़ा और flexible बनाना चाहिए। Bridgy Fed में भी APub से आए data को original URL, text आदि metadata के रूप में जोड़ा जाता है। (https://fed.brid.gy/docs#bluesky-fields देखें)

    • common lexicon को बेहतर बनाने के प्रयास चल रहे हैं: https://github.com/lexicon-community

  • मुझे लगने लगा है कि "next Twitter" का दावा करने वाले projects समस्या को हल करने में थोड़ा-थोड़ा चूक रहे हैं। Twitter की सुविधाओं को पूरी तरह दोहराने के बाद वे users और content की कमी वाली chicken-and-egg समस्या में फँस जाते हैं। आख़िरकार लोग वहीं जाते हैं जहाँ लोग पहले से हैं, और वह अब भी Twitter ही है। इसके बजाय, हाल में OpenAI ने जो timeline लॉन्च की है, उसके जैसे — जहाँ background में पहले data इकट्ठा किया जाता है और फिर users तक पहुँचाया जाता है — उस दिशा में जाना बेहतर लगता है। ठोस implementation अलग हो सकती है, लेकिन दिशा सही लगती है। ज़्यादातर users, tweet लिखने की सुविधा को इतनी अहमियत नहीं देते; असली value data consumption, यानी content sourcing में है। इस नज़रिए से multi-social RSS reader + P2P option ज़्यादा अच्छा रास्ता लगता है। यह मेरी निजी राय है।

    • जैसा कि लेख में बताया गया है, शुरुआती framing में microblogging का इस्तेमाल किया गया है, लेकिन वास्तव में यह सिर्फ़ Twitter-जैसी चीज़ों तक सीमित नहीं है; कई अलग रूप संभव हैं। उदाहरण के लिए Tangled, "Github on atproto" है, और Leaflet, "Medium on atproto" की तरह है। client-side P2P तरीक़े की सीमा यह है कि बड़े पैमाने पर aggregation और consistency की गारंटी देना मुश्किल होता है, जबकि यही social apps में ज़्यादातर आम users की बुनियादी अपेक्षा होती है। OpenAI वाला उदाहरण भी atproto की ताकत दिखाता है। नेटवर्क में data पहले से मौजूद होता है, इसलिए crawling, indexing, automation tools जोड़ना आसान है। शुरुआती उदाहरण के तौर पर https://github.com/graze-social/iftta देखा जा सकता है।

    • social networks, "वही पुरानी चीज़, बस कुछ extra!" से नहीं बढ़ते; वे तब बढ़ते हैं जब कोई ऐसा नया तरीका सामने आता है जो पिछले platforms पर संभव ही नहीं था।

    • इसलिए Nostr अलग है! इससे blog, Twitter-जैसी services, streaming services, messenger — कुछ भी बनाया जा सकता है। उदाहरणों का संग्रह: https://nostrapps.com

  • सोचता हूँ, क्या free top-level domain (TLD) संभव हो सकता है? असल domain registration की लागत आख़िर है क्या? जब Let's Encrypt certificates मुफ्त में दे सकता है, तो कोई non-profit domains मुफ्त में क्यों नहीं दे सकता? उन्हें सुंदर दिखने की भी ज़रूरत नहीं। UUID v7 के कई टुकड़े जोड़ दिए जाएँ, तब भी ठीक है — बस globally unique और free हों। browser एक बार access करने के बाद याद रख लेगा, इसलिए लंबे addresses भी समस्या नहीं होंगे। क्या यह वाकई बहुत खराब विचार है?

    • atproto में यह काम did:plc करता है। https://web.plc.directory/ पर मुफ़्त ID जारी की जा सकती है। उदाहरण के लिए मेरी ID है https://plc.directory/did:plc:3danwc67lo7obz2fmdg6jxcr। domain के TXT record के ज़रिए इसे उस did:plc से जोड़ा जा सकता है।

    • free TLD व्यवहार में लागू करना मुश्किल है। TLD और public suffix list से जुड़ी कई नीतियाँ, लागतें और प्रशासनिक विशिष्टताएँ होती हैं, देखें https://github.com/publicsuffix/list। हाँ, TLD के बजाय सामान्य domains को खुलकर इस्तेमाल किया जा सकता है, और free subdomains भी बाँटे जा सकते हैं। लेकिन ऐसी service सच में चलाइए, तो जल्द ही spam, phishing और dark internet के दूसरे हमले शुरू हो जाएँगे, और आपको इसे चलाने का पछतावा होगा। जैसे कोई भी URL redirector बना सकता है, लेकिन उसे व्यवहार में चलाना अलग बात है — सही मायनों में चलाते ही समस्याएँ शुरू हो जाती हैं। दुखद हक़ीक़त है।

    • यह व्यवहार में IPv6 addresses बाँटने जैसा ही विचार है। आजकल ज़्यादातर home internet में /64 public IPv6 दिया जाता है, लेकिन ISP आमतौर पर ports पर firewall लगा देते हैं, इसलिए उसका वास्तविक उपयोग रुक जाता है। ऊपर से ISP बदलने पर address खोना भी आसान है। इसे अगर सचमुच permanent और portable IPv6 address बनाना हो, तो व्यक्तियों को provider-independent address space मुफ्त में बाँटना होगा और उसे BGP के ज़रिए global routing से जोड़ना होगा। सिद्धांत में यह संभव है, लेकिन अभी तक ऐसा लागू नहीं हुआ है (कुछ-कुछ वैसे जैसे Let's Encrypt आने से पहले की स्थिति)। DNS-based naming की ज़रूरत क्यों हो, यह स्पष्ट नहीं, लेकिन अगर लक्ष्य छोटा और याद रखने लायक नाम नहीं है, तो DNS बहुत उपयुक्त नहीं है। फिर भी ngrok की तरह अपने gTLD के भीतर domains जारी करने का मॉडल आज़माया जा सकता है। सच में .me ccTLD ने कभी इस तरह free domains बाँटे थे, और बदले में बीच के proxy server पर हर traffic में ads inject करता था।

    • .tk मुफ़्त था और registrations की संख्या के हिसाब से दुनिया का सबसे बड़ा ccTLD था। इसका ज़्यादातर इस्तेमाल दुरुपयोग में होता था। Facebook ने operating company (डच कंपनी Freenom) पर phishing में शामिल होने का मुक़दमा किया, और अब यह मुफ्त में उपलब्ध नहीं है।

    • पहले .FREE TLD initiative भी था, लेकिन execution में समस्याओं और deadlines पूरी न होने के कारण अब वह लगभग ठंडा पड़ चुका है https://icannwiki.org/.free

  • Dan का लेख दिखे तो मैं क्लिक करता हूँ। open web शायद first-mover premium की वजह से सफल हुआ था, इसलिए थोड़ा चिंतित भी हूँ। दूसरी ओर open source को सफल होते देखकर उम्मीद मिलती है। मैं ऐसी दुनिया देखना चाहता हूँ जहाँ atproto जैसी चीज़ें सफल हों। network effects की वजह से बेहतर apps का सफल न हो पाना सच में अफ़सोसजनक है।

    • HTML के सफल होने की वजह यह थी कि वह ‘मुफ़्त’ था। उस समय paid hypermedia standards बहुत थे, लेकिन उनके मुकाबले इसकी accessibility ज़्यादा थी। कोई भी आसानी से browser या server बना सकता था।

    • ATProto का एक बड़ा फ़ायदा यह भी है कि इसे network effects की सीमा तोड़ने के लिए डिज़ाइन किया गया है। अगर सब लोग atproto पर migrate कर जाएँ, तो फिर social network को "बस आख़िरी बार" migrate करने वाली स्थिति ख़त्म हो जाएगी। आख़िरकार यह decentralisation और स्वतंत्र competition वाला माहौल दे सकता है।

  • व्यवहारिक रूप से यह कल्पना करना मुश्किल है कि ऐसा सिस्टम व्यापक रूप से फैल पाएगा। पारंपरिक social media के target users और decentralisation-उन्मुख users की प्रवृत्तियाँ बिल्कुल अलग हैं। ज़्यादातर लोग platform को सिर्फ़ एक साधन मानते हैं, सिस्टम की परवाह नहीं करते। आख़िर में अगर सब सिर्फ़ bluesky account ही बना लें, तो पहले की तरह फिर कुछ बड़े services में ही केंद्रीकरण हो जाएगा और बात बेमानी हो जाएगी।

    • भले ही सब लोग bsky.social पर इकट्ठा हों, यह पहले की तुलना में बहुत बड़ा सुधार है। जैसे AWS पर बहुत-से servers होने से web को centralised नहीं कहा जाता, वैसे ही यहाँ भी ज़रूरत पड़ने पर कभी भी migration संभव है।

    • असल में bluesky में अभी federation पूरी तरह implement नहीं हुई है। सारा traffic एक ही BGS router server पर निर्भर करता है।

    • अफ़सोस की बात है, लेकिन आख़िर में समस्या की जड़ 'लोग' ही हैं।

  • इस काम को लेकर मेरी भावनाएँ मिली-जुली हैं। एक तरफ़, यह विचार पूरी तरह मेरी पसंद का है। हर व्यक्ति अपने content का मालिक हो — यह Indie web movement की भावना से मेल खाता है, और इस page तथा लेखों की quality भी बहुत प्रभावशाली है। दूसरी तरफ़, ऐसे standards को वास्तव में अपने personal blog या open source projects में लागू करने वाले developers बहुत कम हैं, और vlog/blog चलाने वाले या आम users के बीच भी adoption कम है। यह बात चिंतित करती है कि कितने लोग data ownership, openness और interoperability के प्रति उदासीन हैं। ऐसा लगता है कि लोग सिर्फ़ TikTok, Instagram Reels जैसी feeds चाहते हैं। vision और effort का मैं सम्मान करता हूँ, लेकिन सोचता हूँ कि क्या यह सिर्फ़ niche hobby बनकर रह जाएगा या कभी mainstream भी बन सकेगा।

    • developer experience को और आसान बनाने का काम अभी बाकी है। लेकिन इस क्षेत्र की प्रगति की रफ़्तार बहुत तेज़ है, इसलिए अगले 6~12 महीने बहुत रोमांचक लगते हैं। ज़्यादातर लोग अब भी यह नहीं समझते कि ATProto सिर्फ़ Bluesky के लिए नहीं, बल्कि इससे कहीं ज़्यादा विविध क्षेत्रों में लागू हो सकता है, और इस बात को बाज़ार में अधिक ठोस रूप से दिखने में थोड़ा समय लगेगा।

    • मैं यह जानना चाहता हूँ कि 'data ownership' की अवधारणा आख़िर इतनी महत्वपूर्ण क्यों मानी जाती है, और यह बात कि आम लोग इसकी परवाह नहीं करते, वास्तव में इतनी चिंताजनक क्यों है। पहले भी लोग TV, किताबों, radio की तरह ownership के बिना content consume करते आए हैं। अब बस उन्हें कुछ पोस्ट करने और अपने आसपास के लोगों को दिखाने का मौका मिला है — ऐसे में Instagram post का वास्तविक 'ownership' इतना अहम क्यों है, यह सवाल भी उठता है।

    • मैं आपकी बात से सहमत हूँ। आख़िरकार, अगर हमें यह तकनीक सफल बनानी है, तो हमें खुद आगे बढ़कर इसे फैलाना होगा और इसे लोकप्रिय बनाने की कोशिश करनी होगी। कौन जाने, कभी open social से मोहित कोई founder/CTO एक लोकप्रिय सफल app लेकर आए — और अगर हम कुछ करेंगे ही नहीं, तो यह कभी सफल नहीं होगा।