also, random note, i had written the codec so it was reusing memory from received event data, overwriting the first half of hex fields, specifically id, pubkey and signature, i am altering this to allocate new memory instead because i have encountered an error where for some reason the read buffer is being decoded again and of course has mangled fields.

hooray for the wonders of AI coding agents, these tedious tasks i can delegate and not get tied up with getting these tedious, simple tasks causing bugs in my code.

well, it didn't actualy look like i really needed to do that, so i'm undoing it. was just some mangled kind 0 from nostr:npub1y80vm0yvp64cx6e8y0eetu4mhwt5muzrttgaj8a988xnx5q4kn2qlu87je oddly enough.

Reply to this note

Please Login to reply.

Discussion

ok, no, it's actually an in-spec feature, event keys that are not the main ones, a key called "tenantId"

i am not gonna bother supporting that right now, this is the first time i have ever seen an "extra key" in an event object. i don't think there is NEED for these extra keys so nostr:npub1y80vm0yvp64cx6e8y0eetu4mhwt5muzrttgaj8a988xnx5q4kn2qlu87je whichever client it is you are using, let them know that they are using gay extra keys in your kind 0 profile metadata event, and to stop it. why? i mean why the fuck do you need extra keys. tags. bro, tags.

i also saw a bunch of other users with these "tenantId" tags in their profile metadata events. fuck you. lol

dammit, i have to modify my unmarshal code to accept this bullcrap

It's Amethyst 😁

interesting that it only affected 4 out of 4000 users in my second degree social graph.

ie, nobody uses amethyst to edit their profile except for our some time klingon chancellor here.

Which profile field specifically? I'll change it and we'll see if it persists or goes away. Might be a remnant from another client 👀

it is called "tenantId" and every single one i found was

"tenantId":1

Could that have been Yakihonne or Nostrcheck.me I wonder 🤔