Nostr

अन्ना को Nostr पर ऐसे लेखक मिलते हैं जिन्हें वह फ़ॉलो करना चाहती है। बाद में उसे अपना ऐप पसंद नहीं आता। अगर दूसरे ऐप में वही निजी कुंजी या उससे जुड़ा हस्ताक्षर उपकरण सुरक्षित तरीके से इस्तेमाल किया जाए, तो वह अपनी पहचान बनाए रख सकती है। सार्वजनिक कुंजी से दूसरे लोग उसे पहचानते और हस्ताक्षर जाँचते हैं; निजी कुंजी रखने वाला उसके नाम से हस्ताक्षर कर सकता है। इसीलिए npub और nsec में इतना बड़ा अंतर है। NIP-19 के अनुसार ये सार्वजनिक और निजी कुंजी के Bech32 एन्कोडिंग वाले रूप हैं। NIP क्रमांकित दस्तावेज़ हैं जो Nostr के नियमों और विस्तारों का वर्णन करते हैं। एन्कोडिंग, एन्क्रिप्शन नहीं है: nsec कोई साधारण प्रोफ़ाइल लिंक नहीं जिसे किसी को भी भेज दें। पहचान बने रहने का यह अर्थ भी नहीं कि नया ऐप हर पुरानी पोस्ट खोज लेगा या सभी सेटिंग अपने आप ले आएगा। [2] [7]

ऐप, जिसे क्लाइंट कहते हैं, पोस्ट पर हस्ताक्षर करके उसे चुने हुए relay सर्वरों को भेजता है। relay संदेश स्वीकार करता है और अपने नियमों के अनुसार उन्हें सहेजता या आगे भेजता है। पेत्र का ऐप इन सर्वरों से जुड़कर उसकी रुचि की पोस्ट माँगता है। न कोई एक केंद्रीय सर्वर है, न हर सर्वर के लिए सब कुछ कॉपी करने की बाध्यता। तकनीकी रूप से बातचीत WebSocket पर होती है, यानी ऐसा कनेक्शन जो खुला रहता है: EVENT संदेश ले जाता है, REQ सदस्यता शुरू करता है और OK स्वीकृति या अस्वीकृति बताता है। सकारात्मक OK भी पेत्र तक पहुँचने या हमेशा के लिए सहेजे जाने की पुष्टि नहीं करता। EOSE उस अनुरोध के सहेजे हुए परिणामों का अंत बताता है; उसके बाद सदस्यता से नए संदेश आते रह सकते हैं। [1] [7]

पेत्र को संदेश मिलने पर ऐप जाँचता है कि हस्ताक्षर दी गई सार्वजनिक कुंजी से मेल खाता है और हस्ताक्षरित डेटा बदला नहीं गया। इससे संदेश का सच होना या लेखक की वास्तविक पहचान साबित नहीं होती। संदेश बनने का समय भी लेखक भरता है, इसलिए यह स्वतंत्र समय-प्रमाण नहीं है। तकनीकी जानकारी चाहने वालों के लिए: event नाम के रिकॉर्ड में pubkey, created_at, kind, tags और content होते हैं, यानी कुंजी, समय, प्रकार, टैग और सामग्री। इन डेटा को बिल्कुल तय प्रारूप में लिखकर SHA-256 से id नाम का एक छोटा जाँच-मान बनाया जाता है। इससे हस्ताक्षरित डेटा में बदलाव का पता लगाया जा सकता है। sig फ़ील्ड में BIP340 के अनुसार secp256k1 कर्व पर बनी Schnorr Signature होती है। इसका अर्थ है “संबंधित कुंजी के धारक ने इस डेटा पर हस्ताक्षर किए”, न कि “इस दावे पर भरोसा किया जा सकता है”। [1]

लंबी सार्वजनिक कुंजी याद रखना कठिन है। NIP-05 उसे ईमेल पते जैसे पहचानकर्ता से जोड़ने देता है। ऐप संबंधित डोमेन से पूछता है कि नाम किस कुंजी से जुड़ा है, फिर जवाब को प्रोफ़ाइल की कुंजी से मिलाता है। वह डोमेन और कुंजी का यही संबंध जाँचता है, किसी का असली नाम, प्रतिष्ठा या भरोसेमंद होना अपने आप नहीं। डोमेन का संचालक बाद में यह संबंध बदल सकता है। अन्ना अगर पहले से किसी को फ़ॉलो करती है, तो मूल सार्वजनिक कुंजी ही आधार रहनी चाहिए; उसी नाम को नई कुंजी देने से फ़ॉलो किया जाने वाला व्यक्ति चुपचाप नहीं बदलना चाहिए। छद्मनामिता का मतलब असली नाम के बजाय स्थायी पहचानकर्ता इस्तेमाल करना है, गुमनामी की गारंटी नहीं। [3]

