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 @blocktrades (you may see the exact changes by examining the Github linked below). Why did I write the first draft? Because someone had to do it and I found the time to start the process. There is no secret meaning to it.

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.

Intent

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.

Read Source

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.

Read Text: 'Technical Vision'

Scalable | Modular | Accessible | Flexible | Decentralized

[1] Enterprise-level blockchain solution

Optimized blockchain technology built to scale and adapt to shifting needs.

• Identification and focus on new deliverables and commitments.
• Optimizing the existing processes, including testing, patching and gap identification.
• Building in security mechanisms to address potential DPoS-related vulnerabilities.
• Lowering the operating cost of nodes and baseline infrastructure to promote robust scaling.

[2] Expansive roster of maintained libraries and development tools

Diverse libraries maintained by a group of decentralized developers.

• Libraries managed by developers who have created them or have extensively modified them.
• Developer commitment to select library or code base.
• Documented development tools supported with recipes and community resources.
• Focus on ease of integration and ease of new development.

[3] Layered solutions

First and second layer of plugins that allow for functionality without adding bulk to the blockchain itself.

• Modular plugins at first layer (blockchain-level) and second layer (applications layer)
• Blockchain layer operations streamlined to focus on governance and native token management.
• Second layer solutions to support custom functions such as smart contracts, fungible and non-fungible tokens, and interactive social applications.
• Standardized microservices to support easy integration of new 2nd layer applications into the Hive ecosystem.

[4] Decentralized redundancy

Backup provisions to ensure lossless and continued operation of critical infrastructure.

• Automatic failover in case of loss or compromise of primary key servers and nodes.
• Geographically distributed servers and nodes to prevent critical infrastructure-based attacks.
• Full utilization of and emphasis on the promotion of Open Source developed and incorporated solutions.
• Teams with overlapping skill-sets for high availability design and support.

Breakdown and Explanation

[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 @howo's suggestion. It was replaced as above to show a positive innovation. Originally, it spoke to the fact that we are not married to anything that Steemit Inc had planned or intended.

• 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 @blocktrades' post: @blocktrades/hive-s-future-as-a-2nd-layer-blockchain-network It basically means that solutions may be placed on layers without altering the core blockchain code and requiring HFs.

• 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, @arcange's HiveSQL is one such microservice.

[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 @blocktrades, just as it sounds.

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.

Alterations

Pull Requests or Issues please.

General Feedback

In the comments below. No offense will be taken to anything said.