NIP-17: प्राइवेट डायरेक्ट मैसेज - एक संपूर्ण गाइड
NIP-17 के बारे में जानें, NIP-04 का सुरक्षित विकल्प, और Nostr में अपनी प्राइवेट मैसेजिंग कैसे माइग्रेट करें
NIP-17 Nostr में प्राइवेट मैसेज काम करने के तरीके में एक महत्वपूर्ण सुरक्षा अपग्रेड का प्रतिनिधित्व करता है। यह गाइड समझाता है कि आपको इस प्रोटोकॉल सुधार की परवाह क्यों करनी चाहिए, पुराने NIP-04 स्टैंडर्ड से कैसे माइग्रेट करें, और अपने संचार को सुरक्षित करने के व्यावहारिक कदम।
NIP-17 क्या है?
NIP-17 एक Nostr प्रोटोकॉल स्पेसिफिकेशन है जो “seal + gift wrap” कहलाती डुअल-लेयर एन्क्रिप्शन सिस्टम का उपयोग करके प्राइवेट डायरेक्ट मैसेज को परिभाषित करता है। इसे पिछले NIP-04 एन्क्रिप्शन विधि की मौलिक सुरक्षा कमियों को दूर करने के लिए बनाया गया था।
NIP-04 के विपरीत, जो सिंगल-लेयर AES-256-CBC एन्क्रिप्शन उपयोग करता था, NIP-17 उपयोग करता है:
- Seal (kind 13) इनर लेयर है। यह आपकी असली key से साइन होती है, ताकि जिसे आप लिख रहे हैं वह पहचान सके कि मैसेज वाकई आपका है
- Gift wrap (kind 1059) बाहरी लिफाफा है, जो एक throwaway key से साइन होता है और seal को छुपा देता है, ताकि रिले जो इवेंट स्टोर करते हैं उस पर आपकी असली पहचान कभी न दिखे
इस लेयरिंग का मतलब है:
- मैसेज कंटेंट प्राइवेट रहता है
- रिले यह नहीं देख सकते कि मैसेज किसने भेजा: गिफ्ट रैप पर साइन एक रैंडम वन-टाइम key की होती है, आपकी key की नहीं
- टाइमस्टैम्प रैंडमाइज़ किए जाते हैं, जिससे मैसेज की टाइमिंग को आपस में जोड़ना मुश्किल हो जाता है
रिले फिर भी देख सकते हैं कि आप किसे मैसेज कर रहे हैं
गिफ्ट रैप में रिसीवर की public key एक प्लेनटेक्स्ट p टैग में मौजूद रहती है। ऐसा
होना ज़रूरी है। वरना रिसीवर के रिले को पता ही नहीं चलेगा कि इसे किसे डिलीवर करना
है। NIP-17 सेंडर को छुपाता है, रिसीवर को नहीं।
किसी रिले की स्ट्रीम पढ़ने वाला कोई भी व्यक्ति देख सकता है कि किसी ने आपको मैसेज भेजा और कब भेजा। किसने भेजा और क्या भेजा, यह उसे नहीं दिखता। अगर आपके थ्रेट मॉडल में यह छुपाना भी ज़रूरी है कि आपको कुछ मिला ही है, तो अकेला NIP-17 काफी नहीं है।
NIP-17 क्यों महत्वपूर्ण है: NIP-04 सुरक्षा समस्या
NIP-04 Nostr का मूल डायरेक्ट मैसेज प्रोटोकॉल था, लेकिन इसमें कई महत्वपूर्ण सुरक्षा समस्याएं हैं जो इसे वास्तव में प्राइवेट संचार के लिए अनुपयुक्त बनाती हैं।
तुलना: NIP-04 vs NIP-17
| फीचर | NIP-04 | NIP-17 |
|---|---|---|
| एन्क्रिप्शन | सिंगल-लेयर AES-256-CBC | डुअल-लेयर (seal + gift wrap) |
| सेंडर मेटाडेटा | रिले को दिखाई देता | छिपा हुआ, वन-टाइम key से साइन |
| रिसीवर मेटाडेटा | रिले को दिखाई देता | अब भी दिखाई देता, प्लेनटेक्स्ट p टैग |
| मैसेज कंटेंट | एन्क्रिप्टेड | एन्क्रिप्टेड |
| टाइमिंग मेटाडेटा | असली टाइमस्टैम्प दिखते | दो दिन तक पीछे रैंडमाइज़्ड |
| फॉरवर्ड सीक्रेसी | नहीं | नहीं (NIP-44 इसे प्रदान नहीं करता) |
| सुरक्षा स्टेटस | डेप्रिकेटेड | रिकमेंडेड |
| इंटरऑपरेबिलिटी | व्यापक रूप से समर्थित | बढ़ता समर्थन |
NIP-04 की मुख्य समस्या
NIP-04 मैसेज कौन किससे बात कर रहा है यह हर उस रिले के सामने खोल देते हैं जो उन्हें स्टोर करता है। (Nostr में कोई ब्लॉकचेन नहीं है। इवेंट्स बस रिले पर पड़े रहते हैं, और कोई भी किसी रिले से पढ़ सकता है।) जबकि मैसेज बॉडी एन्क्रिप्टेड है, लिफाफा शामिल करता है:
# NIP-04 इवेंट स्ट्रक्चर (सरलीकृत)
{
"pubkey": "<sender_public_key>", # कोई भी देख सकता है किसने भेजा
"tags": [["p", "<recipient_pubkey>"]], # कोई भी देख सकता है किसने प्राप्त किया
"content": "<encrypted_content>" # केवल कंटेंट छिपा हुआ है
}
इसका मतलब है कि रिले ऑपरेटर, नेटवर्क ऑब्जर्वर, और डेटा स्क्रैपर:
- सोशल ग्राफ़ बना सकते हैं जो दिखाता है कौन किससे संचार कर रहा है
- संचार पैटर्न और फ्रीक्वेंसी ट्रैक कर सकते हैं
- मैसेज टाइमिंग से रिश्ते का अनुमान लगा सकते हैं
NIP-17 इस खाई का ज़्यादातर हिस्सा इस तरह पाटता है कि पूरे मैसेज को एक बाहरी लिफाफे में रैप कर देता है, जो एक throwaway key से साइन होता है, इसलिए रिले यह नहीं बता सकता कि भेजा किसने। एक चीज़ जान-बूझकर खुली रहती है: रिसीवर की public key लिफाफे पर एक प्लेन टैग में सवार रहती है, क्योंकि रिले को पता होना चाहिए कि मैसेज किसे सौंपना है। यानी NIP-17 सेंडर को छुपाता है, रिसीवर को नहीं।
NIP-17 कैसे काम करता है: Seal + Gift Wrap
तकनीकी इम्प्लीमेंटेशन को समझना सुरक्षा सुधारों की सराहना करने में मदद करता है।
गिफ्ट रैप लेयर (आउटर)
गिफ्ट रैप वही लिफाफा है जो रिले असल में स्टोर करता है। आपका क्लाइंट सिर्फ इसी एक मैसेज के लिए बिल्कुल नई key बनाता है, लिफाफे को उससे साइन करता है और फिर वह key फेंक देता है। अंदर का सामान इस तरह एन्क्रिप्टेड होता है कि उसे सिर्फ रिसीवर खोल सके। इस लेयर पर होता है:
- एक रैंडम वन-टाइम public key, जिसका आपसे जोड़ने वाला कुछ भी नहीं
- रिसीवर की public key, एक प्लेन टैग में जिसे रिले पढ़ सकता है
- एक रैंडमाइज़्ड टाइमस्टैम्प
- सील किया गया इनर मैसेज
सील लेयर (इनर)
गिफ्ट रैप के अंदर सील बैठता है। लेखकत्व यहीं रहता है, और रिले को यह कभी देखने को नहीं मिलता। इस लेयर में:
- यह आपकी असली key से साइन होती है, जिससे रिसीवर को पता चलता है कि मैसेज आपका है
- यह आपकी private key और रिसीवर की public key से बनी key से एन्क्रिप्ट होती है, इसलिए इसे सिर्फ आप दोनों पढ़ सकते हैं
- इसमें मैसेज कंटेंट होता है
- इसमें ऐसा टाइमस्टैम्प होता है जिसे आपका क्लाइंट जान-बूझकर दो दिन तक पीछे खिसका देता है, ताकि कोई मैसेज को उनके भेजे जाने के समय से समूहबद्ध न कर सके
गिफ्ट रैप (आउटर लेयर)
रैंडम pubkey, रिसीवर हिंट, रिले को बस इतना ही दिखता है
सील (इनर लेयर)
सेंडर की असली key से साइन, सिर्फ रिसीवर पढ़ सकता है
वास्तविक मैसेज कंटेंट
सेंडर: असली pubkey · टाइमस्टैम्प: 1234567890
मुख्य फायदे
- सेंडर प्राइवेसी: रिसीवर को छोड़कर कोई भी यह निर्धारित नहीं कर सकता कि मैसेज
किसने भेजा। लेकिन रिसीवर का नाम एक प्लेनटेक्स्ट
pटैग में होता है, जिसे रिले का पढ़ पाना ज़रूरी है। - अनलिंकेबिलिटी: हर मैसेज एक नई वन-टाइम key से साइन होता है, इसलिए एक ही सेंडर के मैसेज देखकर यह साफ़ नहीं होता कि वे आपस में जुड़े हैं।
- फॉरवर्ड सीक्रेसी नहीं है: NIP-44 अपनी conversation key दो स्टैटिक keys से
निकालता है, इसलिए जिस हमलावर को बाद में आपका
nsecमिल जाए, वह अपने सेव किए हुए हर मैसेज को डिक्रिप्ट कर सकता है। वन-टाइम keys यह छुपाती हैं कि मैसेज किसने भेजा; वे पुराने मैसेज की रक्षा नहीं करतीं। अगर यह आपके लिए मायने रखता है, तो पुराने वार्तालाप डिलीट कर दें।
डिलीवरी: DM रिले सूची (Kind 10050)
Seal और gift wrap बताते हैं कि मैसेज को कैसे पैक किया जाता है। तीसरा हिस्सा kind 10050 इवेंट है, जो बताता है कि उसे कहाँ डिलीवर किया जाता है। यह उन रिले की एक छोटी, सार्वजनिक सूची है जो आपके प्राइवेट मैसेज स्वीकार करते हैं।
स्पेक इस बारे में सख्त है: भेजने वालों को gift wrap केवल रिसीवर की kind 10050 सूची में मौजूद रिले पर ही प्रकाशित करने होते हैं। अगर आपने कभी ऐसी सूची प्रकाशित ही नहीं की, तो स्पेक आपको “मैसेज प्राप्त करने के लिए तैयार नहीं” मानता है और क्लाइंट को कोशिश भी नहीं करनी चाहिए। यानी आपको भेजे गए DM चुपचाप कभी डिलीवर नहीं होते। किसी भी तरफ कोई एरर नहीं दिखता।
दो व्यावहारिक नियम:
- कोई भी NIP-17 DM पाने की उम्मीद करने से पहले एक सूची प्रकाशित करें (नीचे माइग्रेशन गाइड का चरण 3 देखें)
- सूची छोटी रखें। स्पेक 1-3 रिले की सिफारिश करता है, और सूची में बैठा हर रिले देख सकता है कि आपको कौन मैसेज भेज रहा है
माइग्रेशन गाइड: NIP-04 से NIP-17 में स्विचिंग
आधुनिक Nostr क्लाइंट के साथ NIP-17 में माइग्रेट करना सरल है। यहां स्विच कैसे करें।
चरण 1: अपने क्लाइंट सपोर्ट चेक करें
NIP-17 तभी काम आता है जब बातचीत के दोनों सिरों पर बैठा क्लाइंट इसे बोलता हो। ये चार अपने डॉक्यूमेंटेशन या अपने सोर्स कोड में यह कहते हैं:
| क्लाइंट | NIP-17 | कहाँ चलता है |
|---|---|---|
| Amethyst | हाँ | Android |
| 0xchat | हाँ | Android, iOS |
| Coracle | हाँ | वेब |
| Snort | हाँ | वेब |
Damus के लिए अलग से चेतावनी। सितंबर 2026 तक Damus जो स्पेसिफिकेशन सूची प्रकाशित करता है उसमें NIP-17 है ही नहीं, सिर्फ पुराना NIP-04 है। इसके दो नतीजे हैं, और दोनों मायने रखते हैं। आपका भेजा हुआ गिफ्ट-रैप मैसेज Damus वाले व्यक्ति को बिल्कुल भी नहीं दिखेगा। और वे जो कुछ भेजते हैं वह एक सादे kind 4 इवेंट के रूप में जाता है, जिसके बाहर आप दोनों की public keys लिखी होती हैं, और उसे स्टोर करने वाला हर रिले उन्हें पढ़ सकता है। अगर बातचीत संवेदनशील है, तो उसे ऊपर दिए क्लाइंट में से किसी एक पर ले जाएं।
Primal, Iris और Nos बीच की अनिश्चित जगह पर हैं। Primal सार्वजनिक रूप से कुछ नहीं कहता, इसलिए उसे अज्ञात मानिए। Iris अपनी प्राइवेट चैट को सादे NIP-17 के बजाय अपनी ही double-ratchet स्कीम से एन्क्रिप्ट करता है, जो Iris के भीतर ठीक है और उसके बाहर किसी बात की गारंटी नहीं। Nos न NIP-17 सूचीबद्ध करता है और न वे दो स्पेसिफिकेशन जिन पर वह बना है, और प्रोजेक्ट 2025 की शुरुआत से शांत है।
क्लाइंट की फीचर सूचियाँ गाइड से तेज़ बदलती हैं। अगर आपके क्लाइंट का नाम यहाँ नहीं है, तो चरण 5 का टेस्ट changelog पढ़ने से जल्दी फैसला कर देगा।
चरण 2: आमतौर पर चालू करने को कुछ होता ही नहीं
यह चरण आपकी उम्मीद से छोटा है। ऊपर दिए किसी भी क्लाइंट में “NIP-17 चालू करें” जैसा कोई टॉगल डॉक्यूमेंट नहीं है, क्योंकि ढूँढ़ने के लिए वह है ही नहीं। सामने वाला व्यक्ति जिस पल गिफ्ट रैप पाने लायक होता है, ये क्लाइंट अपने आप उन्हीं का उपयोग करने लगते हैं।
तो सीधे चरण 3 पर जाइए, असल में आपकी जरूरत वहीं है। आपकी मौजूदा NIP-04 बातचीतें जहाँ हैं वहीं रहती हैं और पढ़ी जा सकती हैं; उन्हें कुछ भी बदलता नहीं।
चरण 3: अपनी DM रिले सूची (Kind 10050) प्रकाशित करें
NIP-17 भेजने वाले सिर्फ़ उन्हीं रिले पर डिलीवर करते हैं जो आपके kind 10050 इवेंट में सूचीबद्ध हैं। इसके बिना आपको भेजे गए मैसेज चुपचाप गिर जाते हैं (ऊपर डिलीवरी: DM रिले सूची देखें)।
- अपने क्लाइंट में DM, प्राइवेट-मैसेज, या मैसेजिंग-रिले सेटिंग ढूँढें
- एक से तीन ऐसे रिले जोड़ें जो gift wrap (kind 1059) स्वीकार करते हों। कुछ रिले इन्हें अस्वीकार कर देते हैं
- सेव करें। आपका क्लाइंट आपके लिए kind 10050 सूची प्रकाशित कर देता है
कुछ क्लाइंट पहली बार प्राइवेट चैट खोलते ही यह सूची आपके लिए प्रकाशित कर देते हैं। यह मान कर मत चलिए कि आपके क्लाइंट ने किया: उस पर भरोसा करने से पहले चरण 5 में डिलीवरी वेरिफाई करें।
चरण 4: अपने संपर्कों को सूचित करें
NIP-17 तभी काम करता है जब दोनों पक्षों के पास NIP-17 सपोर्ट हो। जिन संपर्कों से आपकी अक्सर बात होती है, उन्हें एक नोट भेजें:
"अरे! मैं अपने DMs में बेहतर प्राइवेसी के लिए NIP-17 में अपग्रेड कर रहा हूं।
कृपया अपना Nostr क्लाइंट अपडेट करें अगर आपने पहले से नहीं किया है।
हमारे भविष्य के मैसेज अधिक सुरक्षित होंगे!"
चरण 5: वेरिफाई करें कि यह वाकई काम कर रहा है
जो जाँच असल में मायने रखती है उसमें कोई तकनीकी कौशल लगता ही नहीं। चरण 1 के किसी क्लाइंट का उपयोग करने वाले किसी व्यक्ति से कहिए कि वह आपको मैसेज करे, फिर आप जवाब दीजिए। अगर दोनों दिशाओं में मैसेज पहुँचते हैं, तो आपकी kind 10050 सूची प्रकाशित है और गिफ्ट रैप आप तक आ रहे हैं। अगर आपका मैसेज गायब हो जाता है और दोनों में से किसी को कोई एरर नहीं दिखता, तो यह रिले सूची न होने का जाना-पहचाना लक्षण है, और वापस चरण 3 पर जाना चाहिए।
यही टेस्ट आप अकेले भी कर सकते हैं: किसी दूसरे क्लाइंट में अपने अकाउंट से लॉग इन कर लीजिए, या अगर आपका क्लाइंट देता है तो खुद को मैसेज भेज दीजिए।
अगर आप जानना चाहते हैं कि असल में भेजा क्या जा रहा है, तो njump.me जैसा कोई Nostr इवेंट व्यूअर आपको raw इवेंट दिखा देगा। काम करता हुआ गिफ्ट रैप कुछ ऐसा दिखता है:
// उदाहरण NIP-17 इवेंट (सरलीकृत)
{
"kind": 1059, // गिफ्ट रैप इवेंट
"pubkey": "<random_ephemeral_key>", // वास्तविक सेंडर नहीं!
"tags": [["p", "<recipient_pubkey>"]],
"content": "<encrypted_seal_content>"
}
यहाँ दो चीज़ें पढ़नी हैं। pubkey एक वन-टाइम key है जिसे आप पहचानेंगे नहीं, और यही सेंडर का छुपा होना है, ठीक वही जो आप चाहते हैं। p टैग रिसीवर की असली key ज़रूर दिखाता है। यह आपके सेटअप की गड़बड़ी नहीं है; रिले को यह जानना ही है कि मैसेज कहाँ जाना है।
सुरक्षा सर्वोत्तम अभ्यास
NIP-17 उपयोग करते समय अपनी प्राइवेसी को अधिकतम करें:
1. संवेदनशील संचार से पहले क्लाइंट सपोर्ट वेरिफाई करें
कुछ भी संवेदनशील साझा करने से पहले हमेशा कन्फर्म करें कि आपका संपर्क NIP-17-सक्षम क्लाइंट उपयोग करता है। जिसका क्लाइंट सिर्फ NIP-04 बोलता है, उसे भेजा गया गिफ्ट रैप गिबरिश बनकर नहीं पहुँचता। वह पहुँचता ही नहीं: उनका क्लाइंट kind 1059 इवेंट कभी खोजने ही नहीं जाता, और आप दोनों में से किसी को कोई एरर नहीं मिलता।
2. NIP-04 पर लौटने को एक असली फैसला मानें
कुछ क्लाइंट आपको पुराना NIP-04 थ्रेड चलाते रहने देते हैं। कभी-कभी यही व्यावहारिक विकल्प होता है, लेकिन इसकी कीमत जान लीजिए: NIP-04 मैसेज दोनों public keys को खुले में, हर उस इवेंट पर डाल देता है जिसे हर रिले स्टोर करता है। इसे उसी बातचीत के लिए रखिए जिसका सार्वजनिक रूप से आपसे जुड़ जाना आपको नागवार न हो, और कुछ भी संवेदनशील एक नई NIP-17 बातचीत के रूप में शुरू कीजिए।
3. उच्च-सुरक्षा वार्तालाप के लिए नई keys उपयोग करें
अधिकतम सुरक्षा के लिए:
- संवेदनशील संचार के लिए एक समर्पित keypair बनाएं
- सुरक्षित आउट-ऑफ-बैंड चैनल के माध्यम से public key साझा करें
- समय-समय पर keys रोटेट करें
4. अन्य इवेंट प्रकारों में मेटाडेटा से अवगत रहें
NIP-17 केवल डायरेक्ट मैसेज को प्रोटेक्ट करता है। अन्य इवेंट प्रकार (नोट्स, रिएक्शन, फॉलोज़) अभी भी सोशल ग्राफ डेटा एक्सपोज़ करते हैं। कम्पार्टमेंटेशन के लिए मल्टीपल पहचान उपयोग करें।
5. प्राइवेसी-फोकस्ड रिले चुनें
NIP-17 के साथ भी, आपके ट्रैफिक पैटर्न रिले को दिखाई देते हैं। उपयोग करें:
- अतिरिक्त नेटवर्क-लेवल प्राइवेसी के लिए Tor या VPN
- ऐसे रिले जो लॉग नहीं करते या मैसेज मेटाडेटा रिटेन नहीं करते
- अपने ट्रैफिक को वितरित करने के लिए मल्टीपल रिले
6. सीमाओं को समझें
NIP-17 असली सुधार है, और यह कोई अदृश्यता की चादर नहीं है:
- रिले अभी भी आपका IP एड्रेस देखते हैं (VPN या Tor उपयोग करें)
- टाइमिंग एनालिसिस अब भी संचार पैटर्न प्रकट कर सकती है
- रिसीवर की key लिफाफे पर प्लेन टेक्स्ट में रहती है, और यह डिज़ाइन से है
- कंप्रोमाइज़्ड फोन या क्लाइंट सब कुछ लीक कर देता है, प्रोटोकॉल चाहे जो करे
सामान्य समस्याओं का निवारण
”मेरे मैसेज कभी नहीं पहुँचते”: पहले अपनी DM रिले सूची जाँचें
यह NIP-17 की सबसे आम विफलता है, और यह लगभग कभी एन्क्रिप्शन की समस्या नहीं होती।
NIP-17 भेजने वाले आपके सामान्य रिले पर डिलीवर नहीं करते। वे एक kind 10050 इवेंट खोजते हैं, यानी आपकी वह प्रकाशित सूची कि कौन-से रिले आपके डायरेक्ट मैसेज स्वीकार करते हैं। gift wrap सिर्फ़ वहीं जाते हैं। अगर आपने कभी ऐसी सूची प्रकाशित ही नहीं की, तो भेजने वाले के क्लाइंट के पास कोई गंतव्य नहीं होता और मैसेज चुपचाप गिर जाता है। दोनों में से किसी भी इंटरफ़ेस में कुछ नहीं दिखता।
समाधान: NIP-17 सपोर्ट करने वाले किसी क्लाइंट में प्राइवेट-मैसेजिंग रिले सेटिंग ढूँढें और कम से कम एक रिले सेव करें। इससे आपकी kind 10050 सूची प्रकाशित हो जाती है। ऐसा रिले चुनें जो वाकई gift wrap स्वीकार करता हो, क्योंकि कुछ रिले kind 1059 को सीधे अस्वीकार कर देते हैं।
सूची छोटी रखें। उसमें मौजूद हर रिले वह रिले है जो देख सकता है कि आपको कौन लिख रहा है। (यह माइग्रेशन गाइड का चरण 3 है, अगर आपने इसे छोड़ दिया था तो वहीं से शुरू करें।)
“एक खास संपर्क तक मेरा भेजा कुछ भी नहीं पहुँचता”
अगर बाकी सबको आपका मैसेज मिल जाता है और एक व्यक्ति को नहीं, तो समस्या उनके सिरे पर है, आपकी एन्क्रिप्शन में नहीं। लगभग तय है कि उनके क्लाइंट में NIP-17 सपोर्ट ही नहीं है, इसलिए वह गिफ्ट रैप की सदस्यता कभी लेता ही नहीं और आपका मैसेज कभी देखता ही नहीं। गिबरिश जैसा कुछ नहीं दिखता, क्योंकि कुछ दिखता ही नहीं।
फिक्स: उनसे चरण 1 वाले किसी क्लाइंट पर जाने को कहें। अगर वे नहीं कर सकते और आप दोनों सिर्फ पुराने NIP-04 मैसेज पर ही बात कर सकते हैं, तो पहले सुरक्षा सर्वोत्तम अभ्यास वाली चेतावनी पढ़ लें: NIP-04 आप दोनों की public keys हर रिले को खुले में सौंप देता है।
“देख नहीं सकते कि किसी ने मेरा NIP-17 मैसेज पढ़ा”
कारण: अभी NIP-17 के लिए रीड रिसीप्ट स्टैंडर्डाइज़ नहीं हैं समाधान: यह अपेक्षित व्यवहार है। NIP-17 डिलीवरी कन्फर्मेशन से प्राइवेसी को प्राथमिकता देता है।
“मैसेज गलत क्रम में दिखते हैं”
कारण: डिवाइस के बीच क्लॉक स्क्यू समाधान: सुनिश्चित करें कि आपका डिवाइस समय सिंक्रनाइज़्ड है (ऑटोमैटिक टाइम सिंक एनेबल करें)
“रिले NIP-17 इवेंट्स रिजेक्ट करता है”
कारण: रिले पुराना सॉफ्टवेयर चला रहा है, या वह kind 1059 इवेंट स्टोर करने से साफ़ इनकार करता है समाधान: उसे अपनी DM रिले सूची से हटाकर कोई दूसरा रिले रख दें। कुछ क्लाइंट अपनी रिले स्क्रीन पर दिखाते हैं कि रिले क्या सपोर्ट करता है; अगर आपका नहीं दिखाता, तो जाँच-पड़ताल करने से जल्दी यह है कि दूसरा रिले आज़माकर देख लें कि मैसेज आने लगे या नहीं। ऑपरेटर को बता देना भी एक मिनट के लायक है।
“मेरा क्लाइंट मुझसे मैसेज का प्रकार चुनने को कहता है”
अपेक्षित व्यवहार: नेटवर्क के पूरी तरह शिफ्ट होने तक कुछ क्लाइंट दोनों फॉर्मेट पढ़ते-लिखते हैं और आपको हर बातचीत के लिए चुनने देते हैं। जब भी NIP-17 का विकल्प मिले, उसे चुनें।
Nostr में प्राइवेट मैसेजिंग का भविष्य
NIP-17 इस समय Nostr पर एक-से-एक प्राइवेट मैसेजिंग का स्टैंडर्ड है, और आज आपको यही उपयोग करना चाहिए। हालाँकि यह रास्ते का अंत नहीं है, और इसकी दो असली कमियों पर ही लोग काम कर रहे हैं: फॉरवर्ड सीक्रेसी नहीं है, और ढंग की ग्रुप चैट नहीं है।
अब तक का सबसे गंभीर जवाब Marmot प्रोटोकॉल है, जो MLS (Signal जैसी ग्रुप चैट के पीछे वाला ग्रुप-मैसेजिंग स्टैंडर्ड) को Nostr के ऊपर रखता है और पहचान के लिए Nostr keys ही रखता है। Marmot की अपनी रिपॉजिटरी स्पेक को अपनाया हुआ बताती है, और White Noise उसी पर बना चैट ऐप है। यह तरीका फॉरवर्ड सीक्रेसी देता है और ग्रुप भी संभालता है, यानी ठीक वही जो NIP-17 छोड़ देता है।
एक बात साफ़ कर देना जरूरी है, क्योंकि नंबर देखकर भ्रम होता है। NIP-44 NIP-17 की प्रतिद्वंद्वी नहीं है और उसकी जगह नहीं लेगी। NIP-44 वही एन्क्रिप्शन है जो NIP-17 अपनी दोनों लेयर के लिए पहले से उपयोग करता है। दोनों एक ही चीज़ के हिस्से हैं।
निष्कर्ष
NIP-17 NIP-04 पर एक असली सुधार है, और यही आपको उपयोग करना चाहिए। लेकिन आपको मिल क्या रहा है, इस बारे में साफ़ रहिए। आपके शब्द एन्क्रिप्टेड हैं और रिले यह नहीं बता सकता कि मैसेज किसने भेजा। वह यह अब भी देख सकता है कि मैसेज किस अकाउंट के लिए है, और दोनों सिरों पर नज़र रखने वाला टाइमिंग से अब भी बहुत कुछ जान सकता है। इसे बिना निशान वाली नहीं, प्राइवेट डाक मानिए।
इस पर आना ज़्यादातर सही क्लाइंट चुनने और एक छोटी सूची प्रकाशित करने की बात है। सपोर्ट असली है पर असमान है, और iPhone पर सबसे ज़्यादा उपयोग होने वाले क्लाइंट में से एक, Damus, में अब भी नहीं है, इसलिए बातचीत के दूसरे सिरे को जाँच लेना वैकल्पिक कदम नहीं है।
एक्शन आइटम:
- ✅ ऐसा क्लाइंट उपयोग करें जो NIP-17 सपोर्ट करता हो (Amethyst, 0xchat, Coracle, Snort)
- ✅ अपनी DM रिले सूची (kind 10050) प्रकाशित करें। इसके बिना कुछ नहीं पहुँचता
- ✅ किसी संपर्क के साथ दोनों दिशाओं में टेस्ट मैसेज भेजें, ताकि आपको पता हो कि डिलीवरी काम कर रही है
- ✅ कुछ भी संवेदनशील भेजने से पहले देख लें कि सामने वाला किस क्लाइंट पर है
याद रखें: प्राइवेसी एक आदत है, जिसे बरतना पड़ता है। NIP-17 आपको टूल्स देता है; उन्हें ठीक से उपयोग करना अब भी आप पर है।
अपने NIP-17 ज्ञान का परीक्षण करें
सुरक्षित मैसेजिंग की अपनी समझ चेक करने के लिए तैयार हैं?
एन्क्रिप्शन
0/5 उत्तर दिए
अंतिम अपडेट: 2 सितंबर, 2026
क्वेश्चन हैं? Nostr पर चर्चा में शामिल हों या इस डॉक्यूमेंटेशन रिपोजिटरी पर इश्यू खोलें।
आगे पढ़ें
- प्राइवेसी और सुरक्षा डीप डाइव, वह बड़ा थ्रेट मॉडल जिसके भीतर ये मैसेज बैठते हैं
- आपकी Keys, आपकी Identity, key खो जाना यानी बातचीत भी हमेशा के लिए खो जाना