A few weeks ago, I came across an article about how a Samsung-backed university is issuing NFTs to select graduates. This reminded me of a Reddit post I saw a while back where someone opened his door using Ethereum.

As a self-sovereign identity developer, so from a technical point of view, this is hilarious. I can think of ten ways to open your door that are more secure. But I believe there’s more to these stories. These people are coming up with solutions that are in line with most of the core values we in the SSI space have been working on for years.

Web 3 has seen a big rise in popularity in the last year. A lot of people (including me) are getting to know this new decentralized version of the internet by exploring cryptocurrencies, NFTs, DeFi and Blockchain games.

If you’ve been around for a while, I know exactly what you’re thinking. We’ve all seen these waves of excitement come and go. Most of this stuff is just unfounded hype around cryptocurrency, the Metaverse and other buzzwords to raise venture capital money. In the SSI community, we have a tendency to distance ourselves from it and believe we are working on better, more long term solutions. But fundamentally, these projects don’t differ that much from what we are working on in the SSI space.

• Some cryptocurrencies provide a safe haven in a world where no country is safe from problems like inflation, corruption or even fraud by introducing a monetary system that is open, transparent and decentralized.
• Online ownership has been an issue for years, where the most viable solution was dumping your stuff at some centralized organization that handles it for you, while also taking a big chunk from the revenue in the process. NFTs provide a way to solve this issue by creating scarcity, uniqueness and transparency.
• More recently, the decentralized gaming space gained a lot of popularity by promising more interoperability between the games you play and providing real ownership over the in game assets you obtain, most of which is now handled via black markets.

There is a lot of value in these projects, and by combining them with the identity layer we have been building for years the possibilities could be endless.

For example, while NFTs might not be the best for opening doors or issuing diplomas, they do provide use cases for ownership-based access management, which allows products and services to become tradable. The DeFi space is another good example. It is still incredibly unregulated, and an identity layer that uses verifiable credentials would help DeFi handle the upcoming regulations regarding KYC and AML. Lastly, this recent article from cheqd explains how the uniqueness and scarcity from NFTs combined with verifiable credentials can also make a big impact in the decentralized gaming space. This last item especially shows how much we are still in the middle of the ongoing innovation, and how little we know of what is yet to come.

I think there is a lot of skepticism around NFTs and the crypto space in general among some of my peers right now. But what if we embrace the hype that is created around this technology to show people what we’ve been building for the past 5 years? Instead of hating on apes and pixelated figures, embrace the attention the Web 3 space is getting as a whole and start a conversation with these new crowds that are ready to dive into decentralized technologies with us.

So next time you see someone advocating for why a JPEG is worth half a million, tell them to buy our million dollar Animo APE! Just kidding, but you might spark up a conversation telling them about SSI and what you’ve been doing. You can use our demo for that.

— - end of original article — -

Join Coinmonks Telegram Channel and Youtube Channel learn about crypto trading and investing

Also, Read

• 3Commas Review | Pionex Review | Coinrule review
• Ledger vs Ngrave | Ledger nano s vs x | Binance Review
• Bybit Exchange Review | Bityard Review | Jet-Bot Review
• 3Commas vs Cryptohopper | Earn crypto interest
• The Best Bitcoin Hardware wallet | BitBox02 Review

Why the SSI community should embrace million dollar apes. was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Often the very first struggles people face when using Aries Framework JavaScript is installing Libindy. This article will guide you through the cumbersome installing process and offer some easy tools to do so!

​Prerequisites

• A system package manager (like apt, pacman, etc.).
• Node (We have tested 17.0.1 and 16.8.0 and they both work, so those should be safe.)
• Cargo (We have to build libindy from source).
• git (to clone a repo, could also be done with downloading the zip from the github page).

Step 1: installing the dependencies

This step is platform-dependent, so check which distribution you have and use the correct provided script. This script installs libsodium, zeromq and possibly some other minor dependencies. If there is no script provided, check the names of these packages and install them with your package manager.

