s@ : स्थिर साइट आधारित विकेंद्रीकृत सोशल नेटवर्किंग

 (satproto.org)
9 पॉइंट द्वारा GN⁺ 2026-03-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • स्थिर वेबसाइटों का उपयोग करने वाला एक विकेंद्रीकृत सोशल नेटवर्किंग प्रोटोकॉल, जिसमें हर उपयोगकर्ता अपने डेटा का सीधे स्वामित्व और प्रबंधन करता है
  • सारा डेटा एन्क्रिप्टेड JSON स्टोरेज में रखा जाता है, और ब्राउज़र क्लाइंट फ़ीड एग्रीगेट करता है तथा पोस्ट प्रकाशित करता है
  • सर्वर या रिले के बिना, दोस्तों की वेबसाइटों और ब्राउज़रों के बीच सीधे संचार के जरिए काम करता है
  • उपयोगकर्ता का डोमेन नाम ही उसकी पहचान है, और HTTPS/TLS के माध्यम से प्रमाणित होता है
  • सरल संरचना के साथ self-sovereign social network को लागू करता है, और व्यक्तियों के बीच भरोसे-आधारित संवाद पर फ़ोकस करता है

sAT Protocol अवलोकन

  • s@ एक स्थिर साइट आधारित विकेंद्रीकृत सोशल नेटवर्किंग प्रोटोकॉल है, जिसमें हर उपयोगकर्ता अपने डेटा को अपनी वेबसाइट पर संग्रहीत करता है
    • सारा डेटा एन्क्रिप्टेड JSON फ़ाइलों के रूप में संग्रहीत होता है, और ब्राउज़र क्लाइंट इन्हें पढ़कर पोस्ट प्रकाशित करने और फ़ीड एग्रीगेशन का काम करता है
    • यह केंद्रीय सर्वर या रिले के बिना काम करता है, और डेटा उपयोगकर्ता की साइट से सीधे दोस्त के ब्राउज़र तक जाता है
  • पोस्ट का आदान-प्रदान केवल आपसी follow संबंध होने पर संभव है, जिससे influencer-केंद्रित संरचना को बाहर रखा जाता है
  • यह प्रोटोकॉल GitHub Pages जैसी किसी विशेष होस्टिंग सेवा पर निर्भर नहीं है

पहचान (Identity)

  • उपयोगकर्ता का डोमेन नाम ही पहचान की भूमिका निभाता है
  • HTTPS/TLS के माध्यम से यह प्रमाणित होता है कि डोमेन स्वामी ने ही सामग्री प्रकाशित की है

डिस्कवरी (Discovery)

  • https://{domain}/satellite/profile.json पथ पर प्रोटोकॉल वर्ज़न और public key उपलब्ध कराई जाती है 
    {
  "satproto_version": "0.1.0",
  "public_key": "<base64-encoded X25519 public key>"
}
  • डिफ़ॉल्ट पथ /satellite/ के अलावा कोई दूसरा पथ उपयोग करने पर, .well-known/satproto.json फ़ाइल से वास्तविक स्टोरेज लोकेशन निर्दिष्ट की जा सकती है

एन्क्रिप्शन मॉडल (Encryption Model)

  • सारा उपयोगकर्ता डेटा एन्क्रिप्टेड JSON स्टोरेज में रखा जाता है, और केवल उपयोगकर्ता तथा followers ही इसे डिक्रिप्ट कर सकते हैं
  • X25519 key pair का उपयोग कर public key को profile.json में प्रकाशित किया जाता है, और private key को ब्राउज़र localStorage में रखा जाता है
  • पोस्ट डेटा को XChaCha20-Poly1305 से एन्क्रिप्ट किया जाता है, और content key को प्रत्येक follower के लिए libsodium के crypto_box_seal से एन्क्रिप्ट किया जाता है
  • keys/_self.json फ़ाइल में उपयोगकर्ता की content key और publishing secrets शामिल होते हैं, जिन्हें केवल वही डिक्रिप्ट कर सकता है

key rotation और unfollow

  • unfollow होने पर नई content key बनाई जाती है और सभी पोस्टों को फिर से एन्क्रिप्ट किया जाता है
  • बचे हुए followers के लिए नए key envelopes बनाए जाते हैं और keys/_self.json अपडेट किया जाता है
  • जिसे unfollow किया गया है, वह अब पोस्टों को डिक्रिप्ट नहीं कर सकता

डिक्रिप्शन फ्लो

  • जब कोई विज़िटर दोस्त की साइट पर जाता है, तो वह अपनी private key से keys/{follower-domain}.json को डिक्रिप्ट कर content key प्राप्त करता है
  • इसके बाद posts/index.json और अलग-अलग पोस्ट (posts/{id}.json.enc) को लाकर डिक्रिप्ट किया जाता है

