add S2PA and MUXL

[iameli]

Update 2026-05-22: Okay, finally pretty happy with this. Let me know if you'd like me to split into two commits or PRs. I'll let the specs mostly speak for themselves, but a brief MUXL changelog off of the last version:

• Everything is reframed around canonical MUXL m4s segments, and their bytes never change. Rather than muxing to different formats for certifying, we just have one hashing and content-addressing target, which makes the rest of the spec much simpler.
• MUXL segments gained a DRISL blob containing their catalog data that gets prepended to each segment in a uuid atom. I was initially reluctant about doing this, it felt too close to inventing a totally bespoke media format, but now I think it's kind of dope. It means we can concatenate together MUXL segments freely, which opens up things like BLAKE-3/BDASL addressing as moving identifiers for the full recording of an in-progress livestream.
• The presentation formats are no longer load-bearing to content-addressing and signing. Previously, signatures happened over the "Flat MP4" format, which meant if we tweaked anything about the fiddly process of edit-list synthesis, signing would break. Now they're just advisory: "here's how you could generate a standard MP4 file from some MUXL segments." And in both cases, going from presentation format to canoncial bytes is just "throw away everything until you get to the first UUID atom."
• I was unhappy with the MP4-atoms-in-your-face technical format of the previous one, so now each section has prose describing the design decision (hand-written by a human, in fact!) followed by a <details> element with the low-level technical detail needed by implementers.

[darobin]

Thanks Eli! I looked through it and IMHO it's solid enough that we can ship it as a draft, great stuff!

For the two issues, I reckon maybe simply file an issue here about each? We don't need to decide that right away.

[mishmosh]

As discussed in today's DASLing group call, including a flat mp4 will help with backwards compatibility, reference implementation ergonomics, and adoption. If you're worried about spec complexity, it can link out to a separate page/microspec/section.

+1 on proceeding with this, filing an issue to handle audio/text later. (Podcasting anyone?)

[mishmosh]

I was wondering why so many files were touched. Thanks for all the typo fixes! But I think you have to make them in each spec's .src.html file, not the .html (which is autogenerated).

README says:

Be particularly careful not to edit the .html files but rather the .src.html ones. Otherwise you'll overwrite yourself.

[iameli]

@mishmosh Whoops you're right, all of those changes just came from running the builder script, not sure what the actual diff was. Rebased to remove those from the log, no other changes yet.

My plan is to make one more change to the "canonical signing format" - now that we have Flat-MP4 capability there's no reason not to use that as the canonical form (considering you already need the entire file in order to sign it). Working on that today and then would be potentially interested in a draft-spec merge.

[mishmosh]

@iameli saw that you pushed another commit here. Is this ready for review and potential merge?

[iameli]

@mishmosh Very nearly; the Streamplace VOD beta is shipping this week and I was tweaking the details down to the last moment. I'll have a finalized version in the next day or two.

[iameli]

@mishmosh @darobin Finalized and ready for review. PR description updated with the current state of affairs.