# 三种联邦通信架构对比

> 源文件：`三种联邦通信架构.drawio`

当 AID1（Issuer A）需要向 AID2（Issuer B）发送消息时，跨域流量如何路由？以下三种架构各有取舍。

---

## 模式一：服务直连远端 Gateway

```
┌─ Issuer A ──────────────────────────┐    ┌─ Issuer B ──────────────┐
│ Auth  Message  Group  Storage  Mail │    │        Gateway          │
│         │╌╌╌╌╌╌╌│╌╌╌╌╌╌╌╌╌╌╌╌│─────┼───▶│   Message  Group  Mail │
│              Gateway                │    │          ▲              │
│                ▲                    │    └──────────┼──────────────┘
└────────────────┼────────────────────┘              AID2
                AID1
```

**机制**：每个服务（Message/Group/Mail）独立发现并直连远端 Gateway，完成跨域 RPC。

| 优点 | 缺点 |
|------|------|
| 实现直接，延迟最低（一跳） | 每个服务都要实现联邦发现与连接逻辑 |
| 服务可独立选择路由策略 | 对外暴露多个出口，安全攻击面大 |
| | 服务与远端 Gateway 地址耦合 |

---

## 模式二：Gateway-to-Gateway 中继

```
┌─ Issuer A ──────────────────────────┐    ┌─ Issuer B ──────────────┐
│ Auth  Message  Group  Storage  Mail │    │        Gateway          │
│           ↕                         │    │     ↕                   │
│         Gateway ────────────────────┼───▶│   Message  Group  Mail │
│           ▲                         │    │          ▲              │
└───────────┼─────────────────────────┘    └──────────┼──────────────┘
           AID1                                      AID2
```

**机制**：所有跨域流量统一由本端 Gateway 转发到远端 Gateway，服务只和本地 Gateway 通信。

| 优点 | 缺点 |
|------|------|
| 服务零联邦逻辑，只感知本地 Gateway | Gateway 职责过重（客户端接入 + 联邦路由） |
| 单一安全出口，易于审计和限流 | Gateway 成为性能瓶颈和单点 |
| 部署简单，无额外组件 | 联邦路由演进需要改动 Gateway 核心 |

---

## 模式三：Federation Gateway 独立模块

```
┌─ Issuer A ──────────────┬──────┐    ┌──────┬─ Issuer B ──────────┐
│ Message  Group  Mail    │ Fed  │    │ Fed  │      Gateway        │
│    │                    │  GW ◀┼────┼▶ GW  │    ↕                │
│    └───────────────────▶│      │    │      │  Message Group Mail │
│         Gateway         │      │    │      │        ▲            │
│           ▲             └──────┘    └──────┘        │            │
└───────────┼─────────────────────┘    └──────────────┼────────────┘
           AID1                                      AID2
```

**机制**：引入独立的 Fed Gateway 模块专门处理跨域通信。本地服务 → Fed GW(A) → Fed GW(B) → 远端服务。

| 优点 | 缺点 |
|------|------|
| 职责分离：Gateway 管接入，Fed GW 管联邦 | 多一跳，延迟略增 |
| Fed GW 可独立扩缩容、独立演进 | 部署复杂度增加 |
| 单一安全出口 | 需要定义 Fed GW 之间的协议 |
| 服务零联邦逻辑 | |

---

## 核心差异总结

| 维度 | 模式一：服务直连 | 模式二：GW-to-GW | 模式三：Fed Gateway |
|:-----|:---:|:---:|:---:|
| 联邦逻辑位置 | 各服务内部 | Gateway | 独立 Fed GW 模块 |
| 服务是否感知远端 | 是 | 否 | 否 |
| Gateway 职责 | 仅客户端接入 | 接入 + 联邦 | 仅客户端接入 |
| 安全出口数量 | 多个 | 单一 | 单一 |
| 延迟（跳数） | 1 | 2 | 3 |
| 扩展性 | 差（每服务改） | 中（GW 重） | 好（独立扩缩） |
| 部署复杂度 | 低 | 低 | 中 |
| 协议演进影响 | 全部服务 | Gateway | 仅 Fed GW |

---

## 经典联邦系统架构参照

### SMTP（电子邮件）

```
[User-A] → MUA → MSA(A) → MTA(A) ──DNS MX──▶ MTA(B) → MDA(B) → [User-B]
```

- **联邦发现**：DNS MX 记录
- **跨域传输**：MTA-to-MTA（SMTP，端口 25/587）
- **架构模式**：接近**模式二**——MTA 同时负责本域投递和跨域路由
- **特点**：MTA 职责重（反垃圾、TLS、DKIM、SPF、DMARC 全在 MTA 层），但 40 年实践证明足够可靠；无实时性要求，队列重试容错

