What would you like to search for?

Weekly Updates|16 MIN. READ

Hive 2.0: An Introduction

  • SHARE

With development accelerating on all fronts, The Elastos Foundation is excited to get readers up to speed on yet another rapidly developing component of the Elastos tech stack: Elastos Hive 2.0. Together with Elastos’ DID solution and Elastos Carrier, Elastos Hive makes up the platform service layer in the Elastos Smartweb, and provides users with a series of decentralized storage solutions via elastOS. In this article, we introduce Hive’s upcoming release, Hive 2.0, and cover its functionality, advantages, and new features in depth. 

Hive 2.0: An Introduction

Hive 2.0 is Elastos’ decentralized storage solution. In the new architecture native to Hive, the Elastos blockchain is left out of the equation entirely, and data is stored on traditional servers called “Hive nodes” and accessed using traditional API calls. However, Hive’s key feature lies in the  provision of its servers; Hive servers act as independent services that are provided by third parties or end users themselves – not application developers. Hive also enables users to transfer data to another location or storage space at any time.

Practical Use

Technology and specifications aside, here is what interacting with Hive 2.0 will look like for the average user:

After creating a unique, decentralized identity (DID) in a DID wallet such as the elastOS Identity Capsule or Elamask, once it becomes available, users will select a Hive node that acts as their initial “Vault provider.” The term “Vault” describes the sandboxed storage space designated to a particular user on a given Vault provider – that is, a Hive node.

Inside elastOS, the Hive Manager Capsule enables users to get started quickly by providing public addresses for 2 default Hive nodes: “Trinity Tech Hive 1” and “Trinity Tech Hive 2.” Users can easily select a default address for convenience, or select a custom Vault provider of their choice. For now, Hive 2.0 remains under active development, and is presently in alpha version; thus, only two Trinity Tech Hive nodes have been deployed. However, anyone is free to deploy a Hive node, and users can add such nodes to their elastOS profiles. Trinity Tech is currently providing its 2 default nodes for demo purposes, and to allow users to get started quickly and without complication. In the future, Trinity Tech’s default nodes may or may not remain available, pending the discretion of the Elastos community.

Once a user has selected a Hive node, the Hive node’s information is saved to the public DID profile of the user, and is recorded on the DID Sidechain. Via this mechanism, other users can find this original user’s Vault location. For example, if user A posts a message on his Vault, the message will be stored on his chosen vault provider –  say Trinity Tech Hive 1, for instance. If user B wants to read user A’s message, user B must first retrieve user A’s DID from the DID Sidechain, where he discovers that user A uses Trinity Tech Hive 1 as a Vault provider. From here, user B can query user A’s Vault to access his messages.

Vault Transfer

As outlined above, Hive 2.0’s primary feature is the flexibility it provides users in enabling them to determine where to store their data – a decision that was previously delegated to application developers. As an added benefit, all Hive nodes use the same service software, which is and will always remain open source.

Consequently, once users have chosen an initial Vault provider, they are free to transfer their data to another Vault provider at any time. Such transfers are made possible by Hive 2.0’s “Vault Transfer” feature.

There are a number of reasons for which users may want to transfer personal data to different Vault providers, including:

  • Finding another commercial Vault provider that they deem more trustworthy.
  • Finding another commercial Vault that provides superior packaging, support, speed, or price.
  • Deciding to initiate and run a personal Hive node over Carrier to take full control over their data.
  • Experiencing interrupted or unreliable service from a previously selected Vault provider.


Hive 2.0’s Main Features and Capabilities

Authentication:

  • DID Access: All Hive Vaults are accessed exclusively through DIDs. Elastos’ DID solution and Hive 2.0 act as a compatible and efficient pair of technologies.


Storage Features:

  • File Storage: Traditional file storage.
  • Database: Mongo-backed database queries.
  • Key Values Store: A convenient way to store data objects using a simple key as a reference.
  • Pub/Sub: Get notified of data changes instantly while online, without having to manually fetch data.


Additional Features:

  • Payment Module to incentivize Vault providers to run Hive nodes.
  • Vault Backup and Vault Transfer functions.
  • Data Encryption.
  • Access Control allows a data-owning user to select other users that can read or contribute to his or her data, and specify conditions for which reading and contribution are allowed and disallowed.


The Present and Future of Hive 2.0

