Hey everyone! ICYMI: we published an updated DHF Proposal after talking with a number of important stakeholders and witnesses on Hive over the past several weeks. One of the main points of feedback we got was that INLEO's Proposal would give more value to Hive if we open sourced our onboarding technology. Afterall, our proposal is focused on growing the chain and one of the best ways INLEO can serve to grow the chain better is to release this framework that has become one of the most used signup methods on Hive.

A few days ago, we also published our first DHF Report. While we are not yet funded (our proposal is currently 95%), we believe in reporting transparently on both of the core goals announced in the updated proposal:

1. Open Source INLEO's technologies as well as build Plug & Play APIs for other UIs to seamlessly integrate our technologies
2. Collaborate with external ecosystems (ChainLink, Arbitrum, Solana, Litecoin, etc.) to market our onboarding technologies and bring their communities to Hive - like we did with Dash in November of 2024

In that first report, we released a transparent and immediate timeline on which technologies we will open source as part of our DHF Proposal. While we are not yet funded, we want to begin open sourcing some of our technologies and release APIs that can be utilized for free by other Hive UIs. These APIs will allow other UIs to not only add these sign up and login options to their frontend, it will also tap into our resources (use of our Account Creation Tokens + Dynamic RC Delegation System).

As promised, we are delivering the Plug & Play APIs for Keystore signups and logins. This API - when utilized - automatically includes the tap of our resources for Account Creation Tokens + Dynamic RC Delegation System to ensure new signups have the RCs they need for initial interactions on-chain.

If our proposal passes, we would like to continue to Open Source more of INLEO's technologies such as our other wallet sign up options that we've been developing, our Referral System, our dynamic RC delegation system, Accounts API, etc.

If you support INLEO's Open Source contributions to Hive and our collaboration approach to marketing these technologies, check out the INLEO DHF Proposal.

Open Source Code Base vs. APIs

Just as a reminder (as we stated it in our last post), there are actually two releases here:

1. We are releasing Plug & Play APIs that can seamlessly be integrated by any UI. This means that the code base doesn't need to be used by other Hive UIs who want to integrate. This is one of our goals to release a finalized product that can be easily integrated
2. We are releasing the full code base Open Source - in addition to the APIs, we are releasing the Code Base fully open source so that it can be audited, improved and even customized by other Hive interfaces who wish to add it to their own code base

Some interfaces will likely choose option #1 as it offers an easy way to add these options to their frontend. Others may choose option #2 as it offers the ability to maintain your own DB's and assume the responsibility of doing so while allowing for customization if a UI chooses to do so.

In this post, we are releasing the Docs + the Plug & Play APIs. We are planning to Open Source the repo in the next 24 hours (more info on this below).

Auditing the Code Base Prior to Open Sourcing

We have the code base ready in a new Gitlab environment. We've invited a handful of Hive developers and trusted people on the chain to audit this codebase.

We have ample disclaimers in the docs (below) as well: while this code base has been used on INLEO, it should be looked at as a Beta product. The INLEO team is standing by to make any adjustments, updates and upgrades that are suggested both by the private parties who are auditing this code base as well as the public Hive community once it is open sourced.

Not everything is perfect right off the bat. We are not promising perfection here. I want to make that very clear. The INLEO team develops and innovates new products and we iterate our way closer to perfection over time. If there are any bugs, issues or recommended fixes; our team is standing by to handle them immediately. We are very open to any and all #feedback to improve this technology and we believe that allowing other Hive UIs to tap into it will bring a new age of onboarding to Hive - especially as it coincides with the incredible attention and onboarding that will come from our Solana, Arbitrum, Litecoin, etc. partnerships that we wish to launch as part of our DHF Proposal.

If you are a developer and would like early access to the code base prior to us releasing it publicly, please reach out to us either in a comment below or on Discord/MatterMost.

Security is a priority for us and we would love more third-party reviews of what the team has built here.