### XMPP（Jabber）

```
[Client-A] → C2S → Server(A) ──DNS SRV + S2S──▶ Server(B) → C2S → [Client-B]
```

- **联邦发现**：DNS SRV 记录（`_xmpp-server._tcp.domain`）
- **跨域传输**：S2S（Server-to-Server，XMPP over TCP/TLS）
- **架构模式**：**模式二**——单一 Server 进程同时处理 C2S（客户端接入）和 S2S（联邦路由）
- **特点**：Server 承担所有职责（认证、消息路由、MUC 群聊、联邦）；大规模部署时 S2S 连接数成为瓶颈（每对域维持一条 TCP），ejabberd/Prosody 通过连接池缓解

### Matrix

```
[Client-A] → CS API → Homeserver(A) ──Federation API──▶ Homeserver(B) → CS API → [Client-B]
```

- **联邦发现**：`GET https://domain/.well-known/matrix/server` → 返回 `server` 地址
- **跨域传输**：Federation API（HTTPS，Server-Server API）
- **架构模式**：**模式二**——Homeserver 同时负责 Client-Server API 和 Server-Server Federation API
- **特点**：基于 DAG（有向无环图）的事件复制模型，每个房间的完整历史在所有参与 Homeserver 间同步；Federation API 是独立的 HTTP 端点集，但仍运行在同一 Homeserver 进程内

### ActivityPub（Fediverse：Mastodon 等）

```
[User-A] → Client API → Server(A) ──HTTP POST Inbox──▶ Server(B) → [User-B]
```

- **联邦发现**：WebFinger（`GET https://domain/.well-known/webfinger?resource=acct:user@domain`）
- **跨域传输**：HTTP POST 到目标 Actor 的 Inbox（HTTP Signatures 认证）
- **架构模式**：接近**模式一**——每个 Actor（用户/服务）直接向远端 Inbox 投递，无统一路由层
- **特点**：无中心路由，每条消息独立投递；适合"发布-订阅"模型（社交动态），不适合实时双向通信；签名验证在接收端逐条进行

### AT Protocol（Bluesky）

```
[Client] → AppView → PDS(A) ──Relay/Firehose──▶ PDS(B) → AppView → [Client]
```

- **联邦发现**：DID（去中心化标识符）+ DNS handle 解析
- **跨域传输**：Relay（BigSky Firehose）聚合所有 PDS 的 commit 流，AppView 消费并索引
- **架构模式**：**模式三的变体**——Relay 作为独立的联邦中继层，PDS（个人数据服务器）不直接互联
- **特点**：PDS 只管数据托管，Relay 聚合全网事件流，AppView 做业务视图；分层极致但 Relay 目前事实上中心化

---

## 经典系统与 AUN 三种模式的对应关系

| 系统 | 联邦发现 | 跨域传输 | 最接近模式 | 关键差异 |
|:-----|:---------|:---------|:----------:|:---------|
| **SMTP** | DNS MX | MTA→MTA (SMTP) | 模式二 | 异步队列，无实时性要求 |
| **XMPP** | DNS SRV | S2S (TCP/TLS) | 模式二 | 长连接，每对域一条 TCP |
| **Matrix** | .well-known | Federation API (HTTPS) | 模式二 | DAG 事件同步，房间状态全量复制 |
| **ActivityPub** | WebFinger | HTTP POST Inbox | 模式一 | 无统一路由，逐条投递 |
| **AT Protocol** | DID + DNS | Relay Firehose | 模式三 | Relay 聚合全网，分层极致 |
| **AUN** | .well-known/aun-gateway | Gateway WS/WSS | 待定 | 实时 WebSocket + 多服务协议 |

### 对 AUN 的启示

1. **SMTP/XMPP/Matrix 都选了模式二**——说明"单一出口 + 统一路由"在实践中最可靠，XMPP 和 Matrix 都是实时通信场景
2. **ActivityPub 的模式一看似简单，但在 AUN 场景不适用**——AUN 有 Message/Group/Storage/Mail 多个服务，若每个都自行联邦，复杂度爆炸
3. **AT Protocol 的模式三最接近 AUN 的 Fed Gateway 方案**——独立中继层，PDS 不感知彼此；但 AT 的 Relay 目前中心化，AUN 的 Fed GW 是对等的
4. **Matrix 的 .well-known 发现机制**与 AUN 的 `/.well-known/aun-gateway` 设计一致，说明这个方向是对的
