हर चीज का संदेशवाहक

सभी मौजूदा दूतों के पास अपने पेशेवरों और विपक्ष हैं, लेकिन उनमें से प्रत्येक अन्य के साथ असंगति के कारण कंबल को अपनी तरफ खींचता है - और उपयोगकर्ता इससे पीड़ित हैं।

XMPP एक एकल मानक बन सकता है, लेकिन यह, ई-मेल के विपरीत, अपेक्षाकृत देर से दिखाई दिया और पर्याप्त दर्शकों को प्राप्त करने का प्रबंधन नहीं किया, ताकि निगम पहले से ही इसे मना न कर सकें। आखिरकार, उन्होंने जल्दी से महसूस किया कि दर्शकों को अपने स्वयं के पारिस्थितिकी तंत्र में बनाए रखने के बिना, कमाई करने के लिए बहुत कुछ नहीं है। और इसके अलावा, मुझे स्वीकार करना चाहिए, एक्सएमपीपी में एक्सटेंशन की प्रचुरता के कारण पर्याप्त कमियां थीं, जिनमें से कई, उनके महत्व के बावजूद, प्रायोगिक स्थिति में बने रहे, और कुछ ने एक दूसरे को पूरी तरह से डुप्लिकेट किया।

स्मार्टफोन में एक दर्जन तत्काल दूतों के "नई अद्भुत दुनिया" में रहने के बाद, और इस मामले की सभी कमियों को महसूस करते हुए, हम अंत में कुछ नया करने के लिए तैयार हैं।

और हाँ, हमें एक नए मानक की आवश्यकता है!

एक उत्कृष्ट फ्यूचर मैसेंजर निम्नलिखित आवश्यकताओं को संतुष्ट करता है: खुले विकास और विकेंद्रीकरण, पोर्टेबिलिटी (क्रॉस-प्लेटफॉर्म), मल्टी-प्रोटोकॉल (अन्य संचार नेटवर्क से कनेक्ट करने की क्षमता) और उपयोगकर्ता-मित्रता के माध्यम से विश्वसनीयता, सुरक्षा सुनिश्चित करना।

सब कुछ इतना बुरा क्यों है?

लेकिन पहले, यह पता लगा लें कि हर कोई सिर्फ पहले से ही लोकप्रिय == केंद्रीकृत मैसेंजर पर स्विच नहीं करता है, चाहे वह सशर्त व्हाट्सएप हो या कहो, टेलीग्राम, जिसका रूस में काफी दर्शक हैं।

बेशक, केंद्रीकृत निर्माण मालिकों को अधिक पैसा कमाने की अनुमति देता है, और इस तरह न केवल विकास के लिए भुगतान करता है, बल्कि विज्ञापन में महत्वपूर्ण धन का निवेश भी करता है और यहां तक ​​कि सेवा सुरक्षा जैसे व्यावहारिक रूप से अनुपस्थित कार्यों का महिमामंडन भी करता है । हालांकि, इसके साथ, मालिक अचानक सेवा को बंद करने का निर्णय ले सकता है, ट्रैक्टर को डेटा सेंटर से तार को स्थानांतरित करने के लिए, या बस एक दूत को एक निश्चित देश के क्षेत्र में प्रतिबंधित किया जा सकता है। जरूरी नहीं कि राजनीतिक कारणों के लिए, हो सकता है, और सशर्त कॉपीराइट धारकों के अनुरोध पर, कई कारण हो सकते हैं। यह अच्छा है यदि बाजार के नगण्य आकार के बावजूद, टेलीग्राम रूस में अलग-अलग सफलता के साथ काम करना जारी रखता है, लेकिन यह मालिक के व्यक्तिगत खातों के कारण है, और उसी व्हाट्सएप को अवरुद्ध करने के मामले में, फेसबुक को ताले को बायपास करने के लिए भारी निवेश करने की संभावना नहीं है।

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

