Nostr View

Silberengel @Silberengel - 29d

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.

1
0
3

Silberengel @Silberengel - 29d

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.

1
0
3

Silberengel @Silberengel - 29d

It's the Zettelkasten concept, basically.

1
0
3

mleku @mleku - 29d

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

1
1
3

Silberengel @Silberengel - 29d

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.

1
1
3

mleku @mleku - 29d

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

1
1
3

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
Showing page 1 of 1 pages