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: https://hive.blog/hive/@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.
Well, we all yelled for a couple of years there "Steemit is not Steem".
Meaning either the company Steemit Inc. or the website, steemit . com , which ever of the two was applicable to the context of the conversation.
Time to understand what it was that everyone kept saying and yelling!
Note: Replying to the general topic of "Vision".
Turned out that Steemit was Steem as they held the trademark.
This is largely backend and aspects to be used to facilitate frontend development.
Yeah, turned out that way.
But that wasn't the point of the comment. Thinking out of the box, the box that we maliciously got put into by some bad actors in the Steem days.
We are not limited to any one niche, we are not limited to any one line of business, we are not limited to any one identity deciding on the future of people with dreams and real ideas.
It is a FREE & OPEN market.
Open to one and all.
We can all finally start putting things in their place:
Data storage.
Finances (economy).
Blochchain development.
All are interlocked, yet all are individual branches of business and our ecosystem.
We can't let one stop the other two, no matter which of the three we are talking about.
Hence, why I reminded everyone about the old saying "steemit .com is not Steem"!
Nice Post!!
Thanks.
I appreciate your work on Technology development of our Hive
Thank you, but its a massive group effort.
Alrighty. Been clamoring for this left and right.
Thats the first step. Second step is to condense it into a easily spread message and broadcast it.
I feel this is a very important point that needs to be expanded on. If you feel this document is not the place for it, id like to see a more comprehensive breakdown and comparison to industry standards and why this solution is superior.
Im not talking a post or a github document but rather places like Hive.io or hiveonboarding.
Im personally not happy with the lack of mention of SMTs. I feel theyre an essential tool to achieve this vision and should get a line of their own in there.
Sidenote:
The thing devs need to understand is that PRICE is a huge factor when it comes to survival of a project. In the simplest of ways put:
"If you dont built that which directly creates demand in economic terms for the token (especially a inflationary one) but focus mostly on creating convenience there wont be monies for you to get payed."
It wont matter how convenient it is to build a dapp on HIVE if the price is 0.
Every system needs to create a incentive to buy HIVE. Otherwise, in that sense, what can happen is that a system can be "useful" and "worthless" at the same time.
All of the documents that then can go to Hive.io or any other website or info point need a start, so I'm aiming to start them off in the Github. They can then be taken and incorporated into marketing, into websites, into whatever the community sees fit. I'm thinking the Tech Vision can go as infographics.
This is an excellent idea. It will have to wait until the whitepaper is finalized.
Regarding SMTs, we may very well see an expansion of this concept. They're not thee focal point because we do have more to offer than tokens, but they're a key point. At the same time, we don't want to go around yelling SMTs like the pre-fork teams did because that's not the one deliverable. Optimization and comprehensive libraries, for example, make the chain far more attractive to build on than any SMT ever will. This goes towards your mention of price. If the cost of development is reduced due to a reduction of complexity, the price naturally becomes less of a factor.
Yes... Again i want to emphasize that the top couple stakeholders need to push that forth. Nothing happens simply because its a good idea.
Awesome. The thing about SMTs is that they were a acknowledged and relatively understood concept by most of the community. It wasnt because Steemit.inc did a good job at relaying the message, but rather out of community despair and a need to search for a "savior". SMTs were just that. People understood that concept because they needed to hang on to a hope, something that would change everything for the better.
Steem before the end was a desperate time, something everyone was so fast to forget.
Thats why i implore you guys to expand on that topic and realize it in the same sense it was realized by the community in the time during the Steemit episode.
We havent managed to shed the Steem legacy just yet.
The rest i wont comment on. We wont agree, but i really dont want to steer the convo in that direction because it wont lead to anything concrete and i dont want that because "concrete" is what we need now.
I saw what you said on Twitter to that regard. It's getting pushed out, just not as quickly as it would be if it was a corporate entity pushing it. Once this document here is finalized, we need to still pretty it up and only then can stakeholders or whomever has pull elsewhere put it out.
I agree on the SMTs and on the previous state of Steem. It's getting done and it will be done. @blocktrades is the best person to speak on these further, but he did put most of his ideas on paper in that post I linked in the main post above. Right now we're at the part where optimization and basic controls must be put in place and then we can innovate. Kind of how when you buy a house you got to get the subfloor fixed and only then you can start installing the granite countertop.
This sounds a bit odd to me. I guess the idea is to express that the structure in which the developers operate is decentralized, not the developers themselves. I would therefore rephrase in the direction of:
Diverse libraries maintained by a decentralized network (OR group OR community) of developers.
Thanks for working on this!
I see what you're saying, duly noted, changed the Github version.
will the other whitepaper be added to hive.io ?
Once its done, it will be.
Thanks for dealing with all this stuff!
Congratulations @guiltyparties! You have completed the following achievement on the Hive blockchain and have been rewarded with new badge(s) :
You can view your badges on your board And compare to others on the Ranking
If you no longer want to receive notifications, reply to this comment with the word
STOPDo not miss the last post from @hivebuzz: