Nostr Web Client

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.

Laeserin 1y ago

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.

Reply to this note

Please Login to reply.

Discussion

Laeserin 1y ago

Of course, we will be displaying wiki and long-form and allowing comments and highlights on them, nostr:nprofile1qqs2js6wu9j76qdjs6lvlsnhrmchqhf4xlg9rvu89zyf3nqq6hygt0spz9mhxue69uhkummnw3ezuamfdejj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uygje4n , but books first.

Niel Liesmons 1y ago

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 / ...

Niel Liesmons 1y ago

I need to start writing out the docs for the zaplab_design widgets I'm building.

Laeserin 1y ago

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

Niel Liesmons 1y ago

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.

Laeserin 1y ago

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.

Laeserin 1y ago

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.

Laeserin 1y ago

So, probably needs to be a separate event, specifying the format for a particular use case (book, hypernote, online Magazine, etc.)

Laeserin 1y ago

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.

Laeserin 1y ago

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. 😂

Niel Liesmons 1y ago

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.

Laeserin 1y ago

You already have a format type (Asciidoc). This is for display or export to other types.

Laeserin 1y ago

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.

Niel Liesmons 1y ago

So it's some sort of interoperable file that the Nostr analogs of things like InDesign, Affinity Publisher and Scribus could tap into? 🤔

Laeserin 1y ago

Yeah, it's a markup language and can be converted to other markups, like HTML, Man Pages, DocBook/XML, PDF, EPUB3, Markdown, LaTeX, KaTeX, etc.