डेटा संरचना (Data Schema)

  • हर पोस्ट को अलग-अलग एन्क्रिप्टेड फ़ाइल के रूप में संग्रहीत किया जाता है, और posts/index.json में पोस्ट ID नई से पुरानी क्रम में सूचीबद्ध होती हैं
  • पोस्ट ऑब्जेक्ट का उदाहरण: 
    {
  "id": "20260309T141500Z-a1b2",
  "author": "alice.com",
  "created_at": "2026-03-09T14:15:00Z",
  "text": "Hello, decentralized world!",
  "reply_to": null,
  "reply_to_author": null
}
  • पोस्ट ID, ISO8601 UTC timestamp और 4-अक्षर वाले random hash से बनी होती है

follow सूची (Follow List)

  • https://{domain}/satellite/follows/index.json पथ पर plain-text JSON के रूप में संग्रहीत 
    { "follows": ["bob.example.com", "carol.example.com"] }
  • यह एन्क्रिप्टेड नहीं होती, क्योंकि key envelopes के माध्यम से follow संबंध पहले ही उजागर हो जाता है

फ़ीड एग्रीगेशन (Feed Aggregation)

  • क्लाइंट follow सूची पढ़ता है और प्रत्येक follower की पोस्टों को डिक्रिप्ट करके समयक्रमिक फ़ीड बनाता है
  • पोस्टों को created_at के आधार पर descending क्रम में sort किया जाता है

रिप्लाई (Reply)

  • रिप्लाई वे पोस्ट हैं जिनमें reply_to और reply_to_author फ़ील्ड सेट होते हैं
  • nested replies समर्थित नहीं हैं, और केवल top-level पोस्ट पर सीधे रिप्लाई किया जा सकता है
  • यदि मूल पोस्ट दिखाई नहीं देती (जैसे non-follow स्थिति में), तो रिप्लाई भी प्रदर्शित नहीं होगी

प्रकाशन (Publishing)

  • नई पोस्ट बनाना → content key से एन्क्रिप्ट करना → स्थिर साइट पर अपलोड करना → posts/index.json अपडेट करना
  • अपलोड के लिए GitHub Contents API आदि का उपयोग किया जा सकता है
  • publishing secrets को keys/_self.json में एन्क्रिप्ट करके संग्रहीत किया जाता है

स्थिर साइट संरचना उदाहरण

{domain}/satellite/
  profile.json              # public key और प्रोफ़ाइल
  posts/
    index.json              # पोस्ट ID सूची
    {id}.json.enc           # एन्क्रिप्टेड पोस्ट
  follows/
    index.json              # follow सूची
  keys/
    _self.json              # content key और credentials
    {domain}.json           # follower-विशिष्ट content key

FAQ

  • “क्या यह RSS + एन्क्रिप्शन है?” → हाँ
  • “क्या यह AT Protocol का firehose-रहित वर्ज़न है?” → हाँ
  • “क्या यह scalable है?” → नहीं (“दोस्ती भी scalable नहीं होती”)
  • “क्या s का मतलब slow/shitty है?” → हाँ
  • “क्या इसे self-host किया जा सकता है?” → हाँ, लेकिन CORS सक्षम होना चाहिए

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

