File sync broken: filemeta IDs don't match S3 storage keys

[petergaultney]

Problem

Binary file sync doesn't work. Two issues found:

1. Filemeta hash field contains incorrect values

Almost all file entries in the filemeta CRDT have the same hash value (da7b674ea47abd6abcd69e834b03223cea1bf032e839bd37d747d68ad2133f65), regardless of actual file content. This is clearly not the real file content hash. The git-sync passes this hash to /f/{id}/download-url?hash={hash}, and the relay server returns 404 because no file exists at that hash in the S3 store.

The actual files in Tigris have correct, unique hashes - the mismatch is in the filemeta CRDT data.

2. Filemeta IDs don't match S3 storage keys

The filemeta id fields (e.g., 54bdc2c7-...) have zero overlap with the UUIDs used in Tigris S3 keys (e.g., 019771a6-...). The git-sync constructs download URLs using relay_id-filemeta_id as the compound doc ID, but the files are stored under different UUIDs.

Evidence

Filemeta entries (from CRDT via Y-Sweet API):

54bdc2c7-...  hash=da7b674ea47abd6a...  /z-attachments/simpson strong-drive screws.png
26119b9a-...  hash=da7b674ea47abd6a...  /z-attachments/Screenshot 2025-07-30 at 17.00.25.png
41f9bc2e-...  hash=da7b674ea47abd6a...  /pitches/cycle-11/purple/z-attachments/IMG_0751.jpg

Tigris S3 keys (different UUIDs, different hashes):

files/26120033-...-019771a6-.../1bb18b5d4bc9f019...  217582 bytes
files/26120033-...-047bba0b-.../3b0b06698cfe9836...  111065 bytes

Zero filemeta IDs or hashes match any Tigris entries (0/35 files, 0/86 S3 objects).

Context

• This was working as recently as Feb 23, 2026 (relay-server v0.8.5)
• Broke around March 3, 2026 when relay-server was upgraded to v0.9.6
• With Tigris properly configured, download-url returns valid Tigris presigned URLs, but the wrong hash/ID means the file can't be found

Environment

• relay-server v0.9.6 with Tigris store
• relay-git-sync v0.0.4
• Obsidian Relay plugin v0.7.4