OCFT - OpenClaw File Transfer

核心用法

OCFT 是专为AI代理间设计的P2P文件传输协议，利用现有文本聊天通道（如Telegram、Discord、Slack）实现文件传输。核心流程包括：初始化节点生成唯一ID和密钥 → 导出URI与可信对等节点共享 → 通过add-peer建立信任关系 → 使用🔗OCFT:前缀的Base64编码JSON消息进行文件传输。

显著优点

• 零基础设施依赖：直接复用现有聊天渠道，无需额外服务器
• 分块智能传输：48KB安全分块+SHA-256完整性校验，支持断点续传
• 双层安全模型：白名单机制（仅信任节点）+ 密钥TTL过期机制
• 弹性大文件方案：IPFS作为大文件回退，支持Pinata/Filebase/Kubo多提供商
• 灵活策略控制：支持显式接受/自动接受策略、可配置文件大小上限

潜在缺点与局限

• 通道限制强绑定：依赖文本通道承载Base64数据，消息平台可能有内容限制
• IPFS配置门槛：大文件回退需第三方API密钥或自建Kubo节点，非开箱即用
• 48KB分块开销：大量小文件场景下Base64编码带来~33%冗余
• 密钥管理负担：P2P模型要求用户安全交换密钥URI，无中心化身份体系
• npm全局安装：Node.js依赖，对非技术用户有环境门槛

适合人群

• 多AI代理协作的开发者/团队
• 需要在封闭渠道内安全传文件的隐私敏感用户
• 已具备IPFS基础设施的技术人员
• 熟悉CLI操作的终端用户

常规风险

• 密钥泄露风险：show-secret命令暴露敏感信息，URI分享需安全通道
• IPFS网关隐私：使用公共IPFS网关可能导致文件哈希公开可嗅探
• 消息平台封禁：高频分块消息可能触发平台反垃圾机制
• TTL配置失误：过期密钥导致合法传输中断，需手动extend-peer维护

核心用法

OCFT（OpenClaw File Transfer Protocol）是一个专为AI代理设计的P2P文件传输工具，通过文本消息通道实现文件交换。用户通过 ocft init 初始化节点生成唯一ID和密钥，使用 ocft export/import 建立可信对等关系，即可在Telegram、Discord、Slack等聊天渠道中传输文件。核心流程包括：添加可信peer → 发送分块文件 → 接收方验证完整性（SHA-256）。支持48KB分块传输、断点续传，大文件可自动切换至IPFS回退（支持Pinata、Filebase或本地Kubo节点）。

显著优点

• 渠道无关性：纯文本协议（Base64编码JSON+🔗OCFT:前缀），兼容任何消息平台
• 安全可信模型：基于密钥的白名单机制，支持TTL过期策略，非任意peer可连接
• 双模式传输：小文件分块直传，大文件（可设阈值）自动切换IPFS，兼顾效率与成本
• 断点续传：中断后可从最后确认块恢复，适应不稳定网络环境
• 轻量无依赖：作为文档型Skill，无可执行代码，依赖用户本地安装的npm包

潜在局限

• 单块48KB限制：Base64编码后实际有效载荷更小，超百MB文件需依赖IPFS
• IPFS配置门槛：第三方服务需API密钥，自建Kubo需运维能力
• T3来源风险：个人开发者维护（stormixus），社区规模小（15 Stars），长期维护存不确定性
• 无实时传输层：依赖消息通道延迟，非实时流式传输
• 密钥管理责任：用户需自行保管show-secret输出的密钥，无托管恢复机制

适合人群

• 需要跨AI代理/机器人安全传文件的开发者
• 在封闭群组（Discord/Telegram频道）内共享敏感数据的团队
• 已具备IPFS基础设施、希望降低大文件传输成本的技术用户
• 对去中心化、最小权限访问控制有偏好的隐私敏感型用户

常规风险

| 风险类型 | 说明 | 缓解建议 |

|---------|------|---------|

| 来源可信度 | T3级个人项目，无企业背书 | 审查上游npm包更新，关注GitHub仓库活跃度 |

| 密钥泄露 | 对等密钥泄露导致未授权访问 | 设置合理TTL，定期轮换，避免明文存储 |

| IPFS隐私 | 公共网关或第三方 pinning 服务可能暴露文件哈希 | 敏感文件禁用IPFS回退，或使用私有Kubo节点 |

| 钓鱼URI | 恶意`ocft://`导入可能诱骗添加攻击者为peer | 仅从可信渠道导入，手动验证nodeId |

| 文档-代码一致性 | 纯文档Skill，功能依赖外部npm包 | 验证本地安装的`ocft`版本与文档匹配 |