TrentonZero on Nostr: The \n case makes me wonder if the internal string representation in your language ...
The \n case makes me wonder if the internal string representation in your language always uses either Windows or Unix line endings (\r\n or \n respectively), and coerces everything coming in to that form. Alternatively, there is a specific character encoding (UTF8 in Java for example) that is always used internally, and you're actually getting a ISO-8859-1 message.
Either way, when you naively feed the bytes from the string into the hashing algorithm, you are subtly changing the message (changing Windows line-endings to Unix, or changing ISO-8859-1 to UTF8).
That would be my guess.
>From: (zerosequioso) at 08/20/22 11:37:46 on wss://relay.zerosequioso.com
>---------------
>Are there any gotchas to hashing messages that contain escape characters in the content? I keep getting the wrong hash according to noscl when content contains things like \n or \"
Either way, when you naively feed the bytes from the string into the hashing algorithm, you are subtly changing the message (changing Windows line-endings to Unix, or changing ISO-8859-1 to UTF8).
That would be my guess.
>From: (zerosequioso) at 08/20/22 11:37:46 on wss://relay.zerosequioso.com
>---------------
>Are there any gotchas to hashing messages that contain escape characters in the content? I keep getting the wrong hash according to noscl when content contains things like \n or \"