Silberengel @Silberengel - 2d
I just published the "Bitcoin White Paper" as a 30040 eBook in Asciidoc, to test the reader view, and it renders in #Alexandria and looks pretty, and that gives me good feels. https://image.nostr.build/e1eb14631db5416e4111b7af9901b8450199d1a2b84ff01e0fcdd565a7f95957.png https://njump.me/nevent1qqsd78chv40hvpcvznc4q2qda7emc42qrw7gdgas93rs0rtwxqt60jspzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgq3q2umrfdjgvdxt45g0y3ghwcyfagssjrv5qlm3t6pu2aa5vydwdmwqgrkp6z
Still need to get the publisher to write "a" tags, instead of "e" tags, and have those also render, but I'm pretty darn happy, for now.
Woops, wrong author. Doh! Nobody would believe, that Stella actually wrote that. 🤣 corrected it https://image.nostr.build/68dc0bccd8bdbada837b6ac40270f9812e0548f8a3424573c923493989fe49e4.png https://njump.me/nevent1qqsxlf29tzeenrvgvjfe3ueuuwews6yu4xfh7ceagp07nxct7su6fzspzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgq3q2umrfdjgvdxt45g0y3ghwcyfagssjrv5qlm3t6pu2aa5vydwdmwqag27vr
You just got a prime example of why we're switching to "a" tags, so that replaced events get updated to the newest version. Both 30040 events might still exist, but the client should display only the one with Satoshi as author.
You can see, here, the light view, and how the publication is structured, with an event for each section. (The sections are only visible, if you hover over them. Otherwise, it's just flowing text.) https://image.nostr.build/8ee8c5359e7c0c8adc0ea2a340446fa9a308971dbc2e5aa16f73315a465696de.png And here is the CLI output, from the bash terminal. I'm now including an optional tag "type" that contains the text "book", so that it's easy to recognize books. https://image.nostr.build/2ed9b1793e4d1231aa0fb905ea1ff37b6ea6be5d22128be946c190ebba99bffc.png
Once I get a couple of minor bugs in the Asciidoc parser fixed, I'm going to do a release v0.1.0 V0.2.0 will fulfill the NIP-62 standard, with the "a" tags. Have to release that in coordination with Alexandria.
liminal @liminal - 2d
its 🤌
Gigi @Gigi - 2d
👀
Changed it to my Minibits. That seems to work.
We're working on hosting a dev version of Alexandria, since running an instance seems to be a hurdle to use. Just be aware that it's still a construction site, until the release.
The formatting is designed for an eBook, but a stylesheet for an online article would probably have the background color for the code sections a bit lighter. That's what I meant nostr:nprofile1qqs2js6wu9j76qdjs6lvlsnhrmchqhf4xlg9rvu89zyf3nqq6hygt0spz9mhxue69uhkummnw3ezuamfdejj7qghwaehxw309aex2mrp0yhxummnw3ezucnpdejz7qg4waehxw309aex2mrp0yhxgctdw4eju6t09uygje4n
Silberengel @Silberengel - 1d
I feel like you're not even reading anything I'm writing. Obviously, I'm talking about exporting the data to files.
There's no point in having different content formats in the notes because any client can display Asciidoc content however they want. It would be redundant information. Alexandria displays them as HTML because it's web-based. (There is no such thing as displaying markup in a browser, just HTML.) A client can generate an ePUB, PDF, LaTeX, txt, doc, etc. document from the events and the author can stipulate which stylesheet to use, in that case. But editing that document would have no effect on the state of the event it was generated from; it's a snapshot. The Nostr event is the Single Point of Truth.
Because you can create downloadable articles in HTML. They're packages.
You can then read them offline or upload them someplace else and make them available online, in isolation of the client.
Some of my magazine subscriptions offer this. Read online or download.
Obviously, you can't dictate to a client, how to display your notes. You can only provide a stylesheet and they are free to ignore it and use their own. But there can be fields in stylesheets that are used in the .adoc file, like custom fields, and the client might not know how to format those. You can define them in the stylesheet.
Like, you wanted something with very exacting formatting, called a "hypernote". You could just create a .css with a style called "hypernote" and give that to the devs to integrate into their default .css. Then, you would just need to create a 30041 including the .adoc tag "hypernote" and it would render in HTML, the way you'd defined it. It would use a Nostr Asciidoc event to generate hypernotes on the fly, without storing HTML in the events.
We could add all of the supported tags to a drop-down box and let people add custom ones, or something. Whatever. Zukunftsmusik.
You can also create a website with 30040/30041 notes, export it as HTML, and then display it under your domain.
There's something similar to this from the band devs, but this would be something you could host yourself, edit, and overwrite. So, more dynamic and personalized. You could auto-publish after you replace notes, for instance.
You know what I mean? Like, you could have a website consisting of NIP-62 events and just edit/add/delete the events, and the website would upate.
If you think of 30040s as folders, that can be nested, and 30041s as files in the folders, then it's easy to see how this could be done because the files and folders can be changed (replaced/versioned), while still staying in place. nostr:nevent1qqsgcnqpf8jymxz6cjky9z3ej4e8j4sgjjwz5659hvqcn6a492d235cpz3mhxw309akx7cmpd35x7um58g6rsd3e9upzplfq3m5v3u5r0q9f255fdeyz8nyac6lagssx8zy4wugxjs8ajf7pqvzqqqqqqyzfvzxs
The neat thing about this, is that your website can be viewable in any client that can handle those events, and you just need to edit markup, not HTML.
