liminal 🦠on Nostr: Nostr is no knowledge base if we struggle to navigate across related ideas, its just ...
Nostr is no knowledge base if we struggle to navigate across related ideas, its just data. Hence a knowledge base app specifically caters to that usability. If we want to consider composable knowledge.
30041 is the original idea, taken from Zettelkasten/Obsidian-like, a Zettel is a loose note. It's a knowledge base specific equivalent to a kind1. And a bunch of chained 30041s compose to an article, which is functionally equivalent to a 30023 or 30818. We thought Zettel was sufficient to distinguish it from the rest, but it was too jargony, so we went with something more general.
The glue that separates this from being another note taking app is 30040. It allows notes to be chained in any way to create articles. So you have the capacity to view notes away from context, or within the context of other notes, and travel through backlinks. The way I view the relation is - User: {metadata=kind0, content: kind1} vs modular articles: {metadata: 30040, content: kind30041}, where modular articles can be anything from a book collection of chapters, to a collage of various notes connected because a user want's not just a bookmark list, but a sprawling collection of related ideas that have been grouped by the user.
We are not defining anything functionally new outside of nostr, but for a knowledge base we need it to be focused with context that kind1 does not provide.
30041 is the original idea, taken from Zettelkasten/Obsidian-like, a Zettel is a loose note. It's a knowledge base specific equivalent to a kind1. And a bunch of chained 30041s compose to an article, which is functionally equivalent to a 30023 or 30818. We thought Zettel was sufficient to distinguish it from the rest, but it was too jargony, so we went with something more general.
The glue that separates this from being another note taking app is 30040. It allows notes to be chained in any way to create articles. So you have the capacity to view notes away from context, or within the context of other notes, and travel through backlinks. The way I view the relation is - User: {metadata=kind0, content: kind1} vs modular articles: {metadata: 30040, content: kind30041}, where modular articles can be anything from a book collection of chapters, to a collage of various notes connected because a user want's not just a bookmark list, but a sprawling collection of related ideas that have been grouped by the user.
We are not defining anything functionally new outside of nostr, but for a knowledge base we need it to be focused with context that kind1 does not provide.