Matrix डिवाइस वेरिफिकेशन अब अनिवार्य होगा

• अप्रैल 2026 से अनवेरिफाइड डिवाइस Element में end-to-end encrypted (E2EE) मैसेज न तो भेज सकेंगे, न ही प्राप्त कर सकेंगे
• यह बदलाव Matrix specification update के अनुसार है, और सभी यूज़र्स की बातचीत की सुरक्षा मजबूत करने के लिए किया जा रहा है
• डिवाइस वेरिफिकेशन वह प्रक्रिया है जिसमें क्रिप्टोग्राफ़िक तरीके से साबित किया जाता है कि यूज़र का हर डिवाइस वास्तव में उसी का है, जिससे untrusted message का संकेत हट जाता है
• आगे चलकर केवल verified डिवाइस ही बातचीत में भाग ले सकेंगे, और warning icon या shield indicator दिखाई नहीं देंगे
• यह कदम trust-based secure communication environment बनाने की दिशा में एक अहम चरण है

---

सुरक्षा अपडेट का अवलोकन

• अप्रैल 2026 से Element अनवेरिफाइड डिवाइस के end-to-end encrypted मैसेज भेजने और पाने पर रोक लगाएगा
  • यह 2025 के अक्टूबर में Matrix conference में घोषित Matrix specification update के अनुरूप कदम है
  • यूज़र्स को अपने मौजूदा डिवाइस पर encrypted मैसेज का इस्तेमाल जारी रखने के लिए डिवाइस वेरिफिकेशन पूरा करना होगा
• इस अपडेट का उद्देश्य यह सुनिश्चित करना है कि मैसेज वास्तव में इच्छित प्रेषक से ही आया हो
• Element का लक्ष्य इसके ज़रिए सबसे सुरक्षित communication technology उपलब्ध कराना है

अनवेरिफाइड डिवाइस का जोखिम

• अनवेरिफाइड डिवाइस एक attack vector बन सकते हैं
  • उदाहरण के लिए, बातचीत के दौरान warning icon दिखना सिर्फ एक unverified डिवाइस का मामला भी हो सकता है, या account takeover attempt का संकेत भी
  • अगर ऐसे warning को नज़रअंदाज़ किया जाए, तो पूरे network में security risk फैल सकता है
• Element सभी यूज़र्स को डिफ़ॉल्ट रूप से end-to-end encryption देता है, और वेरिफिकेशन को अनिवार्य बनाकर अनिश्चितता और malicious activity की संभावना को हटाना चाहता है

डिवाइस वेरिफिकेशन की भूमिका

• डिवाइस वेरिफिकेशन हर डिवाइस के बीच एक cryptographic ‘handshake’ है, जो साबित करता है कि वह डिवाइस वास्तव में यूज़र का ही है
• किसी नए अनवेरिफाइड डिवाइस से भेजे गए मैसेज untrusted message के रूप में दिखाए जाते हैं
• वेरिफिकेशन अनिवार्य होने से यूज़र आश्वस्त रह सकते हैं कि सभी मैसेज विश्वसनीय स्थिति में हैं

डिफ़ॉल्ट डिज़ाइन के रूप में trust

• आगे से डिवाइस केवल दो स्थितियों में होंगे: ‘verified’ या ‘बातचीत में भाग नहीं ले सकता’
  • warning या shield icon अब नहीं दिखेंगे
  • इसका उद्देश्य यूज़र्स को warning के प्रति असंवेदनशील हो जाने की समस्या से बचाना है
• डिवाइस वेरिफिकेशन सिर्फ व्यक्तिगत सुरक्षा ही नहीं, बल्कि पूरे network के trust environment को मजबूत करने में भी मदद करता है
• Element security-first system design को आगे बढ़ा रहा है, और वेरिफिकेशन प्रक्रिया उसका मुख्य हिस्सा है

यूज़र्स को क्या करना चाहिए

• जिन यूज़र्स ने पहले से अपने डिवाइस verify कर लिए हैं और recovery key सेट कर ली है, उन्हें कोई अतिरिक्त कार्रवाई नहीं करनी है
• बाकी यूज़र्स को ये कदम उठाने होंगे
  • मोबाइल, web, desktop सहित सभी डिवाइस की वेरिफिकेशन स्थिति जाँचें
  • recovery feature सेट करें (वैकल्पिक, लेकिन ज़ोरदार रूप से अनुशंसित)
• recovery feature नए डिवाइस को verify करना आसान बनाती है, और सभी डिवाइस खो जाने पर भी वेरिफिकेशन रिकवर किया जा सकता है
• प्लेटफ़ॉर्म के अनुसार विस्तृत प्रक्रिया Element के user documentation में देखी जा सकती है

