Skip to content

Illegible Consensus

"He who defends with love will be secure." - Lao Tzu

Following on from last week's essay mixer, we'll both look back in history, and consult a popular online personality for a deeper introduction to internet-age institutions. In order to understand our roots, we turn to the Internet Engineering Task Force (IETF) and a governance document they ratified in 1992, just as the web was really getting going. In order to move through it's most modern branches, we'll turn to Venkatesh Rao and James Scott.

How does this fit into KERNEL?

"It is easier to comprehend the whole by walking among the trees and becoming a holographic, fractal part of the forest, than by hovering above it."

Brief

IETF governance revolves around the simple maxim that engineering is about trade-offs. As such, we need clear ways of thinking about how we make decisions. We ought to avoid "majority rule" and get to rough consensus decisions which promote the best technical outcomes.

Rough consensus is therefore a sort of "exception processing", meant to deal with cases where the person objecting still feels strongly that their objection is valid and must be accommodated. Balloting or looking at percentages cannot "determine" consensus in such cases.

Minority views must be addressed, with justification. Simply having a large majority of people agreeing to dismiss an objection is not enough to claim there is rough consensus; the group must have honestly considered the objection and addressed fully all technical issues.

In a different article, Venkatesh Rao discusses how:

"Rough consensus is about finding the most fertile directions in which to proceed rather than uncovering constraints. Constraints in software tend to be relatively few and obvious. Possibilities, however, tend to be intimidatingly vast. Resisting limiting visions, finding the most fertile direction, and allying with the right people become the primary challenges."

As with our own play of thinking patterns, the IETF addresses these challenges in the negative. They consider issues first rather than agreements; address them but don’t accommodate them; and understand (through iterative practice) that consensus is a tool and not a destination.

1. Lack of disagreement is more important than agreement

  1. Determining consensus and coming to consensus are different to having consensus. In determining consensus, the key is to separate those choices that are simply unappealing from those that are truly problematic.
  2. Closure is more likely to be achieved quickly by asking for objections rather than agreement.

1a. The two meanings of "compromise"

  1. Among engineering choices, compromises are expected and essential. We must weigh trade-offs and collectively choose the set that best meets the full set of requirements.
  2. Among people, far less so. Such compromises occur when one group has given up trying to appease the others. Conceding when there is an outstanding technical objection is not coming to consensus. Even worse is horse-trading: "I object to your proposal for such-and-so reasons. You object to my proposal for this-and-that reason. Neither of us agree. If you stop objecting to my proposal, I'll stop objecting to your proposal and we'll put them both in."

2. Issues are addressed, not necessarily accommodated

  1. "That's not my favorite solution, but I can live with it. We've made a reasonable choice" - this is consensus, not rough. It’s only rough when an unsatisfied person still has an open issue, but the group has truly answered the objection at a technical level.
  2. This relies on the good judgement of the consensus caller, or chair. Finding “rough consensus” means that not only has the working group taken the objection seriously, but that it has fully examined the ramifications of not making a change to accommodate it, and that the outcome does not constitute a failure to meet the technical requirements of the work.
  3. What can't happen is that the chair bases their decision solely on hearing a large number of voices saying, "The objection isn't valid." That would simply be to take a vote. A valid justification needs to be made.

3. Humming, not voting

  1. We don't vote because we can't vote. The IETF is not a membership organization, it's nearly impossible to figure out who would get a vote for any given question. There are only “participants”, not “members”.
  2. One reason for humming is pragmatic: to find a starting place for the conversation. A hum can indicate that there were less objections to A than to B at the beginning of the discussion, so starting with the objections to A might shorten the discussion.
  3. Another is to "take the temperature". A smaller bunch of loud hums for choice A and a larger number of non-committal hums for choice B might indicate that some believe that there are serious problems with choice B, albeit the more popular by sheer number of people.
  4. There is deep symbolism here: a show of hands might leave the impression that the number of people matters in some formal way. It doesn’t.
  5. The formulation and order of questions asked can have huge effects on the outcome. Asking, "Who supports going forward with this proposal?", and asking it first, can cause more people to hum in the affirmative than would for differently formulated questions, or asking the same question after some more "negatively" framed questions. Any sort of polling must aim to prompt discussion and questions, not conclude the matter.

4. Consensus is the path, not the destination

  1. Consensus is a tool to ensure we get to the best technical outcomes.
  2. Experience has shown us that traditional voting leads to gaming of the system; "compromises" of the wrong sort; important minority views being ignored; and worse technical outcomes.
  3. Again, you cannot confirm that there is consensus by counting people, it must be about the outstanding issues and whether they have been addressed.

4a. One hundred people for and five people against might not be rough consensus

  1. If there is a minority who have a valid technical objection, that objection must be dealt with before consensus can be declared. This rules out vote stuffing.
  2. It's the existence of an unaddressed open issue, not the number of people, which determines consensus. As above, you can have rough consensus with issues that have been purposely dismissed, but not ones that have been ignored.

