Nostr

प्लेटफ़ॉर्म · विस्तृत विश्लेषण ख़ुद प्लेटफ़ॉर्म के और ख़ुद प्लेटफ़ॉर्म के और सहायक टूल के पेजों से।

यह भी देखें: कार्ड कैसे पढ़ें и स्रोतों और पद्धति के बारे में.

अवलोकन

Nostr कोई प्लेटफ़ॉर्म नहीं, बल्कि एक प्रोटोकॉल है। इस नाम का पूरा रूप है Notes and Other Stuff Transmitted by Relays — «नोट्स और अन्य सामग्री, जो रिले के ज़रिये भेजी जाती है»। साइट nostr.com इसका वर्णन इस तरह करती है: «एक स्वतंत्र और खुला नेटवर्क, जिसका न कोई मालिक है और न कोई उस पर नियंत्रण रखता है»।

ढाँचा सरल है और बाकी सब उसी पर टिका है। रिले होते हैं — वे सर्वर, जो संदेश रखते और बाँटते हैं। क्लाइंट होते हैं — वे ऐप, जिनके ज़रिये लोग पढ़ते और लिखते हैं। और कुंजियाँ होती हैं: सार्वजनिक कुंजी उपयोगकर्ता-नाम की तरह काम करती है, निजी कुंजी पासवर्ड की तरह; आपकी पहचान पर आपका हक़ किसी कंपनी से नहीं, इन्हीं कुंजियों से आता है। चूँकि पहचान ऐप की नहीं, कुंजी की होती है, इसलिए आप एक क्लाइंट से दूसरे पर जा सकते हैं और प्रोफ़ाइल, सब्सक्राइबर तथा पोस्ट अपने साथ ले जा सकते हैं।

तकनीकी रूप से सब कुछ एक ही प्रकार की वस्तु पर आ टिकता है। प्रोटोकॉल का आधार दस्तावेज़ कहता है: अस्तित्व में केवल एक ही प्रकार की वस्तु है — «इवेंट» (event), हस्ताक्षर और कुंजियाँ secp256k1 वक्र पर श्नोर योजना का उपयोग करती हैं, और रिले बाहर की ओर एक websocket बिंदु खोलता है, जहाँ क्लाइंट तीन तरह के संदेश भेजता है: प्रकाशन के लिए EVENT, चयन की सदस्यता के लिए REQ और उसे बंद करने के लिए CLOSE।

इस संदर्भ पुस्तिका के लिए इसका अर्थ यह है: Nostr का कोई मालिक नहीं, कोई एक दर्शक-वर्ग नहीं, कोई विज्ञापन कैबिनेट नहीं, कोई मॉडरेशन नियम नहीं और कोई भुगतान कार्यक्रम नहीं। आगे यही देखा गया है कि उनकी जगह क्या है।

यहाँ कौन है

Nostr के दर्शकों का कोई आँकड़ा मौजूद नहीं है — और सामान्य रूप में हो भी नहीं सकता। ऐसा कोई केंद्रीय सर्वर नहीं है जो उपयोगकर्ताओं की गिनती करे: कई स्वतंत्र रिले हैं, और हर रिले केवल अपने ही लोगों को देखता है।

अप्रत्यक्ष अनुमान केवल अलग-अलग रिले से लगाया जा सकता है। nostr.com का क्लाइंट डिफ़ॉल्ट रूप से छह रिले से जुड़ता है और उनकी सूची सीधे इंटरफ़ेस में दिखाता है: relay.nostr.com, relay.damus.io, nos.lol, nostr.bitcoiner.social, nostr.mom और relay.snort.social। रिले की सूची देखने के लिए परियोजना बाहरी टूल Nostr.watch की सलाह देती है, और क्लाइंट की सूची के लिए nostrapps.com की (रिले के बारे में पृष्ठ, क्लाइंट के बारे में पृष्ठ)।

भाषा और देश के अनुसार कोई विभाजन नहीं है और हो भी नहीं सकता: प्रोटोकॉल उपयोगकर्ता की ऐसी जानकारी रखता ही नहीं। प्रोफ़ाइल में डिफ़ॉल्ट रूप से केवल नाम, विवरण और चित्र होता है।

शुरुआत कैसे करें

