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