C-toxcore: एक नया पोर्टेबल सरल मानक टॉक्स सेव फॉर्मेट बनाएं

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

मुझे लगता है कि इस प्रारूप को एक साधारण कुंजी-मूल्य स्टोर प्रदान करना चाहिए जहां ग्राहक उपयोगकर्ता नाम, ऑनलाइन स्थिति, स्थिति संदेश और मित्र उपनामों की सूची जैसी चीजों को स्टोर कर सकते हैं (यह भी देखें: #112)। क्लाइंट इंटरऑपरेबिलिटी सुनिश्चित करने के लिए कुछ मानक कुंजियों को टीसीएस द्वारा परिभाषित किया जाएगा।

मैं https://github.com/TokTok/c-toxcore/issues/112#issuecomment -257151226 में फेंक दूंगा

@isotoxin सुरक्षित संचार को संभालने के लिए ज़िम्मेदार लाइब्रेरी में JSON पार्सर को लागू करने का प्रयास करना गलत लगता है, क्योंकि आप केवल हमले/बग सतह को चौड़ा कर रहे हैं। यदि, उदाहरण के लिए, आप एक JSON कॉन्फ़िगरेशन चाहते हैं, तो इसे एक अच्छी तरह से बनाए रखा पुस्तकालय में स्थगित करना बेहतर है जो JSON (और _only_ हैंडल JSON) को संभालने के लिए था। https://github.com/akheron/jansson/ JSON मामले के लिए एक आदर्श उम्मीदवार की तरह लगता है; यह टोक्सकोर की तरह ही पोर्टेबल है, और एम्बेडेड प्लेटफॉर्म के लिए भी उपयुक्त है।

दस्तावेज़ पढ़ने के बाद मैं सहमत हूं कि वर्तमान प्रारूप भयानक है और मरना चाहिए।

न्यूनतम क्लाइंट के लिए लागू करने के लिए आवश्यक सामग्री को कम करने के लिए मुझे लगता है कि फ़ाइल को दो भागों में विभाजित किया जाना चाहिए:

• मूल भाग
• वैकल्पिक भाग

मूल भाग में एक साधारण प्रारूप (शायद बाइनरी भी) में ग्राहकों के बीच दोस्तों (निर्णय लेने के लिए) को स्थानांतरित करने के लिए न्यूनतम मात्रा में डेटा होगा और पार्स करने के लिए बाहरी पुस्तकालय की आवश्यकता नहीं होनी चाहिए।

वैकल्पिक भाग को मूल भाग में जोड़ा जाएगा और JSON (या जो कुछ भी) एन्कोडेड है। प्रत्येक क्लाइंट के लिए आवश्यक कुछ कुंजी, जैसे उपनाम, पिछली बार ऑनलाइन,...

चर्चा करना।

मुझे JSON प्रारूप का विचार पसंद है क्योंकि इसे पढ़ना आसान है (मानव के लिए) और यह स्वयं द्वारा क्रॉस प्लेटफॉर्म सुरक्षित है। वास्तव में इसके लिए एक अतिरिक्त और बाहरी पुस्तकालय की आवश्यकता होती है, लेकिन कम से कम कुछ मामलों में ग्राहक उसी पुस्तकालय का उपयोग कर सकते हैं, ताकि वे कॉन्फिग हैंडलिंग (कॉन्फ़िगरेशन का वैकल्पिक भाग) के अपने हिस्से को संभाल सकें। साथ ही, मुझे कठिन समय सोचने का मामला है जहां क्रॉस प्लेटफॉर्म कॉन्फ़िगरेशन फ़ाइल का संचालन, संभवतः समृद्ध सामग्री युक्त, बाहरी पुस्तकालयों (JSON, msgpack, protobuf, जो भी हो) के बिना किया जाता है।

मुझे अचानक 6 का विचार पसंद है कि टॉक्स सेव फॉर्मेट में दो भाग हो सकते हैं।
मूल भाग - खाते को कार्यात्मक बनाने के लिए डेटा के आवश्यक और सभी आवश्यक

वैकल्पिक भाग - वह भाग जिसमें ग्राहक की विशिष्ट जानकारी या अन्य जानकारी हो सकती है जो काम करने के लिए आवश्यक नहीं है। यह वैकल्पिक हिस्सा कुछ ऐसा होगा जो क्लाइंट टोक्सकोर से पूछ सकता है। कॉन्फिग के इस हिस्से में क्लाइंट टॉक्सकोर को कुछ स्टोर करने के लिए भी कह सकते हैं। वैकल्पिक कॉन्फ़िगरेशन के किसी भी भाग को टॉक्सकोर द्वारा व्याख्या नहीं किया जाना चाहिए, लेकिन कोर क्लाइंट को स्ट्रिंग के रूप में देता है। ग्राहक इसे अपनी इच्छानुसार संभाल सकते हैं।

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

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

आइए बुनियादी और वैकल्पिक अनुभागों के साथ JSON कॉन्फ़िग फ़ाइल के पेशेवरों और विपक्षों के बारे में सोचें:
पेशेवरों

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

दोष

• बाहरी पुस्तकालय की आवश्यकता है
• बुनियादी और वैकल्पिक विभाजन सुरक्षा चिंताओं का परिचय देते हैं
• बाइनरी डेटा के लिए अक्षम (मित्र अवतार?)
• यदि क्लाइंट स्वतंत्र रूप से कुछ भी शामिल कर सकते हैं, तो वे कॉन्फिग सेव फाइल के वैकल्पिक हिस्से में कार्बेज का विशाल ढेर बन सकते हैं (पेशेवर देखें। -> सरल संस्करण सहेजें)।
• टोक्सकोर को सिंटैक्स मान्य होना चाहिए लेकिन वैकल्पिक भागों की व्याख्या नहीं करनी चाहिए

आखिरकार, मुझे टॉक्स सेव फाइल के लिए JSON फॉर्मेट का विचार पसंद है। हालाँकि, इसका कार्यान्वयन सावधानी से किया जाना चाहिए! कृपया अधिक चर्चा...

बाइनरी डेटा के लिए अक्षम (मित्र अवतार?)

IIRC अवतार अभी *.tox फ़ाइल में संग्रहीत नहीं हैं और मुझे लगता है कि कॉन्फ़िग फ़ाइल में इतना डेटा संग्रहीत करना वास्तव में एक बुरा विचार होगा।

बुनियादी और वैकल्पिक विभाजन सुरक्षा चिंताओं का परिचय देते हैं

क्यों?

यदि क्लाइंट स्वतंत्र रूप से कुछ भी शामिल कर सकते हैं, तो वे कॉन्फिग सेव फाइल के वैकल्पिक हिस्से में कार्बेज का विशाल ढेर बन सकते हैं (पेशेवर देखें। -> सरल संस्करण सहेजें)।

हां, यह एक बड़ी समस्या बन सकती है।

टोक्सकोर को सिंटैक्स मान्य होना चाहिए लेकिन वैकल्पिक भागों की व्याख्या नहीं करनी चाहिए

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

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

• कम कॉन्फ़िग फ़ाइलें
• पार्सर पुस्तकालयों पर कोई कठोर निर्भरता नहीं

दोष

• कोई गारंटी नहीं है कि प्रत्येक ग्राहक आयात/निर्यात लागू करता है

कुल मिलाकर मुझे लगता है कि सामग्री को कैसे सहेजना है, इस पर कि इस फ़ाइल में

@ मास्टर-पासेलि

JSON प्रारूप के साथ, सहेजी गई फ़ाइल को एन्क्रिप्ट करना तुच्छ है।

डेटा प्रारूप की परवाह किए बिना एन्क्रिप्ट/डिक्रिप्ट करना तुच्छ है।

@ अचानक6

इसके अलावा एक संभावित समाधान यह होगा कि क्लाइंट को जेएसओएन पार्सिंग को लाइब्रेरी के साथ अपनी पसंद से संभालने दें और उपयुक्त कॉन्फ़िगरेशन स्ट्रक्चर/फ़ंक्शन के साथ बस init toxcore दें।

एरर, नहीं, समाधान नहीं, लेकिन चीजों को गलत तरीके से करना।

मैं मानता हूं कि टॉक्स सेव फाइल में अवतारों को सहेजना बुरा विचार हो सकता है लेकिन अवतार सिर्फ एक उदाहरण था। मैं अब किसी भी बाइनरी डेटा के बारे में नहीं सोच सकता जिसे हम सेव फाइल में सेव करना चाहते हैं लेकिन भविष्य में हमारे पास हो सकता है। भविष्य की भविष्यवाणी करना थोड़ा कठिन है। :)

बुनियादी और वैकल्पिक भागों में कुछ सुरक्षा चिंताएँ हैं यदि वैकल्पिक भाग कुछ ऐसा है जिसे ग्राहक स्वतंत्र रूप से जोड़ सकते हैं। यह कुछ तरीके खोलता है कि कैसे बगी क्लाइंट अच्छी तरह से तैयार किए गए या बगी डेटा देकर टॉक्स कोर को खतरे में डाल सकता है। मुझे विश्वास है कि यह सुनिश्चित करके इस संभावना को कम किया जा सकता है कि क्लाइंट द्वारा जोड़े गए भागों को टोक्सकोर द्वारा व्याख्या नहीं किया गया है और टॉक्सकोर वाक्य-विन्यास उन हिस्सों को मान्य करता है जिन्हें ग्राहक शामिल करना चाहते हैं।

@ अचानक6

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

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

यदि इस तरह का मूल और वैकल्पिक भाग अलगाव किसी भी मामले में बहुत जोखिम भरा है, तो भी मैं JSON प्रारूप के लिए +1 देता हूं। मैंने बहुत सारे b *t XML कॉन्फिग या बाइनरी * के ढेर देखे हैं।