ریموٹ کنٹرول اور موبائل
Control Center ایک ڈیسک ٹاپ ایپ ہے، مگر جس کام کی یہ نگرانی کرتا ہے وہ آپ کے
میز سے دور جانے پر رکتا نہیں۔ ریموٹ کنٹرول آپ کے فون کو آپ کے cc_server
کے ساتھ جوڑتا ہے، اور اِس کے لیے Remote استعمال
کرتا ہے، یعنی remote.usectrl.dev پر موجود ساتھی ایپ، تاکہ آپ وہیں سے فلیٹ کا پیچھا
کر سکیں: پیغامات اور ٹکٹس پڑھیں، کسی ایجنٹ کو جواب دیں، اپنی نیوز فیڈ ٹرائیج
کریں — اور سرور پر موجود آڈیو، ٹرانسکرپٹ، سورس کوڈ یا اسناد کبھی وہاں سے باہر نہ
جائیں۔
اِسے ڈیک کے ساتھ چلنے والا ایسا ساتھی سمجھیں جو زیادہ تر پڑھتا ہے۔ یہ مکمل ڈیسک ٹاپ کلائنٹ کی جگہ لینے کے لیے نہیں بنایا گیا۔
ٹرانسپورٹ
سیکشن کا عنوان “ٹرانسپورٹ”فون cc_server تک WebSocket کے ذریعے پہنچتا ہے: یا تو براہِ راست کنکشن (لوپ بیک،
LAN، ٹیل نیٹ یا wss://) سے، یا کسی سگنلنگ بروکر پر دعوت نامے سے محدود کمرے سے
جو سیل شدہ فریم آگے بھیجتا ہے۔ کوئی پیئر ٹو پیئر ڈیٹا چینل نہیں ہوتا۔
فون کیا کر سکتا ہے
سیکشن کا عنوان “فون کیا کر سکتا ہے”پیئر شدہ فون سرور کی سطح کے ایک چھوٹے اور جان بوجھ کر محدود حصے تک پہنچتا ہے:
- پڑھنا: ٹکٹس، ایجنٹس، اسپیسز اور اُن کے پیغامات، اور آپ کی نیوز فیڈ
- جواب دینا: کسی اسپیس میں پیغام بھیجنا، ٹکٹ اپ ڈیٹ کرنا یا تفویض کرنا، کسی مضمون کو پڑھا ہوا یا محفوظ نشان زد کرنا
- پلی بک چلانا: محفوظ شدہ پلان ٹیمپلیٹ کو اُس کے پیرامیٹرز کے ساتھ تشکیل دینا۔ یہ صرف پلان کی تجویز دیتا ہے؛ جب تک کوئی آپریٹر مکمل کلائنٹ پر Plan Studio میں اُس کی منظوری نہ دے، کچھ بھی چلتا یا خرچ نہیں ہوتا
- ورک اسپیسز بدلنا، فون کے اپنے منتخب کنندہ سے
یہ تقریباً سب کچھ ہے۔ فون مکمل کلائنٹ کے مقابلے کم تر مراعات یافتہ پرنسپل ہوتا ہے۔ یہ پروسیس شروع نہیں کر سکتا، LLM بجٹ خرچ نہیں کر سکتا، GitHub پر پش نہیں کر سکتا اور نہ ورک اسپیسز بنا سکتا ہے۔ یہ صرف نیت نہیں بلکہ واقعی نافذ کیسے کیا جاتا ہے، یہ رسائی کا ماڈل دیکھیں۔
لنک کیسے بنتا ہے
سیکشن کا عنوان “لنک کیسے بنتا ہے”کنکشن ایک بروکر شدہ ریلے پر چلتا ہے: سرور بطور مالک wss:// بروکر پر دعوت
نامے سے محدود ایک کمرے میں شامل ہوتا ہے اور ہر پیئر شدہ کلائنٹ — ڈیسک ٹاپ، ویب،
فون — وقت کی حد والے داخلہ ٹوکن کے ساتھ اُسی کمرے میں شامل ہوتا ہے۔ تین ٹکڑے مل
کر یہ بناتے ہیں:
| ٹکڑا | کردار |
|---|---|
| Remote (فون ایپ) | ساتھی ویب ایپ، جو بطور ڈیفالٹ remote.usectrl.dev پر میزبانی شدہ ہے یا خود میزبان۔ براؤزر میں لوڈ ہوتی ہے اور پیئرنگ ریکارڈ IndexedDB میں رکھتی ہے۔ |
| ریلے بروکر | بے حالت wss:// ریلے (cc_signaling_server) جو N طرفہ کمروں کی میزبانی کرتا ہے۔ یہ صرف مبہم فریم لے کر چلتا ہے: ہر پے لوڈ فون اور سرور کے درمیان اینڈ ٹو اینڈ سیل ہوتا ہے، چنانچہ بروکر نہ کبھی ایپ ڈیٹا یا پیئرنگ راز دیکھتا ہے اور نہ آگے بھیجی گئی چیز کی تشریح کرتا ہے۔ |
cc_server |
کمرے کا مالک۔ یہ فون کی کالوں کا جواب اُسی ڈسپیچر کے ذریعے دیتا ہے جو ہر دوسرا کلائنٹ استعمال کرتا ہے۔ |
پیئرنگ کی پیشکش ایک کنکشن ڈسکرپٹر لے کر آتی ہے جس میں سرور تک کے تمام راستے
(LAN، ٹیل نیٹ، عوامی wss://، ریلے) اور اُس کا شناختی فنگر پرنٹ درج ہوتا ہے۔ فون
کا ریزالور بہترین قابلِ رسائی راستہ چنتا ہے اور پہلی کنکٹ پر فنگر پرنٹ کو پن کر
دیتا ہے (TOFU)؛ ریلے رسائی کی ضمانت دیتا ہے چاہے کوئی براہِ راست راستہ موجود نہ
ہو، مگر ٹریفک کبھی پڑھ نہیں سکتا۔
پیئرنگ پے لوڈ کیا ہوتا ہے
سیکشن کا عنوان “پیئرنگ پے لوڈ کیا ہوتا ہے”پیئرنگ ایپ سے جاری کی جاتی ہے اور ڈیپ لنک کی صورت میں پہنچائی جاتی ہے؛ طریقہ کار کے لیے ڈیوائس پیئر کریں دیکھیں۔ یہاں اصل بات اُس کی ساخت ہے۔
https://<pwa-host>/#<payload>پے لوڈ URL کے فریگمنٹ میں سفر کرتا ہے، یعنی # کے بعد کا وہ حصہ جسے براؤزر
کبھی سرور کو نہیں بھیجتے، چنانچہ PWA کا HTTPS ہوسٹ اُسے کبھی نہیں دیکھتا۔ اِس میں
وہ سب کچھ ہوتا ہے جو فون کو سرور تک پہنچنے اور یہ ثابت کرنے کے لیے درکار ہے کہ وہ
کون ہے: کنکشن ڈسکرپٹر (ہر راستہ اور شناختی فنگر پرنٹ)، نیا جاری کیا گیا ڈیوائس
id، 32 بائٹ کی پری شیئرڈ کلید اور میعاد کا اسٹیمپ۔ فون اُسے ڈی کوڈ کرتا ہے،
پیئرنگ ریکارڈ مقامی طور پر محفوظ کرتا ہے اور فریگمنٹ ہٹا دیتا ہے تاکہ راز URL سے
نکل جائے۔
پے لوڈ کی دو شکلیں ہیں اور وہ آپس میں بدلی نہیں جا سکتیں۔ ایپ کے اندر پیئرنگ
پینل سے جاری ہونے والا فون QR وہی اوپر والا v2 PairingPayload ہے جو Remote PWA
ہوسٹ کی طرف اشارہ کرتا ہے۔ cc_server pair --client-url ایک مختلف، پرانا v1 لنک
({s, i, k} — سرور URL، ڈیوائس id، کلید) خارج کرتا ہے جو صرف ویب کلائنٹ کے
لیے ہے۔
اِن کی عمر بھی مختلف ہوتی ہے، اور یہاں غلطی کرنا آسان ہے:
| کس نے جاری کیا | اسناد کی میعاد |
|---|---|
ایپ کے اندر پیئرنگ پینل (pairing.mint) |
ہمیشہ 30 دن |
کمانڈ لائن پر cc_server pair |
کوئی نہیں — اسناد میعاد ختم نہیں ہوتیں |
رسائی کا ماڈل
سیکشن کا عنوان “رسائی کا ماڈل”پیئر شدہ ڈیوائس تصدیق شدہ مگر غیر قابلِ اعتماد ہوتی ہے۔ کئی آزاد گیٹ یہ روکتے ہیں کہ کوئی منظور شدہ (یا لیک ہو گئی) پیئرنگ سرور پر مکمل کنٹرول بن جائے۔
1. حد رکنیت ہے، پیئرنگ نہیں
سیکشن کا عنوان “1. حد رکنیت ہے، پیئرنگ نہیں”درست پیئرنگ کلید یہ ثابت کرتی ہے کہ آپ کون سی ڈیوائس ہیں۔ آپ کیا پڑھ یا بدل سکتے ہیں، یہ آپ کا ورک اسپیس کردار طے کرتا ہے — جو ہر ایک کال پر دوبارہ حل ہوتا ہے — اور ریپو کا مواد سامنے لانے والی ہر چیز پر فی ریپو گرانٹس بھی۔ ایسی ڈیوائس جس کے پاس بالکل درست کلید ہو مگر اُس کا صارف نامزد ورک اسپیس کا رکن نہ ہو، “Not a member of this workspace” کے ساتھ مسترد کر دی جاتی ہے۔
کردار کی کم سے کم حد آپریشن کی قسم سے اخذ ہوتی ہے، الا یہ کہ وہ اپنی حد خود بتائے:
پڑھنے کے لیے guest، تبدیلیوں کے لیے member اور تباہ کن آپریشنز کے لیے admin
درکار ہے۔
2. فون ایک نچلے درجے کا سیشن ہے
سیکشن کا عنوان “2. فون ایک نچلے درجے کا سیشن ہے”کردار کی جانچ کے علاوہ، فون سیشن کی صلاحیت ڈیسک ٹاپ یا ویب سیشن سے کم ہوتی ہے۔ جو آپریشنز صرف مکمل کلائنٹ کے لیے قرار دیے گئے ہوں، وہ فون کے لیے ہینڈلر چلنے سے پہلے ہی مسترد کر دیے جاتے ہیں، چاہے اُس کے پیچھے موجود صارف کتنے ہی اختیارات رکھتا ہو: ڈیوائس پیئرنگز جاری کرنا، فہرست بنانا، نام بدلنا اور منسوخ کرنا؛ ٹنل کنیکٹوٹی پڑھنا اور سیٹ کرنا؛ سرور بیک اپ اور ورک اسپیس ایکسپورٹ/امپورٹ؛ پروسیس کی نشان دہی اور قتل؛ اڈاپٹر پروبز؛ سرور ترتیبات؛ SSO ایڈمن؛ فلیٹ کنٹرول؛ اور کسی چلتے ایجنٹ کا کنٹرول سنبھالنا یا واپس دینا۔
3. بطور ڈیفالٹ انکار کرنے والی ٹول اجازت فہرست
سیکشن کا عنوان “3. بطور ڈیفالٹ انکار کرنے والی ٹول اجازت فہرست”خاص طور پر MCP ٹول سطح (tools/call) کے لیے ایک ایسی اجازت فہرست ہے جو بطور
ڈیفالٹ انکار کرتی ہے اور طے کرتی ہے کہ فون کون سے ٹول کال کر سکتا ہے۔ جو فہرست
میں نہ ہو وہ چلنے سے پہلے مسترد ہو جاتا ہے۔ فہرست زیادہ تر پڑھنے اور مشاہدے پر
مبنی ہے، نیز چند صرف مقامی تحریریں — ایک پیغام، ٹکٹ کی اپ ڈیٹ، مضمون پر
نشان — جو نہ LLM بجٹ خرچ کرتی ہیں، نہ کوئی پروسیس شروع کرتی ہیں اور نہ کسی بیرونی
نظام کو چھوتی ہیں۔
مسترد ہیں، مثلاً: کسی ایجنٹ سے مشورہ لینا، AI ریویو شروع کرنا، ایجنٹ کو قتل کرنا، GitHub پر ریویو شائع کرنا، ایجنٹس کی بھرتی یا برخاستگی، اور ورک اسپیس بنانا۔
4. فی کال ورک اسپیس کا دائرہ
سیکشن کا عنوان “4. فی کال ورک اسپیس کا دائرہ”سرور کے پاس کوئی ”موجودہ ورک اسپیس“ نہیں ہوتا۔ یہ بناوٹ ہی سے بے حالت ہے: ہر
ورک اسپیس کے دائرے والی کال کو اپنے دلائل میں ہدف workspace_id بتانا ہوتا ہے اور
ڈسپیچر اُس کال کو فوراً مسترد کر دیتا ہے جب وہ غائب ہو یا ایسا ورک اسپیس بتائے جو
سرور کے پاس رجسٹرڈ نہ ہو — اور یہ سب کچھ کسی ڈیٹا بیس کے کھلنے سے پہلے ہوتا ہے۔
چنانچہ فون نہ کبھی کسی دوسرے کلائنٹ کے دائرے کا وارث بن سکتا ہے اور نہ اُس میں سرک
سکتا ہے، اور کسی اجنبی ورک اسپیس کا نام لینا بھی فائدہ نہیں دیتا، کیونکہ گیٹ 1 کی
رکنیت کی جانچ پھر بھی لاگو ہوتی ہے۔ یہ وہی
ورک اسپیس تنہائی کی لازمی شرط ہے جو
مصنوعات کا باقی حصہ نافذ کرتا ہے۔
5. پری شیئرڈ کلید سے بندھے اینڈ ٹو اینڈ سیل شدہ فریم
سیکشن کا عنوان “5. پری شیئرڈ کلید سے بندھے اینڈ ٹو اینڈ سیل شدہ فریم”فون اور سرور کے درمیان ہر فریم پیئرنگ کلید سے سیل ہوتا ہے؛ داخلہ ٹوکن کسی کلائنٹ کو صرف کمرے میں پہنچاتا ہے، وہ کچھ بھی ڈی کرپٹ نہیں کرتا۔ بروکر خفیہ متن آگے بھیجتا ہے اور کلید کبھی نہیں دیکھتا۔ منسوخ شدہ ڈیوائس اپنی اسناد پہلے ہی غائب پاتی ہے، اس لیے دوبارہ کنکٹ پر وہ بند حالت میں ناکام ہوتی ہے۔
ایپ سے جاری اسناد 30 دن تک محدود ہوتی ہیں؛ اُس کے بعد کنکٹ گیٹ اُنہیں ناکام کر دیتا ہے اور فون کو دوبارہ پیئر کرنا ہوتا ہے۔ منسوخی بروقت ہوتی ہے: سرور ڈیوائس ٹیبل پر نظر رکھتا ہے اور منسوخ شدہ ڈیوائس کے کھلے سیشنز اگلی کنکٹ کا انتظار کرنے کے بجائے سیکنڈوں میں گرا دیتا ہے۔
6. فی پرنسپل ریٹ لمٹنگ
سیکشن کا عنوان “6. فی پرنسپل ریٹ لمٹنگ”ایک سلائیڈنگ ونڈو لیمیٹر ریموٹ ٹول ٹریفک کو 120 کال فی منٹ پر محدود کرتا ہے، اور تبدیلی کرنے والے فعلوں پر 30 فی منٹ کی مزید سخت ذیلی حد ہے۔ یہ بجٹ پرنسپل کا ہے، سیشن کا نہیں: آپ کی تین ڈیوائسز ایک ہی کھاتے سے خرچ کرتی ہیں، اس لیے ہائی جیک ہوا کلائنٹ مزید سیشنز کھول کر گنجائش نہیں خرید سکتا اور کوئی شور مچانے والا رکن باقیوں کو ختم نہیں کر سکتا۔
7. ایسا بروکر جو کچھ نہیں جانتا
سیکشن کا عنوان “7. ایسا بروکر جو کچھ نہیں جانتا”ریلے بروکر جان بوجھ کر سادہ رکھا گیا ہے: یہ کمرے میزبانی میں دیتا ہے، سیل شدہ فریم آگے بھیجتا ہے، اور کوئی اکاؤنٹ، کوئی ایپ ڈیٹا اور کوئی کلید نہیں رکھتا۔ کمرے دعوت نامے سے محدود اور عارضی ہوتے ہیں۔ ایپ ڈیٹا، آڈیو، ٹرانسکرپٹ، سورس اور اسناد سب سرور پر ہی رہتے ہیں۔
لائیو اپ ڈیٹس
سیکشن کا عنوان “لائیو اپ ڈیٹس”پیئر ہونے کے بعد فون کو لائیو اپ ڈیٹس اطلاعاتی فریم کی صورت میں ملتی ہیں — نئے ایجنٹ پیغامات، آپ کو تفویض شدہ ٹکٹس، اسٹیٹس کی تبدیلیاں — جو ڈیسک ٹاپ کی اپنی اطلاعات کی عکاسی کرتی ہیں۔ سرور یہ فریم ہر منسلک سیشن کو نشر کرتا ہے اور ورک اسپیس کا فلٹر کلائنٹ کی طرف لاگو ہوتا ہے، اس لیے جو آپ دیکھتے ہیں وہ اُسی ورک اسپیس تک محدود ہے جو آپ کے سامنے کھلا ہے۔
یہ کہاں رہتا ہے
سیکشن کا عنوان “یہ کہاں رہتا ہے”| سطح | یہ کیا دکھاتی ہے |
|---|---|
ترتیبات → آپ → آپ کی ڈیوائسز (/workspaces/:workspaceId/settings/you/devices) |
لائیو اسٹیٹس کے ساتھ پیئر کلائنٹس، نیز نیا کلائنٹ پیئر کریں (ویب براؤزر، ڈیسک ٹاپ ایپ یا فون) اور منسوخی |
یہی پینل صرف فونز کے لیے نہیں بلکہ دوسرے براؤزر یا ڈیسک ٹاپ ایپ کے لیے بھی پیئرنگز جاری کرتا ہے — طریقہ کار بالکل یکساں ہے، صرف ڈیپ لنک مختلف ہوتا ہے۔
مزید دیکھیں
سیکشن کا عنوان “مزید دیکھیں”- ورک اسپیسز اور تنہائی: فی کال دائرہ بندی جس پر یہ ٹکا ہے
- ملٹی پلیئر — شناخت، رکنیت اور موجودگی: کردار، رکنیت اور ریپو گرانٹس
- ڈیپلائمنٹ اور کلائنٹس: کلائنٹ درجوں میں ریموٹ کنٹرول کہاں بیٹھتا ہے
- آرکیٹیکچر: اسٹیک میں ریموٹ کنٹرول کہاں بیٹھتا ہے
- ڈیوائس پیئر کریں