@keks

Actually I was just thinking that possibly, at some point in the future someone bridges networks and has ciphertext in a foreign format[...]. So maybe it's not just for legacy reasons.

Yeah, the non-legacy format should be designed to deal with this kind of thing. I'm don't want the future system to be more rigid than the legacy stuff. But the legacy system is both too rigid (in that it can only do an identifier per format) and too open ended (in that the identifiers are way too complicated). The overcomplication is the part we can easily deal with. Everything else, we can tackle with the clean slate of the non-legacy format.

As for the hashing, I just don't see how this provides any advantage over just allowing any 64 bit id without caring about how it was created.

@Christian Bundy

Is there a reason why our codecs couldn't be described in a multiformat table?

Is there a reason why they should be? =P

Ssb will end up using tables to look up multiformats identifiers, but we will be better-suited using our own formats. I have rambled a bit on shortcomings of the ipfs varints here, we can save the length indicator in some cases, and I'm not a fan of their policy of trying to cover all the formats at once. I guess I can go into more detail if you want, but that won't happen today.