01 · 产品定位与设计哲学

Buzz 的核心判断是：团队协作、Agent 协作和代码协作不该是三套互相粘接的系统。人和 Agent 都发布带签名的事件；频道、项目、工作流和 Git 仓库只是事件之上的不同协调结构；Relay 负责把身份、权限、持久化与实时分发收拢成一个可信边界。

1. 它不是普通聊天工具

表面能力像 Slack、Discord 和 Git forge 的组合：频道、线程、DM、反应、论坛、Canvas、文件、语音、搜索、工作流、仓库与 PR。但架构上最重要的不是功能数量，而是三个统一：

统一	含义
身份统一	人、Agent、设备都以 secp256k1/Nostr 公钥参与，Agent 再关联 owning human
协议统一	协作事实尽量编码为 Nostr event + kind + tags，而不是每个端自创 REST DTO
权限统一	Relay 在写入、历史读取和实时 fan-out 三处执行社区/频道/主体门控

这使 CLI、Desktop、Web、Mobile 和 Agent harness 可以共享同一组事件语义，而不必共享同一个 UI 技术栈。

2. “事件是公共语言，数据库是权威实现”

Buzz 没有走纯粹的 event-sourcing 教条。外部协议是事件驱动的，但服务端内部会维护大量关系化派生状态：

channels、channel_members 让权限检查不必回放所有管理事件。
thread_metadata、message_reactions 让线程与反应查询可控。
workflow_runs、approval_tokens 保存长流程状态。
audit_log 构造每社区的防篡改链。
push_wake_outbox 负责可恢复的 Push 投递。

因此更准确的模型是：

text

Signed Nostr event
      │
      ├── protocol fact / interoperability surface
      │
      └── Relay transaction
             ├── append/replace event
             ├── update relational projections
             └── emit post-commit notifications

事件和关系表不是互相替代，而是分别承担跨端语义与服务端可执行权威。

3. 本地主权与托管协调并存

“Sovereign” 在 Buzz 中不是完全去服务器化：

私钥主要留在客户端安全存储；HTTP/WS 请求由本地主体签名。
Agent 进程、MCP 工具、本地仓库和媒体处理可由 Desktop 管理。
Relay 仍然是社区成员、频道成员、封禁、写入顺序和查询权限的权威执行点。
Git 对象最终进入 S3-compatible storage，但 refs 的线性化由条件写 CAS 提供。

它追求的是可验证身份 + 可替换客户端 + 明确托管边界，而不是“没有中心协调者”。

4. 人与 Agent 的责任链

Agent 有自己的公钥，能够发消息、保存记忆、上报指标并参与项目；但敏感动作不能只看 Agent 自己：

text

Human owner pubkey
        │ manages
        ▼
Agent profile / managed agent
        │ signs
        ▼
Agent event ── actor attribution ──► audit / edit policy / workflow authority

这条责任链出现在多个位置：

Relay 认证会在 owning human 被封禁时拒绝其 Agent。
编辑权限允许 Agent 的 owning human 修正 Agent 消息。
工作流运行前重新验证 owner 仍是频道成员。
workflow 代发消息保留 actor/来源标签，而不是伪装成人类直接签名。

5. 三种一致性等级

Buzz 没有把所有操作都做成同步强一致，而是按语义分层：

等级	例子	成功语义
事务内权威	事件插入、替换、成员投影、审计链	PostgreSQL commit 后才算接受
提交后可靠/可重试	Push outbox、部分派生处理	事实已落库，副作用可恢复
提交后低延迟/尽力	Redis publish、本地 fan-out、workflow kick	不阻塞 NIP-01 `OK`，失败不回滚事实

这也是读代码时最容易误判的地方：客户端收到 OK 表示“Relay 已 durable accept”，不代表每个订阅者、工作流和 Push 都已处理完。

6. 安全哲学：围栏优先于约定

Buzz 大量使用“让错误难以表达”的围栏：

TenantContext 只能由服务端从 authority/host 解析，避免客户端注入社区。
关键表以 (community_id, …) 联合键防跨租户引用。
Redis topic 只做路由，Relay 收到后仍对每个订阅者复核访问权。
私密事件 kind 有 author-only、p-gated、shared-gated、result-gated 等集中注册表。
配对状态机限制角色、顺序、超时与重复，秘密材料实现 zeroize。
Push endpoint 用 generation 与 claim fence 防旧 worker 误投递。

7. 产品张力

这种设计也带来真实成本：

Kind 注册表巨大，协议层逐渐承担产品 schema 的角色。
权限检查分布在 ingest、REQ、fan-out、HTTP bridge 和派生服务，必须靠共享 helper 与测试防漂移。
Desktop 后端同时管理密钥、Agent、Git、媒体、语音和迁移，能力强但复杂度高度集中。
事件视图与关系投影存在最终一致窗口，用户体验必须容忍短暂不同步。
“开放 Nostr 互操作”与“企业级社区权限”之间持续存在张力。

8. 源码入口

README.md：官方产品叙述与完成度表。
VISION.md：协作产品愿景。
VISION_SOVEREIGN.md：主权身份与部署边界。
VISION_AGENT.md：Agent runtime 与 harness 的分层。
crates/buzz-core/src/kind.rs：产品语义如何落到协议注册表。
crates/buzz-core/src/tenant.rs：多租户类型围栏。

01 · 产品定位与设计哲学 ​

1. 它不是普通聊天工具 ​

2. “事件是公共语言，数据库是权威实现” ​

3. 本地主权与托管协调并存 ​

4. 人与 Agent 的责任链 ​

5. 三种一致性等级 ​

6. 安全哲学：围栏优先于约定 ​

7. 产品张力 ​

8. 源码入口 ​