सामान्य अर्थ में पंजीकरण है ही नहीं: खाता एक कुंजी-युग्म है, जिसे ऐप स्वयं बनाता है। न मेल की पुष्टि, न फ़ोन नंबर, न आवेदन की जाँच।

इसी से वह मुख्य जोखिम निकलता है, जिसकी चेतावनी परियोजना स्वयं देती है: निजी कुंजी खाते तक पूरी पहुँच देती है — उससे आपके नाम पर लिखा जा सकता है, प्रोफ़ाइल बदली जा सकती है और संदेश भेजे जा सकते हैं; यदि कुंजी खो जाए और प्रतिलिपि न हो, तो «पासवर्ड भूल गए» जैसा कोई बटन मौजूद नहीं है। परियोजना की व्यावहारिक सलाह: अपनी निजी कुंजी हर ऐप में डालते मत जाइए — हस्ताक्षर करने वाला ब्राउज़र एक्सटेंशन या दूरस्थ हस्ताक्षरकर्ता अधिक सुरक्षित है।

«टिक» जैसा सत्यापन योग्य नाम पाया जा सकता है: प्रोटोकॉल का एक अलग दस्तावेज़ कुंजी को डोमेन से जोड़ने का तरीका बताता है। क्लाइंट प्रोफ़ाइल से नाम@डोमेन रूप का पता लेता है, https://डोमेन/.well-known/nostr.json?name=नाम पर अनुरोध भेजता है और मिली सार्वजनिक कुंजी की तुलना पोस्ट के लेखक की कुंजी से करता है। किसी कंपनी के लिए यही वह तरीका है जिससे यह पुष्टि हो कि खाता सचमुच उसी का है: पुष्टि डोमेन पर नियंत्रण से मिलती है, किसी मॉडरेटर के निर्णय से नहीं।

अलग से कोई व्यावसायिक खाता नहीं है — जैसे साधारण खाता भी नहीं है। Nostr में कंपनी की उपस्थिति का अर्थ है उसके डोमेन से जुड़ी एक कुंजी और, यदि वह चाहे, अपना रिले।

क्या प्रकाशित किया जा सकता है

प्रारूप इवेंट के «प्रकारों» से तय होते हैं, और प्रकार अलग-अलग दस्तावेज़ों में बताए गए हैं — NIP (Nostr Implementation Possibilities)। उनकी सूची एक खुले रिपॉज़िटरी में रखी जाती है और उसमें, अन्य बातों के साथ, ये शामिल हैं: छोटे नोट और चर्चा की शृंखलाएँ, लंबी सामग्री, चित्र और वीडियो, लाइव प्रसारण और «स्पेस», सर्वेक्षण, कैलेंडर इवेंट, विकी, टोरेंट, सूचियाँ, बुकमार्क और उद्धरण (NIP की सूची)।

लंबाई और आकार की सीमाएँ प्रोटोकॉल में नहीं हैं — वे रिले में हैं, और रिले को उन्हें घोषित करना ही होता है। रिले की जानकारी वाला दस्तावेज़ इन क्षेत्रों का वर्णन करता है: max_message_length — आने वाले JSON का अधिकतम आकार बाइट में (व्यवहार में यही इवेंट का आकार भी सीमित करता है), max_content_length — सामग्री क्षेत्र में वर्णों की अधिकतम संख्या, max_event_tags — टैग की अधिकतम संख्या, max_subscriptions — एक ही कनेक्शन पर एक साथ चलने वाली सदस्यताओं की संख्या, max_limit — एक अनुरोध के उत्तर में इवेंट की अधिकतम संख्या।

व्यवहार में यह ऐसा दिखता है। रिले relay.damus.io जाँच की तिथि पर संदेश की सीमा 1 000 000 बाइट, 200 सदस्यताएँ और चयन की अधिकतम सीमा 500 इवेंट घोषित करता है; रिले nos.lol — 131 072 बाइट, 20 सदस्यताएँ, वही 500 इवेंट; रिले relay.nostr.com — 131 072 बाइट, 200 सदस्यताएँ, 500 इवेंट। ये संख्याएँ हर रिले की अपनी हैं, और दूसरे रिले पर ये अलग होंगी।

