- Indy Node
- Announcements
- About Indy Node - Relationship with Sovrin - Getting Started Guide - Hyperledger Wiki-Indy
- Technical Overview of Indy Blockchain
- Indy Node Repository Structure
- Dependent Projects
- Contact us
- How to Contribute
- How to Install a Test Network
- How to Start Working with the Code
- Continuous Integration and Delivery
- How to send a PR
- Docs and links
The project branches have changed.
The main branch now contains the Ubuntu 20.04 work stream, and the previous main branch containing the Ubuntu 16.04 work stream has been moved to the ubuntu-16.04 branch. We encourage everyone to switch to using the new code and appreciate your patience while we stabilize the work flows and documentation on this new branch.
The following changes were made to the branches:
main(default) renamed toubuntu-16.04- This retargeted the associated PRs.
ubuntu-20.04-upgradeset as the default branch.ubuntu-20.04-upgrade(default) renamed tomain
This codebase embodies all the functionality to run nodes (validators and/or observers) that provide a self-sovereign identity ecosystem on top of a distributed ledger. It is the core project for Indy; over time, all other indy-* projects may collapse into this one, except for indy-sdk.
Indy has its own distributed ledger based on RBFT.
This code is independent from but commonly associated with The Sovrin Foundation. The Sovrin Foundation is a public utility
for identity, built on top of this codebase. People who install sovrin packages (e.g., with
sudo apt install sovrin) get prepackaged genesis transactions that integrate
with an Indy validator pool using Sovrin's governance and trust framework. However, it is possible to use Indy Node
with a different network, using whatever conventions a community chooses.
We recommend that developers should explore Indy Walk through to learn about Indy basics or Getting Started Guide with VCX and Getting Started Notebook.
If you haven't done so already, please visit the main resource for all things "Indy" to get acquainted with the code base, helpful resources, and up-to-date information: Hyperledger Wiki-Indy.
- Refer to our documentation site at
indy.readthedocs.iofor the most current documentation and walkthroughs - Please visit Technical Overview of Plenum.
- More documentation can be found in indy-plenum-docs and indy-node-docs.
Indy Node repo consists of the following parts:
- indy-node:
- indy-plenum-based implementation of distributed ledger
- Extends plenum's base pool functionality with specific transactions support (CLAIM_DEF, SCHEMA, POOL_UPGRADE, etc.)
- indy-common
- Common code for indy-node
- scripts
- Some scripts that can be run for installed Node (in particular, scripts to start Nodes, generate keys, prepare test Network, etc.)
- doc
- A folder with documentation
- .devcontainer
- A folder with scripts helping to configure a development environment. Please refer to the official DevContainer documentation for more information.
- indy-plenum
- The heart of the distributed ledger technology inside Hyperledger Indy.
- Most probably you will need to make changes in Plenum if you want to contribute to Indy. So, if you want to work with Indy Node, you will need to have the Plenum code as well in most of the cases and work with two projects at the same time (see How to Start Working with the Code below).
- indy-sdk
- An official SDK for Indy.
- It contains client and anoncreds implementation
- You don't need it to contribute to Indy-Node. But please use indy-sdk for your own applications dealing with Indy ecosystem.
- ursa
- Hyperledger's shared crypto library
- In particular, it contains BLS multi-signature crypto needed for state proofs support in Indy.
- Bugs, stories, and backlog for this codebase are managed in Hyperledger's Jira.
Use project name
INDY.
- Join us on Hyperledger's chat in
or 
to discuss.
- We'd love your help; see these instructions on how to contribute.
- You may also want to read this info about maintainers.
- See How to send a PR below.
You can have a look at Start Nodes to understand what needs to be done to create a Network, initialize and start Nodes, and what scripts are provided for this.
The described process is automated in one of the ways below (it allow to install a test Network):
-
Docker Start Pool with Docker
-
Docker-based pool using with new libindy-based CLI:
-
Also coming soon: Create virtual machines in AWS.
The preferred method of setting up the development environment is to use the devcontainers. All configuration files for VSCode and Gitpod are already placed in this repository. If you are new to the concept of devcontainers in combination with VSCode here is a good article about it.
Simply clone this repository and VSCode will most likely ask you to open it in the devcontainer, if you have the correct extension("ms-vscode-remote.remote-containers") installed.
If VSCode didn't ask to open it, open the command palette and use the Remote-Containers: Rebuild and Reopen in Container command.
If you want to use Gitpod simply use this link
or if you want to work with your fork, prefix the entire URL of your branch with gitpod.io/# so that it looks like https://gitpod.io/#https://github.com/hyperledger/indy-node/tree/main.
Note: Be aware that the config files for Gitpod and VSCode are currently only used in the main branch!
Please have a look at Continuous integration/delivery
- Make sure that you followed write code guideline before sending a PR
- Do not create big PRs; send a PR for one feature or bug fix only. If a feature is too big, consider splitting a big PR to a number of small ones.
- Consider sending a design doc into
designfolder (as markdown or PlantUML diagram) for a new feature before implementing it - Make sure that a new feature or fix is covered by tests (try following TDD)
- Make sure that documentation is updated according to your changes
- Provide a full description of changes in the PR including Jira ticket number if any
- Make sure that all your commits have a DCO sign-off from the author
- Make sure that static code validation passed
(you can run
flake8 .on the project root to check it; you can install flake8 from pypi:pip install flake8) - Put the link to the PR into
#indy-pr-reviewchannel in Rocket.Chat - A reviewer needs to start your tests first (add
test this pleasecomment to the PR) - You need to make sure that all the tests pass
- A reviewer needs to review the code and approve the PR. If there are review comments, they will be put into the PR itself.
- You must process them (feel free to reply in the PR threads, or have a discussion in Rocket.Chat if needed)
- A reviewer or maintainer will merge the PR (we usually use Squash)
If you made changes in both indy-plenum and indy-node, you need to do the following:
- Raise a PR to indy-plenum's master and wait until code is reviewed and merged (see above)
- So, a new build of indy-plenum is created
- Note a just built version
X.Y.Z.devBof indy-plenum (you can check it in pypi or on CI server). - Change indy-plenum's dependency version to the new one in indy-node's setup.py.
- Raise PR to indy-node's master and wait until code is reviewed and merged (see above)
- So, a new build of indy-node is created
- Indy-plenum is based on RBFT protocol
- Please have a look at documents and diagrams in docs/source folder
- Please have a look at documents and diagrams in Plenum's docs folder, or on https://indy.readthedocs.io/projects/plenum :
- Relationship between Entities and Transactions: relationship diagram
- Supported transactions and their format: transactions
- Supported requests (write, read) and their format: requests
- Network roles and permissions
- Indy file folder structure guideline
- Helper Scripts
- Pool Upgrade
- Node Addition
