Experiment: Event-based RicardianContracts using Textile Threads v2

[placer14]

Purpose

I've been poking at Textile's ThreadsV2 repo and interested in leveraging some of the patterns it provides. I see some benefit to adopting these patterns within the daemon. A non-exhaustive list of benefits/goals:

• add messaging redundancy for Order handling. (Note: Message redundancy is not provided directly by the adoption of Threads, however, it may be indirectly enabled by its use. By using a redundant online node (self-hosted, or as a provided service) to capture all offline traffic on behalf of another node -- without coupling to the model and ensuring the content is unreadable by the redundant node.)
• creating a state-machine-based model for our RicardianContract updates (so they can be more idempotent and causal during their state changes)
• ~appreciate the added security of per-contract key handling provided by Threads~ It doesn't seem prudent at this point to leverage key handling offered by Threads. Even though its redundancy at the message layer is important, Threads does not safely expose the keychain for use by the application which still has dependencies on those keys. Further, sharing key handling between apps may expose security risks which aren't worth the benefits a shared keychain might provide. It does seem Thread's keychain can operate independently of the app's keychain provided the app provides it a sufficiently-hardened key to initialize itself.
• forcing us into formalizing a RicardianContract model which is separate from our current serialization usage with protobufs
• forcing us to separate ob-go concerns into separate composable modules which will make it easier for OB to integrated into other systems/projects by the community
• avoid "recreating the wheel" as we explore solving some problems and sharing the effort and improvements offered by the community

Concerns

This approach (if fruitful) would supercede/conflict the following efforts which are already in progress:

• Our order message backup solution inside ethereum-master. Threads provides it's own datastore of state updates and would even provide the pattern needed (a reducer) for these updates to be applied on top of any version of the existing state to bring it up to the latest state.
• Our offline message relaying being explored for Haven. Threads provides the ability for any peer to be party to a set of messages (independent of whether the updates can be read as they are encrypted). We could potentially configure a peer to simply capture ALL updates and share them with interested parties without the need for connectivity at the time of update. Threads call this cafés and are akin to our push nodes.
• ~Our existing message key handling. Currently, we encrypt all messages with a single key which is shared for all orders indiscriminately. Threads applies a unique key for each set of updates, a read and write key are separately used. We would need to find a way to allow our existing peer key to act as a seed within these stores.~ Solved. We can derive some seed bytes from our internal identity for Threads to init their own keychain which will remain separate/isolated from ours.
• Our existing implementations. Both ob-go and ob-web (in JS) use the existing message handling pattern. Given our current handling is not idempotent and the new system would be, there is some concern that redundant behavior provided by Threads may affect existing nodes. The effects of Threads usage should remain isolated to other nodes which have opted-into the new ContractStore.

Approach

In order to explore Threads in a parallel fashion as mentioned, here is the idea for how we might approach this:

• [ ] Figure out how to close dependency gaps between ob-go and ThreadsV2. Proof would be the initialization of a Threadservice within ob-go using its own IPFS impl.
  • [ ] Abstract Threadservice's dependency on IPFSLite (to indirectly remove the go v1.13 crypto package dep)
• [ ] Abstract our message handling callbacks to allow multiple "services" to handle updates.
• [ ] Create our RicardianContract (RC) state-machine Model and EventCodec (which contains the Reduce behavior) collectively called the ContractStore.
  • [ ] Demonstrate that the ContractStore state is eventually-consistent with the existing impl in the online case. (How?)
  • [ ] Demonstrate the same for offline cases using an independently-deployed daemon which replicates the events for later consumption by the interested/authorized peers

[placer14]

Had a meeting with the folks from Textileio and got some additional insight. Updated the description with this gained insight. Will begin exploring how to close the dependency gap as that appears to be unavoidable if we want to run these two systems side-by-side.

To this end, I'll see if I can somehow get the existing Threads impl to use our custom IPFS node instance... will report back as progress is made.