এই পাতাটি চীনা মূল থেকে অনূদিত। দুটির মধ্যে অমিল হলে মূল পাঠই প্রামাণ্য।

Confer — সিস্টেম আর্কিটেকচার

এই নথি লক্ষ্য আর্কিটেকচার বর্ণনা করে, বর্তমান বাস্তবায়ন নয়। এখনকার gateway এক প্রসেস, এক ইনস্ট্যান্স: WebSocket সংযোগের তালিকা, A2A রিপ্লে-সুরক্ষার nonce আর হার-সীমার কাউন্টার — সবই gateway প্রসেসের স্মৃতিতে থাকে (ws/handler.ts, lib/nonce-cache.ts, middleware/rate-limit.ts)।

তাই gateway-এর দ্বিতীয় রেপ্লিকা চালানো যায় না। রেপ্লিকা যোগ করলেই A2A রিপ্লে-সুরক্ষা নিঃশব্দে ভেঙে পড়ে — পুনরাবৃত্ত অনুরোধ অন্য রেপ্লিকায় গিয়ে পড়ে, যেখানে nonce তালিকা ফাঁকা, আর সোজা ছাড়পত্র পেয়ে যায়। পাশাপাশি WS বিজ্ঞপ্তি সেই ব্যবহারকারীদের কাছে পৌঁছায় না যাঁরা অন্য রেপ্লিকায় যুক্ত, আর হার-সীমার থ্রেশহোল্ড রেপ্লিকার সংখ্যা দিয়ে গুণ হয়ে যায়।

নিচে যে NATS / Redis-এর কথা আছে, সেগুলো অনুভূমিক সম্প্রসারণের জন্য ভাবা পরিকল্পনা; আজ সেগুলো মোতায়েনও নেই, কোথাও যুক্তও নেই (২০২৬-০৮-০৭-এ 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 + কী-ভ্যালু স্টোর (কথোপকথনের ক্যাশ, অফলাইন বার্তার খসড়া)।

বহু-প্ল্যাটফর্ম বিস্তার

একটিই কোডবেস, কোনো নেটিভ বিকল্প নেই।

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-এর সার্ভার-সাইড এনক্রিপশন।

মূল প্রযুক্তিগত সিদ্ধান্ত