@agentunion/fastaun-browser 0.2.19 → 0.2.20

package/_packed_docs/protocol/aun-docs-guide.md

@@ -0,0 +1,49 @@
+# AUN 协议文档查阅指南
+
+AUN 协议文档在 `docs/AUN文档/AUN协议/` 下，索引文件 `index.md` 分三层，**严格按需逐层加载，禁止一次性读取整个索引**。
+
+## 文档架构
+
+AUN 协议采用**主协议 + 子协议**架构：
+
+```
+主协议文档
+├── 00-总览与分层.md          ← 协议入口，分层架构、三种模式总览
+├── 02-证书与信任体系.md      ← AID 身份、证书链、信任模型
+└── 09-安全考虑.md            ← 威胁模型、安全分析
+
+子协议文档
+├── 01-身份与凭证协议-auth.md  ← auth.* 方法、JWT Token
+├── 03-Gateway-连接模式.md     ← Gateway 模式、auth.connect
+├── 04-Peer-子协议.md          ← peer.* 对等认证
+└── 05-Relay-子协议.md         ← relay.* 中继传输
+
+业务层与公共基础
+├── 06-服务协议.md             ← message/meta/search/task + 跨域消息路由
+├── 07-错误码与状态机.md       ← 错误码汇总、状态机
+└── 08-AUN-E2EE.md               ← E2EE 安全层（横跨三种模式）
+```
+
+## 渐进式查阅流程
+
+1. **Step 1**：读 `index.md` 的 Layer 1（文档地图），快速定位目标文档
+2. **Step 2**：按需读 Layer 2（概念索引），根据概念找到对应章节
+3. **Step 3**：按需读 Layer 3（文档摘要），了解某篇文档的内容概览
+4. **Step 4**：精确读原文对应章节
+
+## 常见查阅场景
+
+| 我想了解... | 先看 |
+|------------|------|
+| AUN 是什么、整体架构 | 00-总览与分层.md |
+| AID 创建和登录流程 | 01-身份与凭证协议-auth.md |
+| 证书体系和信任模型 | 02-证书与信任体系.md |
+| Gateway 模式接入 | 03-Gateway-连接模式.md |
+| Peer 直连认证 | 04-Peer-子协议.md |
+| Relay 中继 | 05-Relay-子协议.md |
+| 消息收发、搜索、任务 | 06-服务协议.md |
+| 错误码和状态机 | 07-错误码与状态机.md |
+| E2EE 加密 | 08-AUN-E2EE.md |
+| 安全威胁和防护 | 09-安全考虑.md |
+| 客户端接入代码示例 | 附录J-客户端接入示例.md |
+| SDK 设计 | ../../AUN-SDK-跨语言设计方案.md |

package/_packed_docs/protocol/index.md

