NIP-62: Curated Publications #1600
Conversation
|
Looks good! I still think "Collections" is too generic of a name though. Also, the use of You can use |
|
That's true. We were working on |
|
Why did you remove the kind entry @limina1 ? Thought that was correct. |
|
Just saw a typo in the second example.
should be
|
|
Coracle currently supports collections as tagged NIP 32 labels. Just FYI, I don't care strongly about this one. |
|
Thanks. |
E-Books constructed out of labels, or do you mean, that those labels are also called "collections"? |
| ["author", "Aesop"], | ||
| ["i", "isbn:9780765382030"], | ||
| ["t", "fables", "classical", "literature"], | ||
| ["published_on", "2003-05-03"], |
There was a problem hiding this comment.
NIP-23 uses "published_at" for the timestamp the article was first published, and uses UNIX timestamp format-it might make sense to re-use that tag here, instead of defining a new one with a new format?
There was a problem hiding this comment.
I originally had that, but UNIX timestamps only go back to 1970, and we are publishing old books.
There was a problem hiding this comment.
Right, that's true. Having to use negative timestamps for old books would be bad.
In that case, it would make sense to document the date format explicitly.
There was a problem hiding this comment.
I originally specified ISO 8601.
There was a problem hiding this comment.
Otherwise, European and American dates would differ.
There was a problem hiding this comment.
Exactly. So just YYYY-MM-DD? i doubt this needs any of the extended formats, timezone suffixes, year-week format etc from ISO-8601.
(though for a book, "year of publication" is generally all the information available, also allowing like YYYY or YYYY-MM might make sense, though it complicates sorting)
|
More the latter. It's a mechanism for content curation, which is what I usually think of when I hear the word "collection". This PR seems more like an "ebook" kind of thing rather than a collection. The NIP 32 approach probably wouldn't be appropriate, but its benefit is that the contents of the collection can be dynamic based on who you accept events from. But that's all probably irrelevant to your use case here. |
62.md
Outdated
| ["title", "Aesop's Fables"], | ||
| ["author", "Aesop"], | ||
| ["i", "isbn:9780765382030"], | ||
| ["t", "fables", "classical", "literature"], |
There was a problem hiding this comment.
["t", "fables"],
["t", "classical"],
["t", "literature"],
might be more useful, as then one could query for either of the tags. It also matches the current definition of the t tag in README.md.
There was a problem hiding this comment.
Ah, you're right, just checked and it's like that in my last Habla-generated article.
We thought about "Library", since they're the core events for the Alexandria client, but we want to use them to publish the Bible and that literally translates to "library", so it's sort of confusing. |
We've been resisting naming it "ebook" because it could be used for something like a project plan, anthology, research paper, academic journal, user manual, etc. We were calling it "modular article" and then "Nostr Knowledge Base", so we keep changing the name. |
|
Maybe we should call it "Documents". If you export a 30040, together with its 30041, you get a document file, in whichever format you want: Asciidoc, ePUB, LaTeX, Markdown, PDF, etc. |
|
Given the rest of the tags, 30040 could be called a Publication. Then this NIP's name could be simply Publications or Editorial Publications and 30041 could be called Content idk... just ideas. |
|
That's brilliant. Actually. We keep talking about how we're using this to publish stuff, but we couldn't think of what name to give the stuff, but we could just give the name of the action we're doing. What do you think, @limina1 @buttercat1791 ? |
|
Publication makes me think of magazines. Not a bad implication. Perhaps something like Curated Collection or Curated Publication could also work. Curated to emphasize that it can be comprised of Content from a number of different sources. |
|
Curated publication sounds pretty good. Sounds fundamentally different from NIP-51 "curation sets" lists. Makes it more clear that one document comprised of sections is the result, rather than just a list of events. |
|
I like it. Curated publications as a structure itself requiring publication metadata 30040 and publication content 30041. |
|
Probably also have to change the corresponding entries in the ReadMe.md, under "Event Kinds" and "Tags". |
|
Do you have a way to mark the index as draft? I would like to distinguish between drafts and final versions, since it might take time, multiple people and iterations to get the end result together and then the clients can filter by status. |
|
We don't have that in the client, yet, we've just been using browser cache, but that would make this more consistent with other longform. 🤔 30042 for draft, or something. |
|
If 30040/30041 are final versions, then 30042/30043 could be drafts. |
|
Keep in mind there is also a private drafts proposal on #1124 In that way, people can't see the drafts being made, which to me is a constant complaint on many draft proposals that people can just integrate with their clients and see before they are ready. |
|
In that case we can subsume drafts for Curated Publications into the generic kind 31234 draft event. In any case, 30040/30041 events are by nature replaceable, so even if they're not marked as "draft" they are still editable to any client that supports edits. |
|
Does NIP-51 Curation sets serve such purpose or not ? It seems better to use those rather than keep expanding use cases. If there is no books events or journal events, whats the purpose of using such proposal? |
|
Private drafts don't quite work for collaborative work of mutiple authors. But this could potentially be handled by pre-publishing to a private relay the authors share for such a purpose, before sharing with a wider audience. |
Per NIP-51:
NIP-62 does not prescribe an order to events in the list, instead letting the npub creating the Curated Publication determine the order. Additionally, NIP-62 is intended for use in aggregating several events into a single, coherent, readable presentation, such as a Twitter-style thread consisting of several Tweets or a magazine article consisting of several sections. This is different from the curation sets described by NIP-51, which describes them as:
NIP-62 goes beyond just a collection, it allows the user creating the Curated Publication to define a structure to the publication. 30040 events can contain other 30040 events, leading naturally to an ordered, hierarchical tree structure, as opposed to a flat list or collection. |
I think there might be some confusion. 30040s are the books and journals. The result is a single publication, not a list of publications. I explain it a bit more, here. |
I still think this falls under the lists nip rather than defining a new one regardless of the used definition since there is listing/curating/organizing. |
As you are saying collection you are referring to a group of events of a specific or any type merging this with the lists nip would be more suitable imo, even tho i’m not sure of the exact utility. |
|
Kinds 30040 and 30041 specified in this NIP are not for creating lists, they are for creating structured, hierarchical publications. Different use case. I don't think there's sufficient overlap with the lists NIP to warrant merging them. |
So, you want to: So, separate the book cover, publishing information and table of contents, from the pages of the book? Or do you want to leave the content undefined? |
|
Lists are a general structure, where there isn't a specific kind attached to it. If its important enough, I see a possibility in expanding the specification for lists; where lists are composable, like curated publications which require two kinds. However, NIP-66 is a specific instantiation of that structure, where a client feed is composed out of 30040s just as microblogging clients are composed out of kind1s. It could have a reference within nip-51 as hierarchical, composable lists. Throwing out some ideas |
|
Nobody reading a magazine article or book thinks of it as a list, and someone wanting to build an eReader client isn't going to go to the list NIP. I mean, you could say wiki pages are just a special kind of article and articles are just long microblogs and comments are just microblogs in reply, so everything is just a Kind 01 note and all of the NIPs should be collapsed down to one. But the NIPs are clearly domain and use case centered, so that developers don't all have to watch the same NIP, so that every tiny change to one part of the spec results in 30 people throwing a fit. Someone wanting to build a book client, will want a NIP about books. Done discussing it. Moving on. This NIP is mostly a formality and a chance to make slight corrections, as the event is already being handled or produced by three clients, and will soon be added to more. Anyone have any constructive feedback? |
|
I have nothing to add. I just proposed referencing it within the nip-51 or expanding the specification however if you are saying it is implemented by 3 clients and already in use then you should go for it. I just strongly suggest using a unique UUID rather than a title-generated d-tags (as far as i’m seeing), because it can cause editing problems or conflicts between existed copies since relays may fail to publish an event in one try. |
|
We've refrained from specifying the content for d-tags, as clients have different methods. It might need to be standardized somewhere, for each use case, but it's a longer and more-difficult conversation. |
|
The same d-tag issue arises also for longform and wikis, but it's slightly out of scope. |
|
I think it is standardized somewhere but not sure where. |
This NIP defines a specification for organizing nostr events into collections - ordered, optionally-hierarchical structures like books, journals, or documentation.
Currently, there's no standardized way to create versioned collections of content. The closest option is to use lists, but this extends that idea beyond a strictly linear hierarchy.
Introducing two new event kinds:
kind:30040 - Collection Index
kind:30041 - Collection Section
@SilberWitch