It bridges the organizational methods of Obsidian (personal notes) and more structured text (articles, documentation, etc). The result is a unified interface for interacting with knowledge because larger articles are composed out of smaller notes.

Something like:

1) Take a YouTube programming tutorial, grab the transcript

2) split transcript into sections (noteID, linked list format)

3) manually create notes of code in each transcript section. Link the specific parts of the library documentation being used (given that documentation is also split apart into modular notes)

4) kind 1s link to each note as commentary/QA, aka now this YouTube tutorial can be interacted with in a sort of stack overflow manner

5) documentation itself can also have code notes for each function allowing for many different use case examples

Reply to this note

Please Login to reply.

Discussion

This sounds awesome but impossibly hard to write code for.

Maybe DVMs could solve part of this? 1 we already have and probably 2 might be doable. For the linking and the rerpresentation it sounds similar to Pablo's highlighter.

The specific mechanisms for creating the notes are not super important - automating, or creating some interface to create the notes is something to think about later on. I'm basically just uploading notes via Node

https://github.com/limina1/upload_files

Suppose the notes already exists: partitioned transcripts, documentation, code etc.

Also suppose all these notes have an accompanying Svelte component. (Say the client accepts pull requests for a note type, or links to something like schema.org for directions in how to render a note, maybe even something like nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z 's nostr webserver

https://github.com/vitorpamplona/nostr-web-server/tree/main

https://nostr-webserver-3c29f7957ffe.herokuapp.com/e/1efc13c6ffbaf60c0347baf89f6ecaad22f74abf82165fcdb55ef7e8cca8a597)

Full articles can be displayed this way:

Think about Kind 0 (metadata) and kind 1 (text notes), analogize article versions (article header, article notes, indextr's kind 30040 and 30041 respectively)

the headers contain the metadata of the article, but also in the tags contain the ordered list of individual notes that create the article. Technically any event kind can be in this list, so long as the client has accompanying components to display them. if the note is a header by itself, its just a recursive process to render the article

Very simple demo here which connects to the indextr relay

https://github.com/limina1/indextr-client

Why is it important for notes to contain svelte components? Wouldn't markdown be sufficient for client side article rendering?

I think having the different components would allow the user to display content according to their own needs (for example the old vs new wikipedia design) or interactivity (flashcard). I think you have a strong point though. Markdown might just be enough to cover 99% of the use cases and forks could take the client and change it according to their own needs.

I mean the UI.

For writing articles:

Article headers: a form entry for entering the metadata as a dictionary

Creating Article notes could happen in two ways:

1) could be a single entry containing markdown text thats parsed by header, creating individual notes

2) list of individual noteIDs

The workflow for nested articles would be to publish the deepest layer of articles first and work your way out

If the noteID in the is another header, then the display would be something similar to displaying a table of contents rather than displaying the full article at once.

Deep articles like textbooks can be displayed incrementally