1 टिप्पणियां

 
GN⁺ 2026-03-13
Hacker News की राय

  • लगता है यह प्रोजेक्ट भी वही समस्याएँ झेलता है जिनसे कई वैकल्पिक सोशल·self-hosted नेटवर्क गुजरते हैं
    crypto-केंद्रित डिज़ाइन अच्छा है, लेकिन नए डिवाइस पर बदलने पर दोस्तों की follow सूची बहाल करना मुश्किल होता है, और X25519 key pair जैसी अवधारणाएँ आम लोगों के लिए समझना कठिन हैं
    मुझे लगता है कि सिर्फ ID·password आधारित ढाँचा, जहाँ server encryption को संभाले, ज़्यादा व्यावहारिक है
    मेरा मानना है कि यही वह दिशा है जो non-technical users भी इस्तेमाल कर सकें, और Big Tech का विकल्प बन सके

    • मैं भी कुछ हद तक सहमत हूँ। लेकिन अगर हम बिना बिचौलियों वाली दुनिया चाहते हैं, तो आखिरकार non-technical users को भी खुद थोड़ा-बहुत संभालने वाली सांस्कृतिक आदत विकसित करनी होगी
    • शुरुआती setup के बाद private key export करके उसे password manager वगैरह में रखा जा सकता है। अगर आप खुद protocol implement नहीं कर रहे, तो यह इतना जटिल नहीं है
      हाँ, परिवार या दोस्तों के लिए मुझे शायद setup खुद करना पड़े। फिर भी, अगर उनके पास अपनी वेबसाइट हो, तो वे इसे काफ़ी पसंद कर सकते हैं
    • लेख के नीचे FAQ के अनुसार, यह AT Protocol(BlueSky) के कुछ हिस्से हटाकर किया गया एक conceptual experiment ज़्यादा है
      व्यवहार में इसे static blog को BlueSky में integrate करने के विचार की तरह देखा जा सकता है।
      BlueSky identity का उपयोग करके, या static site generator plugin से auth जानकारी अपने-आप लाने जैसी दिशा में इसे बेहतर बनाया जा सकता है
    • पहले email को social network transport layer की तरह इस्तेमाल करने का विचार आज़माया था, लेकिन वह असफल रहा
      संबंधित लेख देखें
    • पता नहीं लक्ष्य Big Tech को बदलना है या नहीं। अगर सिर्फ छोटे community भी इसे उपयोगी पाएँ, तो मैं उसे ही सफलता मानूँगा

  • browser के localStorage में private key सहेजने वाली बात देखकर हैरानी हुई
    browser settings reset या reinstall होने पर data उड़ सकता है, backup मुश्किल है, और malware के लिए पहुँचना आसान है
    आखिरकार key खो जाए तो feed भी हमेशा के लिए गायब हो सकती है, इसलिए users के छोड़कर जाने का जोखिम बड़ा है

    • सहमत। “X25519 key pair” जैसे शब्दों का इतने सहज ढंग से इस्तेमाल देखकर लगता है कि यह प्रोजेक्ट mass adoption से ज़्यादा concept experiment के करीब है
    • मेरा मानना है कि “कुंजी को सुरक्षित स्थान पर export करें” जैसा एक button काफ़ी हद तक समस्या सुलझा सकता है। URL.createObjectURL(localStorage.getItem(...)) जैसे सरल code से file save करने के लिए प्रेरित किया जा सकता है
    • perfection के पीछे भागते-भागते ‘काफ़ी अच्छा’ समाधान नहीं छोड़ना चाहिए। सिर्फ key download/upload feature जोड़ देने से भी ज़्यादातर समस्याएँ सुलझ सकती हैं
      बेशक key खोने पर access खत्म हो जाएगा, लेकिन 2FA या crypto wallet users भी ऐसी ही ज़िम्मेदारी उठाते हैं, इसलिए यह पूरी तरह असंभव नहीं है

  • /satellite/ path की जगह /.well-known/ इस्तेमाल करने का सुझाव दिया गया
    Well-known URI standard का हवाला दिया गया

    • जवाब में मज़ाक किया गया: “.poorly-known”
    • AT Proto के शुरुआती दिनों में root path इस्तेमाल करने से security vulnerability पैदा हुई थी, यह याद करके चिंता जताई गई
    • तर्क दिया गया कि .well-known पूरे host के लिए होता है, इसलिए stream स्तर पर यह उपयुक्त नहीं है। अलग-अलग directories अलग रखना बेहतर होगा

  • मुझे लगता है .well-known/ वाला सुझाव गंभीरता से विचार करने लायक है
    यह पहले से IANA-registered standard के रूप में व्यापक रूप से इस्तेमाल होता है, और security व discovery files यहीं रखी जाती हैं
    /satellite/satproto.json की जगह /.well-known/satproto.json रखने से conflict भी बचेगा और यह भी साफ़ होगा कि यह protocol endpoint है

    • लेकिन .well-known host स्तर का है, इसलिए अगर account-वार कई directories रखनी हों तो यह ठीक नहीं बैठेगा, ऐसा प्रतिवाद किया गया

  • social network protocol का मकसद सिर्फ तकनीक के लिए तकनीक नहीं, बल्कि users को सीधा लाभ देना होना चाहिए
    BitTorrent की तरह लोगों को सिर्फ ‘ज़रूरत’ के कारण शामिल होना चाहिए, तभी network effect बनेगा
    data management और sharing convenience से शुरू होने वाला दृष्टिकोण ज़्यादा व्यावहारिक लगता है

    • मैंने कई decentralized SNS इस्तेमाल किए हैं, और आखिरकार लोग dopamine stimulus न हो तो वापस नहीं आते
      Lemmy और Pixelfed में content कम था, इसलिए वे “जहाँ कुछ होता ही नहीं” जैसे लगे
      Signal भी वैसा ही है; सिर्फ messaging के लिए है, इसलिए ‘scroll करने की वजह’ नहीं बनती
      आखिरकार content और FOMO(छूट जाने का डर) होना चाहिए, तभी लोग लगातार आते हैं
    • फिर भी अच्छा protocol design महत्वपूर्ण है। अगर वह बहुत जटिल हो या future-ready न हो, तो अच्छा विचार भी जल्दी गायब हो सकता है

  • सचमुच decentralized social·E2EE messenger बनाना है तो Discord की तरह हर server सच में स्वतंत्र रूप से host होना चाहिए
    account को Nostr जैसे protocol से manage किया जाए, और Yggdrasil Network पर चलाया जाए ताकि IPv4/6 और DNS पर निर्भरता घटे
    traffic को HTTPS में wrap करके और NAT traversal को automate करके कोई भी server चला सके, ऐसा होना चाहिए
    तभी ऐसी संरचना Big Tech और सरकार के नियंत्रण से बाहर निकल सकेगी

    • लेकिन सिर्फ तकनीक से काम नहीं चलेगा। आम लोग आखिरकार उसी platform पर जाएँगे जहाँ marketing capital ज़्यादा है
    • मेरी राय में BitTorrent, IPFS जैसे cache-आधारित distributed network वाला तरीका बेहतर है
      server गायब हो जाए, तब भी data edge पर बचा रहता है, और user का browser भी host की भूमिका निभा सकता है
      ephemeral-p2p-project देखें
    • इस तरह की संरचना पर geogram.radio में पहले से प्रयोग चल रहा है
      हर device server की तरह काम करता है, और WebRTC से पूरी तरह P2P messaging लागू की जाती है
      internet न होने पर भी radio connection से data exchange संभव है
    • मैं Mikoto Platforms में कुछ ऐसा ही बना रहा हूँ। “Spaces” भौतिक node चाहे जहाँ हों, मौजूद रह सकते हैं, और DM कई nodes से होकर E2EE routing के साथ भेजे जाते हैं

  • पहले FOAF या Pingback जैसे पूरी तरह decentralized social प्रयास हो चुके हैं

    • उसका आधुनिक संस्करण Webmention है
      IndieWeb wiki ऐसी personal-web आधारित social technologies को समझने के लिए अच्छी सामग्री है, इसलिए इसकी सिफारिश की गई
    • एक और उदाहरण XFN है, जिसे भूलना नहीं चाहिए

  • “sAT Protocol static site आधारित decentralized social network है” यह विवरण पढ़ते हुए लगा जैसे भौंहें लगातार ऊपर उठती जा रही हों

    • फिर भी, क्योंकि इसका दायरा सीमित है, यह एक तर्कसंगत system लगता है
      लेकिन ciphertext को सार्वजनिक रूप से enumerate किया जा सकता है, इसलिए quantum computing के दौर में यह जोखिम भरा हो सकता है
    • यह PGP + RSS के संयोजन जैसा है। हर feed को encrypt किया जाता है ताकि सिर्फ संबंधित व्यक्ति उसे decrypt कर सके
      छोटे network के लिए यह उपयुक्त है, लेकिन key distribution और rotation की समस्याओं के कारण बड़े पैमाने पर विस्तार कठिन होगा
    • मैंने इसे “database भेजा जाता है और client static site build करता है” जैसी अवधारणा के रूप में समझा
    • “Key Rotation (Unfollow)” वाला हिस्सा ASCII art के रूप में मज़ाकिया अंदाज़ में पेश किया गया

  • user के नज़रिये से पहले यह समझाना ज़रूरी लगता है कि यह असल में कौन-सी service है
    fork, path, JSON, encryption जैसे technical terms ही भरे हैं, इसलिए असली use case दिखाई नहीं देता

    • फिर भी मेरे कुछ दोस्त तकनीक में काफ़ी रुचि रखते हैं, इसलिए ‘paranoid security taste’ वाले लोगों के साथ इसे आज़माने का सोच रहा हूँ
      Mastodon या Signal से जो ज़रूरत पूरी नहीं होती, उस जगह पर यह प्रयोग करने लायक है

  • ऐसे decentralized network experiments देखना सच में रोचक है
    भले ही संरचनात्मक समस्याएँ बहुत हों, नए संयोजन सीखने में मज़ा आता है
    लेकिन follow/unfollow पर पूरी site को फिर से encrypt और rebuild करना बहुत झंझट वाला है
    और अगर आप follow न करें तो comments दिखें ही नहीं, ऐसी संरचना scalability को काफ़ी सीमित करती है
    फिर भी RSS, ActivityPub और static site के मिश्रण का विचार आकर्षक है
    static site से dynamic friends-list access control लागू करने की कोशिश विरोधाभासी है, लेकिन दिलचस्प भी
    आखिरकार यह ऐसा ढाँचा लगता है जिससे एक साथ प्यार भी होता है और चिढ़ भी। फिर भी, ऐसे प्रयास स्वागतयोग्य हैं और इनके लिए आभार है