آزاد شاہد

روسی زبان میں بوٹ اور پروکسی کی ترتیب۔

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

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

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

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

ٹوکن پینل کے 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 پروفائل دیکھیں)۔

ایکسٹرا → اپنے چینل میں ایک بوٹ → پینل میں ایک بوٹ سیٹ اپ کریں۔ تین مراحل میں صرف پڑھنے کی اجازت، آپ کے چینل اور وقفے کا تعین، اور پھر ویٹنس کو لانچ کرنا شامل ہے۔ اشاعت کی پالیسی، اختیاری 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://witness.example.org استعمال کرتا ہے، دیگر ورک اسپیس https://witness.example.org/profiles/ID استعمال کرتے ہیں۔ ٹوکنز کی ضرورت اب بھی ہوتی ہے؛ پینل اور اس کے دیگر API روٹس اس ورچوئل ہوسٹ کے ذریعے فارورڈ نہیں کیے جاتے۔

all کو باقاعدگی سے شائع ہونے والے چیک پوائنٹس کے لیے منتخب کریں۔ پانچ منٹ کے وقفے کا مطلب ہے کہ روزانہ فی ورک اسپیس تقریباً 288 پوسٹس۔ changes/problems جان بوجھ کر کچھ چیکس غیر شائع شدہ چھوڑ دیتے ہیں۔ MTProxy کلیکٹر کے ٹیلیگرام کلائنٹ کے لیے ہے۔ Witness HTTP پولنگ اور ٹیلیگرام کا HTTPS Bot API اپنا براہِ راست/HTTP/SOCKS5 راستہ (Bot 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

اختیارات#

جمع کرنے والا پتہ، ٹوکنز اور چینل --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 بھی فراہم کیا جائے، تو دعویٰ شدہ لیکن غائب پوسٹس یا خالی میچ سیٹ اس سخت چیک میں ناکام ہو جاتے ہیں۔ فلیگ کے بغیر، عام سالمیت چیکس اب بھی ایسے ریکارڈز کی اطلاع دیتے ہیں جن کی گواہی نہیں دی گئی، بغیر اس کے کہ ایک ورنہ سالم آرکائیو کو مسترد کر دیں۔

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

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

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