Yesterday 
Last year I was very excited to be working on my own project and my own token (Magitek). I made some good progress and learned a lot. Spent a couple hundred hours on it. The problem was I hit a major wall.
When I started the project I thought that decentralizing it wouldn't be that big of a deal. After all it relies on (second layer) derivative consensus, meaning that all of the data required is inside the Hive blocks, therefore I shouldn't have to worry about decentralization because the data in the Hive blocks is already decentralized.
So I was thinking even though I'd be the only one with a node to start, anyone would be able to boot up a node/frontend for Magitek. This would make it decentralized, or so I thought. But then I realized that even if someone boots up another node, if our nodes aren't connected and no one can roll back bad blocks, then it wouldn't matter. Two nodes would be two completely different networks, even if the data on those networks happened to be identical at any given time.
I started thinking about: what would happen if my node/data-stream got hacked or if my database got corrupted or whatever else. Even if other nodes were up and running they wouldn't be able to tell my node it was wrong, and thus I got a bit frustrated with the sheer complexity of moving forward with the project and quit.
Granted I could have been working on it this whole time and had a centralized version up and running. That would have been fine for the most part, but that's not what I wanted, so I did not pursue that outcome.
@blocktrades/a-developer-s-introduction-to-the-hive-application-framework
So when I heard about HAF technology being developed, I was thinking: "Isn't that like exactly what I need to decentralize Magitek? I'm not sure but I think so." After reading
In fact, I would go so far as to say that the HAF is perhaps the single greatest core technology that will perhaps ever be invented by Hive. The crazy thing is that it won't even require any kind of fork to implement. This is second-layer technology at its finest.
One of the most powerful features offered by HAF as a service to apps is that it enables apps to easily maintain consistent internal state when transactions are reverted by a blockchain fork.
In the case of a blockchain fork, the transactions for a post and all its votes could be reverted (either temporarily or even permanently). When this happens, the app has to undo all its internal state changes that occurred because of those reverted transactions. In other words, a normal blockchain app has to build an “undo” action for every internal state change it makes when it processes a new blockchain transaction, then apply all those undo actions in reverse order when a fork occurs.
The hive fork manager eliminates the need for such undo code.
In practice, this should cut in half the amount of code that is required to write a blockchain-based dapp and it also eliminates the chance for errors that can result if manually-written undo actions don’t get properly updated as the app’s functionality gets updated over time.
This technology will streamline dapp production in a modular way that not only cuts down on development time but also will greatly reduce the chance for bugs to proliferate. It's going to save a lot of time, but more importantly it's going to open up an entirely new level to scale up and maintain robust code.
I'm very impressed by this fundamental development. This is definitely making me want to boot my Magitek project back up and work on it like 12 hours a day like I was doing last year. HAF is exactly what Hive needs to scale up to levels that rival even the top blockchain projects. In fact, with technology like this, Hive can easily scale larger than Ethereum (albeit Ethereum will be more secure, but infinitely more expensive).
When we combine the feeless and non-competitive nature of Hive block production and then weave this modular second layer solution into the protocol, Hive gains a massive amount of power. It will also be very interesting to see what kind of work developers start to do with the HAF servers themselves. It very well may turn into a situation where developers can use a HAF server without actually haven't to set one up themselves. Thus, the HAF API may become just as important (if not moreso) as the Condenser API. Or perhaps I'm saying that wrong, as the HAF API may fully replace the Condenser API (not really sure if Condenser API will be a smaller subset of HAF itself).
In any case, development continues. This is really good news and it sounds like HAF is set to launch soon™. Once we have this tech launched in addition to RC pools this network is going to gain a ton of momentum. Now I just need to reach whale status before our token gets back up to all time highs.
