We basically need an njump-style client, like @fiatjaf built, specialized in browsing long-form (wikis, articles, and modular/books). Stuff that stays relatively static and takes a while to read. And it should allow for highlights. nostr:nevent1qvzqqqqqqypzq77777lz9hvwt86xqrsyf2jn588ewk5aclf8mavr80rhmduy5kq9qqsrjv4yxywh470fa3qds2ffuflkquqg40sqcx9y0ask67qd9ma5v7q9htnpm
This seems like the easiest route for the masses. Not everyone is comfortable with downloading and converting files into a separate app that they had to previously download. If you can pull it off, I'm 100% behind you 🔥🔥🔥
We can, but not until next year. We have GitRepublic to release first, and that's basically going to be a Nostr IDE. It's a monster. 😂
Oh I must've missed that note? What's GitRepublic? Please and thank you.
My mockups should be on the wiki soon. This distracted me. 😂 Just have ugly wireframes, so far.
Very low barrier to entry, as they could read all day without logging in. Just need to login to annotate or to limit to WoT. That makes it more like a library, where you can just stroll around and look.
Love this thought process. 🔥🔥
What do you mean by "converting files into a separate app"? What weird context am I missing here?
The average Kindle user just uses books on their kind. They don't download epub files and import them to a third party app or convert them from one file format to another to consume them.
OK, but what does have to do with anything? Is @Laeserin proposing a way to publish books on Nostr that is compatible with Kindle?
Not compatible, comparable or an alternative to Kindle. If it's done as a low barrier to entry e-reader website, then people could use it as an alternative to their Kindle. They would not have to download epub files and import them into a separate e-reader application. They just visit the site and that's it. Easy reading.
Yes, an e-reader friendly Nostr site for books and anything else in long-form. All e-readers have a browser. Also ideal for tablets or for people (like me) with bad Internet connections or crappy hardware.
If you look on Project Gutenberg, they have all of the different filetypes already created and stored, probably with a database. Nostr already has a database, tho (relays, an event store), where we're storing the books as events, which are the smallest, simplest building blocks of such documents. So we can always work parts-to-whole and generate any other view on the fly, including HTML. With a book, you don't need the speed and convenience of a websocket, as the text hardly changes and there's hardly any interaction. It's just you, staring at a long text, occasionally highlighting something interesting, and maybe submitting a review of the book, at the end (like we do for relays). https://www.gutenberg.org/ebooks/13347
how is that different from highlighter?
No websockets. We tested our various ereaders today and they all passed out trying to use websockets. 😂
it should be possible to write lighter weight webapps that compose raw JSON content and use plain HTTP i seem to recall the web dev guy i used to work with back in 2018 writing Go services that pulled data from simple flat file stores containing JSON and using pure HTTP with simple javascript, it's probably something half way between static site generator and web 2.0 style pre-PWA style you need to build
Or do that. I have no idea. I'm not really from that specialty, I just want my app. 🤣 I love reading the articles, but get so tired of staring at glaring screens. That's why I have the Kindle and Tolino apps on my phone, but I hardly use them. Always go for the e-reader. My laptop is better than the phone, so Nostrudel and Highlighter and Habla get a lot of use, but then I get all ADD and start clicking around to see if I have notifications or an email came in and what's on Slack...
We'd want an HTTP endpoint that renders the events as webpages, and maybe another one that creates a browsable feed that e-readers can use. Bonus points if it's written as a library or plugin or something so anyone can run it on any server. Relay servers should have HTTP surfaces for compatibility with other web technologies around these sorts of solutions. Interoperability.
What format are y’all putting this text in again?
Event kind 30040 and 30041
Well, we'd need to convert from that into some sort of markup. Probably plain HTML so anyone can render it.
Yeah, HTML.
That’s what I was driving at. What format is preferred for storing the content in json? Markdown would seem ideal. I was thinking of tinkering with an event rendering service, which could be done easily with the MarkDig library.
The event content itself is Markdown, I believe. Like Læserin mentioned, some clients may switch to ASCIIDoc. We'll probably need to support both, eventually, but Markdown is a good start. So we need a Markdown-to-HTML converter, and eventually an ASCIIDoc-to-HTML converter. The API endpoint workflow would be: 1. Look up 30040 event and associated 30041 events (or single 30041 event to return a chapter at a time, but that's implementation details). 2. Tie together the Markdown contents or relevant events into a single giant Markdown string/stream. 3. Pass the string/stream through a converter to produce HTML. 4. Return HTML to the caller.
I’ll start playing around with this. I’ll just leave room for adding asciidoc later, as I’m not super comfortable with it.
I hadn't even heard of asciidoc until recently. Not worth worrying about too much at the moment, since most clients are still on Markdown.
Im going to have fun playing with VS’s docker stuff for this. Should make it easier to self-host too. Thanks for a (conceptually) simple thing to play with. I’ll regret saying that later, but çest la vie.