यह पृष्ठ चीनी मूल से अनूदित है। दोनों में अंतर होने पर मूल पाठ मान्य है।

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, टाइप साझा।

सेवाओं की सीमाएँ

1. Edge API Gateway

देखें docs/05-api.md।

• ज़िम्मेदारी: TLS समाप्ति, दोहरी पहचान (उपयोगकर्ता और A2A), चार आयामों में दर-सीमा, HTTP/WS/SSE रूटिंग, कई उपकरणों तक प्रसार।
• तकनीक: Bun + Hono।
• मुख्य निर्भरताएँ: JWKS (उपयोगकर्ता टोकन की जाँच), DID दस्तावेज़ कैश, NATS (प्रसार)।
• जो नहीं करता: व्यावसायिक तर्क, व्यावसायिक डेटा सहेजना, LLM को बुलाना।

2. Agent Runtime

हर उपयोगकर्ता के लिए एक स्थायी Agent इंस्टेंस।

• ज़िम्मेदारी:
  • उपयोगकर्ता के Agent की अवस्था रखना (मॉडल का चुनाव, औज़ार, नीति, स्मृति)।
  • LLM कॉल का चक्र (कई प्रदाताओं का अमूर्तन)।
  • MCP क्लाइंट, उपयोगकर्ता द्वारा लगाए गए औज़ार-सर्वरों से जुड़ा हुआ।
  • बाहर जाने वाली A2A कॉल (किसी और के Agent से बात करने जाना)।
  • नीति इंजन (तय करना कि दूसरे पक्ष को क्या बताया जा सकता है)।
• जीवनचक्र: माँग पर जागता है। संदेश या A2A अनुरोध आते ही PostgreSQL से अवस्था लोड करता है, एक दौर चलाता है, और वापस लिख देता है।
• मुख्य निर्भरताएँ: LLM प्रदाता, MCP सर्वर, पहचान सेवा।

3. Conversation Hub

• ज़िम्मेदारी: संदेशों का भंडारण, सदस्यता और वितरण।
• समर्थित संवाद प्रकार:
  • उपयोगकर्ता ↔ अपना Agent।
  • उपयोगकर्ता ↔ दूसरे का Agent (अपने Agent के ज़रिए)।
  • उपयोगकर्ता ↔ उपयोगकर्ता (साधारण संदेश)।
  • समूह (उपयोगकर्ता और Agent मिलेजुले)।
• मुख्य निर्भरताएँ: NATS Streams (स्थायित्व + प्रसार), PostgreSQL (पुराने संदेश), Redis (उपस्थिति, अपठित की गिनती)।

4. Identity & A2A Gateway

• ज़िम्मेदारी:
  • उपयोगकर्ताओं के DID:web दस्तावेज़ संभालना।
  • AgentFacts उजागर करना और कैश करना।
  • आने वाले A2A अनुरोध संभालना (HTTP हस्ताक्षर और capability टोकन की जाँच)।
  • बाहर जाने वाले A2A अनुरोध आगे भेजना।
  • फ़ेडरेटेड peer के लिए दर-सीमा और स्पैम-रोक।
• मुख्य निर्भरताएँ: PostgreSQL (DID/peer कैश), Redis (सीमा के काउंटर)।

प्रोटोकॉल का विस्तृत डिज़ाइन docs/03-protocol.md में है।

5. 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 + की-वैल्यू स्टोर (संवाद का कैश, ऑफ़लाइन संदेशों के मसौदे)।

बहु-मंच पहुँच

एक ही कोडबेस, कोई नेटिव विकल्प नहीं।

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 का सर्वर-साइड एन्क्रिप्शन।

मुख्य तकनीकी निर्णय