this is also why it's important to subdivide the trees so you can trace the side effects properly
Discussion
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
It actually goes top-down, rather than bottom-up, and there is no parent-reference, so that the result is modular.
I.e. anyone can reuse the branches from other trees, but the trees can be built from the information in the branches.
They're the only events that work that way, I think. Everything else is child-defines-parent, like you were describing. These are parent-defines-children. The children are just sort of floating around, and different parents can grab them and include them.
That's how you'll be able to include the section from one research paper into another research paper. Like building blocks. Zettel.
It's the Zettelkasten concept, basically.
yeah, the map of the parts works as a gestalt but the pieces don't necessarily have to refer to them, you can't do both
Yeah, it's like you make a scaffold out of 30040s and then pin 30041 Zettels to the the various arms of the scaffold.
Then you can always rearrange the scaffold and move the Zettels around. They're like post-it notes.
a vaguely parallel pattern is what i'll be using with nip-79 nostr relay chat... there is a message type for coordination, and then there is the messages themselves, which can contain other messages of teh same type - that part is just because the protocol i'm designing doesn't use relay storage, clients have to do the replication legwork, so they need signals to coordinate, and they can optionally wrap these messages inside encryption to hide what they are as well (this is kinda necessary, i think)
always takes two things, content, and structure, they can't be mixed or you end up with brittleness and that becomes hard to change
Yeah, that's what I said about the kanban boards. The cards have to remain separate from the boards.
funny side note, when i saw that word kanban just now i thought "kankan"
anyway, yeah, so, i guess the point is this:
the structuring parts of the data are a unit, even if they are a set of layered events (eg book, chapter, verse) in effect there is no actual sense in NOT combining them into a single event structure, because they have to be changed all at once anyway, atomically
if i may suggest, to simplify the atomic unit of a book, just make the entire structure spec into a single event, since it's gonna be a LOT more work for a relay to handle the vomit of new events that are required to update or add a new version
i would also question whether to make them replaceable, perhaps if the version code was the parameter then ok, and you did make them 30k numbers so that all fits, this lets you do both, so you can update a branch independently of another, but then you might need to have human readable identifiers associated with the versions, as well as displaying who made the update on the version
You often only have to change one event, with the version, though. They aren't linked lists, or anything, and they're replaceable.
If you put the entire structure into one event (which might be simpler, yes), then you can't have fine-grained content or large structures. The Bible has over 30k versus, for example. You'd have to list them all within one event.
ah yeah, this is a good reason for structuring it hierarchically then
it's still gonna be quite overhead-heavy but it does make it simpler to make queries to find the parts, since each parameter can relate to a layer
if you change a leaf, you have to change every layer up to the root of the event, so that means verse, chapter, book, and volume events have to all be changed at the same time to modify a verse, but i guess it is what it is
my relay is not bloating up memory that much by keeping a list of whitelisted users over 11k so i think this is fine
Well, you also have to remember that you can have different versions of the same content. Like, I produced first a Bible with the 30041s at the chapter-level. That's fine for reading, and loads quickly, but it's not useful for quoting. So, I'm making another one with 30041 verses.
Most people will be using individual verses, or one parable, but having them as part of a larger structure means that you can navigate back to the chapter and from there, back to the book, and so on.
Because you'll be able to REQ the data, you can then pull it, reformulate it completely, add your own thoughts, and republish in whole or part.
That's actually more like how it originally was. Paper was scarce and text was manual, so people had parts of the Bible, illustrated and copied and commentaried. Like, only the Psalms or only the Gospels. Excerpts from their pastor about how to live an upright life, etc.
That went out of style, as paper and printing got cheap, and people changed to just reading it front-to-back, over and over. Which is also important, but our data structure allows you to use the same papers do build both types of books.
You actually won't have to change the branch, to change the leaf, once the 30041s are linked in with the new "a" tags. These first editions are still using "e" tags, but soon, you'll be able to edit leaves without having to update the branch. I already produced some test publications, with the new structure, but Alexandria isn't picking up on them, yet.
You only have to change a branch if you reorder, add, or remove leaves, not if you change them, so long as the d-tag stays the same.
i see it... makes sense... the tag designates the root for a branch... so there must be a simple event that creates the nodes and gives you that value right? has to be a node identifier to do it this way, totally makes it flexible then
the only problem i foresee is now you have the situation where someone can come along and confuse that branch identifier, it needs to be locked to an npub i think? or something?
A tags are kind:d-tag:npub .
ah, ok, yup, so this locks the node to the npub as i said would be necessary, and if that npub changes the event, it changes the branch from that point down, and there is no way to confuse it so long as you pin it all to the npub
Here's a testdata event with a tags. Easier to show, than tell.
i think i understood it better how you explained it, that doesn't really show me anything all i see is a node of sorts, not how it relates to another node, if you follow me
People kept wondering why it was taking us so long and it's like... Yo, this is a math 🧩. This is not tweets. Nobody has ever done something like this, before, which is why we're going to write up a scientific paper about it. We're inventing the structure, as we go along.
We're still discussing the architecture and it may change some more 🙈, but we decided to just go for it, anyway.
this is how it's done... occasionally you have to rip it down from the higher level of abstraction but more often it's just revising a branch of the tree
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.