सामग्री पर प्रोटोकॉल की ओर से कोई प्रतिबंध नहीं हैं। तकनीकी चिह्नांकन ज़रूर है: एक दस्तावेज़ संवेदनशील सामग्री पर निशान लगाने का वर्णन करता है, दूसरा — इवेंट की शिकायतों का, तीसरा — हटाने के अनुरोध का। «अनुरोध» शब्द पर ध्यान दीजिए: Nostr में हटाना रिले से की गई एक विनती है, कोई गारंटी नहीं। क्या स्वीकार करना और रखना है, यह रिले का मालिक तय करता है।

कैसे बढ़ें

प्रोटोकॉल में एल्गोरिद्म वाली फ़ीड नहीं है। उपयोगकर्ता को क्या दिखाना है, यह क्लाइंट तय करता है, और कौन-से इवेंट देने हैं — रिले। nostr.com का क्लाइंट इसे सीधे दिखाता है: उसके इंटरफ़ेस में फ़ीड के विकल्प «सब्सक्रिप्शन», «वैश्विक» और «अपनी» हैं, और नीचे — जुड़े हुए रिले की सूची।

इससे एक व्यावहारिक निष्कर्ष निकलता है, जिसे परियोजना स्वयं समझाती है: यदि Nostr धीमा या ख़ाली लगे, तो कारण रिले हो सकते हैं; कुछ रिले तेज़ और भरोसेमंद हैं, कुछ बंद हो जाते हैं और जवाब नहीं देते, और कुछ अच्छे रिले जोड़ देने से बहुत फ़र्क़ पड़ता है। Nostr में बढ़ना सबसे पहले उन रिले में प्रकाशित करना है, जहाँ वाक़ई पाठक हैं।

विज्ञापन कैबिनेट है ही नहीं: प्रोटोकॉल के पास न ऐसा कोई प्लेटफ़ॉर्म है, जो इंप्रेशन बेचे, न उन्हें गिनने की कोई व्यवस्था। अंतर्निर्मित आँकड़े भी नहीं हैं; उसके सबसे निकट है — COUNT अनुरोध, जिसे रिले जहाँ तक संभव हो और अनुमानित रूप से पूरा करता है।

स्पैम से लड़ने का असामान्य उपाय प्रोटोकॉल देता है: प्रूफ़-ऑफ़-वर्क वाला दस्तावेज़ रिले को यह अधिकार देता है कि वह नए इवेंट से तय गणनात्मक कठिनाई माँगे। दूसरा उपाय है पैसा: कुछ रिले सशुल्क हैं, और इससे स्पैम घटता है, क्योंकि रिले चलाने में पैसा लगता है और उपयोगकर्ताओं के पास शालीनता से पेश आने का कारण बनता है।

कमाई का रास्ता

प्लेटफ़ॉर्म है ही नहीं — यानी प्लेटफ़ॉर्म से भुगतान भी नहीं। पर लोगों के बीच सीधे भुगतान ज़रूर हैं, और उनका वर्णन ख़ुद प्रोटोकॉल में है।

इस व्यवस्था का नाम है «ज़ैप» (zap) — Lightning नेटवर्क के ज़रिये भुगतान। प्रोटोकॉल का दस्तावेज़ दो प्रकार के इवेंट लाता है: 9734 — ज़ैप का अनुरोध, यानी भुगतान करने वाले का प्राप्तकर्ता के वॉलेट से इनवॉइस माँगना, और 9735 — रसीद, प्राप्तकर्ता के वॉलेट की यह पुष्टि कि इनवॉइस चुका दिया गया। क्रम इस तरह है: क्लाइंट प्राप्तकर्ता की प्रोफ़ाइल से उसके भुगतान बिंदु का पता लेता है, जाँचता है कि वह Nostr का समर्थन करता है, वहाँ हस्ताक्षरित अनुरोध भेजता है और इनवॉइस पाता है; भुगतान के बाद वॉलेट रसीद प्रकाशित करता है। रसीद का अर्थ वहीं समझाया गया है: वह क्लाइंट को भुगतान सीधे फ़ीड में दिखाने देती है — मज़े के लिए या स्पैम से लड़ने के साधन के रूप में।

