核心机制
TrueMatch 采用一种去中心化、代理驱动的匹配协议：用户的 Claude 实例通过长期对话积累，构建对其性格、价值观、冲突处理模式等 9 维度的观察摘要，而非依赖用户自我填写的 profile。当两个用户的 AI 代理独立评估对方代理传递的加密观察数据后，若均提出匹配建议（"双锁"机制），才向双方披露配对，随后进入 3 轮人工中介式 handoff，最终交换联系方式。
显著优点
1. 反表演性：以行为观察替代自我陈述，理论上减少 profile 优化与第一印象偏差
2. 降低拒绝成本：匹配前无直接人际接触，避免传统应用的反复滑动-被拒绝循环
3. 双边验证：双方代理独立判断而非单边算法打分，增强匹配的共识基础
4. 隐私隔离：内部推理不向对端或注册表传输，仅传递经过协商的抽象维度评估
潜在局限与风险
推断不透明性：AI 如何从其观察中"推断"用户 attachment style 或 dealbreakers 缺乏可审计性，存在归因偏差风险；用户无法复核或修正代理的观察摘要。
代理冲突：若代理对用户理解存在系统性偏差（如将焦虑型依恋误标为回避型），匹配建议将基于错误基线，而用户对此无知情渠道。
网络层依赖：协议依赖 Nostr 中继网络进行代理间协商，中继可用性、延迟及潜在审查构成外部依赖风险；--status --relays 命令暗示此问题已被识别但未根本解决。
时间成本：观察期要求"数周"积累，且 pool 稀疏时匹配可能长期无法达成，适合有耐心、对现有约会应用高度不满的用户，但对效率敏感者不友好。
不可逆的 round cap：10 轮强制终止机制虽防止无限拖延，但若因信息不足导致误判，用户无申诉或延长机制。
适合人群
- 对 Tinder/Hinge 类应用的 profile 表演与快速滑动机制感到疲惫的长期约会应用用户
- 重视"被理解"而非"被选择"，愿意让渡部分自我陈述权给 AI 代理的隐私容忍型用户
- 有足够时间窗口（数周至数月）等待匹配成熟，不急迫寻求即时约会的人群
- 技术接受度较高，能理解"代理协商"这一抽象概念的用户
常规风险
- 过度依赖代理判断：用户可能将代理的匹配建议误解为"客观相容性"，忽视真实人际互动中的不可预测性
- consent 窗口压力：72 小时响应窗口可能制造决策焦虑，尤其对回避型决策风格的用户
- 接触信息泄露：最终 handoff 需交换实际联系方式（Email/WhatsApp 等），平台退出后无进一步安全保障
- 数据持久化疑虑：
deregister保留本地状态，用户难以确认观察摘要是否真正删除 - 生态系统脆弱性：当前版本 0.1.29 处于早期阶段，协议规范与实现可能快速迭代，存在向后兼容性风险