Media content is scattered across the web with few clear connections. Inspired by nature, The HIVE protocol is a decentralized platform that seeks to interrelate many of these lost dots. To archieve that ambitious goal, we utilized a toolbox of Bitcoin SV microtransactions, timestamping and storage to incentivize the creation of content node based knowledge networks.
In the following sections we outline the implementation details of Hive, and provide coding samples to start your own hive protocol based platform. The open HIVE protocol can both be used as relational content curation tool for news agencies and platforms, or used by 3rd parties to build machine learning based analysis and prediction models.
The HIVE protocol acts as a “beehive” to connecting information - where each individual adds connections and new information or other media. Each “hive” represents a topic object on the blockchain, that contains descriptive information about the creator, the topic, owner wallets and activity status. Adding the atomic elements of the HIVE protocol directly to the chain (other than hashes) ensures a trans-platform openes of data without 3rd party servers. Following the steps below introduces each component, formalizes and specifies the op_return data and lays out the foundations of the incentive model.
Figure 1: Definition of node layers in a hive networks. The graph indicates naming scheme starting at the L0 node (the active node), and its decreasing reward sharing to the L1-Ln nodes.
The Hive protocol incentive model ensures that content is always relational to other content or topics, and thus creating growing knowledge graphs. The growths of content is incentivized
by Bitcoin SV micro transactions, where not only the creator of the liked content is rewarded, but also his contextual environment.
Rewarding the contextual environment helps to critically
analyse popular content, even if the analysis itself is often less popular. As second side effect, it leads to the connection of contrary perspectives, even though supporters of the initial
node might be directly supporting the second node due to the indirect reward sharing (and thus preventing bubbles).
Figure 2: hyperparameter space of the variational rewards to the surrounding layers defined by R(x) = (x*(1400 - n*400))^z+b. In the graph, the Layers are marked (see figure 1) to visualize their relative reward.
Here we show in the simplified graph how the cost per like/node creation wise with the cost coefficient "x" and the number of connected nodes "a": c(x,a) = sum(n = 0...n) x*a^n*(1400 - n*400). While the parameters in the formula are independend, there is a direct influence of cost "x" on the interaction and creation "a". In the following we have to identify the optimal parameter set between the spam protective incentive model and the user interaction cost is. An advantage of the here presented reward sharing model is the disincentive to further add content to populated dense node clusters and instead incentivizes the branching out in more specified clusters.
Figure 2: User like and node creation cost simulated depending on the population density of nodes. Since high density clusters have increased cost, users will try to branch to other nodes. With low node density, the cost is close to 0 (thus incentivizing interaction and content creation) and polynomially increases at higher node cluster densities.
Layer | Attribute | Type | Description |
---|---|---|---|
s0 | "HIVE | string | Blockchain Protocol identifier |
s1 | "hive" | string | Hive Protocol type identifier |
s2 | title | string | Title of the hive |
s3 | description | string | Description of the hive |
s4 | image url | string | A https link or bitcoin destination to the hive preview image |
s5 | hive ID | string | A unique identifier (uid) of the hive |
s6 | creator uid | string | The unique user identifier (uid) of the user that created that hive. The key must to be persistent, but allowed to be deterministic |
s7 | hdPubKey | string | A BSV HD public key of the creator of the hive. |
s8 | topic | string | The free of choice topic category of the hive |
Layer | Attribute | Type | Description |
---|---|---|---|
s0 | "HIVE" | string | Blockchain Protocol identifier |
s1 | "node" | string | Hive Protocol type identifier |
s2 | title | string | Title of the node |
s3 | description | string | Description of the node |
s4 | image url | string | A https or bitcoin destination to the node preview image |
s4 | node url | string | A https link or bitcoin destination to the content of the node |
s5 | node id | string | A unique identifier (uid) of the node |
s5 | hive id | string | The unique hive id the node is attached to |
s6 | creator uid | string | The unique user identifier (uid) of the user that created that hive. The key must to be persistent, but allowed to be deterministic |
s7 | hdPubKey | string | A BSV HD public key of the creator of the hive. |
Layer | Attribute | Type | Description |
---|---|---|---|
s0 | "HIVE" | string | Blockchain Protocol identifier |
s1 | "like" | string | Hive Protocol type identifier |
s2 | node id | string | A unique node id |
s3 | hive id | string | The unique hive id the node is attached to |
s4 | creator uid | string | The unique user identifier (uid) of the user that created that like. The key must to be persistent, but allowed to be deterministic |
s5 | hdPubKey | string | A BSV HD public key of the creator of the pulse. |
Layer | Attribute | Type | Description |
---|---|---|---|
s0 | "HIVE" | string | Blockchain Protocol identifier |
s1 | "pulse" | string | Hive Protocol type identifier |
s2 | node id | string | A unique node id |
s3 | hive id | string | The unique hive id the node is attached to |
s4 | creator uid | string | The unique user identifier (uid) of the user that created that pulse. The key must to be persistent, but allowed to be deterministic |
s5 | hdPubKey | string | A BSV HD public key of the creator of the pulse. |
s6 | pulse counter | integer | A counter indicating the current number of pulses released from that same pulse. [starts at 1] |
s7 | total pulses | integer | The total amount of pulses released in that pulse [starts at 1] |
At the core of the hive protocol is the incentive model and its reward distribution. As shown in the Javascript + ES6 example below, the connected nodes can be crawled by mapping and pushing connected link elements (as indicated in the specifications). Platforms that enforce the incentive system best will gain a competitive advantage as their networks grow fastest, as quality and creation is over-proportionaly rewarded.
After creation the tx array, the hive node or like can be pushed to the chain via a library of choice. For scalable applications, the TXOs need to be manually handled and can either be done by one of the many BSV node API providers (whatsonchain, blockchair, nownodes) or via own listener node. Raspora.com uses filepay to generate the tx bundle and pushes it directly via the miner API to a miner of choice.
In our example, we choose the axios npm library due to broader browser support compared to the browser internal 'fetch' method and more detailled error handling and timeout functionalities.
I would like to hereby thank members of the Cambridge Metanet Society for countless incentive model discussions, the Bitcoin Association for their repeated support and the members of the Raspora dev team for transforming the abstract concept protocol concept into a real world platform