Plug & Play APIs Are Ready for Integration

The Plug & Play APIs that we've built are ready to be integrated. The information on how to do so can be found in the documentation below.

Lite Account Disclaimers

You'll notice a lot of disclaimers in this documentation about Lite Accounts. We cannot stress the importance of understanding the difference of a Lite Account vs. a Full Account enough:

A Keystore account offers a full Hive account. No keys are saved anywhere but by the user. No keys are ever broadcast over the network.

A Lite Account using X or Google to sign in is exactly what the name implies: a LITE account. This account is meant as a temporary means to signing a user in. The user does not have custody of the account and needs to be warned of such risks of this during the sign up process. If they choose this option, it is highly convenient to quickly sign in to Hive and start interacting but this should not be a long-term login method.

Our Interface warns users who are on Lite Accounts about the risks of not custodying their own keys. We also warn of the risks of using a Web2 authentication method (being banned on X could for example cause a loss of access to the accompanying "temporary" Hive account).

INLEO's interface has a user flow (seen in docs) that educates users about Hive keys, changes their Hive keys and downloads the new keys so that only the user has a copy in order to offboard from a Lite Account and into a Full Hive Account.

*Please see the disclaimers section for more info about this.

Documentation (1st Draft)

Prior to fully open sourcing the repo, we would love some #feedback on the documentation we've written for it. Please Note: let this serve as a 1st draft of our documentation for this Open Source codebase + the Plug & Play APIs that accompany them.

LeoInfra V2.0 API Documentation

Welcome to the LeoInfra V2.0 API! This API provides endpoints for user signup, login, and account management on the Hive blockchain. Below, you'll find details on how to use each endpoint, including URLs, request payloads, and potential responses.

Base URL: http://localhost:8090 (adjust based on your deployment)

Authentication: Some endpoints require a Firebase ID token or reCAPTCHA verification for security.

Rate Limiting: The API enforces a limit of 3 requests per second with a burst size of 30 requests.

Disclaimers

⚠⚠ IMPORTANT DO NOT SKIP ⚠⚠

While LeoInfra V2 has been in production on INLEO for quite some time, consider this as Beta technology. Implementing this technology is done so at your discretion as an application owner. We also advise ample displays giving users proper education and warnings about key handling.

The API seen here allows your users to sign up and sign in to Hive using 3 different methodologies that the INLEO Team has developed:

1. Keystore (Full Hive Account, Full Self-Custody)
2. X Lite Accounts (Lite Account, Web2 Authentication)
3. Google Lite Accounts (Lite Account, Web2 Authentication)

Keystore (Full Hive Account, Full Self-Custody)

Keystores allow users convenient logins. It encrypts their posting key in Local Storage and has the user generate their own decryption pin code which is saved in their SessionStorage. If the user tries to do any Active Key Operation, then they're prompted to sign that operation with their Keystore file. Their Active Keys are never saved in the browser and none of their keys are ever broadcast over any network.

X & Google Lite Accounts (Lite Account, Web2 Authentication)

X & Google Lite Accounts offer A LOT of convenience for new users. HOWEVER, a big caveat of Lite Accounts is - as the name suggests - they are LITE accounts. These accounts are not full self-custody and they rely on the LeoInfra server (or your infra, if you choose to clone our Open Source code base). This means that the users keys are encrypted by the user's Web2 authentication method. The user could lose access to "their" Hive Lite Account if:

1. Their Web2 account is compromised
2. LeoInfra is compromised
3. The passthrough of their keys to LeoInfra is compromised (man-in-the-middle attacks)

*"their" is in parentheses as both you as the app owner and the user should be aware that the account has very low security (as low or worse than a Web2 sign in method). INLEO's use of Lite Accounts on our frontend gives a disclaimer to the user that they are using a temporary account that doesn't belong to them. In order to take control of the account, they need to change and download their keys - our UI has a Lite Account to Full Account flow where all of the keys get changed and downloaded by the user so that they can safely take custody of the "temporary" account they are using. We cannot stress the LOW SECURITY nature of Lite Accounts enough. While they make it easy and convenient to sign up a new user, users should be continuously reminded that they don't own the Hive account they're controlling with their Web2 account.

