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.
liminal ðŸ¦
npub1m3x…a5sf
2024-06-23 17:15:29
in reply to nevent1q…9h7s
Author Public Key
npub1m3xdppkd0njmrqe2ma8a6ys39zvgp5k8u22mev8xsnqp4nh80srqhqa5sfPublished at
2024-06-23 17:15:29Event JSON
{
"id": "7f378b628e3be96c2072b45824e5fc244c340c0c6cd64ee4d4f4f436fe0cf6bb",
"pubkey": "dc4cd086cd7ce5b1832adf4fdd1211289880d2c7e295bcb0e684c01acee77c06",
"created_at": 1719155729,
"kind": 1,
"tags": [
[
"e",
"c27bcfc67d347a63425c5f096e4923c42f2f3b917d0171a4f3590268e333413a",
"",
"root"
],
[
"e",
"8b03208081333e899c50c7d9527b0f60f61eb8dd370bfff67a5df86948293c62"
],
[
"e",
"0d5dc1d9110f6d4d1e9eb78a6b7668d6531d77b935d34465b0cbfbb3b0a277c9",
"",
"reply"
],
[
"p",
"dc4cd086cd7ce5b1832adf4fdd1211289880d2c7e295bcb0e684c01acee77c06"
],
[
"p",
"dd664d5e4016433a8cd69f005ae1480804351789b59de5af06276de65633d319"
]
],
"content": "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. \n\nThe 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.\nI thought about some sort of \"list spec\" as an element of the tags section:\n```\n{\ntags:[\n..., \n[\"eventlist\", [\"e\", id0, relayhint0],[\"e\", id1. relayhint1],...], \n...\n]\n//eventlist as a list within the list of tags\n}\n```\nJust 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. \n\nThen seeing nip-01 and finding an equivalency between ideas:\n\nkind1: 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.\n\nKind 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.",
"sig": "6fc5afe2e33b404651e287c28719cebca3fee0b6928b3b5911b0c5291408df4c69b1b8f9ad3fd4738930ac8c1a991ec0eb0b29325480d5aef4d44f2e8b907afe"
}