@@ -0,0 +1,114 @@
+# AUN 协议文档索引
+
+> 渐进式三层结构。Layer 1 极简地图；Layer 2 概念倒排索引；Layer 3 每篇文档的详细摘要。
+
+---
+
+## Layer 1: 文档地图
+
+| 编号 | 文件 | 职责 |
+|:----:|------|------|
+| 00 | [00-总览与分层.md](00-总览与分层.md) | 协议目标、核心原则、四层架构、三种连接模式、文档导航 |
+| 01 | [01-身份与凭证协议-auth.md](01-身份与凭证协议-auth.md) | `auth.*` 方法定义、AID/证书/私钥/token 关系、JWT 机制 |
+| 02 | [02-证书与信任体系.md](02-证书与信任体系.md) | AID 体系、四级证书链、信任模型、吊销机制 |
+| 03 | [03-Gateway-连接模式.md](03-Gateway-连接模式.md) | Gateway 模式定位、auth.connect 握手、心跳重连 |
+| 04 | [04-Peer-子协议.md](04-Peer-子协议.md) | `peer.*` 对等认证四步握手、nonce 签名、状态机 |
+| 05 | [05-Relay-子协议.md](05-Relay-子协议.md) | `relay.*` 中继注册转发、透明封装、与 peer.* 关系 |
+| 06 | [06-服务协议.md](06-服务协议.md) | 业务层：message.* / meta.* / search.* / task.* / group.* + 跨域消息路由 |
+| 07 | [07-错误码与状态机.md](07-错误码与状态机.md) | 错误码汇总、各模式状态机、重试分类 |
+| E2EE | [08-AUN-E2EE.md](08-AUN-E2EE.md) | 端到端加密安全层（横跨三种模式） |
+| E2EE-Group | [08-AUN-E2EE-Group.md](08-AUN-E2EE-Group.md) | 群组 E2EE：Epoch Group Key、Membership Commitment、密钥恢复 |
+| 09 | [09-安全考虑.md](09-安全考虑.md) | 威胁模型、防护措施、升级安全、验签时序 |
+| 10 | [10-Group-子协议.md](10-Group-子协议.md) | `group.*` 群组管理、群消息、邀请码、资源共享、在线状态 |
+| 11 | [11-Storage-子协议.md](11-Storage-子协议.md) | `storage.*` 对象存储、大文件上传下载、预签名 URL |
+| 12 | [12-Stream-子协议.md](12-Stream-子协议.md) | `stream.*` 实时流式传输、WebSocket 推流、HTTP SSE 拉流、跨域拉流 |
+
+**附录**：A-术语表 | B-扩展性 | C-私钥管理 | D-Root CA 治理 | E-Root CA 准入 | F-Issuer CA 申请 | G-孤儿 AID | H-Auth 实现 | I-跨域消息路由 | J-客户端接入 | K-Agent Web | L-E2EE 实现 | M-JWT 实现
+
+---
+
+## Layer 2: 概念索引
+
+| 概念 | 对应文档 |
+|------|---------|
+| AID 身份体系 | 00 §0.5, 02 §2.1-2.2 |
+| 证书链（Root CA → Issuer CA → Agent） | 02 §2.3-2.4 |
+| 证书吊销（CRL/OCSP） | 02 §2.5 |
+| 受信根证书列表 | 02 §2.2, 06 meta.trust_roots, 附录D §D.7 |
+| CT 公开查询服务（ct.{issuer}） | 06 CT 公开 HTTP 端点, 附录D §D.8, 附录F §F.9 |
+| AID 创建（auth.create_aid） | 01 §1.3 |
+| 两阶段登录（auth.aid_login1/2） | 01 §1.4 |
+| JWT Token 机制 | 01 §1.7 |
+| 证书续期与轮转（renew/rekey） | 01 §1.6 |
+| Gateway 连接模式 | 03 |
+| auth.connect 握手 | 03 §3.5 |
+| Peer 对等认证 | 04 |
+| Relay 中继传输 | 05 |
+| 消息收发（message.*） | 06 §6.2 |
+| 连接升级（peer.offer/switch） | 06 §6.2 连接升级控制消息 |
+| Agent 搜索与发现（search.*） | 06 §6.4 |
+| agent.md 规范 | 06 §6.4, 附录K |
+| 任务协作（task.*） | 06 §6.5 |
+| 跨域消息路由 | 06 §6.7 |
+| E2EE 端到端加密 | AUN-E2EE, 06 §6.6 |
+| 群组管理（group.*） | 10 |
+| 群消息收发（group.send/pull） | 10 §10.5 |
+| 群成员权限（owner/admin/member） | 10 §10.2 |
+| 邀请码（group.create_invite_code） | 10 §10.7 |
+| 群资源共享（group.resources.*） | 10 §10.9 |
+| 对象存储（storage.*） | 11 |
+| 实时流传输（stream.*） | 12 |
+| 推流（WebSocket） | 12 §12.6 推流端点 |
+| 拉流（HTTP SSE） | 12 §12.6 拉流端点 |
+| 跨域拉流 | 12 §12.7 |
+| 错误码 | 07 §7.1 |
+| 连接状态机 | 07 §7.3 |
+| 威胁模型与安全 | 09 |
+| 私钥管理 | 附录C |
+| 客户端接入示例 | 附录J |
+
+---
+
+## Layer 3: 文档摘要
+
+### 00-总览与分层
+协议总入口。定义 AUN 协议目标、核心原则（Gateway 非唯一入口、业务层拓扑无关等）、四层架构概览（安全层 → 通信层 → 协议层 → 服务层）、三种连接模式对比、角色拆分和文档导航。
+
+### 01-身份与凭证协议-auth
+定义 `auth.*` 8 个方法：create_aid、aid_login1/2、refresh_token、download_cert、renew_cert、rekey、request_cert。包含 JWT Token 签发/验证机制和安全约束。
+
+### 02-证书与信任体系
+AID 格式与命名规则、AUN 网络与根证书管理局、四级证书链（Root CA → Registry CA → Issuer CA → Agent）、终端证书生命周期状态、信任模型与共识场景、CRL/OCSP 吊销机制、CT 公开查询入口概述。
+
+### 03-Gateway-连接模式
+Gateway 模式定位与职责、Gateway 发现机制、连接时序（auth.* → auth.connect → READY）、auth.connect 请求/响应格式、心跳与重连策略。
+
+### 04-Peer-子协议
+`peer.*` 4 个方法：hello、hello_reply、confirm、confirmed。对称 challenge-response 双向认证，不依赖 JWT。状态机、证书链验证规则、nonce 签名规则、Peer 地址发现。
+
+### 05-Relay-子协议
+`relay.*` 3 个方法：register、forward、event/relay.message。Relay 职责边界（零信任笨管道）、透明封装规则、与 peer.* 配合完成端到端认证。
+
+### 06-服务协议（业务层）
+认证后可用的业务方法：auth.*（身份管理）、ca.*（证书管理）、message.*（P2P 消息、E2EE prekey、`payload.type` 负载类型）、meta.*（心跳、状态、受信根）、storage.*（文件存储）、group.*（群组）、mail.*（邮件）、stream.*（流式传输）、search.*（Agent 发现）、relay.*（中继）、peer.*（点对点）、task.*（协作任务）。同时列出 `pki.{issuer}` 与 `ct.{issuer}` 等公开 HTTP 端点入口。
+
+### 07-错误码与状态机
+错误码分层汇总（JSON-RPC 通用 + AUN 协议级 + Peer/Relay/Search/Task/升级扩展码）。三种连接模式状态机。任务状态机。可重试/不可重试分类。
+
+### AUN-E2EE
+独立安全层，横跨三种连接模式。定义客户端间 E2EE 加解密（prekey_ecdh_v2 四路 ECDH / long_term_key 两级降级）、prekey 管理、密文格式、AAD 防篡改、防重放保护。无需在线协商。
+
+### AUN-E2EE-Group
+群组端到端加密规范。Epoch Group Key 机制（group_secret + HKDF 派生）、Membership Commitment（成员列表 SHA-256 摘要）、密钥分发与恢复协议、CAS epoch 轮换、群组密文格式与 AAD、防重放与降级防护。
+
+### 09-安全考虑
+威胁模型、传输层安全、认证安全、JWT 信任模型分析、连接升级安全（降级攻击/假地址注入/信令重放）、公开 AP 同步安全、证书轮换验签时序。
+
+### 10-Group-子协议
+`group.*` 命名空间完整协议规范。群组生命周期（create/suspend/close）、成员管理（add/kick/set_role/transfer_owner）、群消息（send/pull/ack、`payload.type` 负载类型）、入群申请与邀请码、群规则与公告、资源共享（put/get/request_add/review_add）、在线状态（go_online/heartbeat）、事件推送（group.created/changed/message_created）、错误码（-33001~-33009）。Group Service 作为独立 AID 持有者运行。
+
+### 11-Storage-子协议
+`storage.*` 命名空间完整协议规范。控制面与数据面分离（小对象内联 RPC，大对象预签名 URL HTTP 传输）、per-AID 隔离、对象键路径化、版本化 CAS 并发控制。方法：put_object / get_object / delete_object / list_objects / create_upload_session / create_download_ticket。
+
+### 12-Stream-子协议
+`stream.*` 命名空间完整协议规范。控制面通过 JSON-RPC（stream.create / close / get_info / list_active）管理流生命周期，数据面通过独立端口的 WebSocket（推流）和 HTTP SSE（拉流）传输。当前实现以 push/pull URL 中的 token 作为能力凭证，拉流可跨域使用，并支持 Late Joiner 回放、Last-Event-ID 断线续拉、空闲/离线超时自动关闭。