खैर, क्यों नहीं कुछ संघीय करने के लिए स्विच करें। उदाहरण के लिए, वही मैट्रिक्स। मैं HTTP लॉन्ग पोलिंग, खराब सर्वर रिसिबिलिटी और क्लाइंट इंटरफ़ेस की स्पष्टता के बारे में बात नहीं करता - ये सभी सॉल्व करने योग्य कार्य हैं, यद्यपि यह तुच्छ नहीं है (वैश्विक स्तर पर, यह कुछ भी नहीं बदलता है)। मुझे पसंद है कि डेवलपर्स ने एक्सएमपीपी के अनुभव को ध्यान में रखा और स्वतंत्र एक्सईपी के एक समूह के बजाय सामान्य विनिर्देशों को विकसित किया, लेकिन यह एक्सएमपीपी के नुकसान में से केवल एक है। एक अन्य समस्या संघीय नेटवर्क का क्लासिक उपकरण है, जब हमें कुछ सर्वर चुनने और उसके मालिक पर भरोसा करने के लिए मजबूर किया जाता है कि यह सुनिश्चित करेगा कि सर्वर काम कर रहा है और इसे बंद नहीं करेगा। और डेटा सेंटर की एक और विफलता की स्थिति में, हम दुनिया से कट जाएंगे, दूसरे सर्वर के साथ पिछले खाते से संवाद करने में सक्षम नहीं होंगे। यहां तक ​​कि अगर आप एक नया खाता बनाते हैं, और किसी तरह अपने संपर्कों की सूची को पुराने सर्वर से स्थानांतरित करते हैं, तो संचार करते समय, आपको किसी तरह फिर से पुष्टि करनी होगी कि यह वास्तव में आप हैं, और कोई ऐसा व्यक्ति नहीं जो आपका परिचय दे।

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

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

इस प्रकार, हालांकि पी 2 पी एक दिलचस्प तकनीक है, यह अप्रभावी हो जाएगा यदि, कहते हैं, बचाव दल को अपने निर्देशांक भेजते हैं, लगभग कोई इंटरनेट कनेक्शन और 1% बैटरी चार्ज के साथ टैगा में एक पेड़ पर कहीं नहीं है।

इसे कैसे ठीक करें?

इसलिए, मैं एक हाइब्रिड क्लाइंट-सर्वर आर्किटेक्चर को पेश करना चाहता हूं जिसने मौजूदा तरीकों का सबसे अच्छा लिया और उनकी कमियों से बचा।

इसलिए, ताकि न्यूनतम आवश्यक संसाधनों के साथ हमारा संदेशवाहक मोबाइल उपकरणों पर काम करता है, हम क्लाइंट-सर्वर मॉडल का उपयोग करेंगे, जहां कंप्यूटिंग कार्यों और ट्रैफ़िक की मांग वाले संसाधनों का अधिकतम उपयोग सर्वरों पर केंद्रित है, और क्लाइंट की तरफ डेटा को डिक्रिप्ट और उपयोगकर्ता को प्रदर्शित किया जाता है।

को संबोधित

प्रत्येक उपयोगकर्ता ई-मेल, या XMPP, यानी उपनाम @ डोमेन के प्रारूप में अपना पता प्राप्त करता है। लेकिन उपरोक्त सेवाओं के विपरीत, एक डोमेन निर्दिष्ट करना इस वास्तुकला में एक ही महत्वपूर्ण पता भूमिका नहीं निभाता है।

डोमेनों को उपनाम रजिस्ट्रार के रूप में उपयोग किए जाने की संभावना है ताकि इस संभावना को खारिज किया जा सके कि सभी मौजूदा उपनाम जानबूझकर या अनजाने में कब्जे में हो सकते हैं।

डोमेन इंटरनेट पर पैसे खर्च करता है, जो बड़े पैमाने पर पंजीकरण को रोकता नहीं है, लेकिन इसके दायरे को काफी कम कर देता है। केंद्रीकृत सेवाओं में, एक्सेस अक्सर एक मोबाइल फोन के लिंक के माध्यम से होता है, जो एक विशेष कारक भी नहीं है, लेकिन सिम कार्ड भी हवा से नहीं लिया जाता है! और इस संबंध में, मुझे आश्चर्य है कि वे https://toxme.io/ में यह कैसे लड़ने जा रहे हैं - टोक्स के लिए एक सेवा जो आपको एक छोटी उपनाम वाली लंबी कुंजी को जोड़ने की अनुमति देती है। मुझे कोई कारण नहीं दिखाई देता है कि वे अरबों कबाड़ उपनामों के साथ स्पैम क्यों नहीं कर सकते हैं।
इसके अलावा, डोमेन घर और काम के लिए विभिन्न खातों के लिए समझ बना सकता है। या एक आंतरिक कॉर्पोरेट नेटवर्क को व्यवस्थित करने के लिए।

उपयोगकर्ता के दृष्टिकोण से, किसी को लिखने के लिए, आपको उसकी पूर्ण लॉगिन या सार्वजनिक कुंजी जानने की आवश्यकता है।

सर्वर सॉफ्टवेयर के दृष्टिकोण से, यदि कोई उपयोगकर्ता अपने फिंगरप्रिंट के लिए अनुरोध किया जाता है, तो सर्वर इसके साथ जुड़े लॉगिन के लिए अपनी तालिका में खोजता है, अगर इसे तुरंत लॉगिन के लिए अनुरोध किया जाता है, तो यह कदम छोड़ दिया जाता है। फिर, जिस खाते में वर्तमान में प्रतिनिधि है उस सर्वर का लॉगिन और पता। यदि ऐसी कोई प्रविष्टि नहीं है, तो यह माना जाता है कि लॉगिन में @ के बाद इंगित किया गया खाता खाते के लिए जिम्मेदार है।