At present, Hive 2.0 offers users the following features:

  • File Storage
  • Database
  • Access Control
  • Payments

Trinity Tech plans to have the following features available to users in Hive 2.0’s next releases:

  • Vault Backup and Transfer
  • Key values
  • Pub/Sub
  • Data Encryption


Eliminating Reliance on the Blockchain

As has become common knowledge throughout the digital asset space, the utility of blockchain technology is and should be limited. Blockchains are notoriously inefficient, and are to be used only for cases where they provide, secure, and contribute to: 

  • Immutability
  • Proof of Ownership


As such, blockchains are not to be used for operations such as storing massive volumes of application data on a daily basis. For these purposes – namely, those relevant to the operations of Elastos Hive, blockchains are inefficient, and will not serve the Elastos ecosystem nor its users.

Providing Support for Elastos Carrier

In addition to offering users a host of proprietary benefits, Hive 2.0 acts to support Elastos Carrier as well. Here’s how:

While Elastos Carrier is an excellent decentralized communication protocol, just like any other technology, it has a few drawbacks as well:

  • Carrier employs a “slow handshake”, and needs a few seconds to find peers, and to determine if peers are on- or offline.
  • Carrier can only support purely centralized offline storage, or offer none at all. 
  • Supporting Groups can be quite cumbersome for the Carrier protocol.

Now, here’s what Hive 2.0 adds to the equation: applications can use Hive as a source of primary storage, so a significant volume of data no longer needs to flow over to Carrier. In addition, Hive nodes never go offline, so users can rest assured their data is being stored securely. Thus, with Hive playing its role as a decentralized storage service, Carrier can dedicate all of its computational resources to what it does best: enabling decentralized, instant communication.

For example, in the case of the community-built Hyper IM, Hive 2.0 and Carrier working in conjunction ensure that messages and friend invitations are not lost in the event that one user spontaneously goes offline.

In a traditional chat architecture, a user sending a message results in the following actions:

  • An API call stores the message on the centralized server database.
  • A Websocket passes the message to online users, without requiring those users to manually fetch the data from the database – a  slow and resource-intensive process.


With Hive 2.0 and Carrier, the same process flow is executed on Elastos as follows:

  • A Hive 2.0 call stores the message on the chosen user’s Vault.
  • Carrier passes the message to online users.


Hive 2.0’s Major Advantage Over Traditional Models

The bottom line is that with Hive 2.0, users determine where their data is stored – not application developers. In this way, Hive 2.0 opens the door to a vast domain of reimagined application architectures.

In traditional models, all user accounts and user data are stored on the application developer’s dedicated server, and users can control only what the application developers permit them to control.

In Elastos’ model, users control their identity via a DID stored on their local device and data storage location via their Vault provider of choice.

Once dApps begin using DIDs, Carrier, and Hive together – most immediately, Hyper IM – the Elastos Foundation, Elastos community, and rising partners will take on the task of refining and improving innovative economic models that integrate and support the innovative technical architecture conceived by Hive 2.0. When user data is being directed to and stored in particular Vaults via Hive 2.0, and users determine exactly which elements of their respective profiles they choose to share with dApps via DID credentials, brand new, data-oriented economic models will enter the frame. As merely one example, smart contracts could be used to automatically distribute tokens to various users based on any number of metrics. A Feeds publisher, for instance, may receive a calculated denomination, as may a service provider, content creator, and any other contributors in a value creation chain.

Of course, the big question is where the wealth would be sourced from. One potential model might involve users sharing personal app usage data and personal profile data to interested third parties, such as data aggregators and advertisers. Another potential model could leverage automated smart contracts to allow users to choose how to pay for the content they consume. For example, users could decide to either pay for a Hive Vault subscription or receive a discount by sharing data with third parties, who would realize the discount by contributing to the Hive Vault subscription fee.


Preventing User Exploitation Through Hive Node Software Customization

