# آزاد شاہد

Canonical page: https://phishdestroy.github.io/TgWitness/ur/docs/reference/witness/

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

[روسی زبان میں بوٹ اور پروکسی کی ترتیب](https://github.com/phishdestroy/TgWitness/blob/main/docs/ru/WITNESS.md)۔

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

دھارے کا خاکہ · جمع کنندہ → گواہ (مصنوعی چیک پوائنٹ: ریکارڈز کی تعداد + ہیڈ ہیش); گواہ → گواہ جرنل، اپنی کلید; گواہ → ٹیلیگرام چینل (اپنے بوٹ کے ذریعے دستخط شدہ پوسٹ); شواہد کا زپ → verify.py; گواہ جرنل، اپنی کلید → verify.py; ٹیلیگرام چینل → verify.py (ٹیلیگرام ڈیسک ٹاپ ایکسپورٹ یا t.me/s صفحہ) · جمع کنندہ · گواہ · گواہ جرنل، اپنی کلید · ٹیلیگرام چینل · شواہد کا زپ · verify.py · مصنوعی چیک پوائنٹ: ریکارڈز · کی تعداد + ہیڈ ہیش · اپنے بوٹ کے ذریعے دستخط شدہ · پوسٹ · ٹیلیگرام ڈیسک ٹاپ ایکسپورٹ · یا t.me/s صفحہ

**ڈایاگرام بطور متن**

1. جمع کنندہ → گواہ (مصنوعی چیک پوائنٹ: ریکارڈز کی تعداد + ہیڈ ہیش)
2. گواہ → گواہ جرنل، اپنی کلید
3. گواہ → ٹیلیگرام چینل (اپنے بوٹ کے ذریعے دستخط شدہ پوسٹ)
4. شواہد کا زپ → verify.py
5. گواہ جرنل، اپنی کلید → verify.py
6. ٹیلیگرام چینل → verify.py (ٹیلیگرام ڈیسک ٹاپ ایکسپورٹ یا t.me/s صفحہ)

## گواہ کو کیا ملتا ہے، اور کیا نہیں ملتا

| گواہ کے پاس ہے | گواہ نے کبھی نہیں |
| --- | --- |
| ایک ورک اسپیس کے لیے صرف پڑھنے کے قابل **وِٹنس ٹوکن** | جمع کرنے والے کا ٹیلیگرام سیشن یا API کی شناختی تفصیلات |
| اپنی Ed25519 کلید اور جرنل | جمع کنندہ کا خزانہ، دستخطی کلید یا پینل ٹوکن |
| اس کا اپنا ٹیلیگرام بوٹ ٹوکن | پیغام کا مواد: سر میں ریکارڈز کی تعداد اور ہیش شامل ہے |

ٹوکن پینل کے **Witness** صفحے پر بنایا جاتا ہے، ایک بار دکھایا جاتا ہے اور صرف SHA-256 کے طور پر محفوظ کیا جاتا ہے۔ یہ بالکل ایک ہی اینڈ پوائنٹ، `GET /api/witness/head`، کھولتا ہے، جو تازہ دستخط شدہ چیک پوائنٹ کے ساتھ دستخط شدہ مواد سے خالی کلیکشن کاؤنٹرز اور آپریشنل ہیلتھ واپس کرتا ہے۔ یہ پینل نہیں کھول سکتا، پیغام کا مواد نہیں پڑھ سکتا یا ترتیبات تبدیل نہیں کر سکتا، اور پینل ٹوکن وہاں قبول نہیں کیا جاتا۔ ایک ٹوکن کو اسی صفحے پر منسوخ کریں۔ کلیکٹر ریکارڈ کرتا ہے کہ ایک نئی وِٹنس کی (`witness.seen`) کب چیک کرنا شروع کرتی ہے اور ہر ٹوکن کے لیے آخری چیک دکھاتا ہے؛ ایک وِٹنس جو 2.5 وقفوں کے اندر چیک نہیں کرتی اسے مقررہ وقت سے تجاوز شدہ قرار دیا جاتا ہے۔

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

## یہ کیا چیک اور ریکارڈ کرتا ہے

ہر وقفے (ڈیفالٹ کے طور پر 10 منٹ) پر گواہ:

1. خود ہی ہیڈ کو حاصل کرتا ہے (جمع کرنے والا اسے دھکیل یا چھوڑ نہیں سکتا)؛
2. جمع کنندہ کے دستخط کی تصدیق کرتا ہے، پن کیے گئے جمع کنندہ کلید (`--collector-fingerprint`، یا پہلی دیکھی گئی کلید)، ایک غیر کمی پذیر گنتی اور ایک غیر تبدیل شدہ ہیڈ کو غیر تبدیل شدہ گنتی پر؛
3. اپنے جرنل میں ایک دستخط شدہ ریکارڈ منسلک کرتا ہے: `witness.anchor` جس کی حیثیت `ok`، `key_changed`، `rollback` (پہلے سے کم ریکارڈز)، `fork` (لمبائی ایک جیسی، مختلف ہیڈر) یا `invalid` (جواب توثیق میں ناکام رہا)، یا `witness.no_response` جب جمع کرنے والے نے جواب نہیں دیا؛
4. نتیجہ چینل پر پوسٹ کیا جاتا ہے، دستخط شدہ، بشمول "کوئی جواب نہیں" جب تک گواہ چل رہا ہو اور Bot API تک پہنچ سکے۔ پوسٹ آئی ڈی ریکارڈ کی جاتی ہے (`witness.posted`)، ایک ناکام پوسٹ بھی (`witness.post_failed`).

ایک پوسٹ اس طرح نظر آتی ہے؛ آخری سطر میں دستخط شدہ بیان شامل ہوتا ہے:

```
TgWitness witness #42 · journal head
Collector 3fa9c2d1e0b4a7f6: 18234 records
Head 9b1f…c07e
2026-10-28T19:40:00.123+00:00
TGW1.eyJhdCI6…<statement>.<signature>
```

## ویٹنس چلائیں

آپ کو ایک ٹیلیگرام بوٹ (@BotFather کے ذریعے ایک بنائیں)، ایک چینل جہاں وہ بوٹ منتظم ہو، اور گواہ کی جانب سے قابلِ رسائی کلیکٹر کا پتہ — نجی نیٹ ورک کے باہر HTTPS کے ذریعے ([تینفذ](https://phishdestroy.github.io/TgWitness/ur/docs/reference/deployment/) میں HTTPS پروفائل دیکھیں)۔

**ایکسٹرا → اپنے چینل میں ایک بوٹ →** پینل میں **ایک بوٹ سیٹ اپ** کریں۔ تین مراحل میں صرف پڑھنے کی اجازت، آپ کے چینل اور وقفے کا تعین، اور پھر ویٹنس کو لانچ کرنا شامل ہے۔ اشاعت کی پالیسی، اختیاری HTTP/SOCKS5 پروکسی اور کسٹم بوٹ API ایڈریس **ایڈوانسڈ سیٹنگز** کے تحت ہیں۔ فارم `witness.json` کو اس ورک اسپیس کی کلیکٹر کی کے ساتھ ڈاؤن لوڈ کرتا ہے۔ نئے بنائے گئے ریڈ-اونلی ٹوکن کو **'Save access file** as' کے ساتھ `witness-token.txt` کے طور پر ڈاؤن لوڈ کریں؛ اسے اور ویٹنس ہوسٹ پر بنائے گئے `bot-token.txt` کو اس JSON کے ساتھ رکھیں۔ کلیکٹر کو بوٹ ٹوکن کبھی موصول نہیں ہوتا۔ ڈاؤن لوڈ کرنا کوئی سروس شروع نہیں کرتا اور نہ ہی کوئی پیغام شائع کرتا ہے۔ کوئی ہوسٹڈ پروجیکٹ وٹنس خود بخود شامل نہیں ہوتا۔

```
python -m tgwitness.witness run --config witness.json --check-config
python -m tgwitness.witness run --config witness.json
python -m tgwitness.witness fingerprint --config witness.json
```

پہلی کمانڈ کنفیگریشن اور خفیہ فائلوں کی جانچ کرتی ہے، بغیر کسی نیٹ ورک درخواست یا کلید کی تخلیق کے۔ JSON میں راستے اس فائل کے نسبت سے ہوتے ہیں؛ CLI/ماحول کے راستے کام کرنے والی ڈائریکٹری کے نسبت سے ہوتے ہیں۔ گواہ کے فنگر پرنٹ کو اس کے ہوسٹ کے باہر محفوظ رکھیں۔ کلیکٹر کا آخری پول انڈیکیٹر صرف درخواست کی تصدیق کرتا ہے؛ اشاعت کی اطلاع Proof کے ذریعے دی جاتی ہے یا گواہ کے جرنل اور چینل میں چیک کی جاتی ہے۔

اگر پینل SSH ٹنل کے پیچھے رہے، تو صرف اسکوپڈ وِٹنس اینڈ پوائنٹ کو ایک الگ HTTPS ہوسٹ نیم پر [اس Caddy مثال](https://github.com/phishdestroy/TgWitness/blob/main/deploy/Caddyfile.witness.example) کے ساتھ ظاہر کریں۔ ڈیفالٹ ورک اسپیس پھر `https://witness.example.org` استعمال کرتا ہے، دیگر ورک اسپیس `https://witness.example.org/profiles/ID` استعمال کرتے ہیں۔ ٹوکنز کی ضرورت اب بھی ہوتی ہے؛ پینل اور اس کے دیگر API روٹس اس ورچوئل ہوسٹ کے ذریعے فارورڈ نہیں کیے جاتے۔

`all` کو باقاعدگی سے شائع ہونے والے چیک پوائنٹس کے لیے منتخب کریں۔ پانچ منٹ کے وقفے کا مطلب ہے کہ روزانہ فی ورک اسپیس تقریباً 288 پوسٹس۔ `changes`/`problems` جان بوجھ کر کچھ چیکس غیر شائع شدہ چھوڑ دیتے ہیں۔ MTProxy کلیکٹر کے ٹیلیگرام کلائنٹ کے لیے ہے۔ Witness HTTP پولنگ اور ٹیلیگرام کا HTTPS Bot API اپنا براہِ راست/HTTP/SOCKS5 راستہ ([Bot API](https://core.telegram.org/bots/api)) استعمال کرتے ہیں۔

**کلیکٹر کے ساتھ، ڈوکر کے ذریعے** (ایک ہی ہوسٹ — آزاد عمل اور کلید، لیکن ایک ہی آپریٹر): `.env` میں ویلیوز درج کریں اور پروفائل شروع کریں۔

```
TGWITNESS_WITNESS_TOKEN=tgww_...
TGWITNESS_WITNESS_BOT_TOKEN=123456:ABC...
TGWITNESS_WITNESS_CHANNEL=@your_witness_channel
# another workspace: TGWITNESS_WITNESS_COLLECTOR=http://tgwitness:8787/profiles/<workspace ID>

docker compose --profile witness up -d
docker compose logs witness     # prints the witness key fingerprint
```

شائع شدہ تصویر کے لیے `docker compose --project-directory . -f deploy/compose/compose.image.yaml --profile witness up -d` استعمال کریں۔

**کسی اور کے سرور پر** (ایک حقیقی آزاد گواہ): وہاں ریپوزیٹری کاپی کریں، `TGWITNESS_WITNESS_COLLECTOR=https://your-collector.example.org` میں اوپر دیے گئے تین اقدار کے ساتھ `.env` سیٹ کریں، پھر

```
docker compose --project-directory . -f deploy/compose/compose.witness.yaml up -d
```

یا ڈاکر کے بغیر:

```
python -m tgwitness.witness run --collector https://your-collector.example.org \
    --token-file witness-token.txt --bot-token-file bot-token.txt --channel @your_witness_channel
```

### اختیارات

| اختیار | ماحول | ڈیفالٹ | معنی |
| --- | --- | --- | --- |
| `--interval` | `TGWITNESS_WITNESS_INTERVAL` | 10 | چیکس کے درمیان منٹ، 1–1440 |
| `--timeout` | `_TIMEOUT` | 30 | کلیکٹر اور بوٹ API کے لیے انتظار کے سیکنڈز، 5–600 |
| `--post` | `_POST` | `all` | `all`: ہر چیک؛ `changes`: ایک نیا سربراہ یا ایک مسئلہ؛ `problems`: صرف مسائل اور غائب جوابات |
| `--title` | `_TITLE` | `TgWitness witness` | ہر چینل پوسٹ کے پہلے الفاظ |
| `--collector-fingerprint` | `_COLLECTOR_FINGERPRINT` | – | پہلے جواب پر بھروسہ کرنے کے بجائے کلیکٹر کلید کو پن کریں۔ |
| `--proxy` | `_PROXY` | براہِ راست | `socks5://host:port` یا `http://host:port` |
| `--bot-api` | `_BOT_API` | `https://api.telegram.org` | بوٹ API کا پتہ، مثلاً ایک مقامی بوٹ API سرور |
| `--data-dir` | `_DATA` | `witness-data` | ویٹنس کی اور جرنل |
| `--config` | `_CONFIG` | – | مندرجہ بالا اختیارات میں سے کسی کے ساتھ JSON فائل |

جمع کرنے والا پتہ، ٹوکنز اور چینل `--collector`، `--token` یا `--token-file`، `--bot-token` یا `--bot-token-file` اور `--channel`، یا `_COLLECTOR`، `_TOKEN`، `_TOKEN_FILE`، `_BOT_TOKEN`، `_BOT_TOKEN_FILE` اور `_CHANNEL` سے آتے ہیں، جو عمل کی فہرست سے رازوں کو باہر رکھتا ہے۔

ایک کنفیگ فائل آپشن کے ناموں کے لیے انڈر اسکورز استعمال کرتی ہے، اور `texts` بھی، جو چینل کی پوسٹس کے الفاظ کو تبدیل کر دیتا ہے:

```
{"collector": "https://your-collector.example.org", "token_file": "witness-token.txt",
 "bot_token_file": "bot-token.txt", "channel": "@your_witness_channel",
 "interval": 5, "timeout": 30, "post": "changes", "title": "Partner witness",
 "texts": {"ok": "journal head", "no_response": "no answer from the collector", "records": "records"}}
```

`texts` کلیدیں: `ok`, `key_changed`, `rollback`, `fork`, `invalid`, `no_response`, `collector`, `records`, `head`. کمانڈ لائن ماحول پر، اور ماحول فائل پر غالب آتی ہے۔ نامعلوم اختیارات یا ٹیکسٹ کلیدیں نظر انداز کیے جانے کے بجائے ایک پیغام کے ساتھ ویٹنس کو روک دیتی ہیں۔ الفاظ کی ترتیب کبھی تصدیق کو متاثر نہیں کرتی: verify.py ہر پوسٹ کے آخر میں دستخط شدہ ٹوکن کی جانچ کرتا ہے۔ `--post changes` یا `problems` کے ساتھ، وہ چیکس جو پوسٹ نہیں کیے گئے تھے وہ اب بھی ویٹنس جرنل میں موجود ہیں اور `verify.py` انہیں کبھی پوسٹ نہ کیے جانے کے طور پر درج کرتا ہے؛ شروع کا ریکارڈ پالیسی کا نام بتاتا ہے۔ ہر چیک اب بھی جرنل میں ظاہر ہوتا ہے، لہٰذا کم پوسٹس کا مطلب کم آزاد ٹیلیگرام اوقات ہیں، نہ کہ کم چیکس۔

چینل کے بغیر بھی ویٹنس اپنا جرنل برقرار رکھتا ہے۔ ویٹنس کی کلید کے فنگر پرنٹ (`python -m tgwitness.witness fingerprint`) کو کہیں اور محفوظ رکھیں۔

## تصدیق کریں

گواہ کی جانب سے، اپنا جریدہ برآمد کریں:

```
python -m tgwitness.witness export --out witness.zip
# Docker (add -f deploy/compose/compose.witness.yaml on a witness server):
docker compose exec witness python -m tgwitness.witness export --out /witness/witness.zip
docker compose cp witness:/witness/witness.zip .
```

پھر، کہیں بھی، کلیکٹر کے دستخط شدہ ZIP اور ٹیلیگرام ڈیسک ٹاپ سے ایکسپورٹ کیے گئے چینل کے ساتھ (*Export chat history* → JSON سے `result.json` ملتا ہے) یا اس کے عوامی `https://t.me/s/…` صفحے کے ذریعے:

```
python verify.py tgwitness-evidence.zip --fingerprint COLLECTOR_SHA256 \
    --witness witness.zip --witness-fingerprint WITNESS_SHA256 --channel result.json
```

`verify.py` گواہ کے جرنل (زنجیر اور دستخط) کی جانچ کرتا ہے، پھر یہ کہ **ہر وہ سر جو گواہ نے دیکھا ہے، برآمد شدہ جرنل کا حصہ ہے**: اس گنتی پر ریکارڈ میں بالکل وہی ہیش ہونا چاہیے۔ جو سر میل نہیں کھاتا وہ توثیق میں ناکام ہو جاتا ہے — جرنل گواہ کے دیکھنے کے بعد تبدیل کیا گیا تھا۔ یہ برآمدات کے بعد دیکھے گئے ہیڈز، گواہ کی ریکارڈ کردہ بے ضابطگیاں، ناکام جوابات، وہ ادوار جن کے مطابقت رکھنے والے چیک پوائنٹس اس برآمد میں موجود ہیں ("X سے Y تک گواہی دی گئی") اور خلاؤں کی بھی رپورٹ کرتا ہے۔ بعد کے چیک پوائنٹس ان ادوار کو بڑھا نہیں سکتے۔ نتیجے میں آخری مطابقت پذیر ریکارڈ نمبر اور بغیر میچنگ چیک پوائنٹ کے پیچھے آنے والے ریکارڈز کی تعداد شامل ہوتی ہے۔ صرف وہ جوابات شمار کیے جاتے ہیں جن پر خود ایکسپورٹ کی کلید نے دستخط کیے ہوں: ایک ایکسپورٹ جس پر ایسی کلید نے دستخط کیے ہوں جو گواہ نے کبھی نہیں دیکھی، اسے غیر گواہی شدہ رپورٹ کیا جاتا ہے، اور `--fingerprint` کے بغیر اس کا دستخط کنندہ پن نہ شدہ رہتا ہے۔ `--channel` کے ساتھ ہر دستخط شدہ پوسٹ کو ویٹنس جرنل سے ریکارڈ بہ ریکارڈ ملانا ضروری ہے: تبدیل شدہ پوسٹس کی توثیق ناکام ہو جاتی ہے، اور غائب پوسٹس کی فہرست بنائی جاتی ہے۔ فراہم کردہ ٹیلیگرام JSON ایکسپورٹ میں موجود تاریخ قابل ترمیم میٹا ڈیٹا ہے، جو دستخط شدہ ویٹنس ٹوکن کے باہر ہوتی ہے۔ ٹوکن سے مطابقت رکھنے کا مطلب اشاعت کی تاریخ کی تصدیق نہیں ہے؛ نتیجہ واضح طور پر رپورٹ کرتا ہے کہ اشاعت کے وقت کی توثیق نہیں کی گئی تھی۔

### مشاہدہ شدہ برآمدی حد درکار

ایک ہینڈ اوور کے لیے جس میں گواہی شدہ حتمی ریکارڈ شامل ہونا چاہیے، `--require-witness` شامل کریں:

```
python verify.py tgwitness-evidence.zip --fingerprint COLLECTOR_SHA256 \
    --witness witness.zip --witness-fingerprint WITNESS_SHA256 --require-witness
```

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

یہ فلیگ فراہم کردہ، پن کیے گئے ویٹنس ریکارڈز کے ساتھ مطابقت کو برقرار رکھتا ہے۔ آپریٹر کو اب بھی ویٹنس کی آزادی قائم کرنی ہوگی اور اس کے ریکارڈز کو علیحدہ طور پر محفوظ کرنا ہوگا۔ یہ پیغام کی صداقت، مکمل جمع یا آزادانہ طور پر ماپا گیا رن ٹائم ثابت نہیں کرتا۔

ایک ویٹنس دکھاتا ہے کہ کلیکٹر نے اُس وقت کیا رپورٹ کیا اور بعد کی ایکسپورٹس اس سے مطابقت رکھتی ہیں۔ یہ اس بات کو ثابت نہیں کرتا کہ کلیکٹر نے ٹیلیگرام کی جانب سے فراہم کردہ ہر چیز کو ریکارڈ کیا، یا یہ کہ پیغام کا مواد درست ہے۔ ایک ہی آپریٹر کے ذریعے ایک ہی مشین پر چلایا گیا ویٹنس، کسی اور کے ذریعے چلائے گئے ویٹنس کے مقابلے میں کمزور ہوتا ہے۔

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