Add BRC-145: Block Media Format (BMF) — Composable On-Chain Audio/Video

README.md

@@ -204,6 +204,7 @@ BRC | Standard
 138  | [Single-Use Signed Proofs for Request Authentication](./peer-to-peer/0138.md)
 139  | [Multicast Shard Manifest Announcement Protocol](./transactions/0139.md)
 140  | [Threshold Key Sharing and Backup via Shamir's Secret Sharing Scheme](./key-derivation/0140.md)
+145  | [Block Media Format (BMF) — Composable On-Chain Audio/Video](./apps/0145.md)
 
 ## License
 

SUMMARY.md

@@ -12,6 +12,7 @@
 
 * [The deployment-info.json Specification](./apps/0102.md)
 * [Auditable Real-time Inference Architecture (ARIA)](./apps/0122.md)
+* [Block Media Format (BMF) — Composable On-Chain Audio/Video](./apps/0145.md)
 
 ## Wallet
 

apps/0145.md

@@ -0,0 +1,95 @@
+# BRC-145: Block Media Format (BMF) — Composable On-Chain Audio/Video
+
+<!-- Author line: a handle + a contact link. Email is optional in a BRC; the PR/issue thread is the real discussion channel. -->
+sun-dive (https://github.com/sun-dive)
+
+## Abstract
+
+Block Media Format (BMF) is an open format for **composable, on-chain-native audio/video**. Instead of one monolithic encoded file, a "video" is expressed as a small **timing manifest** that references independently-owned **media components** — each of which can be minted once on-chain, provenanced, and reused many times. BMF defines two file types: `.bmf` (the manifest / "recipe") and `.bmc` (a portable ZIP container bundling a `.bmf` with its media). BMF introduces **no new codec** — it carries standard WebP, FLAC and MP3 inside — and requires no IANA registration to use. It is the media-composition layer that sits above component-level token/provenance standards.
+
+> The Abstract section should concisely describe your proposal at a high-level.
+
+## Motivation
+
+Conventional video is a single opaque file: content is duplicated wherever it recurs, and the individual parts (a loop, a stem, the master audio) carry no independent ownership. On a chain that can carry media payloads, each component can instead be its own on-chain asset with its own author and royalty.
+
+BMF exists to make that structure expressible and playable:
+
+1. **Store once, reference many.** A clip used at five moments is one stored component plus five cue lines — not five copies.
+2. **Component-level provenance.** Every clip and the song is an owned on-chain asset; a composition is a *composition of owned parts*, each independently attributable and monetizable. This complements token/provenance standards (e.g. BRC-113, MPT<sup>[1](#footnote-1)</sup>).
+3. **Fully on-chain composable video.** When a manifest references components by **txid**, the "video" is nothing but a tiny manifest; a player fetches each component from chain and sequences it — no fat file anywhere.
+4. **Standard media, universal decode.** No bespoke codec; anything that plays WebP/FLAC/MP3 can implement a player.
+5. **Tempo-native authoring.** Cues are absolute seconds, so scenes can be placed on the beat.
+
+> The Motivation section should let people know the context for your proposal, and why it was written.
+
+## Specification
+
+1. **Two file types.**
+   - `.bmf` — **Block Media Format**: the manifest — a timeline that references media components (by on-chain **txid**/outpoint or by local **filename**) with start-time cues.
+   - `.bmc` — **Block Media Container**: a ZIP holding exactly one `.bmf` plus the media files it references by local name — the portable, self-contained form.
+   A `.bmc` **contains** a `.bmf` + media; a standalone `.bmf` **references** on-chain content. One spec, two delivery forms.
+
+2. **Manifest encodings.** A `.bmf` MAY be written in either encoding, and a conformant player SHOULD accept both:
+
+   **A. Cue form (LRC-compatible).** References components by local filename. Lines are `[mm:ss.cc]<name>`, with optional `# key: value` headers:
+   ```
+   # bmf: 0
+   # audio: supersonic.mp3
+   # tempo: 110
+   [00:00.00]forgotten-control-room.webp
+   [00:04.36]power-low.webp
+   [00:08.72]power-high.webp
+   ```
+
+   **B. JSON form.** Carries on-chain **txid** references (the pure on-chain form):
+   ```json
+   {
+     "bmf": 0,
+     "audio": { "tx": "6059dfef894d83be6df1ca858e7d644dfbc1256b7611f98abb1a1111765ba0e5", "name": "supersonic.mp3" },
+     "tempo": 110,
+     "scenes": [
+       { "t": 0.00, "tx": "dff809f6ab5052ed96f7a75e2f9751e88cedcf9aca2e8211b9c46b1ec76de128", "name": "forgotten-control-room" },
+       { "t": 4.36, "tx": "2722b170aace00cc992bf671dc458f30588e96ad4a5992308c46dc01f574e5bc", "name": "power-low" },
+       { "t": 8.72, "tx": "2722b170aace00cc992bf671dc458f30588e96ad4a5992308c46dc01f574e5bc", "name": "power-high" }
+     ]
+   }
+   ```
+
+3. **Fields.**
+   - `bmf` — format version integer (currently `0`).
+   - `audio` — the master audio track, by `tx` (on-chain) and/or `name` (local).
+   - `tempo` — OPTIONAL BPM metadata to aid beat-aligned authoring.
+   - `scenes[]` — ordered scene cues: `t` = scene start in **seconds**; `tx` = on-chain reference (txid/outpoint of the minted component); `name` = filename/label (used inside a `.bmc`, or as a human label).
+
+4. **Playback semantics.** A scene plays until the next scene's `t`. Looping media (e.g. animated WebP) **restarts from frame 0 on its cue**, so loops stay phase-locked to the beat.
+
+5. **Resolution algorithm.** To resolve a `.bmf` a player MUST:
+   1. Load the manifest (cue or JSON).
+   2. Resolve `audio` and each scene reference: if `tx` is present, fetch that component **from chain** (raw tx → extract media payload); else read `name` from the accompanying `.bmc` / folder.
+   3. Play the audio; at each cue time, switch to that scene and restart its loop; hold until the next cue.
+
+6. **Media constraints.** Components MUST use standard, universally-decodable media — WebP (including animated and **variable-frame-rate**, where a long hold costs a single frame), FLAC, or MP3. BMF defines **no new codec**.
+
+7. **MIME types (informal).** `.bmf` → `application/x.bmf` (or `application/vnd.blockmedia+json` when JSON); `.bmc` → `application/x.bmc` (or `application/vnd.blockmedia+zip`). The `x.` experimental tree is used today; a `vnd.` registration MAY follow if native OS/browser recognition is ever required.
+
+> The Specification section of your proposal should stipulate all information needed to implement the standard, and make up the bulk of the document. Generally, people should be able to create a compatible implementation with only the specification.
+
+## Implementations
+
+1. **Authoring tool** — a local-first studio ("Pole Position") whose music-video timeline exports a `.bmc` (media files + a `.bmf` cue manifest).
+2. **Player** — a smart-NFT player reads the manifest, resolves each component (by txid from chain, or by name from the container), and sequences the scenes to the audio, restarting loops on cue.
+3. **Reference repository (MIT):** `https://github.com/sun-dive/block-media-format` — full v0 spec, examples, and the `.bmf` / `.bmc` definitions.
+4. **First real-world components (BSV mainnet).** The "Supersonic" release ships its building blocks as individually-minted, provenanced, reusable on-chain assets — each resolvable today and composable in a `.bmf` by `{tx, name}` reference<sup>[2](#footnote-2)</sup>:
+   - *Forgotten Control Room* — an SOS-flicker loop BMF atom: `dff809f6ab5052ed96f7a75e2f9751e88cedcf9aca2e8211b9c46b1ec76de128`.
+   - *Suited Up* — three tube-power loops published as ONE `.bmc` set, each member addressable by `{tx, name}`: `2722b170aace00cc992bf671dc458f30588e96ad4a5992308c46dc01f574e5bc` (members `power-low`, `power-medium`, `power-high`).
+   - *Supersonic* master audio: `6059dfef894d83be6df1ca858e7d644dfbc1256b7611f98abb1a1111765ba0e5`.
+
+> The Implementations section should contain information about places where the standard is implemented, or examples of its implementation.
+
+## References
+
+- <a name="footnote-1">1</a>: Merkle Proof Token (MPT) protocol — BRC-113, https://github.com/bitcoin-sv/BRCs
+- <a name="footnote-2">2</a>: Block Media Format reference implementation and examples, https://github.com/sun-dive/block-media-format
+
+> The References section should contain any footnotes used throughout the document.