almost there with this... 

found one problem, the tag writer was not putting a zero byte in to indicate the tag field is empty

this was also causing the content field to not be decoded properly because it was decoding a length value of the content instead of the tag, and finding invalid bytes or even varints following it and giving up on the decode

next obvious problem has to do with a tags, that i mentioned also... a typical example:

original
```
["a",
"32123:7759fb24cec56fc57550754ca8f6d2c60183da2537c8f38108fdf283b20a0e58:a470b862-1522-4c91-bb11-ded892d8d1
61","wss://relay.wavlake.com"]
```

mangled
```
["a",
"0:3737353966623234636563353666633537353530373534636138663664326336303138336461323533376338663338313038666
4663238336232306130653538:a470b862-1522-4c91-bb11-ded892d8d161","wss://relay.wavlake.com"]
```

if you are familiar with ascii, you'd know that 37 is the number `7` and 35 is `5` so you can see that what has happened is it has failed to encode the kind prefix (which is a decimal) and it has instead decoded the hex value, which is decoded to binary in my binary encoder for a, p and e tags field 2 and for id, pubkey and signature

the a tag is the most complicated because it contains two numbers, which i have encoded as a 16 bit prefix value and a 32 byte for the npub that follows in an `a` tag.

likely again it's some mess to do with the `a` tag processing either it's writing, or not writing the varint prefix correctly... really, the a tag should not need a length prefix until the third arbitrary text field, so i've probably messed that up somewhere

note that all of the bugs i'm finding here were outliers... events with no tags are not common, and `a` tags are mostly only used with delete events. still a problem though, because for those cases it fails to decode properly, or encode properly, or both, and this is unexpected behaviour for clients

probably there will be one or two more little glitches to get through here

like, for example, maybe i should try to make a prefix code for these tag types so if it spots this prefix code it knows the field is noncompliant and stores it verbatim

nostr:nevent1qvzqqqqqqypzqnyqqft6tz9g9pyaqjvp0s4a4tvcfvj6gkke7mddvmj86w68uwe0qyghwumn8ghj7mn0wd68ytnvv9hxgtcpz4mhxue69uhhgetnwsh8yetpd3ujumr0dshsz9mhwden5te0d4kx26m49ehx7um5wgcjucm0d5hszythwden5te0dehhxarj9emkjmn99uqzpu0wdtqumzdlrwt2ctqaatylhwcuw8j6ewyw66wypth5lhhf0xfjvhkccv