varx/tech on Nostr: nprofile1q…rk39d Hmm, I'm not sure how well protobufs handle extensible formats. ...
nprofile1qy2hwumn8ghj7un9d3shjtnddaehgu3wwp6kyqpq8369m6ejyjfh47ths7qrlvqcu8jvyzxnuysx72cpvg95jfvt9l0sgrk39d (nprofile…k39d) Hmm, I'm not sure how well protobufs handle extensible formats. I'd like people to be able to add extensions to the protocol; in fact, I'm planning on having a core protocol + "official extensions". Someone just implementing the core should be able to ignore everything else. So I think I need a self-describing format anyhow.
One annoying approach I could take to canonical signatures would be to require the receiver to parse the message, canonicalize, and reserialize it, and then check the signature against *those* bytes. Then I could add grease into the standard implementation (extra fields, unsorted keys) so that any new implementation immediately discovers the need to comply with that part of the spec. (Not sure if this would violate the Cryptographic Doom Principle.)
One annoying approach I could take to canonical signatures would be to require the receiver to parse the message, canonicalize, and reserialize it, and then check the signature against *those* bytes. Then I could add grease into the standard implementation (extra fields, unsorted keys) so that any new implementation immediately discovers the need to comply with that part of the spec. (Not sure if this would violate the Cryptographic Doom Principle.)