For the recond, none of the nostr:npub1s3ht77dq4zqnya8vjun5jp3p44pr794ru36d0ltxu65chljw8xjqd975wz devs have merge rights on the NIP repo. We're expected to go there and grovel for changes, while some others use it as their personal playground.
This is why our NUD has stayed a NUD.
I keep saying this: People take the nip repo waaay too seriously. Yes, there is some standard to be kept. But let's not pretend the repo is some sort of high ground for anything over there. It's just a place to reach consensus for the interoperability of the apps in this protocol.
It's someone else's consensus.
I think both proposals are just examples of how the Kind 01 event is getting turned into a microblogging metadata π½, but Alex at least thought it through for 5 minutes.
So? Anyone can put anything on kind 0s. It is the place for any key metadata people want. It is π½ by design. I don't know why would anyone think otherwise.
Because it is mixing neutral profile metadata (name, pfp, wallet, bot, website) that are useful in almost all clients, from spreadsheets, to issues lists, to e-readers, to recipe websites, etc.), with stuff that hardly anyone cares about, outside a subset of clients or some demographic minority, like sexual fetishes, favorite colors, political parties, and food allergies. And what about fields I'd be interested in seeing, that hardly anyone else would want? Do we add those to NIP-24, as well? There are so many devs, now, that you can always find 2 willing to implement something, even if it's just a joke.
You get a field, you get a field, everybody gets a field.
A NIP shouldn't be defining stuff like that, and it certainly isn't something we need to rush through in 2 days. The NIP repo commits are getting more and more ridiculous, niche, and bloated.
We don't have the option to not mix neutral fields with others. Many users have over 30 fields in their kind 0. It doesn't matter what the nip says. It is normal for clients to add fields there and there is nothing you or the nip repo can do about it. All we can do is to try to document what's there, regardless of how useful the field actually is.
Okay, let's have a nationality field, a race field, an ethnicity field, a religion field, a species field, a food-sensitivity field, a dietary field, a job description field, a furry field, an author field, a...
Are we seriously going to document every stupid identifier a human can have, directly in a NIP, just because two devs think it's cute? A profile doesn't even necessarily refer to a human. It's just a way to add metadata to a key.
Yep. Like I said. There is no option. Dont fool yourself thinking that there is an alternative. It's irrelevant what each dev thinks. It's irrelevant what nip devs with merging rights think. It doesn't matter what you think. It doesn't matter what fiatjaf thinks. The fields are already out there. The cat is out of the bag. No one can control it. No one.
Okay, y'all do whatever with your repo.
You still don't get it do you? It doesn't matter what the repo says. The repo can only document what exists to avoid duplications of fields that do the same thing with different names. That's all it can do.
this naming problem is just a subset of how to name anything within nostr
You keep telling me that it doesn't matter what the repo says, but you are constantly editing the repo content.
If you thought it didn't matter, you would ignore it.
Thereβs plenty of professionals whose entire career is describing things that exist in nature.
I feel like the main point of contention in the nips repo is whether you see the repo as prescriptive or descriptive.
I would wager that the vast majority would consider the repo prescriptive even if it isnβt meant to be
I care because of interoperability. To let others know what we are doing so that they can parse and generate things like we do.
It's not about telling them what to do.
Because in the end, each dev does whatever they want to do and we also adapt to that (and change the NIP to reflect it).
You can't block people from doing what they want in Nostr. You can only hope people want to collaborate in the same payloads.
It's easier for you to get a new NIP than for any normal dev to even get a small change to an existing NIP. So, changes to NIPs don't seem like a big deal to you, whereas NIPs are basically carved in stone, from the viewpoint of most other devs.
It's not easier for me. I propose so much crazy stuff that people just ignore my NIPs these days... "There comes Vitor again". I found that it's easier if I just convince somebody new to send the NIP than sending it myself. Reviews are softer because everybody welcomes a new person. Less biases. In that way, I can also see if people are liking it because of the idea or just because it's coming from Amethyst and will be implemented anyway. I do appreciate the criticism over the idea itself.
But I consider myself a really good NIP writer. So, that helps me for sure.
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?"...
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.
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.
Okay. I'll revamp it on the wiki and @ you.
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.
You have literally built nothing public, can't even find the gitcitadel stuff repo. Why should your nip be merged for a non released, closed source(?) thing nobody uses yet?
