nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 & nostr:npub1q7klm2w94hyq3qdm9ffzpahrrq0qcppmjrapzhz0rq6xgq3fdrnqr6atmj if you're looking for help in making this more than a Wiki and something that leverages interoperability and composability of nostr we should really talk.
You guys have the basic functionality, my idea reaches towards general knowledge management. Linked notes to create full articles, something I think offers a lot of potential
nostr:npub1t3ggcd843pnwcu6p4tcsesd02t5jx2aelpvusypu5hk0925nhauqjjl5g4 also bought the domain name nostrwiki.com and it needs a home.
You're talking about Indextr? I remember finding it pretty interesting, but more like a Google Wave, it would require a team to build.
Or maybe it is more like Obsidian?
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
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
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
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
