but how to preserve it in the json object so the binary version can be derived/verified from it? easier to stick with existing fields but define a strict meaning to one that is then essentially exempted from the indexing rule, this way clients won't break decoding it even if they don't use it

adding more keys to the object is going to break them, and you do want to keep these extra fields (sans ID) in other encodings

Reply to this note

Please Login to reply.

Discussion

yes, my suggestion would be then, that you put the tags so it's `["b","",""] and the rest is implied by the canonical encoding rule

we don't have to have the ID in the wire format, period, so it doesn't have to be in the tag either, actually

i personally am very much in favour of making a gradual move towards this by suggesting that relays and clients with some nip-11 flag understand events that are in canonical format, and then you can add a futher tag with a list of supported encoders and the in-event signature for other formats, which are optional, only the json form is mandatory, can have signatures for your faster verification form the binary form. done.

also just need to point out - the signer of an event could make an after-the-fact amendment to add the tag with another tag that refers to the replaced version that gives you your new (multiple) signature tags as i described, much like the parameterised replaceable protocol already existing