Why is Hyperledger Indy the best solution to start a Self-Sovereign Identity solution on?
The biggest community of people building a Self-Sovereign Identity infrastructure is Hyperledger Indy.
“Hyperledger is an open source collaborative effort created to advance cross-industry blockchain technologies. It is a global collaboration, hosted by The Linux Foundation”. (1)
One of its projects – Hyperledger Indy – is a distributed ledger built for the purpose of decentralized identity.
“Hyperledger Indy provides tools, libraries, and reusable components for providing digital identities rooted on blockchains or other distributed ledgers so that they are interoperable across administrative domains, applications, and any other silo.” (2)
Although Hyperledger Indy is still quite young with a lot to be discussed and done, we believe it is by far the best infrastructure to study and to start building in a Self-Sovereign Identity Solution on. Indy has one of the most mature codebase and an engaged community around it, researching, asking questions and working towards the maturity of the ecosystem. Not only are the best people in the identity field working on developing it but also because it’s part of a transparent consortium, a transparent foundation.
The main tool to start using Indy is Indy-SDK. An SDK (Software Development Kit) is a “kit” that brings all-you-need tools in one library.
We do believe Hyperledger Indy still has to overcome two hurdles:
1) Today the solution still relies solely on the Indy-SDK.
That can be tricky as it carries a lot of heavy-weight assumptions like the need to use ZeroMQ, which browsers are not compatible with because it requires RAW TCP access to communicate with the node. That usually requires more recent mobile devices to work. Also, being a kind of all-in-one library it carries functionalities not always needed to everyone that uses it.
2) The use of Rust to write the Indy-SDK
According to Daniel Hardman, Technical Ambassador at Hyperledger, the reason to use Rust as the programming language for Indy was because “We needed a language that could cross-compile for many different platforms, and that produced a C-callable API so lots of other languages could benefit from the artifacts it builds; if we didn’t have that, we’d have to write the same low-level crypto and wallet operations multiple times. Rust, Go, and C++ were the only serious candidates, and Rust had the nicest compiler options for cross-platform. Go’s C-callable support is harder to adapt when you are using Go routines. Rust is growing and is very popular with its developers.” (3)
We do agree that Rust is a very optimized programming language. It was a great choice to develop Indy. It compiles into C and can be read by most of the libraries. Rust can be compiled into C callable libraries and can be called by Node.js. But, in our opinion, it doesn’t matter much if it can be called but cannot be read by the great majority of other programmers.
Other languages that can generate C callable libraries – like C# (CoreRT) – are way easier to read and have a bigger community. For us to ramp-up someone new to this space, someone fresh out of University who needs to be onboarded to Sovrin, for example, we have to teach him blockchain, mathematics, cryptography, P2P networking and now also on Rust. The amount of knowledge that needs to be transmitted makes it more difficult to democratize this technology. To make it available for more developers.
Nonetheless, we believe Rust is a promising language.