hyperledger/indy-vdr

A library and proxy server for interacting with Hyperledger Indy Node ledger instances

Indy-VDR (Verifiable Data Registry)

• Introduction
• Features
• Building from Source
• Wrappers
• Proxy Server
• Connecting to a Ledger
• How to Contribute

Introduction

This library is derived from Hyperledger Indy SDK for the more limited use case of connecting to an Indy Node blockchain ledger. It is written in Rust and currently includes a Python wrapper and a standalone proxy server.

This library is still in development and there are currently no standard release packages.

Features

Indy-VDR can be used to connect to one or more Indy Node ledger pools given sets of genesis transactions. Methods are provided to construct ledger requests and send them to the validators, collecting the results and ensuring that there is a consensus between the nodes.

Building from Source

First, you must have Rust installed. For development, we recommend VS Code with the RLS plugin.

The library and proxy server can be built by running cargo build in the root directory. To build only the library, use cargo build --lib. You can add --release to produce smaller, faster binaries but with less information available for debugging purposes.

This should compile and place the shared library and indy-vdr-proxy executable in the target/debug subdirectory. The library will be named as libindy_vdr.so on Linux, libindy_vdr.dll on Windows, and libindy_vdr.dylib on Mac OS.

Wrappers

The Python wrapper is located in wrappers/python/indy_vdr. In order for the wrapper to locate the shared library, the latter may be placed in a system shared library directory like /usr/local/lib. Otherwise, the location of the shared library must be added to the appropriate environment variable for your platform: PATH for Windows, LD_LIBRARY_PATH for Linux or DYLD_LIBRARY_PATH for Mac OS.

At a later stage it should be possible to install a precompiled 'wheel' package for your platform using pip install indy_vdr, but at the moment it is necessary to build the library from source.

Proxy Server

The indy-vdr-proxy executable can be used to provide a simple REST API for interacting with one or more Indy ledgers. Command line options can be inspected by running indy-vdr-proxy --help.

To start the proxy server for a single ledger use the following command:

indy-vdr-proxy -p <PORT> (-g <OPTIONAL_PATH_TO_GENESIS_FILE>)

To start the proxy server with the standard configuration of indy ledgers use the following command: indy-vdr-proxy -p <PORT> -- --multiple-ledgers This will get the ledger configuration from https://github.com/IDunion/indy-did-networks

A custom ledger configuration can be provided either by specifying a Github repo or a local folder:

indy-vdr-proxy -p <PORT> -g <GITHUB_URL or PATH_TO_FOLDER> -- --multiple-ledgers

The structure needs to be as follows <NAMESPACE>/OPTIONAL<SUB_NAMESPACE>/pool_transactions_genesis.json, e.g. /sovrin/staging/pool_transactions_genesis.json

Responses can be formatted in either HTML or JSON formats. HTML formatting is selected when the text/html content type is requested according to the Accept header (as sent by web browsers) or the request query string is set to ?html. JSON formatting is selected otherwise, and may be explicitly selected by using the query string ?raw. For most ledger requests, JSON responses include information regarding which nodes were contacted is returned in the X-Requests header.

Sending prepared requests to the ledger is performed by delivering a POST request to the {LEDGER}/submit endpoint, where the body of the request is the JSON-formatted payload. Additional endpoints are provided as shortcuts for ledger read transactions:

• / Return configured ledgers
• {LEDGER}/ Basic status information about the server and the ledger pool
• {LEDGER}/genesis Return the current set of genesis transactions
• {LEDGER}/taa Fetch the current ledger Transaction Author Agreement
• {LEDGER}/aml Fetch the current ledger Acceptance Methods List (for the TAA)
• {LEDGER}/nym/{DID} Fetch the NYM transaction associated with an unqualified DID. Can be used with timestamp or seq_no query parameters to fetch specific versions
• {LEDGER}/attrib/{DID}/endpoint Fetch the registered endpoint for an unqualified DID
• {LEDGER}/schema/{SCHEMA_ID} Fetch a schema by its identifier
• {LEDGER}/cred_def/{CRED_DEF_ID} Fetch a credential definition by its identifier
• {LEDGER}/rev_reg/{REV_REG_ID} Fetch a revocation registry by its identifier
• {LEDGER}/rev_reg_def/{REV_REG_ID} Fetch a revocation registry definition by its registry identifier
• {LEDGER}/rev_reg_delta/{REV_REG_ID} Fetch a revocation registry delta by its registry identifier
• {LEDGER}/auth Fetch all AUTH rules for the ledger
• {LEDGER}/auth/{TXN_TYPE}/{ADD|EDIT} Fetch the AUTH rule for a specific transaction type and action
• {LEDGER}/txn/{SUBLEDGER}/{SEQ_NO} Fetch a specific transaction by subledger identifier (0-2, or one of pool, domain, or config) and sequence number.

If the proxy server is used with a single ledger, the {LEDGER} part of the path must be omitted.

DID:Indy Resolver

Indy VDR contains a DID Resolver to resolve DIDs and dereference DID Urls to ledger objects from configured ledgers according to the did:indy specification.

GET /1.0/identifiers/{DID or DID_URL}

Connecting to a Ledger

Whether using the library or the proxy server, you will need a genesis.txn file containing the set of pool genesis transactions. You can run a local pool in Docker using VON-Network or follow the Indy-SDK instructions.

However the library is used, the RUST_LOG environment variable may be set in order to adjust the volume of logging messages produced. Acceptable values are error, warn, info, debug, and trace. The RUST_BACKTRACE environment variable may also be set to full for extended output in the case of fatal errors.

How to Contribute

• Join us on the Hyperledger Discord. Guidance at chat.hyperledger.org.
• Developer certificate of origin (DCO) are required in all Hyperledger repositories, so to get your pull requests accepted, you must certify your commits by signing off on each commit. More information can be found in Signing Commits article.

indy-vdr's Issues

replies which do not verify can be returned as ok

If more than min_consensus(total_nodes_count) nodes return a reply, and those replies cannot be verified by check_state_proof, then as a result of consensus.rs line 81, the non-verified reply will be returned by indy-vdr anyway to the caller, as an OK result.

Indy-SDk has the same problem, see https://jira.hyperledger.org/browse/IS-1502

I found this while trying to do lookups on the audit ledger of the Builder Net, i.e. fetches to indy-vdr-proxy of the form: http://localhost:3030/txn/3/1

Create design doc for indy-vdr

Can't generate libs on Alpine

Compiling libindy_vdr on rust-alpine gives me the following warning (among other syntactical warnings) :

warning: dropping unsupported crate type cdylib for target x86_64-unknown-linux-musl

As expected the cdylib is not present under the target folder.

I successfully recreated the error with the following Dockerfile:

FROM rust:1.57-alpine3.14

RUN apk update
RUN apk add git g++ make cmake

RUN git clone https://github.com/hyperledger/indy-vdr.git

WORKDIR indy-vdr/libindy_vdr

RUN git checkout tags/v0.3.3
RUN cargo build --lib

RUN ls ../target/debug

Contents of target/debug:

build
deps
examples
incremental
libindy_vdr.a
libindy_vdr.d
libindy_vdr.rlib

Cargo build warnings:

warning: dropping unsupported crate type `cdylib` for target `x86_64-unknown-linux-musl`

warning: trailing semicolon in macro used in expression position
   --> libindy_vdr/src/utils/macros.rs:78:10
    |
78  |         };
    |          ^
    |
   ::: libindy_vdr/src/pool/genesis.rs:157:24
    |
157 |         let vec_json = unwrap_or_return!(self.encode_json(), Err(std::fmt::Error {}));
    |                        -------------------------------------------------------------- in this macro invocation
    |
    = note: `#[warn(semicolon_in_expressions_from_macros)]` on by default
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
    = note: this warning originates in the macro `unwrap_or_return` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: trailing semicolon in macro used in expression position
   --> libindy_vdr/src/utils/macros.rs:69:10
    |
69  |           };
    |            ^
    |
   ::: libindy_vdr/src/state_proof/mod.rs:299:48
    |
299 |           let (signature, participants, value) = unwrap_opt_or_return!(
    |  ________________________________________________-
300 | |             _parse_reply_for_proof_signature_checking(&parsed_sp.multi_signature),
301 | |             {
302 | |                 debug!("Reply parsing failed");
303 | |                 false
304 | |             }
305 | |         );
    | |_________- in this macro invocation
    |
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
    = note: this warning originates in the macro `unwrap_opt_or_return` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: trailing semicolon in macro used in expression position
   --> libindy_vdr/src/utils/macros.rs:78:10
    |
78  |           };
    |            ^
    |
   ::: libindy_vdr/src/state_proof/mod.rs:313:27
    |
313 |           let proof_nodes = unwrap_or_return!(base64::decode(&parsed_sp.proof_nodes), {
    |  ___________________________-
314 | |             debug!("Error decoding proof nodes from state proof");
315 | |             false
316 | |         });
    | |__________- in this macro invocation
    |
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
    = note: this warning originates in the macro `unwrap_or_return` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: trailing semicolon in macro used in expression position
   --> libindy_vdr/src/utils/macros.rs:78:10
    |
78  |           };
    |            ^
    |
   ::: libindy_vdr/src/state_proof/mod.rs:317:25
    |
317 |           let root_hash = unwrap_or_return!(base58::decode(parsed_sp.root_hash), {
    |  _________________________-
318 | |             debug!("Error decoding root hash from state proof");
319 | |             false
320 | |         });
    | |__________- in this macro invocation
    |
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
    = note: this warning originates in the macro `unwrap_or_return` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: trailing semicolon in macro used in expression position
   --> libindy_vdr/src/utils/macros.rs:78:10
    |
78  |           };
    |            ^
    |
   ::: libindy_vdr/src/state_proof/mod.rs:325:35
    |
325 |                           let key = unwrap_or_return!(base64::decode(&k), {
    |  ___________________________________-
326 | |                             debug!("Error decoding proof key");
327 | |                             false
328 | |                         });
    | |__________________________- in this macro invocation
    |
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
    = note: this warning originates in the macro `unwrap_or_return` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: trailing semicolon in macro used in expression position
   --> libindy_vdr/src/utils/macros.rs:87:10
    |
87  |           };
    |            ^
    |
   ::: libindy_vdr/src/state_proof/mod.rs:947:18
    |
947 |       let seq_no = unwrap_or_map_return!(seq_no, |err| {
    |  __________________-
948 | |         debug!("Error while parsing merkle tree seq_no: {}", err);
949 | |         false
950 | |     });
    | |______- in this macro invocation
    |
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
    = note: this warning originates in the macro `unwrap_or_map_return` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: trailing semicolon in macro used in expression position
   --> libindy_vdr/src/utils/macros.rs:87:10
    |
87  |           };
    |            ^
    |
   ::: libindy_vdr/src/state_proof/mod.rs:972:20
    |
972 |       let mut hash = unwrap_or_map_return!(hash, |err| {
    |  ____________________-
973 | |         debug!("Error while hashing merkle tree leaf: {:?}", err);
974 | |         return false;
975 | |     });
    | |______- in this macro invocation
    |
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
    = note: this warning originates in the macro `unwrap_or_map_return` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: trailing semicolon in macro used in expression position
   --> libindy_vdr/src/utils/macros.rs:78:10
    |
78  |           };
    |            ^
    |
   ::: libindy_vdr/src/state_proof/mod.rs:980:26
    |
980 |           let _next_hash = unwrap_or_return!(base58::decode(next_hash), {
    |  __________________________-
981 | |             debug!("Error decoding next hash as base58");
982 | |             false
983 | |         });
    | |__________- in this macro invocation
    |
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
    = note: this warning originates in the macro `unwrap_or_return` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: trailing semicolon in macro used in expression position
   --> libindy_vdr/src/utils/macros.rs:87:10
    |
87  |           };
    |            ^
    |
   ::: libindy_vdr/src/state_proof/mod.rs:989:16
    |
989 |           hash = unwrap_or_map_return!(turned_hash, |err| {
    |  ________________-
990 | |             debug!("Error while hashing: {:?}", err);
991 | |             return false;
992 | |         })
    | |__________- in this macro invocation
    |
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
    = note: this warning originates in the macro `unwrap_or_map_return` (in Nightly builds, run with -Z macro-backtrace for more info)

warning: `indy-vdr` (lib) generated 10 warnings
    Finished dev [unoptimized + debuginfo] target(s) in 2m 37s

Add example app to indy vdr for React Native

Because we can not have tests right now for the React Native wrapper, we can add an example app with some buttons to execute the code and make sure it works.

It MUST be an Expo app to keep the repo a lot smaller and should work with the latest version of RN and Expo.

build library for iOS and Android

in order to create a wrapper for iOS and Android, via react native, I must have the libraries built for iOS and Android. I can pick this up and already have the build scripts in a Makefile so it will just be converting it into a GitHub Action.

This is not really an issue but more of an update on what's coming and to track progress.

Indy-shared crate?

In my current refactoring PR I've added a vdr-shared crate containing some utilities and traits that are used by both the library and the integration tests, because the integration tests can only use public exports from the indy-vdr crate. Currently this includes the following:

• base58 encode/decode
• sha2 hashing (via Ursa)
• ed25519 verkey derivation (via Ursa)
• Qualifiable and Validatable traits, and ValidationError
• test code to create genesis transactions

I think it makes sense to expand this with the Indy identifier and ledger data types (SchemaId, CredentialDefinitionId, .. Schema, CredentialDefinition ..) as those are also used in credx, and would be used in the storage backend as well. The DID and Verkey handling code would probably go there as well, and maybe MerkleTree. Then this might be published as a separate crate (and maybe Hyperledger project) to be used as a dependency. I believe the SDK has a similar setup internally.

Are there any practical or technical reasons not to do this?

@Artemkaaas @jovfer @esplinr @swcurran

Release Indy VDR for React Native to NPM

Continuation of #113, but focuses on the React Native implementation

The iOS & Android build is currently broken and needs some extra work.

TODO

