सोशल फाइलसिस्टम

 (overreacted.io)
1 पॉइंट द्वारा GN⁺ 2026-01-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • फाइल-केंद्रित personal computing की अवधारणा को social computing तक विस्तार देते हुए यह समझाया गया है कि उपयोगकर्ता द्वारा बनाया गया सारा कंटेंट apps नहीं, बल्कि स्वयं उपयोगकर्ता के स्वामित्व में रहता है
  • AT Protocol के आधार पर, apps के बीच data interoperability संभव बनाने वाली decentralized social filesystem की अवधारणा प्रस्तुत की गई है
  • हर उपयोगकर्ता के पास अपना ‘everything folder’ या repository होता है, जहाँ पोस्ट, likes, follows आदि JSON-आधारित फाइलों (record) के रूप में संग्रहीत होते हैं
  • DID (Decentralized Identifier) और at:// URI सिस्टम के माध्यम से, hosting बदलने या handle बदलने पर भी स्थायी रूप से पहचाने जा सकने वाले links बनाए रखे जाते हैं
  • यह संरचना app नहीं, data-केंद्रित social ecosystem बनाती है, जिससे कोई भी नया app बनाकर मौजूदा data पर काम कर सकता है

फाइल पैरेडाइम और उसका सामाजिक विस्तार

  • फाइलें मूल रूप से apps के अंदर नहीं, बल्कि उपयोगकर्ता के नियंत्रण वाले स्थान में मौजूद होती हैं, और apps केवल फाइलों को पढ़ने-लिखने के tools की भूमिका निभाते हैं
    • .svg जैसे open file formats कई apps को एक ही data साझा करने देते हैं
    • “file format ही API है” के सिद्धांत के तहत, apps के बीच interoperability संभव होती है
  • इस अवधारणा को social apps पर लागू करने पर, पोस्ट, follow, like जैसी क्रियाओं को भी फाइलों की तरह संभाला जा सकता है
    • उपयोगकर्ता की सभी online गतिविधियों को समेटने वाला ‘everything folder’ मौजूद होता है
    • apps इस folder के data को प्रतिबिंबित करते हैं, और folder single source of truth की भूमिका निभाता है

AT Protocol और social filesystem

  • AT Protocol इस संरचना को वास्तविक रूप से लागू करने वाली तकनीक है, और Bluesky, Leaflet, Tangled, Semble, Wisp आदि इसी के आधार पर काम करते हैं
  • apps उपयोगकर्ता data के स्वामी नहीं होते; फाइल-स्तर पर अलग-अलग data storage के कारण नए apps मौजूदा data का पुनः उपयोग कर सकते हैं
  • सभी उपयोगकर्ताओं के folders मिलकर decentralized social filesystem बनाते हैं

record और collection की संरचना

  • हर पोस्ट को JSON फाइल (record) के रूप में दर्शाया जाता है, और उसमें लेखक की जानकारी या derived data (जैसे likes की संख्या) शामिल नहीं होती
    • उदाहरण: { text: 'no', createdAt: '2008-09-15T17:25:00.000Z' }
  • फाइल नाम timestamp-आधारित key (record key) से बनाया जाता है, ताकि टकराव से बचा जा सके
  • फाइल संरचना lexicon नामक schema से परिभाषित होती है, और हर app अपना lexicon डिज़ाइन कर सकता है
    • उदाहरण: com.twitter.post, fm.last.scrobble, io.letterboxd.review
  • एक ही अवधारणा के लिए भी अलग-अलग apps के अलग lexicon हो सकते हैं, और domain-आधारित namespace टकराव से बचाते हैं

सत्यापन और भरोसा

  • Lexicon Police जैसी कोई चीज़ मौजूद नहीं है — कोई भी app दूसरे app के data को लागू कराने के लिए बाध्य नहीं कर सकता
    • apps इनपुट data को read के समय validate करते हैं, और मान्य न होने पर उसे नज़रअंदाज़ कर देते हैं
  • lexicon बदलते समय backward compatibility बनाए रखना अनिवार्य है, और breaking changes को नए lexicon में अलग किया जाता है
  • lexicon को सार्वजनिक रूप से वितरित किया जा सकता है, और DNS के माध्यम से domain ownership proof किया जाता है

