This customized / abstract consensus concept is purely awesome!

From a "Hey I think I'd like to use that" perspective, what if there wasn't just one system state but many systems' (plural) states tracked across the set of all active nodes and libp2p is helping to pass these state notification messages around and optimally record/track the vote of each Actor?

Some thoughts about what I see the libp2p-consensus would provide as an interested dApp author:

Coordinating the collective, state voting information so an Actor can see the votes and states in a normalized way, but not implementing the particulars of any consensus algorithm.

This library focuses on recording and aggregating the votes the Actors propose and optimizes communicating those changes between peer ids.

Specific algorithm implementations for decision making [e.g. libp2p-consensus-paxos] are then written on top of this; and that's what the dApps include (and/or write for themselves).

This makes algorithms much easier to write because you have a single object that describes every Actor in the system, what their vote is, who their peers (quorum group members) are, and this Actor's vote is then automatically synchronized across the system without having to write anything.

Creating the concept of a VSID (virtual system identifier).

This means many p2p applications on the same computer and across the same peer network can track consensus separate from each other despite sharing/reusing the same p2p communication ports/channels, and sharing/reusing peers.

I think of many mobile phones in a room.
It's way more efficient if there was one p2p "service" per phone taking advantage of IR, USB, BlueTooth, and WiFi Direct transport layers and many apps connecting with that service (easily discovering nearby nodes, communicating to the Internet, etc.) than for each Application to repeat that independently.

This VSID is like a Domain Name, Application ID, and Instance ID all rolled into one.
It's equivalent to a "PID" for a p2p decentralized network system; this VSID represents a governing authority (group of people) responsible for maintaining it, the service type/class it's supposed to implement (a game name or other distributed app), and a specific instance of that service/class.

An example of a VSID could be the CID Hash for the string:

Session Instance "XYZ123" 
of the application "Shooting Fish in a Barrel" 
managed by the Organization "Distributed FunHouse"

--- This VSID is the thing all the distributed nodes are consensing on the "State" of.

To some extent, these VSIDs layers are also hierarchical, before Session Instance "XYZ123" of the application "Shooting Fish in a Barrel" can begin, the "Shooting Fish in a Barrel" VSID has to come to consensus on that the Session exists; just like the "Distributed FunHouse" VSID had to announce that the "Shooting Fish in a Barrel" game existed within its domain (at this level it might track current player count across all instances, or Peers with Games in Progress (to spectate over)).

I see the calls to libp2p being something like:
SetState(VSID, State) or SetState(VSID, ActorID)
to set this Actor's "vote" on what the state should be.
Then libp2p handles distributing the information to its peers as part of libp2p-consensus.

A way for the application to register the id or version of the consensus algorithm the application is using.
This is so other "Actors" in the system can know what algorithm that Actor is practicing. It might refuse to participate, ignore that Actor's votes (treating it somewhat like a malicious actor), adjust to the other Actor's strategy, do nothing special and act normally, etc.

The Consensus Algorithm ID the VSID is currently using should also be part of the System State. As new Actors join the VSID with new algorithms, the system can decide how/if/when it should upgrade/migrate to the other algorithms. Or the algorithm could change depending on other circumstances too; like when "Bootstrapping" a different consensus algorithm is used than when "Under Attack" or "Operating Normally". [Perhaps this gives the VSID the concept of "Go to Red Alert!" which lower level VSIDs can respond to.]

I also definitely expect to see different consensus algorithms working simultaneously on different VSIDs.

Thanks so much for allowing me to contribute!

As defined in the OpLogConsensus interface,

   // Rollback rolls the state of the cluster back to the given node. The
    // passed in node should be a node that was previously a state in the chain of
    // states. Although some discussion will need to be had as to whether or not
    // this is truly necessary
    Rollback(State) error

This is the discussion that will need to be had. I have several questions:

• Do rollbacks imply an non-truncated log which in which every state can be rolled back because every state can be rebuilt by re-applying the ops from the very beginning?
• What happens when the log has several equivalent States at different points? Should the rollback happen to the newest or to the oldest? (The original notes suggest the oldest (ipfs/notes#179 (comment)) but it would seem to me that common sense would expect the newest )
• The OpLogConsensus needs two things: a consensus mechanism and a log. The consenus mechanism is interfaced as Consensus. The log though is not defined anywhere and should be interchageable too (it is not a MUST, but it would be nice in order to facilitate swapping log backends inside consensus implementations: i.e. inmem vs disk vs ipfs-based logs).
• A rollback is very similar to a SetState() which gets performed with a previous "snapshot" of the System. Would it make sense to have OpLogConsensus include the Consensus interface and pass the responsability of setting a valid previous State to the user via CommitState() directly? After all, a user can only rollback to a state if it knows the state in advance.