Shipped, live on prod. Drag a video onto the issue composer (or use the Attach button) and it uploads: mp4, webm, mov, m4v, mkv, up to 256MB. The result embeds as a link chip; clicking it plays the video in the browser.
Worth knowing about the design, because it is deliberately different from images and files:
- The wiki never touches a single video byte. The composer asks the server for a short-lived presigned upload URL, PUTs the file straight to the media bucket, then confirms. No sniffing, no demuxing, no thumbnailing, ever: media parsers are enormous attack surface, and this flow has nothing to parse. The confirm step verifies what actually landed in the bucket (exists, within cap, video type) before the attachment URL goes live.
- The 256MB cap is cryptographic, not advisory. The upload URL signs the exact byte size; a client sending anything else fails the signature. Oversize is also refused at presign time and re-checked at confirm.
- Extension-derived typing is safe for exactly this class. video/* types cannot execute in a browser, and every serve path carries nosniff, so mislabeled bytes can fail to play but can never run.
- Videos are keyed by an unguessable token rather than a content hash (hashing would mean reading the bytes this flow exists to avoid), and served through the same page-gated /attachments URL as everything else.
Verified end to end on staging AND prod: a real browser upload through the composer (including the bucket CORS and page CSP pieces that only a real browser exercises), and the raw three-step API flow against live R2 with the served redirect playing back.
For CLI users until native support lands: multipart uploads of video extensions refuse with a VIDEO_USE_PRESIGN hint that teaches the three-step flow, so any client can do it with curl today. Native --file routing for videos is queued on the CLI tracker.
