I love simplicity. Sometimes I get accused of over-simplification, but I am always motivated to find that starting point where I can build back up, instead of peeling more and more away. Once I find that starting point, I can add on those those necessary complexities - and when I am wrong, I can back up ever-so slightly, re-work, and not be concerned that I have over-invested in a model that started from wrong first principles.
In my copious spare time, I have a few technical projects underway. I try to apply the same simplicity principle - that if I don’t ‘get’ what the tool/framework/app is doing, either I am missing something very fundamental, or the tool/framework/app has missed something very fundamental.
Recently, I have been going on a technical journey, learning the most awesome FastAPI framework for building applications and APIs, built on the Python language. I have grown to love the Python language for its simplicity and its long heritage: if you are looking for an abstract concept implemented and tested in the real, Python is the place to look. For example, I wanted to prove that I could implement the key aspects of Bitcoin with zero dependencies - right down to the cryptography, and I did it in on Bitcoin from Scratch on repl.it. I also found a fabulous web framework, the MostMinimalFramework that creates a Python web server framework (similar to the likes of FastAPI, DJango and Flask) with only 99 lines of code.
In short, by mastering these new tools and driving my learning to first principles, I’ve been able to do things, that I never dreamed possible to do on my own, but now I can. I also have the benefit of applying this clarity and focus to the softer, messier world that I inhabit related to trust frameworks and digital identity.
In this world of trust frameworks and digital identity schemes are pretty complicated, nuanced and hard to understand. I have also discovered that there are lots of (not-so-obvious) commonalities with monetary frameworks, both crypto (Bitcoin, etc.) and fiat (state-issued currency). In studying these, I have arrived at a simple framework that I am calling the Most Minimal Trust Framework. You can see it below.
As you can see, there are not very many elements. Let me explain them.
First, there are two counter-parties (illustrated by the profile icons). For every transaction, or interaction they exist on opposite sides. Counter-parties exist independently of role or status, which are often fundamental elements of more complex framework.
Second, there are two layers: The first layer is the [Intention] layer which is concerned with the motivations of the counter-parties. The second layer is the [Integrity] layer, which is concerned with the correctness, or soundness of the mechanisms involved.
And third, there are functions that are imbued within these layers. So far I have identified two that seem to capture everything. (Verify) is concerned with authenticity of a fact or statement, and (Transfer) is concerned with transfer (change of state) and eventually, final settlement of something of value
I’ll conclude the post here. Have a look a this framework and see if it clarifies anything or can be applied within your context.
I am not saying that this model is right, but I am always looking for the simple way out. This model reflects my latest thinking of how to synthesize those complex framework into manageable elements that I can contain within my head and work with conceptually.
Nice! I love simple models, because they're the only ones I can remember.