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:
- 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? - 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.
- 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. - 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.
- 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.
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 <https://gtg.openhive.network/get/snapshot/snapshot_filename>
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 application (like PeakD or HiveSigner), allowing the app to schedule posts or cast votes on the account’s behalf.
- Double Delegation: Authorities can also be layered through multiple accounts. For instance, a user might delegate their posting authority to a dApp (e.g.,
@peakd.app), which then delegates that authority to HiveSigner (e.g.,@hivesigner), so HiveSigner can broadcast transactions on behalf of the app, all without needing to expose private keys.
8.3 Hierarchical Authority and Multi-Signature Accounts #optionalFeature
Hive supports hierarchical structures for managing account authorities, enabling greater flexibility and security. One of the most secure forms of authority delegation is multi-signature accounts, where multiple keys or accounts must approve a transaction before it can be executed. This structure adds layers of security, ensuring that no single party can act alone on behalf of an account, especially for critical or high-value actions.
This is not a common feature but allows for projects and accounts to share the burden of authorizing a transaction. This is similar to how companies or organizations often have majority votes in order to sign off on an action.
9. Authentication #CoreFunction #KeyKnowledge
Authentication in Web3 differs from traditional Web2 methods. Hive employs secure methods to authenticate users without exposing private keys, which provides a major security advantage. In Web2, authentication often involves sending passwords or other sensitive information to a centralized server, making it susceptible to data breaches. In contrast, Hive's approach allows users to keep their private keys entirely on their own devices, using them only to sign transactions locally. This means that private keys are never transmitted across the internet, significantly reducing the risk of key theft or hacking. This method of signing transactions ensures that users maintain complete control over their account security, and it is a key reason why blockchain authentication is considered more resilient against many traditional cyber threats.
9.1 User Authentication Options #KeyTech
- Private Keys: Users retain control over their private keys, which are used to sign transactions.
- Message Signing: Users sign arbitrary messages to verify ownership, facilitated by wallet applications.
- Authentication Services: Integrate community-maintained services to enhance security and reduce trust vulnerabilities.
9.2 WALLETS (KEYCHAIN and PEAKVAULT) #KeyKnowledge #ImportantTools
Overview
HiveKeychain and PeakVault are essential tools for developers working on Hive projects that require secure and seamless interactions with the blockchain, the majority of Hive blockchain users depend on one of these wallets. HiveKeychain and PeakVault store private keys locally on the user's device, allowing users to sign transactions and interact with Hive-based dApps without exposing their private keys to external threats. They serve as crucial layers of security that enable safe blockchain interactions without compromising user control over their accounts. This benefits both user and applications in experience and security. HiveKeychain additionally has a mobile wallet application, extending functionality beyond browser use.
How Wallets Work (HiveKeychain and PeakVault)
HiveKeychain and PeakVault act as gateways between users and Hive-based applications, they help users make transactions and get information on the blockchain. When developers build Hive dApps, these wallets provide a mechanism that allows users to securely sign and authorize blockchain transactions.
These wallets store private keys encrypted locally, meaning keys are never shared over the network or exposed to third-party services. When a user interacts with a dApp/website (e.g., peakd.com or splinterlands.com), these wallets (HiveKeychain and PeakVault) prompt the user to manually approve transactions. This approval process involves accessing the private keys locally only to generate the required signature for the transaction. Once signed, the transaction is sent directly to the Hive blockchain. By keeping private keys entirely on the user's device, developers can ensure that sensitive information is never at risk of interception during communication with external applications.
Key Features
- In-Wallet Transactions: Users can transfer tokens and perform other limited transactions directly within the wallet without needing any other website or application.
- Transaction Signing: HiveKeychain and PeakVault enable users to sign blockchain transactions initiated by third-party websites or web-based apps, securely managing the private key signing process locally.
- Authentication and Security: HiveKeychain and PeakVault offer a way for users to authenticate without sending their private keys over the network, thus mitigating common security issues such as phishing or man-in-the-middle attacks.
User and Developer Workflow
Here is how a typical integration flow works and what developers need to know:
User Account Setup: Users initially add their Hive accounts to the wallet extension and input their keys (Posting, Active, Memo). The private keys are encrypted and stored locally, ensuring that sensitive information remains secure and inaccessible to external parties. The keys are only accessible when the wallet is unlocked (usually with a password), and the wallet cannot be used while it remains locked.
Transaction Preparation: Hive-based websites or dApps generate the blockchain transaction payload and send a formatted request to the wallet (HiveKeychain or PeakVault) for the user's review and authorization.
User Authorization: The wallet prompts the user to manually approve or reject the transaction. Upon approval, the wallet uses the locally stored private keys to sign the transaction, ensuring only the account owner can initiate it and providing full user control.
(Note: Wallets have an option for users to auto-sign transactions of a specific type or all posting transactions. Active key transactions are always approved manually.)
Broadcasting Transactions: Once confirmed and signed, the wallet broadcasts the transaction to Hive nodes. Block producers (witnesses) on the Hive network verify and add the transaction to the blockchain, ensuring the integrity of the decentralized network.
This approach provides several benefits for developers:
- No Key Handling: Developers do not need to handle private keys, significantly reducing liability and risk.
- Seamless Integration: HiveKeychain and PeakVault offer straightforward integration using APIs that allow for easy interaction between the dApp and the wallet.
- User Control and Security: Users are always in control, ensuring that sensitive actions are explicitly authorized by them. This helps developers build trust with their users, as they are not directly handling or storing sensitive information.
How Keychain and PeakVault Differ from Other Options
Unlike other authentication methods like HiveSigner or HiveAuth, HiveKeychain and PeakVault do not rely on a centralized service to facilitate logins. Instead, they function entirely as client-side solutions, allowing users to retain full control over their keys and each transaction they make. This provides enhanced security and control for users who prioritize keeping their private information local.
HiveAuth, for example, focuses on a decentralized key management approach but may require more setup compared to the straightforward integration of HiveKeychain and PeakVault's browser tools. HiveSigner, on the other hand, offers a simpler mobile experience but compromises on security and ease of user setup.
Potential Security Issues
While HiveKeychain and PeakVault provide robust security, there are still some potential risks that developers and users need to consider:
- User Awareness: Users can still be tricked into signing fraudulent transactions, highlighting the importance of user education and vigilance when authorizing transactions.
- Unlocked Wallet Vulnerability: If a user's device is compromised while HiveKeychain or PeakVault is unlocked, unauthorized individuals could perform actions on the user's behalf or view and copy keys from the wallet software.
- Device Security: Malware, keyloggers, or any form of local device compromise can still jeopardize user accounts. It is essential that users maintain strong device security practices to ensure that their keys are not at risk.
Wallet Developer Resources
HiveKeychain
- Documentation: Available on HiveKeychain GitHub.
- SDK: Multiple SDKs are available, including the HiveKeychain SDK on npm, providing various options for integrating wallet functionality.
- Tutorial: JavaScript/Node.js Tutorial.
PeakVault
- Documentation: https://vault.peakd.com/peakvault/guide.html
- SDK: $ npm i @peakd/hive-wallet-sdk
Thehive-wallet-sdkallows developers to handle every Hive wallet (Peak Vault, MetaMask and Keychain) without the need to write duplicate code.
9.3 HiveSigner Overview #OptionalTool
HiveSigner is an OAuth2-based authentication and authorization service that allows users to interact with the Hive blockchain without exposing their private keys to applications. Its primary advantage lies in enabling applications to request posting operations or perform specific actions while maintaining the user's key security. By using a system of double delegation of posting authority, HiveSigner improves security by ensuring that apps never need to access or manage the user’s private keys directly.
Authorities and Tokens
- Authorities on the Hive Blockchain:
- Posting Authority: On the Hive blockchain, users can delegate authority to another account (such as an app or service). This means an account delegated posting authority can perform specific operations (e.g., posting content, content voting) on the user's behalf, but without access to higher-level functions that require the Active or Owner keys, which are more sensitive.
- Double Delegation Model: HiveSigner uses a system of double delegation. The user delegates posting authority to the application (e.g.,
@peakd.app), and the application then grants posting authority to HiveSigner (e.g.,@hivesigner). This allows HiveSigner to broadcast transactions securely on behalf of the app without any private keys being exposed.
- HiveSigner's Role:
- Access Tokens in HiveSigner act as authorization keys for transactions within the scope of the delegated authority. While the access token is issued to ensure the app has user consent for actions like posting or voting, the actual interaction with the Hive blockchain leverages the posting authority granted to HiveSigner. This authority allows HiveSigner to sign transactions on behalf of the user, but only within the scope that has been permitted by both the user and the app.
- Hive Blockchain Functionality:
- The delegation of authority is a core Hive blockchain feature. It allows users to safely delegate certain operations to trusted third parties without giving full control of their account (i.e., the private keys are never shared). The blockchain itself manages these authority relationships, ensuring that apps like PeakD or Ecency can function securely through HiveSigner without requiring private key access.
Additional Key Points for AI Understanding:
Security Mechanisms:
- Token Expiry and Revocation: Access tokens are time-limited, meaning they expire after a set duration. Users also have full control to revoke tokens via the HiveSigner interface, instantly terminating the app’s ability to interact with their account. This is important for maintaining long-term security and preventing unauthorized usage.
- Local Signing: All private key operations, such as signing messages or transactions, happen locally in the user's browser or on their device. HiveSigner does not store or have access to the user’s private keys at any point.
- Security Concern: While HiveSigner may not transmit or save keys it is important to note that the system does require user to input a key into a web browser which is considered by some as security risk and though the key is not transmitted over the internet the practice of putting a key into a website is frowned upon by crypto experts.
App Integration:
- OAuth2 Flow: Developers integrate HiveSigner into their applications through the OAuth2 standard. When a user logs in through HiveSigner, they are prompted to authorize the app, and HiveSigner handles the secure transaction flow via access tokens. This allows the app to interact with the blockchain without directly handling any sensitive key information.
Use Cases:
- Web3 Applications: HiveSigner is essential for any Web3 app that wants to allow user interaction with the Hive blockchain (e.g., posting, voting, or commenting) while maintaining security. Examples include social platforms (like PeakD) or games (like Splinterlands) that require user interaction with the blockchain.
User Control:
- Revoking Permissions: Users can manage and revoke app permissions directly through HiveSigner. This is an essential security feature, ensuring users retain control over what actions an app can perform and allowing them to terminate access at any time.