docs(readme): the demo plays at the top, with sound

[wine-fall]

A radio you cannot hear is a README nobody can evaluate. The repo had no demo of any kind — no video, no gif, no audio — so judging murmur meant installing Node 24, ffmpeg, yt-dlp, a Claude subscription and a voice endpoint first. Nobody does that for a project they have not heard.

The player goes above the fold, right after the one-line pitch, with controls and without autoplay, so a click gives the voice.

Why the video is hosted, not committed

Three routes were tried. Only one can work, and the reason is GitHub's own CSP:

media-src github.com user-images.githubusercontent.com secured-user-images.githubusercontent.com
          private-user-images.githubusercontent.com
          github-production-user-asset-6210df.s3.amazonaws.com gist.github.com github.githubassets.com

Route	Result
Release asset	❌ releases/download/… 302s to release-assets.githubusercontent.com — absent from the allowlist
Commit the mp4, use a raw URL	❌ raw.githubusercontent.com is also absent — and a 5MB binary is carried by every clone forever
Attachment CDN	✅ redirects to github-production-user-asset-6210df.s3.amazonaws.com, which is on the list

An attachment uploaded but never posted does not persist — the first URL minted this way returned a plain 404. The asset is durable only once a comment carrying it exists, so it lives on #206.

poster and playsinline are dropped by GitHub's markdown sanitizer (checked with gh api /markdown); src, controls, muted and width survive. GitHub adds muted itself, which is why the caption tells the reader to turn the sound on.

The file is 5.1MB — the original 1080p recording re-encoded at CRF 30, which a mostly-static dark terminal takes without visible loss (checked on a text crop at 1:45).

Verification

Server side, all confirmed:

• curl on the asset: 206, content-type: video/mp4, valid ISO Media header
• both hosts in the redirect chain are on the media-src allowlist
• the <video> element renders in the README with controls — screenshot taken on the branch
• zero securitypolicyviolation events fire

Not confirmed, and owed to a human: actual playback. The automated browser used for this session will not buffer video at all — it fails identically on a direct top-level navigation to the S3 URL, with no GitHub page and no CSP involved. That points at the harness, not at this change, but it means the one thing that matters was not proven by me.

Before merging, please open the branch README, click play, and confirm you hear the host.

AI coding brief

Original request. The user is promoting murmur overseas and had two stars. They supplied a demo video and asked for it to go in the README. They also asked to confirm the promotion sequence: Reddit and HN karma first, Show HN last.

Manual interventions. One permission gate: minting a durable attachment URL requires posting a public comment on the repo, so the user was asked before anything was posted, and chose #206 over a dedicated issue. Two decisions taken without asking: re-encoding to 5.1MB rather than committing 16.4MB, and renaming the asset after the first upload exposed the internal name murmur-demo-small.mp4 in the player's title bar.

Retro. Reading the media-src header before trying anything would have skipped the release-asset attempt entirely — one curl -I contained the whole answer. The costlier mistake was trusting a probe over the evidence: injected JavaScript reported the video failing three times and each result was treated as a fact about the change, when the harness itself was the variable. A direct navigation to the raw asset — the control case that isolated it — should have been the second step, not the ninth.

🤖 Generated with Claude Code

https://claude.ai/code/session_01P6pPTjtKyjcz4rbDKBPVNe