feat(mediorum): authenticate audio uploads and attest their cids on chain

[rickyrombo]

Stacked on #459. Review that first — this branch contains only the commit on top of it.

#459 lets consensus gate a track's cid fields on a validator attesting that the claiming wallet uploaded those bytes. This produces that attestation.

Knowing who uploaded

Upload.UserWallet was read straight out of client-supplied tus metadata under a key the SDK never sent, so it was NULL on every SDK upload and forgeable on the rest. Harmless while nothing read it; not harmless now that it decides who may claim the resulting cids.

Audio uploads now verify an EIP-712 signature at tus creation and set UserWallet from the recovered address. Unsigned uploads are still accepted where verification is not required, but are never credited to a wallet — recording an unverified one would put a forgeable value in the field attestations are built from. A signature that is offered and fails to verify is always an error, so a bad one cannot pass itself off as absent.

Why EIP-712

The previous revision of this PR hashed canonical JSON and signed it with personal_sign. Typed data is better on two counts:

• No canonicalization. The type definition is the encoding, so there is no key ordering or number formatting for client and server to agree on and later drift apart over. That whole class of bug disappears.
• Domain separation. A bare hashed payload has none — a signature produced for any other purpose over the same two fields would have been replayable as an upload authorization.

It also matches how the SDK already signs entity-manager writes, so both sides use standard calls (signTypedData, go-ethereum's apitypes) rather than a hand-rolled scheme.

The payload covers the user id and a timestamp, not the cid: at tus-create time the bytes have not been sent. Both fields also travel unsigned in tus metadata so the verifier can rebuild the typed data, but they are reproduced inside it, so tampering only breaks recovery. Stale and future-dated signatures are rejected — a captured one would otherwise be a standing credential to upload as someone else.

Only audio is covered. Images are served unauthenticated, so there is no gating story to protect, and requiring signatures would break signup, which uploads a profile picture before the account has a user id.

Decoupled from the DDEX flag

Content authorization runs off ContentAuthEnabled rather than ProgrammableDistributionEnabled. The latter governs DDEX; tying them together meant this bypass could only be closed on networks that also enable an unrelated subsystem with no production consumers — backwards for a fix to the ordinary track-upload path.

An upload is not done until its cids are attested

A client creates its track the moment an upload reads done, and consensus rejects a track naming cids it holds no claim for. Publishing the status first would race the attestation and reject perfectly legitimate uploads, so attestation happens before the status flips and a failure fails the transcode instead. SendTransaction blocks until the transaction is committed, so once the status is done the claims are genuinely on chain.

Cases where no claim was ever possible — content auth off, or an upload with no verified signer — return cleanly rather than erroring, since there is nothing to wait for and no reason to hold the upload back. That decision is split into contentAttestationFor so the rules are testable without a chain.

Cids are attested as they come into being

The initial upload sends one attestation covering the original, the 320 transcode and the preview, since all three exist by the time transcoding finishes.

Previews are the reason #459's attestation carries a plain cid list rather than named orig/transcode/preview fields. POST /uploads/:id lets a client change previewStartSeconds after the fact, which regenerates the preview and yields a new cid every time. Under a single fixed-shape attestation sent at transcode completion, that cid would never be attested and saving the track would be rejected. The edit path now sends its own attestation for the new cid, before responding, so a caller never receives a preview cid it cannot yet use.

Attestation requires a verified signature

Not merely a wallet. The legacy POST /uploads and gRPC paths still populate UserWallet from an unverified X-User-Wallet-Addr header, so keying off the wallet alone would let a forged header mint a claim over someone else's content. Those paths are otherwise untouched; the header fallback is a pre-existing hole worth closing separately.

Testing

Unit coverage for signature recovery, staleness, future-dating, field tampering, the per-template rules, flag independence, which uploads warrant an attestation, and that the skip cases never block an upload from completing.

One is a cross-implementation fixture: a real EIP-712 signature produced by the SDK using viem, pinned so the two independently-written signing paths cannot drift apart silently while both suites still pass on their own. I confirmed it recovers to the expected address in Go before wiring it up.

There is no integration coverage of this path, and I could not add any in this PR. TestUploadStream — the only devnet test that uploads audio — has been skipped since fe3d95c ("flaky on resource-constrained CI runners"), and even un-skipped it would not exercise this change: it uploads through the legacy POST /uploads multipart endpoint with the old per-cid query-string signature, while upload authentication hooks the tus path (tusd.go). An earlier revision of this stack was reported here as devnet-verified; that was overstated, and I have removed the claim.

What that leaves untested end to end: signature verification against a real tus client, the attestation reaching consensus, and the done-blocks-on-attestation behaviour. The unit tests cover the decision logic and the signing format on both sides, but not the wiring. Worth deciding whether this stack should carry a tus-based integration test before enforcement is scheduled.

Two pre-existing test issues found along the way, neither caused by this change: TestGRPC panics on a nil response (fails identically on the base commit), and TestUploadFile / TestRepair / TestPollDelistStatuses are not idempotent — they only pass against a fresh database.

🤖 Generated with Claude Code