Use of Lite Accounts is meant to be a temporary means of signing users up. We consider them to be a low security signup method that is extremely convenient but also risky in terms of the security of the account. For this reason, when a user is signed up, they are given ample warnings and if they get active on INLEO, we continually pester them to follow our flow and convert their account to a Full Hive Account. If you operate a Hive UI and choose to integrate this sign up method, we recommend considering certain disclaimer displays that we have created (such as restrictions when a user starts depositing funds - telling them they MUST go full self-custody to continue, etc.):

For this reason, we have ample disclaimers on INLEO's frontend - and recommend all frontends who add similar disclaimers if they choose to integrate Lite Accounts. Including ones based on the crypto held in a Lite Account. After a Lite Account reaches more than $1 on it, our UI starts warning them that their funds aren't fully secure until they take Full Self Custody. A link to our docs explains it in more detail.

Lite Accounts offer full access to Hive services but do so with a massive security trade-off. We developed Lite Accounts so that new users could quickly and easily sign up to Hive and start using the ecosystem. Once that user has familiarized themself with the ecosystem, they are bombarded with messages from us to "Take Full Self Custody" of their account.

When a Lite Account user is on INLEO, there is persistent messaging to remind them that they're on a Lite Account and we recommend taking Full Self-Custody. On this messaging, there is an action button. This button takes them to a page on INLEO where there is a simple and easy-to-use flow that:

1. Changes their Hive Private Keys
2. Downloads the new Keys

This allows them to turn a Lite Account into a full, self-custodied Hive Account. The keys are changed so that the encrypted keys in LeoInfra are no longer usable and the user is the only one with the new copy of their Hive Account Keys.

What is LeoInfra?

In the disclaimers section, we also explained a bit about what LeoInfra is. LeoInfra allows for 3 new signup and login methods to Hive:

1. Keystore (Full Hive Account, Full Self-Custody)
2. X Lite Accounts (Lite Account, Web2 Authentication)
3. Google Lite Accounts (Lite Account, Web2 Authentication)

These login methods enable users a trade-off of security and convenience. Many new users want extreme convenience (otherwise they see Hive as too complex and immediately leave). Many of them will choose either Keystore or one of our Lite Account methodologies in order to sign up. Ample disclaimers and UI flows should educate them on implementations like Hive Keychain and HiveAuth and encourage these users to delve deeper into the Hive ecosystem. These sign up methods are intended to easily onboard users, but they are not intended for users to continually use for extended periods of time.

If you are curious to see LeoInfra live in action, head over to https://inleo.io/signup and try one of them for yourself. The Keystore flow is extremely easy and creates not only a Hive wallet but also a BTC Wallet, ETH Wallet, Dash Wallet, Litecoin Wallet, etc. and ties them all together (including the Hive wallet).

How to Use INLEO's Resources to Onboard | Open API

Want to use INLEO's Account Creation Tokens and our Dynamic Resource Credit Delegation System for your onboards? This section covers how to access our instance of LeoInfra. This Plug & Play API allows you to onboard new users to your Hive interface without the need for cloning this repo and running your own instance.

Please refer to the Disclaimers prior to integration. We cannot stress enough about the nature of Lite Accounts and how a user doesn't own the account until they take full self-custody, importance of "not your keys, not your crypto", etc.

When a user is signed up using our APIs, it utilizes @leo.voter's Account Creation Tokens. We also built and maintain a Dynamic RC Delegation Pool. This Pool delegates RCs to new signups based on how active they are. It pulls back the delegation if they are inactive for an extended period of time in order to free up RCs for the next onboard. Signing up users with our API is extremely convenient for both you and the user as it uses our resources to onboard the user and allow them to interact on chain