links और पहचान (Identity)

  • उपयोगकर्ता द्वारा बनाए गए ‘like’ या ‘reply’ को दूसरे records का संदर्भ देना होता है, इसलिए स्थायी link सिस्टम की आवश्यकता होती है
  • कई प्रयासों के बाद DID (Decentralized Identifier) के जरिए पहचान स्थापित की गई
    • did:plc:6wpkkitfdkgthatfvspcfmjo जैसा identifier बदला नहीं जा सकता
    • हर DID एक ऐसे document में resolve होता है जिसमें मौजूदा hosting, handle, public key की जानकारी होती है
  • at:// URI, DID, collection और record key को मिलाकर hosting बदलने पर भी न टूटने वाले links देता है
    • उदाहरण: at://did:plc:6wpkkitfdkgthatfvspcfmjo/com.twitter.post/34qye3wows2c5

JSON hyperlinks और संबंधों की अभिव्यक्ति

  • हर ‘like’, ‘repost’, ‘reply’ दूसरे record का संदर्भ देने वाली hyperlink-प्रकार की JSON संरचना होती है
    • उदाहरण: parent फ़ील्ड किसी दूसरे पोस्ट के at:// URI को संदर्भित करती है
  • UI की सारी जानकारी (लेखक, टेक्स्ट, likes की संख्या आदि) ऐसी फाइलों के बीच संबंधों से निकाली जा सकती है

repository और data flow

  • उपयोगकर्ता का ‘everything folder’ repository कहलाता है, और उसकी पहचान DID से होती है
    • इसके अंदर कई collection और record मौजूद होते हैं
  • repository को कहीं भी host किया जा सकता है, और स्थान बदलने पर भी links बने रहते हैं
  • apps repository को filesystem की तरह पढ़ सकते हैं, या stream (WebSocket) के रूप में subscribe करके real-time sync कर सकते हैं
    • हर commit को signed hash tree (Merkle tree) से verify किया जाता है, जिससे data forgery रोकी जाती है
    • relay server सिर्फ events को दोबारा भेजते हैं, और सत्यापित की जा सकने वाली संरचना के कारण भरोसा बनता है

Atmosphere की खोज और वास्तविक उदाहरण

  • pdsls.dev में DID या handle डालकर social filesystem explorer की तरह इस्तेमाल किया जा सकता है
    • हर collection और record को सीधे देखा जा सकता है
  • उदाहरण app Sidetrail उपयोगकर्ता के records में हुए बदलावों को real time में दिखाता है, और यह दर्शाता है कि data app में नहीं, repository में मौजूद है
  • teal.fm Relay demo वास्तविक API के बिना भी fm.teal.alpha.feed.play record को index करके music playback history (scrobble) को visualize करता है
    • lex-gql tool का उपयोग करके Lexicon-आधारित GraphQL query चलाई जा सकती है
  • Bluesky में उपयोगकर्ता स्वयं बनाए हुए custom feed algorithms वितरित कर सकते हैं
    • उदाहरण: @spacecowboy17.bsky.social का “For You” feed स्वतंत्र रूप से काम करता है, और shared data पर third party फीचर्स को बेहतर बना सकती है

निष्कर्ष

  • social filesystem app-केंद्रित नहीं, data-केंद्रित internet संरचना का प्रस्ताव रखता है
  • उपयोगकर्ता अपने data repository के मालिक होते हैं, और apps उसके ऊपर reactive तरीके से काम करते हैं
  • इसका लक्ष्य “सब कुछ करने वाला app” नहीं, बल्कि “जहाँ सब कुछ संभव हो ऐसा ecosystem” है

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

