https://nostrcheck.me/media/83d52b4363d2d1bc5a098de7be67c120bfb7c0cee8efefd8eb6e42372af24689/14e54b8af4d729375cc454b6cb06e03ee48d6256ac06a92ec137e520fbfdd8be.webp

I’m new here. Found Nostr by way of the Primal app, that I found by way of nostr:npub1spdnfacgsd7lk0nlqkq443tkq4jx9z6c6ksvaquuewmw7d3qltpslcq6j7 on IG when he mentioned using Primal for bitcoin zaps amd transactions.

What I notice over here in Nostr land is Devs talking about getting more conversions to Nostr, yet it seems more geared to Devs…

As a non technical human artist,

I am asking what is Nostr anyway.

#asknostr

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':, 'author':, ...}`, // influenced from nip-01: kind 0 metadata, stringified JSON object

}

```

Some extra reading:

https://zettelkasten.de/introduction/

https://www.lesswrong.com/posts/NfdHG6oHBJ8Qxc26s/the-zettelkasten-method-1

see also https://github.com/1l0/hexpattern