And we're going to need to get your stuff running on our GitCitadel webserver, so that people who write stuff can see their stuff displayed. Devs will run your program, but they're not usually writing anything they'd need your program for, so we need to host it.

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": <unix timestamp in seconds>, "kind": 30040, "tags": [ // influenced from nip-51 lists ['e', <event0-id>, <relay-url>], ['e', <event1-id>, <relay-url>], ['e', <event2-id>, <relay-url>], ... ], ... ], "content": `{'title':<article-title>, 'author':<string>, ...}`, // influenced from nip-01: kind 0 metadata, stringified JSON object } ``` Some extra reading:

Introduction to the Zettelkasten Method &bull; Zettelkasten Method

Learn how the Zettelkasten works as a system, what a Zettel is made of, and how to grow an organic web of knowledge.

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

The client should be effective enough to read. Could benifit from better design and to have nested notes, but if the events are formatted well, it should work. Uploading, let alone doing so from a web interface is a different story 😅