Nostr View

Silberengel @Silberengel - 29d

Yeah, that's what I said about the kanban boards. The cards have to remain separate from the boards.

1
0
3

mleku @mleku - 29d

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

2
1
3

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

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.

1
0
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

I think that's something for the relay to handle. Trying to stuff it into events is inefficient.

0
0
3

mleku @mleku - 29d

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

0
1
3

Silberengel @Silberengel - 29d

We're the first team to have an actual use case that _needs_ Nostr. That's why this isn't just a clone of something in existence. This couldn't exist before Nostr. #GitRepublic will also be a doozy, but we have to get Aedile to at least v0.2.0 before we can design that.

0
0
3
Showing page 1 of 1 pages