شواہد کا فارمیٹ

ایک مشاہدہ نتیجہ نہیں ہوتا۔ بھیجنے والے کی شناخت حقیقی دنیا کی شناخت نہیں ہوتی۔ خاتمہ: اکاؤنٹ میں دکھائی دینے والی سروس اپ ڈیٹ ہی ماخذ ہے؛ ٹیلیگرام ان محفوظ شدہ ریکارڈز کو تیسرے فریق کے تفتیش کار کے لیے کرپٹوگرافک طور پر دستخط نہیں کرتا۔

دستخط شدہ کیا ہے#

جمع کرنے والا ہر ایکسپورٹ فارمیٹ تیار کرنے سے پہلے جرنل کے دستخطات کی تصدیق کرتا ہے۔ یہ ماخذ کی جانچ علیحدہ سے ڈاؤن لوڈ کی گئی 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 ZIP فائل میں رکھا جا سکتا ہے۔ یہ پاس ورڈ صرف رازداری کا تحفظ کرتا ہے اور محفوظ نہیں کیا جاتا؛ وصول کنندہ آرکائیو کو نکالتا ہے اور اندر موجود دستخط شدہ ایکسپورٹ کی تصدیق کرتا ہے، جو کہ تبدیل نہیں ہوتا۔
   6. اگر آزاد وقتی لنگر اندازی درکار ہو تو RFC 3161 کے طریقہ کار پر عمل کریں اور درخواست، چیک پوائنٹ، قابل اعتماد CA کی معلومات، اور تصدیق شدہ اتھارٹی کے جواب کو محفوظ رکھیں۔ صرف درخواست تیار کرنے سے ٹائم اسٹیمپ حاصل نہیں ہوتا۔

کامیاب تصدیق معتبر کلیکٹر کی اور محفوظ شدہ حد کے حوالے سے سالمیت قائم کرتی ہے۔ ماخذ کی صداقت، مکمل ٹیلیگرام ترسیل، معتبر وقت، اور قانونی قابلِ قبولیت کے لیے الگ ثبوت درکار ہیں۔ اس ورژن نے ابھی تک لائیو ٹیلیگرام کی اہلیت یا ایک آزاد فارنزک/سیکیورٹی جائزہ مکمل نہیں کیا ہے۔

ایک نقل شدہ کلیکٹر کلید ایک من گھڑا ہوا متبادل جریدہ دستخط کر سکتی ہے۔ ایک آزادانہ طور پر محفوظ کردہ چیک پوائنٹ یا گواہی ریکارڈ کے خلاف تصدیق پہلے کے تبدیل شدہ پری فکس کا پتہ لگاتی ہے؛ صرف دستخط کی تصدیق ایسا نہیں کر سکتی۔ ایک گواہ اس چیز کو درست کرتا ہے جو کلیکٹر نے پیش کی، لہٰذا یہ آزادانہ طور پر ان ریکارڈز کی سچائی کو ثابت نہیں کرتا جو ان کے پہلے بیرونی چیک پوائنٹ سے پہلے بنائے گئے تھے۔ کلاؤڈ ڈیپلائمنٹ رپورٹس کنفیگریشن اور کلیکٹر کی رپورٹ کردہ پیمائشوں کی جانچ کرتی ہیں؛ وہ یہ ثابت نہیں کرتیں کہ بوٹ اسٹراپ کے دوران نجی کلید کبھی کاپی نہیں کی گئی تھی۔

ایپرائز کے ذریعے بھیجی گئی اطلاعات میں ورک اسپیس اور چیٹ کے نام اور تعداد شامل ہوتی ہے؛ حذف شدہ اور ترمیم شدہ پیغامات کے مختصر اقتباسات صرف اس وقت شامل کیے جاتے ہیں جب آپریٹر انہیں آن کرے (ڈیفالٹ طور پر بند)۔ یہ ایک سہولت کا سگنل ہیں، ثبوت نہیں: ترسیل کی ضمانت نہیں دی جاتی، اور صرف جرنل اور اس کے دستخط شدہ ایکسپورٹس ہی اس بات کو ریکارڈ کرتے ہیں کہ کیا مشاہدہ کیا گیا تھا۔ ورک اسپیس پراکسی کے ساتھ، نوٹیفیکیشنز اسی راستے کا استعمال کرتی ہیں؛ جن سروسز کو یہ استعمال کرنے کی اجازت نہیں، اور MTProxy راستوں کو، انکار کر دیا جاتا ہے۔

واقعات کی معیاری شکل میں ترتیب#

ہیش ان پٹ میں بالکل یہی فیلڈز شامل ہیں:

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

