at:// कहाँ स्थित है

(overreacted.io)

2 पॉइंट द्वारा GN⁺ 2025-10-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें

AT protocol एक ऐसा प्रोटोकॉल है जो distributed social network की नींव बनता है, और सभी डेटा की पहचान at:// URI से की जाती है
at:// URI डेटा के निर्माता (उपयोगकर्ता) को authority के रूप में निर्दिष्ट करता है, जबकि वह डेटा वास्तव में कहाँ होस्ट किया गया है यह अलग से पता करना पड़ता है
URI resolution प्रक्रिया handle को identity (DID) में बदलने, DID Document देखकर hosting server की पहचान करने, और फिर उस server से JSON डेटा request करने के क्रम में होती है
दो तरह की DID schemes (did:web, did:plc) समर्थित हैं, और दोनों के फायदे-नुकसान तथा डेटा संरक्षित रखने के तरीके अलग हैं
यह तरीका इस बात पर ज़ोर देता है कि डेटा का स्वामित्व उपयोगकर्ता के पास है, और handle या hosting बदल जाने पर भी कनेक्शन बना रहता है, यानी स्थायित्व मिलता है

AT protocol, at:// URI, और social data की identity resolution प्रक्रिया

# AT protocol और at:// URI की बुनियादी संरचना

AT protocol कई distributed servers को एक निश्चित standard के अनुसार आपस में communicate करने देता है, और इस पूरे नेटवर्क को 'atmosphere' कहा जाता है
atmosphere के भीतर हर data item को at:// से शुरू होने वाला एक unique URI दिया जाता है, जो एक तरह से JSON डेटा के लिंक की तरह काम करता है
पारंपरिक URI संरचना से अलग, AT protocol में डेटा का निर्माता (उपयोगकर्ता) URI की authority होता है
- उदाहरण के लिए, at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z में ruuuuu.de यह दर्शाता है कि वही उस डेटा का मालिक है
डेटा वास्तव में जिस physical server पर host है, वह URI में सीधे शामिल नहीं होता, और उसे खोजने के लिए अतिरिक्त resolution प्रक्रिया की ज़रूरत होती है

# at:// URI resolution की तीन चरणों वाली प्रक्रिया

at:// URI को वास्तविक डेटा (JOSN) से map करने के लिए तीन चरण चाहिए
1. handle (जैसे ruuuuu.de) को identity (DID: Decentralized Identifier) में बदलना
  - handle उपयोगकर्ता की पहचान का alias है और बदल सकता है
  - इसलिए इसे एक immutable global ID यानी DID में बदलना ज़रूरी है
  - बदलने के तरीके:
    - DNS TXT record में _atproto.<handle> query करें → did=... मान देखें
    - या https://<handle>/.well-known/atproto-did पर जाएँ