• add iOS build -> moved to separate task (#122)
• add Android build
• Fix react native setup (check if it works with node-pre-gyp paths)
• Add example app for react native

Revocation wrappers commented out?

https://github.com/andrewwhitehead/indy-vdr/blob/414b1903c2a9efb99ee2a9e6c844394f822ca094/indy-vdr-proxy/src/handlers.rs#L184

partial rewrite of the nodejs wrapper

Right now I am working on the react native wrapper for indy-vdr. I noticed that there is a wrapper for nodejs, but it seems a bit outdated, I could be wrong here. In order to have a consistent api with the react native side, as these wrappers both will be used by AFJ this is rather essential, we must do a partial rewrite of this wrapper.

@Patrik-Stas Do you have any concerns with this, as you are the main author of the wrapper?

The only changes that will probably be made, still have to do a deeper dive into this, are a consistent api and make use of the shared interfaces between the upcoming react native wrapper and nodejs.

I will also make sure that both packages will be properly released on npm.

Debugging output can cause panic

indy-vdr/libindy_vdr/src/pool/handlers/consensus.rs

Lines 90 to 94 in 36b2bd9

	debug!(
	"State proof verification succeeded for node: {}, sp_key: '{}'",
	node_alias,
	base64::encode(state_proof_key.as_ref().unwrap()),
	);

is reachable without a stateproof being present (by fullfilling cnt > f). If this happens with RUST_LOG set to debug, the library will cause a panic even though it is correct behavior to reach this point with state_proof_key being None if I understand correctly?

Happened while testing locally with a von-network and writing nym transactions with a small rust program using indy-vdr

• If i set logging to info then everything works as expected
• If i set logging to debug the application will panic on the first build_nym_request // perform_ledger_request

Removal of role fails with golang wrapper

Hello guys,

I'm currently trying to programmatically remove the role of a DID with the indy VDR golang wrapper. Sadly

err = client.CreateNym(nym.Dest, "", vdr.NoRole, c.serviceDid.DIDVal.MethodSpecificID, c.signature)

Sadly I receive the following error:
ERRO[0009] error from submitted request: (Indy error code: [0] {"code":31,"extra":"{\"op\":\"REJECT\",\"identifier\":\"86U8YCoQFXLu2qRC9spRiS\",\"reqId\":716439808,\"reason\":\"client request invalid: InvalidClientRequest('86U8YCoQF XLu2qRC9spRiS', 716439808)\",\"code\":null}","message":"Request failed: client request invalid: InvalidClientRequest('86U8YCoQFXLu2qRC9spRiS', 716439808)"})

If I change the role to vdr.NetworkMonitorRole (201) the same transaction works just fine and I can see the transaction in the ledger explorer:

err = c.client.CreateNym(nym.Dest, "", vdr.NetworkMonitorRole, c.serviceDid.DIDVal.MethodSpecificID, c.signature)

Type: NYM Nym: EWkYJruPjgXcmoHggPkWcV Role: 201 Verkey:

I'm using the following version of indy VDR Wrapper: github.com/hyperledger/indy-vdr/wrappers/golang v0.0.0-20210709184602-7a38fe8c85c4 and a local VON-Network

Update:

• I have reproduced the error with the latest version: github.com/hyperledger/indy-vdr/wrappers/golang v0.0.0-20210922000711
• I left the verkey empty because otherwise I'll get an error, even if the verkey is still exactly the same as it was before

I looked into the VDR code and to me it looks like a JSON serialization issue. In vdr/requests.go the Nym struct has an 'omitempty' tag on the Role field. Hence I presume the role field is not added to the request at all instead of adding it empty.

indy-vdr is unable to connect to a pool when some genesis nodes do not respond

In some cases indy-vdr will timeout connecting to a pool when one or more of the pool's genesis nodes does not respond.

Scenario:

• indy-vdr versions tested: 0.1.0 and 0.3.4
• Sovrin StagingNet
• Active Genesis Nodes:
  • Absa
  • DigiCert-Node
  • NECValidator
  • australia
  • regioit01
  • anonyome
• Connecting with indy-node-monitor in REST API mode.
• Access to DigiCert-Node is blocked (for a reason yet to be determined) from a given IP.

In the above case indy-vdr is unable to connect to the pool and continually times out.

A pool connection can be established and cached by the API by connecting to a different network via VPN and querying the nodes. Once the connection is cached and the VPN disconnected (returning to the blocked IP) additional queries can be made that indicate a node (DigiCert-Node in this case) is not responding. If the pool cache is cleared (the API restarted) indy-vdr is once again unable to connect to the pool.

I have tried to reproduce this issue with von-network with no success.

I have also tried excluding DigiCert-Node from the pool by using the node_weights like this:

pool = await open_pool(transactions_path=genesis_path, node_weights={'Absa':1.0,'australia':1.0,'regioit01':1.0,'anonyome':1.0,'DigiCert-Node':0.0})

However that always results in the following error whenever any node weight is set to zero:

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: AllWeightsZero', libindy_vdr/src/pool/pool.rs:172:14
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

This issue was reported and discussed at the 2022-10-25 Indy Contributors call

Release Indy VDR for Node.JS to NPM

TODO:

• Set up CI pipeline to build and release packages
• Add node-pre-gyp
• Add local path to the libPaths
• Remove rich schema related code
• submitAction feature parity

Flow

1. Run CI on creation of tag or something
2. Run tests
3. Build native binaries for different platforms and upload them to github somewhere
4. Build the javascript package, copy over the native binaries
5. Release all three packages (indy-vdr-shared, indy-vdr-react-native and indy-vdr-nodejs) to NPM

Responses from /submit endpoint not parseable with indy sdk (parseGetCredDefResponse, etc)

Hi All,

I am running Indy-vdr-proxy in a network where connecting directly to indy-sdk pool would be blocked (FW only allows HTTP/HTTPS egress, so ports 9700-9799 for Sovrin StagingNet are blocked).

The idea here, is that I leverage the indy-vdr-proxy client side to proxy out to ledger in a more favorable way with current security settings. In my client application, I am replacing indy Ledger/pool calls with calls to the proxy on the /submit endpoint. This seems to be working great as far as providing prepared messages, and getting responses out of the proxy.

The issue lies when I attempt to use the indy sdk to parse the message. For example:

Prepared message sent to proxy /submit
This is a get cred def ledger request

{"reqId":1599263022696669846,"identifier":"HAwm7Mvmsw3FGAeLLDwZtA","operation":{"type":"108","ref":137738,"signature_type":"CL","origin":"KuG6kY3i7RwmWV8B4HnWCs","tag":"testcadev9999123654"},"protocolVersion":2}

Response from vdr proxy /submit

{
  "data": {
    "primary": {
      "n": "...",
      "r": {
        "master_secret": "...",
        "name": "..."
      },
      "rctxt": "...",
      "s": "...",
      "z": "..."
    }
  },
  "identifier": "HAwm7Mvmsw3FGAeLLDwZtA",
  "origin": "KuG6kY3i7RwmWV8B4HnWCs",
  "ref": 137738,
  "reqId": 1599263022696670000,
  "seqNo": 137739,
  "signature_type": "CL",
  "state_proof": {
    "multi_signature": {
      "participants": [
        "trusted_you",
        "regioit01",
        "EBPI-validation-node",
        "NECValidator",
        "lab10",
        "DigiCert-Node",
        "ayanworks",
        "Swisscom",
        "Absa"
      ],
      "signature": "Qq1tHugcFCdzaMGbhcEUZGNAcJX6ef6UdSqnRUKWTvJW6U9TigzREznTpi5FFigHbKBjhaY6i14mZRjX88YtyHVaGC3GqWwVpVVPzuRH7xXeNsYVfDhppKxZLnuKkJqNsEjBBvHJsjicwQZjKWYooiZg5JnGGGpH4DXSYMJvnjmbNP",
      "value": {
        "ledger_id": 1,
        "pool_state_root_hash": "9qRu3pcAfutm79nKj43Uv2At5fnStdpQCKQUHtcno92H",
        "state_root_hash": "5WGmWr6UPkMQKENCLLG7DcddcALGRCa9U1xckQnQNSbs",
        "timestamp": 1599263188,
        "txn_root_hash": "8wsCiCwuSRhKXwVkKGjeg83quqa4zmSFYeAJVeQWDJsR"
      }
    },
    "proof_nodes": "...",
    "root_hash": "5WGmWr6UPkMQKENCLLG7DcddcALGRCa9U1xckQnQNSbs"
  },
  "tag": "testcadev9999123654",
  "txnTime": 1598415635,
  "type": "108"
}

Up until this point everything goes fine. However on my client application (making use of Java indy wrapper), I am making the following call with the above response
Client side indy java wrapper parsing call

LedgerResults.ParseResponseResult credObject= Ledger.parseGetCredDefResponse(response).get();

This call always fails with the following message being thrown by the indy-sdk:

exceptionjava.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.pool.LedgerNotFoundException: Item not found on ledger exception.

This error gets thrown deep inside libindy:

    pub fn parse_get_cred_def_response(&self, get_cred_def_response: &str, method_name: Option<&str>) -> IndyResult<(String, String)> {
        let reply: Reply<GetCredDefReplyResult> = LedgerService::parse_response(get_cred_def_response)?;

   //..................

    pub fn parse_response<T>(response: &str) -> IndyResult<Reply<T>> where T: DeserializeOwned + ReplyType + ::std::fmt::Debug {
        let message: serde_json::Value = serde_json::from_str(&response)
            .to_indy(IndyErrorKind::InvalidTransaction, "Response is invalid json")?;

        if message["op"] == json!("REPLY") && message["result"]["type"] != json!(T::get_type()) {
            return Err(err_msg(IndyErrorKind::InvalidTransaction, "Invalid response type"));
        }

        let message: Message<T> = serde_json::from_value(message)
            .to_indy(IndyErrorKind::LedgerItemNotFound, "Structure doesn't correspond to type. Most probably not found")?; // FIXME: Review how we handle not found

        match message {
            Message::Reject(response) | Message::ReqNACK(response) =>
                Err(err_msg(IndyErrorKind::InvalidTransaction, format!("Transaction has been failed: {:?}", response.reason))),
            Message::Reply(reply) =>
                Ok(reply)
        }
    }

The error message states Structure doesn't correspond to type. Most probably not found. Meaning there is likely some difference in what the vdr proxy gives back. Although I really can't see what the difference is based on the following structure:

pub enum GetCredDefReplyResult {
    GetCredDefReplyResultV0(GetCredDefResultV0),
    GetCredDefReplyResultV1(GetReplyResultV1<GetCredDefResultDataV1>)
}

impl ReplyType for GetCredDefReplyResult {
    fn get_type<'a>() -> &'a str {
        GET_CRED_DEF
    }
}

#[derive(Deserialize, Serialize, Debug)]
pub struct GetCredDefResultV0 {
    pub identifier: ShortDidValue,
    #[serde(rename = "ref")]
    pub ref_: u64,
    #[serde(rename = "seqNo")]
    pub seq_no: i32,
    pub signature_type: SignatureType,
    pub origin: ShortDidValue,
    pub tag: Option<String>,
    pub data: CredentialDefinitionData
}

#[derive(Deserialize, Debug)]
#[serde(rename_all = "camelCase")]
pub struct GetCredDefResultDataV1 {
    pub ver: String,
    pub id: CredentialDefinitionId,
    #[serde(rename = "type")]
    pub type_: SignatureType,
    pub tag: String,
    pub schema_ref: SchemaId,
    pub public_keys: CredentialDefinitionData
}

So my question is, is there some type of incompatibility/difference between ledger responses returned by indy-vdr-proxy vs indy-sdk (libindy) ? Is what I'm trying to do even possible? I honestly see no reason why it shouldn't work.

Please let me know if you can provide any answers.

Matt

[JS] Revocation registry entry request missing `revoked` and `issued` keys

JS Wrapper should wait with release until ios / android artifacts are published to the release

indy-shared-rs dependencies issues in vdr version 0.3.1 & 0.3.0

Running a cargo check on a project with an indy-vdr 0.3.1 or 0.3.0 dependency will fail to compile due to mismatching types. This has to do with the different versions of indy-data-types and indy-utils that indy-vdr depends on, which under certain circumstances can cause indy-vdr to be consuming two different versions of indy-utils.

e.g. a cargo tree under a project with a single dependency on indy-vdr = "=0.3.0":

└── indy-vdr v0.3.0
    ├── indy-data-types v0.5.1
    │   ├── indy-utils v0.5.0
    │   │   ├── indy-wql v0.4.0
    ├── indy-utils v0.4.0

this causes errors such as the following:

error[E0599]: no function or associated item named `from_str` found for struct `RevocationRegistryId` in the current scope
   --> /Users/gmulhearne/.cargo/registry/src/github.com-1ecc6299db9ec823/indy-vdr-0.3.0/src/ffi/ledger.rs:454:54
    |
454 |         let revoc_reg_def_id = RevocationRegistryId::from_str(revoc_reg_def_id.as_str())?;
    |                                                      ^^^^^^^^ function or associated item not found in `RevocationRegistryId`
    |
    = help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a `use` for it:
    |
1   | use indy_utils::qualifiable::Qualifiable;
    |

error[E0277]: `?` couldn't convert the error to `common::error::VdrError`
   --> /Users/gmulhearne/.cargo/registry/src/github.com-1ecc6299db9ec823/indy-vdr-0.3.0/src/ffi/ledger.rs:455:85
    |
455 |         let revoc_reg_def_type = RegistryType::from_str(revoc_reg_def_type.as_str())?;
    |                                                                                     ^ the trait `From<indy_data_types::ConversionError>` is not implemented for `common::error::VdrError`
    |
    = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
    = help: the following other types implement trait `From<T>`:
              <common::error::VdrError as From<(common::error::VdrErrorKind, M)>>
              <common::error::VdrError as From<common::error::VdrErrorKind>>
              <common::error::VdrError as From<indy_utils::ConversionError>>
              <common::error::VdrError as From<indy_utils::ValidationError>>
              <common::error::VdrError as From<networker::zmq::zmq::Error>>
    = note: required because of the requirements on the impl of `FromResidual<Result<Infallible, indy_data_types::ConversionError>>` for `Result<_, common::error::VdrError>`

error[E0599]: no method named `to_unqualified` found for reference `&SchemaId` in the current scope
   --> /Users/gmulhearne/.cargo/registry/src/github.com-1ecc6299db9ec823/indy-vdr-0.3.0/src/ledger/request_builder.rs:418:21
    |
418 |         let id = id.to_unqualified();
    |                     ^^^^^^^^^^^^^^ method not found in `&SchemaId`
    |
    = help: items from traits can only be used if the trait is in scope
help: the following trait is implemented but not in scope; perhaps add a `use` for it:
    |
1   | use indy_utils::qualifiable::Qualifiable;
    |

I'm unsure of the best solution to this issue, in general, the cross-dependencies happening in indy-shared-rs seem risky imo

did:indy API changes

I started thinking about the required API changes to support did:indy:

• build_nym_request needs to support an optional diddocContent parameter
• build_get_nym_request needs to support optional seqNo (versionId) and timestamp (versionTime) parameters

Unfortunately, Rust does not support functions with optional arguments. Hence, I see the following options:

1. Break the existing API, i.e add the optional arguments to the functions. Consumers of the API will need to adapt their code when updating Indy VDR
2. Add new functions, e.g. build_nym_request_v2 that include the additional optional parameters
3. Add a feature flag to either build Indy VDR with a legacy API or did:indy API

Did I miss anything? What are your thoughts?

Is this library only for read requests?

Hi,

Do you have any plans to support posting nyms, cred defs and other transactions to Indy registry?

Retrieve real IP address instead of binding address of 0.0.0.0

The indy-node-monitor repo make use of indy-vdr to collect metrics from the ledgers to enable monitoring and visualisation of the health of indy networks. One of the attributes being collected is the node_ip and client_ip of nodes. Some nodes bind to the 0.0.0.0 IP address for these services. The current indy-vdr implementation retrieves the bind IP address, however from a metrics perspective we are looking for the real IP address of the node and not the bind IP address of the node.

Would it be possible to retrieve real node IP addresses for the node and client service respectively?

Release fix for windows builds

Hello,

At the moment, v0.4.0-dev.14 doesn't install correctly on windows. There is already a fix in the main branch for this. It would be really helpful if we can do a new release to update the version

Thanks!

Use indy-node-containers as base for local_nodes_pool tests

It would make sense to switch to node images generated by https://github.com/hyperledger/indy-node-container as a base for the tests running against a local node pool.

That way we avoid the necessity to update dependencies here and can just base on the latest builds from indy-node-container. It could also make things easier/faster for local builds/tests because the base image is already available and only needs minor changes.

Minor issue tracker for indy-vdr and Expo

Right now, building the library that works with the latest react-native will not work with the latest, or any tested version (45.latest, 46.latest), Expo version.

I have supplied the stracktrace for iOS and Android below, but it is an underlying issue that needs investigating, but it is likely an issue with using TurboModules + cpp and Expo that might be fixed later in a patch of expo.

Stracktrace

 ERROR  ReferenceError: Can't find variable: _indy_vdr
 ERROR  Invariant Violation: Failed to call into JavaScript module method AppRegistry.runApplication(). Module has not been registered as callable. Registered callable JavaScript modules (n = 11): Systrace, JSTimers, HeapCapture, SamplingProfiler, RCTLog, RCTDeviceEventEmitter, RCTNativeAppEventEmitter, GlobalPerformanceLogger, JSDevSupportModule, HMRClient, RCTEventEmitter.
        A frequent cause of the error is that the application entry file path is incorrect. This can also happen when the JS bundle is corrupt or there is an early initialization error when loading React Native.
 ERROR  Invariant Violation: Failed to call into JavaScript module method AppRegistry.runApplication(). Module has not been registered as callable. Registered callable JavaScript modules (n = 11): Systrace, JSTimers, HeapCapture, SamplingProfiler, RCTLog, RCTDeviceEventEmitter, RCTNativeAppEventEmitter, GlobalPerformanceLogger, JSDevSupportModule, HMRClient, RCTEventEmitter.
        A frequent cause of the error is that the application entry file path is incorrect. This can also happen when the JS bundle is corrupt or there is an early initialization error when loading React Native.

StateProof verification fails silently

We noticed, that Indy VDR performs a state proof verification for each response of a read request to the ledger, but it seems there's no indication if the verification was successful or failed (except a trace message).

Did I miss anything here?

Multi platform tests for wrapper/javascript/indy-vdr-nodejs

Right now we only test the library on Linux (ubuntu-latest). But with a simple matrix it should be possible to run the tests on Windows, Linux and macOS.

Clean up response output from proxy server

• Set application/json header
• Return node info in a header so that the body is one JSON response
• Return formatted text when text/html is requested

Requires some refactoring to support alternative result formatters.

build failing v0.3.4, v0.3.3, v0.3.2

Running cargo build --lib fails with errors E0277, E0599.
I initially noticed the error on alpine/x86_64 (docker build).
Removing Cargo.lock also caused the compilation to start failing on my main machine as well, so I assume it has to be something with the dependencies. I also tested on MacOS with an M1 chip, it also fails there. I have tested with version v0.3.4, v0.3.3, v0.3.2.

For a quick fix right now, I checked out the latest commit to main 07f03c4609ceed34bc163f83160c609562c34997, that seemed to work on both my main machine and on the docker builds.

Any idea for a better solution?

Full logs of warning and errors (MacOS M1) :

#10 192.7    Compiling indy-vdr v0.3.3 (/indy-vdr/libindy_vdr)
#10 193.3 warning: trailing semicolon in macro used in expression position
#10 193.3    --> libindy_vdr/src/utils/macros.rs:78:10
#10 193.3     |
#10 193.3 78  |         };
#10 193.3     |          ^
#10 193.3     |
#10 193.3    ::: libindy_vdr/src/pool/genesis.rs:157:24
#10 193.3     |
#10 193.3 157 |         let vec_json = unwrap_or_return!(self.encode_json(), Err(std::fmt::Error {}));
#10 193.3     |                        -------------------------------------------------------------- in this macro invocation
#10 193.3     |
#10 193.3     = note: `#[warn(semicolon_in_expressions_from_macros)]` on by default
#10 193.3     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
#10 193.3     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
#10 193.3     = note: this warning originates in the macro `unwrap_or_return` (in Nightly builds, run with -Z macro-backtrace for more info)
#10 193.3
#10 193.3 warning: trailing semicolon in macro used in expression position
#10 193.3    --> libindy_vdr/src/utils/macros.rs:69:10
#10 193.3     |
#10 193.3 69  |           };
#10 193.3     |            ^
#10 193.3     |
#10 193.3    ::: libindy_vdr/src/state_proof/mod.rs:299:48
#10 193.3     |
#10 193.3 299 |           let (signature, participants, value) = unwrap_opt_or_return!(
#10 193.3     |  ________________________________________________-
#10 193.3 300 | |             _parse_reply_for_proof_signature_checking(&parsed_sp.multi_signature),
#10 193.3 301 | |             {
#10 193.3 302 | |                 debug!("Reply parsing failed");
#10 193.3 303 | |                 false
#10 193.3 304 | |             }
#10 193.3 305 | |         );
#10 193.3     | |_________- in this macro invocation
#10 193.3     |
#10 193.3     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
#10 193.3     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
#10 193.3     = note: this warning originates in the macro `unwrap_opt_or_return` (in Nightly builds, run with -Z macro-backtrace for more info)
#10 193.3
#10 193.3 warning: trailing semicolon in macro used in expression position
#10 193.3    --> libindy_vdr/src/utils/macros.rs:78:10
#10 193.3     |
#10 193.3 78  |           };
#10 193.3     |            ^
#10 193.3     |
#10 193.3    ::: libindy_vdr/src/state_proof/mod.rs:313:27
#10 193.3     |
#10 193.3 313 |           let proof_nodes = unwrap_or_return!(base64::decode(&parsed_sp.proof_nodes), {
#10 193.3     |  ___________________________-
#10 193.3 314 | |             debug!("Error decoding proof nodes from state proof");
#10 193.3 315 | |             false
#10 193.3 316 | |         });
#10 193.3     | |__________- in this macro invocation
#10 193.3     |
#10 193.3     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
#10 193.3     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
#10 193.3     = note: this warning originates in the macro `unwrap_or_return` (in Nightly builds, run with -Z macro-backtrace for more info)
#10 193.3
#10 193.3 warning: trailing semicolon in macro used in expression position
#10 193.3    --> libindy_vdr/src/utils/macros.rs:78:10
#10 193.3     |
#10 193.3 78  |           };
#10 193.3     |            ^
#10 193.3     |
#10 193.3    ::: libindy_vdr/src/state_proof/mod.rs:317:25
#10 193.3     |
#10 193.3 317 |           let root_hash = unwrap_or_return!(base58::decode(parsed_sp.root_hash), {
#10 193.3     |  _________________________-
#10 193.3 318 | |             debug!("Error decoding root hash from state proof");
#10 193.3 319 | |             false
#10 193.3 320 | |         });
#10 193.3     | |__________- in this macro invocation
#10 193.3     |
#10 193.3     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
#10 193.3     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
#10 193.3     = note: this warning originates in the macro `unwrap_or_return` (in Nightly builds, run with -Z macro-backtrace for more info)
#10 193.3
#10 193.3 warning: trailing semicolon in macro used in expression position
#10 193.3    --> libindy_vdr/src/utils/macros.rs:78:10
#10 193.3     |
#10 193.3 78  |           };
#10 193.3     |            ^
#10 193.3     |
#10 193.3    ::: libindy_vdr/src/state_proof/mod.rs:325:35
#10 193.3     |
#10 193.3 325 |                           let key = unwrap_or_return!(base64::decode(&k), {
#10 193.3     |  ___________________________________-
#10 193.3 326 | |                             debug!("Error decoding proof key");
#10 193.3 327 | |                             false
#10 193.3 328 | |                         });
#10 193.3     | |__________________________- in this macro invocation
#10 193.3     |
#10 193.3     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
#10 193.3     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
#10 193.3     = note: this warning originates in the macro `unwrap_or_return` (in Nightly builds, run with -Z macro-backtrace for more info)
#10 193.3
#10 193.3 warning: trailing semicolon in macro used in expression position
#10 193.3    --> libindy_vdr/src/utils/macros.rs:87:10
#10 193.3     |
#10 193.3 87  |           };
#10 193.3     |            ^
#10 193.3     |
#10 193.3    ::: libindy_vdr/src/state_proof/mod.rs:947:18
#10 193.3     |
#10 193.3 947 |       let seq_no = unwrap_or_map_return!(seq_no, |err| {
#10 193.3     |  __________________-
#10 193.3 948 | |         debug!("Error while parsing merkle tree seq_no: {}", err);
#10 193.3 949 | |         false
#10 193.3 950 | |     });
#10 193.3     | |______- in this macro invocation
#10 193.3     |
#10 193.3     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
#10 193.3     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
#10 193.3     = note: this warning originates in the macro `unwrap_or_map_return` (in Nightly builds, run with -Z macro-backtrace for more info)
#10 193.3
#10 193.3 warning: trailing semicolon in macro used in expression position
#10 193.3    --> libindy_vdr/src/utils/macros.rs:87:10
#10 193.3     |
#10 193.3 87  |           };
#10 193.3     |            ^
#10 193.3     |
#10 193.3    ::: libindy_vdr/src/state_proof/mod.rs:972:20
#10 193.3     |
#10 193.3 972 |       let mut hash = unwrap_or_map_return!(hash, |err| {
#10 193.3     |  ____________________-
#10 193.3 973 | |         debug!("Error while hashing merkle tree leaf: {:?}", err);
#10 193.3 974 | |         return false;
#10 193.3 975 | |     });
#10 193.3     | |______- in this macro invocation
#10 193.3     |
#10 193.3     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
#10 193.3     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
#10 193.3     = note: this warning originates in the macro `unwrap_or_map_return` (in Nightly builds, run with -Z macro-backtrace for more info)
#10 193.3
#10 193.3 warning: trailing semicolon in macro used in expression position
#10 193.3    --> libindy_vdr/src/utils/macros.rs:78:10
#10 193.3     |
#10 193.3 78  |           };
#10 193.3     |            ^
#10 193.3     |
#10 193.3    ::: libindy_vdr/src/state_proof/mod.rs:980:26
#10 193.3     |
#10 193.3 980 |           let _next_hash = unwrap_or_return!(base58::decode(next_hash), {
#10 193.3     |  __________________________-
#10 193.3 981 | |             debug!("Error decoding next hash as base58");
#10 193.3 982 | |             false
#10 193.3 983 | |         });
#10 193.3     | |__________- in this macro invocation
#10 193.3     |
#10 193.3     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
#10 193.3     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
#10 193.3     = note: this warning originates in the macro `unwrap_or_return` (in Nightly builds, run with -Z macro-backtrace for more info)
#10 193.3
#10 193.3 warning: trailing semicolon in macro used in expression position
#10 193.3    --> libindy_vdr/src/utils/macros.rs:87:10
#10 193.3     |
#10 193.3 87  |           };
#10 193.3     |            ^
#10 193.3     |
#10 193.3    ::: libindy_vdr/src/state_proof/mod.rs:989:16
#10 193.3     |
#10 193.3 989 |           hash = unwrap_or_map_return!(turned_hash, |err| {
#10 193.3     |  ________________-
#10 193.3 990 | |             debug!("Error while hashing: {:?}", err);
#10 193.3 991 | |             return false;
#10 193.3 992 | |         })
#10 193.3     | |__________- in this macro invocation
#10 193.3     |
#10 193.3     = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
#10 193.3     = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813>
#10 193.3     = note: this warning originates in the macro `unwrap_or_map_return` (in Nightly builds, run with -Z macro-backtrace for more info)
#10 193.3
#10 193.9 error[E0599]: no function or associated item named `from_str` found for struct `CredentialDefinitionId` in the current scope
#10 193.9    --> libindy_vdr/src/ffi/ledger.rs:205:51
#10 193.9     |
#10 193.9 205 |         let cred_def_id = CredentialDefinitionId::from_str(cred_def_id.as_str())?;
#10 193.9     |                                                   ^^^^^^^^ function or associated item not found in `CredentialDefinitionId`
#10 193.9     |
#10 193.9     = help: items from traits can only be used if the trait is in scope
#10 193.9 help: the following trait is implemented but not in scope; perhaps add a `use` for it:
#10 193.9     |
#10 193.9 1   | use indy_utils::qualifiable::Qualifiable;
#10 193.9     |
#10 193.9
#10 193.9 error[E0599]: no function or associated item named `from_str` found for struct `RevocationRegistryId` in the current scope
#10 193.9    --> libindy_vdr/src/ffi/ledger.rs:247:50
#10 193.9     |
#10 193.9 247 |         let revoc_reg_id = RevocationRegistryId::from_str(revoc_reg_id.as_str())?;
#10 193.9     |                                                  ^^^^^^^^ function or associated item not found in `RevocationRegistryId`
#10 193.9     |
#10 193.9     = help: items from traits can only be used if the trait is in scope
#10 193.9 help: the following trait is implemented but not in scope; perhaps add a `use` for it:
#10 193.9     |
#10 193.9 1   | use indy_utils::qualifiable::Qualifiable;
#10 193.9     |
#10 193.9
#10 193.9 error[E0599]: no function or associated item named `from_str` found for struct `RevocationRegistryId` in the current scope
#10 193.9    --> libindy_vdr/src/ffi/ledger.rs:269:50
#10 193.9     |
#10 193.9 269 |         let revoc_reg_id = RevocationRegistryId::from_str(revoc_reg_id.as_str())?;
#10 193.9     |                                                  ^^^^^^^^ function or associated item not found in `RevocationRegistryId`
#10 193.9     |
#10 193.9     = help: items from traits can only be used if the trait is in scope
#10 193.9 help: the following trait is implemented but not in scope; perhaps add a `use` for it:
#10 193.9     |
#10 193.9 1   | use indy_utils::qualifiable::Qualifiable;
#10 193.9     |
#10 193.9
#10 193.9 error[E0599]: no function or associated item named `from_str` found for struct `RevocationRegistryId` in the current scope
#10 193.9    --> libindy_vdr/src/ffi/ledger.rs:292:50
#10 193.9     |
#10 193.9 292 |         let revoc_reg_id = RevocationRegistryId::from_str(revoc_reg_id.as_str())?;
#10 193.9     |                                                  ^^^^^^^^ function or associated item not found in `RevocationRegistryId`
#10 193.9     |
#10 193.9     = help: items from traits can only be used if the trait is in scope
#10 193.9 help: the following trait is implemented but not in scope; perhaps add a `use` for it:
#10 193.9     |
#10 193.9 1   | use indy_utils::qualifiable::Qualifiable;
#10 193.9     |
#10 193.9
#10 193.9 error[E0599]: no function or associated item named `from_str` found for struct `SchemaId` in the current scope
#10 193.9    --> libindy_vdr/src/ffi/ledger.rs:314:35
#10 193.9     |
#10 193.9 314 |         let schema_id = SchemaId::from_str(schema_id.as_str())?;
#10 193.9     |                                   ^^^^^^^^ function or associated item not found in `SchemaId`
#10 193.9     |
#10 193.9     = help: items from traits can only be used if the trait is in scope
#10 193.9 help: the following trait is implemented but not in scope; perhaps add a `use` for it:
#10 193.9     |
#10 193.9 1   | use indy_utils::qualifiable::Qualifiable;
#10 193.9     |
#10 193.9
#10 193.9 error[E0599]: no function or associated item named `from_str` found for struct `RevocationRegistryId` in the current scope
#10 193.9    --> libindy_vdr/src/ffi/ledger.rs:454:54
#10 193.9     |
#10 193.9 454 |         let revoc_reg_def_id = RevocationRegistryId::from_str(revoc_reg_def_id.as_str())?;
#10 193.9     |                                                      ^^^^^^^^ function or associated item not found in `RevocationRegistryId`
#10 193.9     |
#10 193.9     = help: items from traits can only be used if the trait is in scope
#10 193.9 help: the following trait is implemented but not in scope; perhaps add a `use` for it:
#10 193.9     |
#10 193.9 1   | use indy_utils::qualifiable::Qualifiable;
#10 193.9     |
#10 193.9
#10 193.9 error[E0277]: `?` couldn't convert the error to `common::error::VdrError`
#10 193.9    --> libindy_vdr/src/ffi/ledger.rs:455:85
#10 193.9     |
#10 193.9 455 |         let revoc_reg_def_type = RegistryType::from_str(revoc_reg_def_type.as_str())?;
#10 193.9     |                                                                                     ^ the trait `From<indy_data_types::ConversionError>` is not implemented for `common::error::VdrError`
#10 193.9     |
#10 193.9     = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
#10 193.9     = help: the following implementations were found:
#10 193.9               <common::error::VdrError as From<(common::error::VdrErrorKind, M)>>
#10 193.9               <common::error::VdrError as From<common::error::VdrErrorKind>>
#10 193.9               <common::error::VdrError as From<indy_utils::ConversionError>>
#10 193.9               <common::error::VdrError as From<indy_utils::ValidationError>>
#10 193.9               <common::error::VdrError as From<zmq::Error>>
#10 193.9     = note: required because of the requirements on the impl of `FromResidual<Result<Infallible, indy_data_types::ConversionError>>` for `Result<_, common::error::VdrError>`
#10 193.9 note: required by `from_residual`
#10 193.9
#10 194.0 error[E0599]: no method named `to_unqualified` found for reference `&SchemaId` in the current scope
#10 194.0    --> libindy_vdr/src/ledger/request_builder.rs:418:21
#10 194.0     |
#10 194.0 418 |         let id = id.to_unqualified();
#10 194.0     |                     ^^^^^^^^^^^^^^ method not found in `&SchemaId`
#10 194.0     |
#10 194.0     = help: items from traits can only be used if the trait is in scope
#10 194.0 help: the following trait is implemented but not in scope; perhaps add a `use` for it:
#10 194.0     |
#10 194.0 1   | use indy_utils::qualifiable::Qualifiable;
#10 194.0     |
#10 194.0
#10 194.0 error[E0599]: no method named `to_unqualified` found for reference `&CredentialDefinitionId` in the current scope
#10 194.0    --> libindy_vdr/src/ledger/request_builder.rs:445:21
#10 194.0     |
#10 194.0 445 |         let id = id.to_unqualified();
#10 194.0     |                     ^^^^^^^^^^^^^^ method not found in `&CredentialDefinitionId`
#10 194.0     |
#10 194.0     = help: items from traits can only be used if the trait is in scope
#10 194.0 help: the following trait is implemented but not in scope; perhaps add a `use` for it:
#10 194.0     |
#10 194.0 1   | use indy_utils::qualifiable::Qualifiable;
#10 194.0     |
#10 194.0
#10 194.0 error[E0599]: no method named `to_unqualified` found for reference `&RevocationRegistryId` in the current scope
#10 194.0    --> libindy_vdr/src/ledger/request_builder.rs:464:21
#10 194.0     |
#10 194.0 464 |         let id = id.to_unqualified();
#10 194.0     |                     ^^^^^^^^^^^^^^ method not found in `&RevocationRegistryId`
#10 194.0     |
#10 194.0     = help: items from traits can only be used if the trait is in scope
#10 194.0 help: the following trait is implemented but not in scope; perhaps add a `use` for it:
#10 194.0     |
#10 194.0 1   | use indy_utils::qualifiable::Qualifiable;
#10 194.0     |
#10 194.0
#10 194.0 error[E0599]: no method named `to_unqualified` found for reference `&RevocationRegistryId` in the current scope
#10 194.0    --> libindy_vdr/src/ledger/request_builder.rs:475:49
#10 194.0     |
#10 194.0 475 |         let revoc_reg_def_id = revoc_reg_def_id.to_unqualified();
#10 194.0     |                                                 ^^^^^^^^^^^^^^ method not found in `&RevocationRegistryId`
#10 194.0     |
#10 194.0     = help: items from traits can only be used if the trait is in scope
#10 194.0 help: the following trait is implemented but not in scope; perhaps add a `use` for it:
#10 194.0     |
#10 194.0 1   | use indy_utils::qualifiable::Qualifiable;
#10 194.0     |
#10 194.0
#10 194.0 error[E0599]: no method named `to_unqualified` found for reference `&RevocationRegistryId` in the current scope
#10 194.0    --> libindy_vdr/src/ledger/request_builder.rs:490:49
#10 194.0     |
#10 194.0 490 |         let revoc_reg_def_id = revoc_reg_def_id.to_unqualified();
#10 194.0     |                                                 ^^^^^^^^^^^^^^ method not found in `&RevocationRegistryId`
#10 194.0     |
#10 194.0     = help: items from traits can only be used if the trait is in scope
#10 194.0 help: the following trait is implemented but not in scope; perhaps add a `use` for it:
#10 194.0     |
#10 194.0 1   | use indy_utils::qualifiable::Qualifiable;
#10 194.0     |
#10 194.0
#10 194.0 error[E0599]: no method named `to_unqualified` found for reference `&RevocationRegistryId` in the current scope
#10 194.0    --> libindy_vdr/src/ledger/request_builder.rs:517:49
#10 194.0     |
#10 194.0 517 |         let revoc_reg_def_id = revoc_reg_def_id.to_unqualified();
#10 194.0     |                                                 ^^^^^^^^^^^^^^ method not found in `&RevocationRegistryId`
#10 194.0     |
#10 194.0     = help: items from traits can only be used if the trait is in scope
#10 194.0 help: the following trait is implemented but not in scope; perhaps add a `use` for it:
#10 194.0     |
#10 194.0 1   | use indy_utils::qualifiable::Qualifiable;
#10 194.0     |
#10 194.0
#10 194.0 error[E0277]: `?` couldn't convert the error to `common::error::VdrError`
#10 194.0    --> libindy_vdr/src/pool/genesis.rs:111:52
#10 194.0     |
#10 194.0 111 |         Ok(MerkleTree::from_vec(self.inner.clone())?)
#10 194.0     |                                                    ^ the trait `From<indy_data_types::ValidationError>` is not implemented for `common::error::VdrError`
#10 194.0     |
#10 194.0     = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
#10 194.0     = help: the following implementations were found:
#10 194.0               <common::error::VdrError as From<(common::error::VdrErrorKind, M)>>
#10 194.0               <common::error::VdrError as From<common::error::VdrErrorKind>>
#10 194.0               <common::error::VdrError as From<indy_utils::ConversionError>>
#10 194.0               <common::error::VdrError as From<indy_utils::ValidationError>>
#10 194.0               <common::error::VdrError as From<zmq::Error>>
#10 194.0     = note: required because of the requirements on the impl of `FromResidual<Result<Infallible, indy_data_types::ValidationError>>` for `Result<MerkleTree, common::error::VdrError>`
#10 194.0 note: required by `from_residual`
#10 194.0
#10 194.0 error[E0277]: `?` couldn't convert the error to `common::error::VdrError`
#10 194.0    --> libindy_vdr/src/pool/genesis.rs:116:44
#10 194.0     |
#10 194.0 116 |         Ok(MerkleTree::from_vec(self.inner)?)
#10 194.0     |                                            ^ the trait `From<indy_data_types::ValidationError>` is not implemented for `common::error::VdrError`
#10 194.0     |
#10 194.0     = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
#10 194.0     = help: the following implementations were found:
#10 194.0               <common::error::VdrError as From<(common::error::VdrErrorKind, M)>>
#10 194.0               <common::error::VdrError as From<common::error::VdrErrorKind>>
#10 194.0               <common::error::VdrError as From<indy_utils::ConversionError>>
#10 194.0               <common::error::VdrError as From<indy_utils::ValidationError>>
#10 194.0               <common::error::VdrError as From<zmq::Error>>
#10 194.0     = note: required because of the requirements on the impl of `FromResidual<Result<Infallible, indy_data_types::ValidationError>>` for `Result<MerkleTree, common::error::VdrError>`
#10 194.0 note: required by `from_residual`
#10 194.0
#10 194.0 error[E0277]: `?` couldn't convert the error to `common::error::VdrError`
#10 194.0    --> libindy_vdr/src/pool/handlers/catchup.rs:74:35
#10 194.0     |
#10 194.0 71  | ) -> VdrResult<Vec<Vec<u8>>> {
#10 194.0     |      ----------------------- expected `common::error::VdrError` because of this
#10 194.0 ...
#10 194.0 74  |         merkle.append(txn.clone())?;
#10 194.0     |                                   ^ the trait `From<indy_data_types::ValidationError>` is not implemented for `common::error::VdrError`
#10 194.0     |
#10 194.0     = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
#10 194.0     = help: the following implementations were found:
#10 194.0               <common::error::VdrError as From<(common::error::VdrErrorKind, M)>>
#10 194.0               <common::error::VdrError as From<common::error::VdrErrorKind>>
#10 194.0               <common::error::VdrError as From<indy_utils::ConversionError>>
#10 194.0               <common::error::VdrError as From<indy_utils::ValidationError>>
#10 194.0               <common::error::VdrError as From<zmq::Error>>
#10 194.0     = note: required because of the requirements on the impl of `FromResidual<Result<Infallible, indy_data_types::ValidationError>>` for `Result<Vec<Vec<u8>>, common::error::VdrError>`
#10 194.0 note: required by `from_residual`
#10 194.0
#10 194.0 error[E0277]: `?` couldn't convert the error to `indy_utils::ValidationError`
#10 194.0    --> libindy_vdr/src/pool/handlers/mod.rs:191:76
#10 194.0     |
#10 194.0 179 | ) -> Result<(), ValidationError> {
#10 194.0     |      --------------------------- expected `indy_utils::ValidationError` because of this
#10 194.0 ...
#10 194.0 191 |     if !mt.consistency_proof(target_mt_root, target_mt_size, &bytes_proofs)? {
#10 194.0     |                                                                            ^ the trait `From<indy_data_types::ValidationError>` is not implemented for `indy_utils::ValidationError`
#10 194.0     |
#10 194.0     = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
#10 194.0     = help: the following implementations were found:
#10 194.0               <indy_utils::ValidationError as From<&str>>
#10 194.0               <indy_utils::ValidationError as From<(M, E)>>
#10 194.0               <indy_utils::ValidationError as From<indy_utils::ConversionError>>
#10 194.0               <indy_utils::ValidationError as From<std::option::Option<std::string::String>>>
#10 194.0               <indy_utils::ValidationError as From<std::string::String>>
#10 194.0     = note: required because of the requirements on the impl of `FromResidual<Result<Infallible, indy_data_types::ValidationError>>` for `Result<(), indy_utils::ValidationError>`
#10 194.0 note: required by `from_residual`
#10 194.0
#10 194.5 warning: unused import: `crate::utils::Qualifiable`
#10 194.5  --> libindy_vdr/src/ledger/request_builder.rs:8:5
#10 194.5   |
#10 194.5 8 | use crate::utils::Qualifiable;
#10 194.5   |     ^^^^^^^^^^^^^^^^^^^^^^^^^
#10 194.5   |
#10 194.5   = note: `#[warn(unused_imports)]` on by default
#10 194.5
#10 194.5 Some errors have detailed explanations: E0277, E0599.
#10 194.5 For more information about an error, try `rustc --explain E0277`.
#10 194.5 warning: `indy-vdr` (lib) generated 10 warnings
#10 194.9 error: could not compile `indy-vdr` due to 17 previous errors; 10 warnings emitted

Remove chrono dependency

I believe it is only used in tests, but chrono is affected by a CVE in the time crate and is not due to be updated.

node-gyp expects `python` to be available, default macos only has `python3` availalbe

Best would be to also support python3 but otherwise we need to add some documentation

Could support genesis transactions at URL

https://github.com/andrewwhitehead/indy-vdr/blob/414b1903c2a9efb99ee2a9e6c844394f822ca094/indy-vdr-proxy/src/main.rs#L52

Could support URL here?

Any issues I put up here are tiny in the face of how awesome this software is as a whole.

Fix iOS build for Indy VDR

Enable auto-refresh of validators in proxy server

Should perform refresh on a timer, with a command line flag to adjust or disable the interval.

Publish to NPM

publish package as @hyperledger/indy-vdr

Build fails on Linux aarch64 with --parallel

Building indy-vdr using cargo build on Ubuntu 18.04 aarch64 fails:

error: failed to run custom build command for `zmq-sys v0.11.0`

Caused by:
  process didn't exit successfully: `/home/indy/indy-vdr/indy-vdr-0.3.3/target/debug/build/zmq-sys-d0b872da29bf9f33/build-script-main` (exit status: 101)
  --- stdout
  cargo:rerun-if-changed=build/main.rs
  cargo:rerun-if-env-changed=PROFILE
  CMAKE_TOOLCHAIN_FILE_aarch64-unknown-linux-gnu = None
  CMAKE_TOOLCHAIN_FILE_aarch64_unknown_linux_gnu = None
  HOST_CMAKE_TOOLCHAIN_FILE = None
  CMAKE_TOOLCHAIN_FILE = None
  CMAKE_GENERATOR_aarch64-unknown-linux-gnu = None
  CMAKE_GENERATOR_aarch64_unknown_linux_gnu = None
  HOST_CMAKE_GENERATOR = None
  CMAKE_GENERATOR = None
  CMAKE_PREFIX_PATH_aarch64-unknown-linux-gnu = None
  CMAKE_PREFIX_PATH_aarch64_unknown_linux_gnu = None
  HOST_CMAKE_PREFIX_PATH = None
  CMAKE_PREFIX_PATH = None
  CMAKE_aarch64-unknown-linux-gnu = None
  CMAKE_aarch64_unknown_linux_gnu = None
  HOST_CMAKE = None
  CMAKE = None
  running: "cmake" "/home/indy/.cargo/registry/src/github.com-1ecc6299db9ec823/zeromq-src-0.1.10+4.3.2/vendor" "-DCMAKE_INSTALL_LIBDIR=lib" "-DCMAKE_C_STANDARD=99" "-DZMQ_BUILD_TESTS=OFF" "-DENABLE_DRAFTS=OFF" "-DENABLE_CURVE=ON" "-DCMAKE_BUILD_TYPE=Debug" "-DWITH_PERF_TOOL=OFF" "-DBUILD_SHARED=OFF" "-DBUILD_STATIC=ON" "-DWITH_LIBSODIUM=OFF" "-DCMAKE_INSTALL_PREFIX=/home/indy/indy-vdr/indy-vdr-0.3.3/target/debug/build/zmq-sys-a64deb418e9c5c5e/out" "-DCMAKE_C_FLAGS= -ffunction-sections -fdata-sections -fPIC" "-DCMAKE_C_COMPILER=/usr/bin/cc" "-DCMAKE_CXX_FLAGS= -ffunction-sections -fdata-sections -fPIC" "-DCMAKE_CXX_COMPILER=/usr/bin/c++" "-DCMAKE_ASM_FLAGS= -ffunction-sections -fdata-sections -fPIC" "-DCMAKE_ASM_COMPILER=/usr/bin/cc"
  -- The C compiler identification is GNU 7.5.0
  -- The CXX compiler identification is GNU 7.5.0
  -- Check for working C compiler: /usr/bin/cc
  -- Check for working C compiler: /usr/bin/cc -- works
  -- Detecting C compiler ABI info
  -- Detecting C compiler ABI info - done
  -- Detecting C compile features
  -- Detecting C compile features - done
  -- Check for working CXX compiler: /usr/bin/c++
  -- Check for working CXX compiler: /usr/bin/c++ -- works
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Detecting CXX compile features
  -- Detecting CXX compile features - done
  -- Looking for pthread.h
  -- Looking for pthread.h - found
  -- Looking for pthread_create
  -- Looking for pthread_create - not found
  -- Looking for pthread_create in pthreads
  -- Looking for pthread_create in pthreads - not found
  -- Looking for pthread_create in pthread
  -- Looking for pthread_create in pthread - found
  -- Found Threads: TRUE  
  -- Detected ZMQ Version - 4.3.2
  -- Performing Test COMPILER_SUPPORTS_CXX11
  -- Performing Test COMPILER_SUPPORTS_CXX11 - Success
  -- Performing Test COMPILER_SUPPORTS_C11
  -- Performing Test COMPILER_SUPPORTS_C11 - Success
  -- Performing Test CXX_HAS_TAUT_WARNING
  -- Performing Test CXX_HAS_TAUT_WARNING - Success
  -- Performing Test CC_HAS_TAUT_WARNING
  -- Performing Test CC_HAS_TAUT_WARNING - Success
  -- Using tweetnacl for CURVE security
  -- Looking for kqueue
  -- Looking for kqueue - not found
  -- Looking for epoll_create
  -- Looking for epoll_create - found
  -- Looking for epoll_create1
  -- Looking for epoll_create1 - found
  -- Using polling method in I/O threads: epoll
  -- Using polling method in zmq_poll(er)_* API: poll
  -- Using 64 bytes alignment for lock-free data structures
  -- Looking for include file windows.h
  -- Looking for include file windows.h - not found
  -- Looking for include file condition_variable
  -- Looking for include file condition_variable - not found
  -- Using condition_variable_t implementation: pthreads
  -- Looking for include file ifaddrs.h
  -- Looking for include file ifaddrs.h - found
  -- Looking for include file sys/uio.h
  -- Looking for include file sys/uio.h - found
  -- Looking for include file sys/eventfd.h
  -- Looking for include file sys/eventfd.h - found
  -- Checking whether EFD_CLOEXEC is supported
  -- Performing Test ZMQ_HAVE_EVENTFD_CLOEXEC
  -- Performing Test ZMQ_HAVE_EVENTFD_CLOEXEC - Success
  -- Looking for SO_PEERCRED
  -- Looking for SO_PEERCRED - found
  -- Looking for LOCAL_PEERCRED
  -- Looking for LOCAL_PEERCRED - not found
  -- Looking for clock_gettime
  -- Looking for clock_gettime - found
  -- Looking for fork
  -- Looking for fork - found
  -- Looking for gethrtimei
  -- Looking for gethrtimei - not found
  -- Looking for mkdtemp
  -- Looking for mkdtemp - found
  -- Looking for accept4
  -- Looking for accept4 - found
  -- Looking for strnlen
  -- Looking for strnlen - found
  -- Performing Test HAVE_FLAG_-Wall
  -- Performing Test HAVE_FLAG_-Wall - Failed
  -- Performing Test HAVE_FLAG_-Wextra
  -- Performing Test HAVE_FLAG_-Wextra - Failed
  -- Performing Test HAVE_FLAG_-Wno-long-long
  -- Performing Test HAVE_FLAG_-Wno-long-long - Failed
  -- Performing Test HAVE_FLAG_-Wno-uninitialized
  -- Performing Test HAVE_FLAG_-Wno-uninitialized - Failed
  -- Performing Test HAVE_FLAG_-pedantic
  -- Performing Test HAVE_FLAG_-pedantic - Failed
  -- Checking whether noexcept is supported
  -- Performing Test ZMQ_HAVE_NOEXCEPT
  -- Performing Test ZMQ_HAVE_NOEXCEPT - Success
  -- Checking whether SOCK_CLOEXEC is supported
  -- Performing Test ZMQ_HAVE_SOCK_CLOEXEC
  -- Performing Test ZMQ_HAVE_SOCK_CLOEXEC - Success
  -- Checking whether O_CLOEXEC is supported
  -- Performing Test ZMQ_HAVE_O_CLOEXEC
  -- Performing Test ZMQ_HAVE_O_CLOEXEC - Success
  -- Checking whether SO_BINDTODEVICE is supported
  -- Performing Test ZMQ_HAVE_SO_BINDTODEVICE
  -- Performing Test ZMQ_HAVE_SO_BINDTODEVICE - Success
  -- Checking whether SO_KEEPALIVE is supported
  -- Performing Test ZMQ_HAVE_SO_KEEPALIVE
  -- Performing Test ZMQ_HAVE_SO_KEEPALIVE - Success
  -- Checking whether TCP_KEEPCNT is supported
  -- Performing Test ZMQ_HAVE_TCP_KEEPCNT
  -- Performing Test ZMQ_HAVE_TCP_KEEPCNT - Success
  -- Checking whether TCP_KEEPIDLE is supported
  -- Performing Test ZMQ_HAVE_TCP_KEEPIDLE
  -- Performing Test ZMQ_HAVE_TCP_KEEPIDLE - Success
  -- Checking whether TCP_KEEPINTVL is supported
  -- Performing Test ZMQ_HAVE_TCP_KEEPINTVL
  -- Performing Test ZMQ_HAVE_TCP_KEEPINTVL - Success
  -- Checking whether TCP_KEEPALIVE is supported
  -- Performing Test ZMQ_HAVE_TCP_KEEPALIVE
  -- Performing Test ZMQ_HAVE_TCP_KEEPALIVE - Failed
  -- Checking whether TIPC is supported
  -- Performing Test ZMQ_HAVE_TIPC
  -- Performing Test ZMQ_HAVE_TIPC - Success
  -- Checking pthread_setname signature
  -- Performing Test ZMQ_HAVE_PTHREAD_SETNAME_1
  -- Performing Test ZMQ_HAVE_PTHREAD_SETNAME_1 - Failed
  -- Performing Test ZMQ_HAVE_PTHREAD_SETNAME_2
  -- Performing Test ZMQ_HAVE_PTHREAD_SETNAME_2 - Success
  -- Performing Test ZMQ_HAVE_PTHREAD_SETNAME_3
  -- Performing Test ZMQ_HAVE_PTHREAD_SETNAME_3 - Failed
  -- Performing Test ZMQ_HAVE_PTHREAD_SET_NAME
  -- Performing Test ZMQ_HAVE_PTHREAD_SET_NAME - Failed
  -- Checking pthread_setaffinity signature
  -- Performing Test ZMQ_HAVE_PTHREAD_SETAFFINITY
  -- Performing Test ZMQ_HAVE_PTHREAD_SETAFFINITY - Success
  -- Checking whether getrandom is supported
  -- Performing Test ZMQ_HAVE_GETRANDOM
  -- Performing Test ZMQ_HAVE_GETRANDOM - Success
  -- Could NOT find AsciiDoc (missing: ASCIIDOC_EXECUTABLE) 
  -- Configuring done
  -- Generating done
  -- Build files have been written to: /home/indy/indy-vdr/indy-vdr-0.3.3/target/debug/build/zmq-sys-a64deb418e9c5c5e/out/build
  running: "cmake" "--build" "." "--target" "install" "--config" "Debug" "--parallel" "4"

  --- stderr
  CMake Warning:
    Manually-specified variables were not used by the project:

      CMAKE_ASM_COMPILER
      CMAKE_ASM_FLAGS


  Unknown argument --parallel
  Unknown argument 4
  Usage: cmake --build <dir> [options] [-- [native-options]]
  Options:
    <dir>          = Project binary directory to be built.
    --target <tgt> = Build <tgt> instead of default targets.
                     May only be specified once.
    --config <cfg> = For multi-configuration tools, choose <cfg>.
    --clean-first  = Build target 'clean' first, then build.
                     (To clean only, use --target 'clean'.)
    --use-stderr   = Ignored.  Behavior is default in CMake >= 3.0.
    --             = Pass remaining options to the native tool.
  thread 'main' panicked at '
  command did not execute successfully, got: exit status: 1

  build script failed, must exit now', /home/indy/.cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.46/src/lib.rs:974:5
  stack backtrace:
     0: rust_begin_unwind
               at /rustc/09c42c45858d5f3aedfa670698275303a3d19afa/library/std/src/panicking.rs:517:5
     1: std::panicking::begin_panic_fmt
               at /rustc/09c42c45858d5f3aedfa670698275303a3d19afa/library/std/src/panicking.rs:460:5
     2: cmake::fail
               at /home/indy/.cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.46/src/lib.rs:974:5
     3: cmake::run
               at /home/indy/.cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.46/src/lib.rs:952:9
     4: cmake::Config::build
               at /home/indy/.cargo/registry/src/github.com-1ecc6299db9ec823/cmake-0.1.46/src/lib.rs:832:9
     5: zeromq_src::Build::build
               at /home/indy/.cargo/registry/src/github.com-1ecc6299db9ec823/zeromq-src-0.1.10+4.3.2/src/lib.rs:314:23
     6: build_script_main::find::configure
               at ./build/vendored.rs:9:21
     7: build_script_main::main
               at ./build/main.rs:6:5
     8: core::ops::function::FnOnce::call_once
               at /rustc/09c42c45858d5f3aedfa670698275303a3d19afa/library/core/src/ops/function.rs:227:5
  note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
warning: build failed, waiting for other jobs to finish...
error: build failed

According to the output, cmake not recognising the --parallel 4 option:

--- stderr
  Unknown argument --parallel
  Unknown argument 4

Manually running above command omitting the --parallel option or compiling rust-zmq and zmq-sys from github source is successful.

any suggestions?

root@7f7aa4b19200:~/indy-vdr/indy-vdr-0.3.3# "cmake" "--build" "." "--target" "install" "--config" "Debug"   
Scanning dependencies of target objects
[  1%] Building C object CMakeFiles/objects.dir/src/tweetnacl.c.o
[  2%] Building CXX object CMakeFiles/objects.dir/src/precompiled.cpp.o
[  3%] Building CXX object CMakeFiles/objects.dir/src/address.cpp.o
[  4%] Building CXX object CMakeFiles/objects.dir/src/client.cpp.o
[  5%] Building CXX object CMakeFiles/objects.dir/src/clock.cpp.o
[  6%] Building CXX object CMakeFiles/objects.dir/src/ctx.cpp.o
[  7%] Building CXX object CMakeFiles/objects.dir/src/curve_mechanism_base.cpp.o
[  8%] Building CXX object CMakeFiles/objects.dir/src/curve_client.cpp.o
[  9%] Building CXX object CMakeFiles/objects.dir/src/curve_server.cpp.o
[ 10%] Building CXX object CMakeFiles/objects.dir/src/dealer.cpp.o
[ 11%] Building CXX object CMakeFiles/objects.dir/src/devpoll.cpp.o
[ 12%] Building CXX object CMakeFiles/objects.dir/src/dgram.cpp.o
[ 13%] Building CXX object CMakeFiles/objects.dir/src/dist.cpp.o
[ 14%] Building CXX object CMakeFiles/objects.dir/src/endpoint.cpp.o
[ 15%] Building CXX object CMakeFiles/objects.dir/src/epoll.cpp.o
[ 16%] Building CXX object CMakeFiles/objects.dir/src/err.cpp.o
[ 17%] Building CXX object CMakeFiles/objects.dir/src/fq.cpp.o
[ 18%] Building CXX object CMakeFiles/objects.dir/src/io_object.cpp.o
[ 19%] Building CXX object CMakeFiles/objects.dir/src/io_thread.cpp.o
[ 20%] Building CXX object CMakeFiles/objects.dir/src/ip.cpp.o
[ 21%] Building CXX object CMakeFiles/objects.dir/src/ipc_address.cpp.o
[ 22%] Building CXX object CMakeFiles/objects.dir/src/ipc_connecter.cpp.o
[ 23%] Building CXX object CMakeFiles/objects.dir/src/ipc_listener.cpp.o
[ 24%] Building CXX object CMakeFiles/objects.dir/src/kqueue.cpp.o
[ 25%] Building CXX object CMakeFiles/objects.dir/src/lb.cpp.o
[ 26%] Building CXX object CMakeFiles/objects.dir/src/mailbox.cpp.o
[ 27%] Building CXX object CMakeFiles/objects.dir/src/mailbox_safe.cpp.o
[ 28%] Building CXX object CMakeFiles/objects.dir/src/mechanism.cpp.o
[ 29%] Building CXX object CMakeFiles/objects.dir/src/mechanism_base.cpp.o
[ 30%] Building CXX object CMakeFiles/objects.dir/src/metadata.cpp.o
[ 31%] Building CXX object CMakeFiles/objects.dir/src/msg.cpp.o
[ 31%] Building CXX object CMakeFiles/objects.dir/src/mtrie.cpp.o
[ 32%] Building CXX object CMakeFiles/objects.dir/src/norm_engine.cpp.o
[ 33%] Building CXX object CMakeFiles/objects.dir/src/object.cpp.o
[ 34%] Building CXX object CMakeFiles/objects.dir/src/options.cpp.o
[ 35%] Building CXX object CMakeFiles/objects.dir/src/own.cpp.o
[ 36%] Building CXX object CMakeFiles/objects.dir/src/null_mechanism.cpp.o
[ 37%] Building CXX object CMakeFiles/objects.dir/src/pair.cpp.o
[ 38%] Building CXX object CMakeFiles/objects.dir/src/pgm_receiver.cpp.o
[ 39%] Building CXX object CMakeFiles/objects.dir/src/pgm_sender.cpp.o
[ 40%] Building CXX object CMakeFiles/objects.dir/src/pgm_socket.cpp.o
[ 41%] Building CXX object CMakeFiles/objects.dir/src/pipe.cpp.o
[ 42%] Building CXX object CMakeFiles/objects.dir/src/plain_client.cpp.o
[ 43%] Building CXX object CMakeFiles/objects.dir/src/plain_server.cpp.o
[ 44%] Building CXX object CMakeFiles/objects.dir/src/poll.cpp.o
[ 45%] Building CXX object CMakeFiles/objects.dir/src/poller_base.cpp.o
[ 46%] Building CXX object CMakeFiles/objects.dir/src/polling_util.cpp.o
[ 47%] Building CXX object CMakeFiles/objects.dir/src/pollset.cpp.o
[ 48%] Building CXX object CMakeFiles/objects.dir/src/proxy.cpp.o
[ 49%] Building CXX object CMakeFiles/objects.dir/src/pub.cpp.o
[ 50%] Building CXX object CMakeFiles/objects.dir/src/pull.cpp.o
[ 51%] Building CXX object CMakeFiles/objects.dir/src/push.cpp.o
[ 52%] Building CXX object CMakeFiles/objects.dir/src/random.cpp.o
[ 53%] Building CXX object CMakeFiles/objects.dir/src/raw_encoder.cpp.o
[ 54%] Building CXX object CMakeFiles/objects.dir/src/raw_decoder.cpp.o
[ 55%] Building CXX object CMakeFiles/objects.dir/src/reaper.cpp.o
[ 56%] Building CXX object CMakeFiles/objects.dir/src/rep.cpp.o
[ 57%] Building CXX object CMakeFiles/objects.dir/src/req.cpp.o
[ 58%] Building CXX object CMakeFiles/objects.dir/src/router.cpp.o
[ 59%] Building CXX object CMakeFiles/objects.dir/src/select.cpp.o
[ 60%] Building CXX object CMakeFiles/objects.dir/src/server.cpp.o
[ 61%] Building CXX object CMakeFiles/objects.dir/src/session_base.cpp.o
[ 62%] Building CXX object CMakeFiles/objects.dir/src/signaler.cpp.o
[ 63%] Building CXX object CMakeFiles/objects.dir/src/socket_base.cpp.o
[ 64%] Building CXX object CMakeFiles/objects.dir/src/socks.cpp.o
[ 64%] Building CXX object CMakeFiles/objects.dir/src/socks_connecter.cpp.o
[ 65%] Building CXX object CMakeFiles/objects.dir/src/stream.cpp.o
[ 66%] Building CXX object CMakeFiles/objects.dir/src/stream_engine.cpp.o
[ 67%] Building CXX object CMakeFiles/objects.dir/src/sub.cpp.o
[ 68%] Building CXX object CMakeFiles/objects.dir/src/tcp.cpp.o
[ 69%] Building CXX object CMakeFiles/objects.dir/src/tcp_address.cpp.o
[ 70%] Building CXX object CMakeFiles/objects.dir/src/tcp_connecter.cpp.o
[ 71%] Building CXX object CMakeFiles/objects.dir/src/tcp_listener.cpp.o
[ 72%] Building CXX object CMakeFiles/objects.dir/src/thread.cpp.o
[ 73%] Building CXX object CMakeFiles/objects.dir/src/trie.cpp.o
[ 74%] Building CXX object CMakeFiles/objects.dir/src/radix_tree.cpp.o
[ 75%] Building CXX object CMakeFiles/objects.dir/src/v1_decoder.cpp.o
[ 76%] Building CXX object CMakeFiles/objects.dir/src/v1_encoder.cpp.o
[ 77%] Building CXX object CMakeFiles/objects.dir/src/v2_decoder.cpp.o
[ 78%] Building CXX object CMakeFiles/objects.dir/src/v2_encoder.cpp.o
[ 79%] Building CXX object CMakeFiles/objects.dir/src/xpub.cpp.o
[ 80%] Building CXX object CMakeFiles/objects.dir/src/xsub.cpp.o
[ 81%] Building CXX object CMakeFiles/objects.dir/src/zmq.cpp.o
[ 82%] Building CXX object CMakeFiles/objects.dir/src/zmq_utils.cpp.o
[ 83%] Building CXX object CMakeFiles/objects.dir/src/decoder_allocators.cpp.o
[ 84%] Building CXX object CMakeFiles/objects.dir/src/socket_poller.cpp.o
[ 85%] Building CXX object CMakeFiles/objects.dir/src/timers.cpp.o
[ 86%] Building CXX object CMakeFiles/objects.dir/src/radio.cpp.o
[ 87%] Building CXX object CMakeFiles/objects.dir/src/dish.cpp.o
[ 88%] Building CXX object CMakeFiles/objects.dir/src/udp_engine.cpp.o
[ 89%] Building CXX object CMakeFiles/objects.dir/src/udp_address.cpp.o
[ 90%] Building CXX object CMakeFiles/objects.dir/src/scatter.cpp.o
[ 91%] Building CXX object CMakeFiles/objects.dir/src/gather.cpp.o
[ 92%] Building CXX object CMakeFiles/objects.dir/src/ip_resolver.cpp.o
[ 93%] Building CXX object CMakeFiles/objects.dir/src/zap_client.cpp.o
[ 94%] Building CXX object CMakeFiles/objects.dir/src/stream_connecter_base.cpp.o
[ 95%] Building CXX object CMakeFiles/objects.dir/src/stream_listener_base.cpp.o
[ 96%] Building CXX object CMakeFiles/objects.dir/src/tipc_address.cpp.o
[ 97%] Building CXX object CMakeFiles/objects.dir/src/tipc_connecter.cpp.o
[ 98%] Building CXX object CMakeFiles/objects.dir/src/tipc_listener.cpp.o
[ 98%] Built target objects
Scanning dependencies of target libzmq-static
[100%] Linking CXX static library lib/libzmq.a
[100%] Built target libzmq-static
Install the project...
-- Install configuration: "Debug"
-- Installing: /home/indy/indy-vdr/indy-vdr-0.3.3/target/debug/build/zmq-sys-a64deb418e9c5c5e/out/lib/pkgconfig/libzmq.pc
-- Installing: /home/indy/indy-vdr/indy-vdr-0.3.3/target/debug/build/zmq-sys-a64deb418e9c5c5e/out/lib/libzmq.a
-- Installing: /home/indy/indy-vdr/indy-vdr-0.3.3/target/debug/build/zmq-sys-a64deb418e9c5c5e/out/include/zmq.h
-- Installing: /home/indy/indy-vdr/indy-vdr-0.3.3/target/debug/build/zmq-sys-a64deb418e9c5c5e/out/include/zmq_utils.h
-- Installing: /home/indy/indy-vdr/indy-vdr-0.3.3/target/debug/build/zmq-sys-a64deb418e9c5c5e/out/share/zmq/AUTHORS.txt
-- Installing: /home/indy/indy-vdr/indy-vdr-0.3.3/target/debug/build/zmq-sys-a64deb418e9c5c5e/out/share/zmq/COPYING.txt
-- Installing: /home/indy/indy-vdr/indy-vdr-0.3.3/target/debug/build/zmq-sys-a64deb418e9c5c5e/out/share/zmq/COPYING.LESSER.txt
-- Installing: /home/indy/indy-vdr/indy-vdr-0.3.3/target/debug/build/zmq-sys-a64deb418e9c5c5e/out/share/zmq/NEWS.txt
-- Installing: /home/indy/indy-vdr/indy-vdr-0.3.3/target/debug/build/zmq-sys-a64deb418e9c5c5e/out/share/cmake/ZeroMQ/ZeroMQTargets.cmake
-- Installing: /home/indy/indy-vdr/indy-vdr-0.3.3/target/debug/build/zmq-sys-a64deb418e9c5c5e/out/share/cmake/ZeroMQ/ZeroMQTargets-debug.cmake
-- Installing: /home/indy/indy-vdr/indy-vdr-0.3.3/target/debug/build/zmq-sys-a64deb418e9c5c5e/out/share/cmake/ZeroMQ/ZeroMQConfig.cmake
-- Installing: /home/indy/indy-vdr/indy-vdr-0.3.3/target/debug/build/zmq-sys-a64deb418e9c5c5e/out/share/cmake/ZeroMQ/ZeroMQConfigVersion.cmake
root@7f7aa4b19200:~/indy-vdr/indy-vdr-0.3.3# 

Non-deterministic issue with the javascript wrapper in Node.js

CI keeps failing on this step: https://github.com/hyperledger/indy-vdr/actions/runs/5082667192/jobs/9145294433

With the error:

FAIL tests/GetAttribRequest.test.ts (21.485 s)
  ● GetAttribRequest › Submit request

    Pool timeout: Request was interrupted

      114 |     const indyVdrErrorObject = JSON.parse(nativeError.deref() as string) as IndyVdrErrorObject
      115 |
    > 116 |     throw new IndyVdrError(indyVdrErrorObject)
          |           ^
      117 |   }
      118 |
      119 |   public get nativeIndyVdr() {

      at NodeJSIndyVdr.handleError (src/NodeJSIndyVdr.ts:116:11)
      at cb (src/NodeJSIndyVdr.ts:87:16)
      at Object.<anonymous> (../node_modules/ffi-napi/lib/callback.js:66:27)

It happens for some functions and the amount of times it happens is different each run.

It passes here: https://github.com/hyperledger/indy-vdr/actions/runs/5044489119/jobs/9048660679

The errors seem to be thrown from the native library, with version: v0.4.0-dev.15.

Error while Compiling the Library

I am trying to compile the library (Tag v0.3.2) with cargo build --lib but I am getting the following error:

Compiling indy-vdr v0.3.2 (<PATH>/indy-vdr/libindy_vdr)
warning: derive helper attribute is used before it is introduced
   --> libindy_vdr/src/pool/types.rs:516:3
    |
516 | #[serde(tag = "op")]
    |   ^^^^^
517 | #[derive(Serialize, Deserialize, Debug)]
    |          --------- the attribute is introduced here
    |
    = note: `#[warn(legacy_derive_helpers)]` on by default
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #79202 <https://github.com/rust-lang/rust/issues/79202>

warning: unused import: `sha3::digest::FixedOutput`
   --> libindy_vdr/src/state_proof/node.rs:152:13
    |
152 |         use sha3::digest::FixedOutput;
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^
    |
    = note: `#[warn(unused_imports)]` on by default

warning: unused import: `sha3::Digest`
   --> libindy_vdr/src/state_proof/node.rs:153:13
    |
153 |         use sha3::Digest;
    |             ^^^^^^^^^^^^

error[E0599]: no method named `input` found for struct `Sha3_256` in the current scope
   --> libindy_vdr/src/state_proof/node.rs:156:16
    |
156 |         hasher.input(encoded.to_vec().as_slice());
    |                ^^^^^ method not found in `Sha3_256`

error[E0599]: no method named `fixed_result` found for struct `Sha3_256` in the current scope
   --> libindy_vdr/src/state_proof/node.rs:157:16
    |
157 |         hasher.fixed_result()
    |                ^^^^^^^^^^^^ method not found in `Sha3_256`

For more information about this error, try `rustc --explain E0599`.
warning: `indy-vdr` (lib) generated 3 warnings
error: could not compile `indy-vdr` due to 2 previous errors; 3 warnings emitted

Cargo version: cargo 1.55.0 (32da73ab1 2021-08-23)
OS: Ubuntu 20.04.03 LTS

Is there any solution to this problem? Thanks in advance!

Test Indy VDR in React Native and fix bugs that are encountered

Dod: Add IndyVdrModule from AFJ to example react native app and make sure we can do a full credential exchange where IndyVdr provides the connection to the ledger

Publish release libraries for linux arm64

Wheels are published for macos universal and linux x86-64, but not for linux arm64. Could the build be updated to publish releases for this architecture?

Release a version with full did:indy support

We have ledgers available now with did:indy support built in. We need to get indy-vdr updated to support that.

Please release a new version of indy-vdr with did:indy support included.

Cannot close pool after calling any `indy_vdr_pool_...` function

When writing tests for the new NodeJS wrapper I encountered some issue with pool_close(). The issue is that when I create a pool and immediately close it nothing goes wrong, however when I create a pool, get the verifiers and close the pool I never receive write access via the lock. I am supposed to call a free or drop or something else after acquiring the lock (I assume this is handled rust via drop but I am not too sure)?

build - tanking out on zmq-sys v0.11.0

error: failed to run custom build command for zmq-sys v0.11.0

Hi Andrew!

Support ZMQ socks proxy

Same as INDY-SDK Issue 2399
must be implemented/copied in INDY-VDR too

By using INDY-VDR behind a corporate proxy, a socks proxy must be configured for ZMQ socket connections.
Zero MQ Socket supports this by setting the ZMQ_SOCKS_PROXY property, for Rust Wrapper is it set_socks_proxy function.
The problem is, that the INDY-VDR doesn't support the possibility to set and pass on the property to ZMQ.

Is indy vdr mandatory

I clone the tails server code and trying to build the tails server docker file and it successfully build but when I run tails image getting indy-vdr-proxy url is mandatory.

Is indy-vdr-proxy url mandatory or can I give von network url here for indy proxy url.

Restore support for custom state proof parser/validators

Will this library be following the contract for resolution defined in DID Core?

As of recently, a contract has been being discussed in the DID Core specification with some of the normative PRs still to come. The non normative structure has been merged in and issues #263, #264, and #265 will be bringing in the normative statements. Is the intent of this library to move in the direction eventually, and if so what sorts of input would you have for those PRs to align with this implementation?

Unable to run indy vdr

I have installed indy vdr through pip install and when I use indy-vdr-proxy --host 0.0.0. --port 7564 --genesis url given.
But getting indy vdr proxy command not found

Add DID Doc path to indy-vdr-proxy

Synthesize a DID Doc by fetching the key and endpoint for a DID

Create a Tails Server capability based on indy-vdr-proxy

With Indy anoncreds 1 revocation now supported in (at least) ACA-Py, we need places for issuers to publish tails files and from which holders can download them. As such, we'd like to create such a service around indy-vdr. BC Gov is planning to host an instance of a tails server that others could use.

Here is a rough outline of the proposed design:

• The service would have two sets of endpoints, one for posting a tails file, the other for downloading one.
• The posting service would expect from the issuer:
  • A call (or two?) with:
    • a mechanism to find the ledger (genesis file or URL)
    • the ID of the revocation registry for the tails file
    • the tails file, perhaps as a URL or passed as a follow up call.
    • perhaps a signature from the issuer based on it's DID on the ledger
  • The tails server would validate the existence of the ledger, revo registry and any other data
  • If all good, get the tails file and make it available at a known location constructed (somehow - TBD) from the ledger and revocation registry.
• The download service would simply make the file available for download a tails file when asked.

We would want a least a docker-compose file for the service so that it can be easily deployed and testing. BC Gov would likely deploy the service on OpenShift.

Glad to help with any questions for getting started on this.

Indy VDR wrapper for React Native

We've been having some discussions in the Aries Bifold and Aries Framework JavaScript (AFJ) calls on how we can adopt the new shared components libraries in AFJ and React Native (RN).

Posting this here so we all have a shared understanding on the approach we want to take.

Currently the AFJ / Indy SDK architecture looks as follows:

• Indy SDK for NodeJS is direct FFI wrapper around libindy
• Indy SDK for RN is JavaScript layer talking to RN layer (Swift + Java) talking to iOS and Java wrappers around lbindy.

This was the most straightforward approach for Indy SDK for the following reasons.

• React Native doesn't allow you to directly invoke a c-callable library or c-code.
• There were already wrappers available for iOS and Android.

React Native is working on a re-architecture that allows you to directly invoke c-code from the JS side. Using JSI (JavaScript interface) an interface from JS to in theory any (c-like?) language can be created with an interface already defined for c++.

What this means is instead of the multi-layer architecture that we needed for the Indy SDK in RN we can create a single C++ wrapper that works for both iOS and Android.

One of the benefits of this new architecture is that the JS->C++ interface can be generated from the TypeScript interfaces. That means we can define the API once in TypeScript (maybe even take the current TS interfaces from the NodeJS wrapper) and generate the C++ boilerplate from it. Same as with indy-sdk we would like the NodeJS and React Native public APIs to match

• https://github.com/microsoft/react-native-tscodegen - Allows to generate TS -> C++ interface from TS interfaces
• https://github.com/craftzdog/react-native-quick-base64 - Library already using JSI
• https://github.com/craftzdog/react-native-quick-md5 - Another library using JSI
• https://blog.inkdrop.info/how-i-improved-my-react-native-app-50x-faster-13d566061e84
• RN JSI Issue
• RN TurboModules / CodeGen Issue

The re-architecture is still WIP and not publicly released yet. This doesn't mean it can't be used yet. As you can see there are libraries using it, and RN uses it internally. There's just not been a lot of focus on DX and documentation yet. So some research is necessary to determine the best approach.

In our discussion on the Aries Bifold call we discussed this is still probably the route we want to go, as it will save a lot of complexity and resources over time. First starting with Indy VDR as it is standalone from Aries Askar / Indy CredX. If we have the setup ready doing the same trick for the other libraries should be more straightforward.

cc @JamesKEbert @swcurran @karimStekelenburg @jakubkoci @andrewwhitehead

Proxy returns data when it should be a 404

Calling /rev_reg_def/6sUh41dtpjSYfEs7szMcqD:4:6sUh41dtpjSYfEs7szMcqD:3:CL:8:default:CL_ACCUM:efd6413f-9765-4032-a40a-a8a14b00de98 when connected to an empty ledger returns this:

{
  "data": null,
  "id": "6sUh41dtpjSYfEs7szMcqD:4:6sUh41dtpjSYfEs7szMcqD:3:CL:8:default:CL_ACCUM:efd6413f-9765-4032-a40a-a8a14b00de98",
  "seqNo": null,
  "txnTime": null,
  "type": "115"
}

Should this be a 404 response?