पेत्र को हर संदेश डाउनलोड नहीं करना पड़ता। वह फ़िल्टर भेज सकता है, जैसे कुछ लेखकों की खास प्रकार की पोस्ट। एक फ़िल्टर की अलग शर्तें AND से जुड़ती हैं: सभी पूरी होनी चाहिए। किसी एक शर्त के कई स्वीकार्य मान OR वाले विकल्प हैं; एक REQ में कई फ़िल्टर भी इसी तरह जुड़ते हैं। उनमें से किसी एक फ़िल्टर से मेल खाना पर्याप्त है। limit शुरुआत में मिलने वाले सहेजे हुए परिणामों की संख्या सीमित करता है, सदस्यता में आगे आने वाले संदेशों को अपने आप नहीं। NIP-01 इवेंट और फ़िल्टर में कुंजियों का हेक्साडेसिमल रूप इस्तेमाल करता है, उपयोगकर्ता वाला npub रूप नहीं। खोज खाली आने का कारण फ़िल्टर, चुना गया सर्वर या उसका इतिहास हो सकता है; यह प्रमाण नहीं कि पोस्ट कहीं मौजूद ही नहीं है। [1]

अन्ना प्रोफ़ाइल का परिचय बदलती है और चाहती है कि दूसरे नया परिचय देखें। इसीलिए Nostr में नियम हैं कि relay को किस तरह का डेटा सहेजना चाहिए। बदले जा सकने वाले इवेंट में वह एक ही pubkey और kind की जोड़ी का सबसे नया रिकॉर्ड चुनता है। पता देकर पहचाने जा सकने वाले इवेंट में d टैग का मान भी जुड़ता है, जो एक लेखक के अलग दस्तावेज़ों को पहचानता है। यदि बदले जा सकने वाले रिकॉर्ड का समय बराबर हो, तो शब्दकोशीय क्रम में छोटा id रखने की सलाह है, यानी लिखित रूप को क्रम में रखने पर जो पहले आए। अस्थायी, यानी ephemeral इवेंट को तो सहेजने की अपेक्षा भी नहीं है। ये प्रचलित नियम हैं और relay का व्यवहार अलग हो सकता है। इसलिए Nostr ऐसा बहीखाता नहीं जिसमें पूरा नेटवर्क एक ही अटल इतिहास पर सहमत हो। [1]

अन्ना को पता चलता है कि उसने ऐसी बात प्रकाशित कर दी जिसे निजी रखना चाहती थी। NIP-09 से वह हस्ताक्षरित हटाने का अनुरोध भेज सकती है। उसे मानने से पहले क्लाइंट को जाँचना चाहिए कि अनुरोध और मूल पोस्ट एक ही सार्वजनिक कुंजी के हैं; कोई दूसरा व्यक्ति सिर्फ़ पोस्ट का उल्लेख करके उसे मिटा नहीं सकता। सहयोग करने वाले सर्वर और ऐप सामग्री हटा सकते हैं या दिखाना बंद कर सकते हैं। मगर अनुरोध हर कॉपी, स्क्रीनशॉट या स्वतंत्र संग्रह नहीं मिटा सकता। एक ऐप में पोस्ट छिप जाने से यह भी नहीं पता चलता कि दूसरा सर्वर उसे अब भी उपलब्ध करा रहा है या नहीं। इसलिए हटाने के बटन से अधिक महत्त्वपूर्ण है कि आप प्रकाशित क्या करते हैं। [4]

सार्वजनिक पोस्ट जिसे मिल जाए, वह पढ़ सकता है; केवल हस्ताक्षर सामग्री नहीं छिपाता। निजी संदेशों के लिए अतिरिक्त नियम हैं। NIP-44 सामग्री का एन्क्रिप्शन बताता है, जबकि NIP-17 संदेश को अतिरिक्त सुरक्षा परतों में लपेटने और पहुँचाने का तरीका बताता है। इससे गुमनामी अपने आप नहीं मिलती: नेटवर्क पते, समय और ऐप का व्यवहार अभी भी जानकारी दे सकते हैं। इस एन्क्रिप्शन में forward secrecy भी नहीं है, यानी दीर्घकालिक कुंजी बाद में लीक होने पर पुरानी बातचीत की सुरक्षा। जिसे ज़रूरी निजी कुंजी और पहले रिकॉर्ड किए गए एन्क्रिप्टेड संदेश मिल जाएँ, वह पुरानी बातचीत भी पढ़ सकता है। इसलिए जाँचें कि ऐप वास्तव में किन विस्तारों का समर्थन करता है; केवल “Nostr” नाम उसकी गोपनीयता का स्तर नहीं बताता। [5] [6]