इस योजना में प्लेटफ़ॉर्म का कमीशन नहीं है — पैसा एक वॉलेट से दूसरे वॉलेट जाता है। पर प्लेटफ़ॉर्म की गारंटी भी नहीं है: भुगतान पहुँचाने की ज़िम्मेदारी Lightning नेटवर्क और आपके चुने हुए वॉलेट प्रदाता की है।

ज़ैप के अलावा प्रोटोकॉल की सूची में पैसे से जुड़ी और भी व्यवस्थाएँ हैं: संग्रह के लक्ष्य (zap goals), बैज, Cashu वॉलेट और «नटज़ैप», वॉलेट का दूरस्थ कनेक्शन और लोगों के बीच ऑर्डर के इवेंट। इनमें से हर एक को क्लाइंट अपनी इच्छा से लागू करता है।

टूल और स्वचालन

Nostr के पास «आधिकारिक API» उसी कारण नहीं है, जिस कारण उसका कोई मालिक नहीं है: प्रोटोकॉल ही इंटरफ़ेस है। कोई भी प्रोग्राम रिले तक websocket खोलकर सीधे उसके साथ काम कर सकता है (आधार दस्तावेज़)। डेवलपर कुंजियाँ, पहुँच के आवेदन और ऐप की मॉडरेशन मौजूद ही नहीं हैं।

सेवा बनाने से पहले सूची में दी गई चेतावनी पढ़ लेना उचित है: «यहाँ दिए गए NIP प्रोटोकॉल की कोई जाँच-सूची नहीं हैं। किसी भी प्रोग्राम को किसी NIP को लागू करने के लिए कुछ बाध्य नहीं करता। हर ऐप वही उपसमूह चुनता है, जो उसके काम के लिए ज़रूरी है»। इसका अर्थ है कि किसी सुविधा पर केवल इसलिए भरोसा नहीं किया जा सकता कि वह लिखी हुई है: यह जाँचना पड़ता है कि कोई विशेष रिले उसका समर्थन करता है या नहीं। जाँच का तरीका दिया गया है: रिले HTTP पर एक दस्तावेज़ देता है, जिसमें समर्थित NIP की सूची, प्रोग्राम का नाम, संस्करण, संपर्क और अपनी सेवा शर्तों का लिंक होता है। ऊपर बताए गए तीनों रिले एक जैसा समूह घोषित करते हैं: तीनों strfry प्रोग्राम पर चलते हैं और NIP 1, 2, 4, 9, 11, 28, 40, 45, 70 तथा 77 का समर्थन करते हैं।

तैयार साधनों में परियोजना हस्ताक्षर के लिए ब्राउज़र एक्सटेंशन और दूरस्थ हस्ताक्षरकर्ता बताती है, साथ ही अपना हस्ताक्षरकर्ता Pomegranate। क्लाइंट और रिले की सूचियाँ प्रोटोकॉल के बाहर रखी जाती हैं — nostrapps.com और Nostr.watch पर (क्लाइंट के बारे में पृष्ठ, रिले के बारे में पृष्ठ)।

सीमाएँ और नियम

• कोई साझा नियम नहीं हैं। ऐसा एक भी दस्तावेज़ नहीं है, जो नेटवर्क के सभी प्रतिभागियों के लिए किसी बात पर रोक लगाता हो। नियम रिले का मालिक तय करता है; प्रोटोकॉल केवल रिले की जानकारी में सेवा शर्तों के लिंक की व्यवस्था करता है।
• सीमाएँ रिले तय करता है और स्वयं घोषित करता है: संदेश का आकार, सामग्री की लंबाई, टैग की संख्या, सदस्यताओं की संख्या, चयन की अधिकतम सीमा।
• रिले माँग कर सकता है प्रमाणीकरण प्रोटोकॉल से प्रवेश या नए इवेंट के लिए प्रूफ़-ऑफ़-वर्क।
• हटाने की गारंटी नहीं है: दस्तावेज़ ठीक «हटाने के अनुरोध» का वर्णन करता है, और उसे पूरा करना है या नहीं, यह हर रिले स्वयं तय करता है।
• कुंजी का खो जाना अपरिवर्तनीय है। पहुँच वापस पाने का कोई रास्ता नहीं है।
• नेटवर्क का कोई क़ानूनी ढाँचा नहीं है। ज़िम्मेदारी रिले के मालिक और लेखक की होती है; प्रोटोकॉल के पास ऐसी कोई क़ानूनी इकाई नहीं है, जिससे अनुबंध किया जा सके। NIP की सूची स्वयं रिपॉज़िटरी में बिना किसी घोषित लाइसेंस के प्रकाशित होती है।

