Current way to run client demo (docker?)


I’m trying to run through a full client workflow with sample agents and claims on a Sovrin network (of any kind, local or test or prod). I’ve been able to set up a session using the Docker environments here:

However, that page refers to “the Sovrin Tutorial (about Emily, her transcripts, job and bank)” which is a tutorial I cannot find. It may mean the the Alice “getting started” doc at but that uses commands like new keyring Alice which gives me an Invalid command error, and it doesn’t seem to have access to any faber-invitation.sovrin files. Or maybe this is all out-of-date.

(I’ve been unsuccessful with other approaches with Vagrant/building on Ubuntu/RHEL/MacOS with indy-sdk/indy-common… the binaries seemed to install on Ubuntu but then there there are other errors running the app.)

So… if the docker approach works then I’d love to hear how to run through the tutorial with it; if not, I’ll try whatever method is recommended as the latest. Thanks!


(PS: this may also help @turmewr3ck here Unable to connect: status is continually "Attempting connection")


It sounds like you’ve uncovered a loose end that is stale. I’m fairly certain that the tutorial about Emily is supposed to be a reference to the tutorial about Alice (Getting Started). I believe the “new keyring Alice” command was updated with the Sovrin release at the end of July, such that “new wallet Alice” is now what’s expected. Clearly we need to get some verbiage updated. I apologize for the confusion.

The vagrant approach should work fine, and that is the preferred and best supported one.

I’m not familiar with the indy-sdk approach that you refer to. I helped design the sdk, however–can I help you troubleshoot something with it?


@trentlarson You might consider emailing support [at] for interactive help getting past the hurdles here…


Thanks for the info!

The indy-sdk I mean is this:
… to which indy-client points and says it will be subsumed by, and indy-node says documentation will be part of indy-sdk in the future.

When you say “sdk”, which one do you mean?

In case you can help with Vagrant: when I try vagrant box add boxcutter/ubuntu1604 it fails with the following:

The box 'boxcutter/ubuntu1604' could not be found or
could not be accessed in the remote catalog. If this is a private
box on HashiCorp's Vagrant Cloud, please verify you're logged in via
`vagrant login`. Also, please double-check the name. The expanded
URL and error message are shown below:

URL: [""]
Error: The requested URL returned error: 404 Not Found

I get this on Vagrant 2.0.0 (and I also got it on 1.8.7 before upgrading), on MacOS. I’m gonna look at the build instructions for boxcutter next… I realize this may be some basic Vagrant understanding I’m missing, though I’ve used it before.


Well, I finally got past that error:

  • downloaded the build and do the following inside that dir
  • packer build -var-file=ubuntu1604.json ubuntu.json
  • vagrant box add box/virtualbox/ --name boxcutter/ubuntu1604

It really seems that the boxcutter/ubuntu1604 box is not just available by default… at least in my world.


OK, I’m continuing with the original task of running the client demo.

I’ve got Vagrant running, I’m able to begin the sovrin story from the indy-client “Getting Started”, and I’ve added the Faber invitation file.

When I load I get this:

sovrin@test> load sample/faber-invitation.sovrin
sovrinb7ae2d is already started, so start has no effect
No connection request found in the given file


(BTW, I’m glad you mentioned the new wallet instead of keyring, and there are other commands in that script that are no longer available such as accept invitation and show link (now show connection?) and most things in the Appendix, so hints there would help. EDIT: to fix this “BTW” stuff, I found there’s a “Getting Started” under indy-node which looks more up-to-date than the indy-client one I found above.)


Here are some current instructions for exercising Sovrin entirely through the SDK, with a docker-backed pool instead of the production Sovrin ledger. These instructions are current as of Sep 7, 2017.

These steps assume setup in PyCharm on Ubuntu 16.04 64-bit of indy-sdk/samples/python project demonstrating use of libindy via its python wrapper:

  • Clone the repository
  • Open indy-sdk/samples/python as a project in PyCharm.
  • Create a new python virtual environment:
  • Open Settings -> Project: python -> Project Interpreter.
  • Click Gear icon to the right from Project Interpreter field and click Create VirtualEnv item in the shown menu.
  • Enter the name and location for the new python virtual environment, select Python 3.5 as the base interpreter and click OK.
  • Click OK in Settings dialog.
  • Re-open the project for all the IDE tool windows to catch the project interpreter update.
  • Replace python3-indy with python3-indy==1.0.0-dev-171 in This is needed to get the recent python wrapper version that is compatible with Python 3.5. This step is needed only until the next stable version of indy-sdk is released.
  • In Terminal tool window ensure that the project directory is current and execute: pip install -e .
  • Download libindy_<X.X.X>_amd64.deb file from the latest version directory at
  • Extract file from /CONTENTS/usr/lib directory of the downloaded deb package.
  • Put file into the project directory.
  • Create Python run configuration for src/
  • Specify the project directory (where is located) as the working directory in settings of the created run configuration.
  • Install Docker.
  • In indy-sdk root directory execute:
docker run -itd -p 9701-9709:9701-9709 indy_pool```
* In the project opened in PyCharm run the created configuration.

The steps for setup of a new python project using libindy via its python wrapper (e.g. a project containing system tests) are similar:

* Create a new python project in PyCharm (and also create a new virtual environment based on Python 3.5 in the project creation dialog).
* In Terminal tool window ensure that the project directory is current and execute: pip install python3-indy==1.0.0-dev-171
* When the next stable version (compatible with Python 3.5) of indy-sdk is released, there will be no need to specify the version. The command will be: ```pip install python3-indy```
* Download libindy_<X.X.X>_amd64.deb file from the latest version directory at
* Extract file from /CONTENTS/usr/lib directory of the downloaded deb package.
* Put file into the project directory.
* Every time you create a run/debug configuration, specify the project directory (where is located) as the working directory in settings of that configuration.


OK, I’ve finally worked through the demo successfully, with Vagrant, with the notes above plus this PR.

Note that the PR corrects links to old docs so I recommend getting those changes in soon. (Flash back to my 3 other attempts over this past year, where I have tried building and running these tools in multiple ways on multiple environments and I never got through the demo; I’ve tried the Vagrant approach before but when some of the current docs point to old docs… well, it’s hard to tell what is new vs what is a helpful hint that still applies vs what is just plain out-of-date. I know that goes without saying at this point in the project and I respect all you’ve done to move :mount_fuji:! It may be worth considering release packages already, if it’s possible to have a consistent set of versions of the repos… though I realize there’s an impact. So many details. OK, rant over. Cheers!)

@danielh Thank you very much… that looks like it’ll be helpful for my next steps.


We very much appreciate the PR. Thank you.

Also, it appears the Vagrant box that we were using has recently been pulled from Vagrant Cloud, which resulted in the error you noted. I’ve identified and tested a different box, and the Vagrant environment has been updated accordingly.

Release .deb packages are available–the Vagrant environment sets up the repositories and then installs the specific packages. If you are interested, you may want to look at the script(s) being called by the VagrantFile to see what is being done to prep the environment.

Regarding the documentation, the fast pace of the project has certainly left some detritus in its wake. We appreciate you pointing it out where you’ve found it (and providing the PR), and we’ll continue to look for it as well, as it certainly does cause confusion.



Random note: my system couldn’t get to the bento box either. So I’ve added this suggestion (which built it fine for me).

On the .deb and VagrantFile suggestion: the vagrant add step was before any references to a Vagrantfile, so I don’t quite follow. Is that a tip for accessing that Vagrant box? If so, can you walk me through how I might use that?


@trentlarson - So sorry about the “Emily” reference - that was supposed to be Alice in my PR. There was also subsequent PR that broke the Markdown on the docker document (looks like that’s fixed now). Other than that, the process works pretty well in docker following those steps. We’ve had a number of people using it successfully.

Sorry the straight docker didn’t work for you.


Actually, before I figured out the doc discrepancies, I got furthest with the Docker setup… and I may try again now that I can have success with the Vagrant setup. If I do, maybe you can help: I don’t see the “sample” files in the docker containers, so I have problems trying to run the “show” and “load” commands in the sovrin REPL. My first thought is to do adjust my setup to mount some directory somehow (I’m a Docker newbie)… but if you know an easy way to work on those test files then I’m all ears. (Hm… or maybe the Docker setup isn’t meant for that approach and it’s better to use from direct SDK accesss?) Thanks.


In late July, the Sovrin terminology changed, which affected the Alice script - e.g. in the commands “keyring” became “wallet”, “identity” became “DID”, “invitation” became “request” and a couple of other changes. As well, the file names changed. I’m not finding the newest names, but have to run. Anyway - as you hit issues, let me know and I’ll try to help.