उपयोगकर्ता प्रोफ़ाइल

क्लाइंट अनुप्रयोग उपयोगकर्ता प्रोफ़ाइल का प्रतिनिधित्व करता है:

• पूर्ण उपयोगकर्ता लॉगिन
• बैकअप सर्वर की सूची
• सार्वजनिक और निजी उपयोगकर्ता कुंजी
• प्रोफ़ाइल जानकारी जैसे संपर्क सूची, चैट सेटिंग्स और उपयोगकर्ता प्रोफ़ाइल

प्रत्येक उपयोगकर्ता की सार्वजनिक कुंजी फ़ेडरेटेड नेटवर्क में प्रत्येक सर्वर के बीच वितरित की जाती है। उपयोगकर्ता किसी भी सर्वर पर लॉग इन कर सकता है, क्योंकि प्रमाणीकरण सर्वर सर्वर में संग्रहीत पासवर्ड हैश का उपयोग नहीं करता है, लेकिन उपयोगकर्ता की निजी कुंजी है।

प्राधिकरण प्रक्रिया निम्नानुसार है: सर्वर क्लाइंट को क्लाइंट की सार्वजनिक कुंजी के साथ एन्क्रिप्टेड डेटा का एक यादृच्छिक सेट भेजता है, क्लाइंट अपनी निजी कुंजी के साथ डिक्रिप्ट करता है और सर्वर को डिक्रिप्ट किए गए डेटा का एक हैश भेजता है। यदि डेटा हैश मैच है, तो सर्वर उपयोगकर्ता को अधिकृत करेगा। उसी समय, यदि उपयोगकर्ता ने पिछली बार सर्वर को बदल दिया है जिससे कनेक्शन बनाया गया है, तो फ़ेडरेटेड नेटवर्क के सभी सर्वर को उपयोगकर्ता के नए स्थान के बारे में सूचित किया जाता है।

पासवर्ड याद रखने की आवश्यकता की अनुपस्थिति (हालांकि, ग्राहक आपको निजी कुंजी को एन्क्रिप्ट करने की अनुमति देता है) दोनों मैसेंजर के साथ बातचीत को सरल करता है और आपकी चाबियाँ खोने का जोखिम पैदा करता है। इससे बचने के लिए, उन्हें अन्य उपयोगकर्ता उपकरणों की नकल करने की सिफारिश की जाती है। एक ही समय में कई उपकरणों से एक ही खाते के तहत कुछ भी चैट करने से रोकता है, केवल सीमा यह है कि वे सभी एक ही सर्वर से जुड़े होने चाहिए, अन्यथा वास्तुकला बहुत भ्रामक हो जाएगी। लेकिन यह शायद ही कोई बड़ा माइनस हो।

ब्राउज़रों के लिए ऐड-ऑन

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

और विकल्प को अभी तक बाहर नहीं किया गया है कि एक हमलावर एक वेब एप्लिकेशन को हैक करेगा और कोड को एम्बेड करेगा जो आपके सभी डेटा को मर्ज कर देगा - भले ही आवेदन के दूसरे भाग आपके लिए इसे कम कर दें, और आप इसके बारे में भी नहीं जानते हैं।

इस संबंध में, मैं इस तरह के रूप में वेब एप्लिकेशन को छोड़ने का प्रस्ताव करता हूं, और ब्राउज़र के लिए एक ऐड-ऑन स्थापित करने का प्रस्ताव करता हूं, जिसमें ये सभी कमियां परिभाषा अनुपस्थित हैं।

इसके अलावा, वेब क्लाइंट कॉन्फ़िगरेशन सर्वर के मालिकों के लिए उनके सर्वर बनाने के लिए प्रवेश सीमा को कम करने की आवश्यकता का अभाव। प्रत्येक घर का अपना सर्वर होता है!

परिवहन

ऐसे संदेशवाहक की जरूरत नहीं है जिसमें संवाद करने वाला कोई न हो? असामान्य दूतों की दिलचस्प परियोजनाएं हैं, लेकिन दर्शकों की कमी की समस्या उन्हें कम से कम कुछ लोकप्रियता हासिल करने की अनुमति नहीं देती है। नतीजतन, अधिक बार बड़े दर्शकों के साथ संदेशवाहक नहीं होते हैं और भी अधिक दर्शक प्राप्त करते हैं, और छोटे दर्शकों के साथ तत्काल दूत इसे खो देते हैं। और अक्सर यह स्थिति केवल विज्ञापन में महत्वपूर्ण निवेश को बदल सकती है।
ठीक है, इसके अलावा, इस राज्य की स्थिति को किसी अन्य दूत की स्थापना की आवश्यकता होती है, जब आपको तत्काल किसी ऐसे व्यक्ति से संपर्क करने की आवश्यकता होती है जो अन्य नेटवर्क पर नहीं है।