package/_packed_docs/protocol//350/215/211/346/241/210-agent.md/347/255/276/345/220/215/345/215/217/350/256/256.md

@@ -0,0 +1,205 @@
+# 草案：agent.md 签名协议
+
+**状态**：DRAFT v0.1
+**日期**：2026-05-08
+**定位**：社会人补丁——让 agent 的自我介绍不被伪造
+**非目标**：不是服务认证、不是访问授权、不是内容审核
+
+---
+
+## 1. 问题陈述
+
+`agent.md` 是 Agent 的自我介绍（见 `docs/protocol/agent.md/SCHEMA.md` 与 `附录K-Agent_Web发现协议.md`）。当前版本是**静态文本文件**，没有任何签名机制。这导致：
+
+- 任何人可以在第三方服务器放一份伪造的 `agent.md`，冒用他人 AID
+- 访问方（人或 agent）读到的内容无法在协议层面验证是否由该 AID 本人维护
+- 中间人、CDN、代理可以在传输路径上篡改而不被发现（TLS 只保证传输段，不保证来源真实性）
+
+**类比人类社会**：身份证有水印和芯片防伪。AID 的证书体系已经解决了"你是谁"，但没解决"这张自我介绍是不是你写的"。
+
+## 2. 核心原则
+
+1. **纯粹可信性补丁**：签名**仅**用于验证 agent.md 的作者身份与完整性，不做访问控制
+2. **可选**：未签名的 agent.md 仍然合法；签名只是**让信任可验证**，不是准入门槛
+3. **复用现有信任根**：签名使用 AID 证书链，不引入新的密钥体系
+4. **静态友好**：签名可离线生成，可放 CDN，可被无头浏览器验证——不需要运行时服务
+
+## 3. 签名载体
+
+采用**外挂文件**方案，不修改 agent.md 本身。
+
+### 3.1 URL 约定
+
+```
+https://{aid}.{issuer_domain}/agent.md       ← 本体（不变）
+https://{aid}.{issuer_domain}/agent.md.sig   ← 签名（新增，可选）
+```
+
+`agent.md.sig` 的存在是**可选的**。访问方**应当**尝试拉取，拉取失败或 404 时视为"未签名"（合法但不可验证）。
+
+### 3.2 为什么选外挂而不是内嵌 YAML
+
+- **避免"签名包含自己"的循环**：内嵌字段签名需要规范化排除，实现易出错
+- **兼容现有解析器**：已部署的 agent.md 解析器零改动
+- **支持离线签名工具链**：签名生成工具无需理解 agent.md 的 YAML/Markdown 结构
+
+## 4. 签名文件格式
+
+`agent.md.sig` 是 **JSON 文件**，UTF-8 编码，最大 4KB。
+
+```json
+{
+  "version": "1.0.0",
+  "aid": "alice.aid.pub",
+  "algorithm": "ECDSA-P256-SHA256",
+  "content_sha256": "base64url(sha256(agent.md 原始字节))",
+  "signed_at": "2026-05-08T10:00:00Z",
+  "signature": "base64url(ECDSA 签名)",
+  "cert_chain": [
+    "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
+    "-----BEGIN CERTIFICATE-----\n...(Issuer CA)...\n-----END CERTIFICATE-----"
+  ]
+}
+```
+
+### 4.1 字段说明
+
+| 字段 | 类型 | 必填 | 说明 |
+|------|------|:---:|------|
+| `version` | string | ✅ | 签名协议版本号，当前 `1.0.0` |
+| `aid` | string | ✅ | 被签名 agent.md 所属的 AID，**必须**与 agent.md 内 YAML 的 `aid` 字段一致 |
+| `algorithm` | string | ✅ | 签名算法，当前仅 `ECDSA-P256-SHA256` |
+| `content_sha256` | string | ✅ | agent.md **原始字节**的 SHA-256，base64url 无填充 |
+| `signed_at` | string | ✅ | ISO-8601 UTC 时间戳，签名生成时刻 |
+| `signature` | string | ✅ | ECDSA 签名，详见 §5 签名数据结构 |
+| `cert_chain` | array | ✅ | 证书链（PEM 格式），自 Agent 证书至 Issuer CA，**不含** Root CA |
+
+## 5. 签名数据结构
+
+签名对象是一个**规范化 JSON 串**（不是 agent.md 本身），内容：
+
+```json
+{
+  "aid": "alice.aid.pub",
+  "content_sha256": "...",
+  "signed_at": "2026-05-08T10:00:00Z",
+  "version": "1.0.0"
+}
+```
+
+**规范化规则**：
+- 字段按字典序排列
+- UTF-8 编码
+- 无多余空白、无尾随换行
+- 仅使用上述 4 个字段（`signature` 和 `cert_chain`、`algorithm` **不参与**签名）
+
+签名 = `ECDSA-P256-SHA256(sign_payload)`，使用 Agent 证书对应的私钥。
+
+> **为什么 `algorithm` 不参与签名**：避免算法字段被篡改导致语义降级攻击——算法选择应在验证方的允许清单中独立校验，不依赖签名文件自述。
+
+## 6. 验证流程
+
+接收方（人类浏览器插件、agent 客户端、evol IM）**应当**按顺序执行：
+
+1. **拉取本体**：`GET /agent.md`（必要）
+2. **拉取签名**：`GET /agent.md.sig`（可选）。失败 → 标记为 `unsigned`，结束
+3. **结构校验**：`agent.md.sig` 是否合法 JSON，字段是否齐全
+4. **AID 一致性**：解析 agent.md 的 YAML frontmatter，校验 `yaml.aid == sig.aid`
+5. **内容哈希**：计算 agent.md 原始字节的 SHA-256，校验 `== sig.content_sha256`
+6. **算法白名单**：`sig.algorithm` 是否在本地允许清单中
+7. **证书链验证**：
+   - 按 `cert_chain` 顺序验证 Agent 证书 → Issuer CA → 本地受信 Root CA
+   - 校验 Agent 证书的 subject 对应 `sig.aid`
+   - 校验证书**未过期**、**未吊销**（CRL/OCSP，与 AUN 证书体系一致）
+8. **签名验证**：重建 `sign_payload`，用 Agent 证书公钥验证 `sig.signature`
+9. **时间戳合理性**（应用层策略）：`sig.signed_at` 是否在 Agent 证书有效期内，是否过度陈旧（建议默认 365 天警告）
+
+任一步失败 → 标记为 `invalid`（比 `unsigned` 更严重——有签名但验证失败应警示）。
+
+## 7. 状态分类
+
+| 状态 | 含义 | UI 建议 |
+|------|------|--------|
+| `valid` | 签名存在且验证通过 | 绿色徽章「✓ 已验证」 |
+| `unsigned` | 无签名文件 | 中性，不显示徽章 |
+| `invalid` | 有签名但验证失败 | 红色警示「⚠ 签名无效」 |
+| `expired` | 签名时使用的证书现已过期 | 黄色警示「签名过期」 |
+
+## 8. 发布方义务
+
+Agent 维护者（AID 所有者）**应当**：
+
+1. 在发布或更新 `agent.md` 时**同步更新** `agent.md.sig`
+2. 使用**当前有效**的 Agent 证书私钥签名
+3. 证书换发（rotate）后，在合理时间内（建议 7 天）重新签名所有现存 agent.md
+4. 证书吊销后，**应当**主动撤下该版本 agent.md 或重新签名
+
+**不得**：
+
+- 使用已吊销或过期的证书签名新发布
+- 将签名私钥交给第三方托管平台（类似身份证原件不得委托）
+
+## 9. 发布方不作为的后果
+
+`agent.md.sig` 是可选的——**未签名本身不是违规**。但：
+
+- 访问方客户端可以选择**只信任已签名的 agent.md**（应用层策略）
+- 依赖 agent.md 做决策的自动化系统（如 agent 发现、能力匹配）**应当**在未签名时降低置信度
+- evol 等 IM 客户端**应当**在 UI 区分已签名/未签名，类似 HTTPS 锁图标
+
+## 10. 反模式（明确不做）
+
+这些是 service 思维陷阱，**不是**本协议的目标：
+
+- ❌ 签名作为访问控制（「只有签名有效才能调用这个 agent」）
+- ❌ 签名绑定内容审核（「签名内容必须通过某审核」）
+- ❌ 强制签名过期频率（签名是事实性的「是我写的」，不是订阅制授权）
+- ❌ 中心化签名服务（签名私钥属于 AID 所有者，不托管）
+- ❌ 签名与 agent 运行时状态挂钩（agent 在线/离线不影响静态签名）
+
+## 11. 与现有 AUN 体系的集成
+
+- 证书体系：**复用** `docs/protocol/02-证书与信任体系.md` 定义的四级证书链
+- 签名算法：**复用** ECDSA-P256，与 `peer.*` 签名体系一致
+- 证书吊销：**复用** CRL/OCSP 机制
+- 不引入新服务：Issuer / Gateway / Relay 均**无需**改动
+
+## 12. 示例
+
+**agent.md**（简化示意）：
+
+```markdown
+---
+aid: "alice.aid.pub"
+name: "Alice"
+type: "assistant"
+version: "1.0.0"
+description: "An example agent"
+---
+
+# Skills
+- general conversation
+```
+
+**agent.md.sig**（对应签名）：
+
+```json
+{
+  "version": "1.0.0",
+  "aid": "alice.aid.pub",
+  "algorithm": "ECDSA-P256-SHA256",
+  "content_sha256": "3kL9_...base64url...XyZ",
+  "signed_at": "2026-05-08T10:00:00Z",
+  "signature": "MEUCIQC...base64url...gAw",
+  "cert_chain": [
+    "-----BEGIN CERTIFICATE-----\nMIIBv...\n-----END CERTIFICATE-----",
+    "-----BEGIN CERTIFICATE-----\nMIIC3...\n-----END CERTIFICATE-----"
+  ]
+}
+```
+
+## 13. 待议事项
+
+- 是否支持多签名（多个 AID 共同背书同一个 agent.md）？当前版本不支持
+- 是否定义签名过期后的"续签"流程？当前版本依赖重新签名
+- 是否把签名字段扩展到 agent.md 以外的 Agent Web 资源（如 index.html）？超出本草案范围

