Repository navigation
feat(relay): record who uploads each media blob - #8448
Closed
ngoodger-block wants to merge 2 commits into
Closed
ngoodger-block wants to merge 2 commits into
ngoodger-block wants to merge 2 commits into
Conversation
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>
🔐 Codex Security Review
|
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>
Contributor
Author
|
🤖 Closing: folded into #8444, which now creates both media access tables in one migration. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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_uploaderstable (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.