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"? |
62.md
Outdated
| ["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. |
|
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. |
|
See related thoughts on #1011 and #1139. The three use cases I was originally looking at, which would be satisfied by this, are:
This NIP would satisfy all these use cases! Would be happy to see this formalized. |
62.md
Outdated
| ["published_by", "public domain"], | ||
| ["image", "https://imageserver.com/piclink.jpg"], | ||
| ["summary", "Collection of selected fables from the ancient Greek philosopher, known as Aesop."], | ||
| ["e", "<id>", "<relay_url>", "<pubkey>"], |
There was a problem hiding this comment.
Being forced to change the kind:30040 every time any kind:30041 might be a bit annoying; I would use the a tag here or at least have it as an option (I,.e. if you were referring to someone else's event you might want to anchor it to a very specific version in which case an e tag would be useful)
There was a problem hiding this comment.
Yes, we should maybe note that a tags can be used instead of e tags. @limina1
There was a problem hiding this comment.
yes, let's move this to a, A tags.
Should it also have a description to render without having to load the attached event?
There was a problem hiding this comment.
I don't know. Sort of turns it into a list, rather than a publication. I mean, anyone can add a description tag to 30041s, of course, and use it that way, but that's a specific implementation out of scope of the NIP.
There was a problem hiding this comment.
We've added a tags as an alternative, but we need to keep e tags for research papers and other technical documents.
There was a problem hiding this comment.
I agree with y'all, the solution proposed is quite elegant.
The one thing I'll add to this discussion is that we shouldn't remove e tags from the specification entirely. We can reference 30041 and other replaceable event kinds with a tags, but some use cases of the 30040 kind may require referencing non-replaceable events, in which case e will suffice and we don't need to worry about content changing.
There was a problem hiding this comment.
I don't like this idea of using 30040 for other kinds. Because then clients that implement this spec must also implement every other kind that gets attached to it. Which is terrible for interoperability.
Do we have real uses of other kinds in this? If so, let's work through each of them and put the guidance in this nip.
There was a problem hiding this comment.
I have a wishlist item. I would like to be able to use kind 1063, so that one could put together a journal article that has text sections and media sections. I am aware that images can be added directly into content, but this works somewhat like stock images or custom-made graphics that can be attributed directly. If this is out of scope, I understand.
There was a problem hiding this comment.
I don't think it is out of scope. Anything text, tables, code, etc., can be in a 30041 (or migrated to, or embedded in, one), but something like an image is sort of extra.
Numerous artists have complained about their images being altered/skewed/cropped by clients, so we should maybe treat images with more care. Identifying something explicitly as media would also ease formatting options like text-wrapping and floating.
There was a problem hiding this comment.
I don't like this idea of using 30040 for other kinds. Because then clients that implement this spec must also implement every other kind that gets attached to it. Which is terrible for interoperability.
Do we have real uses of other kinds in this? If so, let's work through each of them and put the guidance in this nip.
Perhaps this NIP will need to be updated over time to provide helpful guidance for integrating with various event kinds.
Right off the bat, though, an obvious case for 30040 events referencing a kind other than 30041 would be to create curated publications that republish long-form articles. A user might use the NIP-62 hierarchical curation structure to set up a magazine publication that includes a mix or original articles written using kind 30041, and republished, older articles written in 30023.
At some point, the client developer can determine how far to extend the supported features beyond the basic 30040 and 30041 pairing specified in this NIP.
|
LGTM other than one minor comment |
|
Which clients support this already and where can I find a realistic example? :) |
|
The two clients currently implementing this structure are |
|
And my uploader, that is a CLI I use for test data. Highlighter and the Uploader need to incorporate the changes. We'd been using markdown, still. Chachi will also be getting a tab for this, so that communities can have their own library. |
|
Here is a highlighter example, but it's missing the Here is an event, that works well in Alexandria, with a Then you should see this:
|
|
Okay, went ahead and updated the eBook uploader to this NIP version. That's at least one writing with this format, then, and Alexandria displays them. @VnUgE is working on getting a test instance of Alexandria running on our gitcitadel website. |
security model tag specifies how events should be updated
|
What do you think of adding the section title to the This way you don't need to load all linked events to build a named section list. As a bonus, the section titles can be different from what's in the content events. |
Co-authored-by: arthurfranca <[email protected]>
Co-authored-by: arthurfranca <[email protected]>
Co-authored-by: arthurfranca <[email protected]>
62.md
Outdated
| ["a", "<kind:pubkey:dtag>", "<relay hint>", "<event id>"], | ||
| ["auto-update", "<yes|ask|no>"], | ||
| ["p", "<pubkey_0>"], | ||
| ["E", "<original_event_id>", "<relay_url>", "<pubkey>"] |
There was a problem hiding this comment.
Shouldn't this original event id also be A?
Not a bad suggestion, but I'm not sure about it either. The split of responsibilities in this NIP has been that |
|
|
||
| `draft` `optional` | ||
|
|
||
| This NIP defines the minimum specification for curated publication - ordered, optionally-hierarchical assemblies of nostr events. Collections provide a standard way to organize and present related content, similar to how books organize chapters or journals organize articles. |
There was a problem hiding this comment.
Typos:
- "curated publication" should be "curated publications
- "nostr" should be "Nostr"
|
|
||
| ## 30041: Publication Content | ||
|
|
||
| Also known as sections, zettels, episodes, or chapters contain the actual content that makes up a collection. |
There was a problem hiding this comment.
Should be "that makes up a publication."
| ["d", "aesop's-fables-by-aesop-the-farmer-and-the-snake"], | ||
| ["wikilink", "fable", "<pubkey>", "wss://thecitadel.nostr1.com", "<event id>"] | ||
| ], | ||
| "content": "== The Farmer and The Snake\nA [[fable]], by Aesop.\nONE WINTER a Farmer found a Snake stiff and frozen with cold. He had compassion on it, and taking it up, placed it in his bosom. The Snake was quickly revived by the warmth, and resuming its natural instincts, bit its benefactor, inflicting on him a mortal wound. 'Oh,' cried the Farmer with his last breath, 'I am rightly served for pitying a scoundrel.'\nThe greatest kindness will not bind the ungrateful.", |
There was a problem hiding this comment.
Wikilinks in NIP-54 does not have a tag for reference and is different from this, is this intentional? How about using nostr:... links of NIP-21?
There was a problem hiding this comment.
You can use nostr: links in any text; that's just a rendering issue.
This is a wikilink from a note that isn't a wiki page, where the specific version might need to be specified and where the client doesn't necessarily handle wikis. We should maybe use something like the new a-tag, instead of an eventID.
There was a problem hiding this comment.
The wikilink specification here intentionally diverges from NIP-54. I agree we could use a parameterized replaceable event reference like with a tags in the wikilink.
One of the goals with wikilinks, in terms of client implementation, is that they always "just work." Even if, for one reason or another, the specific referenced event can't be found, a client might tie the wikilink to a search feature to find related events by keyword.
That's just one possibility, but that's why we're both diverging from NIP-54 somewhat, and not just using nostr: links.
There was a problem hiding this comment.
Ok I see. Thanks for explaining.
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