@Alexr1239 thanks for the feedback on the woo-woo-ness of the whole ‘no absolute truth’ thing as it relates to app dev. After trying to digest it over the past two years (and getting indigestion a few times) I think I’ve got a half-decent grasp of the consequences for devs and UX… I want to write an article on it, but in the meantime here’s my take:
- It costs energy to keep information in coherence, because entropy is always chipping away at it (cf Claude Shannon’s information theory).
- The more copies of a piece of information there are, the more energy it takes to keep it in coherence across all copies. In a distributed system, entropy takes the form of interrupted communication, synchronisation issues, hardware failures, and malicious agents.
- Therefore, you have a few choices:
- Choose one canonical source of information and discard all other perspectives. This is the cheapest, and is appropriate whenever there should be a single authority. Server-based systems choose this because simplicity and control.
- Coordinate everyone so that they have the same information, often at great energy cost. For systems that don’t involve malicious actors, this requires a Byzantine fault-tolerant coordination protocol that can tolerate 1/3 corruption. For systems that do involve malicious actors, you need to go one step further and introduce economic penalties for intentionally introducing entropy (corrupting the data set), namely proof-of-work or proof-of-stake. This is the approach that blockchain is taking.
- Embrace the fact that every node has a different perspective, and design systems that equip each agent to make their own decisions about the quality of the data they’re seeing. This is the approach that Holochain, Secure Scuttlebutt, Git, and probably others are taking. (I’d characterise all three as ‘agent-centric’.)
I think each has its place, but the thing I like about the third approach, the ‘agent-centric’ approach, is that it does a better job of reflecting how real life works — all we ever have is our own perspective, and the judgments we’re able to make based on the information we receive. Just like real life, it’s uncomfortably messy for those of us who are accustomed to predictability (I still struggle with the inherent messiness of Holochain’s data integrity model sometimes).
But I take hope in the fact that this messiness actually creates robustness — there’s no central point of failure. It works well for the natural world; mammalian immune systems are essentially P2P networks of cells that have mostly agreed to cooperate in identifying pathogens, spreading information about them, and coordinating attacks against them.
How does this apply to app development? Well, not much — it’s mostly to do with how Holochain’s ‘immune system’ identifies and suppresses bad actors. I guess it does leak through into the UX of the app in some ways though:
- The local-first-ness of Holochain means you can take yourself offline and your perspective on other people’s data goes with you.
- You own your data, not some company.
- It encourages app designs that reflect its uncertainty — why not allow a user to register multiple handles, or allow multiple users to use the same handle, or even allow my friends to assign their own handle to me?
- It gives you decentralised data management without the performance overhead of blockchain.