Well, I might fail at step 1.

Parsing public keys are confusing. In the past, all keys are 256 bytes for crypto and 128 bytes for signing.

But then we have other algos, which introduce keys like 128 bytes, 512 bytes, 32 bytes, etc. How does I2P respond?

For those keys smaller than 256/128 bytes, just add paddings. Add padding after the crypto key and before the signing key.

What about those longer keys? Just chop them off. Write only the first 256 bytes of the crypto pub key and the first 128 bytes of the signing pub key. Then put the excess into a separate structure after the pub keys. Now you get something like: CryptoPubKey(part of), SigningPubKey(part of), KeyCertificate(the rest of them, act like a patch).

Is that self-contain? Not yet. That's how they handle things in RouterInfo. In some places like LeaseSet have a separate encryption and signing key, which, doesn't have any KeyCertificate. And the doc said: Key type and length are inferred from context or are specified in the Key Certificate of a Destination. Well, I do spot a Destination, but what if we have a long pub key? Where is the excess? The Destination itself has its own crypto and signing pub key. And we have part of the keys outside it. WTF

I guess that's reason why people fork it and make changes like I2P+, rather than start a new project from scratch. Those data structures are preventing people from setting up new projects. It's too hard to parse and easy to screw up.