یہ صفحہ چینی اصل سے ترجمہ کیا گیا ہے۔ اختلاف کی صورت میں اصل متن معتبر ہے۔

Confer — نظام کا آرکیٹیکچر

یہ دستاویز مطلوبہ آرکیٹیکچر بیان کرتی ہے، موجودہ عمل درآمد نہیں۔ ابھی gateway ایک پروسیس، ایک انسٹینس کا ہے: WebSocket کنکشنز کی فہرست، A2A ری پلے تحفظ کے nonce، اور شرحِ حد کے کاؤنٹر — سب کچھ gateway پروسیس کی یادداشت میں رہتا ہے (ws/handler.ts، lib/nonce-cache.ts، middleware/rate-limit.ts)۔

اِسی لیے gateway کی دوسری نقل نہیں چلائی جا سکتی۔ نقل بڑھاتے ہی A2A ری پلے تحفظ خاموشی سے ٹوٹ جاتا ہے — دہرائی گئی درخواست کسی دوسری نقل پر جا پڑتی ہے جہاں nonce کی فہرست خالی ہے، اور سیدھی گزر جاتی ہے۔ ساتھ ہی WS اطلاعات اُن صارفین تک نہیں پہنچتیں جو کسی اور نقل سے جڑے ہیں، اور شرحِ حد کی دہلیز نقلوں کی تعداد سے ضرب کھا جاتی ہے۔

نیچے جن NATS / Redis کا ذکر ہے، وہ افقی توسیع کے لیے سوچی گئی تدبیر ہیں؛ آج وہ نہ تعینات ہیں، نہ کسی سے جڑے ہیں (2026-08-07 کو docker-compose*.yml اور env.ts سے ہٹا دیے گئے؛ اُس سے پہلے وہ خالی گھومتے کنٹینر اور ایک ایسا ماحولیاتی متغیر تھے جسے کبھی پڑھا ہی نہیں گیا)۔ اگر واقعی افقی توسیع کرنی ہو تو پہلے اِن تینوں پروسیس کے اندر کی حالتوں کو مشترکہ ذخیرے میں لے جانا ہوگا — سب سے پہلے nonce، کیونکہ وہی سلامتی کے لحاظ سے نازک ہے۔

اعلیٰ سطحی آرکیٹیکچر

┌────────────────────────────────────────────────────────────┐
│  Clients (Tauri 2.0)                                       │
│  iOS · Android · Windows · macOS · Linux                   │
└──────────────────────────┬─────────────────────────────────┘
                           │ WSS / HTTPS / SSE
                           ▼
┌────────────────────────────────────────────────────────────┐
│  Edge API Gateway  (Bun + Hono)                            │
│  Auth · Rate limit · Routing · WS fan-out                  │
└─────┬─────────────┬─────────────────┬────────────────┬─────┘
      │             │                 │                │
      ▼             ▼                 ▼                ▼
 ┌────────┐  ┌─────────────┐  ┌────────────┐  ┌──────────────┐
 │ Agent  │  │Conversation │  │ Identity & │  │ MCP / Tools  │
 │Runtime │  │     Hub     │  │A2A Gateway │  │  Connector   │
 └───┬────┘  └──────┬──────┘  └─────┬──────┘  └──────┬───────┘
     │              │               │                │
     ▼              ▼               ▼                ▼
┌──────────────────────────────────────────────────────────────┐
│  Data layer: PostgreSQL · Redis · NATS · Vector (Qdrant)·S3 │
└──────────────────────────────────────────────────────────────┘
       │                              │
       ▼                              ▼
 LLM providers              Other instances' Agents
 (Claude / GPT /            (federation via A2A
  DeepSeek / Qwen)           over HTTPS)

ڈیزائن کے اصول

• کنارہ بغیر حالت، مرکز حالت کے ساتھ (ہدف، ابھی نافذ نہیں): بغیر حالت والا اور افقی طور پر بڑھنے کے قابل gateway ہی وہ شکل ہے جس تک پہنچنا ہے؛ آج gateway کے اندر پروسیس کی حالت موجود ہے، اِس لیے وہ صرف ایک انسٹینس میں چل سکتا ہے — اوپر والا نوٹ دیکھیں۔
• پہلے دن سے وفاق کے لیے تیار: DID:web شناخت + AgentFacts، اور اکیلا انسٹینس بھی وفاقی پروٹوکول کے مطابق ہی چلتا ہے، اِس لیے آگے چل کر وفاق میں شامل ہونے کی کوئی منتقلی لاگت نہیں۔
• اپنی LLM کلید لائیے: پلیٹ فارم LLM کی لاگت نہیں اٹھاتا؛ ہر صارف اپنی API کلید استعمال کرتا ہے۔
• پروٹوکول پہلے: بنیادی تعامل کھلے پروٹوکولز سے ہوتا ہے (A2A، MCP، DID:web، NANDA AgentFacts)، کسی نجی پروٹوکول میں بندھے بغیر۔
• پورے اسٹیک میں Bun + TypeScript: بیک اینڈ Bun + Hono، کلائنٹ Tauri + React، ٹائپس مشترک۔