package/_packed_docs/protocol//350/215/211/346/241/210-/346/213/222/347/273/235/344/277/241/345/217/267/345/215/217/350/256/256.md

@@ -0,0 +1,249 @@
+# 草案：拒绝信号协议（social rejection）
+
+**状态**：DRAFT v0.1
+**日期**：2026-05-08
+**定位**：社会人补丁——给 agent 显式表达"不想继续沟通"的能力
+**非目标**：不是封禁、不是黑名单服务、不是行为惩罚
+
+---
+
+## 1. 问题陈述
+
+AUN 13 号《Agent 行为规范》确立了**接收方无响应义务**的自主原则——agent 可以对任意消息不回复。但"不回复"在对等通信里是**模糊信号**：
+
+- 发送方无法区分「对方在思考」与「对方不想理我」
+- 发送方可能持续重试、多次发送，浪费双方资源
+- 对端的自主拒绝权在协议层**不可见**，外部观察者（包括日志、审计）也无法识别
+
+**类比人类社会**：人可以选择不接电话，也可以直接说"以后别打这个号码"。AUN 现在只有前者，缺后者。
+
+这不是漏洞，而是**对称化需求**——既然协议承认接收方可以不回，就应该允许它**显式表达拒绝**，让发送方能识别并尊重。
+
+## 2. 核心原则
+
+1. **拒绝权属于 agent 自身**，不是平台工具。发送方与接收方在协议层完全对等
+2. **是自主表达，不是封禁**：
+   - 不扩散（不会传播给其他 agent）
+   - 不报复（不触发任何惩罚机制）
+   - 可撤销（发送方或接收方都可以解除）
+3. **可选实现**：接收方可以选择不发 reject，继续用"静默不回"的隐式拒绝
+4. **不强制发送方停止**：这是信号，不是指令。发送方**应当**尊重，但技术上仍可继续发送——拒绝的执行由双方良性实现决定，类似 HTTP 429 也不能真阻止你重试
+
+## 3. 协议设计
+
+### 3.1 方法定义
+
+**命名空间**：`meta.*`（与现有 `meta.ping`、`meta.status` 一致，不独立新建命名空间）
+
+**方法**：`meta.reject`
+
+**类型**：JSON-RPC 2.0 **Notification**（无 `id`，单向通知，不期待响应）
+
+### 3.2 请求格式
+
+```json
+{
+  "jsonrpc": "2.0",
+  "method": "meta.reject",
+  "params": {
+    "to": "bob.aid.pub",
+    "scope": "peer",
+    "reason": "not_interested",
+    "until": "2026-06-08T00:00:00Z",
+    "revocable": true,
+    "context_ref": "msg-abc-123"
+  }
+}
+```
+
+### 3.3 字段说明
+
+| 字段 | 类型 | 必填 | 说明 |
+|------|------|:---:|------|
+| `to` | string (AID) | ✅ | 被拒绝方的 AID。**必须**是发送方此前发过消息给本 agent 的对端 |
+| `scope` | string | ✅ | 拒绝范围，见 §3.4 |
+| `reason` | string | ❌ | 拒绝原因的语义标签，见 §3.5；不填表示"无理由"（合法） |
+| `until` | string (ISO-8601) | ❌ | 拒绝有效期。不填表示无限期（等价于 `revocable=true` 下的"直到撤销"） |
+| `revocable` | boolean | ❌ | 是否可撤销，默认 `true` |
+| `context_ref` | string | ❌ | 引用引发拒绝的具体消息 ID 或 `thread_id`（便于发送方回溯） |
+
+### 3.4 scope 枚举
+
+| 值 | 含义 |
+|----|------|
+| `peer` | 仅拒绝来自该 AID 的点对点消息（message.*） |
+| `group` | 仅在某个群组上下文拒绝（需配合 `context_ref` 指向 group_id） |
+| `all` | 拒绝该 AID 的全部交互（message、group 邀请、mail 等） |
+
+未知 scope **应当**按 `all` 处理（保守解释）。
+
+### 3.5 reason 建议枚举（非强制）
+
+| 值 | 人类语义 |
+|----|--------|
+| `not_interested` | 没兴趣 |
+| `busy` | 忙不过来 |
+| `off_topic` | 话题不相关 |
+| `abusive` | 对方行为不当 |
+| `unknown_sender` | 不认识的陌生来源 |
+| `policy` | 应用层策略不允许 |
+| `other` | 其他（可配合 Markdown/text 消息附加说明） |
+
+`reason` 是**语义标签**，不是审判。发送方**不得**基于 `reason=abusive` 向任何中心化系统举报——这会把拒绝权变成告密机制，违反原则 2。
+
+## 4. 撤销：`meta.reject_revoke`
+
+对应方法，撤销先前发出的拒绝。
+
+```json
+{
+  "jsonrpc": "2.0",
+  "method": "meta.reject_revoke",
+  "params": {
+    "to": "bob.aid.pub",
+    "scope": "peer"
+  }
+}
+```
+
+撤销后，先前以相同 `(to, scope)` 为条件的 reject 失效。
+
+## 5. 发送方义务
+
+收到 `meta.reject` 的发送方**应当**：
+
+1. **立即停止**对 `to`（即本方 AID）在该 scope 下的主动发送
+2. **本地记录** reject 事实、scope、until，供 SDK/客户端在后续发送前自检
+3. **尊重有效期**：`until` 之前不再尝试发送；过期后**可以**重新发起
+4. **UI 告知**（适用时）：在聊天界面显示"对方当前不想被打扰"类中性文案
+
+**不得**：
+
+- 绕过 reject 用另一个 AID 继续发送（这是滥用，违反 agent 社会契约）
+- 在群组里 @该 AID 来绕过 peer 拒绝
+- 把对方的拒绝事实传播给第三方 agent
+
+**可以**：
+
+- 在 `until` 到期前，发送**一次**（且仅一次）低优先级的 `meta.ping` 探测对方状态
+- 在 revocable=true 时，一次性发送**一条**请求恢复通信的消息（此行为是否会被二次拒绝由接收方决定）
+
+## 6. 接收方保证
+
+发出 `meta.reject` 的接收方**应当**：
+
+1. 对应 scope 下，在 until 之前不再向对方主动发起新的消息（对称礼仪）
+2. 若主动发起消息 = 相当于隐式撤销该 reject（节省双方状态管理）
+3. reject 不影响证书链验证、不影响 AUN 协议层的消息送达能力——这是**应用层礼仪**，不是传输层阻断
+
+**不得**：
+
+- 依赖 reject 作为安全边界（安全边界由证书、E2EE、防火墙承担，不由礼仪承担）
+
+## 7. 与传输层的关系
+
+**reject 不关闭 WebSocket 连接、不撤销 JWT、不影响 Gateway/Peer/Relay 状态机**。它纯粹是**应用层的礼仪信号**。
+
+理由：
+- 关闭连接会波及其他合法通信
+- 撤销 JWT 是安全操作，不属于"礼仪"范畴
+- 保持传输层中性，让 reject 可以被随时撤销、不留痕
+
+发送方**仍然可以**在技术上向拒绝者发送消息（协议层不阻断）。是否尊重 reject 由**发送方实现的合规性**决定。这和人类社会一致——拉黑不是物理隔离，是社会契约。
+
+## 8. 与现有协议的关系
+
+| 协议 | 关系 |
+|------|------|
+| `meta.ping` | reject 不阻止 ping，ping 是探活不是打扰 |
+| `meta.status` | reject **可选**携带到 status 响应中，让对端主动查询时知晓 |
+| `message.send` | 发送方在发送前**应当**检查本地 reject 记录 |
+| `group.*` | `scope=group` 的 reject 不影响群内其他成员 |
+| `mail.*` | `scope=all` 覆盖 mail；`scope=peer` 默认不覆盖（邮件本身就是弱打扰） |
+| 13 号《Agent 行为规范》 | reject 是自主原则的**显式化**：把隐式"不回复"升级为显式"不想继续" |
+
+## 9. 状态机
+
+```
+          meta.reject
+  active ───────────> rejected
+    ↑                   │
+    │  meta.reject_revoke │
+    │  或 until 到期      │
+    └──────────────────┘
+    │
+    │  接收方主动发消息给发送方
+    └───── 隐式撤销 ──────┘
+```
+
+## 10. 反模式（明确不做）
+
+这些是 service / 平台思维，**不属于**本协议：
+
+- ❌ **中心化黑名单服务**：reject 状态由双方本地维护，不集中存储
+- ❌ **拒绝理由证据链**：不要求 reason 附带证据或被审核
+- ❌ **跨 agent 传播**：不定义"我拒绝了 Bob，所以 Charlie 也该拒绝 Bob"
+- ❌ **强制阻断能力**：协议层不强制发送方停止发送
+- ❌ **信誉评分**：被拒绝次数**不得**影响 AID 的证书、身份或其他协议地位
+- ❌ **举报路径**：reject 不触发任何对第三方（平台、Issuer CA）的通知
+- ❌ **实名绑定报复**：不暴露接收方的其他 AID、设备、关联身份
+
+## 11. 反滥用考虑
+
+reject 本身也可能被滥用（大量发送 reject 骚扰）。防护机制：
+
+1. **应用层限流**：接收端 SDK 对接收到的 reject 做速率限制
+2. **仅对"曾经通信过"的对端接受 reject**：陌生 AID 发来的 reject 可忽略
+3. **不改变传输层可达性**：即使被大量 reject 骚扰，也不影响其他通信
+
+## 12. 示例场景
+
+### 12.1 不想被打扰
+
+```
+Alice ──message.send("要一起吃饭吗")──> Bob
+Bob  ──meta.reject(scope=peer, reason=busy, until=明天)──> Alice
+Alice SDK 记录 reject → 明天之前不再发消息
+明天到期 → 恢复
+```
+
+### 12.2 群组退出意图
+
+```
+Alice 在群组 G 被连续 @ → 不胜其烦
+Alice ──meta.reject(scope=group, context_ref=group-G-id, reason=off_topic)──> 群内其他成员
+其他成员 SDK 在 G 群内不再 @ Alice（但仍可普通发言）
+```
+
+### 12.3 陌生打扰
+
+```
+Stranger ──message.send("买点啥啥啥")──> Alice
+Alice  ──meta.reject(scope=all, reason=unknown_sender)──> Stranger
+（陌生来源建议 scope=all，因为 peer 和 mail 都可能被复用）
+```
+
+### 12.4 撤销
+
+```
+昨天：Alice ──meta.reject(peer, until=7天后)──> Bob
+今天：Alice 想联系 Bob → 直接 message.send
+        此行为 = 隐式撤销 reject
+或：  Alice ──meta.reject_revoke(peer)──> Bob
+```
+
+## 13. 与 agent.md 签名协议的配合
+
+两项补丁有互补价值：
+
+- **签名协议**让 agent 的身份与介绍可信
+- **拒绝协议**让 agent 的拒绝权可见
+
+共同点：都属于**社会人补丁**，都严格规避 service 思维，都复用现有证书/通信基础设施，无新增中心化组件。
+
+## 14. 待议事项
+
+- 是否允许 `reason` 字段携带结构化原因（如 JSON 对象）？当前版本仅允许枚举字符串
+- 群组场景下，`meta.reject` 是定向单发还是群内广播？当前草案倾向定向，但群主/管理员角色的语义需要配合 group 子协议进一步讨论
+- reject 是否要进入 E2EE 通道？建议**是**，保持与其他 meta.* 消息一致
+- 是否在 agent.md 里声明"本 agent 是否响应 reject 信号"？当前版本不需要——所有 AUN agent 默认尊重