Oddbean new post about | logout
 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 
 I don't know who can/wants to build that, but our team is sort of swamped right now. We're just going to push out Indextr and the Biblestr fork of it, and then we have to go back to the NDK grind. 
 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. 
 Sorry 🥹  
 We really need to get Indextr out. The idea has just been sitting around for months. 
 follow me  
 It's basically a Ngit-based integrated development environment for programmers. Like GitHub, but locally installed on WSL or Linux. 
 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 
 This is grant-worthy Nostr Core Development, in my opinion. What do you think @PABLOF7z and @ODELL ?

Would this be a good place for someone ambitious to start? 
 how is that different from highlighter?
 
 follow me 
 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...  
 can relate... it definitely would help us attention deficit kids 
 njump is a centralized shitcoin and people should not rely on it or use it for reading, just for sharing in other shit platforms. 
 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. 
 Markdown, usually. I think some are using asciidoc, too, or both. 
 Yes, we would just need an online generator, were you can fill in the fields for a 30040 and then attach all of the md files you want to include in that batch, and have it write the events. 
 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. 
 "Oh it looks simple" (famous last words)

That's how I feel about the NIP-46 signing for Aedile.  It's a hefty piece of work for a relatively simple concept.