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.