Support & Whitelisting

Please reach out to us via Discord or to Khal in MatterMost if you are integrating these APIs. We do have a whitelisting process, so we will need to whitelist your app for signups. The info below will help you see what is needed for the integration, the final whitelisting will happen by us to allow for use of the Plug & Play APIs (disregard this if you are cloning the codebase).

1. Signup a User With Firebase (Lite Account)

To sign a user up for Hive using our Lite Account method and our resources, use the following steps. REMINDER (yes, we can't stress this enough): a Lite account should be viewed and explained to the user as essentially a temporary account that they do not own. They only truly own the account when they take full self-custody. If you implement the following, ensure your UI has ample disclaimers and education around this.

they need to implement firebase sdk into their ui
need us to allow their domain for firebase logins
they need to request client key + domain allowance from us for keystore

Create a new Hive account using Firebase authentication.

• URL: https://inleo.io/leoinfra/auth/signup
• Method: POST
• Content-Type: application/json
• Description: Registers a new user with Firebase credentials and creates a Hive account.

Request Payload

{
  "username": "yourusername",
  "firebase_uid": "firebase-uid-from-auth",
  "firebase_id_token": "firebase-id-token",
  "memo_key": "STM7q4vYne0DzsRhvvyYhdA3NCTrq3GJNbBFGhTf2cyQQSc4AM",
  "public": {
    "posting_key": "STM4zWK4wDuSuTu1GWxd7Whgp1v6nTEHmCrmS5oJybmSmXyBzV7a",
    "owner_key": "STM6kFyb9WSL4BFRnfEDAzNbkmCcvmzyNKB8xhCMBuq5ADt8am3",
    "active_key": "STM6md43PpdtkF1qdGMWtLvznbBFxyaoRhbURmyq1LnT68gWBM5u"
  },
  "referral": "optional-referral-username"
}

username: Desired Hive username (must be unique).
firebase_uid: User's Firebase UID.
firebase_id_token: Token from Firebase authentication.
memo_key: Public memo key for the Hive account.
public :Public keys (posting, owner, active) for the Hive account.
referral: Optional referral username.

Firebase SDK + Whitelisting

You will also need to implement the firebase SDK into your UI.

The final step is to reach out to the INLEO team (contact info above) and we will whitelist your app's domain.

2. Signup a User with Keystore

Create a new Hive account using a reCAPTCHA token and keystore keys.

• URL: https://inleo.io/leoinfra/auth/signup
• Method: POST
• Content-Type: application/json
• Description: Registers a new user with reCAPTCHA verification and saves minimal data.

Request Payload

{
  "username": "yourusername",
  "keys": {
    "active": "STM6md43Ppdtkf1qDGMWtLvznbBfXxyaoRHbuRMyq1Ln7G8gWBMSu",
    "owner": "STM6Kfyb9WSL4BFRnfEDAzNbkMnCccvmzyNKB8xhCMBuq5ADt8aM3",
    "posting": "STM4zWK4DwDuSuTu1GWXd7WHgpiv6nTEHmCrmS5oJybmSmXybZv7a",
    "memo": "STM7q4vYvneQDzsRhvvXyhdA3NCTrq3GJBnBFGhTf2qcyQQSqc4AM"
  },
  "referral": "optional-referral-username",
  "token": "recaptcha-token",
  "addresses": {
    "email": "user@example.com"
  }
}

• username: Desired Hive username.
• keys: Public keys for the Hive account.
• referral: Optional referral username.
• token: reCAPTCHA token from Google reCAPTCHA.
• addresses: Optional key-value pairs (e.g., email).

Client Key + Whitelisting

To finish the integration for Keystore, reach out to the INLEO team (info above) to request a client key + domain whitelisting.

---

Open Source Docs

If you want to fork the codebase and run your own instance of LeoInfra, this section covers the documentation for that. Please refer to the Disclaimers section above about how LeoInfra works and how you should protect yourself and your users (especially with Lite Accounts) using ample disclaimer displays and user flows for taking full self-custody before a user starts earning/depositing on their account.

Again: Lite Accounts are not meant to be a long-term sign-in option. Your frontend cannot stress this enough.

Endpoints

1. Signup User with Firebase

Create a new Hive account using Firebase authentication.

• URL: /auth/signup
• Method: POST
• Content-Type: application/json
• Description: Registers a new user with Firebase credentials and creates a Hive account.

Request Payload

{
  "username": "yourusername",
  "firebase_uid": "firebase-uid-from-auth",
  "firebase_id_token": "firebase-id-token",
  "memo_key": "STM7q4vYne0DzsRhvvyYhdA3NCTrq3GJNbBFGhTf2cyQQSc4AM",
  "public": {
    "posting_key": "STM4zWK4wDuSuTu1GWxd7Whgp1v6nTEHmCrmS5oJybmSmXyBzV7a",
    "owner_key": "STM6kFyb9WSL4BFRnfEDAzNbkmCcvmzyNKB8xhCMBuq5ADt8am3",
    "active_key": "STM6md43PpdtkF1qdGMWtLvznbBFxyaoRhbURmyq1LnT68gWBM5u"
  },
  "referral": "optional-referral-username"
}

username: Desired Hive username (must be unique).
firebase_uid: User's Firebase UID.
firebase_id_token: Token from Firebase authentication.
memo_key: Public memo key for the Hive account.
public :Public keys (posting, owner, active) for the Hive account.
referral: Optional referral username.

Potential Responses

Success (200 OK):

{"0":true,"1":"Successfully created Hive account, you will be redirected to login."}

Failure (200 OK):

{"0":false,"1":"Failed to create Hive account yourusername, please contact the authorities."}

{"0":false,"1":"This sign up method has already been used. Please login with this method or create a new account using a different sign up method"}

{"0":false,"1":"Error authorizing user to firebase"}

How to Use

1. Obtain a Firebase ID token by authenticating with Firebase (e.g., via their SDK).
2. Generate or provide Hive public keys (e.g., using a tool like Hive Keychain).
3. Send a POST request with the payload above using a tool like curl or Postman:

curl -X POST http://localhost:8090/auth/signup \
-H "Content-Type: application/json" \
-d '{"username":"yourusername","firebase_uid":"uid","firebase_id_token":"token","memo_key":"STM...","public":{"posting_key":"STM...","owner_key":"STM...","active_key":"STM..."}}'

1. Check the response for success or error messages

2. Signup User with Keystore

Create a new Hive account using a reCAPTCHA token and keystore keys.

• URL: /auth/signup_keystore
• Method: POST
• Content-Type: application/json
• Description: Registers a new user with reCAPTCHA verification and saves minimal data.

Request Payload

{
  "username": "yourusername",
  "keys": {
    "active": "STM6md43Ppdtkf1qDGMWtLvznbBfXxyaoRHbuRMyq1Ln7G8gWBMSu",
    "owner": "STM6Kfyb9WSL4BFRnfEDAzNbkMnCccvmzyNKB8xhCMBuq5ADt8aM3",
    "posting": "STM4zWK4DwDuSuTu1GWXd7WHgpiv6nTEHmCrmS5oJybmSmXybZv7a",
    "memo": "STM7q4vYvneQDzsRhvvXyhdA3NCTrq3GJBnBFGhTf2qcyQQSqc4AM"
  },
  "referral": "optional-referral-username",
  "token": "recaptcha-token",
  "addresses": {
    "email": "user@example.com"
  }
}

• username: Desired Hive username.
• keys: Public keys for the Hive account.
• referral: Optional referral username.
• token: reCAPTCHA token from Google reCAPTCHA.
• addresses: Optional key-value pairs (e.g., email).

Potential Responses

• Success (200 OK):

{"0":true,"1":"Successfully created Hive account and saved user data."}

• Failure (200 OK):

{"0":false,"1":"Hive account created but failed to save user data: "}

{"0":false,"1":"Failed to create Hive account yourusername, please contact the authorities."}

{"0":true,"1":"Captcha is wrong!"}

{"0":true,"1":"Failed to verify captcha."}

{"0":false,"1":"You have reached the maximum number of account creations for today."}

How to Use

1. Implement Google reCAPTCHA on your frontend and obtain a token.
2. Provide Hive public keys and a unique username.
3. Send a POST request:

curl -X POST http://localhost:8090/auth/signup_keystore \
-H "Content-Type: application/json" \
-d '{"username":"yourusername","keys":{"active":"STM...","owner":"STM...","posting":"STM...","memo":"STM..."},"token":"recaptcha-token"}'

1. Handle the response accordingly.

Note: Limited to 4 accounts per IP per day.

3. Login User

Log in an existing user using Firebase credentials.

• URL: /auth/login
• Method: POST
• Content-Type: application/json
• Description: Authenticates a user and returns their data.

Request Payload

{
  "firebase_id_token": "firebase-id-token"
}

• firebase_id_token: Token from Firebase authentication.

Potential Responses

• Success (200 OK):

{"0":true,"1":"{\"username\":\"yourusername\",\"firebase_uid\":\"uid\",...}"}
(Returns user data as a JSON string in the second element.)

• Failure (200 OK):

{"0":false,"1":"There is no user registered with this option please consider registering."}

How to Use

1. Authenticate with Firebase to get an ID token.
2. Send a POST request:

curl -X POST http://localhost:8090/auth/login \
-H "Content-Type: application/json" \
-d '{"firebase_id_token":"token"}'

1. Parse the response to extract user data if successful.

4. Verify Signature (Optional)

Verify a Hive signature for login purposes.

• URL: /verify
• Method: GET
• Content-Type: application/json
• Description: Validates a signature against a Hive account's posting key.

Request Payload

{
  "signature": "hex-signature",
  "account": "hive-username",
  "public_key": "STM...",
  "hivesigner": false,
  "timestamp": 1234567890
}

• signature: Hex-encoded signature.
• account: Hive username.
• public_key: Public key to verify against.
• hivesigner:`` Boolean indicating if HiveSigner format is used.
• timestamp: Optional timestamp for HiveSigner.

Potential Responses

• Success (200 OK): "true" or "false" (string)

How to Use

1. Generate a signature using a Hive private key (e.g., via Hive Keychain).
2. Send a GET request:

curl -X GET http://localhost:8090/verify \
-H "Content-Type: application/json" \
-d '{"signature":"hex","account":"username","public_key":"STM..."}'

1. Check the boolean response.

General Notes

• Environment Variables: Ensure the server has FIREBASE_API_KEY, MONGODB_CONNECTION_STRING, HAFSQL_URL, and MAIN_HIVE_ACCOUNT set in a .env file or environment.
• Hive Integration: The API interacts with the Hive blockchain to create accounts and delegate resource credits (RC).
• Error Handling: Responses use a tuple-like JSON structure [success, message]. Check the first element (0) for success/failure.
• CORS: The API allows permissive CORS, so it can be accessed from any origin.

Example Workflow

1. Signup: Use /auth/signup or /auth/signup_keystore to create an account.
2. Login: Use /auth/login with Firebase credentials to authenticate.
3. Verify (Optional): Use /verify to validate a Hive signature if implementing custom login flows.

---

If you support INLEO's Open Source Contributions to Hive and our collaboration approach to marketing our technologies by partnering with ecosystems like Arbitrum, ChainLink, Solana, Litecoin, etc. like we did with Dash in 2024, consider supporting our proposal with your vote:

1. https://peakd.com/me/proposals/332
2. https://ecency.com/proposals/332