Typically no, but in trying to keep close to the specs I was working from (lists and long form content) this was a good compromise.

The tags section of a list makes up the whole list. There there is nothing in there that states what belongs or doesn't belong to the list.

I thought about some sort of "list spec" as an element of the tags section:

```

{

tags:[

...,

["eventlist", ["e", id0, relayhint0],["e", id1. relayhint1],...],

...

]

//eventlist as a list within the list of tags

}

```

Just doesn't seem fun to deal with. Stringified json is how nostr profile metadata works. Its not the most efficient but its a tradeoff because you're not iterating through every tag and checking a number of conditions to display - for every user.

Then seeing nip-01 and finding an equivalency between ideas:

kind1: text note, simple, just renders text. All the functionality needed for just a paragraph section, but being an article it could benefit from markdown as another rule. Thats how kind 30041 relates to kind 1, the base case for a section of text.

Kind 0 : Profile metadata - you click on the "title card" of a user's profile and then you're taken to a page where all their kind1s are dropped down like an accordian of index cards underneath the profile metadata. That's why 30040 is the article equivalent to kind 0 - gives bounds for rendering one layer and also provides surrounding context.