Side-note on hsdt extensibility: It might seem reckless to use up all of these potential extension points for hsdt. But there is an interesting interplay between protocol extensions and canonicity requirements. Hsdt has to reject any non-canonical content. But suppose it also supported future extensions by requiring implementations to ignore certain pieces of data. An implementation could thus accept some message that contains an unknown data extension, but after the implementation learns about that extension, it suddenly detects that the included data was non-canonical. Should it now retroactively ignore the message? This problem basically means that there can only be very limited extensibility in hsdt, as will be used below. But fundamental changes will require a (conceptually) new data format with its own hash primitive. So hsdt itself can happily use up a bunch of cbor's extension points, as they could not be built upon after the initial specification anyways.

@dinosaur Was that paragraph unclear, or did you miss it? Canonicity implies that we can't do non-breaking changes, that's why I allocated all of the primitives. Any future format that might add e.g. 16 bit or 128 bit floats would need a different hash suffix than hsdt.

In general, future extensibility requires ignoring parts of the data, and I don't think that can be reconciled with canonicity. And even if it could, what would the semantics of this be? Should a message signal to the client "by the way, you are missing some information you can't understand, either because you are outdated, or because it is complete garbage, who knows?"? I (tentatively) think disallowing unknown content is the correct choice here. And as a consequence, we get to allocate all those tasty, efficient values.