Nostr

इवेंट में pubkey, created_at, kind, tags, content, id और sig होते हैं। NIP-01 सटीक निर्धारित क्रमांकन से SHA-256 द्वारा id निकालता है और secp256k1 पर BIP340 हस्ताक्षर उपयोग करता है। क्लाइंट अखंडता और कुंजी से प्राधिकरण जाँचता है। created_at लेखक देता है; यह स्वतंत्र समय-मुहर या सामग्री की सच्चाई का प्रमाण नहीं है। [Nostr — NIP-01: Basic protocol] [fiatjaf — Original Nostr description]

क्लाइंट WebSocket पर EVENT प्रकाशित करता और REQ से सदस्यता लेता है। OK उसी रिले की स्वीकृति या अस्वीकृति बताता है। EOSE सहेजे गए इवेंट की सूची समाप्त करता है, नए इवेंट की सदस्यता जरूरी नहीं। इनमें कोई संदेश प्राप्तकर्ता तक पहुँच, पूरे नेटवर्क में प्रतिलिपि या स्थायी संग्रह की पुष्टि नहीं करता। [Nostr — NIP-01: Basic protocol]

एक फ़िल्टर में सभी शर्तें पूरी होनी चाहिए: लेखक और प्रकार का अर्थ AND है। एक REQ के कई फ़िल्टर OR से जुड़ते हैं; एक का मेल पर्याप्त है। limit शुरुआती सूची सीमित करता है, भविष्य के इवेंट की संख्या नहीं। परिणाम न मिलना रिले का सीमित इतिहास हो सकता है, इवेंट का न होना नहीं। [Nostr — NIP-01: Basic protocol]

बदले जा सकने वाले इवेंट pubkey और kind से, पते योग्य इवेंट इनके साथ d टैग से भी तुलना किए जाते हैं। नया संस्करण पुराने को बदल सकता है; समय समान हो तो शब्दकोश क्रम में छोटा id चुना जाता है। क्षणिक इवेंट का संग्रह अपेक्षित नहीं है। ये रिले के नियम हैं, अपरिवर्तनीय वैश्विक संग्रह नहीं; कार्यान्वयन अलग हो सकते हैं। [Nostr — NIP-01: Basic protocol]

NIP-19 उपयोगकर्ता को दिखाने के लिए Bech32 उपयोग करता है: npub सार्वजनिक कुंजी, nsec निजी कुंजी है। एन्कोडिंग एन्क्रिप्शन नहीं है। इसलिए nsec साझा करना केवल प्रोफ़ाइल लिंक नहीं, गुप्त कुंजी देना है। NIP-01 इवेंट और फ़िल्टर सार्वजनिक कुंजी का हेक्साडेसिमल रूप उपयोग करते हैं, npub प्रदर्शन नहीं। [Nostr — NIP-19: Encoded entities]

NIP-05 डोमेन के उत्तर के अनुसार ईमेल-जैसे नाम को सार्वजनिक कुंजी से जोड़ता है। यह उस संबंध को सिद्ध करता है, वास्तविक पहचान या ईमानदारी को नहीं। क्लाइंट को मूल कुंजी का अनुसरण करना चाहिए: डोमेन नाम को नई कुंजी से जोड़ दे तो पहले से फ़ॉलो की गई प्रोफ़ाइल को अपने-आप उससे नहीं बदलना चाहिए। [Nostr — NIP-05: Internet identifiers]

NIP-09 लेखक के अपने इवेंट हटाने के अनुरोध को परिभाषित करता है। छिपाने से पहले क्लाइंट को मूल इवेंट और अनुरोध की सार्वजनिक कुंजी का मिलान करना चाहिए। रिले और क्लाइंट अनुरोध पर काम कर सकते हैं, पर प्रोटोकॉल हर डाउनलोड या सहेजी हुई प्रति नहीं मिटा सकता। एक इंटरफ़ेस में हटना वैश्विक मिटने का प्रमाण नहीं है। [Nostr — NIP-09: Deletion requests]

NIP-44 एन्क्रिप्टेड payload परिभाषित करता है, पूरा निजी संदेश तंत्र नहीं; NIP-17 आवरण और पहुँचाने के नियम जोड़ता है। बाद में कुंजी लीक होने पर अकेला NIP-44 forward secrecy नहीं देता। एन्क्रिप्शन के बावजूद नेटवर्क पते, समय और क्लाइंट का व्यवहार महत्वपूर्ण रहते हैं। हर NIP का समर्थन ऐप के अनुसार अलग जाँचना चाहिए। [Nostr — NIP-44: Encrypted payloads] [Nostr — NIP-17: Private messages]