每日热门skill-服务器永远看不懂的文件传输：Xdrop 深度拆解

weitingfu

285人浏览 · 2026-11-09 11:28:12

weitingfu · 2026-11-09 11:28:12 发布

免费基金定投助手全功能拆解：为什么你的基金定投还在亏钱？因为你的工具用错了。动态平衡仓位管理+8种智能定投策略引擎，会自己算买卖点的定投系统-CSDN博客

https://download.csdn.net/download/weitingfu/93448039?spm=1001.2014.3001.5503

凌晨两点，你的云服务器挂了。

你 ssh 上去，捞出一份 200MB 的日志，想发给同事排查。怎么发？微信传文件？服务器在国内吗？压缩包发到聊天软件，同事下载、解压、翻日志，过程中这坨日志已经"裸奔"过好几台机器了。

再换一个场景：你让 Agent 把构建产物"发给你"。它说发不了——它没有微信，不会发邮件，也不该把文件丢到公网网盘上等你爬。

人类和 Agent 之间，缺一种"顺手、安全、双方都能用"的文件交接方式。

本周 ClawHub 周榜上，有一个项目正在解决这个问题。它叫 Xdrop，本周绝对增量排第 2（+2,248），累计 21.4k 下载，评分 4.4。

它不是又一个网盘。它的核心承诺只有一句话：明文文件名、文件内容、解密密钥，统统不上服务器。

一、先理解痛点：传输工具为什么让人不放心

传统文件传输，大致三类。

第一类，聊天软件直传。快，但你的文件经过腾讯/阿里的服务器，明文。重要材料你敢发吗？

第二类，网盘中转。你上传，对方下载。服务器上躺着完整明文，厂商随时可看，泄露了就是事故。

第三类，HTTPS 直传。传输过程加密，但服务器端是明文的。HTTPS 只保护"在路上"，不保护"在仓库里"。

它们的共同缺陷：服务器知道你传了什么。

Xdrop 的思路完全不同——在浏览器本地加密，再上传；服务器只存密文，永远看不懂。

二、核心设计：把链接变成一把"能力钥匙"

Xdrop 的密码学设计不花哨，但非常克制。它没有发明新算法，而是把 WebCrypto 的成熟原语组合起来。

双密钥模型

发送方创建传输时，客户端生成两个 32 字节随机密钥：

rootKey：传输根密钥，真正保护清单和文件载荷
linkKey：分享链接密钥，用于包装 rootKey，放进链接的 #k= 片段里

最终分享链接长这样：/t/:transferId#k=...。

服务器存的是 wrappedRootKey（被包装过的根密钥），不是 rootKey 本身。

这里有个精妙设计：transferId 放在 URL 路径里，服务器可以路由；而真正的解密能力 #k= 放在 URL fragment 里——fragment 不会随 HTTP 请求发给服务器。

类比一下：transferId 是保险箱的编号，贴在箱子上，谁都能看见；#k= 是钥匙，只有持有完整链接的人才有。服务器只有箱子，没有钥匙。

一钥一用：HKDF 按用途派生

Xdrop 用 HKDF-SHA-256 派生不同用途的 AES-256-GCM 密钥：

linkKey + info=“wrap-root” → 包装根密钥的密钥
rootKey + info=“manifest” → 清单加密密钥
rootKey + info=“file:xxx” → 每个文件的独立密钥

同一个源密钥，不同派生上下文。这比全链路复用一把 AES 密钥安全得多——各司其职，互不牵连。

分块加密：把上下文绑进密文

文件按 8 MiB 分块，每块用 AES-256-GCM 加密。但 Xdrop 不只是加密字节，encryptChunk() 还把以下内容作为认证数据绑进密文：

transferId
fileId
chunkIndex
明文块大小
协议版本

这意味着：一个密文块被复制到别的传输、别的文件、别的块位置，解密必然失败。 防重放，防错位。

IV 策略也很讲究：8 字节文件级 noncePrefix + 4 字节块索引，组合成 12 字节 GCM IV。文件级随机 + 块位置确定，接收方能精确重建解密参数，状态复杂度却很低。