वेरिफिकेशन न करने पर सीमाएँ

• अप्रैल 2026 के बाद अनवेरिफाइड डिवाइस पर ये सीमाएँ लागू होंगी
  • मैसेज भेज नहीं सकेंगे
  • प्राप्त मैसेज का सामग्री भाग नहीं दिखेगा (सिर्फ यह पता चलेगा कि मैसेज आया है)
• नतीजतन, अनवेरिफाइड डिवाइस E2EE बातचीत में इस्तेमाल नहीं किए जा सकेंगे
  • हालांकि encryption बंद वाली बातचीत में भाग लेना संभव रहेगा

trust निर्माण और support

• Element ने डिवाइस वेरिफिकेशन के ज़रिए trust सुनिश्चित करना सुरक्षित संचार का मुख्य तत्व बताया है
• इस बदलाव को छोटा लेकिन security level को काफ़ी बढ़ाने वाला कदम माना जा रहा है
• कंपनी का लक्ष्य है कि यूज़र्स के साथ मिलकर सभी मैसेज आमने-सामने की बातचीत जितने भरोसेमंद बनें
• बदलाव के दौरान support team यूज़र्स के सवालों का जवाब देगी और सहज transition में मदद करेगी

[GN⁺]

Hacker News की राय

• 3 महीने पहले सर्वर बंद कर दिया और कम्युनिटी को वापस IRC पर ले गया
  Podman कंटेनर में IRC चल रहा था, इसलिए आसानी से वापस लौट सका
  हर महीने डिवाइस वेरिफिकेशन एरर, मैसेज डिक्रिप्शन फेल्योर, UX समस्याओं आदि से जूझना पड़ता था
  शुरुआती दिनों में तेज़ी से प्रगति हुई थी, लेकिन पिछले कुछ वर्षों में UX में लगभग कोई सुधार नहीं हुआ, यह निराशाजनक है
  Matrix और Element का रिश्ता भी अब उलझाने वाला लगता है

  • सार्वजनिक Matrix चैनलों में चौंकाने वाली इमेज स्पैम (CSAM सहित) भरी पड़ी है
    डेवलपमेंट टीम उदासीन दिखती है, और प्रस्तावित “policy server” भी अभी अधूरा है
  • मैंने Element ऐप इंस्टॉल करके matrix.org अकाउंट बनाया और संदेश भेजने की कोशिश की, लेकिन
    कमरे खाली थे या संदेश भेजना अटक जाता था; मैं एक बार भी संदेशों का आदान-प्रदान सफलतापूर्वक नहीं कर पाया
  • मुझे लगता है कि समस्या MVP की परिभाषा गलत तय करने से हुई
    “decentralized JSON database” की अवधारणा पर इतना अटक गए कि
    असली चैट सिस्टम के रूप में उपयोगिता छूट गई
    मैं अभी भी इसका इस्तेमाल करता हूँ, लेकिन आम उपयोगकर्ताओं को आकर्षित करने के लिए अभी लंबा रास्ता बाकी है
  • अगर IRC से काम चल जाता है, तो Matrix एन्क्रिप्शन फीचर आदि के कारण ज़रूरत से ज़्यादा भारी विकल्प हो सकता है
    IRC-आधारित कम्युनिटी को अपग्रेड करना हो, तो Jabber(XMPP) मुझे अधिक व्यावहारिक विकल्प लगता है
  • मुझे भी लगभग ऐसा ही लगा
    दोस्तों के साथ टेस्ट किया, लेकिन रफ UX की वजह से यह दूसरे मैसेंजरों से ज्यादा असुविधाजनक था
    IRC ब्रिज सपोर्ट बंद होने के बाद इसे इस्तेमाल करने की वजह ही खत्म हो गई

• कुछ महीने पहले मेरे डिवाइस रैंडम तरीके से डी-वेरिफाई हो गए, और मैंने recovery key से लॉगिन किया, लेकिन फिर भी वे वेरिफाइड नहीं हुए
  iOS, Linux, Windows और Android के बीच cross-verification बिल्कुल मेल नहीं खा रहा था
  ऐसी जबरन वेरिफिकेशन प्रक्रिया दरअसल अनैच्छिक ऑफबोर्डिंग जैसी है
  अगर कोई वेरिफिकेशन तरीका समस्या पैदा कर रहा है, तो इसकी घोषणा ब्लॉग पर करनी चाहिए
  मुझे Element पसंद है, लेकिन ऐसी चीज़ों के लिए पहले से तैयारी होनी चाहिए

  • वेरिफिकेशन फीचर आने के बाद से लगातार समस्याएँ झेल रहा हूँ
    कभी-कभी सफल हो जाता है, लेकिन तुरंत लॉगआउट हो जाता हूँ, और पुराने डिवाइस वेरिफिकेशन पॉपअप बार-बार आते रहते हैं
    आखिर में कहीं सारे प्रोफ़ाइल ही न खो दूँ, इसकी चिंता रहती है
  • मैंने भी वही निराशा झेली है
    कभी-कभी हर बार खोलने पर 30 मिनट तक समस्या सुलझानी पड़ती थी
    आइडिया अच्छा है, लेकिन मेहनत के मुकाबले मिलने वाला फायदा बहुत कम है
    इसका OSS प्रोजेक्ट कम्युनिकेशन पर भी बुरा असर पड़ता है
  • क्या आप self-hosted server इस्तेमाल करते हैं?
    मैं इसका गहन उपयोग करता हूँ, लेकिन मुझे ऐसी समस्या कभी नहीं हुई