With any new economic model, It is always important to consider how actors may attempt to consolidate power and resources for their benefit. For Hive 2.0, it is not inconceivable that Hive node operators may consider implementing customizable, ad-hoc features that cause their nodes to become incompatible with other existing nodes in the network. In such a circumstance, users would be unable to transfer their data to other Vault providers. Trinity Tech will be giving this matter further attention going forward, although a number of preventative solutions have already been discussed:

  • elastOS or other Hive wallets can embed an auto-testing service with the Hive Manager Capsule to ensure that Vault providers are compatible with a given standard.
  • Naturally, as the number of Hive Vault providers increases, Hive’s user base will be distributed across many providers. In this scenario, application developers will be naturally incentivized to ensure that when users access various features of their applications, no issues arise concerning their Vault provider of choice. Therefore, developers may pressure Vault providers to remain fully compatible.
  • The community will always be very welcome to contribute to improving Hive standards. Such contributions will have to be submitted through community talks and pull requests to the Hive GitHub repositories in order to confirm that future improvements benefit the ecosystem at large.
  • Additional services developed for Vault providers will also be welcome, so as long as they do not diminish compatibility with other nodes. One such example is statistics services. 


The Transition: Advancing from Hive 1.0 to Hive 2.0

Simply put, Hive 2.0 supports the pragmatic, real-world adoption of Elastos applications. Hive 1.0 was mostly oriented around IPFS, and IPFS has many shortcomings:

  • First, IPFS is often considered to be decentralized in the sense that – like a blockchain – no data is lost. This is entirely untrue; IPFS uses traditional servers – or a personal computer – to store data initially. Then, the data replication can take place under the condition that other users request data. And even then, the data replication to other IPFS nodes is mostly temporary, meaning that data resilience is not ensured, such as in the event that a user’s computer is destroyed.
  • IPFS is also a public ledger. Even if a user encrypts his or her data, there is no easy, built-in access control to share that data with one user or a group of users, which makes application development complex and cumbersome. Hive 2.0 allows for refined customization of access rights based on DIDs.
  • With IPFS, files cannot be modified; in fact, modifications create new files on IPFS. Each file modification creates a new file ID, thereby creating new challenges for applications that need to keep references for those files in order to function properly.
  • Last but not least, IPFS only stores files – not databases, which are required by most applications.


Hive 2.0 in elastOS

As the foremost home of the Elastos ecosystem, elastOS constitutes part of Elastos’ application layer. As an application, elastOS was not able to leverage a lot of Hive 1.0’s features, and a large part of its potential remained dormant. In short, the majority of elastOS’ use cases could not be implemented with Hive 1.0.

With Hive 2.0 in place, an enormous amount of previously untapped potential can finally be unleashed and explored, thanks to Hive 2.0’s improved performance, database management, and access control support. Hive 2.0 integrates with DID effectively, which opens up a host of functions compatible with elastOS’ DID sessions and sign-in model.

Already, Hive 2.0 is being used a great deal in elastOS. Here are just a few examples:

  • Users can (or will soon be able to) fully back up installed applications and favorites, contact lists, wallet synchronization states, and DID credentials with a Hive Vault. Users may also use their Hive Vaults to restore data when they reinstall elastOS reinstall on their devices. In addition, a single user (identified by a single  DID) may run elastOS on 2 different devices and sync any changes in real-time, thanks to Hive.
  • The Hive Manager Capsule allows users to select Vault providers, pay for a storage plan if needed, and soon, backup and transfer their data.
  • The Trinity Hive plugin is ready to support 100% of Hive node operations, and dApps may already use it.
  • Hyper IM will become the first application to take full advantage of Elastos technologies, leveraging DID, Hive, and Carrier services.


Get Started with Hive 2.0: For Developers

Developers looking to get started with Hive 2.0 can choose from two different points of access:

  • elastOS:
    • Full development environment ready with DID plugin, Hive plugin, DID Capsule, Hive Manager Capsule, authentication helper, backup and restore helpers, and on-boarding for end users.
    • Hive Demo Capsule acts as a starting point for source code.
    • Support through the elastOS Telegram Channel
  • Native Applications (Android, iOS, Linux, Windows, Mac):
    • The DID SDK is already available.
    • The Hive SDK and Hive node service are available on GitHub, but are not yet distributed as packages.
    • More manual work is yet to be done, and the development environment is less advanced relative to that of elastOS.
    • Trinity Tech team members can be contacted directly on the Elastos Developers Telegram Channel to field questions.

 

  • SHARE

Next Posts

Weekly Updates|6 MIN. READ

Elastos Bi-Weekly Update – 18 December 2020

Weekly Updates|8 MIN. READ

Elastos Bi-Weekly Update – 04 December 2020

Team Updates|2 MIN. READ

A New Internet For A New Era: An Elastos Overview

00:00 / 0:00:00