last couple of days I have been quite caught up with my Agora project again. I am working on a full whitepaper and architecture document describing it. I find the process of expressing complex ideas difficult - already I have written some 4000 words, then scrunched it up and threw it in the trash, and started again, and I am not happy with the new one either yet.

Just to explain exactly what has got me so excited, but trying not to go into too much detail, I am designing a multi-chain system that is designed to be easily extended, and I intend to code it in C with GNOME libraries, because, well, I <3 Richard Stallman, and I especially <3 optimised, modular code, I already know C not too badly, and the way I am designing the system, allows me to build small, individual parts at a time, and then gradually building an over-arching control system that coordinates the different subchains and related services the system involves.

So, I probably won't be posting even as often as I am at the moment, because I want to finally dig into this, now that I have a (for me) achievable roadmap sketched out for building it.

You might ask, why rebuild it when Steem already is awesome. Well, Steem is awesome, yes. But it was designed at first to be a monolithic chain with 4 or 5 different data types stored on it. It uses a single, very memory-hungry database that manages all of the tables created by these datatypes, so they are quick to search, so that Witnesses can make their 3 second timeslot and get paid for printing a block.

I also want to build features in that are far off on the horizon for Steem - an agorised Tor type relay network, a Maidsafe/Storj style file storage system, a Bitmessage type system for instant messaging and email, an inventory integrated advertising system for running retail operations on the chain, and, something that I don't expect for a long time from steem - private, verifiable but unreadable transactions and account balances. Yes, several of these things are under consideration.

But now they are going the way that my specification entails - splitting the blockchain into multiple data types. Decoupling this from the overkill super database that makes searching the data fast, is going to be necessary, Graphene will need to be scalable to do really simple and small data sets. I think that as awesome as Graphene is, it is overkill for most parts of the blockchain (subchains) and simpler engines are needed for the simpler data types.

So I believe that building from this design base from scratch is necessary. The old model makes a lot of assumptions that don't hold when you modularise the system. I am sure that such a migration path is possible, but I also think that less time and energy allows a total re-working from the ground up.

Always chasing after the Lapis Philosophorum is l0k1... My apologies to my readers for the necessary drop in my publishing output. I have to brush up on my C and more fully learn to use GLib objects in C, just to start, as well as trying to assemble a readable and logical specification document.

---

We can't stop here! This is Whale country!

Written with StackEdit.