• कुछ महीने पहले मैंने Matrix bot लागू करने की कोशिश की, लेकिन Python के open source SDKs
  E2EE और डिवाइस वेरिफिकेशन को बिल्कुल सपोर्ट नहीं करते थे, इसलिए अनुभव बहुत खराब रहा
  इसके बजाय मुझे internal Rust SDK(matrix-rust-sdk) मिला, जो काफ़ी अच्छा था
  Python/Kotlin के लिए FFI bindings भी थीं, लेकिन documentation कम थी
  LLM और source code के सहारे किसी तरह इसे चलाया, और emoji verification भी सफल रही
  अब documentation काफी बेहतर हो गई है, और reference client भी दिया जा रहा है

• मैंने Reddit पर Matrix की आलोचना वाली एक पोस्ट पढ़ी,
  जिसमें कहा गया कि डेटा स्थायी रूप से स्टोर और डुप्लिकेट होने वाली संरचना के कारण performance और privacy दोनों कमजोर हैं
  कहा गया कि Signal तो metadata तक की रक्षा करता है, जबकि Matrix में room name, participants, time आदि उजागर हो जाते हैं
  क्या यह सच है, और क्या इस प्रोटोकॉल का भविष्य है?

  • Reddit पोस्ट पूरी तरह गलत नहीं है
    फिलहाल metadata protection का स्तर Signal से कम है, लेकिन इसमें सुधार हो रहा है
    Matrix का threat model अलग है, और इसमें trust boundary को खुद चुनने की सुविधा है
    अगर इसे छोटे सर्वर पर चलाया जाए, तो Signal की तुलना में डेटा एक्सपोज़र कम हो सकता है
    यह परफेक्ट नहीं है, लेकिन इसकी प्रगति की गति और दिशा को मैं सकारात्मक मानता हूँ
  • room name एन्क्रिप्टेड नहीं है, यह देखकर मैं चौंक गया
    यह तो बुनियादी privacy requirement है, फिर भी इसका implementation धीमा है
    message decryption की समस्या भी अब तक बनी हुई है
    फिर भी open systems में मुझे यह अब भी सबसे बेहतर विकल्प लगता है
  • Signal में भी केंद्रीय प्राधिकरण पर भरोसा करना पड़ता है, और यह अब भी phone number-based है, इसलिए
    SIM spoofing attacks के प्रति संवेदनशील है
  • Matrix संरचनात्मक रूप से जटिल है
    modular और decentralized design इसकी ताकत भी है और प्रवेश बाधा भी
    Signal की संरचना सरल है, इसलिए उसके core features ज्यादा परिपक्व हैं
  • Reddit पोस्ट की बात मोटे तौर पर सही है
    आखिरकार यह भरोसेमंद सर्वर को आधार मानने वाला प्लेटफ़ॉर्म है

• इस थ्रेड में इतनी शिकायतों के बावजूद,
  मुझे लगता है कि unverified state में लॉगिन करके encrypted messages का आदान-प्रदान रोकना तर्कसंगत है
  मैं 6 साल से Matrix इस्तेमाल कर रहा हूँ, और verification process अब काफी स्मूद हो गया है
  QR code login भी पूरा हो जाए, तो यह और आसान हो जाएगा

  • लेकिन बहुत से उपयोगकर्ताओं के अस्थिर अनुभव से मैं सहमत हूँ
    अलग-अलग निर्णय तर्कसंगत हो सकते हैं, लेकिन कुल मिलाकर कम्युनिकेशन की कमी और
    documentation की कमी के कारण भ्रम पैदा होता है
    जो लोग इसे अक्सर इस्तेमाल करते हैं, उनके लिए तो ठीक है, लेकिन कभी-कभार इस्तेमाल करने वालों को हर बार recovery game खेलना पड़ता है
  • verification में encryption key exchange शामिल होता है
    इससे लॉगिन से पहले के संदेशों को डिक्रिप्ट किया जा सकता है
    verification step को स्किप करने देने वाला UX ही समस्या था
  • समस्या policy नहीं बल्कि समझाने की कमी है
    ब्लॉग में verification क्या है, इसे स्पष्ट रूप से परिभाषित करना चाहिए था

