I'm adding support for multiple public keys per actor in Smithereen for future-proofing purposes.
-
@silverpill I see... Got a link to that, I should update my stuff...
-
@silverpill I see... Got a link to that, I should update my stuff...
@silverpill nevermind, I found it in the FEP.
-
@silverpill @mariusor ok, so after actually reading the FEP, I see that the encoded representation of each key has a variable-length integer prefix specifying which kind of key it is. And it's also encoded into "base-58-btc" so that... implementers suffer? I don't get it. Why not just use base64, that seems like an unnecessary nuisance
-
@silverpill @mariusor ok, so after actually reading the FEP, I see that the encoded representation of each key has a variable-length integer prefix specifying which kind of key it is. And it's also encoded into "base-58-btc" so that... implementers suffer? I don't get it. Why not just use base64, that seems like an unnecessary nuisance
Why would anyone suffer from base-58-btc? IMO it's nice.
base-58-btc is used in eddsa-jcs-2022 cryptosuite, in did:key and in other places. I don't know why, but it makes sense to use the same encoding everywhere.
IIRC newer specs from Verifiable Credentials group allow both base-58-btc and base-64-url.
-
Why would anyone suffer from base-58-btc? IMO it's nice.
base-58-btc is used in eddsa-jcs-2022 cryptosuite, in did:key and in other places. I don't know why, but it makes sense to use the same encoding everywhere.
IIRC newer specs from Verifiable Credentials group allow both base-58-btc and base-64-url.
@silverpill @mariusor well, because it's not part of the Java standard library so I'll have to implement it myself
-
@silverpill @mariusor huh, interesting, I tried fetching your actor and it turns out one of the contexts uses a JSON-LD version that's too new for my JLD processor... Also probably the first time ever I'm seeing @ graph used in the wild.
Not really a problem for me as I was going to put these two contexts into my resources anyway and I could as well edit them.
-
@silverpill @mariusor ok, so after actually reading the FEP, I see that the encoded representation of each key has a variable-length integer prefix specifying which kind of key it is. And it's also encoded into "base-58-btc" so that... implementers suffer? I don't get it. Why not just use base64, that seems like an unnecessary nuisance
@silverpill @mariusor so the prefix is always 2, which corresponds to "identity", which is quite useless, it could as well not be there
-
@silverpill @mariusor so the prefix is always 2, which corresponds to "identity", which is quite useless, it could as well not be there
@silverpill @mariusor the example key from the FEP also uses 2 for that... The FEP itself says "Implementers can use cryptographic keys of any type for which a Multicodec prefix is registered.", I'm very confused. There's 0x1205 for RSA public keys and 0xed for ed25519 ones for example.
-
@silverpill @mariusor huh, interesting, I tried fetching your actor and it turns out one of the contexts uses a JSON-LD version that's too new for my JLD processor... Also probably the first time ever I'm seeing @ graph used in the wild.
Not really a problem for me as I was going to put these two contexts into my resources anyway and I could as well edit them.
@silverpill @mariusor what is even going on here. It's definitely not base58 decoding since I tried several different decoders and they all gave the same result.
-
@silverpill @mariusor the example key from the FEP also uses 2 for that... The FEP itself says "Implementers can use cryptographic keys of any type for which a Multicodec prefix is registered.", I'm very confused. There's 0x1205 for RSA public keys and 0xed for ed25519 ones for example.
@silverpill @mariusor what is even going on here. It's definitely not base58 decoding since I tried several different decoders and they all give the same result.
The first key is from the Multikey array, the second one is the regular publicKey after base64 decoding.
-
@silverpill @mariusor what is even going on here. It's definitely not base58 decoding since I tried several different decoders and they all give the same result.
The first key is from the Multikey array, the second one is the regular publicKey after base64 decoding.
@silverpill @mariusor OpenSSL ain't having any of it either
-
@silverpill @mariusor OpenSSL ain't having any of it either
@silverpill @mariusor ughhhhhhhh. So that's what the "multibase" thing is.... There's ANOTHER spec (https://www.w3.org/TR/cid/#multibase-0) that says that the first character of the string specifies which encoding it uses because it can be different (but not for this FEP). Amazing format. Very convenient to debug.
After that change, it turns out that the RSA key is encoded as "the weird Misskey format" that Java can't parse natively, but I already have the code to handle that at least.
-
@silverpill @mariusor ughhhhhhhh. So that's what the "multibase" thing is.... There's ANOTHER spec (https://www.w3.org/TR/cid/#multibase-0) that says that the first character of the string specifies which encoding it uses because it can be different (but not for this FEP). Amazing format. Very convenient to debug.
After that change, it turns out that the RSA key is encoded as "the weird Misskey format" that Java can't parse natively, but I already have the code to handle that at least.
@silverpill @mariusor at last, I did it
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login