Nostr Web Client

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.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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

Reply to this note

Please Login to reply.

Discussion

Silberengel 1y ago

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.

Silberengel 1y ago

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.

Silberengel 1y ago

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.

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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?

Silberengel 1y ago

A tags are kind:d-tag:npub .

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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

Silberengel 1y ago

Here's a testdata event with a tags. Easier to show, than tell.

https://njump.me/nevent1qqs8hp0e6ahazxjwc6xy6hhsfwc3ayk7umnul3mc8rjygxv90y97wcspzemhxue69uhhyetvv9ujumn0wd68ytnzv9hxgq3q2umrfdjgvdxt45g0y3ghwcyfagssjrv5qlm3t6pu2aa5vydwdmwqshnnfd

ᴛʜᴇ ᴅᴇᴀᴛʜ ᴏꜰ ᴍʟᴇᴋᴜ 1y ago

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