Arch based (arch, Manjaro, Arco, etc.)

# sh

sudo pacman -S libsodium zeromq

Debian based (Ubuntu, Mint, Kali, Deepin, etc.)

# sh

sudo apt install libzmq3-dev libsodium-dev libssl-dev

REHL based (Fedora, CentOS, etc.)

NOTE: This has not been tested yet. It is based on the previous distributions and might contain mistakes. If you found any please open an issue here or email me at berend@animo.id.

# sh

yum -i libsodium zeromq zeromq-devel

Step 2: Installing Libindy

Installing Libindy is slightly different from how we installed the dependencies. Libindy is technically downloadable with most package managers, however it did not work for me after many attempts. The following method has been tested extensively, and should work on any system with Cargo and git.

Step 2.1: Cloning the indy-sdk

First up is to clone the indy-sdk from its github repository.

# sh

git clone https://github.com/hyperledger/indy-sdk.git
​
cd indy-sdk/libindy

Step 2.2: Building Libindy

If this step throws any errors, it might be because you’re missing some packages. Step 1 of this guide provided the dependencies that are required, but it also assumed that you have some basic development packages, such as base-devel on arch.

# sh

pwd
​
# OUTPUT: …/indy-sdk/libindy
​
cargo build --release

​
Step 2.3: Moving the file

# sh

pwd
​
# OUTPUT: …/indy-sdk/libindy
​
sudo mv ./target/release/libindy.so /usr/lib/libindy.so

​ Step 3: Checking if it all worked

After cloning, building and moving Libindy, everything should be installed correctly to develop with Aries Framework JavaScript. To confirm this, execute the following script:

#sh

npx -p @aries-framework/node is-indy-installed

# output
# Libindy was installed correctly

If the output was anything else than that, there might be some issues with your installation. If the only steps you executed were step 1 and 2 from this article, please report this here or email me directly at berend@animo.id with an error log.
​
To acquire this error log execute the following:

#sh

npm i @aries-framework/node

Well done! You have now installed Libindy. Have fun using Aries Framework JavaScript! If you want some pointers on how to work wit hit, check out Issuing a Verifable Credential in 7 Easy Steps.

Often the very first struggles people face when using Aries Framework JavaScript is installing Libindy. This article will guide you through the cumbersome installing process and offer some easy tools to do so!

Prerequisites

• Node (We have tested 17.0.1 and 16.8.0 and they both work, so those should be safe.)
• Python 3+
• VS 2022 Community, or better (with the Desktop Development with C++ )

Step 1: Downloading Libindy

You can download the Libindy from the repository here. This will download Libindy and all its required dependencies.

Step 2: Extracting Libindy

When it is done downloading, navigate to your downloads folder and extract the lib directory to a permanent location. Remember this path as it is required later.

Step 3: Add Libindy to your environment variables

Go to your environment variables and click on new at the System Variables.The name has to be LD_LIBRARY_PATH and the value has to be the path to the lib folder.

This path is the one you extracted the downloaded zip file to.

Step 4: Checking if it all worked

After cloning, building and moving Libindy, everything should be installed correctly to develop with Aries Framework JavaScript. To confirm this, execute the following script:

#sh

npx -p @aries-framework/node is-indy-installed

# output
# Libindy was installed correctly

If the output was anything other than that, there might be some issues with your installation. If the only other steps you undertook were step 1 and 2 from this article, please report this here or email me directly at berend@animo.id with an error log.
​
To acquire this error log execute the following:

# sh
​
npm i @aries-framework/node
​

Otherwise, well done! You have now installed Libindy. Have fun using Aries Framework JavaScript! If you want some pointers on how to work with it, check out Issuing a Verifable Credential in 7 Easy Steps.

Often the very first struggles people face when using Aries Framework JavaScript is installing Libindy. This article will guide you through the installing process to get you started.

Prerequisites

