活动 14 / 调研补充与独立分析

跨社区合作怎样落地：身份可验证，贡献可携带，金库有边界

从交流开篇延伸到身份、凭证、公共金库和开源协作，提出一个明确属于本文设计的28天小规模合作试点。

本篇内容导航

01互操作身份，不等于统一所有人的档案

现有活动内容只覆盖交流开篇，提出跨领域连接与长期公共建设，未展示完整合作机制。以下为独立分析。跨社区首先要解决的是“谁在提出请求、谁为其经历作证”，不是把所有成员装进同一数据库。DID规范提供标识符、验证方法和控制证明，但掌握密钥不等于真实姓名、唯一自然人或自动获得会员资格。[1]

两方需约定支持的标识与签名格式、可信签发者、密钥轮换和失窃恢复方式。为不同合作关系使用不同标识，可减少无意关联；规范也明确提醒公开DID文档不应包含个人资料。[1]互操作的目标是少重复核验，而不是消灭各社区的准入判断。

例如成员完成一份设备安装指南，可取得包含角色、成果链接、验收方、版本和凭证状态的记录。下个社区读取后，仍应判断这段经历是否适合自己的任务，不必继承上一组织的积分权重。资历、一次劳动和治理权是三件事，不能合成一个永久排行榜。

W3C凭证模型区分签发者、持有者与验证者，支持查询撤销或暂停状态，并强调验签不等于声明真实。[2]因此合作方既要检查技术证明，也要认可验收机构；本人应能导出凭证、选择披露范围和纠正错误。对负面评价尤其要有申诉期限，不能让一次争执成为跨社区通行的黑名单。

我的小规模设计是两社区各派一名签署者，加一名共同认可的独立签署者，采用三人中两人确认，并把用途、预算上限和验收依据公开。Safe文档说明，多签门槛约束的是有效签名数量；它不判断采购是否必要、成果是否合格，也不保证签署者没有串谋。[3]

预算批准、任务验收和付款应留不同记录，利益相关者回避自己的报销审核。Safe模块还可能绕过普通签名验证路径，因此试点不启用未经检查的额外模块。[3]所有者变更、丢钥匙处理、剩余资金退回和终止条件要先写明，链上余额公开不能替代法律责任与财务对账。

OSI定义要求开源许可证允许再分发、修改和派生作品，也不能排斥商业用途；仅仅公开代码并不够。[4]跨社区仓库应先明确代码许可证、文档与硬件设计各自的授权、署名和第三方材料来源，避免把“大家一起做”误写成权利已经自动共有。

独立分析：维护者仍可以设测试、审查与发布门槛，开源不等于每个提交都必须合并。参与者数据、密钥和未修复漏洞不应随仓库一起公开。把可公开成果与受限材料分开，约定谁负责长期维护，才不会在一次联合演示后留下无人负责的基础设施。

协议只覆盖本次合作，至少写明参与方、唯一交付目标、责任人、验收标准、预算与付款条件、许可、数据保留和退出方式。双方各自的内部治理不必合并，也不要默认对方的投票代表本方成员。对于争议，先暂停争议部分，由没有直接利益的人复核，保留未受影响工作的正常结算。

可检验的底线是：任何参与者都能读懂自己承诺了什么；退出后仍能保留已验收贡献的证明；没有人能单凭管理员权限改掉另一方的记录。若最基本的责任归属尚不清楚，增加跨链接口或发统一代币只会把争议包装得更复杂。

这不是现场已经实施的活动方案。建议由一个软件社区与一个硬件社区各选三名参与者，围绕同一套传感器演示交付双语安装指南、测试记录和可导出贡献凭证，不发行通用积分，不要求全体成员迁移身份。

第1—7天：约定与基线：确认许可、预算上限、验收人和退出条款；记录旧安装流程，由双方各完成一次身份与签发者验证。
第8—14天：完成最小交付：分工编写与实测，任务表保留修改和费用依据；只对已验收成果签发凭证，未完成部分明确标记。
第15—21天：交叉验证：让未参与编写的另一方成员照指南独立复现，测试错误凭证、撤销查询和密钥恢复；失败就修正，不用展示效果替代验收。
第22—28天：结算与去留：逐笔对账并导出成果。以能否独立复现、识别无效凭证、解释每笔支出和处理未决争议决定是否继续；完成试点不等于证明可扩展到大型网络。

下列资料支持技术与制度背景；分析、方案设计和示例推演由本篇作者给出，并非对现场发言的逐句复述。