1 टिप्पणियां

 
GN⁺ 2026-01-19
Hacker News की राय

  • ऐप गायब हो सकते हैं, लेकिन फ़ाइलें रहती हैं
    swyx की पोस्ट यह ज़ोर देती है कि लंबे समय तक टिकने वाला काम आखिरकार फ़ाइल/डेटा के रूप में मौजूद रहता है
    डेटा को बिना अनुमति के भी parse किया जा सकता है, और थोड़ा खराब होने पर भी वह उपयोगी रहता है, लेकिन आर्थिक incentives अब भी code-केंद्रित हैं
    जब standards आएँगे और code डेटा को स्वीकारना और बाहर निकालना सीख जाएगा, तो पूरी सभ्यता के लिए बहुत बड़ा मूल्य बनेगा
    मुझे लगता है कि developer ecosystem का Google, Microsoft, OpenAI, Anthropic जैसी कंपनियों को डेटा standardization में स्वेच्छा से भाग लेने के लिए प्रेरित करना हमारे पास मौजूद सबसे शक्तिशाली lever में से एक है

    • मैं “फ़ाइलें ही truth source हैं” वाली बात से सहमत हूँ
      लेकिन आज के ऐप ad revenue पर निर्भर websites के रूप में हैं, इसलिए इस तरह की संरचना पर चलने का कोई incentive ही नहीं है
    • Google, MS, OpenAI, Anthropic को जो चाहिए वह दे देने से ज़रूरी नहीं कि बदले में reward भी मिले
      Apple को ही देख लें, standards कई बार दुनिया नहीं बदल पाते
    • यह देखकर अच्छा लगा :) “indirection का नियम” मैंने पहली बार सुना, लेकिन काफ़ी दिलचस्प concept है

  • अगर createdAt field मनमाना value हो, तो क्या मैं अपनी मर्ज़ी से रिकॉर्ड को पीछे की तारीख़ में बदल नहीं सकता?
    मैं जानना चाहता हूँ कि signing के ज़रिए creation time और बाद की edits को verify करने का कोई तरीका है या नहीं

  • POSSE और AT Protocol को interoperable marketplace के रूप में समझा जा सकता है
    Reddit या Instagram की तरह यहाँ user content ही product है, attention currency है, और platforms ads या behavioral data से कमाई करते हैं
    लेकिन यह संरचना अनिवार्य नहीं है
    अगर users के पास अपने social data का ownership हो, तो apps डेटा पढ़ने वाले interfaces में बदल जाते हैं
    मैं commerce में भी ऐसा ही model लागू कर रहा हूँ — seller अपनी order और payment logic खुद host करता है, और marketplace सीधे seller API के साथ integrate करता है
    इससे platform fee घटती है, और value बनाने वाले को ownership वापस मिलती है

    • प्रोफ़ाइल में openship देखा था, तो जिज्ञासा हुई; मैं खुद जाकर देखूँगा

  • पोस्ट इतनी detail में थी कि core message देने के लिए कुछ ज़्यादा लगी
    फिर भी उपमा शानदार है. अगर PDS के लिए file browser हो, तो इसे सीधे अनुभव किया जा सकता है
    Bluesky का PDS मूल रूप से एक public filesystem है, और Git की तरह replication design में शामिल है
    replication को नियंत्रित नहीं किया जा सकता, लेकिन automatic backup का फ़ायदा भी है
    आखिरकार PDS पर डाली गई चीज़ें permanent record की तरह रह जाती हैं, इसलिए सावधानी ज़रूरी है

    • लिखते समय मेरा लक्ष्य दिमाग़ की संरचना को जैसा है वैसा उतारना होता है
      अगर यह उपयोगी है लेकिन लंबा है, तो दूसरे लोग अपनी ज़रूरत का हिस्सा ले सकते हैं
      पोस्ट के अंत में demo section में file manager का असली उदाहरण देखा जा सकता है
      “एक ऐसी दुनिया जहाँ हर कोई scraper बन जाता है” — यही इसकी असली बात है
    • pdsfs का इस्तेमाल करके FUSE के ज़रिए PDS को local में read-only mount किया जा सकता है
    • pdsls.dev यह काम अच्छी तरह करता है. यह पूरी तरह client-side app है और open source है
    • atproto encryption की स्थिति क्या है, यह जानने की उत्सुकता है. क्या सिर्फ sha256 से encrypted data पोस्ट कर देना काफ़ी है?
    • ATProto अभी पूरा बना हुआ protocol नहीं है, और private data support भी जल्द जोड़ा जाएगा

  • मुझे लगता है कि “फ़ाइल” का concept अब पुराना हो चुका है
    अगर हर चीज़ को hash-based blob data की तरह माना जाए, तो कई समस्याएँ ख़त्म हो जाती हैं
    user को ऐप नहीं बल्कि capability चाहिए
    उदाहरण के लिए “योगा वीडियो देखने की क्षमता” या “अपने परिचितों के साथ हालचाल साझा करने की क्षमता”, न कि YouTube या Bluesky खुद
    ऐप तो बस इन capabilities का bundle हैं
    messaging app में कोई शब्द खोजकर, उसका result तुरंत chat window में share कर सकने जैसे custom workflow की ज़रूरत है
    मुझे PerKeep से प्रेरणा मिली

    • filesystem यहाँ एक रूपक है
      इसका इस्तेमाल “apps और file formats के many-to-many relation” को समझाने के लिए किया गया है
      ATProto की repository structure explanation देखें, तो यह Merkle-tree आधारित content-addressed structure है
      Lexicon का apps के साथ 1:1 रिश्ता नहीं है, इसलिए AT पहले ही post-app युग की ओर बढ़ रहा है

  • मुझे लगता है कि walled garden दरअसल consumer preference का नतीजा हैं
    जब internet ने सब कुछ खोल दिया, तो लोगों ने खास culture या ideas के इर्द-गिर्द छोटे spaces चाहने शुरू किए
    IG और Snap ऐसे ही segmented group chat जैसे हैं
    यह अच्छा ही है कि मेरी IG posts अपने-आप HN या Truth Social पर share नहीं होतीं
    data portability की value मुझे खास समझ नहीं आती. अलग context वाले platforms के बीच cross-over अर्थहीन लगता है

    • ATProto apps डिफ़ॉल्ट रूप से हर “फ़ाइल” को अपने-आप share नहीं करते
      मैंने बनाया हुआ Anisota इस तरह design किया गया है कि वह Bluesky और Leaflet दोनों की files को support करे
      उदाहरण के लिए, वही पोस्ट Bluesky और Anisota पर अलग-अलग देखी जा सकती है
      और Aturi नाम का एक project ATProto-आधारित content के universal links देता है
    • जब Twitter का अधिग्रहण हुआ था, तब अच्छा होता अगर मैं अपनी identity, posts, likes और social graph को ज्यों का त्यों साथ ले जा पाता
      ATProto में, अगर apps एक ही Lexicon इस्तेमाल करें, तो identity और data का पूरा migration संभव है
    • मुझे भी data portability की ज़रूरत बहुत स्पष्ट नहीं लगती
      original images मेरे local में हैं, और हर platform बस उनकी अलग expression है
      platforms के बीच अर्थहीन integration मैं नहीं चाहता
    • अगर Truth Social ने federation code नहीं हटाया होता, तो Mastodon आदि पर लिखी posts वैसी की वैसी दिखाई देतीं
    • अलग-अलग apps का अपना “माहौल” बनाए रखना अच्छी बात है
      AT सिर्फ interoperability को संभव बनाता है, सब कुछ एक नहीं करता
      उदाहरण के लिए Leaflet, quote tracking के लिए Bluesky posts को लाकर दिखाता है
      इस संरचना की वजह से product को fork करने पर भी network के साथ पूरी compatibility बनी रहती है, और competition बढ़ता है
      वास्तव में Blacksky Bluesky का fork है, जिसमें अलग moderation policies लागू की गई हैं

  • Dan की लिखी हुई चीज़ें हमेशा दिलचस्प होती हैं. पढ़ते-पढ़ते आखिरकार समझ आता है कि लेखक वही है

    • धन्यवाद :)

  • मैं self-describing data model को लेकर संशय में हूँ
    ATProto का यह दावा कि “सिर्फ Lexicon जोड़ो और client बन जाएगा” कुछ बढ़ा-चढ़ाकर कहा हुआ लगता है
    असल में UI बनाने के लिए data का अर्थ समझना पड़ता है, और सिर्फ Lexicon काफ़ी नहीं है
    आख़िरकार यह documentation देखकर खुद implement करने से बहुत अलग नहीं है
    standardization अच्छी है, लेकिन यह ज़रूरी नहीं कि इसे globally replicated DB के स्तर की समस्या माना जाए
    फिर भी lock-in कम करने की कोशिश की मैं सराहना करता हूँ
    बस Twitter की असली समस्याएँ political content या spam जैसे social factors थे

    • तुम्हारा उदाहरण तो बस ऐसा मामला है जहाँ किसी की दिलचस्पी न होने से client नहीं बना
      लेकिन अगर Bento जैसी प्रिय service बंद हो जाए, तो कोई न कोई उसका data restore करने की कोशिश करेगा
      उदाहरण के लिए Blento ATProto-आधारित Bento alternative है, जिसे open source के रूप में कोई भी फिर से खड़ा कर सकता है
      इस तरह की संरचना user content की स्थायित्व सुनिश्चित करने की दिशा में एक सार्थक प्रगति है

  • “The Unix Programming Environment” पढ़ते हुए एहसास हुआ कि simple tools और text files से भी बहुत कुछ किया जा सकता है
    मैं सोचने लगा कि अगर Slack को file-centered UNIX style में बनाया गया होता तो वह कैसा होता
    मैं फिर से simple और composable systems की तरफ लौटना चाहता हूँ

    • Unix ने शानदार architecture ideas दिए, लेकिन हर data को plain text के रूप में संभालना उसकी सीमा थी
      human-readable serialization अच्छी है, लेकिन हर बार parse और reformat करना कष्टदायक है

  • नए social platforms का distributed/federated environment में common protocols और data formats साझा करने का विचार दिलचस्प है
    लेकिन मौजूदा commercial platforms को मनाना मुश्किल लगेगा
    अगर ऐसे standards जम जाएँ, तो social marketing tools के लिए कई networks को साथ में manage करना आसान हो जाएगा
    लेकिन हक़ीक़त यह है कि अभी भी Facebook, Instagram, TikTok जैसे closed ecosystems हावी हैं