साक्ष्य प्रारूप

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

हस्ताक्षरित क्या है#

कलेक्टर हर एक्सपोर्ट फॉर्मेट को जनरेट करने से पहले जर्नल के हस्ताक्षरों को सत्यापित करता है। यह स्रोत जाँच अलग से डाउनलोड की गई CSV या HTML फ़ाइल पर हस्ताक्षर नहीं बनाती है। इसी तरह, एक मान्य JSONL इवेंट हस्ताक्षर अटैचमेंट बाइट्स प्रदान नहीं करता है या यह स्वतंत्र रूप से स्थापित नहीं करता है कि पूरा अवलोकित जर्नल प्रदान किया गया था।

जांच हस्तांतरण#

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

4. प्राप्तकर्ता से ZIP की पुष्टि करवाएँ, इसके लिए वेरिफायर की एक विश्वसनीय प्रति और स्वतंत्र रूप से प्रदान किया गया फिंगरप्रिंट/चेकपॉइंट उपयोग करें। विश्वसनीय चेकआउट से, जिसमें इसका पाइथन वातावरण सक्रिय हो:

   python -m tgwitness.verify evidence.zip --fingerprint TRUSTED_PUBLIC_KEY_SHA256 --checkpoint retained-checkpoint.json

   सफल आउटपुट रिपोर्ट key_pinned: true और checkpoint_checked: true तब होती है जब दोनों इनपुट प्रदान किए जाते हैं और स्वीकार किए जाते हैं। सत्यापन परिणाम को संरक्षित करें।

   For a handover requiring the final exported record to be witnessed, use
   `--witness witness.zip --witness-fingerprint TRUSTED_WITNESS_SHA256 --require-witness`.
   This refuses an export with an unwitnessed tail. See the
   [witness handover procedure](WITNESS.md#require-a-witnessed-export-boundary).
   

   5. अपने कस्टडी रिकॉर्ड में आर्काइव का SHA-256, एक्सपोर्ट बाउंड्री, ट्रांसफर की तारीख, प्रेषक और प्राप्तकर्ता को दर्ज करें। मूल पैकेज को जस का तस रखें और कॉपी से काम करें। एप्लिकेशन की प्राइवेट डेटा डायरेक्टरी के बजाय सबूत वाली फ़ाइलें साझा करें, जिसमें अकाउंट सेशन और साइनिंग सीक्रेट्स भी शामिल होते हैं। स्थानांतरण के लिए, एक एक्सपोर्ट को पासवर्ड-सुरक्षित AES-256 ज़िप में डाला जा सकता है। पासवर्ड केवल गोपनीयता की रक्षा करता है और संग्रहीत नहीं होता है; प्राप्तकर्ता आर्काइव को निकालता है और अंदर के हस्ताक्षरित एक्सपोर्ट को सत्यापित करता है, जो अपरिवर्तित रहता है।
   6. यदि स्वतंत्र टाइम एंकरिंग की आवश्यकता है, तो RFC 3161 प्रक्रिया का पालन करें और अनुरोध, चेकपॉइंट, विश्वसनीय CA जानकारी, और सत्यापित प्राधिकरण प्रतिक्रिया को बनाए रखें। केवल अनुरोध तैयार करने से टाइमस्टैम्प प्राप्त नहीं होता है।

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

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

Apprise के माध्यम से भेजे गए सूचनाओं में वर्कस्पेस और चैट के नाम और संख्याएँ होती हैं; हटाए गए और संपादित संदेशों के छोटे अंश केवल तभी जोड़े जाते हैं जब ऑपरेटर उन्हें चालू करता है (डिफ़ॉल्ट रूप से बंद)। वे एक सुविधा संकेत हैं, सबूत नहीं: डिलीवरी की गारंटी नहीं है, और केवल जर्नल और उसके हस्ताक्षरित एक्सपोर्ट्स में ही यह रिकॉर्ड होता है कि क्या देखा गया था। एक वर्कस्पेस प्रॉक्सी के साथ, सूचनाएं उसी मार्ग का उपयोग करती हैं; जिन सेवाओं का उपयोग इसे नहीं कर सकते, और MTProxy मार्गों को, अस्वीकार कर दिया जाता है।

घटना का मानकीकरण#

हैश इनपुट में ठीक-ठीक ये फ़ील्ड्स शामिल हैं:

seq, observed_at, source_at, kind, chat_id, message_id, actor_id, payload, previous_hash

पाइथन-संगत JSON का उपयोग करके सीरियलाइज़ करें, जिसमें UTF-8, क्रमबद्ध ऑब्जेक्ट कुंजियाँ, कोई ASCII एस्केपिंग नहीं, कोई तुच्छ व्हाइटस्पेस नहीं, और कोई NaN/अनंत नहीं:

json.dumps(value, ensure_ascii=False, sort_keys=True,
           separators=(",", ":"), allow_nan=False).encode("utf-8")

उन बाइट्स का SHA-256 हैश इवेंट हैश बन जाता है। हस्ताक्षर 32 कच्चे हैश बाइट्स पर Ed25519 का उपयोग करके बनाया जाता है, और फिर उसे base64 में एन्कोड किया जाता है। पहला previous_hash 64 शून्य होता है। क्रम संख्या 1 से शुरू होती हैं और 1 से बढ़ती हैं। सभी घटनाएँ, परिचालन घटनाओं सहित, एक ही श्रृंखला साझा करती हैं। डुप्लिकेट-डिलीवरी दमन नहीं है: दोहराए गए अवलोकन अलग-अलग रसीदें हैं, न कि अलग-अलग टेलीग्राम क्रियाओं का दावा।

कच्ची टेलीग्राम तिथियाँ ISO स्ट्रिंग्स होती हैं; बाइनरी फ़ील्ड्स ऑब्जेक्ट्स बन जाते हैं जिनमें bytes_base64 होता है। जब प्रदान किया जाता है, तो संदेश का टेक्स्ट, इकाइयाँ, मीडिया वर्णनकर्ता, उत्तर मेटाडेटा, प्रतिक्रियाएँ, और सेवा क्रियाएँ कच्चे संदेश मेटाडेटा में बरकरार रखी जाती हैं।

observed_at कलेक्टर की UTC वॉल क्लॉक है। source_at उपलब्ध होने पर टेलीग्राम द्वारा प्रदान की गई तारीख है। डिलीशन सूचनाएं सटीक डिलीशन समय प्रदान नहीं करती हैं, इसलिए source_at शून्य रहता है। ट्रांसपोर्ट रिसेप्शन क्रम का स्रोत-घटना क्रम के साथ मेल होना आवश्यक नहीं है। इतिहास स्नैपशॉट पुराने स्रोत दिनांकों का उपयोग करते हैं लेकिन वर्तमान अवलोकन समयों का उपयोग करते हैं।

अभिनेता अर्थशास्त्र#

message.new actor_id संदेश प्रेषक है। message.edited का कोई अनुमानित संपादक नहीं है; payload.sender_id देखे गए संदेश के प्रेषक को रिकॉर्ड करता है। मिटान वाला actor_id null बना रहता है। सदस्यता सेवा संदेश प्रेषक और क्रिया प्रकार को बनाए रखते हैं, बिना हर हटाने को स्वैच्छिक प्रस्थान में बदले। कच्चे प्रतिभागी अपडेट्स दिए गए actor_id को बनाए रखते हैं। प्रतिक्रिया स्नैपशॉट्स एक परिवर्तन कर्ता का आविष्कार नहीं करते हैं।

निजी चैट और साधारण समूहों के लिए हटाने की सूचनाओं में केवल संदेश आईडी होते हैं। वे चैट एक ही खाते-व्यापी आईडी अनुक्रम साझा करते हैं, इसलिए एक आईडी इस खाते के एक ही संदेश की पहचान करती है। जब उस आईडी वाला कोई संदेश पहले इस जर्नल में सहेजा गया था, तो उस चैट में उसे message.deleted के रूप में रिकॉर्ड किया जाता है, जिसमें payload.chat_resolution को मेथड के रूप में नामित किया गया है। जिन आईडी को कभी सहेजा नहीं गया है, उन्हें बिना किसी chat_id के deletion.unscoped के रूप में रखा जाता है; कुछ भी अनुमान नहीं लगाया जाता है। चैनल और सुपरग्रुप प्रति चैट संदेशों की गिनती करते हैं और इस तरह कभी भी मेल नहीं खाते। जब हटाया गया संदेश देखे गए खाते द्वारा भेजा गया था, तो payload.deleted_message_was_outgoing true होता है; हटाने वाले की जानकारी अभी भी प्रदान नहीं की जाती है।

कवरेज: निरंतरता, अंतराल और अवलोकित नहीं की गई आईडी#

प्रत्येक हस्ताक्षरित ZIP में coverage.json होता है, HTML रिपोर्ट उसी सारांश के साथ खुलती है, और verify.py फ़ाइल पर भरोसा करने के बजाय इसे events.jsonl से पुनः गणना करता है:

• X से Y तक लगातार अवलोकन। एक अवधि observation.started के साथ शुरू होती है और एक विराम, एक रुकावट, टेलीग्राम कनेक्शन खो जाने, साइन-आउट, बिना सुव्यवस्थित समाप्ति के प्रक्रिया के शुरू होने, या अवलोकन के दौरान बिना किसी रिकॉर्ड के तीन मिनट से अधिक समय तक चलने पर समाप्त होती है (हर मिनट हार्टबीट लिखी जाती है, इसलिए खामोशी का मतलब है कि प्रक्रिया रुक गई, ठप हो गई या कंप्यूटर स्लीप मोड में चला गया)। जब पैरामीटर में हार्टबीट अंतराल बदला जाता है, तो प्रत्येक हार्टबीट इसे रिकॉर्ड करती है और अनुमत खामोशी तीन अंतराल हो जाती है, जो कभी भी तीन मिनट से कम नहीं होती।
• गैप अवधि के बीच का समय और कारण सूचीबद्ध करते हैं। अंतिम रिकॉर्ड पर अभी भी खुला एक गैप not_resumed_by_last_record के रूप में चिह्नित है।
• संदेश आईडी अवलोकित नहीं हुए। चैनलों और सुपरग्रुप्स के लिए, जो प्रति चैट संदेशों की संख्या दर्शाते हैं, अवलोकित आईडी के बीच की आईडी को श्रेणियों के रूप में सूचीबद्ध किया जाता है। इन्हें अवलोकित नहीं के रूप में रिपोर्ट किया जाता है — हटाए गए, कभी डिलीवर नहीं हुए, या सहेजे गए इतिहास के बाहर — कभी भी हटाए गए के रूप में नहीं। निजी चैट और साधारण समूह एक खाता-व्यापी अनुक्रम साझा करते हैं, इसलिए वहाँ के अंतराल का कोई मतलब नहीं होता है और उन्हें सूचीबद्ध नहीं किया जाता है।
• चैट-स्तर के गैप नोटिस (उदाहरण के लिए टेलीग्राम द्वारा एक चैनल में अंतर की रिकवरी के लिए अनुरोध) को नोट्स के रूप में गिना जाता है; ये वैश्विक कवरेज में बाधा नहीं डालते।

कवरेज यह वर्णन करता है कि इस कलेक्टर ने क्या रिकॉर्ड किया है। यह इस बात का प्रमाण नहीं है कि टेलीग्राम ने एक निरंतर अवधि के दौरान हर अपडेट प्रदान किया।

निर्माता#

सबूत ZIPs, चैट एक्सपोर्ट, विटनेस जर्नल और लोगों के प्रोफ़ाइल फ़ाइलों के विवरण का हस्ताक्षरित मैनिफेस्ट producer को शामिल करता है: सॉफ़्टवेयर, संस्करण, प्रोजेक्ट (PhishDestroy), होमपेज और स्रोत रिपॉजिटरी। HTML रिपोर्ट उसी लाइन को दिखाती है, और verify.py इसे सत्यापित किए गए हिस्से के रूप में प्रिंट करता है। इस क्षेत्र के अस्तित्व में आने से पहले बनाए गए आर्काइव्स, पहले की तरह सत्यापित करते हैं और इन्हें निर्माता का नाम न बताने के रूप में रिपोर्ट किया जाता है।

लोगों के प्रोफ़ाइल#

एक प्रोफ़ाइल फ़ाइल (tgwitness-dossier-v1, JSON) एक चैट के लिए जर्नल में पहले से मौजूद रिकॉर्ड के अनुरोध पर बनाई जाती है; टेलीग्राम से कुछ भी प्राप्त नहीं किया जाता है और प्रोफ़ाइल की सामग्री कभी भी जर्नल में नहीं लिखी जाती है (प्रोफ़ाइल को चालू और बंद करना dossier.changed के रूप में रिकॉर्ड किया जाता है)। सहेजे गए संदेश वाले प्रत्येक व्यक्ति के लिए यह नाम और उपयोगकर्ता नाम का इतिहास, टेलीग्राम फ़्लैग (बॉट, घोटाला, नकली, प्रीमियम, सत्यापित, प्रतिबंधित, हटाया गया) जैसा कि सहेजने के समय देखा गया था, प्रोफ़ाइल फ़ोटो आईडी, समान अवतारों वाले स्थानीय अवतार कैश से अवतार का SHA-256 और पर्सेप्चुअल हैश (pHash, imagehash.phash के साथ संगत), गतिविधि (पहला और आखिरी संदेश, काउंट, संपादित और हटाए गए शेयर, UTC घंटे के अनुसार संदेश), कौन किसको जवाब दे रहा है, अन्य चैट इस जर्नल में जहाँ उस व्यक्ति ने लिखा, और वॉलेट (BTC, EVM, TRON, TON, LTC, DOGE, XMR, SOL; Base58Check पते चेकसम-प्रमाणित हैं), फोन नंबर, उपयोगकर्ता नाम और लिंक, जिसमें टेक्स्ट के पीछे छिपे लिंक भी शामिल हैं, का उल्लेख किया।

प्रत्येक तथ्य उस जर्नल रिकॉर्ड (seq) को सूचीबद्ध करता है जिससे यह आता है, और record_hashes प्रत्येक संदर्भित रिकॉर्ड का हैश रखता है। यह कथन वर्कस्पेस कुंजी के साथ हस्ताक्षरित है:

python verify.py tgwitness-dossier-CHAT.json --fingerprint TRUSTED_SHA256 --evidence tgwitness-evidence.zip

हस्ताक्षर की जांच करता है, स्वयं साक्ष्य निर्यात (हस्ताक्षर, हैश चेन और फ़ाइलें) को सत्यापित करता है और यह कि प्रत्येक संदर्भित रिकॉर्ड उसी कार्यक्षेत्र के उस निर्यात में अपरिवर्तित मौजूद है। अवतार हैश को स्थानीय कैश से आने वाला लेबल किया जाता है (न कि जर्नल रिकॉर्ड से)। उल्लेख पैटर्न मिलान होते हैं — जांच के लिए सुराग, न कि सत्यापित तथ्य। प्रोफ़ाइल हर चैट के लिए चालू की जाती हैं, इन्हें पासवर्ड के साथ AES-256 ZIP के रूप में एक्सपोर्ट किया जा सकता है, और जब इन्हें बंद किया जाता है या चैट को स्रोतों से हटा दिया जाता है तो इन्हें हटा दिया जाता है।

स्वतंत्र गवाह#

एक गवाह जर्नल (tgwitness-witness-v1) और इसकी चैनल पोस्ट्स की जाँच verify.py --witness … --channel … के साथ एक साक्ष्य एक्सपोर्ट से की जाती है; स्वतंत्र गवाह देखें।

मैनिफेस्ट और चेकपॉइंट्स#

manifest.json में स्वयं manifest.json और manifest.sig को छोड़कर हर कंटेंट सदस्य का फ़ॉर्मेट, एक्सपोर्ट समय, पब्लिक की, फ़िंगरप्रिंट, जर्नल लंबाई, हेड हैश, स्कोप, प्रोड्यूसर, सीमाएँ, और SHA-256 शामिल होता है। manifest.sig कैनोनिकल मैनिफ़ेस्ट JSON पर बेस64 Ed25519 सिग्नेचर है। सत्यापनकर्ता अप्रत्याशित/गैर-मौजूद सदस्यों, डुप्लिकेट नामों, दूषित फ़ाइलों, टूटे हुए अनुक्रम/श्रृंखला, अमान्य हस्ताक्षरों, और प्रदान किए गए चेकपॉइंट के साथ असंगति को अस्वीकार कर देता है। यह कभी भी आर्काइव पथों को निकालता नहीं है। यह कुल घोषित बिना-संपीडित आकार को 4 GiB तक सीमित करता है; --max-gib N, बढ़ाई गई पैरामीटर सीमा के साथ बनाए गए बड़े आर्काइव की अनुमति देता है।

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

एक चेकपॉइंट सार्वजनिक कुंजी, जर्नल की लंबाई, हेड हैश और निर्माण समय वाले एक कथन पर हस्ताक्षर करता है। सत्यापनकर्ता यह जांच सकता है कि बाद के आर्काइव में वही प्रीफ़िक्स है। किसी विवादास्पद परिवर्तन से पहले कलेक्टर के बाहर एक चेकपॉइंट बनाए रखें: यदि कोई हमलावर आर्काइव और चेकपॉइंट दोनों को नियंत्रित कर रहा है, तो वह दोनों को बदल सकता है।

एक अनपिन की हुई कुंजी से प्राप्त एक वैध हस्ताक्षर केवल आंतरिक संगति स्थापित करता है। यहां तक कि एक पिन की हुई कुंजी भी स्रोत सामग्री की सत्यता साबित नहीं कर सकती यदि रिकॉर्डिंग से पहले कलेक्टर या कुंजी समझौता (compromised) हो गई हो। बाहरी टाइमस्टैम्पिंग और विश्वसनीय कैप्चर अलग-अलग आवश्यकताएं हैं। TgWitness स्वीकार्यता या फोरेंसिक प्रमाणीकरण का वादा नहीं करता है।

संलग्नक#

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

ZIP एक्सपोर्टर संग्रहीत मीडिया की उनके नामों के साथ पुष्टि करता है। JSONL, CSV, और HTML एक्सपोर्ट इवेंट सिग्नेचर की पुष्टि करते हैं लेकिन मीडिया बाइट्स को नहीं भेजते हैं। व्युत्पन्न रिपोर्ट सुविधा के लिए हैं; events.jsonl ही प्रामाणिक इवेंट प्रतिनिधित्व है।

टिकाऊ संग्रह और प्रक्रिया रसीदें (0.2)#

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

प्रत्येक वर्कस्पेस का अपना जर्नल और हस्ताक्षर पहचान होती है। एक process.started इवेंट में रन आईडी, स्थानीय घड़ियाँ, निर्भरता संस्करण, स्रोत-फ़ाइल हैश, प्रारंभिक खाता/दायरा, और कैप्चर सेटिंग्स शामिल होती हैं। हार्टबीट्स में रन आईडी, मोनोटोनिक समय, और कतार की स्थिति शामिल होती है। प्रोसेस रसीद को एक अलग से हस्ताक्षरित बयान के रूप में भी डाउनलोड किया जा सकता है। फ़ाइल माप स्व-रिपोर्टेड हैं और वे विश्वसनीय हार्डवेयर प्रमाणीकरण नहीं हैं।

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

रीस्टार्ट के बाद, सहेजी गई टेलीग्राम अपडेट स्थिति को फिर से शुरू किया जाता है (catch_up_from में observation.started) और छूटी हुई अपडेट्स का अनुरोध किया जाता है। एक आवधिक पुनः जाँच छूटे हुए संदेशों के लिए message.recovered और तब message.missing_on_recheck रिकॉर्ड करती है जब टेलीग्राम अब कोई सहेजा हुआ संदेश वापस नहीं करता; बाद वाला कोई हटाने की सूचना नहीं है और न ही इसमें कोई हटाने वाला या समय बताया गया है।

ऑफ़-साइट कॉपी और पुनर्स्थापना (S3)#

ऑफ़-साइट कॉपी (एक्सपोर्ट्स, डिफ़ॉल्ट रूप से बंद) जर्नल सेगमेंट, संरक्षित फ़ाइलें, चेकपॉइंट्स को उनके टाइमस्टैम्प के साथ और पूरी चैट एक्सपोर्ट्स को S3-संगत स्टोरेज में अपलोड करती है, जिसे AES-256-GCM के साथ एन्क्रिप्ट किया गया है अपलोड से पहले S3-संगत स्टोरेज में, वर्कस्पेस वॉल्ट में रखी गई कुंजी के तहत AES-256-GCM से एन्क्रिप्ट किया जाता है; ऑब्जेक्ट लॉक प्रतिधारण लागू होता है जब बकेट इसका समर्थन करता है। डाउनलोड की गई कुंजी के बिना कॉपी को पढ़ा नहीं जा सकता। python -m tgwitness.replica restore --key-file KEY.json --out DIR के साथ पुनर्स्थापित करें और सत्यापित करें।

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

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

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

स्ट्रीमिंग निर्यात स्नैपशॉट्स#

स्ट्रीमिंग एक्सपोर्ट एक स्थिर SQLite रीड स्नैपशॉट का उपयोग करते हैं। जब डाउनलोड पूरा हो जाता है, तो इसका हेड वर्तमान लाइव जर्नल से पुराना हो सकता है। उस स्नैपशॉट के बाद बनाया गया एक चेकपॉइंट सही ढंग से रिपोर्ट कर सकता है कि आर्काइव छोटा है; तुलना एक्सपोर्ट किए गए प्रीफिक्स पर या उससे पहले के चेकपॉइंट से करें, न कि किसी मनमाने बाद के चेकपॉइंट से।

RFC 3161 तैयारी और प्रतिक्रिया सत्यापन (0.2)#

सबूत मोड (डिफ़ॉल्ट रूप से बंद) प्रत्येक हस्ताक्षरित चेकपॉइंट का केवल SHA-256 सूचीबद्ध RFC 3161 प्राधिकरणों और OpenTimestamps कैलेंडर को, वर्कस्पेस मार्ग के माध्यम से भेजता है और कभी भी MTProxy के माध्यम से नहीं। उत्तर checkpoints/anchors/ में रखे जाते हैं, निर्यात किए जाते हैं, और verify.py द्वारा जाँचे जाते हैं (--tsa-ca TSA हस्ताक्षर की जाँच करता है; OpenTimestamps प्रमाणों की पुष्टि ots upgrade और ots verify से करें)।

पैनल एक अनुरोध संग्रह तैयार करता है जिसमें मानक checkpoint.json बाइट्स, एक SHA-256 संदेश छाप और timestamp.tsq में यादृच्छिक नॉन्स, चेकसम और निर्देश शामिल होते हैं। कोई नेटवर्क अनुरोध नहीं किया जाता है। तैयारी एक विश्वसनीय टाइमस्टैम्प नहीं है।

python -m tgwitness.anchor verify दो बार OpenSSL ts को कॉल करता है: एक बार चेकपॉइंट बाइट्स के खिलाफ और एक बार मूल अनुरोध के खिलाफ। एक विश्वसनीय CA फ़ाइल की स्पष्ट रूप से आवश्यकता होती है; शामिल किए गए प्रमाणपत्रों पर स्वचालित रूप से भरोसा नहीं किया जाता है। CLI पर अनुरोध जाँच वैकल्पिक है, इसलिए नॉनस की जाँच करने के लिए --request को बनाए रखें और प्रदान करें। परिणाम बताता है कि क्या इसकी जाँच की गई थी। कलेक्टर चेकपॉइंट हस्ताक्षर और जर्नल को अभी भी विश्वसनीय कलेक्टर फिंगरप्रिंट के साथ अलग से सत्यापित किया जाना चाहिए।

वर्तमान सत्यापनकर्ता रद्दीकरण की जानकारी प्राप्त नहीं करता है या प्रमाणपत्र की समाप्ति के बाद दीर्घकालिक संग्रहण सत्यापन लागू नहीं करता है। सफल हस्ताक्षर सत्यापन को एक योग्य टाइमस्टैम्प या कानूनी स्वीकार्यता के साथ समान न मानें। विकास के दौरान किसी वास्तविक स्वतंत्र TSA से संपर्क नहीं किया गया है। प्रक्रिया देखें।