so, ok, i'm gonna make my json codec accept \u escapes now, fine, but \/ is not ok bro

nostr:nprofile1qy88wumn8ghj7mn0wvhxcmmv9uqjqamnwvaz7tmwdaehgu3wv45kuatwv3a8wctw0f5kwtnnwpskxef0qyfhwumn8ghj7mmxve3ksctfdch8qatz9uq3yamnwvaz7tmwdaehgun4v5hxxmmd9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqyrhprfwl7sxpnf247s07g26g7q8xrry3yftz9t3hkmptkeahd38yj4jvnvj  - this one:

accepts_unlisted_json_escape_sequences: NO (error: event ID 47dbaad60179f1e855ed1cb2b72f584cc44c2aba46cb39e1879539fda702ddd6 is incorrect, should be a01faefd2fa8d2845a2c8c969e6e862924cb73299d4a944aa7e8507579a9aa42)

in my 9999 events trove pulled from old stuff from semisol's giant load of events there is stuff that has \\/ for some reason, in a http:`//` - instead it's http:`\\/\\/`and the codec can only accept this one if it doesn't interpret `\/` as an escape for `/`

what's the most odd thing about this bogus sequence is that if i search my memory the only case where you have to escape forward slash is in `sed`

so, it seems like it shouldn't be there, at all, it looks like the encoder escaped a the `//` as `\\/\\/` which is escaped from `\/\/` which would be valid sed annotations to indicate a search for `//`

*facepalm*

so i'm just gonna leave out handling escaped forward slashes altogether, i don't think the test should fail not handling this because it's either one or the other, you can't have both unless you add complex extra handling to recognise this stupidity in unescaping it

my feeling is, no, `/` does not need escaping by any stretch of the definition of JSON, so fuck whatever robot bullshit that makes them and expects them to be accepted, did they write it in bash script or something?

so anyway, meh, this is a third "NO" in the tester that i'm gonna say is a bogus test (unlisted json escapes, invalid \n in string, and the negative/missing created at and scientific notation form of the created_at all idgaf lol not gonna handle cases that are just plain wrong