The idea is you could take this document and feed it to an ai agent and it would understand a ton about Hive. I'm not done with this project but wanted to share where i was at and see what people think. (of the idea and what would be next)

WORKING WITH AI AS A DEV

I have been thinking of working on some Hive Projects myself independent of PeakD.com at least to play and gain some dev skills in this new world of developer ai tools.

WORKING WITH AI AS A BRAINSTORMING PARTNER

Also sometimes i brainstorm PeakD, Peak.open features with ChatGPT and I can't just depend that the model has been trained perfectly.

TRAIN YOUR ASSISTANT

One of the best methods for working with a ChatGPT or any LLM is to first be responsible for the data it is working with. Train it yourself. But where is the most thorough information... and not just thorough but concise so it doesn't overwhelm the context limits of the LLM model?

So I am taking on this project myself... Here is what i have so far.

Condensed Hive Blockchain Resource for AI Agents and Developers

Introduction

Welcome to the Condensed Hive Blockchain Resource, a comprehensive and self-contained manual designed specifically for AI agents and developers aiming to build applications on the Hive blockchain. This document provides detailed, actionable information to help you fully understand and utilize Hive's functionalities without relying on external resources.

1. Hive Blockchain Overview

The Hive blockchain is a decentralized platform that facilitates the creation and management of decentralized applications (dApps). Built on a robust and scalable architecture, Hive offers various functionalities essential for developers and AI agents to interact seamlessly with the blockchain.

2. How Transactions Get into the Blockchain #CoreFunctions #keyKnowledge

When a user initiates an action on the Hive blockchain, such as posting content, voting, or transferring tokens, this action is bundled into a transaction. The transaction process on Hive works as follows:

1. Transaction Creation: When a user, usually via an application (like PeakD.com), prepares an action for their user, the details are bundled into a transaction object. This object includes information like the sender, recipient, type of action, and importantly a digital signature to prove authority. What is a signature?
2. Broadcasting the Transaction: The transaction is then signed (this is done by various methods, wallets as described later) After signing, the transaction is broadcast to the Hive network. Broadcasting is typically done by a node connected to the blockchain, which listens for and propagates new transactions.
3. Witness Nodes and Block Production: Witness nodes, which are responsible for maintaining the blockchain, pick up the broadcast transaction. They gather the transactions into blocks and append them to the blockchain. Sidenote: Witnesses are elected participants in Hive's Delegated Proof of Stake (DPoS) consensus mechanism.
4. Consensus and Block Inclusion: A block containing the transaction is produced roughly every 3 seconds by one of the active witnesses. The consensus mechanism ensures that only valid transactions (i.e., properly signed and adhering to blockchain rules) are included in the blockchain. Once the block is produced, it is distributed to all other nodes, becoming part of the permanent blockchain ledger.
5. Confirmation: After the transaction is included in a block, it is considered confirmed. This means the action—whether it’s a post, a vote, or a token transfer—has been officially recorded and is immutable. The Hive blockchain uses the distributed consensus to ensure the validity and permanence of all transactions.

KEY NOTES ON INFO ADDED TO CHAIN

• A block is added to Hive Blockchain every 3 seconds.
• Once a transaction is broadcast to the network, a witness validates it by ensuring the transaction follows the protocol rules (e.g., valid signatures, sufficient funds).
• Hive Blockchain has 1 block finality meaning it reaches consensus and transactions are final in 3 seconds and can not be reverted.

RESOURCE CREDITS

• There is no token cost or gas cost for adding information to blockchain (transactions) hive uses a unique feature called resource credit cost. Resource credits are regenerative per account. They are assigned to an account based on amount of that account’s staked hive.
• You do not pay extra resource credits to get information into the blockchain faster there is a set cost by the blockchain for each type of transaction based on the technical impact that type of transaction has long term on the blockchain. (A content vote has a low RC cost and a Post has a high RC cost)
• The more Resource Credits the more transactions the account could do.
• They can also be delegated to other users. This means an application can delegate to their users to help them do all the transactions they want to do.

3. Hive Nodes #blockchainInfrastructure

Applications interfacing with the Hive blockchain require a connection to a Hive node. A Hive node is essentially a server that runs the blockchain software, and it provides the necessary API endpoints and communication channels for developers and applications to send and receive data from the Hive blockchain, such as reading blockchain data, broadcasting transactions, and managing dApp functionalities. Nodes play a critical role in maintaining the network's integrity, validating transactions, and ensuring that the blockchain remains decentralized.

There are two main types of nodes that developers can use: public nodes and private nodes.

3.1 Public Nodes #blockchainInfrastructure

Public nodes are nodes that are made available to the general public by individuals or organizations who run them for the benefit of the Hive community. These nodes are essential for developers who do not wish to maintain their own infrastructure but still need reliable access to the blockchain. By connecting to a public node, developers can read data from the blockchain, broadcast transactions, and access various Hive services (e.g., posting content, voting, retrieving account details).

