ahdinosaur
commented
10 years ago using the hash of the object as immutable keys sounds like a great strategy. :+1:
as it may be relevant, i'll try and provide some missing context as to how i see OpenApp.js working to fulfill it's charter:
- we describe feature requirements of our "next-generation full-stack framework"
- we assemble the best of the node.js module ecosystem that meet these features
- we write new node.js modules to fill gaps in features
- we support all modules within the stack (contributing code, improving docs, revenue sharing, ...)
so with this in mind, secure-scuttlebutt and related modules fit really well to meet the "data subsystem" features of the stack. as you already are, feel free to direct the flow of the "data subsystem" as you wish with awesome modules. :) i'll add "validatable data" as a feature requirement of OpenApp.js.
for contextual completeness, the other possible "subsystems" of the stack that i'm aware of so far: the "view subsystem" of mercury and the "controller subsystem" of graft.
back to the issue at hand, i'm interested to see how immutable keys will work in practice. for example, what do we do when we want to use semantic keys with meaning? is the answer to have another object with its own immutable key that maps the semantic keys to the immutable keys? in general, i think the best way to answer questions of uncertainty is to experiment with applications that increase our understanding of these ideas in practice, so i'll try to experiment with writing something that uses secure-scuttlebutt and mercury, especially as i may now have more exploration and experimentation time.
dominictarr
reading through your bullet points, i was very happy to see you plan immutable data. will you use the hash of the object as keys? that is a very simple way to ensure data is not only immutable but also validatable.