Python کے مطابقت رکھنے والے JSON کے ساتھ UTF-8 استعمال کرتے ہوئے سیریلائز کریں، ترتیب شدہ آبجیکٹ کیز کے ساتھ، ASCII ایسکیپنگ کے بغیر، غیر اہم وائٹسپیس کے بغیر، اور NaN/infinity کے بغیر:

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 null رہتا ہے۔ ٹرانسپورٹ وصولی کا ترتیب ضروری نہیں کہ ماخذ-واقعے کے ترتیب کے مطابق ہو۔ ہسٹری کے سنپ شاٹس پرانی ماخذ تاریخیں استعمال کرتے ہیں لیکن موجودہ مشاہداتی اوقات استعمال کرتے ہیں۔

ایکٹر کے معنی#

message.new actor_id پیغام بھیجنے والا ہے۔ message.edited کا کوئی اندازہ شدہ مدیر نہیں ہوتا؛ payload.sender_id مشاہدہ شدہ پیغام کے بھیجنے والے کو ریکارڈ کرتا ہے۔ مٹانے والا actor_id null رہتا ہے۔ ممبرشپ سروس کے پیغامات بھیجنے والے اور عمل کی قسم کو برقرار رکھتے ہیں، بغیر ہر ہٹانے کو رضاکارانہ رخصت میں تبدیل کیے۔ خام شرکاء کی تازہ کاریاں فراہم کردہ actor_id کو برقرار رکھتی ہیں۔ ردعمل کے سنپ شاٹس تبدیلی کرنے والے ایکٹر کو ایجاد نہیں کرتے۔

نجی چیٹس اور عام گروپس کے لیے حذف ہونے کی اطلاعات میں صرف میسج آئی ڈیز شامل ہوتی ہیں۔ یہ چیٹس ایک اکاؤنٹ بھر میں ایک ہی آئی ڈی کے تسلسل کا اشتراک کرتی ہیں، لہٰذا ایک آئی ڈی اس اکاؤنٹ کے ایک واحد پیغام کی شناخت کرتی ہے۔ جب اس آئی ڈی والا پیغام پہلے اس جرنل میں محفوظ کیا گیا تھا، تو حذف کرنے کو اس چیٹ میں `message.deleted` کے طور پر ریکارڈ کیا جاتا ہے، جس میں `payload.chat_resolution` کو طریقہ کار کے نام کے طور پر استعمال کیا جاتا ہے۔ وہ آئی ڈیز جنہیں کبھی محفوظ نہیں کیا گیا، انہیں `deletion.unscoped` کے طور پر بغیر کسی `chat_id` کے رکھا جاتا ہے؛ کچھ بھی اندازہ نہیں لگایا جاتا۔ چینلز اور سپر گروپس پیغامات کو فی چیٹ گنتے ہیں اور اس طرح کبھی بھی میچ نہیں کیے جاتے۔ جب حذف شدہ پیغام مشاہدہ شدہ اکاؤنٹ کی طرف سے بھیجا گیا تھا، تو payload.deleted_message_was_outgoing سچ ہوتا ہے؛ حذف کرنے والا اب بھی فراہم نہیں کیا جاتا۔

کوریج: تسلسل، خلا اور غیر مشاہدہ شدہ آئی ڈیز#

ہر دستخط شدہ 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 میں فارمیٹ، ایکسپورٹ کا وقت، پبلک کی، فنگر پرنٹ، جرنل کی لمبائی، ہیڈ ہیش، اسکوپ، پروڈیوسر، حدود، اور ہر مواد کے رکن کا SHA-256 شامل ہوتا ہے، سوائے خود manifest.json اور manifest.sig کے۔ manifest.sig کینونکل مینیفیسٹ JSON پر base64 Ed25519 دستخط ہے۔ تصدیق کنندہ غیر متوقع/غائب ارکان، ڈپلیکیٹ نام، خراب فائلیں، ٹوٹی ہوئی ترتیب/سلسلے، غیر معتبر دستخط، اور فراہم کردہ چیک پوائنٹ کے ساتھ عدم مطابقت کو مسترد کر دیتا ہے۔ یہ کبھی بھی آرکائیو راستے (archive paths) نکالنے کی کوشش نہیں کرتا۔ یہ کل اعلان کردہ غیر کمپریسڈ سائز کو 4 GiB تک محدود کرتا ہے؛ --max-gib N بڑھائی گئی پیرامیٹرز حد (Parameters limit) کے ساتھ بنائے گئے بڑے آرکائیوز کی اجازت دیتا ہے۔

