Nostr View

Silberengel @Silberengel - 29d

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.

1
0
3

mleku @mleku - 29d

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

2
1
3

Silberengel @Silberengel - 29d

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.

1
1
3

Silberengel @Silberengel - 29d

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.

1
1
3

Silberengel @Silberengel - 29d

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.

0
0
3

mleku @mleku - 29d

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?

2
1
3

Silberengel @Silberengel - 29d

A tags are kind:d-tag:npub .

1
0
3

Silberengel @Silberengel - 29d

Here's a testdata event with a tags. Easier to show, than tell. https://njump.me/nevent1qqs8hp0e6ahazxjwc6xy6hhsfwc3ayk7umnul3mc8rjygxv90y97wcspzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgq3q2umrfdjgvdxt45g0y3ghwcyfagssjrv5qlm3t6pu2aa5vydwdmwqshnnfd

1
0
3

mleku @mleku - 29d

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

0
1
3

mleku @mleku - 29d

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

0
1
3
Showing page 1 of 1 pages