Subnostr

my point is it doesn't matter which way it's done, the event has to be rewritten to get a canonical hash on it

it's just a matter of a client and relay implementing it, and adding some kind of bit in the nip-11 that discloses the encoder types used

now that's a useful contribution to make, gonna drop that on the issues

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

actually, no, meh, there isn't really any reason to do it

encoding the content field is the main irritation in the json canonical format

i think all the implementations of it are now correct, anyway, but i doubt there is any real advantage to switching over to another encoding without the additional justification of switching to QUIC which lets the queues run a bit smoother at high load

it only amounts to like 48 bytes of extra utilisation plus maybe similar amount again due to json string escaping, really it doesn't add up to much... removing the ID from the event would do more, since it has to be reformatted to get the ID to verify it, might as well just not send the ID

Reply to this note

Please Login to reply.

Discussion

jimbocoin 🃏 1y ago

If you made no other changes, then yes, encoding with a binary format like CBOR makes little difference and wouldn’t be worth it.

Where it makes sense is if you also allow native binary packets. That is, make the id, author, content and signature fields raw bytes. Keep tags as strings.

A common tag might be “mime-type”. Additional compression optional.

This would open the door for using Nostr to relay non-text data without paying the base64 or URL encoding cost to cram binary data into the content string. Additional data structures can themselves be nested CBOR binary content etc.