- Nostr एक खुला communication protocol है जो केंद्रीय नियंत्रण को बाहर रखता है, और ऐसा आर्किटेक्चर प्रदान करता है जिसे अलग-अलग client·relay संयोजनों के ज़रिए जानकारी को स्वतंत्र रूप से वितरित करने के लिए डिज़ाइन किया गया है
- उपयोगकर्ता निजी key·signature आधारित पहचान और संदेश की प्रामाणिकता सुनिश्चित करते हैं, और client एक साथ कई relay से जुड़कर distributed propagation और retrieval करते हैं
- protocol का कोई मालिक नहीं है, लेकिन हर relay operator अपनी नीति के अनुसार censorship·blocking के मानदंड तय करता है, और उपयोगकर्ता चुनते हैं कि कौन-से relay को पढ़ना है
- Twitter-शैली microblogging से आगे बढ़कर closed groups (NIP-29), marketplace, distributed wiki, code collaboration/torrent/livestreaming जैसे sub-protocols और ecosystem का विस्तार जारी है
- यह अभी तैयार finished product से ज़्यादा ऐसा चरण है जहाँ developer·early adopter participation की ज़रूरत है, और spam·scaling·discoverability जैसी चुनौतियों को client·relay combination strategy से हल किया जा रहा है
An open protocol with a chance of working
- Nostr राजनीतिक झुकाव से परे एक communication commons का लक्ष्य रखता है, और ऐसा simple standard परिभाषित करता है जिसे कोई भी implement और use कर सकता है, साथ ही यह scalable client/server architecture देता है
- यह किसी खास company·government के नियंत्रण में नहीं है, और विविध clients के ज़रिए एक ही information layer को अलग-अलग नज़रियों से दिखाने वाली open और chaotic early-internet sensibility को अपनाता है
- साइट वास्तविक client screenshots दिखाती है और ecosystem की diversity तथा practical usability पर ज़ोर देती है
Many clients, many servers
- केंद्रीकृत सेवाओं के विपरीत, Nostr clients एक साथ कई relay से जुड़ते हैं
- हर relay WebSocket-आधारित server होता है, जो रुचि के events को query और subscribe करने वाले distributed post store की भूमिका निभाता है
- किसी एक relay को single source of truth न मानने से censorship·shadowban risk distribution का प्रभाव मिलता है
- संदर्भ लिंक के माध्यम से मौजूदा मॉडल से अंतर समझाने के लिए learning material उपलब्ध कराया जाता है
A new paradigm for communication
- उपयोगकर्ता की पहचान गुप्त private key से व्यक्त होती है, और हर संदेश में digital signature शामिल होता है, जिससे बिना किसी authority के भी author authenticity सत्यापित की जा सकती है
- यह cryptographic trust base censorship-resistant broadcasting को संभव बनाता है
- आसान समझ के लिए वीडियो लिंक देकर शुरुआती प्रवेश की कठिनाई कम की गई है
The protocol is ownerless, relays are not
- protocol ownerless है, लेकिन relay निजी स्वामित्व में होते हैं, इसलिए हर operator मनचाहे accept/reject criteria तय कर सकता है
- उपयोगकर्ता स्वतंत्र रूप से यह चुनते हैं कि किन relay को पढ़ना है, इसलिए अभिव्यक्ति की विविधता और access choice साथ-साथ मौजूद रहते हैं
- “censorship के पक्ष/विरोध” जैसी द्विआधारी सोच के बजाय, यह server-wise rule plurality और user choice को केंद्र में रखता है
Freedom of association
- network effect किसी एक संगठन से बंधा नहीं है, इसलिए किसी खास user group के लिए दूसरों को संरचनात्मक रूप से नुकसान पहुँचाना कठिन होता है
- संबंधित वीडियो के माध्यम से association और separation की स्वतंत्रता पर ज़ोर दिया गया है
Your own piece of Nostr
- programmer आसानी से अपना custom relay चला सकते हैं और उस पर अपनी rules लागू कर सकते हैं
- relay implementation repository की ओर मार्गदर्शन देकर contribution और experimentation को प्रोत्साहित किया जाता है
New Ideas — Exploring the commons
- Twitter-शैली microblogging से आगे, यह video/long-form/image/voice note जैसे कई data types को support करता है
- closed groups, distributed Wikipedia, couchsurfing, marketplace, web annotation जैसे sub-protocol प्रयोग सक्रिय हैं
- git-based distributed code collaboration, file hosting, torrent sharing, video live जैसे क्षेत्रों में Nostr को discovery और coordination layer के रूप में उपयोग करने के प्रयास चल रहे हैं
- standard proposals के संग्रह NIP के माध्यम से features के विस्तार और interoperability को बढ़ावा दिया जाता है
Ecosystem — Still under construction
- open source software और बड़ा user base मौजूद है, लेकिन यह अभी polished end product के चरण में नहीं है
- early users·developers की भागीदारी protocol flow और UX improvements के लिए महत्वपूर्ण है
Microblogging — The outbox model
- outbox model को censorship-resistant client implementation के canonical approach के रूप में पेश किया जाता है, लेकिन parameters अभी भी flexible हैं
- implementation guide relay को storage की तरह treat करने के तरीके और subscription/publishing strategy समझाती है
Relay-based groups — NIP-29
- NIP-29 forum/chat-शैली closed groups को relay-आधारित तरीके से कुशलतापूर्वक implement करने का तरीका बताता है
- यह single relay dependency को घटाते हुए भी censorship resistance बनाए रखने वाली संरचना समझाता है
How Nostr works
- इसका लक्ष्य कठिन परिस्थितियों में भी user-audience connection बनाए रखते हुए वास्तविक स्वतंत्रता प्रदान करना है
- कई relay, local indexing और selective reading के ज़रिए sustained accessibility सुनिश्चित की जाती है
FAQ — मुख्य प्रश्न और उत्तर
-
“protocol” क्या है
- यह कई software के बीच संचार की common language है, और e-mail/HTML/HTTP की तरह किसी एक app पर निर्भर न रहने वाली interoperability को दर्शाता है
- एक ही भाषा साझा करने वाले कई apps एक-दूसरे के विकल्प बन सकते हैं, और हर एक अपनी expression·UI अलग रख सकता है
-
spam और unwanted content को कैसे संभाला जाता है
- default feed केवल जिन लोगों को मैं follow करता हूँ उनकी जानकारी लाती है, इसलिए push spam कठिन होता है
- comments देखने जैसे खुले retrieval spam के संपर्क में आ सकते हैं, इसलिए second-degree neighbor limits, trusted relay whitelist, paid/verified relay जैसी surface reduction strategies अपनाई जाती हैं
- कोई perfect solution नहीं है, लेकिन Nostr को resilience को ध्यान में रखकर डिज़ाइन किया गया है
-
बड़े पैमाने पर adoption होने पर क्या scaling संभव है
- आधार रूप में यह client-server architecture है, और उपयोगकर्ता स्वाभाविक रूप से सैकड़ों relay में distributed हो जाते हैं, इसलिए load distribution इसमें अंतर्निहित है
- कई relay connections चिंता पैदा कर सकते हैं, लेकिन लोग आमतौर पर समान रुचि वाले account groups को follow करते हैं, जिससे relay स्वाभाविक common denominator बनाते हैं
- native apps सैकड़ों WebSocket संभाल सकते हैं, और local database तथा batch requests के ज़रिए performance बनाए रखी जा सकती है
-
online harassment से कैसे निपटा जाता है
- spam की तरह unwanted posts संभव हैं, इसलिए blocking, shared blocklists, restricted-reading relay आदि के ज़रिए exposure minimization लागू किया जाता है
- friends-only view जैसी protective features को relay policies के माध्यम से emulate किया जा सकता है
-
Mastodon/Fediverse क्यों नहीं
- cryptography की अनुपस्थिति के कारण multi-master संभव नहीं होता, जिससे server-owned identity और inter-server trust transfer जैसी समस्याएँ पैदा होती हैं
- इसमें server operators पर अत्यधिक trust की ज़रूरत होती है, और domain·DNS dependency भी समस्या मानी जाती है
- Nostr server-unbound identity और relay choice के माध्यम से relay-स्तर पर वास्तविक community बनाने देता है
-
Bluesky/ATProto क्यों नहीं
- PLC-based identity centralization और Relay-AppView-Client के single canonical flow के कारण censorship·reordering·shadowban का जोखिम बड़ा है
- इसे multi-source बनाकर सुधार किया जा सकता है, लेकिन तब यह लगभग Nostr-जैसी संरचना की ओर converge करता है
-
क्या relay operators के incentives aligned हैं
- server चलाने की लागत कम है, और community/individual/organization/hosting providers जैसे कई पक्ष relay सस्ते में उपलब्ध करा सकते हैं
- उपयोगकर्ता कहीं भी जा सकते हैं, इसलिए विविध आर्थिक पक्षों के incentives naturally align होते हैं
-
क्या कई relay में बिखरी हुई सारी content देखी जा सकती है
- जैसे दुनिया की हर चीज़ नहीं देखी जा सकती, वैसे ही केवल focus और access permissions की सीमा के भीतर ही चीज़ें देखी जा सकती हैं
- यह attention और relay choice से पैदा होने वाली स्वाभाविक सीमा है
-
search कैसे काम करता है
- मूल रूप से जो देखा गया है उसी को search किया जा सकता है, इसलिए public search चाहिए तो crawler/indexer को चुनिंदा रूप से network collect करना होगा
- client local storage के माध्यम से मैंने जो content देखा/जिससे interact किया उसे local search से तेज़ी से ढूँढ सकते हैं
- topic relay अपनी indexing के आधार पर useful scoped search दे सकते हैं
-
algorithm न होने पर नया content कैसे discover होगा
- following के interaction graph exploration को आधार माना जाता है, और Nostr में भी local/relay/AI-based algorithms हो सकते हैं
- client-local highlight/return resurfacing, relay-side curation जैसी कई discoverability mechanisms लागू की जा सकती हैं
-
Bitcoin से इसका क्या संबंध है
- यह cryptographic principles साझा करता है और Bitcoin community से शुरू हुआ था, लेकिन कोई dependency नहीं है
- Zaps कुछ clients द्वारा implement किया गया Bitcoin tipping standard है और यह पूरी तरह optional है
1 टिप्पणियां
Hacker News राय
यह जानना ज़रूरी है कि Nostr की cryptography काफ़ी गंभीर रूप से कमजोर है
इस पेपर में बताए गए मुख्य vulnerability इस प्रकार हैं
event protocol public key authentication नहीं करता, इसलिए symmetric-key signatures बस औपचारिकता भर हैं
Damus, Iris जैसे दो बड़े clients signature को verify भी नहीं करते
सिस्टम के DM unauthenticated CBC encryption का इस्तेमाल करते हैं, इसलिए attacker message bit-flip करके सामग्री बदल सकता है
apps auto link preview बनाते हैं, जिससे पुराना EFAIL attack फिर संभव हो जाता है
सिस्टम में key separation नहीं है, इसलिए users को बहकाकर गलत session key इस्तेमाल कराई जा सकती है
कुल मिलाकर यह 2000 के दशक के मध्य स्तर की शुरुआती गलतियों जैसा है
Nostr के और फायदे हो सकते हैं, लेकिन अगर end-to-end security चाहिए तो यह सही platform नहीं है
मैं Nostr community में लंबे समय से सक्रिय रहा हूँ और Safari के लिए extension भी बनाया है
मैंने वह पेपर नहीं पढ़ा, लेकिन मुझे लगता है कि जिन बिंदुओं की आलोचना की गई है उनमें Nostr protocol को लेकर गलतफ़हमी या भ्रम है
Nostr में public key ही identity की तरह काम करती है
cryptography के हिसाब से public-key-based identity forge नहीं की जा सकती है (हालाँकि implementation bug अलग बात है)
UX के स्तर पर 'public key के मालिक की असली पहचान verify करना' मुश्किल हो सकता है, लेकिन यह cryptographic safety से अलग मुद्दा है
'event protocol public key authentication नहीं करता' यह बात बिल्कुल बेतुकी है
ज़्यादातर clients और relays वास्तव में signatures check करते हैं
Damus के लेखक के तौर पर कहूँ तो यह पुराने version की बात है — वह issue ठीक कर दिया गया है
शुरुआत में सिर्फ trusted relays से connect किया जाता था, और वे relays signatures verify करते थे
optimized signature verification के लिए nostrdb नाम का embedded DB तक बनाया गया था
यह दावा भी गलत है कि DMs unauthenticated CBC होने की वजह से attackable हैं
पूरा note secp256k1 signature से cover होता है
auto link preview, images आदि को on/off किया जा सकता है, और अगर चिंता हो तो VPN recommended है
मैंने यह पता लगाने की कोशिश की कि Nostr में कौन-सा key algorithm इस्तेमाल होता है, लेकिन documentation में कहीं भी यह सीधे नहीं लिखा है
search करने पर सब कुछ Blech32 (Bitcoin key encoding) से जुड़ी चीज़ों पर पहुँचता है
hellonostr.dev का परिचय दस्तावेज़ देखें, तो पता चलता है कि encoding में version information खुद शामिल होती है
npub1abcxyz...format मेंnpubheader है,1version है, और उसके बाद key आती हैसंबंधित docs देखें
जिन समस्याओं की ओर इशारा किया गया है, वे असल में implementation-dependent हैं (जैसे signature verify न करने वाले apps, जो protocol की बुनियाद को ही तोड़ते हैं),
या फिर शुरुआती अस्थायी encryption scheme से जुड़ी हैं (जिन्हें पहले ही NIP44 आदि से replace किया जा चुका है और independent audit भी हो चुका है)
अभी की स्थिति में कुछ भी ऐसा नहीं दिखता जो fatal हो या जिस पर तत्काल व्यावहारिक response की ज़रूरत हो
समझ नहीं आता कि मैं यह बातें अब पहली बार क्यों सुन रहा हूँ
इन पर जल्दी चर्चा होनी चाहिए
protocol के नज़रिए से ज़्यादा सुरक्षित federated platform bluesky(at protocol) है या fediverse, यह जानने में दिलचस्पी है
बहुत से लोग यह गलत समझते हैं कि Nostr relays federation बनाकर messages शेयर करते हैं
असल में ऐसा नहीं है
अगर आप Twitter clone बनाते हैं, तो client app को कई relays पर खुद search और post करना पड़ता है
और अगर common relay इस्तेमाल नहीं होगा, तो लोग एक-दूसरे के messages देख ही नहीं पाएँगे
अगर सिर्फ एक relay इस्तेमाल करें तो यह पूरी तरह centralized हो जाता है,
और कई relays इस्तेमाल करने पर यह धीमा और झंझट भरा हो जाता है, इसलिए users को खुद समझना पड़ता है कि कौन-से relays connect करने हैं
NIP docs भी बिखरे हुए हैं, इसलिए maintenance मुश्किल रहा है
relays federation भी बना सकते हैं
Nostr protocol federation को लेकर कुछ भी तय नहीं करता
मैं एक indexer (relay) चला रहा हूँ, और यह indexer दूसरे relays के साथ interoperate करता है
ActivityPub relay की तरह कोई भी client indexer से connect करके bootstrap कर सकता है और event metadata खोज सकता है
एक ही relay से जुड़े बिना भी clients के बीच अलग-अलग तरीकों से जानकारी साझा हो सकती है
मुझे लगता है यह काफ़ी दिलचस्प कठिन समस्या है
अगर NIP65 की तरह profile metadata में read और write relays बताए जाएँ,
तो clients आसानी से सभी relevant content ढूँढ सकते हैं
इसके अलावा और भी कई ideas पर experiment चल रहा है
मुझे लगता है यह solve की जा सकने वाली समस्या है
relays user-generated content के मालिक नहीं होते, इसलिए federation की ज़रूरत नहीं है
clients आम तौर पर user द्वारा चुने गए relay set पर निर्भर करते हैं
फिर भी कई प्रमुख relays दूसरे relays के events भी store करते हैं, यानी एक तरह की federation चलाते हैं
उदाहरण: Primal, TheForrest, nostr.land
nostr.land एक paid relay है जिसका मुख्य काम spam filtering और कई public relays के notes को aggregate करना है
अगर आप नहीं चाहते तो कोई दूसरा relay चुन सकते हैं
ज़्यादातर users मौजूदा relay federation में 99% से ज़्यादा notes देख पाते हैं, हालाँकि असली आँकड़ा verify नहीं किया जा सकता
कुछ clients और signers notes को privately store करते हैं,
और अगर relay notes censor करे, तो उन्हें कभी भी दूसरे relay पर दोबारा post किया जा सकता है
वास्तव में अगर आप कोई लोकप्रिय paid relay इस्तेमाल करेंगे, तो 3/4 write events पर जल्दी ही “पहले से दूसरे relay पर registered” जैसी warning दिखने लगेगी
अंत में, relays खुद client की तरह भी काम कर सकते हैं, और यह mobile या धीमे network में cache के रूप में सुविधाजनक होता है
outbox model की अपनी समस्याएँ हैं, लेकिन client developers users को options दे सकते हैं,
इसलिए इसे federated से P2P तक काफ़ी लचीले ढंग से बढ़ाया जा सकता है
ज़्यादातर clients outbox support करते हैं, इसलिए एक ही relay इस्तेमाल करने की ज़रूरत नहीं
हर user के पास अलग inbox और outbox relays हो सकते हैं
NIP docs में कुछ अजीब हिस्से रहे हैं
लेकिन ज़्यादातर NIP लगातार बेहतर हो रहे हैं,
और अगर official regular release हो तो यह छोटा-सा issue आसानी से सुलझ सकता है
बहुत-से developers तेज़ी से response दे रहे हैं
अच्छा होगा अगर ऐसे projects use case, philosophy और implementation को साफ़-साफ़ अलग करके समझाएँ
पहली नज़र में समझ ही नहीं आता कि यह social network है या protocol
“क्या यह censorship-oriented है? क्या मुझे blog article पढ़ना पड़ेगा?”
Scuttlebutt, Mastodon, ActivityPub, Diaspora आदि में भी यही समस्या है
आख़िर “यह email से कैसे अलग है?”, “Twitter की तुलना में इसमें क्या बेहतर है?”
समझने से पहले ही “यह technical implementation है, product है, site है या app” — यही confusion शुरू हो जाता है
शायद बहुत कम लोग Urbit को भी ठीक-ठीक समझा पाएँगे
फिर भी यह “Web3” से बेहतर लगता है
Bluesky और Gemini इस मामले में काफ़ी स्पष्ट हैं
Nostr, P2P संरचना और web architecture के बीच एक समझौता-आधारित solution है
यह web servers का इस्तेमाल करके internet के मौजूदा flow के साथ चलता है,
जबकि users server dependency कम कर सकते हैं और public key/signature के ज़रिए identity और data authentication मज़बूत कर सकते हैं
नतीजतन users को “credible exit” जैसी autonomy मिलती है
इसलिए इसे नया use case कहने के बजाय “नया internet” कहा जाता है
इसमें platform-centric नहीं बल्कि user-centric tradeoff हैं (UX pattern के फ़र्क समेत)
यह मौजूदा social networks के censorship resistance जैसे values देता है,
इसलिए इसके social application use cases ज़्यादा दिखाई देते हैं
आपको ऐसा site खुद बनाकर देखना चाहिए
product description की पहली पंक्ति में “apolitical” शब्द का इस्तेमाल बहुत अजीब लगा
और उसी में “open” भी लिखा है, जबकि यहाँ उसका स्वभाव से ही political अर्थ है
मुझे याद नहीं कि Nostr का cryptocurrency से कोई रिश्ता था या नहीं, लेकिन कुछ गड़बड़-सा ज़रूर लगा था
Nostr में कोई “nostr coin” नहीं है, और न ही कोई onchain action है
यही बात मुझे बहुत पसंद है
खासकर इसलिए कि Nostr और cryptocurrency community का overlap लगभग पूरा का पूरा लगता था
Bitcoin इस्तेमाल करने वाले users काफ़ी हैं
दक्षिणपंथियों का खुद को “apolitical” कहने का लंबा इतिहास रहा है
Nostr, Mastodon, Discord जैसी federation/distributed structure वाली services में
client app के भीतर खुद का relay embed होना चाहिए ताकि हर user server की भूमिका भी निभाए — तभी सच में distributed SNS संभव होगा
पुराना P2P software पहले से ऐसा करता आया है, और वह वाकई काम भी करता है
लेकिन अगर users ऐसा data भी मनमाने ढंग से host करें जो उन्होंने खुद हासिल नहीं किया,
तो illegal content की वजह से सज़ा का जोखिम होता है (जैसे airport पर illegal drugs possession का मामला)
इसी risk की वजह से अगली पीढ़ी की P2P संरचना में AI-based “illegal content filtering” (जैसे CP, movies) की ज़रूरत पड़ेगी
या फिर इसे पूरी तरह closed community बनाया जाए,
ताकि अगर कोई समस्या हो भी तो ज़िम्मेदारी उसी community के भीतर सीमित रहे
अंततः हर client के server भी होने वाला model ही distributed social का सबसे अच्छा model है
iroh नाम का project इसी तरह काम करता है
“relay” सिर्फ दो clients के बीच connection relay करने की भूमिका निभाता है
iroh concepts explanation लिंक देखें
सुनने में अच्छा है, लेकिन असली P2P architecture अक्सर ठीक से नहीं चलता
iroh भी अंदरूनी तौर पर relays पर निर्भर करता है
Nostr relays को policy enforcement की authority सीधे देता है (और यह किसी अलग hack के बिना built-in है)
अच्छा लगा कि Nostr HN top पर पहुँचा
यह अभी शुरुआती दौर में है, लेकिन Nostr में “zapps” (Bitcoin-Lightning आधारित instant micropayments) भी संभव हैं
यानी creators को बिना ads या algorithm issues के सीधे छोटे भुगतान किए जा सकते हैं,
एक decentralized, ad-free social model के रूप में
Nostr client PR work के लिए भी zaps से reward दिया जा सकता है
संबंधित bounty example देखें
Bitcoin पहले से ही काफ़ी regulated है
ऐसी comments पढ़कर sign up करने का मन होने लगता है, लेकिन actual discovery page पर
लोग असली products (flags, Kakao, alternative education आदि) का लेन-देन करते दिखे, जो काफ़ी दिलचस्प था
यह सिर्फ “डायरी public करो और पैसे माँगो” वाला मामला नहीं है
यह असली products, services और creators के लिए platform जैसा लगा
Nostr कम-से-कम 5 साल से मौजूद है
pandemic के समय भी Twitter से Nostr पर जाने वाले लोग काफ़ी थे
इसलिए इसे अभी बस शुरुआती चरण में कहना सही नहीं लगता
अलग-अलग Nostr apps का परिचय
openux.app - Mobbin का विकल्प
kinostr.com - real-time movie chat
zap.stream - Twitch-style live streaming
dtan.xyz - torrent
zapstore.dev - permissionless app store
nostrnests.com - audio room chat
zapmeacoffee.com - Buy Me A Coffee जैसा
asknostr.site
इस तरह decentralized social protocol कई अलग-अलग use cases को संभव बनाता है,
और user के नज़रिए से इसके फ़ायदे हैं
Nostr को सिर्फ microblogging service की तरह इस्तेमाल करना ज़रूरी नहीं, नीचे की layer में इसके और भी इस्तेमाल हैं
उदाहरण के लिए Trystero
central server के बिना P2P WebRTC connection बनाने के लिए Nostr का उपयोग करता है
(MIT license)
मैंने भी कभी Nostr, Bittorrent DHT, Mastodon आदि के साथ censorship-resistant multi-channel broadcast के बारे में सोचा था
लक्ष्य यह था कि network disruption तभी हो जब सारे तरीके एक साथ fail हो जाएँ
इसी तरह मुझे यह भी जिज्ञासा थी कि Nostr या ATProto
P2P instant messenger के “offline message storage” के रूप में इस्तेमाल हो सकते हैं या नहीं
connection setup के लिए इसका उपयोग करना काफ़ी नया तरीका लगा
यह सच में शानदार idea है
मैं भी कुछ ऐसा करना चाहता था, लेकिन अच्छा हुआ किसी और ने पहले ही बना दिया, मेरा समय बच गया
समझ नहीं आता कि ऐसे technical social networks पुराने web की तरह
व्यक्तिगत homepage आपस में जोड़ने वाली संरचना की जगह
अलग account-based platform की ओर क्यों चले जाते हैं
RSS के अलावा, क्या ऐसा कोई प्रयास नहीं हुआ जिसमें personal sites को बढ़ावा दिया जाए
और ऊपर से centralized social media (chat, feed आदि) जैसा network layer जोड़ा जाए?
यहाँ “account” असल में public/private key pair ही है
आप अपना relay खुद भी चला सकते हैं,
और उसी public key के साथ कोई भी relay इस्तेमाल कर सकते हैं
posts को अपनी पसंद के सभी relays पर broadcast भी कर सकते हैं
चाहें तो हर post के लिए नई key भी बना सकते हैं
Mastodon आदि में account server से बँधा होता है, इसलिए portability और freedom कम हो जाती है
हालाँकि account recovery का कोई तरीका नहीं होना एक समस्या हो सकती है
RSDS(Really Simple Decentralized Syndication) देखना उपयोगी हो सकता है
कुल मिलाकर nostr की संरचना कुछ ऐसी ही है
बस website की जगह “note” data type है, और server की जगह सिर्फ “relay” है
आप इसे “स्पष्ट रूप से developers के लिए बनी service” क्यों मानते हैं, यह पूछना चाहूँगा
क्या आप founders के इरादों के बारे में ज़्यादा मानकर नहीं चल रहे?
असल में अलग-अलग technologies को जोड़कर
personal homepage/chat/feed system आज भी खुद बनाया जा सकता है
लेकिन ऐसे hybrid model की व्यावहारिक समस्याएँ हैं
इन सबको एक साथ हल करने की कोशिश में tradeoff आना तय है
पूरी decentralization अक्सर discoverability और accessibility की क़ीमत पर आती है
“अब account की ज़रूरत नहीं” जैसी बात online/offline multiple identities के सवाल से भी जुड़ती है
आख़िरकार यह values की choice है, और developers के बीच लोकप्रिय कई experimental decentralized services (जैसे Mastodon, Nostr, Smolweb)
शुरुआती internet mindset (counterculture, open, standardization, composability) से प्रभावित हैं
सबको संतुष्ट करने वाला एक ही समाधान नहीं हो सकता,
इसलिए मुझे लगता है कि internet की असली ताकत diversity, standardization और openness में है
“apolitical communication commons”
कुछ लोगों ने कहा कि ‘गैर-राजनीतिक’ का यह tag खुद
एक political statement और power position है
समझ नहीं आता कि “politics” से इतना डर क्यों है
एक उदाहरण दिया गया कि प्राचीन Greek सोच में नागरिक के रूप में political participation स्वाभाविक कर्तव्य था
वास्तव में ‘idiot’ शब्द की व्युत्पत्ति भी apolitical व्यक्ति से जुड़ी है
“apolitical” की धारणा
वास्तव में authoritarian regime के तहत चुप रहकर मौजूदा व्यवस्था का मौन समर्थन करने वाले व्यक्ति की तरह देखी जाती है
Russia जैसी dictatorship में यही स्वतंत्रता-दमन और repression का सीधा रास्ता बन जाता है
Nostr जैसी services को भी सरकारें “relay चलाना illegal/criminal है” घोषित करके रोकने की कोशिश करती रही हैं
“अगर सब कुछ political है, तो फिर कुछ भी political नहीं है”
शायद लेखक सिर्फ non-technical बहसों से बचना चाहता है
“apolitical” को इस अर्थ में भी पढ़ा जा सकता है कि सबका स्वागत है
प्रवेश की एकमात्र शर्त internet connection है
और शायद यह पिछले 10 साल में SNS censorship trend के खिलाफ reaction के संदर्भ में लिखा गया होगा
कुछ लोग यह भी कहते हैं कि “अगर आपके पास किसी तरह का विशेषाधिकार है, तो उसका इस्तेमाल दूसरों की मदद के लिए करना चाहिए”
यह बात यहाँ भी लागू हो सकती है