There is a somewhat short piece of Hive documentation that is up for feedback. This is the Technical Vision document. It should not be confused with a Roadmap.
The Technical Vision outlines the greater technical aims, goals and approaches.
This was drafted by me, then edited by 
The document includes realities (libraries, optimization work), his vision regarding layers, and points around decentralization.
The document is not suitable for inclusion in the whitepaper.
The document will be used as a one-sheet statement piece and potentially leveraged for marketing purposes. This is aimed at developers but can be paraphrased for non-technical readers.
https://github.com/gryter/general-docs/blob/master/technicalvision.md
Unlike the Whitepaper, it is not yet replicated on Gitlab. I've placed this and will place subsequent short documents that I initiate for the community in this repository. There is no deeper meaning between using this Github rather than Gitlab; it's purely for convenience.
Scalable | Modular | Accessible | Flexible | Decentralized
Optimized blockchain technology built to scale and adapt to shifting needs.
Diverse libraries maintained by a group of decentralized developers.
First and second layer of plugins that allow for functionality without adding bulk to the blockchain itself.
Backup provisions to ensure lossless and continued operation of critical infrastructure.
[1] Enterprise-level blockchain solution
Optimized blockchain technology built to scale and adapt to shifting needs.
Shows that Hive is able to support applications of any size and should be considered as a peer to Ethereum or Hyperledger.
- Identification and focus on new deliverables and commitments.
This used to read Moving away from pre-existing undelivered commitments designed by pre-fork teams. but was removed as per 
- Optimizing the existing processes, including testing, patching and gap identification.
As it sounds, simple process optimization.
- Building in security mechanisms to address potential DPoS-related vulnerabilities.
Spending time on proactively mitigate the stake-related functionalities and possibilities. This includes steps to reduce the potential of future hostile takeover possibilities, address things such as decaying witness votes, etc.
- Lowering the operating cost of nodes and baseline infrastructure to promote robust scaling.
The upcoming HF is a start to this; we will see much lower node requirements.
[2] Expansive roster of maintained libraries and development tools
Diverse libraries maintained by a group of decentralized developers.
Just as it sounds.
- Libraries managed by developers who have created them or have extensively modified them.
Same, just as it sounds. On Gitlab, developers have focused on the library of their choice, irrespective of whether they are its original creator or not.
- Developer commitment to select library or code base.
Speaks of the fact that the people who are contributing are not of the mindset to just abandon.
- Documented development tools supported with recipes and community resources.
This means that the quality and availability of documentation is a focus.
- Focus on ease of integration and ease of new development.
Just as it sounds.
[3] Layered solutions
First and second layer of plugins that allow for functionality without adding bulk to the blockchain itself.
You can read more about this in
- Modular plugins at first layer (blockchain-level) and second layer (applications layer)
Think Hivemind and similar.
- Blockchain layer operations streamlined to focus on governance and native token management.
'Native token management' is HIVE, HBD.
- Second layer solutions to support custom functions such as smart contracts, fungible and non-fungible tokens, and interactive social applications.
SMTs and similar would go here.
- Standardized microservices to support easy integration of new 2nd layer applications into the Hive ecosystem.
For example, 
[4] Decentralized redundancy
Backup provisions to ensure lossless and continued operation of critical infrastructure.
This section speaks of provisions placed in the case of a primary service or service operator becoming unavailable for any reason. For example, if the Hive.io website goes down. While it's not critical in terms of the blockchain functioning, it is a critical point of marketing and representation for Hive.
- Automatic failover in case of loss or compromise of primary key servers and nodes.
Just as it sounds.
- Geographically distributed servers and nodes to prevent critical infrastructure-based attacks.
Emphasis on decentralization. There have been historical cases where parts of a power grid have gone down for prolonged periods of time in virtually every country. Hosting in diverse locations and with different providers keeps Hive resilient.
- Full utilization of and emphasis on the promotion of Open Source developed and incorporated solutions.
Just as it sounds.
- Teams with overlapping skill-sets for high availability design and support.
Update: Previously "Multiple key holders for critical points." Very straight forward on this point, written by
I will be the first to admit that this point is poorly worded and could use a rewrite. This point speaks to the need for multiple people, either through failover provisions or through shared authority, to have access to or copies of the various elements of Hive infrastructure that are centralized by their nature.
Pull Requests or Issues please.
In the comments below. No offense will be taken to anything said.