Public nodes are usually accessible via HTTPS, and they allow developers to interact with the Hive blockchain without worrying about managing the complexities of maintaining a node themselves. However, it is important to note that some public nodes can sometimes be down or have varying performance. The availability and responsiveness of a public node may depend on factors such as server load, geographic location, and maintenance schedules. Developers may experience slower response times if they are geographically distant from the node they are trying to connect to or if the node is experiencing high traffic. Because of all these factors it is important and wonderful to have a lot of highly capable server nodes available to provide options and decentralization. There are even tools like beacon.peakd.com to assist with what nodes are operating well and what functions each node provides.

Public nodes are an excellent starting point for developers, but they do come with limitations, especially if you require consistent, high-performance access to the blockchain. In such cases, running your own private node might be more suitable.

3.2 Private Nodes #blockchainInfrastructure

A private node is a dedicated server that runs the Hive blockchain software exclusively for your use.  Running a private node offers greater control and customization, such as the ability to configure custom API endpoints, ensure higher reliability, optimize performance for specific use cases, and handle increased transaction throughput without relying on public infrastructure. This can be particularly beneficial for projects that need guaranteed uptime, low latency, or specific customization that is not available through public nodes.

3.3 Node Setup

If you are considering a private node or creating a public node you should have an idea of how they are setup also as this will help you understand the impact of your project on public nodes.

Recommendation: The recommended approach for setting up a private node is to deploy a pre-built Docker container. Below are the steps and requirements for setting up a private node.

#Curiosity

Understanding the type of server setup required for running a Hive node helps developers grasp the underlying infrastructure that supports Hive's blockchain technology.

Typically, a Hive node involves:

• Operating System: Hive nodes generally run on a stable Linux-based OS, such as Ubuntu
• Memory: Nodes need a minimum of 32GB of RAM, though 64GB is often recommended for better synchronization speed and overall performance, especially under heavier transaction loads.
• Storage: Storage requirements are significant, highlighting different components involved in the Hive ecosystem and many of these technologies will be explained in this document.
  • Hive Block Log & Shared Memory (500GB): This stores the entire history of the blockchain, maintaining critical state data necessary for the functioning of Hive.
  • Base HAF Database (3.5TB pre-compression): Supports the Hive Application Framework (HAF), which is essential for scalable application development on Hive.
  • Hivemind Database (0.65TB pre-compression): Contains data for social and user interactions, powering key features of Hive's social layer.
  • Compressed Storage (2.14TB): Utilizing advanced compression reduces the total storage needed, optimizing space while retaining full blockchain functionality.
  • HAF Block Explorer (0.2TB): Provides quick access to explore blockchain data, contributing to better insights and analysis for developers.

These specifications are indicative of the types of demands placed on servers operating as Hive nodes. The high requirements are necessary to ensure nodes can provide reliable, consistent access to blockchain data, handle the network's load, and support the variety of applications and interactions that make Hive a vibrant decentralized ecosystem.

3.4 Running a Hive Node with Docker #blockchainInfrastructure

Running a Hive node with Docker is an option that simplifies deployment by packaging all the necessary components (e.g., blockchain software, dependencies like specific libraries, networking settings, and environment variables) into a containerized environment. This approach is particularly beneficial for developers who want to quickly set up a node without manually installing and configuring each element (e.g., dependencies, networking settings, environment variables). Docker containers provide a consistent environment, making it easier to maintain and replicate nodes across different systems (e.g., deploying on cloud servers like AWS, running locally on development machines, or setting up in on-premise data centers).

Using Docker allows for easier management of dependencies, scalability, and isolation from other processes running on the server. It is a popular choice because it reduces setup complexity and ensures that the node environment remains consistent, which is crucial for both development and production. By using Docker, developers can take advantage of pre-built images and scripts to get a Hive node running efficiently, reducing the time required for configuration and setup.

ZFS is recommended for its compression and snapshot features, which help optimize storage efficiency and provide a robust backup mechanism. The setup involves configuring ZFS to use advanced compression, allowing significant data size reduction without compromising performance, and utilizing snapshots for easy rollback and data recovery in case of issues. These features make ZFS particularly useful for managing the large volumes of blockchain data involved in running a Hive node, ensuring both stability and space optimization.

4. Syncing the Blockchain #blockchainInfrastructure #devtools

Synchronizing your node with the Hive blockchain can be achieved through various methods to optimize speed and efficiency.

4.1 Initializing from a Snapshot

Using a snapshot can significantly reduce synchronization time by providing a pre-synced version of the blockchain state, allowing the node to start from an advanced point instead of downloading and verifying every block from the beginning.

Download Snapshot:

wget -c

4.2 Replay with Blocklog

A trusted block_log file can expedite the syncing process by providing an external log of verified blockchain blocks. This allows the node to use the pre-recorded data, effectively skipping the process of downloading blocks from peers and verifying them individually, which significantly speeds up synchronization.