यह किसके लिए उपयुक्त है

उन परियोजनाओं के लिए उपयुक्त है, जिनके लिए प्लेटफ़ॉर्म के मालिक से स्वतंत्रता मायने रखती है: पहचान कंपनी की नहीं, कुंजी की होती है, खाते को केंद्रीय रूप से ब्लॉक नहीं किया जा सकता, और रिले से असंतोष होने पर रिले बदल देना ही काफ़ी है। डेवलपरों के लिए उपयुक्त है: नेटवर्क से जुड़ने के लिए न ऐप की कुंजी चाहिए, न किसी की मंज़ूरी।

बिटकॉइन और Lightning से जुड़ी परियोजनाओं के लिए उपयुक्त है: भुगतान ज़ैप के रूप में प्रोटोकॉल में अंतर्निहित हैं, और यही उसकी वित्तीय व्यवस्था का सबसे विकसित हिस्सा है।

उपयुक्त नहीं है, यदि आपको अनुमान लगाने योग्य पहुँच और रिपोर्टिंग चाहिए: यहाँ मापने को कुछ है ही नहीं — न प्लेटफ़ॉर्म, न आँकड़े, न विज्ञापन कैबिनेट। बड़े पैमाने पर संदेश भेजने और «प्रचार» के लिए उपयुक्त नहीं है: रिले शुल्क, प्रवेश या प्रूफ़-ऑफ़-वर्क माँग सकता है और बिना कारण बताए आपको काट सकता है। और यदि संगठन को सेवा प्रदाता के साथ अनुबंध चाहिए, तो भी उपयुक्त नहीं है: प्रोटोकॉल के पास ऐसा कोई पक्ष नहीं है।

डेटाबेस के जाँचे गए तथ्य

संक्षिप्त जाँचा हुआ डेटा, जिस पर यह विस्तृत विश्लेषण टिका है।

यह प्लेटफ़ॉर्म क्या है

प्लेटफ़ॉर्म स्वयं का वर्णन इस तरह करता है: «Nostr is a free and open-source protocol for social media and other things - controlled by users, not platforms.»

स्व-विवरण: यह प्लेटफ़ॉर्म का अपने बारे में कथन है, स्वतंत्र मूल्यांकन नहीं

स्रोत, जाँचा गया 2026-07-28

Nostr (Notes and Other Stuff Transmitted by Relays) को एक स्वतंत्र और खुले नेटवर्क के रूप में वर्णित किया गया है, जिसका न कोई मालिक है और न कोई उस पर नियंत्रण रखता है; रिले संदेश संग्रहीत और वितरित करते हैं, क्लाइंट उन्हें पढ़ने और लिखने देते हैं

यह एक प्रोटोकॉल है, मंच नहीं: इसका न कोई मालिक है, न विज्ञापन कैबिनेट और न भुगतान कार्यक्रम

स्रोत, जाँचा गया 2026-07-28

एकमात्र वस्तु-प्रकार घटना (event) है; हस्ताक्षर और कुंजियाँ secp256k1 वक्र पर श्नोर योजना का उपयोग करती हैं; रिले websocket-बिंदु प्रस्तुत करता है, क्लाइंट प्रकाशन के लिए EVENT, सदस्यता के लिए REQ और उसे बंद करने के लिए CLOSE भेजता है

प्रोटोकॉल का आधार दस्तावेज़ NIP-01

स्रोत, जाँचा गया 2026-07-28

कहाँ से शुरू करें

nostr में प्रवेश की सीमा के नियमों का कोई एक स्वामी नहीं है: «Nostr (Notes and Other Stuff Transmitted by Relays) is a free and open network that nobody owns or controls»; प्रोटोकॉल के प्रस्तावों का संग्रह अपने बारे में भी यही कहता है: «NIPs listed here are not a protocol checklist. Nothing forces any software to implement any NIP»