خدمات کی حدود

۱. Edge API Gateway

دیکھیے docs/05-api.md۔

• ذمہ داری: TLS کا اختتام، دوہری شناخت (صارف اور A2A)، چار جہتوں میں شرحِ حد، HTTP/WS/SSE روٹنگ، کئی آلات تک ترسیل۔
• ٹیکنالوجی: Bun + Hono۔
• کلیدی انحصار: JWKS (صارف ٹوکن کی جانچ)، DID دستاویز کیش، NATS (ترسیل)۔
• جو نہیں کرتا: کاروباری منطق، کاروباری ڈیٹا محفوظ کرنا، LLM کو پکارنا۔

۲. Agent Runtime

ہر صارف کے لیے ایک مستقل Agent انسٹینس۔

• ذمہ داری:
  • صارف کے Agent کی حالت رکھنا (ماڈل کا انتخاب، اوزار، پالیسی، یادداشت)۔
  • LLM کالوں کا چکر (کئی فراہم کنندگان کی تجرید)۔
  • MCP کلائنٹ، صارف کے لگائے ہوئے اوزار سرورز سے جڑا ہوا۔
  • باہر جانے والی A2A کالیں (کسی اور کے Agent سے بات کرنے جانا)۔
  • پالیسی انجن (طے کرنا کہ دوسرے فریق کو کیا بتایا جا سکتا ہے)۔
• زندگی کا چکر: طلب پر جاگتا ہے۔ پیغام یا A2A درخواست آتے ہی PostgreSQL سے حالت اٹھاتا ہے، ایک دور چلاتا ہے، اور واپس لکھ دیتا ہے۔
• کلیدی انحصار: LLM فراہم کنندگان، MCP سرورز، شناختی سروس۔

۳. Conversation Hub

• ذمہ داری: پیغامات کا ذخیرہ، رکنیت اور ترسیل۔
• معاون گفتگو کی اقسام:
  • صارف ↔ اپنا Agent۔
  • صارف ↔ کسی اور کا Agent (اپنے Agent کے ذریعے)۔
  • صارف ↔ صارف (عام پیغام رسانی)۔
  • گروپ (صارف اور Agent ملے جلے)۔
• کلیدی انحصار: NATS Streams (پائیداری + ترسیل)، PostgreSQL (پرانے پیغامات)، Redis (موجودگی، اَن پڑھے کی گنتی)۔

۴. Identity & A2A Gateway

• ذمہ داری:
  • صارفین کی DID:web دستاویزات سنبھالنا۔
  • AgentFacts ظاہر کرنا اور کیش کرنا۔
  • آنے والی A2A درخواستیں سنبھالنا (HTTP دستخط اور capability ٹوکن کی جانچ)۔
  • باہر جانے والی A2A درخواستیں آگے بھیجنا۔
  • وفاقی peer کے لیے شرحِ حد اور اسپام کی روک تھام۔
• کلیدی انحصار: PostgreSQL (DID/peer کیش)، Redis (حد کے کاؤنٹر)۔

پروٹوکول کا تفصیلی ڈیزائن docs/03-protocol.md میں ہے۔

۵. MCP / Tools Connector

• ذمہ داری:
  • صارف کے لگائے ہوئے MCP اوزار سرورز کے کنکشن کا انتظام۔
  • Agent Runtime اوزار یہیں سے پکارتا ہے۔
  • اوزار کالوں کے نتائج کی معیاری بندی۔
• کلیدی انحصار: @modelcontextprotocol/sdk۔

ڈیٹا کی تہہ

کلائنٹ کا آرکیٹیکچر

• بنیاد: Tauri 2.0 (Rust کرنل + WebView رینڈرنگ)۔
• فرنٹ اینڈ: React 19 + TypeScript + Tailwind CSS۔
• حالت کا انتظام: Zustand یا Jotai (ہلکے)۔
• روٹنگ: TanStack Router۔
• نیٹ ورک: مقامی fetch + مقامی WebSocket + EventSource (SSE)۔
• مقامی ذخیرہ: Tauri کا فراہم کردہ SQLite + key-value اسٹور (گفتگو کا کیش، آف لائن پیغامات کے مسودے)۔