• Homebrew
• Node (We have tested 17.0.1 and 16.8.0 and they both work, so those should be safe.)

​
Step 1: Installing Libindy

It is possible to install Libindy for MacOS via a very simple homebrew script. This script installs Libindy from the correct repository and installs its dependencies. These dependencies include OpenSSL, ZeroMQ and Libsodium.

# sh

brew tap blu3beri/homebrew-libindy
brew install libindy

​
​Step 2: Checking if it all worked

​To confirm if Libindy is correctly installed to be used with Aries Framework JavaScript, run the command below.

# sh

npx -p @aries-framework/node is-indy-installed
​
# OUTPUT: Libindy was installed correctly

If the output was anything else than that, there might be some issues with your installation. If the only step you did was step 1 from this article, please report this here or email me directly at berend@animo.id with an error log.

# sh

npm i @aries-framework/node

Otherwise, well done! You have now installed Libindy. Have fun using Aries Framework JavaScript! If you want some pointers on how to work with it, check out Issuing a Verifable Credential in 7 Easy Steps.

​

Often the very first struggles people face when using Aries Framework JavaScript is installing Libindy. This article will guide you through the cumbersome installing process and offer some easy tools to do so!

Prerequisites

• Homebrew
• Node (We have tested 17.0.1 and 16.8.0 and they both work, so those should be safe.)

Step 1: Installing OpenSSL

The first thing we’ll do is install OpenSSL. Since Apple replaced OpenSSL with their own version of LibreSSL, we’ll need to install it. Also, we need to install a specific version of OpenSSL that is compatible with Apples architecture. After the installation, we need to link it, so that it overrides the default openssl command (we have not noticed any issues with overriding this command, but be cautious).

# sh

brew install openssl@1.1 # possibly already installed on your system

brew link openssl@1.1 --force

echo 'export PATH="/opt/homebrew/opt/openssl@1.1/bin:$PATH"' >> ~/.zshrc

source ~/.zshrc

After the installation, we have to link openssl@1.1. If brew link openssl@1.1 --force does not work you can execute the last two commands. Note that if you do not have zsh, but must replace the ~/.zshrc with your shell-specific rc.

To double-check if the correct version is installed, you need to restart your terminal session and run the following command:

# sh

openssl version

# OUTPUT: OpenSSL 1.1.1 ...

Step 2: Installing other dependencies

After installing OpenSSL, we can now install the easier dependencies by running the following command:

# sh

brew install libsodium zeromq

This will simply install libsodium and zeromq.

Step 3: Installing libindy

Hyperledger provides some libindy build, but the one for Apple is built for intel x86_64. We have built libindy for Apple architecture, arm64, and is located here.

Open your downloads folder and /usr/local/lib (create it, if it does not exist)

Drag the downloaded file libindy.dylib to /usr/local/lib. In this Finder window, click on libindy.dylibwith control + click and click on open. This is a weird quirk in macOS to be able to use this file.

Step 4: Checking if it all worked

To check if your installation worked, execute the following commands:

#sh

npx -p @aries-framework/node is-indy-installed

# output
# Libindy was installed correctly

Well done! You have now installed Libindy. Have fun using Aries Framework JavaScript! If you want some pointers on how to work with it, check out Issuing a Verifable Credential in 7 Easy Steps.

Verifiable credentials are getting easier and easier to work with. In this piece, we’re going to show you how to issue a verifiable credential using Aries Framework JavaScript in around 100 lines of code. To see and copy the code, you can see this repo to run it yourself.

Imagine you just purchased a gold tier gym membership from a new gym in your neighborhood. This gym is modern and sleek and makes an effort to embrace new technologies, so they’re using a new membership system. Instead of a plastic card that proves you are a member, you are going to receive a verifiable credential on your phone!

First we’re going to create a holder Agent, this will be the Agent that receives the membership credential. During their life, the holder will collect many different verifiable credentials. Memberships, ID-cards, even purchasing records. Anything a person might need to prove something about themselves can be a verifiable credential they can store on their phone.