4b. Five people for and one hundred people against might still be rough consensus

  1. This is the most controversial result. It generally occurs in the case of small, active working groups where an objector recruits many otherwise silent participants to their cause.
  2. The principle is still the same: If the objection has been addressed, and the new voices are not giving informed responses to that point, it can still justifiably be called rough consensus.
  3. Sometimes, a show of hands can be useful; sometimes, it can be damaging and result in sub-optimal decisions. Sometimes, using a device like a "hum" can avoid those pitfalls; sometimes, it is just a poorly disguised vote. The objective nevertheless remains to protect against simple “majority rule” and get to the best technical outcomes.

The 2020 Take

Most of this is still relevant 28 years later, though there are two points that stand out: this idea of a "consensus caller" or chair, and the strange concept of humming.

In remote working environments there is no easy way to replicate humming. Nevertheless, it indicates two critical ideas for technical governance systems: voting ought to be about finding useful starting places for generative discussion, not reaching conclusions; and sheer number of people or votes does not determine consensus.

That said, sentiment analysis of memes on sovereign social media could serve as a modern means of "humming". Memetic influence also addresses the issue of a "chair", which we do not - and should not - have in decentralized, community-run protocols. While there is no formal position, it is also undeniable that reputation gives certain individuals the power to shift conversations radically.

Unfortunately, it's exactly the authority conferred by the formal position of "chair" which gives such individuals the power to get work done once all technical objections have been addressed. In place of this, we must turn to economics. If we combine delegated voting with algorithms like SourceCred, we can determine quality objections and rebuttals more easily. If we then plug this into non-linear funding mechanisms, which also act as on-chain economic signals of support - as we saw with EIP-1559 - we can determine collectively the best technical outcomes.

Funded code running consensus

EIP-1559 points at something deeper, which is also the reason that the previous paragraph is unnecessarily complicated. We were trying to replicate the IETF process, without acknowledging that, in 1992, there were sufficiently few people and resources online that it made sense we all came to at least rough consensus. Forking the internet in the 90's was not an option.

If the ways in which we signal preference leads to an economic consensus that is strong enough to fund a given project, then we should not build governance systems that stand in the way. It sounds great to "address all technical objections" but - in practice - there are often so many variables at play that doing so in a truly neutral manner is impossible. Cost, however, is a single variable we can all reason about to at least a first approximation.

Rough consensus is just "exception processing" for people. When your running code already establishes economic consensus, you can leverage this to fund multiple different working groups with multiple approaches, removing the need to handle exceptions at the initial stage because you know it will be decided by actual use later on.

"In other words, true north in software is often the direction that combines ambiguity and evidence of fertility in the most alluring way: the direction of maximal interestingness."

Legibility

We tend to reject "rough" systems and opt for more orderly approaches. It was precisely this tendency - arising from the anxiety produced by ambiguity - which prompted Pete Resnick to write the above article. And now, we're saying it's not even about rough consensus. It's about however many projects can garner sufficient support because, in open protocols for money, a "vote" is a economic signal which can simultaneously be used to fund what is being voted on.

If you're objecting to the inevitable chaos of such an approach, it's time to talk about legibility.

James Scott's book, Seeing Like A State, describes how modern states reorganized societies to make them more legible to the apparatus of governance. As Rao describes it:

"The state is not actually interested in the rich functional structure and complex behavior of the very organic entities that it governs. It merely views them as resources that must be organized in order to yield optimal returns. Importantly, this happens on both left and right: the failure mode is ideology-neutral: it arises from a flawed pattern of reasoning rather than values.

"This style of thinking leads to simplification, since a reality that serves many purposes presents itself as illegible to a vision informed by a singular purpose [...] The deep failure in thinking lies is the mistaken assumption that thriving, successful and functional realities must necessarily be legible."

Don't misunderstand: there is - as always - a trade-off between "simple to understand" and "functionally useful", and there are some cases in which the first is genuinely useful. For instance:

"The bewilderingly illegible geography of time in the 18th century, while it served a lot of local purposes, would have made modern global infrastructure, from the railroads (the original driver for temporal discipline in the United States) to airlines and the Internet, impossible."

We can learn a great deal from the history of states and the very human desire for legibility. It does, in some instances, lead to improvement. For instance, we should learn from the IETF that:

  1. Closure is more likely to be achieved quickly by asking for objections rather than agreement.
  2. We should compromise between engineering choices, but not between people.
  3. We must address issues and justify technical choices to the greatest extent possible.
  4. Majority rule sucks.
  5. We must use consensus as a tool, not an end.
  6. We must build systems and cultivate cultures which make these principles easier to uphold.

That said, we no longer operate in a version of the internet where rough consensus about a single way forward is even possible, let alone desirable. We need to embrace the generative chaos and use economic code which establishes consensus to fund as many different approaches as is appropriate, without treating humans as exceptions to be handled.

"Reformers do not acknowledge (and often do not understand) that they are engineering a shift in optima and power, with benefits AND costs. Instead, the process is driven by a naive 'best for everybody' paternalism, that genuinely intends to improve the lives of the people it affects."

Don't be a reformer. Build systems that help people govern themselves, and then - the most radical choice of all - let them actually do so.