What article were you looking at? Can you send a link to the page on which that happened?
Discussion
All of them
Gotcha, thanks for letting us know! We may need to solve that by including ordering information in event indices so we can guarantee to display indexed events in the intended order.
We'll work on fixing that!
Do you have a link to the NIP/kind description? I am curious. Did you guys just assume the order in the json would imply the order of the parts? If so, then yeah that is not going to work out
It's NIP-62. Currently just a PR on the NIPs repo. We specified that the order of the tags determines the display order. That may need to change. But that's why we're testing this!
Making the order explicit will make editing and replacement interesting. Means they can't use functions they've developed for editing other replaceable events.
i think that because changing one section implies a change that propagates up the tree to the ToC is necessary for integrity checking, so the replacement of events for this also has propagating effects, can't be avoided
this is also why it's important to subdivide the trees so you can trace the side effects properly
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.
Yeah, we're also going to add a check, if all of the parts are even rendering, as there going to be hundreds or thousands of parts, to some publications.
So, check for completeness and order. Shouldn't slow it down much.
you will want to use merkle trees for this, and possibly subdivide the tree so like, chapters->verses trees and books->chapters and so forth
Yes, that's the nested 30040 construct. The app only displays the last branch, at the moment. That's why the Bible books are still separate books.
The ToC will actually be collapsable, in the next version. We're just trying to get it the right way up, complete, and in the correct order, this time around. 🙈😂
I discussed this briefly with some south american jungle spirit, and listed key-value pairs should actually work in terms of implied order.
If/When i find the time i will have a look at the NIP with the NSF guys, see what they think of all of this stuff.
Tags are by defacto already ordered; NIP-51 lists also use the tag ordering
Via https://alexandria.gitcitadel.com/ on my phone, using firefox. Screenshot attached where i scroll upwards popping up the refresh icon thingy to indicate .jpg that i am indeed at the top of the page whilst looking at the "conclusion" :)
https://image.nostr.build/891d5d361f8c7504c191d5f3c35583acf8b09262f8534fd7440b4f5b388256f5
And the chapter overview is also nicely in reverse order, so atleast it is consistent ;)
It's that bug I mentioned in the PR, about the ToC flipping. We decided to handle that with the revamp of the ToC in the ALEX-50 ticket.
I've now added the scenario:
Scenario 3: Multiple 30041s
GIVEN I have a 30040 index, containing at least five 30041 content events
BUT containing no nested 30040 events
WHEN I select that index card from the landing page
THEN the reading view opens with the content in the correct order
AND the ToC lists the content in the correct order
AND clicking on a section, causes the viewer to focus on that section