Jeff Martin on Nostr: nprofile1q…y8u0g protobufs aren't designed to be explicitly extensible, so if if ...
nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpq63w7zdlg2u0prldz2t2xtxq49upayn497zq3swe4euww4alts4ss4y8u0g (nprofile…8u0g) protobufs aren't designed to be explicitly extensible, so if if you want rich support for that, you may be disappointed here.
The workaround I use is pretty simple though. Just encode whatever you want into a `bytes` field and add that to your message. Onion encoding, if you want to call it that. In your case, a `repeated bytes extensions` field might do the trick. Then, your extension blobs would need to be self-describing somehow. Or you could wrap them in an envelope message so you can hold standardized metadata next to the blob.
Canonicalization is tricky, especially if you're trying to deal with extensions that can be a bit unpredictable. But forcing a decode-canonicalize-encode-sign step might not even get you want you want, since you're running a parse before verifying the signature. That sounds a bit dangerous.
*looks up Cryptographic Doom Principle*
Ah, yes. That seems about right. =P
The workaround I use is pretty simple though. Just encode whatever you want into a `bytes` field and add that to your message. Onion encoding, if you want to call it that. In your case, a `repeated bytes extensions` field might do the trick. Then, your extension blobs would need to be self-describing somehow. Or you could wrap them in an envelope message so you can hold standardized metadata next to the blob.
Canonicalization is tricky, especially if you're trying to deal with extensions that can be a bit unpredictable. But forcing a decode-canonicalize-encode-sign step might not even get you want you want, since you're running a parse before verifying the signature. That sounds a bit dangerous.
*looks up Cryptographic Doom Principle*
Ah, yes. That seems about right. =P