Skip to content

feat(relay): record who uploads each media blob - #8448

Closed
ngoodger-block wants to merge 2 commits into
block:mainfrom
ngoodger-block:feat/media-uploaders
Closed

ngoodger-block wants to merge 2 commits into
block:mainfrom
ngoodger-block:feat/media-uploaders

Conversation

@ngoodger-block

@ngoodger-block ngoodger-block commented Oct 19, 2026 •

Copy link
Copy Markdown
Contributor

Why?

Channel-scoped media reads (#8444) must still let someone read bytes they uploaded themselves, even when identical bytes (the same meme, say) are already attached in a private channel they cannot see — and the relay has no record of who uploaded what.

What?

A community-scoped media_uploaders table (migration 0067, write-fenced and purged with the community like other tenant tables) and a row recorded on every successful upload, including deduplicated re-uploads, written under the upload's serving-write lease like other final writes of a side effect; the upload fails if the row cannot be written. Nothing reads the table yet — #8444, stacked on this, does.

Related issue

Prerequisite for #8444.

Testing

Postgres tests for idempotent recording and refusal once the upload's serving lease is released; migration and deletion-manifest tests updated.

Add a community-scoped `media_uploaders` table (migration 0067, write-fenced
and purged with the community) and record the uploader on every successful
upload, including deduplicated re-uploads. Uploading the exact bytes proves
possession, which channel-scoped media reads (block#8444) will use to
admit an uploader even when the same bytes are attached somewhere they cannot
read. Nothing reads the table yet.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Signed-off-by: Nikolaj Goodger <ngoodger@squareup.com>
@github-actions

github-actions Bot commented Oct 19, 2026 •

Copy link
Copy Markdown

🔐 Codex Security Review

Status: review required for the current range.

The current range is 3debf18f1448334aa7bc202d328d93bb9651e168...4474d69f42ea98e774871fa3ec9b631bb8c14cff.
A new review must complete for this exact range. When manual authorization
is required, a user with write access must comment exactly
@buzz-security-review 4474d69f42ea98e774871fa3ec9b631bb8c14cff to authorize a new review.
Any previous review applies only to its recorded range.

Record the uploader in a transaction admitted with the upload's serving-write
lease, like other final writes of an external side effect, so an admitted
upload can finish while its community quiesces and nothing lands after the
lease is gone.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Signed-off-by: Nikolaj Goodger <ngoodger@squareup.com>
@ngoodger-block

Copy link
Copy Markdown
Contributor Author

🤖 Closing: folded into #8444, which now creates both media access tables in one migration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant