Oddbean

Hmm. I do like 2.5 then. By default we keep the first entry as the title. Any other important searchable metadata (which can be different, depending on domain) could go there. Could this essentially combine nip36 and 54 to reduce redundancy?

Y'all I searched and the NIPs repo doesn't formally define the `d` tag anywhere. That means no one can tell us we can't extend it lol. I was thinking we use positional values to extend the `d` tag array. Something like: ```json "tags": [ ["d", "war-and-peace", "leo-tolstoy", "penguin-classics-edition"] ] ``` The general format would be `["d", <title>, <author>, <edition>]` where edition is a human-readable edition name (as opposed to just a number). The event _should_ still be addressable by `#d` and the title, just like other event kinds' d tags, but we can increase address specificity for the Nostr Knowledge Base use case. Then we can bake this specificity into wikilinks (see NIP-54 for an existing wikilinks specification). A document might contain `[[War and Peace. Leo Tolstoy. Penguin Classics Edition.]]` and we can specify that clients should split that at the periods and normalize it into a d tag array reference, so it becomes `["#d", "war-and-peace", "leo-tolstoy", "penguin-classics-edition"]`. The client can then use this tag array to search its relays, find the closest match, and display to the user a hyperlink to the referenced event. Basically, we define a citation format for NKB events. Since the event ID is derived from a serialization of the whole event, including tags, increasing identifier specificity will always generate a unique event ID. We'll have to experiment with how relays index events by d tag, and how they respond to queries for such events. Maybe Stella's PHP utilities can help us with that. Worst case, relays only support searching by the first `d` tag value and return a bunch of matching results, and then we have Alexandria walk through the results and find matches by author and edition.

Maybe using `[[author:leo-tolstoy]]` should link to a search page showing results with that `author` tag. We can use a similar format for wikilinks to search results or tag-based feeds. Perhaps you want to link to a feed of literature on a specific topic.

Yeah, just allowing for a multitude of ways for human navigation. The general case would be to remove the '{noun}:' and just find anything matching the sane string across the categories. Kind of an aside, but I'm wondering if it would make sense backend-wise if we paired an optional db for caching on relays we want to associate with to improve performance. I'd imagine without the db search performance would degrade as events increase.

I think the caching DB could be part of our premium offering. The client is open-source, so anyone can run an instance. The data? Not everybody will have that. We can attach a caching service to TheCitadel relay and introduce a paid tier for those who want that additional performance.

>>The index MUST also be uniquely identifiable using a combination of the d tag's first value (usually containing the title), the pubkey, and the kind fields.<< This is the part in the NKBIP-01 that pertains to the d tag. We could change the text to read >>The index MUST also be uniquely identifiable using a combination of the d tag's values (at least including the first value, usually the title), the pubkey, and the kind fields.<<