To use the new #biblestr ✝ wikilinks best, might I suggest simply biting the bullet and trying to cache the entire Bible? Makes it work faster.
Format is `[ [book: bible: Genesis 2:3-4, Song 1:1 | DRB] ]`. (KJZ coming #thoon.) Skip the spaces between the brackets; just did that to make sure it doesn't render.
Accepts long (Genesis) and short (Gen) terms for the book names. Immediately renders a card for each included passage, with a hyperlink to it on Bible Gateway, and then tries to find the matching events in your cache or on the relays, to render it inline.
Also updated my #Orly 🦉 and implemented the bookstr macro-tags as indexes, so that you can always find nostr:npub18cddpua960qjy3wmw7y9gmzr4h3ajlrwq3k9jnmqzlxke4qkg6gqeyaztw stuff there. I don't know how good it is, tho. 🙈 ( nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku probably need a specialist on that, it's: type, book, chapter, verse, and version tags.)
(Bookstr is not Bible-specific, FYI.)
Here it is, as a demo.
[[book: bible: Genesis 2:3-4, Song 1:1]]
#christian #catholic
GN and God bless. 🤙🏻
Login to reply
Replies (36)
This is absolutely brilliant.
Amazing work! 🫶
Here is how it looks, If you use `nostr:naddr...` to embedd a #bookstr event.
nostr:nevent1qvzqqqqqqypzplfq3m5v3u5r0q9f255fdeyz8nyac6lagssx8zy4wugxjs8ajf7pqydhwumn8ghj7mmjd3uj6un9d3shjtnfd4mkzmry9ejh2tcprdmhxue69uhhg6r9vehhyetnwshxummnw3erztnrdakj7qpq4uc4aups7vrkzxeuwjkv9hp7ewdluqc24su2s4z8gmtaad9nyqlscysdtu
And here is how it looks, if you post a hyperlink that contains a naddr address that leads to a 30040/30041 #bookstr event.
I pull the book's tags from the relays and render them, if they don't provide OpenGraph data. I include the beginning of the content, which is usually enough for a single Bible verse. So, hyperlinking to a Bible verse on #Alexandria lets people read the verse on Jumble.
This appears anytime a hyperlink is on its own line, but not within paragraphs.
nostr:nevent1qvzqqqqqqypzplfq3m5v3u5r0q9f255fdeyz8nyac6lagssx8zy4wugxjs8ajf7pqydhwumn8ghj7mmjd3uj6un9d3shjtnfd4mkzmry9ejh2tcprdmhxue69uhhg6r9vehhyetnwshxummnw3erztnrdakj7qpqkekj3sv2stx4grh44mwcyrnj4sw6nqcjzkugardw9xdy6jghu7nstewysq
Thanks. 🫂
🫂
It's all slowly coming together. I'm editing four different repos in parallel, but I am beginning to see light at the end of the tunnel.
Nostr interop. 🤌🏻
Yeah, I made indexes, including a composite, but they're sort of underwhelming and they're terribly vibey. I bet it could be very fast and efficient, but best I could do was "start up, don't throw errors, don't crash". 😂🙈
I have no idea if it even works.
Yeah, each verse is an event. So, if you request Gen 2:3-5 it gives you Gen 2:3, Gen 2:4, and Gen2:5, in order, within one container.
And you can then expand to view the entire chapter (Gen 2), with your passages highlighted.
But you see how slow it loads. I want to specialize my Orly on this bookstr macro, so that it quickly returns results.
Oh, that sounds good!
Why didn't I think of that, duh.
It's way over my DB pay grade, to be honest. The AI did something something and I was like, I give up, merge whatever. 😂
But I just know I need some indexy or filtery thingamajigger that can find stuff in tags that are longer than one letter.
The fields from one example are:
```json
[
"type",
"bible"
],
[
"book",
"1-maccabees"
],
[
"book",
"1-macc"
],
[
"chapter",
"7"
],
[
"verse",
"15"
],
[
"version",
"drb"
],
```
`book` appears twice, once longform and once shortform
Like, how to find this, on a relay, if all you know is kind 30040 or 30041?
I'm just pulling all 30040s and combing through them client-side, to find the 30041s I'm looking for, but there are so many 30040s, that the relays give me back 800 events and none of them match. 😏
nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku an example of the tags I have available, to search from, along with kind.
"book" and "chapter" are the two most essential ones.
How can I do a fulltext keyword search?
only single letter tags are indexed (can be used in a REQ) by regular relays..
also, if you didnt know this, you can have more than one of the same single letter tag on an event. for example, a geohash, for people to filter by precision, you can tag the event with 6+ "g" tags or whatever and so then a client can query on the precision they wanted from 1-6 chars long.. maybe something like this would help here.
Yeah, I know.
nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku should I just switch to using a standard indexed tag containing the values, like
["B", "bible", "1 Macc", "2", "3"]
Bible: 1 Maccabees 2:3
?
More concise and then all relays would index it, right?
I have to go to bed, now. GN.
I'll let the relay devs figure it out, while I'm asleep. I have a good publishing facility, now, so I don't mind changing the tags on the events. Only a few lines of code. Whatever is simplest and fastest, going forward.
#Bookstr links are definitely the Holy Grail of wikilinks. 😁
My goal is to publish the Western Canon with these tags and make them quotable in any Nostr client, just by typing in the terms like ("Jane Eyre" Chapter 22, 1st paragraph):
[[book: book: Jane-Eyre 22:1]]
That reminds me that only type=bible should have the Bible Gateway button.
Okay, I'll try that, tomorrow.
I actually need all of the tags. I'll write it up a tech spec, tomorrow, and add it to NKBIP-01. 🤙🏻
I think the AI used some library that hashed the index names.
I'm just going to send you my current data structure and examples of what the bookstr-wikilinks would look like and then you tell me how best to do the tags and I change the publisher to match and reprint.
Whatever is most efficient and effective, as there will eventually be thousands of books... 😬
Okay, I'll get back to you, tomorrow.
GN! 🫂
nostr:nevent1qvzqqqqqz5pzphtxf40yq9jr82xdd8cqtts5szqyx5tcndvaukhsvfmduetr85ceqydhwumn8ghj7argv4nx7un9wd6zumn0wd68yvfwvdhk6tcpr3mhxue69uhkx6rjd9ehgurfd3kzumn0wd68yvfwvdhk6tcqypnn6h3un4744f83rfy7z667uzye6wwqhk465j8x5ya334xsssvqsawxrn7
I don't actually use a graph database. In the past I tried neo4j and memgraph (similar but in memory), and both were just too slow. So I builder my own database, specifically designed for the operations I needed to make generating and updating random walks very fast. This allowed to lower the execution time of pagerank by a factor of 100x compared to traditional algorithms.
For the search, I use my other SQLite database to do a full text search for the profiles. Then I rank these profiles using Pagerank, and I create a composite rank which is a combination of search similarity, and reputation. The result is what is powering npub.world
You can click the button at the bottom of the wikistr article, to see the Asciidoc source and get away from any parsing errors.
Decided it was worthy of its own spec: [[NKBIP-08]]
https://wikistr.imwald.eu/nkbip-08*645eb808ac7689f08b5143fbe7aa7289baad2e3bf069c81d2a22a0d3b3589c18
You were right: it wasn't clearly defined before. I need to redo some of my logic in the parser.
The Bible on Nostr 👀?
It's been on Nostr, in at least two editions, for over a year. This is a #Bible that is broken down into verse-level events, so that you can quote the Bible easily by wikilink.
nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku this is also me. Laptop-Me. 😁
Yeah, I use regex to create the filter for the relay.
My question is:
What do I have to send Orly, to get the desired result?
Do I just send whichever indexes I have in the event I'm looking for? (C, B, c, s, v)
Okay, I'll try that.
The single-letters are simpler. Glad I asked about that.
Ah, I can put all canonical titles in the tags, in a row...
Ah. That's so different to Nostr json tags, where you need an entry for each.
So, if the event tags have
```json
["T", "Canticle of Canticles"],
["T", "Song of Solomon"],
["T", "Song"],
```
Then I can request from the relay like:
```json
["T", "Canticle of Canticles", "Song of Solomon", "Song"]
```
and it would find any of the three that match?