I need to arbitrarily create a stream for a contract.
on this stream I will store Create/Update/Delete commands for entities within the generic contract schema.
party nodes, and only party nodes on this contract/stream, need to be able to validate these operations at an application level. By that I mean, I need the nodes to call my javascript stuff to check that we are OK with the operation, which will involve interrogating this generic schema. If they like it they will commit to their local instance and return success back to multichain.
all parties need to sign the transaction with the resultant hash of the contract, which should be consistent in normal circumstances.
My schema has a Request->Dialogue one to many relation for each operation. A contract is not in a valid state until all the dialogues for each party have been completed correctly (have the right hash state). I have a Transmitter and Receiver program on each node, these would get refitted to write and read from streams, not from each other.
parties can be added or removed from the contract provided everyone, including the leaving party on a delete, agree, based on rules configured within the contract itself. e.g. the originator of the contract, before inviting new members, may have configured the rules so that only they can add new users, or that only a certain list of parties (such as approved brokers for a specific area). New users will therefore have agreed to join a contract where they have less privileges than the originator.
Right now, as you know, I am just broadcasting the request to everyone directly and on another channel collecting confirmations, and merkeling these hashes. Collisions are merged into a block until we have a consistent hash. In terms of the amount of traffic, i dont think it makes any difference using blockchain proper, it's still going to be ~n^2. For prototyping purposes my stuff works. But you have to trust me that the immutability really does work in production. I am going to have to refit this with one or other standard offering, even though ultimately its doing no more than what I am doing now. (well, universal timestamp makes stuff even easier, but I've sidestepped most of that)
This business of who can and cannot be on the chain is messy I guess. We need the originator to be able to delegate the choice of sub parties to other intermediates, possibly with restrictions. i.e it's your choice, but they have to be in this list.
I dont need this right now, but if it's all there or will be soon I can at least think more seriously about using MC both as a transport layer under my generic contract schema, as well as a publication layer for certain states of the contract , the purpose of which right now is mainly so we can say we are using blockchain proper ;).
