Signal 附件存储私有化部署

Signal 的聊天附件存储经过了好些个版本，从代码里就可以看到 从 AttachmentControllerV2 （AWS S3）， 到 AttachmentControllerV3 （GCS），再到现在的 AttachmentControllerV4(TUS)，目前最新的版本使用了 GCS/Google Cloud Storage即谷歌云服务的存储与 TUS 协议；按如下代码描述，暂时只是「内测用户」使用 tus 协议上传附件，大多数用户仍然使用 GCS。

this.attachmentGenerators = Map.of(
    2, gcsAttachmentGenerator,
    3, tusAttachmentGenerator
);

final boolean useCdn3 = this.experimentEnrollmentManager.isEnrolled(auth.getAccount().getUuid(), CDN3_EXPERIMENT_NAME);
int cdn = useCdn3 ? 3 : 2;

V4 版本服务器代码在这里 https://github.com/signalapp/tus-server 此工程是一个运行在 cloudflare worker 上的工程，使用了 cloudflare 的存储引擎 R2，只能被 cloudflare 加载或 wrangler 调试器模拟加载。相比以往明显新方案的「运维成本」更高昂，毕竟原方案无论是 aws，还是 gcs，均无须代码手动处理。那为何官方依然选择如此呢？

从 aws 迁往 gcs 动机不明，难道是成本问题？但从 aws/gcs 迁移到 R2 则是确定的，成本与带宽/用户体验都能明显改善，所以哪怕需要额外写一个工程代码，需要额外运维，也是更有价值的。

但对于我们希望私有化 Signal 的人来说就不一定了，不可能还私有化一套 Cloudflare 出来，如若使用 wrangler 则只能运行一个 「模拟器」，疑心存在性能上的问题；GCS 对于某而言，用都没用过，更谈不上其他；

最终使用了两个独立的方案解决了 Signal 聊天附件存储，两个方案都可以解决，择一即可，也可以两个都用：

• 方案1，同步服务端与客户端。服务端方面，按AttachmentControllerV4 的使用方式，重新加入 aws S3 协议，将原有的 gcsAttachmentGenerator 替换为 awsAttachmentGenerator ；此方案需要同步修改客户端，但修改点比较简单，只需要去掉上传部分的 「断点续传」即可。
• 方案2，单独只改服务端，重新实现 signalapp/tus-server 即可，我做了一个例子，开源在此处： https://github.com/alexsunday/tus-storage

在 docker compose 下使用非常简单：

docker run -d --rm --name tusd --network signal -e AWS_ACCESS_KEY_ID=xxxxxxx -e AWS_SECRET_ACCESS_KEY=yyyyyyyyyy -e AWS_REGION=test1 tuss:0.0.1 /app/tuss -redis redis://redis:6379/1 -secret abcdefghijklmnopqrstuvwxyz0123456789ABCDEFG=

最终完美实现 参考下图：

使用方案2 部署，完美适配原客户端，客户端代码无须任何变更；但上传速度方面可能没有客户端直传 aws 更快；官方使用该方案是因为其部署在 cloudflare worker上，利用其遍布全球的 CDN 网络加速上传；但对于私有化部署而言，可能使用 方案1 aws s3 直传性能更优。如果你有这方面需求，或者想看看方案1，可联系我 +signal: pfoxh.25 或者 tg: pfoxh25