We now need a second party, the gym itself, this will be our second Agent. They will be the ones that issues the membership credential to your holder agent. In classic terms where you (the member) are the ‘holder’, the gym will be the ‘issuer’.

Our two Agents need to have a connection to exchange information. To create a connection between them, the issuer Agent will send an invitation to connect to the holder Agent.

The holder Agent will need to receive and accept this invitation to establish the connection. Once our two parties are connected, they can use that connection for different purposes like communicating, requesting and sending proofs and (of course) issuing credentials.

Now we’re getting to the exciting stuff. The gym will need to define what attributes are a part of their membership, they need to create a schema for the credential they are going to issue. An ID credential might contain your first name, last name, citizen number, nationality etc. This gym membership only contains a starting date and a tier, so we’ll create a schema with those values.

While the schema defines the attributes of the credential (‘Start date’ and ‘Tier’), the credential definition links the schema to the issuers DID (Decentralized Identifier). Now the holder will always be able to prove that the gym issued the credential, as it is connected to their organizational DID

The credential definition has been created and registered. To give you the credential, the issuer Agent will offer it to your holder Agent, who will then decide whether to accept. On your phone this could be in the form of a popup or notification in your personal digital wallet app. To show the holder Agent what they are accepting/rejecting, the issuer will create a preview of the credential and send it along with the credential offer.

The holder Agent is listening for change, and can accept the credential when it is offered. After this they are now the owner of the verifiable credential. The holder Agent can use it to prove to anyone asking that they are a member of this particular gym.

Great job! We’ve seen two Agents establishing a connection, one of them offering a credential and the other accepting it. All in 7 easy steps.

To run this code yourself, check out this repo. It contains some additional config, setup and logging so you can run it all in one go, but you’ll see that the code is largely the same as the steps above.

Aries Framework JavaScript is a great framework for those starting with development around verifiable credentials. The framework is constantly being improved with accessibility and ease of use in mind, so make sure to keep an eye on it.

By Timo Glastra.

Both on company time and in my personal time, I spend a lot of time contributing to Aries Framework JavaScript. So much so that it has become a bit of a joke between colleagues how much I care for the framework. They’re probably right. I believe Aries Framework JavaScript has the potential to become one of the key tools to making self-sovereign identity development truly accessible for everyone.

If you haven’t heard about Aries Framework JavaScript (AFJ), it is a framework written in TypeScript for building self-sovereign identity (SSI) agents that aims to be compliant and interoperable with the standards defined by Hyperledger Aries. Even though the framework does not have all features you’d expect from an Aries implementation yet, the growth of the framework towards a fully functional and multi-platform option for self-sovereign identity solutions has been a large focal point for us. Now with AIP 1.0 practically supported, and multiple organizations using it, the value is becoming more visible to others as well. We’ve seen a lot of interest in the framework from organizations looking for an accessible, cross-platform, and open-source option for SSI development.

In this post, I’ll give an overview of why Animo chooses to develop our solutions on Aries Framework JavaScript, where it stands today, and why it might be a good fit for your use case. You’ll find out why I choose to spend my evenings contributing and hopefully you’ll even agree. First up, what are the benefits of AFJ for agent development?

It is Cross Platform

One of the main challenges still existing in agent development is the limited number of accessible options for development in different platforms. Aries Framework JavaScript takes away the complexities and allows you to reuse code across implementations. It provides the building blocks to bootstrap your SSI solution, whether it is a mobile wallet built in React Native, a desktop application built in Electron, or a server-side cloud agent built in Node.JS. AFJ doesn’t pick sides.

When working on innovative SSI solutions, we don’t want to be restricted by a single platform or tool. We want our developers (as well as our customers) to have an accessible, easy-to-use, and open-source foundation to build anything they envision on.