ایک معتبر چیک آؤٹ یا جائزہ شدہ آزاد نقل سے ویریفائر کوڈ حاصل کریں۔ ایک ویریفائر جو غیر معتبر آرکائیو کے اندر ہو، وہ اس آرکائیو کے مصنف کی فراہم کردہ قابلِ عمل مواد ہے؛ اس کی موجودگی پورٹیبلٹی کی سہولت ہے، نہ کہ ایک آزاد قابلِ اعتماد لنگر۔

ایک چیک پوائنٹ ایک بیان پر دستخط کرتا ہے جس میں پبلک کی، جرنل کی لمبائی، ہیڈ ہیش، اور تخلیق کا وقت شامل ہوتا ہے۔ تصدیق کنندہ یہ چیک کر سکتا ہے کہ بعد کا آرکائیو اسی پری فکس پر مشتمل ہے۔ کسی متنازع تبدیلی سے پہلے کلیکٹر کے باہر ایک چیک پوائنٹ برقرار رکھیں: ایک حملہ آور جو آرکائیو اور چیک پوائنٹ دونوں کو کنٹرول کرتا ہو، دونوں کو تبدیل کر سکتا ہے۔

ایک غیر پن کیے گئے کلید سے حاصل شدہ درست دستخط صرف اندرونی مطابقت قائم کرتا ہے۔ یہاں تک کہ ایک پن کی گئی کلید بھی ماخذ کے مواد کی صداقت ثابت نہیں کر سکتی اگر جمع کرنے والا یا کلید ریکارڈنگ سے پہلے سمجھوتے کا شکار ہو گئی ہو۔ بیرونی ٹائم اسٹیمپنگ اور معتبر کیپچر الگ الگ ضروریات ہیں۔ TgWitness قابلِ قبولیت یا عدالتی تصدیق کا وعدہ نہیں کرتا۔

منسلکات#

فائلیں media/ کے تحت SHA-256 کے ذریعے پتے جاتے ہیں۔ media.saved واقعہ ایک ہیش اور بائٹ کی لمبائی کو ایک مخصوص پیغام کے واقعے سے منسلک کرتا ہے۔ خام فائل کے نام میٹا ڈیٹا ہیں، کبھی بھی مقامی راستے نہیں۔ میڈیا بائٹس غیر ہم آہنگ (asynchronously) ڈاؤن لوڈ کیے جاتے ہیں، لہٰذا فوری حذف کرنے سے ان کی گرفتاری (capture) رک سکتی ہے۔ غیر فعال شدہ کلیکشن، حد سے زیادہ/نامعلوم سائز والی فائلیں، ڈاؤن لوڈ کی ناکامیاں، اور منقطع شدہ ڈاؤن لوڈز نتائج کے طور پر ظاہر ہوتے ہیں۔ پراسیس کے کریش ہونے سے غیر متعلقہ (unreferenced) جزوی فائلیں رہ سکتی ہیں؛ یہ ایکسپورٹس میں شامل نہیں ہوتیں۔

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 کے ساتھ انکرپٹ کیے جاتے ہیں، اپ لوڈ سے پہلے ورک اسپیس والٹ میں محفوظ کی گئی کلید کے تحت؛ جب بکیٹ اس کی حمایت کرتا ہے تو آبجیکٹ لاک ریٹینشن لاگو ہوتی ہے۔ ڈاؤن لوڈ کی گئی کلید کے بغیر کاپی پڑھی نہیں جا سکتی۔ بحال کریں اور تصدیق کریں 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 پر درخواست کی جانچ اختیاری ہے، لہٰذا نانسی (nonce) کی جانچ کے لیے --request استعمال کریں۔ نتیجہ بتاتا ہے کہ آیا اسے چیک کیا گیا تھا۔ کلیکٹر کے چیک پوائنٹ کے دستخط اور جرنل کو اب بھی قابلِ اعتماد کلیکٹر فنگر پرنٹ کے ساتھ علیحدہ طور پر تصدیق کرنا ضروری ہے۔

موجودہ تصدیق کنندہ منسوخی کی معلومات حاصل نہیں کرتا اور سرٹیفیکیٹ کی میعاد ختم ہونے کے بعد طویل مدتی آرکائیول توثیق نافذ نہیں کرتا۔ کامیاب دستخط کی تصدیق کو معیاری ٹائم اسٹیمپ یا قانونی قابلِ قبولیت کے برابر نہ سمجھیں۔ ترقی کے دوران کسی حقیقی آزاد TSA سے رابطہ نہیں کیا گیا۔ طریقہ کار دیکھیں۔