# فرمت مدرک

Canonical page: https://phishdestroy.github.io/TgWitness/fa/docs/reference/evidence/

محتویات فایل ZIP امضا شده، انواع سوابق، رسیدهای فرایند، پروفایل افراد، نسخه‌های خارج از محل و تأیید آفلاین.

یک مشاهده، یک نتیجه‌گیری نیست. شناسه فرستنده، یک هویت واقعی در دنیای بیرون نیست. منبع، به‌روزرسانی سرویس قابل مشاهده برای حساب کاربری است؛ تلگرام این سوابق ذخیره‌شده را برای یک محقق شخص ثالث به صورت رمزنگاری‌شده امضا نمی‌کند.

## امضا شده چیست

| مطالب | حفاظت | چه مواردی را باید حفظ کرد |
| --- | --- | --- |
| هر مشاهدهٔ دفترچه، از جمله رویدادهای عملیاتی | زنجیره SHA-256 و امضای Ed25519 برای هر رویداد | امضای اصلی `events.jsonl`، اثر انگشت کلید مورد اعتماد، و یک نقطه کنترل حفظ‌شده |
| محتویات فایل ZIP شواهد | `manifest.sig` مانیفست کانونیکال را امضا می‌کند که هش فایل‌های محتوا را فهرست می‌کند | فایل فشردهٔ کامل، شامل مانیفست و امضا |
| پیوست‌های نگهداری‌شده | SHA-256 و شمارش بایت در یک رویداد امضا‌شده با `media.saved`؛ هش فایل در مانیفست ZIP امضا‌شده | بایت‌های اصلی درون فایل ZIP تأییدشده |
| نقطهٔ کنترل | امضای Ed25519 بر طول دفترچه، هش سر، کلید عمومی و زمان ایجاد | یک نسخهٔ مستقل که پیش از تغییر مورد مناقشه نگهداری شده است |
| دریافت رسید | اندازه‌گیری‌های جمع‌آوری‌شده که به‌طور جداگانه امضا شده‌اند؛ همچنین در یک رویداد امضا‌شده با کلید `process.started` گنجانده شده‌اند | رسید و دفترچه مربوطه؛ اندازه‌ها به‌صورت خوداظهاری گزارش شده‌اند |
| CSV یا HTML مستقل | امضای رمزنگاری مستقل وجود ندارد؛ هش‌های رویداد به‌تنهایی کافی نیستند | برای بررسی یکپارچگی، از متن دقیق داخل فایل ZIP تأییدشده استفاده کنید. |
| اسکرین‌شات‌ها، خروجی‌های چاپی یا PDF تولیدشده توسط مرورگر | امضای TgWitness روی مشتق وجود ندارد | پکیج اصلی تأییدشده را حفظ کنید و نحوهٔ ساخت نسخهٔ مشتق را مستندسازی کنید |

جمع‌آورنده پیش از تولید هر فرمت خروجی، امضاهای دفترچه را تأیید می‌کند. این بررسی منبع، امضایی برای یک فایل CSV یا HTML که به طور جداگانه دانلود شده است، ایجاد نمی‌کند. به همین ترتیب، یک امضای رویداد JSONL معتبر، بایت‌های پیوست را فراهم نمی‌کند و به طور مستقل تأیید نمی‌کند که کل دفترچه مشاهده‌شده ارائه شده است.

## واگذاری تحقیقات