• “वेरिफिकेशन क्या है?” इस सवाल पर

  • Element आधिकारिक दस्तावेज़ के अनुसार
    नए डिवाइस पर लॉगिन करते समय मौजूदा डिवाइस से cryptographic identity proof किया जाता है
  • नए डिवाइस पर लॉगिन करते समय यह साबित करने की प्रक्रिया है कि वह डिवाइस आपका ही है
    यह emoji comparison, QR code scan, या recovery key input में से किसी एक से किया जाता है
    ज़्यादातर मामलों में यह तेज़ और सरल है, लेकिन कुछ clients में bugs हैं
  • यह किसी third-party verification जैसा बिल्कुल नहीं है
    यह सिर्फ नए डिवाइस को मौजूदा डिवाइस से approve करने की प्रक्रिया है
    अब तक इस्तेमाल किए गए encrypted messengers में यह सबसे आसान verification तरीका था
  • फिलहाल यह एक साधारण self-verification process है,
    जिसमें दोनों डिवाइस पर दिख रहे emoji एक जैसे हों, तो approval मिल जाता है
  • अच्छी बात है कि यह Play Integrity जैसी बाहरी verification नहीं है
    नए डिवाइस पर लॉगिन होने पर बस मौजूदा डिवाइस से approve करना होता है

• मैं Thunderbird को Matrix client के रूप में इस्तेमाल करता हूँ, लेकिन
  Element या Nheko खोलने पर दोनों एक-दूसरे को unverified बताते हुए warning दिखाते हैं
  verification button दबाने पर भी कुछ नहीं होता, और QR code भी नहीं दिखता
  Matrix का UX सचमुच दुःस्वप्न जैसा है

  • Thunderbird अभी beta version में है, और इसमें बहुत bugs हैं
    updates धीमे हैं, इसलिए मैंने इसका इस्तेमाल बंद कर दिया
  • मेरी भी यही स्थिति है
    सुधार के कोई संकेत नहीं दिखते

• मैंने alpha client आज़माया, लेकिन verification popup गायब ही नहीं होता
  कुछ clients में verification flow का implementation ही नहीं है, इसलिए
  लगता है नए clients के लिए entry barrier और बढ़ जाएगी
  clients अक्सर crash होते हैं, और sync delay भी गंभीर है
  इन्हीं कारणों से मुझे Matrix के बजाय XMPP ज्यादा बेहतर decentralized chat विकल्प लगता है
  XMPP खामियों को ज्यादा सलीके से संभालता है, और real-time sync problems भी नहीं हैं

  • मैं भी XMPP परिवार के साथ इस्तेमाल करता हूँ, लेकिन web interface(converse.js) काफी रफ है
    कार्यस्थल के सहकर्मियों को मनाना हो, तो बेहतर UI चाहिए
  • Element Desktop में unverified devices हटाने से इसे हल किया जा सकता है
    लेकिन XMPP में Cross Signing या key backup नहीं है, इसलिए
    Matrix जैसी सुविधा अभी उसमें कम है
  • पहले मैं Matrix का प्रशंसक था, लेकिन आजकल दिलचस्पी कम हो गई है
    Element भारी लगता है, और दूसरे clients में features का संतुलन बहुत खराब है
    इसके बजाय मैंने Prosody server के साथ XMPP फिर से आज़माया
    documentation थोड़ी कम अनुकूल है, लेकिन resource efficiency चौंकाने वाली थी
    यह प्रभावशाली है कि XMPP server कम स्पेक वाले सिस्टम पर भी अच्छी तरह चल जाता है
    client पक्ष थोड़ा निराशाजनक था, लेकिन
    मुझे लगता है documentation सुधारने की काफी गुंजाइश है
    आखिरकार मैं चाहता हूँ कि free और open source messenger ecosystem फले-फूले

• नवीनतम Matrix Conference वीडियो media.ccc.de पर उपलब्ध हैं
  उनमें बहुत सी दिलचस्प बातें हैं,
  और खुद server चलाए बिना भी etke.cc जैसी paid hosting इस्तेमाल की जा सकती है

• मुझे Matrix/Element बहुत पसंद है
  मैं FOSDEM devroom के लिए कई spaces चला रहा हूँ, और
  video calls तक पूरी तरह सही चलीं
  हालांकि, मैं चाहता हूँ कि इसमें और features जोड़े जाएँ