in case it isn't clear, this means that the events have to have a reference to their parent node... and to do that, because of hashes being involved, you can't just do that with hashes, it has to be a versioning scheme that probably is easiest to base on a timestamp, so it would need a d tag scheme that includes the timestamp, and the timestamp would be the reference point for the reverse link
this is complicated, i know but i've wrangled this tree versioning thing with embedding versions into Git repos and you simply can't refer to the commit at the top within the branches themselves, it's impossible
or more exactly, the chances of finding it are so small that it would take a really long time to find it to protect the consistency, so you have to have a secondary scheme of versions
Yeah, I'm planning on
30040 Bible
|__ 30040 Introduction
|__ 30040 New Testament
|__ 30040 Gospels
|__ 30040 Mark
|__ 30040 Chapter 4
|__ 30041 Verse 4:11
|__ 30040 Old Testament
|__ 30040 Apocrypha
|__ 30040 Appendices
Something like that. In the final version, the bottom 30041 content-level will be individual versions. In this training material, it's all lumped together in the 30041 chapters, but we need verse-events for #biblestr The idea is that we atomize large publications and then any npub can piece them back together, in various formats and orders.
Of course, it's Nostr, so someone else is free to create a different tree out of the same content. They could even add commentary, at the various levels, or something. Just have to include an additional event, in between, and reorder (and, with this change) and *renumber* the 30040.
Showing page 1 of
1 pages