能力对象模型把访问权限做成引用，拿到引用才能调用，中继服务器只负责转发密文和路由消息，不持有对方的凭据，所以它无法读取内容，也无法冒充任何一方发起调用。这套设计适合需要跨组织互通、又不愿意把信任交给中间节点的团队。
能力对象模型和传统权限模型的差别
传统服务端鉴权把权限写进一张表，收到请求后查表判断这个账号能不能做这件事。授权判断发生在服务器进程里，谁控制服务器，谁就拿到全部判断权。
能力对象模型换了一种做法。权限本身是一段不可伪造的引用，业内常叫 capability 或者 sturdyref。调用方手里有这个引用，就能调用对应的方法，没有这个引用，连对象存在与否都问不出来。判断动作由持有者完成，不经过中心裁决。Macaroons 和 Spritely 项目里的 Goblins 都在这一脉络上。OCapN 想把不同实现、不同语言的能力对象网络连起来，目前公开的还是草案规范。
中继在加密体系里到底做什么
中继承担三件事。它维持长连接，把消息从一个网络送到另一个网络；它按会话标识做转发，不解析载荷；它保管一个短连接标识，让离线的一方上线后能找回没收到的那批消息。
能不能真的做到不看明文，取决于加密层次放在哪里。传输层加密只保护一跳，中继作为端点会看到明文消息体。要在能力模型里做到端到端，必须把每个交付消息整体加密，密钥在两端协商。OCapN 相关项目近两年推进的方向，就是让联邦中继在不解密的前提下完成对象引用与消息交付。
落地时要处理的四个问题
- 为每对通信方跑一次握手，用临时密钥协商出会话密钥，中继全程只看到密文和不含身份信息的会话标识。
- 把能力引用拆成两半，一半是公开的中继地址和会话号，一半是只有收件人能解开的密钥材料，两半分别传递。
- 为中继准备签名密钥并公开公钥，让接收方在本地验证路由字段有没有被篡改。
- 断线时由中继按会话号缓存密文，设定过期时间，过期即丢弃，不落明文索引。
中继能看到什么，看不到什么
不夸大边界比较重要。中继即使不解密载荷，仍然能看到通信双方的网络地址、消息长度、发送时间，以及哪个会话在跟哪个会话通信。这类元数据足以支撑流量分析。想进一步收窄，需要固定长度填充或者混入无关流量，成本都不低。
中继还能做拒绝服务。它可以只投递一部分消息，或者干脆不投递，接收方很难分辨这是网络问题还是中继作恶。所以通常不建议把中继当成可信第三方来用，两侧必须有重传和切换中继的能力。
适合用和暂时别用的场景
- 参与方数量固定、彼此有业务关系，中继只做连通性，这套设计收益明显。
- 需要审计谁在什么时候调用过什么方法，能力模型的授权不经过中心，审计要另建一层。
- 参与方希望用现成的中心化账号体系收口权限，能力引用会成为额外负担。
- 团队还没有密钥轮换和密钥丢失的处置流程，先补这一块，再谈中继。
常见问题
中继能不能伪造消息。它在没有会话密钥时不能，但它可以丢弃和延迟，要防这两件事得靠接收方的超时和重传策略。
能力引用泄露了怎么办。引用等同于权限，泄露就等于把权限给了别人，所以引用要求可撤销，并在泄露后换发一批新的。
这套东西现在能用吗。OCapN 的规范还在草案阶段，生产环境建议先在小范围的两三个服务之间验证，不要一步铺到对外入口。