उद्धरण शब्दशः हैं, स्रोत की भाषा अंग्रेज़ी। दूसरा NIP संग्रह के README से: https://raw.githubusercontent.com/nostr-protocol/nips/master/README.md। पाठक के लिए व्यावहारिक निष्कर्ष: पूरे नेटवर्क पर अनिवार्य प्रवेश-शर्तें हैं ही नहीं; शर्तें हर अलग रिले और हर ऐप तय करता है, और वे भिन्न हैं

स्रोत, जाँचा गया 2026-08-07

रिले लिखने पर रोक लगा सकता है, हस्ताक्षर से प्रवेश या कार्य का प्रमाण माँग सकता है: NIP-11 की पाबंदियों की सूची में «auth_required», «restricted_writes», «min_pow_difficulty», «payment_required» नामित हैं; «Your client should expect that requests exceed these practical limitations are rejected or fail immediately»

उद्धरण शब्दशः हैं, स्रोत की भाषा अंग्रेज़ी, स्रोत की वर्तनी सुरक्षित रखी गई है। प्रोटोकॉल के स्तर पर न आवेदन है, न निमंत्रण, न मॉडरेशन; ऊपर गिनाया गया सब कुछ अलग रिले के गुण हैं, और उन्हें रिले से उसकी जानकारी का दस्तावेज़ माँगकर जाना जा सकता है

स्रोत, जाँचा गया 2026-08-07

अकाउंट और एक्सेस

खाता एक कुंजी-युग्म है, मंच-स्वामी के यहाँ की प्रविष्टि नहीं: «Every account has Nostr keys. Your public key is like your username and can be shared with anyone. Your private key is like your password and must be kept safe. These keys give you ownership of your identity, rather than a company owning it for you»

उद्धरण शब्दशः है, स्रोत की भाषा अंग्रेज़ी। कुंजियाँ पाने के लिए न पंजीकरण चाहिए, न पहचान-पुष्टि, न स्वीकृति: कुंजी-युग्म उपकरण पर ही बनता है। नाम@डोमेन प्रकार का ऐच्छिक जाँचने योग्य नाम अलग NIP-05 में वर्णित है

स्रोत, जाँचा गया 2026-08-07

खाते में कुंजियों का एक जोड़ा होता है: सार्वजनिक कुंजी उपयोगकर्ता नाम की तरह काम करती है, निजी — पासवर्ड की तरह; पहचान कुंजी की होती है, अनुप्रयोग की नहीं, इसलिए प्रोफ़ाइल और अनुयायी बनाए रखते हुए क्लाइंट बदला जा सकता है

पंजीकरण, डाक पते की पुष्टि और आवेदन के मॉडरेशन जैसा कुछ नहीं है

स्रोत, जाँचा गया 2026-07-28

निजी कुंजी खो जाने पर बैकअप प्रति के बिना पहुँच बहाल नहीं होती: «забыли пароль» बटन मौजूद ही नहीं है

परियोजना सलाह देती है कि निजी कुंजी हर अनुप्रयोग में न डालें, बल्कि हस्ताक्षरकर्ता-विस्तार या दूरस्थ हस्ताक्षरकर्ता का उपयोग करें

स्रोत, जाँचा गया 2026-07-28

नाम@डोमेन रूप का सत्यापन-योग्य नाम: क्लाइंट https://डोमेन/.well-known/nostr.json?name=नाम का अनुरोध करता है और प्राप्त सार्वजनिक कुंजी को प्रविष्टि के लेखक की कुंजी से मिलाता है

कंपनी के लिए यह खाते की पुष्टि डोमेन पर नियंत्रण से करने का तरीका है, मॉडरेटर के निर्णय से नहीं

स्रोत, जाँचा गया 2026-07-28

क्या प्रकाशित किया जा सकता है

NIP की सूची अन्य बातों के साथ वर्णन करती है: छोटे नोट और सूत्र, लंबी सामग्री, छवियाँ और वीडियो, सीधे प्रसारण और स्पेस, सर्वेक्षण, कैलेंडर घटनाएँ, विकी, टोरेंट, सूचियाँ, बुकमार्क और उद्धरण

NIP की सूची दायित्व नहीं है: किसी भी प्रोग्राम को कोई NIP लागू करने के लिए कुछ भी बाध्य नहीं करता

स्रोत, जाँचा गया 2026-07-28

यहाँ भुगतान कैसे होता है

