quotingTypically no, but in trying to keep close to the specs I was working from (lists and long form content) this was a good compromise.
nevent1q…4rsr
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.
Laeserin on Nostr: I asked liminal 🦠that, yesterday. ...
I asked liminal 🦠(npub1m3x…a5sf) that, yesterday.