nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z Stripped it down, simplified it, and removed everything specific to some particular use case.
https://wikistr.com/nkbip-01*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1
D-tags are weird. They should have just one value, not 3 as in the Index. And the Section simply says "events-and-signatures" for it's d tag. What does that mean?
Usually we just put a UUID on the d-tag and leave everything else to their own tags.
Ohhh... The example is about "events and signatures".. hahaha. Maybe make an example that doesn't use Nostr's vocabulary. :)
Let me use one of the actual ebooks, for more relatable content.
Also, is Knowledge Base, Index and Sections the best names for this?
Nostr is a knowledge base on itself. So, it might be too generic. And knowledge bases don't need to be ordered, which is the only property of this object.
Index can be confused with search index or database index, which serve different purposes.
And Section seems rather specific for books or maybe webpages?
You can name the NIP Anthology or Collection or Catalog.
The Catalog event (30040) organizes items in order, while Entry event (30041) provide the actual content.
What about "compilation", since it's the "result of bringing together, organizing, and arranging existing works whether related in some way or not"?
The thing about this is that it can be an anthology, a collection... anything that is assembled, grouped, or curated.
But it is for texts only, right? Or are you proposing any list of events, like NIP-51 does?
we considered that, but decided that if someone wan't to use existing events to aggregate together, we will have a 'carbon copy' process, which transforms (automatically, or made by the user) it into a 30041. That way, the poster has agency over what they want in the collection.
Any event type. It's content-agnostic, as we've already come up with working examples for MP3s and stuff. Can also have different types of data in one. Like text interspersed with videos or graphics. Or indexes within indexes, to create a hierarchy, like in a ToC.
>>
Kind 30040 MUST have events listed in e tags in the order that they should appear, in the client. The events may be any already-existing events (including nested kind 30040s).
<<
Like so:
I wouldn't make it that generic otherwise it's just a list and should be part of NIP-51
But I do question if it makes sense to merge every type of event into just one kind. Clients will need to support all types of content just to be able to comply with the NIP. That is terrible for adoption.
You could do an event kind for a collection of articles, another for a music collection, etc.. Then clients that support them would only code the kinds that they offer support for.
Yep, album, directory or library could also work. Even book could be a good name, depending on your goals for the texts inside of it.
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.
I wouldn't make it so generic that it replaces bookmarks. The secret for a great NIP is to be specific to the use case. If the use case is for a collection of notes, you could call it a Notebook.
I'm overloading the term bookmark here, because that is mostly for the user. The bookmark list is a linear list of saved notes
the 30040/41 structure creates this potential:
30040: Title - Programming
{
30040: Title -Programming basics,
30040: Title - Machine Learning
30040: Title - Nostr Specs
30040: Title - Personal Programming Notes
}
each 30040 is a list that can branch out. They don't need to even be written by the same user, and they can hyperlink individual notes together or connect lists together. Anyone could use this functionally as a bookmark, because the basic functionality is NIP51, but it is an extension in it that can connect multiple contexts together.
I could just define "d" tags as "according to NIP-54", and leave it less-defined.
Remember that you cannot change `d`. So some times is better to just leave it as a UUID to avoid any confusion on why the title is now so different than d. But you do you.
Additional feedbacks:
E tags only have 1 relay URL. The next param should be the pubkey of the e's author, like:
["e", "
I would use a different tag, maybe `E` for the original event. In that way, users know that the original event should not be added to the end of this collection.
`p`s are one pubkey per tag. You can't do multiple public key s in the same p-tag because relays will only index the first key.
