multi-agent-protocol 0.0.3 → 0.0.6

package/README.md

@@ -107,3 +107,7 @@ The protocol defines 27 methods across three tiers:
 ## License
 
 MIT
+
+## Authors
+
+Created and maintened by the [sudocode](https://github.com/sudocode-ai) team.

package/docs/00-design-specification.md

@@ -155,6 +155,16 @@ interface MAPParticipantCapabilities {
   // Scope management
   canCreateScopes: boolean;
   canManageScopes: boolean;
+
+  // Mail (conversations/turns) - extension
+  mail?: {
+    enabled?: boolean;              // Server supports mail (response only)
+    canCreate?: boolean;            // Can create conversations
+    canJoin?: boolean;              // Can join conversations
+    canInvite?: boolean;            // Can invite participants
+    canViewHistory?: boolean;       // Can view conversation history
+    canCreateThreads?: boolean;     // Can create threads
+  };
 }
 ```
 
@@ -318,6 +328,14 @@ interface MAPMessage {
     isResult?: boolean;
     priority?: "urgent" | "high" | "normal" | "low";
     delivery?: "fire-and-forget" | "acknowledged" | "guaranteed";
+
+    // Mail turn tracking (optional extension)
+    mail?: {
+      conversationId: string;       // Record as turn in this conversation
+      threadId?: string;            // Optionally assign to thread
+      inReplyTo?: string;           // Turn ID this is replying to
+      visibility?: TurnVisibility;  // Who can see this turn
+    };
   };
 }
 ```
@@ -421,8 +439,25 @@ type MAPAddress =
 // FEDERATION
 "map/federation/connect"    // Connect to peer MAP system
 "map/federation/route"      // Route message to peer system
+
+// MAIL (Conversations, Turns, Threads)
+"mail/create"           // Create a conversation
+"mail/get"              // Get conversation details with optional includes
+"mail/list"             // List conversations with filtering
+"mail/close"            // Close a conversation
+"mail/join"             // Join a conversation with optional catch-up
+"mail/leave"            // Leave a conversation
+"mail/invite"           // Invite a participant to a conversation
+"mail/turn"             // Record a turn in a conversation
+"mail/turns/list"       // List turns with filtering and pagination
+"mail/thread/create"    // Create a thread within a conversation
+"mail/thread/list"      // List threads in a conversation
+"mail/summary"          // Get or generate a conversation summary
+"mail/replay"           // Replay conversation turns from a point
 ```
 
+> See [10-mail-protocol.md](10-mail-protocol.md) for the full Mail Protocol specification.
+
 ---
 
 ## Design Decisions Summary
@@ -450,6 +485,7 @@ type MAPAddress =
 - [06-visibility-permissions.md](06-visibility-permissions.md): Visibility & Permission Model
 - [07-federation.md](07-federation.md): Federation & System-to-System Communication
 - [08-macro-agent-migration.md](08-macro-agent-migration.md): macro-agent Migration Example
+- [10-mail-protocol.md](10-mail-protocol.md): Mail Protocol (Conversations, Turns, Threads)
 
 ---
 

package/docs/01-open-questions.md

@@ -1048,8 +1048,3 @@ Child specs where these questions originated:
 - Connection Model & Client Patterns (05-connection-model.md)
 - Visibility & Permission Model (06-visibility-permissions.md)
 - Federation & System-to-System Communication (07-federation.md)
-
-External references:
-- [A2A Protocol Specification](https://google.github.io/A2A/specification/) - Artifacts and task model
-- [ACP SDK](https://github.com/anthropics/acp) - Capability negotiation patterns
-- [Agent Interoperability Survey](https://arxiv.org/html/2505.02279v1) - Protocol comparison

package/docs/02-wire-protocol.md

@@ -278,7 +278,7 @@ interface StdioTransport {
 {
   "jsonrpc": "2.0",
   "id": "ext_001",
-  "method": "anthropic.macro/workspace.sync",
+  "method": "macro/workspace.sync",
   "params": {
     "worktree": "/path/to/worktree",
     "remote": "origin/main"

package/docs/07-federation.md

@@ -206,18 +206,94 @@ Sensitive computation isolated in secure system, federated for I/O.
 
 ---
 
+## Single-Request Federation Auth
+
+Federation connection can be completed in a single round-trip by including auth credentials in the initial `map/federation/connect` request. When the server can validate the credentials immediately, it returns a fully authenticated response — reducing setup from 2 RTT to 1 RTT.
+
+### Flow: Single-Request Auth (Optimized)
+
+```
+System A                                      System B
+   │                                              │
+   │──── map/federation/connect ─────────────────►│
+   │     { systemId, endpoint, auth: { ... } }    │
+   │                                              │ ← Validates auth inline
+   │◄─── response ────────────────────────────────│
+   │     { connected: true, sessionId, principal } │
+   │                                              │
+```
+
+### Flow: Auth Negotiation Fallback
+
+If no credentials are provided, or validation fails recoverably, the server returns auth requirements:
+
+```
+System A                                      System B
+   │                                              │
+   │──── map/federation/connect ─────────────────►│
+   │     { systemId, endpoint }                   │
+   │                                              │
+   │◄─── response ────────────────────────────────│
+   │     { connected: false,                      │
+   │       authRequired: { methods, challenge } } │
+   │                                              │
+   │──── map/federation/connect ─────────────────►│
+   │     { systemId, endpoint, auth: { ... },     │
+   │       authContext: { challenge } }            │
+   │                                              │
+   │◄─── response ────────────────────────────────│
+   │     { connected: true, sessionId, principal } │
+   │                                              │
+```
+
+---
+
 ## Security Considerations
 
 ### Authentication
 
 ```typescript
+type FederationAuthMethod =
+  | "bearer" | "api-key" | "mtls" | "none"
+  | "did:wba" | "oauth2" | `x-${string}`;
+
 type MAPFederationAuth =
-  | { method: "mutual-tls"; certificate: string }
-  | { method: "bearer"; token: string }
-  | { method: "api-key"; key: string }
-  | { method: "oauth2"; config: OAuth2Config };
+  | { method: FederationAuthMethod; credentials?: string; metadata?: Record<string, unknown> }
+  | DIDWBACredentials;
+
+interface DIDWBACredentials {
+  method: "did:wba";
+  metadata: { did: string; proof: DIDWBAProof };
+}
 ```
 
+#### `did:wba` — Decentralized Identity for Federation
+
+The `did:wba` method enables domain-anchored decentralized identity for federation. An identity like `did:wba:agents.example.com:gateway` resolves to a DID document at `https://agents.example.com/gateway/did.json` containing public keys and MAP service endpoints.
+
+**Authentication flow:**
+1. Connecting system provides its DID and a cryptographic proof (ECDSA P-256 over challenge nonce)
+2. Receiving system resolves the DID document via HTTPS
+3. Receiving system verifies the proof against the public key in the DID document
+4. On success, the connecting system is authenticated as the DID principal
+
+```json
+{
+  "method": "did:wba",
+  "metadata": {
+    "did": "did:wba:agents.example.com:gateway",
+    "proof": {
+      "type": "JsonWebSignature2020",
+      "created": "2026-02-10T12:00:00.000Z",
+      "challenge": "map_chal_01ABCDEFGHJ0123456789AB",
+      "jws": "eyJhbGciOi..."
+    }
+  }
+}
+```
+
+See `docs/09-authentication.md` for full details on all auth methods including `did:wba`, and `docs/11-anp-inspired-improvements.md` Proposal 1 for the design rationale.
+
 ### Message Signing
 
 ```typescript
@@ -253,7 +329,7 @@ interface MAPFederationQueueConfig {
 ## Open Questions
 
 1. **Transitive federation**: If A↔B and B↔C, can A route to C via B?
-2. **Federation discovery**: Should there be a discovery mechanism for finding peers?
+2. ~~**Federation discovery**: Should there be a discovery mechanism for finding peers?~~ — Partially addressed by `did:wba` (DID document service endpoints) and proposed `.well-known` discovery (see `docs/11-anp-inspired-improvements.md` Proposal 2).
 3. **Consistency**: How to handle concurrent updates across federated systems?
 4. **Schema versioning**: What if peers have different protocol versions?
 5. **Audit requirements**: What federation activity must be logged?