This sounds very impressive and interesting. Synchronized distributed applications without deadlocks, while worrying only about client-side code? Sounds amazing, I'll have to play with it.
Currently, you can't, so you're not missing anything. :) But I'm currently working on the necessary hooks so that any security model you want can be enforced by the server.
I have worked on projects that occupy this space. I tend to think that it's ok for the client to have arbitrary read access, but for writes it's a better idea for the client to generate events that are then approved and applied by the/a server. The reason for this is that it's much easier to approve high level events than low-level change-sets.
Yup. I haven't dug too much, but is there anyway to have the web clients just respond to state changes and then have some server "client" (in node or what not) be allowed to alter state?
I've just pushed new versions of the client and server which solve a couple of bugs. Please let me know how you get on if you have a chance to try out this stuff. Would be great to get some feedback.
Just out of curiosity, how much is it tied to Node? I mean, I imagine the server side could be implemented in other languages, but how much are you leveraging the fact that Javascript is used on both server and client? Just wondering because I'd be interested in running this with a Python back-end.
The protocol between client and server is dead simple, and the server is currently about 400 lines of code. The only reason the server is still in nodejs is because it's quite neat to be able to write transactions on the server-side too and by being in JS, I can just use the same client code as in the browser to do that, with very few changes. Writing just the txn engine in other languages would be very simple too. Next week I'm hoping to write some documentation for the protocol. But it's really just abstract addresses and version numbers and such. No rocket science at all - especially given that Node is single-threaded!