کثیر پلیٹ فارم رسائی

ایک ہی کوڈ بیس، کوئی مقامی متبادل نہیں۔

Claude Code پلگ ان

دیکھیے docs/06-claude-code-plugin.md۔

• الگ MCP سرور پروسیس، Node.js یا Bun میں لکھا ہوا۔
• صارف claude mcp add confer <command> سے لگاتا ہے۔
• OAuth یا ٹوکن سے صارف کے Confer اکاؤنٹ سے جڑتا ہے۔

تعیناتی کا آرکیٹیکچر

واحد انسٹینس (افراد / چھوٹی ٹیمیں)

اصل docker-compose.prod.yml (agent-runtime اور identity gateway کے اندر کی لائبریریاں ہیں، الگ خدمات نہیں):

  - gateway   (Bun سروس، واحد نقل — اوپر والا نوٹ دیکھیں)
  - client    (nginx کا پیش کردہ فرنٹ اینڈ)
  - migrate   (ایک بار چلنے والا کام)
  - postgres
  - qdrant
  - minio

تعیناتی: docker compose -f docker-compose.prod.yml up -d چلائیے اور کام شروع۔

ادارے کا انسٹینس

• وہی Docker Compose ایک خودمختار تعیناتی کے طور پر۔
• اپنے ڈومین کے ساتھ (acme.com)۔
• https://acme.com/.well-known/did.json اور https://acme.com/.well-known/agent.json ظاہر کرتے ہوئے۔
• اندرونی صارفین SSO سے لاگ اِن کرتے ہیں۔

کلاؤڈ (Confer کا اپنا کلاؤڈ)

پیشگی شرط: gateway اِس وقت واحد نقل ہے (حالت پروسیس کے اندر)۔ کئی نقلیں کرنے سے پہلے WS کنکشن فہرست، A2A nonce اور حد کے کاؤنٹر مشترکہ ذخیرے میں لے جانے ہوں گے، ورنہ ری پلے تحفظ خاموشی سے بیکار ہو جائے گا۔

• کثیر کرایہ دار Kubernetes۔
• ہر صارف یا ادارے کا اپنا namespace یا schema۔
• مشترکہ LLM فراہم کنندہ تجریدی تہہ (مگر کلید پھر بھی اپنی اپنی)۔
• دنیا بھر میں کئی خطوں میں تعیناتی، قریب ترین خطے سے داخلہ۔

وفاق (انسٹینسز کے درمیان)

Confer کا کوئی بھی انسٹینس — خود میزبان ہو یا کلاؤڈ کا — A2A پروٹوکول سے دوسرے انسٹینسز کے ساتھ رابطہ کر سکتا ہے۔

[acme.com]              [vendor-x.com]            [confer.cloud]
 Agent A    <─── A2A ───> Agent B    <─── A2A ───> Agent C

شناخت اور دریافت:

• ہر انسٹینس /.well-known/did.json پر اپنی DID دستاویز ظاہر کرتا ہے۔
• ہر Agent /.well-known/agent.json پر اپنے AgentFacts ظاہر کرتا ہے۔
• انسٹینسز کے درمیان تلاش: معلوم انسٹینسز تک ترسیل + عوامی رجسٹری۔

قابلِ مشاہدگی

• ٹریسنگ: OpenTelemetry؛ trace_id gateway میں ڈالا جاتا ہے اور تمام خدمات سے گزرتا ہے۔
• لاگ: ساختہ JSON، Vector / Loki سے جمع۔
• میٹرکس: Prometheus۔ اہم ترین:
  • gateway_active_ws_connections{user_id}
  • agent_runtime_llm_tokens_total{provider,role}
  • a2a_inbound_requests_total{peer_domain,status}
  • mcp_tool_calls_total{tool,result}

سلامتی کی حدود

• صارف ↔ gateway: JWKS سے جانچا گیا JWT۔
• A2A peer ↔ gateway: HTTP Message Signatures (RFC 9421) + DID:web عوامی کلید۔
• خدمات کے درمیان اندرونی RPC: mTLS یا مشترکہ راز (Docker نیٹ ورک کے اندر)۔
• LLM فراہم کنندہ کو کال: API کلید خفیہ کاری کے ساتھ محفوظ (AES-256، کلید Vault / KMS میں)۔
• صارفین کی فائلیں: S3 کی سرور سائیڈ خفیہ کاری۔

کلیدی تکنیکی فیصلے