5. Hive Testnet #blockchainInfrastructure #devTool

The Hive Testnet allows developers to test applications without impacting the mainnet. It provides a sandbox environment where developers can safely experiment with new features, identify and fix bugs, and test upgrades or changes before they go live. This also allows Hive to make upgrades to the blockchain software more smoothly, as new implementations can be thoroughly vetted for stability and compatibility in a controlled environment.

5.1 Public Testnet

The public testnet is maintained for rapid application testing.

• Chain ID: 18dcf0a285365fc58b71f18b3d3fec954aa0c141c44e4e5cb4cf777b9eab274e
• P2P Endpoint: testnet.openhive.network:2001
• API Endpoint: https://testnet.openhive.network
• Condenser: Accessible via testblog.openhive.network
• Wallet: Accessible via testwallet.openhive.network

Note: Use your mainnet account and keys cautiously on the testnet to prevent compromising your mainnet account.

5.2 Running a Private Testnet Node

To run a private testnet node using Docker:

docker run -d -p 8090:8090 inertia/tintoy:latest

6. Accounts #CoreFunction

On the Hive blockchain, an account is not merely a username—it is the core entity through which all interactions people or apps can have with the blockchain. All user decided operations, from posting content to transferring tokens, must be initiated by an account.

Accounts are created by other accounts, there is a limited cost and there are naming rules for accounts including limit of 16 characters. Also no two accounts can be named the same.

Accounts on Hive are defined by their permissions and control over specific blockchain actions through a combination of keys and authorities. A role of an account is to act as a custodian of resources (e.g., Hive tokens, content, voting decisions) and to manage access to those resources through cryptographic mechanisms.

7. Keys and Authorities: Foundation of Account Operations #CoreFunction

At the heart of account functionality on Hive are keys and authorities. Both define what an account can do, but they operate on different levels.

7.1 Keys: Access and Ownership

Keys in the Hive blockchain are cryptographic tools that provide proof of ownership and the ability to execute transactions. Each Hive account is usually associated with four distinct types of cryptographic keys, each designed to manage different levels of access. The private key is what grants authority to act on the blockchain, and the public key serves as the identifier that proves who controls the private key without revealing it.

• Owner Key: This is the most critical key, representing ultimate control over the account. It is rarely used in everyday interactions and is mainly employed for changing other keys or recovering a compromised account. TIP: While all keys should be safely stored The Owner key most of all should be stored securely and offline to prevent any unauthorized access.
• Active Key: The Active key grants control over more sensitive transactions including the account’s financial operations, such as transferring funds, powering up or down, and delegating Hive Power.
• Posting Key: The Posting key is more limited in scope and is designed for social interactions—posting content, commenting, voting, and following other users. It cannot be used for financial operations, which makes it safer for frequent use.
• Memo Key: This key is used for encrypting and decrypting memos attached to token transfers. It plays a specialized (though infrequently used) role in securing communication on the blockchain.

7.2 Authorities: Delegation and Permissions

While keys determine direct access to an account’s functions, authorities define who (or what) is allowed to perform actions on behalf of the account. Authorities allow the delegation of specific permissions to another account without revealing or sharing private keys.

• Authorities refer to the permissions tied to an account and are often delegated to other accounts or services. These can be thought of as rules that control who can act on behalf of an account, based on key types.
• Key vs. Authority: A key is a cryptographic credential that directly authorizes actions (e.g., a private key signing a transaction), whereas an authority is a rule that specifies which other accounts or applications are permitted to perform certain operations on your behalf.
• It is possible (though uncommon) for an account to have authorities delegated to other accounts and to not have been created with any keys. That means transactions for that account can only be done by those other accounts.
• Hive does have the functionality to allow multiple accounts (with authority) or multiple keys split the burden of approving a transaction. Some call this multi-signature transactions.

8. How Hive Determines Account Abilities #KeyKnowledge

In the Hive blockchain, an account’s ability to perform operations is defined by the combination of keys and authorities it holds or delegates. The Hive blockchain operates under a strict hierarchy of permissions, where the ability to execute actions depends on the keys being used and the authorities granted to others.

8.1 Role of Keys in Account Operation

• Direct Control: When a user signs a transaction (like posting content, transferring tokens, or voting), the blockchain checks whether the key used has sufficient authority for that action. For example, only an Active key can authorize a transaction that requires active authority (like a token transfer)
• Signing Mechanism: Every action on Hive requires a signature from the appropriate key, verifying that the transaction was authorized by someone who holds the private key. The public key is then used by the blockchain to verify the signature without needing access to the private key itself. In other words only the private key could create a signature needed and because the public key is public it is therefore provable that the user was indeed in possession of the private key. The signatures are public data as well as the public keys.

8.2 Role of Authorities in Account Operation

• Delegation of Power: Authorities allow an account to delegate control to other accounts or services without handing over private keys. For example, an account can delegate posting authority to a third-party applica