किसे स्वीकार किया जाता है। भुगतानों के लिए सदस्यों, दृश्यों या प्रकाशनों की संख्या की कोई सीमा नहीं है: ज़ैप Lightning नेटवर्क से सीधे एक व्यक्ति से दूसरे तक जाते हैं, और शर्त केवल यह है कि पाने वाले के पास lnurl पते वाला बटुआ हो — «Client calculates a recipient's lnurl pay request url from the zap tag on the event being zapped, or by decoding their lud16 field on their profile»

उद्धरण शब्दशः है, स्रोत की भाषा अंग्रेज़ी। सीमा शून्य है: NIP-57 न सदस्यों की संख्या माँगता है, न देखने के घंटे, न खाते की आयु। अधिकतम राशियाँ पाने वाले का बटुआ «minSendable» और «maxSendable» क्षेत्रों से तय करता है, नेटवर्क नहीं

स्रोत, जाँचा गया 2026-08-07

नेटवर्क का कमीशन न है, न किसी का हो सकता है: पैसा प्रोटोकॉल के बाहर, पाने वाले के बटुए से जाता है, और nostr हिसाब में भाग नहीं लेता — NIP-57 केवल दो प्रकार की घटनाएँ वर्णित करता है, अनुरोध की प्रविष्टि और रसीद की प्रविष्टि: «9734 is a zap request… 9735 is a zap receipt, representing the confirmation by the recipient's lightning wallet that the invoice issued in response to a zap request has been paid»

उद्धरण शब्दशः है, स्रोत की भाषा अंग्रेज़ी। अपना कमीशन बटुआ या Lightning नेटवर्क की गाँठ ले सकती है — यह पहले से ही nostr नहीं है, और उसका आकार NIP-57 में तय नहीं। नेटवर्क के पास न कमीशन है, न हिस्सा, न भुगतान सीमा, क्योंकि ऐसा कोई बिचौलिया नहीं जो पैसा रखे

स्रोत, जाँचा गया 2026-08-07

लोगों के बीच भुगतान प्रोटोकॉल में Lightning नेटवर्क के ज़रिये «запы» के रूप में वर्णित हैं: घटना 9734 — ज़ैप का अनुरोध, घटना 9735 — प्राप्तकर्ता के बटुए की चालान-भुगतान की रसीद

योजना में मंच का कमीशन नहीं है: पैसा बटुए से बटुए तक जाता है; वितरण की ज़िम्मेदारी Lightning नेटवर्क और बटुआ प्रदाता की है

स्रोत, जाँचा गया 2026-07-28

NIP की सूची में संग्रह-लक्ष्य (zap goals), बैज, Cashu बटुए और नैट्ज़ैप, बटुए का दूरस्थ संयोजन और लोगों के बीच आदेशों की घटनाएँ भी शामिल हैं

प्रत्येक तंत्र क्लाइंट अपनी इच्छा से लागू करता है

स्रोत, जाँचा गया 2026-07-28

क़ीमत

प्रोटोकॉल पैसे नहीं लेता, पर अलग रिले ले सकता है: NIP-11 में शुल्क के लिए क्षेत्र हैं — «Relays that require payments may want to expose their fee schedules»: «fees»: «admission» (प्रवेश का शुल्क), «subscription» (सदस्यता, «period» क्षेत्र के साथ), «publication» (प्रकाशन का शुल्क, घटनाओं के प्रकार बताते हुए); रिले की पाबंदियों की सूची में «payment_required» चिह्न है

उद्धरण शब्दशः हैं, स्रोत की भाषा अंग्रेज़ी। अंक हर रिले स्वयं तय करता है, इसलिए नेटवर्क में प्रवेश की एक कीमत नहीं है। स्वयं NIP-11 में रिले nostr.wine के उत्तर के नमूने के रूप में दिया गया उदाहरण: «fees»: «admission»: ({«amount»: 18888000, «unit»: «msats»}) — यह दस्तावेज़ के उदाहरण में रिले का कथन है, हमारी गणना नहीं और मौजूदा कीमत का वादा नहीं

स्रोत, जाँचा गया 2026-08-07

पाबंदियाँ और सीमाएँ

