Is there a particular reason you put author and title in the content, rather than as tags?
As far as I know, the header is metadata and that doesn't usually have content.
Lets see how this works, sorry if I repeat or get too verbose:
https://res.cloudinary.com/lesswrong-2-0/image/upload/v1568584395/Zettelkasten_Svg_1_iuqopd.svg
Just to reference the architecture of Zettlekasten for the architecture I'm trying to emulate.
Conceptually - think linked list
Implementation - think of kind 30040s as containers that can connect together. Why containers? Because we need a way to reference the article as a whole, whereas a linked list only deals with immediate neighbors for traversal.
If we have 3 article headers, where id# represents the id of a short text note and ah# is the id for a kind 30040
ah0 : [id0, id1, id2],
ah1 : [id3, id4, ah0],
ah2 : [ah0, id6, ah1]
Each of them contain 3 notes each, but ah1 contains ah0 while ah2 contains both ah0 and ah1.
Even though ah2 contains two headers with one being nested - traversing over the ids in the header allows everything outside that level to be loaded when needed.
Going back to the rendering function
```
def render(e, kind):
if kind == 0 or kind == 30040:
metadata = JSON.decode(event.content)
if kind == 0:
print(metadata.name)
print(metadata.website)
else:
print(metadata.title)
print(metadata.author)
if card.clicked:
eventList = e.tags
return renderEvents(eventList)
elif kind == 1 or kind == 30041:
print(e.content)
else: # output raw json
def renderEvents(eventlist):
for e in eventList:
render(e, kind)
```
It is just a giant wrapped if-else statement that has rules to render the specific kind that appears in the list. The rule to render kind 30040 would be to just display the metadata from content. At minimum you can render the title, which can also be a section or chapter title. All events in the list should have a rule that says how to display it.
Referencing the spec:
```
{
"id": ...,
"pubkey":...,
"created_at":
"kind": 30040,
"tags": [ // influenced from nip-51 lists
['e',
['e',
['e',
...
],
...
],
"content": `{'title':
}
```
Some extra reading:
https://zettelkasten.de/introduction/
https://www.lesswrong.com/posts/NfdHG6oHBJ8Qxc26s/the-zettelkasten-method-1
Discussion
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.