1. شماره پرونده، اپراتور، شناسه عددی حساب تلگرام، منابع منتخب، سیاست جمع‌آوری و دوره جمع‌آوری را در یادداشت‌های پرونده خود ثبت کنید. TgWitness مشاهدات را حفظ می‌کند؛ تخصیص پرونده و سوابق بازداشت خارج از برنامه مدیریت می‌شوند. پیکربندی جمع‌آوری مورد نظر را با [رویه پذیرش زنده](https://github.com/phishdestroy/TgWitness/blob/main/docs/internal/LIVE_ACCEPTANCE.md) مشخص کنید.
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).
   ```

   1. SHA-256 بایگانی، مرز خروجی، تاریخ انتقال، فرستنده و گیرنده را در سوابق نگهداری خود ثبت کنید. بسته اصلی را دست‌نخورده نگه دارید و روی نسخه‌ها کار کنید. فایل‌های مدرک را به اشتراک بگذارید، نه دایرکتوری داده‌های خصوصی برنامه را، که شامل جلسات حساب کاربری و اسرار امضا نیز می‌شود. برای انتقال، می‌توان خروجی را در یک فایل فشرده ZIP با رمزگذاری AES-256 و محافظت با رمز عبور قرار داد. این رمز عبور فقط محرمانگی را حفظ می‌کند و ذخیره نمی‌شود؛ دریافت‌کننده، فایل فشرده را استخراج کرده و خروجی امضا شده داخل آن را که بدون تغییر است، تأیید می‌کند.
   2. اگر لنگراندازی زمانی مستقل مورد نیاز است، [رویه RFC 3161](https://phishdestroy.github.io/TgWitness/fa/docs/reference/timestamp/) را دنبال کنید و درخواست، نقطه کنترل، اطلاعات 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 آن بایت‌ها به‌دست می‌آید. امضا، امضای Ed25519 بر روی ۳۲ بایت خام هَش است که سپس به کد base64 تبدیل می‌شود. اولین previous_hash شامل ۶۴ صفر است. اعداد توالی از ۱ شروع شده و به اندازه ۱ افزایش می‌یابند. تمام رویدادها، از جمله رویدادهای عملیاتی، یک زنجیره مشترک دارند. هیچ سرکوب ارسال تکراری وجود ندارد: مشاهدات مکرر رسیدهای متمایزی هستند، نه ادعایی مبنی بر اقدامات متمایز تلگرام.

تاریخ‌های خام تلگرام رشته‌های ISO هستند؛ فیلدهای باینری به اشیایی حاوی bytes_base64 تبدیل می‌شوند. متن پیام، انتیت‌ها، توصیف‌کننده‌های رسانه، متادیتای پاسخ، واکنش‌ها و اقدامات سرویس، در صورت ارائه، در متادیتای خام پیام حفظ می‌شوند.

observed_at ساعت دیواری UTC گردآورنده است. source_at تاریخ تلگرامی ارائه‌شده در صورت موجود بودن است. اعلان‌های حذف، زمان دقیق حذف را ارائه نمی‌دهند، بنابراین source_at نامشخص باقی می‌ماند. ترتیب دریافت در انتقال لزوماً با ترتیب رویداد منبع مطابقت ندارد. اسنپ‌شات‌های تاریخچه از تاریخ‌های منبع قدیمی‌تر اما زمان‌های مشاهده فعلی استفاده می‌کنند.

## سمانتیک بازیگر

actor_id در message.new، فرستنده پیام است. message.edited ویرایشگر مشخصی ندارد؛ payload.sender_id فرستنده پیام مشاهده‌شده را ثبت می‌کند. حذف actor_id همچنان null باقی می‌ماند. پیام‌های سرویس عضویت، فرستنده و نوع اقدام را حفظ می‌کنند، بدون اینکه هر حذف را به یک ترک داوطلبانه تبدیل کنند. به‌روزرسانی‌های خام شرکت‌کننده، actor_id را همان‌طور که ارائه شده حفظ می‌کنند. اسنپ‌شات‌های واکنش، یک عامل تغییر را ابداع نمی‌کنند.

اعلان‌های حذف برای چت‌های خصوصی و گروه‌های عادی فقط شامل شناسه پیام‌ها هستند. این چت‌ها یک توالی شناسه یکپارچه در سطح حساب را به اشتراک می‌گذارند، بنابراین یک شناسه، یک پیام واحد از این حساب را شناسایی می‌کند. زمانی که پیامی با آن شناسه قبلاً در این دفترچه ثبت شده باشد، حذف در آن چت به عنوان message.deleted با payload.chat_resolution به عنوان نام متد ثبت می‌شود. شناسه‌هایی که هرگز ذخیره نشده‌اند به صورت deletion.unscoped بدون chat_id نگه داشته می‌شوند؛ هیچ چیز حدس زده نمی‌شود. کانال‌ها و ابرگروه‌ها پیام‌ها را در هر چت شمارش می‌کنند و هرگز به این شکل مطابقت داده نمی‌شوند. هنگامی که پیام حذف‌شده توسط حساب مشاهده‌شده ارسال شده باشد، payload.deleted_message_was_outgoing مقدار true را دارد؛ اما هویت حذفی هنوز مشخص نمی‌شود.

## پوشش: پیوستگی، فواصل و شناسه‌های نادیده

هر فایل ZIP امضا شده حاوی `coverage.json` است، گزارش HTML با همان خلاصه باز می‌شود و `verify.py` آن را از روی `events.jsonl` بازحساب می‌کند به جای اینکه به فایل اعتماد کند:

- **به‌طور مداوم از X تا Y مشاهده می‌شود.** یک دوره با `observation.started` آغاز می‌شود و در یک مکث، یک توقف، قطع اتصال تلگرام، خروج، شروع فرآیندی بدون توقف منظم، یا بیش از سه دقیقه بدون هیچ ثبت در حین مشاهده پایان می‌یابد (تپش‌های قلب هر دقیقه ثبت می‌شوند، بنابراین سکوت به معنای توقف فرآیند، یخ‌زدگی یا خواب رفتن کامپیوتر است). هنگامی که فاصله تپش قلب در **بخش پارامترها** تغییر کند، هر تپش آن را ثبت می‌کند و سکوت مجاز به سه بازه تبدیل می‌شود، که هرگز کمتر از سه دقیقه نخواهد بود.
- **شکاف‌ها** زمان بین دوره‌ها را همراه با دلیل فهرست می‌کنند. شکافی که در آخرین ثبت هنوز باز است با `not_resumed_by_last_record` علامت‌گذاری می‌شود.
- **شناسه پیام‌های مشاهده‌نشده ثبت نمی‌شوند.** برای کانال‌ها و ابرگروه‌ها که پیام‌ها را به ازای هر چت شماره‌گذاری می‌کنند، شناسه پیام‌های مفقود بین موارد مشاهده‌شده به صورت بازه فهرست می‌شوند. این موارد به عنوان *«مشاهده‌نشده*» گزارش می‌شوند — حذف‌شده، هرگز تحویل‌داده‌نشده، یا خارج از تاریخچه ذخیره‌شده — و هرگز به عنوان «حذف‌شده». گفتگوهای خصوصی و گروه‌های عادی از یک توالی در سراسر حساب استفاده می‌کنند، بنابراین فواصل در آنجا معنایی ندارند و فهرست نمی‌شوند.
- اخطاریه‌های شکاف در سطح گفتگو (برای مثال درخواست تلگرام برای بازیابی تفاوت در یک کانال) به‌عنوان یادداشت محسوب می‌شوند؛ آن‌ها پوشش کلی را مختل نمی‌کنند.

پوشش توضیح می‌دهد که این گردآورنده چه چیزی را ضبط کرده است. این اثباتی بر تحویل هر به‌روزرسانی توسط تلگرام در یک دوره مداوم نیست.

## تهیه‌کننده

مفاد امضاشده ZIPهای شواهد، خروجی‌های چت، دفترچه‌های شاهدی و بیانیه فایل‌های پروفایل افراد حاوی `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
```

امضا را بررسی می‌کند، خودِ خروجی مدرک را (امضا، زنجیره هش و فایل‌ها) اعتبارسنجی می‌کند و اطمینان حاصل می‌کند که هر رکورد ارجاع‌داده‌شده در همان خروجیِ همان فضای کاری بدون تغییر وجود دارد. هش‌های آواتار برچسب «منبع از کش محلی» (نه رکوردهای دفترچه) را دارند. @ها تطبیق الگو هستند — سرنخی برای بررسی، نه حقایق تأییدشده. پروفایل‌ها به صورت جداگانه برای هر چت فعال می‌شوند، می‌توانند به صورت یک فایل فشرده ZIP با رمزگذاری AES-256 صادر شوند و هنگام غیرفعال شدن یا حذف چت از منابع، پاک می‌گردند.

## شاهد مستقل

دفترچه یادداشت شاهد (`tgwitness-witness-v1`) و پست‌های کانال آن با خروجی مدرک با `verify.py --witness … --channel …` مطابقت داده می‌شوند؛ به [شاهد مستقل](https://phishdestroy.github.io/TgWitness/fa/docs/reference/witness/) مراجعه کنید.

## منشور و نقاط کنترل

فایل manifest.json شامل فرمت، زمان خروجی، کلید عمومی، اثر انگشت، طول دفترچه، هش سر، دامنه، تولیدکننده، محدودیت‌ها و SHA-256 هر عضو محتوای دیگر به جز خود `manifest.json` و `manifest.sig` است. فایل manifest.sig امضای Ed25519 در قالب base64 بر روی JSON کانونیکال manifest است. اعتبارسنج، اعضای غیرمنتظره/غایب، نام‌های تکراری، فایل‌های خراب، توالی/زنجیره شکسته، امضاهای نامعتبر و عدم تطابق با نقطه کنترل ارائه‌شده را رد می‌کند. این هیچ‌گاه مسیرهای آرشیو را استخراج نمی‌کند. اندازه کل اعلام‌شده بدون فشرده‌سازی را به ۴ گیگابایت محدود می‌کند؛ `--max-gib N` آرشیوهای بزرگ‌تری را که با افزایش حد **پارامترها** ساخته شده‌اند، مجاز می‌داند.

کد راستی‌آزمایی را از یک نسخه معتبر یا یک نسخه مستقل بررسی‌شده دریافت کنید. یک راستی‌آزمایی‌کننده در یک آرشیو غیرقابل‌اعتماد، یک فایل اجرایی است که توسط نویسنده آن آرشیو ارائه شده است؛ حضور آن یک سهولت در حمل‌پذیری است، نه یک لنگر اعتماد مستقل.

یک نقطهٔ کنترل بیانیه‌ای را امضا می‌کند که شامل کلید عمومی، طول دفترچه، هش سرآیند و زمان ایجاد است. اعتبارسنج می‌تواند بررسی کند که یک آرشیو بعدی حاوی همان پیش‌وند است. یک نقطهٔ کنترل را خارج از جمع‌کننده و پیش از یک تغییر مورد مناقشه حفظ کنید: یک مهاجم که هم بر آرشیو و هم بر نقطهٔ کنترل تسلط دارد می‌تواند هر دو را جایگزین کند.

یک امضای معتبر از یک کلید سنجاق‌نشده تنها سازگاری داخلی را برقرار می‌کند. حتی یک کلید سنجاق‌شده نیز نمی‌تواند اصالت محتوای منبع را اثبات کند اگر گردآورنده یا کلید قبل از ضبط، به خطر افتاده باشد. ثبت زمان‌بندی خارجی و ضبط مورد اعتماد، الزامات جداگانه‌ای هستند. TgWitness، قابلیت پذیرش در دادگاه یا گواهی قانونی را تضمین نمی‌کند.

## پیوست‌ها

فایل‌ها در پوشه media/ با استفاده از SHA-256 آدرس‌دهی می‌شوند. یک رویداد media.saved یک هش و طول بایت را به یک رویداد پیام خاص پیوند می‌دهد. نام‌های خام فایل‌ها متادیتا هستند و هرگز مسیرهای محلی نیستند. بایت‌های رسانه به‌صورت ناهمزمان دانلود می‌شوند، بنابراین حذف فوری ممکن است از ضبط آن‌ها جلوگیری کند. موارد غیرفعال‌سازی جمع‌آوری، فایل‌های بزرگ/با اندازه نامشخص، خطاهای دانلود و دانلودهای قطع‌شده به‌عنوان نتایج قابل مشاهده هستند. از کار افتادن یک فرآیند می‌تواند فایل‌های ناقص و ارجاع‌نشده‌ای را باقی بگذارد؛ این فایل‌ها در خروجی‌ها گنجانده نمی‌شوند.

خروجی‌گیرنده ZIP، رسانه‌های ذخیره‌شده را با نام‌هایشان تطبیق می‌دهد. خروجی‌های JSONL، CSV و HTML امضاهای رویدادها را تأیید می‌کنند اما بایت‌های رسانه را منتقل نمی‌کنند. گزارش‌های مشتق شده صرفاً برای سهولت هستند؛ فایل events.jsonl، نمایش معتبر رویدادها است.

## جمع‌آوری پایدار و رسیدهای فرایند (۰.۲)

یک جاب رسانه و رویداد پیام آن در یک تراکنش ثبت می‌شوند. این جاب، توصیف‌کننده اصلی پیام تلگرام (TL) را ذخیره می‌کند؛ مشاهده امضا شده، سیاست‌های SHA-256، حساب کاربری و اندازه آن را پیوند می‌دهد. بازیابی، پیش از دانلود، این پیوند را تأیید می‌کند. این جاب هرگز پیام فعلی را فراخوانی نمی‌کند و بی‌صدا یک پیوست جدیدتر را جایگزین آن می‌کند. جاب‌های متوقف‌شده دوباره امتحان می‌شوند، در حالی که شکست دائمی یک نتیجه صریح باقی می‌ماند.

هر فضای کاری (workspace) دارای دفتر ثبت (journal) و هویت امضای خود است. یک رویداد process.started شامل شناسه اجرا (run ID)، ساعت‌های محلی، نسخه‌های وابستگی، هش‌های فایل منبع، حساب/دامنه اولیه و تنظیمات ضبط است. تپش‌های قلب (Heartbeats) شامل شناسه اجرا، زمان مونوتونیک و وضعیت صف هستند. رسید فرآیند نیز می‌تواند به صورت یک بیانیه با امضای جداگانه دانلود شود. اندازه‌گیری‌های فایل به صورت خوداظهاری هستند و تأیید هویت سخت‌افزاری مورد اعتماد نیستند.

نقاط کنترل خودکار هنگام راه‌اندازی، هر پنج دقیقه در حین مشاهده (**پارامترها → نقطه کنترل امضا شده هر**)، و در هنگام توقف منظم، به‌صورت محلی نگهداری می‌شوند. تأییدیه راه‌اندازی و مقایسه خروجی، دفترچه را با آخرین نقطه کنترل محلی نگهداری‌شده مقایسه می‌کنند. این کار می‌تواند بازگشت پایگاه داده را در صورتی که نقطه کنترل باقی بماند، تشخیص دهد؛ یک اپراتور که هر دو را کنترل می‌کند همچنان می‌تواند هر دو را جایگزین کند. نگهداری مستقل و مهرهای زمانی خارجی مورد اعتماد، همچنان الزامات جداگانه‌ای باقی می‌مانند.

پس از راه‌اندازی مجدد، موقعیت به‌روزرسانی ذخیره‌شده تلگرام از سر گرفته می‌شود (`catch_up_from` در `observation.started`) و به‌روزرسانی‌های از دست رفته درخواست می‌شوند. یک بازبینی دوره‌ای، `message.recovered` را برای پیام‌های از دست رفته و `message.missing_on_recheck` را زمانی که تلگرام دیگر یک پیام ذخیره‌شده را بازنمی‌گرداند، ثبت می‌کند؛ مورد دوم یک اطلاعیه حذف نیست و نه نام حذف‌کننده و نه زمان را مشخص نمی‌کند.

### نسخه‌برداری و بازیابی خارج از محل (S3)

نسخهٔ خارج از محل (Exports، به‌صورت پیش‌فرض غیرفعال) بخش‌های مجله، فایل‌های نگهداری‌شده، نقاط کنترل با مهر زمانی و خروجی‌های چت تکمیل‌شده را به ذخیره‌سازی سازگار با S3 بارگذاری می‌کند، رمزگذاری‌شده با نسخهٔ خارج از محل (Exports، به طور پیش‌فرض غیرفعال) بخش‌های دفترچه، فایل‌های نگهداری‌شده، نقاط کنترل را به همراه مهرهای زمانی‌شان و خروجی‌های چت تکمیل‌شده را در یک فضای ذخیره‌سازی سازگار با S3 بارگذاری می‌کند، که پیش از بارگذاری با کلید نگه‌داری‌شده در گاوصندوق فضای کاری با استفاده از رمزگذاری 256-GCM AES رمزگذاری می‌شود؛ نگهداری Object Lock در صورتی اعمال می‌شود که باکت از آن پشتیبانی کند. بدون کلید دانلودشده، این نسخه قابل خواندن نیست. با `python -m tgwitness.replica restore --key-file KEY.json --out DIR` بازیابی و تأیید کنید.

بازیابی به یک دایرکتوری معمولی و خالی نیاز دارد. فایل‌های دانلود شده و اشیاء رمزگشایی شده تا زمان تأیید کامل دفترچه یادداشت و هر نقطه کنترل نگهداری‌شده، در حافظه موقت خصوصی باقی می‌مانند. مسیرهای شیء ناامن، بازه‌های بخش ناسازگار و دفترچه‌های یادداشت کوتاه‌تر از یک نقطه کنترل رد می‌شوند؛ اعتبارسنجی ناموفق، هیچ‌یک از فایل‌های بازیابی‌شده را منتشر نمی‌کند. تأییدهای نگهداری، حالت و تاریخ Object Lock بازگشتی را با مهلت ارسال‌شده هنگام بارگذاری (با تلرانس گرد کردن یک ثانیه‌ای) مقایسه می‌کنند. مهلت منقضی‌شده، نامعتبر یا کوتاه‌تر از حد مجاز، تأییدشده محسوب نمی‌شود. وضعیت، شیء نمونه‌برداری‌شده‌ای را گزارش می‌دهد که نگهداری آن برای آن بارگذاری خاص خوانده شده است.

پیشرفت کپی محدود به مقصد و کلید رمزگذاری است. تغییر نقطه پایانی، باکت یا پیش‌وند، کپی کاملی از دفترچه ثبت محلی، رسانه‌ها و نقاط کنترل را به آن مقصد آغاز می‌کند. پیشرفت قدیمی بدون محدوده حفظ می‌شود اما پس از ارتقا یک بار مجدداً اجرا می‌شود. خروجی‌های تاریخی چت که قبلاً از صندوق خروجی محلی حذف شده‌اند، در مقصد قبلی خود باقی می‌مانند.

نبود یا خرابی رسانه محلی به‌عنوان خطای مرحله گزارش می‌شود و مکان نمای رسانه را قبل از آن نگه می‌دارد، تا فایل در مرحله بعدی دوباره امتحان شود؛ فایل‌ها، نقاط کنترل و خروجی‌های بعد از آن همچنان کپی می‌شوند. عملیات بازیابی، تمام ارجاعات به رسانه‌های نگهداری‌شده را با هش‌های رمزگشایی‌شده و اندازه‌های ثبت‌شده مطابقت می‌دهد. بخش‌های مجله‌ای یکسان و همپوشان از بارگذاری‌های قطع‌شده یکپارچه‌سازی (deduplication) می‌شوند؛ همپوشانی‌های متضاد رد می‌شوند. نقاط کنترل ایجادشده در حین بارگذاری، تا زمانی که سوابق مجله‌ای مربوط به آن‌ها کپی نشده‌اند، به تعویق می‌افتند، بنابراین یک چرخه کامل‌شده، هیچ نقطه‌کنترلی را جلوتر از مجله‌اش منتشر نمی‌کند.

### اسنپ‌شات‌های خروجی استریم

صادرات جریانی از یک اسنپ‌شات خواندن پایدار SQLite استفاده می‌کند. ممکن است سر آن هنگام تکمیل دانلود، قدیمی‌تر از ژورنال زندهٔ فعلی باشد. یک نقطه‌کنترل که پس از آن اسنپ‌شات ایجاد می‌شود، می‌تواند به درستی گزارش دهد که آرشیو کوتاه‌تر است؛ آن را با یک نقطه‌کنترل در یا قبل از پیش‌وند صادر شده مقایسه کنید، نه یک نقطه‌کنترل دلخواه بعدی.

## آماده‌سازی RFC 3161 و تأیید پاسخ (۰.۲)

حالت مدرک (به طور پیش‌فرض غیرفعال) تنها هش SHA-256 هر نقطه کنترل امضا شده را از طریق مسیر فضای کاری و هرگز از طریق MTProxy، به مراجع RFC 3161 و تقویم‌های OpenTimestamps فهرست‌شده ارسال می‌کند. پاسخ‌ها در `checkpoints/anchors/` نگهداری، صادر و توسط `verify.py` بررسی می‌شوند (`--tsa-ca` امضای TSA را بررسی می‌کند؛ اثبات‌های OpenTimestamps را با `ots upgrade` و `ots verify` تأیید کنید).

پنل یک آرشیو درخواست آماده می‌کند که حاوی بایت‌های کانونیکال checkpoint.json، یک اثر انگشت پیام SHA-256 و یک نانس تصادفی در timestamp.tsq، چک‌سام‌ها و دستورالعمل‌ها است. هیچ درخواست شبکه‌ای انجام نمی‌شود. آماده‌سازی یک مهر زمانی معتبر نیست.

`python -m tgwitness.anchor verify` دو بار ts را در OpenSSL فراخوانی می‌کند: یک بار برای بررسی بایت‌های نقطه‌کنترل و یک بار دیگر برای بررسی درخواست اصلی. یک فایل CA مورد اعتماد به صراحت مورد نیاز است؛ گواهی‌نامه‌های ضمیمه‌شده به طور خودکار مورد اعتماد قرار نمی‌گیرند. بررسی درخواست در CLI اختیاری است، بنابراین برای بررسی نانسی (nonce) باید --request را نگه دارید و ارائه دهید. نتیجه بیان می‌کند که آیا بررسی شده است یا خیر. امضای نقطه کنترل جمع‌آورنده و دفترچه همچنان باید به طور جداگانه با اثر انگشت جمع‌آورنده مورد اعتماد، تأیید شوند.

اعتبارسنج فعلی اطلاعات لغو اعتبار را دریافت نمی‌کند و پس از انقضای گواهی، اعتبارسنجی بایگانی بلندمدت را انجام نمی‌دهد. اعتبارسنجی موفق امضا را با مهر زمانی معتبر یا قابلیت پذیرش قانونی معادل ندانید. در طول توسعه با یک TSA مستقل واقعی تماس گرفته نشده است. به [رویه](https://phishdestroy.github.io/TgWitness/fa/docs/reference/timestamp/) مراجعه کنید.