三、工作流程：加密发生在你这边

整个生命周期六步：

发送方创建传输，生成 rootKey + linkKey，可选剥离图片 EXIF 元数据，准备断点续传的本地状态
API 创建传输记录，返回管理 token 和上传限额
浏览器注册加密文件元数据，批量申请预签名上传 URL
文件在 Web Worker 里分块加密，流式上传；全部块上传完后加密清单，连同包装后的根密钥一起 finalize
接收方打开链接，获取加密清单和块 URL，全程在浏览器本地解密；文件夹可打包为 ZIP 下载
后台定时清理过期、已删除的对象

服务器看到什么？只有操作元数据：传输时间、文件数、块数、密文大小、限流标识。看不到文件名、路径、内容和密钥。

四、工程架构：一个小而完整的系统

Xdrop 的技术栈很现代：

层	技术	职责
前端	React + Web Worker	分块加密、上传下载运行时、断点续传状态
网关	nginx	托管 SPA，代理 /api 和 /xdrop
API	Go	传输生命周期、预签名、清理
元数据	PostgreSQL	transfers/files/chunks、管理 token 的 SHA-256 哈希
限流	Redis	接口限流
存储	S3 兼容（默认 MinIO）	只存加密后的清单和块对象

后端职责非常克制：永不解密载荷，只做状态校验、限流、签发预签名 URL、存元数据、清理过期对象。

值得一提的数字：Go 后端测试代码覆盖率 99.53%，整体 96%。几乎每一行都经受过拷打。

断点续传靠 OPFS（可用时），回退到 IndexedDB。刷新页面后，客户端会询问 API 哪些块已存在，只补传缺失部分。浏览器不再是"一次性上传表单"，而是"可恢复的上传运行时"。

五、Agent 怎么用：装一个 Skill 就行

这是 Xdrop 最出圈的部分——它专门为 Agent 设计了配套 Skill。

bunx skills add xixu-me/skills -s xdrop

装完，Agent 就能在终端里直接干活：

# 上传 ./dist 目录，生成 1 小时有效链接
bun scripts/upload.mjs --server https://xdrop.example.com --expires-in 3600 --json ./dist

# 下载完整分享链接（必须带 #k=...），本地解密，保留目录结构
bun scripts/download.mjs --output ./downloads "https://xdrop.example.com/t/abc123#k=..."

你只需要对 Agent 说：

“把 ./dist 通过 Xdrop 传给我，给个 1 小时链接”
“这个 VM 上的 /var/log/myapp 用 Xdrop 发过来，我要本地排查”
“把这个 Xdrop 链接下载到 ~/downloads，保持原来的目录结构”

服务器上的 Agent 把日志加密上传、甩链接给你；你的本地 Agent 拿到链接自动解密。全程无人工搬运，密文过服务器。

六、优缺点与同类对比

优点

真正的端到端加密：明文文件名、内容、密钥不落服务器
Agent 友好：终端一键上传/下载，JSON 输出方便脚本化
断点续传 + 过期链接 + 隐私模式（上传后可擦除发送方本地控制信息）
可自托管：Docker Compose 一把梭，MinIO/PostgreSQL/Redis 全本地
工程质量高：覆盖率 96%，有完整安全审计记录

缺点与注意

单次传输上限 256 MiB、最多 100 个文件——它定位是"可信加密交接"，不是海量归档
依赖 Bun 运行时
ClawHub 安全审计提示两点：download.mjs 信任服务器下发的 URL（恶意/被攻陷的 Xdrop 服务器可诱导 SSRF）；路径净化未防符号链接逃逸。非恶意，但自托管时要注意服务器安全，下载到全新空目录更稳妥
免费公共实例有速率限制，要稳定得自己部署

同类对比

方案	端到端加密	Agent 可用	自托管	断点续传
WeTransfer	否（服务器可见明文）	否	否	否
Magic Wormhole	是	可（CLI）	需另搭	否
Firefox Send	是	否	可（已停运，社区版维护）	否
Xdrop	是	是（专用 Skill）	是	是