2. DID Document देखकर डेटा hosting की जानकारी पता करना
  - DID Document में उस identity की public key, service endpoint (server) आदि की जानकारी होती है
  - did:web:~ के मामले में, domain-आधारित access (https://domain/.well-known/did.json)
  - did:plc:~ के मामले में, PLC directory (https://plc.directory/DID) में lookup किया जाता है
  - service endpoint (serviceEndpoint) ही वास्तविक डेटा hosting server होता है
3. hosting server के API के ज़रिए JSON डेटा request करना
  - com.atproto.repo.getRecord endpoint पर at:// के हर हिस्से को parameter के रूप में भेजकर डेटा माँगा जाता है
  - लौटाया गया JSON वही वास्तविक डेटा है जो at:// URI से map होता है

# उदाहरण के साथ resolution प्रक्रिया

उदाहरण: at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z
- चरण 1: ruuuuu.de → did:web:iam.ruuuuu.de (DNS TXT record या .well-known से पुष्टि)
- चरण 2: https://iam.ruuuuu.de/.well-known/did.json से DID Document lookup → serviceEndpoint है https://blacksky.app
- चरण 3: https://blacksky.app/xrpc/com.atproto.repo.getRecord?... पर request → वास्तविक JSON return
```
{
  "uri": "at://did:web:iam.ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z",
  "cid": "...",
  "value": {
    "text": "posting from did:web, like a boss",
    "$type": "app.bsky.feed.post",
    ...
  }
}
```
handle बदल जाए तब भी, अगर DID-आधारित at:// URI (permalink) इस्तेमाल किया जाए, तो account और data के बीच का संबंध बना रहता है

# DID schemes: did:web और did:plc का अंतर

did:web:
- आप अपने domain को manage और authenticate कर सकते हैं
- लेकिन domain पर नियंत्रण खो जाने पर पूरा ID खोने की आशंका होती है
did:plc:
- PLC (Public Ledger of Credentials) ID के संचालन का प्रमुख माध्यम है
- यह domain से बँधा नहीं होता, लेकिन PLC operator updates को अस्वीकार कर दे जैसी सीमित control संभावना मौजूद रहती है
- सभी परिवर्तन hash के ज़रिए verify और track किए जा सकते हैं

# identity, hosting और data का विभाजन तथा स्थायित्व

at:// identity और data hosting को अलग करता है, जिससे user data को portable बनाना और permanent links बनाना संभव होता है
Handle (उपनाम) कभी भी बदला जा सकता है, और hosting server भी उसी तरह migrate किया जा सकता है
DID (identity) immutable रहता है, इसलिए उसके आधार पर बना at:// URI एक स्थायी permalink की तरह इस्तेमाल किया जा सकता है
DID Document में handle के ownership proof, signature verification key, और hosting जानकारी सब शामिल होती है, जिससे भरोसा और flexibility दोनों मिलते हैं

# व्यावहारिक उपयोग और development संदर्भ

व्यवहार में अधिकांश AT-आधारित apps Websocket आदि के माध्यम से डेटा push के रूप में लेते हैं और उसे अपनी internal DB में aggregate करते हैं
फिर भी at:// URI resolution को समझना network की विशेषताओं को समझने और data portability सुनिश्चित करने के लिए आवश्यक है
at:// ढाँचा HTTP, DNS, JSON के ऊपर social network abstraction देता है, और डेटा का स्वामित्व उपयोगकर्ता के पास है इसे तकनीकी रूप से लागू करता है

# निष्कर्ष

AT protocol और at:// URI social data की identity, connectivity, और permanence को तकनीकी रूप से एक नए स्तर पर ले जाते हैं
developers के लिए handle resolution, DID का उपयोग, DID Document की संरचना, और वास्तविक डेटा request करने की विधि जैसे मुख्य workflow को समझना ज़रूरी है
इस संरचना की वजह से अपनी content, identity, और hosting location के बीच flexibility और ownership हासिल की जा सकती है

1 टिप्पणियां

GN⁺ 2025-10-05

Hacker News राय

हाल की ATProto से जुड़ी पोस्टों से प्रेरित होकर मैंने bsky जॉइन किया, लेकिन वहाँ बस अंतहीन अमेरिकी राजनीति ही दिखी। "ऐसी पोस्ट कम दिखाएँ" पर बार-बार क्लिक करने से भी कोई खास फर्क नहीं पड़ा। सोच रहा हूँ क्या यही इस प्लेटफ़ॉर्म का मूल स्वभाव है। विदेशों की अजीब बहसों पर वही घिसी-पिटी राय बार-बार देखना मानसिक रूप से अच्छा नहीं लगता।
- नए अकाउंट पर "Discover" फ़ीड खास अच्छी नहीं होती। लाइक और फ़ॉलो डेटा जमा होने पर यह धीरे-धीरे बेहतर होती है, लेकिन फिर भी इसे बेहतरीन नहीं कहूँगा। मैं व्यक्तिगत रूप से "For You" फ़ीड की सलाह दूँगा। यह फ़ीड लाइक्स को जल्दी शामिल करती है और रैंडम कंटेंट कम धकेलती है। "Dev Trending" फ़ीड भी काफ़ी अच्छी है। For You Feed, Dev Trending
- मैंने यह किया कि कुछ अच्छे अकाउंट ढूँढकर फ़ॉलो किए और "Discovery" टैब को पूरी तरह छिपा दिया। उसके बाद फ़ॉलोअर्स/फ़ॉलोइंग से आने वाली लोगों की इंटरैक्शन्स देखकर स्वाभाविक रूप से अपनी फ़ॉलोइंग सूची बढ़ाई। या फिर ब्लॉग और वेबसाइटों पर अकाउंट ढूँढकर फ़ॉलो किया। मेरे हिसाब से असली सोशल मीडिया इसी तरह काम करना चाहिए, न कि जबरन automated recommendation वाला कंटेंट ठूँसा जाए।
- अच्छी बात यह है कि bsky में एक non-algorithmic फ़ीड है जो सिर्फ़ उन लोगों की पोस्ट दिखाती है जिन्हें आपने फ़ॉलो किया है। मुझे लगता है मानसिक संतुलन बनाए रखने का यही एकमात्र तरीका है।
- मैंने bsky एक साल से ज़्यादा इस्तेमाल किया, लेकिन ज़्यादातर कंटेंट अमेरिकी राजनीति ही था। एक यूरोपीय होने के नाते यह मुझे सिर्फ़ शोर जैसा लगा। इसलिए मैं फिर Mastodon पर लौट गया। tech लोगों को फ़ॉलो करने के लिए Mastodon कहीं बेहतर था। न्यूज़ मैं feedly के RSS से ले लेता हूँ। अब तो समझ नहीं आता Bluesky की ज़रूरत ही क्या है। यह बस Twitter का left-wing संस्करण लगता है। टेक्नोलॉजी Nostr के विकसित रूप की तरह दिलचस्प थी, बस उतना ही।
- settings में जाकर Contents and Media > Your Interests > News and Politics को बंद करने की सलाह दूँगा। अगर आप अमेरिकी राजनीति नहीं बल्कि किसी और देश की न्यूज़ और राजनीति देखना चाहते हैं, तो उसके लिए मुझे कोई खास तरीका नहीं पता।
मुझे अब भी नहीं पता कि यह प्रोजेक्ट वास्तव में identity और data ownership की समस्याओं को अर्थपूर्ण तरीके से हल करता है या नहीं। identity के मामले में आपके पास या तो अपना domain होता है, या किसी और का domain इस्तेमाल करते हैं, जैसे Bluesky वगैरह। ज़्यादातर लोगों के पास domain नहीं होता, तो आख़िरकार उनकी identity किसी third party के हाथ में ही रहती है। data के साथ भी यही है। अगर Bluesky या किसी दूसरे server पर आपका अकाउंट block हो जाए, तो storage भी बंद हो जाती है और आप data कहीं और ले जाने का मौका भी खो सकते हैं। यह ईमेल जैसा ही है। जब तक आपका अपना domain और server नहीं है, असल में आपके नियंत्रण में कुछ नहीं है।
- AT में data handle या hosting से नहीं, बल्कि DID (Decentralized Identifier, विकेंद्रीकृत पहचानकर्ता) से जुड़ा होता है। मैंने अपनी पोस्ट में इस हिस्से को विस्तार से समझाया था। अगर आप अपना "handle" domain खो भी दें, तो बस इतना होगा कि handle अमान्य हो जाएगा और ऐप में username की जगह "invalid handle" दिखेगा। पोस्ट, followers और बाकी data DID से lookup किया जा सकता है, इसलिए वह बना रहता है। handle बस एक nickname जैसा है। handle बदलना भी ऐप के "change handle" फीचर से किया जा सकता है। hosting के साथ भी यही बात है — कुछ बाधाएँ हैं, लेकिन यदि आपने repository backup रखा है तो आप उसे कहीं और ले जा सकते हैं। backup automation भी संभव है, और third-party apps पहले से हैं जो auto backup करती हैं। आधिकारिक Bluesky ऐप से भी repository export की जा सकती है। जब hosting provider सहयोगी हो, तो PDSMover जैसा मामला काम आता है। और अगर वह सहयोग न करे, तब भी adversarial pds migration देखें तो यह संभव है। अभी इसमें technical knowledge चाहिए, लेकिन उम्मीद है कि समय के साथ यह प्रक्रिया आसान होगी। repository को नए host पर अपलोड कर दें तो वही identity, वही पोस्ट, वही followers आदि पहले जैसे लौट आते हैं। इस मायने में यह ईमेल से काफ़ी अलग है। अभी थोड़ा कठिन है, लेकिन AT ecosystem के विकसित होने के साथ यह कहीं अधिक आसान हो जाना चाहिए।
- domain होने पर भी यह तय नहीं कि वह हमेशा आपके पास रहेगा। server के विपरीत, domain के लिए registrar पर निर्भर रहना पड़ता है, इसलिए यह कुछ अधिक नाज़ुक लगता है। इसी वजह से मैंने registrar चुनते समय अपने देश के कानून के तहत आने वाली कंपनी चुनी, ताकि समस्या होने पर recovery की कुछ बेहतर उम्मीद रहे।
- जिन अधिकांश users के पास domain नहीं है, वे हमेशा उस जोखिम के सामने हैं कि hosting provider जैसे ही "दुश्मन" बन जाए — उदाहरण के लिए अचानक अकाउंट block कर दे। पूर्ण सुरक्षा तभी संभव है जब आप किसी neutral TLD के तहत domain खुद own करें और DNS से traffic route करें। फिर भी, इस यथार्थ के भीतर — कि लगभग कोई अपना domain इस्तेमाल नहीं करेगा — यह प्रोजेक्ट कुछ आंशिक flexibility और protection जोड़ता है, जो Big Social (Facebook, X, Instagram आदि) की तुलना में प्रगति है, जहाँ data हमेशा के लिए फँस जाता है। Bluesky शायद इसी वजह से दिलचस्प है कि ऐसे माहौल में handle वैसा ही रखते हुए सिर्फ़ data hosting बदली जा सकती है। मेरा मानना है कि उद्योग एक ही बार में perfection हासिल नहीं करता; वह व्यावहारिक समस्याओं में क्रमिक सुधार करते हुए आगे बढ़ता है।
- identity proof का सबसे अच्छा तरीका मेरे हिसाब से private key का स्वामित्व है। hosting के लिए BitTorrent शायद सबसे मज़बूत विकल्प हो सकता है। content को git repository में रखकर, commits पर sign करके, उन्हें torrent से distribute करने का मॉडल भी सोचा जा सकता है। update notifications के लिए मैंने NNTP या RSS के बारे में सोचा था। दिक्कत है discoverability और interaction की कमी, जैसे comments न होना।
- कम से कम ईमेल में आप अपनी PGP/SMIME keys साथ ले जाकर कहीं और migrate कर सकते हैं। सोच रहा हूँ क्या ATproto का concept भी कुछ ऐसा ही है।
Dan की व्याख्याएँ हमेशा शानदार होती हैं। हाल की उस ख़बर के संदर्भ में यह और भी समयानुकूल है कि Bluesky PLC का संचालन अधिकार transfer कर रहा है। हमारी टीम ने भी fair.pm में WordPress plugins के distributed वितरण के लिए यही DID system चुना है — मोटे तौर पर कहें तो यह App Store जैसा package management है। Bluesky की तरफ़ से, ख़ासकर Bryan ने, बहुत मदद की और हमें libsodium इस्तेमाल करने के लिए Ed25519 key support तक दिलवाया। हमारा protocol DID और Bluesky के stackable moderation के ऊपर design किया जा रहा है, लेकिन हम सीधे atproto इस्तेमाल नहीं करते। महत्वपूर्ण बात यह है कि DID एक W3C standard है, इसलिए PLC atproto तक सीमित नहीं है।
- "हम" कौन हैं, और अगर यह WordPress drama को तकनीकी रूप से हल करने की कोशिश है, तो थोड़ा और विस्तार से जानना चाहूँगा।
- आपने कहा कि PLC atproto पर निर्भर नहीं है, लेकिन PLC (did method) क्या आख़िरकार bluesky या किसी केंद्रीय authority से बँधा नहीं है? अगर यह इतना centralized है, तो इसे DID क्यों कहा जाता है? did:plc portable भी नहीं है। इसे did:web की तरह क्यों नहीं बनाया गया, जिसमें PLC जैसा व्यवहार जोड़ा जा सके? method-specific-id को public key hash जैसे portable आधार पर क्यों नहीं बनाया गया? और DHT जैसे decentralized मॉडल, जैसे did:pkarr, की दिशा में क्यों नहीं गए? PLC तो अंततः एक और केंद्रीयकृत प्रणाली जैसा लगता है।
at:// को resolve करने के लिए plc.directory पर GET request भेजनी पड़ती है, और यहीं सिस्टम मुझे 100% centralized model में बदलता दिखता है। कम-से-कम कई trusted directories को protocol से अलग रखने का विकल्प होना चाहिए था, जैसे DNS root या CA।
- अगर आप इसे व्यक्तिगत रूप से करना चाहते हैं, तो did:web:fqdn भी इस्तेमाल कर सकते हैं। इसका ज़िक्र पोस्ट में भी है।
at:// links को store करने वाले सभी servers को आख़िरकार DNS/HTTPS के ज़रिए canonical permalink representation ढूँढनी होगी। अगर DNSSEC ठीक से न हो, तो यह ढाँचा कुछ कमजोर लगता है। मैंने इस पर बहुत गहराई से नहीं सोचा, लेकिन पहली चिंता यही आती है कि DNS poisoning जैसी समस्या से कोई attacker मेरे नाम से पोस्ट कर सकता है, क्योंकि public key तो DNS से मिली DID में शामिल होगी।
- DNS poisoning चिंता का विषय हो सकता है, लेकिन व्यावहारिक रूप से यह हमेशा वैसा नहीं होता। at:// में authority की जगह DID डालना सामान्य है, इसलिए अगर आप handle की जगह DID से request करते हैं, तो अंततः HTTPS और web PKI पर निर्भरता रहती है। अगर शुरुआत handle से भी करें, तो web PKI और TXT record के रास्ते से गुज़रना पड़ता है। अनुशंसित तरीका यह है कि servers handles को resolve करें, और अगर आपको यह खुद करना पड़े तो किसी trusted DoH (HTTPS DNS) provider से query करें। यह पूर्ण नहीं है, लेकिन attack surface बहुत कम कर देता है। DNSSEC निश्चित रूप से इस समस्या का समाधान है, लेकिन वास्तविक production networks में मुझे DNSSEC की वजह से कई बार दिक्कतें झेलनी पड़ी हैं। उदाहरण के लिए, अमेरिकी senators identity verification के लिए senate.gov domain इस्तेमाल करते हैं, लेकिन हाल में DNSSEC config बिगड़ने से दर्जनों senators Bluesky पर "invalid handle" के रूप में दिखे थे। ऐसे निराशाजनक अनुभवों के कारण मैं अभी DNSSEC को अनिवार्य बनाने के पक्ष में ज़ोर नहीं दे रहा। अगर कोई और बड़ा protocol इसे सफलतापूर्वक लागू करता है, तो दोबारा सोचा जा सकता है।
- अगर कोई attacker आपकी identity बनकर पोस्ट करना चाहता है, तो उसे private key की ज़रूरत होगी। DNS records सिर्फ़ यह बताते हैं कि DID document कहाँ से लाना है, और उस DID document को DNS के ज़रिए फिर verify किया जाना होता है। इस प्रक्रिया में verification logic मौजूद है। DNSSEC DNS record tampering के जोखिम को कम करता है, लेकिन DNSSEC न होने का मतलब यह नहीं कि कोई भी व्यक्ति आपकी पहचान बनकर पोस्ट कर सकता है। server भी ऐसी चीज़ को reject कर देगा।
- यह हिस्सा थोड़ा जटिल है, लेकिन DNS TXT method में भी साफ़ लिखा है कि "DNSSEC आवश्यक नहीं है"। कुल मिलाकर DNS सिर्फ़ Handle -> DID रूपांतरण के लिए है, जबकि verification एक दो-तरफ़ा प्रक्रिया है जिसमें DID -> Handle भी शामिल है।
पोस्ट में DID change history में इस्तेमाल होने वाली keys के बारे में पर्याप्त जानकारी नहीं है। उदाहरण के लिए, अगर मैं foobar.bsky.social हूँ, तो मुझे याद नहीं कि मैंने कभी कोई key खुद upload की हो या उसे download करने के लिए कहा गया हो। जानना चाहता हूँ कि keys असल में कहाँ हैं, उनका मालिक कौन है, और वे कब और कैसे इस्तेमाल होती हैं। और अगर DID plc.directory पर है, तो उस साइट का operator मेरी DID को मनमाने ढंग से overwrite करके मेरी identity हड़प न ले, इसे रोकने की व्यवस्था क्या है?
at:// का concept दिलचस्प है, लेकिन मैं उन समस्याओं को लेकर भी चिंतित हूँ जो data ownership आधारित systems में आ सकती हैं। जैसे, user के पास data है, तो वह कभी भी content को मनचाहे तरीके से बदल या मिटा सकता है। पहले कोई ठीक-ठाक पोस्ट लिखी, फिर बाद में उसे दुर्भावनापूर्ण ढंग से बदल दिया। भले ही पुराने पोस्ट का hash रखकर tamper रोकने की कोशिश करें, नई services को उस इतिहास का पता नहीं होगा। likes/upvotes जैसी चीज़ों को track करना भी मुश्किल लगता है। अगर हर कोई सब कुछ अलग-अलग objects के रूप में store करे, तो किसने upvote किया यह ढूँढना कठिन होगा। नकली अकाउंट बनाकर कोई अपना ही कंटेंट बार-बार आगे बढ़ाता रहे, ऐसा भी लगता है कि रोकने की सीमा नहीं होगी। और अगर कई platforms से आने वाले अकाउंट्स की संख्या बहुत बड़ी हो जाए, तो spam और malicious activity की moderation असंभव नहीं हो जाएगी? यदि हर अकाउंट अपना data खुद manage करता है, तो transparency, accountability, moderation, spam control जैसे पूरे system design की बुनियाद टिकती है या नहीं, इस पर मुझे संदेह है।
- change history को साथ में publish किया जा सकता है। data (json) में आप अपनी ज़रूरत की पर्याप्त जानकारी रख सकते हैं, इसलिए पुराने पोस्ट addresses को at:// के रूप में linked list की तरह जोड़कर व्यक्त किया जा सकता है। DID identity moderation के संदर्भ में यह अच्छी तरह बताता है — यानी कौन है, उसे block करना है या नहीं, निर्णय लेने के लिए पर्याप्त आधार देता है। मुख्य बात यह है कि यह blockchain नहीं है, बल्कि data owner-केंद्रित साझा करने योग्य मॉडल है। जब तक कोई जानबूझकर इसे बिगाड़ने पर तुला न हो, यह काफ़ी आकर्षक ढाँचा है। "इस व्यक्ति का कौन-सा data कहाँ है" यह स्पष्ट रूप से पता चल सकता है। अगर ऐसी transparency वगैरह आपके लिए महत्वपूर्ण नहीं है, तो इसे इस्तेमाल न करना भी ठीक है।
- मूल content में दुर्भावनापूर्ण संशोधन रोकने के लिए strongRef नाम का hash-आधारित असली permalink मौजूद है। Dan ने पोस्ट में इसे विस्तार से नहीं बताया, लेकिन strongRef को store करके रखा जाए तो पुरानी पोस्ट का content बदलते ही इसका पता चल जाएगा। Bluesky edit फीचर न लाने की एक वजह यही malicious editing है। (संदर्भ: permalinks और record editing पर permalink प्रयोग सारांश, record editing history प्रयोग देखें।) upvotes को track करने के लिए network crawl करके data इकट्ठा किया जा सकता है और roaring bitmap जैसी चीज़ों से इसे मोटे तौर पर संभाला जा सकता है (roaring-bitmaps उदाहरण)। moderation की समस्या के लिए stackable moderation है, जो मौजूदा systems की तुलना में कहीं ज़्यादा दिलचस्प है। labeler/feedgen को DAG (set operations आधारित rule composition system) के रूप में बनाने पर भी चर्चा है। data forgery की समस्या में हर object के CID hash से बदलाव का पता चलता है, और change history track करना भी तकनीकी रूप से संभव है।
यह मुझे कई crypto protocols जैसा लगता है, जो decentralization की बात तो करते हैं लेकिन आख़िर में एक ही platform से बँध जाते हैं।
- अभी शुरुआती दौर है, लेकिन tangled.org (GitHub जैसा), leaflet.pub (Medium जैसा) आदि पहले से सक्रिय उपयोग में हैं। network indexing अपने-आप करने वाले tools, जैसे slices.network, की वजह से नए apps बनाने की बाधा लगातार कम हो रही है, इसलिए और apps आने की संभावना है। पोस्ट में यह समझाया गया था कि यह कैसे काम करता है। अहम बात यह है कि "सामान्य" users के लिए यह तकनीक इतनी महत्वपूर्ण नहीं होती। ज़्यादातर Bluesky users दरअसल "decentralization" के प्रति उदासीन हैं, या कभी-कभी नकारात्मक भी। लेकिन क्योंकि decentralized संरचना product की सतह पर सीधे नज़र नहीं आती — जैसे web browsing में नहीं आती — इसलिए इस तरह का adoption संभव है। users बस चाहते हैं कि चीज़ें "ठीक से काम करें"।
- यह कुछ हद तक Git और GitHub के पुराने इतिहास जैसा भी लगता है — धीरे-धीरे features बढ़ते गए और प्रणाली कुछ अधिक distributed और flexible होती गई।
"at:// URI से JSON कैसे मिलता है" यह एक बुनियादी संरचनात्मक सवाल है। documentation पढ़ने पर भी समझ नहीं आता कि आख़िर "उस JSON" की ज़रूरत क्यों है। व्यक्तिगत रूप से यह तरीका मुझे सहज नहीं लगता।
- परिचय थोड़ा अचानक था, उसके लिए माफ़ी। at:// protocol apps के बीच data को स्वतंत्र रूप से embed और export करने, user identity साझा करने, और content को self-host या migrate करने की सुविधा देता है। यह ऐसे permanent URI देता है जो handle/server पर निर्भर नहीं होते। तकनीकी सिद्धांत पूरी पोस्ट में समझाए गए थे। उदाहरण के तौर पर leaflet.pub और bsky.app दो apps हैं, जो एक ही public network से data इकट्ठा करते हैं, इसलिए अलग API के बिना भी वे आसानी से एक-दूसरे का data जोड़कर दिखा सकते हैं (demo post)।
- समझाने के लिए इसे ऐसे देखा जा सकता है जैसे कोई पूछे, "https:// URI से HTML कैसे मिलता है?" यह थोड़ा oversimplified है, लेकिन DNS, HTTP, TLS को पहली बार सीखने वाले को समझाने के लिए ठीक तुलना है।
क्या यह protocol एक विशाल public Kafka topic जैसा काम करता है? जैसे, अगर मैं नई webapp बनाऊँ, तो data खुद store करने की बजाय हर user अपना data अपनी जगह रखे, मैं एक listener रखूँ, protocol data propagation की गारंटी दे, और app उस data को सुनकर cache कर ले — क्या मॉडल ऐसा है? अवधारणात्मक रूप से यह काफ़ी दिलचस्प है, लेकिन जानना चाहता हूँ कि updates miss न हों इसके लिए offsets, scale के लिए partitions जैसी Kafka की अवधारणाएँ भी लागू होती हैं या नहीं।
- हाँ, firehose लगभग वही भूमिका निभाता है। कोई भी इसे subscribe कर सकता है या खुद firehose चला सकता है। ATProto distributed systems engineers के लिए विवरण देखें। firehose और jetstream में cursors होते हैं, इसलिए देर से जुड़ने पर भी आप ताज़ा data तक updates ले सकते हैं। coverage window instance के अनुसार 1–72 घंटे के बीच होती है। अगर पूरा इतिहास चाहिए, तो उसे backfill तरीके से संभाला जा सकता है।

at:// कहाँ स्थित है

AT protocol, at:// URI, और social data की identity resolution प्रक्रिया

# AT protocol और at:// URI की बुनियादी संरचना

# at:// URI resolution की तीन चरणों वाली प्रक्रिया

# उदाहरण के साथ resolution प्रक्रिया

# DID schemes: did:web और did:plc का अंतर

# identity, hosting और data का विभाजन तथा स्थायित्व

# व्यावहारिक उपयोग और development संदर्भ

# निष्कर्ष

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

1 टिप्पणियां

Hacker News राय