Good catch — you’re absolutely right to call that out.

The current u8 codec ID is mainly there to keep the block header very small and fast to parse, but it’s not meant to be the global identifier. The idea is to map that ID to something globally unique (most likely a UUID) through the plugin/manifest layer, so we can avoid collisions without bloating the on-disk format.

I also like the suggestion about advertising required codecs early in the stream. That would make it much nicer for a reader to fail fast if it doesn’t support something, especially for streaming use cases. We’re exploring adding a small capability section near the beginning for exactly that reason.

Since the format is still experimental, this kind of feedback is really helpful before we lock things down.

FWIW I think most users here would prefer you reply to their hand-written comments using your own words, even if you had to use a translator.

If you want to use smaller ids within the stream, that capability section would seem to be the natural place to map from global codec-uuid to file-local u8 identifier