In this post I want to share my complete pet project todo list. As I only have about 8 hours per week to work on any of this, the whole stack might never fully get achieved while I am working on it alone unless someone wants to sponsor the project to the extend that I'll be capable of taking a 2 year sabatical (what would equate about €250k to match my current day job pay).
It's an insane stack of 20 projects. It the projects didn't have dependencies and if I was able to work on all 20 projects, my 8 hours would give me 24 minutes per project, so I may need to accept that I can't reasonably finish all of them.
Don't get overwhelmed, but here is my full stack of 20 projects in one image. I will explain them all in high level details later.
My overarching mission: Web 3.0 needs quantum-resistant security and better authorization models across all possible abstraction level.
The above image is just the stack when "everything" is working. Because of my limited time I found it nececary already to try and be realistic, I've divided my 20 projects into three groups. High prioirity, medium priority and low priority. This was already hard to do because in my heart every single one feels high priority, but I need to keep things realistic. My active projects at this date are the C++ CoinZdense library, The aiow3 Web 3.0 bots and L2 node framework, and the Merg-E DSL/runtime. Other high priority projects that arent currently active are python language bindings (that will replace the old Python Proof Of Concept lib), and a port of the Hive Archeaology Bot to aiow3.
Let's do a deep dive to see how things fit together.
CoinZdense libraries
At the very bottom of our stack we find CoinZdense implementations. In this YouTube video, recorded already 3 years ago at HiveFest in Amsterdan you can see the base ideas presented. In short CoinZdense is about combination of hierarchical high-reuse post-quantum hash-based signing-keys and about decomposable and delegatable authority through least authority subkey management. This post is too hight level to get into the gritty details, but quantum resistance, decomposition, delegation and entropy as a resource are the four pilars of CoinZdense that I hope make it part of the way forward for securing Web 3.0 towards the future.
While building a first Proof Of Concept of a Python CoinZdense library, a library of what I've used a tiny bit of an early version by creating the HIVE CoinZdense Disaster Recovery tools, at one point I started running into the concurency limitations of Python. So the PoC was not fully completed when I decided to start porting it fist (unfortunately) to Rust, and later, when I ran into language binding issues with Rust, I switched recently to restarting my efforts as a C++ template library, libcoinzdense, the C++ CoinZdense template library. The porting process is still in it's early stages and I'm using way too many higher version C++ standard features right now, but getting back into C++ feels like it has been the right decission.
While the C++ implementaion is going to be the backbone of much of the rest of the stack, language bindings for native languages like Rust and Go are a pain. They aren't high on my priority list, but next to the C++ library, I hope to also one day have time to do both a Rust and a Go port of libcoinzdense.
CoinZdense language bindings
Above the C++ template library libcoinzdense is the language bindings layer. My top priority in this layer right now are the Python language bindings. At medium priority we find the typescript language bindings, but to implement these, we will need to extend the libcoinzidense implementation with a build target for a (non-template) Web Assembly target on what we can then buikd a TypeScript and many other non-native language bindings.
Next to Python and TypeScript, language bindings for other languages are desires too though low priority. Clojure and Clojurescript are important if we want to later support FlureeDB. And next to TypeScript, maybe we want JavaScript and Secure EcmaScript too. I'll need to look into that to see if the last one is achievable.
Bot/L2 framework
On the Web 3.0 client side, language bindings arent enough to do usefull things. In the past I did work on the aiohivebot python library. An event oriented asynchonous Python framework for writing fault tolerant high-failover HIVE bots. Currently I'm porting aiohivebot to a new project named aiow3 that aims to provide the same functionality as aiohivebot, but not for HIVE only. I'm aiming to make aiow3 a python framework that can handle multiple chains. HIVE is still my first target, later with CoinZdense piggybacking and eventually with support for dual signing if any chain accepts CoinZdense pull or merge requests (more on thet later).
What aiow3 is for Python, two other, frameworks aim to do for ClojereScript and TypeScript. The medium priority tsw3 for TypeScript and the low priority clsw3 for ClosureScript.
Merg-E DSL
In an earlier prospect stack there were four more projects. Two language bindings, one for Elixir and one for Monte. And for these two languages a framework akin to aiofw. One for Elixir and one for Monte.
After looking into what would be needed for language bindings though, I ran into the fact that Elixir runs on BEAM, the Erlang VM, and Monte runs on Typhon, it's own VM. Neither with options to use WASM as an easy bridge for language bindings and neither as far as I could figure out, with a friendly module interface compatible with C++ modules. But I really did want to support at least one least authority language and have a bot/L2 framework in that language, if possible with support for actors.
After thinking things through, I remembered that 14 years ago I wrote a blog post with musings on how reference stealing akin to the undesired behaviour of the now depricated C++ auto_ptr smart pointer should be default, and the idea of writing a realy minimal bot/L2 runtime in C++ with CoinZdense integrated, and with a small special purpose Domain Specific Language (DSL) started looking like a way out.
The Merg-E DSL is meant to be combined with a Merg-E runtime in a C++ implementation that eventualy will be both language bindings and framework in a way. A language and framework that should be able to do everything that aiow3 can do, and in a least-authority and in an optionally actor oriented way, but nothing more. It's not meant as a general purpose language.
But Merg-E is a project in its own right. I need to do suficient testing and I'm looking at a growth path. A first Merg-E runtime that I'm currently working on is a Python prototype. When it works I want to make the real thing in C++ and link CoinZdense in. And then maybe, just maybe, if I ever find the time, it would be interesting to look at the posibility of porting Merg-E to BEAM.
Demo
A framewk in different languages is cool, but without some code to demo it, it is prety much unproven technology. For this reason there are currently two demo project in my stack, One fun one, and one rviving a really old project of mine that I abandoned because I was getting a M.Sc in digital forensics and that was eating up my spare time.
The first demo I have defined is a little HIVE bot that I wrote a while ago that currently runs on lighthive. That library needs to be ported to aiow3 in such a way that I can test the whole client side stack with CoinZdense piggybacking. That is not real post-quantum security yet, but enough to demonstrate what is possible. The bot demo of a HIVE-Archeaology bot should demonstrate the Python stack. This is the high-prio stack right now.
A second demo I want to make is a revival of MinorFS2 reimagined as a distributed capability secure Web 3.0 storage system. This Demo I hope to be angle to fully implement in the Merg-E language. For more information on MinorFS2 check out my old slide deck from my 2013 OHM2013 talk on the subject.
Blockchain pull requests
So far all of this should be a lot of work but so far everything just hinges on my ability to complete things and allocat time. But for the next part I'll need to be lobying and interacting socialy to convince communities to either accept my pull or merge requests for their chain, or to integrate my native or clojure bindings coinzdense implementation themselves. This is I think the most chalenging bit of my stack. My stack is already way too big for me and I would hate it if I would end up having to write my own layer-0 because I can't get any chain to accept my pull request.
My priority one chain for what I hope to either write a pull or merge request of find cooperation from the core team is HIVE. Fluree is a close second. With ThorChain and Cosmos behind these two at quite e some distance.
My priorities.
So here is my top 5 of high priority pet projects that I currently have on my todo list of 20:
| project | status | active | priority | blocked by | goal |
|---|---|---|---|---|---|
| c++ CoinZdense lib | porting from Python POC | YES | high | - | Core hash-based signatures and least-authority subkey management, meant both for Web3 core blockchain integration for C++ based chains like HIVE, and for all first generation language bindings. |
| Python Language Bindings | NOT STARTED | NO | high | c++ CoinZdense lib | Replacement of the Python POC, language bindings from Python to C++ CoinZdense |
| aiow3 | Porting from aiohivebot | YES | high | - | Multi-chain python implementation of the Web 3.0 framework for bots and layer-2 nodes, largely based on aiohivebot. |
| Hive Archaeology bot | Exists as a HIVE only implementation | NO | high | aiow3 | An example bot that needs to be ported to aiow3 in order to make a testable stack for CoinZdense piggybacking |
| Merg-E | design and lexer | YES | medium | - | Least authority bot & layer-2 node framework and Domain Specific Language with actor-model support. This replaces the earlier plans for both a Monte and Elixir language bindings, and for a framework implementation in both Monte and Elixir |
Then the next set of 5 with medium priority. When I complete high prioirity projects I might move one or two up to high.
| project | status | active | priority | blocked by | goal |
|---|---|---|---|---|---|
| w3minorfs | NOT STARTED | NO | medium | Merg-E | An example layer-2 node for a re-imagined distributed Web 3.0 version of MinorFS using RumpleTree, written in Merg-E. |
| C++ WASM target | NOT STARTED | NO | medium | c++ CoinZdense lib | An extra target for the c++ CoinZdense lib allowing language bindings for everything but Python for first gen |
| TypeScript language bindings | NOT STARTED | NO | medium | c++ CoinZdense lib | Prime language bindings for the JS/TS/SES family. |
| tsw3 | NOT STARTED | NO | medium | TypeScript language bindings | Idiomatic port of aiow3 to TypeScript |
| HIVE pull requests | NOT STARTED | NO | medium | c++ CoinZdense lib | Collection of pull requests for HIVE core to allow HIVE to implement dual-signing with CoinZdense |
And my list of 11 low priority projects, at least low priority until I've completed a few high and medium prioirity projects.
| project | status | active | priority | blocked by | goal |
|---|---|---|---|---|---|
| ClosureScript language bindings | NOT STARTED | NO | low | C++ WASM target | Language bindings for ClosureScript to potentially support FlureeDB |
| clsw3 | NOT STARTED | NO | low | Clojure language bindings | Idiomatic port of aiow3 to ClosureScript |
| Clojure language bindings | NOT STARTED | NO | low | C++ WASM target | Language bindings for Closure to potentially support FlureeDB |
| Fluree pull requests | NOT STARTED | NO | low | Clojure language bindings | Collection of pull requests for FlureeDB ledger core to allow FlureeDB to implement dual-signing with CoinZdense |
| JavaScript language bindings | NOT STARTED | NO | low | C++ WASM target | Language bindings for JavaScript for where TS isn't an option |
| SES language bindings | NOT STARTED | NO | low | C++ WASM target | It would be amazing to be able to use CoinZdense from SES, though not sure yet if this is possible |
| Rust Port | Remnants from earlier attempts to use Rust as basis for all language bindings. | NO | low | - | Same as C++ CoinZdense lib, aimed at Web3 core blockchain integration for Rust based chains like ThorChain |
| ThorChain pull requests | NOT STARTED | NO | low | Rust language bindings | Collection of pull requests for ThorChain core to allow ThorChain to implement dual-signing with CoinZdense |
| Go Port | NOT STARTED | NO | low | c++ CoinZdense lib | Same as C++ CoinZdense lib, aimed at Web3 core blockchain integration for Go based chains like Cosmos |
| Cosmos pull requests | NOT STARTED | NO | low | Go Language bindings | Collection of pull requests for Cosmos core to allow Cosmos to implement dual-signing with CoinZdense |
How to help
Want to weigh in and help out with this close to impossible to complete task? Right now feedback on any of my plans or projects is already real help. If you know how to progam or review code and have some spare time, I'dd love your input on tha too. Right now the main thing I would like input on is Merg-E. I've been posting a number of blog post on HIVE in recent weeks on my Merg-E ideas, and I really would like Web 3.0 devs to weigh in on things that are good and things that might be problematic. I'm trying to keep things scoped, small, and DSL nor general purpose, but if there are features every Web 3.0 framework/language needs that I haven't considered yet, please pont them out.
Anyone wanting to help out on any part of the stack, especialy the currently low prio part but also the medium preo bit, please reach out. It's all only medium or low prio because of my time resources. Everything would be high prio if had unlimited time.
Finacial support for the project is also very much welcome, but small amounts don't really help, I apreciate them but they dont help because they don't allow me to make extra hours. For extra hours I need to be able to go to my employer before the start of the year and basicly arange I'm shifting from 40 to 36 or 32 hours a week for at least a whole year. That is 10% of my yearly income at least, and I don't curently expect anyone to cough that up to support me. But if you can and want, please drop me a message. Oh, if I manage to sell my ols capibara.com domain (available on godaddy )for a decent price soon that should allow me to free up 4 more hours each week for at least a year, possibly two. Not quite the two years sabatical but at least a 50% increase in velocity.
And a final way to help is advocacy. If you like my project stack and believe in what it could add to your favorite Web 3.0 chains, advocate for the future integration in these chains. Help me get info on possible misallignment between CoinZdense and these chains so I can cirrent my direction.