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 

 And you dun even hafta escape forward slashes in sed by using another character as your delimiter (`|` for example)!  

 Ok but... JSON allows "\/" to mean "/".  Dumb that it does, but it does.  If you find a "\\/"  that means "\/".  The "\\" prefix becomes "\" and the suffix remains "/".  The escaping is not recursive so it then remains "\/" in total, it doesn't do another pass to become "/".

But it probably doesn't matter much.  Events that use "\/" escaping are kinda dumb and unnecessary and NIP-01 violations.

As for things like scientific notation, I never expected any relays to support that. Chorus doesn't. The test is just more of a curiousity.  This is why it says "NO" meaning NO we don't support that (perhaps stupid) thing, rather than the more judgemental FAIL. 

 ah, that helps

well, i've reached the point with this tool where all the rest of my issues relate to subscription management and i haven't properly implemented that yet so i'm digging into khatru to figure out what i need to add... i've got the basics all there but not the part where it actually scans the subs from incoming events, or closing subs properly when they do the limit, etc etc

that's gonna be more complicated, i think, because the code i've built already plays nice with the "cache relay" interface from nostrudel which is a lot more dumb and acts like it's got infinity bandwidth

just so many times i'm like "so why doesn't the reelay see an event when i click this" and the clients just give ZERO feedback on why there is a problem, except maybe if your relay sends a NOTICE or OK, false