At the moment, the main interest in the framework is for developing cross-platform mobile wallets for iOS and Android using React Native. AFJ can be used with React Native Indy SDK, allowing you to write your business logic once instead of twice.

JavaScript is a Popular Language

It may seem weird to promote a framework because it is written in a popular programming language. The general belief is that you should pick the language best suited for your use case. However, the current level of self-sovereign identity adoption means that for now the programming language *does* matter. If you don’t have engineers that can build out a specific framework, or build on top of it, you won’t get far.

JavaScript is the most popular language according to the StackOverflow Developer Survey 2020. Although the language has its quirks, it is a very accessible language that a lot of developers are familiar with. And the usage of TypeScript on top of JavaScript helps us catch mistakes early, making the development process more efficient (my love for TypeScript is another thing that is well known around our office)

A great example is what happened with the transition of the Coinbase iOS and Android apps from native to React Native. They were having a hard time finding mobile engineers in comparison to web engineers. The transition to a web-based programming language allowed them to easily train their web engineers to be effective mobile engineers.

Focused on ease of use

The goal that we’re trying to achieve with Aries Framework JavaScript is to make it as easy as possible to get started, without the need to rely on proprietary code. Documentation is crucial to making the framework easy to use. In the past we’ve been (rightly) called out multiple times that there was no documentation, or that the documentation was outdated. This is something that commercial products often do right, they invest the time to make their products usable, as that’s how they make their money. We recently did a complete overhaul of the documentation (check out the Getting Started guide), and other contributors are actively working to extend the documentation.

There’s a long way to go, and we’re still hard at work to improve the developer experience of the framework, but we think emphasizing ease of use from the start will help us stay focused on the overall goals. Over time, the framework will transform into more and more of a “plug and play” experience, allowing developers to pick and choose which functionalities best suit their project.

Take for example the code block below. Only 16 lines of code to both set up your agent and receive a connection invitation. Depending on if the other agent responds immediately ( autoAcceptConnections is set to true), the connection is ready to use in a matter of seconds. This is a great example of some simple code that doesn’t require you to do a deep dive, we’re trying to automate as much as possible.

Interoperability

Interoperability is key for SSI. That’s why we’ve taken interoperability testing serious from the beginning. Thanks to the Aries Agent Test Harness, Aries Framework JavaScript is tested for interoperability against other open-source Aries implementations every day. If something breaks, we’ll get notified immediately, allowing us to move fast without breaking things (in contrast to the famous “Move Fast and Break Things” motto from Mark Zuckerberg).

On the Aries Framework JavaScript Interoperability page, you can get an up-to-date overview of the interoperability of AFJ against other Aries implementations. I’ve also been involved with the .NET and ACA-Py test harness back channels, so Aries Agent Test Harness could be considered another favorite of mine. It’s great to see the growing amount of connected frameworks, and it really puts a visual to what interoperability means.

Open source collaboration

At Animo, we think a self-sovereign identity should be accessible to everyone, which also means the code that powers it should be open source. Truly open source. It takes time to build a community around open-source tools, but once established, everyone benefits from it.

The power of open source collaboration is already noticeable with Aries Cloud Agent Python (ACA-Py), one of the largest open-source Aries implementations. Although mainly powered by the Government of British Columbia, ACA-Py has attracted pretty large open-source contributions from companies such as SICPA, BMW, and Indicio. Aries Framework JavaScript is not yet near ACA-Py contributor-wise, but it has gained a lot of traction lately. The community has been making more new contributions, and we’re starting to see some cool projects built on top of it.

To give you an idea of what is happening on the implementer side of Aries Framework JavaScript I’ve included examples of some of these projects.

Cardea

One of the new projects build on top of Aries Framework JavaScript is the Cardea project, a complete ecosystem for the exchange of privacy-preserving digital credentials, open-sourced as a project in Linux Foundation Public Health (LFPH). The Cardea holder wallet and Cardea verifier app are both powered by Aries Framework JavaScript.

