Aight, what happened, what did I miss? xD
Haven't peeked into the issues/pr tab in forever on that repo. Something goin down?
Discussion
No, nothing going down. That's the point. They're controlling the supply of merged NIPs, even though the number of PRs is going through the roof.
The nostr train will continue with or without the github nips repository. It's already too slow to adapt, the channel for adaptation just hasn't been carved... yet.
Yeah, the NIPs repo is very 2023 technology.
I'm just going to move the changes back to our wiki and add a link to this PR, and then they can do whatever over here. Our events are already in the NIPs repo ReadMe, anyway, so I don't know what getting a number would effectively change.
Just wanted to give everyone a chance to review the NUD before our release, and that worked well enough. Seems like the repo is just a crutch for the wiki pages not having comments, really, but we can solve that ourselves, by adding them to #Alexandria.
Of course, we will be displaying wiki and long-form and allowing comments and highlights on them, nostr:nprofile1qqs2js6wu9j76qdjs6lvlsnhrmchqhf4xlg9rvu89zyf3nqq6hygt0spz9mhxue69uhkummnw3ezuamfdejj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uygje4n , but books first.
Sidenote: do you know of a :Nostr: solution to docs yet? Seems like 30040/30041 would be the way to go for that too, no?
Which leads me to my next question: Is there a way (i.e. tag/label or sth) to tell what the text content type is? Book / Scientific paper / Docs / Article / ...
I need to start writing out the docs for the zaplab_design widgets I'm building.
I suggested we add a "type" tag, to denote specific content.
Yes, this would be for any longer, more-complex document.
https://github.com/nostr-protocol/nips/pull/1600#issuecomment-2544617399
Thanks. Yup agree :Check:
Cool, I can work with that. Then, as long as it's text, it can just be 99% the same creation / reading tools under the hood. Just need to switch icon, name and (sometimes) serif to sans font.
Asciidoctor stylesheets will handle the custom formatting stuff, for HTML rendering or publishing. We haven't implemented that, yet, though. Would probably be a linked 30042 event, containing formatting. Or some new "style" tag, or whatnot.
Currently have that planned for v0.3.0.
Like, we'll need to offer some different themes for publishing books or journals, and make them customizable. So, it's not just HTML stuff.
Of course, you will be able to design the content with adoc once, and then set different stylesheets for different formats (ePUB, LateX, HTML, GitHub-flavor markdown, etc.) many times.
So, probably needs to be a separate event, specifying the format for a particular use case (book, hypernote, online Magazine, etc.)
Like, you could publish something as a series of articles, as an online magazine, or as a document to be downloaded and read on ePaper. You wouldn't necessarily want to formatted identically, everywhere, or using the same title page or cover Image, or whatnot.
You could also reuse format events, or reuse zettles in a different document with different formatting.
Complicated, so v0.3.0.
You can see how difficult it is, just configuring index event tags. 😂
Why do you need an event for the formatting (stylesheet)? Why can't it just **be** the format (file type)? And then you link those PDF's, epubs, etc... to the index event.
You already have a format type (Asciidoc). This is for display or export to other types.
You don't want to have a bunch of event-copies containing different formatting, as you'd then have to change the event content in each copy, to edit it. Nightmare.
But, yeah, way too slow. Stuff just languishes there, in perpetual draft. Documents need to increment, so that people have some reference point, as a release.