@keks I still feel like we are talking past each other.

We need to clearly separate the logical data values from the actual encodings. The logical value of a multibox consists of an identifier for the primitive, and a slice of bytes (the cyphertext). To me, this discussion is primarily about settling on the type of the primitive-identifier.

Assuming the identifier type is uint64, we can then look at possible encodings, and there are a bunch of those. For the machine-exchange format, I would have defaulted to using a VarU64 (n.b. not the same as a multiformats varint) for the identifier, followed by the cyphertext (varu64 for the length, followed by that many raw bytes).

The next encoding we'd need is one that is compatible with the current json-based signing format that is used to compute the signature of each message. This is done by base64 encoding the cyphertext, appending .box and then appending a suffix identifying the primitive. The suffix for the "private box" primitive is the empty string. Whatever encoding scheme we come up with needs to respect this.

The signing encoding doesn't really need to be all that human-friendly, which is why I'd just go with simply hex-encoding (without any leading zeros) the varu64 identifier to obtain the suffix. This conveniently maps the identifier zero to the empty string.

Where does the hashing scheme fit in here? Honestly, I have no idea. If you want to display a multibox to a human, take its logical value and do whatever you want - the ssb protocol shouldn't need to care. You can suggest a default approach, but I'm free to completely ignore it anyways.

The question of which identifiers to reserve is pretty orthogonal to the encoding questions. But considering that a varint encoding is likely, it might make more sense to reserve based on the least-significant bit than based on the most significant bit, since the former assigns the same number of efficiently encodable identifiers to the reserved and the non-reserved space.