इसलिए, सर्वर को तृतीय-पक्ष नेटवर्क को परिवहन के संचालन का समर्थन करना चाहिए।
यदि उपयोगकर्ता अन्य त्वरित दूतों में अपने खातों से कनेक्ट करने के लिए डेटा निर्दिष्ट करता है, तो वह उन नेटवर्क के लोगों को देखेगा जिन्हें उसने अपने संपर्कों में जोड़ा था।
तृतीय-पक्ष नेटवर्क से कनेक्शन सर्वर साइड पर किया जाता है, और क्लाइंट में संपर्कों को सबसे साधारण लोगों के रूप में प्रदर्शित किया जाता है, न्यूनतम अंतर के साथ - उदाहरण के लिए, नेटवर्क का आइकन जहां से उपयोगकर्ता होता है, प्रदर्शित होता है।

एक नुकसान के रूप में, तीसरे पक्ष के नेटवर्क से कनेक्ट करने के लिए अपने डेटा के साथ सर्वर पर भरोसा करना आवश्यक हो जाता है। हर कोई अपने अधिकार को तीसरे पक्ष के सर्वर को सौंपने के लिए तैयार नहीं है, इसलिए आपको अपने स्वयं के सर्वर के निर्माण को हर तरह से प्रोत्साहित करने की आवश्यकता है।

क्रिप्टोग्राफी

बेशक, एक विकेन्द्रीकृत नेटवर्क डिवाइस सभी प्रेषित डेटा के एन्क्रिप्शन के बिना करने का प्रबंधन नहीं करता है, क्योंकि हम यह सुनिश्चित नहीं कर सकते हैं कि हमें सौंपे गए सर्वर में भी, किसी प्रकार का बुकमार्क जो सभी डेटा को मर्ज करता है, अंतर्निहित नहीं है।
यह पहले ही बताया जा चुका है कि प्राधिकरण के लिए उपयोगकर्ता की एक प्रमुख जोड़ी का उपयोग किया जाता है, अन्य उपयोगकर्ताओं को भेजे गए सभी संदेशों को भी प्रेषक की निजी कुंजी के साथ हस्ताक्षरित किया जाता है और प्राप्त करने वाली पार्टी की सार्वजनिक कुंजी के साथ एन्क्रिप्ट किया जाता है।

यहां कुछ नया नहीं है, मानक जीपीजी एन्क्रिप्शन उपकरण का उपयोग किया जाता है।
समूहों में एन्क्रिप्शन का मुद्दा अभी तक हल नहीं हुआ है, लेकिन आप संभवतः सिग्नल में उपयोग किए जाने वाले तंत्र का उपयोग कर सकते हैं।

जो पहले ही किया जा चुका है

फिलहाल, हमने पहले ही टॉरनेडो का उपयोग करके पायथन में एक सर्वर बनाया है, जो मैसेंजर के बुनियादी कार्यों को लागू करता है, एक थोड़ा जमे हुए वेब संस्करण है जिसे ब्राउज़र के लिए अतिरिक्त रूप से परिवर्तित किया जाना चाहिए, रस्ट में एक पुस्तकालय है, जिसके आधार पर क्लाइंट QML इंटरफ़ेस के साथ काम करता है।

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

मैं यह भी नोट करना महत्वपूर्ण मानता हूं कि ग्राहक एक श्रेणी का उपयोग करता है चैट की सूची में, नवीनतम संदेशों की तारीख के अनुसार क्रमबद्ध, व्यापक रूप से आधुनिक तत्काल दूतों में उपयोग किया जाता है, और एक पारंपरिक रोस्टर, श्रेणियों में संपर्कों को क्रमबद्ध करने के साथ। मैसेंजर के सक्रिय उपयोग के साथ, आपको बड़ी संख्या में चैट के साथ बातचीत करनी होगी, और कभी-कभी बदलते क्रम में उनके लिए खोज करना मुश्किल हो जाता है। उसी टेलीग्राम में सूची के शीर्ष पर चयनित चैट को पिन करने की समस्या को आंशिक रूप से हल करता है, लेकिन यह केवल समस्या का एक अस्थायी समाधान है।

→ यहाँ रिपॉजिटरी हैं जो हमारी अंतर्दृष्टि को दर्शाते हैं