रिले अपनी सीमाएँ सूचना दस्तावेज़ में घोषित करता है: max_message_length (आने वाले JSON का आकार), max_content_length (सामग्री फ़ील्ड में वर्ण), max_event_tags, max_subscriptions, max_limit; प्रमाणीकरण और कार्य-प्रमाण की माँगें संभव हैं

दस्तावेज़ NIP-11; प्रोटोकॉल की अपनी लंबाई और आकार की सीमाएँ नहीं हैं

स्रोत, जाँचा गया 2026-07-28

रिले relay.damus.io जाँच की तिथि पर संदेश की सीमा 1 000 000 बाइट, 200 एक साथ सदस्यताएँ और 500 घटनाओं की चयन-सीमा घोषित करता है; प्रोग्राम strfry

यह संख्या इसी रिले की है, दूसरे पर वह अलग है

स्रोत, जाँचा गया 2026-07-28

रिले nos.lol संदेश की सीमा 131 072 बाइट, 20 सदस्यताएँ और 500 घटनाओं की चयन-सीमा घोषित करता है

रिले के सूचना दस्तावेज़ के अनुरोध से मापा गया

स्रोत, जाँचा गया 2026-07-28

रिले relay.nostr.com संदेश की सीमा 131 072 बाइट, 200 सदस्यताएँ और 500 घटनाओं की चयन-सीमा घोषित करता है; घोषित NIP — 1, 2, 4, 9, 11, 28, 40, 45, 70, 77

वही NIP समूह damus.io और nos.lol भी घोषित करते हैं

स्रोत, जाँचा गया 2026-07-28

पाबंदियाँ

एक जैसे नियम नहीं हैं: क्या स्वीकार और संग्रहीत करना है, यह रिले का मालिक तय करता है; प्रोटोकॉल केवल रिले की सूचना में सेवा शर्तों के लिंक का प्रावधान करता है

विलोपन को «запрос на удаление» के रूप में वर्णित किया गया है, निष्पादन की गारंटी नहीं

स्रोत, जाँचा गया 2026-07-28

स्पैम के विरुद्ध साधन: रिले निर्धारित कठिनाई का कार्य-प्रमाण या प्रमाणीकरण माँग सकता है; कुछ रिले सशुल्क हैं, जिससे, परियोजना की व्याख्या के अनुसार, स्पैम कम होता है

Nostr.watch को परियोजना रिले की निर्देशिका के रूप में और nostrapps.com को क्लाइंट की निर्देशिका के रूप में सुझाती है

स्रोत, जाँचा गया 2026-07-28

nostr.com की रोबोट फ़ाइल सभी एजेंटों को साइट का क्रॉल करने की अनुमति देती है

अलग से जाँचा गया

स्रोत, जाँचा गया 2026-07-28

क़ानूनी पहलू

NIP की सूची का भंडार बिना निर्दिष्ट लाइसेंस के प्रकाशित है

प्रोटोकॉल का कोई क़ानूनी व्यक्ति नहीं है जिससे अनुबंध किया जा सके

स्रोत, जाँचा गया 2026-07-28

API एक्सेस

nostr.com पर क्लाइंट डिफ़ॉल्ट रूप से छह रिले से जुड़ता है: relay.nostr.com, relay.damus.io, nos.lol, nostr.bitcoiner.social, nostr.mom, relay.snort.social

सूची सीधे इंटरफ़ेस में दिखती है

स्रोत, जाँचा गया 2026-07-28

अलग «официального API» नहीं है: इंटरफ़ेस स्वयं प्रोटोकॉल है, कोई भी प्रोग्राम रिले से websocket खोल सकता है; डेवलपर कुंजियाँ और अनुप्रयोगों का मॉडरेशन मौजूद नहीं

विशिष्ट सुविधाओं का समर्थन रिले के सूचना दस्तावेज़ से जाँचना चाहिए

स्रोत, जाँचा गया 2026-07-28

भाषाएँ

मुख्य पेज की इंटरफ़ेस भाषा: en

भाषा मार्कअप के एट्रिब्यूट से ली गई है, संस्करण — hreflang से

स्रोत, जाँचा गया 2026-07-28

कैटलॉग अनुभाग: सभी समान यह भी देखें: कैटलॉग अनुक्रमणिका · शेड्यूलर की तुलना · स्थिति के अनुसार चुनाव · प्लेटफ़ॉर्म की पाबंदियाँ