Interesting, with each report I learn something about the architecture of HIVE. For the HF25, better to take time to have something well tested, we need it to be robust to avoid any long downtime during the release (there are many more users now than at HF24). I know that these are banalities and you already don't care about the pressure of a few about a fast release but I wanted to remind it.
Do you plan to update the HIVE white paper after HF25 so that it no longer correlates with the STEEM white paper given the major differences?
Do you plan to create a graphical representation of the full architecture with the different layers to better understand how HIVE works? I think this would be useful for a better understanding and to avoid design errors when developing an application around HIVE, I'm thinking in particular of the different API calls coming from the different layers, some of which are very similar in the result and knowing which one is the most relevant for our use case is not obvious.
We'll definitely be updating architecture-level documentation in the future.
We'll also be creating docs for how to implement Hive apps using modular hivemind technology once it is near to deployment. Modular hivemind allows for a faster and much more streamlined form of Hive app, but the design of such apps will be quite different in terms of API usage than current Hive apps. This is because with a modular hivemind-based app, the app designer will be able to create custom APIs to suit their needs as well as being able to incorporate sets of modularized, standardized API functionality.
!PIZZA
$PIZZA@mintrawa! I sent you a slice of on behalf of @darkflame.
Learn more about $PIZZA Token at hive.pizza