Oof, parameterized replaceable?
Discussion
Again, I'm a noob with this.
I have no idea what to use when. I just know what general spec pattern I need.
Should both the Graph and the Edge event be Replaceable.
Only the Edge?
Replacing means you want to change them in place, but I don't really know why you would do that.
I want to be able to edit my graph.
I'm fine with just deleting and creating new connections/edges tho, so those could be just normal events.
It's cleaner, I think, but nostr:npub1fjqqy4a93z5zsjwsfxqhc2764kvykfdyttvldkkkdera8dr78vhsmmleku would know.
Maybe a 10000 series replaceable is a happy medium.
it would need to be a 30k range with d tags attached to a workspace and probably a set of custom tags to make a hierarchy of graph elements, and other things like labels and whatnot.
making it work as a realtime collab workspace would also mean clients would need to be constantly chattering events from the UI to the relay and back to other clients currently viewing the same document. probably this would just be a subscription on kind and d tag, and maybe some other tags that designate other facets such as comments, and so forth.
it probably would be faster if it used a binary encoding as well, and a QUIC/HTTP/3 base for the network transport, though i can see it being servicable with JSON/NIP-01
The graph is very similar to a 30040 index, so I'm lost as to why it shouldn't be param. repl. too.
It's like a visual wiki article with the references being nodes on a canvas.
yup, that's exactly what it is, so its structure is similar, and would also have a tree geometry, but maybe more like a DAG than a tree to account for merging collisions of changes between users (or at least determining their total ordering).