Provide a more flushed out consistency model for the ACL + data

[sanderpick]

From @aschmahmann

It'd be great to have a more fleshed out consistency model for the ACL + data. Some examples:

1. Strong Consistency/Consensus:

   * The participants in the network have an agreement as to the total order of all events

2. Causal Consistency

   * If A makes a change a1, and later makes a change a2, B cannot process a2 without first processing a1

3. Eventual Consistency

   * If A, B and C make changes, if they are allowed to communicate then they will eventually agree on the same state (could be event ordering, or just the state created by processing the events)

[carsonfarmer]

Some discussions with @andrewxhill on this topic has made me rethink some of our earlier assumptions about ACLs in the context of Threads. We should probably flesh that out more here and then dig in and address this issue.

To get the discussion going, one suggestion from @andrewxhill was to have a fixed ACL per thread, and require that Thread be 'forked' to derive a new ACL. The nice thing about this is that we now have pretty 'Strong Consistency/Consensus' (at least in terms of the ACL document). The danger is that, if a fork isn't properly communicated, updates to the old Thread could be lost. This also implies some way to selectively notify Thread participants of the fork (to support things like revoking access).

There are other up- and down-sides to this approach. But it might give us some time to see what falls out of broader discussions around ACLs and CRDTs?

[aschmahmann]

I agree that this is a good avenue to explore. While we don't quite get Strong Consistency unless we get the participants to agree on some consensus (e.g. no forward progress until the forked thread is agree upon) we do get some other nice properties including Operation Compaction.

Operation Compaction: If we have a reasonable system for forking a Thread then when an op-based Thread (e.g. operational transform or op-based CRDT) gets big we can always force a compaction via fork. Because the fork is "opt-in" by each participant they can freely check if the compacted data is equal to the operation data, it's sort of a lazy consensus.

updates to the old Thread could be lost

It depends on what we'd want the scheme to look like. If forking a Thread is a fork, rather than a deletion of the previous Thread, then no data will be lost. Additionally, depending on the data model it's possible that even if two forks diverged (e.g. Bob made a change on Fork1, while Alice has moved on to making changes on Fork2) that there is an automatic merge function that can merge Fork1 into Fork2. Even if the data model does not support that type of functionality at least the data is still available for the forks to be manually merged.

I'll do some more thinking about this, but if any of you want to chat about this I'm more than happy to.

[carsonfarmer]

After some offline discussion and meetings (thanks @aschmahmann), we're moving to a more flushed out design via a TIP (#66). Closing this in favour of that.