Privacy-first COVID verification technology takes a giant step forward with Cardea

United Nations International Computing Centre

Another project worth mentioning is the United Nations Digital ID. The United Nations International Computing Centre (UNICC) recently presented the UN Digital ID. They also announced it will use Aries Framework JavaScript for the mobile wallet implementation.

UNICC's CTO Shashank Rai Presents UN Digital ID at Hyperledger Social Impact Special Interest Group - UNICC

Student Projects (HU University of Applied Sciences)

Although some big projects are starting to look at Aries Framework JavaScript, the whole point of this blog was to highlight its accessibility. Through a collaboration with the Hogeschool Utrecht, Animo has been able to launch several student projects that use AFJ. Asking young software developers that are inexperienced with SSI and relatively new to development in general has allowed us to really pinpoint the weak points of the framework. The struggles of student teams working on implementations for smart locks, patient records, and age verification has shown us what needs to be fixed. We’ve seen some amazing results and creativity because of their efforts.

So we’ve seen the benefits and some implementations of Aries Framework JavaScript. What is our focus for the future? The framework is starting to be used for more and more production use cases, and the extra contributors allow us to add more features.

We’re currently mostly focusing on support for Aries Interop Profile 1.0 (AIP), of which you can already use a lot in AFJ. Besides the focus on AIP 1.0, the Aries Framework JavaScript contributors are also working on some extra features. Let’s highlight some of them.

Auto Acceptance of Credentials and Proofs

One feature we’re currently working on is the auto-acceptance of credentials and proofs. This will make it even easier to get started building your agent. Connections already have the auto-acceptance feature, and this is the reason the code example earlier in this post was only a few lines of code. The agent automatically handles the required steps to complete the connection.

Credentials and proofs are a bit more complex as most of the time you want something in between auto-acceptance and doing everything manually. You want to check the content once, and then let the agent automatically handle the exchange for you. If, for example, the issuer suddenly changes the attributes of the credential during the exchange, the auto-acceptance is canceled. This is different from how most agents implement it today and makes auto-acceptance a feature you can use in production environments.

Mediation

Another feature being worked on is full mediator support according to the open standards. Aries Framework JavaScript includes a sample mediator that you can use to route messages, however, the mediator can only be used for agents built on top of AFJ and is not built for production use cases. With support for mediation according to the standards, you can use the production-ready mediator agent built into Aries Cloud Agent Python to route messages to mobile devices.

We’re pretty excited about this contribution from Indicio and look forward to start using it ourselves.

Connection-less issuance and verification

As the name suggests, connection-less issuance and verification allows you to issue and verify credentials without making a connection with the other agent first. This is ideal for situations where you don’t want to create a long-lasting relationship, such as issuing event tickets, accessing a building, or verifying your age online.

All the features mentioned above (auto acceptance of credentials and proofs, mediation, and connection-less issuance and verification) are already implemented in AFJ and will be released soon.

In conclusion, if you have a use case that could use a cross-platform, easy-to-use and, open-source solution with a focus on interoperability, look no further! Aries Framework JavaScript undoubtedly has something to offer you and your development needs.

If you want to join the discussion you can join the Aries Framework JavaScript Working Group call every Thursday at 07:00 MT / 14:00 UTC (zoom link: https://zoom.us/j/92215586249?pwd=Vm5ZTGV4T0cwVEl4blh3MjBzYjVYZz09)

If you just want to get started building on Aries Framework JavaScript, check out the GitHub repository or shoot me an email at timo@animo.id (when Aries Framework JavaScript is concerned I’m always happy to talk). I’m eager to hear how you want to use the framework.

hyperledger/aries-framework-javascript

In a future blog post we’ll go into more detail on the long-term roadmap for AFJ, including support for Aries Interop Profile 2.0, adopting the new shared components libraries (aries-askar, indy-vdr, and indy-credx), and supporting BBS+ credential exchange.