Nostr Web Client

We've made one attempt at a NIP. It was a disaster. LOL Haven't decided, if we should make another attempt.

The process is annoying only if your ego is in the way. Once I learned how to avoid that bias, things become just about technicalities: is it the best way of doing it, is it too simple, or is it too hard? Too prescriptive or too broad and vague?

Most of those answers are subjective and thus most decisions on the NIP repo just reflect the "feelings" of devs in the debate.

Once you understand that, you stop caring about perfection and engineering qualities and start caring more about "are people actually going to code this shit and is it actually useful?"...

Reply to this note

Please Login to reply.

Discussion

Silberengel 1y ago 💬 1

Fine.

We'll submit NKBIP-01 for review, since it's been implemented in multiple clients, covers something very basic, and people keep asking us where the spec is because they want to use it, and see how it goes.

Vitor Pamplona 1y ago

Remove the WHY section. No one cares. Keep things as if you were writing a TLDR..

Don't use jargon or your own naming convention for things. "Dumb english" is best.

Show an example as soon as possible. Then explain what the kinds do, and the fields in them.

Silberengel 1y ago 💬 3

Okay. I'll revamp it on the wiki and @ you.

Silberengel 1y ago 💬 1

nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z Stripped it down, simplified it, and removed everything specific to some particular use case.

https://wikistr.com/nkbip-01*fd208ee8c8f283780a9552896e4823cc9dc6bfd442063889577106940fd927c1

Vitor Pamplona 1y ago 💬 2

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.

Vitor Pamplona 1y ago 💬 2

Ohhh... The example is about "events and signatures".. hahaha. Maybe make an example that doesn't use Nostr's vocabulary. :)

Silberengel 1y ago

Let me use one of the actual ebooks, for more relatable content.

Vitor Pamplona 1y ago 💬 4

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.

Silberengel 1y ago 💬 2

What about "compilation", since it's the "result of bringing together, organizing, and arranging existing works whether related in some way or not"?

Silberengel 1y ago

The thing about this is that it can be an anthology, a collection... anything that is assembled, grouped, or curated.

Vitor Pamplona 1y ago 💬 3

But it is for texts only, right? Or are you proposing any list of events, like NIP-51 does?

liminal 🦠 1y ago

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.

Silberengel 1y ago

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:

Vitor Pamplona 1y ago

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.

Vitor Pamplona 1y ago

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.

liminal 🦠 1y ago

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.

Vitor Pamplona 1y ago 💬 1

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.

liminal 🦠 1y ago

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.

Silberengel 1y ago

I could just define "d" tags as "according to NIP-54", and leave it less-defined.

Vitor Pamplona 1y ago 💬 4

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.

PABLOF7z 1y ago

booooh UUIDs booooooh

talvasconcelos 1y ago

uuid().hex ?

Silberengel 1y ago

I wanted UUIDs, but everyone hates them, as the URL is then a bunch or random characters.

Vitor Pamplona 1y ago

True... Readable `d`s are fine, I would just get rid of the 3 params on kind 30040

Vitor Pamplona 1y ago

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.