%i8kZo3h3awoj/t/aY33fdLtcz0fDOUfU3f6VeOrmfvo=.sha256natural numbers (positive integers and zero) are first, so "6" is first, because it's a valid integer. the rest of those keys are not valid integers:
numbers that are not valid natural numbers are encoded as strings and lexicographically sorted.
The output on my test message is definitely not lexicographically sorted for the non-integer keys. Can you point to a source for the deserialization order you claimed? Is it part of the ECMAScript spec, or just an implementation detail of node? Does node guarantee that behavior, or might it change?
About the scope of this issue: This is not part of the core message format, instead this is a detail of the rpcs sbots use to send messages to each other. But in practice, this forces signature computation to use the exact same object entry ordering, or all sbots will reject the message, since they will compare the message's claimed signature against the signature they got by using the ordering emitted by JSON.stringify(JSON.parse(str), null, 2). If we don't change the sbot rpcs but don't understand the entry ordering procedure either, it becomes impossible to write non-js implementations (and the js one could break on us with any new node version, at which point the scuttleverse would fork).
We really should change the rpcs to use a decoding procedure we actually understand. And since we need to support those legacy messages for which we do not understand the entry order, we should let is simply use the entry-order of the input when computing the signing format.
This is a pretty serious issue, can I please get back an ack that you are fully aware of the consequences @Dominic? Your previous post reads like you don't see a problem here.