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

• फाइल-केंद्रित 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” है