farooq_m_khan (Thu, 27 Apr 2017 16:42:32 GMT):
Has joined the channel.

peacekeeper (Thu, 27 Apr 2017 17:00:17 GMT):
Has joined the channel.

peacekeeper (Thu, 27 Apr 2017 17:12:44 GMT):
hello

danielhardman (Thu, 27 Apr 2017 20:26:54 GMT):
Hi, folks. This channel is where we're going to discuss the evolution of code and docs that will eventually constitute a Sovrin SDK of sorts. Right now the nucleus of that SDK is the effort we currently know as "libsovrin". See https://github.com/evernym/sovrin-client-rust. This code will eventually move into the github repo at https://github.com/hyperledger/indy-sdk (which is still being created). That same repo is expected to have extensive docs, example code, and probably subfolders for a few canonical wrappers of the C-callable API. Other wrappers may live independently, like the one @peacekeeper is working.

danielhardman (Thu, 27 Apr 2017 20:30:05 GMT):
Some important links of general interest: The c-callable API for libsovrin is here: https://github.com/evernym/sovrin-client-rust/tree/master/src/api (read the javadoc-style comments for info about specific functions) Some thoughts about writing wrappers are here: https://docs.google.com/document/d/15P6JOEKxbNC892DWReBStJIXrObVoaBDxbKJFOpAdjI/edit Markus's java wrapper around libsovrin is here:

danielhardman (Thu, 27 Apr 2017 20:30:05 GMT):
Some important links of general interest: The current (but soon-to-be-superseded) C-callable API for libsovrin is here: https://github.com/evernym/sovrin-client-rust/tree/master/src/api (read the javadoc-style comments for info about specific functions) Some thoughts about writing wrappers are here: https://docs.google.com/document/d/15P6JOEKxbNC892DWReBStJIXrObVoaBDxbKJFOpAdjI/edit A doc about exploring wallet use cases: https://docs.google.com/document/d/13s0M7XGd2t3M7Kybb18O5d6t9MfqA3hQ_HlOlriJb98/edit?usp=sharing @peacekeeper, can you re-post the link to your java wrapper?

gudkov (Fri, 28 Apr 2017 10:01:12 GMT):
Has joined the channel.

gudkov (Fri, 28 Apr 2017 10:04:02 GMT):
Hello, Here’s what our team that’s working on the c-callable sovrin client got done today: - Bugfixes in Milagro wrapper. - Continue implementation of Anoncreds API. Prover and Issuer commands implementation. - Continue implementation of catch up process. Finished consistency proof implementation. - Initial implementation of pool emulator: creating nodes, ping handling. - Continue implementation of secure wallet.

peacekeeper (Fri, 28 Apr 2017 11:07:38 GMT):
work-in-progress Java wrapper is here, not functional yet: https://github.com/projectdanube/sovrinclient-java

peacekeeper (Fri, 28 Apr 2017 11:09:10 GMT):
It currently only implements the pool.rs methods so I can test the overall wrapping approach a bit. I'm planning to refactor a bit and then add all other methods.

peacekeeper (Fri, 28 Apr 2017 11:09:54 GMT):
BTW I noticed all methods start with sovrin_XXX except the ones in ledger.rs, looks a bit inconsistent?

gudkov (Fri, 28 Apr 2017 11:18:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=joaNa8GDJhRnMZAYd) Agreed. sovrin prefix is needed for all methods. Looks like we need to change it.

gudkov (Fri, 28 Apr 2017 11:49:58 GMT):
I created corresponded issue https://github.com/evernym/sovrin-client-rust/issues/49 You can sibsribe to it to be notified when we fixed it.

gudkov (Fri, 28 Apr 2017 14:57:03 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Continue implementation of Anoncreds API. Prover and Issuer commands implementation. - Continue implementation of pool emulator: new requests was added. - Continue implementation of catch up process. Deep testing with pool emulator. Solving interperobility issues in consistensy proofs. - Continue implementation of secure wallet. Added functionality for freshness checking. Integration with commands code. - Continue iOS wrapper. Solving problems with 3d party dependencies linking.

nage (Fri, 28 Apr 2017 17:00:54 GMT):
Has joined the channel.

cbruguera (Fri, 28 Apr 2017 22:10:12 GMT):
Has joined the channel.

cbruguera (Sun, 30 Apr 2017 22:50:44 GMT):
Is _libsovrin_ already usable for making simple writes/reads against the ledger? (DIDs, claims, etc)... If I were to make a "hello world" write to the ledger, would you advise using libsovrin at its current state? Or would it be easier (and/or safer) to utilize classes and methods already implemented on the `sovrin-client` python reference code?

darrell.odonnell (Mon, 01 May 2017 12:25:55 GMT):
Has joined the channel.

peacekeeper (Mon, 01 May 2017 14:42:03 GMT):
@cbruguera i'm not as close to this as others, but my understanding is that the python code will also migrate to using `libsovrin` soon, therefore it's probably a good idea to focus all attention on that

rjones (Mon, 01 May 2017 18:31:25 GMT):
peacekeeper

prashiyn (Tue, 02 May 2017 06:48:55 GMT):
Has joined the channel.

gudkov (Tue, 02 May 2017 16:15:51 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - iOS wrapper implementation: - Project for sovrin-ios-wrapper is ready, We can build client which calls one function from rust lib libsovrin - Ported milagro library, milagro tests are in progress - Milagro is made as pod and uploaded to deb server - Continue implementation of Anoncreds API. About 90% commands finished for the moment. - Continue implementation of catch up process. Deep testing with pool emulator. Consistensy proofs were finished. - We started implementation of python wrapper. Have some discussions and researches. Plan to continue with API design.

gudkov (Tue, 02 May 2017 16:15:51 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - iOS wrapper implementation: * Project for sovrin-ios-wrapper is ready, We can build client which calls one function from rust lib libsovrin * Ported milagro library, milagro tests are in progress * Milagro is made as pod and uploaded to deb server - Continue implementation of Anoncreds API. About 90% commands finished for the moment. - Continue implementation of catch up process. Deep testing with pool emulator. Consistensy proofs were finished. - We started implementation of python wrapper. Have some discussions and researches. Plan to continue with API design.

nage (Wed, 03 May 2017 13:47:02 GMT):
Any topics folks here would like to share in the Agent WG call tomorrow, please post to #indy-agent

nage (Wed, 03 May 2017 13:47:47 GMT):
I'd love to see another update on libsovrin progress, particularly any progress around the language-specific wrappers

gudkov (Wed, 03 May 2017 15:06:01 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - iOS wrapper implementation: Ported all tests for milagro (all tests passed on iPhone device) - Continue implementation of Anoncreds API. All verifier commands were implemented. - Started implementation of pool transactions. Provided draft implementation for sending request to nodes. - Continue implementation of python wrapper. API definition. Research docs according python bindings creation and examples. - Refactored crypto service types. Deep testing of anoncreds part of crypto service. - Continue wallet implementation. Provided list command. Deep testing.

schwentker2 (Wed, 03 May 2017 19:18:53 GMT):
Has joined the channel.

devin-fisher (Thu, 04 May 2017 15:48:27 GMT):
Has joined the channel.

denofernandes (Thu, 04 May 2017 15:48:37 GMT):
Has joined the channel.

gudkov (Thu, 04 May 2017 15:56:31 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Continue iOS wrapper implementation. Code migrated to main repo. - Continue implementation of Anoncreds API. We finished implementation of API and started integration and demo preparation. - Continue implementation of pool transactions. We got working first API level integration test. - Continue implementation of python wrapper. We got fist API draft and will publish it soon. - Wallet API was implemented. - We started working on integration testing and demo preparation. Creation of docker image to pool nodes. Integration of this test pool to CI (in progress).

JoVercammen (Thu, 04 May 2017 20:19:10 GMT):
Has joined the channel.

gudkov (Fri, 05 May 2017 15:40:44 GMT):
Hello, here is current libsovrin status: - We started integration and created few working API level demos: * Anoncreds demo. It covers all anoncreds workflow from claim def creation to proof verification. *Request demo. It shows catch up and sending request to real pool ledger. This test works but disabled for now as it requires launching of the pool. We are working on automation of this process now. * You can find tests code here: https://github.com/evernym/sovrin-client-rust/blob/master/tests/demo.rs * Demo code looks too raw, but this was done on purpose to avoid hiding of API calls in helpers. - Anoncreds API is implemented except revocation part. Most of the revocation code is implemented, but this code is based on thin stab for pairing functionality. To finish it we are waiting for completion of math work from Dmitry Khovratovich. - Pool API. We implemented configuration creation, pool opening, merkle tree creation and catch up process. Current catch up implementation isn't production ready as the graceful processing of error cases and shutdown is required. We will implement it after getting of basic integration. - Ledger API. We got working sovrin_submit_request call. sovrin_sign_and_submit_request and request builder calls are in progress. - Wallet API. Wallet API is implemented, but default wallet implementation is very basic and requires better security. We will enhance it after getting of basic integration. - Signus API. It is in progress now but will be finished in 1-2 working days. - iOS wrapper. We were able to build all dependencies and libsovrin and created corresponded pods for build automation. We created the simple proof of concept to make sure that wrapper is working at all and now working on the implementation of all calls and integration testing. - Python wrapper. API draft was created. You can find it here: https://github.com/evernym/sovrin-client-rust/tree/master/wrappers/python/sovrin Our backlog: - Build of libsovrin for windows and corresponded CI automation - Provide ability to execute of integration tests that works with real pool on CI (probable Jenkins instance with more ram is required) - Graceful error handling and shutdown for Pool API - Finish Signus API - Finish Ledger API - Proper security in default wallet - Deep integration testing of all API, enhance existing unit tests with complex corner cases - Finish iOS wrapper, deep testing, and automation of artifacts creation (CI is under question) - Finish python wrapper, deep testing, and automation of artifacts creation - Creation of debs and similar artifacts, integration of this scripts to CI

tyler (Mon, 08 May 2017 18:56:57 GMT):
Has joined the channel.

TelegramSam (Mon, 08 May 2017 23:40:27 GMT):
Has joined the channel.

avkrishnan (Tue, 09 May 2017 04:48:58 GMT):
Has joined the channel.

turmewr3ck (Tue, 09 May 2017 08:21:04 GMT):
Has joined the channel.

theofilis (Tue, 09 May 2017 20:44:58 GMT):
Has joined the channel.

gudkov (Wed, 10 May 2017 15:22:51 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Implemented async ios wrapper for pool and anoncreds api. - Reviewed available tests framework for ios and decided to use standard one XCTest. - Trying to get working of anoncreds demo test on iOS (in progress). - Implementation of signus API (in progress). - Implemented new complex test scenarious for MerkleTree cons proof: some failed. Trying to fix them. - Started porting of libsovrin to windows. Working on milagro windows build. - Continue python wrapper implementation.

hydrat (Thu, 11 May 2017 07:30:37 GMT):
Has joined the channel.

dhuseby (Thu, 11 May 2017 14:15:25 GMT):
Has joined the channel.

gudkov (Thu, 11 May 2017 16:11:13 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Trying to get working of anoncreds demo test on iOS (in progress). Solving ios specific io errors. - Continue implementation of Signus API (in progress). Implemented an infrastrucure for async calls on the services layer and most of the Signus related code. - Working on milagro windows build (in progress). - Review of catch up and transactions code with the team. Started refactoring to simplify this code and make it production ready.

gudkov (Fri, 12 May 2017 15:01:59 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Trying to get working of anoncreds demo test on iOS (in progress). We solved blockers and big part of test scenario was passed. - Research of rust's llv bitcode flag problem for iOS. It seems as big risk for the future. See https://github.com/rust-lang/rust/issues/35968. No reliable workaraund was found for the moment. We plan to continue this research. - Continue implementation of Signus API (in progress). Sign/Verify part was implemented. - Working on milagro windows build (in progress). Looks like we can't build it without problems to use in MSVC based projects and we have to fork it for now. We will create github issues and try to push our changes to mainstream. - Catch up and transactions code refactoring (in progress).

tiennv (Fri, 12 May 2017 17:27:49 GMT):
Has joined the channel.

peacekeeper (Sat, 13 May 2017 20:08:10 GMT):
until recently, `sovrin_open_wallet` had a `pool_handle` parameter, now this has been removed.. why?

gudkov (Mon, 15 May 2017 10:01:51 GMT):
To be able to use wallet for cases when we don't need access to the pool. For exmplae, now you can put most of crypto staff to dedicated secure machine without network access. For ceses when API requires access to the pool and the wallet at the same time you need to provide both handles. For example, in few Signus API methods. Actually this changes were rised by thinking on your question on #53 issue.

gudkov (Mon, 15 May 2017 15:44:24 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Trying to get working of anoncreds demo test on iOS (in progress). It mostly passed except small bug related to iOS/Rust API interoperability (unnecessary usage of option type). We updated libsovrin with the fix. Will re-check tomorrow. - Trying to get working of ledger demo test on iOS (in progress). - Removing of ring dependency (in progress) that have problems on iOS. Instead of this, we will use sha256 implementation from OpenSSL. - Signus API was implemented. - Working on milagro windows build (in progress). We were able to build it with MSVC, but we still need to automate this build as there were manual steps. - Working on libsovrin windows build (in progress). - Integration signus to transactions code. Implementation of write transactions (in progress).

rjones (Tue, 16 May 2017 19:37:20 GMT):
Has left the channel.

gudkov (Wed, 17 May 2017 16:06:47 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Preparation of docker configuration to automate execution of integration tests with real pool ledger on CI (in progress) - Added iOS wrapper for Signus API. - Ported Singus API demo test to iOS. Test passed. - Refactoring of Signus API to support signing of any structure JSON in sovrin compatible way. - Working on libsovrin windows build (in progress). - Refactoring of transactions code for better suportability and error cases handling. - Implementetion request builder helpers in Ledger API (in progress)

amigus (Wed, 17 May 2017 23:40:13 GMT):
Has joined the channel.

gudkov (Thu, 18 May 2017 14:27:00 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Preparation of docker configuration to automate execution of integration tests with real pool ledger on CI (in progress) - Trying to get working ledger demo test for iOS (in progress) - Refactoring of Signus API to support signing of any structure JSON in sovrin compatible way (done). - Working on libsovrin windows build. We got first build and tests passed, but we are continue work on build automation. - Refactoring of transactions code for better suportability and error cases handling (in progress). - Implementetion request builder helpers in Ledger API. Helpers were implemented. For now we are creating integration tests to check that transactions are compatible with ledger. Tests for NYM/GET_NYM/SCHEME/GET_SCHEME/ATTRIB/GET_ATTRIB passed. - Refactoring of internal error structs to correspond new code structure.

nage (Thu, 18 May 2017 14:51:36 GMT):
The regular agent WG call is scheduled to start in 10 minutes https://zoom.us/j/232861185

peacekeeper (Thu, 18 May 2017 15:42:58 GMT):
@gudkov "Implementetion request builder helpers in Ledger API" is this already included in the evernym/sovrin-client-rust repository master branch, or elsewhere?

danielhardman (Thu, 18 May 2017 15:50:29 GMT):
@gudkov I am reposting for the larger community the demos you and your team gave of libsovrin functionality. Hope that's okay. (If your sharing settings on these links aren't "viewable by anyone with the link", would you mind adjusting?) Anoncreds (Rust and iOS): - Full anoncreds workflow except revocation: Claim Definition creation, Master Secret creation, Claim Request creation, Claim creation, Proof Request creation, Proof creation, Proof verification - https://github.com/evernym/sovrin-client-rust/blob/master/tests/demo.rs (anoncreds_demo_works) - https://github.com/evernym/sovrin-client-rust/blob/master/wrappers/ios/libsovrin-pod/libsovrin-demoTests/AnoncredsDemo.mm - Recording of demo execution: https://drive.google.com/file/d/0B3cpfqLvlReadE9FeW9lVl9HZjA Ledger: - Communication with real ledger: Catch up and connection to ledger, write request creation and signing, sending of write request, sending of corresponded read request - https://github.com/evernym/sovrin-client-rust/blob/master/tests/demo.rs (ledger_demo_works) - Recording of demo execution: https://drive.google.com/file/d/0B-bXTGH2ThrALS1IbldCNDNnVUk Signus: - Storing of my did, storing of their did, signing of message, verification of message, encryption of message, decryption of message - https://github.com/evernym/sovrin-client-rust/blob/master/tests/demo.rs (signus_demo_works)

danielhardman (Thu, 18 May 2017 15:50:51 GMT):
^^^ @peacekeeper

danielhardman (Thu, 18 May 2017 15:51:40 GMT):
^^^ @cbruguera

nage (Thu, 18 May 2017 17:32:29 GMT):
For folks working on the client code please notice the DID TLS document that is being worked on in #indy-agent

gudkov (Thu, 18 May 2017 18:41:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Zg6pSSrn7oxg4xnuK) The code is in team fork. We will push it to master soon after gettig all tests passed.

peacekeeper (Thu, 18 May 2017 18:58:16 GMT):
Thanks that's what I thought, just wanted to ask, no rush.

stevetolman (Thu, 18 May 2017 19:18:16 GMT):
Has joined the channel.

tkuhrt (Fri, 19 May 2017 01:18:47 GMT):
Has joined the channel.

gudkov (Fri, 19 May 2017 14:26:49 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Preparation of docker configuration to automate execution of integration tests with real pool ledger on CI. We created an image that can be used locally, but integration to CI is still required. - Trying to get working ledger demo test for iOS (in progress). - Libsovrin windows build automation (in porgress). - Refactoring of transactions code for better suportability and error cases handling (in progress). - Refactoring of internal error structs to correspond new code structure (done). - Deep integration testing of Anoncreds API (in progress). - Implementetion request builder helpers in Ledger API. Still have few failing tests and working on solving of this.

peacekeeper (Fri, 19 May 2017 18:15:03 GMT):
if i get a CryptoBackendError while calling sovrin_sign_and_submit_request, any idea what the reason might be? some dependency not installed?

peacekeeper (Mon, 22 May 2017 06:25:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5JbQKCShwhPhe8jBA) @peacekeeper nevermind i solved this, i passed in an invalid JSON object as one of the parameters, just the "backend" related error was a bit confusing

gudkov (Mon, 22 May 2017 15:57:37 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Integrated execution of integration tests to CI with docker-based pool instance. - Researched possibility to replace Milagro with PBC for paring based revocation. We see big risks in migration to PBC that are related to license issues and platforms support. - Started implementation of Type-3 pairing revocation with Milagro.

gudkov (Mon, 22 May 2017 15:58:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ByiWNtrTJgxZmPJbD) We significantly refactored error processing on Friday. Most probable it will return more suitable error code now. Also please note that there was some changes in error codes in common section.

peacekeeper (Tue, 23 May 2017 06:22:31 GMT):
Hello, I'm trying to understand the details of the `sovrin_build_nym_request` call... In the code comments, the first 2 parameters are called `submitter_did` and `target_did`, but in demo.rs it seems `my_verkey` and `their_verkey` are passed. Also, how does the third parameter `verkey` relate to this, is it optional?

peacekeeper (Tue, 23 May 2017 10:31:17 GMT):
And another issue.. Any idea why I get the error `assertion failed: (left == right)` while calling `sovrin_open_pool_ledger()`: https://pastebin.com/aaKufQjq, with these logs on the node: https://pastebin.com/KFdDcEq7 (I'm using the latest sovrin-client-rust and connect to sovrin-node version 0.3.111)

sergey.minaev (Tue, 23 May 2017 12:28:47 GMT):
Has joined the channel.

sergey.minaev (Tue, 23 May 2017 12:31:37 GMT):
@peacekeeper hello! According to the second one issue about open_pool. Seems like sovrin-nodes pool and rust library use different genesis transactions. Now it's assert and will became critical error passed to callback as result.

sergey.minaev (Tue, 23 May 2017 12:37:32 GMT):
@peacekeeper please make sure, that you transfer to `sovrin_create_pool_ledger_config` call correct parameter `config`. This JSON should contains path to the file with genesis transactions used by nodes.

gudkov (Tue, 23 May 2017 13:11:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=XyXcCCaZpb8zChAss) Do you use master branch? sovrin_build_nym_request is implemented only in 104 pool request branch that is under review now.

peacekeeper (Tue, 23 May 2017 13:28:32 GMT):
@gudkov i'm using mostly master branch, but have also tried the feature/ledger-commands branch

peacekeeper (Tue, 23 May 2017 13:34:37 GMT):
@sergey.minaev thanks, i think i had the same genesis transactions on the pool and also libsovrin, but i'll check again to make sure

gudkov (Tue, 23 May 2017 13:43:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=cAy4emCj7cRhWmB36) In feature/ledger-command it is the error in test. their_did should be passed instead. Thanks for noticing this.

peacekeeper (Tue, 23 May 2017 14:26:31 GMT):
@sergey.minaev thanks, you were correct, my genesis transactions were inconsistent. my mistake was that in the pool i was using internal IPs (10.0.0.x), and in libsovrin i was using public IPs in the genesis transaction file (everything else was the same)

peacekeeper (Tue, 23 May 2017 14:30:55 GMT):
i now get InvalidSignature errors when calling `sovrin_sign_and_submit_request()`: ``` RemoteNode_recv_msg Node1 {"reason":"client request invalid: InvalidSignature()","reqId":1495549701068366248,"op":"REQNACK","identifier":"GJ1SzoWzavQYfNL9XkaJdrQejfztN4XqdsiV4ct3LXKL"} RemoteNode_recv_msg Node2 {"reason":"client request invalid: InvalidSignature()","op":"REQNACK","reqId":1495549701068366248,"identifier":"GJ1SzoWzavQYfNL9XkaJdrQejfztN4XqdsiV4ct3LXKL"} ```

sergey.minaev (Tue, 23 May 2017 14:37:23 GMT):
@peacekeeper do you try to run integration tests or your own code?

peacekeeper (Tue, 23 May 2017 14:37:46 GMT):
my own code using my java wrapper

peacekeeper (Tue, 23 May 2017 14:38:07 GMT):
i'm basically trying to do the ledger_demo_works demo in Java

sergey.minaev (Tue, 23 May 2017 14:38:45 GMT):
it's ok. can you run integration tests firstly to check basic functionality?

peacekeeper (Tue, 23 May 2017 14:39:23 GMT):
how do i do that? will they run if i do `cargo build` ?

sergey.minaev (Tue, 23 May 2017 14:39:46 GMT):
one moment, I will check current master state

sergey.minaev (Tue, 23 May 2017 14:41:12 GMT):
try to run `cargo test --features="local_nodes_pool"`

gudkov (Tue, 23 May 2017 14:41:21 GMT):
One moment

gudkov (Tue, 23 May 2017 14:41:40 GMT):
RUST_TEST_THREADS=1

gudkov (Tue, 23 May 2017 14:41:49 GMT):
environment variable is also required

gudkov (Tue, 23 May 2017 14:42:03 GMT):
RUST_TEST_THREADS=1 cargo test --features="local_nodes_pool"

gudkov (Tue, 23 May 2017 14:42:49 GMT):
It requires local pool. You can execute it inside docker. @sergey.minaev Can you provide instructions?

peacekeeper (Tue, 23 May 2017 14:45:30 GMT):
i think i know how to run a pool from docker

peacekeeper (Tue, 23 May 2017 14:45:33 GMT):
thx

peacekeeper (Tue, 23 May 2017 14:47:07 GMT):
but one more questions... if i start a fresh pool with genesis transactions, there are no trust anchors yet, so how can initial NYMs be created without trust anchors?

peacekeeper (Tue, 23 May 2017 14:47:07 GMT):
but one more question... if i start a fresh pool with genesis transactions, there are no trust anchors yet, so how can initial NYMs be created without trust anchors?

peacekeeper (Tue, 23 May 2017 14:47:16 GMT):
should initial trust anchors be added in the genesis transactions file ?

gudkov (Tue, 23 May 2017 14:53:56 GMT):
You can use init_sovrin_keys command to generate initial keys

gudkov (Tue, 23 May 2017 15:02:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=vp4RZdexs7AhAfQoG) Just re-checked it. generate_sovrin_pool_transactions creates default pool that contains Trustee and Steward.

gudkov (Tue, 23 May 2017 15:02:41 GMT):
You can use 000000000000000000000000Steward1 seed to create compatible Steward identity in the wallet.

gudkov (Tue, 23 May 2017 15:03:21 GMT):
To create trust anchor you need to send corresponded NYM transaction to identity ledger.

peacekeeper (Tue, 23 May 2017 15:04:11 GMT):
i see, yes i noticed the 000000000000000000000000Steward1 seed and thought it has special meaning

gudkov (Tue, 23 May 2017 15:04:34 GMT):
With python CLI you can just send command: send NYM dest=FuN98eH2eZybECWkofW6A9BKJxxnTatBCopfUiNxo6ZB role=TRUST_ANCHOR

gudkov (Tue, 23 May 2017 15:04:45 GMT):
Replace FuN98eH2eZybECWkofW6A9BKJxxnTatBCopfUiNxo6ZB with DID you want

alex.nagelberg (Tue, 23 May 2017 15:53:28 GMT):
Has joined the channel.

gudkov (Tue, 23 May 2017 16:55:10 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Solving of problems related to execution of integration tests on CI that we faced today (in progress). - Implementation of Type-3 pairing revocation with Milagro (in progress). We expect to get this working in 1-2 days. - Design of agent to agent comminication API (in progress). - Implementation of integration tests for iOS wrapper (in progress). - Implementation of PairwiseCurveCP protocol PoC in ZMQ (in progress).

peacekeeper (Wed, 24 May 2017 07:09:45 GMT):
does this look like a correct NYM request? authorized by 000000000000000000000000Trustee1? ``` { "identifier": "GJ1SzoWzavQYfNL9XkaJdrQejfztN4XqdsiV4ct3LXKL", "operation": { "dest": "Tvf18xqqpBtWXFKgYiqoqf", "type": "1", "verkey": "Fg9zzieW9UmRYqAFpfqjtkz8otnJ7erhfexvkzH2PexE" }, "reqId": 1495607631108144663, "signature": "4HFfmRpJpHAAqvsew3ppnVuY5eyXJoZaj82tYB3KenGwryAxwUTxLGnqDNAQNA2ERcrbW4ymQKAyXk6tT9UD61WG" } ```

sergey.minaev (Wed, 24 May 2017 07:50:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Q6Kbtn4Z2p9GtGGqu) @peacekeeper I try to execute your request in my environment and got probably correct response: `{"result":{"raw":null,"enc":null,"verkey":"Fg9zzieW9UmRYqAFpfqjtkz8otnJ7erhfexvkzH2PexE","type":"1","role":null,"data":null,"hash":null,"reqId":1495607631108144663,"alias":null,"txnTime":null,"rootHash":"4c7HsVkogC2E3XxWH9gcsbdeoVAv7oFxWXLpfzc7hdzF","auditPath":["ENB7qfzWgHetMjEeALxueDAggg2tN7LyqmeKcC8RvP4i","DMCXWtK5ieEWwagj5ZviWEsxhL5fv8ZGtguqbNYkvotk","FiVgaUHHJ9Nu842dcj7JBHXned5mkz6HZRyhE8kTeWUH"],"dest":"Tvf18xqqpBtWXFKgYiqoqf","seqNo":12,"signature":"4HFfmRpJpHAAqvsew3ppnVuY5eyXJoZaj82tYB3KenGwryAxwUTxLGnqDNAQNA2ERcrbW4ymQKAyXk6tT9UD61WG","signature_type":null,"ref":null,"identifier":"GJ1SzoWzavQYfNL9XkaJdrQejfztN4XqdsiV4ct3LXKL"},"op":"REPLY"}`

sergey.minaev (Wed, 24 May 2017 07:51:07 GMT):
Do you have any errors while running this request?

peacekeeper (Wed, 24 May 2017 07:54:17 GMT):
No error, but I don't think the NYM is actually added.

peacekeeper (Wed, 24 May 2017 07:54:23 GMT):
On the node, I see this log: https://pastebin.com/QktPHJRg

peacekeeper (Wed, 24 May 2017 07:55:10 GMT):
If the NYM is added correctly, should it show up in this file? `/home/sovrin/.sovrin/transactions_sandbox`

sergey.minaev (Wed, 24 May 2017 08:34:17 GMT):
You can try to send GET_NYM after this request and check the result. Same case is present in demo.

sergey.minaev (Wed, 24 May 2017 08:35:09 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Wp2Mhx6jkYWDvSHSN) AFAIK no. @gudkov can you confirm?

peacekeeper (Wed, 24 May 2017 12:26:49 GMT):
when i send GET_NYM (operation type 105) i seem to always get an answer like this, even for DIDs i never registered: ``` { "result": { "dest": "BtcqZHsRfzqu5rPt9wjZtG", "identifier": "6wFgp9XDQDKY8QesfhubAyyFY17CpJ42YvEM4aPobpSo", "data": null, "type": "105", "reqId": 1495628718651854621 }, "op": "REPLY" } ```

sergey.minaev (Wed, 24 May 2017 13:19:18 GMT):
`"data": null` seems incorrect for existing DID

sergey.minaev (Wed, 24 May 2017 13:21:27 GMT):
I will try to run pair of request (the first on will be your NYM) and share my result. Also, demo got not null data field at GET_NYM request.

peacekeeper (Wed, 24 May 2017 13:30:09 GMT):
for running local pool, is the recommendation now to run all nodes on same IP 10.0.0.2 ? i saw the changes you made today

sergey.minaev (Wed, 24 May 2017 13:30:43 GMT):
it's requirement for integration tests

sergey.minaev (Wed, 24 May 2017 13:33:45 GMT):
In your code you can use any pool, just same genesis transaction for sovrin_create_pool_ledger_config and pool itself. If you want to run integration tests from clear source, you should use all nodes at 10.0.0.2 with default keys. There is alternative - use different poll, but locally change appropriate helpers in integration tests.

sergey.minaev (Wed, 24 May 2017 13:33:45 GMT):
In your code you can use any pool, just same genesis transaction for sovrin_create_pool_ledger_config and pool itself. If you want to run integration tests from clear source, you should use all nodes at 10.0.0.2 with default keys. There is alternative - use different pool, but locally change appropriate helpers in integration tests.

peacekeeper (Wed, 24 May 2017 13:34:37 GMT):
i wonder if this will work with docker, i.e. will docker allow me to create multiple containers on same IP

sergey.minaev (Wed, 24 May 2017 13:35:15 GMT):
there is docker image in source: ci/sovrin-pool.doclerfile

peacekeeper (Wed, 24 May 2017 13:37:44 GMT):
ok will try that

sergey.minaev (Wed, 24 May 2017 13:38:07 GMT):
So, to run integration tests from clear source and default docker, please perform next steps: 1) build docker image from sovrin-pool.dockerfile `docker build -f ./sovrin-pool.dockerfile -t sovrin_pool .` (paths are relative to ci/ folder) 2) create docker network for the pool `docker network create --subnet=10.0.0.0/8 pool_network` 3) run image on fixed IP `docker run -d --ip="10.0.0.2" --net=pool_network sovrin_pool`

sergey.minaev (Wed, 24 May 2017 13:41:33 GMT):
also, the command bellow may be helpful for you (run only ledger_demo test) `cargo test --package sovrin-client --test demo ledger_demo_works`

peacekeeper (Wed, 24 May 2017 13:42:57 GMT):
do i need RUST_TEST_THREADS=1 ?

sergey.minaev (Wed, 24 May 2017 13:43:23 GMT):
if you run only one test - no.

peacekeeper (Wed, 24 May 2017 13:44:04 GMT):
ok i'll try these steps and see if the tests succeed, and afterwards i'll try to connect with the java wrapper again

sergey.minaev (Wed, 24 May 2017 13:45:34 GMT):
ok. I try to perform your NYM request and then GET_NYM. And got response for 105 with not null data...

peacekeeper (Wed, 24 May 2017 13:46:33 GMT):
i mean i tried GET_NYM without NYM first, and still got response

sergey.minaev (Wed, 24 May 2017 13:47:08 GMT):
... but with null data field?

peacekeeper (Wed, 24 May 2017 13:47:35 GMT):
yes

peacekeeper (Wed, 24 May 2017 13:47:56 GMT):
so integration test works now! yay

sergey.minaev (Wed, 24 May 2017 13:54:21 GMT):
my trace for running GET_NYM for actually added NYM

sergey.minaev (Wed, 24 May 2017 13:54:24 GMT):
https://pastebin.com/CeSc5N2N

sergey.minaev (Wed, 24 May 2017 13:58:01 GMT):
For non-existent dest in GET_NYM I got response with null data field. So, it's the same result as you mention above.

sergey.minaev (Wed, 24 May 2017 13:58:01 GMT):
For non-existent dest in GET_NYM I got response with null `data` field. So, it's the same result as you mention above.

sergey.minaev (Wed, 24 May 2017 13:58:01 GMT):
For non-existent `dest` in GET_NYM I got response with null `data` field. So, it's the same result as you mention above.

krw910 (Wed, 24 May 2017 13:59:09 GMT):
Has joined the channel.

peacekeeper (Wed, 24 May 2017 14:01:55 GMT):
thanks, i also just got successful REPLY for a NYM request using java wrapper

peacekeeper (Wed, 24 May 2017 14:02:01 GMT):
for the first time :)

peacekeeper (Wed, 24 May 2017 14:02:10 GMT):
thanks for all your help

sergey.minaev (Wed, 24 May 2017 14:02:41 GMT):
thank you for feedback)

gudkov (Wed, 24 May 2017 16:14:06 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Implementation of Type-3 pairing revocation with Milagro. We completed code and created basic integration tests, but tests execution is blocked by problems in Milagro/Milagro rust wrapper. - Soving of problems in Milagro/Milagro rust wrapper found during implementation of Type-3 pairing revocation (in progress). - Design of agent to agent comminication API. We created API draft for Libsovrin Agent 2 Agent communication API: - API calls can be found here: https://github.com/vimmerru/sovrin-client-rust/blob/e24c87b6b7e5edeca4527f6644e14606455226a4/src/api/agent.rs - Sequence diagram that illustrates workflow can be found here: https://github.com/vimmerru/sovrin-client-rust/blob/e24c87b6b7e5edeca4527f6644e14606455226a4/doc/libsovrin-agent-2-agent.puml - Implementation of integration tests for iOS wrapper. We were able to execute all existing demos sucessfully on iOS device. - Refactoring of all iOS wrapper tests to use common utility functions. - Implementation of PairwiseCurveCP protocol PoC in ZMQ (in progress).

danielhardman (Thu, 25 May 2017 02:07:20 GMT):
Heads up @here: the location of the sovrin-client-rust repo will be changed over to github.com/hyperledger/indy-sdk in the near future. Please be prepared to adjust your git remotes.

KhageshSharma (Thu, 25 May 2017 13:07:25 GMT):
Has joined the channel.

jlaw (Thu, 25 May 2017 14:26:21 GMT):
Has joined the channel.

nage (Thu, 25 May 2017 15:34:40 GMT):
The repository has been moved (Thanks @rjones!)

rjones (Thu, 25 May 2017 15:34:40 GMT):
Has joined the channel.

nage (Thu, 25 May 2017 15:35:48 GMT):
Notice that https://github.com/sovrin-foundation/sovrin-client-rust now redirects

gudkov (Thu, 25 May 2017 16:13:23 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Moved to hyperladger repo https://github.com/hyperledger/indy-sdk. CI config was updated to use this repo too. - Soving of problems in Milagro/Milagro rust wrapper found during implementation of Type-3 pairing revocation (in progress). We still see stack corruption in Milagro. - Agent 2 Agent communication API implementation (in progress). - Porting of walllet and anoncreds integration tests to iOS (in progress). - Implementation of PairwiseCurveCP protocol PoC in ZMQ (in progress). - Error structs refactoring (in progress). Simplification and fxing of error cases problems. - Improving errors handling in pool service (in progress)

nage (Thu, 25 May 2017 16:14:11 GMT):
@gudkov: How did the migration go for you and the other developers working on indy-sdk? Was it very disruptive? How long did it take on average to handle the issues related to the change? Do you think it would be a good idea to move forward with the migration of the other repositories?

gudkov (Thu, 25 May 2017 16:17:26 GMT):
@nage We didn't expirience big problems. We just changed repo-name in Jenkins pipeline config, get local copy of forks with in-progress branches, changed origin, pushed all in-progress branches to new forks and re-created pool requests.

nage (Thu, 25 May 2017 16:18:55 GMT):
Thanks for the feedback, I'll talk with @danielhardman and @stevetolman about moving the next repository

peacekeeper (Thu, 25 May 2017 17:45:09 GMT):
now that the repository has been moved to hyperledger/indy-sdk, is the plan also to change all "sovrin" terminology to "indy" in the rust library, e.g. function names and the name of the library itself?

nage (Thu, 25 May 2017 18:07:40 GMT):
yes, there is a plan to change all sovrin references to indy

gudkov (Fri, 26 May 2017 15:21:56 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Soving of problems in Milagro/Milagro rust wrapper found during implementation of Type-3 pairing revocation (in progress). We still issues. - Agent 2 Agent communication API implementation (in progress). - Porting of walllet and anoncreds integration tests to iOS (in progress). - Implementation of PairwiseCurveCP protocol PoC in ZMQ (in progress). - Error structs refactoring (in progress). Simplification and fxing of error cases problems. - Improving logging (in progress)

peacekeeper (Sat, 27 May 2017 18:54:48 GMT):
Q about error handling, it looks like internally the library has error codes and error descriptions, but on the API level only the error code (not the description) is exposed, correct?

peacekeeper (Mon, 29 May 2017 04:41:35 GMT):
Also, could someone provide an example of an ATTRIB request? Does this one look valid? ``` { "identifier": "GJ1SzoWzavQYfNL9XkaJdrQejfztN4XqdsiV4ct3LXKL", "operation": { "dest": "V4SGRU86Z58d6TV7PBUe6f", "raw": "{\"endpoint\":{\"ha\":\"127.0.0.1:5555\"}}", "type": "100" }, "reqId": 1496032790247438970, "signature": "3cYdokbuSn3SBDLHp8HmHTCiN7yWKVH1vNKigPmNGXJdaLjNrx4tw6hW5h1VK5UEWrUdkqZRihzVThZiHRwdxtdR" } ```

gudkov (Mon, 29 May 2017 07:04:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=M625cjsLKmpd8K4Du) @peacekeeper Yes, It is correct. I also have feeling that providing of error descriptions is a good idea and can help in debugging. Can you create an issue in indey-sdk repo?

peacekeeper (Mon, 29 May 2017 07:15:29 GMT):
@gudkov Done: https://github.com/hyperledger/indy-sdk/issues/19

peacekeeper (Mon, 29 May 2017 10:16:24 GMT):
@sergey.minaev maybe you can help with ATTRIB?

sergey.minaev (Mon, 29 May 2017 10:45:31 GMT):
@peacekeeper I haven't any additional information about ATTRIB request. Did you check appropriate helpers in sovrin library?

peacekeeper (Mon, 29 May 2017 10:52:07 GMT):
I used sovrin_build_attrib_request in ledger.rs, but not sure if I passed correct parameters.

peacekeeper (Mon, 29 May 2017 10:52:27 GMT):
I wonder if the above request looks correct.

peacekeeper (Mon, 29 May 2017 10:58:18 GMT):
I get `client request invalid: InvalidSignature()` when I submit this and don't really understand why.

gudkov (Mon, 29 May 2017 15:05:27 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Soving of problems in Milagro/Milagro rust wrapper found during implementation of Type-3 pairing revocation: -- Prepared determisinstic test and reported invmodp bug to comminity. -- Detailed description of milagro bug#168 -- reproducing crashes on stack_smashing_detected tests - Trying to use AMCL (rust version) as alternative pairing library: We forked repo, refactored the code to get valid cargo crate, added missed functionality (points copy and serialization) and started integration to our code (almost done). - Agent 2 Agent communication API implementation (in progress). - Porting and debugging of anoncreds integration tests to iOS (in progress). - Implementation of PairwiseCurveCP protocol PoC in ZMQ (in progress). - Error structs refactoring (in progress). Simplification and fxing of error cases problems.

peacekeeper (Mon, 29 May 2017 17:30:00 GMT):
Can only NYM owners add ATTRIBs to their own NYMs? Can a trustee or steward add ATTRIBs to someone else's NYM?

peacekeeper (Mon, 29 May 2017 17:31:48 GMT):
I guess only NYM owners can add their own ATTRIBs, wouldn't make sense otherwise.

srottem (Mon, 29 May 2017 21:00:09 GMT):
Has joined the channel.

spivachuk (Tue, 30 May 2017 11:47:12 GMT):
Has joined the channel.

spivachuk (Tue, 30 May 2017 12:31:35 GMT):
As I can understand, the rules are as follows: If the verkey has been set for a nym then only the identity owner can modify this nym's fields (including the verkey) and attributes. This also is applied to the case when the identifier is a cryptonym because the cryptonym acts as both the identifier and verkey. If the verkey has not been set (or has been removed) for a nym then only the creator of this nym can modify this nym's fields (including the verkey) and attributes. In such a case the creator of the nym is referred to as a guardian of this nym.

spivachuk (Tue, 30 May 2017 12:32:35 GMT):
@danielhardman, could you please verify this?

gudkov (Tue, 30 May 2017 16:24:42 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Trying to use AMCL (rust version) as alternative pairing library: We finished implementation of revocation code based on AMCL, but still jave fails in tests. Continue debugging. - Agent 2 Agent communication API implementation (in progress). - Creation of Agent API wrapper for iOS (in progress). - Implementation of PairwiseCurveCP protocol PoC in ZMQ (in progress). - Error structs refactoring (in progress). Simplification and fxing of error cases problems.

gudkov (Tue, 30 May 2017 16:24:42 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Trying to use AMCL (rust version) as alternative pairing library: We finished implementation of revocation code based on AMCL, but still have fails in tests. Continue debugging. - Agent 2 Agent communication API implementation (in progress). - Creation of Agent API wrapper for iOS (in progress). - Implementation of PairwiseCurveCP protocol PoC in ZMQ (in progress). - Error structs refactoring (in progress). Simplification and fxing of error cases problems.

peacekeeper (Wed, 31 May 2017 08:10:42 GMT):
looks like someone may have a similar problem as me, InvalidSignature() on an ATTRIB request: http://forum.sovrin.org/t/error-running-nodes-send-attrib-results-in-invalidsignature/278

gudkov (Wed, 31 May 2017 15:06:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=NZPo3tfbJPnbKxvyX) ATTRIB transaction must be signed by NYM owner (if corresponded transaction contains verkey) or by NYM submitter if there was no verkey in NYM transaction.

peacekeeper (Wed, 31 May 2017 17:55:59 GMT):
thanks @gudkov, could you maybe show an example working ATTRIB transaction?

gudkov (Wed, 31 May 2017 19:08:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=m9uSSXtoTGDzzhbKL) We are now working on integration tests for each transaction that sovrin supports. Hope it will be merged soon.

gudkov (Wed, 31 May 2017 19:15:54 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Revocation functionality debugging. We found the cause of our issues with Milagro and it seems can continue without crashes. we found that our points selection algorithm don't satisfy pairing rules. Trying to fix this. - Agent 2 Agent communication API implementation (in progress). Implemented integration tests and command layer for connect command. Started implementation of the service layer. - Creation of Agent API wrapper for iOS (in progress). - Implementation of PairwiseCurveCP protocol PoC in ZMQ (in progress). - Error structs refactoring (in progress). Simplification and fixing of error cases problems. - Implementation of high integration test cases for Ledger API. Implementation and debugging of integration tests related to sending of different transaction types (in progress). - Backlog grooming

mhailstone (Thu, 01 Jun 2017 16:40:21 GMT):
Has joined the channel.

mhailstone (Thu, 01 Jun 2017 16:40:43 GMT):
I'm working on getting a running agent service. I've tried running a docker-compose on the https://github.com/hyperledger/indy-sdk repository: `docker-compose run sovrin-client-rust-test` but the `ledger_demo_works` test is failing.

gudkov (Thu, 01 Jun 2017 16:53:07 GMT):
@mhailstone Execution through docker-compose doesn't support tests that work with ledger now. You need to execute dedicated pool. It can be done with docker too. You can use testUbuntu method in Jenkins to get instruction how to execute all tests

mhailstone (Thu, 01 Jun 2017 17:02:13 GMT):
@gudkov I'm not so interested in running the tests, but to get a running sovrin client/agent. I just ran the docker-compose command with the docker-compose.yml file to see what I could get running and saw the error. I'm also currently trying other options: `docker run sovrinfoundation/sovrin-client` `docker run -it sovrin-agent python -m agent.scripts.startApiServer.py 0.0.0.0 8080` after building the "sovrin-agent" image from https://github.com/sovrin-foundation/sovrin-agent/blob/master/ci/ubuntu.dockerfile but getting errors in https://github.com/sovrin-foundation/sovrin-agent/blob/master/setup.py I just created an image from https://github.com/sovrin-foundation/sovrin-client/blob/master/docker-files/Dockerfile successfully, but get an error when running `docker run -it sovrin-client`: ```Loading module /usr/local/lib/python3.5/dist-packages/config/config-crypto-example1.py libpbc.so.1: cannot open shared object file: No such file or directory```

gudkov (Thu, 01 Jun 2017 17:06:48 GMT):
I am not sure that docker files in https://github.com/sovrin-foundation/sovrin-client repo aren't outdated. You can check the following repo https://github.com/evernym/sovrin-environments/tree/master/docker that contains actual scripts to run client and node in the Docker. According to agent i have no information. I can only consult you to any questions about indy-sdk.

rjones (Thu, 01 Jun 2017 17:18:59 GMT):
Has left the channel.

mhailstone (Thu, 01 Jun 2017 17:36:30 GMT):
@gudkov Thanks for the links to the scripts repo.

gudkov (Thu, 01 Jun 2017 18:12:23 GMT):
@peacekeeper [ ](https://chat.hyperledger.org/channel/indy-sdk?msg=m9uSSXtoTGDzzhbKL) You can check this PR https://github.com/hyperledger/indy-sdk/pull/15 Some work is still required, before merging, but we was able to execute tests for all transactions types in this branch. There are some important changes in signing procedure (use hex encoding instead of base58 for raw attributes) .

gudkov (Thu, 01 Jun 2017 18:12:23 GMT):
@peacekeeper [ ](https://chat.hyperledger.org/channel/indy-sdk?msg=m9uSSXtoTGDzzhbKL) You can check this PR https://github.com/hyperledger/indy-sdk/pull/15 Some work is still required, before merging, but we were able to execute tests for all transactions types in this branch. There are some important changes in signing procedure (use hex encoding instead of base58 for raw attributes) .

gudkov (Thu, 01 Jun 2017 18:15:02 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Today we were able to correctly execute low level pairing operations with AMCL. Most probable it can be done with milagro-crypto-c too. Our confidence level that we can move with Milagro for revocation has grown significantly. - Agent 2 Agent communication API implementation (in progress). - Agent API wrapper for iOS was implemented. Waiting for libsovrin implementation to start testing. - Implementation of PairwiseCurveCP protocol PoC in ZMQ (in progress). - Error structs refactoring (in progress). Simplification and fixing of error cases problems. - We were able to execute integration tests for all transaction types, but some work is still required before merging this code to master. - Backlog grooming

peacekeeper (Thu, 01 Jun 2017 19:22:32 GMT):
thanks @gudkov and others for helpful information as always!

peacekeeper (Fri, 02 Jun 2017 06:42:07 GMT):
@gudkov I can confirm that running the `feature/ledger` branch against a pool version 0.3.124 now for the first time allows me to send successful ATTRIB and GET_ATTRIB operations!

ashcherbakov (Fri, 02 Jun 2017 12:48:06 GMT):
Has joined the channel.

sergey.minaev (Fri, 02 Jun 2017 13:59:36 GMT):
@peacekeeper we have merged the feature branch, so you can use master.

sergey.minaev (Fri, 02 Jun 2017 15:56:12 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Research problems with AMCL (finished with pair and inverse functions) - Agent 2 Agent communication API implementation (in progress). - Finished iOS wrapper for Agents API - Start learning CI service for iOS - Implementation of PairwiseCurveCP protocol PoC in ZMQ (in progress). - Error structs refactoring is finished and merged to master. - Resolve issues in integration tests with nodes pool interaction, integration tests for all transaction types are merged to master

peacekeeper (Fri, 02 Jun 2017 20:30:28 GMT):
I added some basic example code to the README of the Java wrapper: https://github.com/projectdanube/libsovrin-java

peacekeeper (Fri, 02 Jun 2017 20:30:28 GMT):
I added some basic example code to the README of the Java wrapper: https://github.com/projectdanube/libsovrin-java. Let me know if anyone has feedback.

peacekeeper (Fri, 02 Jun 2017 20:31:40 GMT):
Still need to rename it to indy-sdk-java I guess.

sergey.minaev (Mon, 05 Jun 2017 16:32:05 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Integration tests for Ledger API (high and medium cases) - Integration tests for Anoncreds API (revocation part) - Research libsovrin cross-compatibility - Agent 2 Agent communication API implementation (in progress: connect draft ready, work on listen). - Complete build and integration tests (all passed now) on Mac for libsovrin. Update documentation. - Start working on CI tool for iOS - Implementation of PairwiseCurveCP protocol PoC in ZMQ (in progress, about 50% of implementation).

peacekeeper (Mon, 05 Jun 2017 19:21:27 GMT):
Is there (or should there be) a way to enumerate all ATTRIBs associated with a NYM?

danielhardman (Mon, 05 Jun 2017 21:13:56 GMT):
@peacekeeper I have asked myself the same question and do not have an answer.

peacekeeper (Mon, 05 Jun 2017 21:18:17 GMT):
I guess any validator/observer node could offer this anyway by reading internally straight from their node's database, but not sure if that's good practice.

MRJCrunch (Tue, 06 Jun 2017 11:37:00 GMT):
Has joined the channel.

sergey.minaev (Tue, 06 Jun 2017 21:55:31 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Implementation of Wallet API high and medium cases integration tests. - Implementation of Signus API integration tests. - Research libsovrin cross-compatibility, start working on schema transaction. - Agent 2 Agent communication API implementation (in progress: work on listen, discuss some problems). - Complete build and integration tests (all passed now) on Mac for libsovrin. Update documentation. - Debug new integration tests on iOS. - libcurve modifications for PoC of PairwiseCurveCP.

sergey.minaev (Tue, 06 Jun 2017 21:55:31 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Implementation of Wallet API high and medium cases integration tests. - Implementation of Signus API integration tests. - Research libsovrin cross-compatibility, start working on schema transaction. - Agent 2 Agent communication API implementation (in progress: work on listen, discuss some problems). - Debug new integration tests on iOS. - libcurve modifications for PoC of PairwiseCurveCP.

sergey.minaev (Wed, 07 Jun 2017 21:43:40 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Implementation of Signus API integration tests, update Signus verify command. - Continue working on libsovrin cross-compatibility. - Agent 2 Agent communication API implementation (finish draft for listen). - Finish debugging of new integration tests on iOS. - Finish libcurve modifications for PoC of PairwiseCurveCP, start fixing failed self-tests.

peacekeeper (Thu, 08 Jun 2017 16:08:21 GMT):
@nage Maybe you could at some point give an overview how we can move the Java wrapper to align with the rest of the project

peacekeeper (Thu, 08 Jun 2017 16:08:30 GMT):
https://github.com/projectdanube/libsovrin-java

peacekeeper (Thu, 08 Jun 2017 16:08:54 GMT):
E.g. I think I should rename it to indy-sdk-java, change license to Apache2, change Java package names according to some convention

peacekeeper (Thu, 08 Jun 2017 16:09:03 GMT):
Not sure what else

nage (Thu, 08 Jun 2017 16:11:06 GMT):
@gudkov We are hoping to make room inside of indy-sdk for language wrappers around the library. Could you give it some thought and give us a recommendation on how it might make sense to organize this code? In particular we will want to pay attention to how building and testing those SDKs might work so that we don't introduce unnecessary dependencies on people who are only developing against one particular API personality (for example: folks working on a C# personality of the SDK shouldn't have to worry about Java dependencies)

nage (Thu, 08 Jun 2017 16:11:35 GMT):
@peacekeeper have you logged a ticket for this in Hyperledger Jira yet? If not, could you make one and outline what you're proposing?

nage (Thu, 08 Jun 2017 16:13:02 GMT):
With respect to the legal parts, you'll want to license the code under Apache-2 and make sure all the contributors are happy with the license switch and able to sign the Hyperledger CLA that is available on CLAHub (I'm not sure if we've fully integrated and set that up yet)

nage (Thu, 08 Jun 2017 16:14:31 GMT):
we could have @rjones move the repo as it exists now over to Hyperledger as indy-sdk-java, if we decide that keeping them in their own repos is more desirable.

rjones (Thu, 08 Jun 2017 16:14:32 GMT):
Has joined the channel.

peacekeeper (Thu, 08 Jun 2017 16:39:34 GMT):
ok created this: https://jira.hyperledger.org/browse/INDY-184

danielhardman (Fri, 09 Jun 2017 00:09:28 GMT):
Thanks for creating the ticket, @peacekeeper . I left a comment.

danielhardman (Fri, 09 Jun 2017 00:09:28 GMT):
Thanks for creating the ticket, @peacekeeper . I left a comment in jira.

sergey.minaev (Fri, 09 Jun 2017 02:15:51 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Implementation of Signus API integration tests finished. - Implementation of Anoncreds API integration tests started. - Continue working on libsovrin cross-compatibility. - Debug libsovrin and ledger exchange. Discuss about quorums (read/write). - Start porting new integration tests to iOS. - Finish fixing self-tests for libcurve.

sergey.minaev (Fri, 09 Jun 2017 13:54:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=tT6oNtXysx2EAdagS) @nage AFAIK there is folder `wrappers` in ind-sdk and it now contains ios and python stubs. @ashcherbakov, can you confirm?

sergey.minaev (Fri, 09 Jun 2017 13:54:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=tT6oNtXysx2EAdagS) @nage AFAIK there is folder `wrappers` in indy-sdk and it now contains ios and python stubs. @ashcherbakov, can you confirm?

ashcherbakov (Fri, 09 Jun 2017 13:55:47 GMT):
Yes, currently it's done as Sergey described.

peacekeeper (Fri, 09 Jun 2017 19:14:27 GMT):
Note that other Hyperledger projects seem to have separate repos, e.g. "fabric-sdk-go" "fabric-sdk-py" "iroha-scala" "iroha-python" "iroha-android".

rjones (Fri, 09 Jun 2017 20:44:18 GMT):
@peacekeeper that is an artifact of governance IMHO

rjones (Fri, 09 Jun 2017 20:46:12 GMT):
@peacekeeper Iroha is mostly one team, but the Fabric SDKs aren't necessarily built by subsets of the core fabric developers.

rjones (Fri, 09 Jun 2017 20:46:44 GMT):
@peacekeeper so having the Python SDK operating with a set of maintainers and rules that are distinct from Fabric itself makes sense.

sergey.minaev (Fri, 09 Jun 2017 22:18:41 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Implementation of Anoncreds API integration tests. - Continue working on libsovrin cross-compatibility. - Debug unit and integration test cases. Stability fixes. - Continue working on CI for Mac (setup bitrise.io CI, resolve problems) - Porting new integration tests to iOS. - Discuss PairwiseCurveZMQ PoC.

danielhardman (Tue, 13 Jun 2017 15:09:43 GMT):
@rjones and @nage , I am wondering if we need another jira project for indy-sdk. This codebase releases on different milestones from indy itself; it has different contributors, a different build system, and a different backlog. What do you think? Alternatively, I suppose we could use tags within the indy project instead... @avkrishnan @gudkov

nage (Tue, 13 Jun 2017 15:11:44 GMT):
In discussions with developers before the migration started, we talked about using tags within the indy project (I think that was the consensus). I like the idea of having one place for all Indy tickets but am open to other ideas.

avkrishnan (Tue, 13 Jun 2017 15:52:54 GMT):
My vote is for a separate project. As @danielhardman has pointed out, there are sufficient differences between the indy and indy-sdk projects, and having only a tag to differentiate between them would, I feel, add to the management burden.

danielhardman (Tue, 13 Jun 2017 16:04:49 GMT):
I'd prefer two projects, I think. However, if that is anomalous with respect to standard hyperledger practice, we can make it work in one project.

sergey.minaev (Tue, 13 Jun 2017 21:40:56 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Implementation of Anoncreds API integration tests, update Anoncreds commands. - Discuss Agent2Agent API, make part of changes. - Continue working on CI for Mac (continue resolving problems in bitrise.io) - Continue porting new integration tests to iOS. - Investigate libzmq for new variant of PairwiseCurveZMQ PoC

rjones (Wed, 14 Jun 2017 04:30:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=M8fLPTprkhp9nXFaN) @danielhardman let me know what you decide - I have no opinion on it

danielhardman (Wed, 14 Jun 2017 04:31:12 GMT):
I prefer to have two projects. Can you create "indy-sdk" as a clone of "indy"?

rjones (Wed, 14 Jun 2017 04:34:59 GMT):
https://jira.hyperledger.org/projects/IS/issues/?filter=allopenissues

rjones (Wed, 14 Jun 2017 04:35:17 GMT):
I can't clone a project, but it looks like a copy

srottem (Wed, 14 Jun 2017 07:16:44 GMT):
I assume that the current target for the indy-sdk is to build cloud agents (e.g. on Linux or Windows servers) - is there any working being done in the direction of building local agents (e.g. on Android or iOS)? My understanding at this point is that there will be some challenges as there are no implementations of the RAET protocol and some of the supporting software stacks for these OSes...is that right?

danielhardman (Wed, 14 Jun 2017 18:39:59 GMT):
Actually, the iOS work is much further along than you might guess.

danielhardman (Wed, 14 Jun 2017 21:16:04 GMT):
Please check with @gudkov , @avkrishnan , and @KhageshSharma for status.

sergey.minaev (Wed, 14 Jun 2017 22:18:08 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Finish implementation of Anoncreds API integration tests, and updating Anoncreds commands. - Resume implementation of Agent2Agent (work on logic for sending messages). - Continue working on CI for Mac (continue resolving problems in bitrise.io) - Continue porting new integration tests to iOS. - Continue investigate libzmq for PairwiseCurveZMQ PoC

rjones (Wed, 14 Jun 2017 22:21:59 GMT):
Has left the channel.

nage (Thu, 15 Jun 2017 05:01:12 GMT):
@here would someone be able to give updates about Indy-sdk and the language wrappers during tomorrow's Agent WG discussion? It sounds like there is interest in seeing the iOS wrapper and knowing more about the status of various language wrappers.

nage (Thu, 15 Jun 2017 05:01:35 GMT):
(See #indy-agent for call information)

avkrishnan (Thu, 15 Jun 2017 05:03:03 GMT):
@nage I will see if we can have someone available to do this

ashcherbakov (Thu, 15 Jun 2017 07:29:11 GMT):
@nage I think Kirill Neznamov can present iOS demo. There is also a recorded iOS demo, I will send it to you. Sergey Minaev can talk about indy-sdk status in general. As for the languages support, we have working iOS wrapper, @peacekeeper's been working on Java wrapper. Also we have a wrapper for Python API, but there is no implementation there (it's in TODO list).

peacekeeper (Thu, 15 Jun 2017 07:34:04 GMT):
i may join a bit late on today's WG call, but can give an update on the Java wrapper then

srottem (Thu, 15 Jun 2017 07:37:22 GMT):
Thanks for the update everyone. Unfortunately I don't think I'm going to make today's call due to prior commitments but I'll do my best.

cybermag (Thu, 15 Jun 2017 09:34:24 GMT):
Has joined the channel.

sergey.minaev (Thu, 15 Jun 2017 14:11:03 GMT):
@nage what about my and Kirill (@cybermag) participating in the Agent WG discussion?

sergey.minaev (Thu, 15 Jun 2017 14:11:03 GMT):
@nage what about my and Kirill ( @cybermag ) participating in the Agent WG discussion?

nage (Thu, 15 Jun 2017 14:18:03 GMT):
@sergey.minaev please join us!

nage (Thu, 15 Jun 2017 14:18:21 GMT):
the meeting starts in ~42 minutes

sergey.minaev (Thu, 15 Jun 2017 14:18:30 GMT):
ok

sergey.minaev (Thu, 15 Jun 2017 21:33:47 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Implementation of Pool API integration tests, updating Anoncreds tests. - Finish minimal implementation of Agent2Agent (just simple listen+connect+send messages, no errors handling, no close, etc). - Discuss about CI for iOS, check docker pool from Mac host. - Continue working on libsovrin cross-compatibility. - Continue porting new integration tests to iOS. - Continue working on PoC for PairwiseCurveZMQ in libzmq.

peacekeeper (Thu, 15 Jun 2017 21:42:19 GMT):
I created a pull request for the Java wrapper: https://github.com/hyperledger/indy-sdk/pull/46

sergey.minaev (Fri, 16 Jun 2017 12:49:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=s66uRhkQgjhKfcJiH) @peacekeeper merged

Artemkaaas (Fri, 16 Jun 2017 14:32:08 GMT):
Has joined the channel.

sergey.minaev (Fri, 16 Jun 2017 20:21:52 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Minor updates in integration test. - Continue implementation of Agent2Agent (close connection logic). - Successfully run docker pool from Mac host. - Continue working on libsovrin cross-compatibility. - Continue porting new integration tests to iOS. - Continue working on PoC for PairwiseCurveZMQ in libzmq.

gudkov (Mon, 19 Jun 2017 14:21:34 GMT):
@peacekeeper Do you have plans to provide wrapper for libsovrin Agent 2 Agent communication API https://github.com/hyperledger/indy-sdk/blob/master/src/api/agent.rs?

sergey.minaev (Mon, 19 Jun 2017 15:54:50 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Moving to hyperledger JIRA. - Minor updates in integration tests. - Continue implementation of Agent2Agent (refactoring, get info from ledger for connect). - Continue working on libsovrin cross-compatibility (claim_request). - Working on implementing Anoncreds tests for iOS. Almost finished all high cases tests. - Continue working on PoC for PairwiseCurveZMQ in libzmq.

peacekeeper (Tue, 20 Jun 2017 06:20:42 GMT):
@gudkov yes I will add the wrapper for agent.rs some time this week

gudkov (Tue, 20 Jun 2017 14:31:10 GMT):
@peacekeeper Do you have any integration tests for java wrapper? For example, for iOS wrapper we plan to port all high cases integration tests from libsovrin. Should we integrate tests execution and artifacts creation to CI?

peacekeeper (Tue, 20 Jun 2017 14:33:18 GMT):
I have started some very simple unit tests, but they are not very useful at this point. I agree it would probably make sense to do what you describe, i.e. port standard tests to all the wrappers including Java.

gudkov (Tue, 20 Jun 2017 14:33:51 GMT):
Also we need to discuss versioning approach. Espetially versions synchronization between libsovrin and wrappers.

peacekeeper (Tue, 20 Jun 2017 14:34:21 GMT):
Yes I'm very interested in the versioning question. Is there a timeline or proposed date for a certain version/tag ?

gudkov (Tue, 20 Jun 2017 14:38:25 GMT):
For current moment no, but i hope to get some vision soon.

gudkov (Tue, 20 Jun 2017 14:46:40 GMT):
Also interesting question is should wrappers in one branch be comatible with libsovrin in same branch or depend on some version/tag.

peacekeeper (Tue, 20 Jun 2017 16:02:21 GMT):
I think it's hard to keep libsovrin and wrappers always in sync (for example, one parameter was removed from `sovrin_build_nym_request`, and I only updated the Java wrapper a few days later).

peacekeeper (Tue, 20 Jun 2017 16:03:04 GMT):
But of course for release tags all wrappers must be in sync.

peacekeeper (Tue, 20 Jun 2017 16:16:01 GMT):
2 questions.. 1. In `sovrin_agent_connect()`, is there a guarantee that `connection_cb()` will be called only once? 2. In `sovrin_agent_listen()`, is there a guarantee that `listener_cb()` will be called only once?

gudkov (Tue, 20 Jun 2017 17:57:23 GMT):
Yes, listener_cb and connection_cb will be executed once. Actually it is the result of this calls.

peacekeeper (Tue, 20 Jun 2017 18:33:25 GMT):
thx makes sense

danielhardman (Tue, 20 Jun 2017 21:13:46 GMT):
@gudkov Are these semantics described in the comment next to the function? All API semantics need to be documented in our comments.

sergey.minaev (Tue, 20 Jun 2017 22:14:09 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Finish moving to hyperledger JIRA. - Finish base implementation of Agent2Agent. - Review technical debt, start working on Pool API (close/delete) - Continue working on libsovrin cross-compatibility (claim_request, create proof). - Working on implementing Anoncreds tests for iOS. Finished high cases tests, start medium cases. - Finish primitive PoC for PairwiseCurveZMQ in libzmq, discuss modification libzmq for Agent2Agent.

gudkov (Wed, 21 Jun 2017 10:01:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=zLxTPbvwv9eDQzGbf) We have reasonable comment for each callback and parameter, but we will extend this description a bit today as we see questions about this semantics.

sergey.minaev (Wed, 21 Jun 2017 10:12:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6uGaQBq5NWxLmemMx) @gudkov done as part of PR-48

peacekeeper (Wed, 21 Jun 2017 20:39:51 GMT):
I started work on the Java wrapper for agent.rs, but need to think a bit more on how to properly model the various callbacks in Java: https://github.com/peacekeeper/indy-sdk/tree/master/wrappers/java/src/main/java/org/hyperledger/indy/sdk/agent

peacekeeper (Wed, 21 Jun 2017 20:39:51 GMT):
I started work on the Java wrapper for agent.rs, but need to think a bit more about how to properly model the various callbacks in Java: https://github.com/peacekeeper/indy-sdk/tree/master/wrappers/java/src/main/java/org/hyperledger/indy/sdk/agent

sergey.minaev (Wed, 21 Jun 2017 22:00:08 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Review and correction of integration tests. - Finish technical debt for PoolAPI (close/delete/refresh), update integration tests for new calls. - Continue working on libsovrin cross-compatibility (claim, create proof and verify). - Finish implementing Anoncreds tests for iOS, checking and updating other tests. - Working on libzmq fork with functionality for PairwiseCurveZMQ (multiply server keypairs, client identification).

harrihoo (Thu, 22 Jun 2017 08:30:14 GMT):
Has joined the channel.

wightman (Thu, 22 Jun 2017 15:44:08 GMT):
Has joined the channel.

himansri (Thu, 22 Jun 2017 17:57:08 GMT):
Has joined the channel.

sergey.minaev (Thu, 22 Jun 2017 21:37:14 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Review and refactoring of ledger integration tests. Implementation of missed cases and Ledger API bugfixes. - Working on libsovrin cross-compability: finished anoncreds create proof and verify. Fix and update tests for python modules. - Finished with new pool tests, started agent tests - Create forks for Rust ZMQ wrappers for PW, working on build. - Implement workaround for receiving connection information for Agent2Agent communication from ledger: use ATTRIB transaction instead of unimplemented in ledger DDO.

sergey.minaev (Fri, 23 Jun 2017 22:55:43 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Support of build on Amazon Linux and other RHEL based platforms. Creation of Amazon Linux based Dockerfile with build environment for future integration to CI (in progress). - Bugfixes in Ledger API (in progress) - Working on libsovrin cross-compability: fixing tests because of changes for claim, writing test for claim. Working on sovrin-client: create proof and verify - iOS integration tests: added CoreBitcoin framework for tests to work with base58 data format. Fixing anoncreds tests after recent merge - Working on build for libzmq-pw. Start integration into indy-sdk

mvsjober (Mon, 26 Jun 2017 11:29:33 GMT):
Has joined the channel.

Tiitus (Mon, 26 Jun 2017 12:54:33 GMT):
Has joined the channel.

sergey.minaev (Mon, 26 Jun 2017 20:23:26 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Finish work on main part of iOS integration test - all pass, started working on agent tests. - Removing unnecessary dependencies from RHEL build. Actualization of build instructions for all platforms (in progress). - Continue working on libsovrin cross-compability: sovrin-client - changing of proof request and create proof. - Continue integration forked zmq with PW functionality to libsovrin, working on verification of client.

sergey.minaev (Tue, 27 Jun 2017 21:23:54 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Working on libsovrin cross-compatibility: sovrin-client - changing of proof request, implementation of GET_TXNS operation. - Better build documentation for all platforms was provided. - Working on iOS build with zmq forks with PW functionality - Update client verification in Agent2Agent communication.

sergey.minaev (Wed, 28 Jun 2017 15:40:34 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Working on libsovrin cross-compatibility: implemented of GET_TXNS operation, updated create proof and verify, debug test for process claim received from libsovrin - Implementation of sovrin_register_wallet_type call - Working on iOS Agent2Agent tests (initial implementation finished, not tested yet) - Finish client verification in Agent2Agent communication.

sergey.minaev (Thu, 29 Jun 2017 16:40:59 GMT):
@peacekeeper we have merged changes in Agent2Agent API into master branch. The main difference is splitting old call `sovrin_agent_listen(endpoint, wallet_handle, did)` into 2 new: `sovrin_agent_listen(endpoint)` and `sovrin_agent_add_identity(listener_handle, wallet_handle, pool_handle, did)` So listener will start on predefined endpoint and before `add_identity` will not accept any connections. Also `add_identity` can be called multiply times for different DID but for same listener.

sergey.minaev (Thu, 29 Jun 2017 21:26:51 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Working on libsovrin cross-compability: sovrin-client create proof and verify updating, testing for claim and proof. - Continue implementation of custom registered wallet (API call sovrin_register_wallet_type). - Continue working on libzmq-pw for iOS, review integration test on iOS. - Implement disabling Identity for listener in Agent2Agent API. Initial implementation of Agent2Agent is finished.

peacekeeper (Thu, 29 Jun 2017 22:21:12 GMT):
Thanks @sergey.minaev and @gudkov, I updated the Java `agent.rs` wrapper with those new methods. Also as mentioned on today's agent call I created a fresh pull request even though the callbacks are not expressed well yet in the Java wrapper: https://github.com/hyperledger/indy-sdk/pull/71

srottem (Fri, 30 Jun 2017 14:49:26 GMT):
Is there anyone out there who can help me get a Windows build environment set up for indy-sdk?

gudkov (Fri, 30 Jun 2017 15:06:58 GMT):
@srottem I use windows envrionment and can help you. Have you checked https://github.com/hyperledger/indy-sdk/blob/master/doc/windows-build.md? For curremt moment we have technical problems in our repo with pre-build dependencies, but we hope it will be available soon.

srottem (Fri, 30 Jun 2017 15:16:58 GMT):
@gudkov I have, but I've been running into problems. I'm working with VS 2017 community edition on Windows 10 64-bit. Following the directions in that doc fail on building pretty much all of the pre-build dependencies (as you mentioned) and I'm guessing there are a lot of build environment prerequisites that are implied that I'm not really aware of - for example cmake isn't available by default in Windows and I didn't know where it should come from. I've made some progress by installing msys2 and mingw64 but I'm still having problems.

gudkov (Fri, 30 Jun 2017 15:21:00 GMT):
We don't have near plans to support msys or mingw64 for the current moment. It is better to use MSVC based build. I suggest the following: 1. I will share with you pre-build dependencies as quick workaround 2. It would be nice if you can create a bug about Windows build documentation enhancement and point your problems in this bug.

srottem (Fri, 30 Jun 2017 15:22:54 GMT):
That would be magnificent. Since I haven't manage to build the source deps I don't have any real feedback on building the SDK itself, but I'll definitely open a ticket. I'll see if I can't create a pull request with an updated readme if I manage to figure out how to build the deps too.

gudkov (Fri, 30 Jun 2017 15:25:24 GMT):
You can download cmake here: https://cmake.org/download/ Just use latest msi. Most probanle there will be no additional tools needed except MSVC.

sergey.minaev (Fri, 30 Jun 2017 17:16:17 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Implementation of sovrin_register_wallet_type. Draft implementation was finished. Working on examples and testing. - Working on libsovrin cross-compatibility: added tests for create proof and verify, fix old sovrin_client tests. - Debug and fix consistency proofs checking in Rust implementation of MerkleTree.

nage (Mon, 03 Jul 2017 20:49:24 GMT):
@gudkov and @danielhardman what are our plans for releasing indy-sdk? I'm discussing code maintenance with @peacekeeper and we would like coordinate releases so things stay stable together for all the wrappers.

nage (Mon, 03 Jul 2017 20:50:12 GMT):
There have also been discussions about reusing rust tests for other wrappers, and we should discuss how this might work (let's discuss this here and perhaps queue something up for next week's agent WG call if chat is insufficient?)

sergey.minaev (Mon, 03 Jul 2017 21:33:19 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Working on libsovrin cross-compatibility: refactoring, fixing sovrin_client tests. - Start working on libzmq-pw pod for iOS. - Update indy-sdk to be compatible with the latest pool. - Finish migration to new Jenkins.

danielhardman (Mon, 03 Jul 2017 23:40:09 GMT):
@avkrishnan, please join in the discussion of @nage's question about release plans.

danielhardman (Mon, 03 Jul 2017 23:41:01 GMT):
My own expectation is that the sdk releases soon after the network goes live, and this constitutes version 1.0 of the sdk. Then we release on a cadence (e.g., every 2-3 months thereafter).

avkrishnan (Tue, 04 Jul 2017 03:53:40 GMT):
Slava (@gudkov) and I are working on a release plan for indy-sdk and we will communicate it in a few days.

srottem (Tue, 04 Jul 2017 20:23:12 GMT):
Is anyone working on a .NET wrapper at the moment? If not I'll put my hand up to get started.

sergey.minaev (Tue, 04 Jul 2017 23:07:48 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Working on libsovrin cross-compatibility: implemented GET_TXN transaction and tests. Added tests and code refactoring in pysovrin_client - Continue working on libzmq-pw pod for iOS. - Debug agent integration test on iOS. - Debug register custom wallet logic. - Draft implement consistency proofs checking in catchup.

sergey.minaev (Tue, 04 Jul 2017 23:08:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mPM7S3RuQ4pMjZdcN) @srottem AFAIK no, @gudkov @avkrishnan can you confirm?

avkrishnan (Wed, 05 Jul 2017 03:36:17 GMT):
@srottem, @sergey.minaev As of now, we are not aware of anyone working on a .Net wrapper

srottem (Wed, 05 Jul 2017 05:40:10 GMT):
I'll get started and post a pull request when I have something useful. I'm working with @peacekeeper on the Java API and will endeavor to follow the same approach.

avkrishnan (Wed, 05 Jul 2017 06:13:32 GMT):
Thanks, @srottem !

sergey.minaev (Wed, 05 Jul 2017 16:28:03 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Continue working on libzmq-pw pod for iOS (almost done). - Working on Pysovrin Interoperability: replace claim_def_seq_no to issuer_did and schema_seq_no for Claim Definition in indy-sdk (almost done). - Debugged Agent tests, updating integration tests. - Correcting Get_txn transaction in python. - Testing of sovrin_register_wallet_type.

avkrishnan (Thu, 06 Jul 2017 09:29:54 GMT):
@srottem @peacekeeper @gudkov Thanks for joining the call to discuss the Java wrapper. Symon, Marcus: please update this ticket https://jira.hyperledger.org/browse/INDY-7 with your Linux Foundation IDS. I will work on getting you access to our CI servers using those IDs.

peacekeeper (Thu, 06 Jul 2017 09:50:09 GMT):
yes thanks for the call, just updated that ticket

avkrishnan (Thu, 06 Jul 2017 10:12:45 GMT):
Thanks, Marcus. I see that you are also able to make updates to the IS (IndySDK) project in Hyperledger Jira, which is good.

sergey.minaev (Thu, 06 Jul 2017 16:57:03 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Finish work on libzmq-pw pod for iOS. - Writing integration tests for pool. - Updating jenkinsfile for redhat. - Working on Pysovrin Interoperability: finish replace claim_def_seq_no to issuer_did and schema_seq_no for Claim Definition, start Interoperability tests. - Resume work on checking proofs while CatchUp. - Updating iOS integration tests for pool and anoncreds. - Testing of sovrin_register_wallet_type.

jleders (Thu, 06 Jul 2017 22:22:57 GMT):
Has joined the channel.

peacekeeper (Fri, 07 Jul 2017 11:44:05 GMT):
any idea why Jenkins on this pull request says "This commit cannot be built"? https://github.com/hyperledger/indy-sdk/pull/71

avkrishnan (Fri, 07 Jul 2017 14:19:15 GMT):
It probably has to do with the changes we are making to the CI infrastructure. I think you might need explicit privileges. Tagging @tharmon to take a look. BTW, @peacekeeper were you able to trigger builds earlier (a couple of weeks back)?

avkrishnan (Fri, 07 Jul 2017 16:27:01 GMT):
Looks like the build has completed after the PR. We see some issues, not sure if they have been completely fixed. Let us know if this happens again.

peacekeeper (Fri, 07 Jul 2017 19:33:38 GMT):
ok looks good now thanks, maybe someone can merge it, it has the in-progress agent wrapper and some other changes

peacekeeper (Fri, 07 Jul 2017 19:34:27 GMT):
also FYI, @srottem and i have gone through a simple exercise where he fixed a bug, and i successfully reviewed+approved+merged it: https://github.com/hyperledger/indy-sdk/pull/87

sergey.minaev (Fri, 07 Jul 2017 20:10:44 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - Updating and testing CI for redhat. - Working on Pysovrin Interoperability: Interoperability tests. - Finish implementation of checking proofs while CatchUp. - Updating iOS integration tests for anoncreds. - Finish API call sovrin_register_wallet_type with high-level integration tests. - Switching to sprint based management approach. Stories estimation.

gudkov (Mon, 10 Jul 2017 09:43:52 GMT):
Hello all, Friday build of pool has a issue that prevents pool from starting and also contains interoperability issues with indy-sdk. Indy-sdk CI will be broken until fixing of https://jira.hyperledger.org/browse/INDY-391 and https://jira.hyperledger.org/browse/IS-199

gudkov (Mon, 10 Jul 2017 13:31:44 GMT):
@peacekeeper I added review for your #71 PR. There are some important suggestions about Agent interface and proposal how to fix GC issues with callbacks. Please ping me in case you have any questions.

gudkov (Mon, 10 Jul 2017 14:34:49 GMT):
@peacekeeper I plan to create few issues in Jira related to my code review and assign this issues to you,

peacekeeper (Mon, 10 Jul 2017 14:36:19 GMT):
thanks, I just had a quick look.... the pattern using a single static callback with a map of command handles and futures is also what i had in mind

sergey.minaev (Mon, 10 Jul 2017 16:43:24 GMT):
Here’s what our team that’s working on the c-callable sovrin client got done today: - working on jenkins pipeline for redhat, almost done - check get_txn tests (with latest nodes pool) - updating wallet tests on iOS - working on IS-185: Pysovrin Interoperability: Interoperability test - code review of Java Wrapper - change to fixed dependency on pool version

gudkov (Tue, 11 Jul 2017 09:26:54 GMT):
@peacekeeper Usage of JSONParameters in methods signature conflicts with the idea to be as close as possible to the original Indy sdk API. Also in some cases this json's can be extended by user. For example, user can register custom wallet type and configuration params will be managed by user's code. It is better to use the same types as Indy sdk, but we can leave JSONParameters as dedicated request builders. So instead of someCall(SomeJSONParameter("a", "b")) user will just use without any addidional pain someCall(SomeJSONPArameter("a", "b")::toJson()) or directly someCall("{a: a, b: b}") I created IS-216 about it.

sergey.minaev (Tue, 11 Jul 2017 12:43:21 GMT):
Hello all, we have merged to master total renaming from `sovrin` to `indy` prefix. Changes applied for sources, include files, libraries and also for Java wrapper. Renaming for iOS wrapper in progress now.

fabienpe (Tue, 11 Jul 2017 15:13:11 GMT):
Has joined the channel.

sergey.minaev (Tue, 11 Jul 2017 16:16:38 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Working on java wrapper tests. - Updated iOS tests, renamed libsovrin to libindy iOS framework. - Total renaming `sovrin` to `indy`. - Check compatibility with the sovrin-node v0.4.19. - Sprint planning. - Working on python wrapper infrastructure. - Working on IS-185: Pysovrin Interoperability: Interoperability test; fixing problems with compatibility

nage (Wed, 12 Jul 2017 15:03:20 GMT):
There is a new #indy-pr-review channel where code owners and maintainers should hang out for responding to and reviewing pull requests (see you there!)

tharmon (Wed, 12 Jul 2017 15:44:04 GMT):
Has joined the channel.

tharmon (Wed, 12 Jul 2017 15:45:37 GMT):
Does the Java wrapper require Java 1.8? Or, is 1.7 sufficient?

sergey.minaev (Wed, 12 Jul 2017 16:57:40 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Continue working on java wrapper tests (wallet - complete; pool and signus - in progress). - Finish iOS tests and renaming in the wrapper. All tests checked and working. Built new version of libindy-core pod. - Check compatibility with the sovrin-node v0.4.21. - Pysovrin Interoperability tests - finished. Need to integrate it to ci. - Implementation of Python wrapper infrastructure for indy-sdk (in progress).

sergey.minaev (Wed, 12 Jul 2017 16:57:40 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Continue working on java wrapper tests (wallet - complete; pool and signus - in progress). - Finish iOS tests and renaming in the wrapper. All tests checked and working. Built new version of libindy-core pod. - Check compatibility with the sovrin-node v0.4.21. - Pysovrin Interoperability tests - finished. Need to integrate it to CI. - Implementation of Python wrapper infrastructure for indy-sdk (in progress).

peacekeeper (Wed, 12 Jul 2017 19:46:22 GMT):
@tharmon it should actually be able to work with 1.5, i'll make this change, thanks for pointing it out

tharmon (Wed, 12 Jul 2017 23:41:52 GMT):
@peacekeeper It's using the `CompletableFuture` class, which appears to be a 1.8 class, but I'm not a Java expert.

peacekeeper (Thu, 13 Jul 2017 08:49:22 GMT):
@tharmon i think you're right.. let's see if maybe we can replace CompletableFuture with something else

Rouven (Thu, 13 Jul 2017 12:26:18 GMT):
Has joined the channel.

sergey.minaev (Thu, 13 Jul 2017 21:55:48 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Continue working on java wrapper tests: pool, signus, anoncreds. - Implement compatibility with the indy-node v0.4.23. - Working on Pysovrin interoperability tests. - Continue working on implementation of Python wrapper.

MRJCrunch (Fri, 14 Jul 2017 15:31:30 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Finished signus and demo integration tests for Java wrapper. Start working on ledger tests. - Working on Agent2Agent in Java wrapper: simplify callbacks logic, update demo test. - Create draft Agent2Agent demo in Rust integration tests. - Finished Pysovrin interoperability tests. Added these tests to ci. - Continue working on implementation of Python wrapper. Implemented basic infrastructure, Wallet API, ported part of Wallet API tests.

tharmon (Fri, 14 Jul 2017 16:45:43 GMT):
@MRJCrunch Have these changes been checked into `master` or is there a PR that I should be monitoring? I'm very interested in this.

srottem (Sat, 15 Jul 2017 21:32:34 GMT):
I've just updated my indy-sdk source from hyperledger/master on GitHub and when I run cargo build on Windows it's failing with "error: failed to run custom build command for `indy-sdk v0.1.1 ...` process didn't exit successfully: `...\indy-sdk-f1a509f84656fab5\build-script-build` (exit code: 101)" I'm a little lost on why this is failing - have some of the binary dependencies changed or might this be some other problem?

srottem (Sat, 15 Jul 2017 21:32:34 GMT):
I've just updated my indy-sdk source from master branch on GitHub and when I run cargo build on Windows it's failing with "error: failed to run custom build command for `indy-sdk v0.1.1 ...` process didn't exit successfully: `...\indy-sdk-f1a509f84656fab5\build-script-build` (exit code: 101)" I'm a little lost on why this is failing - have some of the binary dependencies changed or might this be some other problem?

MRJCrunch (Mon, 17 Jul 2017 07:34:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4TFSyM6WexFKKgBpA) @tharmon https://github.com/hyperledger/indy-sdk/pull/110 - it's a PR with integration test for A2A in Rust. Pysovrin interoperability tests already are in master(indy-sdk and indy-anoncreds) and integrated to CI Basic infrastructure of Python wrapper is already in master

gudkov (Mon, 17 Jul 2017 07:38:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ZgRtWRfBX52p9SfHe) @srottem I will check. Do you have all 3d party dependencies in PATH?

srottem (Mon, 17 Jul 2017 08:12:23 GMT):
@gudkov They've been set as per the windows build instructions, which seemed to work a week or so back.

srottem (Mon, 17 Jul 2017 08:21:10 GMT):
@gudkov Ah - I see the problem: the SOVRIN_PREBUILT_DEPS_DIR environment var changed to INDY_PREBUILT_DEPS_DIR which I missed. The build appears to work fine now - sorry about that.

gudkov (Mon, 17 Jul 2017 08:21:48 GMT):
@srottem Most probable you need to provide INDY_PREBUILT_DEPS_DIR environment variable. It was changed from SOVRIN_PREBUILT_DEPS_DIR some time ago.

srottem (Mon, 17 Jul 2017 08:22:54 GMT):
@gudkov Thanks - I was away for more than a week and I missed the change. Thanks for pointing me in the right direction.

srottem (Mon, 17 Jul 2017 10:45:19 GMT):
I notice that the txn file generated by the Java unit tests refers to a test pool on 10.0.0.2. Is there a vagrant box or other specific environment that exposes a node pool on that IP by default? Or is setting up a node pool at this location the responsibility of each developer?

gudkov (Mon, 17 Jul 2017 12:11:42 GMT):
@srottem Yes, There is a docker file that allows execution of compatible pool

gudkov (Mon, 17 Jul 2017 12:13:04 GMT):
Check ci\indy-pool.dockerfile It also requires creation of corresponded network. For now the best way is check Jenkinsfile for details.

srottem (Mon, 17 Jul 2017 14:44:02 GMT):
@gudkov Thanks - will do.

MRJCrunch (Mon, 17 Jul 2017 15:23:45 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Continue working on python wrapper. Finished IS-177(Infrastructure), IS-16 (Wallet API), IS-15 (Signus API). In progress: IS-19(Pool API) and IS-17(Agent API). - Continue working on implementation tests for Java wrapper. Finished: IS-209 (Java Wrapper: Demo integration tests), IS-207 (Java Wrapper: Signus API integration tests (high cases)). IS-218 (Agent API: Agent demo test)

srottem (Mon, 17 Jul 2017 20:44:43 GMT):
I think I've managed to stand up the indy-pool container using docker-toolbox on my Windows host and I'm seeing that the nodes have entered a running state. Unfortunately the Java unit tests I'm running on the host Windows box don't seem to be communicating with the nodes. I'm assuming I've started the docker container correctly (I've used the commands from the Ubuntu build instructions) but I'm a newb at this. I'm also seeing an issue (maybe) when I run the base indy-sdk tests which appear to get stuck with the message "test services::agent::tests::agent_worker::agent_worker_try_start_listen_works has been running for over 60 seconds" - perhaps this is related?

srottem (Tue, 18 Jul 2017 07:30:35 GMT):
OK, after banging my head on docker for a while I've managed to get a set of nodes up and running using the indy-pool.dockerfile (albeit on the wrong IP address, so I've temporarily hacked the code that generates the txn file to refer to the one docker seems to insist on using) but now I'm getting an error when attempting to open the pool: <> Any hints?

gudkov (Tue, 18 Jul 2017 07:36:31 GMT):
@srottem I will try to run windows tests with Docker today and share instruction with you. Do you use latest master?

srottem (Tue, 18 Jul 2017 07:37:07 GMT):
@gudkov Yes.

srottem (Tue, 18 Jul 2017 07:37:07 GMT):
@gudkov Yes. And thanks again.

srottem (Tue, 18 Jul 2017 07:52:11 GMT):
@gudkov Oh, and it's worth noting that I don't have HyperV (thanks Microsoft!) so I'm running docker-toolbox.

gudkov (Tue, 18 Jul 2017 07:52:38 GMT):
We

gudkov (Tue, 18 Jul 2017 07:54:53 GMT):
I use HyperV, but most probable VirtualBox based solution should also work. On MacOS we have an issue with creation of network interfaces for Docker network. We have a plan to update docker container to just use different ports on 127.0.0.1 instead of different ips.

srottem (Tue, 18 Jul 2017 07:55:50 GMT):
@gudkov Yeah, I think docker-toolbox is using VirtualBox under the covers. All new territory for me.

gudkov (Tue, 18 Jul 2017 07:57:08 GMT):
Most propable your error can be related to network setup. Ip addresses of nodes should correspond exactly to your genesis txns and it must be true inside and outside of container.

srottem (Tue, 18 Jul 2017 08:00:42 GMT):
@gudkov That will be it then - Docker is bridging the indy_pool container on 192.168.99.100 so I hacked the txn file to use those IPs. I haven't been able to figure out how to get docker to use 10.0.0.2 (even though I am using the --ip 10.0.0.2 parameter on the docker run command). This might be something to do with my machine being on the 192.168.x.x network, but I'm out of my depth here.

farooq_m_khan (Tue, 18 Jul 2017 10:13:51 GMT):
I followed these steps: https://github.com/FarooqKhan/indy-sdk/blob/master/doc/mac-build.md

farooq_m_khan (Tue, 18 Jul 2017 10:14:09 GMT):
I get a error: note: library: m error: linking with `cc` failed: exit code: 1

farooq_m_khan (Tue, 18 Jul 2017 10:14:15 GMT):
Has this been tested recently

farooq_m_khan (Tue, 18 Jul 2017 10:45:05 GMT):
I can give you the full error report if you wish

farooq_m_khan (Tue, 18 Jul 2017 10:49:59 GMT):
Maybe no one has tested in for mac in a while

gudkov (Tue, 18 Jul 2017 11:07:16 GMT):
> Has this been tested recently Actually Mac Support is on the very initial stage. It is better to use linux for expermiments.

gudkov (Tue, 18 Jul 2017 11:09:14 GMT):
You can check this epic for the progress https://jira.hyperledger.org/browse/IS-60

gudkov (Tue, 18 Jul 2017 15:14:40 GMT):
@srottem I tried the following steps to execute pool: 1. Create docker network for pool docker network create --subnet=10.0.0.0/8 indy 2. Build pool images. Use --no-cache to avoid our intermediate faults docker build --no-cache -t indy_pool -f ./ci/indy-pool.dockerfile . 3. Run pool docker run --ip="10.0.0.2" --network=indy indy_pool 4. Execute tests

gudkov (Tue, 18 Jul 2017 15:16:14 GMT):
Pool started without any problems, but looks like we have an regression in rust's windows tests that works with pool TRACE|indy::services::pool | src\services\pool\mod.rs:571 | PoolService::create indy_send_request_works_for_invalid_pool_handle with config Some("{\"genesis_txn\": \"C:\\Users\\V6F76~1.GUD\\AppData\\Local\\Temp\\indy\\indy_send_request_works_for_invalid_pool_handle.txn\"}") ERROR|indy::errors::indy | src\errors\indy.rs:63 | Casting error to ErrorCode: Invalid structure: Invalid pool config format: JSON error thread 'high_cases::requests::indy_send_request_works_for_invalid_pool_handle' panicked at 'called `Result::unwrap()` on an `Err` value: CommonInvalidStructure', src\libcore\result.rs:859

gudkov (Tue, 18 Jul 2017 15:17:50 GMT):
I will try to fix this and after this try to execyte tests for java wrapper on windows

srottem (Tue, 18 Jul 2017 15:38:21 GMT):
@gudkov These look the same as the commands I executed, but I can't execute any of the Java tests that interact with the pool at all - there is no response from 10.0.0.2 so the tests hang. In order to access the host I have to communicate with 192.168.99.100 which appears to be the IP of the VirtualBox VM that docker-toolbox is using to host the container. Of course, if I change the txn file so that it communicates on this IP address I get the 'unacceptable merkel tree ' error. You mentioned you are running a host that has HyperV - perhaps that's the difference in our situations.

srottem (Tue, 18 Jul 2017 15:42:22 GMT):
@gudkov kind of frustrating as I've put together a .NET wrapper that matches the Java wrapper, including most of the unit tests, but I don't want to submit a pull request until I can execute the tests and verify they work.

farooq_m_khan (Tue, 18 Jul 2017 15:43:15 GMT):
okay thanks @gudkov

MRJCrunch (Tue, 18 Jul 2017 15:48:45 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Continue working on python wrapper. Finished: IS-19: Python Wrapper: Pool API In progress: IS-18: Python Wrapper: Ledger API IS-17: Python Wrapper: Agent API - Continue working on implementation tests for Java wrapper. Finished: IS-210 (Java Wrapper: Ledger API integration tests (high cases)) In progress: IS-224 (Java Wrapper: Anoncreds API integration tests (high cases)) - Found a problem in our tests on windows

gudkov (Tue, 18 Jul 2017 16:09:35 GMT):
@srottem > 192.168.99.100 which appears to be the IP of the VirtualBox VM that docker-toolbox is using to host the container. Of course, if I change the txn file so that it communicates on this IP address I get the 'unacceptable merkel tree ' error. You mentioned you are running a host that has HyperV - perhaps that's the difference in our situations. You can try the following: 1. Change generate_sovrin_pool_transactions command in docker file to use 127.0.01 ip address for nodes communication 2. Map public ports of nodes to your local 127.0.01 interface with docker run We have very similar issue for testing on Mac and iOS https://jira.hyperledger.org/browse/IS-221

gudkov (Tue, 18 Jul 2017 16:18:23 GMT):
@srottem As it bloks we will put this issue to current sprint backlog and try to fix this tomorrow.

srottem (Tue, 18 Jul 2017 16:19:11 GMT):
@gudkov Thanks mate - much appreciated. I'm in the process of building the new docker image and will report back on using 127.0.0.1 shortly.

srottem (Tue, 18 Jul 2017 18:38:53 GMT):
@gudkov I must still be missing something. I've made the change to the generate_sovrin_pool_transactions commands, rebuilt and updated the Java PoolUtils class in test to use the 127.0.0.1 address. I've used the docker run command with the -p switch for each of the ports but it still seems to want to run the VM on the 192.168.99.100 IP so I can't reach it on 127.0.0.1. Do I need to set up another network or use some other switch I've missed? Sorry for being a bit slow on this.

farooq_m_khan (Tue, 18 Jul 2017 19:37:27 GMT):
@gudkov https://jira.hyperledger.org/browse/IS-60 and the subtask https://jira.hyperledger.org/browse/IS-43 Build of libsovrin is marked Done

farooq_m_khan (Tue, 18 Jul 2017 19:37:27 GMT):
@gudkov Per https://jira.hyperledger.org/browse/IS-60 and the subtask https://jira.hyperledger.org/browse/IS-43 Build of libsovrin on Mac is marked Done

srottem (Tue, 18 Jul 2017 19:40:29 GMT):
@gudkov Success! Using the command 'netsh interface portproxy add v4tov4 listenaddress=127.0.0.1 listenport=9701 connectaddress=192.168.99.100' for all the ports 9701 to 9708 along with your instructions worked. Thanks!

gudkov (Wed, 19 Jul 2017 06:01:18 GMT):
@farooq_m_khan IS-43 closed as dupplicate. See https://jira.hyperledger.org/browse/IS-7 for actual status

farooq_m_khan (Wed, 19 Jul 2017 07:52:59 GMT):
@gudkov thanks

gudkov (Wed, 19 Jul 2017 07:56:56 GMT):
@farooq_m_khan actually if you can put your error logs we can try to help. Most probable the problem isn't too hard to solve.

farooq_m_khan (Wed, 19 Jul 2017 08:39:41 GMT):
okay i will upload the logs on the jira ticket

gudkov (Wed, 19 Jul 2017 11:14:00 GMT):
@farooq_m_khan Thanks, We move this tickets to In Progress

gudkov (Wed, 19 Jul 2017 11:14:00 GMT):
@farooq_m_khan Thanks, We moved this tickets to In Progress

farooq_m_khan (Wed, 19 Jul 2017 11:14:29 GMT):
Done i have put in all information i could if you need more let me know, I was able to compile it on Ubuntu successfully

MRJCrunch (Wed, 19 Jul 2017 15:26:42 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Continue working on python wrapper. Finished: IS-18: Python Wrapper: Ledger API IS-12: Python Wrapper: Ledger API integration tests (High cases) In progress: IS-17: Python Wrapper: Agent API Decided to switch from ovserver-like API to poll-like API that seems much more compatible with asyncio approach. Testing of agent_connect and agent_listen calls in this approach. - Investigate the build state on Mac platform. We have a linking problem on the latest step. Involved Kirill to this problem and moved corresponded tasks to current sprint - Continue working on implementation tests for Java wrapper. Finished: IS-224 (Java Wrapper: Anoncreds API integration tests (high cases)). IS-211 (Java Wrapper: Agent API integration tests (high cases)).

faisal00813 (Thu, 20 Jul 2017 06:42:19 GMT):
Has joined the channel.

Dpkkmr (Thu, 20 Jul 2017 11:54:33 GMT):
Has joined the channel.

MRJCrunch (Thu, 20 Jul 2017 16:29:12 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Continue working on python wrapper. In progress: IS-17: Python Wrapper: Agent API (Almost done) IS-11: Agent API integration tests IS-226: Python Wrapper: Anoncreds API - Continue working on implementation tests for Java wrapper. In progress: IS-212 Java Wrapper: CI Pipeline - Finished IS-61 Ubuntu Support: Packages - Checked MessagePack serialization in Rust (IS-227 - finished)

pwnintended (Fri, 21 Jul 2017 13:13:50 GMT):
Has joined the channel.

farooq_m_khan (Fri, 21 Jul 2017 14:41:50 GMT):
Thanks Indy-SDK builds on Mac now

farooq_m_khan (Fri, 21 Jul 2017 14:41:50 GMT):
Thanks for completing https://jira.hyperledger.org/browse/IS-7 Indy-SDK builds on Mac now

MRJCrunch (Fri, 21 Jul 2017 16:02:27 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Continue working on python wrapper. In progress: IS-226: Python Wrapper: Anoncreds API IS-11 (Agent API integration tests) Finished: IS-17 (Agent API) - Finished: IS-212 Java Wrapper: CI Pipeline IS-229 Delete zmq from documentation and docker files IS-171 MacOS Support: Port libzmq-pw to MacOS - Started IS-230 Java Wrapper: register_wallet_type integration tests (high cases) - Fixing indy-sdk tests on windows platform

MRJCrunch (Mon, 24 Jul 2017 20:17:59 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Continue working on python wrapper. In progress: IS-11 (Agent API integration tests) IS-14 Python Wrapper: Port demo tests (Implemented Ledger, Signus demo tests) Finished: IS-226: Python Wrapper: Anoncreds API - Working on implementation of integration tests for Java wrapper. Finished IS-230 Java Wrapper: register_wallet_type integration tests (high cases). - IS-232 Renamed libindy package name from indy-sdk to indy - Finished all API calls in Python Wrapper

srottem (Mon, 24 Jul 2017 20:26:37 GMT):
Quick question - is there a way to get the indy-sdk to log output to a file rather than console? Unfortunately when running unit tests using mstest the console logging generated by indy.dll gets swallowed and it's causing me some headaches in debugging.

gudkov (Tue, 25 Jul 2017 06:34:13 GMT):
For logging we use the following crate as facade https://doc.rust-lang.org/log/log/index.html

gudkov (Tue, 25 Jul 2017 06:36:09 GMT):
Initialization of logger is performed in C:\sovrin-client-rust\src\utils\logger.rs

gudkov (Tue, 25 Jul 2017 06:37:13 GMT):
For now It forces to use env_logger that only supports logging to std streams. We plan to provide API to register logger handler.

gudkov (Tue, 25 Jul 2017 06:38:04 GMT):
As temporary workaraund you can link with simplelog (https://github.com/drakulix/simplelog.rs) instead of env_logger

srottem (Tue, 25 Jul 2017 06:38:41 GMT):
Thanks!

gudkov (Tue, 25 Jul 2017 06:38:42 GMT):
and change LoggerUtils::init() method to use simplelog

gudkov (Tue, 25 Jul 2017 06:43:26 GMT):
The list of available logging implementations https://doc.rust-lang.org/log/log/index.html#available-logging-implementations

srottem (Tue, 25 Jul 2017 09:41:31 GMT):
I've started consistently getting the following error when trying to build the sdk: "error: failed to run custom build command for `milagro-crypto v0.1.13`". Has something changed?

srottem (Tue, 25 Jul 2017 09:47:08 GMT):
"process didn't exit successfully: `C:\Users\srott\Source\indy-sdk\target\debug\build\milagro-crypto-6adbb2324884ba7d\build-script-build` (exit code: 101)"

gudkov (Tue, 25 Jul 2017 09:48:20 GMT):
I can't remember changes. Will try to re-build from public master now.

gudkov (Tue, 25 Jul 2017 09:49:42 GMT):
I just started the task about platform windows support

gudkov (Tue, 25 Jul 2017 09:50:51 GMT):
Just got the same error

gudkov (Tue, 25 Jul 2017 09:51:57 GMT):
As workaraund you can set both SOVRIN_PREBUILT_DEPS_DIR and INDY_PREBUILT_DEPS_DIR env variables

srottem (Tue, 25 Jul 2017 11:08:18 GMT):
That got me going again - thanks!

MRJCrunch (Tue, 25 Jul 2017 16:21:40 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Continue working on python wrapper. In progress: IS-10 Python Wrapper: Wallet API integration tests (High cases) IS-233: Python Wrapper: Anoncreds API integration tests (High cases) - almost finished Finished: IS-11 (Agent API integration tests) IS-14 Python Wrapper: Port demo tests (Anoncreds and Agent). IS-190 Python Wrapper: CI pipeline - Working on windows support

jamesmonaghan (Wed, 26 Jul 2017 11:22:58 GMT):
Has joined the channel.

MRJCrunch (Wed, 26 Jul 2017 18:00:22 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Continue working on python wrapper. Finished IS-10 Python Wrapper: Wallet API integration tests (High cases) IS-9 Python Wrapper: Signus API integration tests (High cases) IS-233: Python Wrapper: Anoncreds API integration tests (High cases) IS-13: Python Wrapper: Pool API integration tests (High cases) - fixed tests for ledger in Python Wrapper - code refactoring - Windows support: - Review windows related issues - Refactoring of pool container and code to support all supported environments. Trying to workaround docker limitations on Windows and Mac (in progress) - Solving path escaping projects in tests on Windows (in progress)

srottem (Thu, 27 Jul 2017 09:27:10 GMT):
Question: I've just seen that a 'forceCreate' parameter was added to the Java Wallet.registerWalletType() method. What is the purpose of this? It looks like the list of registered names is being tracked and it's preventing a new type being registered for an old name if false, but I'm unclear as to why that'd desirable.

srottem (Thu, 27 Jul 2017 09:31:58 GMT):
Another question: In the Java wrapper the callbacks to get values from a custom wallet type copy the strings from the managed JVM environment to unmanaged memory so the underlying SDK can access them and the SDK subsequently calls the free() callback in order to get the type to release the unmanaged resources. I'm concerned since the managed environment doesn't track the allocated resources there is a risk that under some circumstances, if the free() callback is not called (e.g. if the type was disposed by the managed environment before the callback) then some unmanaged resources may never be freed. Not being an expert in the area I'm looking for some feedback on whether or not this could truly be a issue.

gudkov (Thu, 27 Jul 2017 09:54:51 GMT):
> I've just seen that a 'forceCreate' parameter was added to the Java Wallet.registerWalletType() It seems like error. Originally forceCreate parameter was only in test utils for Rust code. Just to allow check the case of registering wallet type twice. I will check with the team. Most probable we need to remove this param.

gudkov (Thu, 27 Jul 2017 09:57:41 GMT):
> Not being an expert in the area I'm looking for some feedback on whether or not this could truly be a issue. I suggest to create issue in Jira and assign this issue to me. I will check this in the near future.

srottem (Thu, 27 Jul 2017 10:03:38 GMT):
@gudkov I suspect whatever the outcome in Java will more or less apply to .NET. I've implemented slightly differently in .NET to hide pointers from wallet type implementers and to track unmanaged resources to ensure they are released when the wallet instance is disposed. I'll open the ticket now.

nage (Thu, 27 Jul 2017 14:38:03 GMT):
@MRJCrunch, @gudkov, @srottem and @peacekeeper If anyone has updates on indy-sdk and the changes that have happened in the last two weeks along with any changes planned for the next two weeks, we'd love to get updates from you in the Agent WG call (that starts in ~20 minutes)

srottem (Thu, 27 Jul 2017 15:11:03 GMT):
I can comment on the .NET wrapper and maybe provide some info on the Java wrapper in the absence of @peacekeeper.

nage (Thu, 27 Jul 2017 15:11:25 GMT):
awesome ^^^

nage (Thu, 27 Jul 2017 15:11:33 GMT):
I'll turn it over to you next, if that is all right

srottem (Thu, 27 Jul 2017 15:11:42 GMT):
Sure.

srottem (Thu, 27 Jul 2017 15:26:58 GMT):
I'm trying to run the equivalent of the TestsProverGetClaimOffersWorksForFilterByIssuer test using an in-memory wallet in .NET but I'm getting a failure after making the indy_prover_get_claim_offers call. It appears that this function calls the wallet's list callback with the key prefix "claim_offer_json::" but then fails with CommonInvalidStructure(113) after the wallet returns the JSON result. I'm not sure why this is failing as there's not enough detail in the logging so I haven't been able to successfully troubleshoot this. Can anyone provide some guidance?

Terminalman90 (Thu, 27 Jul 2017 15:51:39 GMT):
Has joined the channel.

MRJCrunch (Thu, 27 Jul 2017 16:29:11 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Working on revocation part of Anoncreds In progress IS-108: Anoncreds API: Type-3 pairing based revocation - Continue working on python wrapper. Finished IS-8 Python Wrapper: Packages - Windows support: In progress Refactoring of pool container and code to support all supported environments

srottem (Fri, 28 Jul 2017 08:35:06 GMT):
The get, get_not_expired and list callbacks of the indy_register_wallet_type function appear to be called by the base wallet infrastructure when various other functions that interact with the wallet need to obtain values from the wallet. The return type appears to be *mut *const c_char in the rust code but what string encoding are the functions relying on the wallet expecting?

srottem (Fri, 28 Jul 2017 08:35:06 GMT):
The get, get_not_expired and list callbacks of the indy_register_wallet_type function appear to be called by the base wallet infrastructure when various other functions that interact with the wallet need to obtain values from the wallet. The return type appears to be '*mut *const c_char' in the rust code but what string encoding are the functions relying on the wallet expecting?

MRJCrunch (Fri, 28 Jul 2017 15:28:12 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Working on revocation part of Anoncreds In progress IS-108: Anoncreds API: Type-3 pairing based revocation - IS-243 Invalid error code and a bad message is used for case if pool configuration already exists - finished

ibasart (Fri, 28 Jul 2017 21:38:59 GMT):
Has joined the channel.

jonathanendersby (Mon, 31 Jul 2017 11:34:48 GMT):
Has joined the channel.

sergey.minaev (Mon, 31 Jul 2017 16:13:22 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Working on revocation part of Anoncreds IS-108: Anoncreds API: Type-3 pairing based revocation - Jenkins pipelines IS-249: Integrate all pipelines to CI - IS-248: Support pool node v1.0.68 - Debugging of tests on Windows. Most of problems were fixed except periodical InvalidState error during high load to pool.

srottem (Tue, 01 Aug 2017 07:04:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=FarNzenZCvsqWeF8J) @srottem bump

sergey.minaev (Tue, 01 Aug 2017 10:26:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=voEFqAYSKck5BEwM2) @srottem all string in IndySDK should be UTF-8 encoded now

srottem (Tue, 01 Aug 2017 10:44:24 GMT):
Thanks Sergey!

gudkov (Tue, 01 Aug 2017 11:44:26 GMT):
@srottem I created https://jira.hyperledger.org/browse/IS-251 that can be interrested for you

srottem (Tue, 01 Aug 2017 11:47:27 GMT):
Thanks [ ](https://chat.hyperledger.org/channel/indy-sdk?msg=n3syPes3B9NrnshgS) @gudkov Thanks - I'll look into it.

sergey.minaev (Tue, 01 Aug 2017 16:42:07 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Jenkins pipelines IS-249: Integrate all pipelines to one common pipeline - IS-176: Updated iOS Pod, found a bug with PrettyPrinted flag in iOS. If set, formatted json with spaces and tabs will be configured, which is not handled by Rust correctly. - Code review of .Net wrapper (it was merged) - Debugging of libindy tests on windows platform. All tests passed. Documentation update is still required - IS-237 and IS-238: Working on Windows build, update build environment variables usage

Captain63Dragon (Wed, 02 Aug 2017 03:41:47 GMT):
Has joined the channel.

jonathanendersby (Wed, 02 Aug 2017 10:08:56 GMT):
Does Indy have any support for storing keys and key operations on an HSM?

rujaun (Wed, 02 Aug 2017 10:15:45 GMT):
Has joined the channel.

sergey.minaev (Wed, 02 Aug 2017 10:27:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=hH62c8yAjDk7cZRNP) @jonathanendersby indy-sdk has ability to register custom wallet realization. So, it can be implemented to use HSM. You can ask @gudkov for more info.

jonathanendersby (Wed, 02 Aug 2017 10:27:55 GMT):
@sergey.minaev Thanks, @gudkov would love a URL for some reading material around how you implement HSMs.

gudkov (Wed, 02 Aug 2017 10:31:07 GMT):
We don't have any implementation of HSM now, but libindy provides a call indy_register_wallet_type that allow registering user defined handler for all wallet operations like opening, reading and writing keys. So you can define these handlers that will work with specific HSM in your case.

jonathanendersby (Wed, 02 Aug 2017 10:31:39 GMT):
:+1:

skibz (Wed, 02 Aug 2017 10:32:33 GMT):
Has joined the channel.

JohnCallahan (Wed, 02 Aug 2017 10:37:05 GMT):
Has joined the channel.

sergey.minaev (Wed, 02 Aug 2017 14:13:50 GMT):
Windows build process has been updated (https://github.com/hyperledger/indy-sdk/pull/154/files)

gudkov (Wed, 02 Aug 2017 15:37:26 GMT):
Also we just merged big PR that moves libindy related code to libindy folder. It can require some changes in IDE setup.

srottem (Wed, 02 Aug 2017 16:14:10 GMT):
Thanks guys - I'll check it out tomorrow.

peacekeeper (Thu, 03 Aug 2017 08:01:00 GMT):
can someone resolve/close this issue: https://jira.hyperledger.org/browse/INDY-184, maybe @danielhardman

gudkov (Thu, 03 Aug 2017 08:17:16 GMT):
It has "done" status. Not sure that "resolution" field is important here.

sergey.minaev (Thu, 03 Aug 2017 08:18:23 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done Wednesday: - Refactoring of python wrapper tests to be compatible with windows (done) - Debugging of python wrapper tests on windows. It is possible to execute all tests one by one, but high load to pool causes random freezes. - Finished IS-249: Integrate all pipelines to one common pipeline - IS-125: Pool API: Integration tests (Medium cases) - Working on revocation part of Anoncreds: IS-108: Anoncreds API: Type-3 pairing based revocation - Finished IS-237 and IS-238: Working on Windows build, update build environment variables usage - Start working on IS-144: Technical debt: Refactoring of libindy tests to perform correct full cleanup

marek.dapps (Thu, 03 Aug 2017 08:43:39 GMT):
Has joined the channel.

srottem (Thu, 03 Aug 2017 08:50:24 GMT):
Question: How is the return value from the list callback on a custom registered wallet supposed to be structured? I'm running a test with a custom wallet that mirrors the testProverGetClaimsWorksForFilterByIssuer() test but I'm unable to get the call to proverGetClaims() to work correctly with the custom wallet - it always fails with "Invalid structure: JSON error". I can see that the call to the custom wallet's list callback is being made with the key prefix "claims::" and my custom wallet is constructing a JSON array with the single claim that's returned (e.g. '[{"claim":...}] - is there some additional encoding that should be taking place? including the single value in the array as a JSON encoded string and that also fails. Can someone provide a sample of what the valid JSON should look like?

srottem (Thu, 03 Aug 2017 08:50:24 GMT):
Question: How is the return value from the list callback on a custom registered wallet supposed to be structured? I'm running a test with a custom wallet that mirrors the testProverGetClaimsWorksForFilterByIssuer() test but I'm unable to get the call to proverGetClaims() to work correctly with the custom wallet - it always fails with "Invalid structure: JSON error". I can see that the call to the custom wallet's list callback is being made with the key prefix "claims::" and my custom wallet is constructing a JSON array with the single claim that's returned (e.g. '[{"claim":...}] - is there some additional encoding that should be taking place? Including the single value in the array as a JSON encoded string also fails. Can someone provide a sample of what the valid JSON should look like?

sergey.minaev (Thu, 03 Aug 2017 08:52:01 GMT):
^^^ @gudkov

gudkov (Thu, 03 Aug 2017 10:40:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wBYJ8Q2EwD7JEdHuT) @srottem an example of json: [{"key": "key1", "value": "value1"}, {"key": "key2", "value": "value2"}] most probably we need to enhance our documentation

Terminalman90 (Thu, 03 Aug 2017 15:17:30 GMT):
I'm missing something obvious here; in the Getting Started for Ubuntu the section Run Tests has what looks like a command `RUST_TEST_THREADS=1 cargo test` I don't think it is a command line, but if not, what do I do with it?

sergey.minaev (Thu, 03 Aug 2017 21:20:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=F99nbPfiHxpc7dqNQ) @Terminalman90 it's command line with defined env variable for this command

sergey.minaev (Thu, 03 Aug 2017 21:21:39 GMT):
As alternative you can set (or may be export) this env variable and after that just run `cargo test`

sergey.minaev (Thu, 03 Aug 2017 21:35:45 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Updated python tests to be compatible with windows. Main problem was related to problem with libindy freezes we found on windows. - Investigate random freezes while integration testing. Found most probably reason and create test + fix. - Completed Pool APi Medium cases integration tests. - Updated build scripts for python wrapper - Writing Agent APi Medium cases integration tests (listen, connect)" - Updated iOS pods, updated merge request, updated cocoapods setup after big merge - Continue working on revocation part of Anoncreds

srottem (Fri, 04 Aug 2017 10:01:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RLGLAqXX7kMGNsEyz) @gudkov Hm. When running the test I mentioned earlier the list() callback on the custom wallet responds with the JSON below, but it's rejected as invalid. This doesn't happen in the default wallet. '[{"claim":{"age":["28","28"],"height":["175","175"],"name":["Alex","1139481716457488690172217916278103335"],"sex":["male","5944657099558967239210949258394887428692050081607692519917050011144233115103"]},"revoc_reg_seq_no":null,"schema_seq_no":1,"signature":{"primary_claim":{"m2":"52860447312636183767369476481903349046618423276302392993759146262753859184069","a":"29395086646470547811993887048799213709178630710326966372898126767337959119844586453609504010801664726687901728982228612330849428694548583832035954147323865496169000153996482190020150828150852742196010775755682045820656674879684203910214948253472820704000357524051062450492539169677505929268851065868140465765997593562616235118298752881030967364772386565303084489642045285899928470156159697070644845143245406211195358095736151183048138849422349528312005636015649490614067377197505891615460641506494595591052670962427146202405800508701778409860786033999238667891033533384445806556632118555146718323455126481430886109181","e":"259344723055062059907025491480697571938277889515152306249728583105665800713306759149981690559193987143012367913206299323899696942213235956742930181926374361907796036212673285786663","v":"6279202366720246011320300238036134252117330829074094631414842748458255822427056847177741676847684860432542437204641219677512435329115910392881511961513572086058749767175222264122609168397623678555170758547756396240129966282727672616628073664904194063209190799728012669248699511069232912459718633995536188008085086270871943925016066062578438672013383264616291427059050661389049487695541257189524737437669354598865059489399895254210202855542373172480994878680598905357628806512114521588682799687995957668526387686482131537156681864872129320418009470354118041107266811404414286111049270947362381017184919824320448691627038084368392680344549933878747471266105683025441651842870969822395482306708042704319926885184386306944999883931968122405717217824525427275540364954015720532404696588963523282639533230332021843822174989231"},"non_revocation_claim":null},"issuer_did":"NcYxiDXkpYi6ov5FcYDi1e"}]'

gudkov (Fri, 04 Aug 2017 15:36:36 GMT):
This string seems to be valid json, but may be it doesn't follow anoncreds scheme? May be just compare strings that returns custom and default wallet?

srottem (Fri, 04 Aug 2017 15:37:41 GMT):
Good thought.

mgbailey (Fri, 04 Aug 2017 17:23:35 GMT):
Has joined the channel.

sergey.minaev (Fri, 04 Aug 2017 21:56:34 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Investigation problems with publishing deb/rpm artifacts, create hotfix - Simplification of python tests by massive usage of fixtures. PoC has been created and most critical part of tests has been ported to this approach. - Updating java wrapper tests to be compatible with Windows (in progress)

Captain63Dragon (Sat, 05 Aug 2017 14:05:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JWQBg3jvbPefmPPrC) @sergey.minaev Thanks. Got that sorted out. What JDK on Ubuntu should I be using? I couldn't find that info anywhere. The default-jdk didn't seem to work.

sergey.minaev (Mon, 07 Aug 2017 10:23:31 GMT):
@Captain63Dragon > What JDK on Ubuntu should I be using? AFAIK openjdk-8-jdk is used in our CI. @peacekeeper could you confirm and may be update java.md?

srottem (Mon, 07 Aug 2017 11:08:03 GMT):
Question regarding closing connections opened on a listener: a comment in agent_close_listener() in the Python wrapper says "Note that all opened incomming connections will be closed automatically." Does the Rust code handle this? Or does closing the listener leave the connections available for the developer to close when they're ready?

gudkov (Mon, 07 Aug 2017 13:22:51 GMT):
It just means that closing of listener handle forces auto closing of handles for all incoming connections on this listener.

gudkov (Mon, 07 Aug 2017 13:25:31 GMT):
Trying to close an incoming connection after listener was closed will cause invalid handle exception. This behavior is implemented on libindy level. So all wrappers should also share this behavior.

srottem (Mon, 07 Aug 2017 13:25:50 GMT):
Excellent.

peacekeeper (Tue, 08 Aug 2017 03:56:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WxEhjHsKYHZvFB5qq) @sergey.minaev Yes currently Java 8 is required, because of the use of the CompletableFuture class, there is a Jira issue for investigating earlier Java support: https://jira.hyperledger.org/browse/IS-217

mgbailey (Tue, 08 Aug 2017 13:57:43 GMT):
I need a python script that 1) retrieves the verkeys of the nodes in the validator pool, and 2) posts a transaction in the config ledger to upgrade the software version on the pool. Is this possible with the sdk? Are there example scripts around that I can learn basics from?

lohan.spies (Tue, 08 Aug 2017 15:47:56 GMT):
Has joined the channel.

sergey.minaev (Wed, 09 Aug 2017 06:08:24 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done Tuesday: - Finished IS-259: Windows: Update java tests to be compatible Finsihed IS-260: Python Wrapper: Better tests organization of tests with fixtures - Debugging: IS-263: Java Wrapper: Integration tests freeze periodically - Finished IS-69 - Agent API: Integration testing (Medium cases) - Added medium tests for AgentApi

gudkov (Wed, 09 Aug 2017 06:48:11 GMT):
@mgbailey > 1) retrieves the verkeys of the nodes in the validator pool As I know there is no dedicated GET_NODE operation support on indy node level. Nodes keys exchange is performed only when a client connects to nodes and creates merkle tree. Could you describe your use case for this? We can analyze this and consider to implement these operations in node and sdk. Ideally if you can create the ticket on our Jira with this feature request. > 2) posts a transaction in the config ledger to upgrade the software version on the pool. There is no builder helper for Upgrade transaction in indy sdk now, but it should be possible to create json message for this transaction manually and send it with indy_sign_and_submit_request call. We don't have an exact example of this transaction sending, but you can check how to send transactions to ledger with python here: https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/tests/demo/test_ledger.py

gudkov (Wed, 09 Aug 2017 06:49:36 GMT):
I will a create a ticket about support of Upgrade transaction message builder helper method in indy sdk.

gudkov (Wed, 09 Aug 2017 07:38:21 GMT):
@mgbailey I created a ticket about retrieving of node data with indy sdk. Could you describe your use case for retrieves the verkeys of the nodes in the validator pool in this ticket?

lohan.spies (Wed, 09 Aug 2017 08:09:45 GMT):
Do anyone know what the ETA would be for the nodejs wrapper?

gudkov (Wed, 09 Aug 2017 09:21:19 GMT):
@mgbailey Please take a look at tickets https://jira.hyperledger.org/browse/IS-270 (Ledger API: Upgrade transaction support) and https://jira.hyperledger.org/browse/IS-269 (Ledger API: GET_NODE (or similar) transaction support) .

gudkov (Wed, 09 Aug 2017 09:27:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3jGprLnfBuZ5BtjAF) @lohan.spies I am not sure that we clarified our plans about the support of NodeJS wrapper for the moment. I created corresponded issue: https://jira.hyperledger.org/browse/IS-272 (NodeJS Wrapper: Define roadmap and ETA). Could you start conversation in this issue? It would be nice if you can describe your use case.

srottem (Wed, 09 Aug 2017 11:06:24 GMT):
The Anoncreds demo test TestVerifyProofWorksForProofDoesNotCorrespondToProofRequest is failing in step 9 when calling prover_create_proof with :Invalid structure: Predicate not found". This satisfies the exception expectation for the test but doesn't look like it's actually the the point where the exception should be thrown from as there's a whole lot of code after that comprising step 10. Is this actually where the test is intended to throw?

srottem (Wed, 09 Aug 2017 11:06:24 GMT):
The Anoncreds demo Java test TestVerifyProofWorksForProofDoesNotCorrespondToProofRequest is failing in step 9 when calling prover_create_proof with :Invalid structure: Predicate not found". This satisfies the exception expectation for the test but doesn't look like it's actually the the point where the exception should be thrown from as there's a whole lot of code after that comprising step 10. Is this actually where the test is intended to throw?

srottem (Wed, 09 Aug 2017 11:06:24 GMT):
The Anoncreds demo Java test TestVerifyProofWorksForProofDoesNotCorrespondToProofRequest is failing in step 9 when calling prover_create_proof with "Invalid structure: Predicate not found". This satisfies the exception expectation for the test but doesn't look like it's actually the the point where the exception should be thrown from as there's a whole lot of code after that comprising step 10. Is this actually where the test is intended to throw?

Artemkaaas (Wed, 09 Aug 2017 12:27:47 GMT):
You are right. There is mistake in testVerifyProofWorksForProofDoesNotCorrespondToProofRequest tests (invalid requestedClaimsJson and proofRequestJson further). Actually exception must be thrown on verifierVerifyProof step. Thanks for your comment.

srottem (Wed, 09 Aug 2017 13:22:13 GMT):
Thanks. I noticed the issue when I was porting the test to .NET - I'll keep an eye out for the Java fix and will update the dotnet wrapper accordingly.

mgbailey (Wed, 09 Aug 2017 15:45:00 GMT):
@gudkov Thanks for the tickets. I will update them with the use case information.

sergey.minaev (Wed, 09 Aug 2017 22:26:13 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Created tickets for feature requests from community - Documenting of CI pipeline (in progress) and design pipeline enhancements and releasing automation - Start working on Windows CI: investigate solution for running nodes pool - Finish IS-263 Java Wrapper: Integration tests freeze periodically - Refactoring for sovrin_sign and sovrin_verify_signature calls (should support arbitrary byte array)

gudkov (Thu, 10 Aug 2017 11:53:07 GMT):
MM from our Java/.Net wrappers related meeting * We started working on windows support in our CI. It will allow creating CI pipeline for .Net wrapper. @srottem will try to handle this * There is a pool request that solves "IS-158: indy_sign and indy_verify_signature should support arbitrary byte array" (PR 172). It changes API and requires support in wrappers. We performed this changes in python and java wrapper, but require @srottem support for .Net wrapper. * We started working on DID-TLS support in Agent API. Most probable it will require some changes in wrappers soon. * Marcus created a PR with better cross-platform way for libindy lookup. It was merged. * There are PRs about modified WalletType to abstract marshalling of values to unmanaged memory away from implementers. We agreed to review and merge this (https://github.com/hyperledger/indy-sdk/pull/173) first, which should make custom wallets working. And then @srottem + @peacekeeper and others can further discuss higher-level functionality for custom wallets (https://github.com/hyperledger/indy-sdk/pull/160) * There were fixes for Anoncreds tests. Thanks to @srottem.

nage (Thu, 10 Aug 2017 14:59:20 GMT):
@gudkov will you be on the Agent call to discuss what changes and improvements have been happing in the SDK?

sergey.minaev (Thu, 10 Aug 2017 16:27:58 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Documenting of CI pipeline (in progress) and design pipeline enhancements and releasing automation - Finished IS-63 Windows Support: CI pipeline - Finished IS-158 sovrin_sign and sovrin_verify_signature should support arbitrary byte array - Finished for Rust IS-164 Signus API: Integration tests for encrypt/decrypt (High cases) - Finished for Rust IS-165 Signus API: Integration tests for encrypt/decrypt (Medium cases)

Suedonym (Thu, 10 Aug 2017 17:55:06 GMT):
Has joined the channel.

srottem (Fri, 11 Aug 2017 08:25:38 GMT):
PR for sign and verify changes ported to .NET: https://github.com/hyperledger/indy-sdk/pull/180

sergey.minaev (Fri, 11 Aug 2017 16:06:44 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today: - Answer community questions on GitHub - Documenting of CI pipeline (in progress) and design pipeline enhancements and releasing automation - Investigate reason of broken compilation of libindy on CI, implement approach to fix dependencies versions - Start work for creating artifacts on windows - Finished Java/Python IS-164 Signus API: Integration tests for encrypt/decrypt (High cases) - Working on IS-158 sovrin_sign and sovrin_verify_signature should support arbitrary byte array

DibbsZA (Sun, 13 Aug 2017 07:30:51 GMT):
Has joined the channel.

sergey.minaev (Tue, 15 Aug 2017 10:59:37 GMT):
indy-sdk CI now publishes the latest windows artifact (zip archive with all required dll and headers) to https://repo.evernym.com/deb/windows-bins/indy-sdk/ Actual version at the message moment is https://repo.evernym.com/deb/windows-bins/indy-sdk/0.1.1-118/indy-sdk_0.1.1.zip

mgbailey (Tue, 15 Aug 2017 14:03:13 GMT):
I am working on an app using the python wrapper. Whenever I try to run, I get a parsing error on line 118 in error.py. Was this inadvertently added?

gudkov (Tue, 15 Aug 2017 14:55:01 GMT):
@mgbailey for current moment wrapper requires latest stable python version (3.6).

mgbailey (Tue, 15 Aug 2017 15:04:51 GMT):
thank you @gudkov , that cleared it up.

mgbailey (Tue, 15 Aug 2017 15:19:55 GMT):
Have we tested using indy-sdk with a pool of validators that includes validators that are not in the genesis file? When I do this, I get an error.

gudkov (Tue, 15 Aug 2017 15:27:36 GMT):
In tests/pool.rs there are open_pool_ledger_works_for_two_nodes and open_pool_ledger_works_for_three_nodes that checks connection to 4 nodes pool with 2 and 3 genesis transactions in file.

mgbailey (Tue, 15 Aug 2017 15:29:04 GMT):
hm.

mgbailey (Tue, 15 Aug 2017 15:31:59 GMT):
I have a 4-node pool with all 4 nodes in the genesis file. This works fine. Then I add a fifth node by adding a steward and node dato to the ledger. If I then try to run an indy-sdk app, it crashes. It looks like it is trying to sync to the ledger, and fails.

mgbailey (Tue, 15 Aug 2017 15:32:25 GMT):
I think I will file a ticket with details.

mgbailey (Tue, 15 Aug 2017 15:35:47 GMT):
IS-287

swcurran (Tue, 15 Aug 2017 22:23:23 GMT):
Has joined the channel.

sergey.minaev (Tue, 15 Aug 2017 23:10:54 GMT):
@mgbailey could you re-run your case with 'RUST_BACKTRACE=1' environment variable, please (and update the ticket description)? Also we will try to reproduce the issue (we have an ignored integration test for same scenario), but may be some significant differences between our and your cases.

sergey.minaev (Tue, 15 Aug 2017 23:15:43 GMT):
Here’s what our team that’s working on the c-callable indy-sdk got done today and yesterday: - Implementing publishing windows artifacts from CI - Update signus API: sign/verify now works with byte arrays. Old functionality (sign JSON message with specific serialization) is implemented as additional call - Start working on MessagePack serialization in indy-sdk to be compatible with the latest indy-node pool

mgbailey (Wed, 16 Aug 2017 16:16:40 GMT):
@sergey.minaev , I added the backtrace as a comment on the ticket.

sergey.minaev (Wed, 16 Aug 2017 22:52:34 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done today:

sergey.minaev (Wed, 16 Aug 2017 22:52:34 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done today: IS-220 Working on messagepack serialization in indy-sdk IS-158 sovrin_sign and sovrin_verify_signature should support arbitrary byte array - Finished for Python and Java Started working on IS-108

srottem (Thu, 17 Aug 2017 12:02:41 GMT):
I've just built the master branch of the SDK and a series of ledger tests are failing in the .NET and Java wrappers. It looks like the JSON being generated from calls such as indy_build_claim_def_txn have changed (e.g. for this particular call the value of the "data" node was returned as a string, however now it's not). Were these changes intentional?

srottem (Thu, 17 Aug 2017 12:11:04 GMT):
It also looks like calls to the same method now include a "revocation" node in the claim def request which wasn't there before.

gudkov (Thu, 17 Aug 2017 12:36:15 GMT):
@srottem See https://github.com/hyperledger/indy-sdk/pull/187 It contains compatibility fixes for latest Node. Most probable .Net wrapper must be updated too.

srottem (Thu, 17 Aug 2017 13:37:38 GMT):
OK, fixed for .NET. Java will need these changes too.

sergey.minaev (Thu, 17 Aug 2017 15:29:11 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done today: IS-291 Resolve cross dependencies in CI for wrappers and libnidy IS-182 Update A2A UML: describe add_identity step IS-108 Anoncreds API: Type-3 pairing based revocation Sprint finishing/planing the new one

sergey.minaev (Thu, 17 Aug 2017 15:38:49 GMT):
Actually there are some links to currently published binaries of indy-sdk: https://repo.evernym.com/deb/indy-sdk/ - deb packages of indy-sdk https://repo.evernym.com/deb/windows-bins/indy-sdk/ - windows archives of indy-sdk https://repo.evernym.com/deb/windows-bins/indy-sdk-deps/ - windows dependencies for building indy-sdk from sources https://repo.evernym.com/deb/python-indy-sdk/ - python wrapper debs

sergey.minaev (Thu, 17 Aug 2017 15:38:49 GMT):
Actually there are some links below to currently published binaries of indy-sdk: https://repo.evernym.com/deb/indy-sdk/ - deb packages of indy-sdk https://repo.evernym.com/deb/windows-bins/indy-sdk/ - windows archives of indy-sdk https://repo.evernym.com/deb/windows-bins/indy-sdk-deps/ - windows dependencies for building indy-sdk from sources https://repo.evernym.com/deb/python-indy-sdk/ - python wrapper debs

dsurnin (Thu, 17 Aug 2017 15:53:42 GMT):
Has joined the channel.

mgbailey (Thu, 17 Aug 2017 16:00:41 GMT):
@sergey.minaev are their RPMs for RHEL/Centos?

mgbailey (Thu, 17 Aug 2017 16:23:32 GMT):
They are at https://repo.evernym.com/rpm/indy-sdk/

peacekeeper (Thu, 17 Aug 2017 16:44:56 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=7Foz73C3eCfeyB4MG) @srottem here's a PR with same test fixes for Java: https://github.com/hyperledger/indy-sdk/pull/196

RBowron (Fri, 18 Aug 2017 00:21:21 GMT):
Has joined the channel.

MaheshBiradar (Sat, 19 Aug 2017 09:30:12 GMT):
Has joined the channel.

sergey.minaev (Sat, 19 Aug 2017 11:07:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wMCGsMPPbnnvG8r9A) @mgbailey yes (the main target is amazonlinux).

sergey.minaev (Sat, 19 Aug 2017 11:08:17 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done today and yesterday: - Sprint Planning - Designing releases approach, documenting pipelines structure - Refactoring artifacts structure on repo.evernym.com - Finished Anoncreds API: Type-3 pairing based revocation

sergey.minaev (Sat, 19 Aug 2017 11:08:17 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done today and yesterday: - Sprint Planning - Designing releases approach, documenting pipelines structure - Refactoring artifacts structure on repo.evernym.com/libindy - Finished Anoncreds API: Type-3 pairing based revocation

MaheshBiradar (Sat, 19 Aug 2017 11:56:40 GMT):
Is there any way I can use the Indy identities in ethereum solidity smart contracts?

jljordan_bcgov (Mon, 21 Aug 2017 16:09:44 GMT):
Has joined the channel.

sergey.minaev (Mon, 21 Aug 2017 22:10:23 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done today:

sergey.minaev (Mon, 21 Aug 2017 22:10:23 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done today: IS-287 Investigate reason of the bug, debug and create hotfix IS-296 Discuss design, start work on testing wrappers at just built libindy IS-213 Java Wrapper: Packages - research, created template IS-244 Inconsistent Param Name for indy_open_pool_ledger() api

gudkov (Tue, 22 Aug 2017 08:26:21 GMT):
@srottem There is the change that renames all json params fields to snake case. Most probable it will break .Net wrapper tests. Could you integrate this change to .Net wrapper? See https://github.com/hyperledger/indy-sdk/pull/206/files

srottem (Tue, 22 Aug 2017 08:40:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=M7wpfLSPehTfNPG5L) @gudkov Done. See PR https://github.com/hyperledger/indy-sdk/pull/210

maheshkr81 (Tue, 22 Aug 2017 09:48:25 GMT):
Has joined the channel.

sklump (Tue, 22 Aug 2017 11:37:25 GMT):
Has joined the channel.

mark.hadley (Tue, 22 Aug 2017 20:57:26 GMT):
Has joined the channel.

sergey.minaev (Tue, 22 Aug 2017 21:43:58 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done today: Proposed pipleline structure was documented IS-296 Working on pipeline for wrappers. IS-288,IS-289 - Supported TRUST_ANCHOR role IS-108 Code refactoring IS-290 Research fpm for build rmp and deb

skibz (Wed, 23 Aug 2017 10:09:27 GMT):
hi all just want to say with regards to https://jira.hyperledger.org/browse/IS-272 i've begun working on a nodejs wrapper you can find it at github.com/io-digital/indy-sdk/tree/wrapper-for-node/wrappers/node

skibz (Wed, 23 Aug 2017 10:09:27 GMT):
hi all with regards to https://jira.hyperledger.org/browse/IS-272 i've begun working on a nodejs wrapper you can find it at github.com/io-digital/indy-sdk/tree/wrapper-for-node/wrappers/node

skibz (Wed, 23 Aug 2017 10:10:30 GMT):
i'm not sure how you all would feel about having my work merged upstream - it's still quite early and requires more test coverage, but open to discussing! :D

gudkov (Wed, 23 Aug 2017 11:16:25 GMT):
@skibz As I understand you plan to create node module? Did you consider node-ffi usage also?

skibz (Wed, 23 Aug 2017 11:25:01 GMT):
hi! i didn't know about node-ffi :) i'll see how far i can get with it

sergey.minaev (Wed, 23 Aug 2017 14:08:45 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done today: - IS-139 Designing releases approach - IS-268 Review DID-TLS spec - IS-296 Finish work for testing wrappers on the latest SDK (IS-300, IS-299), start work on publishing artifacts to different streams - IS-290 Jenkins fails to cleanup Indy SDK pipeline - research - IS-308 Finished Clean-up wrappers after removing revocRegSeqNo from API

OlufAndrews (Wed, 23 Aug 2017 14:25:41 GMT):
Has joined the channel.

AxelNennker (Wed, 23 Aug 2017 14:48:35 GMT):
Has joined the channel.

AxelNennker (Wed, 23 Aug 2017 14:50:56 GMT):
'RUST_TEST_THREADS=1 RUST_BACKTRACE=1 cargo test --test agent indy_agent_connect_works_for_expired_key_in_ledger' fails for me with a timeout. I installed indy-sdk on Ubuntu14.04 and followed https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md Any ideas what is wrong?

AxelNennker (Wed, 23 Aug 2017 14:59:47 GMT):

Message Attachments

sklump (Wed, 23 Aug 2017 15:42:34 GMT):
So I set up the python wrapper to run through a debugger (Eclipse/PyDev), in an attempt to investigate why I got 190ish "RuntimeWarning: coroutine '...' was never awaited" warnings. Sure enough, as I verified in the debugger, none of the async def routines in tests/*/*.py actually run via pytest. That's not so good, because that's all of them. I am concerned that I am not getting any test coverage out of the box. #1) is there a flag or a setting I should know about here for pytest? #2) I changed one test file (tests/demo/test_signus.py) to define the (lone) test_ function synchronously and within it, get the event loop and await to the original async def test_ function. That works OK. SURELY there is a better way to get test coverage than mangling the whole test suite in this fashion? The end goal here is to be able to understand better how this stuff hangs together.

gudkov (Wed, 23 Aug 2017 15:53:05 GMT):
Did you install dependencies from pypi? It requires pytest-asyncio to execute async tests with pytest.

gudkov (Wed, 23 Aug 2017 15:58:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aJivQgq9w8Rq9XBMj) Could you send logs?

sklump (Wed, 23 Aug 2017 16:04:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=rR8bBmFvX3rQujGYb) @gudkov I thought I had, via pip install pytest-asyncio -- let me try it again, thanks

sklump (Wed, 23 Aug 2017 16:10:14 GMT):
... now I have an awful lot of "E OSError: libindy.so: cannot open shared object file: No such file or directory" LD_LIBRARY_PATH=/home/sklump/indy/indy-sdk/libindy/target/debug pytest works a treat! Hurray! Thanks!

sklump (Wed, 23 Aug 2017 16:13:58 GMT):
Segmentation fault (core dumped) occurs in test_issuer_create_claim.py. Sorry, I know that's not very helpful.

sklump (Wed, 23 Aug 2017 16:13:58 GMT):
Segmentation fault (core dumped) occurs in test_issuer_create_claim.py, before any '.' goes to output -- I believe that means it's in the first method, test_issuer_create_claim_works() Sorry, I know that's not very helpful.

sklump (Wed, 23 Aug 2017 16:36:16 GMT):
I see that there is some debug logging in anoncreds.py:issuer_create_claim() -- I will figure out how to capture these and isolate where it dies.

sklump (Wed, 23 Aug 2017 17:28:45 GMT):
After libindy:create_cb: returns a CFunctionType object, output (stdout) from $ LD_LIBRARY_PATH=/home/sklump/indy/indy-sdk/libindy/target/debug pytest -s tests/anoncreds/* follows: DEBUG:indy.libindy:do_call: >>> name: indy_issuer_create_claim, args: (c_int(2), c_char_p(17577360), c_char_p(140436921960160), c_int(-1), c_int(-1), ) DEBUG:indy.libindy:do_call: Function indy_issuer_create_claim returned err: 0 DEBUG:indy.libindy:do_call: <<< DEBUG:indy.libindy:_indy_callback: <<< INFO|command_executor | src/commands/mod.rs:91 | AnoncredsCommand command received INFO|anoncreds_command_executor | src/commands/anoncreds/mod.rs:44 | Issuer command received INFO|issuer_command_executor | src/commands/anoncreds/issuer.rs:82 | CreateClaim command received INFO|anoncreds_service | src/services/anoncreds/issuer.rs:174 | Issuer create claim for schema 1 -> start INFO|anoncreds_service | src/services/anoncreds/issuer.rs:227 | Issuer issue primary claim for attributes ["sex", "name", "age", "height"] -> start INFO|anoncreds_service | src/services/anoncreds/issuer.rs:246 | Issuer sign attributes ["sex", "name", "age", "height"] -> start INFO|anoncreds_service | src/services/anoncreds/issuer.rs:282 | Issuer sign attributes -> done INFO|anoncreds_service | src/services/anoncreds/issuer.rs:239 | Issuer issue primary claim -> done INFO|anoncreds_service | src/services/anoncreds/issuer.rs:206 | Issuer create claim for schema 1 -> done Segmentation fault (core dumped) I would appreciate any pointers anyone might have.

sklump (Wed, 23 Aug 2017 17:28:45 GMT):
Sorry - it's too big. I'm pruning it, hoping to get under the limit

AxelNennker (Wed, 23 Aug 2017 18:19:52 GMT):
@gudkov I uploaded the output of the command. Which logs? How do I enable them? BTW happened yesterday and today after a pull too

sergey.minaev (Thu, 24 Aug 2017 07:11:00 GMT):
@sklump your last log seems like old python (or java) wrapper use latest libindy. Since PR-205 was merged our master always contains compatible java/python wrappers and libindy. So, please update your sources, rebuild libindy and make sure, that wrapper use latest sdk.

sergey.minaev (Thu, 24 Aug 2017 07:24:37 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aJivQgq9w8Rq9XBMj) @AxelNennker Do you run node pool in docker and forward ports as described in the first case of step 4 in the ubuntu-build.md? ```docker build -f ci/indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9708:9701-9708 indy_pool ``` Or you try the second case with docker network and specific IP?

sergey.minaev (Thu, 24 Aug 2017 07:24:37 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aJivQgq9w8Rq9XBMj) @AxelNennker Do you run node pool in docker and forward ports as described in first case of step 4 in the instruction? ``` docker build -f ci/indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9708:9701-9708 indy_pool ```

sergey.minaev (Thu, 24 Aug 2017 07:24:37 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aJivQgq9w8Rq9XBMj) @AxelNennker Do you run node pool in docker and forward ports as described in first case of step 4 in the instruction? ```docker build -f ci/indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9708:9701-9708 indy_pool ```

sergey.minaev (Thu, 24 Aug 2017 07:24:37 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aJivQgq9w8Rq9XBMj) @AxelNennker Do you run node pool in docker and forward ports as described in the first case of step 4 in the instruction? ```docker build -f ci/indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9708:9701-9708 indy_pool ```

sergey.minaev (Thu, 24 Aug 2017 07:37:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qig4g8ohA5ZKTxhFr) @AxelNennker this file contains only stdout. Libindy trace is in stderr. Also it's possible to configure log level via RUST_LOG environment variable. Actually to obtain helpful log for problem investigation please run test (or set of tests) with `RUST_LOG=trace RUST_BACKTRACE=1` and save both stderr and stdout.

sergey.minaev (Thu, 24 Aug 2017 07:38:32 GMT):
`RUST_TEST_THREADS=1` also required if multiply tests are run.

AxelNennker (Thu, 24 Aug 2017 09:21:03 GMT):
@sergey.minaev I did the second case because the first did not work; will send upload logs/traces later today. Thanks

sergey.minaev (Thu, 24 Aug 2017 09:22:13 GMT):
@AxelNennker for the second case `TEST_POOL_IP` environment variable is required too

sergey.minaev (Thu, 24 Aug 2017 09:22:13 GMT):
@AxelNennker for the second case `TEST_POOL_IP` parameter is required too

AxelNennker (Thu, 24 Aug 2017 09:24:05 GMT):
@sergey.minaev Just made that connection. Maybe https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md could point that out more clearly?

AxelNennker (Thu, 24 Aug 2017 09:24:50 GMT):
Another thing: the link https://github.com/hyperledger/indy-sdk/tree/master/ci/ubuntu.dockerfile yields a 404

sergey.minaev (Thu, 24 Aug 2017 09:26:03 GMT):
thanks for report, we will update these nuances.

sklump (Thu, 24 Aug 2017 13:30:04 GMT):
I got a fresh copy from github, rebuilt, and tried the cargo tests. They're failing, both for the port-map and docker-network configurations. With option --test=agent, there are: * a few dozen ERROR logs - pool handle invalid, - can't parse JSON, - wallet record not found, - address already in use, - connection not founded, - etc. * a whole bunch of CURVE I: public key not found messages (not sure if this is just expected test output?) * finally, an exit_with_error and a backtrace on a Rust panic. I've captured stdout and stderr from command: $ RUST_TEST_THREADS=1 RUST_LOG=trace RUST_BACKTRACE=1 TEST_POOL_IP=10.0.0.2 cargo test --test=agent &> libindy-agent-only.ubuntu1604.indy-pool-network.log and attached the file. Even with agent only, it's pretty big at 11MB.

gudkov (Thu, 24 Aug 2017 13:42:21 GMT):
Were we can find this log?

sklump (Thu, 24 Aug 2017 13:45:06 GMT):
Sorry, I'm pruning it to get under the max attachment size.

gudkov (Thu, 24 Aug 2017 13:47:47 GMT):
May be just put to google drive?

sklump (Thu, 24 Aug 2017 13:50:05 GMT):
Incoming ...

sklump (Thu, 24 Aug 2017 13:51:35 GMT):
https://drive.google.com/open?id=0B5fC2DoP_ko_bk91VWFsaVpFckk

sklump (Thu, 24 Aug 2017 13:52:03 GMT):
I trimmed out the test cases that succeeded (55 out of 57, one failed, one ignored)

sklump (Thu, 24 Aug 2017 14:24:31 GMT):
I've zipped and uploaded the log from command: RUST_TEST_THREADS=1 RUST_LOG=trace RUST_BACKTRACE=1 cargo test >& libindy.ubuntu1604.docker-p.log to google drive, at https://drive.google.com/open?id=0B5fC2DoP_ko_cFZyNXRaVlhBQUE I very much appreciate all your work and dedication. I will be more than happy to do what I can to help troubleshoot.

sklump (Thu, 24 Aug 2017 14:35:42 GMT):
For what it's worth, picking up the latest libindy fixes the trouble I was having yesterday with the python/pytest wrappers, thanks.

AxelNennker (Thu, 24 Aug 2017 14:54:07 GMT):
@sergey.minaev I created a PR https://github.com/hyperledger/indy-sdk/pull/222 and signed the CLA

sergey.minaev (Thu, 24 Aug 2017 14:55:59 GMT):
@AxelNennker Thanks! I will merge it soon

AxelNennker (Thu, 24 Aug 2017 15:01:41 GMT):
@sergey.minaev now fixed the link to ubuntu.dockerfile too

sergey.minaev (Thu, 24 Aug 2017 15:02:23 GMT):
@AxelNennker seems like GitHub can't recognize your email address (used for commit) for your profile.

AxelNennker (Thu, 24 Aug 2017 15:13:05 GMT):
@sergey.minaev Strange, never happened before. Anyway, I added that email address to my account too.

danielhardman (Thu, 24 Aug 2017 15:18:35 GMT):
Conversation on today's Agent Working Group call about writing wrappers; here's the link to the google doc we wrote about design guidelines: https://docs.google.com/document/d/15P6JOEKxbNC892DWReBStJIXrObVoaBDxbKJFOpAdjI/edit

ewelton (Fri, 25 Aug 2017 14:24:43 GMT):
Has joined the channel.

ewelton (Fri, 25 Aug 2017 14:25:27 GMT):
hello all and ready to work on the typescript/javascript/node.js port!

sergey.minaev (Fri, 25 Aug 2017 15:14:27 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done today: IS-140 Re-check the latest pool behavior, gathering logs from pool on jenkins Resolve various bugs and improvements: IS-204 IS-262 IS-268 Discuss DID-TLS design IS-287 Work on general solution (not just hotfix) - do not using fixed structure while catch-up, use AST for parsing received transactions IS-295 Release: Design acceptance procedure Creation of alternative Agent communication framework proposal. IS-296 Finish work on publishing indy-sdk to different streams

sergey.minaev (Fri, 25 Aug 2017 15:14:27 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done today and yesterday: IS-140 Re-check the latest pool behavior, gathering logs from pool on jenkins Resolve various bugs and improvements: IS-204 IS-262 IS-268 Discuss DID-TLS design IS-287 Work on general solution (not just hotfix) - do not using fixed structure while catch-up, use AST for parsing received transactions IS-295 Release: Design acceptance procedure Creation of alternative Agent communication framework proposal. IS-296 Finish work on publishing indy-sdk to different streams

sklump (Fri, 25 Aug 2017 18:37:27 GMT):
I'm going to ask probably a dumb question here: what is file libindy/docker-compose.yml (and its delegate libindy/ci/ubuntu.dockerfile) for? I've been hunting for code/scripts that use it, and not finding anything. Is this for automated testing, maybe?

ewelton (Fri, 25 Aug 2017 19:02:19 GMT):
that's an area where I've been quite confused as well....

ewelton (Fri, 25 Aug 2017 19:04:41 GMT):
the ci is definitely for automated testing, but then I tried to just do something like "copy the ubuntu.dockerfile" and I got stuck trying to get Charm to compile.... kinda made me want to step back and kick the tires a bit. kept trying my own little docker compositions, but then grinding teeth about header libs and feeling I'm just "so close!" ;)

sklump (Fri, 25 Aug 2017 19:06:25 GMT):
Any hand-rolled docker compositions are of tremendous interest to me. I am probably a month behind you but heading along that trail.

sklump (Fri, 25 Aug 2017 19:06:25 GMT):
Any hand-rolled docker compositions for nodes on the plenum are of tremendous interest to me. I am probably a month behind you but heading along that trail.

srottem (Sat, 26 Aug 2017 12:58:51 GMT):
I've been thinking this weekend about how to make the .NET wrapper cross-platform - since .NET Core is available on Windows, Linux and Mac it probably makes sense to target Core as well as the traditional .NET Framework which is Windows only. There are possible issues, however; for example, the PInvoke functionality uses the DllImport attribute to make native library calls available to the managed environment and this is applied in code with a hard-coded name for the c-callable library. The filenames for the Indy SDK library are different on Windows vs. other platforms (as far as I'm aware) but replicating the functions for each platform and using conditional statements at runtime to choose which version to use based on the execution environment would be a maintenance nightmare. In addition, considerations regarding how the wrapper will be packaged are important - I'm assuming we should make it available through NuGet, however I'm not clear on how developers/users are expected to get/install the c-callable libs the managed wrapper uses on a per-platform basis. Is anyone who might have some ideas on this available to have explore these issues?

sergey.minaev (Mon, 28 Aug 2017 04:39:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=xottvJXMYsXBH33cy) @sklump docker-compose.yml was used by our developers on Windows platform before we support native build for win. It may be helpful to run Ubuntu env on windows for some developers/debug purposes

sergey.minaev (Mon, 28 Aug 2017 04:40:45 GMT):
ubuntu.dockerfile used both for autotests while CI and from *.ym;

sergey.minaev (Mon, 28 Aug 2017 04:40:45 GMT):
ubuntu.dockerfile used both for autotests while CI and from *.yml

sergey.minaev (Mon, 28 Aug 2017 04:42:02 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=38xduBAT4ZTHZsxHQ) @ewelton what do you mean > something like "copy the ubuntu.dockerfile" Do you try to perform commands from the dockerfile on your host machine?

sergey.minaev (Mon, 28 Aug 2017 04:43:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=YpB4apkNL5rypNAgJ) @gudkov

sergey.minaev (Mon, 28 Aug 2017 04:43:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=YpB4apkNL5rypNAgJ) @gudkov >>>

srottem (Mon, 28 Aug 2017 12:55:57 GMT):
Quick question - where does the default wallet write it's files in Windows?

srottem (Mon, 28 Aug 2017 12:55:57 GMT):
Quick question - where does the default wallet type write it's files in Windows?

sklump (Mon, 28 Aug 2017 14:16:07 GMT):
Hello, I'm currently looking at /wrappers/python/tests/demo/test_anoncreds.py, and trying to figure out where the following magic values come from: * line 27 - 'NcYxiDXkpYi6ov5FcYDi1e' (issuer_did for call to anoncreds.issuer_create_and_store_claim_def()) * line 38 - 'BzfFCYk' (prover DID for call to anoncreds.prover_create_and_store_claim_req()) * line 43 - '5944657099558967239210949258394887428692050081607692519917050011144233115103' in JSON for 'male' <- not even facebook has this many genders ;-) * line 44 - '1139481716457488690172217916278103335' in JSON for 'Alex' Is there some strategy to generating the right numbers here, or else some set of guidelines for how big they ought to be? I may be missing something obvious. Thanks in advance.

sklump (Mon, 28 Aug 2017 14:16:07 GMT):
Hello, I'm currently looking at indy-sdk/wrappers/python/tests/demo/test_anoncreds.py, and trying to figure out where the following magic values come from: * line 27 - 'NcYxiDXkpYi6ov5FcYDi1e' (issuer_did for call to anoncreds.issuer_create_and_store_claim_def()) * line 38 - 'BzfFCYk' (prover DID for call to anoncreds.prover_create_and_store_claim_req()) * line 43 - '5944657099558967239210949258394887428692050081607692519917050011144233115103' in JSON for 'male' <- not even facebook has this many genders ;-) * line 44 - '1139481716457488690172217916278103335' in JSON for 'Alex' Is there some strategy to generating the right numbers here, or else some set of guidelines for how big they ought to be? I may be missing something obvious. Thanks in advance.

gudkov (Mon, 28 Aug 2017 14:23:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Locr5fK9has3iJj5D) It is ./indy/wallet folder inside user's home that is determined as: /// Returns the value of the 'HOME' environment variable if it is /// set and not equal to the empty string. Otherwise, returns the value of the /// 'USERPROFILE' environment variable if it is set and not equal to the empty /// string. If both do not exist, [`GetUserProfileDirectory`][msdn] is used to /// return the appropriate path.

srottem (Mon, 28 Aug 2017 20:57:45 GMT):
If I have two separate custom wallet types registered and if I create a wallet for the first registered wallet there's no problem, but if I attempt to create a second registered wallet with the same name it fails. I assumed that wallet names would be specific to a given wallet type, but it looks as though the SDK enforces the pool - wallet name combination is unique regardless of whether the default wallet type is used. Is this intentional?

srottem (Mon, 28 Aug 2017 20:57:45 GMT):
If I have two separate custom wallet types registered and if I create a wallet for the first registered wallet there's no problem, but if I attempt to create a wallet with the same name using the second wallet type it fails with a 203. I assumed that wallet names would be specific to a given wallet type, but it looks as though the SDK enforces the pool - wallet name combination is unique regardless of whether or not the default wallet type is used. Is this intentional?

srottem (Tue, 29 Aug 2017 07:16:13 GMT):
Another question; what's the plan on documentation? It would be nice to have links from the code docs in .NET to more detailed non-wrapper specific SDK documentation hosted on the web somewhere. Is the wiki a good target for this? Or is someone already working on documentation?

srottem (Tue, 29 Aug 2017 08:30:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6LbdZzaH4LZ8HmuKm) @srottem This looks like a bug so I've registered a ticket: https://jira.hyperledger.org/browse/IS-318

srottem (Tue, 29 Aug 2017 08:30:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6LbdZzaH4LZ8HmuKm) This looks like a bug so I've registered a ticket: https://jira.hyperledger.org/browse/IS-318

gudkov (Tue, 29 Aug 2017 08:41:58 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=LkodEarRKNHzxZEkd) It isn't a bug. It is expected behavior. Wallet name must be a unique regardless wallet type. This folder is used to store persistent wallet state (configuration).

srottem (Tue, 29 Aug 2017 08:42:26 GMT):
Oh, OK.

gudkov (Tue, 29 Aug 2017 09:19:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=PQzSGKvJKDQxdWpFc) @srottem Could you look to: IS-322: Documentation: Generate API documentation IS-297: Documentation: Restructure and enhance documentation and check these tasks correspond to your vision. We are welcome to any comments and feedback.

srottem (Tue, 29 Aug 2017 09:49:22 GMT):
@gudkov These tickets look like they touch on the relevant parts. I'll write up my thinking in the comments. I'm mostly focused on writing documentation for the .NET wrapper want those docs to focus on the .NET specific behavior and avoid replicating documentation that is about the underlying SDK. I think it makes more sense to have the .NET docs explain what SDK calls are used under the covers and link to those for more detailed descriptions of behavior.

sergey.minaev (Tue, 29 Aug 2017 14:51:51 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done today and yesterday: Discuss with indy-node team about blocker for IS-140: issue in indy-node INDY-761 Response with outdated data Resolve catch-up issue IS-287 Resolve issue IS-310 callback on custom wallet types never called Resolve issue IS-311 ubuntu: agent test cases fail on port-map configuration Implement publishing java wrapper to Maven repository (IS-213) Working on demo projects for installation testing (IS-313) Check compatibility with latest indy-node master and rc, update CI (IS-298) Create release candidate build (1.0.0-rc-1) Next Sprint planning

sklump (Tue, 29 Aug 2017 17:51:08 GMT):
#1 - Reminder, scrolled off the top: [ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RhG4KBxDK8A2Y92WK) #2 - I can't find any list of supported JSON keys for wallet credentials -- and from my limited understanding of the Rust source code, it looks like they are not implemented yet in the default wallet type. Is this correct? A username/password would suffice for our purposes.

sklump (Tue, 29 Aug 2017 17:51:08 GMT):
I can't find any list of supported JSON keys for wallet credentials -- and from my limited understanding of the Rust source code, it looks like they are not implemented yet in the default wallet type. Is this correct? A username/password would suffice for our purposes.

sklump (Tue, 29 Aug 2017 17:52:29 GMT):
I can't find any list of supported JSON keys for wallet credentials -- and from my limited understanding of the Rust source code, it looks like they are not implemented yet in the default wallet type. Is this correct? A username/password would suffice for our purposes.

Syscom (Wed, 30 Aug 2017 05:35:09 GMT):
Has joined the channel.

gudkov (Wed, 30 Aug 2017 08:41:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=H9Jjrz4FDGMDFZFC4) @sklump The list of JSON keys is specific for concrete wallet type. Default wallet type doesn't support any encryption/credentials now. We plan to provide basic encryption support in the next releases.

gudkov (Wed, 30 Aug 2017 08:42:32 GMT):
You can track progress in the following issue https://jira.hyperledger.org/browse/IS-46

gudkov (Wed, 30 Aug 2017 08:45:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RhG4KBxDK8A2Y92WK) @sklump NcYxiDXkpYi6ov5FcYDi1e and BzfFCYk are just some random DIDs. Big numbers in 43/44 are expected pre-calculated values based on ZQP math. It isn't magical numbers as this values must be prepared by INDY SDL calls.

gudkov (Wed, 30 Aug 2017 08:45:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RhG4KBxDK8A2Y92WK) @sklump NcYxiDXkpYi6ov5FcYDi1e and BzfFCYk are just some random DIDs. Big numbers in 43/44 are expected pre-calculated values based on ZQP math. The values aren't magical numbers as these values will be prepared by INDY SDK calls in real use cases.

sklump (Wed, 30 Aug 2017 10:51:20 GMT):
@gudkov How would I generate the numbers corresponding to, for example, 'female' and 'Laura' ? Could you point me in the direction of this ZQP math? We will be using indy-sdk to generate stuff like this for real use cases -- it's why I am particularly interested in this demo sample.

gudkov (Wed, 30 Aug 2017 10:53:48 GMT):
Have you looked to libindy-anoncreds.puml diagram in docs folder? It describes anoncreds protocol workflow in details.

gudkov (Wed, 30 Aug 2017 10:56:28 GMT):
Sorry

gudkov (Wed, 30 Aug 2017 10:56:28 GMT):
Sorry, I misunderstand your question intiially.

gudkov (Wed, 30 Aug 2017 10:57:13 GMT):
Some additional info for you: # 5. Issuer create Claim for Claim Request claim_json = json.dumps({ 'sex': ['male', '5944657099558967239210949258394887428692050081607692519917050011144233115103'], 'name': ['Alex', '1139481716457488690172217916278103335'], 'height': ['175', '175'], 'age': ['28', '28'] }) > 5944657099558967239210949258394887428692050081607692519917050011144233115103 > 1139481716457488690172217916278103335 Are just any hex encoded attributes valies

gudkov (Wed, 30 Aug 2017 10:58:07 GMT):
You can use any string or data and encode this string as hex any way you want.

gudkov (Wed, 30 Aug 2017 11:02:37 GMT):
'sex' attribute contains 2 values: 1. Human readable value 2. Some hex representation of this value

gudkov (Wed, 30 Aug 2017 11:07:41 GMT):
Verifier can verify predicates from this hex representation. For current moment it is possible to verify equality and ge

gudkov (Wed, 30 Aug 2017 11:08:36 GMT):
@sklump Ping me if you need additional help

sklump (Wed, 30 Aug 2017 11:34:41 GMT):
Thanks! I must digest all of these doc/*.puml diagrams.

sergey.minaev (Wed, 30 Aug 2017 21:35:18 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done today and yesterday: *Releasing candidate 2 for v1.0.0* Investigate Patricia Merkle Tree (ethereum article, python implementation, analyse use cases for indy-sdk) Complete IS-313 Release: Demo projects for installation testing Implement IS-323 Indy Crypto: AMCL curves configuration through Cargo features Support IS-324 Indy Crypto:Debug build support for AMCL

ewelton (Thu, 31 Aug 2017 02:52:33 GMT):
update on the node port - currently available here : https://github.com/korsimoro/indy-sdk/tree/init-node-wrapper/wrappers/node, which is just a fork - send me your github and I'll give you full access.

ewelton (Thu, 31 Aug 2017 02:54:45 GMT):
I support keeping it as a fork for the next week or so, while we finish up the major layout changes - node.js is a multi-language environment, but they are all bound together by transpilers - bable/tsc and good old JavaScript (or is that ES5, ors ES6, or ES7?) - we should have a clean package that can be deployed on those node.js based environments, from a common typescript code base soon - at which point we will make a clean submission to hyperledger/indy-sdk.

ewelton (Thu, 31 Aug 2017 02:55:28 GMT):
in the meantime, i invite everyone to weigh in and help us get the right package in place.

gudkov (Thu, 31 Aug 2017 07:46:32 GMT):
@ewelton Thanks for doing this. My first impression that it is great, but looks really overcomplicated and exposes a lot of new words like runtime, ffi, bridge, async bridge, promise bridge, service provider, debug trace middlewares and etc. These words are new for libindy and for the most of NodeJS world too. As a developer I just expect the simple interface that will follow original libindy and hide all details: ``` const libindy = new LibIndy({ logger: logger, // Optional support of logger throughput promise: Promise // Optional support of promise throughput }); // It should work with Node-style callbacks if callback passed libindy.create_pool_ledger_config("pool1", { genesis_txn: "./genesis_txn.txn" }, (err) => { }) // It should return promise if no callback passed libindy .create_pool_ledger_config("pool1", { genesis_txn: "./genesis_txn.txn" }) .then() .catch() // It should work also work automatically with async/await as async/await just sugar for yielding promises async function my_method() { await libindy.create_pool_ledger_config("pool1", { genesis_txn: "./genesis_txn.txn" }) } ``` This interface MUST use native Node types and provide optional typing. But i don't need a lot of interfaces and classes exposed. Just one class LibIndy.

gudkov (Thu, 31 Aug 2017 07:46:32 GMT):
@ewelton Thanks for doing this. My first impression that it is great, but looks really overcomplicated and exposes a lot of new words like runtime, ffi, bridge, async bridge, promise bridge, service provider, debug trace middlewares and etc. These words are new for libindy and for the most of NodeJS world too. As a developer I just expect the simple interface that will follow original libindy and hide all details: ``` const libindy = new LibIndy({ logger: logger, // Optional support of logger throughput promise: Promise // Optional support of promise throughput }); // It should work with Node-style callbacks if callback passed libindy.create_pool_ledger_config("pool1", { genesis_txn: "./genesis_txn.txn" }, (err) => { }) // It should return promise if no callback passed libindy .create_pool_ledger_config("pool1", { genesis_txn: "./genesis_txn.txn" }) .then() .catch() // It should also work automatically with async/await as async/await just sugar for yielding promises async function my_method() { await libindy.create_pool_ledger_config("pool1", { genesis_txn: "./genesis_txn.txn" }) } ``` This interface MUST use native Node types and provide optional typing. But i don't need a lot of interfaces and classes exposed. Just one class LibIndy.

ewelton (Thu, 31 Aug 2017 08:26:18 GMT):
thanks for the feedback.

ewelton (Thu, 31 Aug 2017 08:28:45 GMT):
my thought is that the above is almost completely realized by ```const libindy_core = new LibIndyRuntime({ logger: logger, // Optional support of logger throughput }); const libindy = libindy.bridge // It should work with Node-style callbacks if callback passed // we can add 'callbacks' as well. that's a good thought. // libindy.create_pool_ledger_config("pool1", { genesis_txn: "./genesis_txn.txn" }, (err) => { }) // It should return promise if no callback passed // this is supported by the current system libindy .create_pool_ledger_config("pool1", { genesis_txn: "./genesis_txn.txn" }) .then() .catch() // It should also work automatically with async/await as async/await just sugar for yielding promises // this is supported by the current system async function my_method() { await libindy.create_pool_ledger_config("pool1", { genesis_txn: "./genesis_txn.txn" }) }```

ewelton (Thu, 31 Aug 2017 08:31:00 GMT):
i do agree with you about the simplification - but what do you think?. I like the idea of making a terminal callback optional - and automatically switching between promise/non-promise modes, but that leaves the question of how structure the ffi.Callback() call.

ewelton (Thu, 31 Aug 2017 08:31:46 GMT):
the interface can be phrased in terms of strings, ints, and the like - but what about the "string-as-json", what are your interests there?

gudkov (Thu, 31 Aug 2017 08:32:07 GMT):
I believe we should remove exposing FFI at all.

ewelton (Thu, 31 Aug 2017 08:32:35 GMT):
my concern with that was the person coming in and saying that 'bridge' added too much

ewelton (Thu, 31 Aug 2017 08:33:13 GMT):
i, on the other hand, do *not* want the above interface - i am consuming something like the SPI in an express/electron client. so if I had the above only, I'd just have to re-create that model.

ewelton (Thu, 31 Aug 2017 08:33:43 GMT):
i want it available - definitely - and I know I can think of cases when that is exactly what I want - but for my current main use cases, I want something a little different.

ewelton (Thu, 31 Aug 2017 08:36:58 GMT):
another option is to make it a 'package time' distinction - i've done that.

gudkov (Thu, 31 Aug 2017 08:37:11 GMT):
Why should system libirary provide express/electron interface? It is a very strange decision. If someone needs this he can easy create his own small integration. Same with FFI. If someone need access on DLL level he can just call ffi.dlopen()

ewelton (Thu, 31 Aug 2017 08:37:14 GMT):
so there's a "indy-sdk-promise" and "indy-sdk" and so forth.

gudkov (Thu, 31 Aug 2017 08:38:22 GMT):
I spend significant time to just understand this mess of interfaces.

ewelton (Thu, 31 Aug 2017 08:38:29 GMT):
i see what you're saying - i'm actually using the SPI in my electron thing, and I just wanted a standard way of exposing the LIBINDY_PATH environment variable. Finding that in a "platform neutral" way has a bit of magic - that's pretty much what I was hoping for. That and having a 'first line of defense' against the lowest level of changes.

gudkov (Thu, 31 Aug 2017 08:39:19 GMT):
Why you need to expose LIBINDY_PATH?

ewelton (Thu, 31 Aug 2017 08:39:22 GMT):
if we hid that, what are your preferred mechanics for finding the library? i'm a bit weak on the options available - i figure an env var is required, but the platform specific issues are a bit of a mystery to me

ewelton (Thu, 31 Aug 2017 08:39:43 GMT):
the guidelines point about "finding the associated rust library" in standard ways

gudkov (Thu, 31 Aug 2017 08:40:12 GMT):
ffi.dlopen() will find libirary for you.

ewelton (Thu, 31 Aug 2017 08:40:29 GMT):
pretty much all "FFI" is about, to me at least, is addressing that point and taking care of the low level bits - did you see the stuff about the *mut? I don't have a good solution to those on wallet type implementatoins yet.

ewelton (Thu, 31 Aug 2017 08:40:37 GMT):
ffi.dlopen() did not find for me.

ewelton (Thu, 31 Aug 2017 08:41:02 GMT):
i was unable to reliably control the targetting of my ffi implementation using that.

ewelton (Thu, 31 Aug 2017 08:41:02 GMT):
i was unable to reliably control the targetting of my ffi implementation using that alone.

ewelton (Thu, 31 Aug 2017 08:43:10 GMT):
ffi.dlopen, for me at least, had no problem finding a specific instance of a library given a path, but as for working in a cross-platform way to find pre-installed libraries, i didn't have luck. But I don't discount user error

ewelton (Thu, 31 Aug 2017 08:52:01 GMT):
what about a strategy like fs, and fs-extra?

gudkov (Thu, 31 Aug 2017 08:52:38 GMT):
I don't understand why we need this at all. Could you provide use case when my example doesn't work for you?

gudkov (Thu, 31 Aug 2017 08:53:55 GMT):
why we need a lot of this words: bridge, bridge.promise, bridge.async, a lot of words about ffi in documentation, strange libindy.use call and etc...

ewelton (Thu, 31 Aug 2017 08:56:10 GMT):
well - i have code, and it uses a different interface than yours - let's just leave it at that, why i want that code is kinda just personal i guess.

ewelton (Thu, 31 Aug 2017 08:56:20 GMT):
but i get it - you want something that's pretty much like bridge only

ewelton (Thu, 31 Aug 2017 08:56:27 GMT):
and I definitely understand that

ewelton (Thu, 31 Aug 2017 08:56:44 GMT):
so - let's see what we can do to make that happen - specifically - i'm curious about the library loading.

ewelton (Thu, 31 Aug 2017 08:56:54 GMT):
did you have luck with ffi.dlopen() requiring something other than a specific path?

ewelton (Thu, 31 Aug 2017 08:57:31 GMT):
if so, maybe we can jetison the FFI portion - if that can be safely absorbed - but there are about 4 issues I struggle with there

ewelton (Thu, 31 Aug 2017 08:58:30 GMT):
1) finding dlopen library, 2) handling the callback argument interpolation (and avoiding having it hardcoded throughout my code), 3) mutable types, and 4) how to keep my binding to librust in one place in my app.

ewelton (Thu, 31 Aug 2017 08:59:58 GMT):
i don't have great answers to those 4, but i think they are "common to node deployments" - if we can find a good solution for those, i'm all in favor of ditching the ffi directory.

ewelton (Thu, 31 Aug 2017 09:07:42 GMT):
and - also - this is an open repo as far as I'm concerned - not "mine" in any way - please feel free to commit and change directly - or make branches or whatnot... #1 goal is to get something into hyperledger/indy-sdk and use this space for playing around with exactly these sorts of overarching concerns - it's a challenge made large by node with it's crazy flexibility. i defer to the community to get this right! ;)

ewelton (Thu, 31 Aug 2017 09:09:09 GMT):
BTW: for me, I have a small footprint v8 app w/ DID for https://lab.ruuvi.com/

ewelton (Thu, 31 Aug 2017 09:09:54 GMT):
and I also have the electron/react/redux use (which taps libindy calls via middleware to generate redux actions and update UI and app state)

ewelton (Thu, 31 Aug 2017 09:10:30 GMT):
but, I'm not convinced that putting that all into *one* wrapper is a good idea at all.

ewelton (Thu, 31 Aug 2017 09:11:09 GMT):
but that, i hope, kinda lays out a spectrum of v8 based consumption of the rust library.

gudkov (Thu, 31 Aug 2017 09:36:28 GMT):
> 1) finding dlopen library, 2) handling the callback argument interpolation (and avoiding having it hardcoded throughout my code), 3) mutable types, and 4) how to keep my binding to librust in one place in my app. From my point of view libindy wrapper should provide the following: - Easy cross-platform way to load libidny library based on process environment configuration. Optionally there can be the way to provide explicit path to library through LibIndy constructor. - Explicit set of libindy calls that can be easy integrated to Node-callback style, promise and async/await environment - Mapping of NodeJS types and callbacks to native types and callbacks and that's all. > 2) handling the callback argument interpolation (and avoiding having it hardcoded throughout my code), 3) mutable types, and 4) how to keep my binding to librust in one place in my app. Is completely out of scope for this wrapper as it is very application specific behaviour that will be hard to understand and support.

gudkov (Thu, 31 Aug 2017 09:37:42 GMT):
It can be provided by dedicated codebase and package.

ewelton (Thu, 31 Aug 2017 10:01:33 GMT):
I'm ok with that, definitely.

ewelton (Thu, 31 Aug 2017 10:02:00 GMT):
so - for FFI - have you gotten dlopen() to work on a cross platform way?

ewelton (Thu, 31 Aug 2017 10:02:48 GMT):
i finally just got tired of trying, so switched to LIBINDY_PATH env var - which I can control, but I couldn't get anything like "solid cross platform" loading working. thoughts?

gudkov (Thu, 31 Aug 2017 10:04:57 GMT):
We have it implemented for python and java

gudkov (Thu, 31 Aug 2017 10:05:47 GMT):
Actually java handles the most of logic, python requires library name configuration

gudkov (Thu, 31 Aug 2017 10:06:14 GMT):
You can look to https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/indy/libindy.py

gudkov (Thu, 31 Aug 2017 10:06:24 GMT):
See def _load_cdll() -> CDLL:

gudkov (Thu, 31 Aug 2017 10:06:24 GMT):
`` def _load_cdll() -> CDLL: ```

gudkov (Thu, 31 Aug 2017 10:06:24 GMT):
``` def _load_cdll() -> CDLL: ```

gudkov (Thu, 31 Aug 2017 10:07:38 GMT):
For process level control you can use standard LD_LIBRARY_PATH varibale on linux and PATH on windows

gudkov (Thu, 31 Aug 2017 10:08:01 GMT):
but this varibable will be handled by system dlopen call, not by your code.

gudkov (Thu, 31 Aug 2017 10:15:34 GMT):
Actually expected workflow for the most of users: 1. Install libindy.deb 2. Instantiate LibIndy without any additional variables provided

ewelton (Thu, 31 Aug 2017 11:16:03 GMT):
100% agree

ewelton (Thu, 31 Aug 2017 11:16:18 GMT):
question - for the node-ffi, are you getting accurate interpolation of LD_LIBRARY_PATH or is that something that we need to implement?

ewelton (Thu, 31 Aug 2017 11:17:11 GMT):
i was not getting it to work with ffi.dlopen('libindy') - but i suspect user error

ewelton (Thu, 31 Aug 2017 11:17:26 GMT):
are you getting ffi.dlopen to find your libindy via LD_LIBRARY_PATH?

ewelton (Thu, 31 Aug 2017 11:18:21 GMT):
if so, then the current implementation should find it without any configuration options - if you do not specify anything, it calls ffi.dlopen('libindy') - and if you set LIBINDY_PATH it will use that instead.

ewelton (Thu, 31 Aug 2017 11:19:18 GMT):
It should do this: ffi.dlopen('libindy') unless the LIBINDY_PATH environment variable is set, or unless it has been programmatically set (skipping both)...

gudkov (Thu, 31 Aug 2017 11:27:12 GMT):
As i understand the code: ``` var ffi = require('ffi'); var libm = ffi.Library('libm', { 'ceil': [ 'double', [ 'double' ] ] }); libm.ceil(1.5); // 2 ``` Will look for libm in system/process library path automatically. User can change this path by setting some OS-specific variables like LD_LIBRARY_PATH or PATH. So you don't need to have access to this variables from your code.

darrell.odonnell (Thu, 31 Aug 2017 11:37:41 GMT):
@ewelton I'd be happy to have a discussion on how you can help @gudkov meet the "bare bones" (my term) approach to creating a basic libIndy Node.js library.

ewelton (Thu, 31 Aug 2017 13:22:21 GMT):
great - what are the ideas

ewelton (Thu, 31 Aug 2017 13:24:13 GMT):
i agree with @gudkov - but the current system does exactly what he's requested, only it has a layer of indirection. the way I see it we have a lot of options to make it easier - e.g. we could package just that set of functionality as one npm package, or we could carve the source base separately to make it smaller - so that there are two repositories - one that is bare bones, etc.

ewelton (Thu, 31 Aug 2017 13:24:49 GMT):
i do, however, think that forcing people to use system installed packages is not ideal. Currently it *will* do exactly libindy = ffi.library('libindy') - so that is what it does.

ewelton (Thu, 31 Aug 2017 13:25:31 GMT):
we can remove the ability to optionally override that, but I'm not sure what the gain is there.

ewelton (Thu, 31 Aug 2017 13:26:40 GMT):
i definitely see his point about "too complicated a wrapper" - and there are a couple of options for dealing with that. Again, this is why I didn't want to go straight for the hyperledger/indy-sdk pull request - cause, once we get under the hood there are a couple of issues to straighten out

ewelton (Thu, 31 Aug 2017 13:27:10 GMT):
the mutable stuff, particularly in wallet type definitions is one - as well as the need to call ffi.Callback in a very boilerplate fashion, is another.

ewelton (Thu, 31 Aug 2017 13:28:48 GMT):
very happy to have this discussion though - we need the right set of npm packages - not sure if one will do it, maybe there are one or two - it'll shake out soon enough. looking forward to hearing more ideas.

gudkov (Thu, 31 Aug 2017 13:43:41 GMT):
We don't need ffi.Callbacks and any ffi types usage in bare bones wrapper. It must be Native node callbacks.

gudkov (Thu, 31 Aug 2017 13:43:58 GMT):
All FFI related staff must be completely hidden by this wrapper.

ewelton (Thu, 31 Aug 2017 13:44:37 GMT):
hmmm - interesting,

ewelton (Thu, 31 Aug 2017 13:44:49 GMT):
how would the Callback cb parameter be handled in the ffi._method_ case?

ewelton (Thu, 31 Aug 2017 13:45:35 GMT):
for example, in ``` // pool.rs 'indy_create_pool_ledger_config': [ffi_error_code, [ffi_command_handle,ffi_name,ffi_json_data_string,ffi_callback]], 'indy_open_pool_ledger':[ffi_error_code, [ffi_command_handle, ffi_name, ffi_json_data_string, ffi_callback]], 'indy_refresh_pool_ledger':[ffi_error_code, [ffi_command_handle, ffi_handle, ffi_callback]], 'indy_close_pool_ledger':[ffi_error_code, [ffi_command_handle, ffi_handle, ffi_callback]], 'indy_delete_pool_ledger_config':[ffi_error_code, [ffi_command_handle, ffi_name, ffi_callback]], ```

ewelton (Thu, 31 Aug 2017 13:45:43 GMT):
the last ffi_callback - how can we get rid of that?

gudkov (Thu, 31 Aug 2017 13:46:50 GMT):
Sure you must use this FFI Callback, but it is private function from wrapper code that calls user defined Node callback

ewelton (Thu, 31 Aug 2017 13:47:04 GMT):
exactly, that's what I'm talking about

ewelton (Thu, 31 Aug 2017 13:47:46 GMT):
you have to call ffi.Callback() to generate the callback and hand it in. Almost all of the callbacks are identical.

ewelton (Thu, 31 Aug 2017 13:48:25 GMT):
what, exactly, do you feel is missing between libindy.ffi.(args) - is it all the ffi_X constants?

ewelton (Thu, 31 Aug 2017 13:48:25 GMT):
what, exactly, do you feel is missing from libindy.ffi.(args) - is it all the ffi_X constants?

gudkov (Thu, 31 Aug 2017 13:52:16 GMT):
Wrapper should provide the following API: ``` libindy.create_pool_ledger_config("pool1", { genesis_txn: "./genesis_txn.txn" }, (err) => { }) ``` (err) => { } here is regular js lambda or function. Implementation of libindy.create_pool_ledger_config will call libindy method and wrap this callback to ffi.Callback. If no callback passed it should return promise instead that will be resolved inside ffi.Callback.

gudkov (Thu, 31 Aug 2017 13:53:36 GMT):
err must be instance of Error or Error child class (like IndyError) that contains error code returned form libindy

gudkov (Thu, 31 Aug 2017 13:55:47 GMT):
libindy have a significant amount of callbacks that also return results (handles, keys and etc.). In this case callback signature will be like: ``` function (err, wallet_handle) ``` corresponded promise will be resolved with this wallet_handle value or rejected with IndyError

sergey.minaev (Thu, 31 Aug 2017 14:21:54 GMT):
We are happy to present *Indy-SDK v1.0.0 release*: The first official release of [indy-sdk](https://github.com/hyperledger/indy-sdk). Artifacts: * Libindy * [deb files](https://repo.evernym.com/libindy/ubuntu/stable/1.0.0/) for Ubuntu-based distributives * [zip-archive](https://repo.evernym.com/libindy/windows/stable/1.0.0/) for windows * Python wrapper pip package [python3-indy==1.0.0](https://pypi.python.org/pypi/python3-indy/1.0.0) * Java wrapper maven artifcat `indy` on Evernym repo: ``` evernym https://repo.evernym.com/artifactory/libindy-maven-local org.hyperledger indy 1.0.0 ```

sergey.minaev (Thu, 31 Aug 2017 14:21:54 GMT):
We are happy to present *Indy-SDK v1.0.0 release*: The first official release of [indy-sdk](https://github.com/hyperledger/indy-sdk). Artifacts: Libindy * [deb files](https://repo.evernym.com/libindy/ubuntu/stable/1.0.0/) for Ubuntu-based distributives * [zip-archive](https://repo.evernym.com/libindy/windows/stable/1.0.0/) for windows Python wrapper pip package [python3-indy==1.0.0](https://pypi.python.org/pypi/python3-indy/1.0.0) Java wrapper maven artifcat `indy` on Evernym repo: ``` evernym https://repo.evernym.com/artifactory/libindy-maven-local org.hyperledger indy 1.0.0 ```

jamesmonaghan (Thu, 31 Aug 2017 14:24:03 GMT):
fantastic!

jamesmonaghan (Thu, 31 Aug 2017 14:24:21 GMT):
well done guys, what a huge milestone :tada:

ewelton (Thu, 31 Aug 2017 14:28:22 GMT):
@gudkov - that is exactly what happens. I think something has been lost - the API you describe is implemented, but I think that is not apparent. Let's see if we can clear that up.

ewelton (Thu, 31 Aug 2017 14:30:06 GMT):
the only difference is that you have a layer that interpolates the callback function, and calls ffi.Callback, and I implemented a callback that only resolves/rejects.

ewelton (Thu, 31 Aug 2017 14:31:16 GMT):
it does seem that we could use another variant that does not use Promises - or, as indicated, if the final parameter in the argumetn array is a function, that is called in lieu of a promise. but it seems like it would be nearly as easy to use libindy.then().catch()

ewelton (Thu, 31 Aug 2017 14:37:13 GMT):
currently, the callback generally does this : ``` return ffi.Callback(ffi_void, [ffi_command_handle, ffi_error_code], (command_handle:rust_command_handle, error_code:rust_error_code) => { if(error_code == 0) { debug("RESOLVING:%j",error_code) resolve() } else { debug("REJECTING:%j",error_code) reject(new IndyError(error_code)) } }); ```

ewelton (Thu, 31 Aug 2017 14:38:29 GMT):
then,you can do ```libindy.ffi.create_pool_ledger_config("name", { genesis_txn: "./genesis_txn.txn" }).then(...).catch(...)```

ewelton (Thu, 31 Aug 2017 14:40:15 GMT):
we could automatically call the .catch *if* the final argument is a callback so that you could move the .catch() to the libindy.ffi.create_pool_ledger_config() call itself.

ewelton (Thu, 31 Aug 2017 14:41:00 GMT):
oops, i typed wrong - i meant ```libindy.bridge.create_pool_ledger_config("name", { genesis_txn: "./genesis_txn.txn" }).then(...).catch(...)``` - if you used libindy.ffi you would have to pass in the results of the ffi.Callback() call directly. but that is available as well.

james-speirs (Thu, 31 Aug 2017 14:53:47 GMT):
Has joined the channel.

gudkov (Thu, 31 Aug 2017 15:06:03 GMT):
@ewelton My main concern is that there are: - 3 different APIs for the same thing (ffi, bridge.promis, bridge.async) - Exposing low-level ffi details - A lot of external staff like middlewares It makes this code hard to understand, support and conflicts with our wrappers design approach. My suggestion is following: - Leave one API that will be compatible with callback-style and promise style convention. It is a very common approach in Node/Frontend world. - Hide all low-level implementation details. It will allow switching from node-ffi to something else in the future without breaking API - Move all external staff to dedicated project After this, we can easily move this core code to the main indy-sdk repo.

andkononykhin (Thu, 31 Aug 2017 15:13:06 GMT):
Has joined the channel.

ewelton (Thu, 31 Aug 2017 15:28:04 GMT):
@gudkov - i can see that - split the code base into two repositories. the spi and middleware stuff is of interest to me (it's what I use) but i could see making it into two packages.

ewelton (Thu, 31 Aug 2017 15:28:49 GMT):
the system was set up so that eveyrthing is built off of FFI. FFI + bridge then, with the rest of it removed as a "core package", and then I can provide an add-on that is built around that. it should just be some restructuring of the code.

ewelton (Thu, 31 Aug 2017 15:29:27 GMT):
for me however, I already have several integrations with express, redux, and running under electron - tooled up using events and middleware. but it would not be any trouble to split it into two repositories.

ewelton (Thu, 31 Aug 2017 15:30:14 GMT):
what I'm seeing is that you wanted an API, and I provided *exactly* that API, but, as you point out, it was too confusing so it wasn't obvious. Simplifying and making the base API without anything else as indy-sdk is totally reasonable - and if that's the consensus, I'm all for it.

ewelton (Thu, 31 Aug 2017 15:39:16 GMT):
actually also - i should point out, the 3 apis are FFI, Promise, and Object - FFI has no type checking and requires manual construction of callbacks and handles. Bridge is pretty much exactly what you asked for (you can ignore the async stuff - as I said in the README, I think it should be gone), but then the Object library - which is the one I'm most actively using myself.

ewelton (Thu, 31 Aug 2017 15:39:55 GMT):
I think that FFI itself is too low level, I think the Promise library is the closes to the right one. It is the one you describe.

ewelton (Thu, 31 Aug 2017 15:41:58 GMT):
should we try that in a branch - maybe make a branch "simplified", get rid of middleare, just include promise and FFI, and see how that looks?

gudkov (Thu, 31 Aug 2017 15:53:37 GMT):
Let's try

srottem (Fri, 01 Sep 2017 12:04:56 GMT):
I'm working on documentation at the moment and in the SDK code-docs I see the term "validator pool" used in leder.rs and "pool ledger" used in pool.rs. Are these terms interchangeable?

srottem (Fri, 01 Sep 2017 12:04:56 GMT):
I'm working on documentation at the moment and in the SDK code-docs I see the term "validator pool" used in ledger.rs and "pool ledger" used in pool.rs. Are these terms interchangeable?

gudkov (Fri, 01 Sep 2017 12:33:46 GMT):
In these comments, it means the same.

gudkov (Fri, 01 Sep 2017 12:35:39 GMT):
Not sure that it is the best terms here. Actually ledger==distributed database. And pool is set of nodes. Pool hosts multiple distrivutes databases: identity ledger, nodes ledger, configuration ledger.

srottem (Fri, 01 Sep 2017 13:37:01 GMT):
OK, so the Pool class in Java is really referring to a "node pool".

srottem (Fri, 01 Sep 2017 13:39:10 GMT):
When using the using the Ledger.submitRequest() function we're submitting a request to the node pool so validators in the pool can read from or write to the ledger, no?

srottem (Fri, 01 Sep 2017 13:39:10 GMT):
When using the Ledger.submitRequest() function we're submitting a request to the node pool so validators in the pool can read from or write to the ledger, no?

gudkov (Fri, 01 Sep 2017 13:46:34 GMT):
Yes Pool part is related to connecting to nodes, Ledger part is about sending transactions.

srottem (Fri, 01 Sep 2017 13:47:21 GMT):
That was my understanding - just confirming so the docs read correctly.

srottem (Fri, 01 Sep 2017 14:40:20 GMT):
Is there a reason the config parameter is passed to the delete callback in indy_register_wallet_type? I haven't been able to discern why it would be there.

gudkov (Fri, 01 Sep 2017 15:12:10 GMT):
Because it can just store the link to database/HKS/HashiCorp. And to remove the database you need this information.

gudkov (Fri, 01 Sep 2017 15:13:25 GMT):
Your WalletType can be state full and store this information, but for a lot of use cases it is unnecessary.

srottem (Fri, 01 Sep 2017 15:46:51 GMT):
Gotcha.

mark.hadley (Fri, 01 Sep 2017 15:56:04 GMT):
For the java wrapper, the readme refers to an object 'CreatePoolLedgerConfigResult'. I'm unable to find that object in the java wrapper code. Is this an old reference?

srottem (Fri, 01 Sep 2017 17:20:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=gcsZ8B3EKcMsswdhH) @mark.hadley Yes - this is an old reference. The future returned from the Pool.createPoolLedgerConfig() method resolves to Void.

srottem (Sat, 02 Sep 2017 08:26:51 GMT):
The documentation on the indy_store_their_did function indicates that the "verkey" member in the identity_json parameter is optional "if only pk is provided". Is this correct? If so, where is the pk provided?

srottem (Sat, 02 Sep 2017 11:15:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Dj6QcTEhFMp3sTh2d) @gudkov I'm interested in this too - how are these hex encoded values generated? e.g. in your example how is '5944657099558967239210949258394887428692050081607692519917050011144233115103' derived from 'male'?

gudkov (Mon, 04 Sep 2017 09:04:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=23PCHK8j6fSnpSbEv) @srottem hex encoding is out of API scope. You can use any approach. Anoncreds code will compare hex values and verify predicates on hex values.

srottem (Mon, 04 Sep 2017 09:28:20 GMT):
Ah, I see. Thanks!

srottem (Mon, 04 Sep 2017 13:26:52 GMT):
I'm seeing a problem when trying to build indy-pool.dockerfile on ubuntu - I get the following error messages: - Version '1.1.112' for 'indy-plenum' was not found - Version '1.0.25' for 'indy-anoncreds' was not found - Version '1.1.119' for 'indy-node' was not found

gudkov (Mon, 04 Sep 2017 14:45:55 GMT):
I will check with Node team

sergey.minaev (Mon, 04 Sep 2017 14:55:20 GMT):
@srottem @gudkov currently `master` branch contains unconsist `ARG`s in this docker file. I will produce PR to fix it. workaround is set something of the parameters in build command. E.g. `docker build -f ci/indy-pool.dockerfile --build-arg sovrin_stream=master .`

srottem (Mon, 04 Sep 2017 16:45:04 GMT):
Yep - that worked. Thanks guys.

sergey.minaev (Mon, 04 Sep 2017 17:56:38 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done today and friday IS-315 Indy Crypto python wrapper (in progress) IS-316 Investigate python and rust implementation of Patricia tree in ethereum, draft implementation in indy-sdk for decode trie from proofs and encode IS-314 Indy Crypto BLS calls (in progress) Fix default dependencies versions in indy-node.dockerfile

mark.hadley (Tue, 05 Sep 2017 23:15:06 GMT):
The java wrapper command '$ mvn package' creates the indy1.0.0.jar. It seems that we would need to take the jar and the .so file and put them in the same directory. Does this seem correct, or is there a different file structure? Does the .so file need to be in a directory named 'lib' in the new project?

mark.hadley (Wed, 06 Sep 2017 03:41:56 GMT):

Message Attachments

mark.hadley (Wed, 06 Sep 2017 03:45:16 GMT):
Heres the output for running the java wrapper. The .so file is in ./lib/, and java is 1.8 on ubuntu 16.04. I am able to do $ mvn -Dmaven.test.skip clean install to produce the package. Curious if there is anything obvious that I'm missing to get the tests passing for the java wrapper. Any input appreciated.

mark.hadley (Wed, 06 Sep 2017 03:45:44 GMT):
and by package I mean 'jar file'

gudkov (Wed, 06 Sep 2017 06:41:47 GMT):
@mark.hadley libindy java wrapper requires libindy to be present in the path that system dynamic lib loader can find it. For Ubuntu, i recommend installing libindy from deb here https://repo.evernym.com/libindy/ubuntu/stable/ Alternatively, you can copy libindy.so to ./lib folder or just configure library loaded with an environment variable (LD_LIBRARY_PATH on linux or PATH on windows). To execute tests you need to start local nodes pool on 127.0.0.1:9701-9708 with Docker: ``` docker build -f ci/indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9708:9701-9708 indy_pool ```

gudkov (Wed, 06 Sep 2017 06:41:47 GMT):
@mark.hadley libindy java wrapper requires libindy to be present in the path that system dynamic lib loader can find it. For Ubuntu, i recommend installing libindy from deb here https://repo.evernym.com/libindy/ubuntu/stable/ Alternatively, you can copy libindy.so to ./lib folder or just configure library loader with an environment variable (LD_LIBRARY_PATH on linux or PATH on windows). To execute tests you need to start local nodes pool on 127.0.0.1:9701-9708 with Docker: ``` docker build -f ci/indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9708:9701-9708 indy_pool ```

mark.hadley (Wed, 06 Sep 2017 11:34:15 GMT):
Thanks, cant believe I forgot about the nodes. I'll use the deb as well.

sklump (Wed, 06 Sep 2017 12:08:38 GMT):
Hello, As an exercise to improve our understanding of the process, I would like to add a new agent to Faber, Acme, and Thrift in the Alice story. The Indigenous and Northern Affairs Canada (INAC) agent would: * on creation, - write a (simplistic) INAC-Status claim definition consisting of: > ssn [str] _(wrong on many levels for Canada, but plough through)_ > status [boolean] - create a request for Alice to connect - store an INAC-Status claim for Alice * on bootstrap, - get or bootstrap the INAC-Status claim definition defined above - make Alice's claim available. A few questions arise, regarding magic values. From `sovrin_client/test/agent/faber.py`: --------------------------------------- * in `create_faber()`, - `agent.invites`, > is `b1134a647eb818069c089e7694f63e6d` a nonce? > can `openssl rand -hex 16` suffice to generate such a nonce, or is there a more native way in practice? * in `bootstrap_faber()`, - re: ID `schema_id`, `FuN98eH2eZybECWkofW6A9BKJxxnTatBCopfUiNxo6Z` is Faber's DID. > How is it generated? > Is it only in the `sovrin>` client that the steward writes Faber as a trust anchor? - re: coro call to `bootstrap_schema()` -- the primes `p` and `q` come from `../constants.py`. > is it OK to use `openssl prime -generate -bits 1024` to generate both? > Do `p` and `q` need to be related somehow on the ed/curve25519 curve or is it enough that they are 1024 bits (and distinct)? From `sovrin_client/test/agent/acme.py`: -------------------------------------- * in `bootstrap_acme()`, the code re-uses the same `primes["prime1"]` to bootstrap the `Job-Certificate` schema as `bootstrap_faber()` in `faber.py` uses for its `Transcript` schema. Is this safe? What are `p` and `q` for?? Disclaimer: I have a degree in crypto, but it's from 1993-94 when elliptic curve crypto was new, so I don't know all the modern tricks. So you can get pretty technical with me, but I can't claim to understand all the results in depth.

gudkov (Wed, 06 Sep 2017 12:39:34 GMT):
@sklump Not sure that it is correct channel. Try to ask in ~indy-node

sklump (Wed, 06 Sep 2017 12:46:05 GMT):
Thanks, my mistake.

sklump (Wed, 06 Sep 2017 12:46:05 GMT):
Thanks, my mistake. Deleted.

sklump (Wed, 06 Sep 2017 12:46:05 GMT):
Thanks, my mistake. Deleted to avoid polluting the stream.

mark.hadley (Wed, 06 Sep 2017 14:42:48 GMT):
Just confirming: the java wrapper tests require the nodes to be running (using the docker command above) and have the libindy.so file in the lib directory of the root directory of the java wrapper. After those two items are in place, then the $ mvn clean install should run the tests successfully?

mark.hadley (Wed, 06 Sep 2017 14:47:22 GMT):
I just remembered that my machine falls into the docker network issue. Most likely thats my issue.

mark.hadley (Wed, 06 Sep 2017 15:04:08 GMT):
Well that definitely helped things. After running the libindy cargo tests successfully, I moved to the java wrappers test and only had 1 failed test: DeletePoolTest.testDeletePoolWorksForOpened

ryanmarsh (Wed, 06 Sep 2017 16:49:05 GMT):
Has joined the channel.

ewelton (Thu, 07 Sep 2017 13:50:18 GMT):
I noticed earlier a discussion of the strange "pool/ledger/pool-ledger" concept. The existing rust SDK has a separation of concerns here, but there are 1:1 relationships. I managed to separate them out as follows

ewelton (Thu, 07 Sep 2017 13:51:17 GMT):
in pool.rs there are 2 methods related to "pool_ledger_configs" - these are independent, and refer only to a GenesisTxn set - which, sadly, is "stored on a filesystem" - but ultimately is a set of "JSON-like" data, so you can wrapperize it to hide the FS part and concentrate on the data

ewelton (Thu, 07 Sep 2017 13:51:47 GMT):
so "GenesisConfigurations" are "Unopened Pools" - in pool.rs, 2 of the 5 signatures deal with this.

ewelton (Thu, 07 Sep 2017 13:51:59 GMT):
the other three signatures deal with "pools" which are opened with a GenesisConfiguration.

ewelton (Thu, 07 Sep 2017 13:52:15 GMT):
I've modeled that as a Pool = e.g. a Pool = an open genesis configuration.

ewelton (Thu, 07 Sep 2017 13:54:00 GMT):
then there is the step of getting a Ledger out of a Pool - the ledger requires additional configuraiton (3 options listed in the docs) - and to me, *that* is the difference between an opened pool and a ledger. it is born out by the contract of pool.rs, which has combined 2 separate concerns - "pool_ledger_configs" and "pool_ledgers", while a "ledger" (as in ledger.rs) is a "pool which has been opened with a given configuration" - this is why you hand the pool_handle all over the ledger.rs instead of, say, a ledger handle.

ewelton (Thu, 07 Sep 2017 13:54:52 GMT):
but - this makes sense, given that the factoring of the rust library is broken down as @gudkov indicates - there is an underlying cryptographic reason for this, but not one that maps into other APIs directly.

gudkov (Thu, 07 Sep 2017 14:00:38 GMT):
From my point of view, you have some conception misunderstanding: - Pool is set of nodes that communicate in RBFT approach. You can define a configuration of the pool, perform nodes resolving based on this config and connect to nodes. It is part of "pool" API. - Ledger is distributed database. Pool provides different ledgers: nodes, config, transactions. We don't have any open_ledger API calls. Calls from "ledger" API allows you to build and send transactions to ledgers.

ewelton (Thu, 07 Sep 2017 15:04:06 GMT):
this is great - it is the understanding I'd like to see in the SPI wrapper around Bridge. (Bridge is, I think, the API you want - if it is not, let's follow that in a separate thread because it should be actionable change, the design issues in the SPI are at a higher level)

ewelton (Thu, 07 Sep 2017 15:04:25 GMT):
is a pool anything other than a named set of genesis transactions?

ewelton (Thu, 07 Sep 2017 15:04:51 GMT):
from the API it looks that way, but I suspect I'm missing something

ewelton (Thu, 07 Sep 2017 15:19:04 GMT):
BTW - I like the idea of splitting out the SPI totally - I think that a clear, simple package, w/ just FFI + Bridge is a good idea. Is there anything about the bridge API or README usecase that specifically look bad - assuming I pull all of the SPI stuff into a tertiary repo?

gudkov (Thu, 07 Sep 2017 15:36:26 GMT):
pool is set of nodes (Indy Node instances). Genesis transactions is part of node ledger transactions list that is used to construct node ledger state on the client. This state contains set of nodes (ips and public keys) that allow client to connect to nodes.

gudkov (Thu, 07 Sep 2017 15:36:26 GMT):
pool is set of nodes (Indy Node instances). Genesis transactions is part of pool ledger transactions list that is used to construct node ledger state on the client. This state contains set of nodes (ips and public keys) that allow client to connect to nodes.

gudkov (Thu, 07 Sep 2017 15:36:26 GMT):
pool is set of nodes (Indy Node instances). Genesis transactions is part of pool ledger transactions list that is used to construct pool ledger state on the client. This state contains set of nodes (ips and public keys) that allow client to connect to nodes.

gudkov (Thu, 07 Sep 2017 15:36:26 GMT):
pool is set of nodes (Indy Node instances). Genesis transactions is part of pool ledger transactions list that is used to construct pool ledger state on the client. This state contains set of NODE transactions (contains ips and public keys of Nodes in pool) that allow client to connect to nodes.

sergey.minaev (Thu, 07 Sep 2017 16:10:25 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done today IS-314: Tests for Indy Crypto FFI and Rust interfaces (done) IS-315: Indy Crypto python wrapper (in progress) IS-316: Working on error cases for state proofs checking IS-336: Python Wrapper: Python 3.5 compatibility IS-337: Python Wrapper: Remove Python 3.6 dependency from CI

sergey.minaev (Thu, 07 Sep 2017 16:10:25 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done today IS-314 Tests for Indy Crypto FFI and Rust interfaces (done) IS-315 Indy Crypto python wrapper (in progress) IS-316 Working on error cases for state proofs checking IS-336 Python Wrapper: Python 3.5 compatibility IS-337 Python Wrapper: Remove Python 3.6 dependency from CI

ewelton (Fri, 08 Sep 2017 02:21:36 GMT):
@gudkov From the perspective of the Rust API, the pool.rs has 2 functions create_pool_ledger_config and open_pool_ledger_config, which assign names to a set of genesis transactions (which are required to communicate with the pool). Then, pool.rs has 3 additional functions which open, refresh, and close the connection with the pool. The connection between these two groups of functions is the named set of genesis transactions - the "config_name" parameter. In fact, the open_pool_ledger combines the named set of genesis transactions with a runtime configuration, and returns a pool_handle. For this reason, I believe the API makes the case that a Ledger is an opened connection to a Pool, where "which pool" is determined by the named set of genesis transactions, and the characteristics of the connections are governed by the runtime configuration.

ewelton (Fri, 08 Sep 2017 02:24:21 GMT):
so - for my personal tastes, I think that modeling the above - where a Ledger is an open connection to a Pool defined by (runtime_config, genesis_transactions) is pretty clear. It is much simpler than the direct Rustlib API, which seems to have a lot of extra overhead - stuff like command handles, and multiple paths to returning an error code - sometimes via a callback (which is *not* good practice in ES6), and sometimes directly.

ewelton (Fri, 08 Sep 2017 02:25:43 GMT):
I am in favor of an API that removes the complexities of the implementation - in fact, I found the Python structure rather confusing and difficult to follow. Specifically with all the futures tracking - that seemed a bit odd. It seemed to me that the bulk of the Python API was built as a work-around for the fact that python does not have the same sort of native Promise and EventLoop support that is core to the V8 and ES6 environments.

ewelton (Fri, 08 Sep 2017 02:28:31 GMT):
In my thinking, something like this ```const libindy = require('indy-sdk') let pool_handle :number let wallet_handle :number try { await libindy.create_pool_ledger_config() pool_handle = await libindy.open_pool_ledger_config() const runtime_config = {} const credentials = {} wallet_handle = await libindy.open_wallet('a-name',runtime_config,credentials) } catch(error) { // error is an instance of IndyError, which has the // integer error code }``` is clear - it is 1:1 mapped onto the Rust API. However, if I understand correctly, the problem with this API is that it is lacking explicit command_handles, has a single Promise based API (e.g. use .then/.catch and exceptions instead of error codes and callbacks). If you can provide some specific, actionable guidance as to how you'd like to change the above - I would very much appreciate the guidance.

ewelton (Fri, 08 Sep 2017 02:37:33 GMT):
I also have a sense that strong-typing and static-type analysis is getting in the way. This could be a deeper issue - for example, when opening a pool to obtain access to a Ledger you pass in a string which contains a serialized JSON object with 3 fields. In TypeScript (ES6 w/ type hints), you typically use an interface to define that structure - that interface allows the compiler to do a lot of optimizations as well as program logic checking. We could choose to hide the type information, and make everything an 'any' type - which would map perhaps better to the Python implementation, but I think that is a definite step backwards. If there is a consensus to avoid static-type analysis and the benefits of strong typing - then I think we really need to think of 2 APIs for Node - one that is oriented towards non-typed, no-promises, manual event lib - and one that is more connected with the full suite of ES6 tools, which include strong-typing, native promises, and single threaded event-lib.

ewelton (Fri, 08 Sep 2017 02:40:55 GMT):
In fact, I think there is some reason for concern about having background threads in a V8 environment - and that is the area that really scares me. I don't like a library that runs background threads - and I prefer to isolate them on their own process - using some lightweight IPC to keep the "clean Node.js" environment separate from the "dirty/threaded" one. It could be that the single-threaded nature of V8 is not fully compatible with the rust library implementation - it would be a shame if that were the case, and I don't know the answer - but out of all the issues surrounding the Rust/V8 integration, this is the one that has me most concerned - maybe someone has some good information?

gudkov (Fri, 08 Sep 2017 15:34:15 GMT):
> is clear - it is 1:1 mapped onto the Rust API. However, if I understand correctly, the problem with this API is that it is lacking explicit command_handles, has a single Promise based API (e.g. use .then/.catch and exceptions instead of error codes and callbacks). If you can provide some specific, actionable guidance as to how you'd like to change the above - I would very much appreciate the guidance. command_handle is needed only for C language that doesn't have closures and requires some id to map callback to API call invocation. For js and python it is compeltely unnecessary. Just look to python API. > and multiple paths to returning an error code Wrapper should have just one path. He should return error code as field of error in promise or first argument of node style callback. It is very easy to achive. Look how it is done in Python. > has a single Promise based API (e.g. use .then/.catch and exceptions instead of error codes and callbacks). It is very natural to Node API to provide callbacks and promise style operations for the same calls. You should return promise if no callback provided. Just look for example to mongodb driver http://mongodb.github.io/node-mongodb-native/2.0/api/MongoClient.html. ::connect method returns Promise if no callback passed. > In fact, I think there is some reason for concern about having background threads in a V8 environment It is impossible to implement complex networking lib without internal threads. If lib will have blocking API you will just block the whole V8 thread loop. I don't see restrications in creation of native threads inside of loaded shared dlls in V8. FFI support working with callbacks out of the box.

bdot (Sat, 09 Sep 2017 10:10:14 GMT):
Has joined the channel.

ewelton (Mon, 11 Sep 2017 01:11:57 GMT):
@gudkov - please don't say "node style callback" - that is innacturate. As indicated, I feel that callbacks are a bad decision when you have full fledged promise support. The python API I looked at had a lot of extraneous 'futures' management, and that is what I am wondering if you are missing. I found the python code very confusing to run through because of this, and I am hoping to avoid that mistake.

ewelton (Mon, 11 Sep 2017 01:12:34 GMT):
So - I really think that, when you put out the situations, having an optional callback after a bunch of optional parameters, expecially when one is not needed, is not a good idea.

ewelton (Mon, 11 Sep 2017 01:13:48 GMT):
The current api resolves to void or the value, and rejects with an Error (for stack trace), that contains the error code. It seems like this is still not apparent though.

ewelton (Mon, 11 Sep 2017 01:15:43 GMT):
so - summary: I think the missing part is 1) you want a callback to provide a redundant alternative to .then, and this is somehow "node-style" (although I quite disagree with that). Otherwise, the API is exactly as you indicate - so, again, I'm confused and "look at Python" - that was not at all clear to me, and I don't see the value there - I really shunned the Python api code when I looked at it and turned to the Java code for a better example.

ewelton (Mon, 11 Sep 2017 01:17:18 GMT):
can we confirm that you don't like the "Promise only" approach, and that you would like to see calls like "function(undefined,undefined,undefined,undefined,(callback)) instead of just "function().then()" - which is equivalent. This might be true if you are wanting to support different languages, e.g. not ES6. But again, that has nothing to do with "node-style" or not, node is a v8 engine, it has no connection to callbacks vs. promises, those are language level issues. And node supports multiple languages.

ewelton (Mon, 11 Sep 2017 01:23:35 GMT):
anyhow - as we discussed, I'll do up a version that I think you'll like and maybe that's the candidate for the community - I won't do the callback + promise though, because I think that is a bad idea. Someone else can add that in - it's just really ugly to me. What I think you're really after is 1) hide FFI, 2) remove middleware wrappers, 3) no object api (the *only* one I use), and 4) introduce a python-style "hidden global" that avoids the ability to instantiate the library *after* configuration. That is a bare-bones, minimal API, but it might be the most like the python one w/o introducing ES6 inappropriate constructs like callbacks. If that's better for the community, then that is a win and we can go with that.

ewelton (Mon, 11 Sep 2017 04:06:40 GMT):
pushed to 'minimal' branch - that is a single-file version - the wallet handling (callbacks & mutable types) is definitely not correct, but let me know if this is more like what you had in mind. Again, using callbacks (pre-ES6) and Promises (>= ES6) via the Mongo (which was developed before ES6) style is, IMHO, a bad design decision and should be avoided. That can be added later. But perhaps this is more suitable - if it is, we can figure out how to build the testing harness and move forward. Most important is that it fits the widest range of use cases for the community. Will look for feedback.

sergey.minaev (Mon, 11 Sep 2017 06:07:39 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done Friday IS-315 Indy Crypto python wrapper (in progress) IS-316 Start integration state_proof into indy-sdk code for ledger communication iOS wrapper: register_wallet_type support and key chain based wallet

gudkov (Mon, 11 Sep 2017 07:46:16 GMT):
> please don't say "node style callback" - that is inaccurate. From my point of view, it is a very natural description of API based on error-first callbacks. Node still uses error first callbacks as the main API approach and the most of articles and books use this. Do you see any promises here https://nodejs.org/api/fs.html#fs_fs_appendfile_file_data_options_callback ??? > The python API I looked at had a lot of extraneous 'futures' management, and that is what I am wondering if you are missing. I found the python code very confusing to run through because of this, and I am hoping to avoid that mistake. Could you describe Python API problems in more details? What you mean on futures management? Python methods return future instead of promise, but it is very similar pattern. What boilerplate or inaccurate code do you see?

gudkov (Mon, 11 Sep 2017 08:55:33 GMT):
> So - I really think that, when you put out the situations, having an optional callback after a bunch of optional parameters, expecially when one is not needed, is not a good idea. All native Node API follow this way. So you just saying that Node has a very badly designed API. Note Node allows to skip optional params. Look to https://nodejs.org/api/fs.html#fs_fs_appendfile_file_data_options_callback You can call it as s.appendFile(file, data, callback) and s.appendFile(file, data, options, callback)

gudkov (Mon, 11 Sep 2017 09:11:08 GMT):
> can we confirm that you don't like the "Promise only" approach, and that you would like to see calls like "function(undefined,undefined,undefined,undefined,(callback)) instead of just "function().then()" - which is equivalent. This might be true if you are wanting to support different languages, e.g. not ES6. But again, that has nothing to do with "node-style" or not, node is a v8 engine, it has no connection to callbacks vs. promises, those are language level issues. And node supports multiple languages. Personally i prefer Promise based API (used with async/await or generators) for the most of use cases, but Promises have significant problems for some use cases: - Promise isn't basic asynchronous primitive in JS. The most basic primitive is callback. Callbacks are faster and thinner. You always can easily convert callbacks based API to promises based API, but promises can't be converted to callbacks without performance degradation. - Native ES6 Promises have some performance problems by design, so it is very common to use alternative implementations like Bluebird on backend side. - Some asynchronous patterns (like saga) aren't compatible with promises. - TypeScript still has problems with 3d party Promises integration In my oppinion the best way to follow is provide hybrid callbacks/promises API. You can use callbacks for some performance critical parts of your app and promises for the rest. Not sure that it is blocker at all. We can start with Promise-only for the beginning. As i understand you are afraid about TypeScript typing for this approach. From my poin of view it can be solved by params overloading feature of TS.

gudkov (Mon, 11 Sep 2017 09:12:29 GMT):
> pushed to 'minimal' branch - that is a single-file version - the wallet handling (callbacks & mutable types) is definitely not correct, but let me know if this is more like what you had in mind. Again, using callbacks (pre-ES6) and Promises (>= ES6) via the Mongo (which was developed before ES6) style is, IMHO, a bad design decision and should be avoided. That can be added later. But perhaps this is more suitable - if it is, we can figure out how to build the testing harness and move forward. Most important is that it fits the widest range of use cases for the community. Will look for feedback. Thank you for this contribution a lot. I will look. We can create PR to indy-sdk repo and start disussion on GH if you want.

sklump (Mon, 11 Sep 2017 11:26:59 GMT):
I hate to be that guy, but I cloned the current (2017-09-11 11:15 GMT: 8837b64) hyperledger indy-sdk from github, and now it fails at the cargo build step: *...libindy$ cargo build* Compiling indy v1.0.0 (file:///home/sklump/indy/indy-sdk/libindy) error: associated constants are experimental (see issue #29646) --> src/services/pool/state_proof.rs:29:5 | 29 | const RADIX: usize = 16; | ^^^^^^^^^^^^^^^^^^^^^^^^ error: associated constants are experimental (see issue #29646) --> src/services/pool/state_proof.rs:30:5 | 30 | const FULL_SIZE: usize = Node::RADIX + 1; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: associated constants are experimental (see issue #29646) --> src/services/pool/state_proof.rs:31:5 | 31 | const PAIR_SIZE: usize = 2; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: associated constants are experimental (see issue #29646) --> src/services/pool/state_proof.rs:32:5 | 32 | const HASH_SIZE: usize = 32; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: associated constants are experimental (see issue #29646) --> src/services/pool/state_proof.rs:33:5 | 33 | const IS_LEAF_MASK: u8 = 0x20; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: associated constants are experimental (see issue #29646) --> src/services/pool/state_proof.rs:34:5 | 34 | const IS_PATH_ODD_MASK: u8 = 0x10; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error(s) There may be a compile flag to enable 'associated constants' in the rust compiler, but I don't see it in the docs just yet?

sklump (Mon, 11 Sep 2017 11:35:34 GMT):
I hate to be that guy, but I cloned the current (2017-09-11 11:15 GMT: 8837b64) hyperledger indy-sdk from github, and now it fails at the cargo build step: `...libindy$ cargo build` produces ``` Compiling indy v1.0.0 (file:///home/sklump/indy/indy-sdk/libindy) error: associated constants are experimental (see issue #29646) --> src/services/pool/state_proof.rs:29:5 | 29 | const RADIX: usize = 16; | ^^^^^^^^^^^^^^^^^^^^^^^^ error: associated constants are experimental (see issue #29646) --> src/services/pool/state_proof.rs:30:5 | 30 | const FULL_SIZE: usize = Node::RADIX + 1; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: associated constants are experimental (see issue #29646) --> src/services/pool/state_proof.rs:31:5 | 31 | const PAIR_SIZE: usize = 2; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: associated constants are experimental (see issue #29646) --> src/services/pool/state_proof.rs:32:5 | 32 | const HASH_SIZE: usize = 32; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: associated constants are experimental (see issue #29646) --> src/services/pool/state_proof.rs:33:5 | 33 | const IS_LEAF_MASK: u8 = 0x20; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: associated constants are experimental (see issue #29646) --> src/services/pool/state_proof.rs:34:5 | 34 | const IS_PATH_ODD_MASK: u8 = 0x10; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error(s) ``` It appears something called a nightly compiler may support this -- but I don't want to stray too far from the documented build procedure. I think it's an oversight?

gudkov (Mon, 11 Sep 2017 11:47:18 GMT):
@sklump latest stable compiler supports this (1.20)

sergey.minaev (Mon, 11 Sep 2017 11:47:51 GMT):
@sklump you can update rust by `rustup update`

gudkov (Mon, 11 Sep 2017 15:35:28 GMT):
@ewelton Some findings on minimal branch: * We need introducing some structure to code. Not sure that all code in one file will work for us. * Call convention looks mostly ok (at least for the beginning) * In your approach you creates new ffi.Callback object for each new invocation. It has some potential problems: * Performance problem. Creation of new native callback is potentially long blocking operation. * When you pass callback to native function you looses the reference to callback. As result it can be garbadge collected and code execution can be broken. I suggest to create exactly one instance of ffi.Callback object for each call and map callback result to Promise through comman_handle param. * I don't like callbacks in agent API. May be we can avoid this. * It would be nice to have complete list of test cases.

skbodwell (Mon, 11 Sep 2017 20:49:08 GMT):
Has joined the channel.

ewelton (Tue, 12 Sep 2017 03:41:58 GMT):
sounds reasonable - let's see what we can do to make this converge. this path will be a bit slower for m though - I am using an advanced node/rust adapter with my express bindings, electron bindings, and dockerode in a project I call "indy-workbench" - it is kinda like Postman (also electron) but for a private indy instance on a local docker universe. It has uport and other hooks based on the different formats of DIDs. That project is my main focus, and I hope to make a formal release end of month. With time permitting I will try to push this forward, and again - i must stress - everyone has admin access on @korsimoro/indy-sdk - so *please* go to town and push this forward. When the community has a good alpha, we can make a pull request against indy-sdk - but *please* commit and use the access to the korsimoro/indy-sdk repo, it is *not* going to break anything for anyone. The repo exists specifically for this kind of large/overarching design adaptation. I think it is worth remembering that Node.js is not a language, it is not even a standard library - it is a VM with conventions and a *huge* infrastructure of ideas - some of which make sense, many of which do not. The degree to which your language is configured by various config files (package.json, tsconfig, tslint, etc. etc.) is kinda unique. With a couple of edits to a config file you can "turn on promises" and "target non-promise event loops on legacy browsers" - and, conversely, you can configure the transpilation to avail yourself of every avant-garde language whim of the day (and still target a toaster runtime).

ewelton (Tue, 12 Sep 2017 03:44:36 GMT):
so - to be clear - korsimoro/indy-sdk - let's hammer on it, and make something look like what everyone wants - it is an open repo, low ceremony, and not on any critical path. Let's get some input beside myself and @gudkov arguing about whether or not a global promise/future dictionary limits transpilation optimizations? ;)

ewelton (Tue, 12 Sep 2017 04:36:46 GMT):
Question: ```pub extern fn indy_create_wallet(command_handle: i32, pool_name: *const c_char, name: *const c_char, xtype: *const c_char, config: *const c_char, credentials: *const c_char, cb: Option) -> ErrorCode { ``` - where are pool's named? is this the pool_ledger_config(configuration_name?) or entry in the ${basepath}/.indy/pool/ directory - in which case, couldn't it map to pool_handle (or an active Pool?) - what are the considerations towards naming pools in this context and how to pool_name's relate to pool_handles?

ewelton (Tue, 12 Sep 2017 05:09:19 GMT):
Question: in ```pub extern fn indy_encrypt(command_handle: i32, wallet_handle: i32, pool_handle: i32, my_did: *const c_char, did: *const c_char, message_raw: *const u8, message_len: u32, cb: Option) -> ErrorCode { ``` it seems like you could have a wallet open on multiple concurrent pools. I don't think this is supported. What is the rationale behind having the wallet/pool separation here - why two independent degrees of freedom in the API? Likewise, both my_did and did are 'encrypting DIDs' (from the comments), which is true, but presumably one is associated w/ the wallet in question (e.g. my_did) and the other is a recipient?

gudkov (Tue, 12 Sep 2017 05:10:13 GMT):
It is config_name from indy_create_pool_ledger_config

ewelton (Tue, 12 Sep 2017 05:10:35 GMT):
ah... so in that call, it is a registered 'configuration_name' - got it. thx.

gudkov (Tue, 12 Sep 2017 05:10:37 GMT):
Looks like we have some incosistence in docs terminology.

ewelton (Tue, 12 Sep 2017 05:10:50 GMT):
nothing an object model can't clear up ;)

gudkov (Tue, 12 Sep 2017 05:11:46 GMT):
The reason of this params is mapping of wallet to concrete pool as identities and keys are only valid in one pool scope.

ewelton (Tue, 12 Sep 2017 05:16:05 GMT):
i have a naive idea that a wallet is tied to a concrete pool - the API suggests that a wallet may be tied to multiple pools - is that correct? is a wallet "pool-ephemeral"?

ewelton (Tue, 12 Sep 2017 05:17:09 GMT):
if a wallet is "pool-locked", then you should have a reference to it when the wallet_handle is minted. If it is *not* pool-locked, then wallets can exist independently of an opened pool. Is that the case?

ewelton (Tue, 12 Sep 2017 05:19:17 GMT):
i'm looking at the viability of a "wallet.encrypt(message).for(...dids).from(...dids)" expression - same low level call, but wanting to understand if I can do that or if I need "wallet.encrypt(message,pool).for...." and so forth.

ewelton (Tue, 12 Sep 2017 05:25:44 GMT):
also - for quick clarification - "message" is a "byte array" or is it a string (e.g. UTF-encoded) - char*'s often point to byte arrays, but sometimes also point to strings.

ewelton (Tue, 12 Sep 2017 05:26:24 GMT):
in the encrypt case, it is a buffer - but agent messages are *const char's

gudkov (Tue, 12 Sep 2017 05:29:41 GMT):
Wallet is related to concrete pool, but this relation is provided through "pool_name" only. Each pool and wallet have 2 identities: 1. Static or persistence identity. "wallet_name" and "pool_name" ("config_name") parameters are provides this identity. Actually it is the folders on file system that contain configuration files, data files (for default wallet type) and chache. 2. Runtime identity. When you "open" wallet or pool it casues creation of runtimes structures like sockets, db connections and etc... It is possible to open pool and wallet independently, but if operation requires access to both pool and wallet it will perform checking that pool and wallet are compatible in runtime. The reason to don't correlate pool_handle and wallet_handle explicitly is the very common use case when pool can be opened on one PC and all cryptocraphy can be done on second PC.

ewelton (Tue, 12 Sep 2017 05:30:41 GMT):
or - in my case - docker images with express links between libindy instances ;)

ewelton (Tue, 12 Sep 2017 05:31:13 GMT):
but - even given that infrastructure - i still am not clear

ewelton (Tue, 12 Sep 2017 05:31:46 GMT):
if I have a wallet, opened with a runtime config relative to a "wallet_name" - is that ever associated with another pool (open or not?)

ewelton (Tue, 12 Sep 2017 05:32:35 GMT):
and, given that there is also a runtime configuration associated with "opening a pool" - let's verify that the link with the wallet and the pool does *not* rely upon the runtime configuration handed when you "open a pool"?

ewelton (Tue, 12 Sep 2017 05:32:49 GMT):
BTW - i do appreciate the clarification - is is *much* faster than reading the .rs files ;)

gudkov (Tue, 12 Sep 2017 05:34:20 GMT):
``` pub extern fn indy_encrypt(command_handle: i32, wallet_handle: i32, pool_handle: i32, ``` This operation will chec that name of wallet (provided by walleet_handle) is the same as the name of pool (provided by pool_handle), but you can close pool, open it again and get new pool_handle as result. It will be possible to use this new handle without any problems.

ewelton (Tue, 12 Sep 2017 05:35:14 GMT):
so, in this case the operative parameter is "pool_name" not "pool_handle" since it does *not* matter if it is open or not - or does it "have to be open" at the time?

gudkov (Tue, 12 Sep 2017 05:35:46 GMT):
encrypt/decrypt and sign/verify methods work with binary buffers (zeros are possible here).

gudkov (Tue, 12 Sep 2017 05:36:15 GMT):
indy_encrypt - requires pool handle as it performs resolving of keys through the ledger.

ewelton (Tue, 12 Sep 2017 05:38:26 GMT):
ah... nice - so encrypt is a live wallet transaction against an open pool - but it is *also* the case that a wallet is bound to the "name" of the opened pool. Presumably, if I did something like "rm -rf ~/.indy/pool/; mv ~/.indy/pool/" - cryptographic chaos would ensue and I'd start getting ErrorCode's from all calls?

gudkov (Tue, 12 Sep 2017 05:41:09 GMT):
"encrypt" the same as "verify" lookups wallet for public key. If no key found or key is outdated it will lookup ledger and cache pk for this identity in wallet.

ewelton (Tue, 12 Sep 2017 05:41:49 GMT):
ah... ok... "this identity" = "my_did", yes?

gudkov (Tue, 12 Sep 2017 05:41:58 GMT):
No, it is their did

ewelton (Tue, 12 Sep 2017 05:42:05 GMT):
ah... got it.

ewelton (Tue, 12 Sep 2017 05:42:33 GMT):
but a wallet can have multiple did's (hence the my_did) parameter?

gudkov (Tue, 12 Sep 2017 05:42:44 GMT):
my did requires private keys. These keys can be saved only through signus_store_my_did

gudkov (Tue, 12 Sep 2017 05:43:07 GMT):
wallet can store any amount of my dids, their dids and claims

ewelton (Tue, 12 Sep 2017 05:43:46 GMT):
excellent - so "wallet.encrypt(...).from()" or "wallet.encrypt(...).as()" make sense ;)

gudkov (Tue, 12 Sep 2017 05:43:48 GMT):
For agency use case it is natural to use one wallet for one user, but user can own multiple dids

ewelton (Tue, 12 Sep 2017 05:44:12 GMT):
beleive me - i am 100% conversant on User : DID relations ;)

ewelton (Tue, 12 Sep 2017 05:45:20 GMT):
not so clear on wallet : DID - but i'm getting caught up, thx to your clarifications - again - i think this is useful to many, and I do appreciate the time and attention. to me it is exceptionally valuable and timesaving.

sergey.minaev (Tue, 12 Sep 2017 05:47:32 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done Monday IS-315 Indy Crypto python wrapper and tests (done) IS-316 Continue integration state_proof into indy-sdk code for ledger communication iOS wrapper: continue work on register_wallet_type support and key chain based wallet

ewelton (Tue, 12 Sep 2017 06:07:18 GMT):
question: why does ```pub extern fn indy_replace_keys(command_handle: i32, wallet_handle: i32, did: *const c_char, identity_json: *const c_char, cb: Option) -> ErrorCode { ``` have an explicit DID *and* DDO (identity_json), but ```pub extern fn indy_create_and_store_my_did(command_handle: i32, wallet_handle: i32, did_json: *const c_char, cb: Option) -> ErrorCode { ``` uses a complex logic to determine the effective DID - e.g. ```/// did_json: Identity information as json. Example: /// { /// "did": string, (optional; /// if not provided and cid param is false then the first 16 bit of the verkey will be used as a new DID; /// if not provided and cid is true then the full verkey will be used as a new DID; /// if provided, then keys will be replaced - key rotation use case) ``` - question is, is this significant or just an implementation detail?

ewelton (Tue, 12 Sep 2017 06:14:58 GMT):
both seem to potentially replace the same keys, depending on the configuration of these two parameters, with the create_and_store case storing a fresh DDO in the event that the DID is not yet registered. There is also a linking with the verkey that I thought we abandonded a long, long time ago - not that I find the default behaviour objectionable, but it seems at cross purposes with the part of the Sovrin DID being an opaque identifier (which, ultimately, is 1:1 associated w/ a private key)

ewelton (Tue, 12 Sep 2017 06:14:58 GMT):
both seem to potentially replace the same keys, depending on the configuration of these two 'DID solutions', with the create_and_store case storing a fresh DDO in the event that the DID is not yet registered. There is also a linking with the verkey that I thought we abandonded a long, long time ago - not that I find the default behaviour objectionable, but it seems at cross purposes with the part of the Sovrin DID being an opaque identifier (which, ultimately, is 1:1 associated w/ a private key)

ewelton (Tue, 12 Sep 2017 06:23:39 GMT):
the signficance of the verkey is only whether or not a level of indirection is required when processing arbitrary "DID resolutions" - both did:sov: and did:sov: are compatible, but the idea of using the full verkey was to push the frontier of DDoS validation out to the very front side of the network interface (DNS, HTTP, QUIC, whatever) - e.g. . or http:// or whatnot gives an optimization, but . requires one consultation to an index to see if resolves to a verkey, or if it should be interpreted as a verkey. This is pretty mild, but in the minds of consumers, it seems like we should be able to tell a simpler story "it is an opaque key" or "it is a verkey" - and if "it is an opaque key" then why add the logic to "autoguess it"- what is the use case for that?

gudkov (Tue, 12 Sep 2017 06:37:24 GMT):
The main difference between indy_create_and_store_my_did and indy_replace_keys is that indy_create_and_store_my_did can generate new DID and additional settings are related to DID generation format as ledger supports multiple options (it is related to saving ledger space): - NYM can use full verkeys as DID - it is CID form - NYM can use half of verkeys as DID. - NYM can use verkey that isn't relted to DID. Any key rotation will cause this.

gudkov (Tue, 12 Sep 2017 06:41:07 GMT):
Current implementation of relace_keys have problems as it doesn't allow atomic wallet/ledger transaction and will be changed soon. See https://jira.hyperledger.org/browse/IS-319

srottem (Tue, 12 Sep 2017 11:35:02 GMT):
Is it expected behavior that calling indy_agent_close_connection or indy_agent_close_listener should error with a 113 (CommonInvalidStructure)? I would have expected a specific error code indicating an invalid handle such as when attempting to close an already closed wallet.

gudkov (Tue, 12 Sep 2017 12:11:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=94DAFsZzqzBrgKwzw) @srottem Could you describe your case?

srottem (Tue, 12 Sep 2017 12:15:40 GMT):
It's not really a use case, more an issue of how clear errors are. If I call indy_close_wallet with an handle that does not correspond to an open wallet then I'll get a WalletInvalidHandle error (200). On the other hand, if I call indy_agent_close_connection with a handle that does not correspond to an open connection then I get a CommonInvalidStructure error (113). The latter doesn't seem very descriptive of what has gone wrong. I'm just wondering if this is intentional.

gudkov (Tue, 12 Sep 2017 12:24:12 GMT):
CommonInvalidStructure means that some passed complex primitive has unexpected structure. Like, claim json or crypto key. For your case, it is better to have dedicated error. Or may provide generic INVALID_HANDLE error code and use it for all similar cases. It would be nice if you log bug/enhancement ticket about this.

srottem (Tue, 12 Sep 2017 12:25:23 GMT):
OK. Since the intention is that a more specific message should be present I'll open a ticket.

sklump (Tue, 12 Sep 2017 17:46:10 GMT):
I haven't been able to get the indy-sdk anoncreds cargo tests to pass (I'm using the docker network configuration, but anoncreds shouldn't care). Out of the box, after following the build instructions: ``` $ git clone https://github.com/hyperledger/indy-sdk.git $ cd indy-sdk/libindy $ cargo build ``` _(so far, so good)_ ``` $ cd .. $ docker network create --subnet 10.0.0.0/8 indy_pool_network $ docker build --build-arg pool_ip=10.0.0.2 -f ci/indy-pool.dockerfile -t indy_pool . $ docker run -d --ip="10.0.0.2" --net=indy_pool_network indy_pool $ cd libindy $ RUST_TEST_THREADS=1 TEST_POOL_IP=10.0.0.2 cargo test --test anoncreds ``` produces output ``` ... running 88 tests test demos::anoncreds_works_for_claim_revoked_after_proof_created ... INFO|command_executor | src/commands/mod.rs:68 | Worker thread started INFO|command_executor | src/commands/mod.rs:107 | WalletCommand command received ... INFO|prover_command_executor | src/commands/anoncreds/prover.rs:118 | StoreClaim command received INFO|anoncreds_service | src/services/anoncreds/prover.rs:71 | Prover process received claim -> start FAILED test demos::anoncreds_works_for_claim_revoked_before_proof_created ... INFO|anoncreds_service | src/services/anoncreds/prover.rs:85 | Prover process received claim -> done ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid library state: Unexpected SQLite error: no such table: wallet thread '' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', /checkout/src/libcore/result.rs:860:4 FAILED ``` I don't like the look of the `Unexpected SQLite error: no such table: wallet` - any ideas or updates pending to build instructions? I'd be happy to generate and attach whatever logs anyone might require.

sklump (Tue, 12 Sep 2017 17:46:10 GMT):
I haven't been able to get the indy-sdk anoncreds cargo tests to pass (I'm using the docker network configuration, but anoncreds shouldn't care). Out of the box, after following the build instructions: ``` $ git clone https://github.com/hyperledger/indy-sdk.git $ cd indy-sdk/libindy $ cargo build ``` _(so far, so good)_ ``` $ cd .. $ docker network create --subnet 10.0.0.0/8 indy_pool_network $ docker build --build-arg pool_ip=10.0.0.2 -f ci/indy-pool.dockerfile -t indy_pool . $ docker run -d --ip="10.0.0.2" --net=indy_pool_network indy_pool $ cd libindy $ RUST_TEST_THREADS=1 TEST_POOL_IP=10.0.0.2 cargo test --test anoncreds ``` produces output ``` ... running 88 tests test demos::anoncreds_works_for_claim_revoked_after_proof_created ... INFO|command_executor | src/commands/mod.rs:68 | Worker thread started INFO|command_executor | src/commands/mod.rs:107 | WalletCommand command received ... INFO|prover_command_executor | src/commands/anoncreds/prover.rs:118 | StoreClaim command received INFO|anoncreds_service | src/services/anoncreds/prover.rs:71 | Prover process received claim -> start FAILED test demos::anoncreds_works_for_claim_revoked_before_proof_created ... INFO|anoncreds_service | src/services/anoncreds/prover.rs:85 | Prover process received claim -> done ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid library state: Unexpected SQLite error: no such table: wallet thread '' panicked at 'called `Result::unwrap()` on an `Err` value: "SendError(..)"', /checkout/src/libcore/result.rs:860:4 FAILED ... ``` I don't like the look of the `Unexpected SQLite error: no such table: wallet` - any ideas or updates pending to build instructions? I'd be happy to generate and attach whatever logs anyone might require.

gudkov (Wed, 13 Sep 2017 07:05:32 GMT):
@sklump Will try the same on my side. "Unexpected SQLite error: no such table: wallet" most probably means that RUST_TEST_THREADS=1 don't work for you. Some test thread performed storage cleanup during execution of another test.

sklump (Wed, 13 Sep 2017 11:48:19 GMT):
The python wrapper tests run fine, even from a python3.5 virtual environment: `(py35) sklump@.../indy-sdk/wrappers/python/tests$ LD_LIBRARY_PATH=.../libindy/target/debug TEST_POOL_IP=10.0.0.2 pytest -s` ... `======================================= 160 passed, 1 skipped in 233.75 seconds ========================================`

sklump (Wed, 13 Sep 2017 11:48:19 GMT):
The python wrapper tests run fine, even from a python3.5 virtual environment: `(py35) sklump@.../indy-sdk/wrappers/python/tests$ LD_LIBRARY_PATH=.../libindy/target/debug TEST_POOL_IP=10.0.0.2 pytest -s` produces ``` ... ======================================= 160 passed, 1 skipped in 233.75 seconds ======================================== ```

sklump (Wed, 13 Sep 2017 11:48:19 GMT):
The python wrapper tests run fine, even from a python3.5 virtual environment; i.e.,: `(py35) sklump@.../indy-sdk/wrappers/python/tests$ LD_LIBRARY_PATH=.../libindy/target/debug TEST_POOL_IP=10.0.0.2 pytest -s` produces ``` ... ======================================= 160 passed, 1 skipped in 233.75 seconds ======================================== ```

sklump (Wed, 13 Sep 2017 11:48:19 GMT):
_In case it might be germane_, the python wrapper tests run fine, even from a python3.5 virtual environment; i.e.,: `(py35) sklump@.../indy-sdk/wrappers/python/tests$ LD_LIBRARY_PATH=.../libindy/target/debug TEST_POOL_IP=10.0.0.2 pytest -s` produces ``` ... ======================================= 160 passed, 1 skipped in 233.75 seconds ======================================== ```

sklump (Wed, 13 Sep 2017 11:48:19 GMT):
Taking out the `RUST_TEST_THREADS=1` does not change the outcome. Curiously, the python wrapper tests run fine, even from a python3.5 virtual environment; i.e.,: `(py35) sklump@.../indy-sdk/wrappers/python/tests$ LD_LIBRARY_PATH=.../libindy/target/debug TEST_POOL_IP=10.0.0.2 pytest -s` produces ``` ... ======================================= 160 passed, 1 skipped in 233.75 seconds ======================================== ```

sklump (Wed, 13 Sep 2017 11:48:19 GMT):
Taking out the `RUST_TEST_THREADS=1` does not change the outcome. Curiously, the python wrapper tests run fine, even from a python3.5 virtual environment (so kudos for that upgrade); i.e.,: `(py35) sklump@.../indy-sdk/wrappers/python/tests$ LD_LIBRARY_PATH=.../libindy/target/debug TEST_POOL_IP=10.0.0.2 pytest -s` produces ``` ... ======================================= 160 passed, 1 skipped in 233.75 seconds ======================================== ```

gudkov (Wed, 13 Sep 2017 14:13:34 GMT):
> Taking out the `RUST_TEST_THREADS=1 So you have to keep this variable. Please make sure that cargo process has access this variable. Python executes tests in a serialized way and currently, it is required for rust tests too.

sklump (Wed, 13 Sep 2017 15:04:12 GMT):
The cargo process definitely has access to RUST_TEST_THREADS=1; I've exported it from the shell.

mhailstone (Wed, 13 Sep 2017 17:22:51 GMT):
Is there a how-to guide in creating and consuming a verifiable claim in an client/agent?

Audrius (Wed, 13 Sep 2017 19:34:53 GMT):
Has joined the channel.

sergey.minaev (Thu, 14 Sep 2017 07:23:36 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done Tuesday and Wednesday Next sprint planning IS-328 CD pipeline for Indy Crypto (done, except publishing to Cargo) IS-316 debug interoperability indy-sdk and indy-node with state proofs. As for now checking state proofs works for GET_ATTRIB, GET_SCHEMA and GET_CLAIMDEF responses. GET_NYM support is waiting indy-node part.

srottem (Thu, 14 Sep 2017 09:29:48 GMT):
I'm getting a bunch of errors when trying to run 'cargo build' on master - 'error: associated constants are experimental (see issue #29646)'. Any ideas?

gudkov (Thu, 14 Sep 2017 12:26:38 GMT):
@srottem update rust to 1.20

srottem (Thu, 14 Sep 2017 12:58:40 GMT):
Thanks.

srottem (Fri, 15 Sep 2017 11:57:36 GMT):
it doesn't appear that the SDK provides any mechanism to determine whether or not a wallet or pool configuration already exists so it's not possible to determine whether or not it is appropriate to try to delete it. The error code thrown by attempting to delete a wallet or pool config that does not exist is CommonIOError (114) which is not very informative. I see a few options here; 1) improve the error code to be more specific, 2) don't error when attempting to delete something that does not exist, 3) provide a method to determine whether or not a wallet or pool config exists by name. Thoughts?

srottem (Fri, 15 Sep 2017 12:08:55 GMT):
From an implementers point of view my thinking is that a combination of 1 and 3 would be ideal (fail if specific error is returned or avoid failure by checking for existence first).

gudkov (Fri, 15 Sep 2017 12:33:44 GMT):
@srottem I added you to our email discussion about this problem.

srottem (Fri, 15 Sep 2017 12:33:58 GMT):
Thanks.

gudkov (Fri, 15 Sep 2017 12:36:32 GMT):
Actually, create returns a correct error code if wallet exists already. It can be enough for the most of the use cases. But adding of a dedicated method for this checking looks reasonable for me too.

srottem (Fri, 15 Sep 2017 12:39:42 GMT):
The issue I ran into was in the event of an application failure after creating a pool config where the deletion of that config doesn't take place. Running the application again results in a failure when attempting to create the pool config again because it already exists. The only real workaround is to either try the create or delete action, catch the error if one is raised then move on. From a .NET wrapper point of view using exception handling here is a pretty kludgy approach, hence my proposal. (same goes for wallets, of course).

gudkov (Fri, 15 Sep 2017 13:30:29 GMT):
I suggest the following: - Alway perfrom create and check for ALREADY_EXISTS error code and consider it as positive case

srottem (Fri, 15 Sep 2017 14:04:14 GMT):
It's certainly possible to do this, however it's pretty inelegant for async code in .NET as there's a lot of handling to do with async exceptions: https://gist.github.com/srottem/4caa63877a19c85661f1b1d7df5ce366

gudkov (Fri, 15 Sep 2017 14:35:46 GMT):
It looks uggly... hm...

gudkov (Fri, 15 Sep 2017 14:36:37 GMT):
Actually there are some errors that require recovering code from user anyway.

sergey.minaev (Fri, 15 Sep 2017 15:29:10 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done Thursday and Friday Sprint planning, estimation, backlog grooming IS-347 fixed in indy-sdk IS-316 Clean-up parsing nodes reply for proof, finish debug for GET_ atrib, claim def and schema. Implement workaround for GET_NYM Fixes in Indy Crypto (BLS API) Tests for registerWalletType (iOS)

srottem (Sat, 16 Sep 2017 09:06:11 GMT):
I'd like to start publishing pre-release versions of the NuGet package for the .NET wrapper - is this something I can do for the team? Is there a specific account on nuget.org that I can use?

peacekeeper (Mon, 18 Sep 2017 11:38:41 GMT):
What's the recommended version of indy-sdk to be used with the Sovrin Provisional Network?

gudkov (Mon, 18 Sep 2017 13:05:14 GMT):
Latest stable version

peacekeeper (Mon, 18 Sep 2017 13:24:09 GMT):
you mean the v1.0.0 tag ?

gudkov (Mon, 18 Sep 2017 13:57:10 GMT):
Yes, v1.0.0

peacekeeper (Mon, 18 Sep 2017 14:41:22 GMT):
hmm i keep getting this error when trying to connect to the provisional network: https://pastebin.com/F4hvKcjR

gudkov (Mon, 18 Sep 2017 14:50:06 GMT):
Do you know what the node version is used for Sovrin Provisional Network now? It can still have the version that isn't supported by the first Indy SDK release.

peacekeeper (Mon, 18 Sep 2017 14:52:01 GMT):
my node is running indy-node 1.0.28

peacekeeper (Mon, 18 Sep 2017 14:52:18 GMT):
i wonder which indy-sdk version (commit # ?) could be used to talk to it

mgbailey (Mon, 18 Sep 2017 15:04:58 GMT):
We plan to issue a transaction to the ledger early this week to upgrade provisional to 1.1.37. Meanwhile, provisional is currrently lagging the current stable significantly.

gudkov (Mon, 18 Sep 2017 15:10:03 GMT):
@peacekeeper I suggest to wait for 1.1.37 that was tested with Indy SDK 1.0.0. As workaraund you can look to commits about month ago.

peacekeeper (Mon, 18 Sep 2017 15:10:29 GMT):
ok i understand. yes i think i still have an older indy-sdk binary i can use.

gudkov (Mon, 18 Sep 2017 15:12:05 GMT):
Compatibility was broken by chaning serialization approach between node 1.0.28 and 1.1.37. We can find corresponded PRs to Indy SDK and find latest compatible commit.

peacekeeper (Mon, 18 Sep 2017 15:20:47 GMT):
no need, thanks

sklump (Tue, 19 Sep 2017 16:19:27 GMT):
Hello, I notice there are a few calls implementing DDO logic in the rust source, but nothing in the python wrapper using it. Is the DID:DDO mapping an internal feature purposefully encapsulated, or is it intended to be a future feature?

gudkov (Wed, 20 Sep 2017 07:52:22 GMT):
There is no DDO support on node side and no public C API and corresponded wrappers. As soon as node will support DDO corresponded APIs will be provided to all sdk artifacts.

gudkov (Wed, 20 Sep 2017 07:52:22 GMT):
There is no DDO support on node side and no public C API and corresponded wrappers for current moment. As soon as node will support DDO corresponded APIs will be provided to all sdk artifacts.

nage (Wed, 20 Sep 2017 12:59:19 GMT):
@sklump the current code pre-dates the DID spec. Essentially we're using the NYM as the DID and the attributes as the critical data elements of the DID. There are tickets to switch to proper DID spec formatted responses.

Captain63Dragon (Wed, 20 Sep 2017 16:29:05 GMT):
I got most of the way through running the Python samples. Execution hung up on the Ledger.py code. Can anyone tell me if the .indy directory is part of Indy-sdk or if it is created by the sample code? I'd like to removed the entire directory to see it fixes the error.

sklump (Wed, 20 Sep 2017 19:44:47 GMT):
It's created by the sample code, in /tmp, to store particulars of the node pool.

Captain63Dragon (Wed, 20 Sep 2017 20:10:13 GMT):
That's what I thought. Mine isn't in /tmp though, it is in the root of the indy clone

mgbailey (Wed, 20 Sep 2017 22:33:41 GMT):
It is made in your home directory. You can "rm -r ~/.indy/*" for a clean restart

srottem (Thu, 21 Sep 2017 09:27:12 GMT):
PR with various .NET packaging, documentation and API fixes: https://github.com/hyperledger/indy-sdk/pull/272

srottem (Thu, 21 Sep 2017 09:32:43 GMT):
PR implementing granular exceptions in .NET wrapper: https://github.com/hyperledger/indy-sdk/pull/273

sklump (Thu, 21 Sep 2017 12:40:08 GMT):
Hi folks, it appears that the agent::Endpoint structure comprises keys `ha` and `verkey`. However, the value for the `verkey` in the structure is not a verification key but a derived public (encryption) key. Do I have this right?

sklump (Thu, 21 Sep 2017 12:40:08 GMT):
Hi folks, it appears that the `agent::Endpoint` structure comprises keys `ha` and `verkey`. However, the value for the `verkey` in the structure is not a verification key but a derived public (encryption) key -- at least in `tests/demo/test_agent.py`. Do I have this right? Specifying the verification key value throws the test into an apparently infinite loop that outputs `CURVE I: public key not found`.

sklump (Thu, 21 Sep 2017 12:40:08 GMT):
Hi folks, it appears that the `agent::Endpoint` structure comprises keys `ha` and `verkey`. However, the value for the `verkey` in the structure is not a verification key but a derived public (encryption) key -- at least in `tests/demo/test_agent.py`.Do I have this right? _(Specifying the verification key value throws the test into an apparently infinite loop that outputs `CURVE I: public key not found`.)_

sklump (Thu, 21 Sep 2017 12:40:08 GMT):
Hi folks, it appears that the `agent::Endpoint` structure comprises keys `ha` and `verkey`. However, the value for the `verkey` in the structure is not a verification key but a derived public (encryption) key -- at least in `tests/demo/test_agent.py`.Do I have this right? _(Specifying the verification key value throws the test into an apparently infinite loop that outputs_ `CURVE I: public key not found` _.)_

srottem (Thu, 21 Sep 2017 12:41:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=DmqcfGy5ZXEtkQnhW) @sklump to the indy-sdk channel.

srottem (Thu, 21 Sep 2017 12:41:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=DmqcfGy5ZXEtkQnhW) @sklump Probably better to post this to the indy-sdk channel.

srottem (Thu, 21 Sep 2017 12:41:42 GMT):
My fault - ignore me.

gudkov (Thu, 21 Sep 2017 15:17:03 GMT):
libindy now use ~/.indy_client/ as root folder instead of ~/.indy/ to don't share the same folder with Indy Node

danconway (Fri, 22 Sep 2017 17:43:00 GMT):
Has joined the channel.

sklump (Fri, 22 Sep 2017 18:03:41 GMT):
In `services/anoncreds/helpers.rs`, function `four_squares` is naive. It fails to find Lagrange 4-square decomposition of some small numbers such as 211 or 1506099439. A greedy algorithm here is not sufficient IMO? Since the 'GE' predicate proving function cannot know in advance what the comparison value is, the delta can always fall on an unlucky number for which the greedy algorithm does not work. Admittedly, the numbers in play are staggering in size, so the proper way to do this might take considerable run time. If the greedy algorithm is provably guaranteed to work for all expected inputs, I have to come back to my ancient question of how to encode attribute values to guarantee they won't blow up the four-square decomposition algorithm. _interesting-yet-probably-boring: From function `_attribute_satisfy_predicate` in `services/anoncreds/prover.rs`, I see that an attribute value has to encode to a 32-bit integer to be considered in a 'GE' comparison._

sklump (Fri, 22 Sep 2017 18:03:41 GMT):
In `services/anoncreds/helpers.rs`, function `four_squares` is naive. It fails to find Lagrange 4-square decomposition of some small numbers such as 211 or 1506099439. A greedy algorithm here is not sufficient IMO? Since the 'GE' predicate proving function cannot know in advance what the comparison value is, the delta can always fall on an unlucky number for which the greedy algorithm does not work. Admittedly, the numbers in play are staggering in size, so a robust 4-square decomposition could take considerable run time. If the greedy algorithm is provably guaranteed to work for all expected inputs, I have to come back to my ancient question of how to encode attribute values to guarantee they won't blow up the four-square decomposition algorithm. _interesting-yet-probably-boring: From function `_attribute_satisfy_predicate` in `services/anoncreds/prover.rs`, I see that an attribute value has to encode to a 32-bit integer to be considered in a 'GE' comparison._

sklump (Fri, 22 Sep 2017 18:03:41 GMT):
In `services/anoncreds/helpers.rs`, function `four_squares` is naive. It fails to find Lagrange 4-square decomposition of some small numbers such as 211 or 1506099439. A greedy algorithm here is not sufficient IMO? Since the 'GE' predicate proving function cannot know in advance what the comparison value is, the delta can always fall on an unlucky number for which the greedy algorithm does not work. Admittedly, the numbers in play are staggering in size, so a robust 4-square decomposition could take considerable run time. If the greedy algorithm is provably guaranteed to work for all expected inputs, I have to come back to my ancient question of how to encode attribute values to guarantee they won't blow up the four-square decomposition algorithm. _Interesting-yet-probably-boring: From function _`_attribute_satisfy_predicate`_ in _`services/anoncreds/prover.rs`_, I see that an attribute value has to encode to a 32-bit integer to be considered in a 'GE' comparison, so if this restriction remains, it mitigates the upper bound in run time for any 4-square decomposition -- but it still could be a long wait for, for example, an EPOCH time._

sklump (Fri, 22 Sep 2017 18:03:41 GMT):
In `services/anoncreds/helpers.rs`, function `four_squares` is naive. It fails to find Lagrange 4-square decomposition of some small numbers such as 211 or 1506099439. A greedy algorithm here is not sufficient IMO? Since the 'GE' predicate proving function cannot know in advance what the comparison value is, the delta can always fall on an unlucky number for which the greedy algorithm does not work. Admittedly, the numbers in play are staggering in size, so a robust 4-square decomposition could take considerable run time. _Interesting-yet-probably-boring: From function `_attribute_satisfy_predicate` in `services/anoncreds/prover.rs`, I see that an attribute value has to encode to a 32-bit integer to be considered in a 'GE' comparison, so if this restriction remains, it mitigates the upper bound in run time for any 4-square decomposition -- but it still could be a long wait for, for example, an EPOCH time._ If the greedy algorithm is provably guaranteed to work for all expected inputs, I have to come back to my ancient question of how to encode attribute values to guarantee they won't blow up the four-square decomposition algorithm.

sklump (Fri, 22 Sep 2017 18:03:41 GMT):
In `services/anoncreds/helpers.rs`, function `four_squares` is naive. It fails to find Lagrange 4-square decomposition of some small numbers such as 211 or 1506099439. A greedy algorithm here is not sufficient IMO? Since the 'GE' predicate proving function cannot know in advance what the comparison value is, the delta can always fall on an unlucky number for which the greedy algorithm does not work. Admittedly, the numbers in play are staggering in size, so a robust 4-square decomposition could take considerable run time. _Interesting-yet-probably-boring: From function `_attribute_satisfy_predicate` in `services/anoncreds/prover.rs`, I see that an attribute value has to encode to a 32-bit integer to be considered in a 'GE' comparison, so if this restriction remains, it mitigates the upper bound in run time for any 4-square decomposition -- but it still could be a long wait for, for example, an EPOCH time._ If the greedy algorithm is provably guaranteed to work for all expected inputs, I have to come back to my ancient question of how to encode attribute values -- in particular, this time, to guarantee that they won't blow up the four-square decomposition algorithm.

sklump (Mon, 25 Sep 2017 00:44:02 GMT):
... I see a pretty good solution I could reasonably write up in Rust and submit via PR, tomorrow-ish.

ashcherbakov (Mon, 25 Sep 2017 12:38:45 GMT):
Hello @sklump Thank you for noticing this. We are already aware of the problem and fixed it in the following PR: https://github.com/hyperledger/indy-sdk/pull/277

sklump (Mon, 25 Sep 2017 13:17:02 GMT):
Great, and it looks way more idiomatic than the my-first-rust effort that I was clobbering together :thumbsup:

sklump (Mon, 25 Sep 2017 14:30:27 GMT):
... there has got to be a way to speed this up. I don't know what makes it so much slower than a python implementation, but after a few iterations on an index candidate, it slows to about a second a trial (on my VM). For example, 1506099439 appears to be incredibly unlucky. A naive approach (4 nested iterations) appeared to be faster initially, but I was thrashing with the binding scopes. It was going to get ugly. I will keep pounding at it and suggest something if I get it to work and faster.

sklump (Mon, 25 Sep 2017 14:30:27 GMT):
... there has got to be a way to speed this up. I don't know what makes it so much slower than a python implementation, but after a few iterations on an index candidate, it slows to about a second a trial and even worse (on my VM). For example, 1506099439 appears to be incredibly unlucky. A naive approach (4 nested iterations) appeared to be faster initially, but I was thrashing with the binding scopes. It was going to get ugly. I will keep pounding at it and suggest something if I get it to work and faster.

sklump (Mon, 25 Sep 2017 14:30:27 GMT):
... there has got to be a way to speed this up. I don't know what makes it so much slower than a python implementation, but after a few iterations on an index candidate, it slows to way over a second a trial and even up to a minute (on my VM). For example, 1506099439 appears to be incredibly unlucky, so far the method is crawling along at 30 minutes and nowhere near a solution. A naive approach (4 nested iterations) appeared to be faster initially, but I was thrashing with the binding scopes. It was going to get ugly. I will keep pounding at it and suggest something if I get it to work and faster.

gudkov (Mon, 25 Sep 2017 15:28:08 GMT):
@sklump Did you try release build? Debug is much slover as Rust use a lot of runtime debug checks.

sklump (Mon, 25 Sep 2017 15:30:04 GMT):
Regardless, it's apples to apples if I am running it against my naive approach. Good tip though, worth a look.

sklump (Mon, 25 Sep 2017 17:38:37 GMT):
I have something I can keep around locally until PR#277 gets reflected in the master. I will submit a PR from that version, rather than having two PRs open at the same time against the same code.

tbrooke (Mon, 25 Sep 2017 18:34:44 GMT):
Has joined the channel.

sklump (Mon, 25 Sep 2017 20:12:41 GMT):
Gents, With a large (but still i32) number, I can get the four-square partition to come back nice and quick, but the prover.rs::_Init_ge_proof() routine only hangs shortly thereafter on this piece: ``` let t_delta = pk.z .exp(&BigNumber::from_dec(&delta.to_string())?, Some(&mut ctx))? .mul( &pk.s.mod_exp(&r_delta, &pk.n, Some(&mut ctx))?, Some(&mut ctx) )? .modulus(&pk.n, Some(&mut ctx))?; ``` I can't say that should be a surprise, once we are dealing with larger (say, over a billion) numbers. At this point I'm at an impasse on how to speed that up. For relatively humble installations, we may have to admit that GE proofs may not actually scale to 32 bits? I'm asking, not telling. _Update_: several hours later, the statement above throws `ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid structure: An OpenSSL error stack`

sklump (Mon, 25 Sep 2017 20:12:41 GMT):
Gents, With a large (but still i32) number, I can get the four-square partition to come back nice and quick, but the prover.rs::_Init_ge_proof() routine only hangs shortly thereafter on this piece: ``` let t_delta = pk.z .exp(&BigNumber::from_dec(&delta.to_string())?, Some(&mut ctx))? .mul( &pk.s.mod_exp(&r_delta, &pk.n, Some(&mut ctx))?, Some(&mut ctx) )? .modulus(&pk.n, Some(&mut ctx))?; ``` We can't say that should be a surprise, once we are dealing with larger (say, over a billion) numbers. The `pk` components in the operation above are on the order of 10^618, and `r_delta` ~ 10^641, with `delta` "large enough" (I've reduced delta to ~ 6 million and the numbers stay on the same order -- an exercise might be to see how low we have to push it to reduce the above to a tractable operation) At this point I'm at an impasse on how to speed that up. For relatively humble installations, we may have to admit that GE proofs may not actually scale to 32 bits? I'm asking, not telling. _Update_: several hours later, the statement above throws `ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid structure: An OpenSSL error stack`

sklump (Mon, 25 Sep 2017 20:12:41 GMT):
Gents, With a large (but still i32) number, I can get the four-square partition to come back nice and quick, but the prover.rs::_Init_ge_proof() routine only hangs shortly thereafter on this piece: ``` let t_delta = pk.z .exp(&BigNumber::from_dec(&delta.to_string())?, Some(&mut ctx))? .mul( &pk.s.mod_exp(&r_delta, &pk.n, Some(&mut ctx))?, Some(&mut ctx) )? .modulus(&pk.n, Some(&mut ctx))?; ``` We can't say that should be a surprise, once we are dealing with larger (say, over a billion) numbers. The `pk` components in the operation above are on the order of 10^618, and `r_delta` about 10^641, with `delta` "large enough" (I've reduced delta to about 6 million and the numbers stay on the same order -- an exercise might be to see how low we have to push it to reduce the above to a tractable operation). At this point I'm at an impasse on how to speed that up. For relatively humble installations, we may have to admit that GE proofs may not actually scale to 32 bits? I'm asking, not telling. _Update_: several hours later, the statement above throws `ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid structure: An OpenSSL error stack`

sklump (Mon, 25 Sep 2017 20:12:41 GMT):
Gents, With a large (but still i32) number, I can get the four-square partition to come back nice and quick, but the prover.rs::_Init_ge_proof() routine only hangs shortly thereafter on this piece: ``` let t_delta = pk.z .exp(&BigNumber::from_dec(&delta.to_string())?, Some(&mut ctx))? .mul( &pk.s.mod_exp(&r_delta, &pk.n, Some(&mut ctx))?, Some(&mut ctx) )? .modulus(&pk.n, Some(&mut ctx))?; ``` We can't say that should be a surprise, once we are dealing with larger numbers. The `pk` components in the operation above are on the order of 10^618, and `r_delta` about 10^641. At this point I'm at an impasse on how to speed that up. For relatively humble installations, we may have to admit that GE proofs may not actually scale to 32 bits? I'm asking, not telling. _Update_: several hours later, the statement above throws `ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid structure: An OpenSSL error stack`

bdot (Tue, 26 Sep 2017 13:40:33 GMT):
Hi Guys, indy-sdk doesn't seem to build on Ubuntu 16.04, error details below. Am I missing something? Thanks for your time. ``` dev@workstation:~/bdot/labs/sovrin/indy-sdk/libindy$ cargo build Compiling openssl-sys v0.9.16 Compiling indy-crypto v0.1.2 error: expected identifier, found keyword `type` --> /home/dev/.cargo/registry/src/github.com-1ecc6299db9ec823/indy-crypto-0.1.2/src/utils/ctypes.rs:30:19 | 30 | ($ptr:ident, $type:ty, $err:expr) => { | ^^^^ error: expected identifier, found keyword `type` --> /home/dev/.cargo/registry/src/github.com-1ecc6299db9ec823/indy-crypto-0.1.2/src/utils/ctypes.rs:35:21 | 35 | let $ptr: &$type = unsafe { &*($ptr as *const $type) };; | ^^^^ error: expected identifier, found keyword `type` --> /home/dev/.cargo/registry/src/github.com-1ecc6299db9ec823/indy-crypto-0.1.2/src/utils/ctypes.rs:35:56 | 35 | let $ptr: &$type = unsafe { &*($ptr as *const $type) };; | ^^^^ error: expected identifier, found keyword `type` --> /home/dev/.cargo/registry/src/github.com-1ecc6299db9ec823/indy-crypto-0.1.2/src/utils/ctypes.rs:40:37 | 40 | ($ptrs:ident, $ptrs_len:ident, $type:ty, $err1:expr, $err2:expr) => { | ^^^^ error: expected identifier, found keyword `type` --> /home/dev/.cargo/registry/src/github.com-1ecc6299db9ec823/indy-crypto-0.1.2/src/utils/ctypes.rs:49:26 | 49 | let $ptrs: Vec<&$type> = | ^^^^ error: expected identifier, found keyword `type` --> /home/dev/.cargo/registry/src/github.com-1ecc6299db9ec823/indy-crypto-0.1.2/src/utils/ctypes.rs:52:56 | 52 | .map(|ptr| unsafe { &*(*ptr as *const $type) }) | ^^^^ error: aborting due to 6 previous errors Build failed, waiting for other jobs to finish... error: use of unstable library feature 'process_abort' (see issue #37838) --> /home/dev/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-sys-0.9.16/src/ossl10x.rs:757:13 | 757 | process::abort(); | ^^^^^^^^^^^^^^ error: aborting due to previous error error: Could not compile `indy-crypto`. To learn more, run the command again with --verbose. ```

sklump (Tue, 26 Sep 2017 13:58:33 GMT):
Do you have rust 1.20 or higher? You can issue `rustup update` to update rust.

bdot (Tue, 26 Sep 2017 15:48:51 GMT):
@sklump my bad. You are right. Thanks for the hint.

bdot (Tue, 26 Sep 2017 16:13:05 GMT):
Another newbie question! Is there a java version of indy-sdk? Just curious

sklump (Tue, 26 Sep 2017 16:14:44 GMT):
Check libindy/wrappers/java

sklump (Tue, 26 Sep 2017 16:15:03 GMT):
It's a set of Java wrappers on the underlying SDK

sklump (Tue, 26 Sep 2017 16:15:38 GMT):
Also included: ios, dotnet, python wrappers.

bdot (Tue, 26 Sep 2017 19:43:25 GMT):
Aah, thanks @sklump

bdot (Tue, 26 Sep 2017 22:57:13 GMT):
Hi Guys, Thanks to @sklump we could successfully build the SDK on Ubuntu. But unfortunately this is failing on Mac. We are following these instructions https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md. Any idea if this is something to do with Mac OS version? We are on 10.11.x (El Capitan). Any hints are greatly appreciated. Thanks. Stack trace below ``` bdot-MacPro:libindy bdot$ cargo build Compiling libsodium-sys v0.0.14 Compiling openssl-sys v0.9.16 Compiling zmq-pw-sys v0.9.8 Compiling rusqlite v0.10.1 error: failed to run custom build command for `libsodium-sys v0.0.14` process didn't exit successfully: `/Volumes/d/bdot/java/labs/indy-sdk/libindy/target/debug/build/libsodium-sys-c34349471c02cc69/build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "Failed to run `\"pkg-config\" \"--libs\" \"--cflags\" \"libsodium\"`: No such file or directory (os error 2)"', src/libcore/result.rs:860:4 note: Run with `RUST_BACKTRACE=1` for a backtrace. warning: build failed, waiting for other jobs to finish... error: build failed ```

gudkov (Wed, 27 Sep 2017 08:29:34 GMT):
Are you sure you installed libsodium?

bdot (Wed, 27 Sep 2017 09:27:41 GMT):
Thanks @gudkov . Yes, it's installed already. Just following these instructions! https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md ``` $ brew install libsodium Updating Homebrew... Warning: libsodium 1.0.14 is already installed ```

bdot (Wed, 27 Sep 2017 09:31:36 GMT):
Issue is same on both master & 1.0.0

bdot (Wed, 27 Sep 2017 11:29:40 GMT):
``` brew install pkg-config ``` seems to solve the problem. Again this is working only on 1.0.0! Thanks to https://github.com/evernym/sovrin-client-rust/issues/84 fyi. @gudkov

gudkov (Wed, 27 Sep 2017 12:17:56 GMT):
Could you create the PR with updated instruction?

sklump (Wed, 27 Sep 2017 12:25:06 GMT):
Item. So I added the following (just before cleanup) to `wrappers/python/tests/demo/test_anoncreds.py` ... ``` # 9a. Verify refuse to verify anti-proof anti_proof = proof # shallow copy is fine here: not using proof again except as anti-proof eve = 'Eve' anti_proof['requested_proof']['revealed_attrs']['attr1_uuid'][1] = eve; anti_proof['requested_proof']['revealed_attrs']['attr1_uuid'][2] = '1139481716457488690172217916278103336'; assert eve == proof['requested_proof']['revealed_attrs']['attr1_uuid'][1] anti_proof_json = json.dumps(anti_proof) print('==== anti-proof: {}'.format(json.dumps(anti_proof, indent=4))) rc_anti_proof = await anoncreds.verifier_verify_proof( proof_req_json, anti_proof_json, schemas_json, claim_defs_json, revoc_regs_json) assert (rc_anti_proof == False) ``` ... mimicking a man in the middle fiddling with revealed attributes in a proof, and expecting to get a False back from the `anoncreds.verifier_verify_proof()` call. However, the call returns `True`. Is this expected behaviour? If so, how does the client detect tampering with the revealed attribute?

sklump (Wed, 27 Sep 2017 12:25:06 GMT):
Item. So I added the following (just before cleanup) to `wrappers/python/tests/demo/test_anoncreds.py` ... ``` # 9a. Verify refuse to verify anti-proof anti_proof = proof # shallow copy is fine here: not using proof again except as anti-proof eve = 'Eve' anti_proof['requested_proof']['revealed_attrs']['attr1_uuid'][1] = eve; anti_proof['requested_proof']['revealed_attrs']['attr1_uuid'][2] = '1139481716457488690172217916278103336'; assert eve == proof['requested_proof']['revealed_attrs']['attr1_uuid'][1] anti_proof_json = json.dumps(anti_proof) print('==== anti-proof: {}'.format(json.dumps(anti_proof, indent=4))) rc_anti_proof = await anoncreds.verifier_verify_proof( proof_req_json, anti_proof_json, schemas_json, claim_defs_json, revoc_regs_json) assert (rc_anti_proof == False) ``` ... mimicking a man in the middle fiddling with revealed attributes in a proof. I expected to get a False back from the `anoncreds.verifier_verify_proof()` call. However, the call returns `True`. Is this expected behaviour? If so, how does the client detect tampering with the revealed attribute?

sklump (Wed, 27 Sep 2017 12:25:06 GMT):
Item. So I added the following (just before cleanup) to `wrappers/python/tests/demo/test_anoncreds.py` ... ``` # 9a. Verify refuse to verify anti-proof anti_proof = proof # shallow copy is fine here: not using proof again except as anti-proof eve = 'Eve' anti_proof['requested_proof']['revealed_attrs']['attr1_uuid'][1] = eve; anti_proof['requested_proof']['revealed_attrs']['attr1_uuid'][2] = '1139481716457488690172217916278103336'; assert eve == proof['requested_proof']['revealed_attrs']['attr1_uuid'][1] anti_proof_json = json.dumps(anti_proof) print('==== anti-proof: {}'.format(json.dumps(anti_proof, indent=4))) rc_anti_proof = await anoncreds.verifier_verify_proof( proof_req_json, anti_proof_json, schemas_json, claim_defs_json, revoc_regs_json) assert (rc_anti_proof == False) ``` ... mimicking a man in the middle fiddling with revealed attributes in a proof. I expected to get `False` back from the `anoncreds.verifier_verify_proof()` call. However, the call returns `True`. Is this expected behaviour? If so, how does the client detect tampering with the revealed attribute?

darrell.odonnell (Wed, 27 Sep 2017 13:33:35 GMT):
@nage can you look at this please.

nage (Wed, 27 Sep 2017 13:37:00 GMT):
@ashcherbakov what do you think? ^^^

ashcherbakov (Wed, 27 Sep 2017 15:00:12 GMT):
Verification should return False in this case, the proof will not be valid Verification will be True only with correct values for revealed attributes. You can have a look at equations (36) and (40) in the paper?

ashcherbakov (Wed, 27 Sep 2017 15:01:07 GMT):
Moreover, I tried a simialr test in python anoncreds, and everything looks fine there. Ypu can replace 'Alex' with 'Alex11111' on line https://github.com/hyperledger/indy-anoncreds/blob/master/anoncreds/test/test_anoncred_usage.py#L55 and the test will fail.

ashcherbakov (Wed, 27 Sep 2017 15:01:27 GMT):
We will have a look why it doesn't work with Rust code

ashcherbakov (Wed, 27 Sep 2017 15:04:07 GMT):
We will have a look why it doesn't work in the code

ashcherbakov (Wed, 27 Sep 2017 15:18:51 GMT):
Ok, I got the issue. The attribute was changed incorrectly. In anoincreds protocol, an attribute needs to be present as 256-bit integer. So, each revealed attribute has two values: a string one ('Alex' or 'eve') and an intgere one (usually a hash). This is the integer value that is used in verification. But only a string value has been changed in the test above. As integer value is still valid (it's still a value for 'Alex'), the verification succeeds. Probably verification should check that a string revealed value corresponds to the intgere one, otherwise should return False for verification. ====> Everything is fine in anoncreds protocol and anoncreds math implementation. The only thing which is missing is checking that string representation of revealed value corresponds to the integer one. I will create a ticket for this check (this should not be very hard).

ashcherbakov (Wed, 27 Sep 2017 15:19:59 GMT):
For python implementation of anoncreds, one cane insert the following lines there https://github.com/hyperledger/indy-anoncreds/blob/master/anoncreds/test/test_anoncred_usage.py#L55 proof.proofs['1'].proof.primaryProof.eqProof.revealedAttrs['name'] = 1139481716457488690172217916278103336 proof.requestedProof.revealed_attrs['attr_uuid'][1] = 'eve' and make sure that the test will fail

bdot (Wed, 27 Sep 2017 15:22:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=rEvGLMS9Z6khh6BRj) @gudkov Will do

sklump (Wed, 27 Sep 2017 15:22:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wxMQc5HKnYMMb4Rz9) @ashcherbakov Not so: `anti_proof['requested_proof']['revealed_attrs']['attr1_uuid'][2] = '1139481716457488690172217916278103336';` replaces the former value of `'1139481716457488690172217916278103335'` for Alex.

ashcherbakov (Wed, 27 Sep 2017 15:24:39 GMT):
ok, I see. I tested it in python code only, and it works there (see a code above). We will create a ticket and have a look why it doesn't work in indy-sdk.

ashcherbakov (Wed, 27 Sep 2017 15:25:27 GMT):
@gudkov @Artemkaaas ^

sklump (Wed, 27 Sep 2017 15:42:55 GMT):
@ashcherbakov , I had thought the encoding from string to int was opaque to the indy-sdk, and relied only on convention? If not, is there a correct way to encode 'Alex' into '1139...3335' ?

darrell.odonnell (Wed, 27 Sep 2017 15:52:45 GMT):
that would certainly make sense at the SDK level (i.e. encoding strings into int) but perhaps there is a reason?

sklump (Wed, 27 Sep 2017 16:04:11 GMT):
I'd been using `int.from_bytes(binhex.b2a_hex(a.encode()), "big")`

sklump (Wed, 27 Sep 2017 16:04:11 GMT):
I'd been using `int.from_bytes(binhex.b2a_hex(a.encode()), "big")`, for most text

ashcherbakov (Wed, 27 Sep 2017 16:23:53 GMT):
FYI: created https://jira.hyperledger.org/browse/IS-358 to adress this issue.

ashcherbakov (Wed, 27 Sep 2017 16:24:31 GMT):
This transformation is not opaque in indy-anoncreds. I will check whether it's in indy-sdk and whether there is a reason for this.

ashcherbakov (Wed, 27 Sep 2017 16:30:15 GMT):
In principle, it's probably not an issue that transformation is opaque. I think it's assumed that we protect against man in the middle attack using agent-to-agent communication (signatures, authenticated encryption). Because if we transfer proofs with revelaed attributes as is, a man in the middle can replace not only revealed attributes, but also the whole proof, and the verifier may not even notice this (he gets a valid proof for attributes and schema, he's not aware that this is not a proof from a prover he asked for).

sklump (Wed, 27 Sep 2017 16:45:35 GMT):
While I have you here, @ashcherbakov, do you have any thoughts on this issue with GE predicate proofs I mentioned above: With a large (but still i32) number, I can get the four-square partition to come back nice and quick, but the prover.rs::_Init_ge_proof() routine only hangs shortly thereafter on this piece: ``` let t_delta = pk.z .exp(&BigNumber::from_dec(&delta.to_string())?, Some(&mut ctx))? .mul( &pk.s.mod_exp(&r_delta, &pk.n, Some(&mut ctx))?, Some(&mut ctx) )? .modulus(&pk.n, Some(&mut ctx))?; ``` We can't say that should be a surprise, once we are dealing with larger numbers. The `pk` components in the operation above are on the order of 10^618, and `r_delta` about 10^641. At this point I'm at an impasse on how to speed that up. For relatively humble installations, we may have to admit that GE proofs may not actually scale to 32 bits? I'm asking, not telling. _Update_: several hours later, the statement above throws `ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid structure: An OpenSSL error stack` ?

sklump (Wed, 27 Sep 2017 16:45:35 GMT):
While I have you here, @ashcherbakov, do you have any thoughts on this issue with GE predicate proofs I mentioned above: With a large (but still i32) number, ~I can get the four-square partition to come back~ the PR-277 implementation of the four-square partition comes back nice and quick, but the prover.rs::_Init_ge_proof() routine only hangs shortly thereafter on this piece: ``` let t_delta = pk.z .exp(&BigNumber::from_dec(&delta.to_string())?, Some(&mut ctx))? .mul( &pk.s.mod_exp(&r_delta, &pk.n, Some(&mut ctx))?, Some(&mut ctx) )? .modulus(&pk.n, Some(&mut ctx))?; ``` We can't say that should be a surprise, once we are dealing with larger numbers. The `pk` components in the operation above are on the order of 10^618, and `r_delta` about 10^641. At this point I'm at an impasse on how to speed that up. For relatively humble installations, we may have to admit that GE proofs may not actually scale to 32 bits? I'm asking, not telling. _Update_: several hours later, the statement above throws `ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid structure: An OpenSSL error stack` ?

ashcherbakov (Wed, 27 Sep 2017 16:50:29 GMT):
Looks like there are some restirctions on open ssl level. Can you please create a ticket, so we can investigate it more closely?

Artemkaaas (Thu, 28 Sep 2017 11:37:09 GMT):
Actually, equal proof verification works in indy-sdk correct too. In addition to changes: ``` anti_proof['requested_proof']['revealed_attrs']['attr1_uuid'][2] = '1139481716457488690172217916278103336'; ``` It's required to change encoded value and here too: ``` anti_proof['proofs'][claim_uuid]['proof']['primary_proof']['eq_proof']['revealed_attrs']['name'] = '1139481716457488690172217916278103336'; ``` and then we will get False. I have added checking that values are equals in both places in this PR https://github.com/hyperledger/indy-sdk/pull/284. But we still don't have any way to check received raw attribute values inside of `verify` function, because according to anoncreds api we receive raw and encoded values from the Issuer and don't know encoding algorithm. Maybe we need to change API for getting only raw values and after that encode them internally in Indy-sdk? (in this case may be problems with such data types as dates).

sklump (Thu, 28 Sep 2017 13:00:06 GMT):
... and also, integers? For example, age (years) and height (cm) in test_anoncreds.py are encoded to themselves where name and sex are encoded to giant numbers. How to tell the difference between a number (2 + 2 = 4) and a numeric string ('2' + '2' = '22') is not knowable.

sklump (Thu, 28 Sep 2017 13:05:28 GMT):
Do I dare bring up another thing? Sure. When I run `pytest` on `wrappers/python/tests/demo/test_anoncreds.py`, it throws ```FATAL: exception not rethrown Aborted (core dumped)``` on exit. Does anyone else get this? Not a top priority for the moment.

gudkov (Thu, 28 Sep 2017 15:55:16 GMT):
@sklump Do you use master or some PRs? In some PRs we are switching to new eliptic curve and it can be caused by this changes.

sklump (Thu, 28 Sep 2017 17:49:41 GMT):
I'm currently using the master (plus PR-277). It's only on exit -- I should build everything from fresh, then see what happens.

sklump (Thu, 28 Sep 2017 17:49:59 GMT):
It'll take maybe half an hour

ashcherbakov (Thu, 28 Sep 2017 17:54:32 GMT):
If libindy is installed in a docker, it may be that it was cached when building the image, so old version is still used. At least we faced such a problem with plenum/indy-node tests

sklump (Thu, 28 Sep 2017 18:01:13 GMT):
It runs just fine from a fresh build. I must have introduced something. Dang.

sklump (Fri, 29 Sep 2017 13:37:39 GMT):
Is anyone online and willing to chat with me about claim definitions vs claims?

srottem (Fri, 29 Sep 2017 13:38:46 GMT):
Not sure I'll be much help, but I'm here. What are you after?

sklump (Fri, 29 Sep 2017 13:43:02 GMT):
I'm looking at python/tests/ledger/test_submit_request.py and test_build_claim_def_txn.py. I see this: ``` data = { "primary": { "n": "1", "s": "2", "rms": "3", "r": { "name": "1" }, "rctxt": "1", "z": "1" } } ``` (that's the polite version, test_build_claim_def_txn.py) and I want to know how to generate the numbers here. Then I look at test_submit_request.py, and its giant magic numbers, and I wonder what the values in dict `claim_def['primary']['r']` mean. E.g., ``` "age": "15428480888651268593621235736458685943389726269437020388313417035842991073151072061010468945249435098482625869236498750525662874597991333642865524104221652457788998109101749530884821300954337535472137069380551054204373136155978715752232238326100335828797868667735730830741789880726890058203015780792583471770404478023662994191588489722949795849990796063953164194432710764145637578113087142419634074378464118254848566088943085760634805903735300398689750649630456000759025366784986694635635510206166144055869823907120081668956271923743188342071093889666111639924270726451727101864752767708690529389259470017692442002767",``` That looks like a claim to me, with an encoded age. Or does every claim have its own claim definition, 1-to-1 ?

sklump (Fri, 29 Sep 2017 13:44:20 GMT):
The medium-term goal, today, is to have one actor write a claim definition on the ledger, and then have another actor retrieve it by its DID + whatever other info (name, version, what-all)

srottem (Fri, 29 Sep 2017 13:49:54 GMT):
My understanding (hazy at best) is that a schema is defined first and is stored as the claim definition. After that any claim or claim request is created referencing the schema to which it conforms.

sklump (Fri, 29 Sep 2017 13:50:19 GMT):
Sure, the schema part is in hand.

sklump (Fri, 29 Sep 2017 13:50:27 GMT):
No magic required.

sklump (Fri, 29 Sep 2017 13:51:02 GMT):
``` "sex": "40646934914193532541511585946883243600955533193734077080129022860038019728021796610599139377923881754708640252789475144625086755150150612623804964347576907276705600241268266301487516824189453869193926251791711672689649199860304727280764676403810510047397326018392955950249975529169980045664874433828266623495515931483137318724210483205730962036282580749206735450480976847188040030165278917936054139926609849181885654646269083459580415131952938813839182742590617440550773580790446467896469090164142755499827316294406540664375065617280568303837662431668218593808092907551353093044984225946834165309588512359379032847125", ``` Alpha cryptographer magic required

srottem (Fri, 29 Sep 2017 13:51:30 GMT):
Yep. I think the magic values are generated when you create the claim using the indy_issuer_create_claim function.

sklump (Fri, 29 Sep 2017 13:51:58 GMT):
Interesting -- looking for that

srottem (Fri, 29 Sep 2017 13:56:44 GMT):
There's a pretty good runthough the the order in which the steps happen in samples\python\src\anoncreds.py if that helps.

sklump (Fri, 29 Sep 2017 13:57:51 GMT):
Thanks, I will look into that -- I'd deleted the samples since they appeared to be pretty much copies of the test cases and (at the time) they didn't compile against python 3.5.

srottem (Fri, 29 Sep 2017 13:58:21 GMT):
They are pretty much copies of the test cases, true.

srottem (Fri, 29 Sep 2017 13:58:57 GMT):
You could look at wrappers\python\tests\demo\anoncreds.py instead if you prefer.

srottem (Fri, 29 Sep 2017 13:58:57 GMT):
You could look at wrappers\python\tests\demo\test_anoncreds.py instead if you prefer.

sklump (Fri, 29 Sep 2017 13:59:09 GMT):
I see `issuer_create_and_store_claim_def` in anoncreds.py; it returns a claim definition. Maybe it has to go in the wallet first, then I can write it to the ledger.

sklump (Fri, 29 Sep 2017 13:59:41 GMT):
Can I reuse a claim definition for many similar claims, or does each claim need its own def?

sklump (Fri, 29 Sep 2017 14:00:02 GMT):
If each claim needs a distinct def, I have to argue to my side not to put them on the ledger.

srottem (Fri, 29 Sep 2017 14:00:37 GMT):
I think the definition is simply defining the schema for a claim, so as many claims as you like that match the schema can be generated. e.g. define the schema for a drivers license, then issue claims for all the drivers licenses you like.

srottem (Fri, 29 Sep 2017 14:00:37 GMT):
I think the definition is simply defining the schema for a claim, so as many claims as you like that match the schema can be generated. e.g. define the schema for a drivers licence, then issue claims for all the drivers licenses you like.

sklump (Fri, 29 Sep 2017 14:01:00 GMT):
Good, at least I had that part right

ashcherbakov (Fri, 29 Sep 2017 14:01:03 GMT):
One claim def can be used for many claims (claim definition defines keys)

srottem (Fri, 29 Sep 2017 14:02:29 GMT):
The definition is also used for claim requests - so you can request proofs for any issued claims that match specific schema.

srottem (Fri, 29 Sep 2017 14:02:38 GMT):
I think.

ashcherbakov (Fri, 29 Sep 2017 14:02:57 GMT):
SCHEMA defines what claim should contain (fields, attributes, types, etc.) CLAIM DEF defines how we create claims for this SCHEMA: keys, signature type (CL only now)

ashcherbakov (Fri, 29 Sep 2017 14:03:39 GMT):
SCHEMA is only for claims as of now, not for Proof requests. There should be a special schema for proof requests, but it doesn't exist yet

srottem (Fri, 29 Sep 2017 14:03:58 GMT):
Thanks for the clarification.

sklump (Fri, 29 Sep 2017 14:04:07 GMT):
That's a top-down view. I

sklump (Fri, 29 Sep 2017 14:04:07 GMT):
Thanks. In particular, `issuer_create_and_store_claim_def()` supplies the magic values for keys `claim_def['primary']` - `['n']` - `['s']` - `['rms']` - `['r']` - `[keys for keys in r]` - `['rctxt']` - `['z']` ? I'd love to understand what the encodings in `'r'` mean.

ashcherbakov (Fri, 29 Sep 2017 14:04:21 GMT):
so, we may have multiple CLAIM_DEFs for the same SCHEMA, and we can issue multiple claims for a CLAIM_DEF

ashcherbakov (Fri, 29 Sep 2017 14:04:55 GMT):
SCHEMA can be issued/created by one organization, while CLAIM DEF is created by issuers (can be another organization)

sklump (Fri, 29 Sep 2017 14:11:57 GMT):
Thanks. In particular, `issuer_create_and_store_claim_def()` supplies the magic values for keys `claim_def['primary']` - `['n']` - `['s']` - `['rms']` - `['r']`, `[keys for keys in r]` - `['rctxt']` - `['z']` ? I'd love to understand what the encodings in `'r'` mean.

sklump (Fri, 29 Sep 2017 14:33:10 GMT):
?

sklump (Fri, 29 Sep 2017 14:33:10 GMT):
I'm asking, not telling?

sklump (Fri, 29 Sep 2017 14:52:22 GMT):
So I get this schema back from the ledger ```

sklump (Fri, 29 Sep 2017 14:52:22 GMT):
So I get this schema back from the ledger ``` schema get from ledger returns { "data": { "attr_names": [ "vendor_code", "registration_epoch" ], "name": "supplier-registration", "version": "1.1", "origin": "8KdHV8WfUfC5wEouN7JJ7y" }, "seqNo": 85 } ``` (after I filter it for `seqNo` and `data`, maybe not necessary) assign it to `schema_json`, and I try to run ``` anoncreds.issuer_create_and_store_claim_def( wallet_handle, did, json.dumps(schema_json), 'CL', False) ``` and then out comes ``` ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid structure: Invalid schema json: missing field `keys` at line 1 column 162 ``` I imagine attr_names was called keys at some point recently. The sample code starts with pre-baked schema JSON, with `keys` where the schema from the ledger query has `attr_names`. For now I can force it.

sklump (Fri, 29 Sep 2017 14:52:22 GMT):
So I get this schema back from the ledger ``` schema get from ledger returns { "data": { "attr_names": [ "vendor_code", "registration_epoch" ], "name": "supplier-registration", "version": "1.1", "origin": "8KdHV8WfUfC5wEouN7JJ7y" }, "seqNo": 85 } ``` _(after I filter it for `seqNo` and `data`, maybe not necessary)_ assign it to `schema_json`, and I try to run ``` anoncreds.issuer_create_and_store_claim_def( wallet_handle, did, schema_json, 'CL', False) ``` and then out comes ``` ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid structure: Invalid schema json: missing field `keys` at line 1 column 162 ``` I imagine attr_names was called keys at some point recently. The sample code starts with pre-baked schema JSON, with `keys` where the schema from the ledger query has `attr_names`. For now I can force it.

sklump (Fri, 29 Sep 2017 14:52:22 GMT):
So I get this schema back from the ledger ``` schema get from ledger returns { "data": { "attr_names": [ "vendor_code", "registration_epoch" ], "name": "supplier-registration", "version": "1.1", "origin": "8KdHV8WfUfC5wEouN7JJ7y" }, "seqNo": 85 } ``` _(after I filter it for `seqNo` and `data`, maybe not necessary)_ assign it to `schema_json`, and I try to run ``` anoncreds.issuer_create_and_store_claim_def( wallet_handle, did, schema_json, 'CL', False) ``` and then out comes ``` ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid structure: Invalid schema json: missing field `keys` at line 1 column 162 ``` I imagine attr_names was called keys at some point recently. The sample code starts with pre-baked schema JSON, with `keys` where the schema from the ledger query has `attr_names`. For now I can force it and try again.

sklump (Fri, 29 Sep 2017 15:29:10 GMT):
... OK, from a schema, replacing `schema['data']['keys'] = schema['data'].pop('attr_names')` helps advance the state, and it generates all the magic values for me. That's actually a nice big win for the moment, thanks for your patience!

farskipper (Fri, 29 Sep 2017 17:21:32 GMT):
Has joined the channel.

sklump (Fri, 29 Sep 2017 17:54:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RFP5wvQuPiKH5taY2) OK, so I notice that in `indy/ledger.py`, ``` async def build_get_claim_def_txn(submitter_did: str, xref: int, signature_type: str, origin: str) -> str: ``` I deduce that for any schema there is exactly one claim definition possible. For example, suppose my schema has 2 `attr_name`s (`vendor_code`, `registration_epoch`) and I create a two claim_defs: - one on `vendor_code`, `registration_epoch` - another on `vendor_code` alone. I can craft and send these distinct claim defs to the ledger, but the prover can only ask for a claim_def based on the schema (since `ledger.build_get_claim_def_txn()` parameters come exclusively from the schema.

sklump (Fri, 29 Sep 2017 17:54:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RFP5wvQuPiKH5taY2) OK, so I notice that in `indy/ledger.py`, ``` async def build_get_claim_def_txn(submitter_did: str, xref: int, signature_type: str, origin: str) -> str: ``` I deduce that for any schema there is exactly one claim definition possible. For example, suppose my schema has 2 `attr_name`s ( `vendor_code`, `registration_epoch` ) and I create a two claim_defs: - one on `vendor_code`, `registration_epoch` - another on `vendor_code` alone. I can craft and send these distinct claim defs to the ledger, but the prover can only ask for a claim_def based on the schema (since `ledger.build_get_claim_def_txn()` parameters come exclusively from the schema. In the example above, the `ledger.submit_request()` comes back with both attributes. How could I ever retrieve my claim_def on `vendor_code` alone?

sklump (Fri, 29 Sep 2017 17:54:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RFP5wvQuPiKH5taY2) OK, so I notice that in `indy/ledger.py`, ``` async def build_get_claim_def_txn(submitter_did: str, xref: int, signature_type: str, origin: str) -> str: ``` I deduce that for any schema there is exactly one claim definition possible. For example, suppose my schema has 2 `attr_name`s ( `vendor_code`, `registration_epoch` ) and I create a two claim_defs: - one on `vendor_code`, `registration_epoch` - another on `vendor_code` alone. I can craft and send these distinct claim defs to the ledger, but the prover can only ask for a claim_def based on the schema (since `ledger.build_get_claim_def_txn()` parameters come exclusively from the schema). In the example above, the `ledger.submit_request()` comes back with both attributes. How could I ever retrieve my claim_def on `vendor_code` alone?

sklump (Fri, 29 Sep 2017 17:54:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RFP5wvQuPiKH5taY2) OK, so I notice that in `indy/ledger.py`, ``` async def build_get_claim_def_txn(submitter_did: str, xref: int, signature_type: str, origin: str) -> str: ``` I deduce that for any schema there is exactly one claim definition possible. For example, suppose my schema has 2 `attr_name`s, `vendor_code`, `registration_epoch` as above, and I create a two claim_defs: - one on `vendor_code`, `registration_epoch` - another on `vendor_code` alone. I can craft and send these distinct claim_defs to the ledger, but the prover can only ask for a claim_def based on the schema (since `ledger.build_get_claim_def_txn()` parameters come exclusively from the schema). In the example above, the `ledger.submit_request()` comes back with the claim_def both attributes. How could I ever retrieve my claim_def on `vendor_code` alone?

sklump (Fri, 29 Sep 2017 17:54:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RFP5wvQuPiKH5taY2) OK, so I notice that in `indy/ledger.py`, ``` async def build_get_claim_def_txn(submitter_did: str, xref: int, signature_type: str, origin: str) -> str: ``` I deduce that for any schema there is exactly one claim definition possible. For example, suppose my schema has 2 `attr_name`s, `vendor_code`, `registration_epoch` as above, and I create a two claim_defs: - one on `vendor_code`, `registration_epoch` - another on `vendor_code` alone. I can craft and send these distinct claim_defs to the ledger, but the prover can only ask for a claim_def based on the schema (since `ledger.build_get_claim_def_txn()` parameters come exclusively from the schema). In the example above, the `ledger.submit_request()` comes back with the claim_def having both attributes. How could I ever retrieve my claim_def on `vendor_code` alone?

sklump (Fri, 29 Sep 2017 17:54:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RFP5wvQuPiKH5taY2) OK, so I notice that in `indy/ledger.py`, ``` async def build_get_claim_def_txn(submitter_did: str, xref: int, signature_type: str, origin: str) -> str: ``` I deduce that for any schema, it is possible to get only one distinct claim definition from the ledger, no matter how many an application can write to it. For example, suppose my schema has 2 `attr_name`s, `vendor_code`, `registration_epoch` as above, and I create a two claim_defs: - one on `vendor_code`, `registration_epoch` - another on `vendor_code` alone. I can craft and send these distinct claim_defs to the ledger, but the prover can only ask for a claim_def based on the schema (since `ledger.build_get_claim_def_txn()` parameters come exclusively from the schema). In the example above, the `ledger.submit_request()` comes back with the claim_def having both attributes. How could I ever retrieve my claim_def on `vendor_code` alone?

sklump (Fri, 29 Sep 2017 17:54:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RFP5wvQuPiKH5taY2) OK, so I notice that in `indy/ledger.py`, ``` async def build_get_claim_def_txn(submitter_did: str, xref: int, signature_type: str, origin: str) -> str: ``` I deduce that for any schema, it is possible to get only one distinct claim definition from the ledger, no matter how many an application can write to it. For example, suppose my schema has attr_names `vendor_code` and `registration_epoch` as above, and I create two distinct claim_defs: - one on `vendor_code`, `registration_epoch` - another on `vendor_code` alone. I can craft and send these distinct claim_defs to the ledger, but the prover can only ask for a claim_def based on the schema (since `ledger.build_get_claim_def_txn()` parameters come exclusively from the schema). In the example above, the `ledger.submit_request()` comes back with the claim_def having both attributes. How could I ever retrieve my claim_def on `vendor_code` alone?

mzk-vct (Sun, 01 Oct 2017 12:16:19 GMT):
Has joined the channel.

gudkov (Mon, 02 Oct 2017 07:59:25 GMT):
@srottem Hi, The latest changes related to StateProofs most probably caused a regression in .Net wrapper tests. Genesis txns data must be changed and also some assumptions in tests are wrong now. Could you check this? Corresponded fixes to java and python wrapper you can find here: https://github.com/hyperledger/indy-sdk/pull/285

srottem (Mon, 02 Oct 2017 07:59:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=dCramtSEoqtJiqCo2) @gudkov Will od.

srottem (Mon, 02 Oct 2017 07:59:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=dCramtSEoqtJiqCo2) @gudkov Will do.

ashcherbakov (Mon, 02 Oct 2017 08:20:24 GMT):
@sklump Each CLAIM_DEF is identifier by two things: corresponding SCHEMA (schema_seq_no) and Claimn Def Issuer's DID. So, yes, as of now, in order to have multiple CLAIM_DEFs for the same SCHEMA, each CLAIM_DEF needs to be issued by a separate DID.

gudkov (Mon, 02 Oct 2017 09:28:49 GMT):
@srottem I created https://jira.hyperledger.org/browse/IS-363 about this.

sklump (Mon, 02 Oct 2017 13:32:39 GMT):
Hello, I'm trying to exercise `anoncreds.prover_get_claims_for_proof_req()`. I feed it the wallet handle and ``` proof_req_nonce = { 'nonce': nonce, 'name': 'proof_req_0', 'version': '0', 'requested_attrs': None, 'requested_predicates': None } ``` which `json.dumps()` encodes as `{"name": "proof_req_0", "nonce": "1506950257", "version": "0", "requested_attrs": null, "requested_predicates": null}`. The sdk comes back with `Casting error to ErrorCode: Invalid structure: Invalid proof_req_json: invalid type: string "{\"name\": \"proof_req_0\", \"nonce\": \"1506950257\", \"version\": \"0\", \"requested_attrs\": null, \"requested_predicates\": null}", expected struct ProofRequestJson at line 1 column 135` and `libindy/src/services/anoncreds/types.rs` defines `ProofRequestJson` as ``` pub struct ProofRequestJson { pub nonce: BigNumber, pub name: String, pub version: String, pub requested_attrs: HashMap, pub requested_predicates: HashMap } ``` Question: does order matter for the content of the JSON? _(I sure hope not)_ This is just the first (and I thought, easiest) among several such exercises to come, but I haven't been able to make it complete. Does anything jump out about what I am doing wrong here?

sklump (Mon, 02 Oct 2017 13:32:39 GMT):
Hello, I'm trying to exercise `anoncreds.prover_get_claims_for_proof_req()`. I feed it the wallet handle and ```proof_req_nonce = { 'nonce': nonce, 'name': 'proof_req_0', 'version': '0', 'requested_attrs': None, 'requested_predicates': None } ``` which `json.dumps()` encodes as `{"name": "proof_req_0", "nonce": "1506950257", "version": "0", "requested_attrs": null, "requested_predicates": null}`. The sdk comes back with `Casting error to ErrorCode: Invalid structure: Invalid proof_req_json: invalid type: string "{\"name\": \"proof_req_0\", \"nonce\": \"1506950257\", \"version\": \"0\", \"requested_attrs\": null, \"requested_predicates\": null}", expected struct ProofRequestJson at line 1 column 135` and `libindy/src/services/anoncreds/types.rs` defines `ProofRequestJson` as ```pub struct ProofRequestJson { pub nonce: BigNumber, pub name: String, pub version: String, pub requested_attrs: HashMap, pub requested_predicates: HashMap } ``` Question: does order matter for the content of the JSON? _(I sure hope not)_ This is just the first (and I thought, easiest) among several such exercises to come, but I haven't been able to make it complete. Does anything jump out about what I am doing wrong here?

srottem (Mon, 02 Oct 2017 13:47:26 GMT):
The structure passed to the equivalent call in the .NET wrapper is structured as follows ``` { "nonce":"123432421212", "name":"proof_req_1", "version":"0.1", "requested_attrs":{"attr1_uuid":{"schema_seq_no":1, "name":"name"}}, "requested_predicates":{} } ```

srottem (Mon, 02 Oct 2017 13:48:59 GMT):
Maybe the requested_attrs and requested_predicates can't be null?

sklump (Mon, 02 Oct 2017 13:50:25 GMT):
OMG the immediate problem is that I can't count to 2. It looks like I double-encoded it. Sorry. Sheesh.

sklump (Mon, 02 Oct 2017 13:54:12 GMT):
... and yes, `{}` is correct where `None` is not.

sklump (Tue, 03 Oct 2017 12:52:18 GMT):
Does any one have a sample code for a pair of agents: * one listening

sklump (Tue, 03 Oct 2017 12:52:18 GMT):
Does any one have a sample code for a pair of agents: * one listeningfsdf

sklump (Tue, 03 Oct 2017 12:52:18 GMT):
Does any one have a sample code for a pair of agents: * agent B listening * agent A connecting to it and sending it a message?

srottem (Tue, 03 Oct 2017 12:52:53 GMT):
There's some in the samples - you're after python?

sklump (Tue, 03 Oct 2017 12:53:46 GMT):
Yes - but they're all really on the same VM. I don't understand where the separation should lie. The omniscient example 'knows' what the listener and the connector both know.

sklump (Tue, 03 Oct 2017 12:54:21 GMT):
Any language will do. I'm just trying to get my head around the abstractions.

sklump (Tue, 03 Oct 2017 12:54:33 GMT):
(I'm a few layers above where I usually code)

srottem (Tue, 03 Oct 2017 13:00:14 GMT):
Most of the glue is provided by the ledger. A DID gets created for the listener and is stored with a DDO using an ATTRIB request that specifies the endpoint of the listener. The sender gets sent the listener's DID by the listener and then they can use the ledger to get the endpoint the listener is listening on.

srottem (Tue, 03 Oct 2017 13:00:56 GMT):
Of course, the listener also has to have the sender's DID to authorize connections from that sender.

srottem (Tue, 03 Oct 2017 13:02:46 GMT):
The agent demo code in the samples (or tests) isn't very long and outlines the steps including creating DIDs, storing them in the wallet, starting a listener and authorizing the sender identity then opening a sender to the listener and sending a message.

sklump (Tue, 03 Oct 2017 13:03:17 GMT):
Under #11 within test_agent.py, for example, then, `agent_wait_for_event([listener_handle])`, is on the listener side and the sender doesn't really have to wait for it to proceed?

srottem (Tue, 03 Oct 2017 13:04:59 GMT):
Ah - that's just about writing async code. If you implemented a listener you can start it and indicate that you want to wait for incoming connections but you're not obliged to block while waiting so your app can continue to function.

sklump (Tue, 03 Oct 2017 13:05:26 GMT):
Async still does my head in.

srottem (Tue, 03 Oct 2017 13:05:49 GMT):
Yeah, can be a bit on a mind-bender. I only just got my head around it in .NET.

sklump (Tue, 03 Oct 2017 13:06:37 GMT):
It looks like I'm going to have to spend some time on separating out the concerns into a server and a client. Part of the voyage of discovery.

srottem (Tue, 03 Oct 2017 13:06:50 GMT):
Indeed!

sklump (Tue, 03 Oct 2017 13:07:57 GMT):
It all makes sense from a high-level perspective, it's the details where I get a bit tangled up.

srottem (Tue, 03 Oct 2017 13:14:38 GMT):
As long as you have the basic steps - each party registers a DID/DDO. The parties then exchange DIDs. One party, the listener, will have to open their wallet, store the sender's DID then start a listener instance on the endpoint (the one specified when they set up their DID/DDO), add the sender identity to the listener instance (to authorize receiving connections from them) then wait for connections on the listener. The other party, the sender, will open their own wallet, store the listener's DID then open a connection specifying the listener's DID as the target and the sender's wallet that contains that DID. When the connection is being opened, in the background the wallet will be checked to get the endpoint for the listener's DID and if it's not there the ledger will be interrogated - once the endpoint is resolved then the sender's connection to the listener will be initiated.

srottem (Tue, 03 Oct 2017 13:15:45 GMT):
Of course, since it's all async there are points at which you will have to await the results - e.g. you don't actually get a connection handle until the async call to agent_connect completes.

srottem (Tue, 03 Oct 2017 13:16:33 GMT):
I'm pretty sure I've got that right - someone correct me if I'm off base.

sklump (Tue, 03 Oct 2017 13:18:16 GMT):
I'm not sure that the listener has to register the sender explicitly before accepting connections, but that's a tiny quibble easily checked. Thanks for this.

bdot (Tue, 03 Oct 2017 14:20:47 GMT):
Any idea, if Indy sdk samples use mock/test pool, referring to https://github.com/hyperledger/indy-sdk/blob/master/samples/java/src/main/java/Signus.java. For some reason, I don't seem to get past Pool.openPoolLedger(poolName, "{}").get(); And below trace appears on console. Thanks for your time. ``` Connected to the target VM, address: '127.0.0.1:20679', transport: 'socket' Ledger sample -> started INFO|command_executor | src/commands/mod.rs:68 | Worker thread started INFO|command_executor | src/commands/mod.rs:99 | PoolCommand command received INFO|pool_command_executor | src/commands/pool.rs:54 | Create command received INFO|command_executor | src/commands/mod.rs:99 | PoolCommand command received INFO|pool_command_executor | src/commands/pool.rs:62 | Open command received INFO|indy::services::pool | src/services/pool/mod.rs:555 | Sending "pi" INFO|indy::services::pool | src/services/pool/mod.rs:555 | Sending "pi" INFO|indy::services::pool | src/services/pool/mod.rs:555 | Sending "pi" INFO|indy::services::pool | src/services/pool/mod.rs:555 | Sending "pi" ```

mark.hadley (Tue, 03 Oct 2017 14:51:06 GMT):
I'm a bit out of the loop here, but I typically get this message when I dont have a pool up and running (for example the docker container indy_node). I dont believe that they have any functionality for mocking the nodes...yet. Let me know if I'm not addressing your question.

mark.hadley (Tue, 03 Oct 2017 14:51:06 GMT):
@bdot I'm a bit out of the loop here, but I typically get this message when I dont have a pool up and running (for example the docker container indy_node). I dont believe that they have any functionality for mocking the nodes...yet. Let me know if I'm not addressing your question.

mark.hadley (Tue, 03 Oct 2017 14:53:09 GMT):
Alos, when running tests through the java wrapper, sometimes you need to point your test to the IP of your pool (I set the environment variable TEST_POOL_IP=10.0.0.2)

mark.hadley (Tue, 03 Oct 2017 15:04:25 GMT):
@srottem [ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wc4h2Ti5JqWBw2NAe) @srottem When you say "The other party, the sender, will open their own wallet, store the listener's DID then open a connection specifying the listener's DID as the target and the sender's wallet that contains that DID." ... Can you please elaborate on what you mean by "...and the sender's wallet that contains that DID".

mark.hadley (Tue, 03 Oct 2017 15:04:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wc4h2Ti5JqWBw2NAe) @srottem When you say "The other party, the sender, will open their own wallet, store the listener's DID then open a connection specifying the listener's DID as the target and the sender's wallet that contains that DID." ... Can you please elaborate on what you mean by "...and the sender's wallet that contains that DID".

bdot (Tue, 03 Oct 2017 15:32:27 GMT):
@mark.hadley You are right. My bad, pool isn't running. Thanks for your help.

srottem (Tue, 03 Oct 2017 16:32:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5hSQS86HhbxGHnXPb) @mark.hadley Sure. The indy_agent_connect method expects a wallet handle, the sender's DID and the DID of the listener. The wallet handle provided to the method should be for an open wallet that has had the DID of the listener added to it previously using the indy_store_their_did method.

mark.hadley (Tue, 03 Oct 2017 16:36:29 GMT):
Gotcha, so a Sender needs two pieces of information: a DID for the listener, and also a correct wallet handle. This wallet handle is the wallet owned by the Listener that has been designated for dealing with that specific Sender.

sklump (Tue, 03 Oct 2017 17:50:36 GMT):
Since I downloaded a fresh copy of indy-sdk (both yesterday and today), the cargo tests don't pass anymore: ```test medium_cases::indy_agent_send::indy_agent_send_works_for_closed_listener_incoming_connection ... INFO|command_executor | src/commands/mod.rs:99 | PoolCommand command received INFO|pool_command_executor | src/commands/pool.rs:54 | Create command received INFO|command_executor | src/commands/mod.rs:99 | PoolCommand command received INFO|pool_command_executor | src/commands/pool.rs:62 | Open command received ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid Handle: Pool with same name already opened FAILED ``` I get a fair few of these 'Invalid Handle: Pool with same name already opened' failures. Could this be some kind of timing issue?

sklump (Tue, 03 Oct 2017 17:50:36 GMT):
Since I downloaded a fresh copy of indy-sdk (both yesterday and today), the cargo tests don't pass anymore: *`RUST_TEST_THREADS=1 TEST_POOL_IP=10.0.0.2 cargo test --test agent`* ```... test medium_cases::indy_agent_send::indy_agent_send_works_for_closed_listener_incoming_connection ... INFO|command_executor | src/commands/mod.rs:99 | PoolCommand command received INFO|pool_command_executor | src/commands/pool.rs:54 | Create command received INFO|command_executor | src/commands/mod.rs:99 | PoolCommand command received INFO|pool_command_executor | src/commands/pool.rs:62 | Open command received ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid Handle: Pool with same name already opened FAILED ... test result: FAILED. 39 passed; 17 failed; 1 ignored; 0 measured; 0 filtered out ``` I get a fair few of these 'Invalid Handle: Pool with same name already opened' failures. Could this be some kind of timing issue?

sklump (Tue, 03 Oct 2017 17:50:36 GMT):
Since I downloaded a fresh copy of indy-sdk (both yesterday and today), the cargo tests don't pass anymore: `$RUST_TEST_THREADS=1 TEST_POOL_IP=10.0.0.2 cargo test --test agent` ```... test medium_cases::indy_agent_send::indy_agent_send_works_for_closed_listener_incoming_connection ... INFO|command_executor | src/commands/mod.rs:99 | PoolCommand command received INFO|pool_command_executor | src/commands/pool.rs:54 | Create command received INFO|command_executor | src/commands/mod.rs:99 | PoolCommand command received INFO|pool_command_executor | src/commands/pool.rs:62 | Open command received ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid Handle: Pool with same name already opened FAILED ... test result: FAILED. 39 passed; 17 failed; 1 ignored; 0 measured; 0 filtered out ``` I get a fair few of these 'Invalid Handle: Pool with same name already opened' failures. Could this be some kind of timing issue?

sklump (Tue, 03 Oct 2017 17:50:36 GMT):
Since I downloaded a fresh copy of indy-sdk (both yesterday and today), the cargo tests don't pass anymore: `$ RUST_TEST_THREADS=1 TEST_POOL_IP=10.0.0.2 cargo test --test agent` ```... test medium_cases::indy_agent_send::indy_agent_send_works_for_closed_listener_incoming_connection ... INFO|command_executor | src/commands/mod.rs:99 | PoolCommand command received INFO|pool_command_executor | src/commands/pool.rs:54 | Create command received INFO|command_executor | src/commands/mod.rs:99 | PoolCommand command received INFO|pool_command_executor | src/commands/pool.rs:62 | Open command received ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid Handle: Pool with same name already opened FAILED ... test result: FAILED. 39 passed; 17 failed; 1 ignored; 0 measured; 0 filtered out ``` I get a fair few of these 'Invalid Handle: Pool with same name already opened' failures. Could this be some kind of timing issue?

mark.hadley (Tue, 03 Oct 2017 18:33:09 GMT):
I just pulled newest, loaded my node network, and ran the same command as you on my ubuntu machine and received all 56 tests passing. Then I turned off my indy_node docker container and ran the tests again, with the same command you gave, and had the same results you are displaying: 39 passed and 17 failing. So it feels like the tests are not getting to the network properly.

jljordan_bcgov (Tue, 03 Oct 2017 18:46:41 GMT):
sometimes I find docker leaves behind old images/containers or whatever and they need to be deleted and recreated ... I had weird behaviour like that with the Hyperledger Fabric demos

jljordan_bcgov (Tue, 03 Oct 2017 18:46:52 GMT):
kind brute force but seemed to work

darrell.odonnell (Tue, 03 Oct 2017 19:08:51 GMT):
yeah `Casting error to ErrorCode: Invalid Handle: Pool with same name already opened` looked to me like something is already running there

sklump (Tue, 03 Oct 2017 19:33:41 GMT):
Yes, I've been through that. I've stopped and removed all containers, even removed the images and pulled everything fresh from the Internet. I still don't know what I'm doing wrong. But the SDK from about a week ago passes all tests, so I'm staying on that one for now.

mark.hadley (Tue, 03 Oct 2017 19:41:35 GMT):
I think that error message occurs because you make the pool config, then the test errors, and never gets cleaned up and then runs into the next test.

sklump (Tue, 03 Oct 2017 19:46:33 GMT):
-> then the test errors <- Sure, it's probably a cascading failure -- I'd like it not to fail in the first place. -> you make the pool config <- What does this mean, in operations?

sklump (Tue, 03 Oct 2017 19:46:33 GMT):
-> then the test errors <- Sure, it's probably a cascading failure -- I'd like it not to fail in the first place. Maybe it would be better if I went back to the port-map configuration

srottem (Tue, 03 Oct 2017 19:51:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=zCfnnBcPXGTeiNJtZ) @mark.hadley Not quite - the sender is the owner of the wallet. The listener provides their DID to the sender (the mechanism for this exchange is not specified as part of the agent communications) and the sender stores it in a wallet they own using the indy_store_their_did method ('their', in this case meaning the listener). This is the wallet that the sender then uses with the indy_agent_connect method to initiate the connection.

mark.hadley (Tue, 03 Oct 2017 21:14:38 GMT):
@sklump I was wrong. I didnt pull the latest and now that I haven I'm getting the same test failings as you.

bryanhuang (Wed, 04 Oct 2017 02:40:57 GMT):
Has joined the channel.

sergey.minaev (Wed, 04 Oct 2017 07:00:58 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done Monday and Tuesday: IS-319 Completed for Libindy, Java and Python wrappers IS-362 Create new methods in signus for better pairwise support - in progress IS-356 New agent 2 agent design

sklump (Wed, 04 Oct 2017 11:13:26 GMT):
@mark.hadley I've submitted https://jira.hyperledger.org/browse/IS-367 to document this.

downTheFallLine (Wed, 04 Oct 2017 14:21:31 GMT):
Has joined the channel.

realisation (Wed, 04 Oct 2017 16:16:02 GMT):
Has joined the channel.

realisation (Wed, 04 Oct 2017 16:16:32 GMT):
Has there been any work on a node wrapping for indy sdk?

sklump (Thu, 05 Oct 2017 13:52:37 GMT):
The solution is to docker-(re)build the indy-pool node from from `ci/indy-pool.dockerfile`. [ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mmPJNmapRJmqK24mE)

realisation (Thu, 05 Oct 2017 14:26:28 GMT):
I just tried to compile on Mac and my build failed with `error: linking with `cc` failed: exit code: 1`

realisation (Thu, 05 Oct 2017 14:26:28 GMT):
I just tried to compile on Mac and my build failed with ```error: linking with `cc` failed: exit code: 1```

realisation (Thu, 05 Oct 2017 14:26:59 GMT):
there's an issue of this in the repository as of yesterday -- no one knows how to fix this do they?

gudkov (Thu, 05 Oct 2017 14:43:51 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=LGmQaNHNpFfJ9wjQD) @realisation You can use "rc" branch. Corresponded issue in our Jira https://jira.hyperledger.org/browse/IS-369

realisation (Thu, 05 Oct 2017 14:44:10 GMT):
Great, I'll give it a shot

realisation (Thu, 05 Oct 2017 14:44:12 GMT):
thnx

realisation (Thu, 05 Oct 2017 14:55:55 GMT):
Looks like I'm getting the same error

realisation (Thu, 05 Oct 2017 15:06:45 GMT):
``` = note: Undefined symbols for architecture x86_64: "_crypto_stream_aes128ctr_xor", referenced from: sodiumoxide::crypto::stream::aes128ctr::stream_xor::h3d312a390c2ce878 in libsodiumoxide-8d1bc5a32d6d16ed.rlib(sodiumoxide-8d1bc5a32d6d16ed.0.o) sodiumoxide::crypto::stream::aes128ctr::stream_xor_inplace::hde80960d3c81e790 in libsodiumoxide-8d1bc5a32d6d16ed.rlib(sodiumoxide-8d1bc5a32d6d16ed.0.o) "_crypto_stream_aes128ctr", referenced from: sodiumoxide::crypto::stream::aes128ctr::stream::hd4bc2460a71665ee in libsodiumoxide-8d1bc5a32d6d16ed.rlib(sodiumoxide-8d1bc5a32d6d16ed.0.o) ld: symbol(s) not found for architecture x86_64 ```

realisation (Thu, 05 Oct 2017 15:08:55 GMT):
it'd be great if I could get past this issue, though I'm not sure how to do it myself

realisation (Thu, 05 Oct 2017 15:09:10 GMT):
I'm at rebooting the web of trust and my goal was to write a node wrapper for the library

Ratnakar (Thu, 05 Oct 2017 15:31:52 GMT):
Has joined the channel.

gudkov (Thu, 05 Oct 2017 15:33:39 GMT):
seems you have no libsodium installed in your system

sklump (Thu, 05 Oct 2017 15:49:57 GMT):
Gents, I'm merging my code into the current indy-sdk build from a few weeks back, at most. The schema `s` that used to come from `ledger.build_get_schema_request()` included the originator's DID at `s['data']['origin']`. Now I see that `s['data']['origin']` is gone. However, the same DID looks like it appears in `s['identifier']` and in `s['dest']`. *Question 1:* What is the correct location within schema `s`, as retrieved from the ledger, for the DID of its issuer? *Question 2:* I thought that every schema has its own DID, independent of the issuer? If so, where should the schema's DID (as opposed to its issuer's) appear within the schema?

ashcherbakov (Thu, 05 Oct 2017 15:52:18 GMT):
No, Schema doesn't have a DID (there is only schema's issuer DID)

sklump (Thu, 05 Oct 2017 15:52:48 GMT):
Great, so I can use either `s['identifier']` or `s['dest']` ? Is one more canonical than the other?

ashcherbakov (Thu, 05 Oct 2017 15:54:21 GMT):
It should be s['identifier']`

sklump (Thu, 05 Oct 2017 15:54:31 GMT):
Great, thanks!

ashcherbakov (Thu, 05 Oct 2017 15:54:36 GMT):
Welcome!

realisation (Thu, 05 Oct 2017 21:04:26 GMT):
alrighty! got it compiled, in a docker container

realisation (Thu, 05 Oct 2017 21:04:30 GMT):
hacky but works

realisation (Thu, 05 Oct 2017 21:04:57 GMT):
now I may be pursuing this project in the near future

realisation (Thu, 05 Oct 2017 21:05:32 GMT):
it would be great if someone else was interested in making a node wrapping for indy sdk, who might be able to provide a little assistance w/r/t wrapping C libraries

gudkov (Fri, 06 Oct 2017 06:55:58 GMT):
@realisation There was some activity on nodejs wrapper. You can search this chat for "nodejs" keyword.

jamesmonaghan (Fri, 06 Oct 2017 10:49:53 GMT):
team, re https://github.com/hyperledger/indy-sdk/issues/281 are we expecting to be able to build in that environment?

gudkov (Fri, 06 Oct 2017 12:43:52 GMT):
Yes, It is planned to be fixed. For SDK users it is better now to use "rc" branch that has no such problems.

gudkov (Fri, 06 Oct 2017 12:45:22 GMT):
Corresponded JIRA ticket: https://jira.hyperledger.org/browse/IS-369

srottem (Sun, 08 Oct 2017 12:29:46 GMT):
I'm seeing some weird behavior with agent listeners and connections; after a listener is closed it doesn't seem to be possible to re-open a new listener on the same endpoint - a CommonIOError is returned - and if a connection is closed no error is thrown when sending a message on that connection. I'm doing this from the .NET wrapper so perhaps I'm doing something wrong...is anyone seeing the anything similar?

anttikettunen (Tue, 10 Oct 2017 09:45:22 GMT):
Has joined the channel.

jamesmonaghan (Tue, 10 Oct 2017 09:54:37 GMT):
hey guys, any idea if the java wrapper is usable in Android?

srottem (Tue, 10 Oct 2017 09:56:25 GMT):
I don't see a reason the wrapper itself shouldn't be Android compliant, but I don't know if it's possible to build the Rust library the Java wrapper depends on for Android - that's something I'd like to know as well.

gudkov (Tue, 10 Oct 2017 14:43:04 GMT):
> hey guys, any idea if the java wrapper is usable in Android? According to this https://forge.rust-lang.org/platform-support.html it is possible to build Rust library for the most popular Android platforms.

srottem (Tue, 10 Oct 2017 15:11:16 GMT):
Then I guess the only remaining part is verifying that the Rust project's build dependencies can be satisfied as well.

srottem (Tue, 10 Oct 2017 20:08:59 GMT):
I've just noticed some Pairwise stuff that's dropped into the Java wrapper - can someone explain what this functionality is intended for? I'm looking at porting to .NET and need to understand it better to add documentation.

srottem (Wed, 11 Oct 2017 10:20:19 GMT):
I also note that there don't appear to be tests in any of the wrappers for the indy_issuer_revoke_claim function - is this an oversight or is the function not ready for prime-time? If it's ready I can work on porting the tests that exist in the appropriate rust tests (anoncreds_works_for_claim_revoked_before_proof_created, anoncreds_works_for_claim_revoked_after_proof_created) - please let me know.

FranciscoReyes (Wed, 11 Oct 2017 10:42:45 GMT):
Has joined the channel.

gudkov (Wed, 11 Oct 2017 10:49:01 GMT):
> I've just noticed some Pairwise stuff that's dropped into the Java wrapper - can someone explain what this functionality is intended for? I'm looking at porting to .NET and need to understand it better to add documentation New calls allow to store metadata about pairwise connections between DIDs

srottem (Wed, 11 Oct 2017 11:20:22 GMT):
So a "pairwise" is record of the relationship between two DIDs that can have optional associated metadata. Is this a reasonable description?

srottem (Wed, 11 Oct 2017 11:20:22 GMT):
So a "pairwise" is a record of the relationship between two DIDs that can have optional associated metadata. Is this a reasonable description?

sklump (Wed, 11 Oct 2017 11:37:28 GMT):
Folks, I think I've found some extraordinarily weird behaviour in anoncreds. In `.../tests/demo/test_anoncreds.py`, I: (1) build a claim offer (2) get a claim request (3) create and store a claim into a wallet (4) get claims for proof request from the wallet (5) pick out the claim uuid from the claim at index [0] (6) create proof (7) verify the proof. All is well. If instead, I write `.../demo/test_x.py` from `test_anoncreds.py` to: (1) build a claim offer (2) get *TWO* claim requests (3) create and store *TWO* claims into a wallet (4) get claims for proof request from the wallet (5) pick out the claim uuid from the claim matching Alex's name (6) create proof (7) verify the proof Then the proof does not verify! I'll attach the test code - does anything jump out as causing this? This is so unexpected I'm betting it's something I've done incorrectly.

sklump (Wed, 11 Oct 2017 11:37:28 GMT):
Folks, I think I've found some extraordinarily weird behaviour in anoncreds. In `.../tests/demo/test_anoncreds.py`, I: (1) build a claim offer (2) get a claim request (3) create and store a claim into a wallet (4) get claims for proof request from the wallet (5) pick out the claim uuid from the claim at index [0] (6) create proof (7) verify the proof. All is well. If instead, I write `.../demo/test_x.py` from `test_anoncreds.py` to: (1) build a claim offer (2) get *TWO* claim requests (3) create and store *TWO* claims into a wallet (4) get claims for proof request from the wallet (5) pick out the claim uuid from the claim matching Alex's name (6) create proof (7) verify the proof Then the proof does not verify! The test code is at https://drive.google.com/open?id=0B5fC2DoP_ko_T3lNSnBJWTBTSzg - does anything jump out as causing this? This is so unexpected I'm betting it's something I've done incorrectly.

sklump (Wed, 11 Oct 2017 11:37:28 GMT):
Folks, I think I've found some extraordinarily weird behaviour in anoncreds. In `.../tests/demo/test_anoncreds.py`, I: (1) build a claim offer (2) get a claim request (3) create and store a claim into a wallet (4) get claims for proof request from the wallet (5) pick out the claim uuid from the claim at index [0] (6) create proof (7) verify the proof. All is well. If instead, I write `.../demo/test_x.py` from `test_anoncreds.py` to: (1) build a claim offer (2) get *TWO* claim requests (3) create and store *TWO* claims into a wallet: one for Alex (M, 175cm, 28) and Ludmilla (F, 170cm, 58) (4) get claims for proof request from the wallet (5) pick out the claim uuid from the claim matching Alex's name (6) create proof (7) verify the proof Then the proof does not verify! The test code is at https://drive.google.com/open?id=0B5fC2DoP_ko_T3lNSnBJWTBTSzg - does anything jump out as causing this? This is so unexpected I'm betting it's something I've done incorrectly.

sklump (Wed, 11 Oct 2017 11:37:28 GMT):
Folks, I think I've found some extraordinarily weird behaviour in anoncreds. In `.../tests/demo/test_anoncreds.py`, I: (1) build a claim offer (2) get a claim request (3) create and store a claim into a wallet (4) get claims for proof request from the wallet (5) pick out the claim uuid from the claim at index [0] (6) create proof (7) verify the proof. All is well. If instead, I write `.../demo/test_x.py` from `test_anoncreds.py` to: (1) build a claim offer (2) get *TWO* claim requests (3) create and store *TWO* claims into a wallet: one for Alex (M, 175cm, 28) and Ludmilla (F, 170cm, 58) (4) get claims for proof request from the wallet (5) pick out the claim uuid from the claim matching Alex's (encoded) name value (6) create proof (7) verify the proof Then the proof does not verify! The test code is at https://drive.google.com/open?id=0B5fC2DoP_ko_T3lNSnBJWTBTSzg - does anything jump out as causing this? This is so unexpected I'm betting it's something I've done incorrectly.

sklump (Wed, 11 Oct 2017 11:37:28 GMT):
Folks, I think I've found some extraordinarily weird behaviour in anoncreds. In `.../tests/demo/test_anoncreds.py`, I: (1) build a claim offer (2) get a claim request (3) create and store a claim into a wallet (4) get claims for proof request from the wallet (5) pick out the claim uuid from the claim at index [0] (6) create proof (7) verify the proof. All is well. If instead, I write `.../demo/test_anonx.py` from `test_anoncreds.py` to: (1) build a claim offer (2) get *TWO* claim requests (3) create and store *TWO* claims into a wallet: one for Alex (M, 175cm, 28) and Ludmilla (F, 170cm, 58) (4) get claims for proof request from the wallet (5) pick out the claim uuid from the claim matching Alex's (encoded) name value (6) create proof (7) verify the proof Then the proof does not verify! The test code is at https://drive.google.com/open?id=0B5fC2DoP_ko_T3lNSnBJWTBTSzg - does anything jump out as causing this? This is so unexpected I'm betting it's something I've done incorrectly.

sklump (Wed, 11 Oct 2017 11:37:28 GMT):
Folks, I think I've found some extraordinarily weird behaviour in anoncreds. In `.../tests/demo/test_anoncreds.py`, I: (1) build a claim offer (2) get a claim request (3) create and store a claim into a wallet for Alex (M, 175cm, 28) (4) get claims for proof request from the wallet (5) pick out the claim uuid from the claim at index [0] (6) create proof (7) verify the proof. All is well. If instead, I write `.../demo/test_anonx.py` from `test_anoncreds.py` to: (1) build a claim offer (2) get *TWO* claim requests (3) create and store *TWO* claims into a wallet: Alex (M, 175cm, 28); Ludmilla (F, 170cm, 58) (4) get claims for proof request from the wallet (5) pick out the claim uuid from the claim matching Alex's (encoded) name value (6) create proof (7) verify the proof Then the proof does not verify! The test code is at https://drive.google.com/open?id=0B5fC2DoP_ko_T3lNSnBJWTBTSzg - does anything jump out as causing this? This is so unexpected I'm betting it's something I've done incorrectly.

sklump (Wed, 11 Oct 2017 11:37:28 GMT):
Folks, I think I've found some extraordinarily weird behaviour in anoncreds. In `.../tests/demo/test_anoncreds.py`, I: (1) build a claim offer (2) get a claim request (3) create and store a claim into a wallet for Alex (M, 175cm, 28) (4) get claims for proof request from the wallet (5) pick out the claim uuid from the claim at index [0] -- by construction, it's the only claim in the wallet (6) create proof (7) verify the proof. All is well. If instead, I write `.../demo/test_anonx.py` from `test_anoncreds.py` to: (1) build a claim offer (2) get *TWO* claim requests (3) create and store *TWO* claims into a wallet: Alex (M, 175cm, 28); Ludmilla (F, 170cm, 58) (4) get claims for proof request from the wallet (5) pick out the claim uuid from the claim matching Alex's (encoded) name value (6) create proof (7) verify the proof Then the proof does not verify! The test code is at https://drive.google.com/open?id=0B5fC2DoP_ko_T3lNSnBJWTBTSzg - does anything jump out as causing this? This is so unexpected I'm betting it's something I've done incorrectly.

sklump (Wed, 11 Oct 2017 11:43:27 GMT):
I'd be happy to submit it to JIRA if it passes sniff test.

sklump (Wed, 11 Oct 2017 11:49:56 GMT):
_Update: If instead I choose the claim uuid from the claim matching Ludmilla's name at step (5), the proof verifies. Curious times!_

sklump (Wed, 11 Oct 2017 11:49:56 GMT):
_Update: If instead I choose the claim uuid from the claim matching Ludmilla's encoded name value at step (5), the proof verifies. Curious times!_

gudkov (Wed, 11 Oct 2017 12:36:55 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jph6R8QDEKSxiyT62) @srottem Yes, It is a good description

gudkov (Wed, 11 Oct 2017 12:38:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nWJaKXqPTuNWC4sEF) @sklump I suggest to submit right now. We will prioritize this for the next sprint.

sklump (Wed, 11 Oct 2017 12:44:46 GMT):
@gudkov My pleasure. It is even weirder: I don't even have to store the second claim -- the act of creating a second claim _request_ queers the proof. I will submit my findings right away.

darrell.odonnell (Wed, 11 Oct 2017 16:30:06 GMT):
@gudkov @nage - any comments on @sklump feedback here? This Proof failure could be a spine-breaker from our perspective.

nage (Wed, 11 Oct 2017 16:37:31 GMT):
I consider this a "blocker bug" and a top priority

nage (Wed, 11 Oct 2017 16:38:09 GMT):
anything that affects claims verification that could allow incorrect claims to check out is a critical issue, and we'll drop other things to go look at them

darrell.odonnell (Wed, 11 Oct 2017 18:28:50 GMT):
by "blocker" does that pull a fix into the current Sprint?

darrell.odonnell (Wed, 11 Oct 2017 18:29:06 GMT):
that's how I interpret "drop other things"

Paratus (Thu, 12 Oct 2017 05:44:15 GMT):
Has joined the channel.

Paratus (Thu, 12 Oct 2017 07:16:57 GMT):
Anyone running Validator nodes, Agents and CLI on AWS, and have any ideas of the shortest way there?

sergey.minaev (Thu, 12 Oct 2017 08:37:02 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done during the end of last sprint: Create new methods for encryption/decryption Analyse problem with rebuilding RC for publishing to stable, found utility to just repacking deb file instead of full rebuilding Java tests refactoring Fixed Anoncreds get claims Api call (return unblinded values) Research Rust http client Implementation stubs for new Agent Api calls - in progress IS-144 libindy tests refactoring IS-332 Handle invalid genesis transaction file IS-356 New agent 2 agent design discussion and meetings IS-360 Libindy publishing in separate repo IS-362 Create new methods in signus for better pairwise support IS-367 obtain details, try to reproduce, investigate the bug - won't fix IS-371 Implement protocol version in indy-sdk, set default version 1 IS-372 Support of abbreviated key form in signus_store_their_did IS-374 Support proof for non-existing value

sklump (Thu, 12 Oct 2017 13:46:09 GMT):
Folks, I'm back to toying with `wrapper/python/tests/demo/test_anoncreds.py`. If I extend `schema['data']['keys']` with an additional attribute, e.g., ``` # 2. Issuer create Claim Definition for Schema schema = { 'seqNo': 1, 'data': { 'name': 'gvt', 'version': '1.0', 'keys': ['age', 'sex', 'height', 'name', 'favourite_drink'] } }``` then the verifier cannot verify the proof in the test case: ``` ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid structure: Value by key 'favourite_drink' not found in mtilde F``` I assume that this is because the claim_def is based on the schema -- and so every claim must have every attribute? Since at present each claim_def (on the ledger) is tied 1:1 to an issuer, this presents a problem for modelling data with optional attributes. Surely I don't want to have, for *n* optional attributes, up to *2^n* issuers for *2^n* claim_defs on one schema. I would welcome any thoughts the community might have in this direction.

darrell.odonnell (Thu, 12 Oct 2017 13:57:21 GMT):
Optional attributes wouldn't be part of a Proof would they?

sklump (Thu, 12 Oct 2017 14:02:08 GMT):
It depends. The proof only includes attributes that the proof_request asks for. If the verifier doesn't know _a priori_ what attributes are in the record, it can easily fall into two traps: * asking for not enough * asking for too much There is no way to request 'show me what you got'.

sklump (Thu, 12 Oct 2017 14:09:51 GMT):
In any case, the SDK doesn't complain until the verifier tries to verify proof of a claim. It creates a claim with some attrs missing from the claim_def, then it creates proof on that claim. Only on verification does it blow up. If it's not acceptable to create a claim missing some attributes in the claim_def, I lean toward thinking it should raise an exception earlier, say, on claim creation?

sklump (Thu, 12 Oct 2017 14:09:51 GMT):
In any case, the SDK doesn't complain until the verifier tries to verify proof of a claim. It creates a claim with some attrs missing from the claim_def, then it creates proof against that claim. Only on verification of that proof does it blow up. If it's not acceptable to create a claim missing some attributes in the claim_def, I lean toward thinking it should raise an exception earlier, say, on claim creation?

srottem (Fri, 13 Oct 2017 06:56:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kAqnNgSQCMbeuuDr5) Bump - is the indy_issuer_revoke_claim function ready for primetime? If so I'm ready to implement the test suites in Java and .NET.

gudkov (Fri, 13 Oct 2017 09:04:34 GMT):
indy_issuer_revoke_claim is implemented, but we covered only high cases by tests

srottem (Fri, 13 Oct 2017 09:48:45 GMT):
No problem - I'll replicate those tests across to Java and .NET.

ashcherbakov (Fri, 13 Oct 2017 10:54:51 GMT):
@sklump As of now, SCHEMA transaction is quite primitive, and I think it assumes all attributes required. The anoncreds protocol also assumes that all attributes are required. I think we need to extend SCHEMA with a notion of optional attributes, and extenmd the anoncreds protocol to support the optional attributes.

austin (Fri, 13 Oct 2017 21:31:33 GMT):
Has joined the channel.

ramnath00 (Mon, 16 Oct 2017 07:50:24 GMT):
Has joined the channel.

austin (Mon, 16 Oct 2017 14:56:52 GMT):
Has left the channel.

austin (Mon, 16 Oct 2017 15:49:15 GMT):
Has joined the channel.

austin (Mon, 16 Oct 2017 15:52:34 GMT):
Trying to run `cargo build` on master and running into a compile issue which is mentioned in https://jira.hyperledger.org/browse/IS-369 Is there a workaround to this issue to unblock development?

gudkov (Tue, 17 Oct 2017 09:34:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qs44GP53JYCpuDzix) The workaraunds are: 1. Use "rc" branch 2. Use "windows" or "ubuntu" platform for development. MacOS isn't best development platform now. We don't provide CI pipeline and binary builds for MacOS for the moment.

sklump (Tue, 17 Oct 2017 13:57:39 GMT):
So, about claim definitions and schema. * ledger (wrapper code) offers designated claim definition transactions. * anoncreds (wrapper code) offers build_and_store_claim_def to create a claim definition from a schema and store it in a wallet * anoncreds (wrapper code) offers issuer_create_claim, but the claim definition must already be in the (issuer) wallet. What I had imagined was the Ontology God creating a schema and a claim def and putting them on the ledger, then claims issuers getting those and issuing claims using them. But there is no means of taking a claim definition from the ledger and putting it into a wallet -- the only way to put a claim def into an issuer wallet is to create it from scratch, from a schema. What good, then does putting a claim definition on the ledger do? Who can use it for anything?

sklump (Tue, 17 Oct 2017 13:57:39 GMT):
So, about claim definitions and schemata. * ledger (wrapper code) offers designated claim definition transactions. * anoncreds (wrapper code) offers build_and_store_claim_def to create a claim definition from a schema and store it in a wallet * anoncreds (wrapper code) offers issuer_create_claim, but the claim definition must already be in the (issuer) wallet. What I had imagined was the Ontology God creating a schema and a claim def and putting them on the ledger, then claims issuers getting those and issuing claims using them. But there is no means of taking a claim definition from the ledger and putting it into a wallet -- the only way to put a claim def into an issuer wallet is to create it from scratch, from a schema. What good, then does putting a claim definition on the ledger do? Who can use it for anything?

sklump (Tue, 17 Oct 2017 13:57:39 GMT):
So, about claim definitions and schemata. * ledger (wrapper code) offers designated claim definition transactions. * anoncreds (wrapper code) offers build_and_store_claim_def() to create a claim definition from a schema and store it in a wallet * anoncreds (wrapper code) offers issuer_create_claim(), but the claim definition must already be in the (issuer) wallet. What I had imagined was the Ontology God creating a schema and a claim def and putting them on the ledger, then claims issuers getting those and issuing claims using them. But there is no means of taking a claim definition from the ledger and putting it into a wallet -- the only way to put a claim def into an issuer wallet is to create it from scratch, from a schema. What good, then does putting a claim definition on the ledger do? Who can use it for anything? Could the ledger build_claim_def_txn() be an artifact of some historic model, or else a placeholder for future development?

sklump (Tue, 17 Oct 2017 13:57:39 GMT):
So, about claim definitions and schemata. * ledger (wrapper code) offers build_claim_def_txn() to build claim definition transactions to submit to the ledger. * anoncreds (wrapper code) offers build_and_store_claim_def() to create a claim definition from a schema and store it in a wallet * anoncreds (wrapper code) offers issuer_create_claim(), but the claim definition must already be in the (issuer) wallet. What I had imagined was the Ontology God creating a schema and a claim def and putting them on the ledger, then claims issuers getting those and issuing claims using them. But there is no means of taking a claim definition from the ledger and putting it into a wallet -- the only way to put a claim def into an issuer wallet is to create it from scratch, from a schema. What good, then does putting a claim definition on the ledger do? Who can use it for anything? Could the ledger build_claim_def_txn() be an artifact of some historic model, or else a placeholder for future development?

sklump (Tue, 17 Oct 2017 13:57:39 GMT):
So, about claim definitions and schemata. * ledger (wrapper code) offers build_claim_def_txn() to build claim definition transactions to submit to the ledger. * anoncreds (wrapper code) offers build_and_store_claim_def() to create a claim definition from a schema and store it in a wallet * anoncreds (wrapper code) offers issuer_create_claim(), but the claim definition must already be in the (issuer) wallet. What I had imagined was the Ontology God creating a schema and a claim def and putting them on the ledger, then claims issuers getting those and issuing claims using them. But there is no means of taking a claim definition from the ledger and putting it into a wallet -- the only way to put a claim def into an issuer wallet is to create it from scratch, from a schema. What good, then, does putting a claim definition on the ledger do? Who can use it for anything? Could the ledger build_claim_def_txn() be an artifact of some historic model, or else a placeholder for future development?

srottem (Tue, 17 Oct 2017 14:27:04 GMT):
I assume you're referring to issuer_create_and_store_claim_def? I think the approach is that you use pass issuer_create_and_store_claim_def a schema and it create the keys (both primary and revocation) in the wallet and returns the claim definition. The definition can then be registered on the ledger - this is dones by constructing a request passing the parts of the claim definition to indy_build_claim_def_txn then sending the request to the ledger using indy_sign_and_submit_request.

sklump (Tue, 17 Oct 2017 14:30:43 GMT):
Yes, it _can_ go on the ledger. Who benefits?

sklump (Tue, 17 Oct 2017 14:31:42 GMT):
If every issuer rolls his own claim_def, and can't do anything with it as retrieved the ledger, why put it on the ledger?

sklump (Tue, 17 Oct 2017 14:33:07 GMT):
Never mind -- the PROVER gets it from the ledger. OK.

sklump (Tue, 17 Oct 2017 14:33:19 GMT):
I have about 200 lines to rethink.

srottem (Tue, 17 Oct 2017 14:33:26 GMT):
You beat me to that answer. :)

sklump (Tue, 17 Oct 2017 14:34:40 GMT):
So easy when it's just lines on a chart

srottem (Tue, 17 Oct 2017 14:34:41 GMT):
I was actually looking for a code sample that demonstrates it, but I have yet to find one.

sklump (Tue, 17 Oct 2017 14:35:08 GMT):
In the anoncreds, there's a sample, but it's one monolithic megaman agent doing all the things.

srottem (Tue, 17 Oct 2017 14:35:23 GMT):
Exactly.

sklump (Tue, 17 Oct 2017 14:35:26 GMT):
So my code is a bit broken

sklump (Tue, 17 Oct 2017 14:35:30 GMT):
:(

sklump (Tue, 17 Oct 2017 14:36:25 GMT):
A single tear, then back into it.

mgbailey (Tue, 17 Oct 2017 15:19:08 GMT):
While it is true that the schema is useful to the prover, @sklump, your original question is still interesting. We want providers to be able to reuse common schemas, and anticipate that they will eventually consolidate on de-facto standards. Are we missing a piece to facilitate this?

sklump (Tue, 17 Oct 2017 15:34:36 GMT):
There is no way for a claim issuer to issue a claim on an existing claim definition, as returned from the ledger. In the case that an issuer goes down, for example, it can't put its own sent claim definition into its wallet, with which to issue more claims. As far as the future big picture is concerned, I have no opinion on whether what you ask is an interesting use case. But please confirm: an Issuer can issue multiple claims off one claim definition. Correct?

sklump (Tue, 17 Oct 2017 15:34:36 GMT):
There is no way for a claim issuer to issue a claim on an existing claim definition, as returned from the ledger. In the case that an issuer goes down, for example, it can't put its own sent claim definition into its wallet, with which to issue more claims. As far as the future big picture is concerned, I have no opinion on whether what you ask is an interesting use case. But please confirm: an Issuer can create multiple claims off one claim definition. Correct?

sklump (Tue, 17 Oct 2017 15:34:36 GMT):
There is no way for a claim issuer to issue a claim on an existing claim definition, as returned from the ledger. In the case that an issuer goes down, for example, it can't put its own sent claim definition into its wallet, with which to issue more claims. As far as the future big picture is concerned, I have no opinion on whether what you ask is an interesting use case. But @mgbailey, *please confirm*: an Issuer can create multiple claims off one claim definition. Correct?

sklump (Tue, 17 Oct 2017 15:59:58 GMT):
PS: I see that a single claim def for all is totally the wrong idea for the indy-sdk as it is -- from anoncreds.py, issuer_create_and_store_claim_def() ... ``` :return: claim definition json containing information about signature type, schema and issuer's public key. *Unique number identifying the public key in the wallet* ```

sklump (Tue, 17 Oct 2017 15:59:58 GMT):
PS: I see that a single claim def for all is totally the wrong idea for the indy-sdk as it is -- from anoncreds.py, issuer_create_and_store_claim_def() ... " :return: claim definition json containing information about signature type, schema and issuer's public key. *Unique number identifying the public key in the wallet* "

mgbailey (Tue, 17 Oct 2017 16:33:59 GMT):
@sklump , my understanding is that claim schemas and claim definitions are different entities, with the claim definition referencing the schema. The schema should be able to be reused by various entities, the definition not.

srottem (Tue, 17 Oct 2017 16:34:33 GMT):
I think the idea would be to be able to register *schema* for all but multiple issuers could have use the same schema for their claim defs. So a (naïve example) driver's license schema could be put on the ledger and then multiple governments could create their own claim definition for a driver's license.

mgbailey (Tue, 17 Oct 2017 16:39:51 GMT):
right, with the other parts of the claim def @sklump mentions above being unique

mgbailey (Tue, 17 Oct 2017 16:41:22 GMT):
There will be no central authority saying what is a valid claim schema, but for interoperability there will probably be evolving consensus in common schemas

mgbailey (Tue, 17 Oct 2017 16:44:46 GMT):
Question: has anyone tried using the CLI in conjunction with an indy-sdk agent? In other words, set up an indy-sdk agent, and then in the CLI client on another node run through commands that will pull a claim or provide a proof to that agent?

sklump (Tue, 17 Oct 2017 16:46:24 GMT):
So, yes or no, one issuer can issue multiple claims using the same claim definition?

mgbailey (Tue, 17 Oct 2017 16:56:54 GMT):
Yes. But in the future the answer is a little more nuanced. When revocation is fully implemented, there will be a "tail file" that will have revocation entries in it. This will be part of (or referenced by -- I am not sure which) the claim def. When the claim def is made, the size of the tail file will be fixed, and there will be an entry for each claim that will be made. So, say a user makes a claim def that has a tail file with 100 entries. He then starts making claims using that claim def. After the 100th claim, he must write a new claim def with a new tail file.

sklump (Tue, 17 Oct 2017 17:05:26 GMT):
Thanks -- onto the next thing.

sklump (Tue, 17 Oct 2017 17:19:34 GMT):
My attempt at an issuer creating a claim fails at libindy/src/commands/anoncreds/issuer.rs, line 397, in fn _create_claim(); i.e., ```let claim_def_json = self.wallet_service.get(wallet_handle, &format!("claim_definition::{}", &get_composite_id(&claim_req_json.issuer_did.clone(), claim_req_json.schema_seq_no)))?; ``` throws `Casting error to ErrorCode: Wallet not found: Wallet record is not found: query returned no rows`. At the issuer, I've: * got the schema from the ledger by its originator DID, name, version * called anoncreds.issuer_create_and_store_claim_def() against the issuer wallet handle, issuer DID, resulting schema (JSON), 'CL' signing, False for revocation. * call anoncreds.issuer_create_claim() on wallet handle, claim req (with blinded master secret etc), and the JSON dumped dict of my claim, which matches the schema. Any idea what could be wrong?? The issuer_did is the claim issuer, not the schema issuer, yes? I just don't see what I'm doing wrong.

sklump (Tue, 17 Oct 2017 17:19:34 GMT):
My attempt at an issuer creating a claim fails at libindy/src/commands/anoncreds/issuer.rs, line 397, in fn __create__claim(); i.e., ```let claim_def_json = self.wallet_service.get(wallet_handle, &format!("claim_definition::{}", &get_composite_id(&claim_req_json.issuer_did.clone(), claim_req_json.schema_seq_no)))?; ``` throws `Casting error to ErrorCode: Wallet not found: Wallet record is not found: query returned no rows`. At the prover, I've created the claim request, and got back its JSON At the issuer, I've: * got the schema from the ledger by its originator DID, name, version * called anoncreds.issuer_create_and_store_claim_def() against the issuer wallet handle, issuer DID, resulting schema (JSON), 'CL' signing, False for revocation. * call anoncreds.issuer_create_claim() on wallet handle, claim req (with blinded master secret etc), and the JSON dumped dict of my claim, which matches the schema in its attributes. Any idea what could be wrong?? The issuer_did is the claim issuer, not the schema issuer, yes? I just don't see what I'm doing wrong.

sklump (Tue, 17 Oct 2017 17:19:34 GMT):
My attempt at an issuer creating a claim fails at libindy/src/commands/anoncreds/issuer.rs, line 197, in fn __create__claim(); i.e., ```let claim_def_json = self.wallet_service.get(wallet_handle, &format!("claim_definition::{}", &get_composite_id(&claim_req_json.issuer_did.clone(), claim_req_json.schema_seq_no)))?; ``` throws `Casting error to ErrorCode: Wallet not found: Wallet record is not found: query returned no rows`. At the prover, I've created the claim request, and got back its JSON At the issuer, I've: * got the schema from the ledger by its originator DID, name, version * called anoncreds.issuer_create_and_store_claim_def() against the issuer wallet handle, issuer DID, resulting schema (JSON), 'CL' signing, False for revocation. * call anoncreds.issuer_create_claim() on wallet handle, claim req (with blinded master secret etc), and the JSON dumped dict of my claim, which matches the schema in its attributes. Any idea what could be wrong?? The issuer_did is the claim issuer, not the schema issuer, yes? I just don't see what I'm doing wrong.

sklump (Tue, 17 Oct 2017 17:41:32 GMT):
Anyone in the know want to spend 15 minutes with me here? This could get ugly.

sklump (Tue, 17 Oct 2017 17:47:49 GMT):
There is definitely a schema at the transaction number (18), I wonder about the issuer DID.

sklump (Tue, 17 Oct 2017 18:03:51 GMT):
_bear with me, trying to trace it through_

srottem (Tue, 17 Oct 2017 19:57:46 GMT):
Are you using the default wallet or a custom one?

sklump (Wed, 18 Oct 2017 11:03:31 GMT):
Default wallet. Current hypothesis: I had earlier problems manifesting as this. Still troubleshooting.

srottem (Wed, 18 Oct 2017 12:06:45 GMT):
Can I see the results from issuer_create_and_store_claim_def and the values you're passing to issuer_create_claim?

bhurley (Wed, 18 Oct 2017 12:40:16 GMT):
Has joined the channel.

sklump (Wed, 18 Oct 2017 12:52:57 GMT):
It looks like I had the wrong DID as the issuer did.

sklump (Wed, 18 Oct 2017 12:55:22 GMT):
It's the claim issuer, not the schema issuer. I have no excuse here, and I'm not sure how I got it mixed up. Possibly in retrieving JSON tokens from the ledger, and mixing up 'dest' and 'identifier'.

sklump (Wed, 18 Oct 2017 12:56:25 GMT):
Sometimes it's humbling what a difference 7 hours of sleep can make.

srottem (Wed, 18 Oct 2017 14:06:03 GMT):
*chuckle* Yep, we've all been there!

austin (Wed, 18 Oct 2017 19:05:11 GMT):
delayed thanks @gudkov, I built the `rc` branch on an Ubuntu image and was able to get a `indy-1.0.0.jar` and a `libindy.so`. However, when importing the library into my project I get a crash which I cannot resolve: ```java.lang.UnsatisfiedLinkError: /Users/austinmoothart/dev/project-indigo/oracle-service/lib/libindy.so: dlopen(/Users/austinmoothart/dev/project-indigo/oracle-service/lib/libindy.so, 1): no suitable image found. Did find: /Users/austinmoothart/dev/project-indigo/oracle-service/lib/libindy.so: unknown file type, first eight bytes: 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x00``` I'm reproing this with a hard coded load `System.load("/Users/austinmoothart/dev/project-indigo/oracle-service/lib/libindy.so")` as I could not get the `LibIndy.init()` methods to work yet. Any further help on how to include the .so is appreciated.

alain2sf (Thu, 19 Oct 2017 06:16:41 GMT):
Has joined the channel.

gudkov (Thu, 19 Oct 2017 11:00:34 GMT):
@austin Are you trying to load "ubuntu" libirary on MacOS? It is impossible as ".so" files can be loaded on linux only. You can build "rc" branch on MacOS with instruction from Readme.md. For current moment only "master" branch have problems with compilation on MacOS.

austin (Thu, 19 Oct 2017 13:08:26 GMT):
@gudkov thanks for the response, yes Michael Bailey confirmed the same issue yesterday. I've been unable to compile the `rc` branch on my Mac for the reasons listed in https://jira.hyperledger.org/browse/IS-369 For the moment I can do development on the VM.

gudkov (Thu, 19 Oct 2017 13:10:46 GMT):
Are you sure you have the same problem as in ticket? I tried to build "rc" few days ago and it compiled without problems on my Mac. There was no merges during this time.

austin (Thu, 19 Oct 2017 13:12:37 GMT):
no... in fact I'm not :blush: ``` = note: Undefined symbols for architecture x86_64: "_crypto_stream_aes128ctr_xor", referenced from: sodiumoxide::crypto::stream::aes128ctr::stream_xor::hb355e452762fc249 in libsodiumoxide-1cdc0f7f784b6550.rlib(sodiumoxide-1cdc0f7f784b6550.0.o) sodiumoxide::crypto::stream::aes128ctr::stream_xor_inplace::haf5a428a0e4d3a8a in libsodiumoxide-1cdc0f7f784b6550.rlib(sodiumoxide-1cdc0f7f784b6550.0.o) "_crypto_stream_aes128ctr", referenced from: sodiumoxide::crypto::stream::aes128ctr::stream::h35020c8b80ef1d7a in libsodiumoxide-1cdc0f7f784b6550.rlib(sodiumoxide-1cdc0f7f784b6550.0.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)```

gudkov (Thu, 19 Oct 2017 15:04:11 GMT):
Did you isntall libsodium?

gudkov (Thu, 19 Oct 2017 15:04:11 GMT):
Did you install libsodium?

austin (Thu, 19 Oct 2017 15:05:56 GMT):
yes, I'm on 1.0.15 ```| => brew install libsodium Warning: libsodium 1.0.15 is already installed```

gudkov (Thu, 19 Oct 2017 15:11:47 GMT):
I am not sure about the version. Can it be outdated? sodiumoxide can't find crypto_stream_aes128ctr_xor and crypto_stream_aes128ctr symbols in libsodium

gudkov (Thu, 19 Oct 2017 15:12:42 GMT):
Try 1.0.12

austin (Thu, 19 Oct 2017 15:12:50 GMT):
That is the latest version https://github.com/jedisct1/libsodium/releases I'll try 1.0.12

gudkov (Thu, 19 Oct 2017 15:14:02 GMT):
Also you can try to update sodiumoxide version in Cargo.toml

gudkov (Thu, 19 Oct 2017 15:14:29 GMT):
May be used version of sodiumoxide is incompatible with 1.0.12

gudkov (Thu, 19 Oct 2017 15:14:29 GMT):
May be used version of sodiumoxide is incompatible with 1.0.15

sergey.minaev (Thu, 19 Oct 2017 15:42:29 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done during last few days: IS-356 New agent 2 agent design IS-380 CLI: Indy-SDK based CLI - Design (in progress) Start implementation new agent2agent approach: IS-357 and IS-387

austin (Thu, 19 Oct 2017 17:10:53 GMT):
@gudkov Bingo! A downgrade to libsodium 1.0.12 did the trick! One other note was I had to include the JNA library in the gradle build or LibIndy wouldn't be able to import. Thanks for all the support.

mgbailey (Fri, 20 Oct 2017 15:46:35 GMT):
sudo pip3 install python3-indy sudo pip3 install --upgrade python3-indy

sklump (Mon, 23 Oct 2017 11:46:42 GMT):
Hey, quick probably one-liner question: how do I turn configure logging (log level, log file, set daily rotation) on the rust indy-sdk operation?

sergey.minaev (Mon, 23 Oct 2017 14:09:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=SoTuSB6fe4Nz6oybw) @sklump actually there is only one configuration for logs in indy-sdk now. You can set log level for modules by `RUST_LOG` environment variable. E.g. `RUST_LOG=trace` or `RUST_LOG=indy=trace,zmq=error`. Also there is issue IS-58 about logger improvement. Please add your comment, to vote for some functionality.

sklump (Mon, 23 Oct 2017 15:50:45 GMT):
I hate to go over old ground, which I get the feeling this is, but installing the indy-sdk via pip install retains the type hint style that is compatible only with python 3.6 (e.g., indy/error.py line 118: ``` error_code: ErrorCode ``` Was there a move to commenting these out in the package, to allow compatibility with python 3.5 à la indy-node, or was the intent to push everything to 3.6?

sergey.minaev (Mon, 23 Oct 2017 16:16:18 GMT):
@gudkov ^

gudkov (Mon, 23 Oct 2017 16:19:39 GMT):
@sklump Current master branch is compatible with python 3.5 (see https://github.com/hyperledger/indy-sdk/commit/1cec2c6cd2feb8dca667f87d9ee6da2605f63197)

gudkov (Mon, 23 Oct 2017 16:19:46 GMT):
Not sure about rc

austin (Mon, 23 Oct 2017 16:24:06 GMT):
hi again folks, I'm seeing issues running `openPoolLedger`. The error is: `ERROR|indy::services::pool | src/services/pool/mod.rs:463 | Pool worker thread finished with error CommonError(IOError(Error { repr: Os { code: 2, message: "No such file or directory" } }))` I'm passing in the a txn which appears to be correct and think the error might come from here https://github.com/hyperledger/indy-sdk/blob/rc/libindy/src/services/pool/mod.rs#L70

austin (Mon, 23 Oct 2017 16:25:18 GMT):
A couple questions: 1) could this be related to Java encoded strings being handled in Rust? 2) Is there any way to debug Rust from behind the Java wrapper? It is very hard to tell what is happening when things go wrong.

sklump (Mon, 23 Oct 2017 20:23:16 GMT):
Hey folks, I can open a pool fine in the test harness. When I try to wire this operation into django app startup, I get a panic: ``` INFO|command_executor | src/commands/mod.rs:99 | PoolCommand command received INFO|pool_command_executor | src/commands/pool.rs:62 | Open command received INFO|pool_command_executor | src/commands/pool.rs:63 | ... config None <--- (this line is mine) thread '' panicked at 'called `Result::unwrap()` on an `Err` value: ErrorImpl { code: KeyMustBeAString, line: 1, column: 2 }', /checkout/src/libcore/result.rs:860:4 stack backtrace: 0: 0x7f52608c32a3 - std::sys::imp::backtrace::tracing::imp::unwind_backtrace::hcdf51e4c9dc54357 at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49 1: 0x7f52608bdab4 - std::sys_common::backtrace::_print::h9da91fd31a37d0f1 at /checkout/src/libstd/sys_common/backtrace.rs:71 2: 0x7f52608d08c3 - std::panicking::default_hook::{{closure}}::h46820a72bf0cb624 at /checkout/src/libstd/sys_common/backtrace.rs:60 at /checkout/src/libstd/panicking.rs:380 3: 0x7f52608d0632 - std::panicking::default_hook::h4c1ef1cc83189c8e at /checkout/src/libstd/panicking.rs:396 4: 0x7f52608d0d87 - std::panicking::rust_panic_with_hook::h99016f44bdcb8544 at /checkout/src/libstd/panicking.rs:611 ... 26: 0x7f5265b206b9 - start_thread 27: 0x7f52658563dc - clone 28: 0x0 - ``` Maddening: when I run the unit test suite, src/commands/pool.rs likes the None config just fine: ``` INFO|pool_command_executor | src/commands/pool.rs:62 | Open command received INFO|pool_command_executor | src/commands/pool.rs:63 | ... config None ... ``` Are there background pieces, in conftest.py for example, that are necessary precursors to starting the pool?

sklump (Tue, 24 Oct 2017 10:46:12 GMT):
_ ... I'm working on tweaking the conftest.py code to reproduce this failure ...

sklump (Tue, 24 Oct 2017 10:46:12 GMT):
_ ... I'm working on tweaking the conftest.py code to reproduce this failure ..._

sergey.minaev (Tue, 24 Oct 2017 10:50:04 GMT):
@sklump attached backtrace is collapsed at most helpful lines, could you reproduce with `RUST_BACKTRACE=full`?

sergey.minaev (Tue, 24 Oct 2017 10:54:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=GuyWJbksMyJHRqv25) @austin 1) all strings for Rust should be UTF-8 encoded 2) I suggest to enable maximal logging before switching to debugger. (`RUST_LOG=trace`)

sklump (Tue, 24 Oct 2017 11:36:15 GMT):
@sergey It appears that my genesis transaction data was incorrect. I had retained {{}} brace escaping from conftest.py, and so it looks like a garbage-in/garbage-out situation. I'll update further if it looks any deeper than that on further development.

austin (Tue, 24 Oct 2017 13:04:05 GMT):
Thanks @sergey.minaev I had enabled `RUST_LOG=indy=trace` already per https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md. I added `RUST_BACKTRACE=full` and got many more logs on the SDK build. However, logs did not change from the SDK crash. Here is the full stack trace: ``` INFO|command_executor | src/commands/mod.rs:99 | PoolCommand command received INFO|pool_command_executor | src/commands/pool.rs:62 | Open command received INFO|command_executor | src/commands/mod.rs:99 | PoolCommand command received INFO|indy::commands::pool | src/commands/pool.rs:66 | OpenAck handle 1, result Err(Terminate) ERROR|indy::services::pool | src/services/pool/mod.rs:463 | Pool worker thread finished with error CommonError(IOError(Error { repr: Os { code: 2, message: "No such file or directory" } })) ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Pool work terminated java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.IndyException: PoolLedgerTerminated: 302```

austin (Tue, 24 Oct 2017 13:05:50 GMT):
I debugged this with @mgbailey yesterday and we noticed that neither the Python wrapper or the Java wrapper are creating any pool config in `~/.indy/pool/`

sergey.minaev (Tue, 24 Oct 2017 13:06:08 GMT):
@austin do you use master or RC/stable?

austin (Tue, 24 Oct 2017 13:06:13 GMT):
rc

sergey.minaev (Tue, 24 Oct 2017 13:10:06 GMT):
Seems like RC has insufficient logs. I may try to guess, that problem in create pool config: path to genesis file is incorrect/relative/etc.

sergey.minaev (Tue, 24 Oct 2017 13:10:06 GMT):
Seems like RC has insufficient logs. I may try to guess, that problem in create pool `config`: path to genesis file is incorrect/relative/etc.

austin (Tue, 24 Oct 2017 13:11:28 GMT):
The path to the genesis is hardcoded and I believe is correct because I get a different error message if I change to a path that doesn't exist

austin (Tue, 24 Oct 2017 13:12:06 GMT):
is there something I need to set to create the pool config?

sergey.minaev (Tue, 24 Oct 2017 13:12:50 GMT):
only genesis transactions file in somewhere

sergey.minaev (Tue, 24 Oct 2017 13:12:50 GMT):
only genesis transactions file somewhere

sergey.minaev (Tue, 24 Oct 2017 13:15:36 GMT):
while call `createPoolLedgerConfig` this file will be copied to `~/.indy/pool//.txn`

sergey.minaev (Tue, 24 Oct 2017 13:18:43 GMT):
@austin do you run tests in Java wrapper or some custom application?

austin (Tue, 24 Oct 2017 13:19:48 GMT):
custom application that is using the Java wrapper

sergey.minaev (Tue, 24 Oct 2017 13:21:22 GMT):
ok. Do you try to run Java wrapper's tests? Are tests passed?

sergey.minaev (Tue, 24 Oct 2017 13:21:22 GMT):
ok. Did you try to run Java wrapper's tests? Are tests passed?

austin (Tue, 24 Oct 2017 13:31:46 GMT):
ok @sergey.minaev you called out `createPoolLedgerConfig` and I realized that this method was missing. I re-added the call to `Pool.createPoolLedgerConfig` and I'm onto the next step. The missing file had been the ~/.indy/pool/ directory Thanks for the help

sklump (Tue, 24 Oct 2017 14:15:49 GMT):
Speaking of fun in the pool, suppose I have two processes (for simplicity, on the same host): * process 0 opens the pool * process 1 wants to connect to it. Process 0 calls pool.create_ledger_config() with pool name and `{"genesis_txn": ".../genesis.txn"}`, then calls pool.open_pool_ledger() on the pool name (let's say config=None). How can process 1 use the pool? It can't create it because it's already created. It can't open it because it's not possible to open a pool twice. It can't use the open pool connection because it's in another process. The way I understand it, process 0 has to write germane info to a file for process 1 to pick up ... grimy and short-sighted, because ultimately process 1 will be on another host. Surely I have this wrong -- what is the right call for process 1 to use the pool that process 0 creates?

sklump (Tue, 24 Oct 2017 14:15:49 GMT):
Speaking of fun in the pool, suppose I have two processes (for simplicity, on the same host): * process 0 opens the pool * process 1 wants to connect to it. Process 0 calls pool.create_ledger_config() with pool name and `{"genesis_txn": ".../genesis.txn"}`, then calls pool.open_pool_ledger() on the pool name (let's say config=None). How can process 1 use the pool? It can't create it because it's already created. It can't open it because it's not possible to open a pool twice. It can't use the open pool connection because it's in another process. The way I understand it, process 1 has to ask process 0 for its (int) pool handle and pool name ... grimy and short-sighted, because ultimately process 1 will be on another host. For now I can code around it, but surely I have this wrong -- is there a more native indy-sdk way for process 1 to use the pool that process 0 creates?

codenamedmitri (Tue, 24 Oct 2017 18:02:47 GMT):
Has joined the channel.

ChristianSmith (Tue, 24 Oct 2017 18:06:14 GMT):
Has joined the channel.

glinklater (Tue, 24 Oct 2017 18:33:13 GMT):
Has joined the channel.

nbrempel (Tue, 24 Oct 2017 20:46:46 GMT):
Has joined the channel.

MALodder (Tue, 24 Oct 2017 22:19:54 GMT):
Has joined the channel.

MALodder (Tue, 24 Oct 2017 22:20:48 GMT):
I submitted a pull request that changes the default wallet implementation from SQLite to SQLCipher that uses HMAC-SHA256 instead of HMAC-SHA1

MALodder (Tue, 24 Oct 2017 22:21:31 GMT):
@gudkov can you and alexander.shcherbakov take a look at it

gudkov (Wed, 25 Oct 2017 14:31:05 GMT):
@sklump > For now I can code around it, but surely I have this wrong -- is there a more native indy-sdk way for process 1 to use the pool that process 0 creates? 1. You can use different home folders for these processes 2. For now you can create 2 different pool configurations with the same config, but different name (not sure that it is a good aproach) 3. Run processes from different users

gudkov (Wed, 25 Oct 2017 14:32:32 GMT):
Actually for Indy SDK it can be a good idea to support multy processes on the most of platforms. As i can have multiple desktop apps that works with Indy Pool.

gudkov (Wed, 25 Oct 2017 14:33:01 GMT):
Could you create a ticket about this in Jira and provide your motivation?

nbrempel (Wed, 25 Oct 2017 21:44:48 GMT):
Does anyone know if there is a good resource that lists all available indy primitives?

nbrempel (Wed, 25 Oct 2017 21:45:11 GMT):
Currently I'm digging through https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/tests/demo/test_agent.py and reading code to get a better understanding

austin (Thu, 26 Oct 2017 20:21:08 GMT):
hi again folks, I'm much further along with the SDK and ran into some issues with the Wallet. After running a series of indy-sdk commands I noticed that the sqlite db is still empty for both wallets created under `~/.indy/wallet/`. What could be causing the sqlite to remain empty despite having run successful indy-sdk commands?

srottem (Thu, 26 Oct 2017 20:21:42 GMT):
What commands have been run?

austin (Thu, 26 Oct 2017 20:23:31 GMT):
I'm running the same commands used in the anoncreds demo: https://github.com/hyperledger/indy-sdk/blob/master/samples/java/src/main/java/Anoncreds.java

austin (Thu, 26 Oct 2017 20:26:34 GMT):
Secondly (and possibly related?) I am getting a `WalletNotFoundError` error after calling `proverCreateAndStoreClaimReq(proverWallet, proverDid, claimOffer, claimDef, masterSecret).get()` This is step 8 in the same anoncreds demo. For all the earlier steps I've been able to open and use a wallet by the same name. Is there something different about this method?

srottem (Thu, 26 Oct 2017 20:29:12 GMT):
Hm. If you're using exactly the same code then it creates and then deletes the wallets, so nothing would be left behind. I imagine you're getting the WalletNotFoundError because the wallet doesn't contain a value required to satisfy the method call rather than because the wallet doesn't exist, so I imaging they're separate issues.

srottem (Thu, 26 Oct 2017 20:29:19 GMT):
My well be related though.

srottem (Thu, 26 Oct 2017 20:29:29 GMT):
Can you share your code?

austin (Thu, 26 Oct 2017 20:30:15 GMT):
It's not exactly the same as I've broken each Sovrin step out into a separate method. I'm setting up and tearing down the config for every step so each one is being run independently. I'll grab some code

srottem (Thu, 26 Oct 2017 20:31:12 GMT):
If you slap it into a gist I'm happy to take a look with you. I'll only be up for another 30 mins or so though (I'm in France)

austin (Thu, 26 Oct 2017 20:33:31 GMT):
https://gist.github.com/amoothart/cd5fa0296728a00dead43b201cc67369 Line 174 is the wallet 204 error

austin (Thu, 26 Oct 2017 20:34:03 GMT):
the setup methods are at the bottom of the file (thank you for staying up late!)

srottem (Thu, 26 Oct 2017 20:34:25 GMT):
No probs - just working on the .NET wrapper while I can... :)

austin (Thu, 26 Oct 2017 20:34:29 GMT):
6/10 of the tests do pass fwiw

austin (Thu, 26 Oct 2017 20:34:55 GMT):
so I'm taking over your dev time... there is no escape from distraction :(

srottem (Thu, 26 Oct 2017 20:41:21 GMT):
OK, so I'm assuming at this stage that the wallets don't exist after you createClaimRequest function is throwing and you're calling closeSovin at the end which cleans them up.

austin (Thu, 26 Oct 2017 20:43:16 GMT):
yes at the very end I ensure the wallets are closed so the next test can be run successfully

austin (Thu, 26 Oct 2017 20:44:10 GMT):
the other commands follow the same pattern which works for them

srottem (Thu, 26 Oct 2017 20:46:40 GMT):
Perhaps I'm missing something. Your first question was about the wallets remaining empty after running commands...but that makes sense if they're deleted after each test, right?

austin (Thu, 26 Oct 2017 20:48:03 GMT):
right, of course. I thought you were looking at the second question of the 204. I'll rerun without the delete

srottem (Thu, 26 Oct 2017 20:50:47 GMT):
As for the WalletNotFoundError you're getting, it's because before you call the proverCreateAndStoreClaimReq expects that you have already run other commands against the wallet to get it to a state where it contains the required values (e.g. proverCreateMasterSecret and proverStoreClaimOffer).

austin (Thu, 26 Oct 2017 20:51:22 GMT):
that was the issue. By deleting the previous runs there was something missing from the wallet that was required in `proverCreateAndStoreClaimReq`

srottem (Thu, 26 Oct 2017 20:51:34 GMT):
Yep!

austin (Thu, 26 Oct 2017 20:51:46 GMT):
good! so.... a few questions why was the error "unable to open wallet"?

austin (Thu, 26 Oct 2017 20:52:00 GMT):
and when do I need to clean up the wallets?

austin (Thu, 26 Oct 2017 20:52:36 GMT):
if I build many secrets and schemas and claimDefs will that cause a problem ^^

srottem (Thu, 26 Oct 2017 20:52:48 GMT):
In a real-world situation? When you no longer want any of the data in it. Think of it as being like throwing away the wallet it your pocket - you wouldn't do it very often. :)

srottem (Thu, 26 Oct 2017 20:52:48 GMT):
In a real-world situation? When you no longer want any of the data in it. Think of it as being like throwing away the wallet in your pocket - you wouldn't do it very often. :)

austin (Thu, 26 Oct 2017 20:53:14 GMT):
good enough analogy for me :)

austin (Thu, 26 Oct 2017 20:53:29 GMT):
awesome! thank you very much, that saved me a bunch of time

srottem (Thu, 26 Oct 2017 20:53:52 GMT):
Its basically the persistent storage for records of your key-pairs, claims, etc.

srottem (Thu, 26 Oct 2017 20:53:53 GMT):
My pleasure.

srottem (Thu, 26 Oct 2017 20:55:03 GMT):
Quick question for you - the syntax in the Java you've used is different to the one I'm familiar with...what version did the var and val keywords arrive in?

srottem (Thu, 26 Oct 2017 20:55:17 GMT):
(then again, I'm really a .NET guy)

austin (Thu, 26 Oct 2017 20:57:34 GMT):
oh right, we're using Kotlin which compiles into the JVM. It is a much more concise version of Java yet is compatible with all the legacy and power Java brings: https://kotlinlang.org/

srottem (Thu, 26 Oct 2017 20:57:48 GMT):
Looks nice!

austin (Thu, 26 Oct 2017 20:57:50 GMT):
It is becoming the language of choice for Android going forward

srottem (Thu, 26 Oct 2017 20:57:59 GMT):
Gotcha.

austin (Thu, 26 Oct 2017 20:58:15 GMT):
I didn't know it a month ago and it was so easy I didn't even realize I had learned yet another programming language

srottem (Thu, 26 Oct 2017 20:58:39 GMT):
Feels kind of like C# to me.. ;)

austin (Thu, 26 Oct 2017 20:59:06 GMT):
all the languages are becoming more and more the same

austin (Thu, 26 Oct 2017 20:59:18 GMT):
it's kind of nice (in my opinion)

srottem (Fri, 27 Oct 2017 11:38:43 GMT):
I'm seeing a failure in the test "testKeyForDidWorksForTheirDid" - the call to Signus.keyForDid is returning WalletValueNotFoundException but the test should pass. Any ideas why?

sklump (Fri, 27 Oct 2017 11:38:45 GMT):
They all are looking more like python to me ...

srottem (Fri, 27 Oct 2017 12:17:59 GMT):
Never mind - I must have had an out of date build of the SDK - all tests passing now.

sklump (Fri, 27 Oct 2017 17:50:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=FpfP92myWf9m6qPdY) @srottem Is prover_store_claim_offer() necessary? Any idea what it does? I hadn't used it and I never had problems ... except now I see I'm getting: ```ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid library state: Unexpected SQLite error: no such table: wallet D ```

sklump (Fri, 27 Oct 2017 19:16:03 GMT):
I am assuming that, at the Prover, one claim_offer suffices per schema seq_no and (claim) issuer_did -- I don't have to rewrite a new claim offer for each individual claim. Correct?

srottem (Fri, 27 Oct 2017 20:28:53 GMT):
I assume prover_store_claim_offer was required before calling indy_prover_create_and_store_claim_req because the call to the latter expects parameter values that include information from data stored by the former (obtained by calling indy_prover_get_claim_offers). I'm basing all of this on the Anoncreds demo tests rather than knowing absolutely, so I could be off base.

srottem (Fri, 27 Oct 2017 20:38:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=f5WwjWyovAkcaSdar) @sklump I have to admit ignorance on this score. From the demo code it doesn't look like the issuer has to register or create a claim offer before the prover stores it, so presumably the idea is that the issuer simply constructs a single structure to say "I can issue claims with this schema" and the prover can then register that so they can generate requests for claims to be issued to them by that issuer that match that schema (using indy_prover_create_and_store_claim_req). Once the issuer receives the request from the prover then the issuer can generate the actual claim and provide it to the prover to store.

srottem (Fri, 27 Oct 2017 20:38:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=f5WwjWyovAkcaSdar) @sklump I have to admit ignorance on this score. From the demo code it doesn't look like the issuer has to register or create a claim offer before the prover stores it, so presumably the idea is that the issuer simply constructs a single structure to say "I can issue claims with this schema" and the prover can then register that. Once registered the prover can generate requests for claims to be issued to them by that issuer that match that schema (using indy_prover_create_and_store_claim_req). Once the issuer receives the request from the prover then the issuer can generate the actual claim and provide it to the prover to store in their wallet.

srottem (Fri, 27 Oct 2017 20:40:27 GMT):
Btw, your error saying "no such table: wallet" would seem to indicate that the wallet doesn't actually exist when you're making the indy call - maybe it's getting deleted at some point?

sklump (Fri, 27 Oct 2017 20:44:13 GMT):
I think that's what's happened -- it's gone away since turned off all the cleanup in conftest.py, since it cleans up the whole ~/.indy_client directory recursively. It looks like one claim_offer is good for any number of claims on a (claim) issuer and schema sequence number. Hurray for that! It's not clear whether that's what helped, or whether it was another problem, but it certainly does no harm to follow the diagram completely.

sklump (Mon, 30 Oct 2017 17:51:02 GMT):
Quick Question: if a Prover throws away his wallet and starts a new one, what happens to his master secret? Should the prover be able to recreate the same on on the same label and put it into his new wallet?

sklump (Mon, 30 Oct 2017 17:51:02 GMT):
Item: if a Prover throws away his wallet and starts a new one, remember to re-create the master secret. It appears to be OK to reuse the same label in a new wallet.

sklump (Mon, 30 Oct 2017 17:51:43 GMT):
Or is it even necessary -- does the secret go 'in' the wallet or does it just take info from the wallet (e.g., DID) and live somewhere else in the sdk?

srottem (Mon, 30 Oct 2017 21:38:13 GMT):
I believe a master secret is a value that is stored in the wallet and is retrieved using the key name it was registered with. The .NET and Java wrappers have some code that exercises a custom walllet implementation which seems to bear that out.

turmewr3ck (Tue, 31 Oct 2017 09:12:56 GMT):
The Hyperledger Wiki for Indy seems to suggest that one should use a Vagrantfile from the Evernym repository in order to setup a developer environment ("Setting up a DEV Environment with Vagrant"). Is this currently the only official way, or is there alternative developer setup guides elsewhere for, e.g., non-VM (bare metal) environments?

turmewr3ck (Tue, 31 Oct 2017 09:12:56 GMT):
The Hyperledger Wiki for Indy seems to suggest that one should use a Vagrantfile from the Evernym repository in order to setup a developer environment ("Setting up a DEV Environment with Vagrant"). Is this currently the only official way, or are there alternative developer setup guides elsewhere for, e.g., non-VM (bare metal) environments?

turmewr3ck (Tue, 31 Oct 2017 09:12:56 GMT):
The Hyperledger Wiki for Indy seems to suggest that one should use a Vagrantfile from the Evernym repository in order to setup a developer environment ("Setting up a DEV Environment with Vagrant"). Is this currently the only official way, or are there alternative developer setup guides elsewhere for, e.g., non-VM (bare metal), or even Docker developer environments?

DibbsZA (Tue, 31 Oct 2017 13:13:52 GMT):
Hi guys. Has anyone tried compiling libindy for the Android (ARM) architecture?

DibbsZA (Tue, 31 Oct 2017 13:13:52 GMT):
Hi guys. Has anyone tried compiling libindy for the Android (ARM) architecture? Was trying to build an app with the java wrapper, but the linbindy.so should be targeting that platform should it not?

mgbailey (Tue, 31 Oct 2017 13:57:58 GMT):
@turmewr3ck There are docker instructions as well, that many people use. I tend not to pay as much attention to these, so I don't know their current state.

srottem (Tue, 31 Oct 2017 14:00:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aHZxuzAsdhcKAk6cz) @DibbsZA Correct - a libindy.so for the specific platform will be required in order to use the Java wrapper. I'm not aware of any ARM build but @gudkov indicated in an earlier discussion on this channel that he thinks it should be possible. As soon as there is one I'd be happy to experiment with it, but I don't have an environment set up for building anywhere other than Windows at the moment.

srottem (Tue, 31 Oct 2017 14:02:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=vH5oCwNNQmME8NQGT) I use the docker container from the indy-sdk's ci folder for testing.

srottem (Tue, 31 Oct 2017 14:02:46 GMT):
Pretty straight forward to get up an running.

sklump (Tue, 31 Oct 2017 17:02:34 GMT):
Hi, I notice that create_and_store_my_did() stopped returning the public (encryption) key in signus.py. Why?

sklump (Tue, 31 Oct 2017 17:03:01 GMT):
It's still in the comments, just not in the code. Is it on purpose?

sklump (Tue, 31 Oct 2017 17:06:52 GMT):
_(similarly for replace_keys_start()) ... I sense this is part of a bigger picture ?

sklump (Tue, 31 Oct 2017 17:06:52 GMT):
(similarly for replace_keys_start()) ... I sense this is part of a bigger picture ?

sklump (Tue, 31 Oct 2017 17:13:25 GMT):
... the endpoint attribute in build_attrib_request has lost the host and port! *Now I start caring.* We need to put a host and port into the endpoint attribution.

sklump (Tue, 31 Oct 2017 17:23:38 GMT):
... unless I've misunderstood the new comment, line 218, ledger.py: ``` :param raw: represented as json, where key is attribute name and value is it's value ``` ? Could any key and any value do?

sklump (Tue, 31 Oct 2017 17:41:00 GMT):
... worse, the schema that comes back from ledger.submit_request() doesn't seem to include its attr_names anymore?? Where can I get them now? This is an unpleasant surprise.

sklump (Wed, 01 Nov 2017 13:01:31 GMT):
A number of important changes in data structures have occurred between 1.0.0.dev-234 and 1.0.0.dev-239. Now I can't seem to get libindy to complete a callback to do with the ledger. Example follows, but there are enough others like it: ``` DEBUG || indy.ledger || build_nym_request: >>> submitter_did: 'V4SGRU86Z58d6TV7PBUe6f', target_did: 'FaBAq1W5QTVDpAZtep6h19', ver_key: '8wefCF1dBBeuCL1BR9QFRvvLmDQBF3fmHeGzbmDw1HdD', alias: None, role: None DEBUG || indy.ledger || build_nym_request: Creating callback DEBUG || indy.libindy || create_cb: >>> cb_type: .CFunctionType'> DEBUG || indy.libindy || create_cb: <<< res: DEBUG || indy.libindy || do_call: >>> name: indy_build_nym_request, args: (c_char_p(140465832583808), c_char_p(140465832583640), c_char_p(140465832999424), None, None, )``` The execution drops dead right here. I have no idea what changed. I have specified RUST_LOG=debug RUST_TRACEBACK=full and this is it.

sklump (Wed, 01 Nov 2017 13:01:31 GMT):
A number of important changes in data structures have occurred between 1.0.0.dev-234 and 1.0.0.dev-239. Possible side effect: now I can't seem to get libindy to complete a callback to do with the ledger. Example follows, but there are enough others like it: ``` DEBUG || indy.ledger || build_nym_request: >>> submitter_did: 'V4SGRU86Z58d6TV7PBUe6f', target_did: 'FaBAq1W5QTVDpAZtep6h19', ver_key: '8wefCF1dBBeuCL1BR9QFRvvLmDQBF3fmHeGzbmDw1HdD', alias: None, role: None DEBUG || indy.ledger || build_nym_request: Creating callback DEBUG || indy.libindy || create_cb: >>> cb_type: .CFunctionType'> DEBUG || indy.libindy || create_cb: <<< res: DEBUG || indy.libindy || do_call: >>> name: indy_build_nym_request, args: (c_char_p(140465832583808), c_char_p(140465832583640), c_char_p(140465832999424), None, None, )``` The execution drops dead right here. I have no idea what changed. I have specified RUST_LOG=debug RUST_TRACEBACK=full and this is it. I have a demo in a couple of hours, I hate to tell the world not to use the most recent version, especially as it drifts away from what I got working before.

sklump (Wed, 01 Nov 2017 13:47:44 GMT):
OK, so I'm troubleshooting this new problem I've been having. When I call a ledger.py function from django, I get: ``` File "/home/sklump/venv/py35/lib/python3.5/site-packages/indy/ledger.py", line 200, in build_nym_request build_nym_request.cb) File "/home/sklump/venv/py35/lib/python3.5/site-packages/indy/libindy.py", line 18, in do_call event_loop = asyncio.get_event_loop() File "/usr/lib/python3.5/asyncio/events.py", line 632, in get_event_loop return get_event_loop_policy().get_event_loop() File "/usr/lib/python3.5/asyncio/events.py", line 578, in get_event_loop % threading.current_thread().name) RuntimeError: There is no current event loop in thread 'Thread-3'. [01/Nov/2017 13:45:14] "POST /api/v0/agent-nym-send HTTP/1.1" 500 83 ``` This was fine with python3-indy.1.0.0.dev-234, and broken with dev-239. Yet I can't see any code change. I am kind of blown away here. Any thoughts?

sklump (Wed, 01 Nov 2017 20:09:46 GMT):
I've tried to get to a working configuration on a new VM, and now I get a segmentation fault when I try to use the `signus.create_and_store_my_did()` call from v1.0.0.dev-234. It must be trying to use an underlying rust library that is not compatible -- can anyone tell me what I should be looking for so that I can demonstrate code that worked a week ago on a new installation? I have looked around pypi and I don't see any history logs -- maybe it's obvious but not to me.

sklump (Wed, 01 Nov 2017 20:09:46 GMT):
I've tried to get to a working configuration on a new VM, and now I get a segmentation fault when I try to use the `signus.create_and_store_my_did()` call from v1.0.0.dev-234. It must be trying to use an underlying rust library that is not compatible -- can anyone tell me what I should be looking for so that I can demonstrate code that worked a week ago on a new installation? In particular, I am looking for three parameters (did, verkey, pubkey) to come back from `signus.create_and_store_my_did()` where maybe it is giving back 2. I have looked around pypi and I don't see any history logs -- maybe it's obvious but not to me.

turmewr3ck (Thu, 02 Nov 2017 10:22:07 GMT):
Does someone have a minimal guide for setting up a basic developer environment based on Docker? Have succeeded using the ci/indy-pool.dockerfile, but running the pytest in wrappers/python give many errors, one of which suggest that there is a dependency on libindy.so (not built I guess). What am I missing? (Running the container with indy-sdk mounted.)

srottem (Thu, 02 Nov 2017 10:44:36 GMT):
There are build instructions for several platforms on the indy-sdk github repo: https://github.com/hyperledger/indy-sdk

srottem (Thu, 02 Nov 2017 10:47:37 GMT):
The ci docker file is for running your node pool - you still have to build libindy and whatever wrapper you plan on using for the platform you're execute your code from.

srottem (Thu, 02 Nov 2017 10:48:32 GMT):
I'm working under Windows so the amount of help I can provide may be limited, but I'm happy to lend a hand where I can.

sklump (Thu, 02 Nov 2017 19:35:08 GMT):
OK, I've found a libindy.so that works fine with the python site-package I'm using. I am back to this: ``` File "/home/sklump/venv/py35/lib/python3.5/site-packages/indy/ledger.py", line 385, in build_get_schema_request build_get_schema_request.cb) File "/home/sklump/venv/py35/lib/python3.5/site-packages/indy/libindy.py", line 18, in do_call event_loop = asyncio.get_event_loop() File "/usr/lib/python3.5/asyncio/events.py", line 632, in get_event_loop return get_event_loop_policy().get_event_loop() File "/usr/lib/python3.5/asyncio/events.py", line 578, in get_event_loop % threading.current_thread().name) RuntimeError: There is no current event loop in thread 'Thread-2'. ``` Lookit, I'm not above admitting I am not the smartest guy in the room with asyncio. Does anyone know a way to make sure that the event loop is available to the indy-sdk?

sklump (Thu, 02 Nov 2017 20:28:41 GMT):
Hurray! I think I got it! Don't store the event loop as a global in the main thread, call for it fresh every time and if it's not there, create it and put it there.

sklump (Thu, 02 Nov 2017 20:29:12 GMT):
Next item for understanding: what the hell is a greenlet ? :-D

Suedonym (Thu, 02 Nov 2017 21:38:42 GMT):
@sklump https://greenlet.readthedocs.io/en/latest/

KhoiNgoLG (Fri, 03 Nov 2017 10:31:59 GMT):
Has joined the channel.

turmewr3ck (Fri, 03 Nov 2017 10:32:52 GMT):
@sklump now you got me curious. What are you using greenlets for? :)

KhoiNgoLG (Fri, 03 Nov 2017 10:32:57 GMT):
Hi all We plan to automate acceptance test for indy-sdk by python. For storing source code, I would like to place it in the 'https://github.com/hyperledger/indy-node/tree/master/acceptance/indy_acceptance' folder. Do you have any idea?

alexeykoren (Fri, 03 Nov 2017 11:15:58 GMT):
Has joined the channel.

nghia47 (Fri, 03 Nov 2017 11:55:49 GMT):
Has joined the channel.

chinh.do (Fri, 03 Nov 2017 13:10:06 GMT):
Has joined the channel.

sergey.minaev (Fri, 03 Nov 2017 17:50:06 GMT):
@ashcherbakov @gudkov ^

sergey.minaev (Fri, 03 Nov 2017 17:53:44 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done during last week: Completed issues: IS-364: iOS Wrapper: Fix State Proof related regressions in iOS wrapper tests iOS Wrapper IS-388: Unable to connect to pool with libindy if genesis file has quotes around port numbers IS-390: Pool API: implement building pool state from pool transactions IS-395: Crypto: Implement crypto methods for keys-based cryptography IS-396: Crypto: Python wrapper for generic crypto methods IS-397: Crypto: Java wrapper for generic crypto methods IS-400: Crypto: Integration tests for generic crypto methods IS-402: State Proof: Support timestamp in muli-signature In-progress issue: IS-394: Agent API: Support new key management and agents communication approach in iOS wrapper - iOS wrapper ready, new tests are in development state

ashcherbakov (Fri, 03 Nov 2017 17:55:19 GMT):
@KhoiNgoLG Are you planning to automate the tests for acceptance of indy-node (using indy-sdk)? If so, thne this is a fine folder. If you are planning to have tests for acceptance of indy-sdk, then I think it's probably better to put them into indy-sdk folder. In general, we should have acceptance tests for the following scenarious: 1) Make sure that a new release of indy-node works with all (or some number of latest) releases of indy-sdk 2) Make sure that a new release of indy-sdk works with the latest indy-node

ashcherbakov (Fri, 03 Nov 2017 17:55:19 GMT):
@KhoiNgoLG Are you planning to automate the tests for acceptance of indy-node (using indy-sdk)? If so, then this is a fine folder. If you are planning to have tests for acceptance of indy-sdk, then I think it's probably better to put them into indy-sdk folder. In general, we should have acceptance tests for the following scenarious: 1) Make sure that a new release of indy-node works with all (or some number of latest) releases of indy-sdk 2) Make sure that a new release of indy-sdk works with the latest indy-node

mark.hadley (Fri, 03 Nov 2017 20:20:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=7qmAKerANjf3SSeH6) @turmewr3ck I also would like to know more.

sklump (Sun, 05 Nov 2017 13:45:55 GMT):
nothing as such -- when I first encountered them, my thought was, "that's just not a word: try harder."

turmewr3ck (Mon, 06 Nov 2017 15:04:03 GMT):
Does the indy-sdk/samples/python example work currently on "master"? Getting a: ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid structure: Invalid schema json: missing field `attr_names` at line 1 column 96

sergey.minaev (Tue, 07 Nov 2017 09:17:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=W3AkDYNM5M7b6uvL8) @turmewr3ck Last time samples were tested on RC branch. On master branch it should works, but not tested manually or while CI. So If you see errors, please create issue in our [jira](https://jira.hyperledger.org/projects/IS/issues/)

smithbk (Wed, 08 Nov 2017 07:25:37 GMT):
Has joined the channel.

gudkov (Thu, 09 Nov 2017 09:18:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qJ74C2DpHM3ho3Frw) It is strange to put indy-sdk tests to indy-node repo. We already have some tests started in https://github.com/hyperledger/indy-sdk/tree/master/samples

ianco (Thu, 09 Nov 2017 21:49:57 GMT):
Has joined the channel.

swlcanderson (Fri, 10 Nov 2017 21:21:51 GMT):
Has joined the channel.

KhoiNgoLG (Mon, 13 Nov 2017 03:43:14 GMT):
Thanks all. @ashcherbakov We will push it to the 'https://github.com/hyperledger/indy-node/tree/master/acceptance/indy_acceptance' folder with master branch. Is it OK?

sergey.minaev (Mon, 13 Nov 2017 06:55:28 GMT):
Here's what our team that's working on the c-callable Indy-sdk got done during last week: *Releasing stable version 1.1.0* with new Agent2Agent, Crypto and updated Signus APIs. (IS-411, IS-419) - IS-369 Fix MacOS build. - IS-394 IS-398 Finish iOS wrapper, create and publish new libindy pod. Update iOS tests (IS-409 IS-410) Also, in master branch: IS-416 Signus: Support Ledgerless DIDs

sydi (Mon, 13 Nov 2017 13:06:27 GMT):
Has joined the channel.

ashcherbakov (Tue, 14 Nov 2017 09:05:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kFn4nPTztzhba2i29) @KhoiNgoLG [ ](https://chat.hyperledger.org/channel/indy-sdk?msg=BZ6rKc7Ng7p8ivXpm)

dv29 (Tue, 14 Nov 2017 10:59:18 GMT):
Has joined the channel.

turmewr3ck (Wed, 15 Nov 2017 09:49:59 GMT):
Is the following supposed to work, or do I need to do something extra? docker build -f ci/indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9708:9701-9708 indy_pool docker exec -it bash indy indy> connect sandbox However, this just writes some help text with, and an empty list of networks.

turmewr3ck (Wed, 15 Nov 2017 09:49:59 GMT):
Is the following supposed to work (on indy-sdk master), or do I need to do something extra? docker build -f ci/indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9708:9701-9708 indy_pool docker exec -it bash indy indy> connect sandbox However, this just writes some help text, and an empty list of networks.

gudkov (Wed, 15 Nov 2017 12:21:44 GMT):
@turmewr3ck What are you tryingto achieve?

gudkov (Wed, 15 Nov 2017 12:21:44 GMT):
@turmewr3ck What are you trying to achieve?

turmewr3ck (Wed, 15 Nov 2017 12:25:01 GMT):
Trying to explore the different possibilities to invoke the ledger CLI. For instance, once is based on: https://github.com/evernym/sovrin-environments/tree/stable/docker But I don't think I have a simple way of doing this in Indy. I do not aim to run the tutorial with agents. Just basic CLI access in a simplest possible way.

turmewr3ck (Wed, 15 Nov 2017 12:25:01 GMT):
Trying to explore the different possibilities to invoke the ledger CLI. For instance, one is based on: https://github.com/evernym/sovrin-environments/tree/stable/docker But I don't think I have a simple way of doing this in Indy. I do not aim to run the tutorial with agents. Just basic CLI access in a simplest possible way.

ashcherbakov (Wed, 15 Nov 2017 13:39:02 GMT):
You can run CLI in docker: 1) Start Pool: `./pool_start.sh` 2) Start CLI for this pool: `./client_for_pool_start.sh`

turmewr3ck (Wed, 15 Nov 2017 14:38:50 GMT):
The above comes from a Sovrin repo. Is there something just as simple using the Hyperledger repo solely?

mountbranch (Wed, 15 Nov 2017 17:15:21 GMT):
Has joined the channel.

josepsan (Wed, 15 Nov 2017 17:31:48 GMT):
Has joined the channel.

anttikettunen (Thu, 16 Nov 2017 08:00:02 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wyv9M7PrSabK6ji8L) @turmewr3ck Have you tried this: https://github.com/brycecurtis/indy-tutorial-sandbox ? It was shared at the #indy-agent channel by @mgbailey

mountbranch (Thu, 16 Nov 2017 08:07:01 GMT):
@sergey.minaev I'm still having the problems from IS-369. What was the fix?

turmewr3ck (Thu, 16 Nov 2017 08:36:15 GMT):
@anttikettunen Not yet. I wanted a little more solid ground at that point in time. My original question was actually if the CLI (indy script) is expected to work when building from ci/indy-pool.dockerfile. That seemed to me to be a useful debugging tool when making wrapper experiments in a, say, libindy dev container.

gudkov (Thu, 16 Nov 2017 09:04:20 GMT):
@mountbranch > I'm still having the problems from IS-369. What was the fix? We replaced some dependencies with different ones that don't require heapsize crate that doesn't work on MacOS. What exact error you have?

mountbranch (Thu, 16 Nov 2017 09:11:40 GMT):
```

mountbranch (Thu, 16 Nov 2017 09:11:40 GMT):
``` = note: Undefined symbols for architecture x86_64: "_crypto_stream_aes128ctr_xor", referenced from: sodiumoxide::crypto::stream::aes128ctr::stream_xor::hb355e452762fc249 in libsodiumoxide-1cdc0f7f784b6550.rlib(sodiumoxide-1cdc0f7f784b6550.0.o) sodiumoxide::crypto::stream::aes128ctr::stream_xor_inplace::haf5a428a0e4d3a8a in libsodiumoxide-1cdc0f7f784b6550.rlib(sodiumoxide-1cdc0f7f784b6550.0.o) "_crypto_stream_aes128ctr", referenced from: sodiumoxide::crypto::stream::aes128ctr::stream::h35020c8b80ef1d7a in libsodiumoxide-1cdc0f7f784b6550.rlib(sodiumoxide-1cdc0f7f784b6550.0.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) error: aborting due to previous error error: Could not compile `indy`. To learn more, run the command again with --verbose. ```

mountbranch (Thu, 16 Nov 2017 10:28:33 GMT):
@gudkov Is there some solution?

mountbranch (Thu, 16 Nov 2017 10:28:50 GMT):
the actual error is

mountbranch (Thu, 16 Nov 2017 10:28:56 GMT):
``` error: linking with `cc` failed: exit code: 1 ```

gudkov (Thu, 16 Nov 2017 12:01:55 GMT):
@mountbranch It is the different problem than IS-369. You need to downgrade libsodium to 1.0.12 (seems 1.0.15 you have is incompatible with rust wrapper). Could you check and update https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md in case of success?

mountbranch (Thu, 16 Nov 2017 12:34:15 GMT):
Not sure how to `brew install` the old version. Any tips?

sergey.minaev (Thu, 16 Nov 2017 12:34:35 GMT):
`brew install `

sergey.minaev (Thu, 16 Nov 2017 12:36:16 GMT):
`brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/65effd2b617bade68a8a2c5b39e1c3089cc0e945/Formula/libsodium.rb`

sergey.minaev (Thu, 16 Nov 2017 12:38:01 GMT):
after install, `brew switch` will work if you want to use latest libsodium for another project

mountbranch (Thu, 16 Nov 2017 12:41:32 GMT):
I'm still getting this, but it's just a warning

mountbranch (Thu, 16 Nov 2017 12:41:39 GMT):
``` | => cargo build Compiling indy v1.1.0 (file:///Users/jonatan/Documents/C8/indy-sdk/libindy) warning: variable does not need to be mutable --> src/services/pool/catchup.rs:212:13 | 212 | let mut process = self.pending_catchup.as_mut() | ^^^^^^^^^^^ | = note: #[warn(unused_mut)] on by default ```

mountbranch (Thu, 16 Nov 2017 12:41:39 GMT):
``` | => cargo build Compiling indy v1.1.0 (file:///Users/user/folder/dolfer/indy-sdk/libindy) warning: variable does not need to be mutable --> src/services/pool/catchup.rs:212:13 | 212 | let mut process = self.pending_catchup.as_mut() | ^^^^^^^^^^^ | = note: #[warn(unused_mut)] on by default ```

sergey.minaev (Thu, 16 Nov 2017 12:42:10 GMT):
this warning was fixed by PR 383 merge

sergey.minaev (Thu, 16 Nov 2017 12:42:17 GMT):
just update master

sergey.minaev (Thu, 16 Nov 2017 12:44:01 GMT):
or if you use stable branch, just ignore this warning

sergey.minaev (Thu, 16 Nov 2017 12:44:01 GMT):
or if you use RC branch (stable tag), just ignore this warning

sergey.minaev (Thu, 16 Nov 2017 12:45:43 GMT):
AFAIR linking error after downgrade to 1 0 12 can still present until full re-build

sergey.minaev (Thu, 16 Nov 2017 12:45:43 GMT):
AFAIR linking error after downgrade to libsodium 1.0.12 can still present until full re-build

mountbranch (Thu, 16 Nov 2017 12:46:16 GMT):
I'm not getting any errors upon build!

mountbranch (Thu, 16 Nov 2017 12:56:05 GMT):
Created a PR

mountbranch (Thu, 16 Nov 2017 12:57:31 GMT):
Thanks for the help

nbrempel (Fri, 17 Nov 2017 01:54:16 GMT):
Hi folks, I'm seeing the following error intermittently and, for the life of me, I can't figure out why it happens. It occurs while using the indy-sdk python wrapper to connect to a node pool. The `pool.open_pool_ledger` throws the following error: `ERROR|indy::services::pool | src/services/pool/mod.rs:778 | Pool worker thread finished with error CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree."))`. I have two node pools running, one on a remote server and one locally — both in 4 docker containers. The code is identical and the docker containers are identical on both machines. The only difference is that my host machine is a mac and the remote host is ubuntu 16.04. It works when connecting to the remote machine, but throws the error when connecting to a local node pool (connects internally through docker network). The thing is: yesterday the opposite was true and it worked fine locally but wouldn't work on the remote machine. Any insight would be helpful.

nbrempel Here's the entire snippet: ``` INFO|command_executor INFO|indy::commands INFO|pool_command_executor _indy_loop_callback: INFO|indy::commands INFO|pool_command_executor INFO|indy::services::pool INFO|indy::services::pool INFO|indy::services::pool INFO|indy::services::pool INFO|indy::services::pool INFO|indy::services::pool INFO|indy::services::pool INFO|indy::services::pool INFO|indy::services::pool INFO|indy::services::pool INFO|indy::services::pool INFO|indy::services::pool INFO|indy::services::pool ERROR|indy::services::pool INFO|indy::commands INFO|indy::commands::pool ERROR|indy::errors::indy ``` (Fri, 17 Nov 2017 01:55:21 GMT):
| src/commands/mod.rs:71 | Worker thread started | src/commands/mod.rs:107 | PoolCommand command received | src/commands/pool.rs:54 | Create command received Function returned None | src/commands/mod.rs:107 | PoolCommand command received | src/commands/pool.rs:62 | Open command received | src/services/pool/mod.rs:891 | Sending "pi" | src/services/pool/mod.rs:891 | Sending "pi" | src/services/pool/mod.rs:891 | Sending "pi" | src/services/pool/mod.rs:891 | Sending "pi" | src/services/pool/mod.rs:885 | RemoteNode::recv_msg Node1 po | src/services/pool/mod.rs:891 | Sending "{\"op\":\"LEDGER_STATUS\",\"txnSeqNo\":4,\"merkleRoot\":\"GMMzJuus7X785Km3njeae8oTNyHYQ94CvawFgBucSaAf\",\"ledgerId\":0,\"ppSeqNo\":null,\"viewNo\":null}" | src/services/pool/mod.rs:885 | RemoteNode::recv_msg Node2 po | src/services/pool/mod.rs:885 | RemoteNode::recv_msg Node4 po | src/services/pool/mod.rs:891 | Sending "{\"op\":\"LEDGER_STATUS\",\"txnSeqNo\":4,\"merkleRoot\":\"GMMzJuus7X785Km3njeae8oTNyHYQ94CvawFgBucSaAf\",\"ledgerId\":0,\"ppSeqNo\":null,\"viewNo\":null}" | src/services/pool/mod.rs:891 | Sending "{\"op\":\"LEDGER_STATUS\",\"txnSeqNo\":4,\"merkleRoot\":\"GMMzJuus7X785Km3njeae8oTNyHYQ94CvawFgBucSaAf\",\"ledgerId\":0,\"ppSeqNo\":null,\"viewNo\":null}" | src/services/pool/mod.rs:885 | RemoteNode::recv_msg Node1 {"merkleRoot":"33So5M1phhZSV7uSG6dg1ZnbqCsCcGfCV8vHt8pBs5dz","ppSeqNo":null,"ledgerId":0,"txnSeqNo":4,"op":"LEDGER_STATUS","viewNo":null} | src/services/pool/mod.rs:885 | RemoteNode::recv_msg Node2 {"ledgerId":0,"txnSeqNo":4,"viewNo":null,"ppSeqNo":null,"merkleRoot":"33So5M1phhZSV7uSG6dg1ZnbqCsCcGfCV8vHt8pBs5dz","op":"LEDGER_STATUS"} | src/services/pool/mod.rs:885 | RemoteNode::recv_msg Node4 {"viewNo":null,"merkleRoot":"33So5M1phhZSV7uSG6dg1ZnbqCsCcGfCV8vHt8pBs5dz","txnSeqNo":4,"ppSeqNo":null,"ledgerId":0,"op":"LEDGER_STATUS"} | src/services/pool/mod.rs:778 | Pool worker thread finished with error CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree.")) | src/commands/mod.rs:107 | PoolCommand command received | src/commands/pool.rs:66 | OpenAck handle 1, result Err(Terminate) | src/errors/indy.rs:63 | Casting error to ErrorCode: Pool work terminated

nbrempel (Fri, 17 Nov 2017 01:56:43 GMT):
It is the same error as this closed ticket but I'm using newer versions of the software. https://jira.hyperledger.org/browse/IS-355?page=com.atlassian.streams.streams-jira-plugin:activity-stream-issue-tab

nbrempel (Fri, 17 Nov 2017 02:37:55 GMT):
I can confirm that it is an intermittent issue. After restarting the node pool several times, I was able to connect.

nbrempel (Fri, 17 Nov 2017 02:38:14 GMT):
Any help on this would be appreciated!

gudkov (Fri, 17 Nov 2017 07:14:45 GMT):
@nbrempel Are you sure that you use the same IPs to connect to nodes as nodes to connect each other. The obvious difference between Mac and Ubuntu environment with docker is that on Mac docker is executed inside VM and there is no network interface sharing with the host.

gudkov (Fri, 17 Nov 2017 07:22:33 GMT):
The only working way to execute test pool on the Mac inside docker and connect to this pool from the host is the following: 1. Execute ALL nodes inside one container and use 127.0.0.1 ips in genesis transactions file (the Dockerfile in indy-sdk repo works this way) 2. Use Virtual Box port forwarding to map local 127.0.01 interface ports to corresponded ports of docker interface and use the same 127.0.0.1 ips in genesis transactions file.

sergey.minaev (Fri, 17 Nov 2017 12:54:52 GMT):
@nbrempel If you see `Ledger merkle tree doesn\'t acceptable for current tree.` it means, that genesis transactions passed to indy-sdk is different against genesis transaction of the pool.

sergey.minaev (Fri, 17 Nov 2017 12:54:52 GMT):
@nbrempel If you see `Ledger merkle tree doesn\'t acceptable for current tree.` it means, that genesis transactions passed to indy-sdk are different against genesis transaction of the pool.

sergey.minaev (Fri, 17 Nov 2017 12:58:45 GMT):
If you try to run indy-sdk tests, genesis transaction file is constructed from template and environment variable `TEST_POOL_IP`.

nbrempel (Fri, 17 Nov 2017 18:29:20 GMT):
Thanks for the help. I've discovered the problem. My docker-compose environment sometimes recreated containers which worked fine. But sometimes it would start existing stopped containers. In this case, it would run `generate_indy_pool_transactions` a second time with separate (correct) ip addresses and restart the node pool. So if you start the nodes, then stop the nodes and change the genesis transaction file, then start them again, the sdk cannot connect. The genesis transactions are correct for both environments, but since the ledger had already been created from the first genesis transaction file, I guess the node pool doesn't pick up the change. My solution: force container recreate on every run.

sergey.minaev (Mon, 20 Nov 2017 15:51:32 GMT):
@ashcherbakov Is it expected behavior for nodes ^?

nbrempel (Mon, 20 Nov 2017 17:03:37 GMT):
It's worth mentioning that the Indy CLI _could_ connect. But the SDK could not.

turmewr3ck (Wed, 22 Nov 2017 08:52:44 GMT):
Has the public_key been removed from the return value of indy_create_and_store_my_did? The documentation in indy_signus.h does not match the function type in that file.

sklump (Wed, 22 Nov 2017 12:53:09 GMT):
Yes, that was about a month ago, if I remember correctly.

panickervinod (Wed, 22 Nov 2017 13:44:43 GMT):
Has joined the channel.

prmdmshra (Wed, 22 Nov 2017 14:04:16 GMT):
Has joined the channel.

prmdmshra (Wed, 22 Nov 2017 14:05:40 GMT):
Hi All, I am receiving the following error on on running 'cargo build' command on Ubuntu 16.04. Could you please suggest(https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md) error: associated constants are experimental (see issue #29646) --> src/services/pool/state_proof.rs:42:5 | 42 | const IS_PATH_ODD_MASK: u8 = 0x10; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 6 previous errors error: Could not compile `indy`. Caused by: process didn't exit successfully: `rustc --crate-name indy src/lib.rs --crate-type staticlib --crate-type rlib --crate-type dylib --emit=dep-info,link -C debuginfo=2 --cfg feature="revocation_tests" --cfg feature="base58_rust_base58" --cfg feature="sodiumoxide" --cfg feature="xsalsa20_sodium" --cfg feature="default" --cfg feature="box_sodium" --cfg feature="indy-crypto" --cfg feature="int_traits" --cfg feature="openssl" --cfg feature="rust-base58" --cfg feature="bn_openssl" --cfg feature="sealedbox_sodium" --cfg feature="local_nodes_pool" --cfg feature="pair_amcl" --cfg feature="hash_openssl" -C metadata=8fc9a5eda7366d1d --out-dir /home/pwc/indy-sdk/libindy/target/debug/deps -L dependency=/home/pwc/indy-sdk/libindy/target/debug/deps --extern uuid=/home/pwc/indy-sdk/libindy/target/debug/deps/libuuid-1460efc7e5ef1449.rlib --extern serde_json=/home/pwc/indy-sdk/libindy/target/debug/deps/libserde_json-66bc5b22473a2da9.rlib --extern serde=/home/pwc/indy-sdk/libindy/target/debug/deps/libserde-dbef705b0e8b3baa.rlib --extern rust_base58=/home/pwc/indy-sdk/libindy/target/debug/deps/librust_base58-c9124ca1f38df88d.rlib --extern digest=/home/pwc/indy-sdk/libindy/target/debug/deps/libdigest-283ec9a9d7068277.rlib --extern serde_derive=/home/pwc/indy-sdk/libindy/target/debug/deps/libserde_derive-e534427a37413b0f.so --extern libc=/home/pwc/indy-sdk/libindy/target/debug/deps/liblibc-c6347de5fb5717e2.rlib --extern indy_crypto=/home/pwc/indy-sdk/libindy/target/debug/deps/libindy_crypto-1b0786044a259be4.rlib --extern indy_crypto=/home/pwc/indy-sdk/libindy/target/debug/deps/libindy_crypto-1b0786044a259be4.so --extern rmp_serde=/home/pwc/indy-sdk/libindy/target/debug/deps/librmp_serde-f0c77c29289ffe90.rlib --extern log=/home/pwc/indy-sdk/libindy/target/debug/deps/liblog-7b7c517a3d819ff1.rlib --extern openssl=/home/pwc/indy-sdk/libindy/target/debug/deps/libopenssl-d08cb218b4fb9dba.rlib --extern hex=/home/pwc/indy-sdk/libindy/target/debug/deps/libhex-800a4c871f111c78.rlib --extern rand=/home/pwc/indy-sdk/libindy/target/debug/deps/librand-bdf85f5985a0e6c6.rlib --extern sha2=/home/pwc/indy-sdk/libindy/target/debug/deps/libsha2-b3b0cc909bfe9d37.rlib --extern generic_array=/home/pwc/indy-sdk/libindy/target/debug/deps/libgeneric_array-c1cc6826ff83df31.rlib --extern byteorder=/home/pwc/indy-sdk/libindy/target/debug/deps/libbyteorder-f6a8d758e466f059.rlib --extern sodiumoxide=/home/pwc/indy-sdk/libindy/target/debug/deps/libsodiumoxide-d5b53ab0b46797ab.rlib --extern base64=/home/pwc/indy-sdk/libindy/target/debug/deps/libbase64-896fc0a4b9b17346.rlib --extern time=/home/pwc/indy-sdk/libindy/target/debug/deps/libtime-c37677e269e2f4c6.rlib --extern zmq_pw=/home/pwc/indy-sdk/libindy/target/debug/deps/libzmq_pw-9b1de4c75977908d.rlib --extern rusqlcipher=/home/pwc/indy-sdk/libindy/target/debug/deps/librusqlcipher-ad5aab71d6f06050.rlib --extern env_logger=/home/pwc/indy-sdk/libindy/target/debug/deps/libenv_logger-aa4d4cc99682f0cc.rlib --extern sha3=/home/pwc/indy-sdk/libindy/target/debug/deps/libsha3-a069de2860335a61.rlib --extern rlp=/home/pwc/indy-sdk/libindy/target/debug/deps/librlp-d1c8f53b15462b36.rlib --extern int_traits=/home/pwc/indy-sdk/libindy/target/debug/deps/libint_traits-f22a1c5c25ede7fa.rlib --extern lazy_static=/home/pwc/indy-sdk/libindy/target/debug/deps/liblazy_static-57bb0e3a8f50b226.rlib -L native=/usr/lib/x86_64-linux-gnu -L /home/pwc/indy-sdk/libindy/target/debug/build/zmq-pw-sys-6b80845a4550579a/out/pkg/lib -L native=/home/pwc/indy-sdk/libindy/target/debug/build/libsqlcipher-sys-c4a5d5cf24233789/out` (exit code: 101)

turmewr3ck (Wed, 22 Nov 2017 14:08:38 GMT):
@sklump where are such decisions logged and described?

sklump (Wed, 22 Nov 2017 14:57:15 GMT):
I found it by misadventure - there may be an official record? Perhaps one could follow the indy-pr-review channel?

gudkov (Wed, 22 Nov 2017 15:41:59 GMT):
> Has the public_key been removed from the return value of indy_create_and_store_my_did? The documentation in indy_signus.h does not match the function type in that file. Initially, there were 2 keys in "indy_create_and_store_my_did" verkey and pubkey. Actually, it was the same ed25519 key as pubkey can be calculated over verkey. The latest changes in libindy were related to providing of API for keys management. In this API keys are identified by verkey. pubkey was removed to don't break this identification uniqueness. You can use this verkey for both encryption and signatures creation.

gudkov (Wed, 22 Nov 2017 15:45:10 GMT):
So no libindy allows: - Create keys in the wallet. These keys are identified by verkey part. There is now API to perform encryption and signatures creation based on keys only (no need to involve DIDs) - Create DIDs in the wallet. When you create DID it causes creation of key for this DID. This key can be resolved by calling indy_key_for_did call or indy_key_for_local_did and used in any low level crypto functions that require keys.

gudkov (Wed, 22 Nov 2017 15:45:10 GMT):
Now libindy allows: - Create keys in the wallet. These keys are identified by verkey part. There is now API to perform encryption and signatures creation based on keys only (no need to involve DIDs) - Create DIDs in the wallet. When you create DID it causes creation of key for this DID. This key can be resolved by calling indy_key_for_did call or indy_key_for_local_did and used in any low level crypto functions that require keys.

gudkov (Wed, 22 Nov 2017 15:46:58 GMT):
These changes were anonsed on Identity WG and Agent WG calls. Seems documentation is outdated. We will fix this soon or you can create PR by yourself.

sklump (Wed, 22 Nov 2017 17:05:58 GMT):
Latest von_base installation and documentation adopts pipenv. No changes required in other repos, only in installation process - which the doc in von_base covers.

sergey.minaev (Wed, 22 Nov 2017 17:42:57 GMT):
@prmdmshra please update your Rust

darrell.odonnell (Thu, 23 Nov 2017 12:17:44 GMT):
@sklump was the decision to remove the public key logged in the HL JIRA perhaps?

sklump (Thu, 23 Nov 2017 12:48:51 GMT):
Probably, somewhere. We didn't need it so I didn't pursue it.

sergey.minaev (Thu, 23 Nov 2017 12:56:38 GMT):
@gudkov ^

nbrempel (Thu, 23 Nov 2017 20:16:52 GMT):
I've noticed that the Wallet implementation in indy-sdk has the following restriction: "It is impossible to open wallet with the same name more than once." Is it possible to share this wallet across multiple processes, or is it designed only for a single process environment?

nbrempel (Thu, 23 Nov 2017 20:17:09 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/indy/wallet.py#L57

sklump (Thu, 23 Nov 2017 20:32:23 GMT):
It looks like the wallet corresponds to the file at `~/.indy_client/wallet/`, and so the second process in would be out of luck.

sergey.minaev (Mon, 27 Nov 2017 10:11:15 GMT):
@nbrempel you can try to share opened wallet handle. @gudkov please correct me about python

sergey.minaev (Mon, 27 Nov 2017 10:11:15 GMT):
@nbrempel you can try to share opened wallet handle to another *thread*. And it should be possible to use single file-system instance of default wallet in different system *processes* with different run-time instances of indy-sdk. @gudkov please correct me about python

gudkov (Mon, 27 Nov 2017 10:32:46 GMT):
@nbrempel > I've noticed that the Wallet implementation in indy-sdk has the following restriction: "It is impossible to open wallet with the same name more than once." Default wallet is sqlite based. It has some kind of based multiprocessing support. See https://sqlite.org/faq.html#q5. One process can open wallet only once, but you can try to work with one sqlite based wallet from different processes. If you really need concurrent access to one wallet you can register your custom wallet implementation with indy_register_wallet_type. For example, you can implement wallet with well-concurrent database engine like PostgreSQL.

gudkov (Mon, 27 Nov 2017 10:32:46 GMT):
@nbrempel > I've noticed that the Wallet implementation in indy-sdk has the following restriction: "It is impossible to open wallet with the same name more than once." Default wallet is sqlite based. It has some kind of basic multiprocessing support. See https://sqlite.org/faq.html#q5. One process can open wallet only once, but you can try to work with one sqlite based wallet from different processes. If you really need concurrent access to one wallet you can register your custom wallet implementation with indy_register_wallet_type. For example, you can implement wallet with well-concurrent database engine like PostgreSQL.

nbrempel (Mon, 27 Nov 2017 17:19:57 GMT):
Ok, @sergey.minaev @gudkov, thanks for the pointers. We'll do what we can for now with the SQLite wallet and move to a custom implementation when we can.

nbrempel (Tue, 28 Nov 2017 20:25:48 GMT):
I've noticed that when the Indy SDK cannot connect to a node pool, the process hangs indefinitely. Is there any plan to add a timeout or some sort of error to help debug problems that stem from connection problems?

sergey.minaev (Wed, 29 Nov 2017 10:49:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RnLR7t5WbGhbLwzde) @nbrempel yes, you are right. If sdk can't connect to nodes on open pool or on sending requests, result callback will never called. Ticket about timeout functionality is https://jira.hyperledger.org/browse/IS-123

jww (Wed, 29 Nov 2017 15:54:04 GMT):
Has joined the channel.

wittrock (Wed, 29 Nov 2017 18:55:38 GMT):
Has joined the channel.

arjanvaneersel (Thu, 30 Nov 2017 07:37:12 GMT):
Has joined the channel.

jljordan_bcgov (Thu, 30 Nov 2017 23:40:15 GMT):
My first verifiable claim that I issued Successfully generated payload and sent to TheOrgBook: {"claim":{"busId":["42","42"],"effectiveDate":["2010-10-01","292278025700124567423128235555255497804808729393"],"LegalName":["Awesome Sauce Maker Inc.","8033122303155280428434874686447689782578407877987860240799113586272831090593835131133619828492763892812579291214437"],"orgTypeId":["Corporation","19530356944638753635879935788333965953044081688327781"],"jurisdictionId":["Outer Rim","4564621053728639390792419526885890972005988"],"endDate":["None","3775483679542162997"]},"schema_seq_no":6,"signature":{"primary_claim":{"m2":"19088367672424418326534616450484907245328296592060315329786820321794134783571","a":"7325451003386988427379349614427505209347537793560493652123751114019007158910101799464547237590692685427142432459758138144528092514667963334510113863556941930395292044437156398533205015221027585060579573978171708041023375736146679664931344863790119458722640494399178824488194184532630034393142895444660808304772791383909358610224545857758453836678149656629654549700876504830146404734109190396426197785388550172474469395743862863293113913796316838241541933334264821965807143008255438601799705749834945774089366822224127070928721334849063686036084009523216069746758461170983380783831785088844949693485866596083399304801","e":"259344723055062059907025491480697571938277889515152306249728583105665800713306759149981690559193987143012367913206299323899696942213235956742929836722212797421437922170791966151861","v":"8134451626913033656498509956877978419934154068105678655725595627921039450411270358141930357075726309852522733717238646494676868746610151017655797381334545726691522836894451278414411040983464861538481493540273466373767762153955888895502937085864446281038225673090560971955858133605196786170401397628034097183637996572110880837253342897723616576247244292623780541659889607504894749286119241307929910229545188952232948964952681540001830141210052759779281576502788189334672825097834028246923353130521291198182800200877634329824065349023989110418497798001154211748624498860124146512746527347623874009048481774038414581571196396149590320322769143820023636856243019331858867307450753239344136208605463813684349983664464278852477704445934505147874052979238983595452764928217804512265598366922820218034515409966660946396451878251"},"non_revocation_claim":null},"issuer_did":"Q4zqM7aXqm7gDQkUVLng9h"}

jljordan_bcgov (Thu, 30 Nov 2017 23:40:47 GMT):
you can see it rendered here https://devex-von-dev.pathfinder.gov.bc.ca/business/113

jljordan_bcgov (Thu, 30 Nov 2017 23:40:51 GMT):
for now :)

jljordan_bcgov (Thu, 30 Nov 2017 23:41:10 GMT):
thanks @nbrempel and @sklump !

nbrempel (Thu, 30 Nov 2017 23:41:27 GMT):
🙌🏻

jljordan_bcgov (Thu, 30 Nov 2017 23:46:56 GMT):
and @WadeBarnes

WadeBarnes (Thu, 30 Nov 2017 23:46:56 GMT):
Has joined the channel.

alexeykoren (Fri, 01 Dec 2017 10:34:19 GMT):
Hi guys! I'm trying to run indysdk java wrapper sample on fresh github master and getting "Pool worker thread finished with error CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree."))". I rebuilt docker couple of times, upgraded indy_node version just in case, tried building libindy.so with rust and using ubuntu binary - nothing helps :( Any idea what can be wrong? Sound like version mismatch problem but I cannot find away to fix this...

alexeykoren (Fri, 01 Dec 2017 10:35:19 GMT):
It worked on 1.0.0 btw

alexeykoren (Fri, 01 Dec 2017 10:35:30 GMT):
back in the days...

sergey.minaev (Fri, 01 Dec 2017 10:38:09 GMT):
@alexeykoren this error means that genesis transaction for pool and sdk are different. Please try to use stable 1.1.*

sergey.minaev (Fri, 01 Dec 2017 10:44:25 GMT):
Both dockerfile for pool and samples code Also I will try to create hotfix in master right now for sample

sergey.minaev (Fri, 01 Dec 2017 10:44:25 GMT):
Both dockerfile for pool and samples code Also I will try to create hotfix in master right now for samples

alexeykoren (Fri, 01 Dec 2017 10:56:38 GMT):
Just tried 1.1.0 and it works, thanks!

sergey.minaev (Fri, 01 Dec 2017 11:08:02 GMT):
@alexeykoren I create hotfix for Java but it will be merged later. If you want you can replace `^/samples/java/src/main/java/utils/PoolUtils.java` `defaultTxns` array by same variable from `^/wrappers/java/src/test/java/org/hyperledger/indy/sdk/utils/PoolUtils.java`

sergey.minaev (Fri, 01 Dec 2017 11:08:25 GMT):
And it should work for master

alexeykoren (Fri, 01 Dec 2017 11:11:55 GMT):
Cool, thanks. I'd stick with 1.1.0 for a while anyway. No real need for such bleeding edge for now )

sergey.minaev (Fri, 01 Dec 2017 16:22:11 GMT):
Hotfix for synchronization `samples` and `indy-pool.dockerfile` has been merged to `master` branch.

swcurran (Mon, 04 Dec 2017 17:36:50 GMT):
Is there a defined plan for how Docs will be generated for the Indy-SDK - e.g. a pipeline for generating docs to https://readthedocs.org/? I see there are some HyperLedger docs there. Is that the plan for the Indy-SDK?

WadeBarnes (Mon, 04 Dec 2017 18:13:45 GMT):
Hi All, We've promoted the latest version of TheOrgBook to TEST (https://devex-von-test.pathfinder.gov.bc.ca/home), and @nbrempel will be pointing our BC Registry Mock-Up (http://138.197.150.19/) at that environment.

WadeBarnes (Mon, 04 Dec 2017 18:17:41 GMT):
@nbrempel has expanded the logging on the Mock-up to better log the messages and interaction of the two systems.

the_identity_guy (Mon, 04 Dec 2017 21:32:46 GMT):
Has joined the channel.

nage (Tue, 05 Dec 2017 08:26:39 GMT):
@swcurran that is a good idea. I don't think anyone has started work on getting docs over to readthedocs.org, it sounds like a good idea. Care to log issues for it?

turmewr3ck (Tue, 05 Dec 2017 10:39:39 GMT):
Is there a description anywhere on how CL and BLS signatures relate to claim definition, state proofs, etc?

gudkov (Tue, 05 Dec 2017 11:11:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=h4p8296gce8LxrJK4) @nage We have a ticket related to docs enhancement and it is one of goals in roadmap. We can add comment about readthedocs.org as possible option.

gudkov (Tue, 05 Dec 2017 11:16:56 GMT):
> Is there a description anywhere on how CL and BLS signatures relate to claim definition, state proofs, etc? BLS - is multi signatures system. It is used to sign state proofs in Indy SDK. CL - is implementation of CL type of anoncreds math. Indy SDK will use CL to implement high level anoncreds protocol. claim definition is one of entities in this anoncreds protocol.

gudkov (Tue, 05 Dec 2017 11:17:58 GMT):
There is PR in review that will replace custom anoncreds math code in Indy SDK by CL module of indy-crypto.

jeffblack360 (Tue, 05 Dec 2017 15:38:08 GMT):
Has joined the channel.

stephen_n (Wed, 06 Dec 2017 09:01:36 GMT):
Has joined the channel.

stephen_n (Wed, 06 Dec 2017 09:02:56 GMT):
Hello All, Indy-sdk looks pretty neat. I was wondering if it can be used with any other blockchain than indy.

stephen_n (Wed, 06 Dec 2017 09:27:04 GMT):
especially anoncreds

gudkov (Wed, 06 Dec 2017 10:13:29 GMT):
> especially anoncreds I suggest look to https://github.com/hyperledger/indy-crypto/tree/master/libindy-crypto/src/cl Here is completely blockchain/protocol agnostic implementation of anoncreds.

gudkov (Wed, 06 Dec 2017 10:14:40 GMT):
https://github.com/hyperledger/indy-crypto/blob/master/libindy-crypto/src/cl/mod.rs contains demo() test with full workflow.

gudkov (Wed, 06 Dec 2017 12:53:41 GMT):
We have a pool request to Indy SDK related to usage of Indy Crypto as backed for anoncreds protocol. There are no changes in API, but It will cause changing of serialization of some anoncreds entities. As result claims from previous Indy SDK version will be incompatible with the new code after this commit. Please let me known if it is problem for someone. We will try to align this. PR https://github.com/hyperledger/indy-sdk/pull/401

alexeykoren (Wed, 06 Dec 2017 16:20:11 GMT):
Hi everybody, we are currently working on sovrin-based app and I'm wondering if there is a working end2end scenario of some peer2peer communications including creating new identities and fetching DDOs from public ledger? Or at least a bit more descriptive docs especially about JSON schemas that are used.

nbrempel (Wed, 06 Dec 2017 17:45:57 GMT):
Is it possible to query the ledger for all schema published by a particular DID? It looks like it requires the name and version of the schema you are looking for: https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/indy/ledger.py#L363

nbrempel (Wed, 06 Dec 2017 17:49:31 GMT):
If this is true, then schemas are not exactly "discoverable". Is it expected that schema publishers will make their schemas known publicly off-ledger? They would publish their (did, schema name, current version)?

mhailstone (Thu, 07 Dec 2017 15:34:56 GMT):
This might be old, forgive me, but I'm getting the following errors when trying to build libindy on Mac OSX (High Sierra): ```error: associated constants are experimental (see issue #29646) --> src/services/pool/state_proof.rs:37:5 | 37 | const RADIX: usize = 16; | ^^^^^^^^^^^^^^^^^^^^^^^^ error: associated constants are experimental (see issue #29646) --> src/services/pool/state_proof.rs:38:5 | 38 | const FULL_SIZE: usize = Node::RADIX + 1; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: associated constants are experimental (see issue #29646) --> src/services/pool/state_proof.rs:39:5 | 39 | const PAIR_SIZE: usize = 2; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: associated constants are experimental (see issue #29646) --> src/services/pool/state_proof.rs:40:5 | 40 | const HASH_SIZE: usize = 32; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: associated constants are experimental (see issue #29646) --> src/services/pool/state_proof.rs:41:5 | 41 | const IS_LEAF_MASK: u8 = 0x20; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: associated constants are experimental (see issue #29646) --> src/services/pool/state_proof.rs:42:5 | 42 | const IS_PATH_ODD_MASK: u8 = 0x10; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error(s) error: Could not compile `indy`. ```

gudkov (Thu, 07 Dec 2017 16:00:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=dMWGaJbPvbKNhRDx4) @mhailstone You need to upgrade Rust

mhailstone (Thu, 07 Dec 2017 16:27:14 GMT):
@gudkov Thank you. I am now getting another error: ```error: linking with `cc` failed: exit code: 1```

gudkov (Thu, 07 Dec 2017 16:41:12 GMT):
Check that you have libsodium 1.0.12. Newer version will fail to link. Also if you downgrade libsodium you need to call "cargo clean" before try to build.

mhailstone (Fri, 08 Dec 2017 17:18:51 GMT):
@gudkov Having a hard time figuring out how to downgrade libsodium to 1.0.12. `brew install libsodium 1.0.12` fails and I cannot see that version in the tap lists when doing a `brew search libsodium` command either.

slafranca (Fri, 08 Dec 2017 18:37:34 GMT):
Has joined the channel.

windley (Fri, 08 Dec 2017 21:48:36 GMT):
Has joined the channel.

windley (Fri, 08 Dec 2017 21:51:51 GMT):
@ewelton and @gudkov: what happened with the node-js wrapper for Libindy?

nhan.trong.nguyen (Mon, 11 Dec 2017 07:36:31 GMT):
Has joined the channel.

gudkov (Mon, 11 Dec 2017 07:44:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=roDA5mik2Wy8ySXpu) @mhailstone brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/65effd2b617bade68a8a2c5b39e1c3089cc0e945/Formula/libsodium.rb See instruction in this PR https://github.com/hyperledger/indy-sdk/pull/385 . We can't merge it due DCO issue. If there will be no answer from the author we will create new PR with updated instruction soon.

gudkov (Mon, 11 Dec 2017 07:48:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=XopdwjSAsunJoLv44) There was no any PRs to indy-sdk repo. There was some version in @ewelton fork, but most probable it is outdated now. Our official issue related to NodeJS is here https://jira.hyperledger.org/browse/IS-272.

turmewr3ck (Mon, 11 Dec 2017 15:10:58 GMT):
The Python wrapper for the Indy SDK seems to be based on single threaded co-routines (asyncio). My first reaction was that this gives some challenges when using the Indy SDK with existing frameworks (say a web or websocket server package) that typically do not use asyncio. With the Python wrapper, is there some pre-anticipated SW pattern in mind for SDK integrators? (Just want to know if this has already been thought through before I spend time on reinventing the wheel.)

mhailstone (Mon, 11 Dec 2017 17:35:17 GMT):
@gudkov Thank you! That was what I needed.

gudkov (Tue, 12 Dec 2017 09:00:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qahFXZQwxEtahKq9w) @turmewr3ck In my vision asyncio is the only way to write effective backend code in python. Thread pool based web-solutions with blocking io seem a bit strange due GIL.Callbacks also looks strange in pyhton world. Anyway you can run asyncio loop in some thread and create ipc based wrapper to any io-handling style you want.

gudkov (Tue, 12 Dec 2017 09:00:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qahFXZQwxEtahKq9w) @turmewr3ck In my vision asyncio is the only way to write effective backend code in python. Thread pool based web-solutions with blocking io seem a bit strange due GIL.Callbacks also look strange in pyhton world. Anyway you can run asyncio loop in some thread and create ipc based wrapper to any io-handling style you want.

mgbailey (Tue, 12 Dec 2017 14:55:20 GMT):
@gudkov I am with you for using asyncio for calls that touch non-local systems such as the ledger or other agents. I don't see it for calls that are internal to the system, such as for the local wallet. I think these should be regular functions, not async.

devin-fisher (Tue, 12 Dec 2017 16:33:09 GMT):
@gudkov and @nage I'm looking at proof verification. It seems to me that the method indy_verifier_verify_proof only checks what I'll call proof authenticity (an Integrity and Source authentication check). But the method requires the proof_requrest used to build the proof. Based on the code it seems that only the nonce is required for proof authenticity. Yet the function requires requested_attrs and requested_predicates but does not do anything with them (best I can tell from the code). So, my question, do we plan on doing more with the indy_verifier_verify_proof method? Are we planning on doing what I'm calling request compliance? Which is checking that the proof not only is authentic but also complies with the conditions of the request? If not is there a reason we require the whole proof_request to verify?

nhan.trong.nguyen (Wed, 13 Dec 2017 07:21:41 GMT):
Hi, I'm Nhan from Logigear. Now I am writting test cases for libindy functinal testing with python wrapper. When I was working with function 'wallet.open_wallet', I realized that we can open wallet with some configurations. For example: wallet.open_wallet(wallet_name='exampleWallet', wallet_config='{"freshness_time": 1}') I wonder if there are any other wallet's configurations except 'freshness_time' and how do these configurations affect to wallet? Could you share with us the document about that or where I can find them? I need them to write and implement test cases for 'wallet'.

BrandonKlotz (Wed, 13 Dec 2017 16:37:27 GMT):
Has joined the channel.

BrandonKlotz (Wed, 13 Dec 2017 16:37:42 GMT):
Hello, I am playing with Sovrin and the Test environment in the Alice scenario. Is there any documentation on creating a verkey/Institution? ``` send NYM dest=ULtgFQJe6bjiFbs7ke3NJD role=TRUST_ANCHOR verkey=~5kh3FB4H3NKq7tUDqeqHc1

mgbailey (Wed, 13 Dec 2017 17:06:14 GMT):
@BrandonKlotz take a look at https://docs.google.com/document/d/1kQcdICAYmSqbk4d5lUtFhk2L55dKJMfyM0JbZPeG55s/edit?usp=sharing

mgbailey (Wed, 13 Dec 2017 17:13:46 GMT):
@nhan.trong.nguyen You have probably seen the javadoc style documentation in wallet.py in wrappers/python/indy. It only mentions freshness_time, but says that other parameters may be available, depending on wallet type. @gudkov , where can we find information on these other parameters?

nghia47 (Thu, 14 Dec 2017 03:11:52 GMT):
Hi @gudkov I am playing with Indy Python wrapper anoncreds. Could you please advise some related documents so I could design the functional test on this service?

ashcherbakov (Thu, 14 Dec 2017 08:28:59 GMT):
Hi @nghia1412. You can have a look at https://github.com/hyperledger/indy-sdk/blob/master/doc/libindy-anoncreds.puml (render it on plantuml website), and https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/tests/demo/test_anoncreds.py

calvinx (Thu, 14 Dec 2017 09:26:07 GMT):
Has joined the channel.

sergey.minaev (Thu, 14 Dec 2017 15:46:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=f6aatyqExRwGrL9v4) @devin-fisher Do you review master/stable branch or Anoncreds from indy-crypto PR? (https://github.com/hyperledger/indy-sdk/pull/401) There are some missed checks in current master/stable, but they should be fixed at migration to anoncreds from indy-crypto.

devin-fisher (Thu, 14 Dec 2017 15:52:47 GMT):
I was looking at the code in master.

sergey.minaev (Thu, 14 Dec 2017 15:53:53 GMT):
Ok, it's known issue for master code and I hope it's fixed in the PR

sergey.minaev (Thu, 14 Dec 2017 15:55:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=yCSebNeAPiB8vZZf7) @mgbailey @nhan.trong.nguyen There is indy_register_wallet_type which allow to register custom wallet implementation. So "depending on wallet type" just mean that custom wallet may has any parameters in this JSON. Default wallet now support only freshness time parameter.

mgbailey (Thu, 14 Dec 2017 15:56:41 GMT):
Thanks @sergey.minaev

arjanvaneersel (Thu, 14 Dec 2017 16:32:00 GMT):
Is there any documentation available about the API of the underlying library that the wrappers use? I'm now starting out with the Python wrapper to get the hang of the wrapper in general. But I'd like to see if I could contribute by writing a wrapper for the Go programming language, so therefore I'd like to get some more insight in how things work.

sergey.minaev (Thu, 14 Dec 2017 16:50:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=R56wSDmnsXXxZhpmP) @arjanvaneersel `libindy` API has documentation in the code. Please check `include` and `api` folders https://github.com/hyperledger/indy-sdk/tree/master/libindy/include https://github.com/hyperledger/indy-sdk/tree/master/libindy/api

arjanvaneersel (Thu, 14 Dec 2017 16:50:48 GMT):
@sergey.minaev Thanks! I'll take a look.

sergey.minaev (Thu, 14 Dec 2017 16:52:00 GMT):
@gudkov @nage @ashcherbakov Do we have any progress or discussion about Go wrapper

sergey.minaev (Thu, 14 Dec 2017 16:52:00 GMT):
@gudkov @nage @ashcherbakov Do we have any progress or discussion about Go wrapper?

ashcherbakov (Thu, 14 Dec 2017 16:53:19 GMT):
@arjanvaneersel As for anonymous credentials (verifable claims) part, you can have a look at https://github.com/hyperledger/indy-sdk/blob/master/doc/libindy-anoncreds.puml (render it on plantuml website), and https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/tests/demo/test_anoncreds.py

ashcherbakov (Thu, 14 Dec 2017 16:54:17 GMT):
Having look at examples from `demo` folder is also a good starting point, as it shows some real examples and workflows on how the API is supposed to work and be used.

mgbailey (Thu, 14 Dec 2017 21:21:28 GMT):
I have some scripts running using the python wrapper. When they run I get a lot of logs to stderr that clutters my output. While I could just suppress this by redirecting stderr, I would prefer to learn how to control the logging output of libindy. How can I configure libindy logging?

sergey.minaev (Thu, 14 Dec 2017 23:48:11 GMT):
@mgbailey in the latest master logging disabled by default and can be confugured via `RUST_LOG` env. variable

sergey.minaev (Thu, 14 Dec 2017 23:49:22 GMT):
examples of usage this variable can be found here https://doc.rust-lang.org/log/env_logger/index.html#enabling-logging

nhan.trong.nguyen (Thu, 14 Dec 2017 23:51:42 GMT):
@mgbailey @sergey.minaev

nhan.trong.nguyen (Thu, 14 Dec 2017 23:51:53 GMT):
thanks for relying

nhan.trong.nguyen (Thu, 14 Dec 2017 23:51:53 GMT):
thanks for replying

nghia47 (Fri, 15 Dec 2017 03:12:07 GMT):
thanks @ashcherbakov

gvvishwanath (Fri, 15 Dec 2017 05:22:12 GMT):
Has joined the channel.

mgbailey (Fri, 15 Dec 2017 15:06:41 GMT):
Thanks, @sergey.minaev , I will give this a try.

notOccupanther (Sun, 17 Dec 2017 16:44:18 GMT):
Has joined the channel.

Raffael 5 (Sun, 17 Dec 2017 18:57:52 GMT):
Has joined the channel.

wittrock (Mon, 18 Dec 2017 21:58:01 GMT):
Hi all, is there a sample agent which uses indy-sdk? I see that the Faber/BaseAgent classes in indy-node use an indy-client directory in that repo, which seems deprecated.

wittrock (Mon, 18 Dec 2017 22:01:59 GMT):
this might be what I'm looking for: https://github.com/PSPC-SPAC-buyandsell/von_agent

Sean_Bohan (Mon, 18 Dec 2017 22:19:51 GMT):
Has joined the channel.

WadeBarnes (Mon, 18 Dec 2017 22:51:34 GMT):
@wittrock, A few other goodies you may want to look at: https://github.com/bcgov/von-connector https://github.com/bcgov/von-network https://github.com/bcgov/permitify https://github.com/bcgov/TheOrgBook

WadeBarnes (Mon, 18 Dec 2017 22:52:21 GMT):
All 5 are related projects we're working on.

WadeBarnes (Mon, 18 Dec 2017 23:03:39 GMT):
Here is a running instance of the von-network complete with a basic ledger browser; http://138.197.170.136/

Harmannz (Mon, 18 Dec 2017 23:29:35 GMT):
Has joined the channel.

Raghuvamz (Tue, 19 Dec 2017 06:12:26 GMT):
Has joined the channel.

Raghuvamz (Tue, 19 Dec 2017 06:18:17 GMT):
cargo build fails for indy-sdk on macos, its says error: linking with `cc` failed: exit code: 1, I have been trying to follow the documentation here

Raghuvamz (Tue, 19 Dec 2017 06:18:19 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md

Raghuvamz (Tue, 19 Dec 2017 06:18:38 GMT):
can someoen bail me out?

gudkov (Tue, 19 Dec 2017 08:39:33 GMT):
@Raghuvamz most probable you have incorrect version of libsodium. What version do you have? Instruction says that you need to install specific version: ``` brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/65effd2b617bade68a8a2c5b39e1c3089cc0e945/Formula/libsodium.rb ```

Raghuvamz (Tue, 19 Dec 2017 09:48:16 GMT):
@gudkov : Thanks, i was using an earlier version - 1.0.12. I am able to build it now, thanks!

Raghuvamz (Tue, 19 Dec 2017 09:56:06 GMT):
however the java wrapper documentation says Then copy the resulting libindy.so to ./lib/. where can i find libindy.so. I am afraid i couldn't find the same withinin my working directory. Is this something that is generated on successful cargo build. If yes, it would be greatful if you can help me locate it.

sergey.minaev (Tue, 19 Dec 2017 10:58:34 GMT):
@Raghuvamz `cargo build` output directory is `./target/debug/`

sergey.minaev (Tue, 19 Dec 2017 10:58:34 GMT):
@Raghuvamz `cargo build` output directory is `./target/debug/` (`target/`)

sergey.minaev (Tue, 19 Dec 2017 10:58:34 GMT):
@Raghuvamz `cargo build` output directory is `./target/debug/` ( `./target/` )

WadeBarnes (Tue, 19 Dec 2017 15:15:21 GMT):
@Raghuvamz, You can find a simple Docker file describing the build process here; https://github.com/bcgov/permitify/blob/master/LibIndy-Dockerfile

WadeBarnes (Tue, 19 Dec 2017 15:16:09 GMT):
It's checking out a known working version of the code.

WadeBarnes (Tue, 19 Dec 2017 15:17:26 GMT):
Another Docker file in the same repo layers Python on top of that.

calvinx (Wed, 20 Dec 2017 08:14:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Wbk8umbGPAu7pruq9) @WadeBarnes so von network is a specific instance of an Indy network. Like Sovrin is a specific instance of an Indy network ?

WadeBarnes (Wed, 20 Dec 2017 15:19:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JeoPaKemsy9RbrFFF) @calvinx Yes, we created it so we had something to work with as we iterate on our applications and dive into agent development. It's meant for development, and being Docker based makes it easy to spin up a local instance on your development machine.

ashcherbakov (Wed, 20 Dec 2017 15:46:56 GMT):
FYI: there are also some docker and vagrant images in https://github.com/evernym/sovrin-environments. We're going to move these script to Indy repos soon.

WadeBarnes (Wed, 20 Dec 2017 18:14:38 GMT):
@ashcherbakov, that's where we started. I did the OpenShift implementation. Our implementations are enhancements on what we learned from there. The implementations there are Ok but we quickly found the hard coded examples just did not work for us.

jljordan_bcgov (Thu, 21 Dec 2017 16:41:57 GMT):
@calvinx A bit more content behind Verifiable Organization Network (VON).The idea is that is it a network of Issuers, Verifiers, Holders (enabled by self-sovereign identity networks that use DID and W3C Verifiable claims). I'm working on more documentation to describe these ideas. Current "network elements" we are implementing are "TheOrgBook" which is a multi-subject holder we are envisioning to hold public verifiable claims about businesses ... you can read about and get links to running instances here http://bcgov.github.io/TheOrgBook. Another network element is the "VON Connector" where it would provide an API for services like a Business Licence, or liquor licence service to issue, verify and so forth claims. The VON Connector current contains an Indy Agent that we built and is shared via our colleagues GitHub repo https://github.com/PSPC-SPAC-buyandsell/von_agent. We plan to evolve this and include it into the Indy repo under a /experiments and hopefully as it matures into a reference implementation. We have an instance of HL Indy running which @wade pointed to so we can learn and test out the ideas and code we are developing. We call this test network BCovrin (for fun).

jljordan_bcgov (Thu, 21 Dec 2017 16:53:17 GMT):
@calvinx good grief ... we all posted in different channels!

jljordan_bcgov (Thu, 21 Dec 2017 16:53:33 GMT):
so you have what you need I think :)

wolili (Fri, 22 Dec 2017 11:27:35 GMT):
Has joined the channel.

calvinx (Thu, 28 Dec 2017 04:34:43 GMT):
@jljordan_bcgov I am experimenting with the indy-sdk and specifically when executing `pool.create_ledger_config` method, with a name and genesis transaction file, I came up against: ``` ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Pool ledger config already exists Pool ledger config file with name "pool.trust-anchor" already exists ... File "... lib/python3.6/site-packages/indy/pool.py", line 38, in create_pool_ledger_config create_pool_ledger_config.cb) indy.error.IndyError: ErrorCode.PoolLedgerConfigAlreadyExistsError ``` on the 2nd run. What does that mean?

calvinx (Thu, 28 Dec 2017 04:34:43 GMT):
@jljordan_bcgov I am experimenting with the indy-sdk and specifically trying to run `pool.create_ledger_config` method, supply a name and genesis transaction file. But I came up against ``` ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Pool ledger config already exists Pool ledger config file with name "pool.trust-anchor" already exists ... lib/python3.6/site-packages/indy/pool.py", line 38, in create_pool_ledger_config create_pool_ledger_config.cb) indy.error.IndyError: ErrorCode.PoolLedgerConfigAlreadyExistsError ``` on the 2nd run. What does that mean?

calvinx (Thu, 28 Dec 2017 04:34:43 GMT):
@jljordan_bcgov I am experimenting with the indy-sdk and specifically trying to run `pool.create_ledger_config` method, supply a name and genesis transaction file. But I came up against ``` ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Pool ledger config already exists Pool ledger config file with name "pool.trust-anchor" already exists ... File "... lib/python3.6/site-packages/indy/pool.py", line 38, in create_pool_ledger_config create_pool_ledger_config.cb) indy.error.IndyError: ErrorCode.PoolLedgerConfigAlreadyExistsError ``` on the 2nd run. What does that mean?

calvinx (Thu, 28 Dec 2017 05:59:08 GMT):
O, figured it out. Just needed to handle it if the config was already created in the first run.

charyorde (Sat, 30 Dec 2017 08:38:02 GMT):
Has joined the channel.

liurf (Tue, 02 Jan 2018 03:27:02 GMT):
Has joined the channel.

elias_p (Tue, 02 Jan 2018 22:55:46 GMT):
Has joined the channel.

sklump (Wed, 03 Jan 2018 14:07:15 GMT):
Trying to sync up my agent wrapper code against libindy-1.1.1-dev-306 (had been 1.0.x from late November). I see that the structure of `claim_offer` has changed from ``` { "issuer_did": "%s", "schema_seq_no": "%s" } ``` to ``` { "issuer_did": "%s", "schema_key": { "name": "%s", "version": "%s", "did": "%s" } } ``` . Presumably the outer `issuer_did` refers to the issuer of the claim offer and the `schema_key.did` refers to the schema originator's DID? Kindly confirm or correct.

sklump (Wed, 03 Jan 2018 15:49:41 GMT):
I hate to be that guy, but I notice that `claim_def['ref']` still refers to a schema sequence number, and I am going to ask if it shouldn't also be a `schema_key` structure as the bulk of the code base appears to adopt now? Given a `claim_def`, now the client needs to visit the ledger again to get all the folderol necessary to do stuff with it (e.g., set master secret).

sklump (Wed, 03 Jan 2018 15:49:41 GMT):
I hate to be that guy, but I notice that `claim_def['ref']` still refers to a schema sequence number, and I am going to ask if it shouldn't also be a `schema_key` structure as the bulk of the code base appears to adopt now? Given a `claim_def`, now the client needs to visit the ledger again to get all the metadata necessary to do stuff with it (e.g., store claim req).

ronniemh (Wed, 03 Jan 2018 16:44:14 GMT):
Has joined the channel.

ronniemh (Wed, 03 Jan 2018 16:45:02 GMT):
good afternoon, can you please explain how to use the Indy SDK? and how to implement it please, if I must first use for example this implementation of Docker https://github.com/hyperledger/indy-node/blob/master/environment/docker/pool/README.md and then use the SDK or are they projects that work without depending on each other? since I want to implement a JAVA EE application to interact with the user. Another question, How and in what type of database does the information keep?

mgbailey (Wed, 03 Jan 2018 16:46:12 GMT):
@sklump FYI much of the team working on the indy-sdk celebrate Christmas later than we do here in the US, so they will probably not be around to answer this until next week.

mgbailey (Wed, 03 Jan 2018 16:51:33 GMT):
@ronniemh a good place to start learning from are the code snippets in the wrappers/python/tests/demo. While they are python not java, you should be able to read them. Other community members are using the java fine, so it will work for you.

mgbailey (Wed, 03 Jan 2018 16:51:51 GMT):
The sdk uses sqlite for its storage.

ronniemh (Wed, 03 Jan 2018 16:54:24 GMT):
@mgbailey thank you very much for answering, ok I will start reading the python codes, but something that does not fit me is from which order I start, there is the start guide but there you do it in a local environment or with docker, and wanted to know if those codes are separate of the SDK or the two complement each other?

mgbailey (Wed, 03 Jan 2018 16:58:26 GMT):
Indy is a multi-node system, so depending on what you are doing, to work with it you will need at least 4 nodes running indy for a validator pool, plus at least one node running indy-sdk. Various people have been contributing ways to set up a test pool, including docker images and vagrant scripts that set up virtualbox VMs

ronniemh (Wed, 03 Jan 2018 17:01:38 GMT):
@mgbailey Thank you very much for responding, now I have a little clearer about this topic, what happens is that I have been trying for a long time to do a test and locally I have achieved it, but at the moment I want to give this test a view with java or python, nose where I occupy the local corrida I did in ubuntu, if the whole SDK gives me already functions to do it or is what I understood, sorry but I read and read and those things are not clear to me, sorry.

ronniemh (Wed, 03 Jan 2018 17:01:38 GMT):
@mgbailey Thank you very much for responding, now I have a little clearer on this subject, what happens is that I have been trying for a long time to do a test and locally I have achieved it, but at this moment I want to give this test a view with java or python, I do not know where I occupy the local environment that I did in ubuntu, if all the SDK already gives me functions to do it or is what I understood, I'm sorry but I read it and I read it and those things are not clear to me, I'm sorry.

mgbailey (Wed, 03 Jan 2018 18:22:20 GMT):
@ronniemh I have set up indy-sdk in an ubuntu vm, following the directions in https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md. Then I have been able to run my (python) applications that use the indy-sdk. Others have done similarly with docker images.

sklump (Wed, 03 Jan 2018 18:33:50 GMT):
Item: how do I map the pypi version of indy-sdk (e.g., 1.1.1-dev-306) against git\hub version (python3-indy=1.1.1rc7) ? Are these the same?

sklump (Wed, 03 Jan 2018 18:33:50 GMT):
Item: how do I map the pypi version of indy-sdk (e.g., 1.1.1-dev-306) against github version (python3-indy=1.1.1rc7) ? Are these the same?

ronniemh (Wed, 03 Jan 2018 18:42:27 GMT):
@mgbailey Thanks! i will do it

smithbk (Wed, 03 Jan 2018 19:55:12 GMT):
@gudkov @nage @ashcherbakov @sergey.minaev @arjanvaneersel I'm also interested in the golang wrapper. Has anyone already started on this?

nage (Wed, 03 Jan 2018 19:56:11 GMT):
Not that I know of. Any volunteers?

smithbk (Wed, 03 Jan 2018 19:56:44 GMT):
It looked like @arjanvaneersel was going to

arjanvaneersel (Thu, 04 Jan 2018 04:08:15 GMT):
I am currently examining the Python wrapper to understand how it's working a bit better and started some tests on invoking rust libraries in Go.

arjanvaneersel (Thu, 04 Jan 2018 04:09:04 GMT):
Wanted to do that first before making a formal proposal on Jira.

arjanvaneersel (Thu, 04 Jan 2018 05:27:32 GMT):
Also it's not clear to me how to make a proposal on Jira for this. Could anyone explain me where I'm supposed to do this?

sklump (Thu, 04 Jan 2018 11:51:45 GMT):
Just a note here to save explorers the trouble, however long it would take to dawn on them. Version 1.1.1-rc7 and 1.1.1-dev-306 are IN NO WAY COMPATIBLE. Treat the version numbers on this toolkit as position-wise meaningless. Just going to assert that this not as clear as it could be.

sklump (Thu, 04 Jan 2018 11:51:45 GMT):
Just a note here to save explorers the trouble, however long it would take to dawn on them. Version 1.1.1-rc7 and 1.1.1-dev-306 are IN NO WAY COMPATIBLE. Treat the version numbers on this toolkit as position-wise meaningless. This not as clear as it could be? Another possibility is that I've misunderstood how the version plan works.

sklump (Thu, 04 Jan 2018 11:51:45 GMT):
Just a note here to save explorers the trouble, however long it would take to dawn on them. Version 1.1.1-dev-306 (off pypi) and 1.1.1 (master) are IN NO WAY COMPATIBLE. Treat the version numbers on this toolkit as position-wise meaningless. This not as clear as it could be? Another possibility is that I've misunderstood how the version plan works.

sklump (Thu, 04 Jan 2018 11:51:45 GMT):
Just a note here to save explorers the trouble, however long it would take to dawn on them. Version 1.1.1-dev-306 (off pypi) and 1.1.1 (master) are IN NO WAY COMPATIBLE. The version on pypi is aligned with branch `rc` on github. Edit: nope, that's still not a correct statement. I have NO EARTHLY IDEA what the relation is between the rc branch, the master branch, and what's up on pypi. I am coming around to the idea that there is no relation.

sklump (Thu, 04 Jan 2018 11:51:45 GMT):
Just a note here to save explorers the trouble, however long it would take to dawn on them. Version 1.1.1-dev-306 (off pypi) and 1.1.1 (master) are IN NO WAY COMPATIBLE. The version on pypi is aligned with branch `rc` on github. Edit: nope, that's still not a correct statement. I have NO IDEA what the relation is between the `rc` github branch, the `master` github branch, and what's up on pypi. I am coming around to the idea that there is no relation.

wolili (Thu, 04 Jan 2018 14:17:54 GMT):
Hi, I tried run the demos in indy-sdk/wrappers/python/test/demo using `pytest test_xxx.py` and I only passed test_anoncreds.py. All the other tests exit with an `indy.error.IndyError: ErrorCode.PoolLedgerTerminated`. How can I fix that?

wolili (Thu, 04 Jan 2018 14:19:00 GMT):
Here is the full failure output of test_ledger.py ```___________________________________________ test_ledger_demo_works ____________________________________________ pool_name = 'pool1', pool_genesis_txn_path = PosixPath('/tmp/indy_client/pool1.txn') seed_trustee1 = '000000000000000000000000Trustee1', pool_genesis_txn_file = None path_home = PosixPath('/home/abcde/.indy_client') @pytest.mark.asyncio async def test_ledger_demo_works(pool_name, pool_genesis_txn_path, seed_trustee1, pool_genesis_txn_file, path_home): # 1. Create ledger config from genesis txn file pool_config = json.dumps({"genesis_txn": str(pool_genesis_txn_path)}) await pool.create_pool_ledger_config(pool_name, pool_config) # 2. Open pool ledger > pool_handle = await pool.open_pool_ledger(pool_name, None) ../../masterarbeit/indy-sdk/wrappers/python/tests/demo/test_ledger.py:16: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ../../masterarbeit/indy-sdk/wrappers/python/indy/pool.py:82: in open_pool_ledger open_pool_ledger.cb) /usr/lib/python3.5/asyncio/futures.py:361: in __iter__ yield self # This tells Task to wait for completion. /usr/lib/python3.5/asyncio/tasks.py:296: in _wakeup future.result() self = ,)> def result(self): .... if self._exception is not None: > raise self._exception E indy.error.IndyError: ErrorCode.PoolLedgerTerminated /usr/lib/python3.5/asyncio/futures.py:274: IndyError ```

wolili (Thu, 04 Jan 2018 14:19:00 GMT):
Here is the full failure output of test_ledger.py ```___________________________________________ test_ledger_demo_works ____________________________________________ pool_name = 'pool1', pool_genesis_txn_path = PosixPath('/tmp/indy_client/pool1.txn') seed_trustee1 = '000000000000000000000000Trustee1', pool_genesis_txn_file = None path_home = PosixPath('/home/abcde/.indy_client') @pytest.mark.asyncio async def test_ledger_demo_works(pool_name, pool_genesis_txn_path, seed_trustee1, pool_genesis_txn_file, path_home): # 1. Create ledger config from genesis txn file pool_config = json.dumps({"genesis_txn": str(pool_genesis_txn_path)}) await pool.create_pool_ledger_config(pool_name, pool_config) # 2. Open pool ledger > pool_handle = await pool.open_pool_ledger(pool_name, None) ../../wrappers/python/tests/demo/test_ledger.py:16: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ../../wrappers/python/indy/pool.py:82: in open_pool_ledger open_pool_ledger.cb) /usr/lib/python3.5/asyncio/futures.py:361: in __iter__ yield self # This tells Task to wait for completion. /usr/lib/python3.5/asyncio/tasks.py:296: in _wakeup future.result() self = ,)> def result(self): .... if self._exception is not None: > raise self._exception E indy.error.IndyError: ErrorCode.PoolLedgerTerminated /usr/lib/python3.5/asyncio/futures.py:274: IndyError ```

wolili (Thu, 04 Jan 2018 14:19:00 GMT):
Here is the full failure output of test_ledger.py ```___________________________________________ test_ledger_demo_works ____________________________________________ pool_name = 'pool1', pool_genesis_txn_path = PosixPath('/tmp/indy_client/pool1.txn') seed_trustee1 = '000000000000000000000000Trustee1', pool_genesis_txn_file = None @pytest.mark.asyncio async def test_ledger_demo_works(pool_name, pool_genesis_txn_path, seed_trustee1, pool_genesis_txn_file, path_home): # 1. Create ledger config from genesis txn file pool_config = json.dumps({"genesis_txn": str(pool_genesis_txn_path)}) await pool.create_pool_ledger_config(pool_name, pool_config) # 2. Open pool ledger > pool_handle = await pool.open_pool_ledger(pool_name, None) ../../wrappers/python/tests/demo/test_ledger.py:16: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ../../wrappers/python/indy/pool.py:82: in open_pool_ledger open_pool_ledger.cb) /usr/lib/python3.5/asyncio/futures.py:361: in __iter__ yield self # This tells Task to wait for completion. /usr/lib/python3.5/asyncio/tasks.py:296: in _wakeup future.result() self = ,)> def result(self): .... if self._exception is not None: > raise self._exception E indy.error.IndyError: ErrorCode.PoolLedgerTerminated /usr/lib/python3.5/asyncio/futures.py:274: IndyError ```

sklump (Thu, 04 Jan 2018 15:43:22 GMT):
If I remember correctly, Anoncreds doesn't need the pool. It looks like maybe you haven't started the pool.

wolili (Thu, 04 Jan 2018 23:21:58 GMT):
How do I "start the pool" when I want to run this testcase?

wolili (Thu, 04 Jan 2018 23:21:58 GMT):
How do I "start the pool" when I want to run this testcase? Do I need Vagrant or Docker or is there a more simple setup for such testcases?

mgbailey (Fri, 05 Jan 2018 14:56:55 GMT):
HI @wolili . A local pool is a good way to do test & development. If you have the RAM to support it, there are instructions and scripts to set up a 4 node pool locally using vagrant and virtualbox. This is what I use. Others use docker scripts that have been contributed by the community. https://github.com/evernym/sovrin-environments/blob/stable/vagrant/training/vb-multi-vm/TestIndyClusterSetup.md

WadeBarnes (Fri, 05 Jan 2018 16:11:44 GMT):
@wolili, You may also want to have a look at the work we've done here; https://github.com/bcgov/von-network It's a 4 node pool and it adds a basic ledger explorer and a few other features. Runs on Docker/Docker Compose

WadeBarnes (Fri, 05 Jan 2018 16:12:59 GMT):
You can find a running instance here; http://138.197.170.136/

nage (Fri, 05 Jan 2018 17:52:26 GMT):
@arjanvaneersel We aren't too formal yet. Logging a ticket in the IS (Indy SDK) project with a description of what wrapper you are writing and then taking a look at the wrapper recommendations would be helpful https://docs.google.com/document/d/15P6JOEKxbNC892DWReBStJIXrObVoaBDxbKJFOpAdjI/edit (@gudkov can verify if that is the most up to date version of those guidelines)

nage (Fri, 05 Jan 2018 17:53:30 GMT):
I am in the process of trying to convert some of our designs and protocol specs into a more PEP or BIP-like format, which should help people propose and discuss this sort of thing. If anyone have suggestions or would like to participate in any of that, please let me know.

wolili (Sun, 07 Jan 2018 10:26:55 GMT):
@WadeBarnes , @mgbailey thank you. Will look into that.

AxelNennker (Mon, 08 Jan 2018 15:03:32 GMT):
Hi, I just did the developer setup of indy-node and indy-plenum - ran the scripts, installed packages, setup virtualenv, forked the two project and wantet to start the cli but now I get pkg_resources.DistributionNotFound: The 'indy-plenum-dev==1.2.212' distribution was not found and is required by indy-node-dev Any quick tip what might be wrong?!

nbrempel (Mon, 08 Jan 2018 23:45:35 GMT):
Hi all, has anyone run into the issue of receiving the error `Casting error to ErrorCode: Wallet not found: Wallet record is not found: query returned no rows` when calling `anoncreds. prover_create_proof `? cc: @sergey.minaev

nbrempel (Tue, 09 Jan 2018 01:10:38 GMT):
As far as I can tell, this is failing on the requested claims json that I pass in (https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/indy/anoncreds.py#L612)

nbrempel (Tue, 09 Jan 2018 01:10:51 GMT):
``` { "requested_attrs": { "doing_business_as_name": [ "claim::b09c0cda-4697-40f6-8fde-ec6c95c98507", true ], "legal_entity_id": [ "claim::fe95c8ab-c794-4cef-be10-c770be494a0d", true ] }, "requested_predicates": {}, "self_attested_attributes": {} } ```

nbrempel (Tue, 09 Jan 2018 01:12:36 GMT):
But I am generating this payload from the available claims from the proof request by calling `anoncreds.prover_get_claims_for_proof_req` which gives me this:

nbrempel (Tue, 09 Jan 2018 01:12:55 GMT):
``` { "attrs": { "doing_business_as_name": [ { "attrs": { "address_line_1": "09h8", "address_line_2": "908h0", "addressee": "09h", "city": "98h", "corp_num": "8cea96b1-58d6-4cfb-96ad-7cd7310db4ab", "country": "098h", "doing_business_as_name": "Nick's Oranges", "effective_date": "2018-01-08", "end_date": "None", "legal_entity_id": "8cea96b1-58d6-4cfb-96ad-7cd7310db4ab", "legal_name": "None", "postal_code": "09h8", "province": "098h" }, "claim_uuid": "claim::b09c0cda-4697-40f6-8fde-ec6c95c98507", "issuer_did": "27TL9VHhcQNok9QvHLVx1a", "schema_seq_no": 74 } ], "legal_entity_id": [ { "attrs": { "address_line_1": "0987", "address_line_2": "0987", "addressee": "0987", "city": "0987", "corp_num": "ae7e6b8e-7970-4b26-8030-ee812c6f858f", "country": "9087", "effective_date": "2018-01-08", "end_date": "None", "legal_entity_id": "ae7e6b8e-7970-4b26-8030-ee812c6f858f", "legal_name": "Nick's Apples", "org_type": "CO", "postal_code": "9087", "province": "0987" }, "claim_uuid": "claim::fe95c8ab-c794-4cef-be10-c770be494a0d", "issuer_did": "27TL9VHhcQNok9QvHLVx1a", "schema_seq_no": 72 } ] }, "predicates": {} } ```

nbrempel (Tue, 09 Jan 2018 01:13:07 GMT):
Any help would be greatly appreciated. Thank you.

nbrempel (Tue, 09 Jan 2018 01:13:43 GMT):
Additionally, I might suggest more verbose logging for wallet errors. Display _what_ query returned no rows would be very helpful.

JOYELIN (Tue, 09 Jan 2018 08:37:00 GMT):
Has joined the channel.

sergey.minaev (Tue, 09 Jan 2018 10:13:56 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=HoRtZhC9XuufRCDwh) @Artemkaaas please re-check

sergey.minaev (Tue, 09 Jan 2018 10:14:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Nagk8bFAXqLwAkCDt) @Artemkaaas

sergey.minaev (Tue, 09 Jan 2018 10:19:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=rGEazmNSdhrPmwyjK) @sklump there are no exactly matching between `dev` and `rc`. But on each succesfull build (rc, stable, dev) all packages are published with same version (pypi, deb/win packages, etc).

sergey.minaev (Tue, 09 Jan 2018 10:22:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=FEh5mvemPomZ93Tx5) @ashcherbakov

sergey.minaev (Tue, 09 Jan 2018 10:29:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=tXPP5LDZPYKtv3mRc) @nbrempel we have some bugs in our backlog about better logging. If you want, you can create one more separate bug: for complex calls like anoncreds API. Accordingly to this call, `Wallet not found` error may be caused by missed master secret, claim definition or revocation registry (last one only in stable, not in master).

Artemkaaas (Tue, 09 Jan 2018 10:58:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=HKcp3Dd2RJFRNvf2L) @sergey.minaev issuer_did refers to the issuer of claim definition schema_key.did refers to the issuer of schema

Artemkaaas (Tue, 09 Jan 2018 11:01:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=82seWfK4KuS7KpXdy) @sergey.minaev We changed format of structures for Libindy only... Indy-Node ClaimDef transaction still works wirk schema_seq_no Currect workflow: 1) Get schema from ledger using schema_key 2) Get cliam_def from ledger using received schema

ashcherbakov (Tue, 09 Jan 2018 13:16:18 GMT):
@AxelNennker Did you follow the guide from https://github.com/hyperledger/indy-node/blob/master/docs/setup-dev.md (you can also run https://github.com/hyperledger/indy-node/blob/master/dev-setup/ubuntu/setup-dev-depend-ubuntu16.sh if you're on Ubuntu16)? BTW do you want just to run the CLI? If so, you can either use Docker (https://github.com/hyperledger/indy-node/tree/master/environment/docker/pool): - run ./pool_start.sh - run ./client_for_pool_start.sh Or you can create a virtual environment, and install indy-node from pypi (pip install indy-node). Don't forget to install additional dependencies like Charm (see instructions above). You don't need to install plenum explicitly.

pupeter (Tue, 09 Jan 2018 13:39:18 GMT):
Has joined the channel.

AxelNennker (Tue, 09 Jan 2018 14:19:03 GMT):
@ashcherbakov Yes, I followed the Quick Setup on Ubuntu 16.04 section of setup-dev.md and ran the scripts. That section told me to fork indy-plenum and indy-node. I have a fresh Ubuntu 16.04 VM. Last year I tried the indy test nodes. Once pre-docker and later with the vagrant docker way. Now I want to have a closer look at the indy code and maybe try to build a build-libindy-android.sh... @peacekeeper told me somebody already successfully tried that but it is not in indy-sdk/libindy. Today I did build libindy on the ubuntu box.

saholman (Tue, 09 Jan 2018 20:54:04 GMT):
Has joined the channel.

nbrempel (Tue, 09 Jan 2018 22:18:58 GMT):
Thank you @sergey.minaev, the issue was in the claim_def.

nbrempel (Tue, 09 Jan 2018 22:19:43 GMT):
Does anyone know what the timeline is for implementing more predicate types? Currently only ">=" is supported. "==" would be very useful.

ashcherbakov (Wed, 10 Jan 2018 10:51:54 GMT):
@nbrempel ''==" predicate is the same as asking for disclosing (revealing) some attributes. So, it's already supported (see `attr_info` part of ProofRequest - https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/api/anoncreds.rs#L555)

wolili (Wed, 10 Jan 2018 19:00:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Tbfg6n7d9nvQ3Bgd3) @WadeBarnes Today I have set up the von-network and it looks great with the ledger explorer. But I still don't know how to "connect" the pytest in indy-sdk/wrapper/python/test/demo with the running docker machines as the local pool...

wittrock (Wed, 10 Jan 2018 19:37:55 GMT):
I'm sure this has been asked before, but I haven't found the answer anywhere yet. Is there an indy-sdk equivalent of https://github.com/hyperledger/indy-node/blob/master/indy_client/test/agent/faber.py ?

wittrock (Wed, 10 Jan 2018 19:38:18 GMT):
Basically I'm trying to implement a simple agent along the lines of the Faber agent from the demo, but I'd like to do it in such a way that I can use indy-sdk

WadeBarnes (Wed, 10 Jan 2018 19:54:41 GMT):
@wolili , @nbrempel can help with that.

wittrock (Wed, 10 Jan 2018 20:17:22 GMT):
:wave: @wolili @nbrempel I've taken a look at von-network a bit, and it seems like there are some agents in there, but they're very tied in with the Django implementation AFAICT. Do you know of any that are less tied to a particular use case or framework?

mgbailey (Wed, 10 Jan 2018 21:00:27 GMT):
@wittrock , as a matter of fact, a libindy version of the getting started guide is a topic of conversation at tomorrow's Indy Agent WG call. All are welcome to join.

mgbailey (Wed, 10 Jan 2018 21:00:29 GMT):
Call details: Hyperledger Indy Agent (SDK) WG Call When: January 11, 2018 8amPT, 9amMT, 11amET, 4pm BST Where: Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/232861185 Or iPhone one-tap (US Toll): +16465588656,232861185# or +14086380968,232861185# Or Telephone: Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll) Meeting ID: 232 861 185 International numbers available: https://zoom.us/zoomconference?m=a0jD_rTMnh0ZYGQDOKPCNrK_0dP7WPfp1

wittrock (Wed, 10 Jan 2018 21:00:50 GMT):
I guess I should join then @mgbailey :) will try to make it!

Harmannz (Wed, 10 Jan 2018 22:25:02 GMT):
Hi all, I am trying work with the sample java sdk code and trying to connect it to an existing indy network I have created. I currently have my own `vagrant indy network` created on four remote validator VM nodes. e.g. ``` ... Connecting to vagrant... CONNECTION: EwN1n15gBnXurWqm5VuqyJTGEJ8snDFhPyYDZL9b1rQ5 now connected to Node1C CONNECTION: EwN1n15gBnXurWqm5VuqyJTGEJ8snDFhPyYDZL9b1rQ5 now connected to Node4C CONNECTION: EwN1n15gBnXurWqm5VuqyJTGEJ8snDFhPyYDZL9b1rQ5 now connected to Node3C CONNECTION: EwN1n15gBnXurWqm5VuqyJTGEJ8snDFhPyYDZL9b1rQ5 now connected to Node2C CATCH-UP: EwN1n15gBnXurWqm5VuqyJTGEJ8snDFhPyYDZL9b1rQ5 completed catching up ledger 0, caught up 0 in total CATCH-UP: EwN1n15gBnXurWqm5VuqyJTGEJ8snDFhPyYDZL9b1rQ5 completed catching up ledger 0, caught up 0 in total Connected to vagrant. ``` I am able to make changes to the sample java code from indy-sdk repo, compile it to a runnable jar and run the jar on a validator node. My genesis file matches the pool_transactions_genesis file from my vagrant network which includes 4 ip addresses of my remote validator nodes. ``` {"data":{"alias":"Node1","blskey":"4N8...","client_ip":"10.20.30.201","client_port":9702,"node_ip":"10.20.30.201","node_port":9701,"services":["VALIDATOR"]},"dest":"Gw6...","identifier":"Th...","txnId":"fea...","type":"0"} {"data":{"alias":"Node3","blskey":"3WF...","client_ip":"10.20.30.203","client_port":9706,"node_ip":"10.20.30.203","node_port":9705,"services":["VALIDATOR"]},"dest":"DKV...","identifier":"4c...","txnId":"7e9...","type":"0"} {"data":{"alias":"Node2","blskey":"37r...","client_ip":"10.20.30.202","client_port":9704,"node_ip":"10.20.30.202","node_port":9703,"services":["VALIDATOR"]},"dest":"8EC...","identifier":"Eb...","txnId":"1ac...","type":"0"} {"data":{"alias":"Node4","blskey":"2zN...","client_ip":"10.20.30.204","client_port":9708,"node_ip":"10.20.30.204","node_port":9707,"services":["VALIDATOR"]},"dest":"4PS...","identifier":"TW...","txnId":"aa5...","type":"0"} ``` Although the jar file runs without error, I am unable to confirm if java-sdk demo is using the vagrant network I have set up. I don't fully understanding if creating a pool ledger config `Pool.createPoolLedgerConfig` then opening the pool `Pool.openPoolLedger` creates a new pool or uses one that is already present. If it creates a new one, then wouldn't the name of the pool collide with my existing pool? If it doesn't create one then I should be able to see a list of wallets that are active? Note: Re-running the jar file without closing some wallets throws an error that a wallet with the specified name already exists, which means somewhere the wallets are being persisted. Basically, How do I connect my java code to use an existing pool of remote nodes and verify that it works?

mgbailey (Wed, 10 Jan 2018 23:22:43 GMT):
@Harmannz , perhaps it was a typo, but you said you run your indy-sdk code on a validator node? It is intended to run on a node that is emulating a client or an agent, that is external to your validator pool. The commands you are looking at are creating data structures on disk in your agent vm. For example, if I were using "testpool" as my pool name, I would see on disk the following file after running createPoolLedgerConfig: ~/.indy_client/pool/testpool/config.json And after running openPoolLedger I would see: ~/.indy_client/pool/testpool/testpool.txn If you look in testpool.txn, you should see data matching the data of the genesis file of the pool that you are connecting to.

Harmannz (Thu, 11 Jan 2018 01:46:36 GMT):
@mgbailey Yes. I can see the config.json and vagrant.txn file thank you for the feedback :) . I also realised that the wallets are saved within the ~/.indy_client/wallets directory. I was wondering why I wasn't able to open the indy-cli and type `list wallets` to view my wallets. Its because the indy cli saves the wallets in the .indy_cli directory

gudkov (Thu, 11 Jan 2018 07:10:23 GMT):
@Harmannz What CLI you use? We have 2 different tools. The old one is on code from indy-node repo and the new one based on indy-sdk. Only CLI based on indy-sdk can read wallets and network configs created through API.

mgbailey (Thu, 11 Jan 2018 14:53:49 GMT):
@gudkov , is the new one ready for use? Where can it be found? Is it in a package yet?

gudkov (Thu, 11 Jan 2018 15:27:25 GMT):
@mgbailey we have development builds only, but you can try it to use. See README.md inside of cli folder in indy-sdk for details.

mgbailey (Thu, 11 Jan 2018 15:27:59 GMT):
@gudkov Thanks

darrell.odonnell (Thu, 11 Jan 2018 16:51:48 GMT):
MoAID (Mother of All Interaction Diagrams) http://www.plantuml.com/plantuml/svg/hLVRZjis47ttLn3kwsu_O047KRon4y1jWaZeea1Uj39jAv58bQBNzT-NDziZyIgdZu9c3cVEd9aXt_UyPFpODhFPA_qNpREchl0S_RQfzmV-eJdYMLbnoiIFFIPyZieUPRDEkDHLtPM4e_bBsJJO_7cPOR8LE0PiLRvYXfPK6Eole7_Zfg4d6tRbXLsDOBEgnGALTP4ub_v0boF8ui3g7KSVIl8p5cVXHIrke0EJ3TxkCLCc6tFUchvXHbg56SfXxJriFSeWfs-i9YZd-5IoRIo9t8kRtt0NYmLQOyvhiaS5E_OSPQGw2A2AuQr0gikcHplnhUhyW6HT7f2XiYHRTCiIeSLYbZ--or-Uq9BXacCxufCAOcGbONeHlCF--VCpsZ7QeXxZhOms7kmZ3EaBUQK2I3hOqNdFXGXVovgTwXwhM2J0vWdbWZtqvxbLn4pnNOkpAI6uuZKbYE5_ZbWaSQhv8Hb6HKqegV1iBG01rr1lXkUX1SWNe8_E7SOi0F8dmR8uZvrfn_4MLJ21lgEanoQ3HD079Cn-uZF8H5Cpf3KHJPyzKCCtsk1KhUZnTQTCjFDaXNZSLkdYS200DbS22-X26LybCVm9SjEOGJMifgWXZkSMWiLU7EWNDQ1spPqIKBwJ5U3sofRf2h0H08lPKe812KZhgmB6Vq5o2ZKe0UcShe4eNg84eZY_g02pp-xKWF6Uh0AVNv4k0nS4uB8GO406slegXE5Va9z13GgXcAA31C149IGW1RImGCkch5kKLmVSoeiGviTEbZffKIedzBdlZtAUclMu2Usje8Vvgvm-jbr3pyhfKosFFi_DVv_7fu_ekHPERNcrL0cQ-xXAyndlQbAhWbmpZSn_xGWZNdb7Sj1MT5qat4Waq6ES3Zn8_HE_O6HkN-MfIDAl2oz7iGbf9ouzt5ChR3jYAI23M4mkLuisUFIGjtICmPFXHhJkEas_e31gymYdRLoNwirgNqSyolHOPu71wdM4UrL0mAsgtz6NjJhu2SkZC5sNlanT-b9tgG_6CJbTpFZ3I2cMuxzMXYvTPauhZ_mWSb6f34wqE_BBReVPXRNSfYhYuU5vZlueUoxlYrYiU5KLq6lfi-BIC2b5jH6-QMcP0azbvkAzqcy2g3QVptqrcCA-6PnTrvmLU_o0qG_wgbMYfeVk-f35kETZCytLnlv9wxCETRtFqTlqbWGSL_bCN-KdzRKDusXhT-w-CEBL0CtSCVe6g-BI4jJ4LqRf3kfSSYGw35LIBBszz4SEB-gC17cE6y32lD2julKRBQTSJRGmdz1VMDmsptxKECMNkMclrjlyz18EIkjVpVuvckhe7P0JBXO9JU87WZ9Qtat45SKKRwYRi7DaVaQSfvFlcgODBObvk-X7ZckWMaRMJ0rNmldcpDIR4pQGo-mxaMWLPNg0RGKzUaBz7dr9kaPpuPrbpXWBtzZtML_A6OhXVmiyR1xQG7xFz1qKAEga9UJ2SQoXYPLB4Z5OHV8WnxYyR2WfyYAweJmeanTN8anmdQbOaWT9xCQNWdPTZAEslX-hcB8-YtiUk8MAThXnxuztzbwSVcoR_m00

mgbailey (Thu, 11 Jan 2018 17:00:20 GMT):
It this the UML for the new GSG?

darrell.odonnell (Thu, 11 Jan 2018 17:02:56 GMT):
@mgbailey yes - I took it out of the git repo and pasted it into the PlantUML demo server.

mgbailey (Thu, 11 Jan 2018 17:03:26 GMT):
It's going to be great!

sklump (Thu, 11 Jan 2018 17:31:48 GMT):
GSG? Go Sens Go?

mgbailey (Thu, 11 Jan 2018 17:32:22 GMT):
sorry - Getting Started Guide :)

Harmannz (Thu, 11 Jan 2018 20:45:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=BkozPpFgXg8FXqrLA) @gudkov I get `indy-cli: symbol lookup error: indy-cli: undefined symbol: indy_build_pool_upgrade_request` when typing indy-cli. I have tried using the master, stable and rc to install libindy and indy-cli apt packages. Seems that the indy_build_pool_upgrade_request function from libindy api has not been incorporated to the indy-cli? I am not sure what this really means

Harmannz (Thu, 11 Jan 2018 20:45:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=BkozPpFgXg8FXqrLA) @gudkov I get `indy-cli: symbol lookup error: indy-cli: undefined symbol: indy_build_pool_upgrade_request` when typing indy-cli. I have tried using the master, stable and rc to install libindy and indy-cli apt packages. Seems that the indy_build_pool_upgrade_request function from libindy api is not supported by the indy-cli? I am not sure what this really means

gudkov (Fri, 12 Jan 2018 07:50:51 GMT):
@Harmannz it means that libindy.so doesn't contain indy_build_pool_upgrade_request function that is required by cli. You need to upgrade libindy package to the latest master.

nbrempel (Fri, 12 Jan 2018 17:32:35 GMT):
Hi @wittrock, the von-network project is used to run a network of 4 indy nodes for development. It allows you to connect via a generated genesis_transactions file or automatically via docker network discovery.

nbrempel (Fri, 12 Jan 2018 17:35:29 GMT):
For a Faber.py sort of implementation using the indy-sdk, we're working on an "end-to-end" example that implements issuers and verifiers and communicates with another system which acts as the holder

nbrempel (Fri, 12 Jan 2018 17:35:56 GMT):
That's here: https://github.com/bcgov/permitify. It should be complete next week.

swcurran (Sat, 13 Jan 2018 00:26:24 GMT):
@nbrempel - I like the sound of that..."complete next week" :-). :thumbsup:

schristie (Mon, 15 Jan 2018 21:48:37 GMT):
Has joined the channel.

arjanvaneersel (Tue, 16 Jan 2018 06:44:05 GMT):
@nage Sorry for the late reply. I just created the issue for the Go wrapper on Jura. I also took notice of the wrapper guidelines and I couldn't agree more on that documents. I think these guidelines make perfect sense. BIP doesn't ring a bell, but regarding Python I'm aware of PEP. Also within the Go community people often stress to write idiomatic go and follow certain standards, so I agree with you that it would be good to create some standard on that. Happy to help out there as well.

arjanvaneersel (Tue, 16 Jan 2018 12:11:59 GMT):
Did I understand correctly that Indy doesn't use Gerrit, but Github pull requests?

nage (Tue, 16 Jan 2018 13:43:48 GMT):
That is correct, we use Github to manage pull requests.

sklump (Tue, 16 Jan 2018 19:01:36 GMT):
*Intense question:* I want to create a proof on multiple claims. Suppose the following claims came back from a prover via anoncreds: ``` { "predicates": {}, "attrs": { "20_endDate_uuid": [ { "claim_uuid": "claim::19a80673-803c-4983-86f6-47e9b3481f43", ... }, { "claim_uuid": "claim::6918fe56-03c2-40a5-a573-fd6059c3e663", ..., }, { "claim_uuid": "claim::9239d6c1-3912-47c0-9a74-c69612328268", ... } } ], ... ``` Then the `prover_create_proof()` call wants (among other parameters) `requested_claims_json`, comments in-line look like: ``` :param requested_claims_json: either a claim or self-attested attribute for each requested attribute { "requested_attr1_uuid": [claim1_uuid_in_wallet, true ], "requested_attr2_uuid": [self_attested_attribute], "requested_attr3_uuid": [claim2_seq_no_in_wallet, false] "requested_attr4_uuid": [claim2_seq_no_in_wallet, true] ``` The sample takes the zeroth claim that shows up in the claims found (i.e., `claims['attrs'][uuid][0]`) - but I want to include more than one claim for attribute revelation. How do I specify this in `requested_claims_json`? It looks like the keys have to match the ones in the claim, but every key has to be distinct of course.

sklump (Tue, 16 Jan 2018 19:01:36 GMT):
*Intense question:* I want to create a proof on multiple claims. Suppose the following claims came back from a prover via anoncreds: ``` { "predicates": {}, "attrs": { "20_endDate_uuid": [ { "claim_uuid": "claim::19a80673-803c-4983-86f6-47e9b3481f43", ... }, { "claim_uuid": "claim::6918fe56-03c2-40a5-a573-fd6059c3e663", ..., }, { "claim_uuid": "claim::9239d6c1-3912-47c0-9a74-c69612328268", ... } } ], ... ``` Then the `prover_create_proof()` call wants (among other parameters) `requested_claims_json`, comments in-line look like: ``` :param requested_claims_json: either a claim or self-attested attribute for each requested attribute { "requested_attr1_uuid": [claim1_uuid_in_wallet, true ], "requested_attr2_uuid": [self_attested_attribute], "requested_attr3_uuid": [claim2_seq_no_in_wallet, false] "requested_attr4_uuid": [claim2_seq_no_in_wallet, true] ``` The sample takes the zeroth claim that shows up in the claims found (i.e., `claims['attrs'][uuid][0]['claim_uuid']`) - but I want to include more than one claim for attribute revelation. How do I specify this in `requested_claims_json`? It looks like the keys have to match the ones in the claim (i.e., `20_endDate_uuid`, but every key has to be distinct of course.

sklump (Tue, 16 Jan 2018 19:01:36 GMT):
*Intense question:* I want to create a proof on multiple claims. Suppose the following claims came back from a prover via anoncreds: ``` { "predicates": {}, "attrs": { "20_endDate_uuid": [ { "claim_uuid": "claim::19a80673-803c-4983-86f6-47e9b3481f43", ... }, { "claim_uuid": "claim::6918fe56-03c2-40a5-a573-fd6059c3e663", ..., }, { "claim_uuid": "claim::9239d6c1-3912-47c0-9a74-c69612328268", ... } ], ... ``` Then the `prover_create_proof()` call wants (among other parameters) `requested_claims_json`, comments in-line look like: ``` :param requested_claims_json: either a claim or self-attested attribute for each requested attribute { "requested_attr1_uuid": [claim1_uuid_in_wallet, true ], "requested_attr2_uuid": [self_attested_attribute], "requested_attr3_uuid": [claim2_seq_no_in_wallet, false] "requested_attr4_uuid": [claim2_seq_no_in_wallet, true] ``` The sample takes the zeroth claim that shows up in the claims found (i.e., `claims['attrs'][uuid][0]['claim_uuid']`) - but I want to include more than one claim for attribute revelation. How do I specify this in `requested_claims_json`? It looks like the keys have to match the ones in the claim (i.e., `20_endDate_uuid`, but every key has to be distinct of course.

sklump (Tue, 16 Jan 2018 19:01:36 GMT):
*Intense question:* I want to create a proof on multiple claims. Suppose the following claims came back from a prover via anoncreds: ``` { "predicates": {}, "attrs": { "20_endDate_uuid": [ { "claim_uuid": "claim::19a80673-803c-4983-86f6-47e9b3481f43", ... }, { "claim_uuid": "claim::6918fe56-03c2-40a5-a573-fd6059c3e663", ..., }, { "claim_uuid": "claim::9239d6c1-3912-47c0-9a74-c69612328268", ... } ], ... ``` Then the `prover_create_proof()` call wants (among other parameters) `requested_claims_json`, comments in-line look like: ``` :param requested_claims_json: either a claim or self-attested attribute for each requested attribute { "requested_attr1_uuid": [claim1_uuid_in_wallet, true ], "requested_attr2_uuid": [self_attested_attribute], "requested_attr3_uuid": [claim2_seq_no_in_wallet, false] "requested_attr4_uuid": [claim2_seq_no_in_wallet, true] ``` The sample takes the zeroth claim that shows up in the claims found (i.e., `claims['attrs'][uuid][0]['claim_uuid']`) - but I want to include more than one claim for attribute revelation. How do I specify this in `requested_claims_json`? It looks like the keys have to match the ones in the claim (i.e., `20_endDate_uuid`), but every key has to be distinct of course.

sklump (Tue, 16 Jan 2018 19:03:17 GMT):
PS - I know I am still on indy-sdk 1.1.1-dev-279, the last release with uuids. Once I have multi-claim proofs going I can look at migrating to 1.3.

sklump (Tue, 16 Jan 2018 19:03:17 GMT):
Or is the idea that a proof can only operate on one claim per claim-def? That might make sense as a restriction, hence the [0] would be OK. PS - I know I am still on indy-sdk 1.1.1-dev-279, the last release with uuids. Once I have multi-claim proofs going I can look at migrating to 1.3.

Rickzan (Tue, 16 Jan 2018 19:23:56 GMT):
Has joined the channel.

dwjohnston (Tue, 16 Jan 2018 22:46:03 GMT):
Has joined the channel.

dwjohnston (Tue, 16 Jan 2018 22:46:18 GMT):
Blockchain stack exchange is in commitment phase: https://area51.stackexchange.com/proposals/106592/blockchain-technology

dwjohnston (Tue, 16 Jan 2018 22:47:15 GMT):
@gudkov re: indy-cli could you look at this issue? https://github.com/hyperledger/indy-sdk/issues/485 - I'm unable to install.

arjanvaneersel (Wed, 17 Jan 2018 07:47:04 GMT):
@nage That's clear. I forked the repo and started development on the fork. I suppose the proper moment to issue a pull request is when the wrapper reaches its first form of completeness, like an alpha version.

gudkov (Wed, 17 Jan 2018 08:11:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=eTgtn84M4PPJNq79x) Instruction says change stable to master or rc if needed. For current moment we don't have CLI in stable and rc repos as there was no CLI release. So you can use only master repo now: sudo add-apt-repository "deb https://repo.sovrin.org/sdk/deb xenial master" Not sure that we need change instruction as release is planned soon.

ashcherbakov (Wed, 17 Jan 2018 08:39:52 GMT):
@sklump it's possible to specify any claims for each requested attribute in proof request. Each attribute in proof request may be associated with a different claim (created from any claim def). The workflow is the following (see https://github.com/hyperledger/indy-sdk/blob/master/doc/libindy-anoncreds.svg): - Verifier sends Proof request to the prover specifying requested attribute (that must be revealed) and the predicates. For each attribute/predicate the Verifier can specify a number of filters (claim def and/or schema as of now). - Prover calls `prover_get_claims_for_proof_req` to find all claims for each requested attributes/predicates according to the filters. - the prover can *select* (probably in UI or by application logic) which claims will be used in proofs, that is what claim to use for each requested attribute/predicate. Each attr/predicate can be associated with a *different* claim. It's possible to select just one claim for each attr/predicate, but I think there is no much sense in selecting more than one for a given attribute. - prover generates proofs for each selected claim => we have a multi-claim proof (or agregated proof) consisting of a number of sub-proofs for each selectected claim. - the final proof (sent to the verifier) contains a mapping of each requested attribute/predicate to the generated sub-proof amd claim-def/schema used to create the proof. - the Verifier can verify the multi-claim proof (that is all subproofs), and if he is fine with the claim-def/schemas used to create the proofs (that is with claims used to create the proofs), then he can say that verification passed. BTW all described logic (including multi-claim support) is in SDK from the very first version.

ashcherbakov (Wed, 17 Jan 2018 08:39:52 GMT):
@sklump it's possible to specify any claims for each requested attribute in proof request. Each attribute in proof request may be associated with a different claim (created from any claim def). The workflow is the following (see https://github.com/hyperledger/indy-sdk/blob/master/doc/libindy-anoncreds.svg): - Verifier sends Proof request to the prover specifying requested attribute (that must be revealed) and the predicates. For each attribute/predicate the Verifier can specify a number of filters (claim def and/or schema as of now). - Prover calls `prover_get_claims_for_proof_req` to find all claims for each requested attributes/predicates according to the filters. - the prover can *select* (probably in UI or by application logic) which claims will be used in proofs, that is what claim to use for each requested attribute/predicate. Each attr/predicate can be associated with a *different* claim. It's possible to select just one claim for each attr/predicate, but I think there is no much sense in selecting more than one for a given attribute with the current quite simple proof request format (I believe we may support it in future if needed with evolving of proof request). - prover generates proofs for each selected claim => we have a multi-claim proof (or agregated proof) consisting of a number of sub-proofs for each selectected claim. - the final proof (sent to the verifier) contains a mapping of each requested attribute/predicate to the generated sub-proof amd claim-def/schema used to create the proof. - the Verifier can verify the multi-claim proof (that is all subproofs), and if he is fine with the claim-def/schemas used to create the proofs (that is with claims used to create the proofs), then he can say that verification passed. BTW all described logic (including multi-claim support) is in SDK from the very first version.

sklump (Wed, 17 Jan 2018 12:19:30 GMT):
Thanks for the figure of the 20000-foot view, never wrong. The trouble I'm having is in the details. In particular, > - the prover can *select* (probably in UI or by application logic) which claims will be used in proofs, that is _what claim to use for each requested attribute/predicate_. Each attr/predicate can be associated with a *different* claim. It's possible to select just one claim for each attr/predicate, but I think there is no much sense in selecting more than one for a given attribute with the current quite simple proof request format (I believe we may support it in future if needed with evolving of proof request) [_italics mine_ - SK] Just to make sure I understand this, what the proof request format supports currently is to specify at most one claim for each attribute. Do I have this right? Thanks in advance for your patience.

sklump (Wed, 17 Jan 2018 12:19:30 GMT):
Thanks for the figure of the 20000-foot view, never wrong. The trouble I'm having is in the details. In particular, > - the prover can *select* (probably in UI or by application logic) which claims will be used in proofs, that is _what claim to use for each requested attribute/predicate_. Each attr/predicate can be associated with a *different* claim. It's possible to select just one claim for each attr/predicate, but I think there is no much sense in selecting more than one for a given attribute with the current quite simple proof request format (I believe we may support it in future if needed with evolving of proof request) [ _italics mine_ - SK] Just to make sure I understand this, what the proof request format supports currently is to specify at most one claim for each attribute. Do I have this right? Thanks in advance for your patience.

ashcherbakov (Wed, 17 Jan 2018 12:39:18 GMT):
Yes. Technically proof request just asks for an attribute/predicate and restircts possible claims to be used there according to the filter. The prover can specify just one claim (according to filters) as of now.

ashcherbakov (Wed, 17 Jan 2018 12:39:43 GMT):
Can you please provide your use case where you need more than one claim to be specified?

nij458 (Wed, 17 Jan 2018 12:45:41 GMT):
Has joined the channel.

sklump (Wed, 17 Jan 2018 12:46:03 GMT):
I believe my use case was overly broad and we need not make it work, but of purely academic interest: "show me all the people in this group who got that licence in year 2017 and create me a proof that shows their licences are still valid". The indy-sdk way to do this would be to issue a proof per person, not one giant proof for everyone.

nij458 (Wed, 17 Jan 2018 12:46:28 GMT):
Hi all, I am new to Indy and I am trying to build the indy-sdk on my MacOS using the guide (https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md). I have followed the guide without issue up until running "cargo build". The guide (https://github.com/hyperledger/indy-sdk/blob/master/wrappers/java/README.md) says that I should expect to see a file "libindy.so" after "cargo build" finishes executing and move it to "./lib/", "cargo build" runs successfully yet I cannot find the file "libindy.so" anywhere in the directory. Have you come across this issue before? Is there a step I am missing that isn't in the guides? Thanks, Nij

sklump (Wed, 17 Jan 2018 12:46:49 GMT):
@nij458 , you will find it in target/debug/libindy.so

sklump (Wed, 17 Jan 2018 12:46:49 GMT):
@nij458 , you will find it in `target/debug/libindy.so` within the indy-sdk directory structure.

sklump (Wed, 17 Jan 2018 12:46:49 GMT):
@nij458 , you will find it at `target/debug/libindy.so` within the indy-sdk directory structure.

gudkov (Wed, 17 Jan 2018 12:48:14 GMT):
.so is dynamic lib format and extension used commonly on linux. On mac you should look for .dylib

nij458 (Wed, 17 Jan 2018 12:49:53 GMT):
@gudkov i have the .dylib, thanks for the help!

ashcherbakov (Wed, 17 Jan 2018 12:54:33 GMT):
@sklump As for your use case: The claim itself is a secret information, and belongs to the user it was issued for only (this is one of the main principles of anoncreds). So, there should not be one entity having access to claims for different users. Please note that only prover can create a proof, not the issuer. So, each prover can create a proof for a claim he owns. I think your use case can be solved either not using anoncreds and just asking the issuer (driver license issuer), or to create claims and proof requests in a special way. For exameple, there can be a Claim containing info about the number of issued licenses each month, and the issuer creates such claims for a special organization. This organization then can create a proof about the number of existing driver licenses.

brycecurtis (Wed, 17 Jan 2018 14:59:58 GMT):
Has joined the channel.

hawkmauk (Wed, 17 Jan 2018 16:39:08 GMT):
Has joined the channel.

metal.carratt (Wed, 17 Jan 2018 20:17:45 GMT):
Has joined the channel.

metal.carratt (Wed, 17 Jan 2018 20:22:45 GMT):
Hi everyone, we're trying to create a Java REST API using the Java-wrapper for the Indy sdk. We have the following code:

metal.carratt (Wed, 17 Jan 2018 20:24:36 GMT):
Which works when we run it purely as a jar file using java -jar on the command line. However as soon as I deploy it to tomcat and use Jersey to invoke it on a rest endpoint it fails with the following error: java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.IOException: An IO error occurred.

metal.carratt (Wed, 17 Jan 2018 20:26:43 GMT):
This happens on line 8, when 'get' is called on the CompletableFuture. We think it's something related to the pool json parameter file, but nothing is different between when we run it as a jar or on the tomcat server. We also put the file onto the filesystem to rule out an error with classpaths. Does anyone know what we could be doing wrong?

metal.carratt (Wed, 17 Jan 2018 21:27:47 GMT):
Hi, sorry, have got this working now. Tomcat needed to be able to write to it's home directory in order to use the sdk and didn't have permissions to do this by default.

Harmannz (Wed, 17 Jan 2018 23:00:28 GMT):
Hi, I was wanting to know if there is documentation on how libindy works? For example, where can I look/read to understand how libindy reads the pool_transactions_genesis file and attempts to connect to a pool. I am having a hard time traversing through the rust source code. Any help is appreciated.

Harmannz (Wed, 17 Jan 2018 23:00:28 GMT):
Hi, I was wanting to know if there is documentation on how libindy works? All I know is that there is a libindy api that the wrappers call, but the internal workings are all black box to me. For example, where can I look/read to understand how libindy reads the pool_transactions_genesis file and attempts to connect to a pool. I am having a hard time traversing through the rust source code. Any help is appreciated.

Harmannz (Wed, 17 Jan 2018 23:00:28 GMT):
Hi, I was wanting to know if there is documentation on how libindy works? Everything behind the libindy api is black box to me. For example, where can I look/read to understand how libindy reads the pool_transactions_genesis file and attempts to connect to a pool. I am having a hard time traversing through the rust source code. Any help is appreciated.

arjanvaneersel (Thu, 18 Jan 2018 06:29:29 GMT):
@nage @gudkov I started working on the Go wrapper as said earlier, but having one thing which isn't clear to be. Now dealing with the indy_create_wallet. This function will return an indy_error_t, but in the callback function is also an argument of type indy_error_t. So this makes me wonder if the same error is returned and passed to the callback function? Or are we talking about different errors here?

gudkov (Thu, 18 Jan 2018 07:14:06 GMT):
@arjanvaneersel Asynchronous calls execution contains 2 steps: 1. Basic validation performed in user thread. It can return indy_error_t synchronously. If it is error callback will not be called. 2. Switching execution to libindy thread and returning indy_error_t in callback Actually it is the same indy_error_t, but you need to check it 2 times. It seems a bit uggly in C, but in more high level languages with futures or coroutines it simplifies. You can look for python wrapper for example: 1. We create Future 2. We call async function and check result 3. If result isn't success than we fail Future and immediately return 4. If result is success we return Future in progress and will resolve it in callback See https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/indy/libindy.py "do_call" method allows to call any libindy function by name and returns Future

arjanvaneersel (Thu, 18 Jan 2018 07:16:58 GMT):
@gudkov, thanks. That makes things a lot more clear.

sklump (Thu, 18 Jan 2018 21:24:39 GMT):
Quick question: does the indy-sdk enforce any kind of uniqueness on (nonce, name, version) within the proof-request data structure? I haven't noticed it squawking even when I give it the same values over and over. They may be a convenience for the caller's logging? I'm not in any way complaining, just asking.

ashcherbakov (Fri, 19 Jan 2018 15:44:44 GMT):
I believe there are no such checks as of now. @gudkov ?

nbrempel (Sun, 21 Jan 2018 19:51:22 GMT):
I'm seeing some strange new behaviour. `seqNo` has started coming back null on all ledger requests.

nbrempel (Sun, 21 Jan 2018 19:52:48 GMT):
https://gist.github.com/nrempel/e512909255ffb811b8ae952c85cbb513

nbrempel (Sun, 21 Jan 2018 19:52:48 GMT):
example: https://gist.github.com/nrempel/e512909255ffb811b8ae952c85cbb513

nbrempel (Sun, 21 Jan 2018 19:53:13 GMT):
Does anyone know why this might have started happening?

gudkov (Mon, 22 Jan 2018 07:27:51 GMT):
@nbrempel Could you provide Node's logs? Contact @ashcherbakov if you need any help with this.

nbrempel (Mon, 22 Jan 2018 16:31:09 GMT):
@ashcherbakov @gudkov If I `tail` `/var/log/indy/sandbox/Node1.log` on the Node1 container, I don't see any logs when I query the ledger. Is there another log file that I can watch?

nbrempel (Mon, 22 Jan 2018 16:35:25 GMT):
Here is Node1.log https://gist.github.com/nrempel/010330019f0816b21119d4f3f7eb5c61

nbrempel (Tue, 23 Jan 2018 03:57:21 GMT):
I managed to resolve this issue, it was an error on my part

nbrempel (Tue, 23 Jan 2018 03:59:34 GMT):
I was attempting to retrieve a schema from the ledger using an invalid did

akhihaki (Tue, 23 Jan 2018 17:57:42 GMT):
Has joined the channel.

JustinBoyer (Tue, 23 Jan 2018 22:59:07 GMT):
Has joined the channel.

sayan.hlf (Wed, 24 Jan 2018 06:56:00 GMT):
Has joined the channel.

sayan.hlf (Wed, 24 Jan 2018 06:57:42 GMT):
Hello All, I'm trying to setup the Indy SDK environment as mentioned in the link: https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md However, I am getting the following error while trying to run the command: RUST_TEST_THREADS=1 cargo test root@ip-172-31-22-54:~/project-indy/indy-sdk/libindy# RUST_TEST_THREADS=1 cargo test Compiling indy-crypto v0.2.0 error: associated constants are experimental (see issue #29646) --> /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/indy-crypto-0.2.0/src/pair/amcl.rs:49:5 | 49 | const BYTES_REPR_SIZE: usize = MODBYTES * 4; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: associated constants are experimental (see issue #29646) --> /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/indy-crypto-0.2.0/src/pair/amcl.rs:198:5 | 198 | const BYTES_REPR_SIZE: usize = MODBYTES * 4; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: associated constants are experimental (see issue #29646) --> /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/indy-crypto-0.2.0/src/pair/amcl.rs:326:5 | 326 | const BYTES_REPR_SIZE: usize = MODBYTES; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: associated constants are experimental (see issue #29646) --> /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/indy-crypto-0.2.0/src/pair/amcl.rs:490:5 | 490 | const BYTES_REPR_SIZE: usize = MODBYTES * 16; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 4 previous errors error: Could not compile `indy-crypto`.

nicolapaoli (Wed, 24 Jan 2018 09:37:45 GMT):
Has joined the channel.

sergey.minaev (Wed, 24 Jan 2018 16:01:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=2zt7fKKLqmJLpGh3e) Hi @sayan.hlf, sounds like you try to build IndySDK with out-of-date Rust compiler. Please update it ( `rustup update` ).

mhailstone (Wed, 24 Jan 2018 17:40:38 GMT):
I am trying to run the Java samples and am getting the following error: ```Exception in thread "main" java.lang.UnsatisfiedLinkError: Error looking up function 'indy_prep_msg': dlsym(0x7fa621a28ac0, indy_prep_msg): symbol not found at com.sun.jna.Function.(Function.java:245) at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:566) at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:542) at com.sun.jna.NativeLibrary.getFunction(NativeLibrary.java:528) at com.sun.jna.Library$Handler.invoke(Library.java:228) at com.sun.proxy.$Proxy0.indy_prep_msg(Unknown Source) at org.hyperledger.indy.sdk.agent.Agent.prepMsg(Agent.java:115) at Agent.demo(Agent.java:28) at Main.main(Main.java:4)```

jtsiros (Wed, 24 Jan 2018 22:58:55 GMT):
Has joined the channel.

jtsiros (Wed, 24 Jan 2018 22:58:58 GMT):
Hello! I need some help with the indy-crypto library: Currently, I'm trying to call the indy-crypto library functions as a C library from Golang. I've created the header files for Golang along with importing the dylib into my project. ``` extern indy_crypto_error_t indy_crypto_bls_sign_key_new(unsigned char* seed, size_t seed_len, const void* sign_key_p); ``` Here is my Go calling code: ``` func NewSigningKey() { var cInstance interface{} ptr := unsafe.Pointer(&cInstance) e := C.indy_crypto_bls_sign_key_new(nil, C.size_t(0), ptr) fmt.Println("new sign key initialized result:", e) C.indy_crypto_bls_generator_free(ptr) } ``` Here are the directives I'm setting at the top: ``` /* #cgo CFLAGS: -I../dyLib #cgo LDFLAGS: -L../dylib -lindy_crypto #include */ import "C" ``` The issue is that I'm getting a malloc error message when attempting to free that pointer that was allocated: ``` new sign key initialized result: 0 didnet(5608,0x7fffaec0d3c0) malloc: *** error for object 0xc4200104f0: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug SIGABRT: abort PC=0x7fffa5e1ed42 m=0 sigcode=0 signal arrived during cgo execution goroutine 1 [syscall, locked to thread]: runtime.cgocall(0x40c9670, 0xc420055ba8, 0x4028fd6) /usr/local/Cellar/go/1.9.2/libexec/src/runtime/cgocall.go:132 +0xe4 fp=0xc420055b78 sp=0xc420055b38 pc=0x4003b94 ***/rp/didnet/crypto._Cfunc_indy_crypto_bls_generator_free(0xc4200104f0, 0xc400000000) ```

sergey.minaev (Thu, 25 Jan 2018 08:42:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4vziDuvNCxawhfaSE) @mhailstone I check current master and seems like samples are out of date against `libindy`. Agent API was removed and partially moved to other subsystem. Please create issue about out of date samples in IndySDK JIRA https://jira.hyperledger.org/projects/IS/ (if you want). Usually we re-check compatibility on each stable release. But right now stable version significantly differs against master.

sergey.minaev (Thu, 25 Jan 2018 08:53:20 GMT):
Hi @jtsiros! I'm not familiar with Go, but there is a possible issue in C header: `sign_key_p` should be pointer to pointer. And `indy_crypto_bls_generator_free` accept just pointer. So I can try to guess about correct Go code: ``` ... C.indy_crypto_bls_sign_key_new(nil, C.size_t(0), &ptr) ... C.indy_crypto_bls_generator_free(ptr) ... ```

sklump (Thu, 25 Jan 2018 16:25:19 GMT):
Hi folks, quick question: is the rc branch of indy-sdk on github currently aligned to v1.3.0-rc9 on pypi?

sklump (Thu, 25 Jan 2018 16:25:19 GMT):
Hi folks, quick question: Which pypi version corresponds to the current master branch version on github?

sklump (Thu, 25 Jan 2018 16:29:24 GMT):
My connection here is like being in a submarine, and I cannot afford to download it more than necessary.

drew 41 (Thu, 25 Jan 2018 16:35:34 GMT):
Has joined the channel.

sklump (Thu, 25 Jan 2018 16:47:27 GMT):
It looks like python3-indy-1.3.0-dev-337 corresponds to commit 03b9178199347bbc731ed11cad25332549e9709d. Please correct me if that's wrong.

jtsiros (Thu, 25 Jan 2018 17:27:06 GMT):
@sergey.minaev yes, you were correct. I fixed that and it worked

Harmannz (Fri, 26 Jan 2018 01:57:51 GMT):
Hi all, can someone confirm if there is any other benefit in creating pairwise relationship between two dids `Pairwise.createPairwise(..)` than to check if you have interacted with a specific did before? We use Pairwise method to simply store the association between 'my did' and 'their did

notOccupanther (Fri, 26 Jan 2018 11:05:26 GMT):
HI .. I'm newb status here .. and am looking at using Indy in my Final Year Project for my part-time college course. My theme is 'Digitized Academic Accreditation on the Blockchain'. I've got the sandbox Faber College demo up and runnig .. but just thinking ahead, is there any info on how I might go about plugging in a web front-end onto the demo?

notOccupanther (Fri, 26 Jan 2018 11:40:40 GMT):
Actually .. I just have to go back to the Tuna demo in the edX course and take start there no?

notOccupanther (Fri, 26 Jan 2018 11:40:40 GMT):
Actually .. I just have to go back to the Tuna demo in the edX course and start there I guess?

tkuhrt (Fri, 26 Jan 2018 12:46:23 GMT):
SeanBohan_Sovrin

gudkov (Fri, 26 Jan 2018 15:28:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qmH4W9THBcShWq6nq) @Harmannz Yes, It just allows to store some application specific metadata for pairwise connection in secure way.

ianco (Sat, 27 Jan 2018 02:02:27 GMT):

Clipboard - January 26, 2018 6:02 PM

ianco (Sat, 27 Jan 2018 02:02:42 GMT):
Hi folks, I've noticed there are two separate wallet programs - one in indy-node/indy-client/client (Python) and one in indy-sdk/

ianco (Sat, 27 Jan 2018 02:03:52 GMT):
... (Rust). Is the intent to maintain both of these? They seem to do the same thing, but with a different command syntax ...

ianco (Sat, 27 Jan 2018 02:21:05 GMT):
... seems like the cli is deleted in the indy-sdk RC branch, so I assume the standard client/wallet is the Python version in the indy-node repo?

nhan.trong.nguyen (Mon, 29 Jan 2018 06:33:10 GMT):
Hi all, I am working on python wrapper, function 'ledger.build_schema_request' and i do not know what role (Trustee, Steward, TrustAnchor and No Role) can submit schema request to ledger. Could you tell me about that or is there some document about the roles? Thank you.

nhan.trong.nguyen (Mon, 29 Jan 2018 08:55:12 GMT):
Our environment: ubuntu: 16.04 indy-node: 1.2.50 indy-plenum: 1.2.29 indy-anoncreds: 1.0.11 sovrin: 1.1.7 Also in 'ledger.build_schema_reuqest(submitter_did, schema_data)', I found out that ledger also accepts schema with 'schema_data' whose field 'attr_names' contains duplicated attribute name. In this case, I think some exceptions should be raised.

NiallC (Mon, 29 Jan 2018 14:39:28 GMT):
Has joined the channel.

Harmannz (Mon, 29 Jan 2018 22:01:49 GMT):
@nhan.trong.nguyen If you look [here](https://github.com/hyperledger/indy-node/blob/master/docs/transactions.md#general-information) you will find information regarding ledgers and link to roles and permissions

Harmannz (Mon, 29 Jan 2018 22:47:02 GMT):
Hi all, I have a question about the format of claim values. For example, when an agent creates a claim via `Anoncreds.issuerCreateClaim(...).get();` the agent must provide a claim values JSON object. In the java tests, an example of a claim is: ``` String claim = "{" + " \"sex\":[\"male\",\"2142657394558967239210949258394838228692050081607692519917028371144233115103\"],\n" + " \"name\":[\"Alexander\",\"21332817548165488690172217217278169335\"],\n" + " \"height\":[\"170\",\"170\"],\n" + " \"age\":[\"28\",\"28\"]\n" + " }"; ``` I don't understand why the value of each key must be an array and what the last element in the array mean? Can someone explain. I have tried returning just a value instead of an array for each attribute which resulted in an InvalidStructureException.

Harmannz (Mon, 29 Jan 2018 22:47:02 GMT):
Hi all, I have a question about the format of claim values. For example, when an agent creates a claim via `Anoncreds.issuerCreateClaim(...).get();` the agent must provide a claim values JSON object. In the java tests, an example of a claim is: ``` String claim = "{" + " \"sex\":[\"male\",\"2142657394558967239210949258394838228692050081607692519917028371144233115103\"],\n" + " \"name\":[\"Alexander\",\"21332817548165488690172217217278169335\"],\n" + " \"height\":[\"170\",\"170\"],\n" + " \"age\":[\"28\",\"28\"]\n" + " }"; ``` I don't understand why the value of each key must be an array and what the last element in the array mean? Can someone explain? I have tried returning just a value instead of an array for each attribute which resulted in an InvalidStructureException.

nhan.trong.nguyen (Tue, 30 Jan 2018 02:44:30 GMT):
@Harmannz Thank you so much. The document is really helpful.

nghia47 (Tue, 30 Jan 2018 03:13:49 GMT):
Hi all, I am working on schema and looking for the data range of its attributes. Is there any related documents?

ashcherbakov (Tue, 30 Jan 2018 08:46:06 GMT):
@nghia47 https://github.com/hyperledger/indy-node/blob/master/docs/requests.md#schema https://github.com/hyperledger/indy-node/blob/master/docs/transactions.md#schema

nghia47 (Tue, 30 Jan 2018 08:52:45 GMT):
Thanks @ashcherbakov

ashcherbakov (Tue, 30 Jan 2018 08:56:02 GMT):
@Harmannz Anoncreds assume that all attributes must be integers. But not all attribute values are inetegers ('name', 'sex'). So, we need to convert string values to integers and preserve real (string) values as well. So, we have an array of two elements: real value and the value as ineteger. If it's alrady integer, we just use it as is (heigh, age). If this is no an integer, we convert it to integer in some predictable way (usually it's up to application; for example Timestamp can be converted to milliseconds in UTC).

nghia47 (Tue, 30 Jan 2018 09:04:38 GMT):
@ashcherbakov i am able to create a schema with duplicated Attribute name (both SDK and CLI). I wonder what is the purpose of this behavior as most implementations of JSON libraries do not accept duplicate keys. Do you have any idea on this case?

nmellal (Tue, 30 Jan 2018 09:56:58 GMT):
Has joined the channel.

EtienneNijboer (Tue, 30 Jan 2018 10:53:22 GMT):
Has joined the channel.

mark.hadley (Tue, 30 Jan 2018 20:58:43 GMT):
Where is CI/CD for this created? I'm unable to find an entry for indy-sdk in jenkins.hyperledger.org

jtsiros (Wed, 31 Jan 2018 00:31:16 GMT):
hello, I'm having a bit of trouble retrieving the sign and ver key from indy_crypto lib as bytes or as a string and encoding it as base58: ``` create sign key (0xc420018350) raw (0) indy_crypto_bls_sign_key_new: >>> seed: 0x0, seed_len: 0, sign_key_p: 0xc420018350 sign key (0xc420018350) raw: (81789568) - created sign key bytes ptr: (0xc42000e038) initial len: (0) fetch sign key bytes at (0xc42000e038) len: (32) O��0��>XQ-Trc)��I ��_ ``` I'm using the following C ABI functions from the library in Go: ``` C.indy_crypto_bls_sign_key_new(nil, C.size_t(0), keyP) C.indy_crypto_bls_sign_key_as_bytes(skPtr, &bytesPtr, &bLen) key := C.GoStringN(bytesPtr, C.int(bLen)) fmt.Println(key)

jtsiros (Wed, 31 Jan 2018 00:31:16 GMT):
hello, I'm having a bit of trouble retrieving the sign and ver key from indy_crypto lib as bytes or as a string and encoding it as base58: ``` create sign key (0xc420018350) raw (0) indy_crypto_bls_sign_key_new: >>> seed: 0x0, seed_len: 0, sign_key_p: 0xc420018350 sign key (0xc420018350) raw: (81789568) - created sign key bytes ptr: (0xc42000e038) initial len: (0) fetch sign key bytes at (0xc42000e038) len: (32) O��0��>XQ-Trc)��I ��_ ``` I'm using the following C ABI functions from the library in Go: ``` C.indy_crypto_bls_sign_key_new(nil, C.size_t(0), keyP) C.indy_crypto_bls_sign_key_as_bytes(skPtr, &bytesPtr, &bLen) Using GoStringN to fetch the contents of byte array as a string key := C.GoStringN(bytesPtr, C.int(bLen)) fmt.Println(key)

jtsiros (Wed, 31 Jan 2018 00:31:16 GMT):
hello, I'm having a bit of trouble retrieving the sign and ver key from indy_crypto lib as bytes or as a string and encoding it as base58: ``` create sign key (0xc420018350) raw (0) indy_crypto_bls_sign_key_new: >>> seed: 0x0, seed_len: 0, sign_key_p: 0xc420018350 sign key (0xc420018350) raw: (81789568) - created sign key bytes ptr: (0xc42000e038) initial len: (0) fetch sign key bytes at (0xc42000e038) len: (32) O��0��>XQ-Trc)��I ��_ ``` I'm using the following C ABI functions from the library in Go: ``` C.indy_crypto_bls_sign_key_new(nil, C.size_t(0), keyP) C.indy_crypto_bls_sign_key_as_bytes(skPtr, &bytesPtr, &bLen) Using GoStringN to fetch the contents of byte array as a string key := C.GoStringN(bytesPtr, C.int(bLen)) fmt.Println(key) ``` Is the key returned supposed to be binary or a 32 bit number?

jtsiros (Wed, 31 Jan 2018 00:31:16 GMT):
hello, I'm having a bit of trouble retrieving the sign and ver key from indy_crypto lib as bytes or as a string and encoding it as base58: ``` create sign key (0xc420018350) raw (0) indy_crypto_bls_sign_key_new: >>> seed: 0x0, seed_len: 0, sign_key_p: 0xc420018350 sign key (0xc420018350) raw: (81789568) - created sign key bytes ptr: (0xc42000e038) initial len: (0) fetch sign key bytes at (0xc42000e038) len: (32) O��0��>XQ-Trc)��I ��_ ``` I'm using the following C ABI functions from the library in Go: ``` C.indy_crypto_bls_sign_key_new(nil, C.size_t(0), keyP) C.indy_crypto_bls_sign_key_as_bytes(skPtr, &bytesPtr, &bLen) Using GoStringN to fetch the contents of byte array as a string key := C.GoStringN(bytesPtr, C.int(bLen)) fmt.Println(key) ``` Is the key returned supposed to be binary or a 32 bit number? Right now it looks like garbage

jtsiros (Wed, 31 Jan 2018 00:41:59 GMT):
also, does anyone know how to turn on debugging statements for that library? It looks like function calls are decorated with the trace! macro, but I can't get any output to print even when setting `RUST_LOG=trace`

jtsiros (Wed, 31 Jan 2018 01:00:17 GMT):
here is some more detailed logging. It looks like the same exact bytes representation on both ends: ``` create sign key (0xc420018350) raw (0) indy_crypto_bls_sign_key_new: >>> seed: 0x0, seed_len: 0, sign_key_p: 0xc420018350 indy_crypto_bls_sign_key_new: seed: None indy_crypto_bls_generator_new: gen: SignKey { group_order_element: GroupOrderElement { bn: BIG: [ 09B46A660344877C7030BDCC745B9318F2FD3DA63E444756D1DC81FA8E5A5F46 ] }, bytes: [9, 180, 106, 102, 3, 68, 135, 124, 112, 48, 189, 204, 116, 91, 147, 24, 242, 253, 61, 166, 62, 68, 71, 86, 209, 220, 129, 250, 142, 90, 95, 70] } indy_crypto_bls_sign_key_new: *sign_key_p: 0x5502750 indy_crypto_bls_sign_key_new: <<< res: Success sign key (0xc420018350) raw: (89139024) - created sign key bytes ptr: (0xc42000e038) initial len: (0) indy_crypto_bls_sign_key_as_bytes: >>> sign_key: 0x5502750, bytes_p: 0xc42000e038, bytes_len_p: 0xc420018360 indy_crypto_bls_sign_key_as_bytes: sign_key: SignKey { group_order_element: GroupOrderElement { bn: BIG: [ 09B46A660344877C7030BDCC745B9318F2FD3DA63E444756D1DC81FA8E5A5F46 ] }, bytes: [9, 180, 106, 102, 3, 68, 135, 124, 112, 48, 189, 204, 116, 91, 147, 24, 242, 253, 61, 166, 62, 68, 71, 86, 209, 220, 129, 250, 142, 90, 95, 70] } indy_crypto_bls_sign_key_as_bytes: <<< res: Success fetch sign key bytes at (0xc42000e038) len: (32) fetched bytes: [9 180 106 102 3 68 135 124 112 48 189 204 116 91 147 24 242 253 61 166 62 68 71 86 209 220 129 250 142 90 95 70]% ```

ashcherbakov (Wed, 31 Jan 2018 08:05:02 GMT):
@mark.hadley We're in process of moving CI for Indy projects from Evernym's Jenkins (private) to Hyperledger's one (public). CD part will stay private (on Evernym's Jenkins)

sergey.minaev (Wed, 31 Jan 2018 11:10:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=sc3AKatvyeysX8Tfm) @ianco Indy CLI (Rust, based on IndySDK) is actual. `indy` (python, based on indy-node) will be deprecated soon

sergey.minaev (Wed, 31 Jan 2018 11:10:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=sc3AKatvyeysX8Tfm) @ianco `indy-cli` (Rust, based on IndySDK) is actual. `indy` (python, based on indy-node) will be deprecated soon

sergey.minaev (Wed, 31 Jan 2018 11:11:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=rRTAaEkGQjy6Bbi8w) @ianco `indy-cli` isn't deleted from RC. It hasn't RC or stable version yet (only master builds).

sergey.minaev (Wed, 31 Jan 2018 11:20:54 GMT):
@jtsiros `indy_crypto_bls_sign_key_as_bytes` returns raw binary data

sergey.minaev (Wed, 31 Jan 2018 11:23:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=otCLkHwJAbtHTST9o) @jtsiros right now there are now API calls to configure logging. @gudkov do we plan (or have ticket in Jira) about indy-crypto logging?

sergey.minaev (Wed, 31 Jan 2018 11:23:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=otCLkHwJAbtHTST9o) @jtsiros right now there are no API calls to configure logging. @gudkov do we have a ticket in Jira about indy-crypto logging?

ianco (Wed, 31 Jan 2018 14:27:44 GMT):
@sergey.minaev thanks!

jtsiros (Wed, 31 Jan 2018 16:57:03 GMT):
@sergey.minaev since its binary, how would I go about base58 encoding it? The encoder expects a number I believe

jtsiros (Wed, 31 Jan 2018 16:57:03 GMT):
@sergey.minaev since its binary, how would I go about base58 encoding it? I just want to make sure I properly represent the key outside the crypto lib

jtsiros (Wed, 31 Jan 2018 17:15:02 GMT):
@sergey.minaev the byte size for the ver key is 128. I looked at the SDK and it looks like it chops the first 16 bytes of both keys and base58 encodes it

jtsiros (Wed, 31 Jan 2018 17:15:02 GMT):
@sergey.minaev the byte size for the ver key is 128. I looked at the SDK and it looks like it chops the first 16 bytes of both keys and base58 encodes it ``` indy_crypto_bls_sign_key_as_bytes: >>> ver_key: 0x55029b0, bytes_p: 0xc42000e040, bytes_len_p: 0xc420018420 indy_crypto_bls_ver_key_as_bytes: ver_key: VerKey { point: PointG2 { point: ECP2: [ false, FP2: [ FP: [ BIG: [ 1C655C79297C9CDB20C243FA247DD50C7596ADADD65E92DD4AF484F3E8DE1854 ] ], FP: [ BIG: [ 062223F6CD8D5E9F2EF7231E2757C41F2C3C4902A545EDAFBE511777F9BF67DE ] ] ], FP2: [ FP: [ BIG: [ 21188DD1E1E404C618A39589085A2714CA28DCE25FDE147CCD37FC4BF4BFC5C5 ] ], FP: [ BIG: [ 247053F9066D85CEA7F1A09084D1DD2186423AB8DFBD520B50BC17D3AEE3049A ] ] ], FP2: [ FP: [ BIG: [ 095E45DDF417D05FB10933FFC63D474548B7FFFF7888802F07FFFFFF7D07A8A8 ] ], FP: [ BIG: [ 0000000000000000000000000000000000000000000000000000000000000000 ] ] ] ] }, bytes: [28, 27, 234, 223, 240, 223, 232, 240, 209, 67, 91, 70, 43, 187, 233, 142, 1, 194, 177, 45, 25, 177, 69, 36, 19, 172, 159, 136, 103, 235, 248, 105, 22, 19, 227, 30, 241, 64, 165, 208, 33, 144, 86, 17, 95, 43, 66, 191, 238, 68, 211, 47, 60, 145, 137, 232, 8, 104, 128, 55, 131, 73, 110, 197, 31, 220, 43, 93, 171, 224, 79, 216, 107, 74, 162, 153, 115, 243, 212, 191, 5, 91, 199, 163, 153, 109, 219, 66, 224, 196, 161, 181, 228, 65, 201, 47, 3, 194, 95, 46, 240, 155, 30, 103, 154, 44, 22, 78, 3, 192, 28, 90, 159, 81, 6, 10, 156, 40, 254, 64, 230, 164, 28, 133, 136, 174, 195, 106] } indy_crypto_bls_ver_key_as_bytes: <<< res: Success key (0x5502930) with size: (128) ```

Harmannz (Wed, 31 Jan 2018 21:32:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=zhLWPHvQfTM8nafWw) @ashcherbakov Thanks for the reply. Do you know what encoding scheme the tests use? I am currently using `Integer.parseInt()` with a radix of 36 to convert string to integer

sergey.minaev (Thu, 01 Feb 2018 09:06:52 GMT):
@jtsiros I'm sorry, I can't understand your first question (and don't know your usecase): > since its binary, how would I go about base58 encoding it? You have raw binary data output from the library. If you want, you can encode it as you want for your application. Is there a problem? In our IndySDK and IndyNode logic we use base58 encoding in network communication and to store Nodes BLS keys in the ledger. > the byte size for the ver key is 128. I looked at the SDK and it looks like it chops the first 16 bytes of both keys and base58 encodes it I don't remember place in IndySDK with chopped BLS key. Could you please provide reference to source file/line?

Artemkaaas (Thu, 01 Feb 2018 11:03:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kXqFpw25Kyytv8xWf) @Harmannz @harmannz In Libindy tests, we used just random numbers for attributes encoded values. You can use any encoding scheme here.

pimotte (Thu, 01 Feb 2018 14:26:33 GMT):
Has joined the channel.

akhihaki (Thu, 01 Feb 2018 15:10:32 GMT):
Hello, after able to setup up test indy network locally, i was exploring indy-sdk and got the following error while trying to test the python samples (indy-sdk/samples/python/). `ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid structure: Invalid claim_offer_json: missing field `schema_seq_no` at line 1 column 122 WARNING:indy.libindy:_indy_loop_callback: Function returned error 113 Traceback (most recent call last): File "main.py", line 15, in loop.run_until_complete(main()) File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step result = coro.throw(exc) File "main.py", line 8, in main await anoncreds.demo() File "/root/indy-sdk/samples/python/src/anoncreds.py", line 60, in demo claim_def_json, master_secret_name) File "/root/indy-node/env/lib/python3.5/site-packages/indy/anoncreds.py", line 377, in prover_create_and_store_claim_req prover_create_and_store_claim_req.cb) File "/usr/lib/python3.5/asyncio/futures.py", line 361, in __iter__ yield self # This tells Task to wait for completion. File "/usr/lib/python3.5/asyncio/tasks.py", line 296, in _wakeup future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception indy.error.IndyError: ErrorCode.CommonInvalidStructure`

akhihaki (Thu, 01 Feb 2018 15:10:32 GMT):
Hello, setting up test indy network locally, i was exploring indy-sdk and got the following error while trying to test the python samples (indy-sdk/samples/python/). `ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid structure: Invalid claim_offer_json: missing field `schema_seq_no` at line 1 column 122 WARNING:indy.libindy:_indy_loop_callback: Function returned error 113 Traceback (most recent call last): File "main.py", line 15, in loop.run_until_complete(main()) File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step result = coro.throw(exc) File "main.py", line 8, in main await anoncreds.demo() File "/root/indy-sdk/samples/python/src/anoncreds.py", line 60, in demo claim_def_json, master_secret_name) File "/root/indy-node/env/lib/python3.5/site-packages/indy/anoncreds.py", line 377, in prover_create_and_store_claim_req prover_create_and_store_claim_req.cb) File "/usr/lib/python3.5/asyncio/futures.py", line 361, in __iter__ yield self # This tells Task to wait for completion. File "/usr/lib/python3.5/asyncio/tasks.py", line 296, in _wakeup future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception indy.error.IndyError: ErrorCode.CommonInvalidStructure`

akhihaki (Thu, 01 Feb 2018 15:10:32 GMT):
Hello, setting up test indy network locally, i was exploring indy-sdk and got the following error while trying to test the python samples (indy-sdk/samples/python/). ```ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Invalid structure: Invalid claim_offer_json: missing field `schema_seq_no` at line 1 column 122 WARNING:indy.libindy:_indy_loop_callback: Function returned error 113 Traceback (most recent call last): File "main.py", line 15, in loop.run_until_complete(main()) File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step result = coro.throw(exc) File "main.py", line 8, in main await anoncreds.demo() File "/root/indy-sdk/samples/python/src/anoncreds.py", line 60, in demo claim_def_json, master_secret_name) File "/root/indy-node/env/lib/python3.5/site-packages/indy/anoncreds.py", line 377, in prover_create_and_store_claim_req prover_create_and_store_claim_req.cb) File "/usr/lib/python3.5/asyncio/futures.py", line 361, in __iter__ yield self # This tells Task to wait for completion. File "/usr/lib/python3.5/asyncio/tasks.py", line 296, in _wakeup future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception indy.error.IndyError: ErrorCode.CommonInvalidStructure```

akhihaki (Thu, 01 Feb 2018 15:11:56 GMT):
Can someone help me giving pointers on why i am getting this error. Thanks

EtienneNijboer (Thu, 01 Feb 2018 15:51:33 GMT):
@akhihaki I had the same error and asked about it on the sovrin forum. https://sovrin.discoursehosting.net/t/indy-sdk-error-running-python-sample-invalid-claim-offer-json-missing-field-schema-seq-no/488/9

akhihaki (Thu, 01 Feb 2018 16:19:23 GMT):
thanks @EtienneNijboer , changing the libindy version from 1.3.0 to 1.3.0~353 worked.

akhihaki (Thu, 01 Feb 2018 16:19:46 GMT):
now all the samples worked without any errors.

jtsiros (Thu, 01 Feb 2018 17:20:03 GMT):
@sergey.minaev https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/services/crypto/mod.rs#L95

nbrempel (Thu, 01 Feb 2018 21:20:28 GMT):
Hi all, does anyone know a method for retrieving a schema from the ledger using only the data in a claim?

nbrempel (Thu, 01 Feb 2018 21:20:41 GMT):
Take for example this claim: ```json { "claim": { "address_line_1": [ "123-350 Columbia St W", "27992537270558133619621536513783580562129615646174357531642788560472298018751279830537791567173793079" ], "address_line_2": [ "", "4294967296" ], "addressee": [ "Nicholas Rempel", "361619475045777691519861540700272643814566900632191535884151877381994083" ], "city": [ "Waterloo", "70735759253203312844865138317542700646" ], "corp_num": [ "686cfc75-823a-4d74-976f-b9a2118fae7a", "49477402469828500666577516625013065345265123134735389624165084193230282897767706879955032120284381179256157592839106970928761198021538279914228512241085688099806415032890929" ], "country": [ "CA", "5170738225" ], "effective_date": [ "1517517148", "1517517148" ], "end_date": [ "", "4294967296" ], "legal_entity_id": [ "686cfc75-823a-4d74-976f-b9a2118fae7a", "49477402469828500666577516625013065345265123134735389624165084193230282897767706879955032120284381179256157592839106970928761198021538279914228512241085688099806415032890929" ], "legal_name": [ "Nick's Business", "361619475045777695541097071857855707855332876556020848090949685412575027" ], "org_type": [ "CO", "5170738278" ], "postal_code": [ "N2L 6P3", "1062703188233012330691500488799027" ], "province": [ "ON", "5174080613" ] }, "issuer_did": "7VkdE3erBDJnrQMVbEnRzg", "schema_seq_no": 20, "signature": { "non_revocation_claim": null, "primary_claim": { "a": "103829892994533078986182854889584958474748343530035757913484513524386905603014125678474718394009740375657308365951391856699802910420117746886484186217605529759814543419287320999101613952620187880371624092133299779224335729880272812690653179364590880177536474842848089144664603342374819320541370119663711364575358315034347509666688215548493278864662787399435298700865388279508338012620313739290721628479116052097519954499310969997601316366714817601481151569993963583601754713021744136289736435235909238531684714355784668391085544753106347099811772113070348824456005183896214100691599123228157677073952479211934232234007", "e": "259344723055062059907025491480697571938277889515152306249728583105665800713306759149981690559193987143012367913206299323899696942213235956742929708886466960771577048122572722934367", "m2": "75498701164074391002902202086195633336797923804376359521949563482927194049326", "v": "10120974166062309790553464824056500763165694895206708537453424357293716522815592902433796816387030974946672344045246455072358982505837796804561542108013892060019589929689729488600033394286061461127663792666186683010928418279065775040814422322630088925506392597178620695931997341339120248007147794626122953546885593082675529804640462011952761148714404208435254576571590078824365962066644263319817213732383263109787760258075100429962035830185361863510939515843325925764121402164219474589465076714420383007809727215993875632941115963029930576591303258780719329410893235492720197121973851842250987653118850330884538100774364784754112635426245390423303077048590500076531497411960199445903833591293860011015943263897320861725315485105916720853326693217852613587826914910352659790766441559946948088729465317815409220980776239567" } } } ```

nbrempel (Thu, 01 Feb 2018 21:21:21 GMT):
All I have is `schema_seq_no `. Is it possible to retrieve the related schema to this claim using the data presented?

Dimple-Kanwar (Fri, 02 Feb 2018 07:12:27 GMT):
Has joined the channel.

Dimple-Kanwar (Fri, 02 Feb 2018 07:13:23 GMT):
Hi everyone.

Dimple-Kanwar (Fri, 02 Feb 2018 07:15:42 GMT):
I am trying out indy-sdk python wrapper.I have done the setup locally.But i am not getting how to connect to the nodes through sdk?I can just see open pool function but not connection logic.

Dimple-Kanwar (Fri, 02 Feb 2018 07:16:22 GMT):
anyone knows how to do that?

ashcherbakov (Fri, 02 Feb 2018 08:13:33 GMT):
@nbrempel You can use `GET_TXN` request (get a txn for the given seqNo) with `schema_seq_no` passed

EtienneNijboer (Fri, 02 Feb 2018 08:30:03 GMT):
@akhihaki Well, the python samples work. The java and .net samples don't.

akhihaki (Fri, 02 Feb 2018 09:09:48 GMT):
As of now i have only tested with python wrappers. and they seem working by updating libindy version

akhihaki (Fri, 02 Feb 2018 10:44:11 GMT):
is there any doc describing how to create custom genesis pool and genesis transactions ?

ashcherbakov (Fri, 02 Feb 2018 11:25:35 GMT):
@akhihaki Please have a look at https://github.com/hyperledger/indy-node/blob/master/docs/start-nodes.md, and https://github.com/hyperledger/indy-node/blob/master/docs/start-nodes.md#generating-keys-and-test-genesis-transaction-files-for-a-test-network

pimotte (Fri, 02 Feb 2018 11:37:25 GMT):
When running the tests of the java wrapper, `org.hyperledger.indy.sdk.demo.AnoncredsDemoTest.testAnoncredsDemo fails` with `InvalidStructureException: A value being processed is not valid.` The log says: ```Casting error to ErrorCode: Invalid structure: Requested attributes {"attr3_referent", "attr2_referent", "attr1_referent"} do not correspond to received {"attr1_referent", "attr2_referent"}``` attr3_referent is a self-attested attribute. Did something change around this recently?

sergey.minaev (Fri, 02 Feb 2018 11:42:03 GMT):
@Artemkaaas ^^^

Artemkaaas (Fri, 02 Feb 2018 11:59:23 GMT):
@pimotte We fixed the bug in Libindy related to self_attested_attributes. These attributes must present in the proof request. But because we have some problems with Jenkins there is not available Libindy Ubuntu Debian package in Apt repo. As a workaround, you can copy libindy/target/debug/libindy.so file to libindy/wrappers/java/lib/ or /usr/lib/ folder and everything must work well

pimotte (Fri, 02 Feb 2018 12:11:59 GMT):
@Artemkaaas Awesome, that did the trick, thanks:)

pimotte (Fri, 02 Feb 2018 12:25:19 GMT):
I'm also trying to update the java samples to 1.3.0. Is the Signus.java sample still relevant? If yes, what does it actually try to illustrate?

sklump (Fri, 02 Feb 2018 12:46:50 GMT):
At least in python world, did is a drop-in replacement for signus.

pimotte (Fri, 02 Feb 2018 12:49:50 GMT):
I see, thanks:)

akhihaki (Fri, 02 Feb 2018 13:04:57 GMT):
@ashcherbakov i have looked in the link you shared but couldnt find information on how to create 'custom' genesis transactions i.e, having own seeds for trustees and stewards instead of default seeds. For "init_indy_node", i understand we can create keys, but is there any way that we can create "pool_transactions_genesis" and "domain_transactions_genesis" files with custom seeds.

ashcherbakov (Fri, 02 Feb 2018 13:08:11 GMT):
@akhihaki There are two options; 1) just generate the file manually (you can modify a test file by replacing it with you own data, that is the keys generated by your seeds, etc.) 2) modify `generate_indy_pool_transactions` to do the job for you. As of now, this script generates pre-defined test Stewards, Trustees and genesis file. One can modify it to support custom seeds. 3) Write a new script for doing what you need. Feel free to contribute, it will be very appreciated :)

akhihaki (Fri, 02 Feb 2018 13:09:15 GMT):
Got it. thanks. Sure will do.

akhihaki (Fri, 02 Feb 2018 13:09:15 GMT):
@ashcherbakov Got it. thanks. Sure will do.

jljordan_bcgov (Fri, 02 Feb 2018 18:11:12 GMT):
Hi All. We are happy to announce we have selected a dev for the BC Government Code With Us opportunity we offered. @ianco will be working with us to complete the work over the next few months. See https://github.com/bcgov/TheOrgBook/issues/164 for more as well as this is related to https://jira.hyperledger.org/browse/IS-486. Please welcome Ian to the community :)

turmewr3ck (Sun, 04 Feb 2018 14:47:54 GMT):
I'm playing with the Indy SDK Java wrapper, and try to understand and get the open-pool-ledger call working in a minimal example (more or less copy/paste from the Java wrapper test suite). It seems to work (no exceptions raised) when running the Java program on the same machine (Ubuntu with libindy.so) as the ledger (on a 10.0.0/24 network in docker), but running the same Java program on a remote machine (Windows with indy.dll) raises an exception and the Rust trace log prints "Err(CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree."))". I think I've been careful using the same v1.3.0 of the Indy SDK on Ubuntu and Windows, but I was wondering if the IP addresses setup in the genesis transaction has a significance here, or if I should look for elsewhere for trouble. Any hints on how to debug this and find the root cause?

hidde-jan (Mon, 05 Feb 2018 10:00:43 GMT):
Has joined the channel.

hidde-jan (Mon, 05 Feb 2018 10:03:41 GMT):
Hi all, from the wrapper examples on Github I see a lot of pre-computed claims: https://github.com/hyperledger/indy-sdk/blob/master/samples/python/src/getting_started.py#L221

hidde-jan (Mon, 05 Feb 2018 10:04:18 GMT):
A lot of the sdk functions also expect attributes as well as attribute_as_int(s) to be passed in

hidde-jan (Mon, 05 Feb 2018 10:04:39 GMT):
is there any docs on how to actually compute these values?

sergey.minaev (Mon, 05 Feb 2018 10:16:30 GMT):
@turmewr3ck IP address in genesis (and other nodes transactions) is significant. File with genesis transactions not just a configuration with list of nodes with IP and ports. It's also a way to verify ledger consistency. Examples: 1) So if you have local environment (dev pool of nodes in docker container with virtual network 10.0.0/24) and run SDK based program on docker host machine and use docker IP address in genesis file for SDK - everything will work. 2) If you will use same dev pool, but try to change addressing - connection will fail with error mentioned above. Even if you try to connect from same host machine, but for example to forwarded port on different local IP. 3) You can try to use a trick to connect dev pool in docker from another machine in your local (home, office) network: * build `indy-pool.dockerfile` with params `--network host` and `--build-arg pool_ip=` * use host IP in genesis file

sergey.minaev (Mon, 05 Feb 2018 10:21:09 GMT):
One more trick to check yourself in case of error `Err(CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree."))` - compare: 1) genesis file used for SDK 2) /var/lib/indy/sandbox/pool_transactions_genesis file in the docker container with pool of nodes

sergey.minaev (Mon, 05 Feb 2018 10:28:48 GMT):
Hi @hidde-jan Actually only integer representation of attribute value is checked by claims math. And it's application specific logic how to transfer user-friendly value to hex. Of course both prover and verifier should use the same approach.

hidde-jan (Mon, 05 Feb 2018 10:31:57 GMT):
So if I understand correctly, there's no fixed way of mapping a string to that integer in Indy currently?

sergey.minaev (Mon, 05 Feb 2018 10:32:11 GMT):
yes

hidde-jan (Mon, 05 Feb 2018 10:33:16 GMT):
And the integer is checked with the anoncreds crypto right

sergey.minaev (Mon, 05 Feb 2018 10:33:17 GMT):
and there is moment to be careful: if you want to use GE predicate for string value, the mapping should keep the oreder

sergey.minaev (Mon, 05 Feb 2018 10:33:17 GMT):
and there is moment to be careful: if you want to use GE predicate for string value, the mapping should keep the order

hidde-jan (Mon, 05 Feb 2018 10:33:52 GMT):
so as a verifier, how do I know that the string 'Alice' corresponds to X and not to Y?

hidde-jan (Mon, 05 Feb 2018 10:34:36 GMT):
For example, https://github.com/hyperledger/indy-sdk/blob/master/samples/python/src/getting_started.py#L222 and https://github.com/hyperledger/indy-sdk/blob/master/samples/python/src/getting_started.py#L434

hidde-jan (Mon, 05 Feb 2018 10:34:44 GMT):
Alice has different integers in that case

sergey.minaev (Mon, 05 Feb 2018 10:35:16 GMT):
there is assumption about prover and verifier "know" and use common mapping

sergey.minaev (Mon, 05 Feb 2018 10:38:15 GMT):
In samples random representation is used and step for verifier is missed (check mapping)

hidde-jan (Mon, 05 Feb 2018 10:39:00 GMT):
ok, so in the real world you might use utf-8 encoding to go to binary and use that as an integer?

hidde-jan (Mon, 05 Feb 2018 10:41:22 GMT):
I think the samples are rather confusing in that regard, together with sparse documentation on the creation of new claims

sergey.minaev (Mon, 05 Feb 2018 10:42:37 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=7qX8kLY3MBtb96jgA) I'm not sure about ordering in this mapping. Longest string will always greater.

hidde-jan (Mon, 05 Feb 2018 10:44:06 GMT):
ok, but there isn't any default / recommended mapping?

sergey.minaev (Mon, 05 Feb 2018 10:45:57 GMT):
Yes, now we haven't any default or recommended mapping.

sergey.minaev (Mon, 05 Feb 2018 10:47:02 GMT):
@ashcherbakov @gudkov do we plan to define something like recommended mapping for typical types (strings for example, or may be json)

sergey.minaev (Mon, 05 Feb 2018 10:51:15 GMT):
@hidde-jan One of the main reasons for mapping definition on SDK level (not application) is unreasonable assumption about actual data types. The sample with string encoding and ordering illustrate one of potential issue for generalized approach.

sergey.minaev (Mon, 05 Feb 2018 10:51:15 GMT):
@hidde-jan One of the main reasons for mapping definition on SDK level (not application) is unreasonable assumptions about actual data types. The sample with string encoding and ordering illustrate one of potential issue for generalized approach.

hidde-jan (Mon, 05 Feb 2018 10:54:28 GMT):
I understand, but for widespread adaptation of this technology, this kind of thing should have usable, clear, secure and well-documented defaults. There's currently also no means to specify what encoding is used, which means I need to know all issuers that I am going to accept claims from.

turmewr3ck (Mon, 05 Feb 2018 10:55:34 GMT):
@sergey.minaev that is useful info, thanks. A side question though: If a validator node needs to change IP address, how is this accomplished then, given the tight relation with the genesis transaction and IP addresses?

sergey.minaev (Mon, 05 Feb 2018 10:56:17 GMT):
Appropriate Steward should sent Node transaction and update IP

sergey.minaev (Mon, 05 Feb 2018 10:56:40 GMT):
this transaction will be received by SDK while catch-up

sergey.minaev (Mon, 05 Feb 2018 11:28:08 GMT):
@turmewr3ck in more details 1) steward send Node transaction with new IP and restart node on new address 2) New client based on SDK will try to connect to nodes, mentioned in genesis file, if enough nodes available, client catch-up all new node transactions and calculate new "state" of Nodes with actual IP:port and may be new nodes 3) client connect to updated list of nodes 4) not implemented yet: client will store received while catch-up new transactions and will connect to last known list of nodes

hidde-jan (Mon, 05 Feb 2018 11:32:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=yFHmNf32LH3mFbBZK) @sergey.minaev So the nodes in the genesis pool transactions are in it for a long time :)

sergey.minaev (Mon, 05 Feb 2018 11:36:09 GMT):
@turmewr3ck Also note: list of transactions (nodes and other types) may be only appended, not changed. Genesis transactions is basis to retrieve all future transactions. And may be republished in case of initial set of transactions is not enough to receive and verify latest state.

turmewr3ck (Mon, 05 Feb 2018 11:52:23 GMT):
Does then mean that: * A client should attempt to keep up to date on what is the latest "genesis". * A developer writing a new client for a ledger that as been running for a long time, should use a "genesis" which is reasonable recent/updated?

turmewr3ck (Mon, 05 Feb 2018 11:52:23 GMT):
Does this mean that: * A client should attempt to keep up to date on what is the latest "genesis"? * A developer writing a new client for a ledger that as been running for a long time, should use a "genesis" which is reasonable recent/updated?

sergey.minaev (Mon, 05 Feb 2018 11:58:33 GMT):
Right now yes. But after 4) will be implemented the first point will be actual only for new clients. Also critical update for genesis transactions is something unusual and rare.

turmewr3ck (Mon, 05 Feb 2018 12:42:21 GMT):
(I wonder how this should work in an IPv6 network where addresses change all the time) :-)

akhihaki (Mon, 05 Feb 2018 14:00:35 GMT):
Trying to understand the `getting-started.py` from python wrapper samples in Indy-SDK, i have question. In the `onboarding` function, the steward each time creates a new did and keys which are being used in while onboarding new trust anchors. My question is why cant the steward use existing did and key to onboard new trust anchors.

akhihaki (Mon, 05 Feb 2018 14:00:35 GMT):
Hello, i am trying to understand the `getting-started.py` from python wrapper samples in Indy-SDK, i have question. In the `onboarding` function, the steward each time creates a new did and keys which are being used in while onboarding new trust anchors. My question is why cant the steward use existing did and key to onboard new trust anchors. Thanks

akhihaki (Mon, 05 Feb 2018 14:52:45 GMT):
Please direct me to any docs explaining how Indy uses pairwise connections for secure communication ?

akhihaki (Mon, 05 Feb 2018 14:52:45 GMT):
Please direct me to any docs explaining how Indy uses pairwise connections for enabling secure communication ?

gudkov (Mon, 05 Feb 2018 15:51:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nZWFh279jGHp5XbW5) @akhihaki Look to https://github.com/Artemkaaas/indy-sdk/blob/d69b4fcebd4513578c9d4818036e303f3862bc66/doc/getting-started/getting-started.md It will be merged soon

gudkov (Mon, 05 Feb 2018 15:54:21 GMT):
In this tutorial we use 2 type of DIDs. The first one is Verinym. Verinym is associated with the Legal Identity of the Identity Owner. For example, all parties should be able to verify that some DID is used by Government to publish schemas for some document type. The second type is Pseudonym - a Blinded Identifier used to maintain privacy in the context on an ongoing digital relationship (Connection). if Pseudonym is used to maintain only one digital relationship we will call it Pairwise-Unique Identifier. We will use Pairwise-Unique Identifiers to maintain secure connections between actors in this tutorial.

gudkov (Mon, 05 Feb 2018 15:56:46 GMT):
Steward creates new pairwise DID for each connection to establish secure channel. For posting verinyms for new trust anchors it uses the same DID for all cases.

akhihaki (Mon, 05 Feb 2018 19:08:40 GMT):
Thanks @gudkov, will look into it.

Harmannz (Mon, 05 Feb 2018 20:49:29 GMT):
Hi all, a lot of the times I have read that claims, claim offer, pairwise did metadata etc are stored in a *secure* wallet. Can someone explain what a *secure* wallet means because at the moment, I can simple open the sqlite.db file and view all contents of the wallet. Is there any planned work to make the wallet secure?

Harmannz (Mon, 05 Feb 2018 20:49:29 GMT):
Hi all, a lot of the times I have read that claims, claim offer, pairwise did metadata etc are stored in a *secure* wallet. Can someone explain what a *secure* wallet means because at the moment, I can simply open the sqlite.db file and view all contents of the wallet for debugging. Is there any planned work to make the wallet secure?

gudkov (Tue, 06 Feb 2018 07:34:40 GMT):
@Harmannz You can use "key" field in credentials param to encrypt the default wallet. Also it supports "rekey" param for key rotation There are some lacks in documentation and we have a jira ticket related to documentation update.

gudkov (Tue, 06 Feb 2018 07:37:05 GMT):
Also wallet in libindy is just interface that can be plugged to provide more complex wallet. For example, iOS wrapper provides HSM based wallet.

khoingo (Tue, 06 Feb 2018 09:24:36 GMT):
Has joined the channel.

akhihaki (Tue, 06 Feb 2018 09:47:51 GMT):
Hello, in the `getting-started.md` shared by @gudkov above (https://github.com/Artemkaaas/indy-sdk/blob/d69b4fcebd4513578c9d4818036e303f3862bc66/doc/getting-started/getting-started.md), within `onboarding` when faber is sending anon_encrypted connection response to steward it is using `steward_faber_verkey`, which means when steward tries to decrypt it should use the same key. How would steward know it should use `steward_faber_verkey` for decryption ? Also is there any problem in using steward verinym's verkey for encryption as the request is tracked using nonce before pairwise connection is established. Thanks

akhihaki (Tue, 06 Feb 2018 09:47:51 GMT):
Hello, in the `getting-started.md` shared by @gudkov above (https://github.com/Artemkaaas/indy-sdk/blob/d69b4fcebd4513578c9d4818036e303f3862bc66/doc/getting-started/getting-started.md), within `onboarding` when faber is sending anon_encrypted connection response to steward it is using `steward_faber_verkey`, which means when steward tries to decrypt, it should use the corresponding signing key only. How would steward know it should use `steward_faber_verkey` for decryption ? Also is there any problem in using steward verinym's verkey for encryption as the request is tracked using nonce before pairwise connection is established. Thanks

akhihaki (Tue, 06 Feb 2018 09:47:51 GMT):
Hello, in the `getting-started.md` shared by @gudkov above (https://github.com/Artemkaaas/indy-sdk/blob/d69b4fcebd4513578c9d4818036e303f3862bc66/doc/getting-started/getting-started.md), within `onboarding` when faber is sending anon_encrypted connection response to steward it is using `steward_faber_verkey`, which means when steward tries to decrypt, it should use the corresponding signing key only. How would steward know it should use `steward_faber_verkey`'s signing key for decryption ? Also is there any problem in using steward verinym's verkey for encryption as the request is tracked using nonce before pairwise connection is established. Thanks

alkopnin (Tue, 06 Feb 2018 15:52:47 GMT):
Has joined the channel.

alkopnin (Tue, 06 Feb 2018 15:53:43 GMT):
Hi folks, I'm trying to create non revocation claim and have got the issue: "org.hyperledger.indy.sdk.wallet.WalletValueNotFoundException: No value with the specified key exists in the wallet from which it was requested."

alkopnin (Tue, 06 Feb 2018 15:54:47 GMT):
I'm not sure that know what exact value is missed.

alkopnin (Tue, 06 Feb 2018 15:55:23 GMT):
I use v1.3.0, Java

nhan.trong.nguyen (Wed, 07 Feb 2018 02:57:35 GMT):
HI all, when I submit request to ledger, a response is returned with a filed 'txnTime' as below: {"op":"REPLY","result":{"reqId":1517971972937280433,"identifier":"Th7MpTaRZVRYnPiabds81Y","txnTime":1517967665,"type":"104","data":"{\"endpoint\":{\"ha\":\"127.0.0.1:5555\"}}","seqNo":5577,"dest":"5bWpfkVcL1TZDUP5JPt3gX","raw":"endpoint"}}

nhan.trong.nguyen (Wed, 07 Feb 2018 02:58:10 GMT):
I wonder what is 'txnTime' mean?

Artemkaaas (Wed, 07 Feb 2018 07:13:31 GMT):
@alkopnin Libindy 1.3.0 does not support Revocation correctly. You can fix your problem by work with one common wallet for Issuer and Prover. We fixed it later. The latest Libindy master does not have this bug.

alkopnin (Wed, 07 Feb 2018 07:45:45 GMT):
Hi @Artemkaaas Thank you for answer. Actually, im using flow without revocation (nonRevoc arg is true). val claimTemplate = Anoncreds.issuerCreateAndStoreClaimDef(wallet, did, schema, SIGNATURE_TYPE, true).get()

alkopnin (Wed, 07 Feb 2018 07:49:01 GMT):
Is it possible to run multiple wallets model?

Artemkaaas (Wed, 07 Feb 2018 08:11:38 GMT):
Revocation with multiple wallets model will not work for Libindy 1.3.0 but it will work for Libindy master 1.3.0~363

gudkov (Wed, 07 Feb 2018 10:02:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=r6goiSXkSWhXkia7A) @akhihaki > when faber is sending anon_encrypted connection response to steward it is using `steward_faber_verkey`, which means when steward tries to decrypt, it should use the corresponding signing key only. How would steward know it should use `steward_faber_verkey`'s signing key for decryption ? Faber send's the message to endpoint associated with steward_faber_did only. Endpoint can be stored on the ledger as part of DDO object or as ATTRIB transaction. Indy and libindy don't force the way how to organize messages routing. For example, if steward_faber_did is managed by cloud agency endpoint can be ip address of the cloud, transport key for anonymous encryption and some internal identifier in the cloud. On the transport level routing will be hidden. > Also is there any problem in using steward verinym's verkey for encryption as the request is tracked using nonce before pairwise connection is established. Sure if you need to send just only one message you can send anonymous message to verinym authenticated by nonce, but most probable you real use case can require to continue communication. In this case pairwise channel will be required.

gudkov (Wed, 07 Feb 2018 10:02:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=r6goiSXkSWhXkia7A) @akhihaki > when faber is sending anon_encrypted connection response to steward it is using `steward_faber_verkey`, which means when steward tries to decrypt, it should use the corresponding signing key only. How would steward know it should use `steward_faber_verkey`'s signing key for decryption ? Faber send's the message to endpoint associated with steward_faber_did only. Endpoint can be stored on the ledger as part of DDO object or as ATTRIB transaction. Indy and libindy don't force the way how to organize messages routing. For example, if steward_faber_did is managed by cloud agency endpoint can be ip address of the cloud, transport key for anonymous encryption and some internal identifier in the cloud. On the transport level routing will be hidden. > Also is there any problem in using steward verinym's verkey for encryption as the request is tracked using nonce before pairwise connection is established. Sure if you need to send just only one message you can send anonymous message to verinym authenticated by nonce, but most probable real use cases will require to continue communication. In this case pairwise channel will be required.

gudkov (Wed, 07 Feb 2018 10:02:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=r6goiSXkSWhXkia7A) @akhihaki > when faber is sending anon_encrypted connection response to steward it is using `steward_faber_verkey`, which means when steward tries to decrypt, it should use the corresponding signing key only. How would steward know it should use `steward_faber_verkey`'s signing key for decryption ? Faber send's the message to endpoint associated with steward_faber_did only. Endpoint can be stored on the ledger as part of DDO object or as ATTRIB transaction. Indy and libindy don't force the way how to organize messages routing. For example, if steward_faber_did is managed by cloud agency endpoint can be ip address of the cloud, transport key for anonymous encryption and some internal identifier in the cloud. On the transport level routing will be hidden. > Also is there any problem in using steward verinym's verkey for encryption as the request is tracked using nonce before pairwise connection is established. Sure if you need to send just only one message you can send anonymous message to verinym authenticated by nonce, but most probable real use cases will require to continue communication. In this case pairwise channel will be required. Pairwise channel is more common approach to exchange messages between agents so we use this approach in the tutorial.

nghia47 (Wed, 07 Feb 2018 10:14:24 GMT):
Hi all, I am working with the schema by using the python wrapper. As my scenarios, I need to use a role of "STEWARD" to create a "TRUST ANCHOR". Is there any default "STEWARD" seed or I have to create a new one with the default "TRUSTEE"? Thanks.

akhihaki (Wed, 07 Feb 2018 10:17:35 GMT):
@gudkov thanks. your answer clarifies.

akhihaki (Wed, 07 Feb 2018 10:23:06 GMT):
@nghia47 if you are using `generate_indy_pool_transactions` from https://github.com/hyperledger/indy-node/tree/master/scripts, the seed for steward1 is 000000000000000000000000Steward1 and so on, for trustee it is 000000000000000000000000Trustee1. Based on your scenarios you can use either of these to add new trust anchor.

alkopnin (Wed, 07 Feb 2018 10:37:18 GMT):
@Artemkaaas thanks. Well, but I don't use revocation. "createNonRevoc Whether or not to create a non-revokable claim definition." I set createNonRevoc to true.

nghia47 (Wed, 07 Feb 2018 11:00:39 GMT):
@akhihaki thank you for your answer.

alkopnin (Wed, 07 Feb 2018 13:36:35 GMT):
if I do val claimTemplate = Anoncreds.issuerCreateAndStoreClaimDef(wallet, did, schema, SIGNATURE_TYPE, false).get() where createNonRevoc=false, - I face another issue. Well, there are 2 questions 1) Could you, please, explain createNonRevoc - I assume that if true that non revocation claim will be issued, otherwise revocation one. Debugger looks different 2) If createNonRevoc=true - claimDef loaded from public ledger returns: "Invalid structure: Invalid claim_def_json: missing field `g` at line 1 column 82" from Anoncreds.issuerCreateClaim(wallet, claimReq, claim, -1).get() for case 2 the claim can be created only if I directly use value from: val claimTemplate = Anoncreds.issuerCreateAndStoreClaimDef(wallet, did, schema, SIGNATURE_TYPE, false).get() But it's strange because I have to send claimTemplate directly to other party instead of getting ClaimDef from the public ledger by: Ledger.buildGetClaimDefTxn(schemaDetails.issuer, schemaId, SIGNATURE_TYPE, schemaDetails.issuer).get()

alkopnin (Wed, 07 Feb 2018 13:36:35 GMT):
if I do val claimTemplate = Anoncreds.issuerCreateAndStoreClaimDef(wallet, did, schema, SIGNATURE_TYPE, false).get() where createNonRevoc=false, - I face another issue. Well, there are 2 questions 1) Could you, please, explain createNonRevoc - I assume that if true that non revocation claim will be issued, otherwise revocation one. Debugger shows different 2) If createNonRevoc=true - claimDef loaded from public ledger returns: "Invalid structure: Invalid claim_def_json: missing field `g` at line 1 column 82" from Anoncreds.issuerCreateClaim(wallet, claimReq, claim, -1).get() for case 2 the claim can be created only if I directly use value from: val claimTemplate = Anoncreds.issuerCreateAndStoreClaimDef(wallet, did, schema, SIGNATURE_TYPE, false).get() But it's strange because I have to send claimTemplate directly to other party instead of getting ClaimDef from the public ledger by: Ledger.buildGetClaimDefTxn(schemaDetails.issuer, schemaId, SIGNATURE_TYPE, schemaDetails.issuer).get()

alkopnin (Wed, 07 Feb 2018 13:36:35 GMT):
if I do val claimTemplate = Anoncreds.issuerCreateAndStoreClaimDef(wallet, did, schema, SIGNATURE_TYPE, false).get() where createNonRevoc=false, - I face another issue. Well, there are 2 questions 1) Could you, please, explain createNonRevoc - I assume if true - non revocation claim will be issued, otherwise revocation one. Debugger shows different 2) If createNonRevoc=true - claimDef loaded from public ledger returns: "Invalid structure: Invalid claim_def_json: missing field `g` at line 1 column 82" from Anoncreds.issuerCreateClaim(wallet, claimReq, claim, -1).get() for case 2 the claim can be created only if I directly use value from: val claimTemplate = Anoncreds.issuerCreateAndStoreClaimDef(wallet, did, schema, SIGNATURE_TYPE, false).get() But it's strange because I have to send claimTemplate directly to other party instead of getting ClaimDef from the public ledger by: Ledger.buildGetClaimDefTxn(schemaDetails.issuer, schemaId, SIGNATURE_TYPE, schemaDetails.issuer).get()

gudkov (Wed, 07 Feb 2018 16:02:00 GMT):
> Could you, please, explain createNonRevoc If you set it to true it will be claim with "Non Revocation Proof" support ) So seems you read this in a wrong way

peacekeeper (Thu, 08 Feb 2018 06:48:51 GMT):
Does 1.3.0 support state proofs?

sergey.minaev (Thu, 08 Feb 2018 07:55:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=PhrfvPu93pTjKL7W5) @peacekeeper stable release 1.3.0 contains disabled code for state proof functionality (because it was released before latest pool with state proof support).

peacekeeper (Thu, 08 Feb 2018 08:28:21 GMT):
Thanks, any ETA when that code will be enabled?

sergey.minaev (Thu, 08 Feb 2018 08:31:27 GMT):
@gudkov @ashcherbakov ^^^ Will we release stable of libindy for current stable on live pool?

ashcherbakov (Thu, 08 Feb 2018 08:38:55 GMT):
A big new stable release will not be released very soon, since we're in the middle of some API changes of anoncreds protocol (so, the new release will have non-backward compatible changes; we will provide full instructions of what these changes are and how to adapt applications to them).

ashcherbakov (Thu, 08 Feb 2018 08:39:32 GMT):
What we could do, is to create a small stable release on top of 1.3.0 with just one small change to enable state proofs

sergey.minaev (Thu, 08 Feb 2018 08:39:39 GMT):
So. may be we should release some minimal update for 1/3/0

peacekeeper (Thu, 08 Feb 2018 08:45:49 GMT):
From a DID specification and resolution standpoint, I think it would be valuable to have state proofs, since this is one of the features that makes "sov" DIDs superior to other DID methods such as "btcr", "v1".

peacekeeper (Thu, 08 Feb 2018 08:46:04 GMT):
But not sure how important this is relative to other priorities.

alkopnin (Thu, 08 Feb 2018 10:04:02 GMT):
Hi folks, Do you have some updates regarding my issue? Is it possible to implement it or should I wait for the next update?

Artemkaaas (Thu, 08 Feb 2018 10:25:01 GMT):
@alkopnin This bug was fixed some time ago. Why do you use stable 1.3.0 ? Could you any last master?

alkopnin (Thu, 08 Feb 2018 10:27:12 GMT):
I just thought that tag more stable than master. Do you recommend to use head of master?

alkopnin (Thu, 08 Feb 2018 10:27:48 GMT):
or the special commit

gudkov (Thu, 08 Feb 2018 10:29:24 GMT):
> Do you recommend to use head of master? I suggest to use stable master. It is stable enough for development. In fact it is more stable than stable tag.

gudkov (Thu, 08 Feb 2018 10:29:24 GMT):
> Do you recommend to use head of master? I suggest to use master. It is stable enough for development. In fact it is more stable than stable tag.

gudkov (Thu, 08 Feb 2018 10:31:41 GMT):
The only reason that we have no release is planned breaking changes. We want to avoid breaking changes after next release.

alkopnin (Thu, 08 Feb 2018 10:35:07 GMT):
Okay, cool. Thank you, I will try

Artemkaaas (Thu, 08 Feb 2018 10:39:21 GMT):
@alkopnin I suggest you to use libindy_1.3.0~367. Also, it will be great to update pool. Recently we merged PR: https://github.com/hyperledger/indy-sdk/pull/524/files where we supported the latest version of Indy-Node. Actually, the problem you describe above was on the Indy-Node side

alkopnin (Thu, 08 Feb 2018 10:42:05 GMT):
got it. Thanks a lot!

gudkov (Thu, 08 Feb 2018 10:47:21 GMT):
Just merged new Getting Started Guide for Indy SDK https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md We will appreciate any feedback.

pimotte (Thu, 08 Feb 2018 10:49:56 GMT):
There's a small typo at the beginning of the Getting Verinym section: "created early Faber DID"

pimotte (Thu, 08 Feb 2018 10:51:39 GMT):
That should probably be something like "the Faber DID created earlier"?

gudkov (Thu, 08 Feb 2018 10:53:27 GMT):
Thanks! Typos are possible. QA will validate the text soon. Also we will appreciate any PRs.

pimotte (Thu, 08 Feb 2018 10:56:02 GMT):
I'm also implementing this sample in java, and I'm getting "Invalid structure: Invalid schema json: Invalid structure: JSON error" on "create_and_store_claim_definition", where my json is the following: ``` { "identifier": "Ddk8Fh77usrVC65zvbkZFp", "seqNo": null, "data": { "name": "Transcript", "version": "1.2" }, "txnTime": null, "type": "107", "dest": "5iWVNb56iqMoGwnY62HB1j", "state_proof": { "root_hash": "5oAKzNpdcaT7wxfteRcWRpMa1L26G7tzrcQspodx9KaF", "multi_signature": { "signature": "RLW4A8kqoKGWHNH6ZUeJxM6zJYYTB47xsgg1yqUhE1xJW3fNm7FNqXb8J3eiVUguQwVp4xTiUyfkjapve12T97eAuLZ1nk5FiL69vHYv5vayuhZRQ1PZPaRoUq7fjT6XNo4C1jjhTRJzFg3YAmNXyDhpt7FEodw8Fj8ZRtjShy6zGF", "value": { "state_root_hash": "5oAKzNpdcaT7wxfteRcWRpMa1L26G7tzrcQspodx9KaF", "txn_root_hash": "DqwNdYN94AcYFtZbJCmnqWeSqWLHZMR3HkPn5ZECEnAq", "ledger_id": 1, "pool_state_root_hash": "n6VPkuHJYFPk6Lnzk6wFKE8HQkwiXvPXfWPb1Xw5zp4", "timestamp": 1518087312 }, "participants": ["Node1", "Node3", "Node2"] }, "proof_nodes": "+QJn+FGAgICAgICAgICAgKD7TuChrJbiHkOHhuygFp4PN2gL8IFQu1m+EOvUhGoPYICgBc018/R1mtfIyraN5+WvY9WX1drKn0K6eImjZv4Kuv2AgID5AhGgQW/WnQr1r0sMrXLMCFcuTmWvfyFZ9CKdhDnDb3hWcTOgEAIsTQ+FL3DluX3x7TP1HumDuhdhZWLyso7t/UkR9Q2g2tcjc04QN6eZWLa4eRr6kRIbYje8AYPXFNQSMZNccF+g7qoahBscaHJOtql+ir8SCyj+T9w4ec0r6+FQzt9LWPOgyod1n49CGs2ka1CCDUwA/oef3qsZfq7FzoHYBIapA5agmX2ZjpxpmfHS7Kie2lEu74TnYxIBrps5OcW7XWj+dF2gyV5VDIEwL0DMxFmOtqnWSUEfvyU9lM76j8kQ0L1ZmMCgeWfJs9wcWR/CwnFgYY6z5bzDQ9lCqKruSXJIjFGtXj6gUTmIiv8BIKK4LHDWQjjcsEqsVZIIuoyguiC5KrCrr0yg5i1l9CKJySO/vdhPuCz+Z3ARCeoZNDywY1yg9H1C8xigryqL4Lc5fWY7s/0EgmIbQlUx6cPzsNEl5qJgoIKkFm6gccgHCJlySf8gnqs8wxGcx9Mylf7rYcY6Xd149jyHq76gjl92Wkka83KsOsIBU2sXaeoh4ePH8JnW0TfkO/bnU2CgXbJjlWL+0+h2naMiBJWDhhXISZFgj3wL1SH70JYeNQqg8s+d88jIrad41blyYZZzA3NQ6b48D2hasPS0varbFnyg/yN/R6OWlHq1sfqdO3jSkcw0L5xINHcA/++qOS0pH9uA" }, "reqId": 1518087312996589551 } ```

pimotte (Thu, 08 Feb 2018 10:56:38 GMT):
Do you happen to know what's going wrong there? My guess would be something with the seqNo, but I have no idea what it means, and replacing it with a number didn't help

gudkov (Thu, 08 Feb 2018 11:32:10 GMT):
This json seems like direct response from the ledger. Most probable you should just use data field only.

Artemkaaas (Thu, 08 Feb 2018 12:01:03 GMT):
The error is here: "seqNo": null

Artemkaaas (Thu, 08 Feb 2018 12:01:03 GMT):
The error is here: "seqNo": null and field "attr_names" is missed

Artemkaaas (Thu, 08 Feb 2018 12:02:16 GMT):
Is it response of GET_SCHEMA request?

pimotte (Thu, 08 Feb 2018 12:06:28 GMT):
@Artemkaaas Yeah, it is

pimotte (Thu, 08 Feb 2018 12:07:29 GMT):
But in the python samples the json that is used in the claim_definition is also just the "result" field of the response to GET_SCHEMA, right?

Artemkaaas (Thu, 08 Feb 2018 12:08:48 GMT):
You are use correct field. It looks like Node did not process SCHEMA request yet. Did you send SCHEMA request and right after it GET_SCHEMA request?

Artemkaaas (Thu, 08 Feb 2018 12:08:48 GMT):
You use correct field. It looks like Node did not process SCHEMA request yet. Did you send SCHEMA request and right after it GET_SCHEMA request?

pimotte (Thu, 08 Feb 2018 12:09:02 GMT):
Ah, yeah, I did

Artemkaaas (Thu, 08 Feb 2018 12:10:27 GMT):
Try to do something between SCHEMA and GET_SCHEMA transaction or add a timeout.

pimotte (Thu, 08 Feb 2018 12:12:10 GMT):
So waiting for the SCHEMA request to return is not enough, right? What's the delay here? Synchonization between nodes?

pimotte (Thu, 08 Feb 2018 12:13:23 GMT):
Oooh, nvm, the schema request actually fails

gudkov (Thu, 08 Feb 2018 12:16:46 GMT):
Pool can return a bit outdated data as result. You can always estimate how old it is by timestamp in state proof.

gudkov (Thu, 08 Feb 2018 12:19:51 GMT):
There is no way to synchronize requests. You can repeat GET requests until you get expected result.

pimotte (Thu, 08 Feb 2018 12:20:36 GMT):
Aha, clear:) Meanwhile, I've fixed the SCHEMA request and now it actually works

pimotte (Thu, 08 Feb 2018 12:21:42 GMT):
If I manage to implement the getting started in java on 1.3.0, would you guys like a PR of that?

pimotte (Thu, 08 Feb 2018 13:00:13 GMT):
@gudkov More feedback on the getting-started: At "Alice gets a Transcript", the concept of schema key is introduced, but can't find any mention of it. (Looking at libindy, it looks to be name/verison/did, right?

gudkov (Thu, 08 Feb 2018 13:03:54 GMT):
@pimotte Could you add your comments to https://jira.hyperledger.org/browse/IS-477 Jira ticket? Schema defines the list of attributes that Claim contains. Currently it is identified by name/verison/did tuple.

pimotte (Thu, 08 Feb 2018 13:06:43 GMT):
Sure:)

gudkov (Thu, 08 Feb 2018 13:12:27 GMT):
Also it would be nice if you share your feedback with us. Was this GSG useful and helpful or not and how we can make it better.

pimotte (Thu, 08 Feb 2018 13:13:48 GMT):
I think it's a good start and clearly demonstrates a use case

pimotte (Thu, 08 Feb 2018 13:16:52 GMT):
Sometimes I feel like I'm missing some context with regards to all the entities and how exactly they relate, but my guess is that there is general indy documentation on that somewhere (haven't really looked for it yet)

pimotte (Thu, 08 Feb 2018 13:18:58 GMT):
And some thoughts about the sdk as a whole: it seems like there are a lot of json-string parameters, which can be a pain to work with. (And leads to issues such as above, where I'm sending a whole lot of json, and only certain parts are relevant)

gudkov (Thu, 08 Feb 2018 13:43:09 GMT):
Thanks!

Artemkaaas (Thu, 08 Feb 2018 14:15:08 GMT):
@pimotte It will be great if you implement Getting-Started for Java wrapper and send PR. I think it will be better to implement it for the latest master Java wrapper to correspond python implementation GSG (https://github.com/hyperledger/indy-sdk/blob/master/samples/python/src/getting_started.py).

pimotte (Thu, 08 Feb 2018 14:23:29 GMT):
Yep, I've been working from that:)

gudkov (Thu, 08 Feb 2018 14:55:58 GMT):
It is invalid json. seqNo==null means that there is no corresponded record in the Pool found.

akhihaki (Thu, 08 Feb 2018 15:29:50 GMT):
Can this scenario be implemented in Indy, suppose identity owner has two claims from two issuers for first name attribute. and the agent is willing to accept claims from either of these issuers. But both claims have different schema, lets say issuer 1 uses `f_name` and issuer 2 `first_name`. How does the agent create proof request in this scenario ?

gudkov (Thu, 08 Feb 2018 15:50:20 GMT):
Prover can create aggregated proof over any claims and can use any attributes. Verifier can include multiple schemas to proof request.

akhihaki (Thu, 08 Feb 2018 18:56:54 GMT):
@gudkov, what i understand is (reading python getting started), verifier can support claims from multiple issuers by putting them in restrictions list in proof request eg, `'attr1_referent': {'name': 'first_name', 'restrictions': [ {'issuer_did': faber_issuer_did, 'schema_key': he_diploma_schema_key}, {'issuer_did': acme_issuer_did,'schema_key': employment_history_schema_key} ]},` now the prover can use either of the claims he got from `faber` or `acme` because both schemas have attribute `first_name`. Lets say in employment claim schema, it used `f_name` instead of `first_name`. In this scenario how verifier will change proof request supporting `f_name` and `first_name` in `attr1_referent` ?

akhihaki (Thu, 08 Feb 2018 18:56:54 GMT):
@gudkov, what i understand is (reading python getting started), verifier can support claims from multiple issuers by putting them in restrictions list in proof request eg, ```'attr1_referent': {'name': 'first_name', 'restrictions': [ {'issuer_did': faber_issuer_did, 'schema_key': he_diploma_schema_key}, {'issuer_did': acme_issuer_did,'schema_key': employment_history_schema_key} ]},``` now the prover can use either of the claims he got from `faber` or `acme` because both schemas have attribute `first_name`. Lets say in employment claim schema, it used `f_name` instead of `first_name`. In this scenario how verifier will change proof request supporting `f_name` and `first_name` in `attr1_referent` ?

akhihaki (Thu, 08 Feb 2018 18:56:54 GMT):
@gudkov, what i understand is (reading from python getting started), verifier can support claims from multiple issuers by putting them in restrictions list in proof request eg, ```'attr1_referent': {'name': 'first_name', 'restrictions': [ {'issuer_did': faber_issuer_did, 'schema_key': he_diploma_schema_key}, {'issuer_did': acme_issuer_did,'schema_key': employment_history_schema_key} ]},``` now the prover can use either of the claims he got from `faber` or `acme` because both schemas have attribute `first_name`. Lets say in employment claim schema, it used `f_name` instead of `first_name`. In this scenario how verifier will change proof request supporting `f_name` and `first_name` in `attr1_referent` ?

PJUllrich (Fri, 09 Feb 2018 08:09:14 GMT):
Has joined the channel.

pimotte (Fri, 09 Feb 2018 09:17:52 GMT):
I've fixed up some earlier parts in my java sample and now I'm running into the same problem I had yesterday. (GET_SCHEMA does not return the schema). I don't see any errors in the SCHEMA request, this is my log. https://pastebin.com/xNHaqJ2q I'm waiting and checking that the timestamp in the state_proof is after the return of the SCHEMA request. Does anyone have a clue what could be going on?

pimotte (Fri, 09 Feb 2018 10:07:15 GMT):
Got it, I was using the wrong destinationDid for the schema

akhihaki (Fri, 09 Feb 2018 13:36:41 GMT):
seq

ianco (Sun, 11 Feb 2018 14:52:53 GMT):
In prover.rs, "fn _attribute_satisfy_predicate()", the only p_type supported seems to be ">=". Is there a plan to add additional p_types (like "==", "<=", etc)?

gudkov (Mon, 12 Feb 2018 08:25:22 GMT):
> Is there a plan to add additional p_types (like "==", "<=", etc)? == is already supported in fact through disclosing of attributes. <= will be supported later.

Artemkaaas (Mon, 12 Feb 2018 08:28:11 GMT):
@akhihaki now there isn't a way to support this case.

NickThomas (Mon, 12 Feb 2018 23:13:24 GMT):
Has joined the channel.

hidde-jan (Tue, 13 Feb 2018 07:40:02 GMT):
Good morning

hidde-jan (Tue, 13 Feb 2018 07:40:53 GMT):
Is there a way to see which did's are stored in your wallet? I see that you can store pairwise relations (i.e. this is my did for communicating with that did) and getting the key of a specific did

hidde-jan (Tue, 13 Feb 2018 07:41:19 GMT):
but I can't seem to find the thing I need to call to get a list of my dids, like there is in the indy cli agent

hidde-jan (Tue, 13 Feb 2018 09:39:35 GMT):
so it seems it would use the rust 'function' indy_list_my_dids_with_meta

hidde-jan (Tue, 13 Feb 2018 09:39:47 GMT):
but there is no corresponding call to that function in the python wrapper

akhihaki (Tue, 13 Feb 2018 09:47:12 GMT):
@Artemkaaas @gudkov @ashcherbakov , i have been trying to create a sample application using INDY. High level, Trust Anchor issues verifiable claims to user and user tries to register to service which is accepting these claims. Weirdly i have a problem thats been occurring with `anoncreds.prover_get_claims_for_proof_req`, it is not behaving consistently. Sometimes it works fine and returns relevant claims for a , but sometimes returns `indy.error.IndyError: ErrorCode.CommonInvalidStructure` (_indy_loop_callback: Function returned error 113). Need help as i am trying to show possibilities using Indy to folks at my company. I am using the python wrappers. My libindy version: libindy_1.3.0~353_amd64.deb Will provide any information as needed. Thanks

alkopnin (Tue, 13 Feb 2018 09:50:44 GMT):
Hi guys, I get an error when try to store my claims on the prover side. Anoncreds.proverStoreClaim(wallet, claim).get() "org.hyperledger.indy.sdk.InvalidParameterException: The value passed to parameter 4 is not valid" Actually, I use the latest version of libindy and wrapper (1.3.1-rc-10) However, in wrapper's test the "proverStoreClaim" gets more arguments: public static CompletableFuture proverStoreClaim(Wallet wallet, String claim, String revRegJson) throws IndyException lib loaded with gradle has: public static CompletableFuture proverStoreClaim(Wallet wallet, String claim) throws IndyException Thanks in advance

gudkov (Tue, 13 Feb 2018 10:27:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=AYQv6sMrgTN3KkAwG) @akhihaki > it is not behaving consistently. Sometimes it works fine and returns relevant claims for a , but sometimes returns `indy.error.IndyError: ErrorCode.CommonInvalidStructure` (_indy_loop_callback: Function returned error 113). To help you we need exact jsons that you pass to functions and logs.

PJUllrich (Tue, 13 Feb 2018 10:41:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=SAxLky38qHpL5SMKK) @hidde-jan we also looked in the Java Wrapper -> No corresponding Java function either. At the moment we are unsure how you can retrieve all DIDs for a user's wallet(s)

PJUllrich (Tue, 13 Feb 2018 10:46:36 GMT):
@hidde-jan there is a indy_list_wallets function in the api/Wallet.rs class. However, there is no corresponding Java function either.

gudkov (Tue, 13 Feb 2018 10:58:14 GMT):
> @hidde-jan there is a indy_list_wallets function in the api/Wallet.rs class. However, there is no corresponding Java function either. You have 2 options: 1. Create a ticket in Jira and wait until main team will add this 2. Add this function to Java wrapper and send PR

akhihaki (Tue, 13 Feb 2018 12:06:40 GMT):
@gudkov here is the information from log files ``` DEBUG:indy.anoncreds:prover_get_claims_for_proof_req: >>> wallet_handle: 3, proof_request_json: '{"nonce": "b9b85f827111c6b3bf50", "name": "Amazon Claim Connection", "version": "0.1", "requested_attrs": {"attr1_referent": {"name": "name", "restrictions": [{"issuer_did": "FvDWG5w5LdBkaWnBqsJBv5", "schema_key": {"name": "Digital PAN Card", "version": "0.1", "did": "HUAc29EjhVEF4Q8So7y3rf"}}, {"issuer_did": "CZVsSKTb6MrSgTj7sHvhBx", "schema_key": {"name": "Bank Proof", "version": "0.1", "did": "RmzyjQGuRkk7ymZX3J3b4m"}}]}, "attr2_referent": {"name": "address", "restrictions": [{"issuer_did": "FvDWG5w5LdBkaWnBqsJBv5", "schema_key": {"name": "Digital PAN Card", "version": "0.1", "did": "HUAc29EjhVEF4Q8So7y3rf"}}, {"issuer_did": "CZVsSKTb6MrSgTj7sHvhBx", "schema_key": {"name": "Bank Proof", "version": "0.1", "did": "RmzyjQGuRkk7ymZX3J3b4m"}}]}, "attr3_referent": {"name": "gender", "restrictions": [{"issuer_did": "FvDWG5w5LdBkaWnBqsJBv5", "schema_key": {"name": "Digital PAN Card", "version": "0.1", "did": "HUAc29EjhVEF4Q8So7y3rf"}}, {"issuer_did": "CZVsSKTb6MrSgTj7sHvhBx", "schema_key": {"name": "Bank Proof", "version": "0.1", "did": "RmzyjQGuRkk7ymZX3J3b4m"}}]}}, "requested_predicates": {"predicate1_referent": {"attr_name": "age", "p_type": ">=", "value": 18, "restrictions": [{"issuer_did": "FvDWG5w5LdBkaWnBqsJBv5"}, {"issuer_did": "CZVsSKTb6MrSgTj7sHvhBx"}]}}}' DEBUG:indy.anoncreds:prover_get_claims_for_proof_req: Creating callback DEBUG:indy.libindy:create_cb: >>> cb_type: .CFunctionType'> DEBUG:indy.libindy:create_cb: <<< res: DEBUG:indy.libindy:do_call: >>> name: indy_prover_get_claims_for_proof_req, args: (c_int(3), c_char_p(21505504), ) DEBUG:indy.libindy:do_call: Function indy_prover_get_claims_for_proof_req returned err: 0 DEBUG:indy.libindy:_indy_callback: >>> command_handle: 34, err 113, args: (b'',) DEBUG:indy.libindy:do_call: <<< DEBUG:indy.libindy:_indy_callback: <<< DEBUG:indy.libindy:_indy_loop_callback: >>> command_handle: 34, err 113, args: (b'',) WARNING:indy.libindy:_indy_loop_callback: Function returned error 113 DEBUG:indy.libindy:_indy_loop_callback <<<

akhihaki (Tue, 13 Feb 2018 12:12:49 GMT):
Let me know if you need more

gudkov (Tue, 13 Feb 2018 12:18:17 GMT):
Yes, we need more. It is only log for python wrapper. We need TRACE level logs for libindy

gudkov (Tue, 13 Feb 2018 12:18:46 GMT):
Also TRACE level logs for libindy are very usefull to debug problems like you have.

gudkov (Tue, 13 Feb 2018 12:19:57 GMT):
libindy for now puts the log to stdout. You can control logs with RUST_LOG env variable. Just sent it it RUST_LOG=trace

gudkov (Tue, 13 Feb 2018 12:19:57 GMT):
libindy for now puts the log to stdout. You can control logs with RUST_LOG env variable. Just set it it RUST_LOG=trace

PJUllrich (Tue, 13 Feb 2018 12:36:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=pXjxZbZkLX7LdLn6c) @gudkov we are currently working on a feasibility study of using Sovrin, but as we see it at the moment, there are 2 major barriers of using Sovrin. 1) The code in the wrappers is enormously complex, making it very hard to use. We recommend to abstract away such complexity either into the libindy library itself, or at least give simpler endpoints in the wrappers, which offer the functionality in a comprehensive way. As it is now, we have to step through multiple layers of Java and Rust code to understand what a wrapper function does. 2) We are missing basic CRUD functions for the model classes like Wallet and Claim in the wrappers, which makes it hard to implement our own functionality using the wrappers. Also, we see that crucial functionality like e.g. onboarding is actually implemented in the samples and not in the wrappers themselves. This as well lowers the usability of the wrappers.

PJUllrich (Tue, 13 Feb 2018 12:39:10 GMT):
I just wanted to share with you what holds us back as newcomers. We will consider to create Jira tickets for these things, but it seemed like being a more fundamental issue to us.

PJUllrich (Tue, 13 Feb 2018 12:39:49 GMT):
Btw. this is not the official opinion of @hidde-jan, only my own.

Artemkaaas (Tue, 13 Feb 2018 12:52:04 GMT):
@akhihaki nonce must be a number represented as a string

akhihaki (Tue, 13 Feb 2018 12:53:41 GMT):
@Artemkaaas, to confirm i am sending nonce as string itself

akhihaki (Tue, 13 Feb 2018 12:55:35 GMT):
just to add, i have restarted the application and started from beginning, and this time everything worked fine ``` DEBUG:indy.anoncreds:prover_get_claims_for_proof_req: >>> wallet_handle: 3, proof_request_json: '{"nonce": "9b3a573e46d5e0a16e13", "name": "Amazon Claim Connection", "version": "0.1", "requested_attrs": {"attr1_referent": {"name": "name", "restrictions": [{"issuer_did": "FvDWG5w5LdBkaWnBqsJBv5", "schema_key": {"name": "Digital PAN Card", "version": "0.1", "did": "HUAc29EjhVEF4Q8So7y3rf"}}, {"issuer_did": "56EXXUHDRjX3vfsoeHJkzM", "schema_key": {"name": "Bank Proof", "version": "0.1", "did": "RmzyjQGuRkk7ymZX3J3b4m"}}]}, "attr2_referent": {"name": "address", "restrictions": [{"issuer_did": "FvDWG5w5LdBkaWnBqsJBv5", "schema_key": {"name": "Digital PAN Card", "version": "0.1", "did": "HUAc29EjhVEF4Q8So7y3rf"}}, {"issuer_did": "56EXXUHDRjX3vfsoeHJkzM", "schema_key": {"name": "Bank Proof", "version": "0.1", "did": "RmzyjQGuRkk7ymZX3J3b4m"}}]}, "attr3_referent": {"name": "gender", "restrictions": [{"issuer_did": "FvDWG5w5LdBkaWnBqsJBv5", "schema_key": {"name": "Digital PAN Card", "version": "0.1", "did": "HUAc29EjhVEF4Q8So7y3rf"}}, {"issuer_did": "56EXXUHDRjX3vfsoeHJkzM", "schema_key": {"name": "Bank Proof", "version": "0.1", "did": "RmzyjQGuRkk7ymZX3J3b4m"}}]}}, "requested_predicates": {"predicate1_referent": {"attr_name": "age", "p_type": ">=", "value": 18, "restrictions": [{"issuer_did": "FvDWG5w5LdBkaWnBqsJBv5"}, {"issuer_did": "56EXXUHDRjX3vfsoeHJkzM"}]}}}' DEBUG:indy.anoncreds:prover_get_claims_for_proof_req: Creating callback DEBUG:indy.libindy:create_cb: >>> cb_type: .CFunctionType'> DEBUG:indy.libindy:create_cb: <<< res: DEBUG:indy.libindy:do_call: >>> name: indy_prover_get_claims_for_proof_req, args: (c_int(3), c_char_p(50030000), ) DEBUG:indy.libindy:do_call: Function indy_prover_get_claims_for_proof_req returned err: 0 DEBUG:indy.libindy:do_call: <<< DEBUG:indy.libindy:_indy_callback: >>> command_handle: 34, err 0, args: (b'{"attrs":{"attr1_referent":[{"referent":"claim::d0647389-08bd-48dd-9f18-6045acff8c5c","attrs":{"account":"SAASUSER00001","name":"Akhilesh","gender":"Male","age":"24","address":"1-1-1, this street, this city, andhra pradesh"},"schema_key":{"name":"Bank Proof","version":"0.1","did":"RmzyjQGuRkk7ymZX3J3b4m"},"issuer_did":"56EXXUHDRjX3vfsoeHJkzM","revoc_reg_seq_no":null}],"attr2_referent":[{"referent":"claim::d0647389-08bd-48dd-9f18-6045acff8c5c","attrs":{"account":"SAASUSER00001","name":"Akhilesh","gender":"Male","age":"24","address":"1-1-1, this street, this city, andhra pradesh"},"schema_key":{"name":"Bank Proof","version":"0.1","did":"RmzyjQGuRkk7ymZX3J3b4m"},"issuer_did":"56EXXUHDRjX3vfsoeHJkzM","revoc_reg_seq_no":null}],"attr3_referent":[{"referent":"claim::d0647389-08bd-48dd-9f18-6045acff8c5c","attrs":{"account":"SAASUSER00001","name":"Akhilesh","gender":"Male","age":"24","address":"1-1-1, this street, this city, andhra pradesh"},"schema_key":{"name":"Bank Proof","version":"0.1","did":"RmzyjQGuRkk7ymZX3J3b4m"},"issuer_did":"56EXXUHDRjX3vfsoeHJkzM","revoc_reg_seq_no":null}]},"predicates":{"predicate1_referent":[{"referent":"claim::d0647389-08bd-48dd-9f18-6045acff8c5c","attrs":{"account":"SAASUSER00001","name":"Akhilesh","gender":"Male","age":"24","address":"1-1-1, this street, this city, andhra pradesh"},"schema_key":{"name":"Bank Proof","version":"0.1","did":"RmzyjQGuRkk7ymZX3J3b4m"},"issuer_did":"56EXXUHDRjX3vfsoeHJkzM","revoc_reg_seq_no":null}]}}',

gudkov (Tue, 13 Feb 2018 13:10:09 GMT):
@PJUllrich > ) The code in the wrappers is enormously complex, making it very hard to use. We recommend to abstract away such complexity either into the libindy library itself, or at least give simpler endpoints in the wrappers, which offer the functionality in a comprehensive way. Could you provide sample of complex code and how you see the same sample in a more simpler way?

gudkov (Tue, 13 Feb 2018 13:14:28 GMT):
> 2) We are missing basic CRUD functions for the model classes like Wallet and Claim in the wrappers, which makes it hard to implement our own functionality using the wrappers. We are now trying to make API less complex. Especially in anoncreds part. For wallet you have create/delete/open/close operations. What additional operation do you need? For Claims i am not sure that that we can provide simple Crud as it requires complex protocol to be issued and handled.

gudkov (Tue, 13 Feb 2018 13:16:17 GMT):
> onboarding is actually implemented in the samples and not in the wrappers themselves. The problem here is that onboarding can be much more complex in real use cases. libindy desn't force onboarding workflow.

Artemkaaas (Tue, 13 Feb 2018 13:17:10 GMT):
@akhihaki I see the strange behavior of OpenSSL... when I use nonce which starts from a digital everything works well, but when I use nonce which starts with a letter I get `An OpenSSL error stack`. Anyway it's better to use nonces as a decimal numbers

gudkov (Tue, 13 Feb 2018 13:18:22 GMT):
Current vision is that additional vendors will provide simple utilities for onboarding integrated with cloud agency infrastructure.

hidde-jan (Tue, 13 Feb 2018 13:22:01 GMT):
@gudkov I've implemented list_my_dids_with_meta for the python wrapper, but I get two return values, the first is a json list with the different dids (and meta data) and the second is some weird bytestring

hidde-jan (Tue, 13 Feb 2018 13:22:19 GMT):
list_my_dids_with_meta: <<< res: (b'[{"did":"VsKV7grR1BUE29mG2Fm2kX","metadata":null,"verkey":"GjZWsBLgZCR18aL468JAT7w9CZRiBnpxUPPgyQxh4voa"}]', b'I\xbb:\xef\xe1\xc9W\x7f')

alkopnin (Tue, 13 Feb 2018 13:23:12 GMT):
@gudkov Hi, could you help me please too

alkopnin (Tue, 13 Feb 2018 13:23:23 GMT):
do you have some comment on my message above?

alkopnin (Tue, 13 Feb 2018 13:23:23 GMT):
do you have some comments on my message above?

gudkov (Tue, 13 Feb 2018 13:24:23 GMT):
> do you have some comments on my message above? What exact message you mean?

gudkov (Tue, 13 Feb 2018 13:27:16 GMT):
I see

gudkov (Tue, 13 Feb 2018 13:27:59 GMT):
@Artemkaaas will check

akhihaki (Tue, 13 Feb 2018 13:29:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=NFfY2SppP3HxNhY9C) @Artemkaaas let me try this out and still check the problem persists

sergey.minaev (Tue, 13 Feb 2018 14:04:12 GMT):
@hidde-jan libindy for this method returns only one string. Most probably issue is around casting FFI to python. You can check `replace_keys_start` as sample

hidde-jan (Tue, 13 Feb 2018 14:07:01 GMT):
@sergey.minaev yeah I changed the callback function parameters and now it seems to work, but I'm not sure if they are really correct. I've added tests and they pass so something must be going well

hidde-jan (Tue, 13 Feb 2018 14:07:05 GMT):
I opened a PR

EtienneNijboer (Tue, 13 Feb 2018 14:42:38 GMT):
sample of complex code... For example the getting_started code is one long method filled with all kinds of calls. Results of one call are going seemlessly into another api call. But in a more real example this would not happen in a single method. This automatically means local variables which are now used with ease are normally not accessible by the other party. It would be nice if the example would be split into different classes, such as the steward, acme, faber and alice. It would hopefully become more clear where certain data would need to be exchanged off-ledger. What makes the code hard to understand is that the wrappers are just pass-through into libindy. It requires extensive knowledge of what strings/json needs to be passed in and what will be returned. Also, having to encode the values of claims into an array with a value and numerical characters gives the idea that some voodoo practices might come into play later as well. At the end everything is closed and deleted. Is that the normal way of working? How to reopen a wallet and resume. If the wallet and pool are not deleted then the getting started won't work anymore. But when (re)opening the wallet, it is unclear how to resume. Calling indy_list_pairwise returns "[]" json strings. The wallet itself ofers no methods itself to work with. I think the main reason that makes understanding and working with indy extremely hard is the fact that there is no flow in how to use the components. It would feel more natural having an IdentityOwner class that has a wallet (or maybe wallet per connection/relation) and is able to list its connections (with some kind of name /description), is able to create new connections. It also has a certain role, and can create claim definitions/requests and assert claims accordingly to its role. Just my two cents...

hidde-jan (Tue, 13 Feb 2018 15:18:47 GMT):
To add to Eienne, something more pythonic like https://github.com/PSPC-SPAC-buyandsell/von_agent with proper classes and OOP-style is what I would expect from an SDK. I know there has been a lot of stuff going on with deprecating indy-client and moving to indy-sdk, but having to pass wallet and pool 'handles' everywhere and getting json strings back isn't very user-friendly

EtienneNijboer (Tue, 13 Feb 2018 15:40:08 GMT):
and... to add to that, apply the principle of least surprise. I'm really trying for weeks now to get something substantial going, without any results I might add. Some surprises: Only when creating the steward a json with seed is passed into the create_and_store_my_did. Another surprise is that the results of did.create_and_store_my_did are stored into the wallet. But did.key_for_did is looking at the ledger. Also, did is just some data but is doing all kinds of things for _my_ and _their_ wallet. I really put a lot of effort into get something going but i'm sorry to say that the code is nothing like the pdf's that describe the idea. For me there is nothing natural about any part of the process.

gudkov (Tue, 13 Feb 2018 16:13:28 GMT):
Thanks for feedback. For some cases i share it and we will improve, but for some it was done for the reason. I will provide more details tomorrow.

gudkov (Wed, 14 Feb 2018 08:06:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Zj4seEHfovigj3nih) @hidde-jan Thanks for contribution. The code looks good, but our process enforces the Developer Certificate of Origin (https://developercertificate.org/) on Pull Requests. It requires all commit messages to contain the Signed-off-by line with an email address that matches the commit author. Git has a -s command line option to append this automatically to your commit message: $ git commit -s -m 'This is my commit message' To pass our DCO validation i suggest to perform interactive re-base of your commits with added sign off line. See https://github.com/probot/dco for more details. If you need some help just ask me.

gudkov (Wed, 14 Feb 2018 08:52:42 GMT):
@EtienneNijboer @hidde-jan Some notes about your feedback: > What makes the code hard to understand is that the wrappers are just pass-through into libindy. > It would feel more natural having an IdentityOwner class that has a wallet (or maybe wallet per connection/relation) and is able to list its connections (with some kind of name /description), is able to create new connections. It also has a certain role, and can create claim definitions/requests and assert claims accordingly to its role. > something more pythonic like https://github.com/PSPC-SPAC-buyandsell/von_agent with proper classes and OOP-style is what I would expect from an SDK. I know there has been a lot of stuff going on with deprecating indy-client and moving to indy-sdk, but having to pass wallet and pool 'handles' everywhere and getting json strings back isn't very user-friendly As i understand you want to increase the level of abstraction and get more OOP-style and use cases oriented API endpoints especially for wrappers. In our current vision libindy is low level libirary that corresponds abstraction level of Indy Node API. It causes necessity of understanding Node transactions format and building blocks are small and don't force some obvious workflow, but also provides some advantages. It is flexible enough to cover all use cases. For example, proposed IdentityOwner class forces edge device agent use case, but doesn't fit well cloud agency use cases or low-level node testing. It doesn't introduce new domain classes that must be in sync with node transactions format, but also it helps to support big amount of language wrappers as part of core project. Wrappers in indy-sdk repo in current vision must be as close as possible to libindy. They are intended to solve most complex wrappers parts: FFI and asynchronous code, but we don't want to increase the level of abstraction or introducing any new semantics. libindy is like Windows API. It requires low level system understanding and main consumers are infrastructure developers. I'm sure in the near future there will be application developer friendly use-case oriented libraries based on libindy and low-level wrappers.

gudkov (Wed, 14 Feb 2018 08:58:43 GMT):
> For example the getting_started code is one long method filled with all kinds of calls. Results of one call are going seemlessly into another api call. But in a more real example this would not happen in a single method. This automatically means local variables which are now used with ease are normally not accessible by the other party. It would be nice if the example would be split into different classes, such as the steward, acme, faber and alice. It would hopefully become more clear where certain data would need to be exchanged off-ledger. Main purpose of this test is to be explained by our Getting Started Guide (https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md). It clearly explains what agent executes the code part and all messages exchanges. Splitting to different classes can make this code more obvious, but i am not sure that it fits out GSG well.

gudkov (Wed, 14 Feb 2018 09:21:13 GMT):
> Also, having to encode the values of claims into an array with a value and numerical characters gives the idea that some voodoo practices might come into play later as well. As i already said we don't want to force use cases on libindy level and attributes representation is completely use case based. > At the end everything is closed and deleted. Is that the normal way of working? How to reopen a wallet and resume. If the wallet and pool are not deleted then the getting started won't work anymore. Unit/integration tests usually perform cleanup and assume clean environment. If you don't want to delete wallet just close it after usage and open again when you need it.

gudkov (Wed, 14 Feb 2018 09:22:09 GMT):
@EtienneNijboer > Only when creating the steward a json with seed is passed into the create_and_store_my_did. I don't understand this. create_and_store_my_did doen't have any specific parameters for roles. You can always use seed if you want. Could you explain?

gudkov (Wed, 14 Feb 2018 09:36:05 GMT):
> Also, did is just some data but is doing all kinds of things for _my_ and _their_ wallet. Did here means "did document" in w3c terminology. Each DID Document contains at least three things: cryptographic material, authentication suites, and service endpoints.

narendranath (Wed, 14 Feb 2018 12:11:04 GMT):
Has joined the channel.

mjmckean (Wed, 14 Feb 2018 22:22:15 GMT):
Has joined the channel.

hidde-jan (Wed, 14 Feb 2018 22:22:31 GMT):
@gudkov thanks for your reply. I understand that indy-sdk might intentionally be low level, which means there is room for projects like the von_agent I linked earlier. Indeed, a cloud agent would behave very differently from an edge device etc. Designing a high level api that fits all use cases would be difficult or impossible. Working with indy kinda forces us into the role of an infrastructure developer at the moment, which might not be the position everyone is comfortable in, but that is the consequence of being some of the first people to try out this stuff :)

rishabhmthakur (Thu, 15 Feb 2018 08:26:17 GMT):
Has joined the channel.

narendranath (Fri, 16 Feb 2018 12:34:46 GMT):
hi iam Blockchain Developer from USTGlobal Spain

narendranath (Fri, 16 Feb 2018 12:35:44 GMT):
indy-sdk for java, Example use public class TestCreate

narendranath (Fri, 16 Feb 2018 12:36:09 GMT):
some classes are doesn't match with sdk

gudkov (Fri, 16 Feb 2018 13:23:33 GMT):
Do you look to master?

sklump (Fri, 16 Feb 2018 17:00:15 GMT):
Could someone kindly direct me to a discussion of what a cloud agent is? I'm afraid I missed all of this.

Drew 42 (Fri, 16 Feb 2018 21:36:43 GMT):
Has joined the channel.

ianco (Sat, 17 Feb 2018 01:51:10 GMT):
Hi folks, looks like the python getting started script is busted with the latest updates in indy-sdk? Basically at this line: "await auth_decrypt(alice_wallet, alice_faber_key, authcrypted_transcript_claim_offer)", it looks like internally in the auth_decrypt function something is getting truncated, and then this line is crashing: "decrypted_message = json.loads(decrypted_message_json)"

ianco (Sat, 17 Feb 2018 01:51:34 GMT):
json.decoder.JSONDecodeError

peacekeeper (Sat, 17 Feb 2018 08:52:55 GMT):
Is there an API to export a DID's private key from a wallet? Why not?

gudkov (Mon, 19 Feb 2018 08:42:29 GMT):
> Is there an API to export a DID's private key from a wallet? Why not? No. The only way to reconstruct the same keys in a separate wallet is seeds usage.

gudkov (Mon, 19 Feb 2018 10:00:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nsLLsFW7AncEi5WqJ) @ianco Fixed in PR https://github.com/hyperledger/indy-sdk/pull/540

gudkov (Mon, 19 Feb 2018 10:04:11 GMT):
Also i added https://jira.hyperledger.org/browse/IS-572 (CI: CI should check all samples of Indy SDK) to our backlog

gudkov (Mon, 19 Feb 2018 10:08:23 GMT):
> Could someone kindly direct me to a discussion of what a cloud agent is? I'm afraid I missed all of this. Cloud Agent is Indy code executed in cloud, not on the user's edge device. For example, it is hard to receive messages on the edge device because you need to have some endpoint published. You can delegate this to some cloud agency that will host your endpoints. On receiving a message it will notify edge device through push notification and edge device will connect to the cloud to download this message. Some use cases can assume delegation of some keys to cloud agent and providing access to messages metadata or part of messages.

ianco (Mon, 19 Feb 2018 16:03:09 GMT):
@gudkov thanks I'll check it out!

ianco (Mon, 19 Feb 2018 16:35:50 GMT):
Is there any documentation around the wallet credentials and how they are to be used? DefaultWallet has a "key" and "rekey" attributes but not really sure what they're used for. Can custom wallet implementations implement any credentials structure? Or should they derive from some base?

ryanmarsh (Mon, 19 Feb 2018 19:33:04 GMT):
@gudkov I am currently working on accepting a proof which contains self attested attributes with the intent of validating it through libindy. I can't find a clear example of this in the demos. When someone creates a proof with a self attested value, will this value only show up in self_attested_attrs part of the proof or will it also be included in the revealed_attrs field? Here is an example proof req: { "name":"Self Attested Proof", "nonce":"2771519439", "requested_attrs":{ "address1_0":{ "issuer_did":"DunkM3x1y7S4ECgSL4Wkru", "name":"address1", "schema_seq_no":296 }, "address2_1":{ "issuer_did":"DunkM3x1y7S4ECgSL4Wkru", "name":"address2", "schema_seq_no":296 }, "self_attested_2":{ "name":"self_attested" } }, "requested_predicates":{ }, "version":"0.1" } The person I send this proof req to contains a claim for both address1 and address2. They will self attest the self_attested_2 field. When the person returns a proof, this is an example message of what I'm guessing it will look like: { "proofs":{ "claim::0554b3de-f59e-491a-b21c-36050fc4bb8a":{ "proof":{ "primary_proof":{ "eq_proof":{ "revealed_attrs":{ "address1":"6", "address2":"5" }, "a_prime":"5", "e":"4", "v":"3", "m":{ }, "m1":"1", "m2":"2" }, "ge_proofs":[ ] }, "non_revoc_proof":null }, "schema_seq_no":296, "issuer_did":"DunkM3x1y7S4ECgSL4Wkru" } }, "aggregated_proof":{ "c_hash":"4", "c_list":[ [ 1, 245 ] ] }, "requested_proof":{ "revealed_attrs":{ "address2_1":[ "claim::0554b3de-f59e-491a-b21c-36050fc4bb8a", "101 Wilson Lane", "6" ], "address1_0":[ "claim::0554b3de-f59e-491a-b21c-36050fc4bb8a", "101 Tela Lane", "5" ] }, "unrevealed_attrs":{ }, "self_attested_attrs":{ "self_attested_2":"self attested value" }, "predicates":{ } } } The problem I see with this is that when libindy tries to validate the proof, it tries to verify that the requested attributes and the received (revealed + unrevealed) attributes are the same. If the self_attested value isn't added to the revealed or unrevealed portion of the proof, it fails verification on line 129 of libindy/src/commands/anoncreds/verifier.rs. Can you let me know if I'm misunderstanding this? If not, this is a bug.

Artemkaaas (Tue, 20 Feb 2018 06:18:19 GMT):
@ryanmarsh What Libindy version do you use? This problem was fixed some time ago.

EtienneNijboer (Tue, 20 Feb 2018 14:09:45 GMT):
I'm currently using the java wrappers to register an agent. But when I use Ledger.buildNymRequest(steward.did, newDid, newVerKey, null, "TRUSTEE") I still have to use (and therefor send) the steward.did when calling Did.keyForDid on the new trust agent side. Otherwise I get an InvalidStateException (sdk internal error). I would expect that the newDid with the nonce should be sent to the new trust agent and it should use those to look up the newVerKey from the ledger. Does someone have an idea what could go wrong? (currently using 1.3.1-dev-399)

ryanmarsh (Tue, 20 Feb 2018 14:27:45 GMT):
@Artemkaaas I am currently using 1.3. Do you know which version it is fixed in?

EtienneNijboer (Tue, 20 Feb 2018 14:34:12 GMT):
Ps. I see in the console of one of the nodes that is says "STEWARD cannot add TRUSTEE". Can someone explain how I can resolve this?

gudkov (Tue, 20 Feb 2018 14:55:23 GMT):
TRUSTEE can be created only by TRUSTEE.

gudkov (Tue, 20 Feb 2018 14:56:01 GMT):
Why you want TRUSTEE? Most probable you need just TRUST_ANCHOR

EtienneNijboer (Tue, 20 Feb 2018 15:01:07 GMT):
Probably that is the issue. I'm just following the getting started (on github) and there only role (as parameter) is being mentioned. In IndyConstants there is TRUSTEE and STEWARD defined. So TRUSTEE seemed to come close. But I guess TRUST_ANCHOR is the role I'm actually looking for.

Artemkaaas (Wed, 21 Feb 2018 05:10:21 GMT):
@ryanmarsh only master branch. rc and stable builds contain November code.

mawi (Wed, 21 Feb 2018 08:17:16 GMT):
Has joined the channel.

pimotte (Wed, 21 Feb 2018 09:03:56 GMT):
I'm getting ` org.hyperledger.indy.sdk.InvalidStateException: The SDK library experienced an unexpected internal error.` on a key_for_did call. Logs say `Invalid library state: Invalid GetNymReplyResult json`. Does anyone have a clue what could be going on?

pimotte (Wed, 21 Feb 2018 09:07:01 GMT):
Surrounding logging: https://pastebin.com/SY73vTan

pimotte (Wed, 21 Feb 2018 10:49:33 GMT):
I've found that a GetNymReplyResult has null "data" which causes the error

pimotte (Wed, 21 Feb 2018 10:52:48 GMT):
Looks like it was an eventual consistency issue, it looks to work

sergey.minaev (Wed, 21 Feb 2018 11:04:58 GMT):
@pimotte Yes, the reason of the exception is the response from ledger with `null` field `data`

sergey.minaev (Wed, 21 Feb 2018 11:05:30 GMT):
Do you waiting result from the previous step?

pimotte (Wed, 21 Feb 2018 11:06:02 GMT):
Yeah, I'm now sleeping after onboarding and that helps

sergey.minaev (Wed, 21 Feb 2018 11:06:39 GMT):
`.get()` for completable feature isn't enough?

pimotte (Wed, 21 Feb 2018 11:07:58 GMT):
Ooh, yeah, turns out I was missing a .get in my onboarding functions

mhailstone (Wed, 21 Feb 2018 23:26:38 GMT):
Getting an error in getting_started.py: ```Traceback (most recent call last): File "~/hyperledger/indy-sdk/samples/python/src/main.py", line 15, in loop.run_until_complete(main()) File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/base_events.py", line 467, in run_until_complete return future.result() File "~/hyperledger/indy-sdk/samples/python/src/main.py", line 11, in main await getting_started.run() File "~/hyperledger/indy-sdk/samples/python/src/getting_started.py", line 189, in run await anoncreds.issuer_create_claim_offer(faber_wallet, json.dumps(transcript_schema), AttributeError: module 'indy.anoncreds' has no attribute 'issuer_create_claim_offer'```

mhailstone (Thu, 22 Feb 2018 00:36:30 GMT):
Found it. I created a virtualenv inside the samples/python directory but was not running the setup.py files from the wrappers and the samples directories in that virtualenv which wasn't updating the libraries. Python noob still.

pimotte (Thu, 22 Feb 2018 12:07:20 GMT):
I just found the "pairwise" API, which seems like a very useful API. Is there any particular reason it is not used in the samples? (i.e. instability or something?)

mattsmithies (Thu, 22 Feb 2018 15:36:09 GMT):
Has joined the channel.

jimscarver (Thu, 22 Feb 2018 16:16:07 GMT):
Has joined the channel.

Comuto (Thu, 22 Feb 2018 16:16:12 GMT):
Has joined the channel.

dkulic (Thu, 22 Feb 2018 16:41:12 GMT):
Has joined the channel.

jankokrstic (Thu, 22 Feb 2018 16:57:50 GMT):
Has joined the channel.

danielhardman (Thu, 22 Feb 2018 17:04:27 GMT):
Here is a link to the wallet doc I shared on today's call: https://docs.google.com/document/d/1uvoZkMdZz-TZKrTYbyLXSa-kDueIex69BBy2SGPgQ2s/edit

codenamedmitri (Thu, 22 Feb 2018 17:41:17 GMT):
is anybody working on a Node.js binding for Indy SDK?

malvikam (Thu, 22 Feb 2018 18:52:30 GMT):
Has joined the channel.

danielhardman (Thu, 22 Feb 2018 19:04:44 GMT):
I have heard at least 2 different node.js wrappers. @nage may know more.

nage (Thu, 22 Feb 2018 19:05:30 GMT):
@farskipper do you have any updates you could share?

LeBaton (Sat, 24 Feb 2018 16:34:39 GMT):
Has joined the channel.

LeBaton (Sat, 24 Feb 2018 16:37:34 GMT):
Hey guys, anybody managed to build Indy.framework? Or launch the demo app?

ianco (Sun, 25 Feb 2018 17:09:20 GMT):
@LeBaton are you trying to run the "getting started" app? (python script)

LeBaton (Sun, 25 Feb 2018 17:09:58 GMT):
I'm trying to run ios-demo

ianco (Sun, 25 Feb 2018 17:10:29 GMT):
oh ok, I've only worked with the python demos

LeBaton (Sun, 25 Feb 2018 17:11:03 GMT):
What about the python stuff, does it run from master branch ?

ianco (Sun, 25 Feb 2018 17:12:16 GMT):
Yes it should. I'm running on Ubuntu so if you follow all these instructions it should work: https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md

ianco (Sun, 25 Feb 2018 17:13:34 GMT):
... and then cd into samples/python and run "python src/main.py" to run the Alice/Faber demo

ianco (Sun, 25 Feb 2018 17:13:34 GMT):
... and then cd into samples/python and run "PYTHON_PATH=".:../../wrappers/python" python src/main.py" to run the Alice/Faber demo

LeBaton (Sun, 25 Feb 2018 17:17:16 GMT):
Thanks @ianco, will try it out tomorrow.

ianco (Sun, 25 Feb 2018 17:17:26 GMT):
:+1:

LeBaton (Sun, 25 Feb 2018 17:18:30 GMT):
If anyone else could help me a bit with the iOS wrapper, I wouldn't mind updating the repo

farskipper (Mon, 26 Feb 2018 18:37:40 GMT):
Hi y’all. I’m actively working on a Node.js wrapper. Here: https://github.com/Picolab/indy-sdk/tree/master/wrappers/nodejs Currently it has a TDD build setup and binds+tests one indy function. I hope to have it fully tested by the end of March. I’m using Nan and follow leveldown’s approach since they have great cross-platform support with prebuilt binaries. The api will mirror the c-api. I.e. `indy.abbreviate_verkey(did, verkey, function (err, verkey) {})`

sergey.khoroshavin (Tue, 27 Feb 2018 10:27:39 GMT):
Has joined the channel.

hawkmauk (Tue, 27 Feb 2018 12:37:02 GMT):
I've been trying to build indy-cli and have encountered the following error: ``` = note: /usr/local/lib/../lib/libindy.so: undefined reference to 'crypto_stream_aes128ctr_xor' /usr/local/lib/../lib/libindy.so: undefined reference to 'crypto_stream_aes128ctr'``` I believe that this is due to the version of libsodium that I am using (1.0.16) as *crypto_stream_aes128ctr* has been completely removed as of v1.0.15 (https://github.com/jedisct1/libsodium/blob/bdc60d47ed5c4a6e66069d19d7b05af2d8b1b315/ChangeLog) > - The aes128ctr primitive was removed. It was slow, non-standard, not authenticated, and didn't seem to be used by any opensource project. I've searched through the source files but can't find a reference to *crypto_stream_aes128ctr* in either indy-sdk/libindy or indy-sdk/cli so am not sure where this is being referenced from. To resolve I've used libsodium-1.0.14 when building indy-sdk instead but would it be appropriate to open a JIRA for this with the limited information I have on this issue?

Toktar (Tue, 27 Feb 2018 14:15:41 GMT):
Has joined the channel.

SergeyPalamarchuk (Wed, 28 Feb 2018 08:01:11 GMT):
Has joined the channel.

ianco (Wed, 28 Feb 2018 14:15:50 GMT):
Hi folks, in doing updated to the indy-sdk for the BC Gov TheOrgBook wallet, I've run into a dependency conflict. Specifically, in indy-sdk there is a dependency on a specific version of the openssl library (0.9.20). I've added a REST client library to the mix (reqwest, which seems to be the most robust and widely used http library), however it requires native-tls version 0.1.5, which requires openssl 0.9.24. Without digging into all the gory details, I tried changing the indy-sdk dependency to allow the library to build with openssl version 0.9.24, and all the unit tests seem to pass, I just wanted to check whether there was a known dependency on the specific openssl version. Thanks!

mboyd (Wed, 28 Feb 2018 16:59:28 GMT):
Has joined the channel.

malvikam (Wed, 28 Feb 2018 19:15:35 GMT):
I am writing a service to create DIDs on Sovrin Sandbox network. How do I go about getting permissions to start creating DIDs on the sandbox network? Currently when I try to invoke indy_sign_and_submit_request(), I get response- "client request invalid: CouldNotAuthenticate('Can not find verkey for ,)...". Assuming the submitter_did has to exist in the ledger, how do I get register that submitter_did for my service?

gudkov (Thu, 01 Mar 2018 00:36:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=uHXNCnGwrHRDdCvk5) @hawkmauk libsodium Rust wrapper that we use just reference these functions. We are waiting for wrapper update for switching to the latest libsodium.

gudkov (Thu, 01 Mar 2018 00:41:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=CuJSSFnb79QFdP5t4) @ianco Are you adding 'reqwest' to libindy codebase? I am not sure that it is a proper way for libindy usage. It is intended to be used as a dynamic library.

gudkov (Thu, 01 Mar 2018 00:43:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ar4edApzD6HfSXaJp) @malvikam Have you read our getting started guide? https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md It explains basics of Indy permissions system.

gudkov (Thu, 01 Mar 2018 00:45:35 GMT):
To send DIDs you have to be Trust Anchor.

malvikam (Thu, 01 Mar 2018 00:46:51 GMT):
I have read it. What I am trying to ask is, is there an official sovrin test network with existing nodes that I can register to become Trust Anchor on and start issuing DIDs?

malvikam (Thu, 01 Mar 2018 00:47:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9C8xBZBjq4HxJgxqA) @gudkov I have read it. What I am trying to ask is, is there an official sovrin test network with existing nodes that I can register to become Trust Anchor on and start issuing DIDs? My organization is currently in process of getting the Trust Anchor role on the official sovrin blockchain. In the meantime, I want to test the code on a test network (trying to avoid running a local network).

ianco (Thu, 01 Mar 2018 00:59:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=fbSDLHW9Xgxmm8AG2) @gudkov I added reqwest as a dependency in Cargo.toml, to support a remote wallet interface via REST. The sdk's .wallet plug-in model (as far as I can tell) doesn't support a Python-based wallet

ianco (Thu, 01 Mar 2018 01:00:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Zd5xcyrE5M5eJ73Rc) @malvikam [ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4Nq9SFBA5JcKrgGYY) https://raw.githubusercontent.com/ianco/indy-sdk/master/doc/wallet/ew-sdk-design.png

ianco (Thu, 01 Mar 2018 01:01:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4Nq9SFBA5JcKrgGYY) https://raw.githubusercontent.com/ianco/indy-sdk/master/doc/wallet/ew-sdk-design.png

gudkov (Thu, 01 Mar 2018 01:04:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4Nq9SFBA5JcKrgGYY) @ianco It is possible to expose register_wallet_type to python API too.

ianco (Thu, 01 Mar 2018 01:43:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=cqc7ZWdKNxAvASF4n) @gudkov You mean with a Python wallet implementing the wallet API (get(), set), list() etc.) that is callable from the Rust code? Do you have an example of that?

lcinacio (Thu, 01 Mar 2018 08:18:13 GMT):
Has joined the channel.

ADoroganov (Thu, 01 Mar 2018 11:45:12 GMT):
Has joined the channel.

ADoroganov (Thu, 01 Mar 2018 11:50:24 GMT):
Hello, everyone. I`m trying to work with 1.3.1-dev-406 wrapper, what commit from master should I use to get proper lib-indy and indy-pool (docker)?

ADoroganov (Thu, 01 Mar 2018 11:50:54 GMT):
Or how can I find it out my self?

ADoroganov (Thu, 01 Mar 2018 12:03:38 GMT):
@gudkov @Artemkaaas ^^^ any ideas?

Artemkaaas (Thu, 01 Mar 2018 12:07:49 GMT):
8b0b6eb801b2937fe85fbf41e0fbf23be0a1ff5b

ADoroganov (Thu, 01 Mar 2018 12:08:53 GMT):
Thx, any ideas how should i be able to do it on my own?

Artemkaaas (Thu, 01 Mar 2018 12:21:32 GMT):
I got it in Jenkins. I think there is not a way to get it for you because there is a shift in numbers between package-version and number of merged PullReq.

ADoroganov (Thu, 01 Mar 2018 12:24:24 GMT):
ok, thank you for details

danielhardman (Thu, 01 Mar 2018 16:51:11 GMT):
I posted about our dev tutorial over in #indy; here's a link: https://chat.hyperledger.org/channel/indy?msg=NYmB3q2P6eC2b8xDE

pimotte (Fri, 02 Mar 2018 13:27:01 GMT):
Are there any known bugs where keyForDid returns the did itself?

the_identity_guy (Fri, 02 Mar 2018 19:46:46 GMT):
Are the SDK tests files located at https://github.com/hyperledger/indy-sdk/tree/master/wrappers/python/tests included anywhere in the Vagrant libindy instanced? I can only find the wrapper's main codes.

the_identity_guy (Fri, 02 Mar 2018 19:57:26 GMT):
is the new Python SDK DID.py file included in the deb packages that are pulled by apt-get ?

gudkov (Fri, 02 Mar 2018 21:32:14 GMT):
> is the new Python SDK DID.py file included in the deb packages that are pulled by apt-get ? We don't have deb package for python wrapper. Only PyPi package https://pypi.python.org/pypi/python3-indy/1.3.1-dev-406

gudkov (Fri, 02 Mar 2018 21:33:54 GMT):
> Are the SDK tests files located at https://github.com/hyperledger/indy-sdk/tree/master/wrappers/python/tests included anywhere in the Vagrant libindy instanced? I can only find the wrapper's main codes. What exact images you mean? We don'y have official images for indy sdk as i know.

the_identity_guy (Fri, 02 Mar 2018 22:06:09 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=fRCFwgtMjscCnPixB) @gudkov I noticed the did.py file is not included in the libindy Vagrant instances.. other Python wrapper related files are there

the_identity_guy (Fri, 02 Mar 2018 22:07:25 GMT):
I'm referring to the Vagrant instances created by the Vagrant file here: https://github.com/hyperledger/indy-node/tree/master/environment/vagrant/training/vb-multi-vm

gudkov (Fri, 02 Mar 2018 22:08:59 GMT):
It is Indy Node images. Check in indy-node channel. Not sure that they contain any Indy SDK artifacts at all.

the_identity_guy (Fri, 02 Mar 2018 22:11:06 GMT):
ok to rephrase the above issue.. one of the Vagrant instance is called Libindy which contains the Python wrapper files.. which is convenient because its easy to write python apps using the python wrapper, however I noticed the the wrapper is missing the did.py file and the test folder that you see on the github folder of the python wrapper: https://github.com/hyperledger/indy-sdk/tree/master/wrappers/python

the_identity_guy (Fri, 02 Mar 2018 22:11:40 GMT):
ok I will ask Indy-node channel about this

gudkov (Fri, 02 Mar 2018 22:12:58 GMT):
Not sure that it is easiest way to start application development with libindy. It seems like a testing environment for Indy Node developers.

gudkov (Fri, 02 Mar 2018 22:13:24 GMT):
did.py is only present in master release channel of libindy

gudkov (Fri, 02 Mar 2018 22:16:01 GMT):
For development with libindy it is much easier to install libindy locally with apt-get + install python3-indy with pypi. Instance of indy pool you can get with simple docker config placed in https://github.com/hyperledger/indy-sdk/blob/master/ci/indy-pool.dockerfile

Sakurann (Mon, 05 Mar 2018 04:44:26 GMT):
Has joined the channel.

lcinacio (Mon, 05 Mar 2018 10:32:44 GMT):
Hi everyone! I just started checking Indy, and while running indy-sdk/samples/python/src/getting_started.py I am getting errors inside the onboarding function when calling did.key_for did. It seems that did.key_for_did only works if I pass the same wallet used for creating the did with did.create_and_store_my_did. Is this a bug?

hidde-jan (Mon, 05 Mar 2018 14:26:21 GMT):
create_and_store_my_did only stores the DID in your own wallet (if I recall correctly) and doesn't publish it to the ledger. Calling key_for_did with another wallet will first look for a localized copy of the key of that did (which a different wallet will not have) and will then try to fetch it from the ledger (where it doesn't exist, because it was never pushed) which will result in an error

lcinacio (Mon, 05 Mar 2018 15:35:44 GMT):
@hidde-jan There is a call to send_nym(pool_handle, from_wallet, from_did, from_to_did, from_to_key, None) between create_and_store_my_did and key_for_did, but it still can't find the key unless I pass the same wallet that was used in create and send_nym

hidde-jan (Mon, 05 Mar 2018 15:36:56 GMT):
might need to wait some time between the send_nym and key_for_did call, did you try that?

lcinacio (Mon, 05 Mar 2018 15:40:30 GMT):
no... I will try it

lcinacio (Mon, 05 Mar 2018 15:55:24 GMT):
I added time.sleep(60) after send_nym, but still get the error when calling key_for_did. Should I wait longer?

mspatel (Mon, 05 Mar 2018 16:02:39 GMT):
Has joined the channel.

AxelNennker (Mon, 05 Mar 2018 16:43:49 GMT):
HI again. I have built libindy on ubuntu 16.04 (https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md) and when running the tests I get this "---- ledger_demo_works stdout ---- thread 'ledger_demo_works' panicked at 'called `Result::unwrap()` on an `Err` value: Timeout', /checkout/src/libcore/result.rs:916:5 note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace at /checkout/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49 1: std::sys_common::backtrace::print at /checkout/src/libstd/sys_common/backtrace.rs:68 at /checkout/src/libstd/sys_common/backtrace.rs:57 2: std::panicking::default_hook::{{closure}} at /checkout/src/libstd/panicking.rs:381 3: std::panicking::default_hook at /checkout/src/libstd/panicking.rs:391 4: std::panicking::rust_panic_with_hook at /checkout/src/libstd/panicking.rs:577 5: std::panicking::begin_panic at /checkout/src/libstd/panicking.rs:538 6: std::panicking::begin_panic_fmt at /checkout/src/libstd/panicking.rs:522 7: rust_begin_unwind at /checkout/src/libstd/panicking.rs:498 8: core::panicking::panic_fmt at /checkout/src/libcore/panicking.rs:71 9: core::result::unwrap_failed at /checkout/src/libcore/macros.rs:23 10: >::unwrap at /checkout/src/libcore/result.rs:782 11: demo::ledger_demo_works at tests/demo.rs:324 12: >::call_box at /checkout/src/libtest/lib.rs:1449 at /checkout/src/libcore/ops/function.rs:223 at /checkout/src/liballoc/boxed.rs:815 13: __rust_maybe_catch_panic at /checkout/src/libpanic_unwind/lib.rs:101 failures: ledger_demo_works test result: FAILED. 10 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out "

gudkov (Mon, 05 Mar 2018 16:51:32 GMT):
@AxelNennker Do you have compatible indy pool available? This test tries to connect indy pool and fails with a timeout.

gudkov (Mon, 05 Mar 2018 16:54:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JS6kbASuprwTTrrHg) @lcinacio Are you sure you have compatible local indy pool available?

AxelNennker (Mon, 05 Mar 2018 16:58:53 GMT):
@gudkov I followed the guide ubuntu-build.md which guided me to start the pool using "docker run -itd -p 9701-9708:9701-9708 indy_pool".

AxelNennker (Mon, 05 Mar 2018 17:04:46 GMT):
@gudkov when I run docker run -itd -p 9701-9708:9701-9708 indy_pool again it fails with ADDRESS already in use. Although I don't see any 10.0.0.0/8 addresses using netstat. ifconfig shows br-839bfb514f86 interface with 10.0.0.1 as ip-address.

AxelNennker (Mon, 05 Mar 2018 17:12:29 GMT):
@gudkov Sorry - I am stupid. I forgot the TEST_POOL_IP=10.0.0.2

sklump (Mon, 05 Mar 2018 19:35:40 GMT):
Thanks for the cautionary tale - I've forgotten it too, and watched the screen, slack-jawed.

ianco (Mon, 05 Mar 2018 20:53:41 GMT):
@AxelNennker did you get this working? I'm getting the same error today in tests/demo.rs, but at line 450 (not line 324 like you got)

ianco (Mon, 05 Mar 2018 20:55:13 GMT):
@gudkov did anything change recently in indy-node that might affect this? I'm running the test node as in https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md step 4, but started getting ledger errors today

ianco (Mon, 05 Mar 2018 21:10:02 GMT):
@AxelNennker @gudkov never mind I got everything working, major brainfart today :-(

sklump (Tue, 06 Mar 2018 15:37:21 GMT):
I see that claim_offer now takes a `nonce` (easy) and a `key_correctness_proof` (hard). What key's correctness is it proving? How do I generate it? Help? Thanks.

sklump (Tue, 06 Mar 2018 15:37:21 GMT):
I see that somewhere between 1.3.1-dev-371 and 1.3.1-dev-408, `claim_offer` now takes a `nonce` (easy) and a `key_correctness_proof` (hard). What key's correctness is it proving? How do I generate it? Help? Thanks.

sklump (Tue, 06 Mar 2018 15:37:21 GMT):
I see that somewhere between 1.3.1-dev-371 and 1.3.1-dev-408, `claim_offer` picked up a `nonce` (easy) and a `key_correctness_proof` (hard). What key's correctness is it proving? How do I generate it? Help? Thanks.

sklump (Tue, 06 Mar 2018 15:41:37 GMT):
... I see also that there is also a new `anoncreds` function, `issuer_create_claim_offer()`. I am going to see if its output suffices, it probably does. I'll keep these comments here to show the breadcrumbs, but I imagine it will work OK.

sklump (Tue, 06 Mar 2018 15:41:37 GMT):
... I see also that there is also a new `anoncreds` function, `issuer_create_claim_offer()`. I am going to see if its output suffices; it probably does. I'll keep these comments here to show the breadcrumbs for fellow travellers, but I imagine it will work OK.

benjsmi (Tue, 06 Mar 2018 16:33:26 GMT):
Has joined the channel.

benjsmi (Tue, 06 Mar 2018 16:33:37 GMT):
anybody know why i'm receiving a `tob-api_1 | ERROR|indy::errors::indy | src/errors/indy.rs:63 | Casting error to ErrorCode: Dupplicated master secret: Master Secret already exists secret`

benjsmi (Tue, 06 Mar 2018 16:33:38 GMT):
?

benjsmi (Tue, 06 Mar 2018 16:34:15 GMT):
also curious how important it is to use `rustup` as opposed to just installing rust as an ubuntu package as far as operating the indy-sdk

sklump (Tue, 06 Mar 2018 18:13:28 GMT):
item: python wrapper for anoncreds.py line 125, ``` if not hasattr(issuer_create_claim, "cb") ``` should be ``` if not hasattr(issuer_create_claim_offer, "cb") ``` Doesn't appear to hurt anything for now.

olegwb (Wed, 07 Mar 2018 09:01:52 GMT):
Has joined the channel.

sergey.minaev (Wed, 07 Mar 2018 09:08:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=yNqrgH2aPmxSnvaoe) @sklump Anoncreds workflow was changed. Now Issuer and Prover exchange nonce and correctness proof for most of substeps. Please check the demo test. @Artemkaaas Did we update anoncreds workflow diagram?

sergey.minaev (Wed, 07 Mar 2018 09:10:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=s5QB7tjxLoBjs4WRz) @benjsmi Sounds like you try to create master secrete with same name twice or more

sergey.minaev (Wed, 07 Mar 2018 09:15:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=tCeZS6QcyQicJa8KX) @benjsmi We never try to use rust ubuntu16.04 package. If it is enough relevant (for example currently our CI/CD use Rust 1.21.0) - it may be better to use native way of package distribution (apt instead downloaded script from Rust language website)

sergey.minaev (Wed, 07 Mar 2018 09:24:14 GMT):
@benjsmi As I can see, cargo package install rustc v1.21.0 for ubuntu16.04 now. It's ok for current moment for our project, but actually rust 1.24.0 already available. So my current vision (after brief overview): 1) we will use rustup as recommended way to install Rust on ubuntu while active development of libindy is in progress 2) most probably we will freeze version of Rust to appropriate from ubuntu package in the future 3) if you want you can use APT way to obtain Rust, especially at the concrete moment when versions of the language are same.

creatornader (Wed, 07 Mar 2018 23:00:14 GMT):
Has joined the channel.

pimotte (Thu, 08 Mar 2018 08:20:18 GMT):
When Did.storeTheirDid is called with just a did, a call to keyForDid with this particular did results in the did, rather than the key. This seems like a bug. If you agree it's a bug, where should I report it? If not, why is this the behaviour?

lcinacio (Thu, 08 Mar 2018 11:01:39 GMT):
@AxelNennker @gudkov I noticed that the call to send_nym shows in the of nodes' console that the message is discarded because of InsufficientCorrectSignatures(0, 1). What is missing? The call is: await send_nym(pool_handle, from_wallet, from_did, from_to_did, from_to_key, None)

pimotte (Thu, 08 Mar 2018 11:23:23 GMT):
@lcinacio I'm not entirely sure, but this might help: What role does the "from_did" have? If it's not a trust anchor, that could be a reason it's failing.

lcinacio (Thu, 08 Mar 2018 12:48:08 GMT):
the from_did was created by create_and_store_my_did passing {'seed': '000000000000000000000000Steward1'} as 2nd parameter. I this this did is a TRUST_ANCHOR.

pimotte (Thu, 08 Mar 2018 12:49:01 GMT):
And are you calling it with the right keys? What also might help is setting RUST_LOG=info in your environment, then you can see the sdk logging.

akhihaki (Thu, 08 Mar 2018 14:35:15 GMT):
Hello, i am trying to test the revocation capabilities using indy, libindy version: libindy_1.3.1~408_amd64.deb steps i am following are 1) Create a claim schema and send it to ledger 2) Create a claim def using anoncreds module using above created schema and register it also on ledger. ``` await anoncreds.issuer_create_and_store_claim_def(WALLET_HANDLE, issuing_did, json.dumps(schema), 'CL', False) ``` 3) Now when i am trying to create and store revoc reg using ``` await anoncreds.issuer_create_and_store_revoc_reg(WALLET_HANDLE, issuing_did, json.dumps(schema), 100) ``` i am getting `ErrorCode.CommonInvalidStructure` Can someone please help me or point me to any resource where i can understand how revocation is done using Indy. Thanks

akhihaki (Thu, 08 Mar 2018 14:35:15 GMT):
Hello, i am trying to test the revocation capabilities using indy, libindy version: libindy_1.3.1~408_amd64.deb steps i am following are 1) Create a claim schema and send it to ledger 2) Create a claim def using anoncreds module using above created schema and register it also on ledger. ``` await anoncreds.issuer_create_and_store_claim_def(WALLET_HANDLE,ssuing_did,json.dumps(schema),'CL', False) ``` 3) Now when i am trying to create and store revoc reg using ``` await anoncreds.issuer_create_and_store_revoc_reg(WALLET_HANDLE,issuing_did, json.dumps(schema),100) ``` i am getting `ErrorCode.CommonInvalidStructure` Can someone please help me or point me to any resource where i can understand how revocation is done using Indy. Thanks

akhihaki (Thu, 08 Mar 2018 14:35:15 GMT):
Hello, i am trying to test the revocation capabilities using indy, libindy version: libindy_1.3.1~408_amd64.deb steps i am following are 1) Create a claim schema and send it to ledger 2) Create a claim def using anoncreds module using above created schema and register it also on ledger. ```await anoncreds.issuer_create_and_store_claim_def(WALLET_HANDLE,ssuing_did,json.dumps(schema),'CL', False) ``` 3) Now when i am trying to create and store revoc reg using ```await anoncreds.issuer_create_and_store_revoc_reg(WALLET_HANDLE,issuing_did, json.dumps(schema),100) ``` i am getting `ErrorCode.CommonInvalidStructure` Can someone please help me or point me to any resource where i can understand how revocation is done using Indy. Thanks

gudkov (Thu, 08 Mar 2018 14:56:15 GMT):
> When Did.storeTheirDid is called with just a did, a call to keyForDid with this particular did results in the did, rather than the key. This seems like a bug. If you agree it's a bug, where should I report it? If not, why is this the behaviour? It seems like a bug

gudkov (Thu, 08 Mar 2018 14:57:39 GMT):
Right place is our jira https://jira.hyperledger.org/projects/IS/issues/IS-575?filter=allopenissues

gudkov (Thu, 08 Mar 2018 15:36:57 GMT):
@akhihaki Revocation is under active development. I suggest to postpone your testing for one week. I will share design, also you can look to Anoncreds paper in indy-crypto repo that describes revocation math.

akhihaki (Thu, 08 Mar 2018 15:37:39 GMT):
Sure @gudkov thanks for the info.

malvikam (Thu, 08 Mar 2018 20:27:58 GMT):
Is there any documentation for "config" and "credentials" parameters in indy_create_wallet() API?

lovesh (Thu, 08 Mar 2018 20:31:05 GMT):
Has joined the channel.

gudkov (Thu, 08 Mar 2018 20:33:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=PSaGbw39dEoKSoEKi) @malvikam https://github.com/hyperledger/indy-sdk/blob/master/doc/default-wallet.md

malvikam (Thu, 08 Mar 2018 20:38:00 GMT):
@gudkov thanks! Any documentation about "config" parameter?

gudkov (Thu, 08 Mar 2018 20:42:32 GMT):
Default wallet doesn't have any configuration

malvikam (Thu, 08 Mar 2018 20:43:37 GMT):
Is there an API to import externally created key-pair into a wallet?

gudkov (Thu, 08 Mar 2018 20:45:02 GMT):
You can only use seeds for deterministic keys creation

malvikam (Thu, 08 Mar 2018 20:48:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=PveWoqd9h2e2AN5pw) @gudkov Thanks!

malvikam (Thu, 08 Mar 2018 20:56:59 GMT):
One more question - is this the correct genesis file to connect to the STN network in order to start issuing NYM transactions? https://github.com/sovrin-foundation/sovrin/blob/master/sovrin/domain_transactions_sandbox_genesis

gudkov (Thu, 08 Mar 2018 21:42:50 GMT):
Most probably yes, but i suggest to re-check in indy-node channel. Indy isn't directly related to Sovrin and i am not completely aware about Sovrin infrastructure details.

tobowers (Fri, 09 Mar 2018 07:31:34 GMT):
Has joined the channel.

tobowers (Fri, 09 Mar 2018 07:33:11 GMT):
Hi, I thought I'd follow up here with my question on verify. I'm in the process of wrapping the libindy-crypto rust library t Go (BLS to start). I figured out my problem and my tests are now passing, but while I was doing the wrapping there was a point where I would have been passing in bad bytes everywhere (generator, sign key, secret key, signature)... however I was getting a success error code and a True for verified (in rust). My email to the hyperledger-indy mailing list has the TRACE output from rust with all the inputs in it.

pimotte (Fri, 09 Mar 2018 07:39:28 GMT):
@tobowers I have been told https://jira.hyperledger.org/projects/IS/issues/IS-575?filter=allopenissues is the place to be for bug reports

tobowers (Fri, 09 Mar 2018 07:40:23 GMT):
ok thanks. I just wanted to see if it was actually a bug first, but I'll file

pimotte (Fri, 09 Mar 2018 07:41:59 GMT):
I'm not familiar enough with the project to see if it is a bug, but it does sound pretty bad

tobowers (Fri, 09 Mar 2018 07:42:22 GMT):
yeah ok, I'll file

tobowers (Fri, 09 Mar 2018 07:43:30 GMT):
oh, hmm - looks like you have to be a member and it doesn't have open access

tobowers (Fri, 09 Mar 2018 07:43:53 GMT):
oh i see - linux foundation

sklump (Fri, 09 Mar 2018 12:33:20 GMT):
In `ledger`, call `indy_build_nym_request()` appears to ignore any `alias` parameter. Could this go into a future release when convenient? It should work as easily as 'role'.

sklump (Fri, 09 Mar 2018 19:46:00 GMT):
In particular, (python) ``` req_json = await ledger.build_nym_request( 'V4SGRU86Z58d6TV7PBUe6f', 'V4SGRU86Z58d6TV7PBUe6f', 'DaFjAdwTwUN2Wq755Ei6XiFYLK5haL13cRLf5PrJYoK3', 'my-alias', None) await ledger.sign_and_submit_request( 1, 2, 'V4SGRU86Z58d6TV7PBUe6f', req_json) ``` yields nym data from the ledger of ``` { "txnTime": 1520624344, "identifier": "V4SGRU86Z58d6TV7PBUe6f", "dest": "Q4zqM7aXqm7gDQkUVLng9h", "role": null, "verkey": "DaFjAdwTwUN2Wq755Ei6XiFYLK5haL13cRLf5PrJYoK3", "seqNo": 18 } ``` Perhaps the alias may reside somewhere else?

gudkov (Fri, 09 Mar 2018 20:37:44 GMT):
build_nym_request fields alias field of NYM request. I am not sure that it should be returned as answer to NYM request by ledger. Also i suggest to send GET_NYM and look for result.

arjanvaneersel (Sat, 10 Mar 2018 12:15:31 GMT):
I'm looking at the indy_create_wallet in indy_wallet.h, there I notice that the first argument is indy_handle_t command_handle. Also the callback function has an argument indy_handle_t xcommand_handle. I wonder if these are the same values. In the Python SDK the value of command_handle is created with an iterator. So if command_handle is returned as xcommand_handle in the callback, then that would definitely solve some a problem I'm facing with writing a Go wrapper.

laoqui (Sat, 10 Mar 2018 19:13:16 GMT):
Has joined the channel.

tomislav (Sun, 11 Mar 2018 14:06:23 GMT):
Has joined the channel.

tomislav (Sun, 11 Mar 2018 14:56:46 GMT):
Hello. I'm trying to run the test project for the dotnet SDK under macOS. Where do I copy the library and header files for it to be visible to the dotnet runtime? I copied the libindy.a in /usr/local/lib and indy_*.h in /usr/local/include. Any other steps I need to take?

tomislav (Sun, 11 Mar 2018 14:59:05 GMT):
I downloaded the Macos binaries, but I was also able to build locally with cargo

tomislav (Sun, 11 Mar 2018 15:09:46 GMT):
it seems copying living.dylib in /usr/local/lib fixed the problem. Tests run, 1 fail

tomislav (Sun, 11 Mar 2018 15:09:46 GMT):
it seems copying libindy.dylib in /usr/local/lib fixed the problem. Tests run, 1 fail

laoqui (Sun, 11 Mar 2018 23:44:30 GMT):
i'm following the python getting started guide (https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md) but i am hitting this error: ``` >>> pool_handle = await pool.open_pool_ledger(pool_name, None) INFO|indy::commands | src/commands/mod.rs:99 | PoolCommand command received ERROR|indy::services::pool | src/services/pool/mod.rs:426 | Pool worker thread finished with error CommonError(InvalidState("MerkleTree contains invalid data Syntax(\"missing field `alias`\")")) INFO|indy::commands | src/commands/mod.rs:99 | PoolCommand command received INFO|indy::commands::pool | src/commands/pool.rs:68 | OpenAck handle 5, pool_id 6, result Err(CommonError(InvalidState("MerkleTree contains invalid data Syntax(\"missing field `alias`\")"))) ERROR|indy::errors::indy | src/errors/indy.rs:68 | Casting error to ErrorCode: Invalid library state: MerkleTree contains invalid data Syntax("missing field `alias`") _indy_loop_callback: Function returned error 112 Traceback (most recent call last): File "/Users/laoqui/.virtualenvs/indy-sdk/lib/python3.6/site-packages/aioconsole/execute.py", line 95, in aexec result, new_local = yield from coro File "", line 2, in __corofn File "/Users/laoqui/Projects/hyperledger/indy-sdk/wrappers/python/indy/pool.py", line 82, in open_pool_ledger open_pool_ledger.cb) indy.error.IndyError: ErrorCode.CommonInvalidState ``` i've created a `genesis.json` file based on https://github.com/hyperledger/indy-sdk/blob/master/samples/python/src/utils.py#L13-L25 but just changed the IP to point to a remote indy network. what could be the problem?

laoqui (Sun, 11 Mar 2018 23:55:42 GMT):
i also tried running the sample directly and setting the value of `TEST_POOL_IP`, but i get this error ``` TRACE|indy::services::pool | src/services/pool/mod.rs:348 | get_zmq_poll_timeout first_event Tm { tm_sec: 54, tm_min: 54, tm_hour: 23, tm_mday: 11, tm_mon: 2, tm_year: 118, tm_wday: 0, tm_yday: 69, tm_isdst: 0, tm_utcoff: 0, tm_nsec: 251310000 } TRACE|indy::services::pool | src/services/pool/mod.rs:349 | get_zmq_poll_timeout now_utc Tm { tm_sec: 5, tm_min: 54, tm_hour: 23, tm_mday: 11, tm_mon: 2, tm_year: 118, tm_wday: 0, tm_yday: 69, tm_isdst: 0, tm_utcoff: 0, tm_nsec: 572045000 } TRACE|indy::services::pool | src/services/pool/mod.rs:351 | get_zmq_poll_timeout diff Duration Duration { secs: 48, nanos: 679265000 } TRACE|indy::services::pool | src/services/pool/mod.rs:353 | get_zmq_poll_timeout diff ms 48679 TRACE|indy::services::pool | src/services/pool/mod.rs:293 | zmq poll 2 INFO|indy::services::pool | src/services/pool/mod.rs:538 | RemoteNode::recv_msg Node2 {"ppSeqNo":null,"op":"LEDGER_STATUS","merkleRoot":"FTH83QNd84mnaXFD8vQdRHbRmmkZqz22pbHFjzy9mYt1","ledgerId":0,"txnSeqNo":4,"viewNo":null} INFO|indy::services::pool | src/services/pool/mod.rs:538 | RemoteNode::recv_msg Node3 {"txnSeqNo":4,"ledgerId":0,"op":"LEDGER_STATUS","ppSeqNo":null,"merkleRoot":"FTH83QNd84mnaXFD8vQdRHbRmmkZqz22pbHFjzy9mYt1","viewNo":null} TRACE|indy::services::pool | src/services/pool/mod.rs:244 | process_actions - Invalid library state: Ledger merkle tree doesn't acceptable for current tree. ERROR|indy::services::pool | src/services/pool/mod.rs:426 | Pool worker thread finished with error CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree.")) INFO|indy::commands | src/commands/mod.rs:99 | PoolCommand command received INFO|indy::commands::pool | src/commands/pool.rs:68 | OpenAck handle 4, pool_id 5, result Err(CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree."))) ERROR|indy::errors::indy | src/errors/indy.rs:68 | Casting error to ErrorCode: Invalid library state: Ledger merkle tree doesn't acceptable for current tree. WARNING:indy.libindy:_indy_loop_callback: Function returned error 112 Traceback (most recent call last): File "./src/main.py", line 15, in loop.run_until_complete(main()) File "/Users/laoqui/.pyenv/versions/3.6.2/lib/python3.6/asyncio/base_events.py", line 467, in run_until_complete return future.result() File "./src/main.py", line 10, in main await ledger.demo() File "/Users/laoqui/Projects/hyperledger/indy-sdk/samples/python/src/ledger.py", line 24, in demo pool_handle = await pool.open_pool_ledger(pool_name, None) File "/Users/laoqui/.virtualenvs/indy-sdk/lib/python3.6/site-packages/indy/pool.py", line 82, in open_pool_ledger open_pool_ledger.cb) indy.error.IndyError: ErrorCode.CommonInvalidState ```

laoqui (Sun, 11 Mar 2018 23:55:42 GMT):
i also tried running the sample directly and setting the value of `TEST_POOL_IP`, but i get this error ``` ... TRACE|indy::services::pool | src/services/pool/mod.rs:348 | get_zmq_poll_timeout first_event Tm { tm_sec: 54, tm_min: 54, tm_hour: 23, tm_mday: 11, tm_mon: 2, tm_year: 118, tm_wday: 0, tm_yday: 69, tm_isdst: 0, tm_utcoff: 0, tm_nsec: 251310000 } TRACE|indy::services::pool | src/services/pool/mod.rs:349 | get_zmq_poll_timeout now_utc Tm { tm_sec: 5, tm_min: 54, tm_hour: 23, tm_mday: 11, tm_mon: 2, tm_year: 118, tm_wday: 0, tm_yday: 69, tm_isdst: 0, tm_utcoff: 0, tm_nsec: 572045000 } TRACE|indy::services::pool | src/services/pool/mod.rs:351 | get_zmq_poll_timeout diff Duration Duration { secs: 48, nanos: 679265000 } TRACE|indy::services::pool | src/services/pool/mod.rs:353 | get_zmq_poll_timeout diff ms 48679 TRACE|indy::services::pool | src/services/pool/mod.rs:293 | zmq poll 2 INFO|indy::services::pool | src/services/pool/mod.rs:538 | RemoteNode::recv_msg Node2 {"ppSeqNo":null,"op":"LEDGER_STATUS","merkleRoot":"FTH83QNd84mnaXFD8vQdRHbRmmkZqz22pbHFjzy9mYt1","ledgerId":0,"txnSeqNo":4,"viewNo":null} INFO|indy::services::pool | src/services/pool/mod.rs:538 | RemoteNode::recv_msg Node3 {"txnSeqNo":4,"ledgerId":0,"op":"LEDGER_STATUS","ppSeqNo":null,"merkleRoot":"FTH83QNd84mnaXFD8vQdRHbRmmkZqz22pbHFjzy9mYt1","viewNo":null} TRACE|indy::services::pool | src/services/pool/mod.rs:244 | process_actions - Invalid library state: Ledger merkle tree doesn't acceptable for current tree. ERROR|indy::services::pool | src/services/pool/mod.rs:426 | Pool worker thread finished with error CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree.")) INFO|indy::commands | src/commands/mod.rs:99 | PoolCommand command received INFO|indy::commands::pool | src/commands/pool.rs:68 | OpenAck handle 4, pool_id 5, result Err(CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree."))) ERROR|indy::errors::indy | src/errors/indy.rs:68 | Casting error to ErrorCode: Invalid library state: Ledger merkle tree doesn't acceptable for current tree. WARNING:indy.libindy:_indy_loop_callback: Function returned error 112 Traceback (most recent call last): File "./src/main.py", line 15, in loop.run_until_complete(main()) File "/Users/laoqui/.pyenv/versions/3.6.2/lib/python3.6/asyncio/base_events.py", line 467, in run_until_complete return future.result() File "./src/main.py", line 10, in main await ledger.demo() File "/Users/laoqui/Projects/hyperledger/indy-sdk/samples/python/src/ledger.py", line 24, in demo pool_handle = await pool.open_pool_ledger(pool_name, None) File "/Users/laoqui/.virtualenvs/indy-sdk/lib/python3.6/site-packages/indy/pool.py", line 82, in open_pool_ledger open_pool_ledger.cb) indy.error.IndyError: ErrorCode.CommonInvalidState ```

sergey.minaev (Mon, 12 Mar 2018 09:30:02 GMT):
@laoqui > just changed the IP to point to a remote indy network It is a problem. Genesis transactions must be same on pool (all nodes) and client (sdk)

sergey.minaev (Mon, 12 Mar 2018 09:32:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=g79QmDQ676npBybHe) @the_identity_guy SDK can't connect to pool nodes. Please check your pool settings, network(s) configuration(s) and genesis transactions

sklump (Mon, 12 Mar 2018 10:48:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kL7zwnFMCXiu6wKto) @gudkov Yes: ``` get_nym_req = await ledger.build_get_nym_request(did, did) resp_json = await ledger.submit_request(pool_handle, get_nym_req) ``` against the python wrapper shows the ledger data above; i.e.,

sklump (Mon, 12 Mar 2018 10:48:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kL7zwnFMCXiu6wKto) @gudkov Yes: ``` get_nym_req = await ledger.build_get_nym_request( 'V4SGRU86Z58d6TV7PBUe6f', 'V4SGRU86Z58d6TV7PBUe6f') resp_json = await ledger.submit_request(1, get_nym_req) ``` against the python wrapper shows the ledger data above; i.e., ``` { "txnTime": 1520624344, "identifier": "V4SGRU86Z58d6TV7PBUe6f", "dest": "Q4zqM7aXqm7gDQkUVLng9h", "role": null, "verkey": "DaFjAdwTwUN2Wq755Ei6XiFYLK5haL13cRLf5PrJYoK3", "seqNo": 18 } ``` with no alias. Is the alias perhaps a low-priority feature on hold? Or maybe I've misunderstood its intended use?

p6g (Mon, 12 Mar 2018 12:31:27 GMT):
Has joined the channel.

sayan.hlf (Mon, 12 Mar 2018 14:06:52 GMT):
Has left the channel.

the_identity_guy (Mon, 12 Mar 2018 16:18:31 GMT):
@sergey.minaev I have updated the IP addresses of the genesis transaction, and it looks just like the other ones used.. I have also checked the etc/hosts file and to make sure all 4 validators are there.. I am also able to successfully ping the validator from the libindy VM. I am using the Vagrant/VM for each node and the libindy box.. should I use a specific 'pool' name or that is not relevant. my pool config is only: ``` {"genesis_txn":"/tmp/indy/pool1.txn"} ``` and my genesis transactions are: ``` {"data":{"alias":"Node1","blskey":"4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba","client_ip":"127.0.0.1","client_port":9702,"node_ip":"127.0.0.1","node_port":9701,"services":["VALIDATOR"]},"dest":"Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv","identifier":"Th7MpTaRZVRYnPiabds81Y","txnId":"fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62","type":"0"} {"data":{"alias":"Node2","blskey":"37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk","client_ip":"127.0.0.1","client_port":9704,"node_ip":"127.0.0.1","node_port":9703,"services":["VALIDATOR"]},"dest":"8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb","identifier":"EbP4aYNeTHL6q385GuVpRV","txnId":"1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc","type":"0"} {"data":{"alias":"Node3","blskey":"3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5","client_ip":"127.0.0.1","client_port":9706,"node_ip":"127.0.0.1","node_port":9705,"services":["VALIDATOR"]},"dest":"DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya","identifier":"4cU41vWW82ArfxJxHkzXPG","txnId":"7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4","type":"0"} {"data":{"alias":"Node4","blskey":"2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw","client_ip":"127.0.0.1","client_port":9708,"node_ip":"127.0.0.1","node_port":9707,"services":["VALIDATOR"]},"dest":"4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA","identifier":"TWwCRQRZ2ZHMJFn9TzLp7W","txnId":"aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008","type":"0" ```

the_identity_guy (Mon, 12 Mar 2018 16:18:31 GMT):
@sergey.minaev I have updated the IP addresses of the genesis transaction, and it looks just like the other ones used.. I have also checked the etc/hosts file and to make sure all 4 validators are there.. I am also able to successfully ping the validator from the libindy VM. I am using the Vagrant/VM for each node and the libindy box.. should I use a specific 'pool' name or that is not relevant. my pool config is only: ``` {"genesis_txn":"/tmp/indy/pool1.txn"} and my genesis transactions are: {"data":{"alias":"Node1","blskey":"4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba","client_ip":"127.0.0.1","client_port":9702,"node_ip":"127.0.0.1","node_port":9701,"services":["VALIDATOR"]},"dest":"Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv","identifier":"Th7MpTaRZVRYnPiabds81Y","txnId":"fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62","type":"0"} {"data":{"alias":"Node2","blskey":"37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk","client_ip":"127.0.0.1","client_port":9704,"node_ip":"127.0.0.1","node_port":9703,"services":["VALIDATOR"]},"dest":"8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb","identifier":"EbP4aYNeTHL6q385GuVpRV","txnId":"1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc","type":"0"} {"data":{"alias":"Node3","blskey":"3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5","client_ip":"127.0.0.1","client_port":9706,"node_ip":"127.0.0.1","node_port":9705,"services":["VALIDATOR"]},"dest":"DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya","identifier":"4cU41vWW82ArfxJxHkzXPG","txnId":"7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4","type":"0"} {"data":{"alias":"Node4","blskey":"2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw","client_ip":"127.0.0.1","client_port":9708,"node_ip":"127.0.0.1","node_port":9707,"services":["VALIDATOR"]},"dest":"4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA","identifier":"TWwCRQRZ2ZHMJFn9TzLp7W","txnId":"aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008","type":"0" ```

the_identity_guy (Mon, 12 Mar 2018 16:18:31 GMT):
@sergey.minaev I have updated the IP addresses within genesis transactions. The genesis tnxs look just like the other ones used in examples.. I have also checked the etc/hosts file and to make sure all 4 validators are there.. I am also able to successfully ping the validator from the libindy VM. I am using the Vagrant/VM for each node and the libindy instance.. should I use a specific 'pool' name or that's not relevant?. my pool config is only: ``` {"genesis_txn":"/tmp/indy/pool1.txn"} and my genesis transactions are: {"data":{"alias":"Node1","blskey":"4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba","client_ip":"127.0.0.1","client_port":9702,"node_ip":"127.0.0.1","node_port":9701,"services":["VALIDATOR"]},"dest":"Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv","identifier":"Th7MpTaRZVRYnPiabds81Y","txnId":"fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62","type":"0"} {"data":{"alias":"Node2","blskey":"37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk","client_ip":"127.0.0.1","client_port":9704,"node_ip":"127.0.0.1","node_port":9703,"services":["VALIDATOR"]},"dest":"8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb","identifier":"EbP4aYNeTHL6q385GuVpRV","txnId":"1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc","type":"0"} {"data":{"alias":"Node3","blskey":"3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5","client_ip":"127.0.0.1","client_port":9706,"node_ip":"127.0.0.1","node_port":9705,"services":["VALIDATOR"]},"dest":"DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya","identifier":"4cU41vWW82ArfxJxHkzXPG","txnId":"7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4","type":"0"} {"data":{"alias":"Node4","blskey":"2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw","client_ip":"127.0.0.1","client_port":9708,"node_ip":"127.0.0.1","node_port":9707,"services":["VALIDATOR"]},"dest":"4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA","identifier":"TWwCRQRZ2ZHMJFn9TzLp7W","txnId":"aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008","type":"0" ```

the_identity_guy (Mon, 12 Mar 2018 16:18:31 GMT):
@sergey.minaev I have updated the IP addresses within genesis transactions. The genesis tnxs look just like the other ones used in examples.. I have also checked the etc/hosts file and to make sure all 4 validators are there.. I am also able to successfully ping the validator from the libindy VM. I am using the Vagrant/VM for each node and the libindy instance.. should I use a specific 'pool' name or that's not relevant?. my pool config is only: ``` {"genesis_txn":"/tmp/indy/pool1.txn"} and my genesis transactions are: @staticmethod def pool_genesis_txn_data(): pool_ip = environ.get("TEST_POOL_IP", "127.0.0.1") return "\n".join([ '{{"data":{{"alias":"Node1","blskey":"4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba","client_ip":"{}","client_port":9702,"node_ip":"{}","node_port":9701,"services":["VALIDATOR"]}},"dest":"Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv","identifier":"Th7MpTaRZVRYnPiabds81Y","txnId":"fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62","type":"0"}}'.format( "10.20.30.201", "10.20.30.201"), '{{"data":{{"alias":"Node2","blskey":"37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk","client_ip":"{}","client_port":9704,"node_ip":"{}","node_port":9703,"services":["VALIDATOR"]}},"dest":"8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb","identifier":"EbP4aYNeTHL6q385GuVpRV","txnId":"1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc","type":"0"}}'.format( "10.20.30.202", "10.20.30.202"), '{{"data":{{"alias":"Node3","blskey":"3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5","client_ip":"{}","client_port":9706,"node_ip":"{}","node_port":9705,"services":["VALIDATOR"]}},"dest":"DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya","identifier":"4cU41vWW82ArfxJxHkzXPG","txnId":"7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4","type":"0"}}'.format( "10.20.30.203", "10.20.30.203"), '{{"data":{{"alias":"Node4","blskey":"2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw","client_ip":"{}","client_port":9708,"node_ip":"{}","node_port":9707,"services":["VALIDATOR"]}},"dest":"4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA","identifier":"TWwCRQRZ2ZHMJFn9TzLp7W","txnId":"aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008","type":"0"}}'.format( "10.20.30.204", "10.20.30.204") ])

tomislav (Mon, 12 Mar 2018 16:43:29 GMT):
Has left the channel.

mboyd (Mon, 12 Mar 2018 16:57:33 GMT):
hi all

gudkov (Mon, 12 Mar 2018 19:41:17 GMT):
@sklump What is your use case for aliases? If it is important for you than we can fill the bug for indy-node that there are no alias field in the result of Indy Node.

malvikam (Mon, 12 Mar 2018 23:35:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9C8xBZBjq4HxJgxqA) There is a self-service portal to add Trust Anchor to the Sovrin Test Network (STN). You have to provide DID/verkey pair that does not exist on the STN ledger. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fs3.us-east-2.amazonaws.com%2Fevernym-cs%2Fsovrin-STNnetwork%2Fwww%2Ftrust-anchor.html&data=04%7C01%7Cmalvikap%40microsoft.com%7C49a06fdded2444cf488b08d5886427f9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636564886111941825%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1&sdata=WKRNXwrdJN3ntcEDCHZS9ZBlATY8Io%2B%2BpGVeJpdOVbU%3D&reserved=0

sklump (Tue, 13 Mar 2018 11:31:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wheuQJFqFNNfc8vbe) @gudkov We would like to be able to search the ledger (by transaction on the ledger, or else once imported into a database) to find the DID that corresponds to a known nickname for an entity (e.g., Ottawa Registrar, My Claim Issuer). Once enough DIDs are floating around the system, friendly nicknames help ease of use. I admit that I myself need a cheat note once I have even 3 or 4 agents.

farskipper (Tue, 13 Mar 2018 14:31:25 GMT):
Node.js wrapper update - It’s getting really close. More tests need to be written but it’s ready if you are daring and willing to be a guinea pig. See the readme for notes on how to install and use it. https://github.com/Picolab/indy-sdk/tree/master/wrappers/nodejs#readme

AxelNennker (Tue, 13 Mar 2018 15:41:14 GMT):
Has somebody tried to build libindy for Android e.g. armv7? Related to that: It seems that indy has some dependencies e.g. on openssl which make it hard to port it to another platform. From openssl indy seems to use bignumber stuff. Isn't there a single purpose bignumber implementation in Rust and we could get rid of the openssl dependency?

laoqui (Tue, 13 Mar 2018 15:52:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=yLLDFRNxWNafAMvQX) thanks for the reply @sergey.minaev. i get that this would be the case for the genesis block. but how would i use the SDK to connect an application to a remote indy pool?

laoqui (Tue, 13 Mar 2018 15:52:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=yLLDFRNxWNafAMvQX) thanks for the reply @sergey.minaev i get that this would be the case for the genesis block. but how would i use the SDK to connect an application to a remote indy pool? just to give a concrete example: i would like to be able to create a wallet for on-boarding an user when they submit a registration form.

hawkmauk (Tue, 13 Mar 2018 16:15:09 GMT):
@farskipper thanks for the work on the wrapper, I'll look to try it out in the next couple of days

hawkmauk (Tue, 13 Mar 2018 16:15:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=v3rNXQwujugrLPQxX) @farskipper thanks for the work on the wrapper, I'll try it out soon!

sklump (Tue, 13 Mar 2018 17:10:51 GMT):
Using indy-sdk, is there any way other than `did.create_and_store_my_did(wallet_handle, did_json)` to get the DID from the seed? This method is OK but not great because we'd prefer not to write to the wallet more than necessary, overwriting an existing entry. Additionally, in the event that a wallet already has changed its verification key for a DID from the original (emerging from the seed), this call would clobber that verification key change: that's a bug in waiting.

gudkov (Tue, 13 Mar 2018 18:21:51 GMT):
@sklump I didn't catch your use case. You don't need seed to generate DID as DID is public. If you want to change the key assigned to DID there are dedicated calls for keys rotation.

sklump (Tue, 13 Mar 2018 18:28:42 GMT):
@gudkov When we start from nothing, we have only a seed. But to interact with the ledger, an actor ("agent") uses its DID, not its seed. How does one get the DID from the seed? At present, I call `did.create_and_store_my_did()` with the seed in the identity information; the method returns the DID (and verification key) after writing it to the wallet. I want to derive a DID from the seed, without having to write to the wallet.

gudkov (Tue, 13 Mar 2018 18:42:36 GMT):
Why you need to derive it? Just use the same DID.

gudkov (Tue, 13 Mar 2018 18:43:25 GMT):
seed is used for deterministic creation of secret associated with DID

gudkov (Tue, 13 Mar 2018 18:43:57 GMT):
To send transaction to the ledger you need to sign it and it is impossible to to without private key

gudkov (Tue, 13 Mar 2018 18:43:57 GMT):
To send transaction to the ledger you need to sign it and it is impossible to do without private key

gudkov (Tue, 13 Mar 2018 18:44:15 GMT):
If you need to send read trunsaction you can use any DID you want

gudkov (Tue, 13 Mar 2018 18:44:15 GMT):
If you need to send read transaction you can use any DID you want

sklump (Tue, 13 Mar 2018 18:49:10 GMT):
The agent scopes in and out, but the wallet stays resident. The agent, when it starts up from seed, needs to get the DID to use in interactions with the ledger. When the agent is starting up from an existing wallet (either its process died, or by design decision the agent is not a long-lived object), I think it's reasonable for it to be able to find its own DID. I didn't know read transactions could use any DID. Still, I've been using the correct one all these months and I'm reluctant to start making one up now. Besides, it ought to be available to the agent for logging. The DID is after all meant as an Identifier.

gudkov (Tue, 13 Mar 2018 18:51:34 GMT):
Seed - is the very private info that must be stored in the safe. Wallet is intended to store secrets.

sklump (Tue, 13 Mar 2018 18:54:13 GMT):
In particular, ``` ledger.sign_and_submit_request(pool_handle, wallet_handle, *did*, request_json) ``` needs the correct DID. If the agent has started after the wallet, how does one get ones own DID from the wallet? I acknowledge that the seed is meant to be secret.

sklump (Tue, 13 Mar 2018 18:54:13 GMT):
In particular, ``` ledger.sign_and_submit_request(pool_handle, wallet_handle, *did*, request_json) ``` needs the correct DID. If the agent has started after the wallet (i.e., the wallet exists already from a prior start), how does one get ones own DID from the wallet? I acknowledge that the seed is meant to be secret.

gudkov (Tue, 13 Mar 2018 19:33:13 GMT):
> how does one get ones own DID from the wallet? You should just store it in a some place instead of seed: 1. libindy generates DID and secrets and provides it for application. Seed is completely optional for this. You need to use it only if you want secrets relocation that isn't a good practice for the most of cases. 2. Application stores DID in some place and use it to reference DID secrets in the wallet for calls like sign_and_submit_request

gudkov (Tue, 13 Mar 2018 20:16:02 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=dihP4RNpF4kmEN26z) @laoqui Did you read getting started guide? It explains the most of indy-sdk API as part of the real use case: https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md

laoqui (Tue, 13 Mar 2018 20:31:52 GMT):
hi @gudkov yes i am following the getting started guide, but I am getting stuck in the first code block, in the line `pool_handle = await pool.open_pool_ledger(pool_name, None)`. I get this error message: ``` Pool worker thread finished with error CommonError(InvalidState("MerkleTree contains invalid data Syntax(\"missing field `alias`\")")) ```

gudkov (Tue, 13 Mar 2018 20:33:03 GMT):
Your genesis transactions are different from ledger genesis transactions.

gudkov (Tue, 13 Mar 2018 20:33:33 GMT):
Most porbable you use different ips. Something like 10.0.0.1 on ledger and 127.0.01 on client

laoqui (Tue, 13 Mar 2018 20:34:16 GMT):
is there a way to retrieve the genesis transaction?

gudkov (Tue, 13 Mar 2018 20:34:48 GMT):
Just follow instruction. What OS do you use and how you start the pool?

gudkov (Tue, 13 Mar 2018 20:35:26 GMT):
and what code you are trying to run

laoqui (Tue, 13 Mar 2018 20:35:31 GMT):
i am using Ubuntu 16.04. i started the pool using this guide https://github.com/hyperledger/indy-node/blob/master/docs/indy-running-locally.md

gudkov (Tue, 13 Mar 2018 20:36:49 GMT):
> i started the pool using this guide https://github.com/hyperledger/indy-node/blob/master/docs/indy-running-locally.md So ask in indy-node channel how to get right genests txns for this case. You can use docker file that indy-sdk provides and your life will be much easier )

gudkov (Tue, 13 Mar 2018 20:37:32 GMT):
Here you can find how to run pool on ubuntu https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md

laoqui (Tue, 13 Mar 2018 20:40:01 GMT):
cool, i will try with docker then. thanks!

ASnelgrove (Wed, 14 Mar 2018 15:11:04 GMT):
Has joined the channel.

tomislav (Wed, 14 Mar 2018 16:14:16 GMT):
Has joined the channel.

the_identity_guy (Wed, 14 Mar 2018 20:03:44 GMT):
Is the plan to have indy-sdk going to replace the entire indy_client package within indy-node at some point? Indy_client has access to all indy-node packages including all agent related code?

tomislav (Wed, 14 Mar 2018 20:23:13 GMT):
Are the wrappers updated against the latest rust code? These native agent method calls don't seem to exist anymore. https://github.com/hyperledger/indy-sdk/blob/master/wrappers/dotnet/indy-sdk-dotnet/AgentApi/NativeMethods.cs

tomislav (Wed, 14 Mar 2018 20:23:49 GMT):
I'm running into similar issue with the iOS framework as well

mboyd (Thu, 15 Mar 2018 03:35:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=8wznqx6p7G57GDh2h) @the_identity_guy yep, you're totally correct, as documented in the indy-node main readme: (https://github.com/hyperledger/indy-node#dependent-projects)

sergey.minaev (Thu, 15 Mar 2018 07:53:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5NwmLeihmTgXX2FZf) @tomislav .Net wrapper was created and supported by @srottem . Right now it may be outdated against other parts of SDK.

srottem (Thu, 15 Mar 2018 08:35:55 GMT):
I haven't done anything with the .NET wrapper this year as I'm kind of snowed under with other work. Any pointers on areas that need attention ?

tomislav (Thu, 15 Mar 2018 13:53:58 GMT):
@srottem At first glance, the AgentApi has changed, others are simply missing hooks (indy_list_wallets comes to mind) etc. I'll see if I can identify them all, perhaps submit a PR if I have time.

tomislav (Thu, 15 Mar 2018 14:32:28 GMT):
@Artemkaaas https://github.com/hyperledger/indy-sdk/blob/ba9f80032b1d51893ebdf3897f1bf730d354b83c/libindy/build-libindy-ios.sh#L29 path "debug" didn't exist with my build. Only "release"

EtienneNijboer (Thu, 15 Mar 2018 15:30:02 GMT):
Looks AnonCreds.proverGetClaims in the java wrapper is somewhat over protective. The documentation of AnonCreds (https://docs.rs/indy/0.1.1/indy/api/anoncreds/fn.indy_prover_get_claims.html) states that the if filter is NULL, all claims get returned. The parameter guard in the java wrapper seems to prohibit this.

gudkov (Thu, 15 Mar 2018 15:34:27 GMT):
@EtienneNijboer could you post a bug to don't miss this?

EtienneNijboer (Thu, 15 Mar 2018 15:55:56 GMT):
@gudkov I figured it out after going through some of the sdk code. Instead of meaning NULL for the whole filter parameter, it means that the optional filter parameters can be null (or actually be omitted). It means that a valid NULL filter is actually: "{}"

Artemkaaas (Fri, 16 Mar 2018 10:34:28 GMT):
@tomislav thanks

AxelNennker (Fri, 16 Mar 2018 12:20:02 GMT):
Has one of you seen a InvalidClientMsgType in your node's log? My node is in 'sandbox'. This exception is thrown in plenum/server/node.py I think. plenum version is 1.2.34

AxelNennker (Fri, 16 Mar 2018 12:20:02 GMT):
Has one of you seen a InvalidClientMsgType in your node's log? My node is in 'sandbox'. This exception is thrown in plenum/server/node.py I think

ashcherbakov (Fri, 16 Mar 2018 15:01:13 GMT):
@AxelNennker Please make sure that you signed a client message properly

ashcherbakov (Fri, 16 Mar 2018 15:01:46 GMT):
You need to have a NYM on the Ledger with a verky, and needs to use the corresponding signing key for signing of write requests

AxelNennker (Fri, 16 Mar 2018 16:24:45 GMT):
@ashcherbakov the messages are send by the nodes in the sandbox network so I assume that they sign their messages correctly. My node is discarding the messages with InvalidClientMsgType. There is only one place in the code where this exception is thrown https://github.com/hyperledger/indy-plenum/blob/master/plenum/server/node.py#L1644 and I think that the if-statement in https://github.com/hyperledger/indy-plenum/blob/master/plenum/server/node.py#L1636 should be true but is not. One of the messages discarded is 2018-03-16 16:07:07,504 | INFO | message_processor.py (29) | discard | Stuard discarding message ({'hashes': ['6dTvY3hdgwyf9QgrwwHda82w4io7L1XSHiS4z4aUuRvi', '6PiBHFqi1Ggzu1vqg5wFuXRnRDknqKsR85ipQvS1TTii', '9Gxsi1LUfPoS5QS5CVPqhF4qb7B2ETFDqYPwCM1Bo24p', 'Hx7wWN6N7RHFPSGcaRc2mszECpV4W9ZEUoeqhBoZxqjC', '2BU2FYa5cjSvrZZ6TzjHPLhJgXjMug7mJUwgBWwKaPoW', '4a5jRoX9ecHxQKDSukYYN4D1gznqY8V3FqgHM9W9hmF1'], 'ledgerId': 0, 'newMerkleRoot': 'HrTzhpj2xhPZsCoHx5FvMpa16DxvY947QAHQTaz6eXmi', 'viewNo': 0, 'oldMerkleRoot': 'AWJrEjCRsAvXEJryWWGcpDuKYWop5yfgAsD6PhVFNU2a', 'seqNoEnd': 23, 'ppSeqNo': 177, 'seqNoStart': 7, 'op': 'CONSISTENCY_PROOF'}, b'1CCbz{7trb?}?B?ITgQJjfJ?t}l&7{]c{Bz/1Pyu') because InvalidClientMsgType()

ashcherbakov (Fri, 16 Mar 2018 16:29:18 GMT):
Can you please show your genesis transaction file? What txns are currently in the ledger (you can get it by running `read_ledger` script on the node)? Are all nodes have the same genesis txns and is the ledger equal on all nodes? It looks like the messages are the messages received during catch-up, that is the ones already in the ledger. There are two ways how the message appears on the ledger: genesis txns and requests from client.

AxelNennker (Fri, 16 Mar 2018 16:31:26 GMT):
Would you please provide the parameters too?

ashcherbakov (Fri, 16 Mar 2018 16:42:27 GMT):
read_ledger --type=pool read_ledger --type=domain

AxelNennker (Fri, 16 Mar 2018 16:44:09 GMT):
indy@sovrin:~$ read_ledger --type domain [1,{"alias":"Phil Windley","dest":"NMjQb59rKTJXKNqVYfcZFi","role":"0","type":"1","verkey":"Ce9jZ2bQcLRCrY3eT5AbjsU5mXFa4jMF6dDSF21tyeFJ"}] [2,{"alias":"Jason Law","dest":"K2ze2xR8MAxkQscdkboKnD","role":"0","type":"1","verkey":"~KhvZWs1QSS8bS1RxB55NE3"}] [3,{"alias":"Drummond Reed","dest":"Jv4afJBghiuJ2tiZDduarJ","role":"0","type":"1","verkey":"AmKnoVceCaEHBCaDjtSYqwLLpmVQLBbZMgAZHfSyv936"}] [4,{"alias":"Peter Simpson","dest":"JX29L7h6UpDNEThiaTYx9N","role":"0","type":"1","verkey":"AYmPQJTcpsH1YxRQUwwRgGzQVLFf8JRvmuS5LKNZN1gA"}] [5,{"alias":"Ron Amstutz","dest":"7jJe9ArRfRchSKL2sYgFDj","role":"0","type":"1","verkey":"4fjHSUqU9RmeXWXHV6MnKFDtEyEcBUipovhNCDuei5XW"}] [6,{"alias":"Mawaki Chango","dest":"CPU9r7iLSXcSdn79FzbUvQ","role":"0","type":"1","verkey":"7CyhcN7gsqo9VxAV1V7ZhiqTetAadY2S4QYcUdo3Uh4p"}] [7,{"alias":"Mike Bailey","dest":"6feBTywcmJUriqqnGc1zSJ","role":"0","type":"1","verkey":"~EpnvDMWiFSSu1YksE1Cg3n"}] [8,{"alias":"Trev Harmon","dest":"BuZUawgmw5zmeBbVZYxgPk","role":"0","type":"1","verkey":"6wmU3PJv9NsEmg4eaqhb89chpmLUraubWHcj9iRR8Zy5"}] [9,{"alias":"australia steward","dest":"3U8HUen8WcgpbnEz1etnai","identifier":"BuZUawgmw5zmeBbVZYxgPk","role":"2","type":"1","verkey":"~MLDyMBnHvF6yXRar8MxTD8"}] [10,{"alias":"brazil steward","dest":"G3knUCmDrWd1FJrRryuKTw","identifier":"BuZUawgmw5zmeBbVZYxgPk","role":"2","type":"1","verkey":"~2uxUwA2KLb5mLLGVvnMUpS"}] [11,{"alias":"canada steward","dest":"22QmMyTEAbaF4VfL7LameE","identifier":"BuZUawgmw5zmeBbVZYxgPk","role":"2","type":"1","verkey":"~4TKsKJxx4A6tNu7iY4dptA"}] [12,{"alias":"england steward","dest":"NYh3bcUeSsJJcxBE6TTmEr","identifier":"BuZUawgmw5zmeBbVZYxgPk","role":"2","type":"1","verkey":"~NvjAaF82xfHPzNsn1JHNqU"}] [13,{"alias":"korea steward","dest":"U38UHML5A1BQ1mYh7tYXeu","identifier":"BuZUawgmw5zmeBbVZYxgPk","role":"2","type":"1","verkey":"~GDxN3v9zduCuqqU9rxojmp"}] [14,{"alias":"singapore steward","dest":"HfXThVwhJB4o1Q1Fjr4yrC","identifier":"BuZUawgmw5zmeBbVZYxgPk","role":"2","type":"1","verkey":"~G23V57WkFCe1AGKoK74WyC"}] [15,{"alias":"virginia steward","dest":"SPdfHq6rGcySFVjDX4iyCo","identifier":"BuZUawgmw5zmeBbVZYxgPk","role":"2","type":"1","verkey":"~EA8RCM4tZ44gL5oifwM7Gu"}] indy@sovrin:~$ read_ledger --type=pool [1,{"data":{"alias":"australia","client_ip":"52.64.96.160","client_port":"9702","node_ip":"52.64.96.160","node_port":"9701","services":["VALIDATOR"]},"dest":"UZH61eLH3JokEwjMWQoCMwB3PMD6zRBvG6NCv5yVwXz","identifier":"3U8HUen8WcgpbnEz1etnai","txnId":"c585f1decb986f7ff19b8d03deba346ab8a0494cc1e4d69ad9b8acb0dfbeab6f","type":"0"}] [2,{"data":{"alias":"brazil","client_ip":"54.233.203.241","client_port":"9702","node_ip":"54.233.203.241","node_port":"9701","services":["VALIDATOR"]},"dest":"2MHGDD2XpRJohQzsXu4FAANcmdypfNdpcqRbqnhkQsCq","identifier":"G3knUCmDrWd1FJrRryuKTw","txnId":"5c8f52ca28966103ff0aad98160bc8e978c9ca0285a2043a521481d11ed17506","type":"0"}] [3,{"data":{"alias":"canada","client_ip":"52.60.207.225","client_port":"9702","node_ip":"52.60.207.225","node_port":"9701","services":["VALIDATOR"]},"dest":"8NZ6tbcPN2NVvf2fVhZWqU11XModNudhbe15JSctCXab","identifier":"22QmMyTEAbaF4VfL7LameE","txnId":"408c7c5887a0f3905767754f424989b0089c14ac502d7f851d11b31ea2d1baa6","type":"0"}] [4,{"data":{"alias":"england","client_ip":"52.56.191.9","client_port":"9702","node_ip":"52.56.191.9","node_port":"9701","services":["VALIDATOR"]},"dest":"DNuLANU7f1QvW1esN3Sv9Eap9j14QuLiPeYzf28Nub4W","identifier":"NYh3bcUeSsJJcxBE6TTmEr","txnId":"d56d0ff69b62792a00a361fbf6e02e2a634a7a8da1c3e49d59e71e0f19c27875","type":"0"}] [5,{"data":{"alias":"korea","client_ip":"52.79.115.223","client_port":"9702","node_ip":"52.79.115.223","node_port":"9701","services":["VALIDATOR"]},"dest":"HCNuqUoXuK9GXGd2EULPaiMso2pJnxR6fCZpmRYbc7vM","identifier":"U38UHML5A1BQ1mYh7tYXeu","txnId":"76201e78aca720dbaf516d86d9342ad5b5d46f5badecf828eb9edfee8ab48a50","type":"0"}] [6,{"data":{"alias":"singapore","client_ip":"13.228.62.7","client_port":"9702","node_ip":"13.228.62.7","node_port":"9701","services":["VALIDATOR"]},"dest":"Dh99uW8jSNRBiRQ4JEMpGmJYvzmF35E6ibnmAAf7tbk8","identifier":"HfXThVwhJB4o1Q1Fjr4yrC","txnId":"51e2a46721d104d9148d85b617833e7745fdbd6795cb0b502a5b6ea31d33378e","type":"0"}] [7,{"data":{"alias":"virginia","client_ip":"34.225.215.131","client_port":"9702","node_ip":"34.225.215.131","node_port":"9701","services":["VALIDATOR"]},"dest":"EoGRm7eRADtHJRThMCrBXMUM2FpPRML19tNxDAG8YTP8","identifier":"SPdfHq6rGcySFVjDX4iyCo","txnId":"0a4992ea442b53e3dca861deac09a8d4987004a8483079b12861080ea4aa1b52","type":"0"}] indy@sovrin:~$

ashcherbakov (Fri, 16 Mar 2018 16:52:12 GMT):
Is it the same on all nodes?

AxelNennker (Fri, 16 Mar 2018 17:07:03 GMT):
?I only have access to my node, right, not to the sandbox nodes

ashcherbakov (Fri, 16 Mar 2018 17:24:18 GMT):
ah, ok, sorry, I was thinking that you mean your local test pool by 'sandbox'

ashcherbakov (Fri, 16 Mar 2018 17:24:37 GMT):
Can you please provide the whole log file from the node?

AxelNennker (Fri, 16 Mar 2018 17:34:58 GMT):
logs sent via email to your dsr-corporation.com address

saholman (Fri, 16 Mar 2018 18:04:37 GMT):
I am getting a `CommonInvalidState` error when calling `open_pool_ledger`. Any ideas as to what could be going wrong? The docs say that this indicates an "Invalid library state was detected in runtime. It signals library bug" but I've built the most recent version and have even tried older versions of libindy.

saholman (Fri, 16 Mar 2018 18:06:03 GMT):
@ashcherbakov Any ideas? Or who would be the best person to ask?

trthhrtz (Sun, 18 Mar 2018 06:40:01 GMT):
Has joined the channel.

danielhardman (Sun, 18 Mar 2018 14:58:37 GMT):
@jankokrstic , @mboyd wants to collaborate with us on the Berdyaev 3 mission to improve developer experience.

alkopnin (Sun, 18 Mar 2018 20:14:38 GMT):
Hi folks, Does it work proof from multiple claims by different issuers? I've got an error: src/errors/indy.rs:68 | Casting error to ErrorCode: Invalid structure: Cannot deserialize list of schemas: ErrorImpl { code: TrailingCharacters, line: 1, column: 177 } My list of used schemas is organized as follow: {"claim::d9548e36-66b3-42bf-9f3d-43a5dc4bfcc8":{"seqNo":15, "dest":"V4SGRU86Z58d6TV7PBUe6f", "data":{"attr_names":["attr1","attr2"],"name":"schema_education","version":"1.0"}}},{"claim::a86d974d-8d0d-4ce5-ba65-ba6847bce769":{"seqNo":13, "dest":"V4SGRU86Z58d6TV7PBUe6f", "data":{"attr_names":["attr1","attr2"],"name":"schema_name","version":"1.0"}}}

steptan (Mon, 19 Mar 2018 04:43:04 GMT):
Has joined the channel.

donaldong (Mon, 19 Mar 2018 08:54:10 GMT):
Has joined the channel.

donaldong (Mon, 19 Mar 2018 08:54:26 GMT):
Hi! I would like to quickly get started up using indy-sdk for a prototype presentation this friday. Any quick steps I can follow and get started?

donaldong (Mon, 19 Mar 2018 08:54:41 GMT):
The guide aren't very straight forward. Hope to get some help.

donaldong (Mon, 19 Mar 2018 08:54:49 GMT):
Intend to run all these locally.

gudkov (Mon, 19 Mar 2018 09:10:05 GMT):
> Any quick steps I can follow and get started? 1. Install libindy 2. Install wrapper 3. Start local pool with docker And you are ready to code

donaldong (Mon, 19 Mar 2018 09:10:39 GMT):
Am I right if I follow this guide? https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md

donaldong (Mon, 19 Mar 2018 09:13:01 GMT):

Clipboard - March 19, 2018 5:12 PM

gudkov (Mon, 19 Mar 2018 09:13:52 GMT):
https://github.com/hyperledger/indy-sdk/pull/572/files

gudkov (Mon, 19 Mar 2018 09:14:14 GMT):
@donaldong see README.md in this PR.

gudkov (Mon, 19 Mar 2018 09:14:30 GMT):
https://github.com/SergeyPalamarchuk/indy-sdk/blob/ec0bea96e0ceb18ad841dc9b582e67911dc2474d/README.md

gudkov (Mon, 19 Mar 2018 09:16:15 GMT):
``` apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 68DB5E88 sudo add-apt-repository "deb https://repo.sovrin.org/sdk/deb xenial master" sudo apt-get update sudo apt-get install -y libindy ``` will install the latest libindy from master channel

donaldong (Mon, 19 Mar 2018 09:18:36 GMT):
Okay. I just amended

donaldong (Mon, 19 Mar 2018 09:18:36 GMT):
Doing a reinstallation.

donaldong (Mon, 19 Mar 2018 09:20:15 GMT):
Is there a quick ready code samples I can use for prototype presentation this friday?

donaldong (Mon, 19 Mar 2018 09:20:33 GMT):
A ready made scenario play would be great!

donaldong (Mon, 19 Mar 2018 09:49:14 GMT):

Clipboard - March 19, 2018 5:49 PM

donaldong (Mon, 19 Mar 2018 09:51:33 GMT):
Do I still need to build?

gudkov (Mon, 19 Mar 2018 09:52:43 GMT):
> Do I still need to build? You can just install libindy with apt.

donaldong (Mon, 19 Mar 2018 10:04:08 GMT):
I see. Got it.

alkopnin (Mon, 19 Mar 2018 10:29:22 GMT):
@gudkov @Artemkaaas Hi guys, do you have some updates regarding my question?

turmewr3ck (Mon, 19 Mar 2018 10:49:07 GMT):
408

turmewr3ck (Mon, 19 Mar 2018 11:45:41 GMT):
Does anybody know if the libindy builds at the site below are reproducible, e.g., by making a git checkout on tags? https://repo.sovrin.org/sdk/deb/pool/xenial/master/libi/libindy/libindy_1.3.1~408_amd64.deb

sergey.minaev (Mon, 19 Mar 2018 12:34:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=7Xsv8CvSzTH2jZDpi) @turmewr3ck our CD is designed as reproducable, but actually there is no public info (e.g. tag in hyperledger GH) to track master version of artifacts against code. But merges into master not so frequent, so you can compare time for artifacts uploading and merging PRs in github

sergey.minaev (Mon, 19 Mar 2018 12:34:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=7Xsv8CvSzTH2jZDpi) @turmewr3ck our CD is designed as reproducable, but actually there is no public info (e.g. tag in hyperledger GH) to track master version of artifacts against code. But merges into master are not so frequent, so you can compare time for artifacts uploading and merging PRs in github

sergey.minaev (Mon, 19 Mar 2018 12:35:42 GMT):
For RC and stable builds major tags are created manually.

alkopnin (Mon, 19 Mar 2018 12:37:15 GMT):
I use commit: 8b0b6eb801b2937fe85fbf41e0fbf23be0a1ff5b wrapper: 1.3.1-dev-406

alkopnin (Mon, 19 Mar 2018 12:37:15 GMT):
@turmewr3ck I use commit: 8b0b6eb801b2937fe85fbf41e0fbf23be0a1ff5b wrapper: 1.3.1-dev-406

alkopnin (Mon, 19 Mar 2018 12:37:15 GMT):
okay, sounds good, will migrate on it

alkopnin (Mon, 19 Mar 2018 12:37:15 GMT):
@turmewr3ck I use for development commit: 8b0b6eb801b2937fe85fbf41e0fbf23be0a1ff5b wrapper: 1.3.1-dev-406

sergey.minaev (Mon, 19 Mar 2018 12:41:49 GMT):
And the latest master is ba9f80032b1d51893ebdf3897f1bf730d354b83c 1.3.1 412

alkopnin (Mon, 19 Mar 2018 12:42:42 GMT):
okay, sounds good, will migrate on it

alkopnin (Mon, 19 Mar 2018 12:43:26 GMT):
Sergey, could you help me with multiple issuers and single proof it

alkopnin (Mon, 19 Mar 2018 12:43:45 GMT):
do you support multiple claims now?

alkopnin (Mon, 19 Mar 2018 12:44:09 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=m8wJr5EqapbhPoFuF)

sergey.minaev (Mon, 19 Mar 2018 12:45:43 GMT):
Actually it should works, but there is not enough test coverage at master. Right now we perform large refactoring at feature/revocation branch and already add more tests for claims from multiple sub-proofs / credential schemas.

Artemkaaas (Mon, 19 Mar 2018 12:49:00 GMT):
@alkopnin yes we support proof with multiple claims. You are passing invalid schema json here

Artemkaaas (Mon, 19 Mar 2018 12:49:35 GMT):
Schemas json must be ``` {"claim::d9548e36-66b3-42bf-9f3d-43a5dc4bfcc8":{"seqNo":15, "dest":"V4SGRU86Z58d6TV7PBUe6f", "data":{"attr_names":["attr1","attr2"],"name":"schema_education","version":"1.0"}}, "claim::a86d974d-8d0d-4ce5-ba65-ba6847bce769":{"seqNo":13, "dest":"V4SGRU86Z58d6TV7PBUe6f", "data":{"attr_names":["attr1","attr2"],"name":"schema_name","version":"1.0"}}} ```

Artemkaaas (Mon, 19 Mar 2018 12:53:15 GMT):
Here are tests for this case (Java wrapper): master branch: https://github.com/hyperledger/indy-sdk/blob/master/wrappers/java/src/test/java/org/hyperledger/indy/sdk/demo/AnoncredsDemoTest.java#L182 rc vranch: https://github.com/hyperledger/indy-sdk/blob/rc/wrappers/java/src/test/java/org/hyperledger/indy/sdk/demo/AnoncredsDemoTest.java#L177

alkopnin (Mon, 19 Mar 2018 13:08:17 GMT):
got it, thank you! I will try

alkopnin (Mon, 19 Mar 2018 13:20:45 GMT):
it works, thanks

alkopnin (Mon, 19 Mar 2018 13:26:17 GMT):
I also have couple questions regarding the business process and API in general. 1) Did.storeTheirDid - what is the purposes of this api and when should I use it? 2) Should I create pairwise for each connection? What is the best practice, if I run session with 1 company but multiple times. Do I need to generate new pairwise each time?

alkopnin (Mon, 19 Mar 2018 13:26:17 GMT):
I also have couple of questions regarding the business process and API in general. 1) Did.storeTheirDid - what is the purposes of this api and when should I use it? 2) Should I create pairwise for each connection? What is the best practice, if I run session with 1 company but multiple times. Do I need to generate new pairwise each time?

danielhardman (Mon, 19 Mar 2018 15:59:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=m8wJr5EqapbhPoFuF) @alkopnin We call this a "compound proof", and I believe it does work. @ashcherbakov ?

danielhardman (Mon, 19 Mar 2018 16:03:13 GMT):
@swcurran and @MALodder : I recommend that the two of you talk about the computation time for a credential issuance. Mike wonders if you, Stephen, are generating new issuer keys with each issuance; that would add quite a bit to issuance time. There may be some helpful optimizations that can be done for credentials that have many fields in common. Mike would like to know exactly which test you are using to profile timing. Can you share the code?

jankokrstic (Mon, 19 Mar 2018 16:46:43 GMT):
Hello, I started working on Go wrapper for Indy SDK. Anyone interested in joining the effort? @arjanvaneersel was also interested. Feel free to message me directly as well

AxelNennker (Mon, 19 Mar 2018 20:17:22 GMT):
@ashcherbakov I could resolve the InvalidClientMsgType exceptions. I started the node with port 9701 and 9702 but the network thought that my node uses 9700 and 9701. So the message were send to the wrong port. Stupid me. Thanks for your help. Mike Bailey finally spotted the mixup.

AxelNennker (Mon, 19 Mar 2018 20:17:22 GMT):
@ashcherbakov I could resolve the InvalidClientMsgType exceptions. I started the node with port 9701 and 9702 but the network thought that my noded uses 9700 and 9701. So the message were send to the wrong port. Stupid me. Thanks for your help. Mike Bailey finally spotted the mixup.

swcurran (Mon, 19 Mar 2018 20:50:25 GMT):
@danielhardman, @MALodder - We're still working on getting the timings. No, we're not doing new issuer keys per issuance, but I won't bet on whether we've got an optimized flow - hence why we've not yet raised a flag. It could be on our side. @nbrempel will be the point of contact on this. Nick - please see note above from @danielhardman.

tomislav (Mon, 19 Mar 2018 21:09:58 GMT):
Is there a way to build the sdk with statically linked deps? Specifically zmq and libsodium? For example for embedding in a mobile framework?

hkrichen (Mon, 19 Mar 2018 21:10:40 GMT):
Has joined the channel.

danielhardman (Mon, 19 Mar 2018 23:25:50 GMT):
@tomislav I believe @KhageshSharma is doing this on iOS.

danielhardman (Mon, 19 Mar 2018 23:37:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=8wznqx6p7G57GDh2h) @the_identity_guy I think yes, indy-client is deprecated. Part of it will get subsumed into indy-node. The CLI has already been moved into indy-sdk. @ashcherbakov knows more.

danielhardman (Mon, 19 Mar 2018 23:47:22 GMT):
I came to a ledger working group meeting a couple weeks ago with my compatriot, Janko, to report on some efforts we had made to create some short, self-contained "developer how-to" documents that demonstrate how to use the indy-sdk to accomplish simple tasks: create a DID, rotate a key, create a schema, issue a credential, send a secure message... I wanted to report that we have completed code for 10 of these short how-tos in python, and we've been porting them over to java. (Actually, I should give Vyacheslav and his crew credit for python, and Janko credit for the porting.) I've been trying to write the one-page docs that describe each developer workflow, and have made some progress. All of these mini tutorials assume a functional dev environment, and we've also been working on documenting the simple commands that a dev can use to get such an environment in a single easy step. This is based on excellent work already done by the indy-sdk team; thanks, guys! If anybody is interested in collaborating with us, or trying out our tutorials as they come online, ping me (@daniel.hardman), Janko (@jankokrstic), and Mike Boyd (@mboyd). I plan to debut a bunch of this at the Blockchaingers hackfest in early April. @vinomaster, can you comment on how this effort relates to work I've heard you are interested in, around providing a smooth developer experience? I think you even volunteered some folks who might be able to help?

vinomaster (Mon, 19 Mar 2018 23:47:22 GMT):
Has joined the channel.

donaldong (Tue, 20 Mar 2018 08:07:03 GMT):
Anyone knows how should I run the samples at this location? /indy-sdk/samples/python

donaldong (Tue, 20 Mar 2018 08:12:07 GMT):

Clipboard - March 20, 2018 4:12 PM

donaldong (Tue, 20 Mar 2018 08:36:14 GMT):
Not sure if someone is around.

donaldong (Tue, 20 Mar 2018 08:36:32 GMT):
Hope to get some good advices soon.

donaldong (Tue, 20 Mar 2018 08:42:30 GMT):

Clipboard - March 20, 2018 4:42 PM

gudkov (Tue, 20 Mar 2018 09:03:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qWJNKXYMiYi6YxKjA) Indy cli now requires the same version of libindy. If versions are different there can be linking problems.

donaldong (Tue, 20 Mar 2018 09:09:30 GMT):
Okay. Let me reinstall again

donaldong (Tue, 20 Mar 2018 09:13:30 GMT):
@gudkov what is the fastest way to get started?

gudkov (Tue, 20 Mar 2018 09:18:25 GMT):
- install libindy - install wrapper - run local pool in docker - start coding

gudkov (Tue, 20 Mar 2018 09:19:21 GMT):
Check https://github.com/SergeyPalamarchuk/indy-sdk/blob/5a5e267d8f908728e3f6e1915b84b479ca8804f7/README.md

gudkov (Tue, 20 Mar 2018 09:19:27 GMT):
It contains all instructions

donaldong (Tue, 20 Mar 2018 09:23:00 GMT):
@gudkov Let me quickly do some read up again. Been doing multiple reinstallation.

donaldong (Tue, 20 Mar 2018 09:23:53 GMT):
@gudkov should I do this guide first? https://github.com/hyperledger/indy-node/blob/master/docs/start-nodes.md

donaldong (Tue, 20 Mar 2018 09:24:34 GMT):
@gudkov first step for me is to get samples running first.

gudkov (Tue, 20 Mar 2018 11:26:27 GMT):
@donaldong In branch that i pointed to you there will be also instruction for running of samples. For python sample you need: 1. Install libindy 2. Go to https://github.com/SergeyPalamarchuk/indy-sdk/tree/master/wrappers/python 3. Install dependencies with pip install -e (or python setup.py develop) 4. Just ru ./src/main.py

pimotte (Tue, 20 Mar 2018 12:24:42 GMT):
In the python sample, why are the claims for first_name and last_name retrieved? https://github.com/hyperledger/indy-sdk/blob/master/samples/python/src/getting_started.py#L334 As far as I can see, there is no way for the verifier to match self-attested attributes to the schema which does contain these fields.

mboyd (Tue, 20 Mar 2018 18:22:44 GMT):
I'm building libindy using an ubuntu 16.04 VM right now, but the `cargo build` command has failed with this error: `rror: failed to run custom build command for `zmq-sys v0.8.2` process didn't exit successfully: `/home/michael/code/indy-sdk/libindy/target/debug/build/zmq-sys-dfd4b602ea42e240/build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'Unable to locate libzmq: `"pkg-config" "--libs" "--cflags" "libzmq >= 3.2"` did not exit successfully: exit code: 1 --- stderr Package libzmq was not found in the pkg-config search path. Perhaps you should add the directory containing `libzmq.pc' to the PKG_CONFIG_PATH environment variable No package 'libzmq' found ', /home/michael/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-sys-0.8.2/build.rs:31:17 note: Run with `RUST_BACKTRACE=1` for a backtrace.`

mboyd (Tue, 20 Mar 2018 18:24:05 GMT):
'm building libindy using an ubuntu 16.04 VM right now, but the `cargo build` command has failed with this error: `Error: failed to run custom build command for zmq-sys v0.8.2 process didn't exit successfully: /home/michael/code/indy-sdk/libindy/target/debug/build/zmq-sys-dfd4b602ea42e240/build-script-build (exit code: 101) --- stderr thread 'main' panicked at 'Unable to locate libzmq: "pkg-config" "--libs" "--cflags" "libzmq >= 3.2" did not exit successfully: exit code: 1 --- stderr Package libzmq was not found in the pkg-config search path. Perhaps you should add the directory containing `libzmq.pc' to the PKG_CONFIG_PATH environment variable No package 'libzmq' found , /home/michael/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-sys-0.8.2/build.rs:31:17 note: Run with RUST_BACKTRACE=1 for a backtrace.` I haven't looked into the pkg_config_path yet, but has anyone recently built libindy and also run into this error? I'm using the master branch of indy-sdk

mboyd (Tue, 20 Mar 2018 18:24:05 GMT):
'm building libindy using an ubuntu 16.04 VM right now, but the `cargo build` command has failed with this error: `rror: failed to run custom build command for `zmq-sys v0.8.2` process didn't exit successfully: `/home/michael/code/indy-sdk/libindy/target/debug/build/zmq-sys-dfd4b602ea42e240/build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'Unable to locate libzmq: `"pkg-config" "--libs" "--cflags" "libzmq >= 3.2"` did not exit successfully: exit code: 1 --- stderr Package libzmq was not found in the pkg-config search path. Perhaps you should add the directory containing `libzmq.pc' to the PKG_CONFIG_PATH environment variable No package 'libzmq' found ', /home/michael/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-sys-0.8.2/build.rs:31:17 note: Run with `RUST_BACKTRACE=1` for a backtrace.` I haven't looked into the pkg_config_path yet, but has anyone recently built libindy and also run into this error? I'm using the master branch of indy-sdk

mboyd (Tue, 20 Mar 2018 18:24:05 GMT):
'm building libindy using an ubuntu 16.04 VM right now, but the `cargo build` command has failed with this error: `Error: failed to run custom build command for zmq-sys v0.8.2 process didn't exit successfully: `/home/michael/code/indy-sdk/libindy/target/debug/build/zmq-sys-dfd4b602ea42e240/build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'Unable to locate libzmq: "pkg-config" "--libs" "--cflags" "libzmq >= 3.2" did not exit successfully: exit code: 1 --- stderr Package libzmq was not found in the pkg-config search path. Perhaps you should add the directory containing `libzmq.pc' to the PKG_CONFIG_PATH environment variable No package 'libzmq' found ', /home/michael/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-sys-0.8.2/build.rs:31:17 note: Run with `RUST_BACKTRACE=1` for a backtrace.` I haven't looked into the pkg_config_path yet, but has anyone recently built libindy and also run into this error? I'm using the master branch of indy-sdk

tomislav (Tue, 20 Mar 2018 20:22:31 GMT):
It looks like you need install libzmq, this is a dependency for libindy

laoqui (Tue, 20 Mar 2018 20:27:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=s2rFkAA5AfLvisB7m) @mboyd i had the same issue a few days ago. you mentioned you are using ubuntu, so `apt-get install libzmq3-dev` should fix this problem

ShikarSharma (Tue, 20 Mar 2018 22:49:21 GMT):
Has joined the channel.

donaldong (Wed, 21 Mar 2018 05:23:37 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=n6CF2eNAExHhDR5mA) @gudkov I keep encountering the following error.

donaldong (Wed, 21 Mar 2018 05:23:55 GMT):

Clipboard - March 21, 2018 1:23 PM

donaldong (Wed, 21 Mar 2018 05:24:04 GMT):
@gudkov any ways to help me?

gudkov (Wed, 21 Mar 2018 10:26:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=tcany2SbNWpdTXHwB) @donaldong You need to add current directory to PYTHONPATH

gudkov (Wed, 21 Mar 2018 10:26:31 GMT):
try set PYTHONPATH=.

gudkov (Wed, 21 Mar 2018 10:26:39 GMT):
and run again

gudkov (Wed, 21 Mar 2018 10:27:03 GMT):
or just open project in PyCharm it adds sources dirs to PYTHONPATH by default

bafonins (Wed, 21 Mar 2018 13:31:06 GMT):
Has joined the channel.

MALodder (Wed, 21 Mar 2018 16:12:54 GMT):
@swcurran Sounds good, let me know when you are ready for me to take a look at what you are doing to see where the bottlenecks are in the code

MikkoLaaksonen (Thu, 22 Mar 2018 07:22:08 GMT):
Has joined the channel.

stevenmilstein (Thu, 22 Mar 2018 15:44:05 GMT):
Has joined the channel.

saholman (Thu, 22 Mar 2018 16:00:17 GMT):
@gudkov I am having issues when changing the TEST_POOL_IP. I am getting a CommonInvalidState error from indy. Any ideas?

stevenmilstein (Thu, 22 Mar 2018 16:02:46 GMT):
Has left the channel.

saholman (Thu, 22 Mar 2018 16:05:13 GMT):
@mboyd ^^

mhailstone (Thu, 22 Mar 2018 16:06:52 GMT):
Is there any documentation that summarizes the discussion surrounding enterprise wallets?

ianco (Thu, 22 Mar 2018 18:14:00 GMT):
@mhailstone the work we've been doing in BC is documented here - https://github.com/ianco/indy-sdk/tree/master/doc/wallet. @danielhardman has some documents, which I don't have the links to handy, but I'll dig them up

mhailstone (Thu, 22 Mar 2018 21:04:55 GMT):
Thank you @ianco !

danielhardman (Thu, 22 Mar 2018 21:46:28 GMT):
@mhailstone other people who have been thinking about enterprise wallets include @gudkov and @dkulic .

danielhardman (Thu, 22 Mar 2018 21:48:49 GMT):
I have been pondering into how encryption has to work, how to get massive scale, and how to support searchability for Evernym's use cases, and trying to imagine a solution that also works well for the use cases I am familiar with from the BCGov guys. I would love to have a chat about this. We could do it in the next community call, or we could schedule something specific and invite everybody.

nbrempel (Thu, 22 Mar 2018 23:39:09 GMT):
Hey folks, currently opening a wallet that is already open throws an error: https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/indy/wallet.py#L57 "It is impossible to open wallet with the same name more than once." Should it be possible to keep a reference to a wallet handle, and use this handle safely from multiple threads?

gudkov (Fri, 23 Mar 2018 06:08:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=CkjCmP8GpRoq5MWKZ) @nbrempel all libindy API is thread safe. All execution and registered callbacks calling are performed in libindy threads

BryanSparks (Fri, 23 Mar 2018 13:58:50 GMT):
Has joined the channel.

thomasmm (Mon, 26 Mar 2018 12:49:52 GMT):
Has joined the channel.

nbrempel (Mon, 26 Mar 2018 17:16:16 GMT):
@gudkov If the sdk is threadsafe, how do you feel about allowing open_wallet to be called multiple times? For subsequent calls, you can return the existing wallet handle.

nbrempel (Mon, 26 Mar 2018 17:17:34 GMT):
Otherwise, the library may be threadsafe but it is not possible to perform concurrent calls to the library without maintaining a reference to the wallet handle in our application state.

nbrempel (Mon, 26 Mar 2018 17:17:34 GMT):
Otherwise, the library may be threadsafe but it is not possible to perform threaded calls to the library without maintaining a reference to the wallet handle in our application state.

hellsnow (Mon, 26 Mar 2018 18:32:34 GMT):
Has joined the channel.

tomislav (Mon, 26 Mar 2018 18:38:38 GMT):
How does one update the default keys for stweard generated with seed 00000Steward? Does the process invlove calling replace_keys_start, build_nym_request, sign_submit, replace_keys_apply in order?

tomislav (Mon, 26 Mar 2018 18:40:11 GMT):
And what is the lifetime of replace_key_start? The docs say they are temporary, how long to they live as temporary?

gudkov (Tue, 27 Mar 2018 06:56:05 GMT):
@tomislav > How does one update the default keys for stweard generated with seed 00000Steward? Does the process invlove calling replace_keys_start, build_nym_request, sign_submit, replace_keys_apply in order? - You call replace_key_start it stores new keys in temporary place and returns new keys - You send NYM transactions with new keys by calling build_nym_request + sign_submit. Not that it will be signed by *old keys* - You call replace_keys_apply to make temporary keys permanent > And what is the lifetime of replace_key_start? The docs say they are temporary, how long to they live as temporary? Until you call replace_keys_apply

gudkov (Tue, 27 Mar 2018 07:05:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ZqroydpEyFjLHeNSY) @nbrempel You can implement this on application level by few lines of code. Also your proposal simple allows application level races: - Thread 1 calls open and gets handle - Thread 2 calls open and gets handle - Thread 1 calls close and makes handle invalid - Thread 2 starts reading from wallet and gets InvalidHandle exception So we prefer "explicit" approach for resources management.

tomislav (Tue, 27 Mar 2018 13:17:22 GMT):
Thank you @gudkov . I noticed the docs now include a Java howto on thekey rotation flow. Cheers

stevenmilstein (Tue, 27 Mar 2018 13:32:40 GMT):
Has joined the channel.

nbrempel (Tue, 27 Mar 2018 17:13:43 GMT):
Ok, thank you @gudkov

stevenmilstein (Wed, 28 Mar 2018 00:41:55 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6v2h4ktjtAmotYa3o) @mboyd @laoqui I had the same issue for Mac OS X. Running `brew install zeromq` as per https://github.com/zeromq/libzmq resolved the problem.

ianco (Wed, 28 Mar 2018 15:17:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=eythPxbxkca2Achyx) @gudkov @nbrempel I can make a couple of comments on the threading support, since we’ve been doing a lot of testing in that area. Our experience may be of interest to others. 1. The sdk code, as far as we’ve been able to tell, is all thread safe. 2. The wallet is also thread safe (we have our own wallet implementation, but we think ‘default’ is also thread safe), however the sdk won’t allow you to open the same wallet multiple times. The client can open a wallet and then ‘share’ the handle, however it doesn’t support (for example) opening the wallet concurrently with different sets of credentials. We’ve implemented this in our own wallet and it works with the sdk code (all thread safe). 3. The higher-level protocol is not ‘thread safe’. In other words, if an agent is trying to run multiple operations concurrently on the same wallet, the operations have the risk of stepping on each other. This is because each operation may involve multiple discreet transactions (create claim offer, send claim request, create claim, etc.) and these may involve storing temporary values (such as a nonce) in the wallet. This is still a problem we are working on … Overall multi-threading support is fairly complex topic within indy. I'm interested if anyone else is dealing with this.

mboyd (Wed, 28 Mar 2018 17:27:36 GMT):
Is there currently a stable way to start the indy-cli using the indy-sdk repository?

mboyd (Wed, 28 Mar 2018 17:27:59 GMT):
I have a friend who would like to demo indy blockchain tomorrow

mboyd (Wed, 28 Mar 2018 17:28:14 GMT):
Has anyone found an easy way to successfully demo this technology?

bmul (Wed, 28 Mar 2018 19:18:19 GMT):
Has joined the channel.

tomislav (Thu, 29 Mar 2018 02:42:14 GMT):
@mboyd The docker tutorial worked pretty well for me, I demoed internally in my company. - Run both pool and client scripts as instructed here with no params (defaults) - https://github.com/hyperledger/indy-node/tree/master/environment/docker/pool - The client script will run the container and start the CLI - setup and start the agents inside this container - https://github.com/hyperledger/indy-node/blob/master/environment/docker/pool/StartIndyAgents.md - Now you can run the full Getting Started guide here, inside the client container - https://github.com/hyperledger/indy-node/blob/stable/getting-started.md

tomislav (Thu, 29 Mar 2018 02:42:14 GMT):
@mboyd The docker tutorial worked pretty well for me, I demoed internally in my company. - Run both pool and client scripts as instructed here with no params (defaults) - https://github.com/hyperledger/indy-node/tree/master/environment/docker/pool - The client script will run the container and start the CLI - setup and start the agents inside this container - https://github.com/hyperledger/indy-node/blob/master/environment/docker/pool/StartIndyAgents.md - Now you can run the full Getting Started guide here - https://github.com/hyperledger/indy-node/blob/stable/getting-started.md

gudkov (Thu, 29 Mar 2018 13:39:48 GMT):
> Is there currently a stable way to start the indy-cli using the indy-sdk repository? Just install package for Ubuntu or download binary for windows

gudkov (Thu, 29 Mar 2018 13:40:20 GMT):
CLI from indy-node repo is outdated

gudkov (Thu, 29 Mar 2018 13:58:06 GMT):
Instruction how to get binaries is here: https://github.com/hyperledger/indy-sdk/blob/master/cli/README.md

gudkov (Thu, 29 Mar 2018 15:14:27 GMT):
We have a demo for Anoncreds workflow with revocation. It is based on demo test for our python wrapper. Revocation demo link: https://drive.google.com/file/d/1jC5YRTELUNsrwLlEqcMgmmkmpdzgq4oQ/view

MikeCohen (Fri, 30 Mar 2018 18:53:14 GMT):
Has joined the channel.

tomislav (Sun, 01 Apr 2018 17:20:09 GMT):
How does one represent string values as int required for `indy_issuer_create_claim` for `claim_values_json` param? Examples use hardcoded values like `[\"male\",\"5944657099558967239210949258394887428692050081607692519917050011144233115103\"]`.

tomislav (Sun, 01 Apr 2018 23:40:54 GMT):
I have one more question. I'm trying to run a full scenario based on the how-to's for claim offer/request issuance. I'm running into a weird issue when calling `indy_prover_create_and_store_claim_req` from the prover wallet. I've created master secret and up until this point everything works fine. However, calling this API always returns 113 (invalid structure). I'm using the dotnet wrapper, but I don't think this is where the error occurs. Here are the values for claimOfferJson and claimDefJson I'm passing. https://pastebin.com/NJYNUttE(pastebin to avoid big pastes). The prover wallet is setup just fine. Interestingly, if I call `indy_prover_store_claim_offer` with the same value for `claimOfferJson` is works fine and stores the claim (verified directly inside sqlite). Am I missing anything? Thank you for your time!

tomislav (Sun, 01 Apr 2018 23:40:54 GMT):
I have one more question. I'm trying to run a full scenario based on the how-to's for claim offer/request issuance. I'm running into a weird issue when calling `indy_prover_create_and_store_claim_req` from the prover wallet. I've created master secret and up until this point everything works fine. However, calling this API always returns 113 (invalid structure). I'm using the dotnet wrapper, but I don't think this is where the error occurs. Here are the values for claimOfferJson and claimDefJson I'm passing. https://pastebin.com/NJYNUttE (pastebin to avoid big pastes). The prover wallet is setup just fine. Interestingly, if I call `indy_prover_store_claim_offer` with the same value for `claimOfferJson` is works fine and stores the claim (verified directly inside sqlite). Am I missing anything? Thank you for your time!

tomislav (Sun, 01 Apr 2018 23:57:56 GMT):
I asked too soon, second issue resolved. Still unclear only on the string to int values

gudkov (Mon, 02 Apr 2018 14:40:06 GMT):
> Still unclear only on the string to int values For now it is application-specific. In the future schema will define how to convert different data-types to ints and how to handle unit conversions.

wangdong (Tue, 03 Apr 2018 02:15:12 GMT):
Has joined the channel.

turmewr3ck (Tue, 03 Apr 2018 11:23:51 GMT):
@tomislav For integer encoding of attributes you can see an example implementation in the BCGov von-connector, encode/decode functions: https://github.com/bcgov/von-connector/blob/master/connector/von_agent/util.py#L14

turmewr3ck (Tue, 03 Apr 2018 11:32:21 GMT):
Is the anoncreds implementation based on some paper about CL signatures? I mean the choice of attribute names in anoncreds claims/proofs ("xz_cap", "m_2", a lot of single letter attr names, etc), do they origin from some specific paper?

gudkov (Tue, 03 Apr 2018 11:34:33 GMT):
@turmewr3ck You can find paper here https://github.com/hyperledger/indy-crypto/blob/master/libindy-crypto/docs/AnonCred.pdf

stefanopulzeic (Wed, 04 Apr 2018 13:12:30 GMT):
Has joined the channel.

turmewr3ck (Wed, 04 Apr 2018 14:21:42 GMT):
I have not checked the anoncreds math, but do any of issuerCreateClaimOffer or issuerCreateClaim (Java wrapper notation) depend on having a claim definition in the wallet beforehand? (Trying to understand what to do if I have written a claim def to both the wallet and ledger, but then delete (say by accident, or just test case tear-down) the wallet, and restart associated agent.)

vmd90 (Wed, 04 Apr 2018 16:24:16 GMT):
Has joined the channel.

mboyd (Wed, 04 Apr 2018 16:46:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wZpAsmd2CqRX9Zbn rd) @gudkov I'm having problems downloading the binaries. There is not a stable branch in the sovrin repo, and the stable-test branch binaries don't seem to be working on Ubuntu. Is there a targeted release binary for ubuntu that you can point me to for indy-cli?

hcsatish (Wed, 04 Apr 2018 17:17:56 GMT):
Has joined the channel.

mboyd (Thu, 05 Apr 2018 04:13:03 GMT):
I've downloaded the stable-test binaries and built them, but I'm getting the following error when I run the docker build command posted on the main readme: https://github.com/hyperledger/indy-sdk/#how-to-start-local-nodes-pool-with-docker ``` $: ~/code/indy-sdk$ sudo docker build -f ci/indy-pool.dockerfile -t indy_pool . ... ... ---> Running in dd851426d324 Err:1 http://archive.ubuntu.com/ubuntu xenial InRelease Temporary failure resolving 'archive.ubuntu.com' Err:2 http://security.ubuntu.com/ubuntu xenial-security InRelease Temporary failure resolving 'security.ubuntu.com' Err:3 http://archive.ubuntu.com/ubuntu xenial-updates InRelease Temporary failure resolving 'archive.ubuntu.com' Err:4 http://archive.ubuntu.com/ubuntu xenial-backports InRelease Temporary failure resolving 'archive.ubuntu.com' Reading package lists... W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial/InRelease Temporary failure resolving 'archive.ubuntu.com' W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial-updates/InRelease Temporary failure resolving 'archive.ubuntu.com' W: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial-backports/InRelease Temporary failure resolving 'archive.ubuntu.com' W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/xenial-security/InRelease Temporary failure resolving 'security.ubuntu.com' W: Some index files failed to download. They have been ignored, or old ones used instead. Reading package lists... Building dependency tree... Reading state information... E: Unable to locate package git E: Unable to locate package wget E: Unable to locate package python3-pip E: Unable to locate package python-setuptools E: Unable to locate package python3-nacl E: Unable to locate package apt-transport-https E: Unable to locate package ca-certificates E: Unable to locate package supervisor The command '/bin/sh -c apt-get update -y && apt-get install -y git wget python3.5 python3-pip python-setuptools python3-nacl apt-transport-https ca-certificates supervisor' returned a non-zero code: 100 ```

gudkov (Thu, 05 Apr 2018 10:43:05 GMT):
@mboyd Seems your docker can't resolve archive.ubuntu.com domain. Check the settings.

gudkov (Thu, 05 Apr 2018 10:44:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=i6ZAu3eFm3E3MRBtm) @mboyd indy-cli is available now in the master release channel only. It will be available in stable as part of the next stable release/

mboyd (Thu, 05 Apr 2018 16:59:05 GMT):
@gudkov Thank you, I was able to deploy a test network

turmewr3ck (Fri, 06 Apr 2018 08:58:18 GMT):
Is there any way of figuring out what is missing/wrong more specifically when I see this, "... .wallet.WalletValueNotFoundException: No value with the specified key exists in the wallet from which it was requested." from a call to Anoncreds.proverCreateAndStoreClaimReq?

lcinacio (Fri, 06 Apr 2018 09:54:11 GMT):
I have a question about how the proof generated by prover_create_proof is used by verifier_verify_proof: I am manually altering the proof and noticed that this causes the verification to fail if I modify the values in proofs.claim.primary_proof.eq_proof.revealed_attrs, but modifications in requested_proof.revealed_attrs are not detected and the verification still succeeds. I could encode the value (e.g. "Bachelor of Science, Marketing") and compare with the integer value (e.g. "636496963002215436589223990206471938837128904267588214790326222474754551276085597482569240298464443614107022172584074265522715728441215319094839"), but that means that the encoding algorithm would have to be known by the verifier. Is there another way of addressing this issue?

turmewr3ck (Fri, 06 Apr 2018 11:09:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=45Xqafms7ECYtuvyh) Sorry, I hadn't set the master secret in the wallet.

sklump (Fri, 06 Apr 2018 13:55:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ps2TduWBmsWvcqS8k) @turmewr3ck FWIW, that code less general than this update to it: https://github.com/PSPC-SPAC-buyandsell/von_agent/blob/94bf48155dcb2363e764aa1fea0e62d471d62a67/von_agent/util.py#L34

sklump (Fri, 06 Apr 2018 13:55:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ps2TduWBmsWvcqS8k) @turmewr3ck @tomislav FWIW, that code less general than this update to it: https://github.com/PSPC-SPAC-buyandsell/von_agent/blob/94bf48155dcb2363e764aa1fea0e62d471d62a67/von_agent/util.py#L34

sklump (Fri, 06 Apr 2018 14:00:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=AWRNTkFCXvxCbjf2j) @turmewr3ck Can also happen on some operations if the wallet is hanging around from a prior life of the node pool, since destroyed and resurrected from genesis transactions.

sergey.minaev (Fri, 06 Apr 2018 14:32:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kSomxMwpvnasDbMcD) @Artemkaaas @gudkov

hawkmauk (Fri, 06 Apr 2018 16:59:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=YWkDEWsAHbBNMfJTp) @srottem @DibbsZA Did you manage to compile libindy for arm? I'm just going to attempt this now so would be good to know how any previous attempts went

srottem (Fri, 06 Apr 2018 21:09:33 GMT):
No, I didn't try. Go for it!

b26 (Sat, 07 Apr 2018 21:21:21 GMT):
Has joined the channel.

b26 (Sat, 07 Apr 2018 21:21:59 GMT):
I'm a little confused about storing data in a DID. Do we store Data as MetaData?

b26 (Sat, 07 Apr 2018 21:23:13 GMT):
my understanding is you send a request to create a new decentralized identity with this model ``` { "did": string, "seed": string, "crypto_type": string, "cid": bool }```

b26 (Sat, 07 Apr 2018 21:23:53 GMT):
Once the identity is created, I think the only place to store data is as meta-data. Do I have the right understanding?

b26 (Sat, 07 Apr 2018 21:23:54 GMT):
Cheers

b26 (Sat, 07 Apr 2018 21:23:54 GMT):
Thank you very much

b26 (Sat, 07 Apr 2018 21:23:54 GMT):
Cheers

bjarny (Sun, 08 Apr 2018 00:51:00 GMT):
Has joined the channel.

mengyg (Sun, 08 Apr 2018 08:20:21 GMT):
Has joined the channel.

gudkov (Mon, 09 Apr 2018 10:03:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qHB4jnuHi9JP5Euca) @b26 What data do you want to store?

kosullivan_sita (Mon, 09 Apr 2018 11:41:24 GMT):
Has joined the channel.

esplinr (Mon, 09 Apr 2018 22:35:45 GMT):
Has joined the channel.

wuxingyi (Tue, 10 Apr 2018 01:33:53 GMT):
Has joined the channel.

wuxingyi (Tue, 10 Apr 2018 01:58:53 GMT):
hello guys, is there any progress for golang wrapper?

turmewr3ck (Tue, 10 Apr 2018 07:55:48 GMT):
The Anoncreds.proverGetClaimsForProofReq method (Java wrapper case) returns a set of claims for each individual attribute from the proof request (attrX_referent). A given claim entry, say attr1_referent, contains a schema_key, which again contains a schema name, version, and DID. I thought this DID would give the schema issuer, but it seems to give the claim (def?) issuer instead. Is that expected? Here I cannot use the claim issuer to find correct schemas to the verifier (via the proof), so what info can I use to find the schemas?

turmewr3ck (Tue, 10 Apr 2018 10:49:01 GMT):
Follow-up on the above: I guess what also tricks me here is the output of Anoncreds.proverGetClaimsForProofReq. Not sure how to process this in a general way. Any opinion on this aspect? For now I make use of the "restrictions" attribute in the proof request to simplify/filter the output of Anoncreds.proverGetClaimsForProofReq. That, however, requires that the verifier has a complete view of which schemas (including issuer DIDs) that are in use. Not unreasonable I suppose, but still the "restrictions" attribute is optional to use, and so I'm in doubt if a general proof verification algorithm can be made without using that attribute.

lcinacio (Tue, 10 Apr 2018 11:09:02 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=BqrMd3fcji86Tp8eE) @sergey.minaev @Artemkaaas @gudkov Hi guys. Any ideas about how to deal with this issue?

gudkov (Tue, 10 Apr 2018 15:48:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=BcfoxQAYQpEB4nXcN) Yes, Prover, Issuer and Verifier require agreement on encoding of attributes. For current moment it is completely up to application. In our roadmap we have plans to work on schemas enhancement. After implementing of this schema will define encoding and unit conversions rules.

b26 (Tue, 10 Apr 2018 17:18:34 GMT):
I'm having issues with this specific line of code ``` string applyForJobProof = await AnonCreds.ProverCreateProofAsync(alice.Wallet, jobApplicationProofRequestJSON, jobApplicationRequestedClaimsJSON, schemasJSON, aliceMasterSecret, claimsDefJSON, revocRegsJSON); ```

b26 (Tue, 10 Apr 2018 17:18:40 GMT):
its unclear which value is incorrect :(

b26 (Tue, 10 Apr 2018 17:20:09 GMT):
If someone is able to help, I would greatly appreciate it. I don't think its a good idea posting all the different parameters in this chat, it would be a large text file

b26 (Tue, 10 Apr 2018 17:21:33 GMT):
I tried running the python example in hopes to see what the request JSON is like, but I'm having issues even running the python getting_started file and don't have the motivation to debug right now. I've spent hours on that one statement

b26 (Tue, 10 Apr 2018 17:22:31 GMT):
I suppose, I could provide a pastebinUrl link for each parameter?

b26 (Tue, 10 Apr 2018 17:25:40 GMT):
here's the code https://pastebin.com/x14dKX80

swcurran (Tue, 10 Apr 2018 20:15:19 GMT):
@b26 - Is the error you are getting this one? ``` Hi all, has anyone run into the issue of receiving the error `Casting error to ErrorCode: Wallet not found: Wallet record is not found: query returned no rows` when calling `anoncreds. prover_create_proof `? ``` I'm not a developer, but our team has run into that one before. It basically means that at least one of the items needed for building the proof was not found in the wallet. However - there is no information logged about what was not found :-( A debugging approach is tracing back for how each of the arguments got into the wallet and looking to see if any didn't. As well, I believe our team in debugging things like this have extracted and reviewed the wallet contents to see what is and is not in the wallet. Hope that helps.

b26 (Tue, 10 Apr 2018 20:16:32 GMT):
interesting, I'll definitely look into that. Thank you very much @swcurran . I'll post my findings as soon as I figure it out :)

hawkmauk (Wed, 11 Apr 2018 07:41:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=S7hgyivgHw4yuNNCp) @srottem Still working on this :rolling_eyes: as it turns out cross-compiling not as straight forward as some of the Gentoo wiki pages make out - who would have thought?! Still I'm learning much so will document the process when (if!) I've had some success. I'm narrowing my search to compiling for Android which looks more promising

hawkmauk (Wed, 11 Apr 2018 07:43:22 GMT):
@srottem Still working on compiling libindy for Android :rolling_eyes: as it turns out cross-compiling not as straight forward as some of the Gentoo wiki pages make out - who would have thought?! Still I'm learning much so will document the process when (if!) I've had some success. I'm narrowing my search to compiling for Android which looks more promising

srottem (Wed, 11 Apr 2018 08:43:09 GMT):
Best of luck with it - out of my area of expertise, I'm afraid.

sklump (Wed, 11 Apr 2018 11:53:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ruMPeyNJ3Bc86oQWt) @gudkov This one little throw-away afterthought keeps on generating confusion. @lcinacio - encoding/decoding is arbitrary for the moment, as long as every possible value encodes to and decodes from non-negative integers, unambiguously. Feel free to take a look at `encode()`, `decode()` within `https://github.com/PSPC-SPAC-buyandsell/von_agent/blob/master/von_agent/util.py` for one approach. It is imperfect -- for example, a floating point would not be great here, as it would decode to a string.

sklump (Wed, 11 Apr 2018 11:53:40 GMT):
@lcinacio - encoding/decoding is arbitrary for the moment, as long as every possible value encodes to and decodes from non-negative integers, unambiguously. Feel free to take a look at `encode()`, `decode()` within `https://github.com/PSPC-SPAC-buyandsell/von_agent/blob/master/von_agent/util.py` for one approach. It is imperfect -- for example, a floating point would not be great here, as it would decode to a string.

lcinacio (Wed, 11 Apr 2018 16:30:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ruMPeyNJ3Bc86oQWt) @gudkov Thanks for the info. In the meantime I will have the verifier check the encoding of attributes on top of calling verifier_verify_proof.

lcinacio (Wed, 11 Apr 2018 16:32:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=7Ykd8Ny325ahqEtcG) @sklump Thanks for the link. I will take a look...

esplinr (Wed, 11 Apr 2018 17:18:57 GMT):
@b26 was your problem the one mentioned by @swcurran ? If that is a common problem, we can look to improve the logging there.

sklump (Wed, 11 Apr 2018 18:57:42 GMT):
Quick question: does the indy-sdk team have a forecast as to when the changes of branch 'feature/revocation' (https://github.com/hyperledger/indy-sdk/tree/feature/revocation) might merge back into master? It represents some significant change to the model and it would help us in planning.

esplinr (Wed, 11 Apr 2018 22:33:28 GMT):
@sklump I'll have to ask the team about that tomorrow.

esplinr (Wed, 11 Apr 2018 22:33:34 GMT):
(Unless one of them answer.)

gudkov (Thu, 12 Apr 2018 06:59:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=SMTfe6pCTasTDwn3v) @sklump We hope today

MyMate (Thu, 12 Apr 2018 09:27:33 GMT):
Has joined the channel.

sklump (Thu, 12 Apr 2018 12:45:36 GMT):
Today for a forecast, or today for a merge? _(I imagine, a forecast today -- it looks like a very tricky merge)_

gudkov (Thu, 12 Apr 2018 13:16:02 GMT):
Just merged

gudkov (Thu, 12 Apr 2018 13:16:17 GMT):
Waiting for new master binary artifacts

brentzundel (Thu, 12 Apr 2018 15:34:57 GMT):
Has joined the channel.

brentzundel (Thu, 12 Apr 2018 15:35:49 GMT):
Is there a better way to get a PR review than simply making a pull request?

esplinr (Thu, 12 Apr 2018 15:44:06 GMT):
@brentzundel Are you looking for feedback in advance of your PR, or are you trying to get your PR reviewed quicker than the normal PR queue?

brentzundel (Thu, 12 Apr 2018 15:45:06 GMT):
I'm not looking for anything special, I just made a pull request and wasn't sure if there was another step I needed to make to get it reviewed.

gudkov (Thu, 12 Apr 2018 15:45:18 GMT):
Libindy test cases that explains complete credentials revocation workflow: Python: https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/tests/interation/interaction.py Rust: https://github.com/hyperledger/indy-sdk/blob/master/libindy/tests/interaction.rs Java: https://github.com/hyperledger/indy-sdk/blob/master/wrappers/java/src/test/java/org/hyperledger/indy/sdk/interaction/AnoncredsRevocationInteractionTest.java Revocation related samples: https://github.com/hyperledger/indy-sdk/blob/master/samples/python/src/anoncreds_revocation.py https://github.com/hyperledger/indy-sdk/blob/master/samples/java/src/main/java/AnoncredsRevocation.java

danielhardman (Thu, 12 Apr 2018 16:00:57 GMT):
Here are the developer tutorials done so far: https://github.com/hyperledger/indy-sdk/tree/master/doc/how-tos. Mixture of python and Java (some of each). The "prerequisites" link is currently broken but is essentially a placeholder for instructions on A) how to compile or install libindy; and B) how to start an indy validator pool in docker. Both of these are covered in the main readme at https://github.com/hyperledger/indy-sdk/

tomislav (Thu, 12 Apr 2018 16:05:15 GMT):
So many new changes! Any ETA on the ios wrapper updates?

codenamedmitri (Thu, 12 Apr 2018 16:18:12 GMT):
where is the source code for the Node.js SDK wrapper? I see the npm package, just curious where the code is

tomislav (Thu, 12 Apr 2018 16:21:06 GMT):
PR is still open https://github.com/hyperledger/indy-sdk/pull/616

codenamedmitri (Thu, 12 Apr 2018 16:21:24 GMT):
*ahaa*

codenamedmitri (Thu, 12 Apr 2018 16:21:24 GMT):
ahaa

tomislav (Thu, 12 Apr 2018 16:22:39 GMT):
Source code at https://github.com/Picolab/indy-sdk/tree/master/wrappers/nodejs

codenamedmitri (Thu, 12 Apr 2018 16:23:21 GMT):
brilliant.

esplinr (Thu, 12 Apr 2018 16:57:48 GMT):
@brentzundel Thanks for the pull request! We'll review it during our next triage.

codenamedmitri (Thu, 12 Apr 2018 18:50:30 GMT):
@danielhardman oh hey, is there a link to that MIT hackathon that was mentioned on the call?

danielhardman (Thu, 12 Apr 2018 20:05:55 GMT):
@codenamedmitri I don't know about the MIT hackathon. I just got done with a hackathon in Holland. It was someone else that mentioned the hackathon at MIT. Maybe @Sean_Bohan remembers who?

Sean_Bohan (Thu, 12 Apr 2018 21:15:18 GMT):
YES - will get details and post here and the Indy and Identity-wg channels

tomislav (Thu, 12 Apr 2018 21:39:21 GMT):
Under the old API, a prover could store an offer and a claim. This is no longer the case, only the claim (credential) can be stored. Is storing the offer coming back or it's no longer part of the design

codenamedmitri (Thu, 12 Apr 2018 23:16:52 GMT):
@danielhardman @Sean_Bohan thanks! :)

danielhardman (Thu, 12 Apr 2018 23:50:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=2v95936zYBQXsAe8D) @tomislav The latest wallet design proposal that I know about allows for the storing of abitrary data in a wallet--as long as that data is small and sensitive. The thinking is documented in this PR: https://github.com/hyperledger/indy-sdk/pull/564. So: if this PR is accepted, it should be possible to store an offer in a wallet. However, I feel like you should think hard about the wisdom of doing so. Credential offers are repudiable by design, and thus do not represent commitments to data. Also, wallets should not become general databases; they are for storing just those pieces of data that comprise your identity. For more on the philosophy of wallets, see https://docs.google.com/presentation/d/1X6F9QVG8M4PqQQLLL_5I6aQ5z7CCpYyYHBNKYMlsqXc/edit?usp=sharing

tomislav (Fri, 13 Apr 2018 01:57:52 GMT):
Thank you @danielhardman This actually simplifies things.

malvikam (Fri, 13 Apr 2018 22:47:10 GMT):
When a request created using indy_build_get_ddo_request() is submitted using indy_sign_and_submit_request() or indy_submit_request(), it fails with error: "reason":"client request invalid: InvalidClientRequest('invalid type: 120',)". Can anyone help?

chriswinc (Sat, 14 Apr 2018 14:12:58 GMT):
Has joined the channel.

lcinacio (Sun, 15 Apr 2018 16:01:51 GMT):
Hi. I cloned the latest indy-sdk repository on github and when running the docker-compose setup in doc/getting-started I get an error " File "/usr/local/lib/python3.5/dist-packages/plenum/server/notifier_plugin_manager.py", line 131, in _findPlugins for pkg in pip.utils.get_installed_distributions() AttributeError: module 'pip' has no attribute 'utils'" in /etc/node*.log

peacekeeper (Sun, 15 Apr 2018 17:49:33 GMT):
``` Traceback (most recent call last): File "/usr/local/bin/start_indy_node", line 6, in from indy_node.utils.node_runner import run_node File "/usr/local/lib/python3.5/dist-packages/indy_node/utils/node_runner.py", line 10, in from indy_node.server.node import Node File "/usr/local/lib/python3.5/dist-packages/indy_node/server/node.py", line 15, in from plenum.server.node import Node as PlenumNode File "/usr/local/lib/python3.5/dist-packages/plenum/server/node.py", line 69, in from plenum.server.monitor import Monitor File "/usr/local/lib/python3.5/dist-packages/plenum/server/monitor.py", line 26, in pluginManager = PluginManager() File "/usr/local/lib/python3.5/dist-packages/plenum/server/notifier_plugin_manager.py", line 35, in __init__ self.importPlugins() File "/usr/local/lib/python3.5/dist-packages/plenum/server/notifier_plugin_manager.py", line 102, in importPlugins plugins = self._findPlugins() File "/usr/local/lib/python3.5/dist-packages/plenum/server/notifier_plugin_manager.py", line 131, in _findPlugins for pkg in pip.utils.get_installed_distributions() AttributeError: module 'pip' has no attribute 'utils' ```

peacekeeper (Sun, 15 Apr 2018 17:49:33 GMT):
Any idea where this comes from when trying to buid and run the latest `indy_pool` Docker image? ``` Traceback (most recent call last): File "/usr/local/bin/start_indy_node", line 6, in from indy_node.utils.node_runner import run_node File "/usr/local/lib/python3.5/dist-packages/indy_node/utils/node_runner.py", line 10, in from indy_node.server.node import Node File "/usr/local/lib/python3.5/dist-packages/indy_node/server/node.py", line 15, in from plenum.server.node import Node as PlenumNode File "/usr/local/lib/python3.5/dist-packages/plenum/server/node.py", line 69, in from plenum.server.monitor import Monitor File "/usr/local/lib/python3.5/dist-packages/plenum/server/monitor.py", line 26, in pluginManager = PluginManager() File "/usr/local/lib/python3.5/dist-packages/plenum/server/notifier_plugin_manager.py", line 35, in __init__ self.importPlugins() File "/usr/local/lib/python3.5/dist-packages/plenum/server/notifier_plugin_manager.py", line 102, in importPlugins plugins = self._findPlugins() File "/usr/local/lib/python3.5/dist-packages/plenum/server/notifier_plugin_manager.py", line 131, in _findPlugins for pkg in pip.utils.get_installed_distributions() AttributeError: module 'pip' has no attribute 'utils' ```

peacekeeper (Sun, 15 Apr 2018 17:49:33 GMT):
Any idea where this comes from when trying to build and run the latest `indy_pool` Docker image? ``` Traceback (most recent call last): File "/usr/local/bin/start_indy_node", line 6, in from indy_node.utils.node_runner import run_node File "/usr/local/lib/python3.5/dist-packages/indy_node/utils/node_runner.py", line 10, in from indy_node.server.node import Node File "/usr/local/lib/python3.5/dist-packages/indy_node/server/node.py", line 15, in from plenum.server.node import Node as PlenumNode File "/usr/local/lib/python3.5/dist-packages/plenum/server/node.py", line 69, in from plenum.server.monitor import Monitor File "/usr/local/lib/python3.5/dist-packages/plenum/server/monitor.py", line 26, in pluginManager = PluginManager() File "/usr/local/lib/python3.5/dist-packages/plenum/server/notifier_plugin_manager.py", line 35, in __init__ self.importPlugins() File "/usr/local/lib/python3.5/dist-packages/plenum/server/notifier_plugin_manager.py", line 102, in importPlugins plugins = self._findPlugins() File "/usr/local/lib/python3.5/dist-packages/plenum/server/notifier_plugin_manager.py", line 131, in _findPlugins for pkg in pip.utils.get_installed_distributions() AttributeError: module 'pip' has no attribute 'utils' ```

sugarcookie (Mon, 16 Apr 2018 04:06:13 GMT):
Has joined the channel.

sugarcookie (Mon, 16 Apr 2018 04:09:46 GMT):
I am running python indy-sdk from mac Docker pooling, I am running the one on indy-node, as indy-sdk one does not work for mac (https://github.com/hyperledger/indy-node/blob/master/environment/docker/pool/README.md) Then I run main.py under samples/python/src, got below error, do you know why? Sherrys-MacBook-Air:src app$ python3 main.py INFO:src.anoncreds:Anoncreds sample -> started ERROR:indy.libindy:_load_cdll: Can’t load libindy: dlopen(libindy.dylib, 6): image not found Traceback (most recent call last): File “main.py”, line 20, in loop.run_until_complete(main()) File “/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/base_events.py”, line 468, in run_until_complete return future.result() File “main.py”, line 13, in main await anoncreds.demo() File “/Users/app/desktop/blockchain/indy-sdk/samples/python/src/anoncreds.py”, line 27, in demo await wallet.create_wallet(pool_name, issuer_wallet_name, None, None, None) File “/Users/app/desktop/blockchain/indy-sdk/wrappers/python/indy/wallet.py”, line 52, in create_wallet create_wallet.cb) File “/Users/app/desktop/blockchain/indy-sdk/wrappers/python/indy/libindy.py”, line 24, in do_call err = getattr(_cdll(), name)(command_handle, File “/Users/app/desktop/blockchain/indy-sdk/wrappers/python/indy/libindy.py”, line 90, in _cdll _cdll.cdll = _load_cdll() File “/Users/app/desktop/blockchain/indy-sdk/wrappers/python/indy/libindy.py”, line 121, in _load_cdll raise e File “/Users/app/desktop/blockchain/indy-sdk/wrappers/python/indy/libindy.py”, line 116, in _load_cdll res = CDLL(libindy_name) File “/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ctypes/init.py”, line 348, in init self._handle = _dlopen(self._name, mode) OSError: dlopen(libindy.dylib, 6): image not found I am running python indy-sdk from mac Docker pooling, I am running the one on indy-node, as indy-sdk one does not work for mac (https://github.com/hyperledger/indy-node/blob/master/environment/docker/pool/README.md) Then I run main.py under samples/python/src, got below error, do you know why? Sherrys-MacBook-Air:src app$ python3 main.py INFO:src.anoncreds:Anoncreds sample -> started ERROR:indy.libindy:_load_cdll: Can’t load libindy: dlopen(libindy.dylib, 6): image not found Traceback (most recent call last): File “main.py”, line 20, in loop.run_until_complete(main()) File “/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/base_events.py”, line 468, in run_until_complete return future.result() File “main.py”, line 13, in main await anoncreds.demo() File “/Users/app/desktop/blockchain/indy-sdk/samples/python/src/anoncreds.py”, line 27, in demo await wallet.create_wallet(pool_name, issuer_wallet_name, None, None, None) File “/Users/app/desktop/blockchain/indy-sdk/wrappers/python/indy/wallet.py”, line 52, in create_wallet create_wallet.cb) File “/Users/app/desktop/blockchain/indy-sdk/wrappers/python/indy/libindy.py”, line 24, in do_call err = getattr(_cdll(), name)(command_handle, File “/Users/app/desktop/blockchain/indy-sdk/wrappers/python/indy/libindy.py”, line 90, in _cdll _cdll.cdll = _load_cdll() File “/Users/app/desktop/blockchain/indy-sdk/wrappers/python/indy/libindy.py”, line 121, in _load_cdll raise e File “/Users/app/desktop/blockchain/indy-sdk/wrappers/python/indy/libindy.py”, line 116, in _load_cdll res = CDLL(libindy_name) File “/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ctypes/init.py”, line 348, in init self._handle = _dlopen(self._name, mode) OSError: dlopen(libindy.dylib, 6): image not found hi, I am using mac, when running samples under indy-sdk python folder, I got below error

sugarcookie (Mon, 16 Apr 2018 04:09:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nLAx89JQbDqyPaByA) @gudkov Hi gudkov, thank you so much, I did build libindy using cargo build, it says Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs

sugarcookie (Mon, 16 Apr 2018 04:09:49 GMT):

Clipboard - April 16, 2018 12:09 AM

sugarcookie (Mon, 16 Apr 2018 04:11:26 GMT):
wonder whether anybody get is work in MAC, even when testing indy-node-master, I am able to create pool using docker, follow the indy commend lines, but agent and user can not communicate

SanketPanchamia (Mon, 16 Apr 2018 05:20:19 GMT):
Has joined the channel.

gudkov (Mon, 16 Apr 2018 09:47:52 GMT):
@sugarcookie To run samples you need: 1. Run indy pool with compatible way. Instruction is here: https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker. Not that the fact that you executed local pool with some instruction in Indy Node repo doesn't mean that you can use it to run tests as pools must be compatible by initial records and ip addresses. Indy SDK provides instruction of execution of compatible pool. 2. Install libindy. See: https://github.com/hyperledger/indy-sdk#install-for-macos 3. Run samples

gudkov (Mon, 16 Apr 2018 09:48:51 GMT):
@sugarcookie > OSError: dlopen(libindy.dylib, 6): image not found This error just means that you don't have libindy isntalled. You have to build and install it.

gudkov (Mon, 16 Apr 2018 11:20:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=AZoRujRYqhKHK6aun) @peacekeeper Pip was updated to version 10 today with breaking changes. The version wasn't fixed in scripts. Team is working on fix.

SanketPanchamia (Mon, 16 Apr 2018 13:30:20 GMT):
Hi All, I am new to Hyperledger Indy and was trying to run indy locally using docker. The tutorial i am following is here https://github.com/hyperledger/indy-sdk and I am using cli to run the Alice tutorial but I am not sure how to create a pool using a genesis txn file using docker. Can someone point me to how that needs to be done and how do i setup a wallet then?

sklump (Mon, 16 Apr 2018 14:30:17 GMT):
I notice that in indy-sdk's master branch, under the new revocation model, the `ci/indy-pool.dockerfile` has: ``` ARG indy_plenum_ver=1.2.38 ARG indy_anoncreds_ver=1.0.11 ARG indy_node_ver=1.3.56 ARG python3_indy_crypto_ver=0.2.0 ARG indy_crypto_ver=0.1.6 ``` which represents (mostly) a significant back-dating from prior iterations (e.g., 1.3.1-dev-440) ``` ARG indy_plenum_ver=1.2.237 ARG indy_anoncreds_ver=1.0.32 ARG indy_node_ver=1.2.297 ARG python3_indy_crypto_ver=0.2.0 ARG indy_crypto_ver=0.2.0 ``` and rolls back months-prior changes from `loglevel` to `logLevel`. Is this possibly a missed side-effect artifact of a complicated merge? Understand, my intent is to flag something that might be a source of problems in case it might help.

sklump (Mon, 16 Apr 2018 14:30:17 GMT):
I notice that in indy-sdk's master branch (==1.3.1-dev-470),the `ci/indy-pool.dockerfile` has: ``` ARG indy_plenum_ver=1.2.38 ARG indy_anoncreds_ver=1.0.11 ARG indy_node_ver=1.3.56 ARG python3_indy_crypto_ver=0.2.0 ARG indy_crypto_ver=0.1.6 ``` which represents (mostly) a significant back-dating from prior iterations (e.g., 1.3.1-dev-441) ``` ARG indy_plenum_ver=1.2.237 ARG indy_anoncreds_ver=1.0.32 ARG indy_node_ver=1.2.297 ARG python3_indy_crypto_ver=0.2.0 ARG indy_crypto_ver=0.2.0 ``` and rolls back months-prior changes from `loglevel` to `logLevel`. Is this possibly a missed side-effect artifact of a complicated merge? Understand, my intent is to flag something that might be a source of problems in case it might help.

sklump (Mon, 16 Apr 2018 14:30:17 GMT):
I notice that in indy-sdk's master branch (==1.3.1-dev-470),the `ci/indy-pool.dockerfile` has: ``` ARG indy_plenum_ver=1.2.38 ARG indy_anoncreds_ver=1.0.11 ARG indy_node_ver=1.3.56 ARG python3_indy_crypto_ver=0.2.0 ARG indy_crypto_ver=0.1.6 ``` which represents (mostly) a significant back-dating from prior iterations (e.g., 1.3.1-dev-441) ``` ARG indy_plenum_ver=1.2.237 ARG indy_anoncreds_ver=1.0.32 ARG indy_node_ver=1.2.297 ARG python3_indy_crypto_ver=0.2.0 ARG indy_crypto_ver=0.2.0 ``` and rolls back months-prior changes from `logLevel` to `loglevel` etc. Is this possibly a missed side-effect artifact of a complicated merge? Understand, my intent is to flag something that might be a source of problems in case it might help.

mgbailey (Mon, 16 Apr 2018 21:31:13 GMT):
@malvikam This looks like it may be a problem with the inputs to the indy_sign_and_submit_request call. What is the requestJson and other inputs? @gudkov . can you take a look at this?

malvikam (Mon, 16 Apr 2018 21:36:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=hcXrssp4CXhJspcbP) @mgbailey @gudkov The request JSON looks like this: {"reqId":1523912078584412900,"identifier":"TTQMzH5FkGdbHuSygCWsok","operation":{"type":"120","dest":"WCTWAkJD8FoP35z4WcHfvc"},"protocolVersion":1} and response JSON from sign_and_submit_request call is : {"reqId":1523912078584412900,"identifier":"TTQMzH5FkGdbHuSygCWsok","operation":{"type":"120","dest":"WCTWAkJD8FoP35z4WcHfvc"},"protocolVersion":1}. We are testing on STN.

malvikam (Mon, 16 Apr 2018 21:36:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=hcXrssp4CXhJspcbP) @mgbailey @gudkov The parameters for sign_and_submit_request() are pretty straightforward- poolHandle=2, walletHandle=3, submitterDid ="TTQMzH5FkGdbHuSygCWsok" , and the request object from the indy_build_get_nym_request()= {"reqId":1523912078584412900,"identifier":"TTQMzH5FkGdbHuSygCWsok","operation":{"type":"120","dest":"WCTWAkJD8FoP35z4WcHfvc"},"protocolVersion":1} . The response JSON from sign_and_submit_request = {"reqId":1523912078584412900,"identifier":"TTQMzH5FkGdbHuSygCWsok","operation":{"type":"120","dest":"WCTWAkJD8FoP35z4WcHfvc"},"protocolVersion":1}. We are testing on STN.

malvikam (Mon, 16 Apr 2018 21:36:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=hcXrssp4CXhJspcbP) @mgbailey @gudkov The parameters for sign_and_submit_request() are pretty straightforward- poolHandle=2, walletHandle=3, submitterDid ="TTQMzH5FkGdbHuSygCWsok" , and the request object from the indy_build_get_nym_request()= {"reqId":1523912078584412900,"identifier":"TTQMzH5FkGdbHuSygCWsok","operation":{"type":"120","dest":"WCTWAkJD8FoP35z4WcHfvc"},"protocolVersion":1} . The response JSON from sign_and_submit_request = {"op":"REQNACK","identifier":"TTQMzH5FkGdbHuSygCWsok","reason":"client request invalid: InvalidClientRequest('invalid type: 120',)","reqId":1523916000878516400}. We are testing on STN.

ryanwest6 (Tue, 17 Apr 2018 01:40:11 GMT):
Has joined the channel.

sugarcookie (Tue, 17 Apr 2018 04:23:23 GMT):
I start docker following this file https://github.com/hyperledger/indy-node/blob/master/environment/docker/pool/README.md, using the code under indy-node-master instead of indy-sdk, assuming it is ok

sugarcookie (Tue, 17 Apr 2018 04:23:23 GMT):
@gudkov I start docker following this file https://github.com/hyperledger/indy-node/blob/master/environment/docker/pool/README.md, using the code under indy-node-master instead of indy-sdk, assuming it is ok, but it still says OSError: dlopen(libindy.dylib, 6): image not found, when I run python3 main.py under python samples, any idea what is missing?

sugarcookie (Tue, 17 Apr 2018 05:29:31 GMT):
@gudkov I am thinking maybe mac somehow can not find libindy I installed, is there other path setting other than the one in this dochttps://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md?

sugarcookie (Tue, 17 Apr 2018 05:43:46 GMT):
@gudkov oh I saw this :mountain_bicyclist_tone5: Install for MacOS Now we haven't prebuild library in some shared place. You can build library yourself. Please refer to How-to-build section. After build add to LD_LIBRARY_PATH and to DYLD_LIBRARY_PATH environment variables path to builded library. It's necessary for dynamic linkage your application with libindy. At first dynamic linker browse library in LD_LIBRARY_PATH, if library in your application doesn't include directory names. If library in your application include any directory name, then dynamic linker will search library in DYLD_LIBRARY_PATH(not LD_LIBRARY_PATH). So for reliability we recommend you set both this variables.

sugarcookie (Tue, 17 Apr 2018 06:01:33 GMT):
@gudkov so I add to path, now I get this error

sugarcookie (Tue, 17 Apr 2018 06:01:33 GMT):
@gudkov so I add to path, now I get this error, no suitable image, any idea?

sugarcookie (Tue, 17 Apr 2018 06:01:37 GMT):

Clipboard - April 17, 2018 2:01 AM

mawi (Tue, 17 Apr 2018 07:25:58 GMT):
Is there any code available for a test agent? My team would like to simulate processing connecting requests and some agent-2-agent communication. We have a client setup in CLI and validator nodes in aws, but we rather not setup an agent for the CLI to communicate with. I couldn't find it in the indy-sdk repo.

mawi (Tue, 17 Apr 2018 07:25:58 GMT):
Is there any code available for a test agent? My team would like to simulate processing connection requests and some agent-2-agent communication. We have a client setup in CLI and validator nodes in aws, but we rather not setup an agent for the CLI to communicate with. I couldn't find it in the indy-sdk repo.

SanketPanchamia (Tue, 17 Apr 2018 09:13:24 GMT):
Hi, I am following this guide https://github.com/hyperledger/indy-sdk to run indy locally using docker I need help running the commands through indy cli after I did this https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker After running the docker scripts, i see the indy_pool container running. After that i installed indy-cli and tried to run it in interactive mode. I am a little unaware what needs to be done after that to run the Alice example. I am not sure of the path to the gen_txn_file file. Can someone please guide me as to what are the next steps? Am i missing any steps?

gudkov (Tue, 17 Apr 2018 09:18:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=B5NDcv37dXNDtfiH7) @SanketPanchamia > I am a little unaware what needs to be done after that to run the Alice example. What exact sample you mean? Getting-started guide for Indy SDK is placed here: https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md It is uses indy sdk only. You don't need indy-cli to run it. > I am not sure of the path to the gen_txn_file file. You

sergey.minaev (Tue, 17 Apr 2018 09:19:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=8JS7KaR6mYWSxtDBs) @sklump please see https://github.com/hyperledger/indy-sdk/pull/655/files#diff-9365981c04c66c3d24d5cd3af1dfb96a 470 master of sdk depends on RC of indy-node/plenum. And 1.2.38 rc of plenum is greater rather 1.2.237 master of plenum. @ashcherbakov please correct me about node/plenum versions if needed.

gudkov (Tue, 17 Apr 2018 09:31:12 GMT):
Current indy cli doesn't force any agent concept. I suggest look to how-to that describes how to exchange secure message between agents https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/send-secure-msg/README.md [ ](https://chat.hyperledger.org/channel/indy-sdk?msg=dEoGmQwLbw8259EAS) @mawi

SanketPanchamia (Tue, 17 Apr 2018 09:32:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6JQxTvpbMt4Ghgg8H) @gudkov Thanks. So if i need to run the sample that you pointed, all i need is the indy-sdk? But how do i run these commands to connect to the indy nodes pool https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md#step-2-connecting-to-the-indy-nodes-pool

gudkov (Tue, 17 Apr 2018 09:33:32 GMT):
@SanketPanchamia There is a section https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/run-getting-started.md that can help you

gudkov (Tue, 17 Apr 2018 09:35:22 GMT):
If you need to run sample on your machine. You need: - Run pool with docker - Install libindy (check instruction for your platform) - Install python - Run samples

SanketPanchamia (Tue, 17 Apr 2018 09:38:42 GMT):
@gudkov When i run docker-compose up i get an error ERROR: Pool overlaps with other one on this address space.

gudkov (Tue, 17 Apr 2018 09:39:23 GMT):
Seems you don't have clean environment

gudkov (Tue, 17 Apr 2018 09:39:36 GMT):
stop all containers

SanketPanchamia (Tue, 17 Apr 2018 09:42:05 GMT):

Clipboard - April 17, 2018 3:12 PM

SanketPanchamia (Tue, 17 Apr 2018 09:42:07 GMT):
i did that and still the same error

gudkov (Tue, 17 Apr 2018 10:13:07 GMT):
@SanketPanchamia > The validators run by default on IP 10.0.0.2, this can be changed by changing pool_ip in the docker-compose file. Most probably 10.0.0.2 ip is already used in your system. Try to change it

SanketPanchamia (Tue, 17 Apr 2018 11:09:24 GMT):
Thanks @gudkov . I will try this on a fresh VM and see what happens. Will keep you posted

sklump (Tue, 17 Apr 2018 11:37:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=zmhFkgFPRhrqijiFj) @sergey.minaev I think the `doc/how-tos/python/` samples got left behind in the merge -- they import and use `signus` instead of `did`, whereas `wrappers/python/indy/` has `did.py`. Sorry if I'm being obtuse. Evidently I'm having a hard time figuring out what version I am supposed to be on.

sergey.minaev (Tue, 17 Apr 2018 12:24:15 GMT):
@sklump yes, how-tos are out-date after `feature/revocation` merge. @gudkov has information about assigned peoples to fix it.

sugarcookie (Tue, 17 Apr 2018 12:49:06 GMT):

Clipboard - April 17, 2018 8:49 AM

sugarcookie (Tue, 17 Apr 2018 12:49:13 GMT):
Hi @gudkov any tips on my error?

gudkov (Tue, 17 Apr 2018 12:56:44 GMT):
@sugarcookie I suggest you provide us exact list of steps and commands you performed. I see that you have some errors, but i don't have any context here.

sugarcookie (Tue, 17 Apr 2018 12:57:55 GMT):
build libindy for mac https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md

sugarcookie (Tue, 17 Apr 2018 12:58:45 GMT):
add libindy.dylib path to DYLD_LIBRARY_PATH and LD_LIBRARY_PATH

sugarcookie (Tue, 17 Apr 2018 12:59:23 GMT):
run docker, run python sample main.py

sugarcookie (Tue, 17 Apr 2018 13:00:26 GMT):
so day before I got message dlopen() no image fund, yesterday I set up path, got different error no suitable image found, did fund the one I set up path

sugarcookie (Tue, 17 Apr 2018 13:00:42 GMT):
something related to libindy not work right somehow

sugarcookie (Tue, 17 Apr 2018 13:10:13 GMT):
@gudkov wait, i think I found out, the path should not include the file name...........thanks! might have other questions later on

smithbk (Tue, 17 Apr 2018 21:08:34 GMT):
There seems to be an inconsistency in https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md in that it says ```Becoming a Trust Anchor requires contacting a person or organization who already has the Trust Anchor role on the ledger.``` which implies that a trust anchor can add a trust anchor, but https://docs.google.com/spreadsheets/d/1TWXF7NtBjSOaUIBeIH77SyZnawfo91cJ_ns4TR-wsq4/edit#gid=0 says otherwise. I assume the later is correct?

smithbk (Tue, 17 Apr 2018 22:09:01 GMT):
Another question ... in the getting started doc, it has ```# Faber Agent (faber_transcript_cred_def_id, faber_transcript_cred_def_json) = \ await anoncreds.issuer_create_and_store_credential_def(faber_wallet, faber_did, transcript_schema, 'TAG1', 'CL', '{"support_revocation": false}')```My question is about the last arg with "support_revocation" set to false. This seems to imply that revocation is not request/supported. But the python comment for `config_json` says ```- support_revocation: whether to request non-revocation credential (optional, default false)```which is not requesting non-revocation. What is a `non-revocation credential` exactly? If it is set to false, does this mean that it can be revoked? Thanks in advance for any details on this.

smithbk (Tue, 17 Apr 2018 22:09:01 GMT):
Another question ... in the getting started doc, it has ```# Faber Agent (faber_transcript_cred_def_id, faber_transcript_cred_def_json) = \ await anoncreds.issuer_create_and_store_credential_def(faber_wallet, faber_did, transcript_schema, 'TAG1', 'CL', '{"support_revocation": false}')```My question is about the last arg with "support_revocation" set to false. This seems to imply that revocation is not request/supported. But the python comment for `config_json` says ```- support_revocation: whether to request non-revocation credential (optional, default false)``` which is not requesting non-revocation. What is a `non-revocation credential` exactly? If it is set to false, does this mean that it can be revoked? Thanks in advance for any details on this.

sugarcookie (Wed, 18 Apr 2018 03:07:23 GMT):
Hi @gudkov now I started getting PoolLedgerTimeOut error, so I read document How to start local nodes pool with docker Start local nodes pool on 127.0.0.1:9701-9708 with Docker: docker build -f ci/indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9708:9701-9708 indy_pool Dockerfile ci/indy-pool.dockerfile supports optional pool_ip param that allows changing ip of pool nodes in generated pool configuration. The following commands allow to start local nodes pool in custom docker network and access this pool by custom ip in docker network: docker network create --subnet 10.0.0.0/8 indy_pool_network docker build --build-arg pool_ip=10.0.0.2 -f ci/indy-pool.dockerfile -t indy_pool . docker run -d --ip="10.0.0.2" --net=indy_pool_network indy_pool Note that for Windows and MacOS this approach has some issues. Docker for these OS run in their virtual environment. First command creates network for container and host can't get access to that network because container placed on virtual machine. You must appropriate set up networking on your virtual environment.

sugarcookie (Wed, 18 Apr 2018 03:08:13 GMT):
it says does not work for mac, can you give me more details about what should be the setting if run docker on Mac?

gudkov (Wed, 18 Apr 2018 06:56:04 GMT):
@sugarcookie See this PR https://github.com/hyperledger/indy-sdk/pull/632/files for instruction

sklump (Wed, 18 Apr 2018 11:01:49 GMT):
I see that in master, the `ledger.build_schema_request()` call's `data` parameter now takes schema `version` and (new) `ver` for the "Version of the Schema json". What is the difference between the version of the schema json that could be distinct for a given version of the schema itself? Any idea what the use case for this item could be?

sklump (Wed, 18 Apr 2018 11:01:49 GMT):
I see that in master, the `ledger.build_schema_request()` call's `data` parameter now takes schema `version` and (new) `ver` for the "Version of the Schema json". What could be in the version of the schema JSON, distinct from the version of the schema itself? Any idea what the use case for this item could be?

sklump (Wed, 18 Apr 2018 11:01:49 GMT):
I see that in master, the `ledger.build_schema_request()` call's `data` parameter now takes schema `version` and (new) `ver` for the "Version of the Schema json". What could be in the version of the schema JSON, distinct from the version of the schema itself? Any idea what the use case for this item could be? (Similarly, credential definitions also have a `ver`, presumably for the same purpose)

sklump (Wed, 18 Apr 2018 11:01:49 GMT):
~I see that in master, the `ledger.build_schema_request()` call's `data` parameter now takes schema `version` and (new) `ver` for the "Version of the Schema json".~ ~What could be in the version of the schema JSON, distinct from the version of the schema itself? Any idea what the use case for this item could be?~ ~(Similarly, credential definitions also have a `ver`, presumably for the same purpose)~ _*UPDATE: `ver` appears to mean the version of the data format on the ledger -- new calls `ledger.parse...()` are important_

sugarcookie (Wed, 18 Apr 2018 13:02:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6Fqeb9XC5CF73rNaY) @gudkov thank you, let me try

sugarcookie (Wed, 18 Apr 2018 13:18:51 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=L6k7mn5ePnBxsEtgH) just to confirm, map 9701-9709 container ports to local 9701-9709 ports is map 10.0.0.0 to 127.0.0.1? something like this?

sklump (Wed, 18 Apr 2018 13:28:12 GMT):
*Item:* the indy-sdk now appears to enforce the `role` of a submitter's nym in policing ledger transactions; the options are `null`, `TRUSTEE`, `STEWARD`, `TRUST_ANCHOR`. *Observation:* the default (`null`) role is insufficient to write a new schema to the ledger, but all other choices have powers far too broad for an agent whose role is only to originate schemata, not to anchor further new agents onto the ledger. *Question:* what is the correct role to assign to a schema originator? *Bonus question:* What is the correct role to assign to a credential Issuer agent (which writes credential definitions to the ledger)?

sklump (Wed, 18 Apr 2018 13:28:12 GMT):
*Item:* the indy-sdk now appears to enforce the `role` of a submitter's nym in policing ledger transactions; the options are `null`, `TRUSTEE`, `STEWARD`, `TRUST_ANCHOR`. *Observation:* the default `null` role is insufficient to write a new schema to the ledger, but all other choices have powers far too broad for an agent whose role is only to originate schemata, not to anchor further new agents onto the ledger. *Question:* what is the correct role to assign to a schema originator? *Bonus question:* What is the correct role to assign to a credential Issuer agent (which writes credential definitions to the ledger)?

sklump (Wed, 18 Apr 2018 13:28:12 GMT):
*Item:* the indy-sdk now appears to enforce the `role` of a submitter's nym in policing ledger transactions; the options are `null`, `TRUSTEE`, `STEWARD`, `TRUST_ANCHOR`. *Observation:* the default `null` role is insufficient to write a new schema to the ledger, but all other choices have powers far too broad for an agent whose role is only to originate schemata, not to anchor further new agents onto the ledger. *Question:* what is the correct role to assign to a schema originator? *Bonus question:* What is the correct role to assign to a credential Issuer agent (which writes credential definitions to the ledger)? _update: `STEWARD` works OK to send a schema ... _

sklump (Wed, 18 Apr 2018 13:28:12 GMT):
*Item:* the indy-sdk now appears to enforce the `role` of a submitter's nym in policing ledger transactions; the options are `null`, `TRUSTEE`, `STEWARD`, `TRUST_ANCHOR`. *Observation:* the default `null` role is insufficient to write a new schema to the ledger, but all other choices have powers far too broad for an agent whose role is only to originate schemata, not to anchor further new agents onto the ledger. *Question:* what is the correct role to assign to a schema originator? *Bonus question:* What is the correct role to assign to a credential Issuer agent (which writes credential definitions to the ledger)? _update: `STEWARD` works OK to send a schema ... and a claim def_

sklump (Wed, 18 Apr 2018 13:28:12 GMT):
*Item:* the indy-sdk now appears to enforce the `role` of a submitter's nym in policing ledger transactions; the options are `null`, `TRUSTEE`, `STEWARD`, `TRUST_ANCHOR`. *Observation:* the default `null` role is insufficient to write a new schema to the ledger, but all other choices have powers far too broad for an agent whose role is only to originate schemata, not to anchor further new agents onto the ledger. *Question:* what is the correct role to assign to a schema originator? *Bonus question:* What is the correct role to assign to a credential Issuer agent (which writes credential definitions to the ledger)? _update: `STEWARD` works OK to send a schema ... and a credential definition_

hawkmauk (Wed, 18 Apr 2018 13:49:15 GMT):
android

hawkmauk (Wed, 18 Apr 2018 13:59:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=gEdJ7YRoaN8R5vF8C) @AxelNennker I'm looking into building libindy for Android at the moment, did you get very far? Based on my previous experience building libindy, there a quite a few dependencies so I'm trying to build a crossdev environment on Gentoo Linux based on the info here: https://wiki.gentoo.org/wiki/Embedded_Handbook/General/Creating_a_cross-compiler

pimotte (Wed, 18 Apr 2018 15:51:29 GMT):
@hawkmauk https://jira.hyperledger.org/browse/IS-574 Might be relevant

mgbailey (Wed, 18 Apr 2018 17:04:07 GMT):
@EvelynEvergreene

EvelynEvergreene (Wed, 18 Apr 2018 17:04:07 GMT):
Has joined the channel.

EvelynEvergreene (Wed, 18 Apr 2018 17:04:18 GMT):
TEST

sklump (Wed, 18 Apr 2018 18:59:49 GMT):
One more thing. I cannot seem to get past this. I know I have just written the cred def name `red` version `1.0` to the ledger because that transaction came back with a `seqNo`. My DID is `G2D4ZAqzMowJQn2WYFbcxZ`. I call ``` await ledger.build_get_cred_def_request('G2D4ZAqzMowJQn2WYFbcxZ', 'G2D4ZAqzMowJQn2WYFbcxZ:3:CL:G2D4ZAqzMowJQn2WYFbcxZ:2:red:1.0') ``` and I always get the exception ``` Invalid structure: Schema ID not found in: G2D4ZAqzMowJQn2WYFbcxZ:3:CL:G2D4ZAqzMowJQn2WYFbcxZ:2:red:1.0. ``` Any guess what I am doing wrong? The docstring from `ledger.py` follows: ``` async def build_get_cred_def_request(submitter_did: str, id_: str) -> str: """ Builds a GET_CRED_DEF request. Request to get a credential definition (in particular, public key), that Issuer creates for a particular Credential Schema. :param submitter_did: DID of read request sender. :param id_: Credential Definition Id in ledger. :return: Request result as json. """ ``` I cannot see anything wrong with the cred def identifier 'G2D4ZAqzMowJQn2WYFbcxZ:3:CL:G2D4ZAqzMowJQn2WYFbcxZ:2:red:1.0', it is issuer-did colon 3 colon sig-type colon schema-issuer-did colon 2 colon version. I'm at a loss.

sklump (Wed, 18 Apr 2018 18:59:49 GMT):
One more thing. I cannot seem to get past this. I know I have just written the cred def name `red` version `1.0` to the ledger because that transaction came back with a `seqNo`. My DID is `G2D4ZAqzMowJQn2WYFbcxZ`. I call ``` await ledger.build_get_cred_def_request('G2D4ZAqzMowJQn2WYFbcxZ', 'G2D4ZAqzMowJQn2WYFbcxZ:3:CL:G2D4ZAqzMowJQn2WYFbcxZ:2:red:1.0') ``` and I always get the exception ``` Invalid structure: Schema ID not found in: G2D4ZAqzMowJQn2WYFbcxZ:3:CL:G2D4ZAqzMowJQn2WYFbcxZ:2:red:1.0. ``` Any guess what I am doing wrong? The docstring from `ledger.py` follows: ``` async def build_get_cred_def_request(submitter_did: str, id_: str) -> str: """ Builds a GET_CRED_DEF request. Request to get a credential definition (in particular, public key), that Issuer creates for a particular Credential Schema. :param submitter_did: DID of read request sender. :param id_: Credential Definition Id in ledger. :return: Request result as json. """ ``` I cannot see anything wrong with the cred def identifier 'G2D4ZAqzMowJQn2WYFbcxZ:3:CL:G2D4ZAqzMowJQn2WYFbcxZ:2:red:1.0', it is issuer-did : 3 : sig-type : schema-issuer-did : 2 : name : version just like `tests/demo/test_anoncreds.py` generates. I'm at a loss.

sklump (Wed, 18 Apr 2018 18:59:49 GMT):
One more thing. I cannot seem to get past this. I know I have just written the cred def name `red` version `1.0` to the ledger because that transaction came back with a `seqNo`. My DID is `G2D4ZAqzMowJQn2WYFbcxZ`. I call ``` await ledger.build_get_cred_def_request('G2D4ZAqzMowJQn2WYFbcxZ', 'G2D4ZAqzMowJQn2WYFbcxZ:3:CL:G2D4ZAqzMowJQn2WYFbcxZ:2:red:1.0') ``` and I always get the exception ``` Invalid structure: Schema ID not found in: G2D4ZAqzMowJQn2WYFbcxZ:3:CL:G2D4ZAqzMowJQn2WYFbcxZ:2:red:1.0. ``` Any guess what I am doing wrong? The docstring from `ledger.py` follows: ``` async def build_get_cred_def_request(submitter_did: str, id_: str) -> str: """ Builds a GET_CRED_DEF request. Request to get a credential definition (in particular, public key), that Issuer creates for a particular Credential Schema. :param submitter_did: DID of read request sender. :param id_: Credential Definition Id in ledger. :return: Request result as json. """ ``` I cannot see anything wrong with the cred def identifier 'G2D4ZAqzMowJQn2WYFbcxZ:3:CL:G2D4ZAqzMowJQn2WYFbcxZ:2:red:1.0', it is issuer-did : 3 : sig-type : schema-issuer-did : 2 : name : version just like `tests/demo/test_anoncreds.py` generates. I'm at a loss. *_UPDATE: It looks like the cred def identifier should be issuer-did : 3 : sig-type : schema-seq-no for this application; e.g., `G2D4ZAqzMowJQn2WYFbcxZ:3:CL:12` _ *

jtsiros (Wed, 18 Apr 2018 19:23:28 GMT):
Hello, I'm looking at the libindy-crypto library to understand how claim values are built. It looks like for string values, they are converted to 64 bit integers. Is there a specific built in encoding/hashing function that is required for non-numeric claim values? Here is the code I'm looking at in ffl/cl/mod.rs: ``` let claim_values_builder = _claim_values_builder(); let attr = CString::new("name").unwrap(); let dec_value = CString::new("1139481716457488690172217916278103335").unwrap(); let err_code = indy_crypto_cl_claim_values_builder_add_value(claim_values_builder, attr.as_ptr(), dec_value.as_ptr()); ```

sklump (Wed, 18 Apr 2018 19:25:31 GMT):
@jtsiros Encoding/decoding is application-specific. It is on the agenda to include a reference implementation at some future date. Meanwhile feel free to use the heuristic implementations from https://github.com/PSPC-SPAC-buyandsell/von_agent/blob/master/von_agent/util.py

jtsiros (Wed, 18 Apr 2018 19:41:55 GMT):
@sklump thanks!

nitin.agarwal (Thu, 19 Apr 2018 04:23:10 GMT):
Has joined the channel.

AxelNennker (Thu, 19 Apr 2018 07:34:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=tvGEyAoNGf7YxZNGj) @hawkmauk To build libindy for Android I have tried out several ways e.g. https://mozilla.github.io/firefox-browser-architecture/experiments/2017-09-21-rust-on-android.html A major obstacle is the openssl dependency which is used for BigNumber. If you search jira for Android you'll find all the related issues. https://jira.hyperledger.org/browse/IS-574?jql=text%20~%20%22Android%22 Certainly it is valuable to have ONE implementation (in rust) for all platforms so that all platforms benefit from improvements. On the other hand this ways does not allow to benefit from platform specific optimizations. I am currently putting together Android code for libindy-crypto based on Apache's milagro project. BLS simple signatures tests pass - multi-signature code not yet... If you want to use libindy in a product then I think it makes sense to wait for Mohammad Abdul Sami's work to complete. I don't know the timeline for that though.

AxelNennker (Thu, 19 Apr 2018 07:34:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=tvGEyAoNGf7YxZNGj) @hawkmauk To build libindy for Android I have tried out several ways e.g. https://mozilla.github.io/firefox-browser-architecture/experiments/2017-09-21-rust-on-android.html A major obstacle is the openssl dependency which is used for BigNumber. If you search jira for Android you'll find all the related issues. https://jira.hyperledger.org/browse/IS-574?jql=text%20~%20%22Android%22 Certainly it is valuable to have ONE implementation (in rust) for all platforms so that all platforms benefit from improvements. On the other hand this ways does not allow to benefit from platform specific optimizations. I am currently putting together Android code for libindy-crypto based on Apache's milagro project. BLS simple signatures tests pass - multi-signature code not yet... If you want to use libindy in a product then I makes sense to wait for Mohammad Abdul Sami's work to complete. I don't know the timeline for that though.

pimotte (Thu, 19 Apr 2018 07:43:16 GMT):
@AxelNennker Good to hear about this. We were wondering how far it was.

pimotte (Thu, 19 Apr 2018 07:43:35 GMT):
Sort of a related question, is anyone aware of efforts to compile to webassembly?

hawkmauk (Thu, 19 Apr 2018 08:20:31 GMT):
@pimotte @AxelNennker I managed to speak with Mohammed Abdul Sami and he pointed me in the direction of his libindy fork https://github.com/faisal00813/indy-sdk/blob/android_support/doc/android-build.md although as I understand it, not all the targets build successfully at the moment

pimotte (Thu, 19 Apr 2018 08:21:24 GMT):
Ahh, nice, thanks!

sklump (Thu, 19 Apr 2018 11:04:23 GMT):
Note: as of v1.3.1-dev-476, `indy-sdk/libindy/src/api/mod.rs` still has ``` LedgerInvalidTransaction = 304 ``` but the python wrapper `error.py` has removed it. This produces a cascading failure `ValueError: 304 is not a valid ErrorCode`. Either the python should include the error code or the rust should not emit it - but I don't know which.

gudkov (Thu, 19 Apr 2018 12:45:32 GMT):
@sklump we will check

gudkov (Thu, 19 Apr 2018 13:34:34 GMT):
@sklump https://github.com/hyperledger/indy-sdk/pull/662

darrell.odonnell (Thu, 19 Apr 2018 15:57:13 GMT):
input on the wallet "encrypted" and "unencrypted" convention. I am a big fan of being blatantly obvious, especially where we are designing capability that we are implementing "by convention". I prefer to see something like full variable names like `tag.encrypted` or `ENCRYPTEDtag` than infer from the data value. Over time convention becomes dead simple for seasoned folks but new arrivals aren't indoctrinated to the level we think. In the case of Indy-SDK making the wallet Indy's problem - I have less belief that a lazy developer will know anything about the convention. They may start looking for rich querying, realize that dropping the `CreditCardNumber` convention for `~CreditCardNumber` because that name is much more queryable - without realizing that they have failed to encrypt a very sensitive piece of information.

darrell.odonnell (Thu, 19 Apr 2018 15:58:06 GMT):
@danielhardman see above

darrell.odonnell (Thu, 19 Apr 2018 16:04:09 GMT):
@nage your comment at the end of the call proved my point above ("Over time convention becomes dead simple for seasoned folks but new arrivals aren't indoctrinated to the level we think.") - in reference to your comment that the seasoned folk don't look at the Getting Started guide. :-D

nage (Thu, 19 Apr 2018 16:11:22 GMT):
This ^^^. I hope we are always helping folks get involved and listening to the unique experience and smarts they bring to our community (and asking them to put it into a pull request!).

Steve-Boyd (Thu, 19 Apr 2018 20:16:51 GMT):
Has joined the channel.

stanleyc-trustscience (Thu, 19 Apr 2018 22:22:47 GMT):
Has joined the channel.

stanleyc-trustscience (Thu, 19 Apr 2018 22:23:33 GMT):

Clipboard - April 19, 2018 3:23 PM

stanleyc-trustscience (Thu, 19 Apr 2018 22:23:52 GMT):
Hi all, I'm new to hyperledger, recently I was trying out the nodeJS wrapper, and trying to build out a dev environment on ubuntu. However, I'm running into a issue above. Wonder if anyone has an idea how to debug this CommonIOError?

stanleyc-trustscience (Thu, 19 Apr 2018 22:23:52 GMT):
Hi all, I'm new to hyperledger indy, recently I was trying out the nodeJS wrapper, and trying to build out a dev environment on ubuntu. However, I'm running into a issue above. Wonder if anyone has an idea how to debug this CommonIOError?

stanleyc-trustscience (Thu, 19 Apr 2018 23:03:57 GMT):
Looks like I found the answer .. it's one of these packages ``` apt-get update && \ apt-get install -y \ build-essential \ pkg-config \ cmake \ libssl-dev \ libsqlite3-dev \ libsodium-dev ```

ianco (Thu, 19 Apr 2018 23:57:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=EeSNnwC4zBqBQdYEB) @stanleyc-trustscience CommonIOError is thrown from within the indy-sdk Rust code, possibly an error trying to create or update the wallet (which is just a file on the filesystem)

stanleyc-trustscience (Fri, 20 Apr 2018 00:12:23 GMT):
@ianco Actually the error was gone after I ran the above apt install command. It might have something to do with missing libraries. Out of curiosity, is there ways to tell what exactly the error of CommonIOError was?

ianco (Fri, 20 Apr 2018 00:17:27 GMT):
@stanleyc-trustscience there is extra info that is included when the sdk throws an exception, but I find that often gets lost by the time the exception gets out to the application. (We use the python wrapper.) I find the best approach is to go back to the Rust code and find where the specific exception type is thrown, and then use a bit of trial and error from there ...

ianco (Fri, 20 Apr 2018 00:18:29 GMT):
IOError could be caused by a failed connection to the pool or the wallet

stanleyc-trustscience (Fri, 20 Apr 2018 00:19:18 GMT):
@ianco Ah I see basically, search where CommonIOError was thrown. Could be from several places, but make a educated guess.

ianco (Fri, 20 Apr 2018 00:19:39 GMT):
I'm sure there's a better approach but that's what I do :-D

stanleyc-trustscience (Fri, 20 Apr 2018 00:20:25 GMT):
:) The details could been included in the message field (in my example)

stanleyc-trustscience (Fri, 20 Apr 2018 00:20:25 GMT):
:) The details could have gone to the message field (in my example)

ryanwest6 (Fri, 20 Apr 2018 02:00:03 GMT):
libzmq3

sugarcookie (Fri, 20 Apr 2018 03:48:11 GMT):
Hi @ianco, I heard there is a working group design new wallet API: developers can retrieve data from indy and store in their own way, can you direct me the page to find working group agenda and meeting schedules if you know, thanks?

ianco (Fri, 20 Apr 2018 03:51:05 GMT):
Hi @sugarcookie I don't know any meetings other than the regular Thursday AM Indy working group. However you can see the design for the new wallet API design here: https://github.com/vimmerru/indy-sdk/blob/wallet-storage-design/doc/design/wallet/wallet-design.md

ianco (Fri, 20 Apr 2018 03:51:31 GMT):
There was a discussion on this morning's call, the recording is probably online by now

sugarcookie (Fri, 20 Apr 2018 03:51:32 GMT):
yes the thursday am one

ianco (Fri, 20 Apr 2018 03:52:11 GMT):
They post the schedule/agenda every week on the indy channel

sugarcookie (Fri, 20 Apr 2018 03:52:13 GMT):
do you know where to find the recordings?

sugarcookie (Fri, 20 Apr 2018 03:52:47 GMT):
sorry where is indy channel?

ianco (Fri, 20 Apr 2018 03:52:52 GMT):
Hyperledger Indy Community Indy Rocketchat: https://chat.hyperledger.org/channel/indyhttps://chat.hyperledger.org/channel/indy-agenthttps://chat.hyperledger.org/channel/indy-node Indy Wiki: https://wiki.hyperledger.org/projects/indy Indy WG Agendas: https://drive.google.com/open?id=1wNnp1pPS6-1Y4B2oygfI6tOU4eHGmpRH Indy Videos: https://drive.google.com/open?id=1Z8-jR7hnXb57fufE0OXxIfeUn05zNmRt Indy WG Meeting Recordings: https://drive.google.com/open?id=0B_NJV6eJXAA1UlJZMXd3cm1zNDQ

ianco (Fri, 20 Apr 2018 03:53:26 GMT):
https://chat.hyperledger.org/channel/indy

sugarcookie (Fri, 20 Apr 2018 03:54:40 GMT):
cool cool, I will take a look, another question, to access to Testing network (when we are ready), I should send request to you? I heard there is some application form somewhere, (apologized if it is on wiki I might miss it)

ianco (Fri, 20 Apr 2018 03:54:57 GMT):
Not me I'm just a humble developer :-D

ianco (Fri, 20 Apr 2018 03:55:21 GMT):
Are you on the Sovrin Slak channel? That's probably the best place to ask

ianco (Fri, 20 Apr 2018 03:55:21 GMT):
Are you on the Sovrin Slack channel? That's probably the best place to ask

ianco (Fri, 20 Apr 2018 03:55:45 GMT):
sovrin.slack.com

sugarcookie (Fri, 20 Apr 2018 03:58:18 GMT):
got it, more questions, I heard there are some discussion regarding "wallet/key restore", especially if client is using browser, do you know is there a project has been initiated on this?

ianco (Fri, 20 Apr 2018 04:04:56 GMT):
Not specifically on the wallet/key restore, although the wallet API project is also considering export and import formats

ianco (Fri, 20 Apr 2018 04:05:28 GMT):
We've done some noodling about wallet restore in BC but we're dealing with enterprise apps rather than browser/phone apps

sugarcookie (Fri, 20 Apr 2018 04:15:46 GMT):
got it, we do have this need, and we are dealing with enterprise, app will be the main devise for user, but we do consider supporting browser later on, that is ok, I heard one of the change in future is to allow different key pairs on different devices, has this solution been finalized?

srinivasanraghavan (Fri, 20 Apr 2018 06:51:07 GMT):
Has joined the channel.

sklump (Fri, 20 Apr 2018 11:32:34 GMT):
One *easy* question: is the credential id in the wallet just a new name for the referent (formerly claim-uuid)?

pimotte (Fri, 20 Apr 2018 11:36:27 GMT):
@sklump As I understand it, yes. Or rather, as I understand it, a "referent" is a credential id in the context of a proof

pimotte (Fri, 20 Apr 2018 11:36:27 GMT):
@sklump As I understand it, yes. Or rather a "referent" is a credential id in the context of a proof

smithbk (Fri, 20 Apr 2018 12:31:53 GMT):
@nage @sergey.minaev Is it possible for Alice to create a credential which uses a credential definition that was created and posted to the ledger by Bob? Perhaps I'm missing something, but I don't see how this is possible with the current python SDK APIs and am not sure if this is an intentional restriction or by design. I wouldn't think that the private key of the credential definition is required in order to create a credential, so perhaps there is another API that I'm missing. The only API I see to create a credential is `issuer_create_credential` which takes the `wallet_handle` and says ``` The credential definition and revocation registry definition referenced in Cred Offer and Cred Request must be already created and stored into the wallet. ``` And I don't see a way to put a credential definition in my wallet except via `issuer_create_and_store_credential_def`. Is there another API for creating a credential that allows me to pass in a credential definition and/or revocation registry definition which I have read from the ledger? If not, doesn't this mean that currently in order to issue credentials, you also be able to write to the ledger? Thanks in advance for your help.

sergey.minaev (Fri, 20 Apr 2018 12:38:30 GMT):
@smithbk New credential can be issued only by owner of appropriate private key for credential definition.

sergey.minaev (Fri, 20 Apr 2018 12:39:25 GMT):
If Bob would like to create Credential for Alice, he can create his own credential definition with keys for any schema in ledger

smithbk (Fri, 20 Apr 2018 12:40:46 GMT):
ok, so then I have to be a trust anchor (or trustee or steward) to issue credentials? (since I have to write the cred def to the ledger as an issuer)

sergey.minaev (Fri, 20 Apr 2018 12:46:22 GMT):
In latest master - yes - only Trust Anchor (or higher) can post cred def to the ledger. In previous versions of SDK / Ledger anybody can do it. Also, it's not a final solution (permissions for creating cred def), and can be returned back in the future

sergey.minaev (Fri, 20 Apr 2018 12:46:22 GMT):
In latest master - yes - only Trust Anchor (or higher) can post cred def to the ledger. In previous versions of SDK / Ledger anybody can do it. Also, it's not a final solution (permissions for posting cred def), and can be returned back in the future

sergey.minaev (Fri, 20 Apr 2018 12:46:22 GMT):
In latest master - yes - only Trust Anchor (or higher) can post cred def to the ledger. In previous versions of SDK / Ledger anybody can do it. Also, it's not a final solution (permissions for posting cred def), and it can be returned back in the future

sklump (Fri, 20 Apr 2018 12:48:56 GMT):
Gents - kindly direct me to an authoritative definition of the difference between the roles of trust anchor, trustee, and steward?

sergey.minaev (Fri, 20 Apr 2018 12:54:12 GMT):
Some definitions are presents in https://sovrin.org/library/glossary/ @nage @ashcherbakov Could you suggest better source?

smithbk (Fri, 20 Apr 2018 12:54:32 GMT):
I was looking at https://docs.google.com/spreadsheets/d/1TWXF7NtBjSOaUIBeIH77SyZnawfo91cJ_ns4TR-wsq4/edit#gid=0

smithbk (Fri, 20 Apr 2018 12:57:20 GMT):
which btw is linked to from https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md (see this block) ```Our ledger is public permissioned and anyone who wants to publish DIDs needs to get the role of Trust Anchor on the ledger. A Trust Anchor is a person or organization that the ledger already knows about, that is able to help bootstrap others. (It is not the same as what cybersecurity experts call a "trusted third party"; think of it more like a facilitator). See Roles to get more information about roles.```

dbluhm (Fri, 20 Apr 2018 13:51:15 GMT):
Has joined the channel.

sklump (Fri, 20 Apr 2018 14:03:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3fgWHgTbEARQoz6EN) @sergey.minaev I believe we need another role, more powerful than null (read-only) but less powerful than trust anchor. All stewards are trust anchors. Trust anchors can not only write schemata and credential definitions to the ledger, but also write nyms for new trust anchors. In our case, schema originators and credential issuers do not need to be able to write nyms for new entities to the ledger. In effect a power-user role with no delegation capabilities would be just the thing. I am just talking off the top of my head here, and have no understanding of how much work it would be to crawl all over the code base and cram in more granular permission checking, so consider this just a wish for now.

sklump (Fri, 20 Apr 2018 14:03:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3fgWHgTbEARQoz6EN) @sergey.minaev I believe we need another role, more powerful than null (read-only) but less powerful than trust anchor. Trust anchors can not only write schemata and credential definitions to the ledger, but also write nyms for new trust anchors. In our case, schema originators and credential issuers do not need to be able to write nyms for new entities to the ledger. In effect a power-user role with no delegation capabilities would be just the thing. _(This is what I had thought a steward meant, but I was wrong about that -- steward is in fact even broader than trust anchor)._ I am just talking off the top of my head here, and have no understanding of how much work it would be to crawl all over the code base and cram in more granular permission checking, so consider this just a wish for now.

sklump (Fri, 20 Apr 2018 14:11:57 GMT):
For the non-revocation interval of (`libindy/src/domain/proof_request.rs::NonRevocedInterval`), the `from:` and `to:` values are 64-bit unsigned ints. Are these epoch seconds? Thanks in advance.

ianco (Fri, 20 Apr 2018 14:52:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9WQaJ2krxX6g8qTES) @sugarcookie @sugarcookie I'm not sure about support for different key pairs on different devices, wil have to send this question out to the group

ianco (Fri, 20 Apr 2018 14:52:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9WQaJ2krxX6g8qTES) @sugarcookie I'm not sure about support for different key pairs on different devices, wil have to send this question out to the group

nage (Fri, 20 Apr 2018 16:21:03 GMT):
@esplinr I have been watching tickets in Jira and noticed we are versioning to 1.4, likely due to the api changes for revocation. Since we are trying to imply compatibility with Indy-node is there any way we can avoid the version number revision?

jtsiros (Fri, 20 Apr 2018 16:33:20 GMT):
@sklump I'm trying to test out signing a claim using libindy_crypto, but I keep seeing the following error: ``` Issuer::_new_non_revocation_claim: >>> rev_idx: 0, claim_context: BigNumber { openssl_bn: 99114990184229736250198513827829944161825601602280267150804733094434284633304 }, blnd_ms: BlindedMasterSecret { u: BigNumber { openssl_bn: Helpers::transform_u32_to_array_of_u8: >>> x: 0 Helpers::transform_u32_to_array_of_u8: <<< res: [0, 0, 0, 0] Helpers::transform_u32_to_array_of_u8: >>> x: 0 Helpers::transform_u32_to_array_of_u8: <<< res: [0, 0, 0, 0] indy_crypto_cl_issuer_sign_claim: <<< res: CommonInvalidStructure error signing claim: 113 ```

sklump (Fri, 20 Apr 2018 16:36:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jsKTqx3ynye2Ygdsj) @jtsiros I'm just a developer like you. Looks like `libindy/src/api/mod.rs` has 113 as the error code for CommonInvalidStructure.

jtsiros (Fri, 20 Apr 2018 16:36:15 GMT):
more specifically in ```Issuer::_new_non_revocation_claim```

sklump (Fri, 20 Apr 2018 16:36:34 GMT):
Doesn't look like python, so I'm automatically 90% uninterested :-/

jtsiros (Fri, 20 Apr 2018 16:38:12 GMT):
yes, this is the Rust library version. Essentially, I drilled down an the error message that gets thrown is: ``` r_acc.acc = r_acc.acc .add(r_acc_tails.tails_dash .get(&index) .ok_or(IndyCryptoError::InvalidStructure(format!("Value by key '{}' not found in g", index)))?)?; ```

sklump (Fri, 20 Apr 2018 16:38:56 GMT):
I'm afraid you've got the wrong guy, I am still porting all my old stuff to the new regime and won't get to revocation for at least a week.

jtsiros (Fri, 20 Apr 2018 16:40:25 GMT):
do you if there is someone that can help?

jtsiros (Fri, 20 Apr 2018 16:40:25 GMT):
do you know who can help?

sklump (Fri, 20 Apr 2018 16:41:37 GMT):
If not Sergey Minaev, then he probably will know who can

bjarny (Fri, 20 Apr 2018 16:53:21 GMT):
is there support in indy-sdk to update the end_point for a DID? I see support to call set_endpoint here https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/indy/did.py but it doesn't take a pool_handle, so it appears to only set the endpoint in the local wallet. I was expecting to see some support to write my DID document metadata as a DID holder. conversely, 'get_endpoint_for_did' does take a pool_handle and goes to the ledger if sdk can't find the end_point in the wallet.

jtsiros (Fri, 20 Apr 2018 17:01:26 GMT):
@sergey.minaev I'm attempting to sign a claim using libindy_crypto and in `Issuer::_new_non_revocation_claim` I'm seeing: ``` r_acc.acc = r_acc.acc .add(r_acc_tails.tails_dash .get(&index) .ok_or(IndyCryptoError::InvalidStructure(format!("Value by key '{}' not found in g", index)))?)?; ``` Unfortunately, I don't have the full context of the implementation here, can you shed some light on what this error actually is? Thanks!

sklump (Fri, 20 Apr 2018 17:03:30 GMT):
@bjarny You can set an attribute via `ledger.build_endpoint_request()`, but the semantics of each attribute are application-specific. For example, you can set an attribute called `endpoint` and have all your relying parties know to get the `endpoint` value to mean a URL.

sklump (Fri, 20 Apr 2018 17:03:30 GMT):
@bjarny You can set an attribute via `ledger.build_attrib_request()`, but the semantics of each attribute are application-specific. For example, you can set an attribute called `endpoint` and have all your relying parties know to get the `endpoint` value to mean a URL.

bjarny (Fri, 20 Apr 2018 17:04:24 GMT):
@sklump ty! exactly what I was looking for. appreciate the help!

troyronda (Fri, 20 Apr 2018 17:53:34 GMT):
Has joined the channel.

esplinr (Fri, 20 Apr 2018 20:17:41 GMT):
@nage Sorry about not discussing the version number with you earlier. It looks like the next release should be a 1.4 instead of a 1.3 because the wallet format changed in a backwards incompatible way. I created a story to document the migration process: IS-654.

esplinr (Fri, 20 Apr 2018 20:19:03 GMT):
If you disagree with the change in version number, we'll find a solution. In the future, we'll also make sure you are aware of version number changes in advance of the release approval discussion.

danielhardman (Fri, 20 Apr 2018 23:39:06 GMT):
@darrell.odonnell and @swcurran and @nage and anybody else who's interested : I've written up some notes about wallet queryability and tagging as it relates to anoncreds. Comments would be delightful! http://bit.ly/2HhjpLs

danielhardman (Fri, 20 Apr 2018 23:41:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=PSjJDzSi4dH4u9PJh) @darrell.odonnell Acknowledged and agreed. However, it is the unencrypted version that is unusual, not the encrypted one. We want unencrypted to be ugly and verbose. So what about `plaintext.tag`?

ianco (Sat, 21 Apr 2018 00:43:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=bKzcA5YqvaKWtrZP9) @danielhardman made a couple of comments regarding encryption, and how to specify the subject of a claim. I also have a question about how keys are managed for the encryption of the wallet, I'm not sure if this was covered in the discussion on Thursday am. Cheers :-)

danielhardman (Sat, 21 Apr 2018 00:54:46 GMT):
Thanks, @ianco

turmewr3ck (Sat, 21 Apr 2018 10:17:49 GMT):
Is it required that the DID owner (verkey and secret key in wallet) writes both schema and claim definition? The (relatively newly written) "Anoncreds Design" (indy-sdk/doc/design/anoncreds/anoncreds-design.md) associated sequence diagram seems to suggest so. However the associated how-to Java example writes the schema as the steward DID (with verkey and secret in wallet), but that example does not seem to be realistic. Are there any restriction in relation with schema isser DIDs and claim def DIDs?

turmewr3ck (Sat, 21 Apr 2018 10:17:49 GMT):
Is it required that the DID owner (verkey and secret key in wallet) writes both schema and claim definition? The (relatively newly written) "Anoncreds Design" (indy-sdk/doc/design/anoncreds/anoncreds-design.md) associated sequence diagram seems to suggest so. However the associated how-to Java example writes the schema as the steward DID (with verkey and secret in wallet), but that example does not seem to be realistic. Are there any restrictions in relation with schema issuer DIDs and claim def DIDs?

darrell.odonnell (Sat, 21 Apr 2018 12:36:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=bKzcA5YqvaKWtrZP9) @danielhardman again I like being blunt like a hammer so a dev, working very tired at night is blatantly reminded that "this ain't encrypted sleepy person" That being said, were you looking at `plaintext.tag` and `tag' or `encrypted.tag`?

danielhardman (Sun, 22 Apr 2018 17:21:15 GMT):
I was thinking `plaintext.tag` (or `unencrypted.tag`) and just `tag` (which would be the default and which would be encrypted. Do you think putting a prefix on the normal case is necessary?

sugarcookie (Sun, 22 Apr 2018 22:40:46 GMT):
Hi @ianco, not sure whether you use mac, it works on windows, but in mac, I always get poolledgertimeout error like below, couldn't find reason: REG-172-29-18-61:src app$ python3 main.py create_pool_ledger_config: >>> config_name: %r, config: %r pool2 {"genesis_txn": "/var/folders/ql/183bf3kx0sb59l3hdkl7n_zc0000gn/T/indy/pool2.txn"} WARNING:indy.libindy:_indy_loop_callback: Function returned error 307 Traceback (most recent call last): File "main.py", line 21, in loop.run_until_complete(main()) File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/asyncio/base_events.py", line 468, in run_until_complete return future.result() File "main.py", line 13, in main await script.run_ledger_demo_works() File "/Users/app/desktop/blockchain/indy-sdk/samples/python/src/script.py", line 22, in run_ledger_demo_works pool_handle = await pool.open_pool_ledger(pool_name, None) File "/Users/app/desktop/blockchain/indy-sdk/wrappers/python/indy/pool.py", line 86, in open_pool_ledger open_pool_ledger.cb) indy.error.IndyError: ErrorCode.PoolLedgerTimeout

sugarcookie (Sun, 22 Apr 2018 22:43:21 GMT):
@ianco run docker network ls

sugarcookie (Sun, 22 Apr 2018 22:43:23 GMT):

Clipboard - April 22, 2018 6:43 PM

ianco (Sun, 22 Apr 2018 23:05:07 GMT):
@sugarcookie how are you running the Indy nodes? (PS I use a mac but I normally develop on an Ubuntu VM)

sugarcookie (Sun, 22 Apr 2018 23:47:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=D4xib3rdwbzhSncAQ) @ianco running this https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker and following this instructions to forward port to local https://github.com/hyperledger/indy-sdk/pull/632/files

ianco (Sun, 22 Apr 2018 23:54:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=TEvKSihjoWX49AqnQ) @sugarcookie These commands worked for me: docker build -f ci/indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9708:9701-9708 indy_pool I haven't tried the second approach (using a custom docker network).

sugarcookie (Sun, 22 Apr 2018 23:55:17 GMT):
@ianco it works for me, no error, so i am try to figure out what ledgerpooltimeout means? didn't connect indy ledger?

sugarcookie (Sun, 22 Apr 2018 23:57:55 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=idYcRDPsnJjRpT99t) so error happens when running pool_handle = await pool.open_pool_ledger(pool_name, None)

sugarcookie (Mon, 23 Apr 2018 01:14:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=idYcRDPsnJjRpT99t) @ianco sorry, one last question, I will give up mac...............so hard! here is my container

sugarcookie (Mon, 23 Apr 2018 01:14:35 GMT):

Clipboard - April 22, 2018 9:14 PM

sugarcookie (Mon, 23 Apr 2018 01:15:20 GMT):
@ianco pretty sure is something wrong here, use almost exactly the same code not work on mac

sugarcookie (Mon, 23 Apr 2018 01:18:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=2xy7bdzDgLitXc3XY) maybe my port forwarding is wrong, new to it

ianco (Mon, 23 Apr 2018 03:09:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=KXNk6YmwDDpdFSox4) @sugarcookie I don't know enough about the pedger protocol, maybe someone else on the channel has an idea? Seems like timeout would mean the indy-sdk is not able to "handshake" with the ledger ...

ianco (Mon, 23 Apr 2018 03:09:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=KXNk6YmwDDpdFSox4) @sugarcookie I don't know enough about the ledger protocol, maybe someone else on the channel has an idea? Seems like timeout would mean the indy-sdk is not able to "handshake" with the ledger ...

sugarcookie (Mon, 23 Apr 2018 03:50:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=NHo85xNmj5ntnkcMs) @ianco ok, thank you

sugarcookie (Mon, 23 Apr 2018 03:50:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=t6xut9ePQpqvtLTCZ) @ianco thank you, I use this docker run -itd -p 127.0.0.1:9701-9708:9701-9708 indy_pool, added 127.0.0.1 finally got it work, I know it seems mention on in the doc, but I don't understand how it works at that time, my team member experience the same issue with mac, but thank you so much!

sugarcookie (Mon, 23 Apr 2018 05:34:01 GMT):
Hi @gudkov, thanks for helping me last time, I am still getting poolledgertimeout when running open_pool_ledger on MAC (only has issue on mac), my docker containers info: f8fe92833f00 indy_pool "/usr/bin/supervisord" 3 hours ago Up 3 hours 0.0.0.0:9701-9708->9701-9708/tcp amazing_edison, I didn't use customized ip, so what could be wrong? many thanks

Kelattar (Mon, 23 Apr 2018 07:38:35 GMT):
Has joined the channel.

KitHat (Mon, 23 Apr 2018 08:53:07 GMT):
Has joined the channel.

gudkov (Mon, 23 Apr 2018 08:56:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=uNjiPXDMS4oR8cT7G) @sugarcookie timeout in the most cases means that client can't connect to pool nodes. You can just try to connect to any node manually with telnet. If there will be welcome CurveCP message than you configured VirtualBox ports forwarding in a right way.

SanketPanchamia (Mon, 23 Apr 2018 09:37:13 GMT):

Clipboard - April 23, 2018 3:07 PM

SanketPanchamia (Mon, 23 Apr 2018 09:37:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=s2zKqzHy7Hq2PC7gh) @gudkov Hi i was able to get the indy sdk running via docker and i ran the sample that was provided (Alice). Now is there a way to see the list of wallets, pools that were created in the process? I believe you could use indy-cli but i am getting an error installing indy-cli via npm. I have installed libindy.

sergey.minaev (Mon, 23 Apr 2018 10:26:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ingmc9TecD7EzXgz7) @danielhardman @nage

sergey.minaev (Mon, 23 Apr 2018 10:29:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=8S5vCdoR3nAGoJAWN) @sklump AFAIR it should be same (format and precision) with txnTime in transactions. @Artemkaaas ?

sergey.minaev (Mon, 23 Apr 2018 10:38:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=FXmsrh8nYPtznmE5v) @jtsiros 1) what version of indy-crypto do you use? 2) please check that you create revocation registry ( only for latest versions: and store tails for it ). 3) another possible reason is using incorrect revocation_index Demo test (in Rust or in a wrapper) is good place to check right sequence of calls. If you already synchronized your code with latest demos, please share more context, I or @Artemkaaas will try to understand the reason of the problem.

sergey.minaev (Mon, 23 Apr 2018 10:40:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Lq2WTwtgMj289ti9b) @turmewr3ck owner of credential (claim) definition can be different against owner of schema

turmewr3ck (Mon, 23 Apr 2018 11:26:00 GMT):
@sergey.minaev for the above; are there any requirements on what is in the wallet from which one creates claim def in case the schema is issued from another DID?

sergey.minaev (Mon, 23 Apr 2018 11:27:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=uGTtTW5Sqxw7Wku9R) @turmewr3ck AFAIR - no. @Artemkaaas could you confirm or correct?

sugarcookie (Mon, 23 Apr 2018 12:56:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=gYByC7Lrwa3fRdZi8) @gudkov thanks, what is the command to connect node manually? assuming node name is Node1, Node2, Node3, Node4 ?

gudkov (Mon, 23 Apr 2018 12:57:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=hYfSMgybFzcGr9cJ4) @sugarcookie ```telnet 127.0.0.1 9701```

Artemkaaas (Mon, 23 Apr 2018 13:41:52 GMT):
Yes, it is epoch seconds [ ](https://chat.hyperledger.org/channel/indy-sdk?msg=zM7f8p4AFK86uy6aK) @sergey.minaev

Artemkaaas (Mon, 23 Apr 2018 13:46:30 GMT):
sergey is right [ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6KkgCXHzsucNNpvyr) @sergey.minaev

Artemkaaas (Mon, 23 Apr 2018 13:49:12 GMT):
if you are getting this error it means that `index` (that you passed) either is 0 or is bigger than max_cred_num * 2 (that you used for registry creation) [ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qe8eqFj6B7Pxe4jmw) @sergey.minaev

lodo1995 (Mon, 23 Apr 2018 14:48:51 GMT):
Has joined the channel.

lodo1995 (Mon, 23 Apr 2018 14:49:56 GMT):
Hello everybody! I'm new to Indy. Is this the right place to ask clarification about indy-sdk status and functionality?

Artemkaaas (Mon, 23 Apr 2018 14:53:26 GMT):
Hello, @lodo1995. Yes

lodo1995 (Mon, 23 Apr 2018 15:09:18 GMT):
I'm starting to work on a university project using Indy. According to indy-node's documentation, indy-sdk should become the client library and replace indy-node/indy_client. But in indy-sdk I only see basic functionality: the Rust library and the wrappers seem to be missing the functionality to programmatically create and manage agents; specifically, the agent-to-agent connection used to transfer certificates/requests/whatever seems to be missing. Related to this, the cli is missing all commands related to connections, certificates and proofs. These aspects of the client api and of the cli are present in indy-node, but the documentation indicates that they are going to be removed in favor of indy-sdk. Is my understanding of the current situation correct? Will these aspects be implemented in the future or are they left to the user? In case they are going to be implemented, can we expect them to become available quickly, or should I start thinking about forking the library and/or writing my own layer on top of it? I'm asking because the project I'm starting to work on runs on a very tight schedule...

lodo1995 (Mon, 23 Apr 2018 15:10:16 GMT):
Or should I just use indy-node/indy-client for the time being?

lodo1995 (Mon, 23 Apr 2018 15:10:16 GMT):
Or should I just use indy-node/indy_client for the time being?

ianco (Mon, 23 Apr 2018 15:28:27 GMT):
@sugarcookie FYI I tested building and running indy-sdk on a mac and everything worked as expected ... Checked out indy-sdk.git and built indy-sdk library as per https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md Started indy nodes as per: docker build -f ci/indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9708:9701-9708 indy_pool (Note that the other approach - setting up a custom docker network - I couldn't connect to the network from the mac host, I think this approach is only for the case where your agent app is also in a docker container.) Then ran the Python test: cd samples/python export DYLD_LIBRARY_PATH="../../libindy/target/debug/" # point to the just-built indy lib rm -rf ~/.indy_client/ # make sure there is no junk from previous runs PYTHONPATH=.:../../wrappers/python python3 src/main.py ... successfully ran through the Alice/Faber demo.

danielhardman (Mon, 23 Apr 2018 15:37:17 GMT):
@lodo1995 Agent-to-agent comms are built into indy-sdk (libindy). For example, see this how-to, which basically creates an agent and sends a message to it: https://github.com/hyperledger/indy-sdk/tree/master/doc/how-tos/send-secure-msg/python

lodo1995 (Mon, 23 Apr 2018 15:48:46 GMT):
@danielhardman Thank you for your reply. In that example, the communication happens by using a shared file, with the user explicitly telling when to read from it. On the other hand, in https://github.com/hyperledger/indy-node/tree/master/indy_client/test/agent there are many examples of Agents implemented by extending the WalletedAgent class. In this case, if I'm correct, the user just needs to override some handler methods and provide the claim definitions; the library will set up the agent on the ledger, ready to listen on a specific port, and will handle all remote interactions with clients, accepting and checking proofs and adding certificates as needed as a consequence. On the other hand, in indy-sdk, I would have to handle the registration of the endpoint and the setup of a network server myself. Or at least, this is what I understand from the code.

ragpach2 (Mon, 23 Apr 2018 16:12:43 GMT):
Has joined the channel.

lodo1995 (Mon, 23 Apr 2018 16:44:42 GMT):
After another look at both codebases (indy-node/indy_client and indy-sdk), what I feel is missing from indy-sdk is the equivalent of the Agent and WalletedAgent classes, that internally manage secure ZeroMQ connections and allow easy exchange of proof requests and claims, and also of arbitrary end-to-end messages, also allowing fully automated agents that react to the reception of connections, claims and other messages.

jtsiros (Mon, 23 Apr 2018 17:14:18 GMT):
@sergey.minaev looks like that was it - I was setting the RevIndex to 0. Changing it to one fixed t

jtsiros (Mon, 23 Apr 2018 17:14:18 GMT):
@sergey.minaev looks like that was it - I was setting the RevIndex to 0. Changing it to one fixed it

jtsiros (Mon, 23 Apr 2018 17:14:18 GMT):
@sergey.minaev looks like that was it - I was setting the RevIndex to 0. Changing it to 1 fixed it

sklump (Mon, 23 Apr 2018 18:36:01 GMT):
@marvint notice that the referent (credential identifier in the wallet) is gone from the proof structure. Where the indy-sdk used to have ``` proof["proof"]["proofs"]: -> ``` now instead it has ``` proof["proof"]["proofs"] = [, ... ] ``` Is this any chance of getting those back in? It was very handy to be able to track a revealed attribute back to its identified claim in the prover's wallet. Anticipating an answer of 'probably not', do the dicts in `proof["identifiers"]` then line up index-by-index with the sub-proofs in of `proof["proof"]["proofs"]` ? In that case the cred_def_id would probably do for my purposes.

sklump (Mon, 23 Apr 2018 18:36:01 GMT):
@marvint notice that the referent (credential identifier in the wallet) is gone from the proof structure. Where the indy-sdk used to have ``` proof["proof"]["proofs"]: -> ``` now instead it has ``` proof["proof"]["proofs"] = [, ... ] ``` Is this any chance of getting those back in? It was very handy to be able to track a revealed attribute back to its identified claim in the prover's wallet. Anticipating an answer of 'probably not', do the dicts in `proof["identifiers"]` then line up index-by-index with the sub-proofs in of `proof["proof"]["proofs"]`? (e.g., in ``` proof["identifiers"]: [ { "cred_def_id": "Q4zqM...:3:CL:17" }, ... ] ``` is the first identifier dict guanteed to pertain to the first dict in ``` proof["proof"]["proofs"] ``` ? In that case the `cred_def_id` would probably do for my purposes.

sklump (Mon, 23 Apr 2018 18:36:01 GMT):
@marvint notice that the referent (credential identifier in the wallet) is gone from the proof structure. Where the indy-sdk used to have ``` proof["proof"]["proofs"]: -> ``` now instead it has ``` proof["proof"]["proofs"] = [, ... ] ``` Is this any chance of getting those back in? It was very handy to be able to track a revealed attribute back to its identified claim in the prover's wallet. Anticipating an answer of 'probably not', do the dicts in `proof["identifiers"]` then line up index-by-index with the sub-proofs in of `proof["proof"]["proofs"]`? (e.g., in ``` proof["identifiers"]: [ { "schema_id": "Q4zM...:2:__:__", "cred_def_id": "Q4zqM...:3:CL:17", ..., }, ... ] ``` is the first identifier dict guanteed to pertain to the first dict in ``` proof["proof"]["proofs"] ``` ? In that case the `cred_def_id` would probably do for my purposes.

sklump (Mon, 23 Apr 2018 18:36:01 GMT):
@marvint notice that the referent (credential identifier in the wallet) is gone from the proof structure. Where the indy-sdk used to have ``` proof["proof"]["proofs"]: -> ``` now instead it has ``` proof["proof"]["proofs"] = [, ... ] ``` Is this any chance of getting those back in? It was very handy to be able to track a revealed attribute back to its identified claim in the prover's wallet. Anticipating an answer of 'probably not', do the dicts in `proof["identifiers"]` then line up index-by-index with the sub-proofs in of `proof["proof"]["proofs"]`? (e.g., in ``` proof["identifiers"]: [ { "schema_id": "Q4zM...:2:schema_name:1.0", "cred_def_id": "Q4zqM...:3:CL:17", ..., }, ... ] ``` is the first identifier dict guanteed to pertain to the first dict in ``` proof["proof"]["proofs"] ``` ? In that case the `cred_def_id` would probably do for my purposes.

sklump (Mon, 23 Apr 2018 18:36:01 GMT):
@marvint notice that the referent (credential identifier in the wallet) is gone from the proof structure. Where the indy-sdk used to have ``` proof["proof"]["proofs"]: -> ``` now instead it has ``` proof["proof"]["proofs"] = [, ... ] ``` Is this any chance of getting those back in? It was very handy to be able to track a revealed attribute back to its identified claim in the prover's wallet. Anticipating an answer of 'probably not', do the dicts in `proof["identifiers"]` then line up index-by-index with the sub-proofs in of `proof["proof"]["proofs"]`? e.g., in ``` proof["identifiers"]: [ { "schema_id": "Q4zM...:2:schema_name:1.0", "cred_def_id": "Q4zqM...:3:CL:17", ..., }, ... ] ``` is the first identifier dict guanteed to pertain to the first dict in ``` proof["proof"]["proofs"] ``` ? In that case the `cred_def_id` would probably do for my purposes.

sklump (Mon, 23 Apr 2018 18:36:01 GMT):
I notice that the referent (credential identifier in the wallet) is gone from the proof structure. Where the indy-sdk used to have ``` proof["proof"]["proofs"]: -> ``` now instead it has ``` proof["proof"]["proofs"] = [, ... ] ``` Is this any chance of getting those back in? It was very handy to be able to track a revealed attribute back to its identified claim in the prover's wallet. Anticipating an answer of 'probably not', do the dicts in `proof["identifiers"]` then line up index-by-index with the sub-proofs in of `proof["proof"]["proofs"]`? e.g., in ``` proof["identifiers"]: [ { "schema_id": "Q4zM...:2:schema_name:1.0", "cred_def_id": "Q4zqM...:3:CL:17", ..., }, ... ] ``` is the first identifier dict guanteed to pertain to the first dict in ``` proof["proof"]["proofs"] ``` ? In that case the `cred_def_id` would probably do for my purposes.

mccown (Mon, 23 Apr 2018 20:35:05 GMT):
Has joined the channel.

sugarcookie (Tue, 24 Apr 2018 04:36:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=H3NqskJ7pd2sTqxet) @gudkov thank you so much, i got it work by replace second line of docker with docker run -itd -p 127.0.0.1:9701-9708:9701-9708 indy_pool , I saw you updated doc with more info on mac, that is great, not sure whether this is mac specific thing, I gained lot of docker network knowledge because of this, thanks again

mawi (Tue, 24 Apr 2018 07:49:08 GMT):
What is the actual status of the indy-sdk wrapper for iOS? It seems outdated on some points with references to evernym repo's and other stuff.

sergey.minaev (Tue, 24 Apr 2018 07:51:04 GMT):
@sklump The order of sub-proofs is significant for math, so we change it representation in JSON from map (unordered structure) to array. Now index in arrays is way to link entities

sergey.minaev (Tue, 24 Apr 2018 07:51:04 GMT):
@sklump The order of sub-proofs is significant for math, so we change subproofs representation in JSON from map (unordered structure) to array. Now index in arrays is way to link entities

pwalimbe (Tue, 24 Apr 2018 08:13:19 GMT):
Has joined the channel.

sergey.minaev (Tue, 24 Apr 2018 09:31:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ctPe45Cfh8hR2mR2h) @mawi iOS wrapper should be up-to-date in the master branch.

AnhDung (Tue, 24 Apr 2018 09:49:04 GMT):
Has joined the channel.

sklump (Tue, 24 Apr 2018 10:49:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=GeHSYNbLtecySdDp9) @sergey.minaev In a future release, if you could put the cred-id into the sub-proof's `identifiers` entry; e.g., ``` "identifiers": [ { "referent": "688828a7-198f-49cc-93ce-924900f56d69" # <- NEW "cred_def_id": "Q4zqM7aXqm7gDQkUVLng9h:3:CL:15", "timestamp": null, "rev_reg_id": null, "schema_id": "Q4zqM7aXqm7gDQkUVLng9h:2:bc-reg:1.0" } ], ``` that would be a very useful piece of data. As it stands, the referent doesn't show up anywhere in the proof if I am reading it correctly.

sklump (Tue, 24 Apr 2018 10:49:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=GeHSYNbLtecySdDp9) @sergey.minaev In a future release, if you could put the cred-id into the sub-proof's `identifiers` entry; e.g., ``` "identifiers": [ { "referent": "688828a7-198f-49cc-93ce-924900f56d69", # <- NEW "cred_def_id": "Q4zqM7aXqm7gDQkUVLng9h:3:CL:15", "timestamp": null, "rev_reg_id": null, "schema_id": "Q4zqM7aXqm7gDQkUVLng9h:2:bc-reg:1.0" } ], ``` that would be a very useful piece of data. As it stands, the referent doesn't show up anywhere in the proof if I am reading it correctly.

sklump (Tue, 24 Apr 2018 10:49:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=GeHSYNbLtecySdDp9) @sergey.minaev In a future release, if you could put the cred-id into the sub-proof's `identifiers` entry; e.g., ``` "identifiers": [ { "referent": "688828a7-198f-49cc-93ce-924900f56d69", # <- NEW "cred_def_id": "Q4zqM7aXqm7gDQkUVLng9h:3:CL:15", "timestamp": null, "rev_reg_id": null, "schema_id": "Q4zqM7aXqm7gDQkUVLng9h:2:bc-reg:1.0" }, ... ], ``` that would be a very useful piece of data. As it stands, the referent doesn't show up anywhere in the proof if I am reading it correctly.

sergey.minaev (Tue, 24 Apr 2018 10:58:42 GMT):
@sklump could you describe motivation/use cases for this referent? Previously we have a issue: referent was persist for credential and it results in risk of correlation... If it will be unique for each proof, I don't see usecases for it.

sklump (Tue, 24 Apr 2018 11:15:56 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jzLjt3xqchqtgF8JT) @sergey.minaev My use case was precisely for correlation - if this goes against the design goals, then it's my test case that's got to change :-)

salmanbaset (Tue, 24 Apr 2018 19:23:29 GMT):
Has joined the channel.

AxelNennker (Tue, 24 Apr 2018 19:34:39 GMT):
I now have a libcrypto.so.1.0.0, libzmq.so, libsodium.so and a libindy.so for Android. Has somebody have an Android test program to test them? IndyJava.java uses CompletableFuture which is not available on Android.

kevin.chan (Tue, 24 Apr 2018 21:10:30 GMT):
Has joined the channel.

kevin.chan (Tue, 24 Apr 2018 21:11:02 GMT):
hi, is there a way to install the the 1.4.0 version of the python3-indy wrapper using pip?

kevin.chan (Tue, 24 Apr 2018 21:12:03 GMT):
{code}

kevin.chan (Tue, 24 Apr 2018 21:13:07 GMT):
```pip install -U python3-indy==1.4.0 Collecting python3-indy==1.4.0 Could not find a version that satisfies the requirement python3-indy==1.4.0```

kevin.chan (Tue, 24 Apr 2018 21:13:07 GMT):
does anybody know why I might be getting this error calling key_for_did? ``` INFO|indy::services::pool | src/services/pool/mod.rs:543 | RemoteNode::recv_msg Node3 {"result":{"data":null,"seqNo":null,"reqId":1524612778295406000,"identifier":"NNKuBP3i39niAUacUu3j8M","dest":"NNKuBP3i39niAUacUu3j8M","txnTime":null,"type":"105"},"op":"REPLY"} TRACE|indy::services::pool::transaction_handler|src/services/pool/transaction_handler.rs:76 | TransactionHandler::process_reply: >>> req_id: 1524612778295406000, raw_msg: "{\"result\":{\"data\":null,\"seqNo\":null,\"reqId\":1524612778295406000,\"identifier\":\"NNKuBP3i39niAUacUu3j8M\",\"dest\":\"NNKuBP3i39niAUacUu3j8M\",\"txnTime\":null,\"type\":\"105\"},\"op\":\"REPLY\"}" TRACE|indy::services::pool::transaction_handler|src/services/pool/transaction_handler.rs:96 | TransactionHandler::process_reply: reply_cnt: 1, f: 1 DEBUG|indy::services::pool::transaction_handler|src/services/pool/transaction_handler.rs:132 | TransactionHandler::process_reply: consensus_reached true TRACE|indy::services::pool::transaction_handler|src/services/pool/transaction_handler.rs:149 | TransactionHandler::process_reply: <<< INFO|indy::commands | src/commands/mod.rs:104 | LedgerCommand command received TRACE|indy::services::pool | src/services/pool/mod.rs:244 | zmq poll loop << INFO|indy::commands | src/commands/mod.rs:112 | DidCommand command received TRACE|indy::services::pool | src/services/pool/mod.rs:238 | zmq poll loop >> INFO|indy::commands::did | src/commands/did.rs:192 | GetNymAck command received TRACE|indy::commands::did | src/commands/did.rs:436 | Invalid structure: invalid type: null, expected a string at line 1 column 22 ERROR|indy::errors::indy | src/errors/indy.rs:68 | Casting error to ErrorCode: Invalid library state: Invalid GetNymReplyResult json ```

stanleyc-trustscience (Tue, 24 Apr 2018 21:32:33 GMT):
Hello has anyone got indy-sdk compile to android C libaries? or have any info on it? eg, `cargo build --target aarch64-linux-android`

stanleyc-trustscience (Tue, 24 Apr 2018 21:33:16 GMT):
Am currently getting this error ``` Could not find directory of OpenSSL installation, and this `-sys` crate cannot proceed without this knowledge. If OpenSSL is installed and this crate had trouble finding it, you can set the `OPENSSL_DIR` environment variable for the compilation process. ```

stanleyc-trustscience (Tue, 24 Apr 2018 21:34:28 GMT):
I do have openssl installed on the ubuntu I'm running, and cargo build compiles fine. But not when I target it to `arrach64-linux-android`

stanleyc-trustscience (Tue, 24 Apr 2018 21:35:06 GMT):
@AxelNennker How did you get those .so files for androids?

kevin.chan (Tue, 24 Apr 2018 23:48:57 GMT):
Hi, anybody know why I might be getting this error executing key_for_did? Seems like it can't parse the reply? ``` INFO|indy::services::pool | src/services/pool/mod.rs:543 | RemoteNode::recv_msg Node3 {"result":{"data":null,"seqNo":null,"reqId":1524612778295406000,"identifier":"NNKuBP3i39niAUacUu3j8M","dest":"NNKuBP3i39niAUacUu3j8M","txnTime":null,"type":"105"},"op":"REPLY"} TRACE|indy::services::pool::transaction_handler|src/services/pool/transaction_handler.rs:76 | TransactionHandler::process_reply: >>> req_id: 1524612778295406000, raw_msg: "{\"result\":{\"data\":null,\"seqNo\":null,\"reqId\":1524612778295406000,\"identifier\":\"NNKuBP3i39niAUacUu3j8M\",\"dest\":\"NNKuBP3i39niAUacUu3j8M\",\"txnTime\":null,\"type\":\"105\"},\"op\":\"REPLY\"}" TRACE|indy::services::pool::transaction_handler|src/services/pool/transaction_handler.rs:96 | TransactionHandler::process_reply: reply_cnt: 1, f: 1 DEBUG|indy::services::pool::transaction_handler|src/services/pool/transaction_handler.rs:132 | TransactionHandler::process_reply: consensus_reached true TRACE|indy::services::pool::transaction_handler|src/services/pool/transaction_handler.rs:149 | TransactionHandler::process_reply: <<< INFO|indy::commands | src/commands/mod.rs:104 | LedgerCommand command received TRACE|indy::services::pool | src/services/pool/mod.rs:244 | zmq poll loop << INFO|indy::commands | src/commands/mod.rs:112 | DidCommand command received TRACE|indy::services::pool | src/services/pool/mod.rs:238 | zmq poll loop >> INFO|indy::commands::did | src/commands/did.rs:192 | GetNymAck command received TRACE|indy::commands::did | src/commands/did.rs:436 | Invalid structure: invalid type: null, expected a string at line 1 column 22 ERROR|indy::errors::indy | src/errors/indy.rs:68 | Casting error to ErrorCode: Invalid library state: Invalid GetNymReplyResult json ```

kevin.chan (Tue, 24 Apr 2018 23:49:51 GMT):
is there something wrong with the reply format? ``` {"result":{"data":null,"seqNo":null,"reqId":1524612778295406000,"identifier":"NNKuBP3i39niAUacUu3j8M","dest":"NNKuBP3i39niAUacUu3j8M","txnTime":null,"type":"105"},"op":"REPLY"} ``` ``` Invalid structure: invalid type: null, expected a string at line 1 column 22 ```

kevin.chan (Tue, 24 Apr 2018 23:57:04 GMT):
looks like this is what happens if it can't find the key for the did i'm trying to lookup

AxelNennker (Wed, 25 Apr 2018 06:58:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=tKSoTEPXc5yCjJd8g) @stanleyc-trustscience I created the libraries for Android by compiling openssl, libsodium, libzmq for armv7-linux-androideabi. There is some manual fiddling with config-generated files that need tweaking. Having those shared libraries I continued with this repo to build libindy https://github.com/faisal00813/ . Please note that the final test still needs to happen that is putting this to use in an app. I'll write up what I did and post it somewhere.

turmewr3ck (Wed, 25 Apr 2018 07:37:11 GMT):
@AxelNennker CompletableFuture seems to be available in Android at API level 24 ... or? https://developer.android.com/reference/java/util/concurrent/CompletableFuture.html

AxelNennker (Wed, 25 Apr 2018 07:40:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4CpBpEPTqJj78spbC) @turmewr3ck True. Not sure this helps us now... Maybe reimplement as IndyCompletableFuture?

AxelNennker (Wed, 25 Apr 2018 11:17:20 GMT):
Building openssl for libindy and Android https://ignisvulpis.blogspot.de/2018/04/building-openssl-for-libindy-and-android.html

stanleyc-trustscience (Wed, 25 Apr 2018 17:46:07 GMT):
@AxelNennker Thank you very much! Much appreciate your work! :) You should consider making a PR to indy-sdk git repo for this walkthrough

stanleyc-trustscience (Wed, 25 Apr 2018 17:46:07 GMT):
@AxelNennker Thank you very much! Much appreciate your work! :) You should consider making a PR to indy-sdk git repo for this walkthrough - as I did get stucked on the openssl step before. I am going to try out your procedure now. Thanks!

sklump (Thu, 26 Apr 2018 11:06:52 GMT):
Could someone kindly point me to an up-to-date document regarding revocation in current the indy-sdk design? Thanks in advance.

sklump (Thu, 26 Apr 2018 11:06:52 GMT):
Could someone kindly point me to design documentation regarding revocation in current the indy-sdk design? I.e., * tails files? * what is a revocation registry and what are configuration options? * what is the revocation delta all about? * are credential definitions still only good for a finite number of credentials to issue? * what are the semantics of the non-revocation dicts, per-attribute/per-predicate/omnibus, in a proof request? _(In particular, I don't understand what "80" and "100" signify as `non_revoked[from/to]` values the sample)_ * is it possible to toggle a revocation? _(i.e., suspension, for duty rotation, parental leave, etc)_ Thanks in advance.

sklump (Thu, 26 Apr 2018 11:06:52 GMT):
Could someone kindly point me to design documentation regarding revocation in current the indy-sdk design? I.e., * tails files? * what is a revocation registry and what are configuration options? * what is the revocation delta all about? * are credential definitions still only good for a finite number of credentials to issue? Does this somehow have something to do with the `tag`? * what are the semantics of the non-revocation dicts, per-attribute/per-predicate/omnibus, in a proof request? _(In particular, I don't understand what "80" and "100" signify as `non_revoked[from/to]` values the sample)_ * is it possible to toggle a revocation? _(i.e., suspension, for duty rotation, parental leave, etc)_ Thanks in advance.

sklump (Thu, 26 Apr 2018 11:06:52 GMT):
Could someone kindly point me to design documentation regarding revocation in current the indy-sdk design? I.e., * tails files - who maintains them, how long to retain them, how much space to plan for them? * what is a revocation registry and what are configuration options? * what is the revocation delta all about? * are credential definitions still only good for a finite number of credentials to issue? Does this somehow have something to do with the `tag`? * what are the semantics of the non-revocation dicts, per-attribute/per-predicate/omnibus, in a proof request? _(In particular, I don't understand what "80" and "100" signify as `non_revoked[from/to]` values the sample)_ * is it possible to toggle a revocation? _(i.e., suspension, for duty rotation, parental leave, etc)_ Thanks in advance.

sklump (Thu, 26 Apr 2018 11:06:52 GMT):
Could someone kindly point me to design documentation regarding revocation in current the indy-sdk design? I.e., * tails files - who maintains them, how long to retain them, how much space to plan for them? * what is a revocation registry and what are configuration options? * what is the revocation delta all about? * are credential definitions still only good for a finite number of credentials to issue? Does this somehow have something to do with the `tag`? * what are the semantics of the non-revocation dicts, per-attribute/per-predicate/omnibus, in a proof request? _(In particular, I don't understand what `80` and `100` signify in sample code `... "non_revoked": {"from": 80, "to": 100}`)_ * is it possible to toggle a revocation? _(i.e., suspension, for duty rotation, parental leave, etc)_ Thanks in advance.

sklump (Thu, 26 Apr 2018 11:06:52 GMT):
Could someone kindly point me to design documentation regarding revocation in current the indy-sdk design? I.e., * tails files - who maintains them, how long to retain them, how much space to plan for them? * what is a revocation registry and what are configuration options? * what is the revocation delta all about? * are credential definitions still only good for a finite number of credentials to issue? Does this somehow have something to do with the `tag`? * is it possible to toggle a revocation? _(i.e., suspension, for duty rotation, parental leave, etc)_ Thanks in advance.

sklump (Thu, 26 Apr 2018 11:06:52 GMT):
Could someone kindly point me to design documentation regarding revocation in current the indy-sdk design? I.e., * tails files - who maintains them, how long to retain them, how much space to plan for them? * what is a revocation registry and what are configuration options? * what is the revocation delta all about? * are credential definitions still only good for a finite number of credentials to issue? Does this somehow have something to do with the `tag`? * is it possible to toggle a revocation? _(i.e., suspension, for duty rotation, parental leave, etc)_ _Update:_ It turns out that the docstring comments in the python wrappers help quite a bit. What would really help me get the spirit of the thing is a swim-lanes diagram, maybe in PUML. Is there one? Thanks in advance.

gudkov (Thu, 26 Apr 2018 12:26:43 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/doc/design/anoncreds/anoncreds-workflow.svg

gudkov (Thu, 26 Apr 2018 12:27:41 GMT):
Some info about tails https://github.com/hyperledger/indy-sdk/blob/master/doc/design/anoncreds/anoncreds-design.md#blob-storage

andrej-zirko (Thu, 26 Apr 2018 13:54:23 GMT):
Has joined the channel.

andrej-zirko (Thu, 26 Apr 2018 13:58:51 GMT):
Hi guys, I started to play with indy. I'm using java-wrapper. When I try to open pool, I get "org.hyperledger.indy.sdk.InvalidStateException: The SDK library experienced an unexpected internal error". Are there some native lib logs where I can get more details? Are there any guidelines how to analyze lib errors in general? Thank you

sklump (Thu, 26 Apr 2018 14:47:49 GMT):
Given that both the credential definition and revocation registry take a tag parameter, I am hoping that it is possible for the same credential definition now to pertain to multiple revocation registries, hence allowing it to issue an unlimited number of credentials? I.e., it is the revocation registry that has the limit on the number of credentials now, and the Issuer can just create a new revocation registry after it issues as many credentials on a credential definition as the old registry could hold?

gudkov (Thu, 26 Apr 2018 15:05:07 GMT):
@sklump Revocation registry is limited in size, but you can use multiple registries for one credential definition.

gudkov (Thu, 26 Apr 2018 15:05:43 GMT):
Bigger size of registry causes bigger size of tails file that needs to be distributed by issuer

stanleyc-trustscience (Thu, 26 Apr 2018 15:39:44 GMT):
Hey @AxelNennker and all android developers here, how many of you have got the indy-sdk compiled and running on Android?

turmewr3ck (Thu, 26 Apr 2018 15:46:38 GMT):
If I see the warnings "unhandled msg Pong" and "unhandled msg ReqACK" apparently after a SignAndSubmitRequest, what has happened? Seems that SignAndSubmitRequest times out. I a message lost somewhere, and if so, is it the responsibility of the app developer to re-issue a new SignAndSubmitRequest.

turmewr3ck (Thu, 26 Apr 2018 15:46:38 GMT):
If I see the warnings "unhandled msg Pong" and "unhandled msg ReqACK" apparently after a SignAndSubmitRequest, what has happened? Seems that SignAndSubmitRequest times out. If a message lost somewhere, and if so, is it the responsibility of the app developer to re-issue a new SignAndSubmitRequest.

turmewr3ck (Thu, 26 Apr 2018 15:46:38 GMT):
If I see the warnings "unhandled msg Pong" and "unhandled msg ReqACK" apparently after a SignAndSubmitRequest, what has happened? Seems that SignAndSubmitRequest times out. Is a message lost somewhere, and if so, is it the responsibility of the app developer to re-issue a new SignAndSubmitRequest.

turmewr3ck (Thu, 26 Apr 2018 15:46:38 GMT):
If I see the warnings "unhandled msg Pong" and "unhandled msg ReqACK" apparently after a SignAndSubmitRequest, what has happened? Seems that SignAndSubmitRequest times out. Is a message lost somewhere, and if so, is it the responsibility of the app developer to re-issue a new SignAndSubmitRequest?

AxelNennker (Thu, 26 Apr 2018 15:50:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=d6nNtkB93zKdPGrGk) @stanleyc-trustscience I am in the stage that the libraries are compiled. Noticed too late that I seem to need the arm64 version. Building those now. Hopefully the error of _ZNSs4_Rep20_S_empty_rep_storageE being undefined does not reappear.

stanleyc-trustscience (Thu, 26 Apr 2018 15:52:33 GMT):
@AxelNennker Morning! :), Actually, I got stucked with your guide ``` ubuntudev@ubuntudev-vm:~/dev/openssl-1.0.2o$ make making all in crypto... make[1]: Entering directory '/home/ubuntudev/dev/openssl-1.0.2o/crypto' gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM --sysroot=/usr/local/android-ndk-r16b/toolchains/arm/sysroot/ -c -o cversion.o cversion.c In file included from /usr/local/android-ndk-r16b/toolchains/arm/sysroot/usr/include/linux/signal.h:21:0, from /usr/local/android-ndk-r16b/toolchains/arm/sysroot/usr/include/signal.h:44, from /usr/local/android-ndk-r16b/toolchains/arm/sysroot/usr/include/sys/select.h:36, from /usr/local/android-ndk-r16b/toolchains/arm/sysroot/usr/include/unistd.h:35, from ../e_os.h:468, from cryptlib.h:65, from cversion.c:59: /usr/local/android-ndk-r16b/toolchains/arm/sysroot/usr/include/signal.h:96:18: error: expected ':', ',', ';', '}' or '__attribute__' before '.' token sighandler_t sa_handler; ^ : recipe for target 'cversion.o' failed make[1]: *** [cversion.o] Error 1 make[1]: Leaving directory '/home/ubuntudev/dev/openssl-1.0.2o/crypto' Makefile:287: recipe for target 'build_crypto' failed make: *** [build_crypto] Error 1 ```

stanleyc-trustscience (Thu, 26 Apr 2018 15:52:33 GMT):
@AxelNennker Morning! :), Actually, I got stucked with your guide. Sorry it s a bit long ``` ubuntudev@ubuntudev-vm:~/dev/openssl-1.0.2o$ make making all in crypto... make[1]: Entering directory '/home/ubuntudev/dev/openssl-1.0.2o/crypto' gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM --sysroot=/usr/local/android-ndk-r16b/toolchains/arm/sysroot/ -c -o cversion.o cversion.c In file included from /usr/local/android-ndk-r16b/toolchains/arm/sysroot/usr/include/linux/signal.h:21:0, from /usr/local/android-ndk-r16b/toolchains/arm/sysroot/usr/include/signal.h:44, from /usr/local/android-ndk-r16b/toolchains/arm/sysroot/usr/include/sys/select.h:36, from /usr/local/android-ndk-r16b/toolchains/arm/sysroot/usr/include/unistd.h:35, from ../e_os.h:468, from cryptlib.h:65, from cversion.c:59: /usr/local/android-ndk-r16b/toolchains/arm/sysroot/usr/include/signal.h:96:18: error: expected ':', ',', ';', '}' or '__attribute__' before '.' token sighandler_t sa_handler; ^ : recipe for target 'cversion.o' failed make[1]: *** [cversion.o] Error 1 make[1]: Leaving directory '/home/ubuntudev/dev/openssl-1.0.2o/crypto' Makefile:287: recipe for target 'build_crypto' failed make: *** [build_crypto] Error 1 ```

stanleyc-trustscience (Thu, 26 Apr 2018 15:54:05 GMT):
I'm not a professional android developer, so seems like it's quite difficult for me to figure this out

AxelNennker (Thu, 26 Apr 2018 15:55:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=AgqQwS26PSwTC8dJm) @stanleyc-trustscience Why gcc? Shouldn't be the compiler be aarch64-linux-android-clang for arm64?

stanleyc-trustscience (Thu, 26 Apr 2018 15:55:50 GMT):
@AxelNennker I'm not sure how to change the compiler to aarch64-linux-android-clang for arm64

AxelNennker (Thu, 26 Apr 2018 15:57:02 GMT):
Edit Setenv-android.sh. Can I upload a file here?

stanleyc-trustscience (Thu, 26 Apr 2018 15:57:55 GMT):

New Text Document.txt

stanleyc-trustscience (Thu, 26 Apr 2018 15:58:05 GMT):
Looks like you can

stanleyc-trustscience (Thu, 26 Apr 2018 15:58:05 GMT):
Looks like you can @AxelNennker

AxelNennker (Thu, 26 Apr 2018 16:00:21 GMT):

setenv-android.txt

stanleyc-trustscience (Thu, 26 Apr 2018 16:03:34 GMT):

Setenv-android-stanley.txt

stanleyc-trustscience (Thu, 26 Apr 2018 16:03:52 GMT):
@AxelNennker Mine above, looks like I'm missing a bunch of stuff, after comparing with yours. Thanks for sharing!

stanleyc-trustscience (Thu, 26 Apr 2018 16:03:52 GMT):
@AxelNennker Mine above, looks like I'm missing a bunch of stuff, after comparing with your

smithbk (Thu, 26 Apr 2018 16:13:16 GMT):
Can someone tell me how the credential's encoded attribute values are computed and/or used as in the following from the Getting Started Guide: ``` transcript_cred_values = json.dumps({ "first_name": {"raw": "Alice", "encoded": "1139481716457488690172217916278103335"}, "last_name": {"raw": "Garcia", "encoded": "5321642780241790123587902456789123452"}, "degree": {"raw": "Bachelor of Science, Marketing", "encoded": "12434523576212321"}, "status": {"raw": "graduated", "encoded": "2213454313412354"}, "ssn": {"raw": "123-45-6789", "encoded": "3124141231422543541"}, "year": {"raw": "2015", "encoded": "2015"}, "average": {"raw": "5", "encoded": "5"} })```

sklump (Thu, 26 Apr 2018 16:23:38 GMT):
There is no intrinsic standard. It is application-specific. Feel free to adapt these heuristic encode/decode routines: https://github.com/PSPC-SPAC-buyandsell/von_agent/blob/master/von_agent/codec.py

smithbk (Thu, 26 Apr 2018 16:49:57 GMT):
@sklump thanks

sklump (Thu, 26 Apr 2018 16:53:31 GMT):
Back on revocation. Is there any way for the Issuer to determine, by the state of a revocation registry, how many credentials it has issued against it? I want to avoid creating something heavy like a database to keep track of one tiny piece of info.

sklump (Thu, 26 Apr 2018 16:53:31 GMT):
Back on revocation. Is there any way for the Issuer to determine, by the state of a revocation registry (or maybe a tails file), how many credentials it has issued against it? I want to avoid creating something heavy like a database to keep track of one tiny piece of info.

sklump (Thu, 26 Apr 2018 16:53:31 GMT):
~Back on revocation. Is there any way for the Issuer to determine, by the state of a revocation registry (or maybe a tails file), how many credentials it has issued against it? I want to avoid creating something heavy like a database to keep track of one tiny piece of info.~ _Update_: the trick is to let the indy-sdk handle it and not try to anticipate. `IndyError.AnoncredsRevocationRegistryFullError` (== 400) comes up if the Issuer tries to put too many in. Hurray!

AxelNennker (Thu, 26 Apr 2018 17:20:50 GMT):
@stanleyc-trustscience I had to change setenv-android.sh more then I liked - or maybe I did not understand how it was intended to be used. Even had to fiddle with the dont-fiddle-with stuff

stanleyc-trustscience (Thu, 26 Apr 2018 17:21:46 GMT):
@AxelNennker Thanks, I've pm'ed you, can you take a look. Thanks!

AxelNennker (Thu, 26 Apr 2018 17:42:10 GMT):
Getting libindy to run on Android I have build the libraries but when I System.loadLibrary them I get a can not resolve _ZTVN10__cxxabiv120__si_class_type_infoE. Dang. Probably something with STL

AxelNennker (Thu, 26 Apr 2018 17:42:10 GMT):
Getting libindy to run on Android I have build the libraries but when I System.loadLibrary them I get a _ZTVN10__cxxabiv120__si_class_type_infoE. Dang. Probably something with STL

stanleyc-trustscience (Thu, 26 Apr 2018 18:39:51 GMT):
Dang, that's very close lol

CabMorris14 (Thu, 26 Apr 2018 22:50:50 GMT):
Has joined the channel.

smithbk (Fri, 27 Apr 2018 03:06:51 GMT):
I'm trying to understand this line in the python getting started at https://github.com/hyperledger/indy-sdk/blob/master/samples/python/src/getting_started.py#L179 which is ```alice_faber_verkey = await did.key_for_did(pool_handle, acme_wallet, faber_alice_connection_response['did'])```This is in the context of Faber issuing a transcript to Alice. So why is it using **acme_wallet**. I would have expected it to be **faber_wallet**.

gudkov (Fri, 27 Apr 2018 06:52:14 GMT):
> This is in the context of Faber issuing a transcript to Alice. So why is it using *acme_wallet*? I would have expected it to be *faber_wallet*. Thanks It seems like error. It still works because did is resolved from the ledger.

smithbk (Fri, 27 Apr 2018 17:34:25 GMT):
@gudkov thanks

kevin.chan (Fri, 27 Apr 2018 18:12:33 GMT):
Hi, I've been trying to work through some of the example python code and writing up my own version of it. I've hit a strange issue that maybe somebody here can help me understand. I'm using the RC branch of indy-node and indy-sdk. Starting the nodes using this docker file: https://github.com/hyperledger/indy-sdk/blob/master/ci/indy-pool.dockerfile And building the indy-sdk locally from the RC branch. In my test.py script, I've created a schema, and in the response from the ledger I do see that attr_names exist, but later when I try to read back the schema using get schema request it does not return the attr_names back to me. ``` 2018-04-27 11:07:10,866 DEBUG test.py:276 - send schema response: { "op": "REPLY", "result": { "identifier": "4G249XeD5XKVwcoSuSCH4J", "signature": "5wnyg6EudY37sYomwQgEtpT4G2iPLLvC8ynv2rRGpkpoUXiGLi1J8f6GkAFyt4Mb1vJ23ntfFi26HnuQpKEPscN9", "reqId": 1524852430798041000, "txnTime": 1524852501, "auditPath": [ "Fj8vfTA7oGSsaAZ5ZwniLhM6L9cLhxA6mXgfX4DCBYjZ", "6bBVJkZeNF7er1LxA2ySWN6y5CsmnvtiQqum6o88nhGA", "6EXKepPvfLgC9AwxeNT9EQVi26hk3ixKBQJ9Af6EuAAF", "B14QSZ6kEqvjTJ8TDH3Mop33oeSrZXEapvag6yTTUKTR" ], "data": { "version": "1.0", "attr_names": [ "student_name", "status", "year", "ssn", "degree" ], "name": "Transcript" }, "type": "101", "signatures": null, "seqNo": 617, "rootHash": "Dh882w1NPZoFMhV2KpSMMi61FAA7PEYNruGww8KW8CXv" } } ``` 2018-04-27 11:07:10,884 DEBUG test.py:283 - get schema response: { "op": "REPLY", "result": { "identifier": "4G249XeD5XKVwcoSuSCH4J", "state_proof": { "root_hash": "6v87DjZhJguqkfDpD3W1CcD9NeqeogzNAKGKwFMQhoZ8", "multi_signature": { "value": { "pool_state_root_hash": "n6VPkuHJYFPk6Lnzk6wFKE8HQkwiXvPXfWPb1Xw5zp4", "timestamp": 1524852501, "txn_root_hash": "Dh882w1NPZoFMhV2KpSMMi61FAA7PEYNruGww8KW8CXv", "ledger_id": 1, "state_root_hash": "6v87DjZhJguqkfDpD3W1CcD9NeqeogzNAKGKwFMQhoZ8" }, "participants": [ "Node1", "Node3", "Node4" ], "signature": "QksyMw6E6NpzFPtZBQdbBn1zh9vgTjGvRMpggajrHrge83TixggqcKebiF5oLvsPbaFhEzjSiaeJtyXCYAynXGNLryi6tjGk3cRGFknEksXppKgdT14iMPczDATvf8vHso4NHfeCYxypWKnEr2cbJ4BxF4MQrSerqrNXncKU2bcGqD" }, "proof_nodes": "+QS7+JGAgICgADQ2IGvQli6eOriNQxl3E1wTUiNxmARbJnPuVR7yr6CAgICAoBPjJctWjvxn/cusocW2vJeD+xzCjpwTfw5D9NJjpIo9gICAgICghwUupmgFqw7lhNp9DO8eGG9xzn1nxp23m7ePH+ZweOKg5LQLoAg59UsGTg7xt7yg8vbzX+NpcurukzA8wVNzCTyA+QIRoI0qAEPp56PWMUWEUfwYEuNKmVRBmB/1hb7sVPrr+tQboJsQrOuUPycDlB4uvOD42rVbgc2r45BoYlDeGbMdsq6doJHN5pFSF5jUc1IlaTm55DfCsA5OEMF4nwIZxg+NTsJUoAsDCOeP5f1kXM27/8YpzCAL9IuquiXyBsE1QQR2H8pwoBnFoQksC5x7/4EXsT7N5EpZ/5XeLktjNRW82mSrSDjSoM9E4i9+bvWKCR8zxgwnZnoVnJLIUuHH/T5ixf23nGDQoDrxTCNb64JrhthwUvMYQXsObseq1jNvQuWkGgu+Z8wLoC6khCEd0zaZ4FqQVeJfOcymn5ki+JMIaJgTjyVYi/RQoM14JeqFpZQ4f5NvhVATK37AsCPx4zOH8mhUNWWCfaCIoMTlxY1y3cyf87gEQDDQLT+ExhUrM+Uf2ZTkR+9toA4AoFOI7eV8cqwP9QclrMDrIGSmKw89js4PshxAAJYo/Z8roB1Sx64FEclM2FM44E09XrG//bBDdRMfXM6025OtskkWoJCOjQxaXUvRPKBEqnCk180wQkee1WU3wFlr0wyRvD5voCmMYp+6Ji0NU02VwGctJDdZKJA9R0wJrqUuGrKUkiq2oIK7KwSPXccAxDMFmp7xXTJ87/qxoSjWh2Mqn3fPauByoI24ef7tTDYgcwIi4MN3XaukLtjDioZYhDx0Yy3QKLCCgPkCEaDt2Q7ZKekFB2bvZBoqBZikXoXIQOWSNJf7YoKdOR7ifqB4KS8kPWbGuTWch+Nkk0UcCKrOQVlYyfNUpzrp5gIOIKATGKVFvFx6w1dqqcHlcttNepl1l4PBKr0ZUodJGB+yQKCruUMn5lmvM88fY2NOlp2v1M+3u30sjAE+ojBJB7oUtqDxOGRj/mpix+bCWslEWp4nObgpvyr7W+e6TvFNpPbL/6BVlojGo4rCu5UraDW7vAuG8xZ3UIbj5UKlduRhkIPJc6A9FLEP8V1lmc6x/yy0aVZJfrMx8+q0K+0OV7iI8AdYJKBB08aXV7Z6y3uIeF5EhjHAk1vbQV2nxjdRGqKu9J2ldKBObq/gfw3mHlE4oGPJQneJf8G1DZZSmy1k+PhWfd5096DdqPaQI4eDqWuf/KA6AwnnCkwt+2iZPCazAdMe+HZMIKBAvue7eKnA1emdzr7znyGJSjSEvUMZbHnSX/lOWX05gaBoKQJmg25T73s5TiLQ+nPmJpDEZKkgy75ZuTB6fJFwzaB5MyCLaWcsn0Q3PLpt9sNUJ1w7Pk/iCcWlMA2zpjnIkKCXJZ7ytu7itU6z1M9esD9i/NUOYj2VfR+iL/aMgphWEaCoYAdMRh9GkQKupTtnuDy0yGqw+vH5P5+mKn1APZb86qBHB0hIiXVfrFsTEYCpR8+hb2dluj7ZKEvjyI9GSRiEloA=" }, "data": { "version": "1.0", "name": "Transcript" }, "txnTime": null, "reqId": 1524852430867246000, "dest": "AsW52DoSwFejGpQCTTmwmM", "seqNo": null, "type": "107" } } ``` anybody have any clues?

kevin.chan (Fri, 27 Apr 2018 18:12:33 GMT):
Hi, I've been trying to work through some of the example python code and writing up my own version of it. I've hit a strange issue that maybe somebody here can help me understand. I'm using the RC branch of indy-node and indy-sdk. Starting the nodes using this docker file: https://github.com/hyperledger/indy-sdk/blob/master/ci/indy-pool.dockerfile And building the indy-sdk locally from the RC branch. In my test.py script, I've created a schema, and in the response from the ledger I do see that attr_names exist, but later when I try to read back the schema using get schema request it does not return the attr_names back to me. ``` 2018-04-27 11:07:10,866 DEBUG test.py:276 - send schema response: { "op": "REPLY", "result": { "identifier": "4G249XeD5XKVwcoSuSCH4J", "signature": "5wnyg6EudY37sYomwQgEtpT4G2iPLLvC8ynv2rRGpkpoUXiGLi1J8f6GkAFyt4Mb1vJ23ntfFi26HnuQpKEPscN9", "reqId": 1524852430798041000, "txnTime": 1524852501, "auditPath": [ "Fj8vfTA7oGSsaAZ5ZwniLhM6L9cLhxA6mXgfX4DCBYjZ", "6bBVJkZeNF7er1LxA2ySWN6y5CsmnvtiQqum6o88nhGA", "6EXKepPvfLgC9AwxeNT9EQVi26hk3ixKBQJ9Af6EuAAF", "B14QSZ6kEqvjTJ8TDH3Mop33oeSrZXEapvag6yTTUKTR" ], "data": { "version": "1.0", "attr_names": [ "student_name", "status", "year", "ssn", "degree" ], "name": "Transcript" }, "type": "101", "signatures": null, "seqNo": 617, "rootHash": "Dh882w1NPZoFMhV2KpSMMi61FAA7PEYNruGww8KW8CXv" } } ``` ``` 2018-04-27 11:07:10,884 DEBUG test.py:283 - get schema response: { "op": "REPLY", "result": { "identifier": "4G249XeD5XKVwcoSuSCH4J", "state_proof": { "root_hash": "6v87DjZhJguqkfDpD3W1CcD9NeqeogzNAKGKwFMQhoZ8", "multi_signature": { "value": { "pool_state_root_hash": "n6VPkuHJYFPk6Lnzk6wFKE8HQkwiXvPXfWPb1Xw5zp4", "timestamp": 1524852501, "txn_root_hash": "Dh882w1NPZoFMhV2KpSMMi61FAA7PEYNruGww8KW8CXv", "ledger_id": 1, "state_root_hash": "6v87DjZhJguqkfDpD3W1CcD9NeqeogzNAKGKwFMQhoZ8" }, "participants": [ "Node1", "Node3", "Node4" ], "signature": "QksyMw6E6NpzFPtZBQdbBn1zh9vgTjGvRMpggajrHrge83TixggqcKebiF5oLvsPbaFhEzjSiaeJtyXCYAynXGNLryi6tjGk3cRGFknEksXppKgdT14iMPczDATvf8vHso4NHfeCYxypWKnEr2cbJ4BxF4MQrSerqrNXncKU2bcGqD" }, "proof_nodes": "+QS7+JGAgICgADQ2IGvQli6eOriNQxl3E1wTUiNxmARbJnPuVR7yr6CAgICAoBPjJctWjvxn/cusocW2vJeD+xzCjpwTfw5D9NJjpIo9gICAgICghwUupmgFqw7lhNp9DO8eGG9xzn1nxp23m7ePH+ZweOKg5LQLoAg59UsGTg7xt7yg8vbzX+NpcurukzA8wVNzCTyA+QIRoI0qAEPp56PWMUWEUfwYEuNKmVRBmB/1hb7sVPrr+tQboJsQrOuUPycDlB4uvOD42rVbgc2r45BoYlDeGbMdsq6doJHN5pFSF5jUc1IlaTm55DfCsA5OEMF4nwIZxg+NTsJUoAsDCOeP5f1kXM27/8YpzCAL9IuquiXyBsE1QQR2H8pwoBnFoQksC5x7/4EXsT7N5EpZ/5XeLktjNRW82mSrSDjSoM9E4i9+bvWKCR8zxgwnZnoVnJLIUuHH/T5ixf23nGDQoDrxTCNb64JrhthwUvMYQXsObseq1jNvQuWkGgu+Z8wLoC6khCEd0zaZ4FqQVeJfOcymn5ki+JMIaJgTjyVYi/RQoM14JeqFpZQ4f5NvhVATK37AsCPx4zOH8mhUNWWCfaCIoMTlxY1y3cyf87gEQDDQLT+ExhUrM+Uf2ZTkR+9toA4AoFOI7eV8cqwP9QclrMDrIGSmKw89js4PshxAAJYo/Z8roB1Sx64FEclM2FM44E09XrG//bBDdRMfXM6025OtskkWoJCOjQxaXUvRPKBEqnCk180wQkee1WU3wFlr0wyRvD5voCmMYp+6Ji0NU02VwGctJDdZKJA9R0wJrqUuGrKUkiq2oIK7KwSPXccAxDMFmp7xXTJ87/qxoSjWh2Mqn3fPauByoI24ef7tTDYgcwIi4MN3XaukLtjDioZYhDx0Yy3QKLCCgPkCEaDt2Q7ZKekFB2bvZBoqBZikXoXIQOWSNJf7YoKdOR7ifqB4KS8kPWbGuTWch+Nkk0UcCKrOQVlYyfNUpzrp5gIOIKATGKVFvFx6w1dqqcHlcttNepl1l4PBKr0ZUodJGB+yQKCruUMn5lmvM88fY2NOlp2v1M+3u30sjAE+ojBJB7oUtqDxOGRj/mpix+bCWslEWp4nObgpvyr7W+e6TvFNpPbL/6BVlojGo4rCu5UraDW7vAuG8xZ3UIbj5UKlduRhkIPJc6A9FLEP8V1lmc6x/yy0aVZJfrMx8+q0K+0OV7iI8AdYJKBB08aXV7Z6y3uIeF5EhjHAk1vbQV2nxjdRGqKu9J2ldKBObq/gfw3mHlE4oGPJQneJf8G1DZZSmy1k+PhWfd5096DdqPaQI4eDqWuf/KA6AwnnCkwt+2iZPCazAdMe+HZMIKBAvue7eKnA1emdzr7znyGJSjSEvUMZbHnSX/lOWX05gaBoKQJmg25T73s5TiLQ+nPmJpDEZKkgy75ZuTB6fJFwzaB5MyCLaWcsn0Q3PLpt9sNUJ1w7Pk/iCcWlMA2zpjnIkKCXJZ7ytu7itU6z1M9esD9i/NUOYj2VfR+iL/aMgphWEaCoYAdMRh9GkQKupTtnuDy0yGqw+vH5P5+mKn1APZb86qBHB0hIiXVfrFsTEYCpR8+hb2dluj7ZKEvjyI9GSRiEloA=" }, "data": { "version": "1.0", "name": "Transcript" }, "txnTime": null, "reqId": 1524852430867246000, "dest": "AsW52DoSwFejGpQCTTmwmM", "seqNo": null, "type": "107" } } ``` anybody have any clues?

kevin.chan (Fri, 27 Apr 2018 19:45:41 GMT):
ah ok, looks like I didn't successfully create the schema afterall after inspecting the type codes

kevin.chan (Fri, 27 Apr 2018 19:45:41 GMT):
ah ok, looks like I didn't successfully create the schema afterall

sugarcookie (Mon, 30 Apr 2018 00:24:44 GMT):
Hi @ianco, I read the updates on wallet, other than tagging, is there way to store wallet in customized way now? (forgive me if I miss any info on document), thanks

sugarcookie (Mon, 30 Apr 2018 00:24:44 GMT):
Hi @ianco, I read the updates on wallet, https://github.com/hyperledger/indy-sdk/blob/master/doc/design/wallet/wallet-design.md, is tagging supported now? Is there way to store wallet in customized way now? (forgive me if I miss any info on document), thanks

AnhDung (Mon, 30 Apr 2018 08:37:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=QwZb2vAmhvBycKaBN) Hi, I'm new to the SDK, as interesting find from @sugarcookie , with the design of the Wallet, how do you vision a wallet design for a mobile application? For instance, given iOS device, it will use iOS SDK and directly connects to one of the indy node? I am trying to figure out users can actually hand on their data on mobile app. Thanks for the hints :)

lcinacio (Mon, 30 Apr 2018 11:13:45 GMT):
Hi. Is it possible to add a role (e.g. TRUST_ANCHOR) to a nym after the initial ledger.build_nym_request/ledger.sign_and_submit_request was done without role? I tried calling these functions again for the same nym but passing TRUST_ANCHOR as role, but I get error message saying that the submitter is not trustee nor owner of the did...

sklump (Mon, 30 Apr 2018 12:36:59 GMT):
*Question re: revocation and tails files* The Issuer at startup may already have a tails file from a prior iteration, and/or for other credential definitions. I notice that the tails file is a new file (with a new name) on every call to `anoncreds.issuer_create_and_store_revoc_reg()`. The Prover needs the tails file to create the revocation state (via the blob storage handle, in `anoncreds.create_revocation_state()`. The Issuer has to supply the current Tails file to the Prover out of band. How does the Issuer determine which tails file corresponds to any given credential definition?

sklump (Mon, 30 Apr 2018 12:36:59 GMT):
*Questions re: revocation and tails files* The Issuer at startup may already have a tails file from a prior iteration, and/or for other credential definitions. I notice that the tails file is a new file (with a new name) on every call to `anoncreds.issuer_create_and_store_revoc_reg()`. *(1)* The Prover needs the tails file to create the revocation state (via the blob storage handle, in `anoncreds.create_revocation_state()`. The Issuer has to supply the current Tails file to the Prover out of band. How does the Issuer determine which tails file corresponds to any given credential definition? *(2a)* Is there a way to take a tails file (from a prior Issuer life) and tell indy-sdk to use it, assuming I found a way to retain the association to the correct revocation registry identifier? _Update 1: it appears that the `file` parameter in the tails-config works for this, only if the file is already present_ _Update 2: next order of business, renaming it on creation so a future iteration can recognize its revocation registry -- doing so and trying to pass its new name via `file` (within the tails config) wrecks the call to `blob_storage.open_reader()`. Disappointing. Does anyone know a workaround?_ *(2b)* Failing that, is there any harm in recreating the tails file every time via `anoncreds.create_revocation_state()`? Would the Issuer have to re-post the revocation registry to the ledger in this case? _(That would lead to ugly unnecessary ledger bloat)_.

sklump (Mon, 30 Apr 2018 12:36:59 GMT):
*Questions re: revocation and tails files* The Issuer at startup may already have a tails file from a prior iteration, and/or for other credential definitions. I notice that the tails file is a new file (with a new name) on every call to `anoncreds.issuer_create_and_store_revoc_reg()`. *(1)* The Prover needs the tails file to create the revocation state (via the blob storage handle, in `anoncreds.create_revocation_state()`. The Issuer has to supply the current Tails file to the Prover out of band. How does the Issuer determine which tails file corresponds to any given credential definition? *(2a)* Is there a way to take a tails file (from a prior Issuer life) and tell indy-sdk to use it, assuming I found a way to retain the association to the correct revocation registry identifier? _Update 1: it appears that the `file` parameter in the tails-config works for this, only if the file is already present_ _Update 2: next order of business, renaming it on creation so a future iteration can recognize its revocation registry -- doing so and trying to pass its new name via `file` (within the tails config) wrecks the call to `blob_storage.open_reader()`. Disappointing. Does anyone know a workaround?_ _Update 3: I'm going to sleaze around it with symbolic links. Horrible. If there's a better answer for how to associate existing tails files with existing revocation registries, I'd love to know it_ *(2b)* Failing that, is there any harm in recreating the tails file every time via `anoncreds.create_revocation_state()`? Would the Issuer have to re-post the revocation registry to the ledger in this case? _(That would lead to ugly unnecessary ledger bloat)_. The overarching motivation is to retain Issuer as a stateless entity between starts. I do not want to introduce a database or whatnot for every start and stop - for loads of obvious reasons.

sklump (Mon, 30 Apr 2018 12:36:59 GMT):
*Questions re: revocation and tails files* The Issuer at startup may already have a tails file from a prior iteration, and/or for other credential definitions. I notice that the tails file is a new file (with a new name) on every call to `anoncreds.issuer_create_and_store_revoc_reg()`. *(1)* The Prover needs the tails file to create the revocation state (via the blob storage handle, in `anoncreds.create_revocation_state()`. The Issuer has to supply the current Tails file to the Prover out of band. How does the Issuer determine which tails file corresponds to any given credential definition? *(2a)* Is there a way to take a tails file (from a prior Issuer life) and tell indy-sdk to use it, assuming I found a way to retain the association to the correct revocation registry identifier? _Update 1: it appears that the `file` parameter in the tails-config works for this, only if the file is already present_ _Update 2: next order of business, renaming it on creation so a future iteration can recognize its revocation registry -- doing so and trying to pass its new name via `file` (within the tails config) wrecks the call to `blob_storage.open_reader()`. Disappointing. Does anyone know a workaround?_ _Update 3: I'm going to sleaze around it with symbolic links. If there's a better answer for how to associate existing tails files with existing revocation registries, I'd love to know it_ *(2b)* Failing that, is there any harm in recreating the tails file every time via `anoncreds.create_revocation_state()`? Would the Issuer have to re-post the revocation registry to the ledger in this case? _(That would lead to ugly unnecessary ledger bloat)_. The overarching motivation is to retain Issuer as a stateless entity between starts. I do not want to introduce a database or whatnot for every start and stop - for loads of obvious reasons.

ianco (Mon, 30 Apr 2018 13:25:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=QwZb2vAmhvBycKaBN) @sugarcookie The design you linked is somehting the SDK team is working on and targetting for release in SDK version 1.5, in 2 or 3 sprints. There is no tagging support in the wallet now. You can build your own wallet and register it with the SDK - many people have done this, including the BC Gov has created a couple of custom wallets that we use with TheOrgBook (we have optimized to handle large data volumes). Once the new SDK wallet is out (supporting tagging) we'll update ours to comply with the new SDK API.

mbwhite (Mon, 30 Apr 2018 13:26:32 GMT):
Has joined the channel.

ianco (Mon, 30 Apr 2018 13:27:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=HfjDSeE5ciJukShJN) @AnhDung With the current SDK wallet you can't access the wallet data except through the SDK (other than direct database access to the wallet). With the new wallet design (linked by @sugarcookie) the wallet contents will be encrypted and you won't even be able to read the data outside the SDK. The new API will have some methods you can call from outside the SDK (as I understand) but it's more to test existence of credentials rather than giving full read access.

sklump (Mon, 30 Apr 2018 18:34:32 GMT):
*One more item.* I see that in a recent (1.3.1-dev-489) 1.3.1 indy-sdk release, `anoncreds.issuer_create_and_store_credential_def()` always creates a new credential definition, even if the wallet already had one on the same credential definition identifier. Before, indy-sdk used to raise `ErrorCode.AnoncredsCredDefAlreadyExistsError`. This causes some problems down the line with key mismatches - the Prover gets the cred def from the ledger, and its keys don't match the new one that the Issuer created. We stop and restart Issuers, often. On an existing Issuer wallet, I need a way to check if it already has a credential definition on a given issuer DID, schema, tag, signature type (always `CL` for now), and configuration (for us, `{'support_revocation': true}`. If I don't create the credential definition in the wallet via `anoncreds.issuer_create_and_store_credential_def()` on restart, the call to `anoncreds.issuer_create_credential_offer()` fails on `WalletNotFoundError`. If I do, the Prover call to `anoncreds.prover_create_credential_req()` raises `Invalid structure: Invalid Credential key correctness proof`. If the Issuer has to rewrite every cred def on restart to its wallet and send it again to the ledger, it will not only bloat the ledger with duelling copies, but open up a race condition for the Prover be operating on the most recent ledger entry for same. *Obviously* I am not getting an important big picture item here, I just don't see what it is. What are the steps required to restart an Issuer and have it sync up its existing wallet with the ledger? Maybe something is coming soon in 1.4 or 1.5 to help us out?

sklump (Mon, 30 Apr 2018 18:34:32 GMT):
*One more item.* I see that in a recent (1.3.1-dev-489) 1.3.1 indy-sdk release, `anoncreds.issuer_create_and_store_credential_def()` always creates a new credential definition, even if the wallet already had one on the same parameters. Before, indy-sdk used to raise `ErrorCode.AnoncredsCredDefAlreadyExistsError`. This causes some problems down the line with key mismatches - the Prover gets the cred def from the ledger, and its keys don't match the new one that the Issuer created. We stop and restart Issuers, often. On an existing Issuer wallet, I need a way to check if it already has a credential definition on a given issuer DID, schema, tag, signature type (always `CL` for now), and configuration (for us, `{'support_revocation': true}`. If I don't create the credential definition in the wallet via `anoncreds.issuer_create_and_store_credential_def()` on restart, the call to `anoncreds.issuer_create_credential_offer()` fails on `WalletNotFoundError`. If I do, the Prover call to `anoncreds.prover_create_credential_req()` raises `Invalid structure: Invalid Credential key correctness proof`. If the Issuer has to rewrite every cred def on restart to its wallet and send it again to the ledger, it will not only bloat the ledger with duelling copies, but open up a race condition for the Prover be operating on the most recent ledger entry for same. *Obviously* I am not getting an important big picture item here, I just don't see what it is. What are the steps required to restart an Issuer and have it sync up its existing wallet with the ledger? Maybe something is coming soon in 1.4 or 1.5 to help us out?

sklump (Mon, 30 Apr 2018 18:34:32 GMT):
*One more item.* I see that in a recent (1.3.1-dev-489) 1.3.1 indy-sdk release, `anoncreds.issuer_create_and_store_credential_def()` always creates a new credential definition, even if the wallet already had one on the same parameters. Before, indy-sdk used to raise `ErrorCode.AnoncredsCredDefAlreadyExistsError`. This causes some problems down the line with key mismatches - the Prover gets the cred def from the ledger, and its keys don't match the new one that the Issuer created. We stop and restart Issuers, often. On an existing Issuer wallet, I need a way to check if it already has a credential definition on a given issuer DID, schema, tag, signature type (always `CL` for now), and configuration (for us, `{"support_revocation": true}`. If I don't create the credential definition in the wallet via `anoncreds.issuer_create_and_store_credential_def()` on restart, the call to `anoncreds.issuer_create_credential_offer()` fails on `WalletNotFoundError`. If I do, the Prover call to `anoncreds.prover_create_credential_req()` raises `Invalid structure: Invalid Credential key correctness proof`. If the Issuer has to rewrite every cred def on restart to its wallet and send it again to the ledger, it will not only bloat the ledger with duelling copies, but open up a race condition for the Prover be operating on the most recent ledger entry for same. *Obviously* I am not getting an important big picture item here, I just don't see what it is. What are the steps required to restart an Issuer and have it sync up its existing wallet with the ledger? Maybe something is coming soon in 1.4 or 1.5 to help us out?

sklump (Mon, 30 Apr 2018 18:34:32 GMT):
*One more item.* ~I see that in a recent (1.3.1-dev-489) 1.3.1 indy-sdk release, `anoncreds.issuer_create_and_store_credential_def()` always creates a new credential definition, even if the wallet already had one on the same parameters. Before, indy-sdk used to raise `ErrorCode.AnoncredsCredDefAlreadyExistsError`. This causes some problems down the line with key mismatches - the Prover gets the cred def from the ledger, and its keys don't match the new one that the Issuer created.~ <-- _update: this is my mistake. The `xwallet` scaffolding in `conftest.py` deletes the issuer wallet on every test suite exit. Sheesh. My face is red. Again. But I still would really appreciate a way to query the wallet for cred defs._ We stop and restart Issuers, often. On an existing Issuer wallet, I need a way to check if it already has a credential definition on a given issuer DID, schema, tag, signature type (always `CL` for now), and configuration (for us, `{"support_revocation": true}`. If I don't create the credential definition in the wallet via `anoncreds.issuer_create_and_store_credential_def()` on restart, the call to `anoncreds.issuer_create_credential_offer()` fails on `WalletNotFoundError`. If I do, the Prover call to `anoncreds.prover_create_credential_req()` raises `Invalid structure: Invalid Credential key correctness proof`. If the Issuer has to rewrite every cred def on restart to its wallet and send it again to the ledger, it will not only bloat the ledger with duelling copies, but open up a race condition for the Prover be operating on the most recent ledger entry for same. *Obviously* I am not getting an important big picture item here, I just don't see what it is. What are the steps required to restart an Issuer and have it sync up its existing wallet with the ledger? Maybe something is coming soon in 1.4 or 1.5 to help us out?

sklump (Mon, 30 Apr 2018 18:34:32 GMT):
*One more item.* ~I see that in a recent (1.3.1-dev-489) 1.3.1 indy-sdk release, `anoncreds.issuer_create_and_store_credential_def()` always creates a new credential definition, even if the wallet already had one on the same parameters. Before, indy-sdk used to raise `ErrorCode.AnoncredsCredDefAlreadyExistsError`. This causes some problems down the line with key mismatches - the Prover gets the cred def from the ledger, and its keys don't match the new one that the Issuer created.~ <-- _update: this is my mistake. The `xwallet` scaffolding in `conftest.py` deletes the issuer wallet on every test suite exit. Sheesh. My face is red. Again. But I still would really appreciate a way to query the wallet for cred defs._ We stop and restart Issuers, often. On an existing Issuer wallet, ~I need a way to check if it already has a credential definition on a given issuer DID, schema, tag, signature type (always `CL` for now), and configuration (for us, `{"support_revocation": true}`. If I don't create the credential definition in the wallet via `anoncreds.issuer_create_and_store_credential_def()` on restart, the call to `anoncreds.issuer_create_credential_offer()` fails on `WalletNotFoundError`. If I do, the Prover call to `anoncreds.prover_create_credential_req()` raises `Invalid structure: Invalid Credential key correctness proof`. If the Issuer has to rewrite every cred def on restart to its wallet and send it again to the ledger, it will not only bloat the ledger with duelling copies, but open up a race condition for the Prover be operating on the most recent ledger entry for same.~ *Obviously* I am not getting an important big picture item here, I just don't see what it is. What are the steps required to restart an Issuer and have it sync up its existing wallet with the ledger? Maybe something is coming soon in 1.4 or 1.5 to help us out?

swcurran (Mon, 30 Apr 2018 19:45:12 GMT):
One important issue with the ```anoncreds.issuer_create_and_store_credential_def()``` call is that it creates a Public/Private key pair, but does not allow the caller to control the Seed. libindy *does* allow the user to control the seed of most (all?) other keypairs that get created - notably the ones for DIDs. Perhaps a solution for our wallet restarts during development is to also allow the optional passing of a seed into this ```anoncreds.issuer_create_and_store_credential_def()``` call? That would eliminate the mismatched public/private key issue.

swcurran (Mon, 30 Apr 2018 19:45:12 GMT):
One important issue with the `anoncreds.issuer_create_and_store_credential_def()` call is that it creates a Public/Private key pair, but does not allow the caller to control the Seed. libindy *does* allow the user to control the seed of most (all?) other keypairs that get created - notably the ones for DIDs. Perhaps a solution for our wallet restarts during development is to also allow the optional passing of a seed into this `anoncreds.issuer_create_and_store_credential_def()` call? That would eliminate the mismatched public/private key issue.

mawi (Tue, 01 May 2018 10:18:52 GMT):
Hi all, I'm currently trying to use the ios wrapper pod in a react native project. Sadly the application crashes on startup. Does anyone have experience with using the ios wrapper/pod in react native?

sklump (Tue, 01 May 2018 10:38:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=At2tWgQXvKTsQz6xc) @swcurran Ideally, a walleted Issuer should be able to ask what credential definitions are in its wallet.

AxelNennker (Tue, 01 May 2018 14:50:43 GMT):
When compiling libzmq for Android I noticed that the provided build script does not use libsodium at all (it seems). Does libindy use libsodium outside of libzmq. If no, could we get rid of the libsodium dependency this way. libzmq uses tweetnacl (but still supports libsodium) ???

tja 16 (Tue, 01 May 2018 15:05:30 GMT):
Has joined the channel.

sklump (Tue, 01 May 2018 15:33:46 GMT):
An easy question for indy-sdk build on ubuntu. On ``` cargo build ``` I am getting ``` error: associated constants are experimental (see issue #29646) --> /home/sklump/.cargo/registry/src/github.com-1ecc6299db9ec823/typenum-1.10.0/src/bit.rs:43:5 | 43 | const U8: u8 = 0; | ^^^^^^^^^^^^^^^^^ ``` and a bunch of other similar errors, so it cannot compile `typenum`. What is the correct version of rust/cargo to be running; how do I get it?

nuxibyte (Tue, 01 May 2018 16:50:44 GMT):
Has joined the channel.

smithbk (Tue, 01 May 2018 19:45:46 GMT):
Hi, I assume that it is possible to change the role associated with a existing DID on the ledger. For example, I can change a DID will the null (common USER) role to a TRUST_ANCHOR role. Is this correct?

lcinacio (Tue, 01 May 2018 20:59:18 GMT):
@smithbk I tried and I could not make this work in my docker setup. I reported the issue a couple days ago but didn't get a reply yet. In the Sovrin Test Network Trust Anchor registration page it says "You must provide a DID/verkey pair that does not yet exist on the STN ledger."

SandeepRanjit (Wed, 02 May 2018 06:52:29 GMT):
Has joined the channel.

mawi (Wed, 02 May 2018 10:39:58 GMT):
i've seen at jira IS-326 that the iSO wrapper is used with ReactNative. I'm constantly getting errors with the podfile. Does anyone have the iOS wrapper working with react native, and if so, could you provide me with your specs?

mawi (Wed, 02 May 2018 10:39:58 GMT):
i've seen at jira IS-326 that the iOS wrapper is used with ReactNative. I'm constantly getting errors with the podfile. Does anyone have the iOS wrapper working with react native, and if so, could you provide me with your specs?

thomasmm (Wed, 02 May 2018 11:46:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JABCiTYj43ucMvp2k) @mawi I have been struggling with adding the podfile to a react native project for a few days now as well. For me, it appears that the library (objc one) was compiled using swift 4.0.x (xcode 9.0). I was using xcode 9.3 which used swift 4.1. Downgrading (i.e. also installing) xcode 9.0 and using that cli under xcode preferences enabled me compile using swift 4.0 instead of 4.1. For me, it works now.

mawi (Wed, 02 May 2018 12:00:01 GMT):
Alright, ill try that

sklump (Wed, 02 May 2018 12:39:11 GMT):
Is there a way to close blob_storage readers and writers? Is it a potential resource leak to leave them hanging around? It's probably fine?

AnhDung (Wed, 02 May 2018 12:57:44 GMT):
hi, I'm having issues when following this https://github.com/hyperledger/indy-node/blob/master/docs/indy-running-locally.md with python3.6, I got this error: `Traceback (most recent call last): File "/home/demo/.virtualenvs/new_indy/bin/generate_indy_pool_transactions", line 6, in exec(compile(open(__file__).read(), __file__, 'exec')) File "/home/demo/indy-node/dev-setup/ubuntu/indy-node/scripts/generate_indy_pool_transactions", line 3, in from plenum.common.test_network_setup import TestNetworkSetup File "/home/demo/.virtualenvs/new_indy/lib/python3.6/site-packages/plenum/common/test_network_setup.py", line 15, in from plenum.common.keygen_utils import initNodeKeysForBothStacks, init_bls_keys File "/home/demo/.virtualenvs/new_indy/lib/python3.6/site-packages/plenum/common/keygen_utils.py", line 3, in from plenum.bls.bls_crypto_factory import create_default_bls_crypto_factory File "/home/demo/.virtualenvs/new_indy/lib/python3.6/site-packages/plenum/bls/bls_crypto_factory.py", line 3, in from crypto.bls.bls_factory import BlsFactoryCrypto File "/home/demo/.virtualenvs/new_indy/lib/python3.6/site-packages/crypto/bls/bls_factory.py", line 8, in from plenum.bls.bls_store import BlsStore File "/home/demo/.virtualenvs/new_indy/lib/python3.6/site-packages/plenum/bls/bls_store.py", line 2, in from storage.helper import initKeyValueStorage File "/home/demo/.virtualenvs/new_indy/lib/python3.6/site-packages/storage/helper.py", line 11, in from storage.kv_in_memory import KeyValueStorageInMemory File "/home/demo/.virtualenvs/new_indy/lib/python3.6/site-packages/storage/kv_in_memory.py", line 3, in from rlp.utils import str_to_bytes ImportError: cannot import name 'str_to_bytes' `

AnhDung (Wed, 02 May 2018 12:57:44 GMT):
hi, I'm having issues when following this https://github.com/hyperledger/indy-node/blob/master/docs/indy-running-locally.md with python3.6, I got this error: `from rlp.utils import str_to_bytes ImportError: cannot import name 'str_to_bytes'` when trying to run generate_indy_pool_transactions. Do you have any clue? Thanks!

sklump (Wed, 02 May 2018 13:17:37 GMT):
@AnhDung this is the channel for indy-sdk. Perhaps you intended to post to https://chat.hyperledger.org/channel/indy-node.

AnhDung (Wed, 02 May 2018 13:29:40 GMT):
@sklump hi, thanks for the notice yes I will reach and ask for support :D

mboyd (Wed, 02 May 2018 15:31:53 GMT):
Does anyone know if our Developer Certificate of Origin requires the signature to be signed with GPG? It seems that it doesn't, that anyone can just put Signed-off-by: [name] in their commits and they will pass the DCO check for PRs for indy-* repos. Not necessarily a bad thing, but if we don't require a crypographic signature for DCO, why are we doing it? It seems a little redundant, but I could be missing something.

mboyd (Wed, 02 May 2018 15:31:53 GMT):
Does anyone know if our Developer Certificate of Origin requires the signature to be signed with GPG? It seems that it doesn't, that anyone can just put Signed-off-by: [name] and they will pass the DCO check for PRs. Not necessarily a bad thing, but if we don't require a crypographic signature for DCO, why are we doing it? It seems a little redundant, but I could be missing something.

SteveGoob (Wed, 02 May 2018 19:42:35 GMT):
Has joined the channel.

danielhardman (Wed, 02 May 2018 22:10:39 GMT):
Many of you have asked for an explanation of how the revocation feature works -- something that's not math-heavy, and that doesn't refer to specific chunks of code, but rather explains the basic concepts. Here is something that may help: https://github.com/hyperledger/indy-sdk/blob/master/doc/cred-revocation.md

ianco (Thu, 03 May 2018 00:40:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=TD55A7zfyji5qZYcg) @danielhardman Excellent description!

mboyd (Thu, 03 May 2018 04:32:21 GMT):
I wonder if anyone knows why this is happening: I am trying to run the IPython code in the doc/getting-started directory, but it is unable to connect to the test pool. I've documented the error here: https://jira.hyperledger.org/browse/IS-673 Has anyone successfully run the docker/jupyter getting-started walkthrough found here: https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/run-getting-started.md

sklump (Thu, 03 May 2018 11:20:55 GMT):
Generating tails files takes a *LOOOONG* time. I average about 0.25 sec per maximum credential limit (for issue on demand -- by default is slower) on an Ubuntu 16 VM with 4GB RAM. For example, suppose a medium-sized province may need up to 4 million drivers licences. That's eleven days of compute time, however we want to split it up (more, smaller tails files mean shorter, more frequent delays in credential generation). A developer innocently using the default value of 100000 can effectively hang his box for 7 hours. Surely that can't be the design intent, but I don't see what else I should have done. Is it expected that indy-sdk will only run on big iron? I don't know what we've specified on the server side for production, but this single operation is MANY ORDERS of magnitude more expensive than anything else in the toolkit, so supporting revocation might bring the house down, yet this is definitely a feature we need. Does it work appreciably faster for anyone out there, and if so what parameters work well for you? Or else, what is a good tactic to pre-compute tails files before an existing revocation registry is full? Again I come back to needing a way to query how many credentials are issued against an existing revocation registry.

sklump (Thu, 03 May 2018 11:34:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=TD55A7zfyji5qZYcg) @danielhardman Thanks for this, it's a good overview. One quibble: the accumulator value of 4928579201096624...103 equals tails file contributor at index 999999, yet the accumulator is meant to be a product. Also, the accumulator value never changes as contributors are removed as multipliers.

sklump (Thu, 03 May 2018 11:35:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=TD55A7zfyji5qZYcg) @danielhardman Thanks for this, it's a good overview. One quibble: the accumulator value of 4928579201096624...103 equals tails file contributor at index 999999, yet the accumulator is meant to be a product. Also, the accumulator value never changes as contributors are removed as multipliers.

sklump (Thu, 03 May 2018 11:49:16 GMT):
Generating tails files takes a *LOOOONG* time. I average about 0.25 sec per maximum credential limit (for issue on demand -- by default is slower) on an Ubuntu 16 VM with 4GB RAM. For example, suppose a medium-sized province may need up to 4 million drivers licences. That's eleven days of compute time, however we want to split it up (more, smaller tails files mean shorter, more frequent delays in credential generation). A developer innocently using the default value of 100000 can effectively hang his box for 7 hours. Surely that can't be the design intent, but I don't see what else I should have done. Is it expected that indy-sdk will only run on big iron? I don't know what we've specified on the server side for production, but this single operation is MANY ORDERS of magnitude more expensive than anything else in the toolkit, so supporting revocation might bring the house down, yet this is definitely a feature we need. Does it work appreciably faster for anyone out there, and if so what parameters work well for you? Or else, what is a good tactic to pre-compute tails files before an existing revocation registry is full? Again I come back to needing a way to query how many credentials are issued against an existing revocation registry.

gudkov (Thu, 03 May 2018 11:59:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=SuxD54wjS2S4qAeoJ) @sklump We will check this. In my expectation it must be significantly faster.

LucW (Thu, 03 May 2018 13:44:09 GMT):
Has joined the channel.

LucW (Thu, 03 May 2018 13:44:47 GMT):
Hey guys, I am trying to install libindy 1.4.0 from the repo.sovrin.org website, but it uses libssl1.0.0 and other old, deprecated dependencies. Is it outdated or am I missing something ?

danielhardman (Thu, 03 May 2018 16:04:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kPTnH9BkuwojFXZ8k) @sklump Thanks for the catch. I'll raise a PR to improve, unless you beat me to it.

danielhardman (Thu, 03 May 2018 16:06:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=8wNAdq2cxPrz53HiN) @LucW I'm guessing your workflow is odd in some way, because I think 1.4 hasn't been released yet. @gudkov?

gudkov (Thu, 03 May 2018 16:08:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=BBhYgFDL2nva43gQZ) @danielhardman We have release candidate for 1.4. Some dependencies can be outdated., Especially for platforms without package manager.

esplinr (Thu, 03 May 2018 16:15:58 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ndiHdTETuRDztZpmq) @mboyd I tried to submit a pull request without the GPG signature, and it was rejected by the CI/CD checks.

esplinr (Thu, 03 May 2018 16:26:51 GMT):
_is not convinced that the cryptographic DCO check is worth the additional hurdle to contributions._

mboyd (Thu, 03 May 2018 16:28:27 GMT):
Nothing in the DCO reference about GPG signatures being required: https://github.com/probot/dco#how-it-works

mboyd (Thu, 03 May 2018 16:29:04 GMT):
It's tripped up more than a few excited contributing devs

swcurran (Thu, 03 May 2018 16:29:24 GMT):
Some notes about the documentation discussion today. Did a bit of quick research - @esplinr As mentioned - reStructuredText (RST) is the native format for readthedocs. Background on why markdown is bad seems to be here - http://ericholscher.com/blog/2016/mar/15/dont-use-markdown-for-technical-docs/ RST is supported by github, and if you have a README.rst in a folder, it is rendered just like README.md. Note that if you have both, md takes precedence. There is a command line converter from md to rst using pandoc `pandoc --from=markdown --to=rst --output=README.rst README.md`. There is even a "de facto" docker image that can be used, so you don't have to install pandoc. Works nicely. As such, in theory, a simple script could be used to convert existing .md files to .rst. That would be a pretty radical approach - using rst instead of md - but it does support the readthedocs model. You go from one de facto standard (using md in github) to another (having readthedocs docs). You gain value for the consumers (they have readthedocs) at the cost of the contributors (they have to use rst instead of md). Not sure it is a good idea, but letting folks know about the tradeoffs.

mboyd (Thu, 03 May 2018 16:37:55 GMT):
@sergey.minaev Are GPG signatures required for commits to pass DCO, or is just the signature line in the commit required?

esplinr (Thu, 03 May 2018 16:52:48 GMT):
@swcurran Thank you for sharing that! It's great to hear that GitHub supports RST.

esplinr (Thu, 03 May 2018 16:53:46 GMT):
From a perspective of "cost to the contributors", I think RST and MD is very similar. The differences are annoying, but not very big.

esplinr (Thu, 03 May 2018 16:54:11 GMT):
@SeanBohan_Evernym Should we discuss further during the next Indy WG call?

SeanBohan_Evernym (Thu, 03 May 2018 16:54:15 GMT):
Has joined the channel.

danielhardman (Thu, 03 May 2018 22:40:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wkFdLPFgHBpBdCSBP) PR raised and merged.

sergey.minaev (Fri, 04 May 2018 07:18:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=7D26QRjKbWoYqqKo7) @mboyd simple signature line is enough.

LucW (Fri, 04 May 2018 09:45:37 GMT):
@gudkov So what would be the solution to have it installed then ?

gudkov (Fri, 04 May 2018 10:29:49 GMT):
@LucW to help you we need additional info. What exact package, what platform and etc...

LucW (Fri, 04 May 2018 10:36:50 GMT):
@gudkov I have a Debian Stretch (the last one). The output, when I try to install the .deb package of libindy is : "libindy depends on libssl1.0.0" and "libindy depends on libsqlite0", however these required versions are too old, which is why my system won't install them thus downgrade the currently installed versions

gudkov (Fri, 04 May 2018 10:37:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wK95pmKN3BSY4DNhh) @LucW We don't support Debian Stretch for now. All deb packages are Only for Ubuntu 16.04.

LucW (Fri, 04 May 2018 10:38:14 GMT):
Ok, thanks for the answer, I'll have it installed on a VM

AxelNennker (Fri, 04 May 2018 17:59:15 GMT):
Please have a look at https://github.com/hyperledger/indy-sdk/pull/722 bumping sodiumoxide from 0.0.14 to 0.0.16. Some low level crypto functions were removed from libsodium but there are still rust bindings for them in sodiumoxide. Bumping the version 0.0.16 gets this in sync again. Otherwise there is an unsatisfied link error when building libindy for aarch64-linux-android because crypto_stream_aes128ctr_xor is missing.

esplinr (Fri, 04 May 2018 20:50:51 GMT):
@LucW If you are feeling adventurous, you can remove those checks in the code and try running the application with the newer libraries, then let us know what breaks.

tomislav (Fri, 04 May 2018 23:20:18 GMT):
@mawi I've no issues using the framework with iOS, but I never tried react native. You can grab a binary framework at https://github.com/streetcrednyc/Indy And just for completeness, a promise wrapper around libindy using PromiseKit is also available at https://github.com/streetcrednyc/IndyPromise

Neumann347 (Sun, 06 May 2018 13:24:01 GMT):
Has joined the channel.

mawi (Mon, 07 May 2018 10:07:48 GMT):
Thanks @tomislav , using the comments of @thomasmm it now works with react native

mawi (Mon, 07 May 2018 10:08:45 GMT):
I can't find the genesis file for the STN by the way, does anyone happen to have a link for this?

chriswinc (Mon, 07 May 2018 13:31:28 GMT):
I am migrating from development on a local pool to the live pool. How do you connect to the live pool vs the local "indy_pool?"

chriswinc (Mon, 07 May 2018 13:32:03 GMT):
Sorry, to clarify, I meant the Sovrin live pool.

samadsajanlal (Mon, 07 May 2018 15:54:11 GMT):
Has joined the channel.

AxelNennker (Mon, 07 May 2018 16:29:52 GMT):
Can I use the docker files in indy-sdk to create the test pool for libindy's junit tests so that the nodes are reachable from a (Android) mobile phone in the same wifi network?

sklump (Mon, 07 May 2018 16:46:44 GMT):
*Question. re: `anoncreds.prover_create_proof(..., rev_states_json)`*

tomislav (Mon, 07 May 2018 18:09:56 GMT):
@AxelNennker Yes. If you're running emulator, you can run the docker as is. If on a device, you will need to modify the IP to match your local network

vidor (Mon, 07 May 2018 23:55:56 GMT):
Has joined the channel.

gudkov (Tue, 08 May 2018 07:53:17 GMT):
@AxelNennker @tomislav Nodes must access each other by the same IPs as client. So if you can expose IPs this way you are fine. If you host docker on linux it seems possible, but for windows and mac it can be more complicated.

tomislav (Tue, 08 May 2018 13:09:34 GMT):
I've been using Mac, and docker file from CI works like a charm with a simulator. If on a device, I update the docker IP and genesis file to my local wifi network. Haven't tried anything on Windows

sklump (Tue, 08 May 2018 14:40:35 GMT):
*Item:* Suppose I specify ``` proof_req = { 'nonce': ..., 'name': '..., 'version': ..., 'requested_attributes': { ... }, 'requested_predicates': { ...}, 'non_revoked': { 'to': int(time()) } } ``` and call `anoncreds.prover_get_credentials_for_proof_req(, json.dumps(proof_req)))`, where a credential has been revoked at least one second prior. Is it expected that the indy-sdk call returns the revoked credential as well as the others? _(because that's what I get)_. Perhaps the `non_revoked` clause is only enforced when getting proof? Or is this a bug? Thanks.

sklump (Tue, 08 May 2018 14:40:35 GMT):
*Item:* Suppose I specify ``` proof_req = { 'nonce': ..., 'name': ..., 'version': ..., 'requested_attributes': { ... }, 'requested_predicates': { ...}, 'non_revoked': { 'to': int(time()) } } ``` and call `anoncreds.prover_get_credentials_for_proof_req(, json.dumps(proof_req)))`, where a credential has been revoked at least one second prior. Is it expected that the indy-sdk call returns the revoked credential as well as the others? _(because that's what I get)_. Perhaps the `non_revoked` clause is only enforced when getting proof? Or is this a bug? Thanks.

sklump (Tue, 08 May 2018 14:40:35 GMT):
*Item:* Suppose I specify ``` proof_req = { 'nonce': ..., 'name': ..., 'version': ..., 'requested_attributes': { ... }, 'requested_predicates': { ... }, 'non_revoked': { 'to': int(time()) } } ``` and call `anoncreds.prover_get_credentials_for_proof_req(, json.dumps(proof_req)))`, where a credential has been revoked at least one second prior. Is it expected that the indy-sdk call returns the revoked credential as well as the others? _(because that's what I get)_. Perhaps the `non_revoked` clause is only enforced when getting proof? Or is this a bug? Thanks.

gudkov (Tue, 08 May 2018 14:56:59 GMT):
> Is it expected that the indy-sdk call returns the revoked credential as well as the others? sure

mawi (Tue, 08 May 2018 15:35:19 GMT):
Is there any difference between a master secret and a link secret? They're both used to prove that a proof from multiple credentials uniquely applies to a certain entity, right?

swcurran (Tue, 08 May 2018 16:46:12 GMT):
@mawi - no difference. The original name was "master secret", but changed to "link secret" to prove that it links the credentials held by an identity to that identity, regardless of what DIDs were used in the relationships in being issued the credentials.

swcurran (Tue, 08 May 2018 16:46:12 GMT):
@mawi - no difference. The original name was "master secret", but changed to "link secret" as it is used to prove the credentials held by an identity are linked to that identity, regardless of what DIDs were used in the relationships in being issued the credentials.

mawi (Wed, 09 May 2018 07:12:40 GMT):
@swcurran thanks!

guido.santos (Wed, 09 May 2018 13:40:25 GMT):
Has joined the channel.

guido.santos (Wed, 09 May 2018 14:33:38 GMT):
Hi everybody , just started playing around with indy-sdk and a question raised.. After running the first how to example (Write DID and Query Verkey), am I able to check the wallet that was created? like using the indy-cli or something, or is it just in-memory? Because from the example, there were 3 DIDs created, I think, and I cannot see them on the ledger. Can anyone help please?

sklump (Wed, 09 May 2018 15:14:22 GMT):
req_json = ledger.build_get_nym_request(my_did, subject_did) ledger.submit_request(pool_handle, req_json) The default wallet is an sqlite3 (file on disk) implementation if I remember correctly.

sklump (Wed, 09 May 2018 15:14:22 GMT):
Check the `libindy/wrapper/*/tests` code for plenty of samples. ``` req_json = ledger.build_get_nym_request(my_did, subject_did) ledger.submit_request(pool_handle, req_json) ``` The default wallet is an sqlite3 (file on disk) implementation if I remember correctly.

guido.santos (Wed, 09 May 2018 15:19:02 GMT):
Indeed, I understand that but what about wallets created via SDK? are they stored someway and accessible from indy-cli, for instance?

sklump (Wed, 09 May 2018 15:19:43 GMT):
No.

sklump (Wed, 09 May 2018 15:20:38 GMT):
releases 1.4 and 1.5 will have some important updates to wallets.

guido.santos (Wed, 09 May 2018 15:22:40 GMT):
So, for the moment, how can I guarantee that SDK is actually writing something to the ledger? Or I can't? Because, like I said, I've created a wallet and 3 DIDs but I can't see them anywhere except during the sdk execution

mbwhite (Wed, 09 May 2018 15:28:55 GMT):
Hi; I've been working through the python how-to "Write a did", However I get an error about 'signus' not being found... is there an up-to-date python sample available?

mbwhite (Wed, 09 May 2018 15:33:41 GMT):
I have been trying to replicate the python example using the `indy-cli` - but not quite got it yet... don't suppose anybody has written this down :-)

sklump (Wed, 09 May 2018 15:37:02 GMT):
@mbwhite they renamed signus to did @guido.santos, ``` req_json = ledger.build_get_nym_request(my_did, subject_did) ledger.submit_request(pool_handle, req_json) ```

mbwhite (Wed, 09 May 2018 15:38:55 GMT):
thanks - trying that now

mbwhite (Wed, 09 May 2018 15:39:27 GMT):
side question; any recommendations for good discussion of the Indy concepts?

mbwhite (Wed, 09 May 2018 15:41:00 GMT):
the sample worked btw

sklump (Wed, 09 May 2018 16:33:20 GMT):
*Question:* How do I specify no delta for ``` async def create_revocation_state(blob_storage_reader_handle: int, rev_reg_def_json: str, rev_reg_delta_json: str, timestamp: int, cred_rev_id: str) -> str: """ Create revocation state for a credential in the particular time moment. :param blob_storage_reader_handle: configuration of blob storage reader handle that will allow to read revocation tails :param rev_reg_def_json: revocation registry definition json :param rev_reg_delta_json: revocation registry definition delta json :param timestamp: time represented as a total number of seconds from Unix Epoch :param cred_rev_id: user credential revocation id in revocation registry :return: revocation state json { "rev_reg": , "witness": , "timestamp" : integer } """ ``` ? I am trying to create and verify a proof of non-revocation through time _t-1_ on a credential revoked at time _t+1_, where time _t_ is the moment of its revocation registry definition (on the ledger). The revocation registry definition does not include any timestamp data, and so there is no way to filter out requests for deltas beforehand. But specifying a timestamp _< t_ in `ledger.build_get_revoc_reg_delta_request()` produces a stub like this: ``` { "result": { "seqNo": null, "identifier": "Rzra4McufsSNUQ1mGyWc2w", "type": "117", "to": 1525883278, "data": { "revocRegDefId": "Q4zqM7aXqm7gDQkUVLng9h:4:Q4zqM7aXqm7gDQkUVLng9h:3:CL:15:CL_ACCUM:1" }, "txnTime": null, "reqId": 1525883374441247915, "revocRegDefId": "Q4zqM7aXqm7gDQkUVLng9h:4:Q4zqM7aXqm7gDQkUVLng9h:3:CL:15:CL_ACCUM:1" }, "op": "REPLY" } ``` which does not parse via `ledger.parse_get_revoc_reg_delta_response()`. So what if there is no delta? How does one call `anoncreds.create_revocation_state()` to get the state for the original revocation registry definition? I'm at a loss.

guido.santos (Wed, 09 May 2018 17:38:22 GMT):
@sklump I'm sorry for being persistent, I understand the piece of code that you've pasted here but the thing is, that information is available during the lifecycle of the SDK interaction.. that is, if the program "exits", there will be no information written in the ledger, at least, I cannot see it using indy-cli

sklump (Wed, 09 May 2018 18:13:34 GMT):
I don't know what indy-cli is. This is the channel for indy-sdk. Indy-sdk offers functions to query the ledger.

sklump (Wed, 09 May 2018 18:13:34 GMT):
I don't know what indy-cli is to any useful degree, maybe part of indy-node. This is the channel for indy-sdk. Indy-sdk offers functions to query the ledger.

AxelNennker (Wed, 09 May 2018 19:51:56 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=XXEYijoP9CRgYjMna) @gudkov If I change the pool_ip IP address to the address of my laptop then the docker commands confuse the network setup on the laptop so Internet access stops working and the usual indy ports are not bound to that address. It unclear to me what is happening. Maybe it is easier to use the 10er addresses and netcat-proxy to them... Maybe it is easier to not use docker and start four node directly. The following does not work 192.168.1.2 is the address of my laptop. docker network create --subnet 192.168.1.0/24 indy_pool_network docker build --build-arg pool_ip=192.168.1.2 -f ci/indy-pool.dockerfile -t indy_pool . docker run -d --ip="192.168.1.2" --net=indy_pool_network indy_pool

mboyd (Wed, 09 May 2018 19:55:18 GMT):
@dbluhm ^^

vidor (Wed, 09 May 2018 20:04:46 GMT):
Hello everyone, new to Indy, as i understand indy-sdk connects to the Sovrin network. I have read in the sovrin protocol document that they would introduce a token as an incentive https://sovrin.org/wp-content/uploads/2018/03/Sovrin-Protocol-and-Token-White-Paper.pdf What is the forecast of something like this happening with Indy/Sovrin public network or does anyone have any insight? Thanks :)

vidor (Wed, 09 May 2018 20:04:57 GMT):
(pdf page 30)

nhelmy (Thu, 10 May 2018 07:42:29 GMT):
Has joined the channel.

gudkov (Thu, 10 May 2018 07:43:02 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=BHLbGTi9t5fDmXHwb) @sklump Indy CLI is part of Indy SDK now. So i believe this channel is a good place to support it.

gudkov (Thu, 10 May 2018 07:48:02 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wpRW7ohbsZwM5kujn) @guido.santos Actually i don't understand you completely: - Wallet is local database intended to store crypto secrets - Ledger is remote database When you create DID with indy_create_my_did it generates DID and corresponded asymmetric key pair and stores in the local wallet. You can: - list your DIDs - Reference DID keys to use in crypto operations like sign, create authcrypt or anoncypt messages.

gudkov (Thu, 10 May 2018 07:49:16 GMT):
If your application needs you can post this DID and corresponded PUBLIC key to the ledger.

gudkov (Thu, 10 May 2018 07:49:41 GMT):
indy-cli allows you to discover entities in your wallet. I just need to open the wallet with the same name.

guido.santos (Thu, 10 May 2018 09:12:10 GMT):
@gudkov looking through SDK documentation, I couldn't find a way to post DID to the ledger, can you point me to where I can check it out?

gudkov (Thu, 10 May 2018 09:19:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=xSuMuYdAF6v5BMzKx) @guido.santos ``` req_json = ledger.build_get_nym_request(my_did, subject_did) ledger.submit_request(pool_handle, req_json)

gudkov (Thu, 10 May 2018 09:20:21 GMT):
Sorry it is for getting. You should use build_nym_request. GSG makes it a lot of times.

gudkov (Thu, 10 May 2018 09:20:53 GMT):
@guido.santos Have you read Getting-started-guide?

guido.santos (Thu, 10 May 2018 09:22:25 GMT):
@gudkov thanks for that! Yes, I've read it but I'm using the Java wrapper SDK

gudkov (Thu, 10 May 2018 09:22:36 GMT):
This how-to also explains that https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/write-did-and-query-verkey/README.md

LuisMarado (Thu, 10 May 2018 10:01:00 GMT):
Has joined the channel.

sklump (Thu, 10 May 2018 12:34:18 GMT):
I'm into the details of revocation and its elements within indy-sdk JSON structures. *(0)* Please correct me if this is wrong: `anoncreds.prover_get_credentials_for_proof_req()` ignores the `proof_request_json` parameter's `non_revoked` interval specifications throughout; i.e., top-level, in `` per `requested_attributes` value, and in `` per `requested_predicates` value. For `anoncreds.prover_create_proof()`, parameter `proof_req_json` carries `non_revoked` interval specifications throughout as above. In parameter `requested_credentials_json`, any (referent) value for `requested_attributes` or `requested_predicates` can carry a `timestamp` value. *(1)* What is the meaning of this timestamp? *(2)* What is its meaning if it differs from the `from` or `to` values for the prevailing `non_revoked` interval in the proof request? *(3)* Is it an error if a `timestamp` is present in a `requested_credentials_json` credential but not in the prevailing `non_revoked` interval of the proof request? *(4)* Should it default to the `to` value of the prevailing `non_revoked` interval of the proof request? The interaction sample gets credentials from the wallet that look like: ``` { "predicates": { "predicate1_referent": [ { "cred_info": { ... }, "interval": { "to": 1525950455, "from": 1525950454 } } ] }, "attrs": { "attr1_referent": [ { "cred_info": { ... }, "interval": { "to": 1525950455, "from": 1525950454 } } ] } } ``` _[I added the `from` values]_ but the processing subsequently ignores the `interval` items in the `attrs` and `predicates` referents. *(5)* What are these for? Can I safely ignore them?

sklump (Thu, 10 May 2018 12:37:30 GMT):
I'm into the details of revocation and its elements within indy-sdk JSON structures. *(0)* Please correct me if this is wrong: *anoncreds.prover_get_credentials_for_proof_req()* ignores the *proof_request_json* parameter's *non_revoked* interval specifications throughout; i.e., - at the top level, - in ** per *requested_attributes* value, and - in ** per *requested_predicates* value. For *anoncreds.prover_create_proof()*, parameter *proof_req_json* carries *non_revoked* interval specifications throughout as above. In parameter *requested_credentials_json*, any (referent) value for *requested_attributes* or *requested_predicates* can carry a *timestamp* value. *(1)* What is the meaning of this timestamp? *(2)* What is its meaning if it differs from the *from* or *to* values for the prevailing *non_revoked* interval in the proof request? *(3)* Is it an error if a *timestamp* is present in a *requested_credentials_json* credential but not in the prevailing *non_revoked* interval of the proof request? *(4)* Should it default to the *to* value of the prevailing *non_revoked* interval of the proof request? The interaction sample gets credentials from the wallet that look like: ``` { "predicates": { "predicate1_referent": [ { "cred_info": { ... }, "interval": { "to": 1525950455, "from": 1525950454 } } ] }, "attrs": { "attr1_referent": [ { "cred_info": { ... }, "interval": { "to": 1525950455, "from": 1525950454 } } ] } } ``` _[I added the *from* values]_ but the processing subsequently ignores the *interval* items in the *attrs* and *predicates* referents. *(5)* What are these for? Can I safely ignore them?

sklump (Thu, 10 May 2018 13:42:53 GMT):
Also, re: *anoncreds.prover_create_proof()*, parameter *rev_states_json* might look like: ``` { "": { "": { "timestamp": 1234567890, "witness": { .... }, "rev_reg": { ... }, ... } } }``` I am looking for the best way to get the value of `` without getting indy-sdk error `RevocationInfo not found by timestamp`.

sklump (Thu, 10 May 2018 13:42:53 GMT):
Also, re: *anoncreds.prover_create_proof()*, parameter *rev_states_json* might look like: ``` { "": { "": { "timestamp": 1234567890, "witness": { .... }, "rev_reg": { ... }, ... } }, ... }``` I am looking for the best way to get the value of `` without getting indy-sdk error `RevocationInfo not found by timestamp`.

bstasyszyn (Thu, 10 May 2018 14:44:14 GMT):
Has joined the channel.

bstasyszyn (Thu, 10 May 2018 14:46:09 GMT):
Hi all - FYI our WIP on a Go Wrapper for Indy: https://github.com/securekey/indy-sdk/tree/master/wrappers/go/dockerenv

kevin.chan (Thu, 10 May 2018 17:31:50 GMT):
hey guys, I am having issues reading a schema from the ledger using the schema Id field of a credential definition, what I am noticing is that in the credential definition returned from the ledger the schemaId field seems to be the schema.seqNo and not the schema id as expected. Anybody know if this is a bug?

kevin.chan (Thu, 10 May 2018 17:31:55 GMT):
``` 2018-05-10 10:24:37,535 INFO issuer.py:103 - cred def: { "ver": "1.0", "id": "7CL1ExNy2K3vgNoFMPxKWq:3:CL:683", "schemaId": "683", ```

kevin.chan (Thu, 10 May 2018 17:32:28 GMT):
``` 2018-05-10 10:24:36,614 INFO issuer.py:86 - schema: { "ver": "1.0", "id": "TT9zhEsNScMpKkcoZuFiqY:2:Transcript:1.0", "name": "Transcript", "version": "1.0", "attrNames": [ "status", "last_name", "average", "first_name", "degree", "ssn", "year" ], "seqNo": 683 } ```

kevin.chan (Thu, 10 May 2018 17:34:05 GMT):
indy-sdk says CommonInvalidStructure when i try to lookup a schema using schemaId = 683 ``` File "/Users/kevin.chan/research/vericreds/utils.py", line 234, in get_schema get_schema_request = await ledger.build_get_schema_request(submitter_did, schema_id) File "/Users/kevin.chan/research/indy-sdk/wrappers/python/indy/ledger.py", line 402, in build_get_schema_request build_get_schema_request.cb) indy.error.IndyError: ErrorCode.CommonInvalidStructure ```

jonathanreynolds (Thu, 10 May 2018 17:34:52 GMT):
Has joined the channel.

sklump (Thu, 10 May 2018 17:42:57 GMT):
@kevin.chan In the context of a cred def, the schema identifier is its transaction number.

kevin.chan (Thu, 10 May 2018 17:43:42 GMT):
thanks for the response sklump, is there a way to walk to the schema from a cred def?

kevin.chan (Thu, 10 May 2018 17:46:05 GMT):
looks like maybe i should use ledger.build_get_txn_request() using 683

sklump (Thu, 10 May 2018 17:52:17 GMT):
call txn = await ledger.build_get_txn_request(my_did, seqNo) extract ['identifier'], ['data']['name'], ['data']['version'] from transaction call await ledger.build_get_scheam_request(my_did, identifier, name, version) call await ledger.parse_get_schema_response()

kevin.chan (Thu, 10 May 2018 17:58:51 GMT):
ah great, thanks, i just tried this which didn't work but thought it might, thanks much for the above! ``` txn_req_json = await(ledger.build_get_txn_request(verifier_did, int(cred_def["schemaId"]))) txn_resp = await(ledger.sign_and_submit_request(pool_handle, verifier_wallet, verifier_did, txn_req_json)) schema_json = await(ledger.parse_get_schema_response(txn_resp)) ```

sklump (Thu, 10 May 2018 18:00:34 GMT):
No need to sign a read-only transaction though

kevin.chan (Thu, 10 May 2018 18:03:59 GMT):
ah right!

kevin.chan (Thu, 10 May 2018 19:42:29 GMT):
``` schema_txn_req_json = await(ledger.build_get_txn_request(verifier_did, int(cred_def["schemaId"]))) schema_txn_resp_json = await(ledger.submit_request(pool_handle, schema_txn_req_json)) schema_txn_resp = json.loads(schema_txn_resp_json) schema_txn_resp_data = schema_txn_resp['result']['data'] schema_id = "{}:2:{}:{}".format(schema_txn_resp_data['identifier'], schema_txn_resp_data['data']['name'], schema_txn_resp_data['data']['version']) ```

kevin.chan (Thu, 10 May 2018 19:42:29 GMT):
this worked, thanks @sklump ``` schema_txn_req_json = await(ledger.build_get_txn_request(verifier_did, int(cred_def["schemaId"]))) schema_txn_resp_json = await(ledger.submit_request(pool_handle, schema_txn_req_json)) schema_txn_resp = json.loads(schema_txn_resp_json) schema_txn_resp_data = schema_txn_resp['result']['data'] schema_id = "{}:2:{}:{}".format(schema_txn_resp_data['identifier'], schema_txn_resp_data['data']['name'], schema_txn_resp_data['data']['version']) ```

kevin.chan (Thu, 10 May 2018 19:43:32 GMT):
including the 2 was important in the schema id

sklump (Thu, 10 May 2018 19:43:51 GMT):
2, 3, 4 mark schema ids from cred def ids and revocation reg ids

Neumann347 (Thu, 10 May 2018 20:26:08 GMT):
Is there any technical mechanism to ensure that an entity that publishes a credential definition to the ledger is only collecting the data defined in the credential schema?

mbwhite (Thu, 10 May 2018 21:21:57 GMT):
Hi; hope this question makes sense - based on the https://github.com/hyperledger/indy-sdk/blob/master/samples/python/src/getting_started.py sample. there are verinyms forexample `acme-did`... this I could make public - and in a separate app and in some way 'validate this' or at least confirm it exists... could you point me to the api(s) I would use for that?

swcurran (Thu, 10 May 2018 22:03:49 GMT):
@danielhardman - going through the Revocation summary and really like it except it glosses over a key point that I wanted to understand. See the link below for the key paragraph where the Prover shows the Verifier that it the credential has been revoked without disclosing her private factor. What the paragraph doesn't say is how she does that. What does the verifier get from the Prover that can be accepted as the proof? I'm guessing it is obvious, but it would great to have it spelled out. https://github.com/hyperledger/indy-sdk/blob/master/doc/cred-revocation.md#presenting-proof-of-non-revocation

swcurran (Thu, 10 May 2018 22:03:49 GMT):
@danielhardman - going through the Revocation summary and really like it except it glosses over a key point that I wanted to understand. See the link below for the key paragraph where the Prover shows the Verifier that it the credential has not been revoked without disclosing her private factor. What the paragraph doesn't say is how she does that. What does the verifier get from the Prover that can be accepted as the proof? I'm guessing it is obvious, but it would great to have it spelled out. https://github.com/hyperledger/indy-sdk/blob/master/doc/cred-revocation.md#presenting-proof-of-non-revocation

swcurran (Thu, 10 May 2018 22:03:49 GMT):
@danielhardman - going through the Revocation summary and really like it except it glosses over a key point that I wanted to understand. See the link below for the key paragraph where the Prover shows the Verifier that the credential has not been revoked without disclosing her private factor. What the paragraph doesn't say is how she does that. What does the verifier get from the Prover that can be accepted as the proof? I'm guessing it is obvious, but it would great to have it spelled out. https://github.com/hyperledger/indy-sdk/blob/master/doc/cred-revocation.md#presenting-proof-of-non-revocation

swcurran (Thu, 10 May 2018 22:09:42 GMT):
Also, to confirm - since the Prover fetches the Witness Delta at a certain time, this only proves that the Credential wasn't revoked to that point in time. I'm guessing that part of what the Verifier gets is that time so they can (a) check if there have been subsequent revocations (updates to the Witness Delta) and (b) they can decide to accept the non-revocation based on it's age (in the case revocations occur more or less continuously).

dbluhm (Thu, 10 May 2018 22:37:03 GMT):
This has partially been addressed before but with Ubuntu 18.04 LTS and Fedora 28 (and other distros I'm sure) moving to libsodium 1.0.16, we are now facing dependency issues. Sure, on newer distros you can build the older version yourself or find a package from someone else that already has but that doesn't seem like the best solution. I also understand the necessity of remaining compatible with Ubuntu 16.04. Does anyone have any ideas on solutions?

wolili (Fri, 11 May 2018 12:39:37 GMT):
Hi, I want to run the example how-to python files of indy-sdk. I installed libindy using apt and have the docker pool running. According to the prerequisites (https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/prerequisites.md) I'm only missing a development environment (for python). What do I have to do to set up such a environment?

gudkov (Fri, 11 May 2018 13:24:31 GMT):
> What do I have to do to set up such a environment? Install python and some text editor you like.

alek (Fri, 11 May 2018 14:45:00 GMT):
Has joined the channel.

guido.santos (Fri, 11 May 2018 17:54:01 GMT):
Hi all

guido.santos (Fri, 11 May 2018 17:54:13 GMT):
I was able to proceed with my example

guido.santos (Fri, 11 May 2018 17:54:19 GMT):
and I'm using the Java wrapper

guido.santos (Fri, 11 May 2018 17:54:35 GMT):
currently, I'm getting an error when calling the buildGetSchemaRequest method

guido.santos (Fri, 11 May 2018 17:54:57 GMT):
and I really can't say what's wrong or what is the error because my Java application just crashes with a SIGBUS

guido.santos (Fri, 11 May 2018 17:55:31 GMT):
going through the core dump, I can see that the error, apparently, may be in the LedgerCommand::BuildGetSchemaRequest

guido.santos (Fri, 11 May 2018 17:55:38 GMT):
but I don't know exactly why

guido.santos (Fri, 11 May 2018 17:55:42 GMT):
can anyone help me out, please?

sklump (Fri, 11 May 2018 19:50:22 GMT):
A word to the wise: Consider the following time line: _t0_ = 1970-01-01T00:00:00Z < _t1_ = cred def creation < _t2_ = cred _c_ creation < _t3_ = cred _c_ revocation < _t4_ = now. *(0)* It is not possible to create proof on cred _c_, using a timestamp before _t1_, because the call to get rev reg delta state throws an exception. However, it is not possible for an outsider to know when _t1_ occurred because it is nowhere in the cred def JSON itself. The Holder/Prover must check for error on revocation registry delta state query and convey disappointment gracefully. *(1)* Any proof on cred _c_, using a timestamp between _t1_ and _t2_, validates as *False*. I can kind of see that as a feature, but it is indistinguishable to a caller from case *(3)* below. _(Good news: it is also *False*, even if the Issuer never revoked cred c.)_ *(2)* Any proof on cred _c_, using a timestamp between _t2_ and _t3v, validates as *True*. Hurray! *(3)* Any proof on cred _c_, using a timestamp between _t3_ and _t4_, validates as *False*. Also good, but indistinguishable from "requested timestamp predates issue" case *(1)* above. *(4)* Any proof on cred _c_, using a timestamp after _t4_ (i.e., in the future), validates as *False* if the credential is revoked and *True* if it has not been. While this appears provisionally true from a _t=t4_ point of view, it is in effect a post-dated cheque. Relying parties should check for post-dating and handle it in accordance with their requirements.

sklump (Fri, 11 May 2018 19:50:22 GMT):
A word to the wise: Consider the following time line: _t0_ = 1970-01-01T00:00:00Z < _t1_ = cred def creation < _t2_ = cred _c_ creation < _t3_ = cred _c_ revocation < _t4_ = now. *(0)* It is not possible to create proof on cred _c_, using a timestamp before _t1_, because the call to get rev reg delta state does not produce one. However, it is not possible for an outsider to know when _t1_ occurred because it is nowhere in the cred def JSON itself. The Holder/Prover must check for error on revocation registry delta state query and convey disappointment gracefully. *(1)* Any proof on cred _c_, using a timestamp between _t1_ and _t2_, validates as *False*. I can kind of see that as a feature, but it is indistinguishable to a caller from case *(3)* below. _(Good news: it is also *False*, even if the Issuer never revoked cred c.)_ *(2)* Any proof on cred _c_, using a timestamp between _t2_ and _t3v, validates as *True*. Hurray! *(3)* Any proof on cred _c_, using a timestamp between _t3_ and _t4_, validates as *False*. Also good, but indistinguishable from "requested timestamp predates issue" case *(1)* above. *(4)* Any proof on cred _c_, using a timestamp after _t4_ (i.e., in the future), validates as *False* if the credential is revoked and *True* if it has not been. While this appears provisionally true from a _t=t4_ point of view, it is in effect a post-dated cheque. Relying parties should check for post-dating and handle it in accordance with their requirements.

sklump (Fri, 11 May 2018 19:50:22 GMT):
A word to the wise: Consider the following time line: _t0_ = 1970-01-01T00:00:00Z < _t1_ = cred def creation < _t2_ = cred _c_ creation < _t3_ = cred _c_ revocation < _t4_ = now. *(0)* It is not possible to create proof on cred _c_, using a timestamp before _t1_, because the call to get rev reg delta state does not produce one. However, it is not possible for an outsider to know when _t1_ occurred because it is nowhere in the cred def JSON itself. The Holder/Prover must check for error on revocation registry delta state query and convey disappointment gracefully. *(1)* Any proof on cred _c_, using a timestamp between _t1_ and _t2_, validates as *False*. I can kind of see that as a feature, but it is indistinguishable to a caller from case *(3)* below. _(Good news: it is also *False*, even if the Issuer never revoked cred c.)_ *(2)* Any proof on cred _c_, using a timestamp between _t2_ and _t3_, validates as *True*. Hurray! *(3)* Any proof on cred _c_, using a timestamp between _t3_ and _t4_, validates as *False*. Also good, but indistinguishable from "requested timestamp predates issue" case *(1)* above. *(4)* Any proof on cred _c_, using a timestamp after _t4_ (i.e., in the future), validates as *False* if the credential is revoked and *True* if it has not been. While this appears provisionally true from a _t=t4_ point of view, it is in effect a post-dated cheque. Relying parties should check for post-dating and handle it in accordance with their requirements.

sklump (Fri, 11 May 2018 19:50:22 GMT):
A word to the wise: Consider the following time line: _t0_ = 1970-01-01T00:00:00Z < _t1_ = revocation registry def creation < _t2_ = cred _c_ creation < _t3_ = cred _c_ revocation < _t4_ = now. *(0)* It is not possible to create proof on cred _c_, using a timestamp before _t1_, because the call to get rev reg delta state does not produce one. However, it is not possible for the Holder/Prover to know when _t1_ occurred because it is nowhere in the revoc reg def JSON itself. A double-tap (get reg rev def, find seqNo, get transaction at seqNo and read timestamp) could provide an good approximation. The Holder/Prover must check for error on revocation registry delta state query and convey disappointment gracefully. *(1)* Any proof on cred _c_, using a timestamp between _t1_ and _t2_, validates as *False*. I can kind of see that as a feature, but it is indistinguishable to a caller from case *(3)* below. _(Good news: it is also *False*, even if the Issuer never revoked cred c.)_ *(2)* Any proof on cred _c_, using a timestamp between _t2_ and _t3_, validates as *True*. Hurray! *(3)* Any proof on cred _c_, using a timestamp between _t3_ and _t4_, validates as *False*. Also good, but indistinguishable from "requested timestamp predates issue" case *(1)* above. *(4)* Any proof on cred _c_, using a timestamp after _t4_ (i.e., in the future), validates as *False* if the credential is revoked and *True* if it has not been. While this appears provisionally true from a _t=t4_ point of view, it is in effect a post-dated cheque. Relying parties should check for post-dating and handle it in accordance with their requirements.

sklump (Fri, 11 May 2018 19:50:22 GMT):
A word to the wise: Consider the following time line: _t0_ = 1970-01-01T00:00:00Z < _t1_ = revocation registry def creation < _t2_ = cred _c_ creation < _t3_ = cred _c_ revocation < _t4_ = now. *(0)* It is not possible to create proof on cred _c_, using a timestamp before _t1_, because the call to get rev reg delta state does not produce one. However, it is not possible for the Holder/Prover to know when _t1_ occurred because it is nowhere in the revoc reg def JSON itself. A double-tap (get reg rev def, find seqNo, get transaction at seqNo and read timestamp) could provide an acceptable approximation. The Holder/Prover must check for error on revocation registry delta state query and convey disappointment gracefully. *(1)* Any proof on cred _c_, using a timestamp between _t1_ and _t2_, validates as *False*. I can kind of see that as a feature, but it is indistinguishable to a caller from case *(3)* below. _(Good news: it is also *False*, even if the Issuer never revoked cred c.)_ *(2)* Any proof on cred _c_, using a timestamp between _t2_ and _t3_, validates as *True*. Hurray! *(3)* Any proof on cred _c_, using a timestamp between _t3_ and _t4_, validates as *False*. Also good, but indistinguishable from "requested timestamp predates issue" case *(1)* above. *(4)* Any proof on cred _c_, using a timestamp after _t4_ (i.e., in the future), validates as *False* if the credential is revoked and *True* if it has not been. While this appears provisionally true from a _t=t4_ point of view, it is in effect a post-dated cheque. Relying parties should check for post-dating and handle it in accordance with their requirements.

sklump (Fri, 11 May 2018 19:50:22 GMT):
A word to the wise: Consider the following time line: _t0_ = 1970-01-01T00:00:00Z < _t1_ = revocation registry def creation < _t2_ = cred _c_ creation < _t3_ = cred _c_ revocation < _t4_ = now. *(0)* It is not possible to create proof on cred _c_, using a timestamp before _t1_, because the call to get rev reg delta state does not produce one. However, it is not possible for the Holder/Prover to know when _t1_ occurred because it is nowhere in the revoc reg def JSON itself. A double-tap (get rev reg def, find seqNo, get transaction at seqNo and read timestamp) could provide an acceptable approximation. The Holder/Prover must check for error on revocation registry delta state query and convey disappointment gracefully. *(1)* Any proof on cred _c_, using a timestamp between _t1_ and _t2_, validates as *False*. I can kind of see that as a feature, but it is indistinguishable to a caller from case *(3)* below. _(Good news: it is also *False*, even if the Issuer never revoked cred c.)_ *(2)* Any proof on cred _c_, using a timestamp between _t2_ and _t3_, validates as *True*. Hurray! *(3)* Any proof on cred _c_, using a timestamp between _t3_ and _t4_, validates as *False*. Also good, but indistinguishable from "requested timestamp predates issue" case *(1)* above. *(4)* Any proof on cred _c_, using a timestamp after _t4_ (i.e., in the future), validates as *False* if the credential is revoked and *True* if it has not been. While this appears provisionally true from a _t=t4_ point of view, it is in effect a post-dated cheque. Relying parties should check for post-dating and handle it in accordance with their requirements.

danielhardman (Fri, 11 May 2018 22:53:23 GMT):
@sklump, yes, this matches my understanding of designed behavior.

mark.hadley (Sat, 12 May 2018 17:56:09 GMT):
Is the `nullpay_init` method intended to be exposed through the API on the master/payments branch? After compiling the branch I'm receiving this: ``` mark@mark-Precision-5510:~/dev/indy/indy-sdk/libindy$ strings target/debug/libindy.so | grep nullpay_init mark@mark-Precision-5510:~/dev/indy/indy-sdk/libindy$ ``` (no hits) Whereas something that is exposed seems to give this output: ``` mark@mark-Precision-5510:~/dev/indy/indy-sdk/libindy$ strings target/debug/libindy.so | grep indy_create_payment_address indy_create_payment_address indy_create_payment_address indy_create_payment_address indy_create_payment_address _ZN4indy3api8payments27indy_create_payment_address28_$u7b$$u7b$closure$u7d$$u7d$17ha965bb487814a883E _ZN4indy3api8payments27indy_create_payment_address28_$u7b$$u7b$closure$u7d$$u7d$17ha965bb487814a883E indy_create_payment_address mark@mark-Precision-5510:~/dev/indy/indy-sdk/libindy$ ```

mark.hadley (Sat, 12 May 2018 17:56:09 GMT):
Is the `nullpay_init` method intended to be exposed through the API on the feature/payments branch? After compiling the branch I'm receiving this: ``` mark@mark-Precision-5510:~/dev/indy/indy-sdk/libindy$ strings target/debug/libindy.so | grep nullpay_init mark@mark-Precision-5510:~/dev/indy/indy-sdk/libindy$ ``` (no hits) Whereas something that is exposed seems to give this output: ``` mark@mark-Precision-5510:~/dev/indy/indy-sdk/libindy$ strings target/debug/libindy.so | grep indy_create_payment_address indy_create_payment_address indy_create_payment_address indy_create_payment_address indy_create_payment_address _ZN4indy3api8payments27indy_create_payment_address28_$u7b$$u7b$closure$u7d$$u7d$17ha965bb487814a883E _ZN4indy3api8payments27indy_create_payment_address28_$u7b$$u7b$closure$u7d$$u7d$17ha965bb487814a883E indy_create_payment_address mark@mark-Precision-5510:~/dev/indy/indy-sdk/libindy$ ```

jastisriradheshyam (Mon, 14 May 2018 05:25:09 GMT):
Has joined the channel.

ramanagak (Mon, 14 May 2018 06:55:58 GMT):
Has joined the channel.

ramanagak (Mon, 14 May 2018 06:56:23 GMT):
Hi, In the script `https://github.com/hyperledger/indy-sdk/blob/57674d75adf2af63ed81dc4fcc53f73ffed7a39f/doc/design/005-dkms/getting-started/getting-started.ipynb`, When Acme creating a job application proof request, How it will know about `faber_transcript_cred_def_id` which is created at faber. The example given is a single script so all variables available there so the script knows about the varialbe. What if I created a seperate scripts for each entity, How Acme knows to get that id. Please suggest me.

ramanagak (Mon, 14 May 2018 06:56:23 GMT):
Hi, In the script `https://github.com/hyperledger/indy-sdk/blob/master/samples/python/src/getting_started.py`, When Acme creating a job application proof request, How it will know about `faber_transcript_cred_def_id` which is created at faber. The example given is a single script so all variables available there so the script knows about the varialbe. What if I created a seperate scripts for each entity, How Acme knows to get that id. Please suggest me.

alek (Mon, 14 May 2018 08:00:58 GMT):
Hi all, i started playing with hyperledger indy and installed `java-sdk`. I followed instructions, installed native libraries and attached them to project. Now i am trying to run tests included there and each of them is failing on `Pool pool = Pool.openPoolLedger(poolName, config.toJson()).get();` operation with the exception message: `java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.ledger.TimeoutException: Timeout happens for ledger operation.` Do you have any suggestions how to resolve that ?

wolili (Mon, 14 May 2018 08:27:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=TqvTMxQqWs6JJZdNy) @gudkov okay so simple, but when I try to run the python howto I get an Error that I cannot find the module indy. ``` Traceback (most recent call last): File "add_claim_def.py", line 43, in from indy import wallet, signus, pool, ledger ModuleNotFoundError: No module named 'indy' ```

wolili (Mon, 14 May 2018 08:28:38 GMT):
when trying to install python3-indy using pip I get ``` Collecting python3-indy Using cached https://files.pythonhosted.org/packages/0f/bf/88600a7f647401bdbc4427a679eaa1f6e7b6d16d66310b0c9b5b24a551e2/python3-indy-1.4.0.tar.gz Complete output from command python setup.py egg_info: Traceback (most recent call last): File "", line 1, in ModuleNotFoundError: No module named 'setuptools' ---------------------------------------- Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-install-3262pbox/python3-indy/ ``` what am I missing? How to I get these example how-tos running?

pimotte (Mon, 14 May 2018 08:32:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=88k9Xj8t4bprPaZZT) @alek Do you have a pool running locally?

alek (Mon, 14 May 2018 09:01:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wAc6HvzWR5o24wbmj) @pimotte thanks for your support, i think so. Taking an example of `AnoncredsDemoTest` class and `public void createWallet()` method. Application is failing on `pool = Pool.openPoolLedger(poolName, config2.toJson()).get();` but just two lines above, `poolName` was created with default settings: `poolName = PoolUtils.createPoolLedgerConfig();` so `poolName` isinitilized and not null.

pimotte (Mon, 14 May 2018 09:03:59 GMT):
@alek That function call just creates the config. Do you have a ledger running on ports 9701-9708? (For example, using the ci/indy-pool.dockerfile)

guido.santos (Mon, 14 May 2018 09:11:45 GMT):
@alek check if the IP address on your Java code corresponds to the IP address of the nodes in the genesis transactions

alek (Mon, 14 May 2018 10:22:05 GMT):
@pimotte it helped. I thought that integration tests will run independently. Thanks a lot ! @guido.santos for your suggestions

alek (Mon, 14 May 2018 10:22:05 GMT):
@pimotte it helped. I thought that integration tests will run independently. Thanks a lot ! @guido.santos thanks for your suggestions

sklump (Mon, 14 May 2018 10:51:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jfAmgeu6M5WBuuFxB) @danielhardman Do you have a design doc anywhere? I have given up trying to make sense of what to do with `to`, `from`, and `timestamp` values in the proof request, credentials, and requested credentials structures to create proof on multiple credentials on multiple revocation registries. My software is going to hobble yours until I get a better understanding.

sklump (Mon, 14 May 2018 10:51:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jfAmgeu6M5WBuuFxB) @danielhardman Do you have a design doc anywhere? I have given up trying to make sense of what to do with `to`, `from`, and `timestamp` values in the proof request, credentials, and requested credentials structures to create proof on multiple credentials on multiple revocation registries. I have a working subset, but my software is going to hobble yours until I get a better understanding.

guido.santos (Mon, 14 May 2018 10:55:25 GMT):
Hey guys, I have a question, I'm going through the Java examples and the SaveSchemaAndCredDef is giving me an error "org.hyperledger.indy.sdk.InvalidStructureException: A value being processed is not valid."

guido.santos (Mon, 14 May 2018 10:55:36 GMT):
anyone can say why? thanks!

tomislav (Mon, 14 May 2018 13:57:25 GMT):
Which java example are you referring to? Mind posting some code of the JSON structure you're using? (please use PasteBin for code smippets)

guido.santos (Mon, 14 May 2018 14:05:27 GMT):
I was using this example https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/save-schema-and-cred-def/java/README.md

guido.santos (Mon, 14 May 2018 14:05:51 GMT):
But already understood that I was using an outdated version of Indy SDK

guido.santos (Mon, 14 May 2018 14:06:13 GMT):
was using 1.3.1 and after switching to 1.4.0 it worked well

mawi (Mon, 14 May 2018 15:02:11 GMT):
Are there any docs on how exactly wallets are encrypted, how and where they store keys, and how the keys are retrieved when needed?

danielhardman (Mon, 14 May 2018 15:09:28 GMT):
@mawi, the right person to answer your question is @dkulic

alek (Mon, 14 May 2018 15:31:18 GMT):
Guys, can i find somewhere simple `java` implementation samples of indy? For example authentication, described here: https://blog.sovrin.org/sovrin-use-case-authentication-9e2a28632bd4

MALodder (Mon, 14 May 2018 15:42:51 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6Ce4tJ5pAjkw7hut4) @swcurran Sam, I will try to answer your question about revocation. What the verifier gets is a commitment to the Provers credential value that should be in the accumulator and a witness (every value in the accumulator except the provers value). With elliptic curve based accumulators you can think of the values as multiplied together as scalars. So imagine the accumulator value default value with nothing in it is G, and we put three credential values in there a, b, c. So the accumulator value is a*b*c*G where * is EC scalar multiplication or G^abc. Now, as a prover who holds the credential with value a, I send a commitment to a using G^a. The witness is computed by taking the tails file and the set from the issuer of revoked values to compute ((G^b)^c) = G^bc. So the verifier can compute the pairing function e(G^a, G^bc) which equals e(G, G)^abc. This way the verifier is essentially computing if two values that the Prover gave them, one of which is secret, equal to the accumulator value I expect. Since it would be really hard for anyone to know the exact value in the credential except the holder the verifier should be able to trust the result

sklump (Mon, 14 May 2018 15:48:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Pdi39bXK5xJPjyDEg) @MALodder Thanks, but kindly revisit phrase "I send a commitment to a using G^a" ?

tomislav (Mon, 14 May 2018 17:00:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=rCxdx2poWBCwFmtaE) @alek The anoncreds sample in the java folder has this full flow. If you think of the "gov" schema as authentication schema, where a credential is issued to Alice during the registration process with a certain organization. Logging in (or authenticating) consists of Alice providing a proof of this credential.

vidor (Mon, 14 May 2018 18:19:00 GMT):
Hello guys, For the payment interface, I find it hard to find use cases https://github.com/hyperledger/indy-sdk/tree/master/doc/design/004-payment-interface Would it be used for a cryptocurrency (incentive) inside the network or to interact with other blockchains (cryptocurrencies) like bitcoin ethereum or similar?

vidor (Mon, 14 May 2018 18:20:17 GMT):
Are there any examples or reading materials on the topic?

rndkeith (Mon, 14 May 2018 18:53:20 GMT):
Has joined the channel.

sklump (Mon, 14 May 2018 18:58:52 GMT):
*Item* I've come across something highly unusual. (1) Issuer creates revocation registry, big enough for more than one credential (2) Issuer issues, and holder/prover stores, two distinct credentials (3) Issuer revokes one credential (4) Prover creates proof on non-revoked credential, using non-empty *requested_predicates* in *requested_credentials* structure (5) Verifier verifies proof on non-revoked credential as *False*. I can't reproduce the condition using only non-empty *requested_attributes* in the holder/prover's *requested_credentials* structure. I've marked up copied wrappers/python/tests/interation/interaction.py to sk.py in the same directory for perusal, available here: https://drive.google.com/open?id=17P2B9g4AWuQ6XDVfCvs_qQhn4Jt9sfZl Anyone who can see what I've done wrong, please let me know. It must be staring me in the face but I've been working this for hours and I haven't see it yet.

sklump (Mon, 14 May 2018 19:09:00 GMT):
*Item* I've come across something highly unusual. (1) Issuer creates revocation registry, big enough for more than one credential (2) Issuer issues, and holder/prover stores, two distinct credentials (3) Issuer revokes one credential (4) Prover creates proof on non-revoked credential, using non-empty *requested_predicates* in *requested_credentials* structure (5) Verifier verifies proof on non-revoked credential as *False*. I can't reproduce the condition using only non-empty *requested_attributes* in the holder/prover's *requested_credentials* structure. I've marked up copied *wrappers/python/tests/interation/interaction.py* to *sk.py* in the same directory for perusal, _[SK: I know it is ugly and naïve]_, available here: https://drive.google.com/open?id=17P2B9g4AWuQ6XDVfCvs_qQhn4Jt9sfZl Anyone who can see what I've done wrong, please let me know. It must be staring me in the face but I've been working this for hours and I haven't see it yet.

sklump (Mon, 14 May 2018 19:09:00 GMT):
*Item* I've come across something highly unusual. (1) Issuer creates revocation registry, big enough for more than one credential (2) Issuer issues, and holder/prover stores, two distinct credentials (3) Issuer revokes one credential (4) Prover creates proof on non-revoked credential, using non-empty *requested_predicates* in *requested_credentials* structure (5) Verifier verifies proof on non-revoked credential as *False*. I can't reproduce the condition using only non-empty *requested_attributes* in the holder/prover's *requested_credentials* structure. I've marked up copied *wrappers/python/tests/interation/interaction.py* to *sk.py* in the same directory for perusal _[SK: I know it is ugly and naïve]_, available here: https://drive.google.com/open?id=17P2B9g4AWuQ6XDVfCvs_qQhn4Jt9sfZl Anyone who can see what I've done wrong, please let me know. It must be staring me in the face but I've been working this for hours and I haven't see it yet.

sklump (Mon, 14 May 2018 19:09:00 GMT):
*Item* I've come across something highly unusual. (1) Issuer creates revocation registry, big enough for more than one credential (2) Issuer issues, and holder/prover stores, two distinct credentials (3) Issuer revokes one credential (4) Prover creates proof on non-revoked credential, using non-empty *requested_predicates* in *requested_credentials* structure (5) Verifier verifies proof on non-revoked credential as *False*. I can't reproduce the condition using only non-empty *requested_attributes* in the holder/prover's *requested_credentials* structure. I've marked up copied *wrappers/python/tests/interation/interaction.py* to *sk.py* in the same directory for perusal _[SK: I know it is ugly and naïve]_, available here: https://drive.google.com/open?id=17P2B9g4AWuQ6XDVfCvs_qQhn4Jt9sfZl Anyone who can see what I've done wrong, please let me know. It must be staring me in the face but I've been working this for hours and I haven't seen it yet.

resndes (Mon, 14 May 2018 19:11:54 GMT):
Has joined the channel.

gudkov (Tue, 15 May 2018 07:11:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=pg57psvMBhqbPuCYW) @vidor The main purpose is to provide ability to add value for credentials and domain transactions. It is just interface. So it can be possible to implement payment transactions as Indy Node plugin or use 3d party crypto currency or payment system like VISA.

alek (Tue, 15 May 2018 09:05:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Q6e3gkmdsRmdXjfnE) @tomislav Appreciate it ! It helps me a lot

vidor (Tue, 15 May 2018 09:10:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=eKMxEYrJeCo4TZPAH) @gudkov Would there be any examples

vidor (Tue, 15 May 2018 09:13:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=eKMxEYrJeCo4TZPAH) @gudkov Will there be any examples of integration of this feature. For example with different cryptocurrencies like ethereum/bitcoin? My concern here is that, to reach a consensus all nodes would have to compute the same result, and when communicating with external services (other blockchains) these functions wouldn't be pure and thus making the system not so secure. To simplify, how would indy nodes check if a certain condition (payment) was met on an external blockchain using the payments feature?

sklump (Tue, 15 May 2018 13:37:24 GMT):
I think I've isolated the offending code that wrecks revocation of one credential in a revocation registry, making it appear that the Issuer revokes all credentials in the registry. It arises when the Issuer posts the revocation registry delta to the ledger for a new credential. ``` cred_values_json = { 'alex': json.dumps({ "sex": { "raw": "male", "encoded": "4887428692050081607692519917050011144233115103"}, "name": {"raw": "Alex", "encoded": "1139481716457488690172217916278103335"}, "height": {"raw": "175", "encoded": "175"}, "age": {"raw": "28", "encoded": "28"}}), 'bonnie': json.dumps({ "sex": { "raw": "female", "encoded": "9796126349812492874234725628428935692359234712"}, "name": {"raw": "Bonnie", "encoded": "3219487310856328485612384623582345221"}, "height": {"raw": "178", "encoded": "178"}, "age": {"raw": "48", "encoded": "48"}}) } # create credential (Alex), for revocation (cred_alex_json, cred_rev_alex_id, rrdelta_alex_json) = \ await anoncreds.issuer_create_credential( issuer_wallet_handle, cred_offer_json, cred_req_json, cred_values_json['alex'], rev_reg_def_id, blob_storage_reader_cfg_handle) print('\n\n-- 6.0 -- cred_rev_alex_id = {}, cred {}'.format(cred_rev_alex_id, ppjson(cred_alex_json))) # Issuer Posts (Alex) Revocation Registry Delta to Ledger rre_alex_request = await ledger.build_revoc_reg_entry_request( issuer_did, rev_reg_def_id, "CL_ACCUM", rrdelta_alex_json) print('\n\n-- 6.1 -- rev reg entry (delta) request for Alex: {}'.format(ppjson(rre_alex_request))) await ledger.sign_and_submit_request(pool_handle, issuer_wallet_handle, issuer_did, rre_alex_request) ''' ''' # create credential (Bonnie), not for revocation (cred_bonnie_json, cred_rev_bonnie_id, rrdelta_bonnie_json) = await anoncreds.issuer_create_credential( issuer_wallet_handle, cred_offer_json, cred_req_json, cred_values_json['bonnie'], rev_reg_def_id, blob_storage_reader_cfg_handle) print('\n\n-- 6.2 -- cred_rev_bonnie_id = {}, delta {}, cred {}'.format( cred_rev_bonnie_id, ppjson(rrdelta_bonnie_json), ppjson(cred_bonnie_json))) ''' ''' # Issuer Posts (Bonnie) Revocation Registry Delta to Ledger rre_bonnie_request = await ledger.build_revoc_reg_entry_request( issuer_did, rev_reg_def_id, "CL_ACCUM", rrdelta_bonnie_json) print('\n\n-- 6.3 -- rev reg entry (delta) request for Bonnie: {}'.format(ppjson(rre_bonnie_request))) await ledger.sign_and_submit_request(pool_handle, issuer_wallet_handle, issuer_did, rre_bonnie_request) ''' ''' ```

gudkov (Tue, 15 May 2018 14:05:55 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qT99SJqv69q78G7uF) @vidor As i know Sovrin developers are doing payments implementation.

alek (Tue, 15 May 2018 14:36:25 GMT):
@tomislav, could you be so kind and help me with understanding of concept used in `java` sdk ? I am going through the `AnoncredsDemoTest` and validate it against authentication problem described here: https://blog.sovrin.org/sovrin-use-case-authentication-9e2a28632bd4. According to that example `connector` is the private secure, person's storage of user sensitive data that is stored out of ledger. When i lookedinto the `AnoncredsDemoTest` i can see that there is ONE API `Anoncreds`that is used both for ledger processing, for example: `Anoncreds.verifierVerifyProof` and off ledger operations refering to `connector` part, for example `Anoncreds.proverStoreCredential`. Then i see that `Anoncreds` uses one `LibIndy.api`. Is my understanding correct that it ideally should be divided into ledger and "off-ledger" operations ? Or it id done in such way because of incubation state of the project ?

alek (Tue, 15 May 2018 14:36:25 GMT):
@tomislav, could you be so kind and help me with understanding of concept used in `java` sdk ? I am going through the `AnoncredsDemoTest` and validate it against authentication problem described here: https://blog.sovrin.org/sovrin-use-case-authentication-9e2a28632bd4. According to that example `connector` is the private secure, person's storage of user sensitive data that is stored out of ledger. When i lookedinto the `AnoncredsDemoTest` i can see that there is ONE API `Anoncreds`that is used both for ledger processing, for example: `Anoncreds.verifierVerifyProof` and off ledger operations refering to `connector` part, for example `Anoncreds.proverStoreCredential`. Then i see that `Anoncreds` uses one`LibIndy.api`. Is my understanding correct that it ideally should be divided into ledger and "off-ledger" operations ? Or it id done in such way because of incubation state of the project ?

gudkov (Tue, 15 May 2018 15:49:02 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=TZYvsJh7eiKJbniJ4) @alek Anoncreds.verifierVerifyProof doesn't require access to ledger. Actually there are no anoncreds endpoints that require access to the ledger

sklump (Tue, 15 May 2018 17:29:16 GMT):
I notice that *anoncreds.update_revocation_state()* and *anoncreds.create_revocation_state()* require a credential revocation identifier *cred_rev_id* parameter. Does the revocation state depend on the *cred_rev_id*? I.e., if I have a prover and it caches the revocation state for a (*timestamp* and) *cred_rev_id*, can I use this revocation state as the *rev_state_json* parameter for a future call to *update_revocation_state()* for a distinct *cred_rev_id*, or do I have to create the state from scratch for the new *cred_rev_id* ?

sklump (Tue, 15 May 2018 17:29:16 GMT):
I notice that *anoncreds.update_revocation_state()* and *anoncreds.create_revocation_state()* require a credential revocation identifier *cred_rev_id* parameter. Does the revocation state depend on the *cred_rev_id*? I.e., if I have a prover and it caches the revocation state for a ( *timestamp* and) *cred_rev_id*, can I use this revocation state as the *rev_state_json* parameter for a future call to *update_revocation_state()* for a distinct *cred_rev_id*, or must the prover create the state (from nothing) for the new *cred_rev_id* ?

Neumann347 (Tue, 15 May 2018 21:21:22 GMT):
Hi - I am trying to run the java sample on a separate machine from the test pool network. When I run the sample on the same machine, it works fine. However, when I run it on a separate machine, I get this exception: "Exception in thread "main" java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.InvalidStateException: The SDK library experienced an unexpected internal error." I installed the stable version of the libindy.so version and was getting it, so I uninstalled that and installed the master version of libindy.so. Still the same error. Is anyone else getting this error?

mark.hadley (Tue, 15 May 2018 21:47:55 GMT):
Are there additional dependencies not listed for the https://github.com/hyperledger/indy-sdk/tree/feature/wallet_storage_integration branch? When compiling the https://github.com/hyperledger/indy-sdk/tree/feature/wallet_storage_integration branch and attempting to link to the libindy.so file that produced by it an error similar to this is outputted: https://pastebin.com/w4hEHgT2.

kevin.chan (Tue, 15 May 2018 22:34:39 GMT):
Hi guys, I have a question related to the DKMS protocol around Agent Policies and Registry. Seems to imply that we need some new indy ledger operations to accomplish this? Has this been planned or is it still in conceptual phase?

kevin.chan (Tue, 15 May 2018 22:34:52 GMT):
https://github.com/hyperledger/indy-sdk/blob/677a0439487a1b7ce64c2e62671ed3e0079cc11f/doc/design/005-dkms/DKMS%20Design%20and%20Architecture%20V3.md#104-update-agent-policy-registry

kevin.chan (Tue, 15 May 2018 22:35:45 GMT):
I also have the same question in reference to microledgers.

gudkov (Wed, 16 May 2018 08:48:56 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=iHCBuiNrFSNhfsend) @mark.hadley As i know it requires never libsodium. I suggest to contact Darko for details.

gudkov (Wed, 16 May 2018 08:50:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=orjAac8ps8geRb3Qn) @Neumann347 I suggest to enable logging by setting env variable RUST_LOG=trace and provide us logs and stack trace. Without this information is it hard to help.

Kelattar (Wed, 16 May 2018 13:08:51 GMT):
hello ! I am working on the python wrappers, but I have some questions : when we create a ledger configuration, what does it exactly mean ? more like a copy of the ledger or a copy of all information about nodes .. ?, and when the prover receives a claim from the issuer and stores it with the functions anoncreds.prover_store_credential where is it stored ? I can't find any of the exchanges done through python wrappers stored somewhere ? can you please help me figure this out ?

tomislav (Wed, 16 May 2018 13:50:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kXqDFwBQJQsAsqfmE) @Kelattar Take a look at ~/.indy_client . All ledger config information as well as wallet data is stored in there. You can use a sqlite browser to see the data inside the wallet

guido.santos (Wed, 16 May 2018 14:04:55 GMT):
Hi all, sorry for jumping into the conversation, @tomislav I'm seeing the .indy_client folder, it has a wallets folder inside, but it is empty.. Is there something missing? Btw, I'm working with Java wrappers

tomislav (Wed, 16 May 2018 14:12:04 GMT):
Indylib stores wallet and pool info inside that folder. If you run create wallet methods successfully, there should be files inside.

tomislav (Wed, 16 May 2018 14:13:20 GMT):
Try creating a did as well.

guido.santos (Wed, 16 May 2018 14:13:31 GMT):
DID's are created and available in the ledger

guido.santos (Wed, 16 May 2018 14:13:41 GMT):
I can see them in the transactions

tomislav (Wed, 16 May 2018 14:14:16 GMT):
Then private key data should be inside wallet folder. Are you running this locally or inside docker?

guido.santos (Wed, 16 May 2018 14:14:41 GMT):
it's locally and I was inspecting the docker node

guido.santos (Wed, 16 May 2018 14:14:46 GMT):
locally the files are there

guido.santos (Wed, 16 May 2018 14:14:49 GMT):
thanks :)

guido.santos (Wed, 16 May 2018 14:21:13 GMT):
@tomislav one more question, is there a way to save a wallet in a different manner? like directly on a DB or something like that?

tomislav (Wed, 16 May 2018 14:22:57 GMT):
Yes. You can register a wallet type by passing callbacks for each of the required methods. Check the API doc https://github.com/hyperledger/indy-sdk/blob/f85f87d74c401eff7f4f29bd6ba1b9a28298a9f2/libindy/src/api/wallet.rs#L31

tomislav (Wed, 16 May 2018 14:24:08 GMT):
In your case, you can use CustomWallet.java interface

guido.santos (Wed, 16 May 2018 14:29:21 GMT):
ok, thanks again :)

Kelattar (Wed, 16 May 2018 14:50:25 GMT):
@tomislav I found them thanks a lot :D

sklump (Wed, 16 May 2018 16:03:54 GMT):
ITEM: In the *interaction.py* sample, there is one *proof_req_json*, that serves for the whole sample, including a *non_revoked* interval ending at a time before the revocation event. The same proof request goes into the *anoncreds.prover_create_proof()* call before and after the revocation event. Yet the resulting proof from before the revocation verifies as *True*, while the proof from after the revocation verifies as *False* afterward. What is the intended use of the non-revocation interval in the proof request? Is it maybe a placeholder for future semantics?

sklump (Wed, 16 May 2018 16:03:54 GMT):
~ITEM:~ ~In the *interaction.py* sample, there is one *proof_req_json*, that serves for the whole sample, including a *non_revoked* interval ending at a time before the revocation event. The same proof request goes into the *anoncreds.prover_create_proof()* call before and after the revocation event.~ ~Yet the resulting proof from before the revocation verifies as *True*, while the proof from after the revocation verifies as *False* afterward. What is the intended use of the non-revocation interval in the proof request? Is it maybe a placeholder for future semantics?~ Never mind, the interval is correct. Eventually I will figure it out or stumble on a real bug.

Neumann347 (Wed, 16 May 2018 17:15:44 GMT):
@gudkov Here is the paste-bin of the log file. https://pastebin.com/cXhPyWTs.

mboyd (Wed, 16 May 2018 18:15:05 GMT):
When working with the python wrapper, how to we target compiled libindy.so that we make from the indy-sdk source code? Right now the wrapper is searching for the natively installed libindy package for ubuntu

sklump (Wed, 16 May 2018 18:31:15 GMT):
``` $ cd indy-sdk ``` ``` $ sudo cp libindy/target/debug/libindy.so /usr/lib ``` or ``` $ sudo cp libindy/target/release/libindy.so /usr/lib ```

mboyd (Wed, 16 May 2018 18:50:47 GMT):
Thank you, that worked.

sklump (Wed, 16 May 2018 18:51:07 GMT):
or ``` $ export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:~/indy-sdk/target/debug/libindy.so ``` (or release)

mboyd (Wed, 16 May 2018 18:51:21 GMT):
I had to remove the native library as well. Does anyone know if the python wrapper has been sufficiently updated for the 1.4.0 release?

sklump (Wed, 16 May 2018 18:51:58 GMT):
The python wrapper is fine for the 1.4.0 release (candidate)

sklump (Wed, 16 May 2018 18:51:58 GMT):
The python wrapper is fine for the 1.4.0 release

tusharg (Thu, 17 May 2018 06:40:09 GMT):
Has joined the channel.

gudkov (Thu, 17 May 2018 07:53:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=EeHoohqN8zDwGF96d) @Neumann347 You can see the error "Ledger merkle tree doesn\'t acceptable for current tree.". So your transactions in genesis file doesn't correspond to the pool ledger. The most probably you use differen nodes ip addresses for pool ledger and for genesis file.

stanleyc-trustscience (Thu, 17 May 2018 08:21:21 GMT):
Hello, I'm trying to build docker with older version of dockerfile. (commit 82c4d68bf509afec89ac820a1a5016ba6bedffc6) The reason i'm using a older version is because the dotnet wrapper isn't updated for the latest changes in libindy I'm getting this ``` Step 20/22 : RUN generate_indy_pool_transactions --nodes 4 --clients 5 --nodeNum 1 2 3 4 --ips="$pool_ip,$pool_ip,$pool_ip,$pool_ip" ---> Running in c9ca6f93c59c Traceback (most recent call last): File "/usr/local/bin/generate_indy_pool_transactions", line 19, in getTxnOrderedFields(), ConfigHelper, NodeConfigHelper) File "/usr/local/lib/python3.5/dist-packages/plenum/common/test_network_setup.py", line 207, in bootstrapTestNodes steward_defs, node_defs = cls.gen_defs(args.ips, args.nodes, startingPort) File "/usr/local/lib/python3.5/dist-packages/plenum/common/test_network_setup.py", line 291, in gen_defs d.verkey = s_signer.verkey File "/usr/local/lib/python3.5/dist-packages/plenum/common/signer_did.py", line 54, in verkey return self.abbr_prfx + self._verkey TypeError: Can't convert 'bytes' object to str implicitly ``` If anyone can help me with this, it'd be greatly appreciated

sergey.minaev (Thu, 17 May 2018 09:18:49 GMT):
@stanleyc-trustscience try to use dockerfile from master branch. Most probably old libindy with wrapper will work successfully with latest node (used in master dockerfile)

wolili (Thu, 17 May 2018 10:15:03 GMT):
Hi, I try to use the how-tos with python wrapper. I cannot Import 'signus' ? What is the problem there? ` ImportError: cannot import name 'signus' `

faisal00813 (Thu, 17 May 2018 10:32:07 GMT):
android

sergey.minaev (Thu, 17 May 2018 10:44:21 GMT):
Hi @wolili, what version of indy sdk do you use? Most probably in your sources version how-tos is outdated against libindy and appropriate wrapper. It also possible for master or even rc branch, as these how-tos are not supported by core IndySDK team

wolili (Thu, 17 May 2018 10:51:27 GMT):
Thanks for your reply. I'm using 1.4.0.

sergey.minaev (Thu, 17 May 2018 10:58:24 GMT):
Do you use master or RC branch of the sources?

sergey.minaev (Thu, 17 May 2018 11:02:05 GMT):
I've check both and see `signus` here (as you mentioned above). This module is out-date, so seems like how-tos for python doesn't updated well. I can suggest you to take a look on 1) demo tests inside python wrapper 2) python sample

tusharg (Thu, 17 May 2018 11:04:27 GMT):
Hey @wolili, I ran into the same problem.. apparently signs has been replaced by "did". Just replace sinus by did everywhere and you should be good to go :)

tusharg (Thu, 17 May 2018 11:04:27 GMT):
Hey @wolili, I ran into the same problem.. apparently signus has been replaced by "did". Just replace sinus by did everywhere and you should be good to go :)

tusharg (Thu, 17 May 2018 11:04:27 GMT):
Hey @wolili, I ran into the same problem.. apparently signus has been replaced by "did". Just replace signus by did everywhere and you should be good to go :)

wolili (Thu, 17 May 2018 11:05:59 GMT):
@sergey.minaev & @tusharg thank you for your quick replies. I will try that!

sergey.minaev (Thu, 17 May 2018 11:29:24 GMT):
@tusharg @wolili if just replacing will not help, there is migration guide about changes https://github.com/hyperledger/indy-sdk/blob/master/doc/migration-guide.md

wolili (Thu, 17 May 2018 11:33:07 GMT):
In my case it helped... I replaced "signus" with "did" like @tusharg said and it worked. Still, thank you @sergey.minaev for the Link. Now I know where to look for if get into trouble again.

sklump (Thu, 17 May 2018 16:22:32 GMT):
Hi folks, I notice that the filter doesn't work in *anoncreds.prover_get_credentials()*. Passing no filter works great - all creds come back. However, in the test code, after adding Alex, the following code ``` filt = json.dumps({'schema_name': 'gvt', 'schema_version': '1.0'}) gvt_creds = json.loads(await anoncreds.prover_get_credentials(prover_wallet_handle, filt)) print('Government creds: {}'.format(ppjson(gvt_creds))) ``` returns an empty list. I'm on python3-indy 1.4.0-rc-20. Could one of you kindly tell me what am I doing wrong?

gudkov (Thu, 17 May 2018 16:48:46 GMT):
Could you provide the full test or at least output without filter @sklump ?

sklump (Thu, 17 May 2018 17:01:33 GMT):
Test code here, https://drive.google.com/open?id=1LrXZ48LE5MfG-huwg9WnfrBpqhE-Afqt, installs in `wrappers/python/tests/interation/`.

sklump (Thu, 17 May 2018 17:01:33 GMT):
Test code here, https://drive.google.com/open?id=1LrXZ48LE5MfG-huwg9WnfrBpqhE-Afqt, installs in `wrappers/python/tests/interation/`. ``` $pytest -s cred-filtration.py ``` produces ``` cred-filtration.py All creds: [ { "attrs": { "name": "Alex", "sex": "male", "age": "28", "height": "175" }, "cred_def_id": "4QxzWk3ajdnEA37NdNU5Kt:3:CL:13", "schema_id": "4QxzWk3ajdnEA37NdNU5Kt:2:gvt:1.0", "cred_rev_id": "1", "referent": "cred_alex_id", "rev_reg_id": "4QxzWk3ajdnEA37NdNU5Kt:4:4QxzWk3ajdnEA37NdNU5Kt:3:CL:13:CL_ACCUM:tag1" } ] Government creds: [] . ```

sklump (Thu, 17 May 2018 17:01:33 GMT):
Test code here, https://drive.google.com/open?id=1LrXZ48LE5MfG-huwg9WnfrBpqhE-Afqt, installs in `wrappers/python/tests/interation/`. ``` $ pipenv run pytest -s cred-filtration.py ``` produces ``` cred-filtration.py All creds: [ { "attrs": { "name": "Alex", "sex": "male", "age": "28", "height": "175" }, "cred_def_id": "4QxzWk3ajdnEA37NdNU5Kt:3:CL:13", "schema_id": "4QxzWk3ajdnEA37NdNU5Kt:2:gvt:1.0", "cred_rev_id": "1", "referent": "cred_alex_id", "rev_reg_id": "4QxzWk3ajdnEA37NdNU5Kt:4:4QxzWk3ajdnEA37NdNU5Kt:3:CL:13:CL_ACCUM:tag1" } ] Government creds: [] . ```

sklump (Thu, 17 May 2018 17:17:28 GMT):
_(It's easy enough to patch it coming back, but I just wanted to make sure it was necessary for the moment.)_

sklump (Thu, 17 May 2018 17:17:28 GMT):
_(It's easy enough to patch it coming back from the wallet into my code, but I just wanted to make sure it was necessary for the moment.)_

AxelNennker (Thu, 17 May 2018 17:24:37 GMT):
Added some files explaining how to cross-compile libindy for Android (examples are for arm64) https://github.com/AxelNennker/indy-sdk/tree/master/doc work in progress

StanleyChen (Thu, 17 May 2018 19:27:25 GMT):
Has joined the channel.

StanleyChen (Thu, 17 May 2018 19:28:38 GMT):
Got some issue here running `var parse = await Ledger.ParseGetSchemaResponseAsync(getSchemaResponse);` Gives `InvalidLedgerTransactionException: The ledger message is unknown or malformed.`

StanleyChen (Thu, 17 May 2018 19:28:38 GMT):
Got some issue here running Gives `InvalidLedgerTransactionException: The ledger message is unknown or malformed.`

StanleyChen (Thu, 17 May 2018 19:28:38 GMT):
Got some issue here running ``` var getSchemaRequest = await Ledger.BuildGetSchemaRequestAsync(govInfo.DidEntity.DidInfo.Did, transcriptSchema.SchemaId); var getSchemaResponse = await Ledger.SubmitRequestAsync(pool, getSchemaRequest); var parsedGetSchemaResponse = await Ledger.ParseGetSchemaResponseAsync(getSchemaResponse); ``` Gives `InvalidLedgerTransactionException: The ledger message is unknown or malformed.`

StanleyChen (Thu, 17 May 2018 19:28:49 GMT):

problem.txt

StanleyChen (Thu, 17 May 2018 19:29:37 GMT):
getSchemaResponse ``` { "op":"REPLY", "result":{ "identifier":"TwY6uNe7EfhtS6yYG64GAq", "seqNo":null, "type":"107", "data":{ "name":"Transcript", "version":"1.2" }, "reqId":1526585027236218700, "dest":"TwY6uNe7EfhtS6yYG64GAq", "txnTime":null, "state_proof":{ "root_hash":"G9ydyF4woEYzfrS3RzMyvc2GJZxx6yCHAufu7ZN4qDTG", "proof_nodes":"+QHn+FGAgICAgKBi\/+WIKrOpdU9OH8EH1p8im1+3kQAg2a3\/J7JdQv6zaoCAgKCVea2xZlEF1WQlMBskbxjhlJXGtb58Pwug0ZUSTwjqpICAgICAgID5AZGgyapkprN+kgPSEdwzjJ2UUfMwn+nPiHziy4sxEOmNiW6g9d46ra7njXzRgU7lqKZUPs3na4wI4+jE1+ygwh\/Ot82gZ\/oKjoF6NYiDUk7JFcXljtVGhK8\/lHAHjwR99B+Pa3egmpq6PvRB\/76zSDjdvXO+dATJAmHaV82rEVG2ZoAO+TCAoDWpDqU01A3GnqHO+NxxRnHe2K8HsoPRt0Pzxl6cPmVqoNpSqLjxEwXf7eDNimKgorFnn9qozb7wQq35jxaLjS5QgKCBkRec7GPF+ukCjMHu7p9HAeiuskawvnj4xUQdIsiTCoCAoCRyJt6FDmJQ60JcPeVA5EXTnNrRiLBPYNq9dgI6SYlCoJukLIzfHjmQto4f2VmmIiqDEAUGhUIvbOkPly5ifbcboLpjFgPX5RmhTYYEgzlDOTAL5kHVkdcq+7Dxn3Lzu8v6oBvSoTludXD0XkhTPm4YxfCcAdCaiDvkzM8w6O4v5\/e1oHe5DVipNLwm0OQhHz4QtQK7qP7WN6qFBGNIgLr5Au3WgA==", "multi_signature":{ "signature":"RWoN9JNa44zYrtHTfrd5ab5F9LbVMd1AaGvEAhg1yE2tmyRTxVYEm2p8St9Grv6wDSQPG8EQiPPh3waeoGzGEfwYBA8Nxn46JsN6wxH2gKY6Xnzk9Dw3gN4FxifeCcGTzDx4syQdVAc7UqwkpbUvrhvFi5eGPL9FX1kGuiWpq25y6F", "participants":[ "Node3", "Node4", "Node1" ], "value":{ "ledger_id":1, "txn_root_hash":"Gm8pjkjgHwgKbmcU6rCBrfkFx75RZ1LFhJTHr3we1eso", "state_root_hash":"G9ydyF4woEYzfrS3RzMyvc2GJZxx6yCHAufu7ZN4qDTG", "pool_state_root_hash":"n6VPkuHJYFPk6Lnzk6wFKE8HQkwiXvPXfWPb1Xw5zp4", "timestamp":1526585026 } } } } } ```

StanleyChen (Thu, 17 May 2018 19:30:10 GMT):

getSchemaResponse.txt

StanleyChen (Thu, 17 May 2018 19:30:21 GMT):
getSchemaResponse is in the txt ..

StanleyChen (Thu, 17 May 2018 19:30:21 GMT):
getSchemaResponse is in the txt .. How's the message malformed?

StanleyChen (Thu, 17 May 2018 19:42:20 GMT):
The schema was created prior to the get ``` var transcriptSchema = await AnonCreds.IssuerCreateSchemaAsync(govInfo.DidEntity.DidInfo.Did, "Transcript", "1.2", "[\"first_name\", \"last_name\", \"degree\", \"status\", \"year\", \"average\", \"ssn\"]" ); string schemaRequest = await Ledger.BuildSchemaRequestAsync(govInfo.DidEntity.DidInfo.Did, transcriptSchema.SchemaJson); await Ledger.SignAndSubmitRequestAsync(pool, govInfo.DidEntity.Wallet, govInfo.DidEntity.DidInfo.Did, schemaRequest); ```

StanleyChen (Thu, 17 May 2018 19:42:20 GMT):
The schema was created as following, prior to the get ``` var transcriptSchema = await AnonCreds.IssuerCreateSchemaAsync(govInfo.DidEntity.DidInfo.Did, "Transcript", "1.2", "[\"first_name\", \"last_name\", \"degree\", \"status\", \"year\", \"average\", \"ssn\"]" ); string schemaRequest = await Ledger.BuildSchemaRequestAsync(govInfo.DidEntity.DidInfo.Did, transcriptSchema.SchemaJson); await Ledger.SignAndSubmitRequestAsync(pool, govInfo.DidEntity.Wallet, govInfo.DidEntity.DidInfo.Did, schemaRequest); ```

StanleyChen (Thu, 17 May 2018 20:15:31 GMT):
FYI, Just figured out the problem, government has to be a trust anchor for the role, I was using null as the role. ``` var trusteeDidNymRequest = await Ledger.BuildNymRequestAsync(stewardDidEntity.DidInfo.Did, decryptedtrusteeDidInfo.Did, decryptedtrusteeDidInfo.VerKey, null, "TRUST_ANCHOR"); ```

tusharg (Fri, 18 May 2018 04:26:26 GMT):
Hey, I have been trying to run the "write a did and query its verkey" tutorial without much luck.. I have a docker pool running and have the genesis_file_path set accordingly, still the program cannot get past the "await pool.create_pool_ledger_config(config_name=pool_name, config=pool_config)" command (step 2) and throws :

tusharg (Fri, 18 May 2018 04:26:29 GMT):
_indy_loop_callback: Function returned error 114 Error occurred: ErrorCode.CommonIOError

gudkov (Fri, 18 May 2018 06:52:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4oq4BBB4ub2Yzu2ui) @StanleyChen Anyway error code returned doesn't seem like a correct behavior. @Artemkaaas Could you check?

ianco (Fri, 18 May 2018 11:59:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3LJmbRXogupy6ghSB) @tusharg The path to the genesis file is hardcoded in the script. You need to update the script to point to your local genesis file (for example in indy-sdk there is a genesis file in "cli/docker_pool_transactions_genesis")

ianco (Fri, 18 May 2018 12:17:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3LJmbRXogupy6ghSB) @tusharg Probably something to do with your genesis file. Make sure the IP in the genesis file points to the IP where your pool is actually running. You can try running the "getting started" python script (samples/python) and see if that works - it creates a genesis txn file under /tmp/indy, you can compare that to the one you are using. (Also as an aside I noticed that the todo is coded against an older version if the sdk, that may be causing problems if your pool is running against a newer version. You can try changing references of "signus" to "did", and make sure to point your PYTHONPATH to wrappers/python.)

swcurran (Fri, 18 May 2018 15:51:37 GMT):
@gudkov - any update on @sklump issue above? This is a blocker for us and cost us a number of hours of time for multiple devs. Seems like a hot-fix to the indy-sdk is needed to get this working. Please let us know the status.

jljordan_bcgov (Fri, 18 May 2018 17:54:43 GMT):
@esplinr ^^

StanleyChen (Fri, 18 May 2018 22:40:24 GMT):
Going through Alice's applying for a job at Acme. Not understanding this ...

StanleyChen (Fri, 18 May 2018 22:40:34 GMT):

proofRequest.txt

StanleyChen (Fri, 18 May 2018 22:40:39 GMT):

credential.txt

StanleyChen (Fri, 18 May 2018 22:42:29 GMT):
` var credForJob = await AnonCreds.ProverGetCredentialsForProofReqAsync(aliceEntity.Wallet, proofRequestJson);` I'm getting attr1_referent, attr2_referent, attr3_referent, and so on. But the tutorial shows a different json returned ``` # Alice Agent { 'referent': 'Transcript Credential Referent', 'attrs': { 'first_name': 'Alice', 'last_name': 'Garcia', 'status': 'graduated', 'degree': 'Bachelor of Science, Marketing', 'ssn': '123-45-6789', 'year': '2015', 'average': '5' }, 'schema_id': job_certificate_schema_id, 'cred_def_id': faber_transcript_cred_def_id, 'rev_reg_id': None, 'cred_rev_id': None } ```

swcurran (Fri, 18 May 2018 22:52:35 GMT):
@StanleyChen - I'm not hands on with this, but what you are showing is the Credential from Faber. A ProofRequest is a list of Claims that need to be proven - each Claim from one or more Credential. So the "first_name" referent in the Proof Request can be proven by the "first_name" claim from the Credential from Faber. Because Indy supports ZKP and Selective Disclosure, you don't proof something by sending a complete Credential, you prove individual claims. Hope that makes sense.

StanleyChen (Fri, 18 May 2018 22:54:52 GMT):
@swcurran Thank you for clarifying

StanleyChen (Fri, 18 May 2018 22:54:59 GMT):
``` "attr1_referent": { "name": "first_name" }, ```

StanleyChen (Fri, 18 May 2018 22:54:59 GMT):
proofRequest ``` "attr1_referent": { "name": "first_name" }, ``` faber credential ``` "attr1_referent":[ { "cred_info":{ "referent":"32e1e580-3d0e-47d4-afc9-4f56d09e4b9e", "attrs":{ "average":"5", "last_name":"Garcia", "year":"2015", "first_name":"Alice", "status":"graduated", "ssn":"123-45-6789", "degree":"Bachelor of Science, Marketing" }, "schema_id":"HsVzmQp4UD958h8z1RLM93:2:Transcript:1.2", "cred_def_id":"EpAP7HviyuYXJ1MEWLqg1n:3:CL:751", "rev_reg_id":null, "cred_rev_id":null }, "interval":null } ], ```

StanleyChen (Fri, 18 May 2018 22:57:33 GMT):
Two questions @swcurran 1. So it looks like, when there is no restriction, it will automatically pop in a matching attribute name (like "first_name" from faber) 2. Why does it gives so many attrs? (eg, like average, last_name, year, etc) when attr1_referent is only asking for `first_name`

StanleyChen (Fri, 18 May 2018 22:57:33 GMT):
Two questions @swcurran 1. So it looks like, when there is no restriction, it will automatically pop in a matching attribute name (like "first_name" from faber). Doesn't matter which issuer issued the attribute 2. Why does it gives so many attrs? (eg, like average, last_name, year, etc) when attr1_referent is only asking for `first_name`

StanleyChen (Fri, 18 May 2018 22:57:33 GMT):
Two questions @swcurran 1. So it looks like, when there is no restriction, it will automatically pop in a value for matching attribute name (like `first_name` from faber). Doesn't matter which issuer issued the attribute 2. Why does it gives so many attrs? (eg, like average, last_name, year, etc) when attr1_referent is only asking for `first_name`

swcurran (Fri, 18 May 2018 23:12:24 GMT):
There are several layers at play here. Indy-sdk is asking the wallet for all of the credentials that meet the criteria. It returns that list to the caller - e.g. an Agent, or in this case the CLI. It's up to that caller to do what it needs to do - e.g. what you are seeing - matching names and populating automatically, or asking the user "Do you want to send this?" or whatever. The IndySDK works on a claim by claim basis and returns the entire credential from the wallet that meets the criteria for the element of the ProofRequest to be proven. That gives whomever calls it the context to make a decision on what to do.

swcurran (Fri, 18 May 2018 23:12:54 GMT):
Hey - I've got to run, so won't be able to follow up immediately. Sorry about that. I hope I helped.

esplinr (Sat, 19 May 2018 12:38:41 GMT):
@swcurran and @jljordan_bcgov I've been traveling and got behind on rocket chat. Which issue is blocking your team?

jljordan_bcgov (Sat, 19 May 2018 13:29:22 GMT):
@esplinr [ ](https://chat.hyperledger.org/channel/indy-sdk?msg=cgx5SpNXqe4Pgi9wT)

jljordan_bcgov (Sat, 19 May 2018 13:29:42 GMT):
More above

swcurran (Sat, 19 May 2018 16:05:41 GMT):
@esplinr - we had another developer independently hit the same issue - spent a lot of time debugging to find it.

ramanagak (Mon, 21 May 2018 06:09:50 GMT):
Hi Guys, Is there any documentation for implementing an agent like faber college?

ramanagak (Mon, 21 May 2018 06:09:50 GMT):
Hi Guys, Is there any documentation for implementing an agent like faber college using python SDK?

gudkov (Mon, 21 May 2018 06:52:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=eraE4mzAc9KEpZbqc) @ramanagak Actually the main GSG is about this.

gudkov (Mon, 21 May 2018 07:47:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qNBPtQ46zaMoqJPGg) @swcurran @sklump @esplinr, @Artemkaaas reproduced the issue and there is already PR with fix. Do you need this fix in stable channel or master will be ok?

gudkov (Mon, 21 May 2018 09:52:09 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=rXBfXrAF9JY3mNvg2) merged to master

Artemkaaas (Mon, 21 May 2018 13:12:48 GMT):
FIxed in Libindy master version - 522

jonathanreynolds (Mon, 21 May 2018 15:36:34 GMT):
Hi all. I hope this is the correct channel to ask this in. Is there a standard way to know which verkey to use when receiving an auth_encrypted message and calling auth_decrypt on it. The examples all pass the correct key as they are written but don't seem to determine which key to use from any context in the message. It seems like we need some information about the pairwise relationship as metadata.

AxelNennker (Mon, 21 May 2018 16:09:32 GMT):
Published https://github.com/AxelNennker/DroidLibIndy to get libindy running on Android. Still trying to get the unit tests to pass... Somebody willing to jump in?

AxelNennker (Mon, 21 May 2018 16:13:04 GMT):
I cloned https://github.com/faisal00813/indy-sdk/blob/android_support/doc/android-build.md and created the Android Studio project around it. Changed all 127.0.01 to the IP of my laptop where the nodes are running.

mboyd (Mon, 21 May 2018 18:35:56 GMT):
@AxelNennker Awesome job! If you can create a ticket in the IS (indy-sdk) jira channel and label the feature as help wanted, I think we can find some people to help out with the unit tests.

mboyd (Mon, 21 May 2018 18:37:43 GMT):
You can add it to the [community contribution sprint board](https://jira.hyperledger.org/secure/RapidBoard.jspa?rapidView=149&projectKey=IS&view=planning&selectedIssue=IS-688)

kevin.chan (Mon, 21 May 2018 21:35:20 GMT):
hey guys, I've been trying out cred revoc. I have a question, is there a way to un-revoke a credential? For example, the opposite of anoncreds.issuer_revoke_credential?

kevin.chan (Mon, 21 May 2018 21:35:20 GMT):
hey guys, I've been trying out cred revocation. I have a question, is there a way to un-revoke a credential? For example, the opposite of anoncreds.issuer_revoke_credential?

Artemkaaas (Tue, 22 May 2018 06:06:36 GMT):
Hi @kevin.chan. There is not a way to recover credential for now. (Actually, there is indy_issuer_recover_credential function in Libindy but it had been decided to hide it because there are some issues) For now, issuance of the same credential is the only way.

gudkov (Tue, 22 May 2018 08:10:58 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Lqnso8Edu3EvWRxzi) @AxelNennker Have you seen this PR https://github.com/hyperledger/indy-sdk/pull/777/files ?

tusharg (Tue, 22 May 2018 09:34:32 GMT):
``` Hi, I got past the first step. Unfortunately, I got stuck on the second... Now the code throws this output `python3 did_write.py 1. Create new pool ledger configuration to connect to ledger. 2. Open ledger and get handle _indy_loop_callback: Function returned error 112 Error occurred: ErrorCode.CommonInvalidState` ``` Can you tell me what to do?

jayapalreddy (Tue, 22 May 2018 12:02:35 GMT):
Has joined the channel.

sklump (Tue, 22 May 2018 13:06:39 GMT):
I know I'm probably asking for something that cannot be, but if there were any way to include some kind of DEBUG log on what part of a proof makes it verify as *False*, that would be a huge help for debugging with revocation. So many things can be wrong, yielding the exact same *False* result.

AxelNennker (Tue, 22 May 2018 13:34:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4cW3DsnL7arCSQ62u) @gudkov I exchanged emails with Mohammad Sami (don't know his handle here) last week and yesterday. Yesterday he told me about android-build.md. I guess he did not see my https://github.com/AxelNennker/indy-sdk/blob/master/doc/android-build.md as I did not see his. Parallel work

AxelNennker (Tue, 22 May 2018 13:36:40 GMT):
It seems that the wallet location in the filesystem is defined by libindy and not by the application using it. Is this true? If yes, then that should be changed, I think...

gudkov (Tue, 22 May 2018 14:08:53 GMT):
It uses the code like: ``` pub fn indy_home_path() -> PathBuf { // TODO: FIXME: Provide better handling for the unknown home path case!!! let mut path = env::home_dir().unwrap_or(PathBuf::from("/home/indy")); path.push(if cfg!(target_os = "ios") { "Documents/.indy_client" } else { ".indy_client" }); path } ```

dbluhm (Tue, 22 May 2018 14:32:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=eraE4mzAc9KEpZbqc) @ramanagak We have a few entities working on agent implementations in Python and other languages. A lot of the conversation is going on here as well as in #indy-agent. Unfortunately, we don't have any documentation on implementing an agent yet (to my knowledge, at least).

dbluhm (Tue, 22 May 2018 14:32:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=eraE4mzAc9KEpZbqc) @ramanagak We have a few entities working on agent implementations in Python and other languages. A lot of the conversation is going on here as well as in #indy-agent . Unfortunately, we don't have any documentation on implementing an agent yet (to my knowledge, at least).

dbluhm (Tue, 22 May 2018 14:32:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=eraE4mzAc9KEpZbqc) @ramanagak We have a few entities working on agent implementations in Python and other languages. A lot of the conversation is going on here as well as in #indy-agent . Unfortunately, we don't have any documentation on implementing an agent yet (to my knowledge, at least) apart from the Getting Started Guide that @gudkov mentioned.

dbluhm (Tue, 22 May 2018 14:33:59 GMT):
@ramanagak there are lots of people willing to answer questions, though!

sklump (Tue, 22 May 2018 15:19:37 GMT):
@ramangak, feel free to track https://github.com/PSPC-SPAC-buyandsell/von_agent/ as it evolves.

sklump (Tue, 22 May 2018 15:19:37 GMT):
@ramangak, feel free to track https://github.com/PSPC-SPAC-buyandsell/von_agent/ as it evolves. Be aware that a VON agent isn't necessarily a conceptual one-to-one match for an indy-agent.

sklump (Tue, 22 May 2018 15:19:37 GMT):
@ramanagak feel free to track https://github.com/PSPC-SPAC-buyandsell/von_agent/ as it evolves. Be aware that a VON agent isn't necessarily a conceptual one-to-one match for an indy-agent.

kosullivan_sita (Tue, 22 May 2018 15:25:04 GMT):
help

ragpach2 (Tue, 22 May 2018 15:47:56 GMT):
revocation

karthikpanicker (Tue, 22 May 2018 21:14:16 GMT):
Has joined the channel.

kevin.chan (Tue, 22 May 2018 21:29:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kk72Zk5s6Qs7NQtTs) @Artemkaaas ok thank you for the response

kevin.chan (Wed, 23 May 2018 00:09:03 GMT):
Hey Guys, can someone confirm some things around blob storage writer and reader? I've been looking at the rust code and I found the BlobStorageService and where it registers the default writer and reader types that write/read from local disk https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/services/blob_storage/mod.rs#L57 Is it true that currently, to implement a different reader/writer (for example read from an http endpoint serving the tails file), we would have to implement it inside the indy-sdk rust code itself? This seems to be different than how the indy-sdk allows registering custom wallet types. Is there any thinking around adding support to register custom blob storage types like there is for registering custom wallet types? Thanks.

kevin.chan (Wed, 23 May 2018 00:11:46 GMT):
The problem I'm trying to figure out how to address, is how a prover will be able to have access to the tails file to generate a proof... given that it looks like the current sdk requires the whole file to be avail on local disk and the size of these files would be very large

tusharg (Wed, 23 May 2018 05:35:18 GMT):
```` ``` `

stanleyc-trustscience (Wed, 23 May 2018 05:39:25 GMT):
Hi guys, I'm trying to run the python getting started sample. I'm running into a weird PoolLedgerNotCreatedError ... Can someone help me with this? ``` ubuntudev@ubuntudev-vm:~/newgit/indy-sdk/samples/python$ sudo docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a5c26a963ea8 indy_pool "/usr/bin/supervisord" 14 minutes ago Up 14 minutes 0.0.0.0:9701-9708->9701-9708/tcp relaxed_turing ubuntudev@ubuntudev-vm:~/newgit/indy-sdk/samples/python$ python3 -m src.main INFO:src.getting_started:Getting started -> started INFO:src.getting_started:Open Pool Ledger: pool1 WARNING:indy.libindy:_indy_loop_callback: Function returned error 114 WARNING:indy.libindy:_indy_loop_callback: Function returned error 300 Traceback (most recent call last): File "/usr/lib/python3.5/runpy.py", line 184, in _run_module_as_main "__main__", mod_spec) File "/usr/lib/python3.5/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/ubuntudev/newgit/indy-sdk/samples/python/src/main.py", line 16, in run_coroutine(main) File "/home/ubuntudev/newgit/indy-sdk/samples/python/src/utils.py", line 45, in run_coroutine loop.run_until_complete(coroutine()) File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step result = coro.throw(exc) File "/home/ubuntudev/newgit/indy-sdk/samples/python/src/main.py", line 8, in main await getting_started.run() File "/home/ubuntudev/newgit/indy-sdk/samples/python/src/getting_started.py", line 29, in run pool_handle = await pool.open_pool_ledger(pool_name, None) File "/home/ubuntudev/newgit/indy-sdk/samples/python/indy/pool.py", line 82, in open_pool_ledger open_pool_ledger.cb) File "/usr/lib/python3.5/asyncio/futures.py", line 361, in __iter__ yield self # This tells Task to wait for completion. File "/usr/lib/python3.5/asyncio/tasks.py", line 296, in _wakeup future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception indy.error.IndyError: ErrorCode.PoolLedgerNotCreatedError ```

stanleyc-trustscience (Wed, 23 May 2018 05:39:58 GMT):
I'm sorry for the lengthy message

tusharg (Wed, 23 May 2018 05:41:31 GMT):
Hi, on running the getting_started.py provided in `indy-sdk/samples/python` using the command `python3 -m src.main` I get the following error (even though it proceeded quite far, hence I am not posting the entire output) `INFO:src.getting_started:============================== INFO:src.getting_started:== Apply for the job with Acme - Transcript proving == INFO:src.getting_started:------------------------------ INFO:src.getting_started:"Acme" -> Create "Job-Application" Proof Request INFO:src.getting_started:"Acme" -> Get key for Alice did WARNING:indy.libindy:_indy_loop_callback: Function returned error 112 Traceback (most recent call last): File "/usr/lib/python3.5/runpy.py", line 184, in _run_module_as_main "__main__", mod_spec) File "/usr/lib/python3.5/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/ubuntu/indy/indy-sdk/samples/python/src/main.py", line 16, in run_coroutine(main) File "/home/ubuntu/indy/indy-sdk/samples/python/src/utils.py", line 45, in run_coroutine loop.run_until_complete(coroutine()) File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step result = coro.throw(exc) File "/home/ubuntu/indy/indy-sdk/samples/python/src/main.py", line 8, in main await getting_started.run() File "/home/ubuntu/indy/indy-sdk/samples/python/src/getting_started.py", line 296, in run alice_acme_verkey = await did.key_for_did(pool_handle, acme_wallet, acme_alice_connection_response['did']) File "/usr/local/lib/python3.5/dist-packages/indy/did.py", line 317, in key_for_did key_for_did.cb) File "/usr/lib/python3.5/asyncio/futures.py", line 361, in __iter__ yield self # This tells Task to wait for completion. File "/usr/lib/python3.5/asyncio/tasks.py", line 296, in _wakeup future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception indy.error.IndyError: ErrorCode.CommonInvalidState`

tusharg (Wed, 23 May 2018 05:41:50 GMT):
Can anyone tell me how to fix it?

stanleyc-trustscience (Wed, 23 May 2018 05:46:43 GMT):
@tusharg How did you get past the pool creation?

tusharg (Wed, 23 May 2018 05:48:07 GMT):
@stanleyc-trustscience Did you run `docker-compose up` in doc/getting_started?

stanleyc-trustscience (Wed, 23 May 2018 05:48:41 GMT):
omg let me check, i only ran docker run ...

stanleyc-trustscience (Wed, 23 May 2018 05:55:47 GMT):
@tusharg Sorry, I tried to google for the error below, but nothing helpful was returned ``` ubuntudev@ubuntudev-vm:~/newgit/indy-sdk/doc/getting-started$ sudo docker-compose up ERROR: Couldn't connect to Docker daemon at http+docker://localunixsocket - is it running? If it's at a non-standard location, specify the URL with the DOCKER_HOST environment variable. ```

stanleyc-trustscience (Wed, 23 May 2018 05:55:47 GMT):
@tusharg ``` ubuntudev@ubuntudev-vm:~/newgit/indy-sdk/doc/getting-started$ docker-compose up ERROR: Couldn't connect to Docker daemon at http+docker://localunixsocket - is it running? If it's at a non-standard location, specify the URL with the DOCKER_HOST environment variable. ```

stanleyc-trustscience (Wed, 23 May 2018 05:55:47 GMT):
@tusharg Sorry, I tried to google for the error below, but nothing helpful was returned ``` ubuntudev@ubuntudev-vm:~/newgit/indy-sdk/doc/getting-started$ docker-compose up ERROR: Couldn't connect to Docker daemon at http+docker://localunixsocket - is it running? If it's at a non-standard location, specify the URL with the DOCKER_HOST environment variable. ```

stanleyc-trustscience (Wed, 23 May 2018 06:02:44 GMT):
nevermind, it needed a docker restart

tusharg (Wed, 23 May 2018 06:04:13 GMT):
@stanleyc-trustscience is your `getting_started.py` running now?

stanleyc-trustscience (Wed, 23 May 2018 06:04:34 GMT):
@tusharg Thanks for checking, docker is building now, will update soon

stanleyc-trustscience (Wed, 23 May 2018 06:05:28 GMT):
I got past your step with a dotnet wrapper that I wrote .. maybe I'll be able to figure out what went wrong for you, when i get there in python

stanleyc-trustscience (Wed, 23 May 2018 06:09:02 GMT):
@tusharg Hm, still the same error

stanleyc-trustscience (Wed, 23 May 2018 06:09:29 GMT):
``` ubuntudev@ubuntudev-vm:~/newgit/indy-sdk/samples/python$ sudo docker ps [sudo] password for ubuntudev: CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES b310f718eb6c getting-started "jupyter notebook ..." 2 minutes ago Up 2 minutes 0.0.0.0:8888->8888/tcp getting_started 0523db17eae3 indy_pool "/usr/bin/supervisord" 2 minutes ago Up 2 minutes 0.0.0.0:9701-9708->9701-9708/tcp indy_pool ```

stanleyc-trustscience (Wed, 23 May 2018 06:14:29 GMT):
@resultspro Oh man, needed a sudo before python3 lol

resultspro (Wed, 23 May 2018 06:14:29 GMT):
Has joined the channel.

stanleyc-trustscience (Wed, 23 May 2018 06:14:54 GMT):
But whoa, I got past your step no problem

stanleyc-trustscience (Wed, 23 May 2018 06:15:28 GMT):
Probably needed the sudo because it was looking for genesis txn file in /tmp/indy/

tusharg (Wed, 23 May 2018 06:44:16 GMT):
@stanleyc-trustscience WOW! Thanks man!

stanleyc-trustscience (Wed, 23 May 2018 07:44:36 GMT):
@tusharg Your problem fixed? lol

esplinr (Wed, 23 May 2018 14:37:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JYz92BWfkJwF9RW5o) @jonathanreynolds Do you believe that this is a bug?

jonathanreynolds (Wed, 23 May 2018 14:40:40 GMT):
It could be a gap

jonathanreynolds (Wed, 23 May 2018 14:40:50 GMT):
Or perhaps just a gap in my understanding

jonathanreynolds (Wed, 23 May 2018 14:40:55 GMT):
an example is https://github.com/hyperledger/indy-sdk/blob/master/samples/python/src/getting_started.py#L189

jonathanreynolds (Wed, 23 May 2018 14:41:12 GMT):
here the `alice_faber_key` is used in the call

jonathanreynolds (Wed, 23 May 2018 14:42:04 GMT):
but it seems to me that when the `authcrypted_transcript_cred_offer` is passed to Alice she would not have context to know which of the pairwise keys she has to use

zhigunenko.dsr (Wed, 23 May 2018 14:56:28 GMT):
Has joined the channel.

tomislav (Wed, 23 May 2018 15:12:56 GMT):
I think it's up to application to decide how to handle this. From SDK perspective, you are correct, there's no way to know which key should be used to decrypt just by looking at the encrypted message. One way this can be handled is the sender can also sign the message and include their DID, or specify which target DID they intend this message for.

tomislav (Wed, 23 May 2018 15:12:56 GMT):
I think it's up to application to decide how to handle this. From SDK perspective, you are correct, there's no way to know which key should be used to decrypt just by looking at the encrypted message. One way this can be handled is the sender can also sign the message and include their DID (which can be used to find pairwise), or specify which target DID they intend this message for.

jonathanreynolds (Wed, 23 May 2018 15:27:00 GMT):
thanks for the reply @tomislav. given everyone who want to use the sdk will have to implement this would it make sense to formalise how to best do this?

jonathanreynolds (Wed, 23 May 2018 15:28:17 GMT):
I'm happy to push a PR as a basis for discussion.

esplinr (Wed, 23 May 2018 15:30:34 GMT):
@jonathanreynolds We have a process for making design decisions. You can see it in the indy-rfc repository (though we might change the name away from RFC to something Hyperledger Indy specific). But before submitting an Improvement Proposa, you might want to discuss this on the mailing list.

esplinr (Wed, 23 May 2018 15:30:34 GMT):
@jonathanreynolds We have a process for making design decisions. You can see it in the indy-rfc repository (though we might change the name away from RFC to something Hyperledger Indy specific). But before submitting an Improvement Proposal, you might want to discuss this on the mailing list.

jonathanreynolds (Wed, 23 May 2018 15:32:46 GMT):
@esplinr this repo: https://github.com/hyperledger/indy-hipe?

esplinr (Wed, 23 May 2018 15:33:24 GMT):
Oh, that was quick. They only proposed renaming it yesterday.

esplinr (Wed, 23 May 2018 15:33:26 GMT):
But yes, that's the one.

esplinr (Wed, 23 May 2018 15:34:21 GMT):
Hyperledger Indy Project Enhancements

jonathanreynolds (Wed, 23 May 2018 15:37:04 GMT):
ok thanks. It looks like this channel is the place for discussion prior to creating a HIPE.

esplinr (Wed, 23 May 2018 15:49:25 GMT):
Or on the mailing list.

esplinr (Wed, 23 May 2018 15:49:50 GMT):
https://lists.hyperledger.org/g/indy

nhelmy (Wed, 23 May 2018 18:32:38 GMT):
Hi, quick question for any devs in the know: is this a reference implementation for an identity wallet? how complete is this? i.e. could an Agency use this implementation, and modify it, to work with an edge agent on an iphone? https://github.com/hyperledger/indy-sdk/tree/master/libindy/src/services/wallet

wolili (Wed, 23 May 2018 18:47:31 GMT):
Hi, I'm getting the same error like @guido.santos got, when executing SaveSchemaAndCredDef.java. ``` Schema: {"name":"gvt","version":"1.0","attr_names":["age", "sex", "height", "name"]} java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.InvalidStructureException: A value being processed is not valid. ``` His proposed fix to upgrade to 1.4.0 didn't work. [ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wRuLt2z7n47Fkjs8n) . Any thoughts what could be the problem there?

nbrempel (Wed, 23 May 2018 22:43:29 GMT):
Is anyone familiar with this error? ``` Casting error to ErrorCode: Invalid transaction: Cannot deserialize transaction Response: Error("data did not match any variant of untagged enum Reply", line: 0, column: 0) ```

Artemkaaas (Thu, 24 May 2018 05:37:46 GMT):
hi, @wolili doc/how-tos are not up to date. Schema format was changed. You can use function Anoncreds.issuerCreateSchema to build Schema in the correct way

Artemkaaas (Thu, 24 May 2018 05:39:03 GMT):
@nbrempel Could you please share logs. (to do it use env variable RUST_LOG=debug)

tusharg (Thu, 24 May 2018 06:51:08 GMT):
Hi, in the write_did_and_query_verkey python tutorial, step 3 says "The DID and public verkey for this steward key are already in the ledger; they were part of the genesis transactions we told the SDK to start with in the previous step". However, on inspecting the genesis transaction manually, I could only find some node data as follows : `cat /tmp/indy/pool2.txn | jq { "data": { "alias": "Node1", "blskey": "4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba", "client_ip": "127.0.0.1", "client_port": 9702, "node_ip": "127.0.0.1", "node_port": 9701, "services": [ "VALIDATOR" ] }, "dest": "Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv", "identifier": "Th7MpTaRZVRYnPiabds81Y", "txnId": "fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62", "type": "0" } { "data": { "alias": "Node2", "blskey": "37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk", "client_ip": "127.0.0.1", "client_port": 9704, "node_ip": "127.0.0.1", "node_port": 9703, "services": [ "VALIDATOR" ] }, "dest": "8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb", "identifier": "EbP4aYNeTHL6q385GuVpRV", "txnId": "1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc", "type": "0" } { "data": { "alias": "Node3", "blskey": "3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5", "client_ip": "127.0.0.1", "client_port": 9706, "node_ip": "127.0.0.1", "node_port": 9705, "services": [ "VALIDATOR" ] }, "dest": "DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya", "identifier": "4cU41vWW82ArfxJxHkzXPG", "txnId": "7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4", "type": "0" } { "data": { "alias": "Node4", "blskey": "2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw", "client_ip": "127.0.0.1", "client_port": 9708, "node_ip": "127.0.0.1", "node_port": 9707, "services": [ "VALIDATOR" ] }, "dest": "4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA", "identifier": "TWwCRQRZ2ZHMJFn9TzLp7W", "txnId": "aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008", "type": "0" }`. What am I missing? Thanks

tusharg (Thu, 24 May 2018 06:51:08 GMT):
Hi, in the write_did_and_query_verkey python tutorial, step 3 says "The DID and public verkey for this steward key are already in the ledger; they were part of the genesis transactions we told the SDK to start with in the previous step". However, on inspecting the genesis transaction manually, I could only find some node data as follows : ```cat /tmp/indy/pool2.txn | jq { "data": { "alias": "Node1", "blskey": "4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba", "client_ip": "127.0.0.1", "client_port": 9702, "node_ip": "127.0.0.1", "node_port": 9701, "services": [ "VALIDATOR" ] }, "dest": "Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv", "identifier": "Th7MpTaRZVRYnPiabds81Y", "txnId": "fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62", "type": "0" } { "data": { "alias": "Node2", "blskey": "37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk", "client_ip": "127.0.0.1", "client_port": 9704, "node_ip": "127.0.0.1", "node_port": 9703, "services": [ "VALIDATOR" ] }, "dest": "8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb", "identifier": "EbP4aYNeTHL6q385GuVpRV", "txnId": "1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc", "type": "0" } { "data": { "alias": "Node3", "blskey": "3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5", "client_ip": "127.0.0.1", "client_port": 9706, "node_ip": "127.0.0.1", "node_port": 9705, "services": [ "VALIDATOR" ] }, "dest": "DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya", "identifier": "4cU41vWW82ArfxJxHkzXPG", "txnId": "7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4", "type": "0" } { "data": { "alias": "Node4", "blskey": "2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw", "client_ip": "127.0.0.1", "client_port": 9708, "node_ip": "127.0.0.1", "node_port": 9707, "services": [ "VALIDATOR" ] }, "dest": "4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA", "identifier": "TWwCRQRZ2ZHMJFn9TzLp7W", "txnId": "aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008", "type": "0" }```. What am I missing? Thanks

tusharg (Thu, 24 May 2018 06:51:08 GMT):
Hi, in the write_did_and_query_verkey python tutorial, step 3 says "The DID and public verkey for this steward key are already in the ledger; they were part of the genesis transactions we told the SDK to start with in the previous step". However, on inspecting the genesis transaction manually, I could only find some node data as follows : ```cat /tmp/indy/pool2.txn | jq { "data": { "alias": "Node1", "blskey": "4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba", "client_ip": "127.0.0.1", "client_port": 9702, "node_ip": "127.0.0.1", "node_port": 9701, "services": [ "VALIDATOR" ] }, "dest": "Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv", "identifier": "Th7MpTaRZVRYnPiabds81Y", "txnId": "fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62", "type": "0" } { "data": { "alias": "Node2", "blskey": "37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk", "client_ip": "127.0.0.1", "client_port": 9704, "node_ip": "127.0.0.1", "node_port": 9703, "services": [ "VALIDATOR" ] }, "dest": "8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb", "identifier": "EbP4aYNeTHL6q385GuVpRV", "txnId": "1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc", "type": "0" } { "data": { "alias": "Node3", "blskey": "3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5", "client_ip": "127.0.0.1", "client_port": 9706, "node_ip": "127.0.0.1", "node_port": 9705, "services": [ "VALIDATOR" ] }, "dest": "DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya", "identifier": "4cU41vWW82ArfxJxHkzXPG", "txnId": "7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4", "type": "0" } { "data": { "alias": "Node4", "blskey": "2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw", "client_ip": "127.0.0.1", "client_port": 9708, "node_ip": "127.0.0.1", "node_port": 9707, "services": [ "VALIDATOR" ] }, "dest": "4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA", "identifier": "TWwCRQRZ2ZHMJFn9TzLp7W", "txnId": "aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008", "type": "0" }```. What am I missing? How did the Steward DID and verkey enter the ledger? Thanks

wolili (Thu, 24 May 2018 10:16:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aNuW9Mkquvi23iTvD) @Artemkaaas thank you, it worked

sergey.minaev (Thu, 24 May 2018 10:18:34 GMT):
@sklump does TRACE logs contain enough information for you?

sergey.minaev (Thu, 24 May 2018 10:18:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=AFuFfSt6FPLf5MJhK) @sklump does TRACE logs contain enough information for you?

sklump (Thu, 24 May 2018 11:37:42 GMT):
I set RUST_LOG=trace for those?

sklump (Thu, 24 May 2018 11:37:42 GMT):
@sergey.minaev I set RUST_LOG=trace for those?

sklump (Thu, 24 May 2018 11:37:42 GMT):
@sergey.minaev I export RUST_LOG=trace for those?

gudkov (Thu, 24 May 2018 12:57:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=MvyBAFEyt4aKmbpdb) @tusharg These keys will be provided on the begging of pool initialization you can get documentation in indy-node repo (or ask in the channel with same name)

benjsmi (Thu, 24 May 2018 15:03:57 GMT):
hello all -- is there anyone here that could help with my questions over in #indy-node ?

benjsmi (Thu, 24 May 2018 15:04:22 GMT):
i was told that this channel is monitored better and i'm not going to repost because my questions don't pertain to the sdk but i could really use some help.

sergey.minaev (Thu, 24 May 2018 15:11:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=xxuMeQgucEBrWSp2q) @sklump yes, `RUST_LOG=trace` is maximal log level for libindy as for now.

AxelNennker (Thu, 24 May 2018 16:05:07 GMT):
Could somebody please have a look at https://jira.hyperledger.org/browse/IS-700 ? I think that the application that uses libindy should be able to set the location of the wallet through the wallet API. Doing this through the environment seems strange to me. Thoughts? Thank you.

mhailstone (Thu, 24 May 2018 20:08:48 GMT):
I'm getting the following error when trying to build libindy: ```error: failed to run custom build command for `zmq-sys v0.8.2` process didn't exit successfully: `/Users/mhailstone/dev/sovrin/hyperledger/indy-sdk/libindy/target/debug/build/zmq-sys-9581007e84245c21/build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'Unable to locate libzmq: `"pkg-config" "--libs" "--cflags" "libzmq >= 3.2"` did not exit successfully: exit code: 1 --- stderr Package libzmq was not found in the pkg-config search path. Perhaps you should add the directory containing `libzmq.pc' to the PKG_CONFIG_PATH environment variable No package 'libzmq' found ', /Users/mhailstone/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-sys-0.8.2/build.rs:31:16 note: Run with `RUST_BACKTRACE=1` for a backtrace. warning: build failed, waiting for other jobs to finish... error: build failed ``` Thoughts?

mboyd (Thu, 24 May 2018 20:12:36 GMT):
@dbluhm has had this problem before

mhailstone (Thu, 24 May 2018 20:13:49 GMT):
As a note, I am running the build on OSX.

mhailstone (Thu, 24 May 2018 20:13:49 GMT):
As a note, I am running the build on Mac OS X.

mboyd (Thu, 24 May 2018 20:14:50 GMT):
You will probably need to manually install libzmq on mac using homebrew

mboyd (Thu, 24 May 2018 20:15:07 GMT):
I think it's libzmq3-dev

dbluhm (Thu, 24 May 2018 20:18:44 GMT):
@mhailstone The issue @mboyd mentioned was solved by installing http://macappstore.org/zeromq/ but I can't make promises

tiger-ts (Thu, 24 May 2018 21:12:11 GMT):
Has joined the channel.

faisal00813 (Thu, 24 May 2018 22:36:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=vBL2ZPK3waDqmTJKh) @mhailstone On OSX you need to install zmq. Try `brew install zeromq --with-libsodium`

mhailstone (Thu, 24 May 2018 22:39:12 GMT):
Thank you @faisal00813 and @mboyd ! This brew install worked `brew install zmq`

mhailstone (Thu, 24 May 2018 22:41:33 GMT):
Questions: How does an agent identify who the connection offer/request/response is from? If we use exclusive pairwise identifiers, is there meta information with the connection transaction that can be used? Does the pairwise identifier (their_did) refer to an alias DID on the ledger that is well-known? Could we use a new message type that is for identification of the pairwise identifier (their_did)? Even with a new message type, how are we sure the DID is who it says it is? I suppose this goes into the Web of Trust concept. If we reference an alias DID, the issuer is probably a well-known DID that is a good pattern to follow in referencing. But, if I'm not an issuer (yet) what would I use as the requesting agent?

lxy (Fri, 25 May 2018 02:29:39 GMT):
Has joined the channel.

lxy (Fri, 25 May 2018 02:29:46 GMT):
Hello!

lxy (Fri, 25 May 2018 02:31:32 GMT):
I am from China. It is my honor to join this group.

faisal00813 (Fri, 25 May 2018 06:42:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=gCztoQMkdo6NYKBbh) @AxelNennker I think delegation of the decision of _where to create the wallet_ to application makes sense.

jeremi 24 (Fri, 25 May 2018 07:06:43 GMT):
Has joined the channel.

jeremi 24 (Fri, 25 May 2018 08:12:52 GMT):
Hi, I'm trying to run the indy-sdk demo using jupyter and docker, but I'm getting an error: `IndyError: ErrorCode.CommonInvalidState`

jeremi 24 (Fri, 25 May 2018 08:13:32 GMT):
```... ============================== == Getting Transcript with Faber - Getting Transcript Credential == ------------------------------ "Faber" -> Create "Transcript" Credential Offer for Alice "Faber" -> Get key for Alice did --------------------------------------------------------------------------- IndyError Traceback (most recent call last) in () 786 loop = asyncio.new_event_loop() 787 asyncio.set_event_loop(loop) --> 788 loop.run_until_complete(run()) 789 time.sleep(1) # FIXME waiting for libindy thread complete /usr/lib/python3.5/asyncio/base_events.py in run_until_complete(self, future) 385 raise RuntimeError('Event loop stopped before Future completed.') 386 --> 387 return future.result() 388 389 def stop(self): /usr/lib/python3.5/asyncio/futures.py in result(self) 272 self._tb_logger = None 273 if self._exception is not None: --> 274 raise self._exception 275 return self._result 276 /usr/lib/python3.5/asyncio/tasks.py in _step(***failed resolving arguments***) 239 result = coro.send(None) 240 else: --> 241 result = coro.throw(exc) 242 except StopIteration as exc: 243 self.set_result(exc.value) in run() 154 155 print("\"Faber\" -> Get key for Alice did") --> 156 alice_faber_verkey = await did.key_for_did(pool_handle, acme_wallet, faber_alice_connection_response['did']) 157 158 print("\"Faber\" -> Authcrypt \"Transcript\" Credential Offer for Alice") /usr/local/lib/python3.5/dist-packages/indy/did.py in key_for_did(pool_handle, wallet_handle, did) 315 c_wallet_handle, 316 c_did, --> 317 key_for_did.cb) 318 319 res = key.decode() /usr/lib/python3.5/asyncio/futures.py in __iter__(self) 359 if not self.done(): 360 self._blocking = True --> 361 yield self # This tells Task to wait for completion. 362 assert self.done(), "yield from wasn't used with future" 363 return self.result() # May raise too. /usr/lib/python3.5/asyncio/tasks.py in _wakeup(self, future) 294 def _wakeup(self, future): 295 try: --> 296 future.result() 297 except Exception as exc: 298 # This may also be a cancellation. /usr/lib/python3.5/asyncio/futures.py in result(self) 272 self._tb_logger = None 273 if self._exception is not None: --> 274 raise self._exception 275 return self._result 276 IndyError: ErrorCode.CommonInvalidState```

jeremi 24 (Fri, 25 May 2018 08:14:06 GMT):
anyone already encountered this issue ?

jeremi 24 (Fri, 25 May 2018 08:16:13 GMT):
I'm using master branch

olegwb (Fri, 25 May 2018 08:20:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=vBL2ZPK3waDqmTJKh) @mhailstone Hi, assuming you have put the library into right place and you have set the right env var to point to it , it is not the case of the library have not been found. It is the library itself that has wrong ELF format.

gudkov (Fri, 25 May 2018 11:25:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=xX4wAHkzduAmEseqa) @faisal00813 I suggest to use https://github.com/hyperledger/indy-hipe process for proposals like this. It is more complex than just " libindy should be able to set the location of the wallet through the wallet API". libindy uses storage not just to only store wallet file.

gudkov (Fri, 25 May 2018 12:30:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=pnz5wxzACipZjGnaf) @jeremi 24 what exact commands do you use?

StanleyChen (Fri, 25 May 2018 18:28:30 GMT):
Hi guys, anyone know how to connect to the real indy's production network? Doing operation like getting verkey by DID

StanleyChen (Fri, 25 May 2018 18:28:30 GMT):
Hi guys, anyone know how to connect to the real indy's production network? Doing read operation like getting verkey by DID

jeremi 24 (Sat, 26 May 2018 06:57:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=gsoMGLzEZXipuH2ja) I'm using the last version of the ipython notebook and followed the doc in this folder: https://github.com/hyperledger/indy-sdk/tree/master/doc/getting-started

rajupenu (Sun, 27 May 2018 09:55:03 GMT):
Has joined the channel.

sndiaye2022 (Sun, 27 May 2018 20:40:23 GMT):
Has joined the channel.

AxelNennker (Mon, 28 May 2018 14:08:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=xX4wAHkzduAmEseqa) @faisal00813 would you please comment on IS-700 ?

AxelNennker (Mon, 28 May 2018 14:11:05 GMT):
Hi, I just updated indy and sovrin packages on ubuntu 16.04 from this versions: ubuntu@identitychain:~/.ssh$ dpkg --list | fgrep indy hi indy-anoncreds 1.0.11 amd64 Anonymous credentials hi indy-node 1.3.55 amd64 Indy node hi indy-plenum 1.2.34 amd64 Plenum Byzantine Fault Tolerant Protocol ii libindy-crypto 0.4.0 amd64 This is the shared crypto libirary for Hyperledger Indy components. hi python3-indy-crypto 0.2.0 amd64 This is the official wrapper for Hyperledger Indy Crypto library (https://www.hyperledger.org/projects). ubuntu@identitychain:~/.ssh$ dpkg --list | fgrep sovrin hi sovrin 1.1.8 amd64 Sovrin node to these versions: ubuntu@identitychain:~$ dpkg --list | fgrep indy ii indy-anoncreds 1.0.32 amd64 Anonymous credentials ii indy-node 1.3.428 amd64 Indy node ii indy-plenum 1.2.375 amd64 Plenum Byzantine Fault Tolerant Protocol ii libindy-crypto 0.4.0 amd64 This is the shared crypto libirary for Hyperledger Indy components. ii python3-indy-crypto 0.4.1 amd64 This is the official wrapper for Hyperledger Indy Crypto library (https://www.hyperledger.org/projects). ubuntu@identitychain:~$ dpkg --list | fgrep sovrin ii sovrin 1.1.53 amd64 Sovrin node ubuntu@identitychain:~$

AxelNennker (Mon, 28 May 2018 14:11:36 GMT):
Now I get this error message: Argh! May 28 14:04:12 localhost env[20175]: File "/usr/local/bin/start_indy_node", line 17, in May 28 14:04:12 localhost env[20175]: run_node(config, self_name, int(sys.argv[2]), int(sys.argv[3])) May 28 14:04:12 localhost env[20175]: File "/usr/local/lib/python3.5/dist-packages/indy_node/utils/node_runner.py", line 54, in run_node May 28 14:04:12 localhost env[20175]: ha=node_ha, cliha=client_ha) May 28 14:04:12 localhost env[20175]: File "/usr/local/lib/python3.5/dist-packages/indy_node/server/node.py", line 92, in __init__ May 28 14:04:12 localhost env[20175]: config=config) May 28 14:04:12 localhost env[20175]: File "/usr/local/lib/python3.5/dist-packages/plenum/server/node.py", line 177, in __init__ May 28 14:04:12 localhost env[20175]: self.primaryStorage = storage or self.getPrimaryStorage() May 28 14:04:12 localhost env[20175]: File "/usr/local/lib/python3.5/dist-packages/indy_node/server/node.py", line 115, in getPrimaryStorage May 28 14:04:12 localhost env[20175]: hashStore=self.getHashStore('domain')), May 28 14:04:12 localhost env[20175]: File "/usr/local/lib/python3.5/dist-packages/plenum/server/node.py", line 750, in getHashStore May 28 14:04:12 localhost env[20175]: return initHashStore(self.dataLocation, name, self.config) May 28 14:04:12 localhost env[20175]: File "/usr/local/lib/python3.5/dist-packages/storage/helper.py", line 54, in initHashStore May 28 14:04:12 localhost env[20175]: read_only=read_only) May 28 14:04:12 localhost env[20175]: File "/usr/local/lib/python3.5/dist-packages/plenum/persistence/db_hash_store.py", line 22, in __init__ May 28 14:04:12 localhost env[20175]: self.open() May 28 14:04:12 localhost env[20175]: File "/usr/local/lib/python3.5/dist-packages/plenum/persistence/db_hash_store.py", line 93, in open May 28 14:04:12 localhost env[20175]: self._leafCount = self.leavesDb.size May 28 14:04:12 localhost env[20175]: File "/usr/local/lib/python3.5/dist-packages/storage/kv_store.py", line 67, in size May 28 14:04:12 localhost env[20175]: for _ in self.iterator(): May 28 14:04:12 localhost env[20175]: File "/usr/local/lib/python3.5/dist-packages/storage/kv_store_rocksdb.py", line 109, in iterator May 28 14:04:12 localhost env[20175]: itr.seek_to_first() May 28 14:04:12 localhost env[20175]: File "rocksdb/_rocksdb.pyx", line 1790, in rocksdb._rocksdb.BaseIterator.seek_to_first May 28 14:04:12 localhost env[20175]: File "rocksdb/_rocksdb.pyx", line 1793, in rocksdb._rocksdb.BaseIterator.seek_to_first May 28 14:04:12 localhost env[20175]: File "rocksdb/_rocksdb.pyx", line 84, in rocksdb._rocksdb.check_status May 28 14:04:12 localhost env[20175]: rocksdb.errors.RocksIOError: b'IO error: While open a file for random read: /var/lib/indy/eit-idchain/data/eit-idchain-telekomde-01/domain_merkleLeaves/000005.sst: No such file or directory' May 28 14:04:12 localhost systemd[1]: indy-node.service: Main process exited, code=exited, status=1/FAILURE May 28 14:04:12 localhost systemd[1]: indy-node.service: Unit entered failed state. May 28 14:04:12 localhost systemd[1]: indy-node.service: Failed with result 'exit-code'.

gudkov (Mon, 28 May 2018 14:57:28 GMT):
@AxelNennker I suggest to ask in indy-node channel

gudkov (Mon, 28 May 2018 15:01:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=2LuDnTE5KfFeyd4bM) @jeremi 24 I understand that you use this instruction. It would be nice to get exact list of commands, commit hash and all logs. This tutorial works for the most of guys, but we saw few cases like you. And we need to understand what the difference. There is a bug that looks similar https://jira.hyperledger.org/browse/IS-673. We will appreciate if you can attach your info to this bug.

sklump (Mon, 28 May 2018 15:22:06 GMT):
I've updated indy-sdk to dev-1.4.0-dev-533 in the virtual environment, and have compiled libindy.so (for release) from the current master. Now at *await pool.create_pool_ledger_config()*, I get: ``` E OSError: /usr/lib/libindy.so: undefined symbol: crypto_pwhash ``` Could someone in the know kindly respond with which pypi version matches the current master? Thanks a million. _I also notice that *ci/indy-pool.dockerfile* has_ ``` ARG indy_plenum_ver=1.2.369 ARG indy_anoncreds_ver=1.0.32 ARG indy_node_ver=1.3.425 ARG python3_indy_crypto_ver=0.4.1 ARG indy_crypto_ver=0.4.0 ``` _which makes me suspect I'm tracking an incorrect branch_

sklump (Mon, 28 May 2018 15:22:06 GMT):
I've updated indy-sdk to dev-1.4.0-dev-533 in the virtual environment, and have compiled libindy.so (for release) from the current master. Now at *await pool.create_pool_ledger_config()*, I get: ``` E OSError: /usr/lib/libindy.so: undefined symbol: crypto_pwhash ``` Could someone in the know kindly respond with which pypi version matches the current master? Thanks a million. _I also notice that *ci/indy-pool.dockerfile* has_ ``` ARG indy_plenum_ver=1.2.369 ARG indy_anoncreds_ver=1.0.32 ARG indy_node_ver=1.3.425 ARG python3_indy_crypto_ver=0.4.1 ARG indy_crypto_ver=0.4.0 ``` _, vastly different from a few days ago, which makes me suspect I'm tracking an incorrect branch_

AxelNennker (Mon, 28 May 2018 19:08:19 GMT):
IS-700 hitting https://github.com/AxelNennker/DroidLibIndy/issues/1

AxelNennker (Mon, 28 May 2018 19:17:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=zqc8opmnAht8uKLcN) @gudkov Sorry, done.

AxelNennker (Tue, 29 May 2018 09:50:48 GMT):
How about deleting https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/utils/environment.rs ? I think that a library should not use environment variables deep inside without a library API the application of the library can use to change the place where the wallet is stored.

AxelNennker (Tue, 29 May 2018 09:52:08 GMT):
The cli has its own version anyway https://github.com/hyperledger/indy-sdk/blob/master/cli/src/utils/environment.rs

gudkov (Tue, 29 May 2018 10:53:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=q8QqafwNw4eNWf2BE) @AxelNennker I suggest to create HIPE for this proposal. libindy doesn't look to environment variables at all. It calls corresponded syscalls to get access to environment. As i understand it has incorrect behavior on Android and we need workaround. It is the main motivation for these changes, but there was also reasons to make libindy responsible for storage of wallet configuration. For example, allow access the same wallet from different applications on same edge device.

gudkov (Tue, 29 May 2018 10:53:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=q8QqafwNw4eNWf2BE) @AxelNennker I suggest to create HIPE for this proposal. libindy doesn't look to environment variables at all. It calls corresponded syscalls to get access to environment. As i understand it has incorrect behavior on Android and we need workaround. It is the main motivation for this changes, but there was also reasons to make libindy responsible for storage of wallet configuration. For example, allow access the same wallet from different applications on same edge device.

AxelNennker (Tue, 29 May 2018 11:05:33 GMT):
@gudkov HYPE? The situation on ios is similar in general. Although not as tricky as on Android. I saw that that the wallet storage branch was merged and deleted. Using the same storage area for wallets is not a real problem. If the application uses shared storage then the other wallets can access the user wallet, if the application NEEDs application-private storage then other application MUST not be able to access those private wallets. The default for libindy should be a shared location but interoperability between apps is not enforceable anyway. One app can just create its own wallet storage implementation and encrypt the records with a app private key. I believe libraries should offer an open API that enables innovation and should not force apps to do stuff in one way.

gudkov (Tue, 29 May 2018 11:06:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=vChShvhL8AwNz3SWZ) @AxelNennker https://github.com/hyperledger/indy-hipe

gudkov (Tue, 29 May 2018 11:09:10 GMT):
I understand these points, but i suggest to consider 2 different problems here: 1. Correct code to determine app storage location on Android 2. More general problem of libindy storage customization

gudkov (Tue, 29 May 2018 11:09:59 GMT):
Problem "1" can be much easier to fix and require less alignment

gudkov (Tue, 29 May 2018 11:10:42 GMT):
Problem "2" after this can be reduced in priority and handled in background.

AxelNennker (Tue, 29 May 2018 12:10:47 GMT):
I claim that 1. cannot be fixed because Rust (currently maybe) has not way to call something like getExternalDir. Each device vendor or OEM can implement user directories and applications specific directories as they like. There is no standard home-directory. Android made it harder and harder for applications to share data because bad apps stole the other application's data without permission and user consent. @faisal00813 picked one path but already noted in his code that this needs to be fixed. https://github.com/faisal00813/indy-sdk/blob/android_builds/libindy/src/utils/environment.rs#L14 There are devices where there is no '/sdcard'. I picked another path that works on my SGS7. Having a libindy and then an application using it that works on some devices but not on others is not optimal. I saw that wallet storage was merged. May that can used to provide a standard storage while allowing apps to change it.

gudkov (Tue, 29 May 2018 12:16:37 GMT):
"wallet storage" is different layer abstraction. libindy uses storage to: - store pool configurations (genesis files and etc) - store pool cache - store wallet configurations wallet storage allows you for example to store wallet data in MySQL, but configuration will be stored in regular place.

AxelNennker (Tue, 29 May 2018 12:47:31 GMT):
@gudkov regarding wallet runtime configuration. Do you have a pointer to its documentation? I saw it as a parameter but no info about what's in the json.

AxelNennker (Tue, 29 May 2018 12:47:31 GMT):
@gudkov regarding wallet runtime configuration. Do you have point to its documentation? I saw it as a parameter but no info about what's in the json.

AxelNennker (Tue, 29 May 2018 12:47:31 GMT):
@gudkov regarding wallet runtime configuration. Do you have pointer to its documentation? I saw it as a parameter but no info about what's in the json.

gudkov (Tue, 29 May 2018 13:24:33 GMT):
For "default storage" there are no any keys. For 3d party storages you need to look to storage documentation. We will add corresponded note to API docs.

sklump (Tue, 29 May 2018 13:33:42 GMT):
@Artemkaaas @gudkov *Re: non-revocation interval in proof requests* I had assumed that *from* & *to* in a proof request meant that the credential was not revoked between these times. But if I submit a proof request with both *from* and *to* later than the revocation time, its verification comes back *False*. Perhaps the non-revocation interval means to prove that the credential was not in a revoked state at any point between the two times? If so, *from* is meaningless until credential recovery becomes a feature? tl;dr: I don't understand what "from" means. Could someone please advise?

gudkov (Tue, 29 May 2018 13:37:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=zTgGrWpYA88nDTCos) @sklump Non-revocation proof is made for specific moment. Prover can select any moment from this interval. The main reason is ability for prover to use cached wittnes value.

sklump (Tue, 29 May 2018 13:43:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RScCnsnwfwRqSxALh) @gudkov Then, if the revocation occurs inside the interval, then the prover's choice of timestamp changes the verification value of the proof. This reduces the information value of a proof, because there could be another one, a second later, on the same proof request, verifying to a different truth value. I'm trying to understand the design intent here and drawing a blank. If there is a document outlining, for verifiers and provers, the semantics of non-revocation intervals and timestamps within proof_request, requested_credentials, revoc_regs_json structures, I would appreciate a link?

AxelNennker (Tue, 29 May 2018 13:46:26 GMT):
Note to self: if you get a "undefined reference to `crypto_pwhash'" then the version of libsodium is older than 1.0.9

gudkov (Tue, 29 May 2018 14:39:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=pMFA7NHeKQTfm7q8v) @sklump > This reduces the information value of a proof, because there could be another one, a second later, on the same proof request, verifying to a different truth value. If it is critical for your application you can use point instead of interval. The main problem here is that generation of proof for "specific" moment is a expensive operation as it can cause re-calculation of wittness from scratch. Incremental witness calculation is cheap, but if verifier requests the point that is older than prover cached value it can require significant math. The main use case is provide the proof that was valid for this morning (we have from, but don't have to).

sklump (Tue, 29 May 2018 14:46:22 GMT):
@gudkov , does the witness value depend on the credential, or on the entire revocation registry? Is it possible at time _t_ to have a witness value for one credential issued against the revocation registry but not for another issued against the same revocation registry? My understanding _(possibly wrong)_ is that the witness depends on the credential, and so any particular cached witness value was not likely to be useful in general. If there are (say) 5000 credentials issued against a revocation registry, holding the states for all of them in cache through any given moment is not feasible for us _(because our prover and verifier agents are stopping and starting all the time -- and if we need a database to keep track of state, that's a counterargument against using a distributed ledger in the first place)_. I'm mulling over how I can use the update instead of the create -- all efforts to this end have failed so far.

sklump (Tue, 29 May 2018 14:46:22 GMT):
@gudkov , does the witness value depend on the credential, or on the entire revocation registry? Is it possible at time _t_ to have a witness value for one credential issued against the revocation registry but not for another issued against the same revocation registry? My understanding _(possibly wrong)_ is that the witness depends on the credential, and so any particular cached witness value is useful only for future revocation registry state creation regarding that credential. If there are (say) 5000 credentials issued against a revocation registry, holding the states for all of them in cache through any given moment is not feasible for us _(because our prover and verifier agents are stopping and starting all the time -- and if we need a database to keep track of state, that's a counterargument against using a distributed ledger in the first place)_. I'm mulling over how I can use the update instead of the create -- all efforts to this end have failed so far.

sklump (Tue, 29 May 2018 14:46:22 GMT):
@gudkov , does the witness value depend on the credential, or on the entire revocation registry? Is it possible at time _t_ to have a witness value for one credential issued against the revocation registry but not for another issued against the same revocation registry? My understanding _(possibly wrong)_ is that the witness depends on the credential, and so any particular cached witness value is useful only for future revocation registry state creation regarding that credential. If there are (say) 5000 credentials issued against a revocation registry, holding the states for all of them in cache through any given moment is not feasible for us _(because our prover and verifier agents are stopping and starting all the time -- and if we need a database to keep track of state, that's a counterargument against using a distributed ledger in the first place)_.

shsedghi (Tue, 29 May 2018 14:53:44 GMT):
Has joined the channel.

AxelNennker (Tue, 29 May 2018 15:00:36 GMT):
Wouldn't it be better if SQLiteStorageType::create_path were called in https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/services/wallet/storage/default/mod.rs#L754 instead of wallet_path?

SergeyBrazhnik (Tue, 29 May 2018 16:02:09 GMT):
Has joined the channel.

SergeyBrazhnik (Tue, 29 May 2018 16:41:24 GMT):
@gudkov Totally agree with @AxelNennker about Android issue (in iOS will be the same) connected to ``` // TODO: FIXME: Provide better handling for the unknown home path case!!! let mut path = env::home_dir().unwrap_or(PathBuf::from("/home/indy")); ``` Most of libraries that used to work with blockchain technology and provide functionality to create wallets gives ability to store wallets in folders that developers want. You can take a look at web3swift or web3j. There is no other way to provide compatibility to many vendors (cause every vendor creates his own file structure ) except to made small changes in Wallet class and provide additional parametr to point path where to store.

SergeyBrazhnik (Tue, 29 May 2018 16:58:22 GMT):
One more (IMHO more suitable way) is to provide direct access to EnvironmentUtils.rs class

SergeyBrazhnik (Tue, 29 May 2018 16:59:03 GMT):
This way developer can configure storage path by his own.

burdettadam (Tue, 29 May 2018 19:15:31 GMT):
Has joined the channel.

stanleyc-trustscience (Tue, 29 May 2018 22:00:59 GMT):
Hi guys, for this method, how do we specify where to store the wallet? `await Wallet.CreateWalletAsync(poolName, "wallet", null, null, null);`

vd30992 (Wed, 30 May 2018 04:41:13 GMT):
Has joined the channel.

vd30992 (Wed, 30 May 2018 06:45:05 GMT):
Hello everyone, wasted my much time on executing this (https://github.com/hyperledger/indy-node/blob/master/getting-started.md) example on deprecated cli version. Now working on new cli version (https://github.com/hyperledger/indy-sdk/tree/master/cli) but here Unable to run above example because commands are changed. Anyone please guide me that How to run ALICE example using new cli. Thanks for any help :-)

AxelNennker (Wed, 30 May 2018 07:29:38 GMT):
@vd30992 last time I tried the examples hitting 'tab' showed the possible next parameters which allowed me to guess what makes sense in each step.

vd30992 (Wed, 30 May 2018 08:15:29 GMT):
@AxelNennker On new cli on old one? Because on old cli, its showing, but not showing on new one. Thanks for reply.

AxelNennker (Wed, 30 May 2018 08:38:50 GMT):
@vd30992 that was the previous cli but that was different then to the getting-started.md as well and the tab-trick worked at that time.

AxelNennker (Wed, 30 May 2018 08:41:40 GMT):
I moved my doc on how to get libindy and its dependencies for Android to a new branch in my fork of indy-sdk. Please use this new link https://github.com/AxelNennker/indy-sdk/blob/android_builds/doc/android-build.md . Also refer to @faisal00813 PR. YMMMV

vd30992 (Wed, 30 May 2018 09:01:18 GMT):
@AxelNennker Thanks very much.

MaxenceAdnot (Wed, 30 May 2018 12:35:18 GMT):
Has joined the channel.

MaxenceAdnot (Wed, 30 May 2018 12:44:51 GMT):
Hi, I'm trying to run the getting started code and i got the following error `IndyError: ErrorCode.CommonInvalidParam6`on the line await wallet.create_wallet(pool_name, wallet_name, None, None, None)

MaxenceAdnot (Wed, 30 May 2018 12:44:51 GMT):
Hi, I'm trying to run the getting started code and i got the following error `IndyError: ErrorCode.CommonInvalidParam6`on the line ` await wallet.create_wallet(pool_name, steward_wallet_name, None, None, None)`

MaxenceAdnot (Wed, 30 May 2018 12:44:51 GMT):
Hi, I'm trying to run the getting started code and i got the following error `IndyError: ErrorCode.CommonInvalidParam6`on the line `await wallet.create_wallet(pool_name, steward_wallet_name, None, None, None)`

MaxenceAdnot (Wed, 30 May 2018 12:45:22 GMT):
any idea ?

gudkov (Wed, 30 May 2018 13:35:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=GBkq8SCxmaKc4DitJ) @stanleyc-trustscience Default wallet storage doesn't provide the way to configure placement of the wallet file.

Jiropole (Wed, 30 May 2018 18:27:20 GMT):
Has joined the channel.

AxelNennker (Wed, 30 May 2018 18:48:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=eZ4DeZ44n4caPFcfA) @MaxenceAdnot That would be raised here: https://github.com/hyperledger/indy-sdk/blob/b3dc4a878d5bf2e6df98e5a2d0847384a585f2e7/libindy/src/api/wallet.rs#L183 , I think.

Steve-Boyd (Thu, 31 May 2018 01:26:21 GMT):
Hi channel. I'm trying to run the Jypter Notebook from the GitHub sample but getting an error `'_xsrf' argument missing from POST`. Anyone have any suggestions?

dbluhm (Thu, 31 May 2018 01:48:05 GMT):
@mboyd is this what you were working on? ^^

mboyd (Thu, 31 May 2018 01:51:04 GMT):
@Steve-Boyd We have an open ticket for errors with the jupyter guide here: https://jira.hyperledger.org/browse/IS-673. It would be good if you could add a comment describing in more detail the error you are facing. It might be the same error.

Steve-Boyd (Thu, 31 May 2018 01:54:34 GMT):
Good to know, I thought maybe I messed up the install. I'm new to Jypter, is there a way to see the console or step through the code? all im getting is the `_xsrf` error at the top.

Steve-Boyd (Thu, 31 May 2018 01:54:45 GMT):
I should probably just RTM..

Steve-Boyd (Thu, 31 May 2018 02:00:47 GMT):
this test fails: ```---- ledger_demo_works stdout ---- thread 'ledger_demo_works' panicked at 'called `Result::unwrap()` on an `Err` value: Timeout', libcore/result.rs:916:5 note: Run with `RUST_BACKTRACE=1` for a backtrace.```

K.Amine (Thu, 31 May 2018 02:47:10 GMT):
Has joined the channel.

K.Amine (Thu, 31 May 2018 02:47:24 GMT):
Hi everyone ! I am currently working with Hyperledger and Indy-sdk infrastructure for my MSc thesis project I have some trouble to install and test the getting-started fellowing this tutorial : https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/run-getting-started.md however I got stuck with an unknown error

K.Amine (Thu, 31 May 2018 02:47:34 GMT):

Capture d’écran 2018-05-30 à 20.42.26.png

K.Amine (Thu, 31 May 2018 02:47:48 GMT):
I've install Rust and rustup (including cargo), I've also succesfully build Indy SDK fellowing tutorials on github I am using Mac OS (High sierra)

Steve-Boyd (Thu, 31 May 2018 02:55:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9iaSRiuBts8xfLxip) @K.Amine I think that error code usually means `sudo` is needed

K.Amine (Thu, 31 May 2018 02:56:06 GMT):
I have exactly same error using the command : "sudo docker-compose up"

K.Amine (Thu, 31 May 2018 02:56:39 GMT):
indy-client-rust-test_1 | error: failed to open: /home/indy/indy-client-rust/target/debug/.cargo-lock indy-client-rust-test_1 | indy-client-rust-test_1 | Caused by: indy-client-rust-test_1 | Permission denied (os error 13) libindy_indy-client-rust-test_1 exited with code 101 macbook-pro-de-amine:libindy Amine$

K.Amine (Thu, 31 May 2018 02:57:12 GMT):
it seems to have something to do with docker permission on mac

K.Amine (Thu, 31 May 2018 02:57:26 GMT):
but I can't figure out how to fix it

K.Amine (Thu, 31 May 2018 03:03:45 GMT):
or maybe the access right in the docker container, but I'm not so familliar with it

dbluhm (Thu, 31 May 2018 03:21:51 GMT):
Welcome to the Indy community, @K.Amine! It's awesome to see indy-sdk being used in a thesis. Unfortunately, I can't reproduce your error from Fedora 28. @ryanwest6 have you encountered this before by chance? ( @ryanwest6 is on the Sovrin team and has done a lot of work tackling incompatibilities related to macOS) If nothing else, you may be able to proceed with the getting started guide by manually building libindy (https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md) and then directly running the getting started guide from the samples/python directory. Alternatively, installing a virtual machine running Ubuntu 16.04 and then installing libindy from the available packages.

K.Amine (Thu, 31 May 2018 03:26:54 GMT):
Thank you for you quick answer @dbluhm ! i built libindy manually exactly using this : https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md However at the and it ask to set up port mapping between docker and local host

K.Amine (Thu, 31 May 2018 03:27:48 GMT):
but I got a bit confused (I am very new wit sovrin to be honest haha)

dbluhm (Thu, 31 May 2018 03:30:42 GMT):
@K.Amine no problem! There is definitely a learning curve lol. So the docker port mapping is referring to this section of the main readme: https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker I'd try running these two commands: ``` docker build -f ci/indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9708:9701-9708 indy_pool ``` Then if that doesn't work, try: ``` docker network create --subnet 10.0.0.0/8 indy_pool_network docker build --build-arg pool_ip=10.0.0.2 -f ci/indy-pool.dockerfile -t indy_pool . docker run -d --ip="10.0.0.2" --net=indy_pool_network indy_pool ```

dbluhm (Thu, 31 May 2018 03:30:42 GMT):
@K.Amine no problem! There is definitely a learning curve lol. So the docker port mapping is referring to this section of the main readme: https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker I'd try running these two commands: ```docker build -f ci/indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9708:9701-9708 indy_pool ``` Then if that doesn't work, try: ```docker network create --subnet 10.0.0.0/8 indy_pool_network docker build --build-arg pool_ip=10.0.0.2 -f ci/indy-pool.dockerfile -t indy_pool . docker run -d --ip="10.0.0.2" --net=indy_pool_network indy_pool ```

K.Amine (Thu, 31 May 2018 03:31:56 GMT):
For the moment what I need to do basically is to take the getting-stated.py as a code base and modify it in order to add nodes from a .csv users and organisations datasets

K.Amine (Thu, 31 May 2018 03:32:41 GMT):
then it could be interesting to simulate interactions between users/organisations on the ledge to get a dataset of claims

K.Amine (Thu, 31 May 2018 03:33:13 GMT):
but I still have some troubles to set everything up haha

dbluhm (Thu, 31 May 2018 03:45:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=vD5Yuf7AvL6nbPCyd) @K.Amine PM'ed you :slight_smile:

K.Amine (Thu, 31 May 2018 03:55:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=F8fSyLZdsHDQFxrqb) @dbluhm Thanks ! using the first 2 commands fixed my problem !

tusharg (Thu, 31 May 2018 04:25:59 GMT):
Hi, is there any way to examine the ledger as it grows? It may not be plaintext as it is just for demonstration purposes..

mdapps (Thu, 31 May 2018 07:58:48 GMT):
Has joined the channel.

nud3l (Thu, 31 May 2018 09:03:03 GMT):
Has joined the channel.

gudkov (Thu, 31 May 2018 10:00:47 GMT):
@AxelNennker @lodo1995 @faisal00813 What if we just add INDY_HOME env variable that will be checked first in EnvironmentUtils::indy_home_path. It can solve Android problem without big expenses for introducing new API and all wrappers update. API for configuration is also good idea, but it will require more time to be aligned and implemented.

Darrylglenn (Thu, 31 May 2018 13:47:06 GMT):
Has joined the channel.

swcurran (Thu, 31 May 2018 14:41:27 GMT):
@tusharg - the we (BC Gov) have a ledger viewer. Code is here if you want to adapt/use it - https://github.com/bcgov/von-network - the server directory. To see a running example, you can look here - http://159.89.115.24/

swcurran (Thu, 31 May 2018 14:42:33 GMT):
Clicking "Domain (pretty)" shows the JSON on the ledger. It's not a view of the blocks, but of the transactions on the ledger. Genesis transactions, DIDs, Schema and CredDefs.

K.Amine (Thu, 31 May 2018 17:19:40 GMT):
Hi everyone, I have a bug when running the command : 'docker-compose up' according to this tutorial : https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/run-getting-started.md

K.Amine (Thu, 31 May 2018 17:19:53 GMT):

Capture d’écran 2018-05-31 à 19.11.40.png

K.Amine (Thu, 31 May 2018 17:20:08 GMT):
anyone familiar with this ?

sklump (Thu, 31 May 2018 18:17:00 GMT):
Hi folks, two quick questions about the prover's Master Secret: (1) is it expected that a user has to set the master secret ( *anoncreds.prover_create_master_secret(wallet_handle, secret_label)* ) every time he closes and re-opens the wallet? (2) I understand that the indy community was going to change this term to Link Secret. Please confirm or deny?

sklump (Thu, 31 May 2018 18:17:00 GMT):
Hi folks, two quick questions about the prover's Master Secret: (1) is it expected that a user has to set the master secret ( *anoncreds.prover_create_master_secret(wallet_handle, secret_label)* ) every time he closes and re-opens the wallet (assuming the prover is going to perform an operation needing the master secret)? (2) I understand that the indy community was going to change the term *Master Secret* to *Link Secret*. Please confirm or deny?

mark.hadley (Thu, 31 May 2018 20:38:45 GMT):
For the indy-sdk/libindy/tests/payments.rs in the master branch, is there an example of using the function call `payments::build_payment_req` that does not result in an error, but instead shows a test that is successful?

dbluhm (Thu, 31 May 2018 22:17:13 GMT):
I'm having an issue getting log information from libindy: when I run the getting started guide setting `RUST_LOG=trace` it works but from another python file that uses python3-indy and setting `RUST_LOG=trace`, I get nothing

dbluhm (Thu, 31 May 2018 22:17:13 GMT):
~I'm having an issue getting log information from libindy: when I run the getting started guide setting `RUST_LOG=trace` it works but from another python file that uses python3-indy and setting `RUST_LOG=trace`, I get nothing~ It appears that my python file raising an error before the logger could even log anything, apparently. I now see output.

dbluhm (Thu, 31 May 2018 22:17:13 GMT):
~I'm having an issue getting log information from libindy: when I run the getting started guide setting `RUST_LOG=trace` it works but from another python file that uses python3-indy and setting `RUST_LOG=trace`, I get nothing~ It appears that my python file was raising an error before the logger could even log anything, apparently. I now see output.

mccown (Fri, 01 Jun 2018 01:42:47 GMT):

libindy tests failing

dbluhm (Fri, 01 Jun 2018 02:52:51 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wrdJWkeYnG8Z4HKiC) @mccown Those same tests fail for me

vd30992 (Fri, 01 Jun 2018 07:25:32 GMT):
Hello everyone, anyone know how to create *pool_transactions_genesis* file from $ *pool create sandbox gen_txn_file=/var/lib/indy/sandbox/pool_transactions_genesis* this command? I tried to find location *"/var/lib/indy/sandbox/pool_transactions_genesis*" but only blank indy folder found. Thank you very much for any suggestions.

AxelNennker (Fri, 01 Jun 2018 08:13:02 GMT):
There is a 404 in https://github.com/hyperledger/indy-sdk/blob/master/cli/README.md to https://github.com/hyperledger/indy-sdk/blob/master/doc/cli-design.md which does not exist (anymore)

AxelNennker (Fri, 01 Jun 2018 08:25:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ZtMP3ctQErCMZ2TDf) @gudkov INDY_HOME as a new env var is doable. A developer could set the var in their mobile app and libindy/src/utils/environment.rs would read it. To use this scheme in the java unit test is not really possible because I would have to change every test setup which would make that code Android-specific https://developer.android.com/reference/android/system/Os#setenv(java.lang.String,%20java.lang.String,%20boolean) Also global variables are generally a bad thing and should be avoided. Using more than one wallet location in the mobile app would be impossible.

sklump (Fri, 01 Jun 2018 11:12:39 GMT):
With *RUST_LOG=trace*, I'm trying to find where this lives in the code base: ``` TRACE|indy_crypto::cl::issuer |/home/sklump/.cargo/registry/src/github.com-1ecc6299db9ec823/indy-crypto-0.4.1/src/cl/issuer.rs:797 | Issuer::_sign_primary_credential: >>> ... ``` @gudkov, where do I find the source that generated this log? There are two issuer.rs files in the distibution, none of which have as many as 797 lines -- puzzling. Thanks in advance.

gudkov (Fri, 01 Jun 2018 12:21:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jSzfZZT7GCZkv2Kc7) @sklump https://github.com/hyperledger/indy-crypto

gudkov (Fri, 01 Jun 2018 12:22:14 GMT):
https://github.com/hyperledger/indy-crypto/blob/master/libindy-crypto/src/cl/issuer.rs

sklump (Fri, 01 Jun 2018 12:32:19 GMT):
On updating to the current (1.4.0-dev-543) master, when on line: ``` await pool.create_pool_ledger_config(self.name, json.dumps({'genesis_txn': ...})) ``` the execution fails with ``` ../../.local/share/virtualenvs/sklump-Vm_I80wM/lib/python3.5/site-packages/indy/pool.py:38: in create_pool_ledger_config create_pool_ledger_config.cb) ../../.local/share/virtualenvs/sklump-Vm_I80wM/lib/python3.5/site-packages/indy/libindy.py:24: in do_call err = getattr(_cdll(), name)(command_handle, ../../.local/share/virtualenvs/sklump-Vm_I80wM/lib/python3.5/site-packages/indy/libindy.py:90: in _cdll _cdll.cdll = _load_cdll() ../../.local/share/virtualenvs/sklump-Vm_I80wM/lib/python3.5/site-packages/indy/libindy.py:121: in _load_cdll raise e ../../.local/share/virtualenvs/sklump-Vm_I80wM/lib/python3.5/site-packages/indy/libindy.py:116: in _load_cdll res = CDLL(libindy_name) _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ self = <[RecursionError("maximum recursion depth exceeded") raised in repr()] CDLL object at 0x7fa43e6ed828> name = 'libindy.so', mode = 0, handle = None, use_errno = False, use_last_error = False def __init__(self, name, mode=DEFAULT_MODE, handle=None, use_errno=False, use_last_error=False): self._name = name flags = self._func_flags_ if use_errno: flags |= _FUNCFLAG_USE_ERRNO if use_last_error: flags |= _FUNCFLAG_USE_LASTERROR class _FuncPtr(_CFuncPtr): _flags_ = flags _restype_ = self._func_restype_ self._FuncPtr = _FuncPtr if handle is None: > self._handle = _dlopen(self._name, mode) E OSError: /usr/lib/libindy.so: undefined symbol: crypto_pwhash ``` `[RecursionError("maximum recursion depth exceeded") raised in repr()` looks to me like maybe repr() refers to itself, in some new code? I've tride updating libsodium to latest stable, and it makes no difference. Has anyone been here and found a way forward?

gudkov (Fri, 01 Jun 2018 13:06:23 GMT):
> OSError: /usr/lib/libindy.so: undefined symbol: crypto_pwhash On what OS are you?

sklump (Fri, 01 Jun 2018 13:06:52 GMT):
ubuntu 16.04

sklump (Fri, 01 Jun 2018 13:07:25 GMT):
libsodium-dev:amd64 (1.0.8-5)

sklump (Fri, 01 Jun 2018 13:07:53 GMT):
(I am looking for a more recent one, but so far 1.0.11 appears only for ubuntu 17)

gudkov (Fri, 01 Jun 2018 13:08:33 GMT):
Are building it yourself?

gudkov (Fri, 01 Jun 2018 13:08:33 GMT):
Are you building it yourself?

sklump (Fri, 01 Jun 2018 13:09:04 GMT):
Not so far, only with sudo apt install

gudkov (Fri, 01 Jun 2018 13:09:24 GMT):
It is strange as it links statically with libsodium now

sklump (Fri, 01 Jun 2018 13:10:46 GMT):
Do you have a link to instructions to get the source and try to build on ubuntu? I'm grasping at straws here.

sklump (Fri, 01 Jun 2018 13:24:54 GMT):
This sequence: ``` $ sudo apt purge libsodium-dev $ sudo apt-get install -y software-properties-common $ sudo bash -c "LC_ALL=C.UTF-8 add-apt-repository -y ppa:ondrej/php" $ sudo apt-get update $ sudo apt-get install -y libsodium-dev ``` picks up libsodium-dev 23, but still results in `undefined symbol: crypto_pwhash` as above.

sklump (Fri, 01 Jun 2018 13:42:00 GMT):
After the installation from ppa:ondrej/php above, file */usr/local/include/sodium/crypto_pwhash.h* exists and */usr/local/lib/* lists as follows: ``` -rw-r--r-- 1 root root 3164932 Jun 1 07:41 libsodium.a -rwxr-xr-x 1 root root 943 Jun 1 07:41 libsodium.la lrwxrwxrwx 1 root root 19 Jun 1 07:41 libsodium.so -> libsodium.so.23.1.0 lrwxrwxrwx 1 root root 19 Jun 1 07:41 libsodium.so.23 -> libsodium.so.23.1.0 -rwxr-xr-x 1 root root 1978752 Jun 1 07:41 libsodium.so.23.1.0 ... ``` Might there be a last step I need to wire up so indy-sdk can find crypto_pwhash header?

sklump (Fri, 01 Jun 2018 13:42:00 GMT):
File */usr/local/include/sodium/crypto_pwhash.h* exists and */usr/local/lib/* lists as follows: ``` -rw-r--r-- 1 root root 3164932 Jun 1 07:41 libsodium.a -rwxr-xr-x 1 root root 943 Jun 1 07:41 libsodium.la lrwxrwxrwx 1 root root 19 Jun 1 07:41 libsodium.so -> libsodium.so.23.1.0 lrwxrwxrwx 1 root root 19 Jun 1 07:41 libsodium.so.23 -> libsodium.so.23.1.0 -rwxr-xr-x 1 root root 1978752 Jun 1 07:41 libsodium.so.23.1.0 ... ``` Might there be a last step I need to wire up so indy-sdk can find crypto_pwhash header?

sklump (Fri, 01 Jun 2018 13:53:13 GMT):
... I also see that my OS has retained libsodium.so.23 from January in /usr/lib/x86_64-linux-gnu: ``` sklump@ubu106:/usr/lib/x86_64-linux-gnu$ ls -l libso* -rw-r--r-- 1 root root 581268 Jan 3 16:28 libsodium.a lrwxrwxrwx 1 root root 19 Jan 3 16:28 libsodium.so -> libsodium.so.23.1.0 lrwxrwxrwx 1 root root 19 Feb 6 2016 libsodium.so.18 -> libsodium.so.18.0.1 -rw-r--r-- 1 root root 384856 Feb 6 2016 libsodium.so.18.0.1 lrwxrwxrwx 1 root root 19 Jan 3 16:28 libsodium.so.23 -> libsodium.so.23.1.0 -rw-r--r-- 1 root root 334536 Jan 3 16:28 libsodium.so.23.1.0 ``` How do I discover where indy-sdk is looking for these libraries?

SteveGoob (Fri, 01 Jun 2018 18:49:44 GMT):
@gudkov, I noticed that the CI on my pr failed with 'The build of this commit was aborted'. I'm told that you could help me fix this and 'retrigger' the CI checks on the pr so that it can go through. I would like to get it through as soon as I can because people have already started asking me for the resources in there.

SteveGoob (Fri, 01 Jun 2018 18:49:52 GMT):
here's the pr: https://github.com/hyperledger/indy-sdk/pull/747

json (Fri, 01 Jun 2018 19:07:44 GMT):
Has joined the channel.

json (Fri, 01 Jun 2018 19:11:25 GMT):
hi guys, trying to run the python tutorial here (https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/write-did-and-query-verkey/python/README.md). Getting a timeout error when it tries to connect to the pool: 2. Open ledger and get handle ←[0m _indy_loop_callback: Function returned error 307 Error occurred: ErrorCode.PoolLedgerTimeout

json (Fri, 01 Jun 2018 19:12:03 GMT):
I've built and started the docker test pool as per the instructions https://github.com/hyperledger/indy-sdk/blob/master/README.md#how-to-start-local-nodes-pool-with-docker.

sklump (Fri, 01 Jun 2018 19:12:32 GMT):
```$ export TEST_POOL_IP=10.0.0.2```

json (Fri, 01 Jun 2018 19:16:45 GMT):
hmm.. unfortunately i'm on win7. tried adding that to the env variables but no luck

json (Fri, 01 Jun 2018 19:16:54 GMT):
might be easier for me to run it on a ubuntu vm?

sklump (Fri, 01 Jun 2018 19:19:18 GMT):
Sorry, I don't do Windows

json (Fri, 01 Jun 2018 19:43:32 GMT):
fair enough. thanks for your help!

AxelNennker (Mon, 04 Jun 2018 08:07:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=a3FPjKzkKoGj7NTgE) fixed 404 https://github.com/hyperledger/indy-sdk/pull/831

gudkov (Mon, 04 Jun 2018 08:24:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=MqKEXnYNw7BedK2i7) @json 10 Here is documentation about running test pool on different OS https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker On windows usually docker port mapping is used and you need to use 127.0.0.1 as addresses of nodes.

DeltaForce (Mon, 04 Jun 2018 10:42:34 GMT):
Has joined the channel.

DeltaForce (Mon, 04 Jun 2018 10:50:10 GMT):
Hi, I have a similar error reported here http://forum.sovrin.org/t/dlopen-linbindy-dylib-6-image-not-fund/633/2 What should I do to fix it ?

qrz (Mon, 04 Jun 2018 12:42:41 GMT):
Has joined the channel.

qrz (Mon, 04 Jun 2018 12:47:26 GMT):
Hi all, I'm not sure this is the right channel, but I am playing around with indy-cli (stable stream) and getting some error while issuing a "ledger cred-def" command. Better ask here or in ml?

gudkov (Mon, 04 Jun 2018 13:39:37 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=KHc6XW9hp9wiNL4iG) @DeltaForce python wrapper can't find native libindy? Do you have one? On MAC you need to build it by yourself as there is no binary package.

gudkov (Mon, 04 Jun 2018 13:41:00 GMT):
Corresponded instruction starts here https://github.com/hyperledger/indy-sdk#macos

gudkov (Mon, 04 Jun 2018 13:41:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=A36ktdns9m2vLNtLd) @qrz It is ok to ask here

nud3l (Mon, 04 Jun 2018 13:45:55 GMT):
Hi all, I am trying to get the SDk up and running without success so far. Info: `Ubuntu 16.04 Docker 18.03 Python 3.5.2 ` 1) I installed the SDK from the sources (master) branch. `sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 68DB5E88 sudo add-apt-repository "deb https://repo.sovrin.org/sdk/deb xenial master" sudo apt-get update sudo apt-get install -y libindy` 2) I started the docker container with: `docker network create --subnet 10.0.0.0/8 indy_pool_network docker build --build-arg pool_ip=10.0.0.2 -f ci/indy-pool.dockerfile -t indy_pool . docker run -d --ip="10.0.0.2" --net=indy_pool_network indy_pool` 3) I created a venv and installed the python wrapper: `pip install python3-indy asyncio` 4) I tried running the first how-to guide: https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/write-did-and-query-verkey/python/write_did_and_query_verkey.py It returns me the following error: `1. Creates a new local pool ledger configuration that is used later when connecting to ledger. _indy_loop_callback: Function returned error 114 Error occurred: ErrorCode.CommonIOError `

nud3l (Mon, 04 Jun 2018 13:45:55 GMT):
Hi all, I am trying to get the SDk up and running without success so far. Info: Ubuntu 16.04 Docker 18.03 Python 3.5.2 1) I installed the SDK from the sources (master) branch. ``` sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 68DB5E88 sudo add-apt-repository "deb https://repo.sovrin.org/sdk/deb xenial master" sudo apt-get update sudo apt-get install -y libindy ``` 2) I started the docker container with: ``` docker network create --subnet 10.0.0.0/8 indy_pool_network docker build --build-arg pool_ip=10.0.0.2 -f ci/indy-pool.dockerfile -t indy_pool . docker run -d --ip="10.0.0.2" --net=indy_pool_network indy_pool ``` 3) I created a venv and installed the python wrapper: `pip install python3-indy asyncio` 4) I tried running the first how-to guide: https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/write-did-and-query-verkey/python/write_did_and_query_verkey.py It returns me the following error: ``` 1. Creates a new local pool ledger configuration that is used later when connecting to ledger. _indy_loop_callback: Function returned error 114 Error occurred: ErrorCode.CommonIOError ```

AxelNennker (Mon, 04 Jun 2018 13:55:13 GMT):
libindy only returns an error code but not further details on what went wrong. So the developer of an app using libindy has no way to see a 'file not found ospath' or a 'connection timeout to 10.0.0.5:9777'. Could we return a json serialization of the error '{code:120, cause:"connection timeout to 10.0.0.5:9777"}'

qrz (Mon, 04 Jun 2018 13:55:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kPaHgptj58KvTtX5k) @gudkov Ok great!

qrz (Mon, 04 Jun 2018 13:59:05 GMT):
I have the following issue: I generated a schema with `indy> ledger schema name=test version=1.0 attr_names=name`

gudkov (Mon, 04 Jun 2018 14:01:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=o5ro94aDcB5HLtYf5) @AxelNennker There is a ticket about this in Jira. But for development purposes you have workaraund. Just enable logging. Set env variable RUST_LOG=indy=trace and you will this string in logs

qrz (Mon, 04 Jun 2018 14:01:44 GMT):
the schema gets correctly written to the ledger, that is `indy> ledger get-schema did=V4SGRU86Z58d6TV7PBUe6f name=test version=1.0` retrieves the schema as expected however, if I now try to write a cred-def to the ledger with `indy> ledger cred-def schema_id=15 signature_type=CL primary={"name":"test"}` I get an error: `Invalid format of command params. Please check format of posted JSONs, Keys, DIDs and etc...`

qrz (Mon, 04 Jun 2018 14:02:43 GMT):
(the value of `schema_id` is the sequence number of the schema as retrieved from the ledger)

smithbk (Mon, 04 Jun 2018 14:06:06 GMT):
I have the following function: ``` async def async_open_pool(self, cfg: dict): if self.handle: return # Create the pool, but ignore the error if it already exists try: logger.info("Create pool ledger config for {}".format(cfg)) await pool.create_pool_ledger_config(self.name, json.dumps(cfg)) except IndyError as e: if e.error_code == ErrorCode.PoolLedgerConfigAlreadyExistsError: logger.debug( 'Pool ledger config for {} already exists'.format(self.name)) else: raise e # Open the pool. This attempts to connect to a steward. self.handle = await pool.open_pool_ledger(self.name, json.dumps(cfg))``` And am getting the following error: ```DEBUG:root:Pool ledger config for agents_pool already exists DEBUG:indy.pool:open_pool_ledger: >>> config_name: 'agents_pool', config: '{"genesis_txn": "/home/indy/sandbox/pool_transactions_genesis"}' DEBUG:indy.pool:open_pool_ledger: Creating callback DEBUG:indy.libindy:create_cb: >>> cb_type: .CFunctionType'> DEBUG:indy.libindy:create_cb: <<< res: DEBUG:indy.libindy:do_call: >>> name: indy_open_pool_ledger, args: (c_char_p(139853035195424), c_char_p(139853034831792), ) DEBUG:indy.libindy:do_call: Function indy_open_pool_ledger returned err: 0 DEBUG:indy.libindy:do_call: <<< DEBUG:indy.libindy:_indy_callback: >>> command_handle: 1, err 112, args: (0,) DEBUG:indy.libindy:_indy_callback: <<< DEBUG:indy.libindy:_indy_loop_callback: >>> command_handle: 1, err 112, args: (0,) WARNING:indy.libindy:_indy_loop_callback: Function returned error 112 DEBUG:indy.libindy:_indy_loop_callback <<< Traceback (most recent call last): File "./api.py", line 55, in pool = NodePool("agents_pool") File "/home/indy/bin/util.py", line 18, in __call__ Singleton, cls).__call__(*args, **kwargs) File "/home/indy/bin/node_pool.py", line 28, in __init__ self.async_init(pool_file=pool_file, cfg=cfg)) File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step result = coro.throw(exc) File "/home/indy/bin/node_pool.py", line 45, in async_init await self.async_open_pool(cfg) File "/home/indy/bin/node_pool.py", line 63, in async_open_pool self.handle = await pool.open_pool_ledger(self.name, json.dumps(cfg)) File "/usr/local/lib/python3.5/dist-packages/indy/pool.py", line 82, in open_pool_ledger open_pool_ledger.cb) File "/usr/lib/python3.5/asyncio/futures.py", line 361, in __iter__ yield self # This tells Task to wait for completion. File "/usr/lib/python3.5/asyncio/tasks.py", line 296, in _wakeup future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception indy.error.IndyError: ErrorCode.CommonInvalidState``` Any ideas what the issue might be?

DeltaForce (Mon, 04 Jun 2018 14:06:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=zNJ5FiZbk6LWEXCzm) @gudkov Thank you

AxelNennker (Mon, 04 Jun 2018 14:09:10 GMT):
@gudkov one of these or this in general? https://jira.hyperledger.org/browse/INDY-778 I think none of them covers improving libindy api

smithbk (Mon, 04 Jun 2018 14:09:35 GMT):
I have the following function: ``` async def async_open_pool(self, cfg: dict): if self.handle: return # Create the pool, but ignore the error if it already exists try: logger.info("Create pool ledger config for {}".format(cfg)) await pool.create_pool_ledger_config(self.name, json.dumps(cfg)) except IndyError as e: if e.error_code == ErrorCode.PoolLedgerConfigAlreadyExistsError: logger.debug( 'Pool ledger config for {} already exists'.format(self.name)) else: raise e # Open the pool. This attempts to connect to a steward. self.handle = await pool.open_pool_ledger(self.name, json.dumps(cfg))```

smithbk (Mon, 04 Jun 2018 14:09:45 GMT):
And am getting the following error: ```DEBUG:root:Pool ledger config for agents_pool already exists DEBUG:indy.pool:open_pool_ledger: >>> config_name: 'agents_pool', config: '{"genesis_txn": "/home/indy/sandbox/pool_transactions_genesis"}' DEBUG:indy.pool:open_pool_ledger: Creating callback DEBUG:indy.libindy:create_cb: >>> cb_type: .CFunctionType'> DEBUG:indy.libindy:create_cb: <<< res: DEBUG:indy.libindy:do_call: >>> name: indy_open_pool_ledger, args: (c_char_p(139853035195424), c_char_p(139853034831792), ) DEBUG:indy.libindy:do_call: Function indy_open_pool_ledger returned err: 0 DEBUG:indy.libindy:do_call: <<< DEBUG:indy.libindy:_indy_callback: >>> command_handle: 1, err 112, args: (0,) DEBUG:indy.libindy:_indy_callback: <<< DEBUG:indy.libindy:_indy_loop_callback: >>> command_handle: 1, err 112, args: (0,) WARNING:indy.libindy:_indy_loop_callback: Function returned error 112 DEBUG:indy.libindy:_indy_loop_callback <<< Traceback (most recent call last): File "./api.py", line 55, in pool = NodePool("agents_pool") File "/home/indy/bin/util.py", line 18, in __call__ Singleton, cls).__call__(*args, **kwargs) File "/home/indy/bin/node_pool.py", line 28, in __init__ self.async_init(pool_file=pool_file, cfg=cfg)) File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step result = coro.throw(exc) File "/home/indy/bin/node_pool.py", line 45, in async_init await self.async_open_pool(cfg) File "/home/indy/bin/node_pool.py", line 63, in async_open_pool self.handle = await pool.open_pool_ledger(self.name, json.dumps(cfg)) File "/usr/local/lib/python3.5/dist-packages/indy/pool.py", line 82, in open_pool_ledger open_pool_ledger.cb) File "/usr/lib/python3.5/asyncio/futures.py", line 361, in __iter__ yield self # This tells Task to wait for completion. File "/usr/lib/python3.5/asyncio/tasks.py", line 296, in _wakeup future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception indy.error.IndyError: ErrorCode.CommonInvalidState```

smithbk (Mon, 04 Jun 2018 14:09:58 GMT):
Any ideas what the issue might be?

smithbk (Mon, 04 Jun 2018 14:09:58 GMT):
@sklump Thanks, but tried removing and doesn't seem to make a diff

smithbk (Mon, 04 Jun 2018 14:09:58 GMT):
Any ideas what causes this?

sklump (Mon, 04 Jun 2018 14:21:43 GMT):
Residual pool files from a defunct distributed ledger. `rm -rf ~/.indy_client`

smithbk (Mon, 04 Jun 2018 14:25:43 GMT):
@sklump Thanks, but tried removing and doesn't seem to make a diff

gudkov (Mon, 04 Jun 2018 14:28:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=76ZeZjYMLs4PG9uP4) @AxelNennker https://jira.hyperledger.org/browse/IS-511

the_identity_guy (Mon, 04 Jun 2018 14:47:21 GMT):
Hi What does CommonInvalidState(112) mean? I have compiled the latest IndySDK on Mac, added to classpath and trying the Python sample codes to open the pool.. but I get that error.. File "/project/lib/python3.6/site-packages/indy/pool.py", line 83, in open_pool_ledger open_pool_ledger.cb) indy.error.IndyError: ErrorCode.CommonInvalidState

the_identity_guy (Mon, 04 Jun 2018 14:47:21 GMT):
What does CommonInvalidState(112) mean? I have compiled the latest IndySDK on Mac, added to classpath and trying the Python sample codes to open the pool.. but I get that error.. File "/project/lib/python3.6/site-packages/indy/pool.py", line 83, in open_pool_ledger open_pool_ledger.cb) indy.error.IndyError: ErrorCode.CommonInvalidState

the_identity_guy (Mon, 04 Jun 2018 14:47:21 GMT):
What does CommonInvalidState(112) error mean? I have compiled the latest IndySDK on Mac, added to classpath and trying the Python sample codes to open the pool.. but I get that error.. File "/project/lib/python3.6/site-packages/indy/pool.py", line 83, in open_pool_ledger open_pool_ledger.cb) indy.error.IndyError: ErrorCode.CommonInvalidState

the_identity_guy (Mon, 04 Jun 2018 14:47:21 GMT):
What does CommonInvalidState(112) error mean? I have compiled the latest IndySDK on Mac (from Master branch), added to classpath and trying the Python sample codes to open the pool.. but I get that error.. File "/project/lib/python3.6/site-packages/indy/pool.py", line 83, in open_pool_ledger open_pool_ledger.cb) indy.error.IndyError: ErrorCode.CommonInvalidState

the_identity_guy (Mon, 04 Jun 2018 14:47:21 GMT):
The error from LibIndy seem to be something about merkle roots: ` INFO|indy::services::pool | src/services/pool/mod.rs:546 | RemoteNode::recv_msg Node1 {"viewNo":null,"ppSeqNo":null,"txnSeqNo":4,"op":"LEDGER_STATUS","merkleRoot":"DKTaqoxsaDxNwVBhGyqH5W6HRMmQ8viSSeypSKekfuQw","ledgerId":0} TRACE|indy::services::pool | src/services/pool/mod.rs:245 | process_actions - Invalid library state: Ledger merkle tree doesn't acceptable for current tree. ERROR|indy::services::pool | src/services/pool/mod.rs:431 | Pool worker thread finished with error CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree.")) INFO|indy::commands | src/commands/mod.rs:114 | PoolCommand command received INFO|indy::commands::pool | src/commands/pool.rs:67 | OpenAck handle 1, pool_id 2, result Err(CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree."))) ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid library state: Ledger merkle tree doesn't acceptable for current tree. TRACE|indy::api::pool | src/api/pool.rs:104 | indy_open_pool_ledger: pool_handle: 0`

the_identity_guy (Mon, 04 Jun 2018 14:47:21 GMT):
The issue seem to be about merkle roots? INFO|indy::services::pool | src/services/pool/mod.rs:546 | RemoteNode::recv_msg Node1 {"viewNo":null,"ppSeqNo":null,"txnSeqNo":4,"op":"LEDGER_STATUS","merkleRoot":"DKTaqoxsaDxNwVBhGyqH5W6HRMmQ8viSSeypSKekfuQw","ledgerId":0} TRACE|indy::services::pool | src/services/pool/mod.rs:245 | process_actions - Invalid library state: Ledger merkle tree doesn't acceptable for current tree. ERROR|indy::services::pool | src/services/pool/mod.rs:431 | Pool worker thread finished with error CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree.")) INFO|indy::commands | src/commands/mod.rs:114 | PoolCommand command received INFO|indy::commands::pool | src/commands/pool.rs:67 | OpenAck handle 1, pool_id 2, result Err(CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree."))) ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid library state: Ledger merkle tree doesn't acceptable for current tree. TRACE|indy::api::pool | src/api/pool.rs:104 | indy_open_pool_ledger: pool_handle: 0

gudkov (Mon, 04 Jun 2018 14:55:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nhamrgkREsoaLXExf) @the_identity_guy It means that libindy detected invalid state that most probably indicates a bug in libindy. You can enable loggin by settting env var RUST_LOG=indy=trace

gudkov (Mon, 04 Jun 2018 14:55:36 GMT):
And get more information and error description

the_identity_guy (Mon, 04 Jun 2018 15:05:44 GMT):
` INFO|indy::services::pool | src/services/pool/mod.rs:546 | RemoteNode::recv_msg Node1 {"viewNo":null,"ppSeqNo":null,"txnSeqNo":4,"op":"LEDGER_STATUS","merkleRoot":"DKTaqoxsaDxNwVBhGyqH5W6HRMmQ8viSSeypSKekfuQw","ledgerId":0} TRACE|indy::services::pool | src/services/pool/mod.rs:245 | process_actions - Invalid library state: Ledger merkle tree doesn't acceptable for current tree. ERROR|indy::services::pool | src/services/pool/mod.rs:431 | Pool worker thread finished with error CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree.")) INFO|indy::commands | src/commands/mod.rs:114 | PoolCommand command received INFO|indy::commands::pool | src/commands/pool.rs:67 | OpenAck handle 1, pool_id 2, result Err(CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree."))) ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid library state: Ledger merkle tree doesn't acceptable for current tree. TRACE|indy::api::pool | src/api/pool.rs:104 | indy_open_pool_ledger: pool_handle: 0`

the_identity_guy (Mon, 04 Jun 2018 15:05:44 GMT):
``INFO|indy::services::pool | src/services/pool/mod.rs:546 | RemoteNode::recv_msg Node1 {"viewNo":null,"ppSeqNo":null,"txnSeqNo":4,"op":"LEDGER_STATUS","merkleRoot":"DKTaqoxsaDxNwVBhGyqH5W6HRMmQ8viSSeypSKekfuQw","ledgerId":0} TRACE|indy::services::pool | src/services/pool/mod.rs:245 | process_actions - Invalid library state: Ledger merkle tree doesn't acceptable for current tree. ERROR|indy::services::pool | src/services/pool/mod.rs:431 | Pool worker thread finished with error CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree.")) INFO|indy::commands | src/commands/mod.rs:114 | PoolCommand command received INFO|indy::commands::pool | src/commands/pool.rs:67 | OpenAck handle 1, pool_id 2, result Err(CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree."))) ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid library state: Ledger merkle tree doesn't acceptable for current tree. TRACE|indy::api::pool | src/api/pool.rs:104 | indy_open_pool_ledger: pool_handle: 0``

the_identity_guy (Mon, 04 Jun 2018 15:05:44 GMT):
The issue seem to be about merkle roots? ``INFO|indy::services::pool | src/services/pool/mod.rs:546 | RemoteNode::recv_msg Node1 {"viewNo":null,"ppSeqNo":null,"txnSeqNo":4,"op":"LEDGER_STATUS","merkleRoot":"DKTaqoxsaDxNwVBhGyqH5W6HRMmQ8viSSeypSKekfuQw","ledgerId":0} TRACE|indy::services::pool | src/services/pool/mod.rs:245 | process_actions - Invalid library state: Ledger merkle tree doesn't acceptable for current tree. ERROR|indy::services::pool | src/services/pool/mod.rs:431 | Pool worker thread finished with error CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree.")) INFO|indy::commands | src/commands/mod.rs:114 | PoolCommand command received INFO|indy::commands::pool | src/commands/pool.rs:67 | OpenAck handle 1, pool_id 2, result Err(CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree."))) ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid library state: Ledger merkle tree doesn't acceptable for current tree. TRACE|indy::api::pool | src/api/pool.rs:104 | indy_open_pool_ledger: pool_handle: 0``

the_identity_guy (Mon, 04 Jun 2018 15:05:44 GMT):
The issue seem to be about merkle roots? ```INFO|indy::services::pool | src/services/pool/mod.rs:546 | RemoteNode::recv_msg Node1 {"viewNo":null,"ppSeqNo":null,"txnSeqNo":4,"op":"LEDGER_STATUS","merkleRoot":"DKTaqoxsaDxNwVBhGyqH5W6HRMmQ8viSSeypSKekfuQw","ledgerId":0} TRACE|indy::services::pool | src/services/pool/mod.rs:245 | process_actions - Invalid library state: Ledger merkle tree doesn't acceptable for current tree. ERROR|indy::services::pool | src/services/pool/mod.rs:431 | Pool worker thread finished with error CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree.")) INFO|indy::commands | src/commands/mod.rs:114 | PoolCommand command received INFO|indy::commands::pool | src/commands/pool.rs:67 | OpenAck handle 1, pool_id 2, result Err(CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree."))) ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid library state: Ledger merkle tree doesn't acceptable for current tree. TRACE|indy::api::pool | src/api/pool.rs:104 | indy_open_pool_ledger: pool_handle: 0```

sklump (Mon, 04 Jun 2018 15:53:04 GMT):
Looks like your genesis block is from an old revision. Maybe try removing and rebuilding the docker image for indy_pool.

gudkov (Mon, 04 Jun 2018 15:57:33 GMT):
Also it is often caused by inconsistent nodes ip addresses used on pool side and in genesis transactions

the_identity_guy (Mon, 04 Jun 2018 16:12:07 GMT):
@sklump ``` {"data":{"alias":"Node1","blskey":"4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba","client_ip":"10.20.30.201","client_port":9702,"node_ip":"10.20.30.201","node_port":9701,"services":["VALIDATOR"]},"dest":"Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv","identifier":"Th7MpTaRZVRYnPiabds81Y","txnId":"fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62","type":"0"} {"data":{"alias":"Node2","blskey":"37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk","client_ip":"10.20.30.202","client_port":9704,"node_ip":"10.20.30.202","node_port":9703,"services":["VALIDATOR"]},"dest":"8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb","identifier":"EbP4aYNeTHL6q385GuVpRV","txnId":"1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc","type":"0"} {"data":{"alias":"Node3","blskey":"3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5","client_ip":"10.20.30.203","client_port":9706,"node_ip":"10.20.30.203","node_port":9705,"services":["VALIDATOR"]},"dest":"DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya","identifier":"4cU41vWW82ArfxJxHkzXPG","txnId":"7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4","type":"0"} {"data":{"alias":"Node4","blskey":"2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw","client_ip":"10.20.30.204","client_port":9708,"node_ip":"10.20.30.204","node_port":9707,"services":["VALIDATOR"]},"dest":"4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA","identifier":"TWwCRQRZ2ZHMJFn9TzLp7W","txnId":"aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008","type":"0"} ``` this is my genesic config generated on every run .. I have tried running the nodes by using Vagrant and Docker both, The above genesis code is from Vagrant config as the IP addresses show

nud3l (Mon, 04 Jun 2018 17:44:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=S7YjZvTJYyBYyYD7K) Anybody has an idea what is causing the problem?

smithbk (Mon, 04 Jun 2018 18:50:07 GMT):
@sklump @gudkov @the _identity_guy Thanks ... with additional trace enabled, the error is as follows: ```DEBUG:indy.libindy:do_call: Function indy_open_pool_ledger returned err: 0 INFO|indy::commands | src/commands/mod.rs:108 | PoolCommand command received INFO|indy::commands | src/commands/mod.rs:108 | PoolCommand command received INFO|indy::commands::pool | src/commands/pool.rs:67 | OpenAck handle 1, pool_id 2, result Err(CommonError(InvalidState("MerkleTree contains invalid data Syntax(\"missing field `data`\")"))) ERROR|indy::errors::indy | src/errors/indy.rs:68 | Casting error to ErrorCode: Invalid library state: MerkleTree contains invalid data Syntax("missing field `data`")DEBUG:indy.libindy:do_call: <<< ERROR|indy::services::pool | src/services/pool/mod.rs:428 | Pool worker thread finished with error CommonError(InvalidState("MerkleTree contains invalid data Syntax(\"missing field `data`\")")) DEBUG:indy.libindy:_indy_callback: >>> command_handle: 1, err 112, args: (0,) DEBUG:indy.libindy:_indy_callback: <<< DEBUG:indy.libindy:_indy_loop_callback: >>> command_handle: 1, err 112, args: (0,) WARNING:indy.libindy:_indy_loop_callback: Function returned error 112 DEBUG:indy.libindy:_indy_loop_callback <<< Traceback (most recent call last): File "./api.py", line 62, in pool = NodePool("agents_pool") File "/home/indy/bin/util.py", line 18, in __call__ Singleton, cls).__call__(*args, **kwargs) File "/home/indy/bin/node_pool.py", line 28, in __init__ self.async_init(pool_file=pool_file, cfg=cfg)) File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step result = coro.throw(exc) File "/home/indy/bin/node_pool.py", line 45, in async_init await self.async_open_pool(cfg) File "/home/indy/bin/node_pool.py", line 63, in async_open_pool self.handle = await pool.open_pool_ledger(self.name, json.dumps(cfg)) File "/usr/local/lib/python3.5/dist-packages/indy/pool.py", line 82, in open_pool_ledger open_pool_ledger.cb) File "/usr/lib/python3.5/asyncio/futures.py", line 361, in __iter__ yield self # This tells Task to wait for completion. File "/usr/lib/python3.5/asyncio/tasks.py", line 296, in _wakeup future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception indy.error.IndyError: ErrorCode.CommonInvalidState```

smithbk (Mon, 04 Jun 2018 18:50:07 GMT):
@sklump @gudkov Thanks ... with additional trace enabled, the error is as follows: ```DEBUG:indy.libindy:do_call: Function indy_open_pool_ledger returned err: 0 INFO|indy::commands | src/commands/mod.rs:108 | PoolCommand command received INFO|indy::commands | src/commands/mod.rs:108 | PoolCommand command received INFO|indy::commands::pool | src/commands/pool.rs:67 | OpenAck handle 1, pool_id 2, result Err(CommonError(InvalidState("MerkleTree contains invalid data Syntax(\"missing field `data`\")"))) ERROR|indy::errors::indy | src/errors/indy.rs:68 | Casting error to ErrorCode: Invalid library state: MerkleTree contains invalid data Syntax("missing field `data`")DEBUG:indy.libindy:do_call: <<< ERROR|indy::services::pool | src/services/pool/mod.rs:428 | Pool worker thread finished with error CommonError(InvalidState("MerkleTree contains invalid data Syntax(\"missing field `data`\")")) DEBUG:indy.libindy:_indy_callback: >>> command_handle: 1, err 112, args: (0,) DEBUG:indy.libindy:_indy_callback: <<< DEBUG:indy.libindy:_indy_loop_callback: >>> command_handle: 1, err 112, args: (0,) WARNING:indy.libindy:_indy_loop_callback: Function returned error 112 DEBUG:indy.libindy:_indy_loop_callback <<< Traceback (most recent call last): File "./api.py", line 62, in pool = NodePool("agents_pool") File "/home/indy/bin/util.py", line 18, in __call__ Singleton, cls).__call__(*args, **kwargs) File "/home/indy/bin/node_pool.py", line 28, in __init__ self.async_init(pool_file=pool_file, cfg=cfg)) File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step result = coro.throw(exc) File "/home/indy/bin/node_pool.py", line 45, in async_init await self.async_open_pool(cfg) File "/home/indy/bin/node_pool.py", line 63, in async_open_pool self.handle = await pool.open_pool_ledger(self.name, json.dumps(cfg)) File "/usr/local/lib/python3.5/dist-packages/indy/pool.py", line 82, in open_pool_ledger open_pool_ledger.cb) File "/usr/lib/python3.5/asyncio/futures.py", line 361, in __iter__ yield self # This tells Task to wait for completion. File "/usr/lib/python3.5/asyncio/tasks.py", line 296, in _wakeup future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception indy.error.IndyError: ErrorCode.CommonInvalidState```

smithbk (Mon, 04 Jun 2018 18:50:20 GMT):
And here is my genesis transaction: ```{"reqSignature":{},"txn":{"data":{"data":{"alias":"Node1","blskey":"4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba","client_ip":"172.19.0.3","client_port":9712,"node_ip":"172.19.0.3","node_port":9711,"services":["VALIDATOR"]},"dest":"Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv"},"metadata":{"from":"Th7MpTaRZVRYnPiabds81Y"},"type":"0"},"txnMetadata":{"seqNo":1,"txnId":"fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62"},"ver":"1"} {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node2","blskey":"37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk","client_ip":"172.19.0.3","client_port":9714,"node_ip":"172.19.0.3","node_port":9713,"services":["VALIDATOR"]},"dest":"8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb"},"metadata":{"from":"EbP4aYNeTHL6q385GuVpRV"},"type":"0"},"txnMetadata":{"seqNo":2,"txnId":"1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc"},"ver":"1"} {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node3","blskey":"3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5","client_ip":"172.19.0.3","client_port":9716,"node_ip":"172.19.0.3","node_port":9715,"services":["VALIDATOR"]},"dest":"DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya"},"metadata":{"from":"4cU41vWW82ArfxJxHkzXPG"},"type":"0"},"txnMetadata":{"seqNo":3,"txnId":"7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4"},"ver":"1"} {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node4","blskey":"2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw","client_ip":"172.19.0.3","client_port":9718,"node_ip":"172.19.0.3","node_port":9717,"services":["VALIDATOR"]},"dest":"4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA"},"metadata":{"from":"TWwCRQRZ2ZHMJFn9TzLp7W"},"type":"0"},"txnMetadata":{"seqNo":4,"txnId":"aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008"},"ver":"1"}```

smithbk (Mon, 04 Jun 2018 18:51:19 GMT):
The IP address matches that of the container running the node pool

haggs (Mon, 04 Jun 2018 21:31:12 GMT):
Has joined the channel.

BreizhIndy (Tue, 05 Jun 2018 07:47:24 GMT):
Has joined the channel.

gudkov (Tue, 05 Jun 2018 07:48:07 GMT):
@smithbk What libindy version do you use? Seems you need to update it to the latest master.

AxelNennker (Tue, 05 Jun 2018 09:11:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ZtMP3ctQErCMZ2TDf) @gudkov INDY_HOME as a new env var is doable. A developer could set the var in their mobile app and libindy/src/utils/environment.rs would read it. To use this scheme in the java unit test is not really possible because I would have to change every test setup which would make that code Android-specific https://developer.android.com/reference/android/system/Os#setenv(java.lang.String,%20java.lang.String,%20boolean) Also global variables are generally a bad thing and should be avoided. Using more than one wallet location in the mobile app would be impossible.

AxelNennker (Tue, 05 Jun 2018 09:13:07 GMT):
@faisal00813 new version in faisal00813:android_builds now uses the environment variable EXTERNAL_STORAGE to set the wallet location https://github.com/hyperledger/indy-sdk/pull/777

nud3l (Tue, 05 Jun 2018 09:25:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=sjpwTWSucbJcrA3om) I figured out I needed to change the path to the pool_transactions_genesis to where those are stored within my indy-sdk location.

AxelNennker (Tue, 05 Jun 2018 11:15:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=To3hPrzfPbx5q2ris) @gudkov I just found https://github.com/hyperledger/indy-sdk/issues/19

gudkov (Tue, 05 Jun 2018 11:17:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9oyJg3WqQ3hxyMyhe) @AxelNennker There are multiple jira tickets related to logging enhancements and getting error messages also.

smithbk (Tue, 05 Jun 2018 12:43:42 GMT):
@gudhov Ah, my node was using master and my client was using stable. They are both using stable now and working fine. Thanks for the help!

smithbk (Tue, 05 Jun 2018 12:43:42 GMT):
@gudkov ov Ah, my node was using master and my client was using stable. They are both using stable now and working fine. Thanks for the help!

smithbk (Tue, 05 Jun 2018 12:43:42 GMT):
@gudkov Ah, my node was using master and my client was using stable. They are both using stable now and working fine. Thanks for the help!

tomislav (Tue, 05 Jun 2018 13:56:43 GMT):
What is the process of publishing an updated nuget package of the sdk for .NET? @srottem I believe you are the owner of this account? The 1.4 release has the dotnet wrapper match libindy API. Would be nice to have this published.

BreizhIndy (Tue, 05 Jun 2018 14:57:44 GMT):
jones!

srottem (Tue, 05 Jun 2018 16:25:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3mtQcujQZWBCbRiDq) @tomislav The only versions I'm aware of on nuget are the pre-release ones I did over 6 months ago. I'm happy to publish new ones, but I'm unaware of what changes may have been made in the interim. @gudkov - should this package be released with the same version as the SDK (1.4)

srottem (Tue, 05 Jun 2018 16:25:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3mtQcujQZWBCbRiDq) @tomislav The only versions I'm aware of on nuget are the pre-release ones I did over 6 months ago. I'm happy to publish new ones, but I'm unaware of what changes may have been made in the interim. @gudkov, @sergey.minaev - should this package be released with the same version as the SDK (1.4)?

srottem (Tue, 05 Jun 2018 17:11:08 GMT):
Also, it looks like the documentation link still doesn't work - @gudkov is this something you can fix? The GitHub repository needs to be configured for "GitHub Pages" by opening the Settings page for the repo and under the *GitHub Pages* heading choose the master branch as the source. This should make the docs available at http://hyperledger.github.io/indy-sdk/wrappers/dotnet/docs/index.html.

tomislav (Tue, 05 Jun 2018 17:25:45 GMT):
@srottem The updates are in these two pull requests. https://github.com/hyperledger/indy-sdk/pull/651 https://github.com/hyperledger/indy-sdk/pull/593 Sample projects are fully functional and updated, however unit tests haven't been fully updated.

srottem (Tue, 05 Jun 2018 17:28:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wQYJwf2YeYAFRuyFN) @tomislav thanks - I'll take a quick look, but I imagine all's well. :)

tomislav (Tue, 05 Jun 2018 17:29:23 GMT):
I've been using it quite a bit, no issues so far :)

srottem (Tue, 05 Jun 2018 17:46:39 GMT):
Thanks for your work on it!

srottem (Tue, 05 Jun 2018 19:09:51 GMT):
@tomislav I notice that you've changed the target framework from netstandard1.1 to netstandard2.0. Was there a particular feature that you needed that required the newer version?

tomislav (Tue, 05 Jun 2018 20:22:13 GMT):
@srottem Not exactly. I believe VS for Mac changed it automatically due to available tooling. I think the project should target multiple frameworks. `netstandard2.0` can be updated to `netstandard1.1;netstandard2.0;net471;net46` etc. This way, `dotnet package` would produce multiple builds targeting different frameworks.

srottem (Tue, 05 Jun 2018 20:24:14 GMT):
I think that will need to be done in a pull request, but once I get an answer on the required version numbering I can do a package that covers the existing target framework until then.

tomislav (Tue, 05 Jun 2018 20:27:03 GMT):
Sure. I'll do a test run with multi targets and send my results.

srottem (Tue, 05 Jun 2018 20:29:44 GMT):
Ta mate.

tomislav (Tue, 05 Jun 2018 20:54:24 GMT):
My pleasure. So here's the update I tried https://github.com/tmarkovski/indy-sdk/commit/1978cbed94dcda49328bfefe4e3e61668749dd1d I used `dotnet pack -c Release` and it build packages successfully. Output - https://pastebin.com/HUBrEFYF As long as you have the targeting packs installed, you can add as many frameworks. On my mac I could only build net1.1 and 2.0, but then I tried on Windows and luckily I had a bunch of target packs installed, so it built them all.

tomislav (Tue, 05 Jun 2018 20:56:02 GMT):
I'm wondering if it's worth installing the new dotnet 2.1 and targeting that as well. Probably unnecessary, as this library has no package dependancies

json (Tue, 05 Jun 2018 21:28:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nJAvXBw9JRDdgRSDK) @gudkov Hi, thanks for that. I didn't look into the VirtualBox NAT forwarding yet. I've set it up (screenshot below) but still doesn't seem to be working. Does it look right to you?

json (Tue, 05 Jun 2018 21:28:41 GMT):

Clipboard - June 5, 2018 3:28 PM

the_identity_guy (Tue, 05 Jun 2018 21:45:16 GMT):
Which Indy-SDK branch provides the stable release? I can't find the stable branch from https://github.com/hyperledger/indy-sdk And does the default Vagrant file pull the Master (latest) version by default? from the validator.sh references by Vagrant file there is: add-apt-repository "deb https://repo.sovrin.org/deb xenial master" In order to get a stable SDK and Node with 100% compatibility do I have to get the 'stable' branch from both repos?

the_identity_guy (Tue, 05 Jun 2018 21:45:16 GMT):
Which Indy-SDK branch provides the stable release? I can't find the stable branch from https://github.com/hyperledger/indy-sdk And does the default Vagrant file within Indy-Node pull the Master (latest) version by default? Within the validator.sh file referenced by Vagrant file there is: add-apt-repository "deb https://repo.sovrin.org/deb xenial master" In order to get a stable SDK and Node with complete compatibility do I have to get the 'stable' branch from both repos?

srottem (Wed, 06 Jun 2018 05:26:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ZwbT43EaxsyftWS4k) @tomislav I'm actually not sure we need to target anything other than the netstandard 1.1 as it provides the APIs we need and should support all higher .NET implementations: https://docs.microsoft.com/en-us/dotnet/standard/net-standard

srottem (Wed, 06 Jun 2018 05:26:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ZwbT43EaxsyftWS4k) @tomislav I'm actually not sure we need to target anything other than the netstandard 1.1 as it provides the APIs we need and should support all higher .NET implementations - unless I'm reading this wrong: https://docs.microsoft.com/en-us/dotnet/standard/net-standard

srottem (Wed, 06 Jun 2018 05:27:42 GMT):
Failing that, we could target all netstandard versions; we still shouldn't need to target any specific implementations though.

gudkov (Wed, 06 Jun 2018 09:02:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=rYE9jaWTkgKbCok3e) @the_identity_guy releases are tags. Here is all information https://github.com/hyperledger/indy-sdk/blob/master/doc/release-workflow.md

tomislav (Wed, 06 Jun 2018 13:35:28 GMT):
@srottem I'm fine with that. Current tooling for dotnet will support 1.1 fine across platforms. Unless someone is developing with older systems (VS2015 for Windows), 1.1 will work.

tomislav (Wed, 06 Jun 2018 13:36:23 GMT):
I have had no issues so far under linux and mac

srottem (Wed, 06 Jun 2018 14:38:14 GMT):
@tomislav OK. That being the case I'll set up a pull request to change it back to 1.1 - there are a number of documentation corrections to be made too. Once that's accepted I can put together a new package and I'll version it 1.4.0, since I haven't had any other feedback.

srottem (Wed, 06 Jun 2018 14:38:14 GMT):
OK. That being the case I'll set up a pull request to change it back to 1.1 - there are a number of documentation corrections to be made too. Once that's accepted I can put together a new package and I'll version it 1.4.0, since I haven't had any other feedback.

sklump (Wed, 06 Jun 2018 15:46:43 GMT):
Just a quick word of thanks to whoever fixed the crypto_pw_hash not found for ubuntu 16.04, somewhere between indy-sdk 1.4.0-dev-543 and the lastest master. You saved me a big headache I was not looking forward to. :+1:

srottem (Wed, 06 Jun 2018 16:11:20 GMT):
@tomislav OK. That being the case I'll set up a pull request to change it back to 1.1 - there are a number of documentation corrections to be made too. Once that's accepted I can put together a new package and I'll version it 1.4.0, since I haven't had any other feedback.

tomislav (Wed, 06 Jun 2018 16:11:54 GMT):
@srottem Sounds good. Thank you for doing this.

the_identity_guy (Thu, 07 Jun 2018 00:45:49 GMT):
I get the following error when I run Indy-SDK sample code or Libindy tests: ``` Invalid library state: Unexpected SQLite error: execute returned results - did you mean to call query? ``` Any idea what that means? . The error only appears on MacOS. The Indy SDK version is 1.4.0. This error doesn't occur on Ubuntu version (Stable release) of IndySDK

gudkov (Thu, 07 Jun 2018 09:00:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=YBKisA2kCaYpCNdjT) @the_identity_guy Most probably you have more modern version of sqlite. Try to check with the same sqlite version as on ubuntu.

bdeva (Thu, 07 Jun 2018 15:23:31 GMT):
Has joined the channel.

json (Thu, 07 Jun 2018 17:28:03 GMT):
HI guys, still stuck with this ErrorCode.PoolLedgerTimeout error as I'm trying to do the Python write_did tutorial. A question: how does the script / libindy know to connect to "127.0.0.1:9701-9708" when you call "pool.open_pool_ledger"? It doesnt seem to be specified anywhere.. how could i verify that it's trying to connect to the right pool address?

tomislav (Thu, 07 Jun 2018 17:40:51 GMT):
@json10 when you open_pool_ledger you are passing a config object with the location of a genesis_txn file. This file contains the IP and ports of the nodes.

tomislav (Thu, 07 Jun 2018 17:40:51 GMT):
@json 10 when you open_pool_ledger you are passing a config object with the location of a genesis_txn file. This file contains the IP and ports of the nodes.

json (Thu, 07 Jun 2018 19:14:42 GMT):
thanks!! i got it working

json (Thu, 07 Jun 2018 19:14:53 GMT):
I had to change the genesis_txn file to point to 127.0.0.1 instead of 10.0.0.2

swcurran (Thu, 07 Jun 2018 19:24:01 GMT):
@esplinr - ^^^ That seems to be a big one for the FAQ. Getting the right IP addresses into the genesis file.

esplinr (Thu, 07 Jun 2018 19:31:27 GMT):
Thanks @swcurran. @kdenhartog is working on the FAQ.

kdenhartog (Thu, 07 Jun 2018 19:31:27 GMT):
Has joined the channel.

esplinr (Thu, 07 Jun 2018 19:31:45 GMT):
I'll nudge him.

swcurran (Thu, 07 Jun 2018 19:40:00 GMT):
Ooopppsss...

abraham (Fri, 08 Jun 2018 05:19:27 GMT):
Has joined the channel.

dungnguyen116 (Fri, 08 Jun 2018 09:40:28 GMT):
Has joined the channel.

dungnguyen116 (Fri, 08 Jun 2018 09:41:17 GMT):
Did someone get this problem ?

dungnguyen116 (Fri, 08 Jun 2018 09:41:19 GMT):
_indy_loop_callback: Function returned error 307

dungnguyen116 (Fri, 08 Jun 2018 09:41:31 GMT):
Error occurred: ErrorCode.PoolLedgerTimeout

dungnguyen116 (Fri, 08 Jun 2018 09:43:16 GMT):
oops , sorry , i missed last messenger

alekhyam (Fri, 08 Jun 2018 10:27:30 GMT):
Has joined the channel.

saikirantyson7 (Fri, 08 Jun 2018 11:29:55 GMT):
Has joined the channel.

saikirantyson7 (Fri, 08 Jun 2018 11:30:08 GMT):
Hi !!

saikirantyson7 (Fri, 08 Jun 2018 11:31:21 GMT):
Im new to indy. I was just exploring when i found that i was able to re-enter the same did multiple times in the pool.

saikirantyson7 (Fri, 08 Jun 2018 11:31:39 GMT):
Is this normal?

gudkov (Fri, 08 Jun 2018 11:32:35 GMT):
What exactly you are doing? Sending NYM transaction multiple times with the same DID?

saikirantyson7 (Fri, 08 Jun 2018 11:35:27 GMT):
yes. !

saikirantyson7 (Fri, 08 Jun 2018 11:36:00 GMT):
i was hoping that if i send the same DID to the same pool again, i might hit an error.

saikirantyson7 (Fri, 08 Jun 2018 11:36:18 GMT):
But here, it just continues

saikirantyson7 (Fri, 08 Jun 2018 11:36:25 GMT):
to next step.

saikirantyson7 (Fri, 08 Jun 2018 11:37:32 GMT):
I tried the same in wallet and it throws the error "IndyError: ErrorCode.DidAlreadyExistsError"

saikirantyson7 (Fri, 08 Jun 2018 11:45:38 GMT):
Can anyone explain me this behaviour?

gudkov (Fri, 08 Jun 2018 11:48:41 GMT):
first NYM is creation, next NYM it is actually update. You can rotate keys, change endpoints and etc...

saikirantyson7 (Fri, 08 Jun 2018 11:50:31 GMT):
nym_transaction_response = await ledger.sign_and_submit_request( pool_handle=pool_handle, wallet_handle=wallet_handle, submitter_did=steward_did, request_json=nym_transaction_request)

saikirantyson7 (Fri, 08 Jun 2018 11:50:31 GMT):
The code im trying is below: nym_transaction_request = await ledger.build_nym_request( submitter_did=steward_did, target_did=regis_did, ver_key=regis_verkey, alias=None, role=None) nym_transaction_response = await ledger.sign_and_submit_request( pool_handle=pool_handle, wallet_handle=wallet_handle, submitter_did=steward_did, request_json=nym_transaction_request) Am i missing anything in it?

saikirantyson7 (Fri, 08 Jun 2018 11:51:32 GMT):
So technically, after steward, iam creating another NYM and sending it.

saikirantyson7 (Fri, 08 Jun 2018 11:51:51 GMT):
Im not using any endpoints or rotate keys..

saikirantyson7 (Fri, 08 Jun 2018 11:54:11 GMT):
but what i what to know is, When i send the same NYM again and again, what happens exactly in the backend.. ?

saikirantyson7 (Fri, 08 Jun 2018 11:54:26 GMT):
can i enter same NYM multiple times to same pool ?

gudkov (Fri, 08 Jun 2018 12:03:59 GMT):
> can i enter same NYM multiple times to same pool ? You can SEND NYM multiple times, not CRATE multiple times. ledger is SEQUENTIAL list of transaction, but each transaction modifies STATE. After sending of first NYM there will be added corresponded record to state. Next NYM will modify the state.

gudkov (Fri, 08 Jun 2018 12:03:59 GMT):
> can i enter same NYM multiple times to same pool ? You can SEND NYM multiple times, not CRATE multiple times. ledger is SEQUENTIAL list of transactions, but each transaction modifies STATE. After sending of first NYM there will be added corresponded record to state. Next NYM will modify the state.

saikirantyson7 (Fri, 08 Jun 2018 12:06:34 GMT):
okay!

AxelNennker (Fri, 08 Jun 2018 18:59:58 GMT):
Why does SubmitAck( i32, // cmd_id Result, // result json or error ), return a PoolError and not an IndyError? in file https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/commands/ledger.rs#L45

json (Fri, 08 Jun 2018 19:44:14 GMT):
Hi guys. working through the tutorial to write a schema. It seems that the python code might be out of date / incomplete, so I'm trying to fix and get it working. Inside indy_ledger.h in libindy, I found this for the credential schema request: /// data: Credential schema. /// { /// id: identifier of schema /// attrNames: array of attribute name strings /// name: Schema's name string /// version: Schema's version string, /// ver: Version of the Schema json /// }

json (Fri, 08 Jun 2018 19:44:32 GMT):
Can anyone point me to documentation about what the "ver" and "id" variables are used for?

json (Fri, 08 Jun 2018 19:44:39 GMT):
doesn't seem to be in the howto code

kdenhartog (Sat, 09 Jun 2018 01:34:38 GMT):
@json 10 I believe the id is used as a way to identify the schema on the ledger so it can be referenced by the cred_def. ver is there to identify versioning of the json structure of the schema. This way a person can provide backward compatibilty as the schema is updated. Docs about this were a bit hard to find, so we'll need to address this, but for now you can read more about how requests are supposed to be structured right now here: https://github.com/hyperledger/indy-node/blob/master/docs/requests.md and the updated structure (where you'll find more useful info) here: https://github.com/hyperledger/indy-node/blob/master/docs/requests-new.md

ashcherbakov (Sat, 09 Jun 2018 06:19:29 GMT):
Please note that https://github.com/hyperledger/indy-node/blob/master/docs/requests-new.md is a design for future. The current format is in https://github.com/hyperledger/indy-node/blob/master/docs/requests.md

gudkov (Sat, 09 Jun 2018 13:53:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=T56bwDyvAkuQwy3X3) @AxelNennker Because it is Ack from PoolService, not request from the user.

AxelNennker (Sat, 09 Jun 2018 14:01:01 GMT):
Does this mean that SubmitAck is not really a API-visible Command and should not be in this list?

AxelNennker (Sat, 09 Jun 2018 14:03:12 GMT):
Hm, not sure about the API-visibility. Looks like something internal

gudkov (Sat, 09 Jun 2018 14:04:23 GMT):
Some requests that handled asynchronously are state machines that can receive commands from API and from internal services.

gudkov (Sat, 09 Jun 2018 14:06:12 GMT):
@AxelNennker Here is sequence that illustrates how libindy process requests https://raw.githubusercontent.com/vimmerru/indy-rfc/78999194d026e7265d5156ac6e0eb837899df670/text/concurrency-improvement/api-call-processing.png

AxelNennker (Sat, 09 Jun 2018 14:47:33 GMT):
Nice diagram. Thanks.

dphhyland (Sun, 10 Jun 2018 08:49:31 GMT):
Has joined the channel.

PhillipGibb (Mon, 11 Jun 2018 14:01:28 GMT):
Has joined the channel.

json (Mon, 11 Jun 2018 15:20:18 GMT):
thanks @kdenhartog

slr (Mon, 11 Jun 2018 17:05:50 GMT):
Has joined the channel.

slr (Mon, 11 Jun 2018 17:11:16 GMT):
Hi! I'm new to indy-node and I'm trying to implement a pretty simple use case to just create a new connection request. I've been looking for a while now and I'm not sure how to do that, changing/adding files in the sample folder doesn't seem to be working. Please help!

json (Mon, 11 Jun 2018 17:46:33 GMT):
Could anyone tell me what the "authz" and "authz-rc" branches are for on the indy-sdk repo? I noticed that these branches contain some functions in the python wrapper that are missing in the master/rc branches (notably anoncreds.py/issuer_create_and_store_claim_def). Without this function I can't go through howto #3

json (Mon, 11 Jun 2018 17:47:53 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/indy/anoncreds.py vs. https://github.com/hyperledger/indy-sdk/blob/authz-rc/wrappers/python/indy/anoncreds.py

json (Mon, 11 Jun 2018 17:51:53 GMT):
ah nvm, I found it's been changed as of V1.4.0! This seems to have the info I need: https://github.com/hyperledger/indy-sdk/blob/v1.4.0/doc/migration-guide.md#anoncreds-api-mapping

danielhardman (Mon, 11 Jun 2018 19:01:12 GMT):
@esplinr and @gudkov : I left a comment on the concurrency HIPE (https://github.com/hyperledger/indy-hipe/pull/16).

esplinr (Mon, 11 Jun 2018 19:14:33 GMT):
Thanks. I scheduled the follow up conversation for June 22.

mccown (Tue, 12 Jun 2018 00:05:37 GMT):
I pulled the latest Indy SDK repo today (& rebuilt a new docker) and I'm having a problem running the Java sample. In the Anoncreds.java file, the SDK is able to create a default pool (1st statement), but errors out trying to open it (only the 2nd statement). I verified in the CLI that the pool was created. // From Anoncreds.java. //1. Create and Open Pool String poolName = PoolUtils.createPoolLedgerConfig(); Pool pool = Pool.openPoolLedger(poolName, "{}").get(); <---- error Stepping through the debugger, I'm finding that the IndyJava.class file (see line 126 in checkCallback()) is returning an error 112, which indy-sdk/indy_mod.h describes as: // Invalid library state was detected in runtime. It signals library bug CommonInvalidState = 112 Does this error look familiar to anyone? It doesn't give me much to go on...

mccown (Tue, 12 Jun 2018 00:05:37 GMT):
I pulled the latest Indy SDK repo today (& rebuilt a new docker) and I'm having a problem running the Java sample. In the Anoncreds.java file, the SDK is able to create a default pool (1st statement), but errors out trying to open it (2nd statement). I verified in the CLI that the pool was created. (BTW, libindy did pass all the integrations tests.) // From Anoncreds.java. //1. Create and Open Pool String poolName = PoolUtils.createPoolLedgerConfig(); Pool pool = Pool.openPoolLedger(poolName, "{}").get(); <---- error Stepping through the debugger, I'm finding that the IndyJava.class file (see line 126 in checkCallback()) is returning an error 112, which indy-sdk/indy_mod.h describes as: // Invalid library state was detected in runtime. It signals library bug CommonInvalidState = 112 Does this error look familiar to anyone? It doesn't give me much to go on...

mccown (Tue, 12 Jun 2018 00:05:37 GMT):
I pulled the latest Indy SDK repo today (& rebuilt a new docker) and I'm having a problem running the Java sample. In the Anoncreds.java file, the SDK is able to create a default pool (1st statement), but errors out trying to open it (2nd statement). I verified in the CLI that the pool was created. (BTW, libindy did pass all the integrations tests.) // From Anoncreds.java. //1. Create and Open Pool String poolName = PoolUtils.createPoolLedgerConfig(); Pool pool = Pool.openPoolLedger(poolName, "{}").get(); <---- error Stepping through the debugger, I'm finding that the IndyJava.class file (see line 126 in checkCallback()) is returning an error 112, which indy-sdk/indy_mod.h describes as: // Invalid library state was detected in runtime. It signals library bug CommonInvalidState = 112 Does this error look familiar to anyone? Do I need to reset something? It doesn't give me much to go on...

tomislav (Tue, 12 Jun 2018 01:13:25 GMT):
@mccown The java wrapper may not be fully updated against latest libindy. Try checking out the 1.4.0 tag and run the indy node from the docker with this version

trthhrtz (Tue, 12 Jun 2018 03:45:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3dFbjz7ZKkXEaQ7Df) @mccown Hi! I just went through this sample. Make sure that your docker is running on the same ports as in the following file: indy-sdk-> samples -> java -> src -> main -> java -> utils -> EnvironmentUtils.java -> `testPoolIp` (if you followed this guide https://github.com/hyperledger/indy-sdk/blob/master/README.md#how-to-start-local-nodes-pool-with-docker and chose option with 10.0.0.2 then try putting 10.0.0.2 as your `testPoolIp`)

trthhrtz (Tue, 12 Jun 2018 03:45:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3dFbjz7ZKkXEaQ7Df) @mccown Hi! I just went through this sample. Make sure that your docker is running on the same ip as in the following file: indy-sdk-> samples -> java -> src -> main -> java -> utils -> EnvironmentUtils.java -> `testPoolIp` (if you followed this guide https://github.com/hyperledger/indy-sdk/blob/master/README.md#how-to-start-local-nodes-pool-with-docker and chose option with 10.0.0.2 then try putting 10.0.0.2 as your `testPoolIp`)

trthhrtz (Tue, 12 Jun 2018 03:45:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3dFbjz7ZKkXEaQ7Df) @mccown Hi! I just went through this sample, did not catch this bug. Make sure that your docker is running on the same ip as in the following file: indy-sdk-> samples -> java -> src -> main -> java -> utils -> EnvironmentUtils.java -> `testPoolIp` (if you followed this guide https://github.com/hyperledger/indy-sdk/blob/master/README.md#how-to-start-local-nodes-pool-with-docker and chose option with 10.0.0.2 then try putting 10.0.0.2 as your `testPoolIp`)

trthhrtz (Tue, 12 Jun 2018 03:45:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3dFbjz7ZKkXEaQ7Df) @mccown Hi! I just went through this sample, did not catch this bug (ubuntu 16.04 LTS). Make sure that your docker is running on the same ip as in the following file: indy-sdk-> samples -> java -> src -> main -> java -> utils -> EnvironmentUtils.java -> `testPoolIp` (if you followed this guide https://github.com/hyperledger/indy-sdk/blob/master/README.md#how-to-start-local-nodes-pool-with-docker and chose option with 10.0.0.2 then try putting 10.0.0.2 as your `testPoolIp`)

trthhrtz (Tue, 12 Jun 2018 03:45:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3dFbjz7ZKkXEaQ7Df) @mccown Hi! I just went through this sample, did not catch this bug (ubuntu 16.04 LTS, java 1.8, Intellij IDEA). Make sure that your docker is running on the same ip as in the following file: indy-sdk-> samples -> java -> src -> main -> java -> utils -> EnvironmentUtils.java -> `testPoolIp` (if you followed this guide https://github.com/hyperledger/indy-sdk/blob/master/README.md#how-to-start-local-nodes-pool-with-docker and chose option with 10.0.0.2 then try putting 10.0.0.2 as your `testPoolIp`)

trthhrtz (Tue, 12 Jun 2018 03:45:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3dFbjz7ZKkXEaQ7Df) @mccown Hi! I just went through the sample, did not catch this bug (ubuntu 16.04 LTS, java 1.8, Intellij IDEA). Make sure that your docker is running on the same ip as in the following file: indy-sdk-> samples -> java -> src -> main -> java -> utils -> EnvironmentUtils.java -> `testPoolIp` (if you followed this guide https://github.com/hyperledger/indy-sdk/blob/master/README.md#how-to-start-local-nodes-pool-with-docker and chose option with 10.0.0.2 then try putting 10.0.0.2 as your `testPoolIp`)

tusharg (Tue, 12 Jun 2018 10:01:15 GMT):
hi, the indy-sdk tutorial at `https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/save-schema-and-cred-def/python/write_schema_and_cred_def.py` runs fine till step 8, but throws the following error at step 9 (the code statement at which the error is thrown is `schema_request = await ledger.build_schema_request(steward_did, json.dumps(schema_data))`). ERROR: ```9. Build the SCHEMA request to add new schema to the ledger as a Steward Schema data: {'attr_names': ['age', 'sex', 'height', 'name'], 'name': 'gvt', 'version': '1.0'} Schema: {'data': {'attr_names': ['age', 'sex', 'height', 'name'], 'name': 'gvt', 'version': '1.0'}, 'dest': 'Th7MpTaRZVRYnPiabds81Y', 'seqNo': 1} _indy_loop_callback: Function returned error 113 Error occurred: ErrorCode.CommonInvalidStructure``` Please help me in resolving this. Tnanks

tusharg (Tue, 12 Jun 2018 10:01:15 GMT):
hi, the indy-sdk tutorials at `https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/save-schema-and-cred-def/python/issue_credential.py` and `https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/save-schema-and-cred-def/python/write_schema_and_cred_def.py` run fine till step 8, but throw the following error at step 9 (the code statement at which the error is thrown is `schema_request = await ledger.build_schema_request(steward_did, json.dumps(schema_data))`). ERROR: ```9. Build the SCHEMA request to add new schema to the ledger as a Steward Schema data: {'attr_names': ['age', 'sex', 'height', 'name'], 'name': 'gvt', 'version': '1.0'} Schema: {'data': {'attr_names': ['age', 'sex', 'height', 'name'], 'name': 'gvt', 'version': '1.0'}, 'dest': 'Th7MpTaRZVRYnPiabds81Y', 'seqNo': 1} _indy_loop_callback: Function returned error 113 Error occurred: ErrorCode.CommonInvalidStructure``` Please help me in resolving this. Thanks

smithbk (Tue, 12 Jun 2018 13:43:42 GMT):
@gudkov Hi, I'm using the stable branch of both indy-node and indy-sdk and am seeing the following error when trying to store a credential. Any ideas or suggestions on how to debug? ```DEBUG:indy.anoncreds:prover_store_credential: Creating callback DEBUG:indy.libindy:create_cb: >>> cb_type: .CFunctionType'> DEBUG:indy.libindy:create_cb: <<< res: DEBUG:indy.libindy:do_call: >>> name: indy_prover_store_credential, args: (c_int(3), None, c_char_p(28456576), c_char_p(28330672), c_char_p(28316928), c_char_p(28420016), None, ) DEBUG:indy.libindy:do_call: Function indy_prover_store_credential returned err: 107 WARNING:indy.libindy:_do_call: Function indy_prover_store_credential returned error 107 DEBUG:indy.libindy:do_call: <<< ,)> ERROR:flask.app:Exception on /api/v1/credentials [POST] Traceback (most recent call last): File "/usr/local/lib/python3.5/dist-packages/flask/app.py", line 2292, in wsgi_app response = self.full_dispatch_request() File "/usr/local/lib/python3.5/dist-packages/flask/app.py", line 1815, in full_dispatch_request rv = self.handle_user_exception(e) File "/usr/local/lib/python3.5/dist-packages/flask/app.py", line 1718, in handle_user_exception reraise(exc_type, exc_value, tb) File "/usr/local/lib/python3.5/dist-packages/flask/_compat.py", line 35, in reraise raise value File "/usr/local/lib/python3.5/dist-packages/flask/app.py", line 1813, in full_dispatch_request rv = self.dispatch_request() File "/usr/local/lib/python3.5/dist-packages/flask/app.py", line 1799, in dispatch_request return self.view_functions[rule.endpoint](**req.view_args) File "/usr/local/lib/python3.5/dist-packages/eve/endpoints.py", line 58, in collections_endpoint response = post(resource) File "/usr/local/lib/python3.5/dist-packages/eve/methods/common.py", line 297, in rate_limited return f(*args, **kwargs) File "/usr/local/lib/python3.5/dist-packages/eve/auth.py", line 78, in decorated return f(*args, **kwargs) File "/usr/local/lib/python3.5/dist-packages/eve/methods/common.py", line 1176, in decorated getattr(app, event_name + '_' + resource)(*rh_params) File "/usr/local/lib/python3.5/dist-packages/events/events.py", line 95, in __call__ f(*a, **kw) File "/home/indy/bin/api.py", line 63, in pre_credentials_post schema = agent.accept_credential_offer(req.json) File "/home/indy/bin/agent.py", line 252, in accept_credential_offer self.wallet, None, req_json, req_metadata_json, cred_json, cred_def, None)) File "/home/indy/bin/agent.py", line 22, in await return loop.run_until_complete(coroutine) File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step result = coro.send(None) File "/usr/local/lib/python3.5/dist-packages/indy/anoncreds.py", line 618, in prover_store_credential prover_store_credential.cb) File "/usr/lib/python3.5/asyncio/futures.py", line 363, in __iter__ return self.result() # May raise too. File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception indy.error.IndyError: ErrorCode.CommonInvalidParam8 ```

sklump (Tue, 12 Jun 2018 13:50:57 GMT):
Consult `indy-sdk/wrappers/python/tests/interation/test_interaction.py` for a demo with pretty much everything you'll need

tomislav (Tue, 12 Jun 2018 14:11:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=adgPcSHzeyBopXLb2) @smithbk The error suggests that the 8th argument in your call is invalid. That would be the callback function you're passing.

tomislav (Tue, 12 Jun 2018 14:11:49 GMT):
@smithbk The error suggests that the 8th argument in your call is invalid. That would be the callback function you're passing.

tomislav (Tue, 12 Jun 2018 14:12:34 GMT):
@smithbk The error suggests that the 8th argument in your call is invalid. That would be the callback function you're passing.

segevm (Tue, 12 Jun 2018 14:38:55 GMT):
Has joined the channel.

smithbk (Tue, 12 Jun 2018 14:40:28 GMT):
@gudkov Hi, I'm using the stable branch of both indy-node and indy-sdk. I'm seeing the following error. Any ideas? `````` DEBUG:indy.anoncreds:prover_store_credential: Creating callback DEBUG:indy.libindy:create_cb: >>> cb_type: .CFunctionType'> DEBUG:indy.libindy:create_cb: <<< res: DEBUG:indy.libindy:do_call: >>> name: indy_prover_store_credential, args: (c_int(3), None, c_char_p(28456576), c_char_p(28330672), c_char_p(28316928), c_char_p(28420016), None, ) DEBUG:indy.libindy:do_call: Function indy_prover_store_credential returned err: 107 WARNING:indy.libindy:_do_call: Function indy_prover_store_credential returned error 107 DEBUG:indy.libindy:do_call: <<< ,)> ERROR:flask.app:Exception on /api/v1/credentials [POST] Traceback (most recent call last): File "/usr/local/lib/python3.5/dist-packages/flask/app.py", line 2292, in wsgi_app response = self.full_dispatch_request() File "/usr/local/lib/python3.5/dist-packages/flask/app.py", line 1815, in full_dispatch_request rv = self.handle_user_exception(e) File "/usr/local/lib/python3.5/dist-packages/flask/app.py", line 1718, in handle_user_exception reraise(exc_type, exc_value, tb) File "/usr/local/lib/python3.5/dist-packages/flask/_compat.py", line 35, in reraise raise value File "/usr/local/lib/python3.5/dist-packages/flask/app.py", line 1813, in full_dispatch_request rv = self.dispatch_request() File "/usr/local/lib/python3.5/dist-packages/flask/app.py", line 1799, in dispatch_request return self.view_functions[rule.endpoint](**req.view_args) File "/usr/local/lib/python3.5/dist-packages/eve/endpoints.py", line 58, in collections_endpoint response = post(resource) File "/usr/local/lib/python3.5/dist-packages/eve/methods/common.py", line 297, in rate_limited return f(*args, **kwargs) File "/usr/local/lib/python3.5/dist-packages/eve/auth.py", line 78, in decorated return f(*args, **kwargs) File "/usr/local/lib/python3.5/dist-packages/eve/methods/common.py", line 1176, in decorated getattr(app, event_name + '_' + resource)(*rh_params) File "/usr/local/lib/python3.5/dist-packages/events/events.py", line 95, in __call__ f(*a, **kw) File "/home/indy/bin/api.py", line 63, in pre_credentials_post schema = agent.accept_credential_offer(req.json) File "/home/indy/bin/agent.py", line 252, in accept_credential_offer self.wallet, None, req_json, req_metadata_json, cred_json, cred_def, None)) File "/home/indy/bin/agent.py", line 22, in await return loop.run_until_complete(coroutine) File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step result = coro.send(None) File "/usr/local/lib/python3.5/dist-packages/indy/anoncreds.py", line 618, in prover_store_credential prover_store_credential.cb) File "/usr/lib/python3.5/asyncio/futures.py", line 363, in __iter__ return self.result() # May raise too. File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception indy.error.IndyError: ErrorCode.CommonInvalidParam8```

smithbk (Tue, 12 Jun 2018 14:42:48 GMT):
@gudkov Hi, I'm using stable branch of indy-node/sdk and seeing the following error ```DEBUG:indy.anoncreds:prover_store_credential: Creating callback DEBUG:indy.libindy:create_cb: >>> cb_type: .CFunctionType'> DEBUG:indy.libindy:create_cb: <<< res: DEBUG:indy.libindy:do_call: >>> name: indy_prover_store_credential, args: (c_int(3), None, c_char_p(28456576), c_char_p(28330672), c_char_p(28316928), c_char_p(28420016), None, ) DEBUG:indy.libindy:do_call: Function indy_prover_store_credential returned err: 107 WARNING:indy.libindy:_do_call: Function indy_prover_store_credential returned error 107 DEBUG:indy.libindy:do_call: <<< ,)>```

dbluhm (Tue, 12 Jun 2018 15:21:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Ns2ZFFfDJwQF22yX6) @tusharg What version of the sdk are you using?

segevm (Tue, 12 Jun 2018 15:39:05 GMT):
Do I need to add `libindy` to the environment path when installing it via apt on ubuntu 16.04?

dbluhm (Tue, 12 Jun 2018 15:41:54 GMT):
If you installed libindy through apt, your library paths should have already been properly configured

dbluhm (Tue, 12 Jun 2018 15:42:53 GMT):
Or rather, `libindy` is installed to a location that is already checked by your linker so no environment variables need to be altered

segevm (Tue, 12 Jun 2018 15:43:01 GMT):
I did install it through apt but its giving me `command not found` when i type `libindy` at the command line

dbluhm (Tue, 12 Jun 2018 15:43:27 GMT):
Ah; `libindy` isn't a command but a library

dbluhm (Tue, 12 Jun 2018 15:43:53 GMT):
If you'd like a command line interface, look into indy-cli in the indy-sdk repo

segevm (Tue, 12 Jun 2018 15:44:12 GMT):
ahh okay thanks :)

trthhrtz (Tue, 12 Jun 2018 16:08:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Ns2ZFFfDJwQF22yX6) @tusharg Hi! ``` schema = { 'seqNo': seq_no, 'dest': steward_did, 'data': { "id": "1", "name": "gvt", "version": "1.0", "attrNames": ["age", "sex", "height", "name"], "ver": "1.0" } }``` ```

trthhrtz (Tue, 12 Jun 2018 16:08:31 GMT):
@tusharg Hi! Try this ``` schema = { 'seqNo': seq_no, 'dest': steward_did, 'data': { "id": "1", "name": "gvt", "version": "1.0", "attrNames": ["age", "sex", "height", "name"], "ver": "1.0" } }``` ```

segevm (Tue, 12 Jun 2018 17:38:11 GMT):
Hi, I'm following the [Indy-SDK Developer Walkthrough #1, Python Edition](https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/write-did-and-query-verkey/python/README.md) on Ubuntu 16.04 (installed `indysdk` via APT) and I'm getting the following error when I try to run the file: ``` _indy_loop_callback: Function returned error 114 Error occurred: ErrorCode.CommonIOError ``` Any ideas what might be causing the issue? I made sure to specify the `genesis_file_path` in the file to the location of my installation (`~/indy/indysdk/cli/docker_pool_transactions_genesis`). I have also confirmed that the docker image is up and running: ``` docker ps -l CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 56d7d1a5a2ca indy_pool "/usr/bin/supervisord" 2 hours ago Up 2 hours 0.0.0.0:9701-9708->9701-9708/tcp elegant_wozniak ```

tomislav (Tue, 12 Jun 2018 17:44:48 GMT):
@segevm This is IO Error. Can you try specifying the full path instead?

trthhrtz (Tue, 12 Jun 2018 17:50:45 GMT):
@segevm , shouldn't you have `~/indy/indy-sdk/cli/docker_pool_transactions_genesis`?

segevm (Tue, 12 Jun 2018 18:03:46 GMT):
@trthhrtz yes sorry that was a typo, the path I have in the file is `~/indy/indy-sdk/cli/docker_pool_transactions_genesis`

segevm (Tue, 12 Jun 2018 18:05:50 GMT):
@tomislav that fixed the error thank you!

segevm (Tue, 12 Jun 2018 18:12:18 GMT):
Hm, now I'm getting `ErrorCode.CommonInvalidState`: ``` 1. Create new pool ledger configuration to connect to ledger. 2. Open ledger and get handle _indy_loop_callback: Function returned error 112 Error occurred: ErrorCode.CommonInvalidState ``` I started the pool previously by following the commands in the tutorial: ``` docker build -f ci/indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9708:9701-9708 indy_pool ``` Did I somehow start the pool wrong?

lenardb79 (Tue, 12 Jun 2018 18:13:09 GMT):
Has joined the channel.

sklump (Tue, 12 Jun 2018 18:26:29 GMT):
Just a small gripe here: the latest master changes the JSON of some ledger responses (build schema, build revoc entry) without bumping the version number. Naughty.

sklump (Tue, 12 Jun 2018 18:26:29 GMT):
Just a small gripe here: the latest master changes the JSON of some ledger responses (build schema, build revoc entry, maybe others I haven't found yet) without bumping the version number. Naughty.

trthhrtz (Tue, 12 Jun 2018 18:29:54 GMT):
@segevm Try to follow the second option with docker (with 10.0.0.2) described here https://github.com/hyperledger/indy-sdk/blob/master/README.md#how-to-start-local-nodes-pool-with-docker . Besides, you might find useful my Pull Request(https://github.com/hyperledger/indy-sdk/pull/864)

json (Tue, 12 Jun 2018 21:37:08 GMT):
Hi guys, I'm also getting `ErrorCode.CommonInvalidState`. I'm on indy-sdk stable (commit tagged 1.4.0), and installed libindy from the stable 1.4.0 branch too. I'm getting the error at this line ```pool_handle = await pool.open_pool_ledger(config_name=pool_name, config=None)``` in the tutorials. I checked out your PR @trthhrtz , looks good but still not sure why I'm getting this

json (Tue, 12 Jun 2018 21:38:11 GMT):
It's very weird because I can make it work if I download a random build of the indy dlls from a few days ago (Master branch from last week sometime). But I want to use the stable ones

json (Tue, 12 Jun 2018 21:38:15 GMT):
any ideas?

mccown (Wed, 13 Jun 2018 02:01:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=d6j6yXLLxnwfwSSRx) @trthhrtz and @tomislav Thanks for the tips. Your comments put me on the right track. The current Java sample is now working with the local docker (verified with the cli). I had a libindy conflict caused by two different versions being installed -- I forgot I installed one a while back via apt-get and then yesterday, I built the sdk. Given that the docker referenced one and the java app referenced the other, nothing complained, but they didn't communicate well.

AvikHazra (Wed, 13 Jun 2018 04:56:03 GMT):
Has joined the channel.

tusharg (Wed, 13 Jun 2018 06:13:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ygM4BQhfdyAisJBzo) @dbluhm I am using indy 1.4.0, but the tutorials are in 1.3.0 and I am having trouble migrating them using the migration guide (since I am very new). Can you point me to a working tutorials directory?

tusharg (Wed, 13 Jun 2018 06:17:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ENN6q5ZRFqNPw6AJZ) @trthhrtz Thanks!! I got past step 9, but got stuck at 11. Also, the output of step 10 was: ```10. Sending the SCHEMA request to the ledger Schema response: {'identifier': 'Th7MpTaRZVRYnPiabds81Y', 'op': 'REJECT', 'reason': 'client request invalid: ' "InvalidClientRequest('Th7MpTaRZVRYnPiabds81Y can have one and only " "one SCHEMA with name gvt and version 1.0',)", 'reqId': 1528867543742434175} 11. Creating and storing CRED DEFINITION using anoncreds as Trust Anchor, for the given Schema _indy_loop_callback: Function returned error 113 Error occurred: ErrorCode.CommonInvalidStructure``` Also, why does your improved version of schema work, while the original doesn

gudkov (Wed, 13 Jun 2018 11:37:15 GMT):
@danielhardman Seems how-tos are very outdated now and require support.

dbluhm (Wed, 13 Jun 2018 12:42:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Qn43pF4hZ9CcrZZ2y) @segevm The current docker Genesis file assumes you started the docker test pool on 10.0.0.2. You can find and replace every occurrence of that value with 127.0.0.1 and it should work with how you started docker.

mboyd (Wed, 13 Jun 2018 13:15:57 GMT):
@dbluhm this has also happened to me when running the docker file for the jupyter python notebook. Can you specify which file is the genesis file?

smithbk (Wed, 13 Jun 2018 13:31:04 GMT):
@tomislav Thanks, so does this mean there is a bug in the python wrapper? Here is the error again ```DEBUG:indy.anoncreds:prover_store_credential: Creating callback DEBUG:indy.libindy:create_cb: >>> cb_type: .CFunctionType'> DEBUG:indy.libindy:create_cb: <<< res: DEBUG:indy.libindy:do_call: >>> name: indy_prover_store_credential, args: (c_int(3), None, c_char_p(48616608), c_char_p(48684864), c_char_p(48708320), c_char_p(48771648), None, ) DEBUG:indy.libindy:do_call: Function indy_prover_store_credential returned err: 107 WARNING:indy.libindy:_do_call: Function indy_prover_store_credential returned error 107 DEBUG:indy.libindy:do_call: <<< ,)>```

smithbk (Wed, 13 Jun 2018 13:31:33 GMT):
And my call is: ``` async def store_credential(self, req_json, req_metadata_json, cred_json, cred_def, issuer_name): logger.debug("Storing credential issued by {}: {}, {}, {}, {}".format( issuer_name, req_json, req_metadata_json, cred_json, cred_def)) await anoncreds.prover_store_credential( self.wallet, None, req_json, req_metadata_json, cred_json, cred_def, None)```

smithbk (Wed, 13 Jun 2018 13:31:33 GMT):
Any help with https://jira.hyperledger.org/browse/INDY-1412 is appreciated logger.debug("Storing credential issued by {}: {}, {}, {}, {}".format( issuer_name, req_json, req_metadata_json, cred_json, cred_def)) await anoncreds.prover_store_credential( self.wallet, None, req_json, req_metadata_json, cred_json, cred_def, None)```

smithbk (Wed, 13 Jun 2018 13:32:31 GMT):
I'm using the stable branch

mjmckean (Wed, 13 Jun 2018 13:57:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=E7hCJiu3AZLX4Sx3Q) @mboyd ~/indy/indy-sdk/cli/docker_pool_transactions_genesis

mjmckean (Wed, 13 Jun 2018 13:57:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=E7hCJiu3AZLX4Sx3Q) @mboyd <~/indy/indy-sdk/cli/docker_pool_transactions_genesis/>

mjmckean (Wed, 13 Jun 2018 13:57:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=E7hCJiu3AZLX4Sx3Q) @mboyd `~/indy/indy-sdk/cli/docker_pool_transactions_genesis`

json (Wed, 13 Jun 2018 15:19:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=55hbNEBZsSPKBrZ7F) @tusharg I believe you should just have to replace #11 with the following - I got this by examining the code and the migrations guide. However, still have not been able to get it to work as I'm getting other errors so let me know if this works for you: ``` # 11. config_json = { 'support_revocation': False } print_log('\n11. Creating and storing CRED DEFINITION using anoncreds as Trust Anchor, for the given Schema\n') claim_def_json = await anoncreds.issuer_create_and_store_credential_def(wallet_handle, trust_anchor_did, json.dumps(schema), 'Test', 'CL', json.dumps(config_json)) ```

trthhrtz (Wed, 13 Jun 2018 18:20:07 GMT):
@json 10 which how-to file are you trying to launch?

trthhrtz (Wed, 13 Jun 2018 18:23:24 GMT):
@tusharg try this for step 11: ``` # 11. print_log('\n11. Creating and storing CRED DEFINITION using anoncreds as Trust Anchor, for the given Schema\n') cred_def_tag = 'cred_def_tag' cred_def_type = 'CL' cred_def_config = json.dumps({"support_revocation": False}) (cred_def_id, cred_def_json) = await anoncreds.issuer_create_and_store_credential_def(wallet_handle, trust_anchor_did, json.dumps(schema_data), cred_def_tag, cred_def_type, cred_def_config) print_log('Credential definition: ') pprint.pprint(json.loads(cred_def_json)) ```

Aswath8687 (Wed, 13 Jun 2018 21:22:14 GMT):
Has joined the channel.

json (Wed, 13 Jun 2018 21:36:44 GMT):
@trthhrtz Seems to be having the issue with all of the Python how-tos . Even just the basic write_did one (I changed genesis_file_path). https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/write-did-and-query-verkey/python/write_did_and_query_verkey.py

ksh (Thu, 14 Jun 2018 02:50:12 GMT):
Has joined the channel.

dungnguyen116 (Thu, 14 Jun 2018 03:00:48 GMT):
indy_loop_callback: Function returned error 307 Error occurred: ErrorCode.PoolLedgerTimeout

dungnguyen116 (Thu, 14 Jun 2018 03:00:59 GMT):
anyone help me for this problem ?

dungnguyen116 (Thu, 14 Jun 2018 03:02:02 GMT):
i changed ip from "10.0.0.2" to "127.0.0.1" but it still not work :(

nbxtruong (Thu, 14 Jun 2018 03:18:24 GMT):
Has joined the channel.

nbxtruong (Thu, 14 Jun 2018 03:50:38 GMT):
_indy_loop_callback: Function returned error 306 Error occurred: ErrorCode.PoolLedgerConfigAlreadyExistsError _indy_loop_callback: Function returned error 306 Error occurred: ErrorCode.PoolLedgerConfigAlreadyExistsError _indy_loop_callback: Function returned error 306 Error occurred: ErrorCode.PoolLedgerConfigAlreadyExistsError _indy_loop_callback: Function returned error 306 Error occurred: ErrorCode.PoolLedgerConfigAlreadyExistsError _indy_loop_callback: Function returned error 306 Error occurred: ErrorCode.PoolLedgerConfigAlreadyExistsError _indy_loop_callback: Function returned error 306 Error occurred: ErrorCode.PoolLedgerConfigAlreadyExistsError _indy_loop_callback: Function returned error 306 Error occurred: ErrorCode.PoolLedgerConfigAlreadyExistsError

nbxtruong (Thu, 14 Jun 2018 03:50:38 GMT):
indy_loop_callback: Function returned error 306 Error occurred: ErrorCode.PoolLedgerConfigAlreadyExistsError

nbxtruong (Thu, 14 Jun 2018 03:52:33 GMT):
I have error 306. How can I fix it?

trthhrtz (Thu, 14 Jun 2018 04:33:34 GMT):
@nbxtruong ``` try: await pool.create_pool_ledger_config(config_name=pool_name, config=pool_config) except IndyError: await pool.delete_pool_ledger_config(config_name=pool_name) await pool.create_pool_ledger_config(config_name=pool_name, config=pool_config) ```

trthhrtz (Thu, 14 Jun 2018 04:33:34 GMT):
@nbxtruong, if you use python version ``` try: await pool.create_pool_ledger_config(config_name=pool_name, config=pool_config) except IndyError: await pool.delete_pool_ledger_config(config_name=pool_name) await pool.create_pool_ledger_config(config_name=pool_name, config=pool_config) ```

dungnguyen116 (Thu, 14 Jun 2018 07:47:54 GMT):
i got a problem when running "write schema and cred def.py"

dungnguyen116 (Thu, 14 Jun 2018 07:47:57 GMT):
AttributeError: module 'indy.anoncreds' has no attribute 'issuer_create_and_store_claim_def'

dungnguyen116 (Thu, 14 Jun 2018 07:48:21 GMT):
File "write_schema_and_cred_def.py", line 116, in write_schema_and_cred_def claim_def_json = await anoncreds.issuer_create_and_store_claim_def(wallet_handle, trust_anchor_did, json.dumps(schema), 'CL', False) AttributeError: module 'indy.anoncreds' has no attribute 'issuer_create_and_store_claim_def'

tusharg (Thu, 14 Jun 2018 08:05:53 GMT):
@trthhrtz @json 10 Thanks!!! write_schema_and_cred_def is working now. However again, the next how-tos again have a multitude of problems. Do you have some updated versions of the how-tos? Again, thanks.

dungnguyen116 (Thu, 14 Jun 2018 08:55:54 GMT):
@tusharg thank you

dungnguyen116 (Thu, 14 Jun 2018 08:58:14 GMT):
but it still not working :(

tusharg (Thu, 14 Jun 2018 11:09:12 GMT):
@dungnguyen116 replace step #11 with what @trthhrtz wrote above: ``` # 11. print_log('\n11. Creating and storing CRED DEFINITION using anoncreds as Trust Anchor, for the given Schema\n') cred_def_tag = 'cred_def_tag' cred_def_type = 'CL' cred_def_config = json.dumps({"support_revocation": False}) (cred_def_id, cred_def_json) = await anoncreds.issuer_create_and_store_credential_def(wallet_handle, trust_anchor_did, json.dumps(schema_data), cred_def_tag, cred_def_type, cred_def_config) print_log('Credential definition: ') pprint.pprint(json.loads(cred_def_json))```

AvikHazra (Thu, 14 Jun 2018 12:03:28 GMT):
hello, I run docker from -> https://github.com/hyperledger/indy-sdk/tree/master/doc/getting-started Attaching to indy_pool, getting_started indy_pool | 2018-06-14 11:54:31,825 CRIT Set uid to user 1000 getting_started | [I 11:54:33.398 NotebookApp] Writing notebook server cookie secret to /home/indy/.local/share/jupyter/runtime/notebook_cookie_secret getting_started | [I 11:54:33.707 NotebookApp] Serving notebooks from local directory: /home/indy getting_started | [I 11:54:33.707 NotebookApp] 0 active kernels getting_started | [I 11:54:33.707 NotebookApp] The Jupyter Notebook is running at: getting_started | [I 11:54:33.707 NotebookApp] http://ee88de8db1dc:8888/?token=db29c825011e8cb5ac389b3f97ca93c065392a4188698de1 getting_started | [I 11:54:33.708 NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation). getting_started | [W 11:54:33.709 NotebookApp] No web browser found: could not locate runnable browser. getting_started | [C 11:54:33.710 NotebookApp] getting_started | getting_started | Copy/paste this URL into your browser when you connect for the first time, getting_started | to login with a token: getting_started | http://ee88de8db1dc:8888/?token=db29c825011e8cb5ac389b3f97ca93c065392a4188698de1&token=db29c825011e8cb5ac389b3f97ca93c065392a4188698de1 After that what to do ? When open the given URL, its returning "This site can’t be reached". What to do ? please help.

Artemkaaas (Thu, 14 Jun 2018 13:19:07 GMT):
hi @AvikHazra for this link `http://ee88de8db1dc:8888/?token=db29c825011e8cb5ac389b3f97ca93c065392a4188698de1` try to replace ` http://ee88de8db1dc:8888` on ` localhost:8888/`

AvikHazra (Thu, 14 Jun 2018 13:24:43 GMT):
@Artemkaaas thanks for your reply. I already did that. It showing the index page of MAMP i.e the htdocs folder

AvikHazra (Thu, 14 Jun 2018 13:24:43 GMT):
@Artemkaaas thanks for your reply. I already did that. It showing the index page of MAMP i.e the htdocs folder. What I did wrong ? please help me

AvikHazra (Thu, 14 Jun 2018 13:32:35 GMT):
@Artemkaaas Thanks. Its working after stop the MAMP server.

ksh (Thu, 14 Jun 2018 13:52:53 GMT):
I have installed indy-node by docker on the MAC. But what is the next step I can follow to practice the Alice example? Any URL?

ksh (Thu, 14 Jun 2018 13:53:07 GMT):
I need a step by step guide.

smithbk (Thu, 14 Jun 2018 17:50:32 GMT):
Hi, could someone help with https://jira.hyperledger.org/browse/INDY-1412

smithbk (Thu, 14 Jun 2018 18:09:09 GMT):
Also, I am using the stable branch of libindy as follows: ```RUN apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 68DB5E88 \ && add-apt-repository "deb https://repo.sovrin.org/sdk/deb xenial stable" \ && apt-get update \ && apt-get install -y \ libindy ``` How do I map that to a github tag for indy-sdk?

smithbk (Thu, 14 Jun 2018 18:09:14 GMT):
```$ git tag v1.0.0 v1.0.1 v1.0.1-rc2 v1.1.0 v1.2.0 v1.3.0 v1.4.0 ```

haggs (Thu, 14 Jun 2018 20:43:02 GMT):
@smithbk looking at the ci-cd workflow there seems to be no system

haggs (Thu, 14 Jun 2018 20:43:07 GMT):
"stable - stable releases These channels don't correspond exactly to branches; the stable channel is just tags in the rc branch, right now. In the future, this may change."

haggs (Thu, 14 Jun 2018 20:43:14 GMT):
I'd imagine stable is 1.4.0

haggs (Thu, 14 Jun 2018 20:43:29 GMT):
But looking at CHANGELOG.md

haggs (Thu, 14 Jun 2018 20:43:34 GMT):
It looks like not

haggs (Thu, 14 Jun 2018 20:44:00 GMT):
https://github.com/hyperledger/indy-sdk/tree/master/doc

haggs (Thu, 14 Jun 2018 20:44:02 GMT):
CHeck this out

Vikrum (Thu, 14 Jun 2018 22:03:46 GMT):
Has joined the channel.

mitrailer (Thu, 14 Jun 2018 22:42:30 GMT):
Has joined the channel.

dungnguyen116 (Fri, 15 Jun 2018 03:16:02 GMT):
@tusharg many many thank <3

dungnguyen116 (Fri, 15 Jun 2018 03:32:02 GMT):
``` Traceback (most recent call last): File "negotiate_proof.py", line 192, in main() File "negotiate_proof.py", line 187, in main loop.run_until_complete(proof_negotiation()) File "/usr/lib/python3.6/asyncio/base_events.py", line 467, in run_until_complete return future.result() File "negotiate_proof.py", line 44, in proof_negotiation await wallet.create_wallet(pool_name, issuer_wallet_name, None, None, None) File "/home/dungnt/Blockchain/indy-sdk/wrappers/python/indy/wallet.py", line 45, in create_wallet c_credentials = c_char_p(credentials.encode('utf-8')) AttributeError: 'NoneType' object has no attribute 'encode' ```

dungnguyen116 (Fri, 15 Jun 2018 03:32:56 GMT):
i got this problem with both issue-credential and negotiate-proof

dungnguyen116 (Fri, 15 Jun 2018 03:33:05 GMT):
anyone can help me for this one ?

mboyd (Fri, 15 Jun 2018 03:49:10 GMT):
@AvikHazra Have you figured out the getting started guide yet?

mboyd (Fri, 15 Jun 2018 03:49:27 GMT):
I'm looking into it now. This is something that I've wanted to fix for a LONG time

mboyd (Fri, 15 Jun 2018 03:52:53 GMT):
@ksh check out https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md

trthhrtz (Fri, 15 Jun 2018 04:08:23 GMT):
@dungnguyen116 , check this commit https://github.com/hyperledger/indy-sdk/pull/864/commits/818bfe6bacc17e951973e98a1a784d4387665cb0 , you need to declare and add `wallet_credentials` to methods associated with wallet

ksh (Fri, 15 Jun 2018 04:27:01 GMT):
@mboyd Is there more friendly guide for the newbie? a little like the URL:https://github.com/hyperledger/indy-node/blob/master/getting-started.md

ksh (Fri, 15 Jun 2018 04:27:42 GMT):
@mboyd In your URL, there is few step-by-step operation I can follow.

mboyd (Fri, 15 Jun 2018 04:49:51 GMT):
Unfortunately, we don't have a simple way to get onboarded to the concepts and the code in a smooth way. Does anyone have any tips on how to understand these concepts in a better way? @ksh if you want to help me make an awesome guide, I'm going to take this crrent getting started guide and make it into an interactive jupyter notebook. Here is the [current Jupyter notebook](https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/run-getting-started.md) Here is the [guide in jupyter notebook format](https://github.com/michaeldboyd/indy-sdk/tree/feature/jupyter-guide/doc/getting-started/jupyter-guide) I want to take these, simplify a ton, and combine them into one guide, then deploy it to the cloud

AvikHazra (Fri, 15 Jun 2018 04:51:02 GMT):
@mboyd I`m looking into the getting-start but can`t figure out how to use it.

mboyd (Fri, 15 Jun 2018 04:52:17 GMT):
Yeah, I just ran it. It's still broken. But I think we can pretty easily fix it.

AvikHazra (Fri, 15 Jun 2018 04:53:34 GMT):
yes. we can. what about if we can make some APIs for all the methods ?

mboyd (Fri, 15 Jun 2018 04:53:39 GMT):
Here's the ticket I logged: https://jira.hyperledger.org/browse/IS-673

mboyd (Fri, 15 Jun 2018 04:54:45 GMT):
I got busy and wasn't able to follow up on it, but this is the progress we made. I think it's just a mix up of IP addresses for the test network. the network runs on 10.0.0.2, but the dockerfile is looking for it at 127.0.0.1. Unfortunately, I don't know enough about docker to fix it

AvikHazra (Fri, 15 Jun 2018 04:55:16 GMT):
same for me.

mboyd (Fri, 15 Jun 2018 04:57:08 GMT):
Let

mboyd (Fri, 15 Jun 2018 04:59:44 GMT):
K. @AvikHazra and @ksh (if interested) let's keep pursuing this bug. If willing, I think we can improve developer experience for many people who come after us

AvikHazra (Fri, 15 Jun 2018 05:00:04 GMT):
yes. sure.

ksh (Fri, 15 Jun 2018 05:56:00 GMT):
@mboyd I think the guide of (https://github.com/hyperledger/indy-node/blob/master/getting-started.md) looks pretty good. In my mind , a good guide will not try to interpret the concepts at first for the newbie. Just make them finish a demo easily by themselves and they will learn a lot from their practice. I hope I can contribute such a guide after I can finish my own practice.

ashcherbakov (Fri, 15 Jun 2018 07:01:48 GMT):
As was announced, the next stable release 1.4 of Indy-Node (which will be issued in a week or so), contains some breaking changes related to transaction format. The changes are done for a better versioning support (that is to support compatibility in future) and more readable format of data (separating payload data, metadata and signature). There will a new stable release of LibIndy (1.5) which should be used to work with IndyNode 1.4. *General* - By default LibIndy 1.5 will be compatible with IndyNode 1.3, and not 1.4 - LibIndy 1.5 can become compatible with IndyNode 1.4 if `indy_set_protocol_version(2)` is called during app initialization. *Guideline for applications* - An application can freely update to LibIndy 1.5 and still use stable Node 1.3 - If an app wants to work with the latest master or Stable Node 1.4, then it needs to - support breaking changes (there are not so many, mostly a new reply for write txns as txn format is changed) There is a migration guide for Indy-Node 1.3 to 1.4: https://github.com/hyperledger/indy-node/blob/master/docs/1.3_to_1.4_migration_guide.md - call `indy_set_protocol_version(2)` during app initialization

Dominic (Fri, 15 Jun 2018 14:41:37 GMT):
Has joined the channel.

Vikrum (Fri, 15 Jun 2018 14:42:44 GMT):
@ksh I was able to get the infra setup for Alice's examples using this guide: https://github.com/evernym/sovrin-environments/blob/stable/vagrant/training/vb-multi-vm/TestIndyClusterSetup.md

mboyd (Fri, 15 Jun 2018 16:37:57 GMT):
@Vikrum I believe that guide is deprecated, and may not work with the newer Indy CLI that has been released in the indy-sdk repository.

mboyd (Fri, 15 Jun 2018 16:44:53 GMT):
If you are looking for coding examples, I think the best resource I've found is the [python samples](https://github.com/hyperledger/indy-sdk/tree/master/samples/python), but I haven't run them in a month or two, so not sure if they're as fresh as they once were

mhailstone (Fri, 15 Jun 2018 17:51:04 GMT):
wallet

esplinr (Fri, 15 Jun 2018 18:56:44 GMT):
We have a bunch of work to update the various guides and examples, and then to keep them current. Help Wanted! IS-770 grin

smithbk (Fri, 15 Jun 2018 19:22:56 GMT):
I'm blocked on the following. Could someone help? https://jira.hyperledger.org/browse/INDY-1412

danielhardman (Fri, 15 Jun 2018 19:49:40 GMT):
I was mentioned in this channel recently, but after some skimming, I can't find where. If someone needs me, please ping me again, because I will forget, otherwise.

esplinr (Fri, 15 Jun 2018 20:22:58 GMT):
@smithbk It's unlikely anyone will be able to help you with that before Monday.

esplinr (Fri, 15 Jun 2018 20:24:45 GMT):
But I'll ask around and see.

esplinr (Fri, 15 Jun 2018 20:25:02 GMT):
For anyone interested in claims exchange: https://medium.com/evernym/open-source-tools-for-creating-digital-identities-b7ca49d0e7d4

smithbk (Fri, 15 Jun 2018 20:37:11 GMT):
@esplinr thanks

esplinr (Fri, 15 Jun 2018 20:51:23 GMT):
We suspect it's a problem with your environment, but we can't look into it in enough detail to be su

esplinr (Fri, 15 Jun 2018 20:51:23 GMT):
We suspect it's a problem with your environment, but we can't look into it in enough detail to be sure.

esplinr (Fri, 15 Jun 2018 20:51:23 GMT):
We suspect it's a problem with your environment, but we can't look into it in enough detail to be sure. @smithbk

danielhardman (Fri, 15 Jun 2018 22:39:07 GMT):
Had some requests for a link to the meeting we had on wallet design the other day. Here is the recording (meat of the meeting begins about 5 min in): https://drive.google.com/open?id=172rPrSxaiipjD9WaM-mMGCYhj8WqyXm_ And here is the slide deck: http://bit.ly/2JUcliT HIPE will be raised shortly.

nbxtruong (Sat, 16 Jun 2018 16:25:44 GMT):
Traceback (most recent call last): File "issue_credential.py", line 196, in main() File "issue_credential.py", line 191, in main loop.run_until_complete(issue_credential()) File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step result = coro.send(None) File "issue_credential.py", line 144, in issue_credential claim_offer_json = await anoncreds.issuer_create_claim_offer(wallet_handle, schema_json, trust_anchor_did, prover_did) AttributeError: module 'indy.anoncreds' has no attribute 'issuer_create_claim_offer'

nbxtruong (Sat, 16 Jun 2018 16:26:51 GMT):
Help me, I run issue-credential.py and I have this error on step 11

nbxtruong (Sat, 16 Jun 2018 16:28:54 GMT):
function issuer_create_claim_offer() is not defined inside anoncreds.py

nbxtruong (Sat, 16 Jun 2018 16:29:05 GMT):
I run libindy 1.4.0

dungnguyen116 (Sat, 16 Jun 2018 18:42:54 GMT):
``` # 11. config_json = { 'support_revocation': False } print_log('\n11. Creating and storing CRED DEFINITION using anoncreds as Trust Anchor, for the given Schema\n') claim_def_json = await anoncreds.issuer_create_and_store_credential_def(wallet_handle, trust_anchor_did, json.dumps(schema), 'Test', 'CL', json.dumps(config_json)) ```

dungnguyen116 (Sat, 16 Jun 2018 18:42:54 GMT):
# 11. print_log('\n11. Creating and storing CRED DEFINITION using anoncreds as Trust Anchor, for the given Schema\n') cred_def_tag = 'cred_def_tag' cred_def_type = 'CL' cred_def_config = json.dumps({"support_revocation": False}) (cred_def_id, cred_def_json) = await anoncreds.issuer_create_and_store_credential_def(wallet_handle, trust_anchor_did, json.dumps(schema_data), cred_def_tag, cred_def_type, cred_def_config) print_log('Credential definition: ') pprint.pprint(json.loads(cred_def_json))

dungnguyen116 (Sat, 16 Jun 2018 18:42:54 GMT):
``` # 11. print_log('\n11. Creating and storing CRED DEFINITION using anoncreds as Trust Anchor, for the given Schema\n') cred_def_tag = 'cred_def_tag' cred_def_type = 'CL' cred_def_config = json.dumps({"support_revocation": False}) (cred_def_id, cred_def_json) = await anoncreds.issuer_create_and_store_credential_def(wallet_handle, trust_anchor_did, json.dumps(schema_data), cred_def_tag, cred_def_type, cred_def_config) print_log('Credential definition: ') pprint.pprint(json.loads(cred_def_json))

dungnguyen116 (Sat, 16 Jun 2018 18:44:29 GMT):
@nbxtruong u can try this one, replace #11

stanleyc-trustscience (Sat, 16 Jun 2018 18:46:19 GMT):
Hello, need some expert iOS help. I'm currently working with iOS wrapper for indy-sdk. I'm referencing indy-sdk's pod via Cocoapod, and when I try to run the code in a simulator, I'm running into the following runtime error in xcode. Tried different things from google, but no luck. Any help is appreciated ``` dyld: Library not loaded: @rpath/libswiftCore.dylib Referenced from: /Users/stanley/Library/Developer/CoreSimulator/Devices/2C4F45FF-C0C1-49D8-808A-23EBEFFCF007/data/Containers/Bundle/Application/2315943B-2E0C-4AD2-A19C-2E011DB8F267/indytest2.app/Frameworks/Indy.framework/Indy Reason: image not found (lldb) ```

stanleyc-trustscience (Sat, 16 Jun 2018 19:55:09 GMT):
I'm using xcode 9.4.1

tomislav (Sun, 17 Jun 2018 03:12:04 GMT):
@stanleyc-trustscience Were you able to build the Indy project into a framework? If yes, you can reference that directly in your ios project

ksh (Sun, 17 Jun 2018 04:51:17 GMT):
I have already installed docker and indy-sdk successfully on my Mac. But how can I log into log into the Indy Client docker container after I run "docker run -d --ip="10.0.0.2" --net=indy_pool_network indy_pool".

tomislav (Sun, 17 Jun 2018 13:45:33 GMT):
`docker exec -i -t container_name /bin/bash`

srottem (Mon, 18 Jun 2018 07:09:43 GMT):
The latest .NET package (1.4.0) has been released on nuget.

AxelNennker (Mon, 18 Jun 2018 09:46:30 GMT):
A minor thing... There are a ton of new warnings when compiling libindy like unused imports and such. They make spotting the real issues harder. I somebody already fixing them?

gudkov (Mon, 18 Jun 2018 12:14:33 GMT):
@AxelNennker we plan to fix them soon. If you want to help we will appreciate.

gudkov (Mon, 18 Jun 2018 12:22:14 GMT):
@AxelNennker @Artemkaaas is working on warnings

AxelNennker (Mon, 18 Jun 2018 16:32:45 GMT):
Getting rid of most warnings when compiling libindy https://github.com/hyperledger/indy-sdk/pull/881

wolili (Mon, 18 Jun 2018 17:43:58 GMT):
Hi, based on the W3C Verifiable Claim specification (https://www.w3.org/TR/verifiable-claims-data-model/) I wanted to create a claim like in Example 5 where I have fields and subfields (like passport has a type, issuer etc...) . ``` "claim": { "id": "did:example:ebfeb1f712ebc6f1c276e12ec21", "name": "Alice Bobman", "birthDate": "1985-12-14", "gender": "female", "nationality": { "name": "United States" }, "passport": { "type": "Passport", "name": "United States Passport", "documentId": "123-45-6789", "issuer": "https://example.gov", "issued": "2010-01-07T01:02:03Z", "expires": "2020-01-07T01:02:03Z" } }, ``` But when I specify some JSON structure including quotation marks I get an `InvalidStructureException: A value being processed is not valid`. Do I have to specify those subfields in the Schema? How can I create a claim with nested fields, is there some example how such a call would look like?

dungnguyen116 (Tue, 19 Jun 2018 08:16:02 GMT):
(node:11738) UnhandledPromiseRejectionWarning: IndyError: LedgerInvalidTransaction at Object.callback (/home/nbxtruong/Documents/Hyperledger-Indy-NodeJS/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10)

dungnguyen116 (Tue, 19 Jun 2018 08:16:02 GMT):
``` (node:11738) UnhandledPromiseRejectionWarning: IndyError: LedgerInvalidTransaction at Object.callback (/home/nbxtruong/Documents/Hyperledger-Indy-NodeJS/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10)

dungnguyen116 (Tue, 19 Jun 2018 08:16:02 GMT):
how can i fix this problem ?? ```(node:11738) UnhandledPromiseRejectionWarning: IndyError: LedgerInvalidTransaction at Object.callback (/home/nbxtruong/Documents/Hyperledger-Indy-NodeJS/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10)

sklump (Tue, 19 Jun 2018 10:51:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=paeeQHrotsiXNugaf) @wolili As far as I know, indy-sdk schemata are simple attribute: value only. Values encapsulate raw (string) and encoded (numeric string) pairs. To pack nested values, you could json-dump into strings as raw values and unpack on parse.

sklump (Tue, 19 Jun 2018 10:51:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=paeeQHrotsiXNugaf) @wolili indy-sdk schemata are simple attribute: value only. Values encapsulate raw (string) and encoded (numeric string) pairs. To pack nested values, you could json-dump into strings as raw values and json-load to unpack on parsing.

mitrailer (Tue, 19 Jun 2018 17:07:22 GMT):
Hi I'm doing the Java "how to" Save a Schema and Credential Definition in the step 3 (https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/save-schema-and-cred-def/java/step3.java) I got the following error: ` Exception in thread "main" java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.InvalidStructureException: A value being processed is not valid. at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895) at com.blockchain.SaveSchemaAndCredDef.demo(SaveSchemaAndCredDef.java:80) at com.blockchain.App.main(App.java:11) Caused by: org.hyperledger.indy.sdk.InvalidStructureException: A value being processed is not valid. at org.hyperledger.indy.sdk.IndyException.fromSdkError(IndyException.java:69) at org.hyperledger.indy.sdk.IndyJava$API.checkCallback(IndyJava.java:90) at org.hyperledger.indy.sdk.ledger.Ledger.access$700(Ledger.java:24) at org.hyperledger.indy.sdk.ledger.Ledger$4.callback(Ledger.java:91) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:520) at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:551) I'm using this dependency in the pom of my project org.hyperledger indy 1.4.0-dev-581 Any help is apreaciated

mitrailer (Tue, 19 Jun 2018 17:07:22 GMT):
Hi I'm doing the Java "how to" Save a Schema and Credential Definition in the step 3 (https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/save-schema-and-cred-def/java/step3.java) I got the following error: ` Exception in thread "main" java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.InvalidStructureException: A value being processed is not valid. at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895) at com.blockchain.SaveSchemaAndCredDef.demo(SaveSchemaAndCredDef.java:80) at com.blockchain.App.main(App.java:11) Caused by: org.hyperledger.indy.sdk.InvalidStructureException: A value being processed is not valid. at org.hyperledger.indy.sdk.IndyException.fromSdkError(IndyException.java:69) at org.hyperledger.indy.sdk.IndyJava$API.checkCallback(IndyJava.java:90) at org.hyperledger.indy.sdk.ledger.Ledger.access$700(Ledger.java:24) at org.hyperledger.indy.sdk.ledger.Ledger$4.callback(Ledger.java:91) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:520) at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:551) ` I'm using this dependency in the pom of my project org.hyperledger indy 1.4.0-dev-581 Any help is apreaciated

mitrailer (Tue, 19 Jun 2018 17:07:22 GMT):
Hi I'm doing the Java "how to" Save a Schema and Credential Definition in the step 3 (https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/save-schema-and-cred-def/java/step3.java) I got the following error: `Exception in thread "main" java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.InvalidStructureException: A value being processed is not valid. at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895) at com.blockchain.SaveSchemaAndCredDef.demo(SaveSchemaAndCredDef.java:80) at com.blockchain.App.main(App.java:11) Caused by: org.hyperledger.indy.sdk.InvalidStructureException: A value being processed is not valid. at org.hyperledger.indy.sdk.IndyException.fromSdkError(IndyException.java:69) at org.hyperledger.indy.sdk.IndyJava$API.checkCallback(IndyJava.java:90) at org.hyperledger.indy.sdk.ledger.Ledger.access$700(Ledger.java:24) at org.hyperledger.indy.sdk.ledger.Ledger$4.callback(Ledger.java:91) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:520) at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:551)```` ``` I'm using this dependency in the pom of my project org.hyperledger indy 1.4.0-dev-581 Any help is apreaciated

mitrailer (Tue, 19 Jun 2018 17:07:22 GMT):
Hi I'm doing the Java "how to" Save a Schema and Credential Definition in the step 3 (https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/save-schema-and-cred-def/java/step3.java) I got the following error: ``` Exception in thread "main" java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.InvalidStructureException: A value being processed is not valid. at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895) at com.blockchain.SaveSchemaAndCredDef.demo(SaveSchemaAndCredDef.java:80) at com.blockchain.App.main(App.java:11) Caused by: org.hyperledger.indy.sdk.InvalidStructureException: A value being processed is not valid. at org.hyperledger.indy.sdk.IndyException.fromSdkError(IndyException.java:69) at org.hyperledger.indy.sdk.IndyJava$API.checkCallback(IndyJava.java:90) at org.hyperledger.indy.sdk.ledger.Ledger.access$700(Ledger.java:24) at org.hyperledger.indy.sdk.ledger.Ledger$4.callback(Ledger.java:91) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:520) at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:551) ``` I'm using this dependency in the pom of my project ` org.hyperledger indy 1.4.0-dev-581 ` Any help is appreciated

tomislav (Tue, 19 Jun 2018 19:05:54 GMT):
@mitrailer The how-to is outdated. The schema json required has been updated. It now requires "id" and "ver" in addition to name, version and attr_names attributes.

sklump (Tue, 19 Jun 2018 19:15:26 GMT):
there is a helper at anoncreds.issuer_create_schema()

PhillipGibb (Tue, 19 Jun 2018 19:51:14 GMT):
A question about ledgering your DID: In the getting started tutorial with Alice and Fabre College Alice can look up in the Sovrin Ledger with Fabre's DID, also it is possible that Alice can have a ledgered DID before the connection was made. But how is the DID ledgered outside of a pairwise relationship? This does not seem obvious from the SDK. It does seem that an organisation can get setup as a Trust Anchor and that was have their DID ledgered for public retrieval, but that seems to be an external and administrative process. What if I want to connect to someone? I supply signed proof etc but how can someone verify that it is me without going to lookup my public key on the ledger?

smithbk (Tue, 19 Jun 2018 19:57:07 GMT):
I mentioned this last week, but this continues to block me. Any help is appreciated. https://jira.hyperledger.org/browse/IS-784

gudkov (Wed, 20 Jun 2018 08:40:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9NjJeogNYECyhZh9s) @smithbk You use stable libindy with master version of python wrapper

Qiu (Wed, 20 Jun 2018 10:10:27 GMT):
Has joined the channel.

Qiu (Wed, 20 Jun 2018 10:36:41 GMT):
I want to know where to run a python test case

Qiu (Wed, 20 Jun 2018 10:36:41 GMT):
I want to know where to run a python test case？docker?

gudkov (Wed, 20 Jun 2018 10:50:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=QnCiesftYk3d43wJn) @Qiu You can run it locally (environment configuration is simple) or in Docker if you want

Qiu (Wed, 20 Jun 2018 10:59:44 GMT):
@

ksh (Wed, 20 Jun 2018 10:59:54 GMT):
Hello everyone. I need some help. I just login into my docker by "docker exec -i -t ed55f05825e3 /bin/bash" and run "indy" in my docker. But indy hangs and no any response. My operation and output as the following: kshdeMac-mini:indy-sdk kangshuo$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES ed55f05825e3 indy_pool "/usr/bin/supervisord" 22 seconds ago Up 20 seconds 9701-9708/tcp laughing_mclean kshdeMac-mini:indy-sdk kangshuo$ docker exec -i -t ed55f05825e3 /bin/bash indy@ed55f05825e3:/$ ls bin dev home lib64 mnt proc run srv tmp var boot etc lib media opt root sbin sys usr indy@ed55f05825e3:/$ indy Loading module /usr/local/lib/python3.5/dist-packages/config/config-crypto-example1.py Module loaded. This client is deprecated! Please, use the new libindy-based CLI: https://github.com/hyperledger/indy-sdk/tree/master/cli Indy-CLI (c) 2017 Evernym, Inc. Type 'help' for more information. Running Indy 1.3.446

gudkov (Wed, 20 Jun 2018 11:20:32 GMT):
@ksh It is hard to get what docker image and instruction you use. There are a lot of different docker files and containers for different purposes

ksh (Wed, 20 Jun 2018 11:22:34 GMT):
@gudkov I just run the ci/indy-pool.dockerfile as the instruction. The code repository I just cloned and use master branch.

BreizhIndy (Wed, 20 Jun 2018 12:20:22 GMT):
Hello when i try to connect my nodejs app to my ledger in docker. I receive the following error:

BreizhIndy (Wed, 20 Jun 2018 12:21:31 GMT):
indy-agent@0.0.0 start /home/indyana/indy-agent/nodejs > node ./bin/www { IndyError: CommonInvalidState at Object.callback (/home/indyana/indy-agent/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10) name: 'IndyError', message: 'CommonInvalidState', indyCode: 112, indyName: 'CommonInvalidState' }

BreizhIndy (Wed, 20 Jun 2018 12:22:11 GMT):
I suspect it's an error from the libindy but I don't know how to check

gudkov (Wed, 20 Jun 2018 12:43:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=79PnKyjoKegLwJJQX) @BreizhIndy You need to start from enabling logging. set env variable RUST_LOG=trace and you will find error messages. Most probably your ledger and sdk have different genesis transactions

BreizhIndy (Wed, 20 Jun 2018 13:19:03 GMT):
Thanks @gudkov: i was able to trace and I get this error src/services/pool/mod.rs:242 | process_actions - Invalid library state: Ledger merkle tree doesn't acceptable for current tree. - Is it related to genesis transaction and how can I solve this ?

gudkov (Wed, 20 Jun 2018 13:20:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JqgyYLH4fCE8N3kpH) @BreizhIndy It just means that Pool uses different genesis transactions that Indy SDK. Most probably ip addresses are different.

gudkov (Wed, 20 Jun 2018 13:21:12 GMT):
@BreizhIndy On what OS you are? What is exactly commands do you use? What is conent of genesis files?

gudkov (Wed, 20 Jun 2018 13:23:32 GMT):
I suggest to look https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker section of readme.

BreizhIndy (Wed, 20 Jun 2018 13:25:13 GMT):
I built my pool as followed: docker network create --subnet 10.0.0.0/8 indy_pool_network docker build --build-arg pool_ip=10.0.0.2 -f ci/indy-pool.dockerfile -t indy_pool . docker run -d --ip="10.0.0.2" --net=indy_pool_network indy_pool

gudkov (Wed, 20 Jun 2018 13:25:29 GMT):
Nodes should be available to each other by the same ips as to libindy. And sometimes it is tricky to expose these ips form docker on some platforms.

gudkov (Wed, 20 Jun 2018 13:25:53 GMT):
In your case Node use 10.0.0.0 ip in genesis transactions

BreizhIndy (Wed, 20 Jun 2018 13:25:56 GMT):
and i call it in my nodejs app folder : TEST_POOL_IP=10.0.0.2 npm start

BreizhIndy (Wed, 20 Jun 2018 13:26:14 GMT):
(my OS is ubuntu 16.04)

gudkov (Wed, 20 Jun 2018 13:26:36 GMT):
is your app read TEST_POOL_IP=10.0.0.2 in some way ???

gudkov (Wed, 20 Jun 2018 13:26:48 GMT):
How you create pool configuration?

BreizhIndy (Wed, 20 Jun 2018 13:29:38 GMT):
in a file config.js I use: testPoolIP : process.env.TEST_POOL_IP (it's the code from https://github.com/hyperledger/indy-agent/nodejs btw)

BreizhIndy (Wed, 20 Jun 2018 13:30:35 GMT):
in a file config.js I use: testPoolIP : process.env.TEST_POOL_IP (it's the code from https://github.com/hyperledger/indy-agent/tree/master/nodejs btw)

gudkov (Wed, 20 Jun 2018 14:35:12 GMT):
and how testPoolIP is used?

BreizhIndy (Wed, 20 Jun 2018 15:11:43 GMT):
It's used here : async function poolGenesisTxnData() { let poolIp = config.testPoolIp; return `{"data":{"alias":"Node1","blskey":"4N8aUN...aLKm3Ba","client_ip":"${poolIp}","client_port":9702,"node_ip":"${poolIp}","node_port":9701,"services":["VALIDATOR"]},"dest":"Gw6p...ds81Y","txnId":"fea8...62","type":"0"}

BreizhIndy (Wed, 20 Jun 2018 15:11:48 GMT):
... }

gudkov (Wed, 20 Jun 2018 15:13:16 GMT):
I suggest to log result from this function. After this go inside if your docker container, find genesis files that nodes use and check the difference.

gudkov (Wed, 20 Jun 2018 15:13:16 GMT):
I suggest to log result from this function. After this go inside your docker container, find genesis files that nodes use and check the difference.

BreizhIndy (Wed, 20 Jun 2018 15:14:07 GMT):
ok thanks for the help I'll try that

nage (Thu, 21 Jun 2018 02:01:24 GMT):
There is now an indy-agent JIRA repo here https://jira.hyperledger.org/projects/IA/summary

nage (Thu, 21 Jun 2018 02:02:34 GMT):
Once we have it setup property we will move agent related tasks there (we also expect crypto related tickets will move to the hyperledger shared crypto library where what are now indy-crypto tickets can live once that project gets underway).

AvikHazra (Thu, 21 Jun 2018 09:55:55 GMT):
Hello, I`m trying to build sdk with the help of https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md. It was run successfully previously. But now when i`m trying it`s returning some warning. warning: unused import: `sodiumoxide::crypto::auth::hmacsha256` --> src/utils/crypto/chacha20poly1305_ietf/sodium.rs:3:5 | 3 | use sodiumoxide::crypto::auth::hmacsha256; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: #[warn(unused_imports)] on by default warning: unused imports: `HMACSHA256Key`, `HMACSHA256` --> src/utils/crypto/chacha20poly1305_ietf/sodium.rs:9:33 | 9 | use utils::crypto::hmacsha256::{HMACSHA256, HMACSHA256Key}; | ^^^^^^^^^^ ^^^^^^^^^^^^^ warning: unused import: `utils::crypto::chacha20poly1305_ietf::ChaCha20Poly1305IETF` --> src/services/wallet/storage/default/mod.rs:15:5 | 15 | use utils::crypto::chacha20poly1305_ietf::ChaCha20Poly1305IETF; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ warning: unused import: `sodiumoxide::utils::memzero` --> src/services/wallet/storage/default/mod.rs:20:5 | 20 | use sodiumoxide::utils::memzero; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ warning: unused import: `errors::common::CommonError` --> src/services/wallet/encryption.rs:17:5 | 17 | use errors::common::CommonError; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ warning: unused imports: `decrypt_merged`, `encrypt_as_not_searchable` --> src/services/wallet/export_import.rs:12:36 | 12 | use services::wallet::encryption::{decrypt_merged, decrypt, encrypt_as_not_searchable, derive_key}; | ^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^ warning: unused import: `std` --> src/services/wallet/wallet.rs:3:5 | 3 | use std; | ^^^ warning: unused imports: `Read`, `Write` --> src/services/wallet/wallet.rs:5:15 | 5 | use std::io::{Write,Read}; | ^^^^^ ^^^^ warning: unused import: `serde_json` --> src/services/wallet/wallet.rs:8:5 | 8 | use serde_json; | ^^^^^^^^^^ warning: unused import: `super::storage::StorageEntity` --> src/services/wallet/wallet.rs:16:5 | 16 | use super::storage::StorageEntity; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ warning: unused import: `Path` --> src/services/wallet/mod.rs:17:17 | 17 | use std::path::{Path, PathBuf}; | ^^^^ warning: unused import: `std::mem` --> src/services/wallet/mod.rs:18:5 | 18 | use std::mem; | ^^^^^^^^ warning: unused import: `ChaCha20Poly1305IETF` --> src/services/wallet/mod.rs:29:44 | 29 | use utils::crypto::chacha20poly1305_ietf::{ChaCha20Poly1305IETF, ChaCha20Poly1305IETFKey}; | ^^^^^^^^^^^^^^^^^^^^ warning: unused import: `self::sodiumoxide::utils::memzero` --> src/services/wallet/mod.rs:37:5 | 37 | use self::sodiumoxide::utils::memzero; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ After that when i`m trying to run indy-agent it`s showing ld: library not found for -lindy What is wrong. please help me.

AvikHazra (Thu, 21 Jun 2018 09:55:55 GMT):
Hello, I`m trying to build sdk with the help of https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md. It was run successfully previously. But now when i`m trying returning some warning. warning: unused import: `sodiumoxide::crypto::auth::hmacsha256` --> src/utils/crypto/chacha20poly1305_ietf/sodium.rs:3:5 | 3 | use sodiumoxide::crypto::auth::hmacsha256; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: #[warn(unused_imports)] on by default warning: unused imports: `HMACSHA256Key`, `HMACSHA256` --> src/utils/crypto/chacha20poly1305_ietf/sodium.rs:9:33 | 9 | use utils::crypto::hmacsha256::{HMACSHA256, HMACSHA256Key}; | ^^^^^^^^^^ ^^^^^^^^^^^^^ warning: unused import: `utils::crypto::chacha20poly1305_ietf::ChaCha20Poly1305IETF` --> src/services/wallet/storage/default/mod.rs:15:5 | 15 | use utils::crypto::chacha20poly1305_ietf::ChaCha20Poly1305IETF; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ warning: unused import: `sodiumoxide::utils::memzero` --> src/services/wallet/storage/default/mod.rs:20:5 | 20 | use sodiumoxide::utils::memzero; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ warning: unused import: `errors::common::CommonError` --> src/services/wallet/encryption.rs:17:5 | 17 | use errors::common::CommonError; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^ warning: unused imports: `decrypt_merged`, `encrypt_as_not_searchable` --> src/services/wallet/export_import.rs:12:36 | 12 | use services::wallet::encryption::{decrypt_merged, decrypt, encrypt_as_not_searchable, derive_key}; | ^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^ warning: unused import: `std` --> src/services/wallet/wallet.rs:3:5 | 3 | use std; | ^^^ warning: unused imports: `Read`, `Write` --> src/services/wallet/wallet.rs:5:15 | 5 | use std::io::{Write,Read}; | ^^^^^ ^^^^ warning: unused import: `serde_json` --> src/services/wallet/wallet.rs:8:5 | 8 | use serde_json; | ^^^^^^^^^^ warning: unused import: `super::storage::StorageEntity` --> src/services/wallet/wallet.rs:16:5 | 16 | use super::storage::StorageEntity; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ warning: unused import: `Path` --> src/services/wallet/mod.rs:17:17 | 17 | use std::path::{Path, PathBuf}; | ^^^^ warning: unused import: `std::mem` --> src/services/wallet/mod.rs:18:5 | 18 | use std::mem; | ^^^^^^^^ warning: unused import: `ChaCha20Poly1305IETF` --> src/services/wallet/mod.rs:29:44 | 29 | use utils::crypto::chacha20poly1305_ietf::{ChaCha20Poly1305IETF, ChaCha20Poly1305IETFKey}; | ^^^^^^^^^^^^^^^^^^^^ warning: unused import: `self::sodiumoxide::utils::memzero` --> src/services/wallet/mod.rs:37:5 | 37 | use self::sodiumoxide::utils::memzero; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ After that when i`m trying to run indy-agent it`s showing ld: library not found for -lindy What is wrong. please help me.

PhillipGibb (Thu, 21 Jun 2018 10:13:27 GMT):
did you build libindy and copy libindy.dylib to /usr/local/lib ? also nullpay dylib

PhillipGibb (Thu, 21 Jun 2018 10:14:15 GMT):
libnullpay.dylib

PhillipGibb (Thu, 21 Jun 2018 10:15:20 GMT):
I am trying to build indy sdk with Cargo and I am getting: undefined reference to `zmq_has' collect2: error: ld returned 1 exit status

gudkov (Thu, 21 Jun 2018 10:22:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=BAX63QorSndNRf3Q2) @PhillipGibb On what OS? If OSX you need to call ```brew install zmq```

K.Amine (Thu, 21 Jun 2018 10:43:45 GMT):
Does someone know how to output rust logs on jupyternotebook ? I already ran RUST_LOG=trace on the docker terminal

PhillipGibb (Thu, 21 Jun 2018 11:18:58 GMT):
@gudkov I am trying to build an ubuntu docker container that uses libindy but I gave up trying to build on ubuntu because of the zmq error and am now trying to pull from the repo

AvikHazra (Thu, 21 Jun 2018 11:22:08 GMT):
hello @PhillipGibb, when i`m trying to build the sdk it showing those warning.

PhillipGibb (Thu, 21 Jun 2018 11:31:53 GMT):
apt-get can't find zmq or libzmq as a package, installed libzmq3 results in: error: failed to run custom build command for `zmq-sys v0.8.2` process didn't exit successfully: `/tmp/indy-sdk/libindy/target/debug/build/zmq-sys-46d3715cdd838802/build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'Unable to locate libzmq: `"pkg-config" "--libs" "--cflags" "libzmq >= 3.2"` did not exit successfully: exit code: 1 --- stderr Package libzmq was not found in the pkg-config search path. Perhaps you should add the directory containing `libzmq.pc' to the PKG_CONFIG_PATH environment variable No package 'libzmq' found ', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-sys-0.8.2/build.rs:31:17 note: Run with `RUST_BACKTRACE=1` for a backtrace. warning: build failed, waiting for other jobs to finish... error: build failed

AxelNennker (Thu, 21 Jun 2018 12:23:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=EcNG4dbZgPXxdXxBW) @AvikHazra This PR fixes all but two of the warnings. https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/commands/non_secrets.rs#L241

AvikHazra (Thu, 21 Jun 2018 12:25:40 GMT):
thank you sir for your reply @AxelNennker

PhillipGibb (Thu, 21 Jun 2018 13:47:06 GMT):
as a matter of interest has anyone built an ubuntu docker container with libindy installed?

swcurran (Thu, 21 Jun 2018 14:15:39 GMT):
@PhillipGibb - the extended BC Gov team has "von-image" that includes libindy, node, python wrapper and other components that you may or may not need. Docker Hub is https://hub.docker.com/r/bcgovimages/von-image/, the github repo is https://github.com/PSPC-SPAC-buyandsell/von-image. A bunch of time was spent minimizing the image size so it's a pretty useful implementation. We are continuing to maintain the repo as new versions of indy components come out.

smithbk (Thu, 21 Jun 2018 14:29:07 GMT):
I'm getting a panic in prover_create_proof. Any ideas? Please see https://jira.hyperledger.org/browse/IS-789

ksh (Thu, 21 Jun 2018 14:51:57 GMT):
How to solve the problem when I try to "send NYM xxxxxxx" :indy@sandbox> new key with seed 000000000000000000000000Steward1 Key created in wallet Default DID for key is Th7MpTaRZVRYnPiabds81Y Verification key is ~7TYfekw4GUagBnBVCqPjiC Current DID set to Th7MpTaRZVRYnPiabds81Y indy@sandbox> send NYM dest=ULtgFQJe6bjiFbs7ke3NJD role=TRUST_ANCHOR verkey=~5kh 3FB4H3NKq7tUDqeqHc1 Adding nym ULtgFQJe6bjiFbs7ke3NJD Error: client request invalid: UnauthorizedClientRequest('Th7MpTaRZVRYnPiabds81Y is neither Trustee nor owner of ULtgFQJe6bjiFbs7ke3NJD',) indy@sandbox>

PhillipGibb (Thu, 21 Jun 2018 14:53:48 GMT):
thanks @swcurran at the moment I am using a node js app with indy_sdk to connect to a pool that I am running with indy-sdk/doc/getting-started but when I use the docker_pool_transactions_genesis file to create the pool I get 'unexpected token :' an I using the incorrect genesis file?

swcurran (Thu, 21 Jun 2018 14:56:34 GMT):
Not sure of that one. Have you looked at the indy-agent nodejs work that is being done? In that, we have added docker and docker-compose files that use VON to successful bring up a network and agents. The instructions are in the folder on how to bring up the network - it uses another of our components - von-network. Links in the instructions. https://github.com/swcurran/indy-agent/tree/master/nodejs

tomislav (Thu, 21 Jun 2018 15:02:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=GJ2JTW8ZXHZdi25Xe) @ksh This is a magic DID that already exists on the ledger, you don't have to send it's nym. You can do a get nym command and see who the owner is

dbluhm (Thu, 21 Jun 2018 15:11:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=c7zi9jkR894P9H3n5) @PhillipGibb There have been changes introduced to the indy-sdk that altered the structure of the genesis transaction file. That may be related to the error you're seeing though I'm not sure.

PhillipGibb (Fri, 22 Jun 2018 06:27:22 GMT):
I am finding this whole genesis file confusing. When you create an service that needs to ledger, then where do I get this file from?

PhillipGibb (Fri, 22 Jun 2018 06:29:40 GMT):
thanks @swcurran where can I get the genesis file for that pool that was created with docker?

AxelNennker (Fri, 22 Jun 2018 07:49:18 GMT):
Could someone please have a look at https://github.com/hyperledger/indy-sdk/issues/897

AxelNennker (Fri, 22 Jun 2018 08:49:49 GMT):
Would it make sense to add higher-level methods to the nodejs module? There are some methods that follow this pattern: buildRequest, sendRequest, optionally parseResponse All of those could be put into the module. The nodejs gettingStarted has some of those already as methods but why not move them to the module? https://github.com/hyperledger/indy-sdk/blob/master/samples/nodejs/gettingStarted.js#L715

AxelNennker (Fri, 22 Jun 2018 08:52:43 GMT):
Also helper methods that generate the parameters which are json strings. The documentation for these parameters could be improved but having helper methods that puts something like https://github.com/hyperledger/indy-sdk/blob/master/samples/nodejs/gettingStarted.js#L428 together would help, I think.

Qiu (Fri, 22 Jun 2018 09:33:04 GMT):
My OS is ubuntu. I want to know where is the configuration problem here parallels@parallels-vm:~/indy-node/environment/vagrant/training/vb-multi-vm$ vagrant up Bringing machine 'cli01' up with 'virtualbox' provider... Bringing machine 'validator01' up with 'virtualbox' provider... Bringing machine 'validator02' up with 'virtualbox' provider... Bringing machine 'validator03' up with 'virtualbox' provider... Bringing machine 'validator04' up with 'virtualbox' provider... ==> cli01: Checking if box 'bento/ubuntu-16.04' is up to date... ==> cli01: Clearing any previously set forwarded ports... ==> cli01: Clearing any previously set network interfaces... ==> cli01: Preparing network interfaces based on configuration... cli01: Adapter 1: nat cli01: Adapter 2: hostonly ==> cli01: Forwarding ports... cli01: 22 (guest) => 2222 (host) (adapter 1) ==> cli01: Running 'pre-boot' VM customizations... ==> cli01: Booting VM... ==> cli01: Waiting for machine to boot. This may take a few minutes... cli01: SSH address: 127.0.0.1:2222 cli01: SSH username: vagrant cli01: SSH auth method: private key Timed out while waiting for the machine to boot. This means that Vagrant was unable to communicate with the guest machine within the configured ("config.vm.boot_timeout" value) time period. If you look above, you should be able to see the error(s) that Vagrant had when attempting to connect to the machine. These errors are usually good hints as to what may be wrong. If you're using a custom box, make sure that networking is properly working and you're able to connect to the machine. It is a common problem that networking isn't setup properly in these boxes. Verify that authentication configurations are also setup properly, as well. If the box appears to be booting properly, you may want to increase the timeout ("config.vm.boot_timeout") value.

gudkov (Fri, 22 Jun 2018 09:49:58 GMT):
@Qiu I suggest to ask this in Indy Node channel

PhillipGibb (Fri, 22 Jun 2018 11:40:35 GMT):
Hi,

PhillipGibb (Fri, 22 Jun 2018 11:41:49 GMT):
anyone know how to set the protocol version for the pool? If I do not it gives me an error: indy_set_protocol_version(2) to set correct PROTOCOL_VERSION") If I do then I get the error: setProtocolVersion is not a function

PhillipGibb (Fri, 22 Jun 2018 11:59:05 GMT):
all I want to do is write code to ledger onto the docker pool, yet it seems to be unsurmountable effort to get the parts to play nicely together

AxelNennker (Fri, 22 Jun 2018 16:18:44 GMT):
Could somebody please review https://github.com/hyperledger/indy-sdk/pull/881 It gets rid of the compile time warning. The changes are quite simple.

AxelNennker (Fri, 22 Jun 2018 16:18:44 GMT):
Could somebody please review https://github.com/hyperledger/indy-sdk/pull/881 It gets rid of the compile time warnings. The changes are quite simple.

K.Amine (Fri, 22 Jun 2018 19:24:05 GMT):
Hi everyone, I have an unexpected error in my script which occur everytime I run it, Unfortunately I can't figure out the problem :

K.Amine (Fri, 22 Jun 2018 19:24:51 GMT):
``` ``` TRACE|indy::services::pool | src/services/pool/mod.rs:322 | zmq poll 1 TRACE|indy::commands::did | src/commands/did.rs:550 | Invalid structure: data did not match any variant of untagged enum Reply ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid library state: Invalid GetNymReplyResult json: InvalidStructure("data did not match any variant of untagged enum Reply") TRACE|indy::api::did | src/api/did.rs:300 | indy_key_for_did: key: "" _indy_loop_callback: Function returned error 112 INFO|indy::services::pool | src/services/pool/mod.rs:692 | RemoteNode::recv_msg Node1 {"op":"REPLY","result":{"txnMetadata":{"txnTime":1529686716,"seqNo":15029},"reqSignature":{"type":"ED25519","values":[{"value":"5DNZhu9m3wsY62uuyJR6xt1YgYsBAfmrJZCVC5ooUBS6HFfpcTYn8nMexCMMSMscBZJmyW1dnu5qJTEAXZojR9u3","from":"Th7MpTaRZVRYnPiabds81Y"}]},"auditPath":["FYCynXknBsSYHA72LBdRHGv1PJhMrzueNmqeRc6Jdbz7","A96eL3oqfuv7NUeZ3tsMZTnKvz7qbndEC8utVLmcUMML","DVDMFpP8tFypkb7syyHCFbN5Fz1ZcRJDYpCgPe2fYRku","HB4UtqcodRYifSKUW2LPUooNS1c2gK8eQ9Hz5jPA7ysQ","7XWq93iX7yPQxeAm2FrSh6zGcSaQopziyUfrRpqExkpm","GUSkvkXSRGbwM62NoFLFXad78otNisCN9yhk96cqNH3b","DL5BYRK7LPWmiQnTX7HeLoaLLxvm4CDYN4VZPPBYG64x","H7C57jCENXiuMweLDn15eXJTVqUb6BJC8pDhnsxw6Q88"],"ver":"1","rootHash":"5gSxYW87HbWRtew7tt6tQ8bT2iH52PN93iVNBrZi7jw5","txn":{"type":"1","data":{"verkey":"4oR9xDySuHr5KtYLAi1d1DuWHWLm8j5HH1m3PBtCcdoK","dest":"7yQhfWgcFNaF8RvRB38beA"},"metadata":{"digest":"8ebca1dd524d181dd39d44eb1bed98b7fc1c6d94ee35bf3cbcfcae3703f25b78","reqId":1529686716623166692,"from":"Th7MpTaRZVRYnPiabds81Y"},"protocolVersion":2}}} DEBUG|indy::services::pool::transaction_handler|src/services/pool/transaction_handler.rs:87 | TransactionHandler::process_reply: >>> req_id: 1529686716623166692, raw_msg: "{\"op\":\"REPLY\",\"result\":{\"txnMetadata\":{\"txnTime\":1529686716,\"seqNo\":15029},\"reqSignature\":{\"type\":\"ED25519\",\"values\":[{\"value\":\"5DNZhu9m3wsY62uuyJR6xt1YgYsBAfmrJZCVC5ooUBS6HFfpcTYn8nMexCMMSMscBZJmyW1dnu5qJTEAXZojR9u3\",\"from\":\"Th7MpTaRZVRYnPiabds81Y\"}]},\"auditPath\":[\"FYCynXknBsSYHA72LBdRHGv1PJhMrzueNmqeRc6Jdbz7\",\"A96eL3oqfuv7NUeZ3tsMZTnKvz7qbndEC8utVLmcUMML\",\"DVDMFpP8tFypkb7syyHCFbN5Fz1ZcRJDYpCgPe2fYRku\",\"HB4UtqcodRYifSKUW2LPUooNS1c2gK8eQ9Hz5jPA7ysQ\",\"7XWq93iX7yPQxeAm2FrSh6zGcSaQopziyUfrRpqExkpm\",\"GUSkvkXSRGbwM62NoFLFXad78otNisCN9yhk96cqNH3b\",\"DL5BYRK7LPWmiQnTX7HeLoaLLxvm4CDYN4VZPPBYG64x\",\"H7C57jCENXiuMweLDn15eXJTVqUb6BJC8pDhnsxw6Q88\"],\"ver\":\"1\",\"rootHash\":\"5gSxYW87HbWRtew7tt6tQ8bT2iH52PN93iVNBrZi7jw5\",\"txn\":{\"type\":\"1\",\"data\":{\"verkey\":\"4oR9xDySuHr5KtYLAi1d1DuWHWLm8j5HH1m3PBtCcdoK\",\"dest\":\"7yQhfWgcFNaF8RvRB38beA\"},\"metadata\":{\"digest\":\"8ebca1dd524d181dd39d44eb1bed98b7fc1c6d94ee35bf3cbcfcae3703f25b78\",\"reqId\":1529686716623166692,\"from\":\"Th7MpTaRZVRYnPiabds81Y\"},\"protocolVersion\":2}}}", src_ind: 3 WARN|indy::services::pool::transaction_handler|src/services/pool/transaction_handler.rs:90 | TransactionHandler::process_reply: <<< No pending command for request TRACE|indy::services::pool | src/services/pool/mod.rs:275 | zmq poll loop << TRACE|indy::services::pool | src/services/pool/mod.rs:269 | zmq poll loop >> Traceback (most recent call last): File "getting-started-debug.py", line 837, in loop.run_until_complete(run()) File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step result = coro.throw(exc) File "getting-started-debug.py", line 119, in run 'TRUST_ANCHOR' File "getting-started-debug.py", line 753, in get_verinym assert sender_verkey == await did.key_for_did(pool_handle, from_wallet, to_from_did) File "/home/amine/.local/lib/python3.5/site-packages/indy/did.py", line 317, in key_for_did key_for_did.cb) File "/usr/lib/python3.5/asyncio/futures.py", line 361, in __iter__ yield self # This tells Task to wait for completion. File "/usr/lib/python3.5/asyncio/tasks.py", line 296, in _wakeup future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception indy.error.IndyError: ErrorCode.CommonInvalidState ```

K.Amine (Fri, 22 Jun 2018 19:24:51 GMT):
``` TRACE|indy::services::pool | src/services/pool/mod.rs:322 | zmq poll 1 TRACE|indy::commands::did | src/commands/did.rs:550 | Invalid structure: data did not match any variant of untagged enum Reply ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid library state: Invalid GetNymReplyResult json: InvalidStructure("data did not match any variant of untagged enum Reply") TRACE|indy::api::did | src/api/did.rs:300 | indy_key_for_did: key: "" _indy_loop_callback: Function returned error 112 INFO|indy::services::pool | src/services/pool/mod.rs:692 | RemoteNode::recv_msg Node1 {"op":"REPLY","result":{"txnMetadata":{"txnTime":1529686716,"seqNo":15029},"reqSignature":{"type":"ED25519","values":[{"value":"5DNZhu9m3wsY62uuyJR6xt1YgYsBAfmrJZCVC5ooUBS6HFfpcTYn8nMexCMMSMscBZJmyW1dnu5qJTEAXZojR9u3","from":"Th7MpTaRZVRYnPiabds81Y"}]},"auditPath":["FYCynXknBsSYHA72LBdRHGv1PJhMrzueNmqeRc6Jdbz7","A96eL3oqfuv7NUeZ3tsMZTnKvz7qbndEC8utVLmcUMML","DVDMFpP8tFypkb7syyHCFbN5Fz1ZcRJDYpCgPe2fYRku","HB4UtqcodRYifSKUW2LPUooNS1c2gK8eQ9Hz5jPA7ysQ","7XWq93iX7yPQxeAm2FrSh6zGcSaQopziyUfrRpqExkpm","GUSkvkXSRGbwM62NoFLFXad78otNisCN9yhk96cqNH3b","DL5BYRK7LPWmiQnTX7HeLoaLLxvm4CDYN4VZPPBYG64x","H7C57jCENXiuMweLDn15eXJTVqUb6BJC8pDhnsxw6Q88"],"ver":"1","rootHash":"5gSxYW87HbWRtew7tt6tQ8bT2iH52PN93iVNBrZi7jw5","txn":{"type":"1","data":{"verkey":"4oR9xDySuHr5KtYLAi1d1DuWHWLm8j5HH1m3PBtCcdoK","dest":"7yQhfWgcFNaF8RvRB38beA"},"metadata":{"digest":"8ebca1dd524d181dd39d44eb1bed98b7fc1c6d94ee35bf3cbcfcae3703f25b78","reqId":1529686716623166692,"from":"Th7MpTaRZVRYnPiabds81Y"},"protocolVersion":2}}} DEBUG|indy::services::pool::transaction_handler|src/services/pool/transaction_handler.rs:87 | TransactionHandler::process_reply: >>> req_id: 1529686716623166692, raw_msg: "{\"op\":\"REPLY\",\"result\":{\"txnMetadata\":{\"txnTime\":1529686716,\"seqNo\":15029},\"reqSignature\":{\"type\":\"ED25519\",\"values\":[{\"value\":\"5DNZhu9m3wsY62uuyJR6xt1YgYsBAfmrJZCVC5ooUBS6HFfpcTYn8nMexCMMSMscBZJmyW1dnu5qJTEAXZojR9u3\",\"from\":\"Th7MpTaRZVRYnPiabds81Y\"}]},\"auditPath\":[\"FYCynXknBsSYHA72LBdRHGv1PJhMrzueNmqeRc6Jdbz7\",\"A96eL3oqfuv7NUeZ3tsMZTnKvz7qbndEC8utVLmcUMML\",\"DVDMFpP8tFypkb7syyHCFbN5Fz1ZcRJDYpCgPe2fYRku\",\"HB4UtqcodRYifSKUW2LPUooNS1c2gK8eQ9Hz5jPA7ysQ\",\"7XWq93iX7yPQxeAm2FrSh6zGcSaQopziyUfrRpqExkpm\",\"GUSkvkXSRGbwM62NoFLFXad78otNisCN9yhk96cqNH3b\",\"DL5BYRK7LPWmiQnTX7HeLoaLLxvm4CDYN4VZPPBYG64x\",\"H7C57jCENXiuMweLDn15eXJTVqUb6BJC8pDhnsxw6Q88\"],\"ver\":\"1\",\"rootHash\":\"5gSxYW87HbWRtew7tt6tQ8bT2iH52PN93iVNBrZi7jw5\",\"txn\":{\"type\":\"1\",\"data\":{\"verkey\":\"4oR9xDySuHr5KtYLAi1d1DuWHWLm8j5HH1m3PBtCcdoK\",\"dest\":\"7yQhfWgcFNaF8RvRB38beA\"},\"metadata\":{\"digest\":\"8ebca1dd524d181dd39d44eb1bed98b7fc1c6d94ee35bf3cbcfcae3703f25b78\",\"reqId\":1529686716623166692,\"from\":\"Th7MpTaRZVRYnPiabds81Y\"},\"protocolVersion\":2}}}", src_ind: 3 WARN|indy::services::pool::transaction_handler|src/services/pool/transaction_handler.rs:90 | TransactionHandler::process_reply: <<< No pending command for request TRACE|indy::services::pool | src/services/pool/mod.rs:275 | zmq poll loop << TRACE|indy::services::pool | src/services/pool/mod.rs:269 | zmq poll loop >> Traceback (most recent call last): File "getting-started-debug.py", line 837, in loop.run_until_complete(run()) File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step result = coro.throw(exc) File "getting-started-debug.py", line 119, in run 'TRUST_ANCHOR' File "getting-started-debug.py", line 753, in get_verinym assert sender_verkey == await did.key_for_did(pool_handle, from_wallet, to_from_did) File "/home/amine/.local/lib/python3.5/site-packages/indy/did.py", line 317, in key_for_did key_for_did.cb) File "/usr/lib/python3.5/asyncio/futures.py", line 361, in __iter__ yield self # This tells Task to wait for completion. File "/usr/lib/python3.5/asyncio/tasks.py", line 296, in _wakeup future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception indy.error.IndyError: ErrorCode.CommonInvalidState ```

K.Amine (Fri, 22 Jun 2018 19:25:31 GMT):
``` ``` TRACE|indy::services::pool | src/services/pool/mod.rs:322 | zmq poll 1 TRACE|indy::commands::did | src/commands/did.rs:550 | Invalid structure: data did not match any variant of untagged enum Reply ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid library state: Invalid GetNymReplyResult json: InvalidStructure("data did not match any variant of untagged enum Reply") TRACE|indy::api::did | src/api/did.rs:300 | indy_key_for_did: key: "" _indy_loop_callback: Function returned error 112 INFO|indy::services::pool | src/services/pool/mod.rs:692 | RemoteNode::recv_msg Node1 {"op":"REPLY","result":{"txnMetadata":{"txnTime":1529686716,"seqNo":15029},"reqSignature":{"type":"ED25519","values":[{"value":"5DNZhu9m3wsY62uuyJR6xt1YgYsBAfmrJZCVC5ooUBS6HFfpcTYn8nMexCMMSMscBZJmyW1dnu5qJTEAXZojR9u3","from":"Th7MpTaRZVRYnPiabds81Y"}]},"auditPath":["FYCynXknBsSYHA72LBdRHGv1PJhMrzueNmqeRc6Jdbz7","A96eL3oqfuv7NUeZ3tsMZTnKvz7qbndEC8utVLmcUMML","DVDMFpP8tFypkb7syyHCFbN5Fz1ZcRJDYpCgPe2fYRku","HB4UtqcodRYifSKUW2LPUooNS1c2gK8eQ9Hz5jPA7ysQ","7XWq93iX7yPQxeAm2FrSh6zGcSaQopziyUfrRpqExkpm","GUSkvkXSRGbwM62NoFLFXad78otNisCN9yhk96cqNH3b","DL5BYRK7LPWmiQnTX7HeLoaLLxvm4CDYN4VZPPBYG64x","H7C57jCENXiuMweLDn15eXJTVqUb6BJC8pDhnsxw6Q88"],"ver":"1","rootHash":"5gSxYW87HbWRtew7tt6tQ8bT2iH52PN93iVNBrZi7jw5","txn":{"type":"1","data":{"verkey":"4oR9xDySuHr5KtYLAi1d1DuWHWLm8j5HH1m3PBtCcdoK","dest":"7yQhfWgcFNaF8RvRB38beA"},"metadata":{"digest":"8ebca1dd524d181dd39d44eb1bed98b7fc1c6d94ee35bf3cbcfcae3703f25b78","reqId":1529686716623166692,"from":"Th7MpTaRZVRYnPiabds81Y"},"protocolVersion":2}}} DEBUG|indy::services::pool::transaction_handler|src/services/pool/transaction_handler.rs:87 | TransactionHandler::process_reply: >>> req_id: 1529686716623166692, raw_msg: "{\"op\":\"REPLY\",\"result\":{\"txnMetadata\":{\"txnTime\":1529686716,\"seqNo\":15029},\"reqSignature\":{\"type\":\"ED25519\",\"values\":[{\"value\":\"5DNZhu9m3wsY62uuyJR6xt1YgYsBAfmrJZCVC5ooUBS6HFfpcTYn8nMexCMMSMscBZJmyW1dnu5qJTEAXZojR9u3\",\"from\":\"Th7MpTaRZVRYnPiabds81Y\"}]},\"auditPath\":[\"FYCynXknBsSYHA72LBdRHGv1PJhMrzueNmqeRc6Jdbz7\",\"A96eL3oqfuv7NUeZ3tsMZTnKvz7qbndEC8utVLmcUMML\",\"DVDMFpP8tFypkb7syyHCFbN5Fz1ZcRJDYpCgPe2fYRku\",\"HB4UtqcodRYifSKUW2LPUooNS1c2gK8eQ9Hz5jPA7ysQ\",\"7XWq93iX7yPQxeAm2FrSh6zGcSaQopziyUfrRpqExkpm\",\"GUSkvkXSRGbwM62NoFLFXad78otNisCN9yhk96cqNH3b\",\"DL5BYRK7LPWmiQnTX7HeLoaLLxvm4CDYN4VZPPBYG64x\",\"H7C57jCENXiuMweLDn15eXJTVqUb6BJC8pDhnsxw6Q88\"],\"ver\":\"1\",\"rootHash\":\"5gSxYW87HbWRtew7tt6tQ8bT2iH52PN93iVNBrZi7jw5\",\"txn\":{\"type\":\"1\",\"data\":{\"verkey\":\"4oR9xDySuHr5KtYLAi1d1DuWHWLm8j5HH1m3PBtCcdoK\",\"dest\":\"7yQhfWgcFNaF8RvRB38beA\"},\"metadata\":{\"digest\":\"8ebca1dd524d181dd39d44eb1bed98b7fc1c6d94ee35bf3cbcfcae3703f25b78\",\"reqId\":1529686716623166692,\"from\":\"Th7MpTaRZVRYnPiabds81Y\"},\"protocolVersion\":2}}}", src_ind: 3 WARN|indy::services::pool::transaction_handler|src/services/pool/transaction_handler.rs:90 | TransactionHandler::process_reply: <<< No pending command for request TRACE|indy::services::pool | src/services/pool/mod.rs:275 | zmq poll loop << TRACE|indy::services::pool | src/services/pool/mod.rs:269 | zmq poll loop >> Traceback (most recent call last): File "getting-started-debug.py", line 837, in loop.run_until_complete(run()) File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step result = coro.throw(exc) File "getting-started-debug.py", line 119, in run 'TRUST_ANCHOR' File "getting-started-debug.py", line 753, in get_verinym assert sender_verkey == await did.key_for_did(pool_handle, from_wallet, to_from_did) File "/home/amine/.local/lib/python3.5/site-packages/indy/did.py", line 317, in key_for_did key_for_did.cb) File "/usr/lib/python3.5/asyncio/futures.py", line 361, in __iter__ yield self # This tells Task to wait for completion. File "/usr/lib/python3.5/asyncio/tasks.py", line 296, in _wakeup future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception indy.error.IndyError: ErrorCode.CommonInvalidState ```

K.Amine (Fri, 22 Jun 2018 19:26:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6Qgoz6piF5zKoD73t) I'm running on Ubuntu 16.04

hendry19901990 (Fri, 22 Jun 2018 23:38:43 GMT):
Has joined the channel.

hendry19901990 (Fri, 22 Jun 2018 23:39:15 GMT):
Hello everyone i need help there is an api like ethereum json-rpc for connecting ?

Taaanos (Sat, 23 Jun 2018 05:47:12 GMT):
Has joined the channel.

PhillipGibb (Sat, 23 Jun 2018 19:43:18 GMT):
still Stuck on a indy-sdk bug where I have to set the protocol version but when I do I get the error : setProtocolVersion is not a function, anyone else?

Vikrum (Sat, 23 Jun 2018 22:16:53 GMT):
von-web_1 | indy.error.IndyError: ErrorCode.PoolLedgerTimeout

gudkov (Mon, 25 Jun 2018 08:15:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=H9cZYhrRRgiWFasNh) @PhillipGibb What wrapper and what exact version do you use? You need to update libindy and wrapper to the latest master

gudkov (Mon, 25 Jun 2018 08:22:55 GMT):
@K.Amine Node returned hat there is no such NYM. And most probably key_for_did contains bug related to incorrect processing of this kind of reply in protocol version 2. We will check with our QA team.

PhillipGibb (Mon, 25 Jun 2018 08:23:24 GMT):
@gudkov I have pulled master indy-sdk, rebuild libindy and copied the dylib (I am with macosx) to the correct dir Where I am uncertain is with npm install indy-sdk - seems that that has not been updated, so I did an npm install on indy-sdk and used that build but same result

PhillipGibb (Mon, 25 Jun 2018 08:25:10 GMT):
@gudkov otherwise: nodejs wrapper indy-sdk 0.2.5 libindy - whatever version that cargo build produces from master

PhillipGibb (Mon, 25 Jun 2018 08:25:17 GMT):
1.4?

gudkov (Mon, 25 Jun 2018 08:25:57 GMT):
we don't have CD pipeline for NodeJS wapper. So you need to rebuild it from sources too.

PhillipGibb (Mon, 25 Jun 2018 08:26:54 GMT):
sources as in https://github.com/hyperledger/indy-sdk/tree/master/wrappers/nodejs

gudkov (Mon, 25 Jun 2018 08:28:08 GMT):
Yes, also i am not sure that it is updated.

PhillipGibb (Mon, 25 Jun 2018 08:29:51 GMT):
not convinced either because I have done this process already

gudkov (Mon, 25 Jun 2018 08:29:59 GMT):
@farskipper Could you check that indy_set_protocol_version endpoint is exposed in NodeJS wrapper. Also master contains a lot of changes that requires to be integrated. https://github.com/hyperledger/indy-sdk/blob/master/doc/migration-guide-1.4.0-1.5.0.md

gudkov (Mon, 25 Jun 2018 08:29:59 GMT):
@farskipper Could you check that indy_set_protocol_version endpoint is exposed in NodeJS wrapper. Also master contains a lot of changes that require to be integrated. https://github.com/hyperledger/indy-sdk/blob/master/doc/migration-guide-1.4.0-1.5.0.md

PhillipGibb (Mon, 25 Jun 2018 09:05:32 GMT):
@gudkov sorted, I thought that I should be building the indy-sdk wrapper separately and then copying the build to my node modules, after running npm install in my project, it worked

PhillipGibb (Mon, 25 Jun 2018 09:06:45 GMT):
my issue at the moment is that opening a connection to the ledger I having running with docker times out

gudkov (Mon, 25 Jun 2018 10:01:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=joZuXrTpdW8EMQTpG) @PhillipGibb You need to check that ips are exposed in a right way by Docker

gudkov (Mon, 25 Jun 2018 10:02:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Dh3RJJPtAcj8gRC5H) QA reported this bug https://jira.hyperledger.org/browse/IS-792

PhillipGibb (Mon, 25 Jun 2018 10:12:17 GMT):
@gudkov hmmm - I can telnet to those ports, so I believe that they are exposed correctly

gudkov (Mon, 25 Jun 2018 10:13:01 GMT):
@PhillipGibb what ip you use for telent? what is the content of genesis txns file?

PhillipGibb (Mon, 25 Jun 2018 10:14:30 GMT):
both 127.0.0.1

gudkov (Mon, 25 Jun 2018 10:16:35 GMT):
Are you sure? Could you provide your code for pool config creation?

PhillipGibb (Mon, 25 Jun 2018 10:19:31 GMT):
async function setup(genesisPoolFile) { let poolConfig = { "genesis_txn": genesisPoolFile }; try { console.log("============================="); console.log(`====== Setting up pool =====`); console.log("-----------------------------"); console.log(`poolConfig = ${genesisPoolFile}`) console.log(`pool NAME = ${env.POOL_NAME}`) //await indy.deletePoolLedgerConfig(env.POOL_NAME) try{ await indy.setProtocolVersion(2) //setProtocolVersion is not a function, 20 bucks says it is : https://github.com/hyperledger/indy-sdk/tree/master/wrappers/nodejs#setprotocolversion--protocolversion----void } catch (e) { console.error(e) } await indy.createPoolLedgerConfig(env.POOL_NAME, poolConfig); } catch (e) { if (e.message !== "PoolLedgerConfigAlreadyExistsError") { throw e; } } };

PhillipGibb (Mon, 25 Jun 2018 10:20:05 GMT):
does rocket chat format code?

PhillipGibb (Mon, 25 Jun 2018 10:20:46 GMT):
{"reqSignature":{},"txn":{"data":{"data":{"alias":"Node1","blskey":"4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba","client_ip":"127.0.0.1","client_port":9702,"node_ip":"127.0.0.1","node_port":9701,"services":["VALIDATOR"]},"dest":"Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv"},"metadata":{"from":"Th7MpTaRZVRYnPiabds81Y"},"type":"0"},"txnMetadata":{"seqNo":1,"txnId":"fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62"},"ver":"2"} {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node2","blskey":"37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk","client_ip":"127.0.0.1","client_port":9704,"node_ip":"127.0.0.1","node_port":9703,"services":["VALIDATOR"]},"dest":"8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb"},"metadata":{"from":"EbP4aYNeTHL6q385GuVpRV"},"type":"0"},"txnMetadata":{"seqNo":2,"txnId":"1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc"},"ver":"2"} {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node3","blskey":"3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5","client_ip":"127.0.0.1","client_port":9706,"node_ip":"127.0.0.1","node_port":9705,"services":["VALIDATOR"]},"dest":"DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya"},"metadata":{"from":"4cU41vWW82ArfxJxHkzXPG"},"type":"0"},"txnMetadata":{"seqNo":3,"txnId":"7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4"},"ver":"2"} {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node4","blskey":"2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw","client_ip":"127.0.0.1","client_port":9708,"node_ip":"127.0.0.1","node_port":9707,"services":["VALIDATOR"]},"dest":"4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA"},"metadata":{"from":"TWwCRQRZ2ZHMJFn9TzLp7W"},"type":"0"},"txnMetadata":{"seqNo":4,"txnId":"aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008"},"ver":"2"}

gudkov (Mon, 25 Jun 2018 10:26:08 GMT):
Seems ok for me. What telnet says when you connect to the port?

PhillipGibb (Mon, 25 Jun 2018 10:41:03 GMT):
well, I run the docker pool with these commands: docker network create --subnet 10.0.0.0/8 indy_pool_network docker build --build-arg pool_ip=10.0.0.2 -f ci/indy-pool.dockerfile -t indy_pool . docker run -d --ip="10.0.0.2" --net=indy_pool_network indy_pool

PhillipGibb (Mon, 25 Jun 2018 10:41:40 GMT):
but I can't telnet 10.0.0.2 9701/2/3/4/5/6/7/8/9

PhillipGibb (Mon, 25 Jun 2018 10:42:22 GMT):
but I can use 127.0.0.1

PhillipGibb (Mon, 25 Jun 2018 10:44:26 GMT):
nope not anymore

PhillipGibb (Mon, 25 Jun 2018 11:40:24 GMT):
@gudkov With the above command on my mac osx I have to run the container like this (otherwise I don't see the ports): docker run -d -p 9701-9708:9701-9708 --ip="10.0.0.2" --net=indy_pool_network indy_pool Then I only see the ports on localhost, not 10.0.0.2 The genesis file uses 10.0.0.2 So I get a timeout with that If I change 10.0.0.2 in the gen file top 127.0.0.1 then I get: ool worker thread finished with error CommonError(InvalidState("Ledger merkle tree doesn\'t acceptable for current tree.")) { IndyError: CommonInvalidState at Object.callback (/Users/phillipgibb/repo/indy-sdk/wrappers/nodejs/src/wrapIndyCallback.js:15:10) name: 'IndyError', message: 'CommonInvalidState', indyCode: 112, indyName: 'CommonInvalidState' }

gudkov (Mon, 25 Jun 2018 12:32:45 GMT):
@PhillipGibb Nodes must see each other by the same ips as client. On MacOS you must use Virtualbox port mapping to achieve this.

gudkov (Mon, 25 Jun 2018 12:33:14 GMT):
See https://github.com/hyperledger/indy-sdk#docker-port-mapping-on-macos

AxelNennker (Mon, 25 Jun 2018 12:34:41 GMT):
pulled master and now I get 22 error messages when compiling in src/services/wallet/language.rs

gudkov (Mon, 25 Jun 2018 12:35:19 GMT):
Yeah...

gudkov (Mon, 25 Jun 2018 12:35:46 GMT):
It was completely clean before merge.

gudkov (Mon, 25 Jun 2018 12:36:07 GMT):
Sorry... error messages? or warning messages?

gudkov (Mon, 25 Jun 2018 12:39:43 GMT):
@AxelNennker "C:/Users/Vyacheslav Gudkov/.cargo/bin/cargo.exe" +stable build Compiling indy v1.4.0 (file:///C:/workspace/src/indy-sdk/libindy) Finished dev [unoptimized + debuginfo] target(s) in 53.52 secs Process finished with exit code 0

gudkov (Mon, 25 Jun 2018 12:40:48 GMT):
on the latest master with rust 1.25.0

gudkov (Mon, 25 Jun 2018 12:41:21 GMT):
The same on CI

gudkov (Mon, 25 Jun 2018 12:41:40 GMT):
No errors and no warnings

AxelNennker (Mon, 25 Jun 2018 12:45:19 GMT):
I fixed this locally

AxelNennker (Mon, 25 Jun 2018 12:45:22 GMT):
ignisvulpis@namenlos:~/development/hyperledger/indy-sdk/libindy$ git diff diff --git a/libindy/src/services/wallet/language.rs b/libindy/src/services/wallet/language.rs index 581cfb3..3fa78a5 100644 --- a/libindy/src/services/wallet/language.rs +++ b/libindy/src/services/wallet/language.rs @@ -329,22 +329,22 @@ mod tests { impl PartialEq for Operator { fn eq(&self, other: &Operator) -> bool { match (self, other) { - (Operator::Eq(name, value), Operator::Eq(other_name, other_value)) - | (Operator::Neq(name, value), Operator::Neq(other_name, other_value)) - | (Operator::Gt(name, value), Operator::Gt(other_name, other_value)) - | (Operator::Gte(name, value), Operator::Gte(other_name, other_value)) - | (Operator::Lt(name, value), Operator::Lt(other_name, other_value)) - | (Operator::Lte(name, value), Operator::Lte(other_name, other_value)) - | (Operator::Like(name, value), Operator::Like(other_name, other_value)) => { + (&Operator::Eq(ref name, ref value), &Operator::Eq(ref other_name, ref other_value)) + | (&Operator::Neq(ref name, ref value), &Operator::Neq(ref other_name, ref other_value)) + | (&Operator::Gt(ref name, ref value), &Operator::Gt(ref other_name, ref other_value)) + | (&Operator::Gte(ref name, ref value), &Operator::Gte(ref other_name, ref other_value)) + | (&Operator::Lt(ref name, ref value), &Operator::Lt(ref other_name, ref other_value)) + | (&Operator::Lte(ref name, ref value), &Operator::Lte(ref other_name, ref other_value)) + | (&Operator::Like(ref name, ref value), &Operator::Like(ref other_name, ref other_value)) => { name == other_name && value == other_value }, - (Operator::In(name, values), Operator::In(other_name, other_values)) => { - name == other_name && vec_to_set(values) == vec_to_set(other_values) + (&Operator::In(ref name, ref values), &Operator::In(ref other_name, ref other_values)) => { + name == other_name && vec_to_set(&values) == vec_to_set(&other_values) }, - (Operator::Not(operator), Operator::Not(other_operator)) => operator == other_operator, - (Operator::And(operators), Operator::And(other_operators)) - | (Operator::Or(operators), Operator::Or(other_operators)) => { - vec_to_set(operators) == vec_to_set(other_operators) + (&Operator::Not(ref operator), &Operator::Not(ref other_operator)) => operator == other_operator, + (&Operator::And(ref operators), &Operator::And(ref other_operators)) + | (&Operator::Or(ref operators), &Operator::Or(ref other_operators)) => { + vec_to_set(&operators) == vec_to_set(&other_operators) }, (_, _) => false }

AxelNennker (Mon, 25 Jun 2018 12:45:34 GMT):
ignisvulpis@namenlos:~/development/hyperledger/indy-sdk/libindy$ rustc --version rustc 1.24.1 (d3ae9a9e0 2018-02-27) ignisvulpis@namenlos:~/development/hyperledger/indy-sdk/libindy$

AxelNennker (Mon, 25 Jun 2018 12:46:25 GMT):
Have to run now to a meeting. Will look into this later again

PhillipGibb (Mon, 25 Jun 2018 13:09:29 GMT):
@gudkov thanks, I don't think that that applies - I don't use VM ware. I think that I am going to have to run my app in another docker container which is going to be irritating for testing on the fly

farskipper (Mon, 25 Jun 2018 13:10:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=L67QeuufRzse7Qq57) @gudkov ok I'll take care of that this week

gudkov (Mon, 25 Jun 2018 13:11:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ww49j8YZZrC4kgpHK) @PhillipGibb In this case it is better to create docker network and use ip addresses inside of these network.

RaniSputnik (Mon, 25 Jun 2018 13:23:53 GMT):
Has joined the channel.

AxelNennker (Mon, 25 Jun 2018 13:58:55 GMT):
Hm... updated rust and now the errors disappeared. Strange. ignisvulpis@namenlos:~/development/hyperledger/indy-sdk/libindy$ rustc --version rustc 1.27.0 (3eda71b00 2018-06-19) ignisvulpis@namenlos:~/development/hyperledger/indy-sdk/libindy$

Dominic (Mon, 25 Jun 2018 14:41:25 GMT):
does the indy-sdk work on ubuntu 18.04?

gudkov (Mon, 25 Jun 2018 15:06:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=SSSN4x5zv8jD4Z6qJ) @Dominic binaries for 16.04 only, but you can build it for 18.04

RaniSputnik (Mon, 25 Jun 2018 17:40:30 GMT):
Hey folks, I'm having some trouble connecting to a pool with the CLI. Wondering if I'm making an obvious mistake? ``` indy> pool create pool1 gen_txn_file=/indy/genesis_transactions Pool config "pool1" has been created indy> pool connect pool1 Pool "pool1" does not exist. indy> pool list +-------+ | Pool | +-------+ | pool1 | +-------+ ``` In terms of setup, I'm running the pool and CLI in two docker containers on a single network. I'm using `ci/indy-pool.dockerfile` and `cli/cli.dockerfile` from master - with one modification; The CLI Dockerfile I have modified to include some genesis transactions. These transactions are copied from the Node sample and I have used the pool's container name as the values for `client_ip` and `node_ip`. Let me know if you can spot anything about this setup that sounds off. Thanks in advance!

RaniSputnik (Mon, 25 Jun 2018 17:40:30 GMT):
~Hey folks, I'm having some trouble connecting to a pool with the CLI. Wondering if I'm making an obvious mistake?~ ``` indy> pool create pool1 gen_txn_file=/indy/genesis_transactions Pool config "pool1" has been created indy> pool connect pool1 Pool "pool1" does not exist. indy> pool list +-------+ | Pool | +-------+ | pool1 | +-------+ ``` In terms of setup, I'm running the pool and CLI in two docker containers on a single network. I'm using `ci/indy-pool.dockerfile` and `cli/cli.dockerfile` from master - with one modification; The CLI Dockerfile I have modified to include some genesis transactions. These transactions are copied from the Node sample and I have used the _pool's container name_ (EDIT: Needed to use IP addresses) as the values for `client_ip` and `node_ip`. Let me know if you can spot anything about this setup that sounds off. Thanks in advance! EDIT: Okay I've made progress, as I suspected the client_ip and node_ip must be IP addresses. That error isn't great, but not a major.

RaniSputnik (Mon, 25 Jun 2018 17:40:30 GMT):
~Hey folks, I'm having some trouble connecting to a pool with the CLI. Wondering if I'm making an obvious mistake?~ ``` indy> pool create pool1 gen_txn_file=/indy/genesis_transactions Pool config "pool1" has been created indy> pool connect pool1 Pool "pool1" does not exist. indy> pool list +-------+ | Pool | +-------+ | pool1 | +-------+ ``` In terms of setup, I'm running the pool and CLI in two docker containers on a single network. I'm using `ci/indy-pool.dockerfile` and `cli/cli.dockerfile` from master - with one modification; The CLI Dockerfile I have modified to include some genesis transactions. These transactions are copied from the Node sample and I have used the _pool's container name_ (EDIT: Needed to use IP addresses) as the values for `client_ip` and `node_ip`. Let me know if you can spot anything about this setup that sounds off. Thanks in advance! *EDIT: Okay I've made progress, as I suspected the client_ip and node_ip must be IP addresses. That error isn't great, but not a major.*

RaniSputnik (Mon, 25 Jun 2018 17:40:30 GMT):
~Hey folks, I'm having some trouble connecting to a pool with the CLI. Wondering if I'm making an obvious mistake?~ ``` indy> pool create pool1 gen_txn_file=/indy/genesis_transactions Pool config "pool1" has been created indy> pool connect pool1 Pool "pool1" does not exist. indy> pool list +-------+ | Pool | +-------+ | pool1 | +-------+ ``` In terms of setup, I'm running the pool and CLI in two docker containers on a single network. I'm using `ci/indy-pool.dockerfile` and `cli/cli.dockerfile` from master - with one modification; The CLI Dockerfile I have modified to include some genesis transactions. These transactions are copied from the Node sample and I have used the _pool's container name_ *(EDIT: Needed to use IP addresses)* as the values for `client_ip` and `node_ip`. Let me know if you can spot anything about this setup that sounds off. Thanks in advance! *EDIT: Okay I've made progress, as I suspected the client_ip and node_ip must be IP addresses. That error isn't great, but not a major.*

Dominic (Mon, 25 Jun 2018 18:01:23 GMT):
I'm trying to set up the indy sdk on Ubuntu 18.04, but I'm experiencing some issues. I installed from source following [these instructions](https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md) When I try to run the CLI ( ./indy-sdk/cli/target/debug/indy-cli ), I am able to use some commands such as wallet create and wallet open, but others end up with a segfault. For example, if I run `wallet list`, I get the following output: `Segmentation fault (core dumped)`. Am I doing something wrong?

Dominic (Mon, 25 Jun 2018 18:01:23 GMT):
I'm trying to set up the indy sdk on Ubuntu 18.04, but I'm experiencing some issues. I installed from source following [these instructions](https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md). When I try to run the CLI ( ./indy-sdk/cli/target/debug/indy-cli ), I am able to use some commands such as wallet create and wallet open, but others end up with a segfault. For example, if I run `wallet list`, I get the following output: `Segmentation fault (core dumped)`. Am I doing something wrong?

K.Amine (Mon, 25 Jun 2018 23:22:12 GMT):
Hi Everyone, I'm trying to run a script that create wallet and credential transactions for users and organisation from a .csv dataset : Is there a way to export/import wallet and ledger to re-use them whenever I run my script ? (at the moment I have to onboard and create wallets for all agents and it takes about 2hours, it makes debugging very very long...)

Qiu (Tue, 26 Jun 2018 01:31:40 GMT):
@

Qiu (Tue, 26 Jun 2018 01:33:38 GMT):
@gudkov My OS is MacOS! I don't know what to do! sudo vagrant up agent01 The VirtualBox VM was created with a user that doesn't match the current user running Vagrant. VirtualBox requires that the same user be used to manage the VM that was created. Please re-run Vagrant with that user. This is not a Vagrant issue. The UID used to create the VM was: 501 Your UID is: 0 vagrant up agent01 Bringing machine 'agent01' up with 'virtualbox' provider... ==> agent01: Checking if box 'bento/ubuntu-16.04' is up to date... /opt/vagrant/embedded/gems/2.1.1/gems/vagrant-2.1.1/lib/vagrant/action/builtin/handle_forwarded_port_collisions.rb:203:in `initialize': Permission denied @ rb_sysopen - /Users/qiubo/.vagrant.d/data/fp-leases/127_0_0_1_2206 (Errno::EACCES)

dbluhm (Tue, 26 Jun 2018 02:45:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RgcwvG26sNwN7zQqK) @Qiu If you intend to develop using Indy-sdk or even make contributions to Indy-sdk, I do not recommend using Vagrant. I suggest starting off with the README in the indy-sdk repo (https://github.com/hyperledger/indy-sdk) then follow instructions for building on MacOS (https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md). @ryanwest6 and I recently improved the MacOS build documentation but have not yet created a PR for it to the indy-sdk repo but if you're interested in a little more detail than what is given in the original instructions, look here: https://github.com/dbluhm/indy-sdk/blob/master/doc/mac-build.md If after following these steps you run into any issues or have any questions, please ask here :slight_smile:

dbluhm (Tue, 26 Jun 2018 02:45:56 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=N4CH2FS46xWkT5nFQ) @K.Amine Seems like it might be a good idea to reduce the input size while you're working on debugging then go back to your original dataset when you've got most of the bugs out :slight_smile:

dbluhm (Tue, 26 Jun 2018 02:48:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=XXtLxcu8n3eocA4HN) @Dominic What version of the indy-sdk are you using? It might also be a good idea to try invoking the cli with `RUST_LOG=trace path/to/indy-cli` to get more output from libindy

Qiu (Tue, 26 Jun 2018 03:04:19 GMT):
@dbluhm Thankyou!

SherifMuhammed (Tue, 26 Jun 2018 06:44:43 GMT):
Has joined the channel.

Qiu (Tue, 26 Jun 2018 08:19:49 GMT):
Hi Everyone,I want to ask you about these two questions has anyone ever met them? How? "vagrant@agent01:~$ python /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/faber.py --port 5555 --network 10.20.30.101 File "/usr/local/lib/python3.5/dist-packages/indy_client/test/agent/faber.py", line 99 async def bootstrap_faber(agent): ^ SyntaxError: invalid syntax" "ALICE@sandbox> accept request from "Faber College" Request not yet verified. Attempting to sync... Synchronizing... Connection Faber College synced Connection Faber College synced Accepting request with nonce b1134a647eb818069c089e7694f63e6d from id ULtgFQJe6bjiFbs7ke3NJD CONNECTION: bf1e05 looking for Faber College at 10.20.30.101:5555"

Qiu (Tue, 26 Jun 2018 08:19:49 GMT):
Hi Everyone,I want to ask you about these two questions has anyone ever met them? How? ```"vagrant@agent01:~$ python /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/faber.py --port 5555 --network 10.20.30.101 File "/usr/local/lib/python3.5/dist-packages/indy_client/test/agent/faber.py", line 99 async def bootstrap_faber(agent): ^ SyntaxError: invalid syntax" "ALICE@sandbox> accept request from "Faber College" Request not yet verified. Attempting to sync... Synchronizing... Connection Faber College synced Connection Faber College synced Accepting request with nonce b1134a647eb818069c089e7694f63e6d from id ULtgFQJe6bjiFbs7ke3NJD CONNECTION: bf1e05 looking for Faber College at 10.20.30.101:5555"```

Qiu (Tue, 26 Jun 2018 08:19:49 GMT):
Hi Everyone,I want to ask you about these two questions has anyone ever met them? How? ```vagrant@agent01:~$ python /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/faber.py --port 5555 --network 10.20.30.101 File "/usr/local/lib/python3.5/dist-packages/indy_client/test/agent/faber.py", line 99 async def bootstrap_faber(agent): ^ SyntaxError: invalid syntax``` ```ALICE@sandbox> accept request from "Faber College" Request not yet verified. Attempting to sync... Synchronizing... Connection Faber College synced Connection Faber College synced Accepting request with nonce b1134a647eb818069c089e7694f63e6d from id ULtgFQJe6bjiFbs7ke3NJD CONNECTION: bf1e05 looking for Faber College at 10.20.30.101:5555```

Dominic (Tue, 26 Jun 2018 17:44:17 GMT):
I ended up just going for an apt installation with ubuntu 16.04

slr (Tue, 26 Jun 2018 22:56:42 GMT):
I'm getting an error that says UnhandledPromiseRejectionWarning, anyone else run into this issue when running the sample for indy-sdk?

Qiu (Wed, 27 Jun 2018 01:59:44 GMT):
Hi Everyone,After I run the indy command in docer, this error appears. How can I solve it? ```Exception in callback PosixAsyncioEventLoop.run_as_coroutine..stdin_ready() at /usr/lib/python3/dist-packages/prompt_toolkit/eventloop/asyncio_posix.py:65 handle: .stdin_ready() at /usr/lib/python3/dist-packages/prompt_toolkit/eventloop/asyncio_posix.py:65>```

PhillipGibb (Wed, 27 Jun 2018 04:55:14 GMT):
Hi, Using the latest indy-sdk for a nodejs app and I am getting: Error: Expected Timestamp for timestamp: setProtocolVersion(protocol_version, cb(err)) any thoughts why this is happening?

PhillipGibb (Wed, 27 Jun 2018 05:12:41 GMT):
actually that is what happens when you pass a string to setProtocolVersion, very misleading error

PhillipGibb (Wed, 27 Jun 2018 05:30:35 GMT):
anyone using `docker build -f ci/indy-pool.dockerfile -t indy_pool .`

PhillipGibb (Wed, 27 Jun 2018 05:31:18 GMT):
indy cli can't connect to Node1 - it timesout

SherifMuhammed (Wed, 27 Jun 2018 07:01:42 GMT):
Hi everyone , is it possible to integrate Indy with Fabric ?

dungnguyen116 (Wed, 27 Jun 2018 08:50:55 GMT):
UnhandledPromiseRejectionWarning: IndyError: CommonInvalidState

Dominic (Wed, 27 Jun 2018 14:06:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=rGKZr7BSRFtB4bom3) @slr put your code that returns a promise in a try-catch block

Dominic (Wed, 27 Jun 2018 14:52:33 GMT):
I don't really understand what a NYM transaction is, and how it interacts with the ledger. Can anyone clear up this concept for me?

sklump (Wed, 27 Jun 2018 15:29:01 GMT):
A (crypto)NYM write transaction writes a public key to the ledgr corresponding to an entity's private key in the wallet. Only a steward (or higher) has privilege to write such a transaction, anchoring a DID to the ledger. Anybody can subsequently query the ledger to read the public part of the NYM, allowing communication with the corresponding entity. Once anchored to the ledger, a DID owner can sign and submit write transactions to the ledger; the indy-sdk manages the crypto aspect via a wallet handle parameter. If the wallet doesn't have a private key for its DID, no sale.

sklump (Wed, 27 Jun 2018 15:29:01 GMT):
A (crypto)NYM write transaction writes a public key to the ledger corresponding to an entity's private key in the wallet. Only a steward (or higher) has privilege to write such a transaction, anchoring a DID to the ledger. Anybody can subsequently query the ledger to read the public part of the NYM, allowing communication with the corresponding entity. Once anchored to the ledger, a DID owner can sign and submit write transactions to the ledger; the indy-sdk manages the crypto aspect via a wallet handle parameter. The wallet must prove private key ownership for its DID (indy-node protocol verifies), the transaction may proceed.

sklump (Wed, 27 Jun 2018 15:29:01 GMT):
A (crypto)NYM write transaction writes a public key to the ledger corresponding to an entity's private key in the wallet. Only a steward (or higher) has privilege to write such a transaction, anchoring a DID to the ledger. Anybody can subsequently query the ledger to read the public part of the NYM, allowing communication with the corresponding entity. Once anchored to the ledger, a DID owner can sign and submit write transactions to the ledger; the indy-sdk manages the crypto aspect via a wallet handle parameter. If the (open) wallet can prove private key ownership for its DID (indy-node protocol verifies), the transaction may proceed.

sklump (Wed, 27 Jun 2018 15:29:01 GMT):
A (crypto)NYM write transaction writes a public key to the ledger corresponding to an entity's private key in the wallet. Only a steward (or higher) has privilege to write such a transaction, anchoring a DID to the ledger. Anybody can subsequently query the ledger to read the public part of the NYM, allowing communication with the corresponding entity. Once anchored to the ledger, a DID owner can sign and submit write transactions to the ledger; the indy-sdk manages the crypto aspect via a wallet handle parameter. If the (open) wallet can prove private key ownership for its DID (indy-sdk verifies via indy-node), the transaction may proceed.

sklump (Wed, 27 Jun 2018 15:29:01 GMT):
A (crypto)NYM write transaction writes a public key to the ledger corresponding to an entity's private key in the wallet. Only a ~steward~trustee (or higher) has privilege to write such a transaction, anchoring a DID to the ledger. Anybody can subsequently query the ledger to read the public part of the NYM, allowing communication with the corresponding entity. Once anchored to the ledger, a DID owner can sign and submit write transactions to the ledger; the indy-sdk manages the crypto aspect via a wallet handle parameter. If the (open) wallet can prove private key ownership for its DID (indy-sdk verifies via indy-node), the transaction may proceed.

swcurran (Wed, 27 Jun 2018 15:38:17 GMT):
That is right except the use of the term "Steward". It's actually a Trust Anchor that can write such a transaction.

sklump (Wed, 27 Jun 2018 15:52:33 GMT):
Not true. Everyone on the ledger is a trust anchor. It's confusing.

sklump (Wed, 27 Jun 2018 15:52:43 GMT):
It might be "trustee".

json (Wed, 27 Jun 2018 19:38:06 GMT):
Hi guys, I'm trying python tuts again and getting error code 113 (ErrorCode.CommonIOError). I know that it's usually caused by incorrect genesis file path, but I've verified that it's completely correct. Code snippet below - it fails on #2 - open_pool_ledger. Any help greatly appreciated!

json (Wed, 27 Jun 2018 19:38:14 GMT):
```pool_name = 'pool' wallet_name = 'wallet' genesis_file_path = '../indy-sdk/cli/docker_pool_transactions_genesis' async def write_schema_and_cred_def(): try: await pool.set_protocol_version(2) # 1. print_log('\n1. Creates a new local pool ledger configuration that is used ' 'later when connecting to ledger.\n') pool_config = json.dumps({'genesis_txn': genesis_file_path}) try: await pool.create_pool_ledger_config(pool_name, pool_config) except IndyError: await pool.delete_pool_ledger_config(config_name=pool_name) await pool.create_pool_ledger_config(pool_name, pool_config) # 2. print_log('\n2. Open pool ledger and get handle from libindy\n') pool_handle = await pool.open_pool_ledger(config_name=pool_name, config=None)```

json (Wed, 27 Jun 2018 19:38:14 GMT):
`pool_name = 'pool' wallet_name = 'wallet' genesis_file_path = '../indy-sdk/cli/docker_pool_transactions_genesis' async def write_schema_and_cred_def(): try: await pool.set_protocol_version(2) # 1. print_log('\n1. Creates a new local pool ledger configuration that is used ' 'later when connecting to ledger.\n') pool_config = json.dumps({'genesis_txn': genesis_file_path}) try: await pool.create_pool_ledger_config(pool_name, pool_config) except IndyError: await pool.delete_pool_ledger_config(config_name=pool_name) await pool.create_pool_ledger_config(pool_name, pool_config) # 2. print_log('\n2. Open pool ledger and get handle from libindy\n') pool_handle = await pool.open_pool_ledger(config_name=pool_name, config=None)`

json (Wed, 27 Jun 2018 19:39:43 GMT):
Debug trace: ```INFO|indy::services::pool | src\services\pool\mod.rs:692 | RemoteNode::recv_msg Node4 {"reason":"client request invalid: InvalidClientRequest() [caused by number of parameters should be less than or equal to the number of fields in schema, but it was 6]","reqId":null,"op":"REQNACK","identifier":""} INFO|indy::services::pool | src\services\pool\mod.rs:692 | RemoteNode::recv_msg Node2 po TRACE|indy::services::pool | src\services\pool\mod.rs:86 | Invalid structure: data did not match any variant of untagged enum Response TRACE|indy::services::pool | src\services\pool\mod.rs:273 | process_actions - invalid data ERROR|indy::services::pool | src\services\pool\mod.rs:577 | Pool worker thread finished with error CommonError(IOError(Kind(InvalidData)))```

PhillipGibb (Wed, 27 Jun 2018 19:47:59 GMT):
Still trying to build indy-sdk nodejs wrapper from source in an ubuntu 10.04 docker container

PhillipGibb (Wed, 27 Jun 2018 20:24:28 GMT):
installed libindy and cli successfully but if I compile the nodejs wrapper or npm install indy-sdk in an ubuntu 16.04 build: `../src/indy.cc:4:23: fatal error: indy_core.h: No such file or directory`

K.Amine (Wed, 27 Jun 2018 23:23:40 GMT):
Hi everyone, I have a bug in my script : Basically I'm trying to call get_verynim function (python wrapper) for a common user role input

K.Amine (Wed, 27 Jun 2018 23:26:13 GMT):
`indy_loop_callback: Function returned error 113 Traceback (most recent call last): File "getting-started-debug.py", line 843, in loop.run_until_complete(run()) File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step result = coro.throw(exc) File "getting-started-debug.py", line 384, in run 'common_USER' File "getting-started-debug.py", line 763, in get_verinym authdecrypted_did_info['verkey'], role) File "getting-started-debug.py", line 768, in send_nym nym_request = await ledger.build_nym_request(_did, new_did, new_key, None, role) File "/home/amine/.local/lib/python3.5/site-packages/indy/ledger.py", line 245, in build_nym_request build_nym_request.cb) File "/usr/lib/python3.5/asyncio/futures.py", line 361, in __iter__ yield self # This tells Task to wait for completion. File "/usr/lib/python3.5/asyncio/tasks.py", line 296, in _wakeup future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception indy.error.IndyError: ErrorCode.CommonInvalidStructure `

K.Amine (Wed, 27 Jun 2018 23:26:13 GMT):
``` indy_loop_callback: Function returned error 113 Traceback (most recent call last): File "getting-started-debug.py", line 843, in loop.run_until_complete(run()) File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step result = coro.throw(exc) File "getting-started-debug.py", line 384, in run 'common_USER' File "getting-started-debug.py", line 763, in get_verinym authdecrypted_did_info['verkey'], role) File "getting-started-debug.py", line 768, in send_nym nym_request = await ledger.build_nym_request(_did, new_did, new_key, None, role) File "/home/amine/.local/lib/python3.5/site-packages/indy/ledger.py", line 245, in build_nym_request build_nym_request.cb) File "/usr/lib/python3.5/asyncio/futures.py", line 361, in __iter__ yield self # This tells Task to wait for completion. File "/usr/lib/python3.5/asyncio/tasks.py", line 296, in _wakeup future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception indy.error.IndyError: ErrorCode.CommonInvalidStructure ```

K.Amine (Wed, 27 Jun 2018 23:29:12 GMT):
here is my code snippet : ``` curr_user_did = await get_verinym(pool_handle, "Generic Government", government_wallet, government_did, government_curr_user_key, curr_user_fullname, curr_user_wallet, curr_user_government_did, curr_user_government_key, 'common_USER') ```

K.Amine (Wed, 27 Jun 2018 23:29:34 GMT):
does anyone has role variable for common users ?

Neumann347 (Thu, 28 Jun 2018 01:19:16 GMT):
@sklump @swcurran - Piggy backing on @Dominic 's question: How does a trustee get added to the ledger?

sergey.minaev (Thu, 28 Jun 2018 08:31:24 GMT):
@json 10 please share few more lines above for debug trace. Up to trace about sending to nodes data. Also please specify version of indy sdk (rc/stable/master, version number) and Indy Node version.

sergey.minaev (Thu, 28 Jun 2018 08:35:09 GMT):
@K.Amine if you would like to create common user without special rule, you have to pass `None` as role parameter

sergey.minaev (Thu, 28 Jun 2018 08:35:09 GMT):
@K.Amine if you would like to create common user without special rule, you have to pass `None` as role parameter Here is a list of available roles https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/indy/ledger.py#L212 . I see `null` here, but most probably it's copipaste from other language wrapper.

sergey.minaev (Thu, 28 Jun 2018 08:46:46 GMT):
@Dominic @swcurran Main roles in Indy networks are: Trustee, Steward, Trust Anchor and simple user without role (in order of decreasing permissions). You can find useful links in sdk and also node github repo. E.g. https://github.com/hyperledger/indy-node/blob/master/README.md#docs-and-links contains link to detailed roles description: https://docs.google.com/spreadsheets/d/1TWXF7NtBjSOaUIBeIH77SyZnawfo91cJ_ns4TR-wsq4/

sergey.minaev (Thu, 28 Jun 2018 08:46:46 GMT):
@Dominic @sklump Main roles in Indy networks are: Trustee, Steward, Trust Anchor and simple user without role (in order of decreasing permissions). You can find useful links in sdk and also node github repo. E.g. https://github.com/hyperledger/indy-node/blob/master/README.md#docs-and-links contains link to detailed roles description: https://docs.google.com/spreadsheets/d/1TWXF7NtBjSOaUIBeIH77SyZnawfo91cJ_ns4TR-wsq4/

sergey.minaev (Thu, 28 Jun 2018 08:46:46 GMT):
@Dominic @sklump Main roles in Indy networks are: Trustee, Steward, Trust Anchor and Identity Owner - simple user - no role in NYM txn (in order of decreasing permissions). You can find useful links in sdk and also node github repo. E.g. https://github.com/hyperledger/indy-node/blob/master/README.md#docs-and-links contains link to detailed roles description: https://docs.google.com/spreadsheets/d/1TWXF7NtBjSOaUIBeIH77SyZnawfo91cJ_ns4TR-wsq4/

sklump (Thu, 28 Jun 2018 10:23:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=HCwn32hRar6dHwgb3) The Genesis transactions include the first trustee. I believe trustees can add further trustees (?).

Neumann347 (Thu, 28 Jun 2018 13:49:24 GMT):
I am having some trouble connecting this to the samples. In https://github.com/hyperledger/indy-sdk/blob/master/samples/python/src/utils.py the pool genesis txn data doesn't have any NYM transactions, they only have NODE transactions. I am unclear how the original steward got onto the ledger to allow for further additions. How does that bootstrapping work?

sergey.minaev (Thu, 28 Jun 2018 14:01:05 GMT):
NYM and NODE txns are belong to different ledgers. SDK use genesis transactions of pool ledger to connect to right nodes. So only genesis for NODE are required and are showed in samples code. In default development environment Trustee from genesis transaction is created from seed `000000000000000000000000Trustee1` All sets of genesis transactions are formed at indy-node bootstrapping. SDK provides indy-pool.dockerfile and you can find line `generate_indy_pool_transactions`. For more details about this script behavior please ask questions about generating genesis transactions in #indy-node channel.

PhillipGibb (Thu, 28 Jun 2018 14:06:02 GMT):
is it possible that someone (maybe from the indy team) to put together a docker file for ubuntu that have libindy, libnullpay, and the nodejs wrapper (1.5.0) installed on the sample project. who will accept the challange

sergey.minaev (Thu, 28 Jun 2018 14:07:50 GMT):
@gudkov what current status and our plans about NodeJS CD? (in context of question above)

PhillipGibb (Thu, 28 Jun 2018 14:45:38 GMT):
@sergey.minaev @gudkov if ubuntu is off the table for now; what docker container would you suggest that I can run a nodejs app in to connect to another docker container running a pool of nodes

saholman (Thu, 28 Jun 2018 21:53:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=rGKZr7BSRFtB4bom3) @slr How far did you get in the sample? What was the last log that printed? If that doesn't help you narrow down what went wrong, try defining the environment variable `RUST_LOG=TRACE` to see the indy logs. If you post the standard logs and the rust (indy) logs, we can help debug the problem a little easier.

stanleyc-trustscience (Thu, 28 Jun 2018 22:42:34 GMT):
Hi guys, what is the process of sending a PR request to indy-sdk This is a new indy-sdk wrapper, that I think would be useful. What's the process for this?

stanleyc-trustscience (Thu, 28 Jun 2018 22:42:34 GMT):
Hi guys, what is the process of sending a PR request to #indy-sdk This is a new indy-sdk wrapper, that I think would be useful. What's the process for this?

stanleyc-trustscience (Thu, 28 Jun 2018 22:43:56 GMT):
I am thinking of making a skeleton project first, and then gradually add in more wrapped methods (either by me or the community) ... or should I complete all methods and send the PR?

stanleyc-trustscience (Thu, 28 Jun 2018 22:44:56 GMT):
Do I need to create any JIRA ticket? ...

arunwij (Fri, 29 Jun 2018 05:51:37 GMT):
Has joined the channel.

gudkov (Fri, 29 Jun 2018 08:08:32 GMT):
@stanleyc-trustscience here is presentation about contribution process https://docs.google.com/presentation/d/1zbb1-4TjH1-iYN7LnFZyPWvB1w-YcoUwKYCfByugSE0/edit#slide=id.p Also about PRs https://github.com/hyperledger/indy-node#how-to-send-a-pr

gudkov (Fri, 29 Jun 2018 08:10:13 GMT):
Before submitting a new wrapper we need discussion. In current vision indy-sdk repo should contain only small set of thier-1 wrappers. All other wrappers can be maintained in its own repo.

sergey.minaev (Fri, 29 Jun 2018 09:54:55 GMT):
The CI policy IndySDK repository is changed: now we don't accept Pull Requests with warnings in libindy, libnullpay or CLI codebase. To pass CI the code of these modules must not contains any warnings.

pimotte (Fri, 29 Jun 2018 11:48:18 GMT):
I noticed the android build instructions got merged to master, and I managed to build an arm binary, but trying to use it in an application leads to zeromq sockets timing out, anyone who has seen this before?

gudkov (Fri, 29 Jun 2018 12:32:55 GMT):
@pimotte You need to make sure that you have correct access to the pool from android device.

pimotte (Fri, 29 Jun 2018 12:33:45 GMT):
The approach I took was using the docker-compose file with host-networking and inserting my ip as TEST_POOL_IP

gudkov (Fri, 29 Jun 2018 12:34:46 GMT):
try to run any telnet app from the same device and check aceess

pimotte (Fri, 29 Jun 2018 12:36:25 GMT):
Gotcha, I'll try that

pimotte (Fri, 29 Jun 2018 12:39:41 GMT):
If I telnet to $TEST_POOL_IP:9701 I get connecting... and then a weird character

pimotte (Fri, 29 Jun 2018 12:40:19 GMT):
I think that means I can connect, right? I tried with my pool offline and got "Connection Refused" instead

pimotte (Fri, 29 Jun 2018 12:41:48 GMT):
Question, in the genesis transaction, there's "client_ip" and "node_ip", should those be different if there are different devices involved?

pimotte (Fri, 29 Jun 2018 12:55:15 GMT):
(I tried changing the client_ip to the android devices ip, but that didn't help, so I restored that)

pimotte (Fri, 29 Jun 2018 12:57:39 GMT):
Nvm, it actually looks like this is getting timed out as well

pimotte (Fri, 29 Jun 2018 13:03:41 GMT):
What should I be seeing if the connection is successful?

gudkov (Fri, 29 Jun 2018 15:24:52 GMT):
you need to check what is exact content of genesis transactions file that you use on client side and on node side. Files must be exactly the same.

gudkov (Fri, 29 Jun 2018 15:25:04 GMT):
libindy doesn't handle $TEST_POOL_IP variable at all

gudkov (Fri, 29 Jun 2018 15:25:28 GMT):
so check your code and fine moment were genesis txns are created.

gudkov (Fri, 29 Jun 2018 15:25:28 GMT):
so check your code and find the moment were genesis txns are created.

gudkov (Fri, 29 Jun 2018 15:26:13 GMT):
telnet should show Curve message from Node

smithbk (Fri, 29 Jun 2018 19:41:37 GMT):
As a verifier, is there any way to restrict based on a schema def ID rather than a cred def ID, or any plans to allow for this? For example, if there was a college schema, then I could generate a proof request for any college, not just Faber college.

smithbk (Fri, 29 Jun 2018 19:41:37 GMT):
@swcurran Great, thanks. So this is supported in the current sovrin stable version?

tomislav (Fri, 29 Jun 2018 20:19:31 GMT):
The podspec for libindy for iOS version 1.5.0 points to a repo, but the file doesn't exist yet on the repo. (https://repo.sovrin.org/ios/libindy/stable/indy-objc/1.5.0/libindy-objc.zip) Will it be added soon? Furthermore, the 1.4.0 version of the framework is build using Swift 4.0.2, which isn't compatible with the latest Swift available with xcode, swift 4.1. I can build the pod manually and create framework, works fine, but would be nice to just have it in Podfile work

swcurran (Fri, 29 Jun 2018 20:47:34 GMT):
@smithbk - that is supported now. It is part of the proof request that the verifier gives to the holder/prover - in the restrictions element.

swcurran (Fri, 29 Jun 2018 20:47:34 GMT):
@smithbk - that is supported now. It is part of the proof request that the verifier gives to the holder/prover - in the restrictions element. - Here is an example of using a schema as the restriction - https://github.com/bcgov/permitify/blob/master/site_templates/city_of_surrey/proof_request.json

swcurran (Fri, 29 Jun 2018 20:50:57 GMT):
@smithbk - yes. It's been there since about the January timeframe. Not sure in what version it was added, but its been awhile.

smithbk (Fri, 29 Jun 2018 20:51:08 GMT):
thanks

smithbk (Sat, 30 Jun 2018 17:07:15 GMT):
@swcurran If A issues a cred to B and B issues a cred to C, how could A generate a proof request for C to prove this indirect relationship to itself?

swcurran (Sat, 30 Jun 2018 21:01:24 GMT):
@smithbk - interesting question... In theory, A could send a Proof Request to C for data from the B->C Credential. A then knows who issued that Credential (B) - at least a DID of B. From there, A might be able to determine that the B they know and the Issuer of the B->C Credential are one and the same. However - no guarantee they could do that. This would work if the parties were motivated to prove that. Another possibility is that A puts a piece of data that C would know into the Credential to B, and B puts that into the Credential to C. A gets in the Proof that piece of data. Do you have more of a business case around this? Depending on the relationship between the parties there might be different ways to do this. For example, we plan on using that latter approach for Delegation of Authority via Credentials. But that assumes there is a business reason for the parties to want interact that way. The thing to remember is that the use of pairwise DIDs for connections mean that there are many DIDs -- not just one per Identity. As such, the DID A has for B is different from the DID C has for B. This deliberately prevents correlation, which in turn deliberately prevents the scenario you present by default.

smithbk (Mon, 02 Jul 2018 02:36:10 GMT):
@swcurran The use case is that an app provides services to multiple premium clients, and those clients in turn have multiple suppliers of goods. The app also provides different services to these suppliers, and therefore needs to authenticate them.

smithbk (Mon, 02 Jul 2018 02:38:29 GMT):
Anyone, I'm seeing the following issue: https://jira.hyperledger.org/browse/IS-800. I am able to run these same images locally using a docker-compose with 127.0.0.1 addresses in my genesis file. But I can't get it to work when running this in the cloud. Thanks for the help.

arunwij (Mon, 02 Jul 2018 04:34:05 GMT):
Hello everyone, I am following dev env setup guide on Mac(indy-sdk). I have built the libraries according to the guide. There is another section I need to follow, "Docker port mapping on MacOS". I am using Docker for Mac. Since it is based on Hyperkit (Not VirtualBox or Vmware Fusion ). How do I map ports? or do I need to use VBox or Fusion based implementation of docker?

KanupriyaPandey (Mon, 02 Jul 2018 05:42:57 GMT):
Has joined the channel.

LuigiRiva (Mon, 02 Jul 2018 07:57:50 GMT):
Has joined the channel.

janl (Mon, 02 Jul 2018 08:16:14 GMT):
Has joined the channel.

sergey.minaev (Mon, 02 Jul 2018 08:51:00 GMT):
@arunwij I can't advice something about Hyperkit, But for simple running try to use first configuration (127.0.0.1:9701-9708). Is it works for you?

sergey.minaev (Mon, 02 Jul 2018 08:51:00 GMT):
@arunwij I can't advice something about Hyperkit. But for simple running try to use first configuration (127.0.0.1:9701-9708). Is it works for you?

LuigiRiva (Mon, 02 Jul 2018 09:00:10 GMT):
Hello everyone! I am looking for a some best practice where to see which strategies can be used in order to integrate Indy with fabric. In my understanding there isn't (yet) a native integration. Anyway my goal would be to use indy ad a CA for Fabric. Any suggestion???

smithbk (Mon, 02 Jul 2018 11:54:34 GMT):
@LuigiRiva There is currently no integration point, but we have been considering making fabric-ca-server an indy verifier to authorize enrollment. In v1.3 of fabric, we will support issuance of an idemix credential from fabric-ca-server which is also ZKP. Support for indy verification to authorize enrollment would come later. Can you comment on your requirements and/or use case?

ltzMaxwell (Mon, 02 Jul 2018 12:03:34 GMT):
Has joined the channel.

arunwij (Mon, 02 Jul 2018 12:19:12 GMT):
@sergey.minaev yeah i tried it and worked for me. Thank you.

PhillipGibb (Mon, 02 Jul 2018 13:01:20 GMT):
hi, can someone please help me troubleshoot connecting and indy-sdk nodejs app running in docker - it is timing out in connecting to docker pool in the same network

pimotte (Mon, 02 Jul 2018 14:20:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Nnii9vrbn982jgvFn) @gudkov My issue from before the weekend was indeed a connectivity issue. Apperently recent Android versions block any non-https traffic by default.

pimotte (Mon, 02 Jul 2018 14:20:58 GMT):
Thanks for your help!

LuigiRiva (Mon, 02 Jul 2018 16:04:16 GMT):
thanks @smithbk. Mainly we have HF used for chaincode capabilities providing business logic on supply chain - and this is done. We now want to add in this architecture Indy to add self-sovereign identity. In this way we would allow any third party using our platform (and not necessarily running a HF node) to be able to issue identity to their users. So their users can join the platform itself indirectly. Does it makes sense to you this approach?

PhillipGibb (Mon, 02 Jul 2018 18:13:23 GMT):
yayyy, I have finally connected to the indy_pool from my app with indy_sdk: 1. I used the getting-started.dockerfile as a base 2. built indy-sdk from my app (pull 1.5.0-beta) 3. retried the connect a few times 4. it seemed that using dbl quotes in the did info when creating a config to the pool made a different - thats when I noticed that I needed to retry because sometimes it would work and other not

arunwij (Tue, 03 Jul 2018 09:17:07 GMT):
@sergey.minaev Hello, when we are setting LD_LIBRARY_PATH and DYLD_LIBRARY_PATH env variables(on mac), should both variables point to the same path?

VitalijReicherdt (Tue, 03 Jul 2018 09:45:53 GMT):
Has joined the channel.

ThomasKrech (Tue, 03 Jul 2018 09:47:39 GMT):
Has joined the channel.

AxelNennker (Tue, 03 Jul 2018 13:32:49 GMT):
I created an jira issue to improve the libindy code: https://jira.hyperledger.org/browse/IS-801

Dominic (Tue, 03 Jul 2018 16:46:24 GMT):
I'm getting a ```thread '' panicked at 'called `Option::unwrap()` on a `None` value', libcore/option.rs:335:21``` when I run `await indy.proverCreateProof();` I'm using the NodeJS wrapper. Any clue what could be going on here?

tomislav (Tue, 03 Jul 2018 19:13:01 GMT):
Is support for having full URI's as did endpoints (instead IP:PORT) planned for future?

json (Tue, 03 Jul 2018 20:09:59 GMT):
Hi guys. It seems that the function `anoncreds.issuer_create_claim_offer` has been removed, possibly as of v1.4.0 of SDK? However, there's nothing in the migration guide, did it get missed?

json (Tue, 03 Jul 2018 20:10:23 GMT):
I'm guessing that we need to use `anoncreds.issuer_create_credential_offer` now instead of create_claim_offer?

json (Tue, 03 Jul 2018 20:10:23 GMT):
I'm guessing that we need to use `anoncreds.indy_issuer_create_credential_offer` now instead of create_claim_offer?

swcurran (Tue, 03 Jul 2018 21:18:22 GMT):
@tomislav - are you talking about node endpoints or DIDs? DID endpoints are up to the agent to process, and can be anything. AFAIK - nodes are IP:Port and that is planned.

sejalsoftware (Wed, 04 Jul 2018 01:32:00 GMT):
Has joined the channel.

tomislav (Wed, 04 Jul 2018 03:09:06 GMT):
@swcurran I was referring to storing "endpoint" attribute on the ledger using build_attrib_request. Currently, ledger returns `"client request invalid: InvalidClientRequest('validation error [ClientAttribOperation]: invalid endpoint address (ha=https:\\/\\/gogole.com)`. Maybe I'm using this attrib incorrectly, is it intended for storing endpoints for any DID's or is this just for nodes?

Qiu (Wed, 04 Jul 2018 03:41:37 GMT):
Hi everyone,Have you ever had this problem? Please tell me the solution ```vagrant@agent01:/usr/local/lib/python3.5/dist-packages$ sudo python3 /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/faber.py --port 5555 --network 10.20.30.101 Loading module /usr/local/lib/python3.5/dist-packages/config/config-crypto-example1.py Module loaded. DEBUG:root:Starting ledger... DEBUG:root:Recovering tree from transaction log DEBUG:root:Recovered tree in 0.014402603002963588 seconds INFO:stp_core.common.log:c737f2 updated its pool parameters: f 0, totalNodes 0,minNodesToConnect 1, quorums {'view_change_done': Quorum(0), 'propagate': Quorum(1), 'view_change': Quorum(0), 'ledger_status_last_3PC': Quorum(1), 'observer_data': Quorum(1), 'propagate_primary': Quorum(1), 'bls_signatures': Quorum(0), 'prepare': Quorum(-1), 'consistency_proof': Quorum(1), 'election': Quorum(0), 'f': 0, 'same_consistency_proof': Quorum(1), 'reply': Quorum(1), 'ledger_status': Quorum(-1), 'timestamp': Quorum(1), 'commit': Quorum(0), 'checkpoint': Quorum(-1)} INFO:stp_core.common.log:Signing and Encryption keys were not found for HVimkpMto5EnLBJiAoqjoGXpn8NHGPQiPZ9uNjvnNKYY. Creating them now INFO:stp_core.common.log:Client c737f2 found an empty node registry: DEBUG:plugin-loader:Plugin loading started to load plugins from plugins_dir: /home/vagrant/.indy-cli/networks/10.20.30.101 DEBUG:plugin-loader:Total plugins loaded from plugins_dir /home/vagrant/.indy-cli/networks/10.20.30.101 are : 0 DEBUG:asyncio:Using selector: EpollSelector INFO:stp_core.common.log:Saved wallet "Faber College" restored (/home/vagrant/.indy-cli/wallets/agents/faber-college/faber college.wallet) INFO:stp_core.common.log:Saved wallet "issuer" restored (/home/vagrant/.indy-cli/wallets/agents/faber-college/issuer/issuer.wallet) INFO:stp_core.common.log:Starting up indy-node DEBUG:zmq.auth:Starting ZAP at inproc://zeromq.zap.1 DEBUG:zmq.auth:Allowing 0.0.0.0 DEBUG:zmq.auth:Configure curve: *[*] INFO:stp_core.common.log:CONNECTION: HVimkpMto5EnLBJiAoqjoGXpn8NHGPQiPZ9uNjvnNKYY listening for other nodes at 0.0.0.0:6040 DEBUG:zmq.auth:Starting ZAP at inproc://zeromq.zap.2 DEBUG:zmq.auth:Allowing 0.0.0.0 DEBUG:zmq.auth:Configure curve: *[*] INFO:stp_core.common.log:Running Faber College now (port: 5555) ERROR:stp_core.common.log:is_connected failed; not trying any more because 120 seconds have passed; args were (,) ERROR:stp_core.common.log:Error while running coroutine wait_until_connected: NotConnectedToNetwork("Client hasn't finished catch-up with Pool Ledger yet or doesn't have sufficient number of connections",) INFO:stp_core.common.log:Looper shutting down now... INFO:stp_core.common.log:Active wallet "Faber College" saved (/home/vagrant/.indy-cli/wallets/agents/faber-college/faber college.wallet) INFO:stp_core.common.log:Active wallet "issuer" saved (/home/vagrant/.indy-cli/wallets/agents/faber-college/issuer/issuer.wallet) INFO:stp_core.common.log:stack HVimkpMto5EnLBJiAoqjoGXpn8NHGPQiPZ9uNjvnNKYY closing its listener DEBUG:zmq.auth:Stopping ZAP at b'inproc://zeromq.zap.1' INFO:stp_core.common.log:stack HVimkpMto5EnLBJiAoqjoGXpn8NHGPQiPZ9uNjvnNKYY stopped INFO:stp_core.common.log:stack FaberCollege closing its listener DEBUG:zmq.auth:Stopping ZAP at b'inproc://zeromq.zap.2' INFO:stp_core.common.log:stack FaberCollege stopped INFO:stp_core.common.log:Looper shut down in 0.022 seconds. ERROR:stp_core.common.log: ------------------------------------------------------------------ERROR------------------------------------------------------------------ Agent startup failed: [cause : Client hasn't finished catch-up with Pool Ledger yet or doesn't have sufficient number of connections] ------------------------------------------------------------------ERROR------------------------------------------------------------------ sys:1: RuntimeWarning: coroutine 'bootstrap_faber' was never awaited```

arunwij (Wed, 04 Jul 2018 06:06:46 GMT):
after cargo build --release for building libindy export LD_LIBRARY_PATH="$HOME/Blockchain/indy/indy-sdk/libindy/target/debug" export DYLD_LIBRARY_PATH="$HOME/Blockchain/indy/indy-sdk/libindy/target/debug" in the .bash_profile, after that i tried to install indy nodejs SDK by,

arunwij (Wed, 04 Jul 2018 06:16:13 GMT):
in my mac, after *cargo build* for building libindy ```export LD_LIBRARY_PATH="$HOME/Blockchain/indy/indy-sdk/libindy/target/debug" export DYLD_LIBRARY_PATH="$HOME/Blockchain/indy/indy-sdk/libindy/target/debug" ``` in the *.bash_profile*, installed node-gyp and have working make and gcc, after that i tried to install indy nodejs SDK by, `npm install --save indy-sdk` i get this error,

arunwij (Wed, 04 Jul 2018 06:18:26 GMT):
Hello Everyone, in my mac, after `cargo build` for building libindy ``` export LD_LIBRARY_PATH="$HOME/Blockchain/indy/indy-sdk/libindy/target/debug" export DYLD_LIBRARY_PATH="$HOME/Blockchain/indy/indy-sdk/libindy/target/debug" ``` in the *.bash_profile*, installed node-gyp and have working make and gcc, after that i tried to install indy nodejs SDK by, `npm install --save indy-sdk` i get this error, ``` node-gyp rebuild gyp WARN download NVM_NODEJS_ORG_MIRROR is deprecated and will be removed in node-gyp v4, please use NODEJS_ORG_MIRROR gyp WARN download NVM_NODEJS_ORG_MIRROR is deprecated and will be removed in node-gyp v4, please use NODEJS_ORG_MIRROR xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance gyp WARN download NVM_NODEJS_ORG_MIRROR is deprecated and will be removed in node-gyp v4, please use NODEJS_ORG_MIRROR CXX(target) Release/obj.target/indynodejs/src/indy.o SOLINK_MODULE(target) Release/indynodejs.node ld: library not found for -lindy clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [Release/indynodejs.node] Error 1 gyp ERR! build error gyp ERR! stack Error: `make` failed with exit code: 2 gyp ERR! stack at ChildProcess.onExit (/Users/mymac/.nvm/versions/node/v8.11.2/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:258:23) gyp ERR! stack at emitTwo (events.js:126:13) gyp ERR! stack at ChildProcess.emit (events.js:214:7) gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:198:12) gyp ERR! System Darwin 17.5.0 gyp ERR! command "/Users/mymac/.nvm/versions/node/v8.11.2/bin/node" "/Users/mymac/.nvm/versions/node/v8.11.2/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild" gyp ERR! cwd /Users/mymac/Blockchain/indy/indy-nodejs/node_modules/indy-sdk gyp ERR! node -v v8.11.2 gyp ERR! node-gyp -v v3.6.2 gyp ERR! not ok npm WARN indy-nodejs@1.0.0 No repository field. ``` i highly appreciate your help.

arunwij (Wed, 04 Jul 2018 06:18:26 GMT):
Hello Everyone, in my mac, after `cargo build` for building libindy ``` export LD_LIBRARY_PATH="$HOME/Blockchain/indy/indy-sdk/libindy/target/debug" export DYLD_LIBRARY_PATH="$HOME/Blockchain/indy/indy-sdk/libindy/target/debug" ``` in the *.bash_profile*, installed *node-gyp* and have working *make* and *gcc*, after that i tried to install indy nodejs SDK by, `npm install --save indy-sdk` i get this error, ``` node-gyp rebuild gyp WARN download NVM_NODEJS_ORG_MIRROR is deprecated and will be removed in node-gyp v4, please use NODEJS_ORG_MIRROR gyp WARN download NVM_NODEJS_ORG_MIRROR is deprecated and will be removed in node-gyp v4, please use NODEJS_ORG_MIRROR xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance gyp WARN download NVM_NODEJS_ORG_MIRROR is deprecated and will be removed in node-gyp v4, please use NODEJS_ORG_MIRROR CXX(target) Release/obj.target/indynodejs/src/indy.o SOLINK_MODULE(target) Release/indynodejs.node ld: library not found for -lindy clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [Release/indynodejs.node] Error 1 gyp ERR! build error gyp ERR! stack Error: `make` failed with exit code: 2 gyp ERR! stack at ChildProcess.onExit (/Users/mymac/.nvm/versions/node/v8.11.2/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:258:23) gyp ERR! stack at emitTwo (events.js:126:13) gyp ERR! stack at ChildProcess.emit (events.js:214:7) gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:198:12) gyp ERR! System Darwin 17.5.0 gyp ERR! command "/Users/mymac/.nvm/versions/node/v8.11.2/bin/node" "/Users/mymac/.nvm/versions/node/v8.11.2/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild" gyp ERR! cwd /Users/mymac/Blockchain/indy/indy-nodejs/node_modules/indy-sdk gyp ERR! node -v v8.11.2 gyp ERR! node-gyp -v v3.6.2 gyp ERR! not ok npm WARN indy-nodejs@1.0.0 No repository field. ``` i highly appreciate your help.

arunwij (Wed, 04 Jul 2018 06:18:26 GMT):
Hello Everyone, in my *mac*, after `cargo build` for building libindy ``` export LD_LIBRARY_PATH="$HOME/Blockchain/indy/indy-sdk/libindy/target/debug" export DYLD_LIBRARY_PATH="$HOME/Blockchain/indy/indy-sdk/libindy/target/debug" ``` in the *.bash_profile*, installed *node-gyp* and have working *make* and *gcc*, after that i tried to install indy nodejs SDK by, `npm install --save indy-sdk` i get this error, ``` node-gyp rebuild gyp WARN download NVM_NODEJS_ORG_MIRROR is deprecated and will be removed in node-gyp v4, please use NODEJS_ORG_MIRROR gyp WARN download NVM_NODEJS_ORG_MIRROR is deprecated and will be removed in node-gyp v4, please use NODEJS_ORG_MIRROR xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance gyp WARN download NVM_NODEJS_ORG_MIRROR is deprecated and will be removed in node-gyp v4, please use NODEJS_ORG_MIRROR CXX(target) Release/obj.target/indynodejs/src/indy.o SOLINK_MODULE(target) Release/indynodejs.node ld: library not found for -lindy clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [Release/indynodejs.node] Error 1 gyp ERR! build error gyp ERR! stack Error: `make` failed with exit code: 2 gyp ERR! stack at ChildProcess.onExit (/Users/mymac/.nvm/versions/node/v8.11.2/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:258:23) gyp ERR! stack at emitTwo (events.js:126:13) gyp ERR! stack at ChildProcess.emit (events.js:214:7) gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:198:12) gyp ERR! System Darwin 17.5.0 gyp ERR! command "/Users/mymac/.nvm/versions/node/v8.11.2/bin/node" "/Users/mymac/.nvm/versions/node/v8.11.2/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild" gyp ERR! cwd /Users/mymac/Blockchain/indy/indy-nodejs/node_modules/indy-sdk gyp ERR! node -v v8.11.2 gyp ERR! node-gyp -v v3.6.2 gyp ERR! not ok npm WARN indy-nodejs@1.0.0 No repository field. ``` i highly appreciate your help.

Marcus1 (Wed, 04 Jul 2018 06:47:23 GMT):
Has joined the channel.

pradeeppadmarajaiah (Wed, 04 Jul 2018 07:08:38 GMT):
Has joined the channel.

pradeeppadmarajaiah (Wed, 04 Jul 2018 07:08:42 GMT):
or u want to try this one chins

pradeeppadmarajaiah (Wed, 04 Jul 2018 07:08:42 GMT):
Hi Team, I have started exploring an Indy . Need your help, to get hello-world type (create a sample identifier in this case) example using Java which includes setup of Indy nodes to running java sample. I am confused, where to start now

arunwij (Wed, 04 Jul 2018 08:50:30 GMT):
@pradeeppadmarajaiah I recommond you to go through the getting start guide in Indy-sdk (https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md). To run the above example, use this https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/run-getting-started.md. After you getting some idea about indy, you can setup the developing environment by Indy-sdk guide. There is wrapper library for java as well.

arunwij (Wed, 04 Jul 2018 08:50:30 GMT):
@pradeeppadmarajaiah I recommend you to go through the getting started guide in Indy-SDK (https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md). To run the above example, use this https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/run-getting-started.md. After you get some idea about indy, you can setup the developing environment by Indy-SDK guide. There is wrapper library for java as well.

AvikHazra (Wed, 04 Jul 2018 10:23:24 GMT):
hello, when I`m trying to run nodejs sample from indy-sdk, getting error Library not loaded: /usr/local/opt/libsodium/lib/libsodium.23.dylib can anyone please help me what is wrong ?

pradeeppadmarajaiah (Wed, 04 Jul 2018 12:31:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9DnbP5t2wRgM5qBqr) @arunwij Thank you. Let me try it now

swcurran (Wed, 04 Jul 2018 13:59:16 GMT):
@tomislav - wow - I was not aware of that limitation. Let's confirm, but that's completely unacceptable for many reasons. I'm glad to push a jira if we can show that. @mhailstone - has your team come across this in implementing your indy-agent?

swcurran (Wed, 04 Jul 2018 14:14:12 GMT):
@tomislav - according to my understanding and this document - https://github.com/hyperledger/indy-node/blob/master/docs/requests-new.md - and specifically - the ATTRIB and GET_ATTRIB requests - the "raw" field contains name/value pairs and I was of the understanding agents would use that for endpoints. As such, I'm thinking you are using a call that is referencing ledger communication and not DIDs. The DIDs calls don't care about endpoints, it appears. #notcertain

swcurran (Wed, 04 Jul 2018 14:22:43 GMT):
@tomislav - I'm seeing the call you are making in the indy-sdk - presumably here: https://github.com/hyperledger/indy-sdk/blob/d9c66b03c1470055328e0032712595c8540179dc/wrappers/nodejs/README.md#ledger, so it looks like you are making the right call. I don't think Indy-SDK or ledger should have an opinion on what you are sending. Weird.

ianco (Wed, 04 Jul 2018 15:28:42 GMT):
I'm getting a compile error on the latest "master" branch of indy-sdk. I noticed it's related to a commit about 9 days ago, so not sure if this is just me? error: non-reference pattern used to match a reference (see issue #42640) --> src/commands/did.rs:555:24 | 555 | if let Some(data) = &res.data { | ^^^^^^^^^^ help: consider using: `&Some(data)` error: aborting due to previous error error: Could not compile `indy`.

LuigiRiva (Wed, 04 Jul 2018 16:24:14 GMT):
Hi! The Sovrin whitepaper speaks a lot about the incentive model of the network based on a Sovrin token. Could you anyone provide me more technical information about that? Is the possibility to use a token in the Sovrin network already available?

Dominic (Wed, 04 Jul 2018 18:41:58 GMT):
I'm looking at the anoncreds part of the indy-sdk. Is there a list of p_types (predicate types)? The only one I know of is `>=`. Line 893 of [this file](https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/api/anoncreds.rs) suggests that this is currently the only supported p_type. If this is true, what other ones are planned to be added in the future?

tomislav (Thu, 05 Jul 2018 01:52:36 GMT):
@swcurran I worked with the same assumption, that agent endpoint would be added using ATTRIB request. It seems that the "endpoint" attribute is handled as a special case, since it won't accept any other format that doesn't have "ha" and "pubkey" as values. Granted, I'm using indylib 1.4 and node 1.3, perhaps this was addressed with the latest release.

tomislav (Thu, 05 Jul 2018 01:52:36 GMT):
@swcurran I worked with the same assumption, that agent endpoint would be added using ATTRIB request. It seems that the "endpoint" attribute is handled as a special case, since it won't accept any other format that doesn't have "ha" and "pubkey" as values, where "ha" must be of format "ip:port". Granted, I'm using indylib 1.4 and node 1.3, perhaps this was addressed with the latest release.

sergey.minaev (Thu, 05 Jul 2018 12:05:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5YWGYwZfWG59xLJ94) @ianco Please update your rust compiler.

sergey.minaev (Thu, 05 Jul 2018 12:12:02 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wxEbtHGESwZ7P4r9G) @Dominic Yes, only `>=` predicate is available right now. In the future `>`, `<=` and `<` will be supported.

hawkmauk (Thu, 05 Jul 2018 13:37:40 GMT):
I've been doing some work on compiling libindy for android and have a bash build script that may be of use: https://github.com/runcrypto/indy-sdk/blob/android-build/libindy/build-libindy-android.sh Just started work on an app and it is worth noting that you need to add 'net.java.dev.jna:jna:4.5.1' to your dependencies in build.gradle, otherwise the java wrapper scripts will complain about missing the 'com.sun.jna' package (thanks to @AxelNennker for the heads up on that one)

AxelNennker (Thu, 05 Jul 2018 13:57:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=FaCaMxFZm4s684zC8) @hawkmauk My Android test app is here: https://github.com/AxelNennker/DroidLibIndy It does not do anything useful but loads libindy

mhailstone (Thu, 05 Jul 2018 14:47:30 GMT):
https://zoom.us/j/232861185

mhailstone (Thu, 05 Jul 2018 14:52:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=yFxJXxgTCsRJsLz7H) @swcurran @tomislav We have encountered this. Our fix was to set a custom attribute: https://github.com/hyperledger/indy-agent/blob/master/nodejs/indy/src/pool/index.js

ianco (Thu, 05 Jul 2018 15:01:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=XtM4YwS27QtDor6rm) @sergey.minaev Done, updated to rustc 1.27 and is now compiling, thanks!

herveblanc (Thu, 05 Jul 2018 15:52:29 GMT):
Has joined the channel.

tomislav (Thu, 05 Jul 2018 17:18:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6engMCuCS8J5SkZhE) @mhailstone That's one way around it. Custom attribute won't work with `indy_get_endpoint_for_did` for ledger lookup, unless the endpoint has been stored locally using `set_endpoint`. It's easy to do workaround for now using another attribute name, so this isn't a blocking issue, but would be nice if the library supported full URI's

swcurran (Thu, 05 Jul 2018 17:48:54 GMT):
@gudkov - please see the issue above ^^^. Are you familiar with the reasoning on why DID endpoints are limited to ip:port format in indy-sdk? That constraint might be reasonable for nodes, but not for arbitrary DIDs. Is this a JIRA we should put in?

gudkov (Thu, 05 Jul 2018 19:42:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=gkFh3nQTYWJ2hbfFW) @swcurran You can just create a ticket in IS jira. In my vision ATTRIB tx will be replaced with DDO-like approach in the future. Forced format can be current Node validation limitation.

swcurran (Thu, 05 Jul 2018 19:59:44 GMT):
Thanks - will do. Since @tomislav is also seeing it, I think it might be a limitation in the .NET wrapper as well? I couldn't navigate the code well enough to find at what layer the format check is happening.

swcurran (Thu, 05 Jul 2018 20:40:01 GMT):
JIRA created - https://jira.hyperledger.org/projects/IS/issues/IS-805 As I was writing it I noticed that the error message title - "client request invalid", which suggests to me that the error is from Indy-Node. I might do a little more digging to see if that is the case.

swcurran (Thu, 05 Jul 2018 20:52:34 GMT):
Confirmed that the check is in Indy Node, so moved the JIRA to the Indy project - https://jira.hyperledger.org/browse/INDY-1456 I noticed that the format is {"endpoint" : { "ha" : "" }}. What is "ha" in that context? We can use {"endpoint": {"foo": "bar"}} - does that help at all in supporting arbitrary URIs?

mhailstone (Thu, 05 Jul 2018 21:12:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qhkHEwX6Lmw6PZdvm) @tomislav Agreed. We would like it fixed in that way as well.

tomislav (Thu, 05 Jul 2018 21:12:11 GMT):
"ha" stands for "host address" I assume. The format is also coded into libindy - https://github.com/hyperledger/indy-sdk/blob/12c5cdea4838cba9fe095653554817f94a7df042/libindy/src/domain/ledger/attrib.rs#L110 { "ha": "..", "verkey": "" }

pimotte (Fri, 06 Jul 2018 06:52:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=FaCaMxFZm4s684zC8) @hawkmauk I'm on the same path, I'm pretty close to having an android hello-world app that can create a connection and accept a credential. I had one issue that popped up on my physical phone "os operation not allowed" that required a small libindy patch, and I was thrown off a lot by android blocking the zmq connectivity, unless you specify a network security config that allows non-https traffic to your node

pimotte (Fri, 06 Jul 2018 06:54:25 GMT):
Feel free to poke me if you run into anything

srinivasanraghavan (Fri, 06 Jul 2018 07:10:04 GMT):
I get ErrorCode.PoolIncompatibleProtocolVersion error in getting_started.py . I have the correct setup of libindy 1.5 and indynode 1.4 and the protocol version is set for 2

srinivasanraghavan (Fri, 06 Jul 2018 07:11:12 GMT):
Is there any mistake i am making. I am running indy_node using the docker and libindy installed in the host ..

gudkov (Fri, 06 Jul 2018 07:17:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=A88aaedu2mguTRWsw) @srinivasanraghavan The error will be returned if you use old format of genesis transactions. How your genesis txns look on client and on node side?

AxelNennker (Fri, 06 Jul 2018 07:21:37 GMT):
@pimotte would you share your code and config. If not the code then perhaps AndroidManifest.xml and gradle files

pimotte (Fri, 06 Jul 2018 07:36:36 GMT):
@AxelNennker https://github.com/Quintor/StudyBitsWallet here you go

pimotte (Fri, 06 Jul 2018 07:38:24 GMT):
I recommend against running it, as the code as I pushed it is extremely unstable. I'll let you know when it gets to a point where it should be runnable

pimotte (Fri, 06 Jul 2018 07:39:27 GMT):
(Or rather than unstable, it's work in progress and I have not pushed the changes I've made to quindy, our wrapper for indy-sdk)

srinivasanraghavan (Fri, 06 Jul 2018 10:09:32 GMT):
{"reqSignature":{},"txn":{"data":{"data":{"alias":"Node1","blskey":"4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba","client_ip":"10.0.0.2","client_port":9702,"node_ip":"10.0.0.2","node_port":9701,"services":["VALIDATOR"]},"dest":"Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv"},"metadata":{"from":"Th7MpTaRZVRYnPiabds81Y"},"type":"0"},"txnMetadata":{"seqNo":1,"txnId":"fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62"},"ver":"1"} {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node2","blskey":"37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk","client_ip":"10.0.0.2","client_port":9704,"node_ip":"10.0.0.2","node_port":9703,"services":["VALIDATOR"]},"dest":"8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb"},"metadata":{"from":"EbP4aYNeTHL6q385GuVpRV"},"type":"0"},"txnMetadata":{"seqNo":2,"txnId":"1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc"},"ver":"1"} {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node3","blskey":"3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5","client_ip":"10.0.0.2","client_port":9706,"node_ip":"10.0.0.2","node_port":9705,"services":["VALIDATOR"]},"dest":"DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya"},"metadata":{"from":"4cU41vWW82ArfxJxHkzXPG"},"type":"0"},"txnMetadata":{"seqNo":3,"txnId":"7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4"},"ver":"1"} {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node4","blskey":"2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw","client_ip":"10.0.0.2","client_port":9708,"node_ip":"10.0.0.2","node_port":9707,"services":["VALIDATOR"]},"dest":"4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA"},"metadata":{"from":"TWwCRQRZ2ZHMJFn9TzLp7W"},"type":"0"},"txnMetadata":{"seqNo":4,"txnId":"aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008"},"ver":"1"}

srinivasanraghavan (Fri, 06 Jul 2018 10:10:05 GMT):
This is genenis tx generated by getting_started.py code ..

pimotte (Fri, 06 Jul 2018 11:40:20 GMT):
Did anything change between 1.4.0 and 1.5.0 for store_their_did behavior? I'm getting "WalletItemAlreadyExistsException: Item already exists." where I wasn't before

BreizhIndy (Fri, 06 Jul 2018 12:33:43 GMT):
Hello, I would like to know if there is a tool or a function to see all the transaction to the ledger like in fabric or etherscan for example. Thanks in advance

janl (Sat, 07 Jul 2018 11:49:07 GMT):
I am having similar problems with some people running the example on my MAC (https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/run-getting-started.md). The getting-started python script is timing out with error 307 (PoolLedgerTimeout). I have been checking earlier threads and from an earlier thread saw the comment that this means the pool nodes cannot be connected. The genesis_txn file that sets up the configures the ledger has a node_ip set to 127.0.0.1 which was recommended in another post. On inspection of getting-started_pool_network (docker network inspect) there are 2 containers, one with IP address 10.0.0.2 (indy_pool) and 10.0.0.3 (getting_started). I can also see the containers running (docker ps). Any suggestions to identify the problem? Thanks

Xzccc (Sun, 08 Jul 2018 01:42:20 GMT):
Has joined the channel.

jworthington (Sun, 08 Jul 2018 10:51:23 GMT):
Has joined the channel.

akuma921 (Mon, 09 Jul 2018 05:41:53 GMT):
Has joined the channel.

akuma921 (Mon, 09 Jul 2018 05:43:36 GMT):
Hi All, I am a newbie in Indy..I successfully tried the indy example (Alice) from CLI as well from node-sdk

akuma921 (Mon, 09 Jul 2018 05:44:31 GMT):
I want to make it a more demoable product with a UI ...so want to expose all these actions via Rest API

akuma921 (Mon, 09 Jul 2018 05:45:45 GMT):
but when I look thru the node example ..I found every wallet onboaring required existing wallet ..so in case of creating a Alice Wallet we need faberwallet there ..which is not possible, right?

akuma921 (Mon, 09 Jul 2018 05:48:08 GMT):
any help?

akuma921 (Mon, 09 Jul 2018 05:48:52 GMT):
anybody implemented separate node interaction for each entity ..like Alice, Faber etc.

pimotte (Mon, 09 Jul 2018 07:15:54 GMT):
When calling "store_their_did" after some other operations using indy-sdk 1.5.0 I get "Item already exists", when I haven't called store_their_did with that did before. Anyone has some idea what might be going on?

MyMate (Mon, 09 Jul 2018 07:16:28 GMT):
I am trying to use libindy for .NET but it fails when I call the NativeMethods.indy_open_pool_ledger method in the wrapper samples - the error was "unmapped error with the code '308'"

MyMate (Mon, 09 Jul 2018 07:18:52 GMT):
dotnet

pimotte (Mon, 09 Jul 2018 09:44:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qTzDJ8rWRYHoQtWCe) @MyMate The error is PoolIncompatibleProtocolVersion, so make sure you're setting the protocol version, and running a pool that supports that version

pradeeppadmarajaiah (Mon, 09 Jul 2018 11:27:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9DnbP5t2wRgM5qBqr) @arunwij Hi Arun, Thanks for the help. I am able to python samples successfully. Need to know ,how to do running setup for java based samples. Not sure, https://github.com/arunwij/indy-sdk/blob/master/wrappers/java/README.md . I tried. Please guide me in setting up environment for java

pradeeppadmarajaiah (Mon, 09 Jul 2018 11:32:10 GMT):
Hi Team,Need your help. Need to know ,how to do running setup for java based samples.

gudkov (Mon, 09 Jul 2018 11:58:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=BYqkusKaEZtNcaBcu) @pradeeppadmarajaiah You need: 1. JDK and maven 2. libindy binaries in PATH and that's all

sklump (Mon, 09 Jul 2018 12:11:05 GMT):
Hi folks, I took a week off and now my wallet code is very broken with respect to the master. Is there a document on what happened to the relationship between pools and wallets?

pimotte (Mon, 09 Jul 2018 12:27:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=vz8zoawxuhFQND4Nc) @sklump Perhaps you're looking for https://github.com/hyperledger/indy-sdk/blob/master/doc/migration-guide-1.4.0-1.5.0.md ? (If it's something more recent, I wouldn't know either)

sklump (Mon, 09 Jul 2018 12:40:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=FxMGMALL5s8iCzXat) @pimotte Thanks, but I suspect that what I am looking for is the 1.5->1.6 migration. It appears that the wallet isn't tied to a pool anymore. I'm looking over API minutia and some tests/samples, it looks like the wallet needing the pool name could be an artifact of history - I think it might suffice just to take its janitorial functions out into another entity. I'd been keeping them in the wallet because it needed pool spec on creation up to 1.5. A doc with the plan would have been a nice confirmation that I was on the right track, but if what I've written above is correct I can live without it.

sklump (Mon, 09 Jul 2018 12:40:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=FxMGMALL5s8iCzXat) @pimotte Thanks, but I suspect that what I am looking for is the 1.5->1.6 migration. It appears that the wallet isn't tied to a pool anymore. I'm looking over API minutia and some tests/samples, it looks like the wallet needing the pool name could be an artifact of history - I think it might suffice just to take its janitorial functions out into another entity. I'd been keeping them in the wallet because it needed pool spec on creation through indy-sdk 1.5 inclusive. A doc with the plan would have been a nice confirmation that I was on the right track, but if what I've written above is correct I can live without it.

gudkov (Mon, 09 Jul 2018 12:56:26 GMT):
In 1.6 we will remove wallet/pool association. Also libindy will stop to store wallets configuration on file system.

sklump (Mon, 09 Jul 2018 13:02:49 GMT):
Thanks @gudkov -- where will libindy store the wallet configuration?

sklump (Mon, 09 Jul 2018 13:03:19 GMT):
Or is that the wrong question?

LuigiRiva (Mon, 09 Jul 2018 13:18:12 GMT):
Hi I successfully managed to install the "getting started" (the jupyter notebook) but when I run the demo code i got this error: IndyError: ErrorCode.PoolLedgerConfigAlreadyExistsError

LuigiRiva (Mon, 09 Jul 2018 13:22:53 GMT):
if i restart the pool the first error is: === Getting Trust Anchor credentials for Faber, Acme, Thrift and Government == ------------------------------ "Sovrin Steward" -> Create wallet Function indy_create_wallet returned error 103 NameError: name 'IndyError' is not defined

LuigiRiva (Mon, 09 Jul 2018 13:23:11 GMT):
any help on how to run smoothly the demo?

tomislav (Mon, 09 Jul 2018 13:23:46 GMT):
Can you try cleaning your indy directory? `rm -fr ~/.indy_client`

tomislav (Mon, 09 Jul 2018 13:24:14 GMT):
The error suggests the demo is trying to create new config file, but one already exists

LuigiRiva (Mon, 09 Jul 2018 13:29:38 GMT):
hi @tomislav just tried.... started everything from scratch

LuigiRiva (Mon, 09 Jul 2018 13:29:53 GMT):
and now the error is:

LuigiRiva (Mon, 09 Jul 2018 13:29:53 GMT):
"Sovrin Steward" -> Create wallet Function indy_create_wallet returned error 103 NameError: name 'IndyError' is not defined

tomislav (Mon, 09 Jul 2018 13:34:47 GMT):
I can only point you to what the error means. 103 is invalid value as param 4, which for indy_create_wallet is the last callback param. I'm not sure what the wrapper you're using it passing, might be an outdated implementation

tomislav (Mon, 09 Jul 2018 13:35:04 GMT):
Error codes - https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/api/mod.rs

gudkov (Mon, 09 Jul 2018 13:38:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=TSQdni9WDTHoFkMbw) @sklump It will be responsibility of application.

LuigiRiva (Mon, 09 Jul 2018 13:52:19 GMT):
@tomislav thanks...could you point me out a proper way to check if my local indy pool of 4 nodes is working properly?

notOccupanther (Mon, 09 Jul 2018 15:43:28 GMT):
@LuigiRiva Can I ask you if your 4 nodes are standalone of running locally on a single machine?

notOccupanther (Mon, 09 Jul 2018 15:43:28 GMT):
@LuigiRiva Can I ask you if your 4 nodes are standalone or running locally on a single machine?

LuigiRiva (Mon, 09 Jul 2018 15:46:06 GMT):
@notOccupanther 4 pool running locally, as per the docker image provided here https://github.com/hyperledger/indy-sdk/tree/master/doc/getting-started

notOccupanther (Mon, 09 Jul 2018 15:58:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=q4Cvd8BHwaDTe4xdC) @LuigiRiva Thanks!

swcurran (Mon, 09 Jul 2018 16:48:51 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=xR8ecfbZAmS36Rj7M) @akuma921 Try looking at the indy-agent repo - https://github.com/hyperledger/indy-agent . It has a node-js implementation of a web-based agent.

pradeeppadmarajaiah (Mon, 09 Jul 2018 18:10:46 GMT):
I tried to run the node.js samples. It fails when creating the wallet. Same thing happened when running a java sample as well Error running node.js "Sovrin Steward" -> Create wallet Segmentation fault (core dumped) npm ERR! code ELIFECYCLE Complete error log for node.js 0 info it worked if it ends with ok 1 verbose cli [ '/home/pradeep/.nvm/versions/node/v8.9.4/bin/node', 1 verbose cli '/home/pradeep/.nvm/versions/node/v8.9.4/bin/npm', 1 verbose cli 'start' ] 2 info using npm@5.6.0 3 info using node@v8.9.4 4 verbose run-script [ 'prestart', 'start', 'poststart' ] 5 info lifecycle gettingstarted@1.0.0~prestart: gettingstarted@1.0.0 6 info lifecycle gettingstarted@1.0.0~start: gettingstarted@1.0.0 7 verbose lifecycle gettingstarted@1.0.0~start: unsafe-perm in lifecycle true 8 verbose lifecycle gettingstarted@1.0.0~start: PATH: /home/pradeep/.nvm/versions/node/v8.9.4/lib/node_modules/npm/node_modules/npm-lifecycle/node-gyp-bin:/home/pradeep/Downloads/indy-sdk-master/samples/n odejs/node_modules/.bin:/home/pradeep/fabric-samples/bin:/home/pradeep/.nvm/versions/node/v8.9.4/bin:/home/pradeep/bin:/home/pradeep/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin :/usr/games:/usr/local/games:/snap/bin:/usr/lib/jvm/java-8-oracle/bin:/usr/lib/jvm/java-8-oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin:/usr/local/go/bin:/home/pradeep/go/bin 9 verbose lifecycle gettingstarted@1.0.0~start: CWD: /home/pradeep/Downloads/indy-sdk-master/samples/nodejs 10 silly lifecycle gettingstarted@1.0.0~start: Args: [ '-c', 'node gettingStarted.js' ] 11 silly lifecycle gettingstarted@1.0.0~start: Returned: code: 139 signal: null 12 info lifecycle gettingstarted@1.0.0~start: Failed to exec start script 13 verbose stack Error: gettingstarted@1.0.0 start: `node gettingStarted.js` 13 verbose stack Exit status 139 13 verbose stack at EventEmitter. (/home/pradeep/.nvm/versions/node/v8.9.4/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:285:16) 13 verbose stack at emitTwo (events.js:126:13) 13 verbose stack at EventEmitter.emit (events.js:214:7) 13 verbose stack at ChildProcess. (/home/pradeep/.nvm/versions/node/v8.9.4/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14) 13 verbose stack at emitTwo (events.js:126:13) 13 verbose stack at ChildProcess.emit (events.js:214:7) 13 verbose stack at maybeClose (internal/child_process.js:925:16) 13 verbose stack at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5) 14 verbose pkgid gettingstarted@1.0.0 15 verbose cwd /home/pradeep/Downloads/indy-sdk-master/samples/nodejs 16 verbose Linux 4.15.0-24-generic 17 verbose argv "/home/pradeep/.nvm/versions/node/v8.9.4/bin/node" "/home/pradeep/.nvm/versions/node/v8.9.4/bin/npm" "start" 18 verbose node v8.9.4 19 verbose npm v5.6.0 20 error code ELIFECYCLE 21 error errno 139 22 error gettingstarted@1.0.0 start: `node gettingStarted.js` 22 error Exit status 139 23 error Failed at the gettingstarted@1.0.0 start script. 23 error This is probably not a problem with npm. There is likely additional logging output above. 24 verbose exit [ 139, true ] pradeep@pradeep-VirtualBox:~/Downloads/indy-sd

smithbk (Mon, 09 Jul 2018 20:28:22 GMT):
Can someone help with the following? I have dockerfiles which have stopped working in a last week. The error is as follows: ``` INFO:root:Create pool ledger config for {'genesis_txn': '/home/indy/sandbox/pool_transactions_genesis'} DEBUG:indy.pool:create_pool_ledger_config: >>> config_name: 'agents_pool', config: '{"genesis_txn": "/home/indy/sandbox/pool_transactions_genesis"}' DEBUG:indy.pool:create_pool_ledger_config: Creating callback DEBUG:indy.libindy:create_cb: >>> cb_type: .CFunctionType'> DEBUG:indy.libindy:create_cb: <<< res: DEBUG:indy.libindy:do_call: >>> name: indy_create_pool_ledger_config, args: (c_char_p(140410026942336), c_char_p(140410023897328), ) DEBUG:indy.libindy:_load_cdll: >>> DEBUG:indy.libindy:_load_cdll: Detected OS name: linux DEBUG:indy.libindy:_load_cdll: Resolved libindy name is: libindy.so DEBUG:indy.libindy:_load_cdll: <<< res: INFO|indy::commands | src/commands/mod.rs:108 | PoolCommand command received TRACE|indy::services::pool | src/services/pool/mod.rs:575 | PoolService::create agents_pool with config Some("{\"genesis_txn\": \"/home/indy/sandbox/pool_transactions_genesis\"}") DEBUG:indy.libindy:_indy_callback: >>> command_handle: 0, err 0, args: () DEBUG:indy.libindy:_indy_callback: <<< DEBUG:indy.libindy:do_call: Function indy_create_pool_ledger_config returned err: 0 DEBUG:indy.libindy:do_call: <<< DEBUG:indy.libindy:_indy_loop_callback: >>> command_handle: 0, err 0, args: () DEBUG:indy.libindy:_indy_loop_callback: Function returned None DEBUG:indy.libindy:_indy_loop_callback <<< DEBUG:indy.pool:create_pool_ledger_config: <<< res: None DEBUG:indy.pool:open_pool_ledger: >>> config_name: 'agents_pool', config: '{"genesis_txn": "/home/indy/sandbox/pool_transactions_genesis"}' DEBUG:indy.pool:open_pool_ledger: Creating callback DEBUG:indy.libindy:create_cb: >>> cb_type: .CFunctionType'> DEBUG:indy.libindy:create_cb: <<< res: DEBUG:indy.libindy:do_call: >>> name: indy_open_pool_ledger, args: (c_char_p(140410026942288), c_char_p(140410023897328), ) INFO|indy::commands | src/commands/mod.rs:108 | PoolCommand command received DEBUG:indy.libindy:do_call: Function indy_open_pool_ledger returned err: 0 DEBUG:indy.libindy:do_call: <<< INFO|indy::commands | src/commands/mod.rs:108 | PoolCommand command received INFO|indy::commands::pool | src/commands/pool.rs:67 | OpenAck handle 1, pool_id 2, result Err(CommonError(InvalidState("MerkleTree contains invalid data Syntax(\"missing field `data`\")"))) ERROR|indy::errors::indy | src/errors/indy.rs:68 | Casting error to ErrorCode: Invalid library state: MerkleTree contains invalid data Syntax("missing field `data`") DEBUG:indy.libindy:_indy_callback: >>> command_handle: 1, err 112, args: (0,) DEBUG:indy.libindy:_indy_callback: <<< DEBUG:indy.libindy:_indy_loop_callback: >>> command_handle: 1, err 112, args: (0,) WARNING:indy.libindy:_indy_loop_callback: Function returned error 112 DEBUG:indy.libindy:_indy_loop_callback <<< ERROR|indy::services::pool | src/services/pool/mod.rs:428 | Pool worker thread finished with error CommonError(InvalidState("MerkleTree contains invalid data Syntax(\"missing field `data`\")"))```

smithbk (Tue, 10 Jul 2018 04:05:08 GMT):
For the above problem, please see https://jira.hyperledger.org/browse/IS-809 which includes instructions on how to reproduce. Thanks for the help.

akuma921 (Tue, 10 Jul 2018 04:43:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=CGSyFAGpbgZhdvSfA) @swcurran Thanks, I will surely look into it

akuma921 (Tue, 10 Jul 2018 04:53:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mHtrnXfkXBzfjLhKQ) Facing this error: npm start > indy-agent@0.0.0 start /Users/akuma921/work/hyperledger-indy/indy-agent/indy-agent/nodejs > node ./bin/www { IndyError: CommonInvalidState at Object.callback (/Users/akuma921/work/hyperledger-indy/indy-agent/indy-agent/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10) name: 'IndyError', message: 'CommonInvalidState', indyCode: 112, indyName: 'CommonInvalidState' }

srinivasanraghavan (Tue, 10 Jul 2018 10:56:04 GMT):
Hi all I am looking at Indy Sdk code base for sometime now .I work for a company Equinix, we have built SGX based cloud hsm. We want to integrate with a pkcs 11 layer for crypto which would call the call the cloud HSM for crypto ops .. Is adding a common pkcs11 layer was discussed before . I want to design a system where secret key does not comes out of HSM. Would just adding a crypto type would work or would require deeper changes as I see some places the secret key is in the memory.

sklump (Tue, 10 Jul 2018 13:00:24 GMT):
Hello - what is the best channel for evernym vcx discussion?

BreizhIndy (Tue, 10 Jul 2018 13:28:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ncztJYsuHPNJDfRsz) @sklump the closest one is the indy-agent I guess

BreizhIndy (Tue, 10 Jul 2018 13:31:42 GMT):
I have a little problem, I took the nodejs script from sample and wanted to add the creation of pairwise in the onboarding function. However, I get a WalletNotFoundError

BreizhIndy (Tue, 10 Jul 2018 13:31:58 GMT):
I have a little problem, I took the nodejs script from sample and wanted to add the creation of pairwise in the onboarding function. However, I get a WalletNotFoundError

BreizhIndy (Tue, 10 Jul 2018 13:33:32 GMT):
I have a little problem, I took the nodejs script from sample and wanted to add the creation of pairwise in the onboarding function. let [fromToDid, fromToKey] = await indy.createAndStoreMyDid(fromWallet, {}); //add pairwise await indy.createPairwise(fromWallet, fromDid, fromToDid, "meta"); However, while for createAndStoreMyDid the wallet is found and the function is working I get a WalletNotFoundError for the createPairwise function

tomislav (Tue, 10 Jul 2018 13:45:19 GMT):
It might be incorrect error reported, but "meta" isn't a valid metadata info. Try passing null or just {} to it.

BreizhIndy (Tue, 10 Jul 2018 13:52:41 GMT):
with null I get the same error, with {} I get Expected String or null for metadata. I don't know why this wallet is disappearing suddenly

BreizhIndy (Tue, 10 Jul 2018 15:20:14 GMT):
with trace : Casting error to ErrorCode: Wallet not found: Wallet record is not found: query returned no rows. What is the query that is sent ? because my wallet isn't empty

tomislav (Tue, 10 Jul 2018 18:43:50 GMT):
@BreizhIndy before storing a pairwise, you need to call did.store_their_did first.

tomislav (Tue, 10 Jul 2018 18:44:10 GMT):
Both keys must be present in the wallet

akuma921 (Wed, 11 Jul 2018 03:16:32 GMT):
facing this error while running indy-agent nodejs `*{ IndyError: CommonInvalidState at Object.callback (/Users/akuma921/work/hyperledger-indy/indy-agent/indy-agent/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10) name: 'IndyError', message: 'CommonInvalidState', indyCode: 112,*` indyName: 'CommonInvalidState' }

srinivasanraghavan (Wed, 11 Jul 2018 05:34:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=iHWSpnCEcxLXMX8GX) HI all any help for me ...

Abhishek_Tyagi (Wed, 11 Jul 2018 06:32:21 GMT):
Has joined the channel.

n3m4nja (Wed, 11 Jul 2018 06:55:04 GMT):
Has joined the channel.

n3m4nja (Wed, 11 Jul 2018 06:58:51 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=naBgx8qfa9weW44c4) @akuma921 I believe this is because there were changes in the indy-sdk API that were not applied to the NodeJS Agent codebase -- mostly concerning interaction with the wallet. You could reach out in the #indy-agent channel and ask for more details.

Abhishek_Tyagi (Wed, 11 Jul 2018 07:02:15 GMT):
I have completed network set-up using "Vagrant up". I have tried to understand how Indy works using CLI01, Validator01/02/03/04 and Agent01/02/03 (https://github.com/hyperledger/indy-node/blob/stable/getting-started.md) . Now I want to prepare a GUI to connect with the indy network to do transactions among clients and agents. Could anyone please guide me how to start with NODE JS and INDY connection (Windows 10)? Thanks, Abhishek Tyagi

Abhishek_Tyagi (Wed, 11 Jul 2018 07:02:15 GMT):
Hello, I have completed network set-up using "Vagrant up". I have tried to understand how Indy works using CLI01, Validator01/02/03/04 and Agent01/02/03 (https://github.com/hyperledger/indy-node/blob/stable/getting-started.md) . Now I want to prepare a GUI to connect with the indy network to do transactions among clients and agents. Could anyone please guide me how to start with NODE JS and INDY connection (Windows 10)? Thanks, Abhishek Tyagi

danielhardman (Wed, 11 Jul 2018 07:29:12 GMT):
I raised a HIPE about the design of wallets. There is nothing new in it; it's just a write-up of the presentation that was previously given. https://github.com/hyperledger/indy-hipe/pull/20

n3m (Wed, 11 Jul 2018 07:32:20 GMT):
Has joined the channel.

akuma921 (Wed, 11 Jul 2018 07:32:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6unxXFFjXD5ZubXqe) @n3m4nja Thanks @n3m4nja

sergey.minaev (Wed, 11 Jul 2018 07:43:07 GMT):
@Abhishek_Tyagi indy-node GSG is deprecated. Please take a look at https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md . At the end of this document you can find a link how to run new GSG scenario by single command (https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/run-getting-started.md) SDK readme has section about running developer pool https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker

janl (Wed, 11 Jul 2018 07:58:09 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=HLs5urFNpGvtrff6F) To confirm can run-getting-started.md "docker-compose up" be run independent of how-to-start-local-nodes-pool-with-docker? I am getting error 307, poolledgertimeout, which means ledger is not being found and I am not clear how to fix the problem.

BreizhIndy (Wed, 11 Jul 2018 08:22:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=PnmBTuWqmFZQuiXGR) @tomislav Thanks, working now !

sergey.minaev (Wed, 11 Jul 2018 08:56:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=2paoZKENjkeRknCdc) @JanL 5 yes, compose for GSG automatically starts pool in docker almost same as described in section of readme (opt2)

janl (Wed, 11 Jul 2018 09:04:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=MpXRq7RsQQNijmfgk) @sergey.minaev Thanks for confirming that GSG takes care of it (I assumed GSG is the getting-started.md). Would there be a reason that ledger could not be found? I checked getting-started_pool_network (docker network inspect) there are 2 containers, one with IP address 10.0.0.2 (indy_pool) and 10.0.0.3 (getting_started). Could there be an issue with compiled libindy that is running in indy_pool? I have not been able to docker attach indy_pool to the container to look more closely. Suggestions?

sergey.minaev (Wed, 11 Jul 2018 09:08:12 GMT):
@JanL 5 Do you use master or RC branch?

janl (Wed, 11 Jul 2018 09:11:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ZngwPTvsfuf2r9d9B) I believe I used the stable version.

sergey.minaev (Wed, 11 Jul 2018 09:15:21 GMT):
Could you please double-check versions: `docker exec -it getting_started apt list libindy` and `docker exec -it indy_pool apt list indy-node`

gudkov (Wed, 11 Jul 2018 09:16:58 GMT):
@sergey.minaev We have a problem that getting_started container use the same image name as pool container and it can cause potential versioning issues

gudkov (Wed, 11 Jul 2018 09:16:58 GMT):
@sergey.minaev We have a problem that getting started container use the same image name as pool container and it can cause potential versioning issues

janl (Wed, 11 Jul 2018 09:17:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=zaZTvFzsX2ppdcmwz) libindy/xenial,now 1.5.0~613 amd64 [installed] indy-node/xenial 1.4.480 amd64 [upgradable from: 1.4.463]

janl (Wed, 11 Jul 2018 09:17:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=zaZTvFzsX2ppdcmwz) libindy/xenial,now 1.5.0~613 amd64 [installed]

sergey.minaev (Wed, 11 Jul 2018 09:21:40 GMT):
> indy-node/xenial 1.4.480 amd64 [upgradable from: 1.4.463] seems strange. Please update your images (`docker-compose build`)

sergey.minaev (Wed, 11 Jul 2018 09:21:40 GMT):
> indy-node/xenial 1.4.480 amd64 [upgradable from: 1.4.463] seems strange. Please update your images ( `docker-compose build` )

janl (Wed, 11 Jul 2018 09:29:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=A3utW8MRnAwea8bxE) I ran docker-compose build and then started up again and same error 307. When I checked the version for xenial it is the same as previous one. What was strange?

sergey.minaev (Wed, 11 Jul 2018 09:43:56 GMT):
> indy-node/xenial 1.4.480 amd64 [upgradable from: 1.4.463] means that you have old 1.4.463 version installed but 1.4.480 available

sergey.minaev (Wed, 11 Jul 2018 09:44:38 GMT):
should be `indy-node/xenial,now 1.4.480 amd64 [installed]`

sergey.minaev (Wed, 11 Jul 2018 10:07:53 GMT):
@JanL 5 btw, there is also potential issue with libindy version please update last 2 commands in `doc/getting-started/getting-started.dockerfile` to (if you would like to use latest stable SDK): ``` RUN pip3 install -U \ pip \ setuptools \ jupyter \ python3-indy==1.5.0 RUN apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 68DB5E88 \ && add-apt-repository "deb https://repo.sovrin.org/sdk/deb xenial stable" \ && apt-get update \ && apt-get install -y \ libindy=1.5.0 ```

pradeeppadmarajaiah (Wed, 11 Jul 2018 10:33:35 GMT):
Able to run Java sample. Trying How to....But there is an error in this lines import static org.hyperledger.indy.sdk.anoncreds.Anoncreds.issuerCreateAndStoreClaimDef; String credDef = issuerCreateAndStoreClaimDef(walletHandle, trustAnchorDID, credDefJSON, "CL", false).get(); Currently using this version 1.4.0-dev-586 Which version supports this api

pradeeppadmarajaiah (Wed, 11 Jul 2018 10:33:36 GMT):
\??

janl (Wed, 11 Jul 2018 10:42:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=L52X47J5HuTrzHhyB) @sergey.minaev I changed to 1.5.0 and ran docker-compose build. I can see that 1.5.0 is being fetched in the log but when I startup again and check version it is still the old version 1.4.463.

sklump (Wed, 11 Jul 2018 10:57:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=TzyQaTwsZA3GSSiJg) @danielhardman Is the presentation available on-line? I am quite curious to see context for a pic of some kind of ebola station!

vtech (Wed, 11 Jul 2018 11:08:40 GMT):
Has joined the channel.

BreizhIndy (Wed, 11 Jul 2018 13:57:58 GMT):
in a relationship, both parties have the same verkeys ?

danielhardman (Wed, 11 Jul 2018 17:20:27 GMT):
@swcurran et al.: I promised by Wed that I'd report back on an action item from our call last friday on agents. The action item was to explore whether it is possible to kludge together a way to do support for multiple keys for a single DID in indy-sdk. I've now done some fact-finding. The short answer is: can be done today with a heavy reliance on convention. Probably could be polished significantly in short order. I can't commit @gudkov and his team to do that work in time for libindy 1.6, since @esplinr is still on vacation and is the arbiter of their time and commitments. However, I *can* commit @kdenhartog's time, and he believes it can be done by him in time for the 1.6 release--so probably we will use Kyle, or maybe we'll use Slava's team--but either way, we'll work on it quickly. The thinking for the approach is captured in this jira ticket: https://jira.hyperledger.org/browse/IS-810

Dominic (Wed, 11 Jul 2018 19:46:55 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4FM869HJdnJ3op8sk) @pradeeppadmarajaiah I've noticed that all the how-tos are outdated as well

Dominic (Wed, 11 Jul 2018 19:48:54 GMT):
Personally, my solution was to look at the demo test files ([python example](https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/tests/demo/test_anoncreds.py))

Dominic (Wed, 11 Jul 2018 21:34:39 GMT):
I'm looking at anoncreds in the indy-sdk, and I'm trying to understand how it works. I have a few questions. + What is a credential def, and how does it differ from a schema? Is it public or kept private? When I output a credential def to the terminal, I get a lot of seemingly random strings in a JSON format.

Dominic (Wed, 11 Jul 2018 21:34:39 GMT):
I'm looking at anoncreds in the indy-sdk, and I'm trying to understand how it works. I have a few questions. What is a credential def, and how does it differ from a schema? Is it public or kept private? When I output a credential def to the terminal, I get a lot of seemingly random strings in a JSON format.

tomislav (Wed, 11 Jul 2018 22:15:53 GMT):
I'm having a weird issue with libindy 1.4 under iOS when trying to create credential request. I've enabled trace, here's the full output. https://pastebin.com/kfJhygMx It returns `deserialize CredentialOffer: InvalidStructure("invalid type: sequence, expected a map at line 1 column 936") Error Domain=IndyErrorDomain Code=113 "(null)"`, but I have no idea why. The offerJson supplied is exactly the one that I got from issuer_create_offer, and I don't do any processing or parsing to the string. Anyone has an idea what's wrong with the structure/call?

tomislav (Wed, 11 Jul 2018 22:23:52 GMT):
Seems to be that `"xr_cap":[["` is confusing it. Char at 936 is `:`

animeshdas (Wed, 11 Jul 2018 23:28:18 GMT):
Has joined the channel.

animeshdas (Wed, 11 Jul 2018 23:28:27 GMT):
Hello, new joinee here

animeshdas (Wed, 11 Jul 2018 23:28:51 GMT):
I am trying to get started with indy for iOS

animeshdas (Wed, 11 Jul 2018 23:28:56 GMT):
and I am following https://github.com/hyperledger/indy-sdk/tree/master/wrappers/ios

animeshdas (Wed, 11 Jul 2018 23:29:50 GMT):
Step 6 needs EVERNYM_REPO_KEY

animeshdas (Wed, 11 Jul 2018 23:30:03 GMT):
I am not sure what should be specified in EVERNYM_REPO_KEY

animeshdas (Wed, 11 Jul 2018 23:30:12 GMT):
Any help would be much appreciated

animeshdas (Wed, 11 Jul 2018 23:30:37 GMT):
P.S I have googled EVERNYM_REPO_KEY and also searched it in this channel messages

animeshdas (Thu, 12 Jul 2018 04:42:54 GMT):
I have a few questions

animeshdas (Thu, 12 Jul 2018 04:43:47 GMT):
Question 1) "Step 8" says "Go to Podspec dir". What is the "podspec" dir?

animeshdas (Thu, 12 Jul 2018 04:44:53 GMT):
Question 2) Step 12 and 13 say => Add new directory and file inside to git repository. Commit to master branch.

animeshdas (Thu, 12 Jul 2018 04:45:12 GMT):
Which git repo? Hyperledger indy?

animeshdas (Thu, 12 Jul 2018 04:45:45 GMT):
Any help would be highly appreciated. Thank you.

animeshdas (Thu, 12 Jul 2018 05:28:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RWkNTKELp8CKCYxLR) @stanleyc-trustscience hi @stanleyc-trustscience I am wondering if you were able to fix the issue. I am facing exact same error.

Abhishek_Tyagi (Thu, 12 Jul 2018 05:30:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=HLs5urFNpGvtrff6F) @sergey.minaev Hello, As suggested, I am done with the network setup with command "docker build -f ci/indy-pool.dockerfile -t indy_pool" as mentioned on this page : https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker . This page does not give any clue further. How to do transactions between Alice and other parties? How to tweak the network? How to connect indy-cli with the pool? How to use node.js sdk to connect with this network? I tried to search about these issues but did not get any clear end-to-end process. Could you please guide me

nikhil.kumar (Thu, 12 Jul 2018 05:37:21 GMT):
Has joined the channel.

stanleyc-trustscience (Thu, 12 Jul 2018 07:01:28 GMT):
@animeshdas Use xcode 9.2

stanleyc-trustscience (Thu, 12 Jul 2018 07:01:28 GMT):
@animeshdas Use xcode 9.2. 9.4.1 and above seem to have problem copying swift core libraries. Even happens in xcode 10 betas

stanleyc-trustscience (Thu, 12 Jul 2018 07:02:28 GMT):
Hello, I am wondering how to use indy-sdk to connect to indy network that is not hosted locally. What config do I do?

pradeeppadmarajaiah (Thu, 12 Jul 2018 07:37:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qxyJWKM3LdHqkGkqh) @Dominic Any updated doc on Java. Please share it

Abhishek_Tyagi (Thu, 12 Jul 2018 08:08:07 GMT):
Hello,

Abhishek_Tyagi (Thu, 12 Jul 2018 08:09:45 GMT):
Hello, While doing "docker-composer up", there is a piece of code "RUN pip3 install -U \ pip \ setuptools \ jupyter \ python3-indy==1.4.0-dev-586", in file getting-started.dockerfile, which is giving following error: " Could not find a version that satisfies the requirement bleach (from nbconvert->jupyter) (from versions: ) No matching distribution found for bleach (from nbconvert->jupyter) You are using pip version 8.1.1, however version 10.0.1 is available. You should consider upgrading via the 'pip install --upgrade pip' command. ERROR: Service 'jupyter' failed to build: The command '/bin/sh -c pip3 install -U pip setuptools jupyter python3-indy==1.4.0-dev-586' returned a non-zero code: 1"

mohitgajera (Thu, 12 Jul 2018 08:40:12 GMT):
Has joined the channel.

mohitgajera (Thu, 12 Jul 2018 08:40:24 GMT):
Hello,

mohitgajera (Thu, 12 Jul 2018 08:41:21 GMT):
Hello, i am looking for Indy-SDK api documentation.

Abhishek_Tyagi (Thu, 12 Jul 2018 09:15:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=KvtyoGciBw7Mi4vhx) Well, adding "RUN pip3 install pipenv" before the aforementioned command solved my problem. The new problem I am facing is "W: Failed to fetch https://repo.sovrin.org/sdk/deb/dists/xenial/master/binary-amd64/Packages GnuTLS recv error (-9): A TLS packet with unexpected length was received." and "E: Unable to locate package libindy".

Abhishek_Tyagi (Thu, 12 Jul 2018 09:16:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=josoSqAccDHN6YvNe) @mohitgajera You can find some information here: https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker

danielhardman (Thu, 12 Jul 2018 09:39:07 GMT):
Indy HIPE Status Notes 1. The HIPE on credential revocation has finished its Final Comment Period and been accepted unanimously by Indy maintainers. It was merged and is now known as Indy HIPE 0011. You can view it at https://github.com/hyperledger/indy-hipe/tree/master/text/0011-cred-revocation. 2. Per a decision of Indy maintainers on Monday, July 9, the HIPE on concurrency improvements in Indy is now entering its Final Comment Period. We believe it is ready to be accepted. You can view the PR for this HIPE at https://github.com/hyperledger/indy-hipe/pull/16. The HIPE will be accepted and merged on Monday, July 23 unless there is significant latebreaking dissonance from community members.

sergey.minaev (Thu, 12 Jul 2018 09:56:11 GMT):
@Abhishek_Tyagi hello, please find some answers inline. But in general please read getting-started guide (GSG) more careful include python code, even if you don't plan to use python wrapper in the future. It contains almost all answers for your questions. btw I try to add some concrete link for your questions: > How to do transactions between Alice and other parties? SDK provide calls to communicate with ledger. But transport level for communication between (directly) agents (Alice, Faber, etc) is out of scope IndySDK. SDK provide crypto-functions and encrypted messages can be transferred via insecure network. > How to tweak the network? https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker describes how to build docker image and run container with developer network instance. > How to connect indy-cli with the pool? same as described in GSG: 1) create configuration to connect, 2) connect to pool Here is a linke to CLI readme section: https://github.com/hyperledger/indy-sdk/blob/master/cli/README.md#getting-help you have to use genesis transactions to create network configuration. You can find a sample `cli/docker_pool_transactions_genesis` - it can be used to connect to pool deployed as described above. It contains 10.0.0.2 IP for 2nd option from `how-to-start-local-nodes-pool-with-docker`. If you setup pool as described at 1st option in `how-to-start-local-nodes-pool-with-docker` please replace all 10.0.0.2 to 127.0.0.1 in this file > How to use node.js sdk to connect with this network? In general (for libindy itself, any wrapper or CLI) you should firstly create a pool configuration based on some genesis transactions. And use this configuration to connect. Here is a link to NodeJS readme section https://github.com/hyperledger/indy-sdk/tree/master/wrappers/nodejs#pool

sergey.minaev (Thu, 12 Jul 2018 09:56:11 GMT):
@Abhishek_Tyagi hello, please find some answers inline. But in general please read getting-started guide (GSG) more careful include python code, even if you don't plan to use python wrapper in the future. It contains almost all answers for your questions. btw I try to add some concrete link for your questions: > How to do transactions between Alice and other parties? SDK provide calls to communicate with ledger. But transport level for communication between (directly) agents (Alice, Faber, etc) is out of scope IndySDK. SDK provide crypto-functions and encrypted messages can be transferred via insecure network. > How to tweak the network? https://github.com/hyperledger/indy-sdk/blob/master/README.md#how-to-start-local-nodes-pool-with-docker describes how to build docker image and run container with developer network instance. > How to connect indy-cli with the pool? same as described in GSG: 1) create configuration to connect, 2) connect to pool Here is a linke to CLI readme section: https://github.com/hyperledger/indy-sdk/blob/master/cli/README.md#getting-help you have to use genesis transactions to create network configuration. You can find a sample `cli/docker_pool_transactions_genesis` - it can be used to connect to pool deployed as described above. It contains 10.0.0.2 IP for 2nd option from `how-to-start-local-nodes-pool-with-docker`. If you setup pool as described at 1st option in `how-to-start-local-nodes-pool-with-docker` please replace all 10.0.0.2 to 127.0.0.1 in this file > How to use node.js sdk to connect with this network? In general (for libindy itself, any wrapper or CLI) you should firstly create a pool configuration based on some genesis transactions. And use this configuration to connect. Here is a link to NodeJS readme section https://github.com/hyperledger/indy-sdk/blob/master/wrappers/nodejs/README.md#pool

sergey.minaev (Thu, 12 Jul 2018 09:56:11 GMT):
@Abhishek_Tyagi hello, please find some answers inline. But in general please read getting-started guide (GSG) more careful include python code, even if you don't plan to use python wrapper in the future. It contains almost all answers for your questions. btw I try to add some concrete link for your questions: > How to do transactions between Alice and other parties? SDK provide calls to communicate with ledger. But transport level for communication between (directly) agents (Alice, Faber, etc) is out of scope IndySDK. SDK provide crypto-functions and encrypted messages can be transferred via insecure network. > How to tweak the network? https://github.com/hyperledger/indy-sdk/blob/master/README.md#how-to-start-local-nodes-pool-with-docker describes how to build docker image and run container with developer network instance. > How to connect indy-cli with the pool? same as described in GSG: 1) create configuration to connect, 2) connect to pool Here is a link to CLI readme section: https://github.com/hyperledger/indy-sdk/blob/master/cli/README.md#getting-help you have to use genesis transactions to create network configuration. You can find a sample `cli/docker_pool_transactions_genesis` - it can be used to connect to pool deployed as described above. It contains 10.0.0.2 IP for 2nd option from `how-to-start-local-nodes-pool-with-docker`. If you setup pool as described at 1st option in `how-to-start-local-nodes-pool-with-docker` please replace all 10.0.0.2 to 127.0.0.1 in this file > How to use node.js sdk to connect with this network? In general (for libindy itself, any wrapper or CLI) you should firstly create a pool configuration based on some genesis transactions. And use this configuration to connect. Here is a link to NodeJS readme section https://github.com/hyperledger/indy-sdk/blob/master/wrappers/nodejs/README.md#pool

RuWander (Thu, 12 Jul 2018 13:13:22 GMT):
Has joined the channel.

Dominic (Thu, 12 Jul 2018 14:08:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=josoSqAccDHN6YvNe) @mohitgajera The Node.js wrapper has decent documentation: https://github.com/hyperledger/indy-sdk/blob/master/wrappers/nodejs/README.md That's what I've been using to understand how to use each function even if I'm writing in Python at the moment.

Dominic (Thu, 12 Jul 2018 14:25:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=te8iznrjBGDoKvGug) @pradeeppadmarajaiah Unfortunately, no. I haven't looked at the Java wrapper.

Dominic (Thu, 12 Jul 2018 14:30:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=bEaCWptzvoRyz8w32) Bump. I'm still looking for answers :sweat:

sklump (Thu, 12 Jul 2018 14:52:59 GMT):
A credential definition uses a schema. Any number of issuers can release credential definitions off a schema. For example, multiple schools could issue transcripts off a government-originated schema. The JSON content provides cryptographic proof of origin for the credential definition. Credential definitions are public, written to the ledger. The issuer also has corresponding private key info particular to the credential definition written to its wallet.

tomislav (Thu, 12 Jul 2018 14:54:52 GMT):
Running `cargo build --release` on Mac to build libindy produces error ``` error: non-reference pattern used to match a reference (see issue #42640) --> src/commands/did.rs:555:24 | 555 | if let Some(data) = &res.data { | ^^^^^^^^^^ help: consider using a reference: `&Some(data)` ``` Compiler version `rustc 1.24.1 (d3ae9a9e0 2018-02-27)`

tomislav (Thu, 12 Jul 2018 14:55:26 GMT):
Trying with the `rc` branch

n3m (Thu, 12 Jul 2018 14:56:09 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WL2FRrLtzj9Ak4MdH) @tomislav try updating the rust compiler. I believe this is related to the version being used

tomislav (Thu, 12 Jul 2018 14:56:30 GMT):
I did, this is the latest from stable. Should I try nightly?

Dominic (Thu, 12 Jul 2018 14:57:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=QGo38reaFD6Hu3y8M) @sklump Thank you

n3m (Thu, 12 Jul 2018 14:57:07 GMT):
This is what I am using `rustc --version rustc 1.26.1 (827013a31 2018-05-25) `

n3m (Thu, 12 Jul 2018 14:57:07 GMT):
This is what I am using ``` rustc 1.26.1 (827013a31 2018-05-25) ```

n3m (Thu, 12 Jul 2018 14:57:07 GMT):
This is what I am using (I believe it is a stable releise) ``` rustc 1.26.1 (827013a31 2018-05-25) ```

n3m (Thu, 12 Jul 2018 14:57:07 GMT):
This is what I am using (I believe it is a stable) ``` rustc 1.26.1 (827013a31 2018-05-25) ```

n3m (Thu, 12 Jul 2018 14:57:07 GMT):
This is what I am using (I believe it is stable) ``` rustc 1.26.1 (827013a31 2018-05-25) ```

tomislav (Thu, 12 Jul 2018 14:57:23 GMT):
I'll switch to nightly, thank you

gudkov (Thu, 12 Jul 2018 15:05:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qzG7pmLJ4Fh3YeihM) @tomislav It works on stable >= 1.26. Latest stable is 1.27

tomislav (Thu, 12 Jul 2018 15:07:06 GMT):
The install script on rust website installs version 1.24 for some reason. Running `rustup update` now, reports it's installing 1.27. Weird

tomislav (Thu, 12 Jul 2018 15:16:29 GMT):
Worked! Thank you

tomislav (Thu, 12 Jul 2018 15:29:38 GMT):
In order to use the docker pool supplied with libindy 1.5 under "ci", do I need to set protocol version?

sergey.minaev (Thu, 12 Jul 2018 15:44:03 GMT):
if we are talking about libindy - yes, it should be `2` for latest node version (e.g. from docker at 1.5.0/ci). CLI by default setup protocol version 2

sergey.minaev (Thu, 12 Jul 2018 15:44:03 GMT):
if we are talking about libindy and wrappers - yes, it should be `2` for latest node version (e.g. from docker at 1.5.0/ci). CLI by default setup protocol version 2

tomislav (Thu, 12 Jul 2018 16:29:59 GMT):
All set. I updated the dotnet samples and wrapper to match the changes, runs fine with 1.5. Will send a PR soon

hendry19901990 (Thu, 12 Jul 2018 16:48:33 GMT):
Help me please

hendry19901990 (Thu, 12 Jul 2018 16:48:46 GMT):
I have got an error

hendry19901990 (Thu, 12 Jul 2018 16:48:48 GMT):
node_modules/indy-sdk/build/Release/indynodejs.node: undefined symbol: indy_list_wallets

RuWander (Thu, 12 Jul 2018 18:14:24 GMT):
Hello,

RuWander (Thu, 12 Jul 2018 18:16:00 GMT):
Hello,

RuWander (Thu, 12 Jul 2018 18:24:36 GMT):
Hello, I am trying to build Indy SDK from source for Ubuntu 16.04, all seems fine up and till the `cargo build` command. It compiles up and to `Compiling rust-base58 v0.0.4` where it either hangs or it exits with an error: `error: Could not compile `indy`. Caused by: process didn't exit successfully:`

RuWander (Thu, 12 Jul 2018 18:24:36 GMT):
Hello, I am trying to build Indy SDK from source for Ubuntu 16.04, all seems fine up and till the `cargo build` command. It compiles up and to `Compiling rust-base58 v0.0.4` where it either hangs or it exits with an error: `error: Could not compile indy. Caused by: process didn't exit successfully:` Have anyone else experienced this? Does anyone know of a solution I could try to fix the error?

RuWander (Thu, 12 Jul 2018 18:24:36 GMT):
Hello, I am trying to build Indy SDK from source for Ubuntu 16.04, all seems fine up and till the `cargo build` command. It compiles up and to `Compiling rust-base58 v0.0.4` where it either hangs or it exits with an error: ``` error: Could not compile indy. Caused by: process didn't exit successfully: ``` Have anyone else experienced this? Does anyone know of a solution I could try to fix the error?

smithbk (Thu, 12 Jul 2018 19:11:34 GMT):
I'm getting a ErrorCode.DidAlreadyExistsError error from `did.create_and_store_my_did` with a steward seed. How can I compute the did and verkey from a seed without trying to add to wallet again? Thanks

n3m (Thu, 12 Jul 2018 19:21:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=CSthCgM2j5KTeAFTh) @tomislav Awesome!

tomislav (Thu, 12 Jul 2018 19:43:52 GMT):
@smithbk You can't compute it using the API. What you can do is use `indy_list_my_dids_with_meta` to list your wallet did's and then use `indy_key_for_local_did` to get the verykey

animeshdas (Thu, 12 Jul 2018 19:52:26 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=cjCcWo5xGkF8hWKY4) @stanleyc-trustscience Hi @stanleyc-trustscience That didn't work :( @tomislav gave me a sample xcode project integrated with indy sdk, that compiles and runs fine. I am using that to debug whats wrong with my project. I will share the findings.

n3m (Thu, 12 Jul 2018 20:19:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Mf3PfmgzdF6aGjxFR) @RuWander A shot in the dark but how much RAM does your machine have, maybe you are hitting a limit related to that and OOM killer shuts you down.

RuWander (Thu, 12 Jul 2018 20:40:38 GMT):
@n3m I'm working on a Digitalocean droplet with 1GB memory, I think you are right it probably is an out-of-memory issue. I, however, did get past that point earlier today but it gave similar issue to: ``` error: non-reference pattern used to match a reference ``` so I started from scratch and that is when I got this new error. Probably a stupid question but do you think there is any workaround? Is a local VM maybe a better solution?

n3m (Thu, 12 Jul 2018 20:48:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=yStgM69nY9CAFeh8G) @RuWander As far as I know there is no workaround, some libraries just demand too much RAM. Local VM is an OK solution if you have enough resources to spin up one

RuWander (Thu, 12 Jul 2018 20:55:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=LJKN3pYYAzgmbwjYr) @n3m Thank you very much for the help I'm going to try a VM.

MohsenZ (Thu, 12 Jul 2018 21:35:26 GMT):
Has joined the channel.

n3m (Thu, 12 Jul 2018 21:35:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=7qoFutkQurgWuiDuC) @hendry19901990 When is this happening? Is there a chance you are using old nodejs module and new `libindy`?

MohsenZ (Thu, 12 Jul 2018 21:40:48 GMT):
Does anyone know how to set the protocol version and how we know what to set it to? I'm using the.Net sample, I have pool running, and I'm getting the 308 error (PoolIncompatibleProtocolVersion )

MohsenZ (Thu, 12 Jul 2018 21:41:24 GMT):
Getting the same issue @MyMate had above.

kevin.chan (Thu, 12 Jul 2018 22:04:01 GMT):
@AxelNennker and @stanleyc-trustscience I see you guys have made some posts with regard to compiling libindy for Android. Using the build scripts here: https://github.com/hyperledger/indy-sdk/tree/master/libindy/build_scripts/android I was able to compile successfully for arm. But when trying to run it for arm64 and x86 I do get an error. Any help would be appreciated. Here's the error

kevin.chan (Thu, 12 Jul 2018 22:05:50 GMT):

arm64_error.txt

kevin.chan (Thu, 12 Jul 2018 22:07:11 GMT):
``` error: linking with `/home/indy_user/arm64/bin/aarch64-linux-android-clang` failed: exit code: 1 = note: /tmp/rustc.nlSCwCXpqlXt/libopenssl_sys-ac0ef2d41fa8ff99.rlib(bio_ssl.o): error adding symbols: File in wrong format clang50: error: linker command failed with exit code 1 (use -v to see invocation) error: aborting due to previous error error: Could not compile `indy-crypto`. To learn more, run the command again with --verbose. Android clang version 5.0.300080 (based on LLVM 5.0.300080) Target: aarch64-none-linux-android Thread model: posix InstalledDir: /home/indy_user/arm64/bin Found candidate GCC installation: /home/indy_user/arm64/bin/../lib/gcc/aarch64-linux-android/4.9.x Selected GCC installation: /home/indy_user/arm64/bin/../lib/gcc/aarch64-linux-android/4.9.x Candidate multilib: .;@m64 Selected multilib: .;@m64 clang50: error: no such file or directory: '/home/indy_user/indy-sdk/libindy/target/aarch64-linux-android/release/libindy.a' cp: cannot stat '/home/indy_user/indy-sdk/libindy/target/aarch64-linux-android/release/libindy.a': No such file or directory The command '/bin/sh -c ./make_indy.sh' returned a non-zero code: 1 ```

kevin.chan (Thu, 12 Jul 2018 22:18:06 GMT):
seems like something to do with openssl in the wrong format?

kevin.chan (Thu, 12 Jul 2018 22:18:18 GMT):
``` = note: /tmp/rustc.nlSCwCXpqlXt/libopenssl_sys-ac0ef2d41fa8ff99.rlib(bio_ssl.o): error adding symbols: File in wrong format ```

kevin.chan (Thu, 12 Jul 2018 22:49:40 GMT):
from what I can tell, seems like there might be a bug here that is always using the arm dependencies when downloading dependencies: https://github.com/hyperledger/indy-sdk/blob/master/libindy/build_scripts/android/build.sh#L28 it should be instead: ``` export OPENSSL_DIR=dependencies/openssl/openssl_${TARGET_ARCH} export SODIUM_DIR=dependencies/sodium/libsodium_${TARGET_ARCH}export LIBZMQ_DIR=dependencies/zmq/libzmq_${TARGET_ARCH} ```

kevin.chan (Thu, 12 Jul 2018 22:49:40 GMT):
from what I can tell, seems like there might be a bug here that is always using the arm dependencies when downloading dependencies: https://github.com/hyperledger/indy-sdk/blob/master/libindy/build_scripts/android/build.sh#L28 it should be instead: ``` export OPENSSL_DIR=dependencies/openssl/openssl_${TARGET_ARCH} export SODIUM_DIR=dependencies/sodium/libsodium_${TARGET_ARCH} export LIBZMQ_DIR=dependencies/zmq/libzmq_${TARGET_ARCH} ```

kevin.chan (Thu, 12 Jul 2018 23:07:05 GMT):
fix worked, created https://github.com/hyperledger/indy-sdk/issues/948

nikhil.kumar (Fri, 13 Jul 2018 01:02:53 GMT):
Hi! i'm currently exploring how I could implement a particular project using Indy/Sovrin. Though some of these questions are inspired by the Sovrin whitepaper, I think they apply to the Indy infrastructure in general. I have read through the Indy SDK (https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md#what-indy-and-libindy-are-and-why-they-matter) and there wasn't a clear answer on a couple of things which are mentioned in the Sovrin whitepaper so I was wondering if anyone could help me understand the following. If these questions are answered on another doc I would be equally appreciative if you could refer me to that document: 1) Is there a way for a verifier to know exactly who issued a particular document or is that information private? 2) In the Indy SDK Getting Started portion there is no discussion about where attributes are stored. Am I correct in understanding that the ledger effectively only facilitates verified communication between two entities for the purpose of sharing this data and that the relevant data storage is off-chain and managed by each entity? Thanks a lot for any help!

mohitgajera (Fri, 13 Jul 2018 06:25:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=cX4CTCjNNLsnNSJAC) @Dominic Thank you very much @Dominic.

srinivasanraghavan (Fri, 13 Jul 2018 07:47:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=a2aCsEdM3pnGozGSb) Again any help for me

VitalijReicherdt (Fri, 13 Jul 2018 07:48:30 GMT):
please publish a new indy-sdk npm package

janl (Fri, 13 Jul 2018 07:52:07 GMT):

Trouble_shoot_GSG.txt

sergey.minaev (Fri, 13 Jul 2018 08:23:51 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=NSXcNypdpNhGMAa2d) @MohsenZ .Net wrapper is a bit out date now and has missed appropriate call. But @tomislav already working on new version of .net (if I understand his comment above correctly)

pimotte (Fri, 13 Jul 2018 08:28:09 GMT):
Is there a way to get a Did created from a seed if the did already exists in the wallet (because then createAndStoreMyDid with that seed fails)?

sergey.minaev (Fri, 13 Jul 2018 09:15:07 GMT):
@pimotte please see comments above https://chat.hyperledger.org/channel/indy-sdk?msg=4kwWJiqK5wQrtscGs

sergey.minaev (Fri, 13 Jul 2018 09:18:20 GMT):
@gudkov https://chat.hyperledger.org/channel/indy-sdk?msg=iHWSpnCEcxLXMX8GX

pimotte (Fri, 13 Jul 2018 09:22:13 GMT):
@sergey.minaev Clear, thanks!

Abhishek_Tyagi (Fri, 13 Jul 2018 09:26:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wKSXNdCFqwxJfmFDc) @pimotte Hello Pimotte,

Abhishek_Tyagi (Fri, 13 Jul 2018 09:28:50 GMT):

Clipboard - July 13, 2018 2:58 PM

Abhishek_Tyagi (Fri, 13 Jul 2018 09:32:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wKSXNdCFqwxJfmFDc) @pimotte Hello Pimotte, Looking at your question, I guess that you have a running network and doing transactions. I have also completed network set-up using : " docker build -f ci/indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9708:9701-9708 indy_pool " But, I am not getting any clue ahead of this. Using vagrant, I was able to do transactions among client and agents but using docker I do not know how to login into client or agents. Further, my ultimate aim is to build a web application(HTML/Angular) through which DID creations, transactions between agents etc. would be possible. Could you please find some time and guide me through this? I have gone through a lot of CLI and wrapper documentations but could not find anything to get going. Thanks and Regards, Abhishek Tyagi

pimotte (Fri, 13 Jul 2018 09:34:32 GMT):
@Abhishek_Tyagi Looks like you're looking for the samples: https://github.com/hyperledger/indy-sdk/tree/master/samples

pimotte (Fri, 13 Jul 2018 09:36:14 GMT):
Also, building a web application at this point would probably need a backend to work

smithbk (Fri, 13 Jul 2018 10:44:11 GMT):
@tomislav Thanks

Abhishek_Tyagi (Fri, 13 Jul 2018 11:00:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qd7wfam47zBdwYdid) @pimotte These samples look good. Thanks for your help.

GarryKelly (Fri, 13 Jul 2018 11:56:37 GMT):
Has joined the channel.

tomislav (Fri, 13 Jul 2018 12:30:45 GMT):
@smithbk I spoke too soon, still speaking in tongues 1.4. There is a way to generate the key using new crypto API `indy_create_key` - https://github.com/hyperledger/indy-sdk/blob/f58e5fde80b71f0dc99ee60ad86c8b3634f8e341/libindy/src/api/crypto.rs#L37

tomislav (Fri, 13 Jul 2018 12:31:47 GMT):
@MohsenZ @sergey.minaev PR is pending that updates dotnet wrapper with protocol version support.

tomislav (Fri, 13 Jul 2018 12:31:47 GMT):
@MohsenZ @sergey.minaev PR is pending that updates dotnet wrapper with protocol version support. - https://github.com/hyperledger/indy-sdk/pull/947

RuWander (Fri, 13 Jul 2018 12:32:47 GMT):
I am getting this error from the nodejs samples when running `npm start` ``` > gettingstarted@1.0.0 start /root/indy-sdk/samples/nodejs > node gettingStarted.js Getting started -> started Open Pool Ledger: pool1 ============================== === Getting Trust Anchor credentials for Faber, Acme, Thrift and Government == ------------------------------ "Sovrin Steward" -> Create wallet "Sovrin Steward" -> Create and store in Wallet DID from seed (node:13717) UnhandledPromiseRejectionWarning: Error: Expected IndyHandle for wallet_handle: createAndStoreMyDid(wallet_handle, did_json, cb(err, [ did, verkey ])) at Object.createAndStoreMyDid (/root/indy-sdk/wrappers/nodejs/src/index.js:204:8) at run (/root/indy-sdk/samples/nodejs/gettingStarted.js:51:47) at (node:13717) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1) (node:13717) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code. /root/indy-sdk/wrappers/nodejs/src/wrapIndyCallback.js:15 cb(new IndyError(err)) ^ TypeError: cb is not a function at Object.callback (/root/indy-sdk/wrappers/nodejs/src/wrapIndyCallback.js:15:7) npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR! gettingstarted@1.0.0 start: `node gettingStarted.js` npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the gettingstarted@1.0.0 start script. npm ERR! This is probably not a problem with npm. There is likely additional logging output above. npm ERR! A complete log of this run can be found in: npm ERR! /root/.npm/_logs/2018-07-13T12_22_04_350Z-debug.log ``` Can someone maybe help with this error?

Abhishek_Tyagi (Fri, 13 Jul 2018 12:37:02 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=yStgM69nY9CAFeh8G) @RuWander Hello RuWander, Did you find any solution to this problem? I am getting a similar issue on my Ubuntu machine. " error[E0658]: non-reference pattern used to match a reference (see issue #42640) --> src/commands/did.rs:538:24 | 538 | if let Some(data) = &res.data { | ^^^^^^^^^^ help: consider using a reference: `&Some(data)` " Thanks, Abhishek

tomislav (Fri, 13 Jul 2018 12:41:30 GMT):
@Abhishek_Tyagi This is because of older rust compiler version. I had the same issue yesterday. Update to at least rustc 1.26

smithbk (Fri, 13 Jul 2018 13:49:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=PXYWboWmxcDXeKJRW) @tomislav But indy_create_key stores it in the wallet. I was looking for a way to generate the DID and verkey from the seed w/o storing it in the wallet because it was already there. I'm currently storing metadata with the DID and using that to look it up, so what you said before works

kendra.bittner (Fri, 13 Jul 2018 16:39:28 GMT):
Has joined the channel.

animeshdas (Fri, 13 Jul 2018 17:37:08 GMT):
Hello, I am facing a end stage issue in using iOS indy sdk

animeshdas (Fri, 13 Jul 2018 17:37:20 GMT):
I am following this https://github.com/hyperledger/indy-sdk/tree/master/wrappers/ios I have successfully completed Step 7 "Run the script. Validate the output that all goes well.", Then I went to directory that has the podfile (~/wrappers/ios/libindy-pod) and I edited the pod file to add "pod 'libindy-objc" to "appPods" defination. Attaching the pod file I am trying to execute.

animeshdas (Fri, 13 Jul 2018 17:37:28 GMT):

Podfile.txt

animeshdas (Fri, 13 Jul 2018 17:38:09 GMT):
And then when I run "pod install" or "pod update". I get the errors shown in the attached file

animeshdas (Fri, 13 Jul 2018 17:38:15 GMT):

podinstallerror.txt

animeshdas (Fri, 13 Jul 2018 17:38:38 GMT):
If the community can give me some pointers on what is preventing the generation of Indy.framework then would be highly appreciated.

ShivKushwah (Fri, 13 Jul 2018 17:59:13 GMT):
Has joined the channel.

ShivKushwah (Fri, 13 Jul 2018 18:17:17 GMT):
Hi! I'm trying to use the indy-sdk for android (working on Mac) and I was able to successfully create the .so files for ARM, ARM64, and x86 after @kevin.chan 's fix. I'm having trouble linking the java wrapper to the .so files in the jniLibs folder, so I'm unable to use the sdk. Is there anyone can point me to help me with this issue? Thanks so much

ShivKushwah (Fri, 13 Jul 2018 18:17:17 GMT):
Hi! I'm trying to use the indy-sdk for android (working on Mac) and I was able to successfully create the .so files for ARM, ARM64, and x86 after @kevin.chan 's fix. I'm having trouble linking the java wrapper to the .so files in the jniLibs folder, so I'm unable to use the sdk. Is there someone anyone can point me to help me with this issue? Thanks so much

AxelNennker (Fri, 13 Jul 2018 18:37:16 GMT):
@ShivKushwah what is the error message? The directory structure? The java wrapper needs java8 and also a network security policy to allow non-https traffic.

Dominic (Fri, 13 Jul 2018 19:01:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=PAr5pyxrTThvhWEXs) @nikhil.kumar 1) *I would like to know as well*. I was actually about to ask the same question. I assume there is a way to check (otherwise anyone would be able issue their own credentials for themselves). 2) Attributes are stored locally in the wallet. From what I can tell, they are stored in a sqlite database at the following location~/.indy_client/wallet//sqlite.db _Based when I see when I open it up with a sqlite DB browser, all the values are encrypted. You can see rows being added when something is stored to the wallet._ I believe your assumption is correct, but I'd still like confirmation from the Indy team

tomislav (Fri, 13 Jul 2018 20:04:10 GMT):
Has the behavior of `indy_set_did_metadata` changed in 1.5? I'm not able to store meta information for their did. Wallet item not found error. Their did is stored and I'm able to pairwise it and list it.

baconsandwich (Fri, 13 Jul 2018 20:58:35 GMT):
Has joined the channel.

MohsenZ (Fri, 13 Jul 2018 21:47:31 GMT):
Hi all. The pull request by @tomislav solved our 308 error issue. We have a pool running on docker on windows and when we run the sample .Net app, we get a 307 (PoolLedgerTimeout) error. Can someone guide us on what we're missing?

swcurran (Fri, 13 Jul 2018 22:50:57 GMT):
@MohsenZ - this a shot in the dark and you probably have checked this already, but frequently when others have seen PoolLedger Timeouts it's because the Agent is trying to talk to the wrong IP:Port to contact the nodes, so it waits forever. If you haven't already - check what IPs:Ports your nodes are running, and check in your agent what IP it is trying to contact.

swcurran (Fri, 13 Jul 2018 22:52:08 GMT):
In our scripts, we use this command to reliably get the dockerhost on different platforms - Mac, Windows, Linux: export DOCKERHOST=${APPLICATION_URL-$(docker run --rm --net=host codenvy/che-ip)}

swcurran (Fri, 13 Jul 2018 22:52:08 GMT):
In our scripts, we use this command to reliably get the dockerhost on different platforms - Mac, Windows, Linux: `export DOCKERHOST=${APPLICATION_URL-$(docker run --rm --net=host codenvy/che-ip)}`

swcurran (Fri, 13 Jul 2018 22:52:36 GMT):
The folks at codenvy make that image just to solve this issue.

ehs035 (Fri, 13 Jul 2018 23:30:02 GMT):
Has joined the channel.

andrewtan (Sat, 14 Jul 2018 02:18:25 GMT):
Has joined the channel.

andrewtan (Sat, 14 Jul 2018 02:22:49 GMT):
Hi, I am trying to get started with Indy-sdk and do some basic coding. As have been out of the coding scene for 10+ years, things have changed a lot indeed. Do I need to have a dedicated PC/Laptop to get Indy-sdk going? I am looking to create a local environment which I can play around. Any help will be much appreciated.

PeterX (Sun, 15 Jul 2018 07:44:10 GMT):
Has joined the channel.

DoctorX (Sun, 15 Jul 2018 12:35:21 GMT):
Has joined the channel.

arunwij (Mon, 16 Jul 2018 04:00:18 GMT):
Hello everyone, In indy-SDK API documentation, there is a method called *setEndpointForDid* (https://github.com/hyperledger/indy-sdk/blob/master/wrappers/nodejs/README.md#setendpointfordid--wh-did-address-transportkey----void) Can anyone explain what is the *transport key* in the method or any documentation related to that?

arunwij (Mon, 16 Jul 2018 04:00:18 GMT):
Hello everyone, In indy-SDK API documentation, there is a method called *setEndpointForDid* (https://github.com/hyperledger/indy-sdk/blob/master/wrappers/nodejs/README.md#setendpointfordid--wh-did-address-transportkey----void) Can anyone explain what is the *transport key* parameter in the method or any documentation related to that?

sergey.minaev (Mon, 16 Jul 2018 05:32:53 GMT):
@andrewtan Hi, I suggest to start from https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md At the end of this file you can find a link to readme about running GSG on almost any machine in docker containers (pre-requests are docker and docker compose) Please read main README also and follow links to your platform. In general are supporting developing and usage SDK on all major OS.

sergey.minaev (Mon, 16 Jul 2018 05:33:32 GMT):
@Artemkaaas @gudkov https://chat.hyperledger.org/channel/indy-sdk?msg=7JaYbGjpRk4eJCmpA

pradeeppadmarajaiah (Mon, 16 Jul 2018 09:49:11 GMT):
Could you please let us know, when the documentation of how-to's for java will updated ??

pradeeppadmarajaiah (Mon, 16 Jul 2018 09:49:55 GMT):
Like Getting started in python, where it issuance loan based. do we have for it java based samples ?

gudkov (Mon, 16 Jul 2018 09:53:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Rau9hcj8eDjSkoQgx) @pradeeppadmarajaiah You can use python getting started as APIs are the same.

DoctorX (Mon, 16 Jul 2018 12:29:15 GMT):

Clipboard - July 16, 2018 8:28 PM

dmitry.anansky (Mon, 16 Jul 2018 14:05:09 GMT):
Has joined the channel.

dmitry.anansky (Mon, 16 Jul 2018 14:11:29 GMT):
Hi all, I was following steps from https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md And got an issue with building the library: --- stdout cargo:rerun-if-env-changed=SODIUM_LIB_DIR cargo:rerun-if-env-changed=SODIUM_STATIC --- stderr thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "`\"pkg-config\" \"--libs\" \"--cflags\" \"libsodium\"` did not exit successfully: signal: 6\n--- stderr\ndyld: Symbol not found: _cg_png_create_info_struct\n Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n Expected in: /usr/local/lib/libPng.dylib\n in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n"', libcore/result.rs:945:5 Please let me know if someone had faced and overcome that issue

dmitry.anansky (Mon, 16 Jul 2018 14:31:01 GMT):
I was trying "cargo build" and 'cargo build --release"

sklump (Mon, 16 Jul 2018 15:33:46 GMT):
Hello, is there any documentation on design intent of the blob_storage reader and writer configuration's `uri_pattern` parameter? What happens if it differs from `base_dir/file` ? Is this data captured somehow in the tails file itself? Thanks.

gudkov (Mon, 16 Jul 2018 15:52:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=iNQ7oTvLcFAKKZu8m) @dmitry.anansky Seems you don't have libsodium that is required for build

dmitry.anansky (Mon, 16 Jul 2018 15:58:52 GMT):
@gudkov , I have it installed "Warning: libsodium 1.0.12 is already installed and up-to-date" with "brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/65effd2b617bade68a8a2c5b39e1c3089cc0e945/Formula/libsodium.rb"

gudkov (Mon, 16 Jul 2018 16:03:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WK2x2XYEHJ7tT99Sp) @dmitry.anansky libindy requires the modern 1.0.14 version of libsodium. Could you check?

dmitry.anansky (Mon, 16 Jul 2018 16:03:37 GMT):
Do I need some other version ?

dmitry.anansky (Mon, 16 Jul 2018 16:04:03 GMT):
ou , will try

dmitry.anansky (Mon, 16 Jul 2018 16:16:05 GMT):
@gudkov Having libsodium 1.0.16 now, but still can see an error: " --- stdout cargo:rerun-if-env-changed=SODIUM_LIB_DIR cargo:rerun-if-env-changed=SODIUM_STATIC --- stderr thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "`\"pkg-config\" \"--libs\" \"--cflags\" \"libsodium\"` did not exit successfully: signal: 6\n--- stderr\ndyld: Symbol not found: __cg_png_create_info_struct\n Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n Expected in: /usr/local/lib/libPng.dylib\n in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n"', libcore/result.rs:945:5 note: Run with `RUST_BACKTRACE=1` for a backtrace. "

dmitry.anansky (Mon, 16 Jul 2018 16:17:11 GMT):
tried both "cargo build" and "cargo build --release"

gudkov (Mon, 16 Jul 2018 16:22:58 GMT):
Try exactly 1.0.14

DoctorX (Mon, 16 Jul 2018 16:25:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WAwWMKea8g9APDRs8) Can anybody help me on this?

kdenhartog (Mon, 16 Jul 2018 20:15:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Rau9hcj8eDjSkoQgx) @pradeeppadmarajaiah This has been brought to a lower priority currently as we're focused on making quite a few changes and keeping them up to date significantly holds back releases of new features. At this point we try to keep the python wrapper up to date only, which @trthhrtz has spent some time working on and we'll bring this maintenance in as a requirement for releases in the future. However, if you would like to help keep the java wrapper how-to guide updated that would be greatly appreciated!

kdenhartog (Mon, 16 Jul 2018 20:21:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=7JaYbGjpRk4eJCmpA) @tomislav As far as I can tell from the git blame, the last change to that part of the SDK was 2 months ago to improve logging. The functionality should be the same. What are the params you are passing when making this call? My guess is, you're getting errors because of the wallet changes in 1.5. Try seeing if the migration guide resolves the problems https://github.com/hyperledger/indy-sdk/blob/master/doc/migration-guide-1.4.0-1.5.0.md

kdenhartog (Mon, 16 Jul 2018 20:23:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WAJXPdSroMJSH9j8v) @dmitry.anansky Did running `cargo build` with libsodium 1.0.14 solve this?

kdenhartog (Mon, 16 Jul 2018 20:25:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nbENTuNpmHYasFRLY) @DoctorX This is the deprecated client. I'd suggest following the instructions for setting up the indy-cli in the indy-sdk repo found here https://github.com/hyperledger/indy-sdk/tree/master/cli

ehs035 (Mon, 16 Jul 2018 20:31:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=LujRStAYqu6Guc2RE) @swcurran Thanks that helped. But now we have a problem in the LedgerDemo.cs file. //8. Trustee Sign Nym Request var nymResponseJson = await Ledger.SignAndSubmitRequestAsync(pool, trusteeWallet, trusteeDid, nymRequest); times out with 307 error. Everything else works fine. (We running the .Net samples app)

kdenhartog (Mon, 16 Jul 2018 20:31:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ZrPFJ4fSoLQFhRWks) @Dominic A Cred_def is a schema which is signed by a key of a DID and exists on the ledger. It is there to identify who can issue a particular schema, as well as I believe it is used in the AnonCreds math.

kdenhartog (Mon, 16 Jul 2018 20:35:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=TXvetK9bZjjy5gJXf) @srinivasanraghavan I don't believe the current implementation would allow for this without deep changes in storage.

kdenhartog (Mon, 16 Jul 2018 20:36:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=SJRsq35jvGfZuCqJ5) @arunwij This is the same as the verkey param

kdenhartog (Mon, 16 Jul 2018 20:37:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=YESguFNZae4tk6RHa) @andrewtan Most guides make the assumption that you're running a local environment and show how to get that setup.

ehs035 (Mon, 16 Jul 2018 21:31:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9MdCQuQrngFeT3qz7) FYI: Just figured it out. var trusteeSeed = "000000000000000000000000Trustee1" was to large for my environment. I guess I need a faster computer.

kdenhartog (Tue, 17 Jul 2018 00:57:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=CQodZpF2nMd8ZvZs3) @ehs035 That seems like an odd solution because that's only a 32bit key that is created from it I believe. Typically, error 307 comes from the wrong IP addresses in your ../indy-sdk/cli/docker_pool_transactions_genesis file

DoctorX (Tue, 17 Jul 2018 01:34:36 GMT):

Clipboard - July 17, 2018 9:33 AM

arunwij (Tue, 17 Jul 2018 03:05:53 GMT):
@kdenhartog Thank you

kdenhartog (Tue, 17 Jul 2018 03:24:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Dzxn4reKtvqLBxj7B) @DoctorX You shouldn't need to make your own. You can find it in the indy-sdk repo here https://github.com/hyperledger/indy-sdk/blob/master/cli/docker_pool_transactions_genesis

DoctorX (Tue, 17 Jul 2018 05:32:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jmto5FxoQ3SCyPKjN) @kdenhartog I see. But I found all the client_ip and node_ip is 10.0.0.2, I may need change it. what does the client_ip and node_ip use for?

dmitry.anansky (Tue, 17 Jul 2018 10:44:06 GMT):
@kdenhartog , @gudkov Currently I have libsoduim 1.0.14 installed [/usr/local/Cellar/libsodium/1.0.14 ]: brew info libsodium => libsodium: stable 1.0.16 (bottled), HEAD NaCl networking and cryptography library https://github.com/jedisct1/libsodium/ /usr/local/Cellar/libsodium/1.0.14 (70 files, 1.2MB) Poured from bottle on 2018-07-17 at 13:37:37 From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/libsodium.rb ==> Options --HEAD Install HEAD version But when I run "cargo build" I can see next output: Compiling pkg-config v0.3.11 ...... Compiling libsodium-sys v0.0.16 ...... Compiling thread_local v0.3.5 error: failed to run custom build command for `libsodium-sys v0.0.16` process didn't exit successfully: `/Users/dananskyi/Documents/swissCom/indy-sdk/libindy/target/debug/build/libsodium-sys-1c36f95f81682a64/build-script-build` (exit code: 101) --- stdout cargo:rerun-if-env-changed=SODIUM_LIB_DIR cargo:rerun-if-env-changed=SODIUM_STATIC --- stderr thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "`\"pkg-config\" \"--libs\" \"--cflags\" \"libsodium\"` did not exit successfully: signal: 6\n--- stderr\ndyld: Symbol not found: __cg_png_create_info_struct\n Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n Expected in: /usr/local/lib/libPng.dylib\n in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n"', libcore/result.rs:945:5 note: Run with `RUST_BACKTRACE=1` for a backtrace. warning: build failed, waiting for other jobs to finish... error: build failed

dmitry.anansky (Tue, 17 Jul 2018 10:44:37 GMT):
I am wondering why it is compiling libsodium-sys v0.0.16 ?

dmitry.anansky (Tue, 17 Jul 2018 10:44:57 GMT):
Should I make some additional changes?

dmitry.anansky (Tue, 17 Jul 2018 10:51:29 GMT):
@gudkov , @kdenhartog JFYI I was using next steps to downgrade my libsodium version: brew rm libsodium brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/cc97dea94e2b9daf01823df81b171e1bcdc4b272/Formula/libsodium.rb brew info libsodium

gudkov (Tue, 17 Jul 2018 11:25:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9mKPuuXNKExzoFQBB) @dmitry.anansky I suggest to call ```cargo clean``` and than try again

DoctorX (Tue, 17 Jul 2018 11:51:02 GMT):
Guys, is there a way I can read\write arbitrary data from indy client to the ledger ?

dmitry.anansky (Tue, 17 Jul 2018 11:54:25 GMT):
@gudkov "cargo clean " didn't help :( dananskyi$ cargo clean dananskyi$ cargo build Compiling num-traits v0.2.4 ... Compiling libsodium-sys v0.0.16 ... Compiling etcommon-rlp v0.2.3 error: failed to run custom build command for `libsodium-sys v0.0.16` process didn't exit successfully: `/Users/dananskyi/Documents/swissCom/indy-sdk/libindy/target/debug/build/libsodium-sys-1c36f95f81682a64/build-script-build` (exit code: 101) --- stdout cargo:rerun-if-env-changed=SODIUM_LIB_DIR cargo:rerun-if-env-changed=SODIUM_STATIC --- stderr thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "`\"pkg-config\" \"--libs\" \"--cflags\" \"libsodium\"` did not exit successfully: signal: 6\n--- stderr\ndyld: Symbol not found: __cg_png_create_info_struct\n Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n Expected in: /usr/local/lib/libPng.dylib\n in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n"', libcore/result.rs:945:5 note: Run with `RUST_BACKTRACE=1` for a backtrace. warning: build failed, waiting for other jobs to finish... error: build failed

dmitry.anansky (Tue, 17 Jul 2018 11:54:25 GMT):
@gudkov "cargo clean " didn't help :( dananskyi$ cargo clean dananskyi$ cargo build Compiling num-traits v0.2.4 ... Compiling libsodium-sys v0.0.16 ... Compiling etcommon-rlp v0.2.3 error: failed to run custom build command for `libsodium-sys v0.0.16` process didn't exit successfully: `/Users/dananskyi/Documents/indy-sdk/libindy/target/debug/build/libsodium-sys-1c36f95f81682a64/build-script-build` (exit code: 101) --- stdout cargo:rerun-if-env-changed=SODIUM_LIB_DIR cargo:rerun-if-env-changed=SODIUM_STATIC --- stderr thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "`\"pkg-config\" \"--libs\" \"--cflags\" \"libsodium\"` did not exit successfully: signal: 6\n--- stderr\ndyld: Symbol not found: __cg_png_create_info_struct\n Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n Expected in: /usr/local/lib/libPng.dylib\n in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n"', libcore/result.rs:945:5 note: Run with `RUST_BACKTRACE=1` for a backtrace. warning: build failed, waiting for other jobs to finish... error: build failed

Abhishek_Tyagi (Tue, 17 Jul 2018 11:55:47 GMT):
Hello, I am following "How-Tos" for python wrapper to connect my Indy Pool with Indy-SDK. In the first step, I have prepared WRITE_DID.PY but while running it, getting following error: "1. Create new pool ledger configuration to connect to ledger. _indy_loop_callback: Function returned error 114 Error occurred: ErrorCode.CommonIOError" I have rechecked the path to the docker_pool_transactions_genesis file and it's correct. Could anyone please look into this? Thanks,

RuWander (Tue, 17 Jul 2018 12:06:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=pLZ29mmeLeQiktQC3) @Abhishek_Tyagi Hi, I am also having this issue. I have also changed the path to point to the docker_pool_transactions_genesis file but then I get this unicode error: ``` (unicode erro) 'unicodeescape' codec can't decode bytes in position 0-1:truncated \UXXXXXXX escape ``` Does anyone know if the file should be another format? I have noticed that the path before I changed it pointed to a vagrant file in the home directory, I am using docker for the pools should the path not in someway point to the genesis file in the docker env?

dmitry.anansky (Tue, 17 Jul 2018 12:09:37 GMT):
@gudkov After I change [[package]] name = "libsodium-sys" version = "0.0.14" source = "registry+https://github.com/rust-lang/crates.io-index" dependencies = [ "libc 0.2.41 (registry+https://github.com/rust-lang/crates.io-index)", "pkg-config 0.3.11 (registry+https://github.com/rust-lang/crates.io-index)", ] inside Cargo.lock file and sodiumoxide = {version = "0.0.14", optional = true} in Cargo.toml I still can see the error: dananskyi$ cargo clean dananskyi$ cargo build Updating registry `https://github.com/rust-lang/crates.io-index` Downloading sodiumoxide v0.0.14 Downloading libsodium-sys v0.0.14 Downloading serde v0.9.15 Compiling pkg-config v0.3.11 .... Compiling libsodium-sys v0.0.14 .... Compiling etcommon-rlp v0.2.3 error: failed to run custom build command for `libsodium-sys v0.0.14` process didn't exit successfully: `/Users/dananskyi/Documents/indy-sdk/libindy/target/debug/build/libsodium-sys-34a8d93cf44a8535/build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "`\"pkg-config\" \"--libs\" \"--cflags\" \"libsodium\"` did not exit successfully: signal: 6\n--- stderr\ndyld: Symbol not found: __cg_png_create_info_struct\n Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n Expected in: /usr/local/lib/libPng.dylib\n in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n"', libcore/result.rs:945:5 note: Run with `RUST_BACKTRACE=1` for a backtrace. warning: build failed, waiting for other jobs to finish... error: build failed

dmitry.anansky (Tue, 17 Jul 2018 12:10:53 GMT):
Not sure that it is right to change it manually , it might be not correctly linked

Abhishek_Tyagi (Tue, 17 Jul 2018 12:12:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=HfmBcMWDEy9g75aSz) @RuWander What file you are pointing to right now, instead of "docker_pool_transactions_genesis" and why?

voddan (Tue, 17 Jul 2018 12:20:27 GMT):
Has joined the channel.

RuWander (Tue, 17 Jul 2018 12:21:29 GMT):
@Abhishek_Tyagi I am still pointing to the 'docker_pool_transactions_genesis' file but not in the' /home/vagrant/code/evernym/indy-sdk/cli/docker_pool_transactions_genesis' path but rather to the path in the indy-sdk directory, my working directory. If that makes sense?

voddan (Tue, 17 Jul 2018 12:26:44 GMT):
Hi! Version 1.4 of the sdk started using something called `schemaId`, which is a structured string (see `Anoncreds.issuerCreateSchema` return value). Can you tell me how stable `schemaId` format is? Do you plan to use those ids to publicly identify schemes, or do you reserve a right to change their format in the future? What are the compatibility and migration guaranties from Indy? Can I share a `schemaId` with a user as-is, or are those internal ids and subgect to change? Thanks

kdenhartog (Tue, 17 Jul 2018 12:46:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=pZs2kexHsPj92TT2L) @dmitry.anansky here is how you set a specific version with brew try this https://stackoverflow.com/questions/3987683/homebrew-install-specific-version-of-formula

kdenhartog (Tue, 17 Jul 2018 12:49:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=PDMFi8kuqL6Cv7DKD) @DoctorX The IPs are the IP addresses of the nodes that run indy-node. In a local environment, they all need to be set to `127.0.0.1` for me (I'm on mac). If you we're to host nodes for a personal test environment on AWS then you would need to change the IPs to the IPs of your instances on the AWS servers.

kdenhartog (Tue, 17 Jul 2018 12:50:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=vgDqTbf78sJmxdoZ7) @DoctorX Can you be more specific about what you are trying to accomplish?

kdenhartog (Tue, 17 Jul 2018 12:54:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=pLZ29mmeLeQiktQC3) @Abhishek_Tyagi The only reason I've seen this error occur is due to the path of the genesis file not being set right. I'd suggest giving a full path to the file, because Python is very picky about how it finds paths of files. I was playing around with how we can fix this yesterday with little luck.

kdenhartog (Tue, 17 Jul 2018 12:56:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=HfmBcMWDEy9g75aSz) @RuWander The file should be of correct format. Did you accidently add a character into the file while running it? Also, which compiler is throwing this error the python compiler? If you are running this with the docker instance, I typically have to change the IPs from `10.0.0.2` to '127.0.0.1' you'll also need to add the command `await pool.set_protocol_version(2)` after step one.

dmitry.anansky (Tue, 17 Jul 2018 12:57:41 GMT):
@kdenhartog , now I have correct version of libsodium, but build still failing

dmitry.anansky (Tue, 17 Jul 2018 12:58:45 GMT):
brew info libsodium libsodium: stable 1.0.16 (bottled), HEAD NaCl networking and cryptography library https://github.com/jedisct1/libsodium/ /usr/local/Cellar/libsodium/1.0.14 (70 files, 1.2MB) * Poured from bottle on 2018-07-17 at 13:37:37 From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/libsodium.rb ==> Options --HEAD Install HEAD version

RuWander (Tue, 17 Jul 2018 12:58:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=hDDEMLKMNY9GCzuro) @kdenhartog I don't believe I have changed the file in any way, but I will go an make sure I haven't. Yes I am using the Python compiler

RuWander (Tue, 17 Jul 2018 12:58:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=hDDEMLKMNY9GCzuro) @kdenhartog @DoctorX I don't believe I have changed the file in any way, but I will go an make sure I haven't. Yes I am using the Python compiler

kdenhartog (Tue, 17 Jul 2018 13:00:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=HtPTPtXRmDyCq4eEM) @dmitry.anansky It still appears you are on 1.0.16 because that is your HEAD and your last command is Install HEAD version

dmitry.anansky (Tue, 17 Jul 2018 13:01:13 GMT):
this one is mine current /usr/local/Cellar/libsodium/1.0.14 (70 files, 1.2MB)

kdenhartog (Tue, 17 Jul 2018 13:02:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=uvYbAEtienkicwKBc) @RuWander What OS are you running on? If it's windows you probably have to build the path differently. See this https://stackoverflow.com/questions/1347791/unicode-error-unicodeescape-codec-cant-decode-bytes-cannot-open-text-file

dmitry.anansky (Tue, 17 Jul 2018 13:03:56 GMT):
@kdenhartog I tried those steps from https://stackoverflow.com/questions/3987683/homebrew-install-specific-version-of-formula brew versions is deprecated now and brew search holds only latest version of libsodium

dmitry.anansky (Tue, 17 Jul 2018 13:04:24 GMT):
that is why I was using those instructions https://github.com/rust-lang/rust/issues/45629

dmitry.anansky (Tue, 17 Jul 2018 13:04:32 GMT):
to get 1.0.14 version

kdenhartog (Tue, 17 Jul 2018 13:08:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=yGrLFQ3sfPyPEkLkN) @dmitry.anansky do `brew list --versions` and list the output to me. I'm still running 1.0.12 and it works for me, so I think you're not specifying the version properly still.

dmitry.anansky (Tue, 17 Jul 2018 13:09:49 GMT):
brew list --versions autoconf 2.69 automake 1.16.1 cmake 3.11.4 gdbm 1.16 libpng 1.6.34 libsodium 1.0.14 libtool 2.4.6_1 mongodb 4.0.0 openssl 1.0.2o_2 pkg-config 0.29.2 python@2 2.7.15_1 readline 7.0.5 source-to-image 1.1.10 sqlite 3.24.0 zeromq 4.2.5

dmitry.anansky (Tue, 17 Jul 2018 13:09:59 GMT):
@kdenhartog

dmitry.anansky (Tue, 17 Jul 2018 13:10:49 GMT):
@kdenhartog yesterday I had 1.0.12 but it was failing for me with the same error

dmitry.anansky (Tue, 17 Jul 2018 13:11:06 GMT):
I also tried on 1.0.16

kdenhartog (Tue, 17 Jul 2018 13:11:32 GMT):
have you set all of your environment variables properly?

RuWander (Tue, 17 Jul 2018 13:11:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=HG42Ke5DouSv3iiwJ) @kdenhartog I got that error on Windows while I was waiting for my Ubuntu environment to finish installing. Thank you I will attempt to build the path. I will mostly be working on Ubuntu and are still getting this error if someone can help: ``` _indy_loop_callback: Function returned error 114 Error occurred: ErrorCode.CommonIOError FATAL: exception not rethrown Aborted (core dumped) ```

dmitry.anansky (Tue, 17 Jul 2018 13:12:50 GMT):
@kdenhartog I followed those instructions https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md

dmitry.anansky (Tue, 17 Jul 2018 13:13:15 GMT):
so all env variables were taken from there

DoctorX (Tue, 17 Jul 2018 13:16:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=w7ieA397Sg8PYGtmS) @kdenhartog @kdenhartog , I want to do some extension beside self-sovereign identity. For example, I am a Indy Agent and I may just need write some data (like bill payment receipt or send money transaction) the ledger. And, I will need read these data from Ledger. @danielhardman told me that I can send ATTRIB transaction to write data. And for the get GET_ATTR request, seems it just return one ATTRIB. But I may need query multiple ATTIRBs once. For example, I may need query Alice's send money transaction in this month.

kdenhartog (Tue, 17 Jul 2018 13:20:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=KEoz7XvLkdGdbA5bM) @RuWander I'm not sure how to trouble shoot Windows. On ubuntu go into `/indy-sdk/cli/` and type `pwd` then paste the results of that and add `docker_pool_transactions_genesis` to the end. So for example on mac my path I use looks like this `/Users/kyle/Dev/Evernym/indy-sdk/cli/docker_pool_transactions_genesis`

kdenhartog (Tue, 17 Jul 2018 13:22:37 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nuduSQ6szEhAcdnjs) @DoctorX Attrib is not for posting data to the ledger. Attrib should only be used to post data that is in the DID-Doc. An example of a DID-Doc can be found here: https://w3c-ccg.github.io/did-spec/#real-world-example

kdenhartog (Tue, 17 Jul 2018 13:25:02 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ditSSwedTgc27YbT5) @dmitry.anansky try uninstalling everything you did in this and start over. That's what I typically do if I can't figure out why something is messing up.

dmitry.anansky (Tue, 17 Jul 2018 13:25:08 GMT):
@kdenhartog dananskyi$ printenv RUST_LOG=indy=trace TERM_PROGRAM=Apple_Terminal SHELL=/bin/bash TERM=xterm-256color TERM_PROGRAM_VERSION=404 OLDPWD=/Users/dananskyi/Documents/indy-sdk USER=dananskyi RUST_TEST_THREADS=1 PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin PWD=/Users/dananskyi/Documents/indy-sdk/libindy PKG_CONFIG_ALLOW_CROSS=1 LANG=en_US.UTF-8 XPC_FLAGS=0x0 XPC_SERVICE_NAME=0 SHLVL=1 HOME=/Users/dananskyi LOGNAME=dananskyi CARGO_INCREMENTAL=1 _=/usr/bin/printenv

dmitry.anansky (Tue, 17 Jul 2018 13:25:31 GMT):
@kdenhartog I will try

DoctorX (Tue, 17 Jul 2018 13:27:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=2ijRP8tfc9LMKtEsg) @kdenhartog Yes, I get that. For example, Alice is customer of WesternUnion, and WesternUnion is Indy Agent. Everytime, Alice send a money to his mother, WesternUnion will write the send money transaction to ledger. And some day, Alice or WesternUnion want to get all the send money transactions for a month, how can I implement it in Indy?

DoctorX (Tue, 17 Jul 2018 13:29:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WM8c5eNpYiqtBiGuJ) @kdenhartog , in this case, maybe one DID-Doc for one send money transaction, but how to get all these transaction from Alice?

kdenhartog (Tue, 17 Jul 2018 13:30:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WM8c5eNpYiqtBiGuJ) @DoctorX You would need to use these API calls to interact with payment functionality, but the node published to hyperledger/indy-node:master won't understand these calls currently. https://github.com/hyperledger/indy-sdk/tree/master/doc/design/004-payment-interface

kdenhartog (Tue, 17 Jul 2018 13:31:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=XPomKizws5nxsQtYe) @DoctorX I think you may be conflating two concepts. DID-Docs should be for posting keys and endpoints and should use ATTRIB transactions. The payments API is for making payments and would have it's own transactions that haven't been implemented yet on the Node side. So although you can submit the transactions from the SDK, you'll get errors because the Nodes don't currently understand the transactions that the SDK is submitting.

RuWander (Tue, 17 Jul 2018 13:34:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=YyPngTHXa2Lcjerad) @kdenhartog Thank you very much this worked for the Ubuntu Machine. I had to add the `await pool.set_protocol_version(2)` after the first step also to get it to work. However, I am now getting this: ``` _indy_loop_callback: Function returned error 306 Error occurred: ErrorCode.PoolLedgerConfigAlreadyExistsError ``` This Might be a stupid question:What might be the best way to fix this? Should the PoolLedgerConfig be deleted in some way?

kdenhartog (Tue, 17 Jul 2018 13:36:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WEYj7dtiajrBZq2sC) @RuWander This typically happens when things error out before it gets to the end of the file. Copy step 19 and paste it above step 1 and everything should run for you.

kdenhartog (Tue, 17 Jul 2018 13:36:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WEYj7dtiajrBZq2sC) @RuWander This typically happens when things error out before it gets to the end of the file, For example when you didn't have the path set properly but it was still trying to setup the pool. Copy step 19 and paste it above step 1 and everything should run for you.

DoctorX (Tue, 17 Jul 2018 13:41:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=czkHzPZczPMiDDsgX) @kdenhartog I am not looking for payment interface. I am looking for a way to simply read\write the ledger. Let me go back the send money example, when Alice send out the money, the transaction is created, and when Alice's mother get the Money, the destination Agent will update the transaction status to 'Complete'. In this case, we just treat the ledger as simple database, just read\write it. I know Indy is not designed for this case, but I mean, it's extension.

DoctorX (Tue, 17 Jul 2018 13:45:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=P6NKXmPQworwiXZ2S) Like in Fabric, I can simply design a struct, and write a instance of that struct by associate it with a Key, then I can update it by the key, and get the history by the key.

DoctorX (Tue, 17 Jul 2018 13:45:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=EFmg8geSZH9vC2tPo) @kdenhartog , I want do the same in Indy.

kdenhartog (Tue, 17 Jul 2018 13:48:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=P6NKXmPQworwiXZ2S) @DoctorX Ahh, I think I'm understanding what you're looking for now. As I understand it you want to be able to write any piece of data to the ledger which is not what the Indy ledger is designed for. Rather, Indy ledger is designed for highly specific pieces of data related specifically to identity (e.g. DID-Doc related data, schemas, cred-defs, etc)

dmitry.anansky (Tue, 17 Jul 2018 13:48:33 GMT):
@kdenhartog I reinstalled everything according https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md brew list --versions autoconf 2.69 automake 1.16.1 cmake 3.11.4 gdbm 1.16 libpng 1.6.34 libsodium 1.0.12 libtool 2.4.6_1 mongodb 4.0.0 openssl 1.0.2o_2 pkg-config 0.29.2 python@2 2.7.15_1 readline 7.0.5 source-to-image 1.1.10 sqlite 3.24.0 zeromq 4.2.5 But I am still getting error while trying to run "cargo build" cargo build Compiling libsodium-sys v0.0.16 Compiling zmq-sys v0.8.2 Compiling typenum v1.10.0 Compiling quote v0.6.3 error: failed to run custom build command for `libsodium-sys v0.0.16` process didn't exit successfully: `/Users/dananskyi/Documents/swissCom/indy-sdk/libindy/target/debug/build/libsodium-sys-1c36f95f81682a64/build-script-build` (exit code: 101) --- stdout cargo:rerun-if-env-changed=SODIUM_LIB_DIR cargo:rerun-if-env-changed=SODIUM_STATIC --- stderr thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "`\"pkg-config\" \"--libs\" \"--cflags\" \"libsodium\"` did not exit successfully: signal: 6\n--- stderr\ndyld: Symbol not found: __cg_png_create_info_struct\n Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n Expected in: /usr/local/lib/libPng.dylib\n in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n"', libcore/result.rs:945:5 note: Run with `RUST_BACKTRACE=1` for a backtrace. warning: build failed, waiting for other jobs to finish... error: build failed

dmitry.anansky (Tue, 17 Jul 2018 13:48:33 GMT):
@kdenhartog I reinstalled everything according https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md brew list --versions autoconf 2.69 automake 1.16.1 cmake 3.11.4 gdbm 1.16 libpng 1.6.34 libsodium 1.0.12 libtool 2.4.6_1 mongodb 4.0.0 openssl 1.0.2o_2 pkg-config 0.29.2 python@2 2.7.15_1 readline 7.0.5 source-to-image 1.1.10 sqlite 3.24.0 zeromq 4.2.5 But I am still getting error while trying to run "cargo build" cargo build Compiling libsodium-sys v0.0.16 Compiling zmq-sys v0.8.2 Compiling typenum v1.10.0 Compiling quote v0.6.3 error: failed to run custom build command for `libsodium-sys v0.0.16` process didn't exit successfully: `/Users/dananskyi/Documents/indy-sdk/libindy/target/debug/build/libsodium-sys-1c36f95f81682a64/build-script-build` (exit code: 101) --- stdout cargo:rerun-if-env-changed=SODIUM_LIB_DIR cargo:rerun-if-env-changed=SODIUM_STATIC --- stderr thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "`\"pkg-config\" \"--libs\" \"--cflags\" \"libsodium\"` did not exit successfully: signal: 6\n--- stderr\ndyld: Symbol not found: __cg_png_create_info_struct\n Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n Expected in: /usr/local/lib/libPng.dylib\n in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n"', libcore/result.rs:945:5 note: Run with `RUST_BACKTRACE=1` for a backtrace. warning: build failed, waiting for other jobs to finish... error: build failed

RuWander (Tue, 17 Jul 2018 13:48:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qu9hEAFxj8DHzLq7P) @kdenhartog It seems that I don't have a step 19 could it be step 15? That is: `await pool.delete_pool_ledger_config(pool_name)`?

dmitry.anansky (Tue, 17 Jul 2018 13:48:55 GMT):
Now I have libsodium 1.0.12

DoctorX (Tue, 17 Jul 2018 13:53:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=NfZs2SoYcGPmHR4XC) @kdenhartog Correct, that why I call it extension. Do you think it's possible?

DoctorX (Tue, 17 Jul 2018 13:57:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mJvoEhSaCGS2JspgJ) Maybe I need modify some Rust code to expose such API to do so, but I don't know how to do that. It's quite difficult to me.

DoctorX (Tue, 17 Jul 2018 14:05:18 GMT):
@kdenhartog , I was trying to use WalletRecord to do so, but in the end, I found it does't write to Ledger.

kdenhartog (Tue, 17 Jul 2018 14:06:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mJvoEhSaCGS2JspgJ) @DoctorX It would be possible to do this, but I wouldn't suggest it as it breaks the Data model that has been designed for this ledger. In particular we've moved all information that is not metadata off the ledger to comply with GDPR and for privacy by design. By moving this data onto the ledger, you will walk dangerously close to being unable to adhere to the right to erasure clause as well. The other issue with Privacy by design is that say for example you encrypt the data and post it to the ledger and then that encryption scheme is broke, then any person who can access the encrypted data (which is anyone because the data is published to the ledger) would be able to crack the ciphertext and read the data. For these two reasons, I'd suggest sticking with the current data model which is that if someone wants data from me they should get it from my agent, not from the ledger.

kdenhartog (Tue, 17 Jul 2018 14:13:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=37yAhHBENgA7JcYrf) @dmitry.anansky have you been able to build the system now?

kdenhartog (Tue, 17 Jul 2018 14:13:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=zjcNNWShhsvKi5fqj) @RuWander yup that's the one

dmitry.anansky (Tue, 17 Jul 2018 14:18:19 GMT):
@kdenhartog no - same error

DoctorX (Tue, 17 Jul 2018 14:19:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Ef9ohiynnWxgkusym) @kdenhartog I understand the risk, but anyway, I have to do this. Do you think where can I get start?

dmitry.anansky (Tue, 17 Jul 2018 14:20:37 GMT):
cargo build Compiling libsodium-sys v0.0.16 Compiling zmq-sys v0.8.2 Compiling typenum v1.10.0 Compiling quote v0.6.3 error: failed to run custom build command for `libsodium-sys v0.0.16` process didn't exit successfully: `/Users/dananskyi/Documents/indy-sdk/libindy/target/debug/build/libsodium-sys-1c36f95f81682a64/build-script-build` (exit code: 101) --- stdout cargo:rerun-if-env-changed=SODIUM_LIB_DIR cargo:rerun-if-env-changed=SODIUM_STATIC --- stderr thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "`\"pkg-config\" \"--libs\" \"--cflags\" \"libsodium\"` did not exit successfully: signal: 6\n--- stderr\ndyld: Symbol not found: __cg_png_create_info_struct\n Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n Expected in: /usr/local/lib/libPng.dylib\n in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n"', libcore/result.rs:945:5 note: Run with `RUST_BACKTRACE=1` for a backtrace. warning: build failed, waiting for other jobs to finish... error: build failed

kdenhartog (Tue, 17 Jul 2018 14:25:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=r6FdNHkGxcquCxYEW) @DoctorX You'd have to write the plugin yourself to do this

kdenhartog (Tue, 17 Jul 2018 14:28:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=eFZLymuCuaGCnRA4Z) The other alternative is that you publish the data to a Fabric ledger and use Indy for your identity system rather than CAs

DoctorX (Tue, 17 Jul 2018 14:39:26 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=eFZLymuCuaGCnRA4Z) @kdenhartog Is there any guidance I can refer to?

dmitry.anansky (Tue, 17 Jul 2018 14:44:59 GMT):
@kdenhartog are you using libsodium 1.0.12 as well ? Why I can see that msg = "error: failed to run custom build command for `libsodium-sys v0.0.16"? Is there are any updated steps for macOS to run indy-sdk?

kdenhartog (Tue, 17 Jul 2018 14:49:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JpzSJ9oDTGBmkpsBc) @dmitry.anansky yes, that I'm also using `libsodium 1.0.12` `libsodium-sys v0.0.16` references the cargo crate version. I don't believe there's updated steps let me look around and see if I can find some.

dmitry.anansky (Tue, 17 Jul 2018 14:52:24 GMT):
I have also backtrace. It might be helpful stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49 1: std::sys_common::backtrace::print at libstd/sys_common/backtrace.rs:71 at libstd/sys_common/backtrace.rs:59 2: std::panicking::default_hook::{{closure}} at libstd/panicking.rs:211 3: std::panicking::default_hook at libstd/panicking.rs:227 4: as core::panic::BoxMeUp>::get at libstd/panicking.rs:463 5: std::panicking::try::do_call at libstd/panicking.rs:350 6: std::panicking::try::do_call at libstd/panicking.rs:328 7: <&'a T as core::fmt::Display>::fmt at libcore/panicking.rs:71 8: core::result::unwrap_failed at /Users/travis/build/rust-lang/rust/src/libcore/macros.rs:26 9: >::unwrap at /Users/travis/build/rust-lang/rust/src/libcore/result.rs:782 10: build_script_build::main at ./build.rs:20 11: std::rt::lang_start::{{closure}} at /Users/travis/build/rust-lang/rust/src/libstd/rt.rs:74 12: std::panicking::try::do_call at libstd/rt.rs:59 at libstd/panicking.rs:310 13: panic_unwind::dwarf::eh::read_encoded_pointer at libpanic_unwind/lib.rs:105 14: std::sys_common::bytestring::debug_fmt_bytestring at libstd/panicking.rs:289 at libstd/panic.rs:374 at libstd/rt.rs:58 15: std::rt::lang_start at /Users/travis/build/rust-lang/rust/src/libstd/rt.rs:74 16: build_script_build::main

gudkov (Tue, 17 Jul 2018 14:58:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=daz8QBS5eyrRWsPeq) @dmitry.anansky I am not sure your problem is related to libindy: ``` Symbol not found: _cg_png_create_info_struct\n Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n Expected in: /usr/local/lib/libPng.dylib\n in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n"', libcore/result.rs:945:5 ```

dmitry.anansky (Tue, 17 Jul 2018 15:14:43 GMT):
@gudkov it might be other source - but I just got version from git by following instructions. No manual changes in indy-sdk

Dominic (Tue, 17 Jul 2018 15:14:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=unR5kbMKiQDfRSRpm) @kdenhartog And how does a cred def differ from a cred offer? I get that it's 1.schema --> 2.cred def --> 3.cred offer, but I don't see why the third step is needed.

Dominic (Tue, 17 Jul 2018 15:14:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jMsseC3rugdignap2) @kdenhartog Sorry I didn't write the question properly. That's my bad. What I'm confused about now is how is the cred offer different from creating and sending the credential? In the code I looked at, the prover receives a credential offer, and then uses it to create a credential request. Once the issuer receives the cred request, he sends back the credential. What job does the credential offer perform? My reasoning is that it would be simpler if a credential offer wasn't necessary for formulating a request. Thanks for taking the time to answer by the way. It means a lot :)

dmitry.anansky (Tue, 17 Jul 2018 15:15:19 GMT):
@gudkov is there are some stable version elsewhere ?

kdenhartog (Tue, 17 Jul 2018 15:39:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=tF25CckMZdokNpfSy) @Dominic Think of the model like this a schema is a template for what the structure of a credential will be. A cred_def is the acknowledgement of that template, so that a person can issue a credential with that template, and a cred offer is the actual issuance of the credential with that template.

Dominic (Tue, 17 Jul 2018 16:07:56 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jMsseC3rugdignap2) @kdenhartog Sorry I didn't write the question properly. That's my bad. What I'm confused about now is how is the cred offer different from creating and sending the credential? In the code I looked at, the prover receives a credential offer, and then uses it to create a credential request. Once the issuer receives the cred request, he sends back the credential. What job does the credential offer perform? My reasoning is that it would be simpler if a credential offer wasn't necessary for formulating a request. Thanks for taking the time to answer by the way. It means a lot :)

Dominic (Tue, 17 Jul 2018 16:07:56 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jMsseC3rugdignap2) @kdenhartog Sorry I didn't write the question properly. That's my bad. What I'm confused about now is how the cred offer differs from creating and sending the credential. In the code I looked at, the prover receives a credential offer, and then uses it to create a credential request. Once the issuer receives the cred request, he sends back the credential. What job does the credential offer perform? My reasoning is that it would be simpler if a credential offer wasn't necessary for formulating a request. Thanks for taking the time to answer by the way. It means a lot :)

VuiLenDi (Tue, 17 Jul 2018 16:40:10 GMT):
Has joined the channel.

ShivKushwah (Tue, 17 Jul 2018 17:07:58 GMT):
Hi, I'm working on using the indy-sdk for Android and I'm running into problems using the generated libindy.so files. Is there anyone who can help me with this? Thanks!

kdenhartog (Tue, 17 Jul 2018 18:15:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aQEKRa7uM7W6Yob46) @Dominic It's like a negotiation of information on that's going to be shared. For example, I say I'll share my name only with you and send it in an offer. Then you respond with a credential request and ask for my name, birthday, address, and phone number. I then submit a credential offer back offering only my name and phone number. You decide that's enough information and send a request back asking for my name and phone number which is a signal of acknowledging the agreement on which information should be shared. At which point I then send you my actual data. More details can be found on this at repository https://github.com/sovrin-foundation/protocol/

Dominic (Tue, 17 Jul 2018 20:30:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=8f7b673c-3416-4b73-8d42-ea894fcb8123) @kdenhartog Are you sure about this? Based on what you're saying, the prover would provide cred offers, but the function is specifically called *issuer*_create_credential_offer. _I'm talking specifically about credential issuance, not proof negotiation._ The issuer already knows the prover's information, they just need to "sign" (issue) it. For example suppose an American driver wants to get a digital driver's license that is issued by a state, and suppose all American states use the same schema created by the federal government. When the driver (prover) wants the state (issuer) to give them a driver's license (credential), the state (issuer) gets a schema defined by the federal government, *the state (issuer) uses the schema to create a credential definition, and then, the state (issuer) uses this credential definition to create a cred offer*, which the state (issuer) then sends to the driver (prover). The driver (prover) takes this cred offer, and creates a cred request that he sends back to the state (issuer). Once the state receives that cred request, they may choose to create the driver's license (credential) and send it to the prover. As far as I can tell, this is the typical sequence for credential issuance. The part that confuses me is the part I highlighted in bold. Why is it two separate steps? Why not just have a cred def and create a credential when they receive a cred request?

kdenhartog (Tue, 17 Jul 2018 21:05:02 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WChGRBs2NNo9EQvQE) @Dominic Looks like I didn't understand your question originally, but now I do. From what I understand, you're wanting to know why is an offer necessary to begin credential issuance rather than just requesting one. `A credential definition associates an issuer and their public issuance keys with a particular schema and revocation strategy.` as defined here: https://github.com/sovrin-foundation/protocol/blob/master/themis/cred-def.md A credential offer is done at the time of issuance in order to notify the holder of willingness to issue, as well as potentially to notify the holder of the cost of the credential. In terms, of why the offer needs to go first, it comes down to design of the protocol. Specifically, by offering first an issuer implicitly commits to issuing a credential of a specific schema. It also has to do with the fact that this same negotiation sequence works for both connection setup and credential issuance. More details of this can be found here https://github.com/sovrin-foundation/protocol/blob/master/patterns/abstract-negotiation-seq.puml

kdenhartog (Tue, 17 Jul 2018 21:05:02 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WChGRBs2NNo9EQvQE) @Dominic Looks like I didn't understand your question originally, but now I do. From what I understand, you're wanting to know why is an offer necessary to begin credential issuance rather than just requesting one. `A credential definition associates an issuer and their public issuance keys with a particular schema and revocation strategy.` as defined here: https://github.com/sovrin-foundation/protocol/blob/master/themis/cred-def.md A credential offer is done at the time of issuance in order to notify the holder of willingness to issue, as well as potentially to notify the holder of the cost of the credential. In terms, of why the offer needs to go first, it comes down to design of the protocol. Specifically, by offering first an issuer implicitly commits to issuing a credential of a specific schema. It also has to do with the fact that this same negotiation sequence works for both connection setup and credential issuance. More details of this can be found [here] (https://github.com/sovrin-foundation/protocol/blob/master/patterns/abstract-negotiation-seq.puml). Does that answer the question better?

kdenhartog (Tue, 17 Jul 2018 21:05:02 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WChGRBs2NNo9EQvQE) @Dominic Looks like I didn't understand your question originally, but now I do. From what I understand, you're wanting to know why is an offer necessary to begin credential issuance rather than just requesting one. `A credential definition associates an issuer and their public issuance keys with a particular schema and revocation strategy.` as defined here: https://github.com/sovrin-foundation/protocol/blob/master/themis/cred-def.md A credential offer is done at the time of issuance in order to notify the holder of willingness to issue, as well as potentially to notify the holder of the cost of the credential. In terms, of why the offer needs to go first, it comes down to design of the protocol. Specifically, by offering first an issuer implicitly commits to issuing a credential of a specific schema. It also has to do with the fact that this same negotiation sequence works for both connection setup and credential issuance. More details of this can be found here: https://github.com/sovrin-foundation/protocol/blob/master/patterns/abstract-negotiation-seq.puml. Does that answer the question better?

animeshdas (Tue, 17 Jul 2018 21:09:13 GMT):
Hello all, over the past week I have been working to get the iOS SDK to compile and generate the Indy.framework that I can use in my iOS app.

animeshdas (Tue, 17 Jul 2018 21:11:01 GMT):
I faced a few problems due to the readme of iOS wrapper (https://github.com/hyperledger/indy-sdk/tree/master/wrappers/ios) being out of date and also my environment not matching the environment for which the readme was written.

animeshdas (Tue, 17 Jul 2018 21:11:19 GMT):
But finally I have managed to resolve everything

animeshdas (Tue, 17 Jul 2018 21:12:05 GMT):
I have compiled the steps I needed to follow in this readme https://github.com/animeshd/Indy-framework-iOS/blob/master/README.md

animeshdas (Tue, 17 Jul 2018 21:13:25 GMT):
how to make the above knowledge available to current and future devs so that they don't have to go through the same problems again?

animeshdas (Tue, 17 Jul 2018 21:13:25 GMT):
I want to make this information available to community, so that current and future devs don't have to go through the same issues that I went through. So whats the best way?

animeshdas (Tue, 17 Jul 2018 21:14:17 GMT):
Also I wanted to give a HUUGGGEEEE thanks to @tomislav, who gave me lot of help and support in figuring out the problems.

kdenhartog (Tue, 17 Jul 2018 21:25:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WYmmisFkeCACGoJ6S) @animeshdas First off thank you! Second, I would suggest adding the new content to the iOS wrapper readme here: https://github.com/hyperledger/indy-sdk/blob/master/wrappers/ios/README.md then make a PR from your fork of the Indy-SDK to the hyperledger repo of the Indy-SDK.

animeshdas (Tue, 17 Jul 2018 21:43:22 GMT):
Also, I have made available an ready-to-use Indy.framework file. For folks, who wanted to get started quickly without having the need to generate Indy.framework from the scratch. https://github.com/animeshd/Indy-framework-iOS Either download it and add to your project, or you if you are already using carthage then just make an entry `github "animeshd/Indy-framework-iOS" "master"` in your cartfile.

animeshdas (Tue, 17 Jul 2018 21:43:22 GMT):
Also, I have made available an ready-to-use Indy.framework file. For folks who wanted to get started quickly without having the need to generate Indy.framework from the scratch. https://github.com/animeshd/Indy-framework-iOS Either download it and add to your project, or if you are already using carthage then just make an entry `github "animeshd/Indy-framework-iOS" "master"` in your cartfile.

stanleyc-trustscience (Tue, 17 Jul 2018 23:21:31 GMT):
Hey all, I've been running into an issue while installing python's indy-sdk wrapper `pip install python3-indy` Gives the following error message `docker-py 1.9.0 has requirement backports.ssl_match_hostname>=3.5, but you'll have backports-ssl-match-hostname 3.4.0.2 which is incompatible.` ``` Could not install packages due to an EnvironmentError: [Errno 13] Permission denied: '/usr/local/lib/python2.7/dist-packages/atomicwrites-1.1.5.dist-info' Consider using the `--user` option or check the permissions. ``` I'm running Ubuntu 16.04

stanleyc-trustscience (Tue, 17 Jul 2018 23:24:15 GMT):
Ubuntu 16.04 only seems to have only version 3.4.0.2 for backports.ssl_match_hostname https://packages.ubuntu.com/search?keywords=python-backports.ssl-match-hostname

dmitry.anansky (Wed, 18 Jul 2018 09:27:31 GMT):
@kdenhartog , @gudkov Please let me know if you figured out any steps I can try to build libindy on macOS

RuWander (Wed, 18 Jul 2018 09:45:18 GMT):
Hi, I am using the how-tos/write_did_and_query_verkey/python file but I am getting this error, can anyone maybe help? ``` 1. Creates a new local pool ledger configuration that is used later when connecting to ledger. 2. Open pool ledger and get handle from libindy 3. Creating new secure wallet _do_call: Function indy_create_wallet returned error 103 Error occurred: ErrorCode.CommonInvalidParam4 ```

DirkT (Wed, 18 Jul 2018 11:23:43 GMT):
Has joined the channel.

DoctorX (Wed, 18 Jul 2018 12:03:21 GMT):
Hi @kdenhartog , I execute the indy-sdk Java sample: Anoncreds.demo() without error. But when I go to node1 to execute the read_ledger script, found there is no new transaction in Ledger, do you know why? I think it should be some records.

DoctorX (Wed, 18 Jul 2018 12:14:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=PaZnw3dqX3H6kTLx3) I don't see the Ledger records for Creates Credential Schema, create Credential Definition, etc, but the suppose be there.

DoctorX (Wed, 18 Jul 2018 12:23:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=AJZymAs4KyaHR5bgW) I use the read_ledger --type domain to check the data

kdenhartog (Wed, 18 Jul 2018 13:07:08 GMT):
@DoctorX im not sure, ill have to check that script today and see if I can figure it out.

Ribas (Wed, 18 Jul 2018 13:09:02 GMT):
Has joined the channel.

n3m (Wed, 18 Jul 2018 13:11:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=BCq5oHsyhEJGTfuDS) @RuWander Seems that the samples are not updated to use the new version of libindy. Certain APIs changed, so you might want to try with a lower version -- maybe 1.4

Dominic (Wed, 18 Jul 2018 14:01:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nb3bzaYCNbz3Qdo8a) for the `--user` error message, I just had to do `sudo pip3.6 install python3-indy` make sure you are using python3.6 as well. The python wrapper doesn't work on python2.7

Dominic (Wed, 18 Jul 2018 14:01:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nb3bzaYCNbz3Qdo8a) for the `--user` error message, if I remember correctly, I just had to do `sudo pip3.6 install python3-indy` make sure you are using python3.6 as well. The python wrapper doesn't work on python2.7

Dominic (Wed, 18 Jul 2018 14:01:33 GMT):
I don't know if that will fix your issue, but it's worth a try

DoctorX (Wed, 18 Jul 2018 14:01:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=db1ab7fb-9c41-4e0a-81eb-b9d565f077bc) @kdenhartog Ok, I will check the code too.

Dominic (Wed, 18 Jul 2018 14:03:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mgHtEtuEjD2gcwrKa) @kdenhartog Okay, the connection setup is something I hadn't considered. I'll have to read up on how that part works. Thanks for all the help :)

dklesev (Wed, 18 Jul 2018 15:05:15 GMT):
Has joined the channel.

ShivKushwah (Wed, 18 Jul 2018 16:41:49 GMT):
Quick Repost : Hi, I'm working on using the indy-sdk for Android and I'm running into problems using the generated libindy.so files. Is there anyone who can help me with this? Thanks!

ShivKushwah (Wed, 18 Jul 2018 16:42:35 GMT):
@stanleyc-trustscience ?

ShivKushwah (Wed, 18 Jul 2018 16:42:52 GMT):
@pimotte ?

stanleyc-trustscience (Wed, 18 Jul 2018 16:57:23 GMT):
@ShivKushwah Hi, I previously attempted to compile libindy.so for different android architecture. I wasn't able to do so. But I think @AxelNennker was actively working on enabling that

ShivKushwah (Wed, 18 Jul 2018 16:57:36 GMT):
He's on vacation :(

stanleyc-trustscience (Wed, 18 Jul 2018 16:57:51 GMT):
I was able to use the iOS wrapper and the binary though

stanleyc-trustscience (Wed, 18 Jul 2018 16:58:03 GMT):
So I switched to iOS

ShivKushwah (Wed, 18 Jul 2018 16:58:25 GMT):
I've generated the .so files successfully, but I'm having trouble figuring out the EXTERNAL_STORAGE environment variable people were talking about earlier

ShivKushwah (Wed, 18 Jul 2018 16:58:48 GMT):
My wrapper is able to load the library, but when I call any methods, it breaks and gives me a null pointer exception

stanleyc-trustscience (Wed, 18 Jul 2018 16:58:50 GMT):
@ShivKushwah Was anyone able to create a indy wallet on android yet?

ShivKushwah (Wed, 18 Jul 2018 16:59:19 GMT):
If you could point me out to someone, that would be great :) I dont know of anyone yet

stanleyc-trustscience (Wed, 18 Jul 2018 16:59:34 GMT):
@ShivKushwah Very cool. Do you mind sharing the instruction to compile the .so files. Maybe I'll join your adventure when I'm free ;)

stanleyc-trustscience (Wed, 18 Jul 2018 17:00:10 GMT):
lol me neither. But you're in need of getting it to work on mobile, you can try iOS. I know many including me have got it working on iphone

ShivKushwah (Wed, 18 Jul 2018 17:03:38 GMT):
If anyone knows someone who can help with, please forward them to me!

ShivKushwah (Wed, 18 Jul 2018 17:03:38 GMT):
If anyone knows someone who can help with this, please forward them to me!

ShivKushwah (Wed, 18 Jul 2018 17:03:39 GMT):
Thanks!

shazzle (Wed, 18 Jul 2018 17:11:15 GMT):
Has joined the channel.

ehs035 (Wed, 18 Jul 2018 17:12:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=SJmKJjmok82BRpgak) @kdenhartog Thanks. Actually I was wrong it is not working. The try catch was swallowing the 307 error message. I did changed the ip address. How do I update my docker file to use it?

tomislav (Wed, 18 Jul 2018 17:37:13 GMT):
What is the timeline for 1.6 release? I'd like to get the dotnet wrappers updated so they get released and tagged along the sdk release.

tomislav (Wed, 18 Jul 2018 17:37:13 GMT):
What is the timeline for 1.6 release? I'd like to get the dotnet wrappers updated, specifically the wallet storage update, so they get released and tagged along the sdk release.

Abhishek_Tyagi (Thu, 19 Jul 2018 04:58:37 GMT):
Hello, I have completed the first part of How-Tos i.e. "write-did-and-query-verkey" in python. But the output is not what I expected. I do not think that ledger is being interrogated at all, since all the DIDs and VERKEYs are blank in output. Could anyone please explain how this is working? 1. Create new pool ledger configuration to connect to ledger. 2. Open ledger and get handle 3. Create new identity wallet 4. Open identity wallet and get handle 5. Generate and store steward DID and verkey Steward DID: Steward Verkey: 6. Generating and storing trust anchor DID and verkey Trust anchor DID: Trust anchor Verkey: 7. Building NYM request to add Trust Anchor to the ledger NYM transaction request: {'identifier': 'Th7MpTaRZVRYnPiabds81Y', 'operation': {'dest': 'KhqQ87d5ibDiQS8YpJJRxa', 'role': '101', 'type': '1', 'verkey': 'BCGkqrRe9ZYKKTfuBBR7avVotXNZmL8PnjNRDHModEkB'}, 'protocolVersion': 2, 'reqId': 1531917207275887047} 8. Sending NYM request to the ledger NYM transaction response: {'op': 'REPLY', 'result': {'auditPath': ['HCa6rb8QhUKGezWvLFtyBuiNacE3zXSNFqwurhHs9azv', 'EsY4hbw8MPXuyQTiq43pvwJqak6pGzfKwJKMXoi6uYS7', 'DNHM372JZJoGcxdHdmsj3QSSiomyeZux6ssJXxAJqyvd'], 'reqSignature': {'type': 'ED25519', 'values': [{'from': 'Th7MpTaRZVRYnPiabds81Y', 'value': '4UjpfTHZp3YcohkQ2EMkAUaxnpZANhdCh6fP3zZaxnDHSBycmtAxjpQU6FRzKnwSt3synfghGzdidD5ZeGmyFBPn'}]}, 'rootHash': 'AJTBhAiZWyQjAupfBLsUaNEokxuj2gwqboanthWB9cKE', 'txn': {'data': {'dest': 'KhqQ87d5ibDiQS8YpJJRxa', 'role': '101', 'verkey': 'BCGkqrRe9ZYKKTfuBBR7avVotXNZmL8PnjNRDHModEkB'}, 'metadata': {'digest': '61a73c6741fdc5f37dfc4dc705cee8d99592764ca3b7dd3fde6a71d05bd2c4fc', 'from': 'Th7MpTaRZVRYnPiabds81Y', 'reqId': 1531917207275887047}, 'protocolVersion': 2, 'type': '1'}, 'txnMetadata': {'seqNo': 12, 'txnId': '219c406f83042609ece8473e8d0544a995d08a042703a6d86ddcbabaa8686408', 'txnTime': 1531917207}, 'ver': '1'}} 9. Generating and storing DID and verkey representing a Client that wants to obtain Trust Anchor Verkey Client DID: Client Verkey: 10. Building the GET_NYM request to query trust anchor verkey GET_NYM request: {'identifier': 'Xd4Sh82ZPTSZYCGU8yQPxV', 'operation': {'dest': 'KhqQ87d5ibDiQS8YpJJRxa', 'type': '105'}, 'protocolVersion': 2, 'reqId': 1531917207521390659} 11. Sending the Get NYM request to the ledger GET_NYM response: {'op': 'REPLY', 'result': {'data': '{"dest":"KhqQ87d5ibDiQS8YpJJRxa","identifier":"Th7MpTaRZVRYnPiabds81Y","role":"101","seqNo":12,"txnTime":1531917207,"verkey":"BCGkqrRe9ZYKKTfuBBR7avVotXNZmL8PnjNRDHModEkB"}', 'dest': 'KhqQ87d5ibDiQS8YpJJRxa', 'identifier': 'Xd4Sh82ZPTSZYCGU8yQPxV', 'reqId': 1531917207521390659, 'seqNo': 12, 'state_proof': {'multi_signature': {'participants': ['Node4', 'Node1', 'Node3'], 'signature': 'R3zk6itzJNVt9MTHJVBPfmApDTfopTHxX5DHH8bU3vzgGmsGp1Vta8jQ2rw2YMdcSqgRaXrpRKk4n2iuYPniCQiro3taaGzgrk3ptospXDSvBV8eGiH3gAaxpdTGm8TkGrhHibmYS4wHCsjzS2fif6P75NXogoTgMBuAkTAz5FR3So', 'value': {'ledger_id': 1, 'pool_state_root_hash': 'n6VPkuHJYFPk6Lnzk6wFKE8HQkwiXvPXfWPb1Xw5zp4', 'state_root_hash': 'KkAnTVCpAEUAYXsXC9ToVZEUkQQTNP2DRX2M6f6cZxH', 'timestamp': 1531917207, 'txn_root_hash': 'AJTBhAiZWyQjAupfBLsUaNEokxuj2gwqboanthWB9cKE'}}, 'proof_nodes': '+QIJ+LOgMZxAb4MEJgns6Ec+jQVEqZXQigQnA6bYbdy6uqhoZAi4kPiOuIx7ImlkZW50aWZpZXIiOiJUaDdNcFRhUlpWUlluUGlhYmRzODFZIiwicm9sZSI6IjEwMSIsInNlcU5vIjoxMiwidHhuVGltZSI6MTUzMTkxNzIwNywidmVya2V5IjoiQkNHa3FyUmU5WllLS1RmdUJCUjdhdlZvdFhOWm1MOFBuak5SREhNb2RFa0IiffkBUaDT0j9uCbFabO0LnyutnB5uDC61QaWLtVTJU4XCa4sWo4Cg06ZNovO7oY+orUhDEtKrVO8pboQRXVi3clzo1hg3EcKgmpq6PvRB/76zSDjdvXO+dATJAmHaV82rEVG2ZoAO+TCAoAIbx/TDY2y4OJtZiJtzVNjJICBQpJ4h68cXrBVl0wEvoEQAggmzS6f2NWpUQAFsJZORzSvJtNWsWBopTosPpyIZgICAoF21RifVmKbW4vphlQr5XtRBsxnVgmRM/tMH2i5PNTIJoCRyJt6FDmJQ60JcPeVA5EXTnNrRiLBPYNq9dgI6SYlCgKB9JVxOO1bVJRb8Jwgua4GPO/Juk6XhGUySCneElMV7aqAb0qE5bnVw9F5IUz5uGMXwnAHQmog75MzPMOjuL+f3taA7Ohl8US/Ipw9m90WNb/7n5LAxzanxSmitjBCIzSGcGoA=', 'root_hash': 'KkAnTVCpAEUAYXsXC9ToVZEUkQQTNP2DRX2M6f6cZxH'}, 'txnTime': 1531917207, 'type': '105'}} 12. Comparing Trust Anchor verkey as written by Steward and as retrieved in GET_NYM response submitted by Client Written by Steward: Queried from ledger: Matching: 13. Closing wallet and pool 14. Deleting created wallet 15. Deleting pool ledger config

LuigiRiva (Thu, 19 Jul 2018 07:23:22 GMT):
Hi team, we are trying to set up the Indy SDK but we still struggling.

LuigiRiva (Thu, 19 Jul 2018 07:23:35 GMT):
Could you please point me out the best practice to do so... ?

LuigiRiva (Thu, 19 Jul 2018 07:30:53 GMT):
.

thPart (Thu, 19 Jul 2018 07:36:10 GMT):
Has joined the channel.

sergey.minaev (Thu, 19 Jul 2018 09:05:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Gog7MerTskn3LbEBx) @tomislav We plan to release 1.6 after https://github.com/hyperledger/indy-sdk/pull/962 will be merged

gudkov (Thu, 19 Jul 2018 09:27:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=snbAkjSn5b28AqDXi) @sergey.minaev @tomislav Planned date is 24 July.

dmitry.anansky (Thu, 19 Jul 2018 10:53:00 GMT):
Seems I am not able to build libindy on UBUNTU as well getting another error: sudo cargo build Compiling indy v1.5.0 (file:///home/ubuntu/indy-test-start/indy-sdk/libindy) error[E0658]: non-reference pattern used to match a reference (see issue #42640) --> src/commands/did.rs:538:24 | 538 | if let Some(data) = &res.data { | ^^^^^^^^^^ help: consider using a reference: `&Some(data)` error[E0658]: non-reference pattern used to match a reference (see issue #42640) --> src/services/pool/networker.rs:133:30 | 133 | .filter(|(_, v)| v.is_orphaned()) | ^^^^^^ help: consider using a reference: `&(_, v)` error[E0658]: non-reference pattern used to match a reference (see issue #42640) --> src/services/wallet/storage/default/mod.rs:238:18 | 238 | Some(Config {path: Some(ref path)}) => std::path::PathBuf::from(path), | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: consider using a reference: `&Config {path: Some(ref path)}` error: aborting due to 3 previous errors error: Could not compile `indy`.

dmitry.anansky (Thu, 19 Jul 2018 10:53:33 GMT):
I followed those instructions : https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md

dmitry.anansky (Thu, 19 Jul 2018 10:54:05 GMT):
any ideas what could go wrong ?

gudkov (Thu, 19 Jul 2018 10:59:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=sSC49quGgwrt2ANcd) @dmitry.anansky You need update Rust to 1.26+ (1.27 is recommended)

dmitry.anansky (Thu, 19 Jul 2018 11:08:48 GMT):
ubuntu@ip-172-31-86-167:~/indy-test-start/indy-sdk/libindy$ rustc -V rustc 1.27.1 (5f2b325f6 2018-07-07) @gudkov already have it

dmitry.anansky (Thu, 19 Jul 2018 11:08:55 GMT):
@gudkov

dmitry.anansky (Thu, 19 Jul 2018 12:15:30 GMT):
result is the same

dmitry.anansky (Thu, 19 Jul 2018 12:15:35 GMT):
:(

gudkov (Thu, 19 Jul 2018 12:35:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9hySqHAshayfrqPMy) @dmitry.anansky The error is 100% related to rust version. I still suggest to re-check your environment. You need to use stable 1.26 or 1.27.

sergey.minaev (Thu, 19 Jul 2018 12:46:03 GMT):
@dmitry.anansky I see one nuance that may be important Here is just ubuntu user: > ubuntu@ip-172-31-86-167:~/indy-test-start/indy-sdk/libindy$ rustc -V But here you use sudo > sudo cargo build

sergey.minaev (Thu, 19 Jul 2018 12:47:13 GMT):
try to `sudo cargo clean` `rustc -V` `cargo build`

sergey.minaev (Thu, 19 Jul 2018 12:47:13 GMT):
try to `sudo cargo clean` `rustc -V` `cargo build` #without sudo

dmitry.anansky (Thu, 19 Jul 2018 13:04:46 GMT):
@sergey.minaev thx, your advice works. I think now I have libindy lib builded.

vtech (Thu, 19 Jul 2018 13:33:06 GMT):
I am running the example with java sdk from here .. https://github.com/hyperledger/indy-sdk/tree/master/samples/java ... it asks for setting up the parameter LD_LIBRARY_PATH=

DoctorX (Thu, 19 Jul 2018 13:56:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=AMTBYQJnb44hwDEXk) Hi @kdenhartog , I checked the code, the demo doesn't send request to Ledger. that's why I don't see data on the Ledger.

DoctorX (Thu, 19 Jul 2018 14:00:13 GMT):
@kdenhartog , Alice can be one of the Indy Agent, then she will be able to send request to write data on Ledger. How does the Alice join the Indy network at the first time? In the get start example, Faber issued her a Transcript , but how Faber join the Indy network?

Sergey.Kupryushin (Thu, 19 Jul 2018 14:02:32 GMT):
Has joined the channel.

kevin.chan (Thu, 19 Jul 2018 14:14:49 GMT):
Has anybody run in to this issue on ubuntu when trying to link from the indy java wrapper to libindy? ``` java.lang.UnsatisfiedLinkError: /usr/lib/libindy.so: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0: version `OPENSSL_1.0.2' not found (required by /usr/lib/libindy.so) ```

kevin.chan (Thu, 19 Jul 2018 14:15:33 GMT):
using libindy v1.4.0

kevin.chan (Thu, 19 Jul 2018 14:15:42 GMT):
installed using apt-get

sergey.minaev (Thu, 19 Jul 2018 14:29:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=LkLrP6aH6Npk9v4So) @vtech DLL is for Windows. If you install libindy on ubuntu from APT you can skip this step as libdiny.so will be available in system path

dklesev (Thu, 19 Jul 2018 15:59:40 GMT):
hi all is there something like explorer for indy?

dmitry.anansky (Thu, 19 Jul 2018 16:39:04 GMT):
Hi all , I am wondering if someone have positive experience installing libindy and indy-sdk on macOs? I was able to made all installation on Ubuntu , but cannot do the same for macOS

tomislav (Thu, 19 Jul 2018 16:41:21 GMT):
NonSecrets fetch records methods says `Not if there are no records this call returns WalletNoRecords error.`. Which error code is this? I wasn't able to find it in mods.rs

animeshdas (Thu, 19 Jul 2018 17:22:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=DBJ9j6ZNTby3Yww5F) @dmitry.anansky Hi @dmitry.anansky I was able to compile libindy on mac, as part of process to generate iOS wrapper. Let me know if you need any help.

animeshdas (Thu, 19 Jul 2018 17:22:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=DBJ9j6ZNTby3Yww5F) Hi @dmitry.anansky I was able to compile libindy on mac, as part of process to generate iOS wrapper. Let me know if you need any help.

tomislav (Thu, 19 Jul 2018 17:39:11 GMT):
Fetch seems to just return null fields if no records found, no error thrown

baconsandwich (Thu, 19 Jul 2018 17:45:13 GMT):
Would you agree that Python has the most mature SDK out of Java, nodejs and Python? Or in other words, which of those three SDKs would you recommend to use for creation of prototypes?

Dominic (Thu, 19 Jul 2018 18:14:36 GMT):
based on my experience, Python

Dominic (Thu, 19 Jul 2018 18:14:36 GMT):
based on my experience: Python

swcurran (Thu, 19 Jul 2018 18:19:15 GMT):
@baconsandwich - depends what you are building. You might want to use the indy-agent repo and bypass the indy-sdk layer. It's still early in that repo, but it's higher level than the indy-sdk. If you do start their, look at the nodejs indy-agent as it is more mature. https://github.com/hyperledger/indy-agent

swcurran (Thu, 19 Jul 2018 18:19:15 GMT):
@baconsandwich - depends what you are building. You might want to use the indy-agent repo and bypass the indy-sdk layer. It's still early in the indy-agent repo, but it's higher level than the indy-sdk. If you do start their, look at the nodejs indy-agent as it is more mature. https://github.com/hyperledger/indy-agent

swcurran (Thu, 19 Jul 2018 18:19:15 GMT):
@baconsandwich - depends what you are building. You might want to use the indy-agent repo and bypass the indy-sdk layer. It's still early in the indy-agent repo, but it's higher level than the indy-sdk. If you do start there, look at the nodejs indy-agent as it is more mature. https://github.com/hyperledger/indy-agent

baconsandwich (Thu, 19 Jul 2018 18:24:35 GMT):
@swcurran but indy-agent only covers the agent part,right? so if I am fine with just configuring the rest without any code adjustments and the client accesses the DL through the agent (as it should be), I should be fine, right?

swcurran (Thu, 19 Jul 2018 18:27:58 GMT):
Yes. There is instructions for bringing up a local ledger for testing - that's von-network for the nodejs indy-agent.

swcurran (Thu, 19 Jul 2018 18:27:58 GMT):
Yes. There are instructions for bringing up a local ledger for testing - that's von-network for the nodejs indy-agent.

swcurran (Thu, 19 Jul 2018 18:28:55 GMT):
You can use any ledger as long as you get the genesis file for that ledger.

swcurran (Thu, 19 Jul 2018 18:30:40 GMT):
And they (BYU) developed a cool demo.

kevin.chan (Thu, 19 Jul 2018 19:13:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=cho3Qy3ynoM5dJsNm) Looks like i was on the wrong linux, GNU instead of Ubuntu, changed that and it works now

Dominic (Thu, 19 Jul 2018 20:11:13 GMT):
I'm not clear on what a revocation registry is, or what a tail reader does. It looks like it's expected to interact with the ledger, but I don't really get what each step does. Can anyone walk me through how a revocable claim is issued and revoked?

arunwij (Fri, 20 Jul 2018 06:11:49 GMT):
Hello everyone, can anyone explain me what is the usage of *setEndpointForDid* method in Indy SDK. Can we set endpoint information

arunwij (Fri, 20 Jul 2018 06:22:33 GMT):
Hello everyone, When an agent makes a connection to another agent for the *first time* => initiator sends a *connection request* to the receiving end, So receiver reply with the response so they can make a secure connection. How can we give the receiving agent the reply URL in the connection request? Can we set it in the DID? Can I use *setEndpointForDid* method in Indy SDK.

arunwij (Fri, 20 Jul 2018 06:22:33 GMT):
Hello everyone, When an agent makes a connection with another agent for the *first time* => initiator sends a *connection request* to the receiving end, So receiver reply with the response so they can make a secure connection. How can we give the receiving agent the reply URL in the connection request? Can we set it in the DID? Can I use *setEndpointForDid* method in Indy SDK.

arunwij (Fri, 20 Jul 2018 06:22:33 GMT):
Hello everyone, When an agent makes a connection with another agent for the *first time*, initiator sends a *connection request* to the receiving end, So receiver reply with the response so they can make a secure connection. How can we give the receiving agent the reply URL in the connection request? Can we set it in the DID? Can I use *setEndpointForDid* method in Indy SDK.

arunwij (Fri, 20 Jul 2018 06:22:33 GMT):
Hello everyone, When an agent makes a connection with another agent for the *first time*, initiator sends a *connection request* to the receiving end, So receiver reply with the *response* so they can make a secure connection. How can we give the receiving agent the reply URL in the connection request? Can we set it in the DID? Can I use *setEndpointForDid* method in Indy SDK.

arunwij (Fri, 20 Jul 2018 06:22:33 GMT):
Hello everyone, When an agent makes a connection with another agent for the *first time*, initiator sends a *connection request* to the receiving end, So receiver reply with the *response* so they can make a secure connection between them. How can we give the receiving agent the reply URL in the connection request? Can we set it in the DID? Can I use *setEndpointForDid* method in Indy SDK.

arunwij (Fri, 20 Jul 2018 06:22:33 GMT):
Hello everyone, When an agent makes a connection with another agent for the *first time*, initiator sends a *connection request* to the receiving end, So receiver reply with the *response* so they can make a secure connection between them. How can we give the receiving agent the *reply URL* in the connection request? Can we set it in the DID? Can I use *setEndpointForDid* method in Indy SDK.

arunwij (Fri, 20 Jul 2018 06:22:33 GMT):
Hello everyone, When an agent makes a connection with another agent for the * first-time*, the initiator sends a *connection request* to the receiving end, So receiver reply with the _response _ so they can make a secure connection between them. How can we give the receiving agent the *reply URL* in the connection request? Can we set it in the DID? Can I use *setEndpointForDid* method in Indy SDK?

vtech (Fri, 20 Jul 2018 06:25:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3rX9rcGjSoGzWhDs8) @sergey.minaev Thanks @sergey.minaev I have tried but JVM crashed this time... test tool IP is configured as 127.0.0.1.. below is the error trace Anoncreds sample -> started # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f77982aac70, pid=5925, tid=5944 # # JRE version: Java(TM) SE Runtime Environment (10.0.2+13) (build 10.0.2+13) # Java VM: Java HotSpot(TM) 64-Bit Server VM (10.0.2+13, mixed mode, tiered, compressed oops, serial gc, linux-amd64) # Problematic frame: # C 0x00007f77982aac70 # # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P" (or dumping to /home/sudip/eclipse-workspace/java/core.5925) # # An error report file with more information is saved as: # /home/sudip/eclipse-workspace/java/hs_err_pid5925.log # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp

pimotte (Fri, 20 Jul 2018 06:40:25 GMT):
@ShivKushwah The nullpointer thing sounds like the library is not actually loaded. Make sure that you have a .so file in the jniLibs folder in the subfolder for the correct architecture

pimotte (Fri, 20 Jul 2018 06:41:02 GMT):
https://github.com/Quintor/StudyBitsWallet/tree/master/app/src/main/jniLibs this is my layout

pimotte (Fri, 20 Jul 2018 06:41:54 GMT):
And https://github.com/Quintor/StudyBitsWallet/blob/master/app/src/main/java/nl/quintor/studybits/studybitswallet/MainActivity.java#L59 and https://github.com/Quintor/StudyBitsWallet/blob/master/app/src/main/java/nl/quintor/studybits/studybitswallet/MainActivity.java#L108 is initialization code

dmitry.anansky (Fri, 20 Jul 2018 08:35:54 GMT):
@animeshdas , @sergey.minaev Maybe you have any ideas why I am getting this error on macOS: cargo build Compiling pkg-config v0.3.9 Compiling error-chain v0.10.0 Compiling toml v0.2.1 Compiling typenum v1.10.0 Compiling unicode-xid v0.1.0 Compiling num-traits v0.2.2 Compiling libc v0.2.40 Compiling cc v1.0.10 Compiling void v1.0.2 Compiling rustc-serialize v0.3.24 Compiling regex v0.2.10 Compiling ucd-util v0.1.1 Compiling lazy_static v1.0.0 Compiling cfg-if v0.1.2 Compiling nodrop v0.1.12 Compiling openssl v0.9.24 Compiling utf8-ranges v1.0.0 Compiling byte-tools v0.2.0 Compiling foreign-types-shared v0.1.1 Compiling unicode-xid v0.0.4 Compiling itoa v0.4.1 Compiling byteorder v1.2.2 Compiling bitflags v0.9.1 Compiling serde v1.0.41 Compiling dtoa v0.4.2 Compiling linked-hash-map v0.4.2 Compiling indy-crypto v0.4.1 Compiling fake-simd v0.1.2 Compiling quote v0.3.15 Compiling indy v1.5.0 (file:///Users/dananskyi/Documents/indy-sdk/libindy) Compiling named_type v0.1.3 Compiling int_traits v0.1.1 Compiling elastic-array-plus v0.9.1 Compiling bitflags v1.0.1 Compiling etcommon-hexutil v0.2.3 Compiling stable_deref_trait v1.0.0 Compiling safemem v0.2.0 Compiling amcl v0.1.2 Compiling lazy_static v0.2.11 Compiling hex v0.2.0 Compiling proc-macro2 v0.3.6 Compiling libsodium-sys v0.0.16 Compiling libsqlite3-sys v0.9.1 Compiling metadeps v1.1.2 Compiling unreachable v1.0.0 Compiling rand v0.4.2 Compiling memchr v2.0.1 Compiling time v0.1.39 Compiling errno v0.2.3 Compiling num-integer v0.1.36 Compiling num-traits v0.1.43 Compiling regex-syntax v0.5.5 Compiling log v0.4.1 Compiling openssl-sys v0.9.28 Compiling foreign-types v0.3.2 Compiling synom v0.11.3 Compiling lru-cache v0.1.1 Compiling owning_ref v0.3.3 Compiling base64 v0.6.0 Compiling etcommon-rlp v0.2.3 Compiling num-complex v0.1.43 error: failed to run custom build command for `libsodium-sys v0.0.16` process didn't exit successfully: `/Users/dananskyi/Documents/indy-sdk/libindy/target/debug/build/libsodium-sys-712d075ec174188f/build-script-build` (exit code: 101) --- stdout cargo:rerun-if-env-changed=SODIUM_LIB_DIR cargo:rerun-if-env-changed=SODIUM_STATIC --- stderr thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "`\"pkg-config\" \"--libs\" \"--cflags\" \"libsodium\"` did not exit successfully: signal: 6\n--- stderr\ndyld: Symbol not found: __cg_png_create_info_struct\n Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n Expected in: /usr/local/lib/libPng.dylib\n in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n"', libcore/result.rs:945:5 note: Run with `RUST_BACKTRACE=1` for a backtrace. warning: build failed, waiting for other jobs to finish... error: build failed

dmitry.anansky (Fri, 20 Jul 2018 08:35:54 GMT):
@animeshdas , @sergey.minaev Maybe you have any ideas why I am getting this error on macOS: cargo build Compiling pkg-config v0.3.9 ...... Compiling num-complex v0.1.43 error: failed to run custom build command for `libsodium-sys v0.0.16` process didn't exit successfully: `/Users/dananskyi/Documents/indy-sdk/libindy/target/debug/build/libsodium-sys-712d075ec174188f/build-script-build` (exit code: 101) --- stdout cargo:rerun-if-env-changed=SODIUM_LIB_DIR cargo:rerun-if-env-changed=SODIUM_STATIC --- stderr thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "`\"pkg-config\" \"--libs\" \"--cflags\" \"libsodium\"` did not exit successfully: signal: 6\n--- stderr\ndyld: Symbol not found: __cg_png_create_info_struct\n Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n Expected in: /usr/local/lib/libPng.dylib\n in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO\n"', libcore/result.rs:945:5 note: Run with `RUST_BACKTRACE=1` for a backtrace. warning: build failed, waiting for other jobs to finish... error: build failed

baconsandwich (Fri, 20 Jul 2018 09:20:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mTZLM7ntw4NCJ8eHP) @swcurran can you help me categorize? I am still very new to indy and found several docker images, e.g. https://github.com/hyperledger/indy-node/tree/master/environment/docker/getting_started_turnkey What would be the advantage of using VON-network instead of the other docker images?

baconsandwich (Fri, 20 Jul 2018 09:22:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=r4FtazqKo88k32Gcm) @swcurran what are you referring here to? demo for a test network?

AxelNennker (Fri, 20 Jul 2018 11:33:35 GMT):
Regarding rustc versions and such: Mozilla uses a python script to check for the correct environment. Maybe we should have something similar to automate version checking. Maybe in build.rs https://dxr.mozilla.org/mozilla-central/source/build/moz.configure/rust.configure

sklump (Fri, 20 Jul 2018 12:17:41 GMT):
Hello folks, there was talk about a month ago about renaming the *master secret* to the *link secret*. Is this still going to happen? I renamed all my references in anticipation, but now it's looking just wrong.

sklump (Fri, 20 Jul 2018 12:21:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=SLZqzahusDzyqXdLX) @Dominic Start here: https://github.com/hyperledger/indy-sdk/blob/master/doc/cred-revocation.md

sklump (Fri, 20 Jul 2018 12:21:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=SLZqzahusDzyqXdLX) @Dominic https://github.com/hyperledger/indy-sdk/blob/master/doc/cred-revocation.md

sklump (Fri, 20 Jul 2018 12:21:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=SLZqzahusDzyqXdLX) @Dominic Start here: https://github.com/hyperledger/indy-sdk/blob/master/doc/cred-revocation.md

sklump (Fri, 20 Jul 2018 12:26:28 GMT):
Hello folks, there was talk about a month ago about renaming the *master secret* to the *link secret*. Is this still going to happen? I renamed all my references in anticipation, but now it's looking just wrong.

sklump (Fri, 20 Jul 2018 12:26:28 GMT):
@sergey.minaev Hello, there was talk about a month ago about renaming the *master secret* to the *link secret*. Is this still going to happen? I renamed all my references in anticipation, but now it's looking just wrong.

swcurran (Fri, 20 Jul 2018 12:37:42 GMT):
@baconsandwich - in the indy-agent repo, nodejs folder, there are instructions and bash scripts for running a demo of the indy-agent using docker that includes starting von-network as a 4-node ledger, and running multiple instances of indy-agent for different personas - Alice, Faber, etc. The BYU team wrote the indy-agent code and web-based agents that you can use to exchange messages and exchange verifiable credentials.

swcurran (Fri, 20 Jul 2018 12:39:11 GMT):
indy-agent embeds indy-sdk and the appropriate wrapper so that instead of just a library, you have code that uses the library to interact with another instance of an agent.

srinivasanraghavan (Fri, 20 Jul 2018 13:22:35 GMT):
I'm very much interested in the deployment architecture of Indy SDK ... Can it be used as a multi-tenant hosted wallet and a PII store with separate Key Management interface which is handled by a cloud HSM . This is use case we are very interested in cases like Indy deployed in nonpublic consortium environment and each participants owning their identity but having a secure way of storage and participants can manage their own keys in Cloud HSM and SDK would have no visible secret keys

gudkov (Fri, 20 Jul 2018 13:45:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=NZnFKGDakJwmRrnYP) @srinivasanraghavan I suggest to read https://github.com/dhh1128/indy-hipe/blob/36d3eddf4213b3a5f4bc9355cd6a645e819b1f31/text/wallets/README.md

baconsandwich (Fri, 20 Jul 2018 14:01:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=PqmwFnwZb9cqASKvN) @swcurran ok, i think i understand, but what does BYU stand for?

baconsandwich (Fri, 20 Jul 2018 14:02:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=FsqmuHCpGMppRHfEK) @swcurran by "embed" you mean "uses the library" of the respective language?

srinivasanraghavan (Fri, 20 Jul 2018 14:06:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=M32YMutcoxQeWPGFp) @gudkov @gudkov I did actually went through this doc and the presentation about this.. I see a section of enclave which generates a wrapper key which would wrap the storage. A curious thing can we do all major key gen activities and encryption activity in a multi tenanted Cloud HSM which can be in the edge . And specifically the DID sign and ver key.. can it be generated in HSM and all encryption and signing activities would take place in the HSM.

n3m (Fri, 20 Jul 2018 14:06:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=irgjYMbyq2iimfhT3) @baconsandwich Here you go: https://byu.edu/

baconsandwich (Fri, 20 Jul 2018 14:07:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=SniE8fg6QXprkDhF4) @n3m thx :)

BreizhIndy (Fri, 20 Jul 2018 14:34:48 GMT):
Hello, I would like as a verifier to keep trace of the proof the user gave me, is there a function to display the proof I got from a specific relationship ? Thanks

baconsandwich (Fri, 20 Jul 2018 14:43:23 GMT):
Is libindy the same as indy-sdk?

gudkov (Fri, 20 Jul 2018 14:45:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ukE6yRgwMcJTfb8BT) @srinivasanraghavan Now you can't store domain secrets in HSM and i am not sure that it will be possible in the future as wallet in libindy is complex and requires complex searches, but it will be possible to store master or wrapper keys with HSM.

gudkov (Fri, 20 Jul 2018 14:46:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=meixCWKRBhNdKWM9Z) @baconsandwich indy-sdk contains libindy, wrappers, cli and libnullpay for now

baconsandwich (Fri, 20 Jul 2018 14:49:28 GMT):
so what is libindy then exactly? the rust implementation?

baconsandwich (Fri, 20 Jul 2018 14:52:54 GMT):
i think i don't understand the scope of the sdk as well, this is why it hard for me to understand. which aspects of indy does indy-sdk cover? just the agent or can i also create ledgers with it, i.e. start genesis transactions. basically, what is the subset of the things that i can do with indy-sdk. let's say I want to create my own instance of the indy framework. can i do everything with indy-sdk or will i have to create the ledger with other tools....?

n3m (Fri, 20 Jul 2018 14:53:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=meixCWKRBhNdKWM9Z) @baconsandwich You can think of `libindy` as a library that exposes low level primitives that allow you to build applications. Wrappers allow you to use that functionality in different languages

n3m (Fri, 20 Jul 2018 14:53:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=meixCWKRBhNdKWM9Z) @baconsandwich You can think of `libindy` as a library that exposes low level primitives that allow you to build applications on top of Indy infrastructure. Wrappers allow you to use that functionality in different languages

baconsandwich (Fri, 20 Jul 2018 14:54:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=oHBtRBAdEizKewmbW) @n3m similar to a ORM framework?

gudkov (Fri, 20 Jul 2018 14:55:37 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=DAnGEsXg7KdjwcZ2L) @baconsandwich No, they don't provide additional abstraction layer. Just exposes C API in python, java, ...

baconsandwich (Fri, 20 Jul 2018 14:58:03 GMT):
any why C? isn't libindy written in Rust?

gudkov (Fri, 20 Jul 2018 14:59:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mJ9Btb56Q48EX43ry) @baconsandwich It isn't important on what language it is written. It is binary library that exposes C compatible API

baconsandwich (Fri, 20 Jul 2018 15:00:56 GMT):
oh ok, thx

baconsandwich (Fri, 20 Jul 2018 15:03:16 GMT):
could you also comment on my previous question regarding what things I can do with indy-sdk? is it just the tasks of an agent or more?

gudkov (Fri, 20 Jul 2018 15:07:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9mKoWKLHD2SN429zq) @baconsandwich libindy is low level library that allows creation of applications based on Indy infrastructure: Access ledger, DID management, Anonymous credentials management, Agent 2 Agent communication basics.

gudkov (Fri, 20 Jul 2018 15:08:07 GMT):
Here is Getting Started Guide that will provide great overview https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md

baconsandwich (Fri, 20 Jul 2018 15:10:51 GMT):
i saw and read this of course but imho it does not really provide an answer to my question (at least in a concise way) from my knowledge if indy it seems to do things that an agent would do but this is never stated explicitly afaics

Dominic (Fri, 20 Jul 2018 15:20:18 GMT):
That's what I assume^ It has all the basic functions that an agent would be able to perform, whether it is an issuer, prover, or verifier. To be fair, I've been focusing on anoncreds, and wallet specifically, so I don't know much about the interaction with ledger aspect.

baconsandwich (Fri, 20 Jul 2018 15:48:17 GMT):
it's a bummer, that there is no clear separation. it would help beginners to partition the new knowledge and build a mental model

baconsandwich (Fri, 20 Jul 2018 15:48:28 GMT):
+structured

Dominic (Fri, 20 Jul 2018 15:56:36 GMT):
how would you separate it?

Dominic (Fri, 20 Jul 2018 15:56:36 GMT):
How would you separate it? (I'm not sure what you mean by clear separation)

Dominic (Fri, 20 Jul 2018 15:56:36 GMT):
How would you separate it? (I'm not sure what you mean by clear separation) Currently the Indy-SDK's API is separated into the following sections: IndyError, anoncreds, blob_storage, crypto, did, ledger, pairwise, pool, wallet

Dominic (Fri, 20 Jul 2018 16:34:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=frfkZyWGyrcd8iHJ6) @sklump Thanks, that doc is super informative!

smithbk (Fri, 20 Jul 2018 16:35:03 GMT):
Is it possible to issue a credential with attribute1 associated with cred_def_id and attribute2 associated with cred_def_id? Or alternatively, is it possible to create a credential schema which inherits from another schema?

smithbk (Fri, 20 Jul 2018 16:35:03 GMT):
Is it possible to issue a credential with attribute1 associated with cred_def_id1 and attribute2 associated with cred_def_id2? Or alternatively, is it possible to create a credential schema which inherits from another schema?

kdenhartog (Fri, 20 Jul 2018 16:36:58 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4G33DaCdET5C98K8b) @DoctorX Thanks for digging into this. I didn't end up having time yesterday. Currently she would be able to write to the ledger by way of a trust anchor (Faber College). In the future, this may be changed but details of it haven't been worked out yet. Faber College (a trust anchor) would have to be added by a Steward or a Trustee I believe.

baconsandwich (Fri, 20 Jul 2018 16:40:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jBPAuERrZebWnzyPQ) @Dominic After reading about the architecture of Indy I have a rough understanding of the elements involved e.g. validator nodes or obeservers, agents working on the ledger, stewards hosting the ledgers. and it is not clear for me which of these roles the SDK can satisfy. I wish there was a statement in the docs that would this clear. after reading indy docs for hours I have no idea was anoncreds, blob_storage etc is. Also I did not find that listing in the README so I would not even know how to see it. This all might become clear after I work with Indy for a while but for a beginner, or at least me, it is hard to understand "oh ok, the SDK will help me with this and this class of tasks but not with this" this is what I mean by separation.

baconsandwich (Fri, 20 Jul 2018 16:40:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jBPAuERrZebWnzyPQ) @Dominic After reading about the architecture of Indy I have a rough understanding of the elements involved e.g. validator nodes or obeservers, agents working on the ledger, stewards hosting the ledgers. and it is not clear for me which of these roles the SDK can satisfy. I wish there was a statement in the docs that would make this clear. after reading indy docs for hours I have no idea what anoncreds, blob_storage etc is. Also I did not find that listing in the README so I would not even know where to look further. This all might become clear after I work with Indy for a while but for a beginner, or at least me, it is hard to understand "oh ok, the SDK will help me with this and this class of tasks but not with this" this is what I mean by separation.

baconsandwich (Fri, 20 Jul 2018 16:46:17 GMT):
and what makes this "worse" is that there are several getting_started guides in each indy-* project often with additional readmes in subfolders and some of them refer to the deprecated CLI getting_started.....I just feel lost.

baconsandwich (Fri, 20 Jul 2018 16:47:13 GMT):
I don't want to complain, just explain what I meant that it would be helpful to have something that would help beginners to organize all the sources mentally and be able to categorize them mentally

sklump (Fri, 20 Jul 2018 16:48:43 GMT):
@baconsandwich It's complicated. Welcome. Now let's talk about elliptic curve cryptography :)

sklump (Fri, 20 Jul 2018 16:48:43 GMT):
@baconsandwich It's complicated. Welcome. https://www.youtube.com/watch?v=lt-udg9zQSE Now let's talk about elliptic curve cryptography :)

ShivKushwah (Fri, 20 Jul 2018 16:53:52 GMT):
@pimotte I figured out my issue, thanks so much!!!! I'm trying to document what I did and see if I can make a PR on the android readme since I think some things need to be documented better

animeshdas (Fri, 20 Jul 2018 16:58:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Bc4WZGNrN8uc7WGTb) @dmitry.anansky @dmitry.anansky make sure that you are using libsodium 1.0.12.

animeshdas (Fri, 20 Jul 2018 16:58:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Bc4WZGNrN8uc7WGTb) @dmitry.anansky make sure that you are using libsodium 1.0.12.

animeshdas (Fri, 20 Jul 2018 16:58:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Bc4WZGNrN8uc7WGTb) @dmitry.anansky make sure that you are using libsodium 1.0.12. Also, run `cargo clean` before you run `cargo build`

baconsandwich (Fri, 20 Jul 2018 17:22:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=xTqXCb3BXS8SXaBgd) @sklump :sweat: :slight_smile:

swcurran (Fri, 20 Jul 2018 17:29:10 GMT):
@smithbk - no, you can't have a credential reference two creddefs at this time. There is talk of implementing an overlay concept for VerCreds that I think was discussed at the recent Amsterdam Hackfest, but I don't know the details. @nage - is there somewhere to look up info on overlays.

Dominic (Fri, 20 Jul 2018 17:39:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=c5S6EbNDqFWenPHjG) @baconsandwich I will concede that It's not too clear. I believe that these roles (validator nodes, agents, steward, trust anchor) are specific to the Sovrin network. I was under the assumption that indy-* projects were independent of any specific ledger implementation, but I do see references to the Sovrin network on indy-agent, so I'm not entirely sure about that. It would be nice if somebody else would be willing to chime-in.

Dominic (Fri, 20 Jul 2018 17:39:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=c5S6EbNDqFWenPHjG) @baconsandwich I will concede that It's not too clear. I believe that these roles (validator nodes, agents, steward, trust anchor) are specific to the Sovrin network. I was under the assumption that indy-* projects were independent of any specific ledger implementation, but I do see references to the Sovrin network on indy-agent, so I'm not entirely sure about that. --> It would be nice if somebody else would be willing to chime-in with additional insight.

MohsenZ (Fri, 20 Jul 2018 18:43:58 GMT):
HI All. We're currently going through the steps of getting a Verinym for a Trustee. We're a little unsure of this step:

MohsenZ (Fri, 20 Jul 2018 18:44:00 GMT):
Steward asks the ledger for the Verification key of Faber's DID by calling did.key_for_did. # Steward Agent faber_verkey = await did.key_for_did(pool_handle, from_wallet, faber_did_info['did'])

MohsenZ (Fri, 20 Jul 2018 18:44:33 GMT):
Is it strange to anyone else that the Steward has access to Faber's wallet? Is this a typo?

mccown (Fri, 20 Jul 2018 19:46:45 GMT):
Yesterday, I pulled the latest indy stable repo and now I am unable to open a pool after I create it. As a simple example, see the Java version of the "Write a DID and Query its Verkey" example (https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/write-did-and-query-verkey/java/README.md). I can create the pool as follows: Pool.createPoolLedgerConfig(poolName, poolConfig).get(); and verify that it exists via the CLI. However, when I try to open it: Pool pool = Pool.openPoolLedger(poolName, "{}").get(); I get a null pointer exception returned from libindy: JNA: Callback org.hyperledger.indy.sdk.pool.Pool$2@3e57cd70 threw the following exception: java.lang.NullPointerException at org.hyperledger.indy.sdk.IndyException.fromSdkError(IndyException.java:53) at org.hyperledger.indy.sdk.IndyJava$API.checkCallback(IndyJava.java:90) at org.hyperledger.indy.sdk.pool.Pool.access$300(Pool.java:20) at org.hyperledger.indy.sdk.pool.Pool$2.callback(Pool.java:68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:520) at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:551) Any thoughts?

smithbk (Fri, 20 Jul 2018 21:09:51 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=uczxuCe6eAjBBzCZg) @swcurran thanks

DoctorX (Fri, 20 Jul 2018 22:29:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WHntnsMfdAbxHNrwx) @kdenhartog So, to setup a new indy network, we have to create a Trustee agent at the very beginning, then this Trustee can create other agent with Steward or Trust Anchor role, then more and more people or organization join the network. The question is how do we create the first Trustee agent, can we use CLI or Indy-sdk to do that?

DoctorX (Fri, 20 Jul 2018 22:44:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aKAxxPFfJhC2fR5RX) @kdenhartog , I checked the Ledger, found the first transaction is *1 {"reqSignature":{},"txn":{"data":{"dest":"V4SGRU86Z58d6TV7PBUe6f","role":"0","verkey":"~CoRER63DVYnWZtK8uAzNbx"},"metadata":{},"type":"1"},"txnMetadata":{"seqNo":1},"ver":"1"}*, and I found it seems be added by *ledger nym did=WnynyXyqjNFXeGELaR81Gh role=TRUSTEE verkey=~XKXdGyymBGos1Hz2JPCEkM* in */indy-node/acceptance/indy-cli-batches/AS-02-01-prepare-DIDs.batch*, but how the DID: WnynyXyqjNFXeGELaR81Gh generated?

DoctorX (Fri, 20 Jul 2018 22:49:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aKAxxPFfJhC2fR5RX) @kdenhartog , I checked the Ledger, found the first transaction is *1 {"reqSignature":{},"txn":{"data":{"dest":"V4SGRU86Z58d6TV7PBUe6f","role":"0","verkey":"~CoRER63DVYnWZtK8uAzNbx"},"metadata":{},"type":"1"},"txnMetadata":{"seqNo":1},"ver":"1"}*, but i don't find where added it.

stanleyc-trustscience (Fri, 20 Jul 2018 23:18:01 GMT):
Anyone has an idea where the wallet and pool folder is on ubuntu?

stanleyc-trustscience (Fri, 20 Jul 2018 23:18:01 GMT):
Anyone has an idea where the wallet folder is on ubuntu?

VitalijReicherdt (Fri, 20 Jul 2018 23:50:36 GMT):
@stanleyc-trustscience /app/.indy_client/wallet

ianco (Sat, 21 Jul 2018 15:36:39 GMT):
Has the python getting_started.py been updated for the lastest sdk/wallet updates (or is this in progress/planned)? For example in getting started the create_wallet() function is given 5 parameters but the wrapper method is not only taking 2 ...

ianco (Sat, 21 Jul 2018 15:50:57 GMT):
^^^ Never mind I found it in one of the outstanding PR's ... :-)

DoctorX (Mon, 23 Jul 2018 01:28:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5JKEEJzFeja7S5TzS) @stanleyc-trustscience For wallet, in Indy CLI, you can use *save wallet* command, then you can see the wallet file path.

DoctorX (Mon, 23 Jul 2018 01:41:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5JKEEJzFeja7S5TzS) @stanleyc-trustscience What do you mean the pool folder?

louie_liu (Mon, 23 Jul 2018 02:32:25 GMT):
Has joined the channel.

BreizhIndy (Mon, 23 Jul 2018 07:33:33 GMT):
~/.indy-client/

rogermartins (Mon, 23 Jul 2018 09:48:38 GMT):
Has joined the channel.

alanz (Mon, 23 Jul 2018 11:26:13 GMT):
Has joined the channel.

nage (Mon, 23 Jul 2018 16:18:49 GMT):
The main work on overlays is being coordinatted on Sovrin slacks #overlay-services channel, there a a couple of Google docs being worked on that should turn into a HIPE PR @swcurran [ ](https://chat.hyperledger.org/channel/indy-sdk?msg=uczxuCe6eAjBBzCZg)

slr (Mon, 23 Jul 2018 17:13:35 GMT):
Hi! I'd like to become a contributor for indy-sdk, any tips/instructions on how to get started?

Dominic (Mon, 23 Jul 2018 17:28:10 GMT):
When verifying a proof of a credential, how can a verifier set up a list of "trusted issuers"? Is there a recommended way of doing this? verifier_verify_proof returns true if it was signed by the cred def issuer (and if the claim is true). For example, how does a verifier check that a drivers' license was signed by a government, and not just anybody "posing" as an issuer?

Dominic (Mon, 23 Jul 2018 17:28:10 GMT):
When verifying a proof of a credential, how can a verifier set up a list of "trusted issuers"? Is there a recommended way of doing this? verifier_verify_proof returns true if it was signed by the cred def issuer (and if the claim is true). For example, how would a verifier check that a drivers' license was signed by a government, and not just anybody "posing" as an issuer?

swcurran (Mon, 23 Jul 2018 17:43:45 GMT):
@Dominic - that is still an exercise left for the implementer at this time. There has not yet been discussion about doing this. I wrote a paper proposing some ideas on that, but there is not any code and the idea has not been really vetted. But it might get you started on thinking about the problem - https://docs.google.com/document/d/1nYq0iakgtyC21oUGWa5hLuJUoKeJFpURtGz6HcLIltY/edit#heading=h.b8ud3xi74tdl

Dominic (Mon, 23 Jul 2018 19:04:15 GMT):
@swcurran So for the time being, what should the verifier do? What variable in the sent proof allows them to know who to trust? I don't find the IssuerDID. Best I can see is the cred_def_id. Should I be using a list of trusted cred_def_ids?

swcurran (Mon, 23 Jul 2018 19:18:58 GMT):
So with the cred_def_id, you can get the cred_def from the Public Ledger. From there, you can get the Issuer of the Cred_Def and that's where you would start on verifying the issuer. How you would do that in a general way - e.g. a standard protocol for doing that - has not yet been defined. On the Indy-Agent calls, we're making progress on setting an interoperable protocol for getting these issues resolved. It's still early though, and we haven't gotten to that one.

Dominic (Mon, 23 Jul 2018 20:01:14 GMT):
The cred def doesn't seem to explicitly declare its issuer. Does that mean there is currently no way to check the public key/DID of the issuer of a credential with indy-sdk at the moment? My goal is just to have a list of trusted issuers, and see if the issuer of a credential is present in that list. Are you saying there is no straightforward way to accomplish this at the moment? If not, is having a list of trusted cred_def_ids a safe alternative? (I would assume yes because the proof verification would fail otherwise)

Dominic (Mon, 23 Jul 2018 20:01:14 GMT):
The cred def doesn't seem to explicitly declare its issuer. Does that mean there is currently no way to check the public key/DID of the issuer of a credential with indy-sdk at the moment? My goal is just to have a list of trusted issuers, and see if the issuer of a credential is present in that list. Are you saying there is currently no straightforward way to accomplish this? If not, is having a list of trusted cred_def_ids a safe alternative? (I would assume yes because the proof verification would fail otherwise)

Dominic (Mon, 23 Jul 2018 20:01:14 GMT):
The cred def doesn't seem to explicitly declare its issuer. Does that mean there is currently no way to check the public key/DID of the issuer of a credential with indy-sdk at the moment? My goal is just to have a list of trusted issuers, and see if the issuer of a credential is present in that list. Are you saying there is currently no straightforward way to accomplish this? Otherwise, is having a list of trusted cred_def_ids a safe alternative?

swcurran (Mon, 23 Jul 2018 20:25:01 GMT):
The answer to your last question is yes. However, it's not ideal in the long run because when a Cred_Def supports revocation, you have to preset the number of Creds to be issued. As a result, there will be multiple Cred_Defs for the same Cred over time. Not a big issue in the short term, but it will be a thing. I just checked our test public ledger at: http://159.89.115.24 - click on the Ledger Domain (Pretty) - http://159.89.115.24/ledger/domain/pretty Look at the DID: 6qnvgJtqwK44D8LFYnV5Yf and transactions 8, 9 and 10. That DID is for an entity ("BC Registries" - a government service). Transaction 8 is the DID being published, 9 is the schema, and 10 is the Cred Def. Note that in 9 and 10, the BC Registries DID is in the transaction. So, I think a DID for the Issuer is in the Cred_Def.

Dominic (Mon, 23 Jul 2018 20:46:54 GMT):
Strange, the formats I get are slightly different (for cred def): _some values shortened for readability_ ``` { "ver": "1.0", "id": "NcYxiDXkpYi6ov5FcYDi1e:3:CL:NcYxiDXkpYi6ov5FcYDi1e:2:canadian_university_transcript:1.0", "schemaId": "NcYxiDXkpYi6ov5FcYDi1e:2:canadian_university_transcript:1.0", "type": "CL", "tag": "tag1", "value": { "primary": { "n": "881822812193876845675...", "s": "67102342566063333...", "rms": "29060958860771...", "r": { "graduation_year": "3837435153727724...", "program": "76558593692900979...", "average": "375197408553279565...", "name": "45944027376870446..." }, "rctxt": "4225587589803...", "z": "4968861307064545..." }, "revocation": { "g": "false 743736FE2C1876 25ED597D6DCC61 ... 95E45DD", "g_dash": "false 40C2BEC07D3446 460C91886074D9 ... 0 0 0 0 0", "h": "false B975A6A423ABCC 90B1F5E91D709B ... 95E45DD", "h0": "false 3191418691BBF B70B6F0135C5A6 ... 95E45DD", "h1": "false C5870565B0A23E 1A4FC2591873B6 ... 95E45DD", "h2": "false BA17DC208430DD FD5F915F3BE7EA ... 95E45DD", "htilde": "false C98798E4A75368 CDEC3D6383845C ... 95E45DD", "h_cap": "false 639D6662344B3 E2667813313B5E ... 0 0 0 0 0", "u": "false 77BB27FD6CCF96 AC5A1A5D1840BD ... 0 0 0 0 0", "pk": "false 66913ED61EE687 A90930ADA7822B ... 95E45DD", "y": "false F63D1DEB08F6A9 EDCA876B17AD7E ... 0 0 0 0 0" } } } ``` Notable differences: "identifier" is just called "id", and the value is `DID:3:` as opposed to just `DID` on your ledger. I'm not using any form of ledger at the moment, as I'm mostly interested in the credential issuance and proofs aspect of the Indy-SDK, so maybe that's changing some of the included data? I'm looking at the cred_def_json cre

Dominic (Mon, 23 Jul 2018 20:46:54 GMT):
Strange, the formats I get are slightly different (for cred def): _some values shortened for readability_ ``` { "ver": "1.0", "id": "NcYxiDXkpYi6ov5FcYDi1e:3:CL:NcYxiDXkpYi6ov5FcYDi1e:2:canadian_university_transcript:1.0", "schemaId": "NcYxiDXkpYi6ov5FcYDi1e:2:canadian_university_transcript:1.0", "type": "CL", "tag": "tag1", "value": { "primary": { "n": "881822812193876845675...", "s": "67102342566063333...", "rms": "29060958860771...", "r": { "graduation_year": "3837435153727724...", "program": "76558593692900979...", "average": "375197408553279565...", "name": "45944027376870446..." }, "rctxt": "4225587589803...", "z": "4968861307064545..." }, "revocation": { "g": "false 743736FE2C1876 25ED597D6DCC61 ... 95E45DD", "g_dash": "false 40C2BEC07D3446 460C91886074D9 ... 0 0 0 0 0", "h": "false B975A6A423ABCC 90B1F5E91D709B ... 95E45DD", "h0": "false 3191418691BBF B70B6F0135C5A6 ... 95E45DD", "h1": "false C5870565B0A23E 1A4FC2591873B6 ... 95E45DD", "h2": "false BA17DC208430DD FD5F915F3BE7EA ... 95E45DD", "htilde": "false C98798E4A75368 CDEC3D6383845C ... 95E45DD", "h_cap": "false 639D6662344B3 E2667813313B5E ... 0 0 0 0 0", "u": "false 77BB27FD6CCF96 AC5A1A5D1840BD ... 0 0 0 0 0", "pk": "false 66913ED61EE687 A90930ADA7822B ... 95E45DD", "y": "false F63D1DEB08F6A9 EDCA876B17AD7E ... 0 0 0 0 0" } } } ``` Notable differences: "identifier" is just called "id", and the value is `DID:3:` as opposed to just `DID` on your ledger. I could just regex the DID part of the identifier, but I don't think that's a secure way to check who issued the cred def. I'm not using any form of ledger at the moment, as I'm mostly interested in the credential issuance and proofs aspect of the Indy-SDK, so maybe that's changing some of the included data? I'm looking at the cred_def_json created from `issuer_create_and_store_credential_def`

Dominic (Mon, 23 Jul 2018 20:50:25 GMT):
Oh and the sample code is for a university transcript (hence the attributes _graduation year, program, average_)

tomislav (Mon, 23 Jul 2018 20:55:30 GMT):
@Dominic You can add restrictions in the credential request. Restrictions can be on cred defs, which are tied to trusted issuers. The `verify` function accepts this request as input, so if any credential supplied doesn't pass this restriction, the verification will fail

Dominic (Mon, 23 Jul 2018 21:03:12 GMT):
That sounds great, do you have a code sample (in any language) of such a restriction being applied on a cred def? I can't seem to find anything in the nodejs wrapper documentation about restrictions.

tomislav (Mon, 23 Jul 2018 21:06:15 GMT):
I just use the SDK source code which is well documented for these things. https://github.com/hyperledger/indy-sdk/blob/2123d8634692edea58f5cf589609762bea18db64/libindy/src/api/anoncreds.rs#L1106

tomislav (Mon, 23 Jul 2018 21:09:02 GMT):
Here's a sample request that uses this restrictions. You can add as many restrictions as you want ``` { "name": "Connection-Identity-Proof-Request", "version": "1.0", "nonce": "0086f6fd-870a-4d73-8a46-b4c3c47f6284", "requested_attributes": { "name.requirement": { "name": "name", "restrictions": [ { "cred_def_id": "Th7MpTaRZVRYnPiabds81Y:3:CL:18:Tag1" } ], "non_revoked": null }, "email.requirement": { "name": "email", "restrictions": [ { "cred_def_id": "Th7MpTaRZVRYnPiabds81Y:3:CL:18:Tag1" } ], "non_revoked": null } }, "requested_predicates": { }, "non_revoked": null } ```

Dominic (Mon, 23 Jul 2018 21:11:28 GMT):
Thanks, I'll be giving that a try tomorrow, and I'll keep you posted :)

swcurran (Mon, 23 Jul 2018 21:32:27 GMT):
@Dominic - our ledger is not up to date :-(. However, the concepts/content have not changed.

stanleyc-trustscience (Mon, 23 Jul 2018 22:49:44 GMT):
@DoctorX Thanks, pool folder is at `~/.indy_client/pool/` on uBuntu. I believe this is where pool config is stored

DoctorX (Tue, 24 Jul 2018 02:26:17 GMT):
Hi @swcurran , regarding Indy Agent Onboarding process, Trust Anchor are created by Trustee or Steward, but how the first Agent(Trustee or Steward) is created when we set up a indy network?

louie_liu (Tue, 24 Jul 2018 02:57:11 GMT):

Clipboard - July 24, 2018 10:56 AM

louie_liu (Tue, 24 Jul 2018 02:57:16 GMT):
Hi all, now I'm trying "Write a DID and Query Its Verkey" in python, I've got the error 308

louie_liu (Tue, 24 Jul 2018 02:58:45 GMT):
But after I changed the code here, then it just came back to step 1 and return error 114...

louie_liu (Tue, 24 Jul 2018 02:58:50 GMT):

Clipboard - July 24, 2018 10:58 AM

louie_liu (Tue, 24 Jul 2018 03:00:09 GMT):
Does anyone know how to fix this?:head_bandage:

louie_liu (Tue, 24 Jul 2018 03:12:57 GMT):
Well I just deleted "await pool.delete_pool_ledger_config(config_name=pool_name)" and it moved on to step 2 and error 308 again:joy:

Gokulraja (Tue, 24 Jul 2018 05:37:05 GMT):
Has joined the channel.

swcurran (Tue, 24 Jul 2018 05:43:38 GMT):
@DoctorX - I'm a little shy on the precise details - I'm not a developer, I just look over their shoulders. However, I think I can point you near to the magic. When setting up a test network, there is a known seed used for the Steward that has Trust Anchor privileges and that allows you to write. On Sovrin or other real network, you would obviously not have this and will have to work with an existing Trust Anchor to either become a Trust Anchor yourself, or to have that Trust Anchor write to the ledger for you. Check out this module in the nodejs indy-agent. The "setupSteward" function has the hard coded value. https://github.com/swcurran/indy-agent/blob/master/nodejs/indy/src/did/index.js

vtech (Tue, 24 Jul 2018 07:19:37 GMT):

Clipboard - July 24, 2018 12:49 PM

vtech (Tue, 24 Jul 2018 07:25:23 GMT):

Clipboard - July 24, 2018 12:55 PM

DoctorX (Tue, 24 Jul 2018 07:28:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ybGvQxrAj9xfNzSQZ) @vtech Check the DEFAULT_POOL_NAME in PoolUtils.java. It should be "sandbox" if you setup the network in dockers.

vtech (Tue, 24 Jul 2018 08:00:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RLbF86v2fyg8Z4cAn) @DoctorX I am not using the PoolUtils class as per example pool ledge is opened with, however have changed the poolName to sandbox(I am using docker) in class WriteDIDAndQueryVerkey.java. It still throws same error ----- String poolName = "sandbox"; String stewardSeed = "000000000000000000000000Steward1"; String poolConfig = "{\"genesis_txn\": \"/home/sudip/Documents/indy-sdk/cli/docker_pool_transactions_genesis\"}"; // Tell SDK which pool you are going to use. You should have already started // this pool using docker compose or similar. System.out.println("\n1. Creating a new local pool ledger configuration that can be used later to connect pool nodes.\n"); Pool.createPoolLedgerConfig(poolName, poolConfig).get(); System.out.println("\n2. Open pool ledger and get the pool handle from libindy.\n"); Pool pool = Pool.openPoolLedger(poolName, "{}").get(); --------------

vtech (Tue, 24 Jul 2018 08:00:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RLbF86v2fyg8Z4cAn) @DoctorX I am not using the PoolUtils class as per example pool ledger is opened with below codebase, however have changed the poolName to sandbox(I am using docker) in class WriteDIDAndQueryVerkey.java. It still throws same error ----- String poolName = "sandbox"; String stewardSeed = "000000000000000000000000Steward1"; String poolConfig = "{\"genesis_txn\": \"/home/sudip/Documents/indy-sdk/cli/docker_pool_transactions_genesis\"}"; // Tell SDK which pool you are going to use. You should have already started // this pool using docker compose or similar. System.out.println("\n1. Creating a new local pool ledger configuration that can be used later to connect pool nodes.\n"); Pool.createPoolLedgerConfig(poolName, poolConfig).get(); System.out.println("\n2. Open pool ledger and get the pool handle from libindy.\n"); Pool pool = Pool.openPoolLedger(poolName, "{}").get(); --------------

vtech (Tue, 24 Jul 2018 08:00:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RLbF86v2fyg8Z4cAn) @DoctorX I am not using the PoolUtils class as per example pool ledger is opened with, however have changed the poolName to sandbox(I am using docker) in class WriteDIDAndQueryVerkey.java. It still throws same error ----- String poolName = "sandbox"; String stewardSeed = "000000000000000000000000Steward1"; String poolConfig = "{\"genesis_txn\": \"/home/sudip/Documents/indy-sdk/cli/docker_pool_transactions_genesis\"}"; // Tell SDK which pool you are going to use. You should have already started // this pool using docker compose or similar. System.out.println("\n1. Creating a new local pool ledger configuration that can be used later to connect pool nodes.\n"); Pool.createPoolLedgerConfig(poolName, poolConfig).get(); System.out.println("\n2. Open pool ledger and get the pool handle from libindy.\n"); Pool pool = Pool.openPoolLedger(poolName, "{}").get(); --------------

DoctorX (Tue, 24 Jul 2018 09:10:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=iQEScoCD5J762MYkD) @vtech Do you check your docker_pool_transactions_genesis is correct?

vtech (Tue, 24 Jul 2018 09:21:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mRhohEpawoaAXePLQ) @DoctorX I have used the indy-sdk/cli/docker_pool_transactions_genesis and changed the default ip to 127.0.0.1, but it is throwing error 'java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.ledger.TimeoutException: Timeout happens for ledger operation.' Docker is running with below--> docker build -f ci/indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9708:9701-9708 indy_pool Below is the first entry in docker_pool_transactions_genesis {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node1","blskey":"4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba","client_ip":"127.0.0.1","client_port":9702,"node_ip":"127.0.0.1","node_port":9701,"services":["VALIDATOR"]},"dest":"Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv"},"metadata":{"from":"Th7MpTaRZVRYnPiabds81Y"},"type":"0"},"txnMetadata":{"seqNo":1,"txnId":"fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62"},"ver":"1"}

vtech (Tue, 24 Jul 2018 09:21:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mRhohEpawoaAXePLQ) @DoctorX I have used the indy-sdk/cli/docker_pool_transactions_genesis and changed the default ip to 127.0.0.1, but it is throwing error 'java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.ledger.TimeoutException: Timeout happens for ledger operation.' Docker is running with below--> docker build -f ci/indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9708:9701-9708 indy_pool {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node1","blskey":"4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba","client_ip":"127.0.0.1","client_port":9702,"node_ip":"127.0.0.1","node_port":9701,"services":["VALIDATOR"]},"dest":"Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv"},"metadata":{"from":"Th7MpTaRZVRYnPiabds81Y"},"type":"0"},"txnMetadata":{"seqNo":1,"txnId":"fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62"},"ver":"1"}

DoctorX (Tue, 24 Jul 2018 09:28:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RPkxhC2CHNuihBjm8) @vtech :innocent:, I have no idea now. I usually use the pool_start.sh to start an indy network.

laurasp (Tue, 24 Jul 2018 09:40:20 GMT):
Has joined the channel.

vtech (Tue, 24 Jul 2018 11:00:04 GMT):
I am trying the write-did-and-query-verkey example using python and but getting the ledger timeout error, indy_pool is up & running _indy_loop_callback: Function returned error 307 Error occurred: ErrorCode.PoolLedgerTimeout

vtech (Tue, 24 Jul 2018 11:00:04 GMT):
I am trying the write-did-and-query-verkey example using python and but getting the ledger timeout error, indy_pool is up & running. Can someone please look into it ? _indy_loop_callback: Function returned error 307 Error occurred: ErrorCode.PoolLedgerTimeout

vtech (Tue, 24 Jul 2018 11:04:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=yxghN2DZa6EDGWass) @louie_liu You should set the protocol version to 2 in pool

vtech (Tue, 24 Jul 2018 11:45:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=BirjXS3yYW7zTuFuG) @DoctorX WHat does pool_start.sh script contains , is this a combination of custom start up commands ?

saikirantyson7 (Tue, 24 Jul 2018 12:50:44 GMT):
Even i am facing the same issue. [IncompatibleProtocolVersion].

saikirantyson7 (Tue, 24 Jul 2018 12:51:28 GMT):
Can anyone help me resolve it? and what versions it is checking and how to bypass it?

vtech (Tue, 24 Jul 2018 12:52:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=dteoNzajRkY897GxW) @saikirantyson7 Please see my above reply, you can set the protocol version to 2

louie_liu (Tue, 24 Jul 2018 13:13:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=khikntAWMES2HJk6R) @vtech Thanks a lot

RuWander (Tue, 24 Jul 2018 13:32:56 GMT):
Can someone maybe help me make sense of the pools and how it would function in a real-world application? Do pools contain all of the nodes in the network or only the nodes that are involved in a transaction? And/or do each node have a separate pool ledger or is it one pool ledger across all nodes? I hope this makes sense and that it is not too stupid of a question.

miranda (Tue, 24 Jul 2018 14:24:47 GMT):
Has joined the channel.

Dominic (Tue, 24 Jul 2018 15:25:13 GMT):
@tomislav Restrictions are working for `requested_attributes` :) but they *don't* seem to be working for requested_predicates. Is this a known issue? ``` proof_req_json = json.dumps( { 'nonce': '120123456789', 'name': 'proof_req_1', 'version': '0.1', 'requested_attributes': { 'attr1_referent': {'name': 'name'} }, 'requested_predicates': { 'predicate1_referent': { 'name': 'average', 'p_type': '>=', 'p_value': 70, "restrictions": [{'cred_def_id': 'a'}], } }, 'non_revoked': {'from': 80, 'to': 100} } ) ``` This is my proof request, but the prover is still able to create a proof, send it, and have it validated by the verifier as "true".

Dominic (Tue, 24 Jul 2018 15:25:13 GMT):
@tomislav Restrictions are working for `requested_attributes` :) but they *don't* seem to be working for requested_predicates. Is this a known issue? ``` proof_req_json = json.dumps( { 'nonce': '120123456789', 'name': 'proof_req_1', 'version': '0.1', 'requested_attributes': { 'attr1_referent': {'name': 'name'} }, 'requested_predicates': { 'predicate1_referent': { 'name': 'average', 'p_type': '>=', 'p_value': 70, 'restrictions': [{'cred_def_id': 'a'}], } }, 'non_revoked': {'from': 80, 'to': 100} } ) ``` This is my proof request. The prover is still able to create a proof, send it, and have it validated by the verifier as "true" (even though none of his credentials come from a cred_def with cred_def_id = 'a').

Dominic (Tue, 24 Jul 2018 15:25:13 GMT):
@tomislav Restrictions are working for `requested_attributes` :) but they *don't* seem to be working for requested_predicates. Is this a known issue? ``` proof_req_json = json.dumps( { 'nonce': '120123456789', 'name': 'proof_req_1', 'version': '0.1', 'requested_attributes': { 'attr1_referent': {'name': 'name'} }, 'requested_predicates': { 'predicate1_referent': { 'name': 'average', 'p_type': '>=', 'p_value': 70, 'restrictions': [{'cred_def_id': 'a'}], } }, 'non_revoked': {'from': 80, 'to': 100} } ) ``` This is my proof request. The prover is still able to create a proof, send it, and have it validated by the verifier as "true" (even though his average does not come from a cred def with cred_def_id = 'a').

marrowdev (Tue, 24 Jul 2018 16:01:52 GMT):
Has joined the channel.

tomislav (Tue, 24 Jul 2018 16:02:08 GMT):
I'm wouldn't know this, perhaps someone from the dev team can help you

tomislav (Tue, 24 Jul 2018 16:02:08 GMT):
I wouldn't know this, perhaps someone from the dev team can help you

swcurran (Tue, 24 Jul 2018 16:05:02 GMT):
Is ">=" supported? I have a vague recollection that only > is working?

sklump (Tue, 24 Jul 2018 16:05:12 GMT):
>= is the only predicate at present

sklump (Tue, 24 Jul 2018 16:05:12 GMT):
`>=` (`GE`) is the only predicate at present

swcurran (Tue, 24 Jul 2018 16:05:57 GMT):
Thanks @sklump. Nevermind what I said.

sklump (Tue, 24 Jul 2018 16:05:59 GMT):
But numeric comparisons are NOT supported in the new credential search

marrowdev (Tue, 24 Jul 2018 16:06:13 GMT):
I'm playing around with the getting started guide in python. For Alice's transcript credential from Faber the JSON document contains both the 'raw' and 'encoded' forms. I'm confused as to which encoding you are using here?

sklump (Tue, 24 Jul 2018 16:07:15 GMT):
@marrowdev everyone asks that. Encoding is application-specific, as long as it can decode and encode reversibly the indy-sdk makes no demands.

sklump (Tue, 24 Jul 2018 16:07:15 GMT):
@marrowdev everyone asks that. Encoding is application-specific, as long as the end-user can decode and encode reversibly the indy-sdk makes no demands. Indy-sdk works on encoded (numeric string) values.

marrowdev (Tue, 24 Jul 2018 16:09:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=FpeiA3Wuy6XLrSxoE) @sklump Makes sense, thanks. Sorry to ask the same question again

sklump (Tue, 24 Jul 2018 16:09:46 GMT):
'sOK, it's what the forum is for.

Dominic (Tue, 24 Jul 2018 16:10:48 GMT):
@marrowdev the encoding used for non-integer attributes is SHA256 converted to decimal

Dominic (Tue, 24 Jul 2018 16:10:48 GMT):
@marrowdev the encoding used for non-integer attributes in the example is SHA256 converted to decimal

marrowdev (Tue, 24 Jul 2018 16:14:18 GMT):
@Dominic Isn't SHA256 one-way though?

Dominic (Tue, 24 Jul 2018 16:17:09 GMT):
I believe so. I didn't know it had to be encoded/decoded reversibly. I just took that information from a comment on this file: https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/issue-credential/java/IssueCredential.java (line 107)

Dominic (Tue, 24 Jul 2018 16:18:09 GMT):
I'm still not sure why encoded values are needed

marrowdev (Tue, 24 Jul 2018 16:19:54 GMT):
@Dominic that looks to be slightly different to the getting started guide. Just to double check i put "Alice" through SHA-256 and that isn't what is used.

marrowdev (Tue, 24 Jul 2018 16:20:52 GMT):
`"first_name": {"raw": "Alice", "encoded": "1139481716457488690172217916278103335"}`

Dominic (Tue, 24 Jul 2018 16:23:00 GMT):
right, I was looking at demo code because the how tos were outdated

Dominic (Tue, 24 Jul 2018 16:23:14 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/tests/demo/test_anoncreds.py

Dominic (Tue, 24 Jul 2018 16:23:14 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/tests/demo/test_anoncreds.py at least there the first one ("male") is decimal(sha256) but "Alex" just seems like random numbers So it looks like for some of the values, they just put in random numbers (or used a different encoding, for some reason)

vtech (Tue, 24 Jul 2018 16:23:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=2bhvRz2XxWetiho5Q) I did fresh set up with stable branch , but getting the PoolLedgerTimeOut, can somebody provide some pointer ? 2. Open pool ledger and get handle from libindy _indy_loop_callback: Function returned error 307 Error occurred: ErrorCode.PoolLedgerTimeout

sklump (Tue, 24 Jul 2018 16:44:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=hxaMu2jdw5knWFXRY) @Dominic The answer is, "don't think about it". Here's one implementation for reference: https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/master/von_anchor/codec.py

sklump (Tue, 24 Jul 2018 16:53:15 GMT):
Notice: anoncreds functions currently return three different kinds of credential blobs. (1) get_credentials_for_proof_request: ``` { "attrs": { "uuid": [ { ```

AxelNennker (Tue, 24 Jul 2018 18:51:56 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=BxEs4DhSzE5rGmZHX) @sklump Would somebody take the time to change the random values to the ones generated by this implementation. Maybe put a link into a comment?! Then send a PR?

ShivKushwah (Tue, 24 Jul 2018 22:31:47 GMT):
Hi, I'm making a PR into the android build setup readme because I believe some of the instructions are missing. Is there any necessary procedures I need to follow, or can I just fork the repo and make a PR?

DoctorX (Wed, 25 Jul 2018 01:02:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=B6QL7xb8DG5w5dgqR) @vtech yes, you can refer to https://github.com/hyperledger/indy-node/blob/stable/environment/docker/pool/StartIndyAgents.md

andrewtan (Wed, 25 Jul 2018 02:38:50 GMT):
Does anyone has issues with installing libsodium on Mac?

andrewtan (Wed, 25 Jul 2018 02:40:04 GMT):

IMG_20180725_103937.jpg

DoctorX (Wed, 25 Jul 2018 03:17:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=gha7hgxMqbfiknyq5) @swcurran Thanks, Stephen. I am reading some doc to try to figure out how to setup a fresh Indy network. One more thing, in https://github.com/hyperledger/indy-sdk/blob/05868745e44634398b56032051e8a516d8621080/doc/getting-started/getting-started.md, the steward use `steward_did_info = {'seed': '000000000000000000000000Steward1'}` to create a did, and then it can signannsubmit the transaction, like this: `nym_request = await ledger.build_nym_request(steward_did, steward_faber_did, steward_faber_key, None, role) await ledger.sign_and_submit_request(pool_handle, steward_wallet, steward_did, nym_request)`. That because there is Steward Agent on the ledger and its NYM DID generated from 000000000000000000000000Steward1, right? And then any DID generated from this seed, will be treat as this Steward Agent, is that correct?

swcurran (Wed, 25 Jul 2018 03:29:21 GMT):
Yes. When you use the seed, the pub/private key pair are repeatable, so that when you have that key, you can write as if you are a Trust Anchor. Cheating Magic, but works for devs.

swcurran (Wed, 25 Jul 2018 03:29:21 GMT):
Yes. When you use the seed, the pub/private key pair are repeatable, so that when you have the keypair, you can write as if you are a Trust Anchor. Cheating Magic, but works for devs.

dungnguyen116 (Wed, 25 Jul 2018 05:31:51 GMT):
`(node:455) UnhandledPromiseRejectionWarning: IndyError: 308 [3] at Object.callback (/root/Hyperledger-Indy-NodeJS/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10) [3] (node:455) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2) [3] POST /api/createPoolLedger - - ms - - `

dungnguyen116 (Wed, 25 Jul 2018 05:31:51 GMT):
` (node:455) UnhandledPromiseRejectionWarning: IndyError: 308 [3] at Object.callback (/root/Hyperledger-Indy-NodeJS/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10) [3] (node:455) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2) [3] POST /api/createPoolLedger - - ms - - `

dungnguyen116 (Wed, 25 Jul 2018 05:31:59 GMT):
anyone can help me ??

pradeeppadmarajaiah (Wed, 25 Jul 2018 05:40:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=bQ7pwrZbeEx9f7YW8) @kdenhartog Thank you .Definitely, I can start working on that part as well. Please let me know, how to getting started on this part

pradeeppadmarajaiah (Wed, 25 Jul 2018 05:44:56 GMT):
I see there is a change in parameters while creating a wallet in updated code. Where can I find the documentation related to the new release. Wallet.createWallet(poolName, walletName, "default", null, walletCredentials).get(); to Wallet.createWallet(issuerWalletConfig, issuerWalletCredentials).get();

kdenhartog (Wed, 25 Jul 2018 06:22:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=fabyk6KwDjwDw8E3k) @pradeeppadmarajaiah Thank you so much for stepping up and offering to help with this! My first suggestion would be to work off of the commands that are called in the Python how-to guides. The command names are very similar and the sdk api calls made should be made in the same order. The main changes that will likely occur between releases will be adding a param here or there and keeping the documentation update to explain whats happening. Since the python one is being kept fairly updated, I'd suggest working off of that for now, and if you have questions drop them in the chat here and someone will help answer them.

DoctorX (Wed, 25 Jul 2018 06:27:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=t64KcrWqZTWn8sprt) @swcurran Yes, I get the same DID value every time when I use the same seed. But I am still not clear how the first Trustee Agent join the indy network. Like we install MS SQL Server, you have to setup a *sa* user. In indy, where to setup the first Trustee? @kdenhartog , do you know?

kdenhartog (Wed, 25 Jul 2018 06:50:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=vCgwY97kodBERQWyA) @DoctorX Through the genesis transaction file. When you setup a pool, the docker image is getting indy-node and doing some setup stuff. Apart of that setup process is loading the pool_genesis_transaction_file and the domain_genesis_transaction_file which is done here for the local pool https://github.com/hyperledger/indy-node/blob/4ecfb358fc88ab44224251b1f0e3a7b14716f5dc/indy_node/pool/local_pool.py

kdenhartog (Wed, 25 Jul 2018 06:51:25 GMT):
@DoctorX in the live pool they were setup using this file https://github.com/sovrin-foundation/launch/blob/master/transactions_live

DoctorX (Wed, 25 Jul 2018 07:33:35 GMT):
@kdenhartog , I use https://github.com/hyperledger/indy-node/blob/4ecfb358fc88ab44224251b1f0e3a7b14716f5dc/environment/docker/pool/pool_start.sh to setup network. On the ledger, the DID for Trustee is *V4SGRU86Z58d6TV7PBUe6f*, the transaction is `{"reqSignature":{},"txn":{"data":{"dest":"V4SGRU86Z58d6TV7PBUe6f","role":"0","verkey":"~CoRER63DVYnWZtK8uAzNbx"},"metadata":{},"type":"1"},"txnMetadata":{"seqNo":1},"ver":"1"}`. But I just found *V4SGRU86Z58d6TV7PBUe6f* in the .batch files under *acceptance/indy-cli-batches* folder. Is these batch files executed when the network is setting up?

DoctorX (Wed, 25 Jul 2018 07:44:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=MPAqPPwM8woC93yix) I don't find *V4SGRU86Z58d6TV7PBUe6f* in https://github.com/sovrin-foundation/launch/blob/master/transactions_live.

DoctorX (Wed, 25 Jul 2018 07:47:37 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=t64KcrWqZTWn8sprt) @swcurran That means, if I get your seed, I can play your role on the ledger. @kdenhartog , is correct?

AxelNennker (Wed, 25 Jul 2018 07:53:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RPbpmR2cjv8ZbTXwG) @ShivKushwah Please remember to sign-off your commits e.g. by using the -s flag to git commit. Otherwise the commits are not accepted. Developer guideslines etc are in the wiki e.g. https://github.com/hyperledger/indy-node#how-to-send-a-pr

baconsandwich (Wed, 25 Jul 2018 08:03:52 GMT):
In the context of pip, what is the difference between indy-sdk (lastest version is 0.0.1.post152) and python3-indy (latest version 1.5.0). Is indy-sdk obsolete?

xnopre (Wed, 25 Jul 2018 08:56:37 GMT):
Has joined the channel.

xnopre (Wed, 25 Jul 2018 09:00:17 GMT):
Hi all :-) . I'm newbie in the indy world, where can I found reference documentation for the API (ruby or other) ? I found some migration guide (for example) in https://github.com/hyperledger/indy-sdk/tree/master/doc, but not the complete API documentation. Thanks :-)

DoctorX (Wed, 25 Jul 2018 09:20:56 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ozL4ByeWB8JjCABf2) @xnopre Welcome to Indy world. You can get start by the following steps: 1. dev setup: https://github.com/hyperledger/indy-node/blob/stable/docs/setup-dev.md 2. Start sandbox Pool and Agencies(Faber, Acme, Thrift), see https://github.com/hyperledger/indy-node/blob/stable/environment/docker/pool/StartIndyAgents.md 3. Try the GetStart Example, see https://github.com/hyperledger/indy-node/blob/stable/getting-started.md Have fun.:blush:

DoctorX (Wed, 25 Jul 2018 09:24:02 GMT):

Clipboard - July 25, 2018 5:23 PM

DoctorX (Wed, 25 Jul 2018 09:24:38 GMT):

Clipboard - July 25, 2018 5:24 PM

DoctorX (Wed, 25 Jul 2018 09:28:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=XYLqrxW3NrhBtvBkR) Hi @kdenhartog , I see the Indy roles as below image. But in the SDK, seems it just support send NYM request with Role: Trustee\Steward\Trust Anchor. What does the "TGB Member" mean? How can I add a new Role?

DoctorX (Wed, 25 Jul 2018 09:29:53 GMT):
:joy:

pradeeppadmarajaiah (Wed, 25 Jul 2018 10:24:36 GMT):
which version of release do i need to use, to run the updated java samples. {release channel} must be replaced with master, rc or stable Pom Points to 1.5.0-dev-625 Also what is the PROTOCOL_VERSION do i need to use. Currently pointng to the value 2=mean 1.4 libindy version

DoctorX (Wed, 25 Jul 2018 10:38:36 GMT):

Clipboard - July 25, 2018 6:38 PM

saikirantyson7 (Wed, 25 Jul 2018 11:27:01 GMT):
I had a doubt. If a DID already exists in the wallet, is it possible to store that DID to a variable?

saikirantyson7 (Wed, 25 Jul 2018 11:27:01 GMT):
I had a doubt. If a DID already exists in the wallet, is it possible to store that DID to a variable? [For example if its something like stewards]

baconsandwich (Wed, 25 Jul 2018 11:46:45 GMT):
Can someone help me troubleshoot the following error message? I am trying to run the samples of the python wrapper . ``` /home/user/project/venv/bin/python /home/user/project/src/getting_started.py INFO:__main__:Getting started -> started INFO:__main__:Open Pool Ledger: pool1 WARNING:indy.libindy:_indy_loop_callback: Function returned error 306 INFO:__main__:============================== INFO:__main__:=== Getting Trust Anchor credentials for Faber, Acme, Thrift and Government == INFO:__main__:------------------------------ INFO:__main__:"Sovrin Steward" -> Create wallet WARNING:indy.libindy:_do_call: Function indy_create_wallet returned error 103 WARNING:indy.libindy:_do_call: Function indy_open_wallet returned error 103 Traceback (most recent call last): File "/home/user/project/src/getting_started.py", line 870, in run_coroutine(run) File "/home/user/project/src/utils.py", line 47, in run_coroutine loop.run_until_complete(coroutine()) File "/usr/lib/python3.6/asyncio/base_events.py", line 468, in run_until_complete return future.result() File "/home/user/project/src/getting_started.py", line 48, in run steward_wallet = await wallet.open_wallet(steward_wallet_config, steward_wallet_credentials) File "/home/user/project/venv/lib/python3.6/site-packages/indy/wallet.py", line 113, in open_wallet open_wallet.cb) indy.error.IndyError: ErrorCode.CommonInvalidParam4 Process finished with exit code 1 ``` Is my assumption correct that `indy.libindy:_do_call: Function indy_create_wallet returned error 103` is an error in the rust implementation and not the python wrapper? And what is a `CommonInvalidParam4`? I am not sure which errors are python errors and which are from the library. Unfortunately I am just starting with Python.

baconsandwich (Wed, 25 Jul 2018 11:54:15 GMT):
OK, I realized the first assumption was wrong, its a python error

xnopre (Wed, 25 Jul 2018 11:55:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wJHRLnaYNnKphD8tX) @DoctorX Thanks for the links that complement those I had. But, to precise my question, I'm searching for "technical reference" document for the API (and/or Python Wrapper) with the list of function, their usage, parameters,...

marrowdev (Wed, 25 Jul 2018 12:11:01 GMT):
I'm getting this error: TRACE|indy::services::pool::pool | src/services/pool/pool.rs:519 | received pool event: Some(NodeReply("{\"identifier\":\"WPrEM6oFsWo689iUCrKRSn\",\"reason\":\"client request invalid: InvalidClientRequest(\'validation error [ClientClaimDefSubmitOperation]: cannot be smaller than 1 (ref=0)\',)\",\"op\":\"REQNACK\",\"reqId\":1532520081616643000}", "Node4")) when I am trying to run these lines of code from the getting started guide in python: ``` # Faber Agent get_schema_request = await ledger.build_get_schema_request(faber_did, transcript_schema_id) get_schema_response = await ledger.submit_request(pool_handle, get_schema_request) (transcript_schema_id, transcript_schema) = await ledger.parse_get_schema_response(get_schema_response) (faber_transcript_cred_def_id, faber_transcript_cred_def_json) = \ await anoncreds.issuer_create_and_store_credential_def(faber_wallet, faber_did, transcript_schema, 'TAG1', 'CL', '{"support_revocation": false}') ``` can anyone shed some light onto the error I'm getting?

marrowdev (Wed, 25 Jul 2018 12:11:01 GMT):
I'm getting this error: TRACE|indy::services::pool::pool | src/services/pool/pool.rs:519 | received pool event: Some(NodeReply("{\"identifier\":\"WPrEM6oFsWo689iUCrKRSn\",\"reason\":\"client request invalid: InvalidClientRequest(\'validation error [ClientClaimDefSubmitOperation]: cannot be smaller than 1 (ref=0)\',)\",\"op\":\"REQNACK\",\"reqId\":1532520081616643000}", "Node4")) when I am trying to run these lines of code from the getting started guide in python: ``` # Faber Agent (faber_transcript_cred_def_id, faber_transcript_cred_def_json) = \ await anoncreds.issuer_create_and_store_credential_def(faber_wallet, faber_did, transcript_schema, 'TAG1', 'CL', '{"support_revocation": false}') cred_def_request = await ledger.build_cred_def_request(faber_did, faber_transcript_cred_def_json) await ledger.sign_and_submit_request(pool_handle, faber_wallet, faber_did, cred_def_request) ``` can anyone shed some light onto the error I'm getting?

swcurran (Wed, 25 Jul 2018 14:14:37 GMT):
@DoctorX - if a seed is used to create a keypair, both the seed and the private key must be protected. In a live operation, a seed would not be used like that - seeds are just used for testing. Same reason you don't see that magic key in the live genesis file - on the real network, there are no backdoors. The keys on the live network for the Nodes and Trustees are all real, and properly protected.

Dominic (Wed, 25 Jul 2018 15:03:14 GMT):
I'm having an issue: My issuer can issue a credential to prover1 with no issues, and prover1 is able to send a proof of that credential to a verifier. However, when I create a new prover (labeled prover2), and prover2 sends a credential request, the credential gets issued properly, but when comes time for the verifier to verify a proof of prover2's credentials, it returns false. Any idea what I'm doing wrong?

tomislav (Wed, 25 Jul 2018 15:31:11 GMT):
Did you try enabling tracing to get an clue? Add environment variable RUST_LOG=trace to your process @Dominic

tomislav (Wed, 25 Jul 2018 15:31:11 GMT):
Did you try enabling tracing to get a clue of what's doing on? Add environment variable RUST_LOG=trace to your process @Dominic

Dominic (Wed, 25 Jul 2018 16:07:51 GMT):
It didn't really help; I couldn't find any messages that provided an explanation of why it returned false. Maybe the answer is somewhere in the massive json objects that are output to the terminal, but I didn't find anything after searching for quite a while.

Dominic (Wed, 25 Jul 2018 16:10:30 GMT):
Just to make sure the problem is not at the issuer level, I am allowed to reuse the same cred def multiple times, right? I've been assuming so since I've been setting `{"max_cred_num": 5}` on the revoc_reg

swcurran (Wed, 25 Jul 2018 18:47:18 GMT):
Question for the indy-sdk team (maybe @esplinr?). AFAIK The term "master secret" has given way to "link secret" in most discussions about Indy and I thought it had changed in the indy-sdk. I'm hearing now that "master secret" is still used in the indy-sdk code base (or perhaps in the python wrapper?). We've changed our stuff to "link secret", but want to stay aligned with Indy. What's it going to be in the future? Thanks!

Dominic (Wed, 25 Jul 2018 20:00:45 GMT):
Unrelated question: What happens when I don't reveal a requested attribute? Suppose I send my name (string), and set revealed=False, what does that prove to the receiver? That I have a name that follows all the restrictions that are set on that attribute? As a verifier, is there a way for me to request that the user reveal their attributes?

tomislav (Wed, 25 Jul 2018 23:09:22 GMT):
@Dominic It proves you have own the credential, but don't want to reveal that attribute. For example your SSN, it may be relevant to the verifier that your credential has this attribute, because, for example, a KYC issuer gave you credential for this, but you don't want to show this to the verifier.

PeterX (Thu, 26 Jul 2018 01:55:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=MPAqPPwM8woC93yix) @DoctorX @DoctorX , you can check here: client_for_pool_start.sh -> client_build.sh -> client.ubuntu.dockerfile -> generate_indy_pool_transactions -> TestNetworkSetup.bootstrapTestNodes -> trustee_def = cls.gen_trustee_def(1) -> d.sigseed = cls.getSigningSeed(d.name)

DoctorX (Thu, 26 Jul 2018 02:19:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=7cMAZ344hS639NAdB) @xnopre you can get start from here: https://github.com/hyperledger/indy-node/tree/master/docs https://github.com/hyperledger/indy-sdk/tree/master/doc

PeterX (Thu, 26 Jul 2018 02:27:28 GMT):
hi, all, I'm trying to use new indy-cli("https://github.com/hyperledger/indy-sdk/tree/master/cli"), but I found it cannot connect to the node pool, but the old cli can connect the node pool, Is there some config for the new indy-cli that I missed?

PeterX (Thu, 26 Jul 2018 02:27:37 GMT):

Clipboard - July 26, 2018 10:27 AM

DoctorX (Thu, 26 Jul 2018 02:27:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=MGsQYKXjHMHL5kryz) @swcurran What can I do if someone already get my seed in live network?

PeterX (Thu, 26 Jul 2018 02:27:59 GMT):

Clipboard - July 26, 2018 10:27 AM

PeterX (Thu, 26 Jul 2018 02:29:54 GMT):
Or anyone know where is the log file location of the indy-cli in SDK?

swcurran (Thu, 26 Jul 2018 02:47:44 GMT):
@anderx - you can rotate your key - update your DID with the public key of a new keypair that you generate from a new seed. That is the same action to take if your private key is compromised.

DoctorX (Thu, 26 Jul 2018 03:14:21 GMT):
Thanks, Stephen, I will check how to rotate the key.

DoctorX (Thu, 26 Jul 2018 03:14:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ozk2NP6j8bBF3XQmq) @swcurran Thanks, Stephen, I will check how to rotate the key.

DoctorX (Thu, 26 Jul 2018 03:19:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=EWuLekhdcsPbMNhZg) @PeterX Peter, it's called generate_indy_pool_transactions in node.init.ubuntu.dockerfile while the pool_start.sh execute. That why I don't execute the client_for_pool_start.sh but the Trustee1 is already on the Ledger. I may check how to setup the first Trustee in the live network. @swcurran , @kdenhartog , FYI.

PeterX (Thu, 26 Jul 2018 03:24:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=zvFXrRABXx9969bey) @DoctorX :grinning:, got it, that's correct

PeterX (Thu, 26 Jul 2018 03:24:39 GMT):
@DoctorX , BTW, please do not change your name again and again

DoctorX (Thu, 26 Jul 2018 03:25:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=a9swStwCF3QYQyTK4) @PeterX no, this is first time

PeterX (Thu, 26 Jul 2018 03:31:42 GMT):
hi, all, I'm trying to use new indy-cli("https://github.com/hyperledger/indy-sdk/tree/master/cli"), but I found it cannot connect to the node pool, but the old cli can connect the node pool, Is there some config for the new indy-cli that I missed?

PeterX (Thu, 26 Jul 2018 03:31:57 GMT):

Clipboard - July 26, 2018 11:31 AM

AvikHazra (Thu, 26 Jul 2018 09:34:11 GMT):
hello, how to handle openWallet ? sometime when the wallet is already open from somewhere its throws WalletAlreadyOpenedError. I checked if I closeWallet, every time it generate new walletHandle(wh). Can it be a problem ? What will be the best way to handle WalletAlreadyOpenedError exception ? Can anyone please help me ?

pimotte (Thu, 26 Jul 2018 09:43:01 GMT):
@AvikHazra Best way is to make sure you do proper resource management and close the wallet when you're done with it. If you need to access an open wallet from multiple places in your code, perhaps a singleton can help out

AvikHazra (Thu, 26 Jul 2018 09:47:45 GMT):
@pimotte thanks, every time when i closeWallet and after that openWallet its generate new walletHandle(wh). Can it be a problem ?

pimotte (Thu, 26 Jul 2018 09:51:57 GMT):
That's expected behaviour. I guess it could be a problem under very high load, but for normal usage, this is something you should be able to do

AvikHazra (Thu, 26 Jul 2018 09:54:47 GMT):
yes.. Thank You :)

PeterX (Thu, 26 Jul 2018 10:37:13 GMT):
@anikitinDSR , hello, I have read the document(https://github.com/hyperledger/indy-node/blob/master/docs/pool-upgrade.md), but I also want to know how to use node_control_tool, is there any document of the steps or example about how to use the node_control_tool?

anikitinDSR (Thu, 26 Jul 2018 10:37:13 GMT):
Has joined the channel.

anikitinDSR (Thu, 26 Jul 2018 10:53:13 GMT):
Hello, @PeterX . node_control_tool is a daemon which starts with indy-node. There is 2 services, when node is running, indy-node.service and indy-node-control.service (you can find it in /etc/systemd/system after indy-node install). node_control_tool it's like supervisor. The main purpose of this is to supply upgrade procedure for node. It's just wait a command from indy-node service to activating upgrade procedure and perform it then. If you want to upgrade the pool, you just need to send POOL_UPGRADE transaction from indy-cli. For example, if you are using indy-cli based on indy-sdk, you can look at https://github.com/hyperledger/indy-sdk/tree/master/doc/design/001-cli#pool_upgrade-transaction

PeterX (Thu, 26 Jul 2018 11:08:03 GMT):
@anikitinDSR , thanks for your response, let me describe my understanding, the node pool upgrade process should be: send POOL_UPGRADE from indy-cli -> indy-node service -> indy-node-control.service -> node_control_tool(The python script that will do the upgrade indy node job), Is this correct?

anikitinDSR (Thu, 26 Jul 2018 11:31:28 GMT):
@PeterX , yes. The workflow is: 1. Send a POOL_UPGRADE transaction with action=start and schedule= 2. Pool write this txn into config-ledger and schedule upgrade procedure for time from 'schedule' param from txn and then send to node_control_tool (through local socket) command to upgrade. 3. After this, node_control_tool will try backup, install corresponded version, call migration script and restart indy-node. service. Please note, that all the logs from indy-control-tool you can find into journalctl

PeterX (Thu, 26 Jul 2018 11:35:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=SKw8hqHZMZg8F8R6c) @anikitinDSR Got it, thanks a lot, I will try it later!

LeHieu (Thu, 26 Jul 2018 12:04:26 GMT):
Has joined the channel.

PeterX (Thu, 26 Jul 2018 12:27:53 GMT):
hi, all, I have connected my localpool with new indy-cli successfully, when I try to upgrade my node pool, I found there is a required param "sha256 - Sha256 hash of the package.", Is anyone know how to get the sha256 of a package?

sklump (Thu, 26 Jul 2018 14:14:43 GMT):
Operating on indy-sdk-1.5.0-dev-635, I send it into a rust panic when I call `anoncreds.prover_get_credentials_for_proof_req()` on a proof request on `requested_attributes` specifications on attributes restricted to one cred def id but a `requested_predicates` specifying a minimum value for an attribute from another cred def id. I'm just recompiling indy-sdk-1.5.0-dev-651 and will update if it fixes the issue. It worked fine before the indy-sdk series that allowed WQL search on wallet credentials.

sklump (Thu, 26 Jul 2018 14:14:43 GMT):
Operating on indy-sdk-1.5.0-dev-635, I send it into a rust panic when I call `anoncreds.prover_get_credentials_for_proof_req()` for a proof request on `requested_attributes` specifications on attributes restricted to one cred def id but a `requested_predicates` specifying a minimum value for an attribute from another cred def id. I'm just recompiling indy-sdk-1.5.0-dev-651 and will update if it fixes the issue. It worked fine before the indy-sdk series that allowed WQL search on wallet credentials.

sklump (Thu, 26 Jul 2018 14:14:43 GMT):
Operating on indy-sdk-1.5.0-dev-651, I send it into a rust panic when I call `anoncreds.prover_get_credentials_for_proof_req()` for a proof request on `requested_attributes` specifications on attributes restricted to one cred def id but a `requested_predicates` specifying a minimum value for an attribute from another cred def id. It worked fine before the indy-sdk series that allowed WQL search on wallet credentials. Offensive proof request follows. ``` { "name": "proof_req", "version": "0.0", "nonce": "1532615113", "requested_attributes": { "16_legalName_uuid": { "name": "legalName", "non_revoked": { "to": 1532615103, "from": 1532615103 }, "restrictions": [ { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:16:0" } ] } }, "requested_predicates": { "15_jurisdictionId_uuid": { "name": "jurisdictionId", "restrictions": [ { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:15:0" } ], "non_revoked": { "to": 1532615103, "from": 1532615103 }, "p_value": 1, "p_type": ">=" } } } ``` With RUST_LOG=debug, RUST_BACKTRACE=full, output follows: ``` DEBUG|indy::commands::anoncreds::prover| src/commands/anoncreds/prover.rs:463 | get_credentials_for_proof_req >>> wallet_handle: 69, proof_req_json: "{\"requested_attributes\": {\"16_legalName_uuid\": {\"non_revoked\": {\"to\": 1532615426, \"from\": 1532615426}, \"restrictions\": [{\"cred_def_id\": \"WgWxqztrNooG92RXvxSTWv:3:CL:16:0\"}], \"name\": \"legalName\"}}, \"nonce\": \"1532615441\", \"version\": \"0.0\", \"name\": \"proof_req\", \"requested_predicates\": {\"15_jurisdictionId_uuid\": {\"p_type\": \">=\", \"non_revoked\": {\"to\": 1532615426, \"from\": 1532615426}, \"restrictions\": [{\"cred_def_id\": \"WgWxqztrNooG92RXvxSTWv:3:CL:15:0\"}], \"name\": \"jurisdictionId\", \"p_value\": 1}}}" DEBUG|indy::commands::anoncreds::prover| src/commands/anoncreds/prover.rs:779 | _query_requested_credentials >>> wallet_handle: 69, query_json: "{\"attr::legalname::marker\":\"1\",\"$or\":[{\"cred_def_id\":\"WgWxqztrNooG92RXvxSTWv:3:CL:16:0\"}]}", predicate_info: None DEBUG|indy::commands::anoncreds::prover| src/commands/anoncreds/prover.rs:787 | _query_requested_credentials <<< credentials: [RequestedCredential { cred_info: CredentialInfo { referent: "af6b0157-c4bc-49d7-8af0-a0cc66323993", attrs: {"legalName": "Tart City", "sriRegDate": "2018-07-26", "jurisdictionId": "1"}, schema_id: "WgWxqztrNooG92RXvxSTWv:2:sri:1.0", cred_def_id: "WgWxqztrNooG92RXvxSTWv:3:CL:16:0", rev_reg_id: Some("WgWxqztrNooG92RXvxSTWv:4:WgWxqztrNooG92RXvxSTWv:3:CL:16:0:CL_ACCUM:0"), cred_rev_id: Some("2") }, interval: Some(NonRevocedInterval { from: Some(1532615426), to: Some(1532615426) }) }] DEBUG|indy::commands::anoncreds::prover| src/commands/anoncreds/prover.rs:779 | _query_requested_credentials >>> wallet_handle: 69, query_json: "{\"attr::jurisdictionid::marker\":\"1\",\"$or\":[{\"cred_def_id\":\"WgWxqztrNooG92RXvxSTWv:3:CL:15:0\"}]}", predicate_info: Some(PredicateInfo { name: "jurisdictionId", p_type: GE, p_value: 1, restrictions: Some(Array([Object({"cred_def_id": String("WgWxqztrNooG92RXvxSTWv:3:CL:15:0")})])), non_revoked: Some(NonRevocedInterval { from: Some(1532615426), to: Some(1532615426) }) }) ERROR|panic |/home/sklump/.cargo/registry/src/github.com-1ecc6299db9ec823/log-panics-2.0.0/src/lib.rs:67 | thread 'unnamed' panicked at 'no entry found for key': libcore/option.rs:914 ```

sklump (Thu, 26 Jul 2018 14:55:51 GMT):
In particular, operation gets to this line and crashes on it: https://github.com/hyperledger/indy-sdk/blob/2f28ac36f807a2cff9b655c58caaf457db6c944d/libindy/src/commands/anoncreds/prover.rs#L785

gudkov (Thu, 26 Jul 2018 14:56:05 GMT):
@sklump Could you create ticket in Jira

gudkov (Thu, 26 Jul 2018 14:56:05 GMT):
@sklump Could you create ticket in Jira?

sklump (Thu, 26 Jul 2018 14:56:15 GMT):
Sure thing

sklump (Thu, 26 Jul 2018 14:56:15 GMT):
Sure thing: https://jira.hyperledger.org/browse/IS-840

bdeva (Thu, 26 Jul 2018 15:12:28 GMT):
credential offer

bdeva (Thu, 26 Jul 2018 15:33:42 GMT):
A question regarding credential offers and I'm not sure if this is the right forum for this: When creating credential offers, they are bound to their credential definition id. However there is no sort of unique credential offer id which describes the specific credential offer, especially when receiving an credential request by the other side. Looping through all pending credential offers does not work if multiple credential offers are created for the same credential definition (say having to customers at the same time). Maybe the creation of a (temporary) credential offer id could solve this issue. I see that also the reference implementation at indy-agent has the same issue, which does not scale for more then two credential offers at the same time. Or am I missing something?

bdeva (Thu, 26 Jul 2018 15:33:42 GMT):
A question regarding credential offers and I'm not sure if this is the right forum for this: When creating credential offers, they are bound to their credential definition id. However there is no sort of unique credential offer id which describes the specific credential offer, especially when receiving an credential request by the other side. Looping through all pending credential offers does not work if multiple credential offers are created for the same credential definition (say having two customers at the same time). Maybe the creation of a (temporary) credential offer id could solve this issue. I see that also the reference implementation at indy-agent has the same issue, which does not scale for more then two credential offers at the same time. Or am I missing something?

bdeva (Thu, 26 Jul 2018 15:33:42 GMT):
A question regarding credential offers and I'm not sure if this is the right forum for this: When creating credential offers, they are bound to their credential definition id. However there is no sort of unique credential offer id which describes the specific credential offer, especially when receiving an credential request by the other side. Looping through all pending credential offers does not work if multiple credential offers are created for the same credential definition (say having two customers at the same time). Maybe the creation of a (temporary) credential offer id could solve this issue. I see that also the reference implementation at indy-agent has the same issue, which does not scale for more than two credential offers at the same time. Or am I missing something?

vladan.divac (Thu, 26 Jul 2018 15:45:34 GMT):
Has joined the channel.

sarveshgupta89 (Thu, 26 Jul 2018 17:59:47 GMT):
Has joined the channel.

andrewtabit (Thu, 26 Jul 2018 18:05:01 GMT):
Has joined the channel.

andrewtabit (Thu, 26 Jul 2018 18:06:57 GMT):
hi everyone! Just joined. I get IndyError: PoolLedgerTimeout when connecting to Sovrin Sandbox Network using https://github.com/sovrin-foundation/sovrin/blob/stable/sovrin/pool_transactions_sandbox_genesis. Is this channel the right place to add a question about Sovrin Sandbox Network?

Dominic (Thu, 26 Jul 2018 19:35:06 GMT):
how do I find what indy-sdk version I'm on?

mgbailey (Thu, 26 Jul 2018 21:26:33 GMT):
@Dominic from the command line, type this: "dpkg -l | grep indy"

DuckLover (Thu, 26 Jul 2018 21:33:40 GMT):
Has joined the channel.

DuckLover (Thu, 26 Jul 2018 21:34:26 GMT):
Hi everybody, im new to indy and tried to setup the environment but got some bugs. Am i missing something

DuckLover (Thu, 26 Jul 2018 21:34:29 GMT):
https://stackoverflow.com/questions/51536879/proper-indy-setup-with-docker

mgbailey (Thu, 26 Jul 2018 23:32:41 GMT):
Is it possible to include metadata in a cred def transaction written to the ledger using the python wrapper? Is there an example?

mohitgajera (Fri, 27 Jul 2018 06:54:50 GMT):
what is the difference between indy-node and indy-sdk? All other indy-* projects may collapse into this one, *except for indy-sdk*. why?

pimotte (Fri, 27 Jul 2018 06:56:34 GMT):
indy-sdk is basically the client to indy-node, so all the other parts are needed to run a node, but you don't need all of it to use indy as a client

AvikHazra (Fri, 27 Jul 2018 12:54:22 GMT):
Hello, UnhandledPromiseRejectionWarning: IndyError: 213

AvikHazra (Fri, 27 Jul 2018 12:57:06 GMT):
hello, when I`m trying to create pairwise (createPairwise), its throwing UnhandledPromiseRejectionWarning: IndyError: 213 exception. Can anyone please help me ? For what this error occur ?

pimotte (Fri, 27 Jul 2018 12:58:12 GMT):
213 corresponsd to WalletItemAlreadyExists

pimotte (Fri, 27 Jul 2018 12:58:51 GMT):
I have had this issue, and I switched to the WalletRecord API for storing pairwise relations

smithbk (Fri, 27 Jul 2018 13:09:59 GMT):
To add a DID with a trust anchor role to the ledger, I use ```ledger.build_nym_request(myDID, did, key, None, "TRUST_ANCHOR") ledger.sign_and_submit_request``` Is there a way to write it to the ledger without a role and then later add the "TRUST_ANCHOR" role? Thanks

sklump (Fri, 27 Jul 2018 13:13:40 GMT):
One thing I would like to see in the Wallet search API, or perhaps someone is very clever with WQL: how to get all cred-def-ids (or schema-ids, rev-reg-ids, etc.) from my wallet? I don't want all the credentials, but getting one (arbitrary) credential (info) per cred_def_id would suffice, so I could pull out its identifiers (schema-id, cred-def-id, rev-reg-id, ...). I might have a hundred thousand credentials on a couple of schema-ids (e.g., drivers licences, transcripts) and I don't need all the creds, just the schema ids (for example). Basically I would love an equivalent to SQL UNIQUE. Anyone have an idea how this might be possible? _update: it came to me last night, so simple: the caller doesn't *have* to finish the fetching through the end; the caller can set a chunk size of 1 and WQL akin to `{'$cred_def_id': ...}`, then stop after 1 iteration and see if there is a result._

sklump (Fri, 27 Jul 2018 13:59:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qbPu4zRq83BeyP8ns) @smithbk My guess is to write an empty string, then call it again with `TRUST_ANCHOR`. `ledger.py`: ``` async def build_nym_request(submitter_did: str, target_did: str, ver_key: Optional[str], alias: Optional[str], role: Optional[str]) -> str: """ Builds a NYM request. :param submitter_did: DID of the submitter stored in secured Wallet. :param target_did: Target DID as base58-encoded string for 16 or 32 bit DID value. :param ver_key: Target identity verification key as base58-encoded string. :param alias: NYM's alias. :param role: Role of a user NYM record: null (common USER) TRUSTEE STEWARD TRUST_ANCHOR empty string to reset role :return: Request result as json. """ ```

sklump (Fri, 27 Jul 2018 13:59:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qbPu4zRq83BeyP8ns) @smithbk My guess is to build nym request with null on creation, then call again with empty string, then call again with `TRUST_ANCHOR`. `ledger.py`: ``` async def build_nym_request(submitter_did: str, target_did: str, ver_key: Optional[str], alias: Optional[str], role: Optional[str]) -> str: """ Builds a NYM request. :param submitter_did: DID of the submitter stored in secured Wallet. :param target_did: Target DID as base58-encoded string for 16 or 32 bit DID value. :param ver_key: Target identity verification key as base58-encoded string. :param alias: NYM's alias. :param role: Role of a user NYM record: null (common USER) TRUSTEE STEWARD TRUST_ANCHOR empty string to reset role :return: Request result as json. """ ```

baconsandwich (Fri, 27 Jul 2018 18:29:28 GMT):
Does the current indy-sdk (master branch on GitHub) work with libindy 1.5.0? I am getting bugs and I am not sure if this is the reason. Afaics the debian repo only contains 1.5.0 so I wonder whether I should build libindy from source.

baconsandwich (Fri, 27 Jul 2018 18:30:38 GMT):
Afaics the most current version of libindy is 1.6.0

smithbk (Sat, 28 Jul 2018 01:26:43 GMT):
@sklump Thanks

smithbk (Sat, 28 Jul 2018 01:39:59 GMT):
I have a scenario in which there are a large number of issuers of a credential associated with a single schema. If the requirement in the proof request has a single "schema_key" comparison, is it possible to get the cred def ID from the proof? I need to make sure that the proof was generated by one of my legitimate issuers. Thanks

tomislav (Sat, 28 Jul 2018 02:10:13 GMT):
Is the pairwise api getting the same love as credentials did with search and tags support?

marksta (Sat, 28 Jul 2018 12:51:30 GMT):
Has joined the channel.

andrewtan (Sun, 29 Jul 2018 03:10:43 GMT):
Hi, I was following the instructions on the page "https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md". While doing so, I run into issues whereby the brew install for zeromq, zmq and libsodium are not linked. How can I resolve this? Trying to get my hands around indy-sdk. Thanks.

leondcastle (Sun, 29 Jul 2018 03:44:38 GMT):
Has joined the channel.

br3nt (Mon, 30 Jul 2018 02:55:46 GMT):
Has joined the channel.

br3nt (Mon, 30 Jul 2018 02:55:53 GMT):
testnet

br3nt (Mon, 30 Jul 2018 02:56:33 GMT):
Hi, Is there a testnet we can connect to? Also are there instructions on how to connect and interact with it?

JacquesFourie (Mon, 30 Jul 2018 03:19:46 GMT):
Has joined the channel.

swoolcock (Mon, 30 Jul 2018 03:24:07 GMT):
Has joined the channel.

mohitgajera (Mon, 30 Jul 2018 06:35:05 GMT):
can not export solution file of dotnet wrapper. anybody knows the solution? Is it in stable state?

saikirantyson7 (Mon, 30 Jul 2018 11:21:29 GMT):
is it possible to retrieve a trustee did using the seed value? The scenario here is: Whenever i run a script it breaks with error "DIDAlreadyExists". Though its failing is expected, i didn't stored the DID anywhere. So is there anyway to retrieve the DID back from my local wallet or to bypass that error?

sklump (Mon, 30 Jul 2018 11:26:33 GMT):
@saikirantyson7 Two approaches can satisfy: (1) create a temporary wallet with the seed, get the DID, erase the wallet; (2) store the seed in the metadata on creation, then search the metadata to identify the DID on demand.

saikirantyson7 (Mon, 30 Jul 2018 11:28:47 GMT):
how do i go for teh 2nd approach?

saikirantyson7 (Mon, 30 Jul 2018 11:28:47 GMT):
how do i go for the 2nd approach?

sklump (Mon, 30 Jul 2018 11:33:05 GMT):
``` from indy import did # ... (_did, _verkey) = await did.create_and_store_my_did(self.handle, json.dumps({'seed': seed})) await did.set_did_metadata(handle, did, json.dumps({'seed': _seed})) ```

sklump (Mon, 30 Jul 2018 11:33:40 GMT):
That should get you started. Metadata APIs are in the `did.py` wrapper.

saikirantyson7 (Mon, 30 Jul 2018 11:36:25 GMT):
Thanks @sklump

sklump (Mon, 30 Jul 2018 12:02:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nkxdnZFGkQmd2kmKD) @smithbk proof['identifiers'][i]['cred_def_id'] for identifier i

AxelNennker (Mon, 30 Jul 2018 12:32:39 GMT):
Has somebody seen the error message 'unresolved symbol: _zmq_has' when building libindy for Android on macos?

AxelNennker (Mon, 30 Jul 2018 12:32:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=DEoJ7SiQEesFmKNea) Has somebody seen the error message `unresolved symbol: _zmq_has` when building libindy for Android on macos?

smithbk (Mon, 30 Jul 2018 12:33:59 GMT):
@sklump thanks

smithbk (Mon, 30 Jul 2018 12:45:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=cYnWzMMTJkSkYraz6) @sklump Could you tell me how to determine "i". The requested_attributes and requested_predicates of the proof request is a map, not an array, so am I to assume the keys of the map are ordered?

smithbk (Mon, 30 Jul 2018 12:56:28 GMT):
@sklump A follow on question. If a user has multiple entries in their wallet which match a requirement (e.g. multiple cred defs which match a particular schema requirement), how does the user control which one is used for the proof?

sklump (Mon, 30 Jul 2018 12:57:10 GMT):
proof-req attr and pred specs have optional 'restrictions' -- use them to specify cred def

smithbk (Mon, 30 Jul 2018 13:00:00 GMT):
ok, maybe i'm not following. If the verifier uses a schema requirement instead, can the prover specify a cred def when generating the proof?

sklump (Mon, 30 Jul 2018 13:05:29 GMT):
If the verifier has a cred def requirement, then the verifier should specify a cred def restriction in building out the proof request.

sklump (Mon, 30 Jul 2018 13:05:45 GMT):
As far as I understand it.

sklump (Mon, 30 Jul 2018 13:05:45 GMT):
I don't get your use case. Any cred def off a schema-id perforce satistfies a requirement of that schema-id. If you have further restrictions or preferences in mind, that's not on indy-sdk.

AvikHazra (Mon, 30 Jul 2018 13:07:27 GMT):
hello, response from submitRequest(poolHandle, getSchemaRequest) like { result: { seqNo: null, dest: 'U3dgLmWDeM2hjLGHmJN6su', identifier: 'LCCKm28cqjbjEM9ReAABrK', txnTime: null, reqId: 1532948318214362000, data: { name: 'basic-address', version: '1.0' }, type: '107' }, op: 'REPLY' } but when I`m hit parseGetSchemaResponse(getSchemaResponse) its returning IndyError: LedgerInvalidTransaction Can anyone please help ? where is the issue ? what is wrong in getSchemaResponse ?

AvikHazra (Mon, 30 Jul 2018 13:07:27 GMT):
hello, response from submitRequest(poolHandle, getSchemaRequest) like { result: { seqNo: null, dest: 'U3dgLmWDeM2hjLGHmJN6su', identifier: 'LCCKm28cqjbjEM9ReAABrK', txnTime: null, reqId: 1532948318214362000, data: { name: 'basic-address', version: '1.0' }, type: '107' }, op: 'REPLY' } but when I`m hitting parseGetSchemaResponse(getSchemaResponse) its returning IndyError: LedgerInvalidTransaction Can anyone please help ? where is the issue ? what is wrong in getSchemaResponse ?

pimotte (Mon, 30 Jul 2018 13:26:19 GMT):
@AvikHazra seqNo being null is something I have been interpreting as "not found"

pimotte (Mon, 30 Jul 2018 13:26:41 GMT):
Make sure you await the call where you create the schema and use the correct id to request it

smithbk (Mon, 30 Jul 2018 13:45:51 GMT):
@sklump WRT the use case, suppose Acme wants proof of a transcript from any of 1000's of colleges (not just Faber). There is a single transcript schema but each college has their own cred def. Acme uses a schema_key requirement to generate the proof request. After verifying the proof, it wants to get the actual cred def id to see if it was among its current list of valid colleges.

sklump (Mon, 30 Jul 2018 13:52:56 GMT):
@smithbk the cred def id is in the list of identifiers, ordinally matching up against the list of proofs in proof['proofs']

DuckLover (Mon, 30 Jul 2018 14:26:47 GMT):
Is there any Doc how to use the sovrin network on indy base?

ShivKushwah (Mon, 30 Jul 2018 21:50:05 GMT):
Hi, I am making changes to the Android Readme, and I was able to sign my commits. However, when I tried to create a pull request between my forked repo and the indy-sdk repo, it says that the pull request is unsigned

ShivKushwah (Mon, 30 Jul 2018 21:50:35 GMT):
Do I need to sign the actual pull request, and if so, how do I do that?

geethanisp (Tue, 31 Jul 2018 01:55:49 GMT):
Has joined the channel.

akuma921 (Tue, 31 Jul 2018 06:11:52 GMT):
I am facing issue while running node wrapper sample (although it was working fine earlier..I just pulled the latest changes and it start failing) *Getting started -> started Open Pool Ledger: pool1 (node:13020) UnhandledPromiseRejectionWarning: IndyError: PoolIncompatibleProtocolVersion at Object.callback (/Users/akuma921/work/hyperledger-indy/indy-sdk/indy-sdk/wrappers/nodejs/src/wrapIndyCallback.js:15:10) (node:13020) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1) (node:13020) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.*

akuma921 (Tue, 31 Jul 2018 06:12:22 GMT):
Any help is appreciated....

AvikHazra (Tue, 31 Jul 2018 06:19:24 GMT):
@akuma921 use setProtocolVersion(2)

akuma921 (Tue, 31 Jul 2018 06:19:39 GMT):
its already 2

akuma921 (Tue, 31 Jul 2018 06:21:01 GMT):
@AvikHazra I took the latest update ..and as per that it is already 2...and btw, as I mentioned it was working perfectly fine earlier

akuma921 (Tue, 31 Jul 2018 06:21:57 GMT):
@AvikHazra is there a way I can connect to some cloud based (remote running public) ledger for testing/understanding purpose

AxelNennker (Tue, 31 Jul 2018 08:18:06 GMT):
java wrapper initialize final json string question: https://github.com/hyperledger/indy-sdk/blob/master/wrappers/java/src/test/java/org/hyperledger/indy/sdk/IndyIntegrationTest.java#L68 does not compile because Android Studio insists on that the JSONException must be caught. Besides me wondering why this is not a problem for others I think that doing the initialization like this would be fine protected static final String WALLET_CONFIG = "{ \"id\":" + WALLET + ", \"storage_type\":" + TYPE + '}';

pimotte (Tue, 31 Jul 2018 08:40:36 GMT):
@AxelNennker It's an issue because the JSONException is checked in Android: https://developer.android.com/reference/org/json/JSONException

pimotte (Tue, 31 Jul 2018 08:41:42 GMT):
I just use the artifact compiled with a normal jdk instead of the android-sdk, but I have no idea if that can cause issues down the line

saikirantyson7 (Tue, 31 Jul 2018 09:05:33 GMT):
Can we run the indy as multinode.? [Physically in different systems]. Can anyone share the procedure to it?

AxelNennker (Tue, 31 Jul 2018 10:38:41 GMT):
I created a JIRA issue related to JSONObject.similar https://jira.hyperledger.org/browse/IS-853

AxelNennker (Tue, 31 Jul 2018 10:38:41 GMT):
I created a JIRA issue related to JSONObject.similar https://jira.hyperledger.org/browse/IS-853?jql=project%20%3D%20%22IS%22%20AND%20text%20~%20JSONObject

AxelNennker (Tue, 31 Jul 2018 10:38:41 GMT):
I created a JIRA issue related to JSONObject.similarhttps://jira.hyperledger.org/browse/IS-853

AxelNennker (Tue, 31 Jul 2018 12:40:08 GMT):
Is there a release plan for "indy" especially for indy-sdk and indy-node?

pimotte (Tue, 31 Jul 2018 15:00:58 GMT):
For those who are interested in indy-sdk on Android, I've got a wallet working https://github.com/Quintor/StudyBitsWallet (app works in conjunction with agent at https://github.com/Quintor/StudyBits)

ShivKushwah (Tue, 31 Jul 2018 16:40:33 GMT):
@AxelNennker I've signed my commits in the PR and it shows up as verified, but my PR still shows as DCO - Sign Off missing

ShivKushwah (Tue, 31 Jul 2018 16:40:42 GMT):
https://github.com/hyperledger/indy-sdk/pull/1009

ShivKushwah (Tue, 31 Jul 2018 16:40:55 GMT):
I used git commit -S -m " ... "

Dominic (Tue, 31 Jul 2018 19:56:53 GMT):
I'm having a problem, and I don't really know what's causing it. When I create a credential using a cred def, I can create it and send it to verifiers for proofs. However, if I create two credentials with the same cred def, the second credential will cause proofs to return as false. Essentially, the problem boils down to this: ``` #Typing this line alone will result in a usable credential for proofs. (cred_json, rev_id, rev_reg_delta_json) = await anoncreds.issuer_create_credential(issuer_wallet_handle, cred_offer_json, cred_req_json, cred_values_json, rev_reg_id, blob_storage_reader_cfg_handle) #Adding the same line a second time doesn't yield an error, but now any proofs using the created credential will fail verification from the verifier (cred_json, rev_id, rev_reg_delta_json) = await anoncreds.issuer_create_credential(issuer_wallet_handle, cred_offer_json, cred_req_json, cred_values_json, rev_reg_id, blob_storage_reader_cfg_handle) ``` The only variables that can be modified by this are cred_json (changed data: omega, witness, u_i), rev_id (changes from '1' to '2'), and rev_reg_delta_json (changed data: value.prevAccum, value.accum, value.issued changes from [1] to [2]) Can someone point me to why this doesn't just work? (I tried changing the prover's info between cred creations as well, but this didn't affect the outcome)

Dominic (Tue, 31 Jul 2018 19:56:53 GMT):
I'm having a problem, and I don't really know what's causing it. When I create a credential using a cred def, I can create it and send it to verifiers for proofs. However, if I create two credentials with the same cred def, the second credential will cause proofs to return as false. Essentially, the problem boils down to this: ``` #Typing this line alone will result in a usable credential for proofs. (cred_json, rev_id, rev_reg_delta_json) = await anoncreds.issuer_create_credential(issuer_wallet_handle, cred_offer_json, cred_req_json, cred_values_json, rev_reg_id, blob_storage_reader_cfg_handle) #Adding the same line a second time doesn't yield an error, but now any proofs using the created credential will fail verification from the verifier (cred_json, rev_id, rev_reg_delta_json) = await anoncreds.issuer_create_credential(issuer_wallet_handle, cred_offer_json, cred_req_json, cred_values_json, rev_reg_id, blob_storage_reader_cfg_handle) ``` The only variables that can be modified by this are cred_json (changed data: omega, witness, u_i), rev_id (changes from '1' to '2'), and rev_reg_delta_json (changed data: value.prevAccum, value.accum, value.issued changes from [1] to [2]) Can someone point me to why this doesn't just work? (I tried using a different prover between cred creations as well, but this didn't affect the outcome)

Artemkaaas (Wed, 01 Aug 2018 05:19:52 GMT):
@Dominic You need to call ``` rev_reg_delta_json = await anoncreds.issuer_merge_revocation_registry_deltas(rev_reg_delta_json_1, rev_reg_delta_json_2) ``` where rev_reg_delta_json_1 - delta from first `issuer_create_credential` and `rev_reg_delta_json_2` from second and use this aggregated delta for proving and verifying

DuckLover (Wed, 01 Aug 2018 07:53:48 GMT):
Hello guys, i setup indy-sdk on a ubuntu vm and created the sandbox pool and a local pool via the genesis file from sovrin-repo. But i cant connect to both pools. What could be the cause? "Pool 'sandbox' has not been connected"

akuma921 (Wed, 01 Aug 2018 08:30:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=w9yKZqPNPwDc2nHAt) @animeshdas I was able to do so 1 month back .....bu tnow getting sudden "InCompatible Protocol Version" error on the latest code ....nots sure they way to proceed

sklump (Wed, 01 Aug 2018 12:48:46 GMT):
I might have found a bug in the (new) anoncreds prover wallet WQL credential search, although it is at least as likely that I've misunderstood the operation details. I have three cred defs: * fav-num v1.0: `WgWxqztrNooG92RXvxSTWv:3:CL:178:0` (on schema with attributes 'ident', 'num') * ident v1.0: `WgWxqztrNooG92RXvxSTWv:3:CL:179:0` (on schema with attributes 'ident', 'regEpoch') * fav-char v1.0: `WgWxqztrNooG92RXvxSTWv:3:CL:180:0` (on schema with attributes 'ident', 'char'). The wallet has 24 creds on each. I build a proof request using only the fav-num cred def; it looks like this: ``` { "version": "0.0", "requested_attributes": { "178_ident_uuid": { "non_revoked": { "to": 1533125645, "from": 1533125645 }, "restrictions": [ { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0" } ], "name": "ident" }, "178_num_uuid": { "non_revoked": { "to": 1533125645, "from": 1533125645 }, "restrictions": [ { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0" } ], "name": "num" } }, "nonce": "1533125655", "requested_predicates": {}, "name": "proof_req" } ``` I search the wallet with the above proof-req and extra WQL dict: ``` { "178_ident_uuid": { "$or": [ { "attr::ident::value": 1 }, { "attr::num::value": 0 } ] }, "178_num_uuid": { "$or": [ { "attr::ident::value": 1 }, { "attr::num::value": 0 } ] } } ``` After getting the search handle, I tracked what I got back from each call to `anoncreds.prover_fetch_credentials_for_proof_req()` per item referent and got: ``` .. FETCHED 6 briefs for referent 178_ident_uuid: [ { "interval": ..., "cred_info": { "referent": "57877da8-8c78-42a8-bcd1-d05f84240ef8", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "cabe9a7b-0d90-427b-ab7b-976eebd3cff7", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "7c1b830c-8b54-443f-8108-ae403a7d3ee8", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:179:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "5461fbb1-2459-43a9-8e93-0c43f25e818b", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:180:0", "attrs": ..., ... } }, { "interval": { "to": 1533125645, "from": 1533125645 }, "cred_info": { "referent": "7e6e8fdd-286a-4317-81d8-0a4ff22dbf2f", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "9ed40b12-60e0-442a-ab40-ac5ca46e8ffe", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } } ] .. FETCHED 4 briefs for referent 178_num_uuid: [ { "interval": ..., "cred_info": { "referent": "57877da8-8c78-42a8-bcd1-d05f84240ef8", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "cabe9a7b-0d90-427b-ab7b-976eebd3cff7", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "7e6e8fdd-286a-4317-81d8-0a4ff22dbf2f", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "9ed40b12-60e0-442a-ab40-ac5ca46e8ffe", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } } ] ``` _(elided for brevity)_. The proof request clearly identifies the cred-def restriction on each item referent, but the search ignores it in the WQL fetch iteration that the item referent identifies. As I see it, no way should this search have found credentials on the fav-char or ident cred-defs. Is this a bug or have I got it wrong?

sklump (Wed, 01 Aug 2018 12:48:46 GMT):
I might have found a bug in the (new) anoncreds prover wallet WQL credential search, although it is at least as likely that I've misunderstood the operation details. I have three cred defs: * fav-num v1.0: `WgWxqztrNooG92RXvxSTWv:3:CL:178:0` (on schema with attributes 'ident', 'num') * ident v1.0: `WgWxqztrNooG92RXvxSTWv:3:CL:179:0` (on schema with attributes 'ident', 'regEpoch') * fav-char v1.0: `WgWxqztrNooG92RXvxSTWv:3:CL:180:0` (on schema with attributes 'ident', 'char'). The wallet has 24 creds on each with ident=0..23, and, for the fav-num creds, * ident 0..3 have num=0 * ident 4..23 have num > 0. I build a proof request using only the fav-num cred def; it looks like this: ``` { "version": "0.0", "requested_attributes": { "178_ident_uuid": { "non_revoked": ..., "restrictions": [ { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0" } ], "name": "ident" }, "178_num_uuid": { "non_revoked": ..., "restrictions": [ { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0" } ], "name": "num" } }, "nonce": "1533125655", "requested_predicates": {}, "name": "proof_req" } ``` I search the wallet with the above proof-req and extra WQL dict: ``` { "178_ident_uuid": { "$or": [ { "attr::ident::value": 1 }, { "attr::num::value": 0 } ] }, "178_num_uuid": { "$or": [ { "attr::ident::value": 1 }, { "attr::num::value": 0 } ] } } ``` After getting the search handle, I tracked what I got back from each call to `anoncreds.prover_fetch_credentials_for_proof_req()` per item referent and got: ``` .. FETCHED 6 briefs for referent 178_ident_uuid: [ { "interval": ..., "cred_info": { "referent": "57877da8-8c78-42a8-bcd1-d05f84240ef8", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "cabe9a7b-0d90-427b-ab7b-976eebd3cff7", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "7c1b830c-8b54-443f-8108-ae403a7d3ee8", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:179:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "5461fbb1-2459-43a9-8e93-0c43f25e818b", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:180:0", "attrs": ..., ... } }, { "interval": { "to": 1533125645, "from": 1533125645 }, "cred_info": { "referent": "7e6e8fdd-286a-4317-81d8-0a4ff22dbf2f", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "9ed40b12-60e0-442a-ab40-ac5ca46e8ffe", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } } ] .. FETCHED 4 briefs for referent 178_num_uuid: [ { "interval": ..., "cred_info": { "referent": "57877da8-8c78-42a8-bcd1-d05f84240ef8", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "cabe9a7b-0d90-427b-ab7b-976eebd3cff7", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "7e6e8fdd-286a-4317-81d8-0a4ff22dbf2f", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "9ed40b12-60e0-442a-ab40-ac5ca46e8ffe", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } } ] ``` _(elided for brevity)_. The proof request clearly identifies the cred-def restriction on each item referent, but the search ignores it in the WQL fetch iteration that the item referent identifies. As I see it, no way should this search have found credentials on the fav-char or ident cred-defs. Is this a bug or have I got it wrong?

sklump (Wed, 01 Aug 2018 12:48:46 GMT):
I might have found a bug in the (new) anoncreds prover wallet WQL credential search, although it is at least as likely that I've misunderstood the operation details. I have three cred defs: * fav-num v1.0: `WgWxqztrNooG92RXvxSTWv:3:CL:178:0` (on schema with attributes 'ident', 'num') * ident v1.0: `WgWxqztrNooG92RXvxSTWv:3:CL:179:0` (on schema with attributes 'ident', 'regEpoch') * fav-char v1.0: `WgWxqztrNooG92RXvxSTWv:3:CL:180:0` (on schema with attributes 'ident', 'char'). The wallet has 24 creds on each with ident=0..23, and, for the fav-num creds, * ident 0..3 have num=0 * ident 4..23 have num > 0. I build a proof request using only the fav-num cred def; it looks like this: ``` { "version": "0.0", "requested_attributes": { "178_ident_uuid": { "non_revoked": ..., "restrictions": [ { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0" } ], "name": "ident" }, "178_num_uuid": { "non_revoked": ..., "restrictions": [ { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0" } ], "name": "num" } }, "nonce": "1533125655", "requested_predicates": {}, "name": "proof_req" } ``` I search the wallet with the above proof-req and extra WQL dict: ``` { "178_ident_uuid": { "$or": [ { "attr::ident::value": 1 }, { "attr::num::value": 0 } ] }, "178_num_uuid": { "$or": [ { "attr::ident::value": 1 }, { "attr::num::value": 0 } ] } } ``` After getting the search handle, I tracked what I got back from each call to `anoncreds.prover_fetch_credentials_for_proof_req()` per item referent and got: ``` .. FETCHED 6 briefs for referent 178_ident_uuid: [ { "interval": ..., "cred_info": { "referent": "57877da8-8c78-42a8-bcd1-d05f84240ef8", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "cabe9a7b-0d90-427b-ab7b-976eebd3cff7", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "7c1b830c-8b54-443f-8108-ae403a7d3ee8", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:179:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "5461fbb1-2459-43a9-8e93-0c43f25e818b", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:180:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "7e6e8fdd-286a-4317-81d8-0a4ff22dbf2f", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "9ed40b12-60e0-442a-ab40-ac5ca46e8ffe", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } } ] .. FETCHED 4 briefs for referent 178_num_uuid: [ { "interval": ..., "cred_info": { "referent": "57877da8-8c78-42a8-bcd1-d05f84240ef8", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "cabe9a7b-0d90-427b-ab7b-976eebd3cff7", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "7e6e8fdd-286a-4317-81d8-0a4ff22dbf2f", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } }, { "interval": ..., "cred_info": { "referent": "9ed40b12-60e0-442a-ab40-ac5ca46e8ffe", "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attrs": ..., ... } } ] ``` _(elided for brevity)_. The proof request clearly identifies the cred-def restriction on each item referent, but the search ignores it in the WQL fetch iteration that the item referent identifies. As I see it, no way should this search have found credentials on the fav-char or ident cred-defs. Is this a bug or have I got it wrong?

AxelNennker (Wed, 01 Aug 2018 14:38:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qx3RBDYSKGQFhJAKT) @ShivKushwah lower-case s `git commit -s`

AxelNennker (Wed, 01 Aug 2018 14:38:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qx3RBDYSKGQFhJAKT) @ShivKushwah lower-case s `git -s`

Dominic (Wed, 01 Aug 2018 14:56:28 GMT):
@Artemkaaas Thank you, that worked perfectly!

Dominic (Wed, 01 Aug 2018 14:56:28 GMT):
@xnopre here is the nodejs documentation: https://www.npmjs.com/package/indy-sdk/v/0.2.1?activeTab=readme#anoncreds

ShivKushwah (Wed, 01 Aug 2018 16:11:00 GMT):
@AxelNennker @Artemkaaas Thanks so much! I successfully finished sign off and am awaiting final review :) https://github.com/hyperledger/indy-sdk/pull/1009

baconsandwich (Wed, 01 Aug 2018 17:32:35 GMT):
Can someone help me understand the following error ``` # Attempt to create pool ledger config with name used for another existing pool PoolLedgerConfigAlreadyExistsError = 306, ``` What is meant here by "config"? I first assumed that a config is just a voliatile value in memory, like an IP or server to connect to, but I get this message where it says that the config is already used? How can a configuration already be used?

baconsandwich (Wed, 01 Aug 2018 17:35:30 GMT):
I am doing the [Write a DID and Query Its Verkey](https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/write-did-and-query-verkey/python/README.md) tutorial and replaced ``` await pool.create_pool_ledger_config(config_name=pool_name, config=pool_config) ``` with ``` try: await pool.create_pool_ledger_config(config_name=pool_name, config=pool_config) except IndyError: await pool.delete_pool_ledger_config(config_name=pool_name) await pool.create_pool_ledger_config(config_name=pool_name, ```but still get the same error.

baconsandwich (Wed, 01 Aug 2018 17:50:55 GMT):
I think I get it know. It is just about the config_name parameter, isn't it?

sklump (Wed, 01 Aug 2018 18:12:09 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=CzuirPikQghNpEies) @baconsandwich You are trying to create a new configuration file and record of genesis transactions at a location on disk where there already is one, likely `~/.indy_client/pool//`. You can just catch this one, check `x_indy.error_code == ErrorCode.PoolLedgerConfigAlreadyExistsError` for exception x_indy, and call `pool.open_pool_ledger()` instead.

sklump (Wed, 01 Aug 2018 18:12:09 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=CzuirPikQghNpEies) @baconsandwich You are trying to create a new configuration file and record of genesis transactions at a location on disk where there already is one, likely `~/.indy_client/pool//`. You can just catch this one, check `x_indy.error_code == ErrorCode.PoolLedgerConfigAlreadyExistsError` for exception `x_indy`, and call `pool.open_pool_ledger()` instead.

baconsandwich (Wed, 01 Aug 2018 18:47:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=FDxfYQpvqmpTwWaXn) @sklump hey thanks for the reply. but should the delete statement i used also solve this problem?

baconsandwich (Wed, 01 Aug 2018 18:48:04 GMT):
i mean, your solution is of course cleaner but I don't understand why the deletion also yields an exception

sklump (Wed, 01 Aug 2018 18:51:03 GMT):
You haven't checked your error code. You don't know that the deletion itself hasn't failed. File permissions?

baconsandwich (Wed, 01 Aug 2018 18:52:16 GMT):
permission are ok. 664 and owned by the user that also runs the IDE I use (PyCharm)

baconsandwich (Wed, 01 Aug 2018 18:52:43 GMT):
I'll try to debug it step by step and verify that it is actually deleted

baconsandwich (Wed, 01 Aug 2018 18:56:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=H695h8enQFBHSZQYY) confirmed that it was deleted

baconsandwich (Wed, 01 Aug 2018 19:01:02 GMT):
oh, nevermind, i just realized that i only delete after the exception was thrown so obvously it shows me the error message first :facepalm_tone1:

sklump (Wed, 01 Aug 2018 19:03:43 GMT):
https://www.youtube.com/watch?v=SrDSqODtEFM

baconsandwich (Wed, 01 Aug 2018 19:06:40 GMT):
:grinning:

baconsandwich (Wed, 01 Aug 2018 19:08:56 GMT):
I couldn't find a "config_exists() : bool" method. So is catching the exception the only way to check if the configuration already exists?

sklump (Wed, 01 Aug 2018 19:09:41 GMT):
You could try opening it and catching the exception too.

baconsandwich (Wed, 01 Aug 2018 19:40:31 GMT):
ok, thanks

MohsenZ (Thu, 02 Aug 2018 02:43:54 GMT):
I've started an Indy node on an AWS EC2 Linux instance. I'm attempting to connect to it through the Sample .Net application provided, but I'm getting a 112 error when calling OpenPoolLedgerAsync. It was working fine when I was running the node of my local machine. Has anyone run into to this or know what the issue is?

swcurran (Thu, 02 Aug 2018 02:56:50 GMT):
@MohsenZ - I would check the genesis file you are using and make sure that is references the correct IP address - the one on AWS. Chances are its pointing at the wrong IP.

swcurran (Thu, 02 Aug 2018 02:56:50 GMT):
@MohsenZ - I would check the genesis file you are using and make sure that it references the correct IP address - the one on AWS. Chances are its pointing at the wrong IP.

Artemkaaas (Thu, 02 Aug 2018 06:38:07 GMT):
@sklump It's a known problem It's not a good idea to mix old restrictions format with wql. Actully, your restriction for cred_def_id is not valid wql and it will be converted under hood to: ``` "$or": [ { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0" } ] ``` We are doing it to save backward compatibility. So, the extra query has "$or" operator too and will overwrite the first one during parsing. To get expected result you need pass restriction as ``` { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0" } ``` without square brackets And the final query will look like: ``` { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attr::ident::marker": "1", "$or": [ { "attr::ident::value": 1 }, { "attr::num::value": 0 } ] } ```

Artemkaaas (Thu, 02 Aug 2018 06:50:50 GMT):
@sklump it looks like a bug. Actully, it's not a good idea to mix old restrictions format with wql. So, your restriction for cred_def_id is not valid wql and it will be converted under hood to: ``` "$or": [ { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0" } ] ``` We are doing it to save backward compatibility. So, the extra query has "$or" operator too and for now it will overwrite the first one during parsing. To get expected result you need pass restriction as ``` { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0" } ``` without square brackets And the final query will look like: ``` { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attr::ident::marker": "1", "$or": [ { "attr::ident::value": 1 }, { "attr::num::value": 0 } ] } ```

Artemkaaas (Thu, 02 Aug 2018 06:50:50 GMT):
@sklump it looks like a bug. Actully, it's not a good idea to mix old restrictions format with wql. So, restriction for cred_def_id is not valid wql and it will be converted under hood to: ``` "$or": [ { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0" } ] ``` We are doing it to save backward compatibility. So, the extra query has "$or" operator too and for now it will overwrite the first one during parsing. To get expected result you need pass restriction as ``` { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0" } ``` without square brackets And the final query will look like: ``` { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attr::ident::marker": "1", "$or": [ { "attr::ident::value": 1 }, { "attr::num::value": 0 } ] } ``` Could you create a bug in our JIRA?

Artemkaaas (Thu, 02 Aug 2018 06:50:50 GMT):
@sklump it looks like a bug. Actully, it's not a good idea to mix old restrictions format with wql. So, restriction for cred_def_id is not valid wql and it will be converted under hood to: ``` "$or": [ { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0" } ] ``` We use "$or" to save backward compatibility. So, the extra query has "$or" operator too and for now it will overwrite the first one during parsing. To get expected result you need pass restriction as ``` { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0" } ``` without square brackets And the final query will look like: ``` { "cred_def_id": "WgWxqztrNooG92RXvxSTWv:3:CL:178:0", "attr::ident::marker": "1", "$or": [ { "attr::ident::value": 1 }, { "attr::num::value": 0 } ] } ``` Could you create a bug in our JIRA?

pradeeppadmarajaiah (Thu, 02 Aug 2018 10:05:52 GMT):
Hi All, I am interested to know, how Indy ledger works. Means, what exactly Indy ledger stores when the wallet data is sent to ledger?. Also, interested to know, the components of Indy Ledger. Could you guide me the link to get the overview

xnopre (Thu, 02 Aug 2018 10:19:24 GMT):
Hi all. Where can I found some documentation or reference guide for Indy SDK and Python or NodeJs Wrapper ? For example, how can I have information to how to user `requested_attributes` or `requested_predicates` in proof request ? Thanks

Dominic (Thu, 02 Aug 2018 14:14:07 GMT):
hmmm... my messages aren't showing up on my screen. Sorry other people if you are somehow reading this.

Dominic (Thu, 02 Aug 2018 14:14:07 GMT):
@xnopre here is the nodejs documentation: https://www.npmjs.com/package/indy-sdk/v/0.2.1?activeTab=readme#anoncreds

Dominic (Thu, 02 Aug 2018 14:14:07 GMT):
@xnopre here is the nodejs documentation: https://www.npmjs.com/package/indy-sdk/v/0.2.1?activeTab=readme#anoncreds I tend to find that the rust implementation comments are the most detailed source of documentation: https://github.com/hyperledger/indy-sdk/blob/2123d8634692edea58f5cf589609762bea18db64/libindy/src/api/anoncreds.rs#L1118

Dominic (Thu, 02 Aug 2018 15:07:06 GMT):
When a prover creates a revocation state with `create_revocation_state`, where does he get the `cred_rev_id`? Does the issuer send it along with the credential after receiving a cred_request? Alternatively, I see that the `cred` (json) has a `signature.r_credential.i` element that seems to always have the same value as the `cred_rev_id`. Could this be where the prover gets the `cred_rev_id`?

sklump (Thu, 02 Aug 2018 15:53:55 GMT):
It appears that pytest-3.7.0, or perhaps pluggy-0.7.1, breaks the python wrapper tests: ``` $ pipenv run pytest -s test_interaction.py ================================================= test session starts ================================================== platform linux -- Python 3.5.2, pytest-3.7.0, py-1.5.4, pluggy-0.7.1 rootdir: /home/sklump/indy-sdk/wrappers/python, inifile: plugins: asyncio-0.9.0 collected 1 item test_interaction.py F ======================================================= FAILURES ======================================================= ____________________________ test_anoncreds_revocation_interaction_test_issuance_by_demand _____________________________ pool_name = 'pool1', pool_handle = 1, wallet_handle = 3, identity_my = identity_my1 = , path_home = PosixPath('/home/sklump/.indy_client') did_my2 = '2PRyVHmkXQnQzJQKxHxnXC', credentials = '{"key":"key"}' @pytest.mark.asyncio async def test_anoncreds_revocation_interaction_test_issuance_by_demand(pool_name, pool_handle, wallet_handle, identity_my, identity_my1, path_home, did_my2, credentials): > issuer_did, _ = identity_my E TypeError: 'coroutine' object is not iterable test_interaction.py:16: TypeError =============================================== 1 failed in 1.99 seconds =============================================== sys:1: RuntimeWarning: coroutine 'identity_my' was never awaited sys:1: RuntimeWarning: coroutine 'identity_my1' was never awaited sys:1: RuntimeWarning: coroutine 'identity_trustee1' was never awaited ``` Does anyone have a quick patch for this? Backdating to pytest-3.6.3 and pluggy-0.6.0 fixes it for now.

sklump (Thu, 02 Aug 2018 15:53:55 GMT):
It appears that pytest-3.7.0, or perhaps pluggy-0.7.1, breaks the python wrapper tests: ``` .../tests/interation$ pipenv run pytest -s test_interaction.py ================================================= test session starts ================================================== platform linux -- Python 3.5.2, pytest-3.7.0, py-1.5.4, pluggy-0.7.1 rootdir: /home/sklump/indy-sdk/wrappers/python, inifile: plugins: asyncio-0.9.0 collected 1 item test_interaction.py F ======================================================= FAILURES ======================================================= ____________________________ test_anoncreds_revocation_interaction_test_issuance_by_demand _____________________________ pool_name = 'pool1', pool_handle = 1, wallet_handle = 3, identity_my = identity_my1 = , path_home = PosixPath('/home/sklump/.indy_client') did_my2 = '2PRyVHmkXQnQzJQKxHxnXC', credentials = '{"key":"key"}' @pytest.mark.asyncio async def test_anoncreds_revocation_interaction_test_issuance_by_demand(pool_name, pool_handle, wallet_handle, identity_my, identity_my1, path_home, did_my2, credentials): > issuer_did, _ = identity_my E TypeError: 'coroutine' object is not iterable test_interaction.py:16: TypeError =============================================== 1 failed in 1.99 seconds =============================================== sys:1: RuntimeWarning: coroutine 'identity_my' was never awaited sys:1: RuntimeWarning: coroutine 'identity_my1' was never awaited sys:1: RuntimeWarning: coroutine 'identity_trustee1' was never awaited ``` Does anyone have a quick patch for this? Backdating to pytest-3.6.3 and pluggy-0.6.0 fixes it for now.

dbluhm (Thu, 02 Aug 2018 16:23:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4WEfq2YkTFiAsDoGR) @sklump I also ran into this while working on the indy-agent test suite. The most recent changes to pytest broke the pytest asyncio extension. I think the best option for now is rolling back to pytest==3.6.4 or pytest==3.6.3

sklump (Thu, 02 Aug 2018 16:28:46 GMT):
It's something to do with async def fixtures, which they've written some words on here https://github.com/pytest-dev/pytest/issues/3661 that I don't fully understand.

mgbailey (Thu, 02 Aug 2018 17:39:56 GMT):
@br3nt there is a testnet called the Sovrin Test Network (STN). Here is a Sovrin forum posting on it: https://forum.sovrin.org/t/testing-on-the-sovrin-test-network-stn/643

MohsenZ (Thu, 02 Aug 2018 18:33:51 GMT):
@swcurran Thanks for the reply. When the IP address is incorrect, I correctly get a 307 error (PoolTimeOut). But with the correct IP (pointing to AWS), I get a 112 error. So it seems it is hitting the node, but is getting some error :(

burdettadam (Thu, 02 Aug 2018 22:21:52 GMT):
un-official libvcx documentation https://burdettadam.github.io/sdk/vcx/libvcx/doc/vcx/ I ran `cargo doc --no-deps`.

Artemkaaas (Fri, 03 Aug 2018 05:19:24 GMT):
@Dominic in the current vision yes, Issuer have to send cred_rev_id to prover together with a credential. In the current implementation `cred_rev_id` matches to `signature.r_credential.i` but it can be changed

xnopre (Fri, 03 Aug 2018 09:05:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=7KHfnEsSgdBmMo99f) @Dominic Many thanks for your answer. I have bookmarked the NodeJs Wrapper that seems to have a good documentation. I'm starting to implement a POC using this Wrapper ;-) . And thank you for the idea of Rust sources, it seems to be a good way to have more details ! :-)

AxelNennker (Fri, 03 Aug 2018 09:21:19 GMT):
Sample Android app that creates a wallet on your phone https://github.com/AxelNennker/DroidLibIndy/

zickau (Fri, 03 Aug 2018 09:59:18 GMT):
Has joined the channel.

vtech (Fri, 03 Aug 2018 10:50:11 GMT):
Hi, I am using java indy-sdk and trying to execute 'Creating and storing CRED DEF using anoncreds as Trust Anchor, for the given Schema', however method 'org.hyperledger.indy.sdk.anoncreds.Anoncreds.issuerCreateAndStoreClaimDef' is not found. I am using hyerledger indy version as 1.4.0-dev-586. Can somebody have information regrading this ? Thanks

akuma921 (Fri, 03 Aug 2018 11:17:54 GMT):
I am using nodejs SDK...can anybody guide me to clean the ledger back to its original state

akuma921 (Fri, 03 Aug 2018 11:18:26 GMT):
even restarting docker prcess is not helping ..I am on mac btw

akuma921 (Fri, 03 Aug 2018 11:18:26 GMT):
even restarting docker container (indy_pool) is not helping ..I am on mac btw

saikirantyson7 (Fri, 03 Aug 2018 11:29:55 GMT):
Can anyone explain how a proof request exactly works?

Dominic (Fri, 03 Aug 2018 14:33:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3ZQP8onXGmDjckPZx) @Artemkaaas Out of curiosity, is there a reason why the cred_rev_id shouldn't be included with the credential itself? (from a design perspective)

sklump (Fri, 03 Aug 2018 14:40:19 GMT):
@Dominic There's a chicken and egg problem with doing that. The issuer doesn't know the id until the credential is done creation.

sklump (Fri, 03 Aug 2018 14:40:19 GMT):
@Dominic There's a chicken and egg problem with doing that. The issuer doesn't know the id until the credential is done creation. In practice it is linear, but there may be a race condition if several are in process in parallel.

Dominic (Fri, 03 Aug 2018 14:48:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=hsSGs3CnCSiQ4WCxK) @saikirantyson7 At a high level, a prover would receive credentials (signed attributes) from issuers. Then, a verifier would ask the prover to send a proof of certain credentials. There are three "types" of attributes when it comes to proof requests. There are "revealed attributes" which are essentially sent in plaintext. Then there's "hidden" attributes: a cryptographic proof that a user owns an attribute (that fulfills the restrictions specified in the proof request) is sent without revealing the actual value of the attribute. Finally there's "predicates": a proof that a statement the refers to an attribute is true (without giving the value of the attribute) - eg. proof that `age >= 18` is true. The verifier creates a proof requesting those attributes and predicates, and can specify restrictions on each of them (eg. issuerDID for the 'age' attribute must be x). When the prover receives the proof request, libindy looks for attributes that satisfy the request in the wallet, and creates a proof using those credentials. Zero-knowledge proofs is the concept used in the back-end to send predicates while still ensuring the privacy of the prover's attributes. The proof is then sent back to the verifier, so that libindy on the verifier's end can verify that the sent proof satisfies the requirements listed in the proof request.

Dominic (Fri, 03 Aug 2018 14:57:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=57M9qBqDSRdjEDoNN) @sklump Thanks for the answer, I see why it's a challenging problem now. To me, it still seems like it would be possible to accomplish (eg. creating the id before the credential and discarding if credential creation fails, or somehow adding it to the credential after the id is generated), but that's probably because I don't have a good grasp of how the libindy codebase is implemented (yet) :sweat_smile:

AxelNennker (Fri, 03 Aug 2018 16:44:19 GMT):
if err was not an int but an errorJsonStr then the java wrappers would look like this https://github.com/AxelNennker/indy-sdk/blob/errorJson/wrappers/java/src/main/java/org/hyperledger/indy/sdk/wallet/Wallet.java#L52 errorJson would be something like `{"errorCode":200,"message":"invalid wallet handle"} The code is in this branch https://github.com/AxelNennker/indy-sdk/tree/errorJson

AxelNennker (Fri, 03 Aug 2018 16:44:19 GMT):
if err was not an int but an errorJsonStr then the java wrappers would look like this https://github.com/AxelNennker/indy-sdk/blob/errorJson/wrappers/java/src/main/java/org/hyperledger/indy/sdk/wallet/Wallet.java#L52 errorJson would be something like `{"errorCode":200,"message":"invalid wallet handle"} This is related to this issue started by @peacekeeper https://github.com/hyperledger/indy-sdk/issues/19 The code for the java wrapper change is in this branch https://github.com/AxelNennker/indy-sdk/tree/errorJson

MohsenZ (Fri, 03 Aug 2018 20:04:28 GMT):
Does anyone know how to access logs that are produced after adding the environment variable RUST_LOG=trace to the process?

dbluhm (Fri, 03 Aug 2018 20:42:14 GMT):
Logs are usually just printed to:w

n3m (Fri, 03 Aug 2018 20:43:38 GMT):
@MohsenZ right now they should be written on the stdout. You could just redirect the outputs to a file and store it there

dbluhm (Fri, 03 Aug 2018 20:44:49 GMT):
I think it's actually going to stderr but what @n3m said :slightly_smiling_face:

ShivVenkatraman (Fri, 03 Aug 2018 22:04:00 GMT):
Has joined the channel.

ShivVenkatraman (Fri, 03 Aug 2018 22:30:24 GMT):
I am an indy newbie. I was able to start a new node (start_indy_node) on Ubuntu using the instructions in https://chat.hyperledger.org/channel/indy-sdk. How do I get going with a simple Java program that creates a DID, schema etc. and 'connects'/writes to the node that I just started. The How-to tutorials are not clear on the connection (bootstrapping) part

ShivVenkatraman (Fri, 03 Aug 2018 22:30:24 GMT):
I am a Indy newbie. Can someone post the steps to run the Java sample on Ubuntu. https://github.com/hyperledger/indy-sdk/tree/master/samples/java. I was able to start nodes (start_indy_node) on Ubuntu with https://github.com/hyperledger/indy-node/blob/master/docs/start-nodes.md. I would like to try it out with a simple Java program to create a wallet (credential schema, credentials etc.)

n3m (Fri, 03 Aug 2018 22:35:37 GMT):
Are you talking about these HOW-TOs: https://github.com/hyperledger/indy-sdk/tree/master/doc/how-tos

n3m (Fri, 03 Aug 2018 22:35:37 GMT):
@ShivVenkatraman Are you talking about these HOW-TOs: https://github.com/hyperledger/indy-sdk/tree/master/doc/how-tos

ShivVenkatraman (Fri, 03 Aug 2018 22:40:24 GMT):
@n3m Yes, I am talking about https://github.com/hyperledger/indy-sdk/tree/master/doc/how-tos. Does not have a pom file to run out of box; and instructions for set up

dredMonkey (Sun, 05 Aug 2018 08:45:27 GMT):
Has joined the channel.

dredMonkey (Sun, 05 Aug 2018 08:47:03 GMT):
Good morning .... i am strugling with a await ledger.build_nym_request call

dredMonkey (Sun, 05 Aug 2018 08:47:22 GMT):
File "/usr/local/lib/python3.6/dist-packages/indy/ledger.py", line 233, in build_nym_request c_submitter_did = c_char_p(submitter_did.encode('utf-8')) AttributeError: 'NoneType' object has no attribute 'encode'

dredMonkey (Sun, 05 Aug 2018 08:47:51 GMT):
can anyone perhaps point me into the right direction?

andrewtan (Sun, 05 Aug 2018 09:24:47 GMT):
Hi, I was following the steps on https://github.com/hyperledger/indy-sdk and have managed to build the sdk for MacOS and have followed the section "How to start local nodes pool with docker". How will I be able to check that its working properly including the Indy SDK? Thanks.

SaraC 2 (Sun, 05 Aug 2018 20:02:42 GMT):
Has joined the channel.

SaraC 2 (Sun, 05 Aug 2018 20:11:46 GMT):
Hi! I'm trying to connect to a pool in a docker container in a linux environment on AWS. I'm trying to connect to the pool from a seperate machine and getting a 112 error when opening the pool. I'm guessing I have the wrong IP in the genesis files. For the 'client_ip' I'm putting the public IP of the linux instance and for the 'node_ip' I'm putting the IP of the docker container in the linux instance. This isnt working. I'm using 'docker run -itd -p 9701-9709:9701-9709 indy_pool' to run the node. Thanks for any guidance!

brmatt (Mon, 06 Aug 2018 03:39:53 GMT):
Has joined the channel.

akuma921 (Mon, 06 Aug 2018 05:14:34 GMT):
I am getting (node:3484) UnhandledPromiseRejectionWarning: IndyError: 212, while running node-sdk ...it worked for me once...by seeing doc it says it is due to "# Requested wallet item not found WalletItemNotFound = 212,"

akuma921 (Mon, 06 Aug 2018 05:14:42 GMT):
any idea how to come over it

Gokulraja (Mon, 06 Aug 2018 05:19:40 GMT):
Has left the channel.

arunwij (Mon, 06 Aug 2018 06:30:29 GMT):
Hi, When we create a credential offer, we should create a JSON object, there are fields called 'raw' and 'encoded' for each attribute. How i should calculate encoded values for each 'raw' content. What is the encoding used there? Eg. From getting Started guide let transcriptCredValues = { "first_name": {"raw": "Alice", "encoded": "1139481716457488690172217916278103335"}, "last_name": {"raw": "Garcia", "encoded": "5321642780241790123587902456789123452"} }

arunwij (Mon, 06 Aug 2018 06:30:29 GMT):
Hi, When we create a credential offer, we should create a JSON object, there are fields called 'raw' and 'encoded' for each attribute. How i should calculate encoded values for each 'raw' content. What is the encoding used there? Eg. From getting Started guide `let transcriptCredValues = { "first_name": {"raw": "Alice", "encoded": "1139481716457488690172217916278103335"}, "last_name": {"raw": "Garcia", "encoded": "5321642780241790123587902456789123452"} }`

arunwij (Mon, 06 Aug 2018 06:30:29 GMT):
Hi, When we create a credential offer, we should create a JSON object, there are fields called 'raw' and 'encoded' for each attribute. How i should calculate encoded values for each 'raw' content. What is the encoding used there? Eg. From getting Started guide ` let transcriptCredValues = { "first_name": {"raw": "Alice", "encoded": "1139481716457488690172217916278103335"}, "last_name": {"raw": "Garcia", "encoded": "5321642780241790123587902456789123452"} }`

arunwij (Mon, 06 Aug 2018 06:30:29 GMT):
Hi, When we create a credential offer, we should create a JSON object according to the guide. There are fields called 'raw' and 'encoded' for each attribute. How i should calculate encoded values for each 'raw' content. What is the encoding used there? Eg. From getting Started guide ` let transcriptCredValues = { "first_name": {"raw": "Alice", "encoded": "1139481716457488690172217916278103335"}, "last_name": {"raw": "Garcia", "encoded": "5321642780241790123587902456789123452"} }`

arunwij (Mon, 06 Aug 2018 06:30:29 GMT):
Hi, When we create a credential offer, we should create a JSON object according to the guide. There are fields called 'raw' and 'encoded' for each attribute. How i should calculate encoded values for each 'raw' content. What is the encoding used there? Eg. From getting Started guide let transcriptCredValues = { "first_name": {"raw": "Alice", "encoded": "1139481716457488690172217916278103335"}, "last_name": {"raw": "Garcia", "encoded": "5321642780241790123587902456789123452"} }`

arunwij (Mon, 06 Aug 2018 06:30:29 GMT):
Hi, When we create a credential offer, we should create a JSON object according to the guide. There are fields called 'raw' and 'encoded' for each attribute. How i should calculate encoded values for each 'raw' content. What is the encoding used there? Eg. From getting Started guide 'let transcriptCredValues = { "first_name": {"raw": "Alice", "encoded": "1139481716457488690172217916278103335"}, "last_name": {"raw": "Garcia", "encoded": "5321642780241790123587902456789123452"} }`

arunwij (Mon, 06 Aug 2018 06:30:29 GMT):
Hi, When we create a credential offer, we should create a JSON object according to the guide. There are fields called 'raw' and 'encoded' for each attribute. How i should calculate encoded values for each 'raw' content. What is the encoding used there? Eg. From getting Started guide *let transcriptCredValues = { "first_name": {"raw": "Alice", "encoded": "1139481716457488690172217916278103335"}, "last_name": {"raw": "Garcia", "encoded": "5321642780241790123587902456789123452"} }*

arunwij (Mon, 06 Aug 2018 06:30:29 GMT):
Hi, When we create a credential offer, we should create a JSON object according to the guide. There are fields called 'raw' and 'encoded' for each attribute. How i should calculate encoded values for each 'raw' content. What is the encoding used there? Eg. From getting Started guide let transcriptCredValues = { "first_name": {"raw": "Alice", "encoded": "1139481716457488690172217916278103335"}, "last_name": {"raw": "Garcia", "encoded": "5321642780241790123587902456789123452"}}*

arunwij (Mon, 06 Aug 2018 06:30:29 GMT):
Hi, When we create a credential offer, we should create a JSON object according to the guide. There are fields called 'raw' and 'encoded' for each attribute. How i should calculate encoded values for each 'raw' content. What is the encoding used there? Eg. From getting Started guide let transcriptCredValues = { "first_name": {"raw": "Alice", "encoded": "1139481716457488690172217916278103335"}, "last_name": {"raw": "Garcia", "encoded": "5321642780241790123587902456789123452"} }

arunwij (Mon, 06 Aug 2018 06:30:29 GMT):
Hi, When we create a credential offer, we should create a JSON object according to the guide. There are fields called 'raw' and 'encoded' for each attribute. How i should calculate encoded values for each 'raw' content. What is the encoding used there? Eg. From getting Started guide ``` let transcriptCredValues = { "first_name": {"raw": "Alice", "encoded": "1139481716457488690172217916278103335"}, "last_name": {"raw": "Garcia", "encoded": "5321642780241790123587902456789123452"} } ```

arunwij (Mon, 06 Aug 2018 06:30:29 GMT):
Hi, When we create a credential offer, we should create a JSON object according to the guide. There are fields called 'raw' and 'encoded' for each attribute. How I should calculate encoded values for each 'raw' content. What is the encoding used there? Eg. From getting Started guide ``` let transcriptCredValues = { "first_name": {"raw": "Alice", "encoded": "1139481716457488690172217916278103335"}, "last_name": {"raw": "Garcia", "encoded": "5321642780241790123587902456789123452"} } ```

vtech (Mon, 06 Aug 2018 08:02:07 GMT):
Hi, I am getting exception while building the SCHEMA request to add new schema to the ledger as a Steward. What will be the correct schema format ? Schema: {"name":"gvt","version":"1.0","attr_names":["age", "sex", "height", "name"]} Exception in thread "main" java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.InvalidStructureException: A value being processed is not valid. at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895) at com.sudip.indy.howto.SaveSchemaAndCredDef.demo(SaveSchemaAndCredDef.java:65) at com.sudip.indy.howto.SaveSchemaAndCredDef.main(SaveSchemaAndCredDef.java:98) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:520) at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:551)

Artemkaaas (Mon, 06 Aug 2018 10:36:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=FvLTSMDKdDwyyHuNL) @vtech https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/api/ledger.rs#L522

AxelNennker (Mon, 06 Aug 2018 12:03:04 GMT):
Building an Android app with Sovrin https://ignisvulpis.blogspot.com/2018/08/building-android-app-with-sovrin.html

AxelNennker (Mon, 06 Aug 2018 13:54:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mo78Js4b7boxdk4Mn) @arunwij @arunwij Please see https://jira.hyperledger.org/browse/IS-786

AxelNennker (Mon, 06 Aug 2018 15:57:53 GMT):
How are the header files in libindy/include created? Manually or something like cbindgen?

SaraC 2 (Mon, 06 Aug 2018 17:16:58 GMT):
Anyone have any guidance on what IP address to use for client_ip and node_ip in the genesis file when hitting container in linux instance from outside the box?

mboyd (Mon, 06 Aug 2018 18:54:42 GMT):
@SaraC 2 can you give us a more detailed description of what you are trying to do?

esplinr (Mon, 06 Aug 2018 19:00:36 GMT):
I forget who it was that asked me for a libvcx demo. It's about 20 minutes into last week's Indy Working Group call: https://drive.google.com/open?id=1xdIUvqmZ7qsCuJvv5UtY0tz3m8YUtlVa

SaraC 2 (Mon, 06 Aug 2018 19:23:52 GMT):
@mboyd We've started a node on AWS on a linus instance for our team. I'm trying to connect to the pool from a seperate machine and getting a 112 error when opening the pool. I'm guessing I have the wrong IP in the genesis files. For the 'client_ip' I'm putting the public IP of the linux instance and for the 'node_ip' I'm putting the IP of the docker container in the linux instance. This isnt working. I'm using 'docker run -itd -p 9701-9709:9701-9709 indy_pool' to run the node.

smithbk (Mon, 06 Aug 2018 20:56:59 GMT):
When calling verifier_verify_proof with a predicate-based proof which is false, I thought it would return false but it is throwing an exception. Is this expected? ```DEBUG|indy::commands::anoncreds::verifier| src/commands/anoncreds/verifier.rs:57 | verify_proof >>> proof_request_json: "{\"nonce\": \"1533588052019\", \"version\": \"0.1\", \"requested_predicates\": {\"predicate1_referent\": {\"p_type\": \">=\", \"p_value\": 25, \"name\": \"age\", \"restrictions\": [{\"cred_d ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid structure: Requested predicates {"predicate1_referent"} do not correspond to received {} TRACE|indy::api::anoncreds | src/api/anoncreds.rs:1277| indy_verifier_verify_proof: valid: false File "/usr/local/lib/python3.5/dist-packages/indy/anoncreds.py", line 1055, in verifier_verify_proof verifier_verify_proof.cb) File "/usr/lib/python3.5/asyncio/futures.py", line 361, in __iter__ yield self # This tells Task to wait for completion. File "/usr/lib/python3.5/asyncio/tasks.py", line 296, in _wakeup future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception indy.error.IndyError: ErrorCode.CommonInvalidStructure ```

SaraC 2 (Tue, 07 Aug 2018 00:57:47 GMT):
To enable logging when running a node, do I just add RUST_LOT= trace when I start the docker instance? Like so: docker run -e RUST_LOG=trace -itd -p 9701-97 08:9701-9708 indy_pool

SaraC 2 (Tue, 07 Aug 2018 00:58:20 GMT):
and then i should see the logs on the std_out?

arunwij (Tue, 07 Aug 2018 03:52:56 GMT):
@AxelNennker Thank you. I will check it.

xnopre (Tue, 07 Aug 2018 08:05:05 GMT):
Hi all. Sorry for my basic question. I'm testing Indy running "getting started" python script, and writing my own NodeJs script. When I create a new DID with seed `000000000000000000000000Steward1` , it has "steward" role (if I good understood), but why ? Where is the explanation that with this special seed, the generated DID has "steward" role ? Thanks :-)

Aschi (Tue, 07 Aug 2018 09:09:35 GMT):
Has joined the channel.

arunwij (Tue, 07 Aug 2018 09:20:50 GMT):
@xnopre As my knowledge, The test ledger already configured to the Specific DID with Steward role. In order to use that steward role we have to have keys (private key and verification key) for that Did. We should use seed value in order to generate exact keys for pre defined Did and store them in our wallet. After that we can send NYM transactions to the ledger as Steward.

arunwij (Tue, 07 Aug 2018 09:20:50 GMT):
@xnopre According to my knowledge, The test ledger already configured to the Specific DID with Steward role. In order to use that steward role we have to have keys (private key and verification key) for that Did. We should use seed value in order to generate exact keys for pre defined Did and store them in our wallet. After that we can send NYM transactions to the ledger as Steward.

vtech (Tue, 07 Aug 2018 11:26:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6JfeB6pi5f5zFkED6) @Artemkaaas So to execute SaveSchemaAndCredDef using java sdk I have done below changes. I think howto sample need to be updated as below. 1) Updated SchemaData Json so that it is in format as Credential schema. * { * id: identifier of schema * attrNames: array of attribute name strings * name: Schema's name string * version: Schema's version string, * ver: Version of the Schema json * } 2) Update method issuerCreateAndStoreClaimDef with issuerCreateAndStoreCredentialDef and pass the attribute as per method documentation and use schema data as in step 1.

sklump (Tue, 07 Aug 2018 11:40:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=GcYoYxaknqe8dwrEo) @dredMonkey It looks like you've got `None` as the submitter DID. There are two DIDs in question: the submitter DID and the target (incoming) DID. The submitter must already be a Trust Anchor. Once you get back the NYM request, the submitter will call `ledger.sign_and_submit_request` with its wallet handle; this process will validate that it has the private key corresponding to the submitter DID in the request.

sklump (Tue, 07 Aug 2018 11:40:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=GcYoYxaknqe8dwrEo) @dredMonkey It looks like you've got `None` as the submitter DID. There are two DIDs in question: the submitter DID and the target (incoming) DID. The submitter must already be a Trust Anchor. Once you get back the NYM request, the submitter will call `ledger.sign_and_submit_request()` with its wallet handle; this process will validate that it has the private key corresponding to the submitter DID in the request.

sklump (Tue, 07 Aug 2018 12:55:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mo78Js4b7boxdk4Mn) @arunwij The raw value is the stringified original value. Indy-sdk elliptic curve cryptography operates on numbers (numbers? well, numeric strings). The process of encoding raw values to numeric strings is outside the scope of indy-sdk, it is up to the application. As long as 32-bit integers encode to their stringified values, the toolkit does not have any further requirement on the detail. Here is one implementation. https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/master/von_anchor/codec.py

xnopre (Tue, 07 Aug 2018 14:57:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=CYNM7gq42YqHvFKZy) @arunwij @arunwij Thank you for your answer. You are right, and I found that the "predefined DIDs" comme with the `generate_indy_pool_transactions` command use starting my indy pool :-)

mboyd (Tue, 07 Aug 2018 17:24:51 GMT):
Where can I find the most useful documentation on how to use the indy CLI to manage wallets? I'm using the internal CLI help command, but would prefer a more descriptive instruction set

AxelNennker (Tue, 07 Aug 2018 18:46:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=sPMTTJJ5fL4gAuQBA) @sklump I agree with @swcurran that an encoding scheme for common values helps interoperability. My take on this https://github.com/hyperledger/indy-sdk/pull/1048

AxelNennker (Tue, 07 Aug 2018 18:46:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=sPMTTJJ5fL4gAuQBA) @sklump I agree with @swcurran that an encoding scheme for common values help interoperability. My take on this https://github.com/hyperledger/indy-sdk/pull/1048

sklump (Tue, 07 Aug 2018 18:48:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=8yYzYekH4PbCLSW9T) @AxelNennker Interesting re: float ordering, but I didn't consider any ordering principle for floats because I thought indy-sdk only provided GE predicates on integers (32-bit integers, specifically).

AxelNennker (Tue, 07 Aug 2018 18:50:00 GMT):
Do you have test cases from the von_codec. I would like to compare...

sklump (Tue, 07 Aug 2018 18:50:25 GMT):
https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/master/test/test_codec.py

AxelNennker (Tue, 07 Aug 2018 18:53:15 GMT):
Close but still hard to compare to other implementations. I was looking for assertEqual(expected, encode("Alice")) for some value of expected.

sklump (Tue, 07 Aug 2018 18:56:47 GMT):
My software's whole purpose is to work with indy-sdk. If indy-sdk doesn't posit an expected encoding value, neither does mine, as long as encode/decode is reversible. It should be easy enough to compare: strip out the WQL stuff and the von_anchor-specific import, then run it and capture the output. Put an 'Alice' or whatever you like into `orig`. Fortunately the routines here don't need anything but python.

sklump (Tue, 07 Aug 2018 18:59:00 GMT):
Hold on, gimme a second and I'll post the results here:

AxelNennker (Tue, 07 Aug 2018 18:59:23 GMT):
Thanks, I was hoping you would do that.

sklump (Tue, 07 Aug 2018 19:00:32 GMT):
``` == Edge cases - (type) orig -> encoded -> (type) decoded: (str)(Alice) -> 1246470866604555559450165 -> (str)(Alice) (str)(Bob) -> 157392413161010 -> (str)(Bob) (str)(J.R. "Bob" Dobbs) -> 123692000107487509633306574080617894598073199214594302365883455161101326628659 -> (str)(J.R. "Bob" Dobbs) (NoneType)(None) -> 2147483648 -> (NoneType)(None) (bool)(True) -> 22147483650 -> (bool)(True) (bool)(False) -> 22147483649 -> (bool)(False) (int)(-5) -> -5 -> (int)(-5) (int)(0) -> 0 -> (int)(0) (int)(1024) -> 1024 -> (int)(1024) (int)(2147483647) -> 2147483647 -> (int)(2147483647) (int)(2147483648) -> 3292278026040422511789490897800973956589404042040 -> (int)(2147483648) (int)(2147483649) -> 3292278026040422511789490897800973956589404042041 -> (int)(2147483649) (int)(-2147483649) -> 318853663399594688067339323832937851927518119208432441 -> (int)(-2147483649) (int)(-2147483648) -> -2147483648 -> (int)(-2147483648) (int)(-2147483647) -> -2147483647 -> (int)(-2147483647) (float)(0.0) -> 456284244423472 -> (float)(0.0) (str)(0.0) -> 156284244423472 -> (str)(0.0) (float)(0.1) -> 456284244423473 -> (float)(0.1) (float)(-0.1) -> 43631083483811885873 -> (float)(-0.1) (float)(-1.9234856120348166e+37) -> 4118346363103572376150257369462524638568181085458527748347795511114206373863808144206434440804224330543005905719 -> (float)(-1.9234856120348166e+37) (float)(1.9234856120348166e+37) -> 41834518484686151139011264936952423078332017444442362935927001841153457642328110021483463741845116787307319 -> (float)(1.9234856120348166e+37) (str)(Hello) -> 1246599980865402989393510 -> (str)(Hello) (str)() -> 12147483648 -> (str)() (str)(Enjoy the process) -> 11547585876377423137304076650266942085095821252384200430752202418975662793106339635 -> (str)(Enjoy the process) (str)(True) -> 13833749873760745013 -> (str)(True) (str)(False) -> 1246563086251355677079093 -> (str)(False) (str)(1234) -> 13688785862641005364 -> (str)(1234) (str)(-12345) -> 115595384821298869659296346933 -> (str)(-12345) (list)([]) -> 93043112292 -> (str)([]) (list)([0, 1, 2, 3]) -> 91308961905647194589628906076081553261331542782599924757860 -> (str)([0, 1, 2, 3]) ``` Is this ok?

AxelNennker (Tue, 07 Aug 2018 19:00:58 GMT):
Cool, thanks.

AxelNennker (Tue, 07 Aug 2018 19:15:06 GMT):
Tried the first three string and the encoding is different. Maybe I have to undust my Python nevertheless. Thanks

rmarsh (Tue, 07 Aug 2018 21:36:22 GMT):
Has joined the channel.

MohsenZ (Wed, 08 Aug 2018 01:41:34 GMT):
Has anyone successfully hit a pool hosted on a Linux environment on AWS? Our team keeps getting a 112 (InvalidStateException) when trying to connect to the pool from their local machines? We're using the .Net sample and we've set the 'testPoolIp' to the public IP of the linux instance. We'd appreciate any guidance

szzzzzzz (Wed, 08 Aug 2018 07:59:19 GMT):
Has joined the channel.

marrowdev (Wed, 08 Aug 2018 09:57:49 GMT):
Hi, in /design/anoncreds.md I found information about a LIST_SCHEMA request. I can see how to build a GET_SCHEMA request using a call to indy_build_get_schema_request, but there does not appear to be a way to call LIST_SCHEMA. Does anyone know if this is not yet implemented?

marrowdev (Wed, 08 Aug 2018 09:57:59 GMT):

Screen Shot 2018-08-08 at 10.54.28.png

sergey.minaev (Wed, 08 Aug 2018 10:23:35 GMT):
@ashcherbakov ^

ashcherbakov (Wed, 08 Aug 2018 10:27:14 GMT):
Yes, this is not implemented yet. GET_SCHEMA now is the same as proposed LIST_SCHEMA

Christian (Wed, 08 Aug 2018 10:44:09 GMT):
Has joined the channel.

mero (Wed, 08 Aug 2018 10:49:26 GMT):
Has joined the channel.

olegwb (Wed, 08 Aug 2018 11:36:18 GMT):
Hi, an attempt to run integration tests ( _cargo test --test xyz.rs --features local_nodes_pool_ ) for libindy always results in large number of tests failing. Running default node pool ( 9701-9708 ) on the build machine fixes few tests only. What is the correct way of running these tests?

Dominic (Wed, 08 Aug 2018 20:38:56 GMT):
Does Indy SDK have a standard way to check for dates in predicates? What's the recommended way to verify a user's age >= 18?

xnopre (Thu, 09 Aug 2018 07:54:58 GMT):
Hi all. When I call `createAndStoreMyDid` to create Steward DID (with seed), I have the `DidAlreadyExistsError` error. How can I retrieve this existing DID/key ? I tried `listMyDidsWithMeta` but there are 2 entries, one for the Steward DID (that I want to retrieve) and the other is for an old onboarding (with Faber). How can I distinct this 2 entries to get the good one ? Do I have to store this DID in my own storage (other than indy local wallet) (and then retrieve verkey with `keyForLocalDid`) ? Thank you for your help :-)

arunwij (Thu, 09 Aug 2018 10:35:34 GMT):
Hi, i am going to build an application based on indy

arunwij (Thu, 09 Aug 2018 10:38:25 GMT):
Hi, i am going to build a web application based on indy. In case of storing wallets of the each user, where can i store them. can i generate and store user keys locally by the browser?

arunwij (Thu, 09 Aug 2018 10:38:25 GMT):
Hi, i am going to build a web application based on indy-sdk. In case of storing wallets of the each user, where can i store them. can i generate and store user keys locally by the browser? Does anyone have suggestion for that or any alternative secure method? Thank you.

arunwij (Thu, 09 Aug 2018 10:38:25 GMT):
Hi, I am going to build a web application based on indy. This question is not specifically indy SDK related. But i am going to build the application on top of that. An agent application manages user interactions with each other and the steward nodes. In case of storing wallets of each user, where can I store them? can I generate and store user keys locally by the browser? Does anyone have a suggestion for that or any alternative secure method? Thank you.

arunwij (Thu, 09 Aug 2018 10:38:25 GMT):
Hi, I am going to build a web application based on indy. This question is not specifically indy SDK related. But i am going to build the application on top of that. In my application agent server manages user interactions with each other and the steward nodes. In case of storing wallets of each user, where can I store them? can I generate and store user keys locally by the browser? Does anyone have a suggestion for that or any alternative secure method? Thank you.

arunwij (Thu, 09 Aug 2018 10:38:25 GMT):
Hi, I am going to build a web application based on indy. This question is not specifically indy SDK related. But i am going to build the application on top of that. In my application agent server manages user interactions with each other and the steward nodes. In case of storing wallets of each user, where can I store them? can I generate and store user keys and wallets locally by the browser? Does anyone have a suggestion for that or any alternative secure method? Thank you.

arunwij (Thu, 09 Aug 2018 10:38:25 GMT):
Hi, I am planning to develop a web application based on indy. This question is not specifically indy SDK related. But i am going to build the application on top of that. In my application agent server manages user interactions with each other and the steward nodes. In case of storing wallets of each user, where can I store them? can I generate and store user keys and wallets locally by the browser? Does anyone have a suggestion for that or any alternative secure method? Thank you.

arunwij (Thu, 09 Aug 2018 10:38:25 GMT):
Hi, I am planning to develop a web application based on Indy. This question is not specifically indy SDK related. But I am going to build the application on top of that. In my application, an agent server manages user interactions with each other and the steward nodes. In case of storing wallets of each user, where can I store them? can I generate and store user keys and wallets locally by the browser? Does anyone have a suggestion for that or any alternative secure method? Thank you.

arunwij (Thu, 09 Aug 2018 10:38:25 GMT):
Hi, I am planning to develop a web application based on Indy. This question is not specifically indy SDK related. But I am going to build the application on top of that. In my application, an agent server manages identity related task of multiple users and handle interactions with steward nodes. There is two questions. 1. Is it good to use one application for handeling many users. Do i need to have seperate instance of server running for each user. 2.In case of storing wallets of each user, where can I store them? can I generate and store user keys and wallets locally by the browser? Does anyone have a suggestion for that or any alternative secure method? Thank you.

arunwij (Thu, 09 Aug 2018 10:38:25 GMT):
Hi, I am planning to develop a web application based on Indy. This question is not specifically indy SDK related. But I am going to build the application on top of that. In my application, an agent server manages identity related task of multiple users and handle interactions with steward nodes. There is two questions. 1. Is it good to use one application for handeling many users. Do i need to have seperate instance of server running for each user. 2. In case of storing wallets of each user, where can I store them? can I generate and store user keys and wallets locally by the browser? Does anyone have a suggestion for that or any alternative secure method? Thank you.

arunwij (Thu, 09 Aug 2018 10:38:25 GMT):
Hi, I am planning to develop a web application based on Indy. In my application, an agent server manages identity related task of multiple users and handle interactions with steward nodes. There is two questions. 1. Is it good to use one agent server for handeling many users. Do i need to have seperate instance of server running for each user. 2. In case of storing wallets of each user, where can I store them? can I generate and store user keys and wallets locally by the browser? Does anyone have a suggestion for that or any alternative secure method? Thank you.

vtech (Thu, 09 Aug 2018 12:19:26 GMT):
Hi, I have started the network using docker (https://github.com/hyperledger/indy-sdk/blob/master/README.md#how-to-start-local-nodes-pool-with-docker).This generates the genesis transaction file in docker instance. Now to get the handle for the pool genesis file is required from indy-sdk api (indy-sdk api is invoked outside of docker container). How can I get hold of genesis transaction ? Or is there anyother way to get handle of pool ledger ? pool_config = json.dumps({'genesis_txn': genesis_file_path}) pool.create_pool_ledger_config(config_name=pool_name, config=pool_config) pool_handle = await pool.open_pool_ledger(config_name=pool_name, config=None) Thanks!

NataliaDracheva (Thu, 09 Aug 2018 12:54:32 GMT):
Has joined the channel.

Vlad (Thu, 09 Aug 2018 15:58:17 GMT):
Has joined the channel.

sklump (Thu, 09 Aug 2018 18:04:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=By8t5Taytqx6grug3) @Dominic The GE (aka >=) predicate supports only 32-bit (signed) integer attribute values. To compare age, you could store Date of Birth as EPOCH seconds at midnight on the day of, local time, then compare vs. current EPOCH time. That gives a range from 1901-12-13 through 2038-01-18, more or less.

sklump (Thu, 09 Aug 2018 18:04:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=By8t5Taytqx6grug3) @Dominic The `GE` (aka `>=`) predicate supports only 32-bit (signed) integer attribute values. To compare age, you could store Date of Birth as EPOCH seconds at midnight on the day of, local time, then compare vs. current EPOCH time. That gives a range from 1901-12-13 through 2038-01-18, more or less. @Artemkaaas or equally knowledgeable indy-sdk, kindly confirm or correct the notion that GE comparison works only on (signed) 32-bit ints? For example it won't work on floating-point numbers? @AxelNennker and I have been revisiting encoding/decoding.

sklump (Thu, 09 Aug 2018 18:04:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=By8t5Taytqx6grug3) @Dominic The `GE` (aka `>=`) predicate supports only 32-bit (signed) integer attribute values. To compare age, you could store Date of Birth as EPOCH seconds at midnight on the day of, local time, then compare vs. current EPOCH time. That gives a range from 1901-12-13 through 2038-01-18, more or less. @ashcherbakov or equally knowledgeable indy-sdk, kindly confirm or correct the notion that GE comparison works only on (signed) 32-bit ints? For example it won't work on floating-point numbers? @AxelNennker and I have been revisiting encoding/decoding.

sklump (Thu, 09 Aug 2018 18:04:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=By8t5Taytqx6grug3) @Dominic The `GE` (aka `>=`) predicate supports only 32-bit (signed) integer attribute values. To compare age, you could store Date of Birth as EPOCH seconds at midnight on the day of, local time, then compare vs. current EPOCH time. That gives a range from 1901-12-13 through 2038-01-18, more or less. @sergey.minaev or equally knowledgeable indy-sdk, kindly confirm or correct the notion that GE comparison works only on (signed) 32-bit ints? For example it won't work on floating-point numbers? @AxelNennker and I have been revisiting encoding/decoding.

sklump (Thu, 09 Aug 2018 18:04:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=By8t5Taytqx6grug3) @Dominic The `GE` (aka `>=`) predicate supports only 32-bit (signed) integer attribute values. To compare age, you could store Date of Birth as EPOCH seconds at midnight on the day of, local time, then compare vs. current EPOCH time. That gives a range from 1901-12-13 through 2038-01-18, more or less. @sergey.minaev or equally knowledgeable indy-sdk, kindly confirm or correct the notion that GE comparison works only on (signed) 32-bit ints? For example it won't work on floating-point numbers? @AxelNennker and I have been revisiting encoding/decoding and it touches on ordering as a topic.

sklump (Thu, 09 Aug 2018 18:04:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=By8t5Taytqx6grug3) @Dominic The `GE` (aka `>=`) predicate supports only 32-bit (signed) integer attribute values. To compare age, you could store Date of Birth as EPOCH seconds at midnight on the day of, local time, then compare vs. current EPOCH time. That gives a range from 1901-12-13 through 2038-01-18, more or less. @sergey.minaev or equally knowledgeable indy-sdk insider, kindly confirm or correct the notion that GE comparison works only on (signed) 32-bit ints? For example it won't work on floating-point numbers? @AxelNennker and I have been revisiting encoding/decoding and it touches on ordering as a topic.

stanleyc-trustscience (Thu, 09 Aug 2018 21:02:06 GMT):
Hi with the new indy-sdk, how do we not encrypt the wallet?

stanleyc-trustscience (Thu, 09 Aug 2018 21:02:30 GMT):
What value should I set credentials to? `wallet.create_wallet(pool_name, wallet_name, None, "{}", credentials)`

vtech (Fri, 10 Aug 2018 07:04:55 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kRPGDoiYZ9gYYQy8v) If somebody please can guide on this , any help on this is really appreciable.

andrewtan (Fri, 10 Aug 2018 08:02:37 GMT):

xnopre (Fri, 10 Aug 2018 09:34:12 GMT):
@vtech Perhaps you can use a `VOLUME` docker command to mount a "real" directory (on your host machine) to the docker container, where the genesis transaction file is generated. Than you can access this file outside of the container....

xnopre (Fri, 10 Aug 2018 09:34:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=TLM4HEsJrce4ZwHHn) @vtech Perhaps you can use a `VOLUME` docker command to mount a "real" directory (on your host machine) to the docker container, where the genesis transaction file is generated. Than you can access this file outside of the container...

xnopre (Fri, 10 Aug 2018 09:53:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=H4ou3JFafYgzQDh44) Hi all. Any idea to help me ? Do I have to store all DIDs in my own storage, for example a local database, including first "Steward" DID, DID for onboarding, etc... ? Thanks

vtech (Fri, 10 Aug 2018 10:17:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=BXzQPTDxgmEvj9ZNb) @xnopre So is it mandatory to have genesis file for opening the pool ledger ?

dkulic (Fri, 10 Aug 2018 10:17:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JhKQam7EN5yJ9cDhc) @xnopre Did you try to use `get_my_did_with_meta`

dkulic (Fri, 10 Aug 2018 10:17:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JhKQam7EN5yJ9cDhc) @xnopre Did you try to use `get_my_did_with_meta`?

sklump (Fri, 10 Aug 2018 10:28:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JhKQam7EN5yJ9cDhc) @xnopre You have to either (1) create a temporary wallet with the seed, read out the DID, and then delete the wallet, or (2) record the seed in metadata when creating the DID, then call did.list_dids_with_meta() to retrieve it on demand. Remember that seeds are like private keys. If you write them to metadata, make sure the wallet has access credentials.

sklump (Fri, 10 Aug 2018 10:28:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JhKQam7EN5yJ9cDhc) @xnopre You have to either (1) create a temporary wallet with the seed, read out the DID, and then delete the wallet, or (2) record identifying information such as the seed in metadata when creating the DID, then call did.list_dids_with_meta() to retrieve it on demand. Remember that seeds are like private keys. If you write them to metadata, make sure the wallet has access credentials.

sklump (Fri, 10 Aug 2018 10:28:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JhKQam7EN5yJ9cDhc) @xnopre You have to either (1) create a temporary wallet with the seed, read out the DID, and then delete the wallet, or (2) record identifying information such as the hashed seed in metadata when creating the DID, then call did.list_dids_with_meta() to retrieve it on demand. Remember that seeds are like private keys.

sklump (Fri, 10 Aug 2018 10:28:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JhKQam7EN5yJ9cDhc) @xnopre You have to either (1) create a temporary wallet with the seed, read out the DID, and then delete the temporary wallet, or (2) record identifying information such as the hashed seed in metadata after creating the DID while the operation knows both, then call did.list_dids_with_meta() to identify the DID to retrieve it on demand. Remember that seeds are like private keys.

marrowdev (Fri, 10 Aug 2018 14:19:36 GMT):
Does anyone know how the Onboarding process works for the initial from-to/to-from DID (pseudonym) exchange? How can this process be protected from someone intercepting the connection request and pretending to be the 'invitee'?

tomislav (Fri, 10 Aug 2018 14:23:39 GMT):
@marrowdev The connection establishment process encrypts all messages agent-to-agent, intercepting wouldn't compromise it. The initial invitiation/offer should be delivered via secure way in already established trusted environment. These protocols and concepts are discussed in great detail in #indy-agent channel.

marrowdev (Fri, 10 Aug 2018 14:25:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Xb7AHmhYLYyKx3ajv) @tomislav Thanks, I'll take a look

wightman (Fri, 10 Aug 2018 15:38:51 GMT):
vcx

esplinr (Fri, 10 Aug 2018 15:40:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Fz2PcSgMWxeooQj9t) @stanleyc-trustscience Can you help with this @dkulic

esplinr (Fri, 10 Aug 2018 15:40:58 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=tQqw8BspAjpTcPZWx) @stanleyc-trustscience @dkulic also this

dkulic (Fri, 10 Aug 2018 15:44:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=DFWKrAzHKxrZb3Wcz) @esplinr Hi Stachen, the answer is no, you cannot do that. In the new version of libindy there is no option of not encrypting the wallet. I am curious what would be your use-case for that?

stanleyc-trustscience (Fri, 10 Aug 2018 16:53:35 GMT):
@esplinr I want to see the content of `sqlite.db`. I used to be able to, before it was encrypted. I doing this mostly to learn what's really stored in the wallet. I guess another method is to decrypt the wallet. I'm using sqlitebrowser, it doesn't seem to have a way to decrypt the wallet content however. All column values are showing up as BLOB due to encryption

swcurran (Fri, 10 Aug 2018 16:59:12 GMT):
@dkulic @stanleyc-trustscience - +1 for a pluggable encryption method that can be used with the wallet so that a non-encrypted wallet can be used for development. We've had that request from our developers as well.

AxelNennker (Fri, 10 Aug 2018 19:20:34 GMT):
I just saw a 'Ledger merkle tree doesn't acceptable for current tree' while testing my Android Indy application when doing a Pool.openPoolLedger against the test pool running on my Ubuntu laptop. I found https://github.com/hyperledger/indy-sdk/issues/536 and saw that the IP addresses in the docker instance was 127.0.01 which did not match the IP address that I had put into the pool config on the Android phone. Phone and laptop are in the same wifi network. Locking at the docker file I saw the docker ARG pool_ip. I changed that when building the pool using: `docker build -f ci/indy-pool.dockerfile -t indy_pool --build-arg pool_ip=192.168.178.90 .` The output of the build still showed 127.0.0.1 but a check of the pool genesis file showed that the laptop IP correct. ``` ignisvulpis@namenlos:~/development/hyperledger/indy-sdk$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a2d809399109 indy_pool "/usr/bin/supervisord" 9 minutes ago Up 9 minutes 192.168.178.90:9701-9708->9701-9708/tcp brave_liskov ignisvulpis@namenlos:~/development/hyperledger/indy-sdk$ docker exec -it a2d809399109 bash indy@a2d809399109:/$ cat /var/lib/indy/sandbox/pool_transactions_genesis {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node1","blskey":"4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba","client_ip":"192.168.178.90","client_port":9702,"node_ip":"192.168.178.90","node_port":9701,"services":["VALIDATOR"]},"dest":"Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv"},"metadata":{"from":"Th7MpTaRZVRYnPiabds81Y"},"type":"0"},"txnMetadata":{"seqNo":1,"txnId":"fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62"},"ver":"1"} {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node2","blskey":"37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk","client_ip":"192.168.178.90","client_port":9704,"node_ip":"192.168.178.90","node_port":9703,"services":["VALIDATOR"]},"dest":"8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb"},"metadata":{"from":"EbP4aYNeTHL6q385GuVpRV"},"type":"0"},"txnMetadata":{"seqNo":2,"txnId":"1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc"},"ver":"1"} {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node3","blskey":"3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5","client_ip":"192.168.178.90","client_port":9706,"node_ip":"192.168.178.90","node_port":9705,"services":["VALIDATOR"]},"dest":"DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya"},"metadata":{"from":"4cU41vWW82ArfxJxHkzXPG"},"type":"0"},"txnMetadata":{"seqNo":3,"txnId":"7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4"},"ver":"1"} {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node4","blskey":"2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw","client_ip":"192.168.178.90","client_port":9708,"node_ip":"192.168.178.90","node_port":9707,"services":["VALIDATOR"]},"dest":"4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA"},"metadata":{"from":"TWwCRQRZ2ZHMJFn9TzLp7W"},"type":"0"},"txnMetadata":{"seqNo":4,"txnId":"aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008"},"ver":"1"} indy@a2d809399109:/$ ``` Now the pool is started using ` docker run -itd -p 192.168.178.90:9701-9708:9701-9708 indy_pool`

AxelNennker (Fri, 10 Aug 2018 19:20:34 GMT):
I just saw a 'Ledger merkle tree doesn't acceptable for current tree' while testing my Android Indy application when doing a Pool.openPoolLedger against the test pool running on my Ubuntu laptop. I found https://github.com/hyperledger/indy-sdk/issues/536 and saw that the IP addresses in the docker instance was 127.0.01 which did not match the IP address that I had put into the pool config on the Android phone. Phone and laptop are in the same wifi network. Locking at the docker file I saw the docker ARG pool_ip. I changed that when building the pool using: `docker build -f ci/indy-pool.dockerfile -t indy_pool --build-arg pool_ip=192.168.178.90 .` The output of the build still showed 127.0.0.1 but a check of the pool genesis file showed that the laptop IP is correct. ``` ignisvulpis@namenlos:~/development/hyperledger/indy-sdk$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a2d809399109 indy_pool "/usr/bin/supervisord" 9 minutes ago Up 9 minutes 192.168.178.90:9701-9708->9701-9708/tcp brave_liskov ignisvulpis@namenlos:~/development/hyperledger/indy-sdk$ docker exec -it a2d809399109 bash indy@a2d809399109:/$ cat /var/lib/indy/sandbox/pool_transactions_genesis {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node1","blskey":"4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba","client_ip":"192.168.178.90","client_port":9702,"node_ip":"192.168.178.90","node_port":9701,"services":["VALIDATOR"]},"dest":"Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv"},"metadata":{"from":"Th7MpTaRZVRYnPiabds81Y"},"type":"0"},"txnMetadata":{"seqNo":1,"txnId":"fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62"},"ver":"1"} {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node2","blskey":"37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk","client_ip":"192.168.178.90","client_port":9704,"node_ip":"192.168.178.90","node_port":9703,"services":["VALIDATOR"]},"dest":"8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb"},"metadata":{"from":"EbP4aYNeTHL6q385GuVpRV"},"type":"0"},"txnMetadata":{"seqNo":2,"txnId":"1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc"},"ver":"1"} {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node3","blskey":"3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5","client_ip":"192.168.178.90","client_port":9706,"node_ip":"192.168.178.90","node_port":9705,"services":["VALIDATOR"]},"dest":"DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya"},"metadata":{"from":"4cU41vWW82ArfxJxHkzXPG"},"type":"0"},"txnMetadata":{"seqNo":3,"txnId":"7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4"},"ver":"1"} {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node4","blskey":"2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw","client_ip":"192.168.178.90","client_port":9708,"node_ip":"192.168.178.90","node_port":9707,"services":["VALIDATOR"]},"dest":"4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA"},"metadata":{"from":"TWwCRQRZ2ZHMJFn9TzLp7W"},"type":"0"},"txnMetadata":{"seqNo":4,"txnId":"aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008"},"ver":"1"} indy@a2d809399109:/$ ``` Now the pool is started using ` docker run -itd -p 192.168.178.90:9701-9708:9701-9708 indy_pool` And the Android app connects to the pool on the laptop. Yeah!

AxelNennker (Fri, 10 Aug 2018 19:20:34 GMT):
I just saw a 'Ledger merkle tree doesn't acceptable for current tree' while testing my Android Indy application when doing a Pool.openPoolLedger against the test pool running on my Ubuntu laptop. I found https://github.com/hyperledger/indy-sdk/issues/536 and saw that the IP addresses in the docker instance was 127.0.01 which did not match the IP address that I had put into the pool config on the Android phone. Phone and laptop are in the same wifi network. Locking at the docker file I saw the docker ARG pool_ip. I changed that when building the pool using: `docker build -f ci/indy-pool.dockerfile -t indy_pool --build-arg pool_ip=192.168.178.90 .` The output of the build still showed 127.0.0.1 but a check of the pool genesis file showed that the laptop IP is correct. ``` ignisvulpis@namenlos:~/development/hyperledger/indy-sdk$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a2d809399109 indy_pool "/usr/bin/supervisord" 9 minutes ago Up 9 minutes 192.168.178.90:9701-9708->9701-9708/tcp brave_liskov ignisvulpis@namenlos:~/development/hyperledger/indy-sdk$ docker exec -it a2d809399109 bash indy@a2d809399109:/$ cat /var/lib/indy/sandbox/pool_transactions_genesis {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node1","blskey":"4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba","client_ip":"192.168.178.90","client_port":9702,"node_ip":"192.168.178.90","node_port":9701,"services":["VALIDATOR"]},"dest":"Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv"},"metadata":{"from":"Th7MpTaRZVRYnPiabds81Y"},"type":"0"},"txnMetadata":{"seqNo":1,"txnId":"fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62"},"ver":"1"} {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node2","blskey":"37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk","client_ip":"192.168.178.90","client_port":9704,"node_ip":"192.168.178.90","node_port":9703,"services":["VALIDATOR"]},"dest":"8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb"},"metadata":{"from":"EbP4aYNeTHL6q385GuVpRV"},"type":"0"},"txnMetadata":{"seqNo":2,"txnId":"1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc"},"ver":"1"} {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node3","blskey":"3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5","client_ip":"192.168.178.90","client_port":9706,"node_ip":"192.168.178.90","node_port":9705,"services":["VALIDATOR"]},"dest":"DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya"},"metadata":{"from":"4cU41vWW82ArfxJxHkzXPG"},"type":"0"},"txnMetadata":{"seqNo":3,"txnId":"7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4"},"ver":"1"} {"reqSignature":{},"txn":{"data":{"data":{"alias":"Node4","blskey":"2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw","client_ip":"192.168.178.90","client_port":9708,"node_ip":"192.168.178.90","node_port":9707,"services":["VALIDATOR"]},"dest":"4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA"},"metadata":{"from":"TWwCRQRZ2ZHMJFn9TzLp7W"},"type":"0"},"txnMetadata":{"seqNo":4,"txnId":"aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008"},"ver":"1"} indy@a2d809399109:/$ ``` Now the pool is started using ` docker run -itd -p 192.168.178.90:9701-9708:9701-9708 indy_pool` And the Android app connects to the pool on the laptop. Yeah! is

esplinr (Fri, 10 Aug 2018 21:40:38 GMT):
@stanleyc-trustscience We have discussed building a tool to do that in order to help with development and understanding of the system. But such a tool does not yet exist.

esplinr (Fri, 10 Aug 2018 21:42:16 GMT):
@swcurran I agree that it would be great to have such a tool in the ecosystem. We'll track requests for that to see if it is something we want to do, and I'll also look to see if someone else does it.

AxelNennker (Sat, 11 Aug 2018 06:33:55 GMT):
@swcurran Do you know why the readme.md suggests to create a docker network `docker network create --subnet 10.0.0.0/8 indy_pool_network` and then port mapping (only explained for macos) when the local pool could just be started on the local machines IP address so e.g. that clients, like an Android app, on the same network can reach it? I would suggest to remove the network creation and port mapping instruction from the readme.md and just bind the pool to the local machine's IP.

andrewtan (Sun, 12 Aug 2018 04:54:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=oZg2wXW7aHPhSx96D) Any help rendered will be much appreciated. I have not code for 10+ years and now trying to get myself reboot and do some coding with Indy. Thanks.

geethanisp (Sun, 12 Aug 2018 06:43:48 GMT):
how to connect indy_sdk for a remote indy network

AxelNennker (Sun, 12 Aug 2018 08:20:50 GMT):
@geethanisp look at the pool transactions genesis file of the pool. You need that info to connect to the pool. It includes IP addresses and public keys etc. Specifiy the txn in the pool config in your client

swcurran (Sun, 12 Aug 2018 18:36:41 GMT):
@AxelNennker - which readme.md are you talking about - I'd like to see that. My recommendation is always use docker to spin up the network - it's much easier and more reliable than trying to build things natively on whatever you happen to have. However, as you point out, one must always find out the IP of the Indy Nodes, including when they are run as docker containers. With docker, the IP platform dependent - different on Windows vs. Mac and Linux. We use a trick that the Codenvy people created to find get the IP address in a device independent way - `$(docker run --rm --net=host codenvy/che-ip)`. That prints out your docker IP address and you can use that in your genesis file. We use scripts to start all our instances so that the we can use that to get the right IP address regardless of the platform. That said, I'm not sure about Android development and what else is needed other than finding out and injecting the Indy Node IP address(es).

pimotte (Mon, 13 Aug 2018 06:39:13 GMT):
@swcurran https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker that readme

pimotte (Mon, 13 Aug 2018 06:46:18 GMT):
For android development the thing you need is the node ip to be accessible from the device, which as far as I understand is what you get using that subshell, but there's also the aside of docker networking not being everything you want it to be on (older) windows and MacOS.

xnopre (Mon, 13 Aug 2018 08:33:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mP7yEWjjjCj3XAecr) @sklump Thank you @sklump , I will take a look at this 2 ways for solution... :-)

AxelNennker (Mon, 13 Aug 2018 08:39:44 GMT):
@swcurran I proposed this PR https://github.com/hyperledger/indy-sdk/pull/1061 I grouped the test pool starting section with docker into 3 alternatives. First: just run the test pool on localhost. Second: use docker with your dev machine's IP address for the test pool. Third: creat a docker network and bind the pool to that.

AxelNennker (Mon, 13 Aug 2018 08:42:18 GMT):
I need this for Androd testing because the mobile phone and my dev machine are in the same (wifi) network - but Android is very relevant to making the test pool reachable from a client that is not on the same machine as the test pool

AxelNennker (Mon, 13 Aug 2018 08:42:18 GMT):
I need this for Androd testing because the mobile phone and my dev machine are in the same (wifi) network - but Android is NOT very relevant to making the test pool reachable from a client that is not on the same machine as the test pool

VitalijReicherdt (Mon, 13 Aug 2018 09:09:04 GMT):
can not find verkey

AxelNennker (Mon, 13 Aug 2018 09:18:30 GMT):
I need this for Androd testing because the mobile phone and my dev machine are in the same (wifi) network - but Android is NOT very relevant to making the test pool reachable from a client that is not on the same machine as the test pool

dkulic (Mon, 13 Aug 2018 12:36:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=2Fg5on2Cz4mWwA6Gt) @stanleyc-trustscience I see. There is an idea to allow pluggable encryption so that different encryption cyphers may be used. I do not know when this may became reality.

smithbk (Mon, 13 Aug 2018 17:04:35 GMT):
A verifier creates a proof request for a holder. Can anyone point me to sample code in which the holder converts the proof request to a human-readable format for approval? If there is no sample code, any recommendations are appreciated. Thanks

smithbk (Mon, 13 Aug 2018 17:09:55 GMT):
Or alternatively, how to convert the proof itself to something human-readable to display to the holder, so that the holder could decide whether to give the proof to the verifier.

sklump (Mon, 13 Aug 2018 18:26:39 GMT):
From von_anchor util.py, ``` def revealed_attrs(proof: dict) -> dict: """ Fetch revealed attributes from input proof and return dict mapping credential definition identifiers to dicts, each dict mapping attribute names to (decoded) values, for processing in further creds downstream. :param: indy-sdk proof as dict :return: dict mapping cred-ids to dicts, each mapping revealed attribute names to (decoded) values """ rv = {} for sub_index in range(len(proof['identifiers'])): cd_id = proof['identifiers'][sub_index]['cred_def_id'] rv[cd_id] = { attr: decode(proof['proof']['proofs'][sub_index]['primary_proof']['eq_proof']['revealed_attrs'][attr]) for attr in proof['proof']['proofs'][sub_index]['primary_proof']['eq_proof']['revealed_attrs'] } return rv ```

smithbk (Mon, 13 Aug 2018 18:32:01 GMT):
@sklump Thanks

coderintherye (Mon, 13 Aug 2018 18:47:02 GMT):
Has joined the channel.

animeshdas (Mon, 13 Aug 2018 21:47:52 GMT):
Hello, do we no longer need to register a custom wallet type before using it?

animeshdas (Mon, 13 Aug 2018 21:50:45 GMT):
The call https://github.com/hyperledger/indy-sdk/blob/master/wrappers/ios/libindy-pod/Indy/Wrapper/IndyWallet.h#L27 is no longer giving callback

animeshdas (Mon, 13 Aug 2018 21:51:51 GMT):
Also I checked the tests, and the tests that test the registerWalletType method, have been commented out https://github.com/hyperledger/indy-sdk/commit/3e1a64559af97f91a798f434ee8892691ccd1f65

animeshdas (Mon, 13 Aug 2018 21:52:34 GMT):
So does someone know if we still need to call `registerWalletType` or not?

xnopre (Tue, 14 Aug 2018 08:18:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ZPNBaJmK8NQsaQXKK) Thanks to @sklump , the (2) solution seems to be good, I can use `setDidMetadata` to set metadata, and then I can retrieve my DID using `listMyDidsWithMeta` and filtering on metadata. Great ! Thanks ! Now, I have a similar question for did/key created when onboarding (for example : Steward onboarding Faber), in a second run of my script, how can Steward retrieve all DIDs and keys from his wallet ? For `steward_faber_did / steward_faber_key`, I can use the same solution (based on metadata and using `setDidMetadata` and `listMyDidsWithMeta`. But what is the best solution to store and retrieve received `faber_steward_did` and `faber_steward_key` (in Steward side) ? Thanks

jakubkoci (Tue, 14 Aug 2018 11:52:12 GMT):
Has joined the channel.

xnopre (Tue, 14 Aug 2018 12:33:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=KCKuQFCPWniJsJZJX) I found a solution storing informations with `storeTheirDid` and `createPairwise` with my metadata string, and then, I can retrieve this informations with `listPairwise` and filtering on the metadata. Is it the good solution, or is there a best or good other solution ? Thanks

tomislav (Tue, 14 Aug 2018 13:00:44 GMT):
@animeshdas Wallet has an updated API for custom storage as of 1.5. See https://github.com/hyperledger/indy-sdk/blob/78cd7625a03c7a9d64d5d63e143eeb8344d59b0d/libindy/src/api/wallet.rs#L42

xnopre (Tue, 14 Aug 2018 14:33:53 GMT):
Hi all. In Alice story, Faber creates and stores a "Credential definition" using `issuerCreateAndStoreCredentialDef`+ `buildCredDefRequest`+ `signAndSubmitRequest` generating an `cred_def_id`like `DHcLEk2UvmLgd33N96K5az:3:CL:14:TAG1`. If I restart my Faber script, or if this credential definition already exists, how can I get the `cred_def_id` to then create a credential offer ? Perhaps using `buildGetCredDefRequest` but how to know the credential definition ID ("CDID") (needed to call this method) ? Or, after creation, do I have to store this "CDID" in a wallet or in my own storage (like DB) ? Thanks

tomislav (Tue, 14 Aug 2018 14:57:51 GMT):
@xnopre You have to store the ID somewhere. You can use the `non_seccrets` api to store data by type, and do a search on it. It's a key/value storage type

xnopre (Tue, 14 Aug 2018 15:33:20 GMT):
@tomislav Many thanks !! :thumbsup: :-D

animeshdas (Tue, 14 Aug 2018 18:08:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ZmXQ7rN4tZDXjKYcE) @tomislav Thanks @tomislav , so does that mean I still need to call registerWalletType method for custom wallet? Or is registerWalletTyper no longer needed to be called?

tomislav (Tue, 14 Aug 2018 18:11:41 GMT):
@animeshdas From what I can see (https://github.com/hyperledger/indy-sdk/blob/78cd7625a03c7a9d64d5d63e143eeb8344d59b0d/wrappers/ios/libindy-pod/Indy/Wrapper/IndyWallet.mm#L29) the iOS wrapper isn't updated to reflect the new API. This effectively means you can't register custom wallet type, can only use the default storage one. I can't say what the plan is for the wrapper update.

animeshdas (Tue, 14 Aug 2018 20:06:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=K7dNK5Hy4PTSyrD4Z) @tomislav I have logged an issue https://github.com/hyperledger/indy-sdk/issues/1073. will update this forum of any progress.

kdenhartog (Wed, 15 Aug 2018 00:26:59 GMT):
@gudkov @sergey.minaev is it there a reason we didn't implement encrypt_detached and decrypt_detached into `utils::crypto::xsalsa20`? I want to be able to get back the tags so I can format a JWE properly, but I see it requires an unsafe block, so I was hesitant to add this in.

smithbk (Wed, 15 Aug 2018 12:12:42 GMT):
Anyone, is there a way to determine the schema_id associated with a credential definition response from the ledger? I don't see a cred def id field. Here is a paired down version of a response: ```2018-08-15 11:56:02,868 DEBUG sign_and_submit_request: <<< res: '{"op":"REPLY","result":{"seqNo":33,"signature_type":"CL","state_proof":{"proof_nodes":"...","multi_signature":{"value":{"state_root_hash":"HcAoehHuuz198Yo1KsZWhS6whVzo6G5QeP2fNwBxPi2Z","timestamp":1534334039,"txn_root_hash":"25bcrVdueiBjNxZacKYepadLH5RoSpmSLWy8aEzVpgWd","pool_state_root_hash":"EnM3GHaGZt1UhDdeZtyQbpr3uv1EVzbBdXv3x533CaAk","ledger_id":1},"signature":"R3sAMTpVVQNGVAS3qDL66opjeSWe6di3g9tXLVAWzq38KxRqadGtfiUdVaQtA7nkeX8fPE4u96VuRge5TwY2MieVSdhySsAkVRSwiREhnscwBeXPSPPPqKE4o3VSmcaDFHt9kgMF9e6s9SVwH3kR6CbHqmvdH3A8WMQh62PVRQU7oM","participants":["Node3","Node1","Node4"]},"root_hash":"HcAoehHuuz198Yo1KsZWhS6whVzo6G5QeP2fNwBxPi2Z"},"identifier":"55sHq7Vgd1pTu1xNfQEKpK","txnTime":1534334039,"reqId":1534334162827212700,"origin":"4sLjDjiv87Fry1u74V7s3X","type":"108","tag":"TAG1","ref":31,"data":{"primary":{"rctxt":"...","n":"...","s":"...","z":"...","r":{"degree":"...","average":"...","first_name":"...","status":"...","year":"...","ssn":"...","last_name":"..."},"rms":"..."}}}}'```

smithbk (Wed, 15 Aug 2018 12:12:42 GMT):
Anyone, is there a way to determine the schema_id associated with a credential definition response from the ledger? I don't see a cred def id field. Here is a pared down version of a response: ```2018-08-15 11:56:02,868 DEBUG sign_and_submit_request: <<< res: '{"op":"REPLY","result":{"seqNo":33,"signature_type":"CL","state_proof":{"proof_nodes":"...","multi_signature":{"value":{"state_root_hash":"HcAoehHuuz198Yo1KsZWhS6whVzo6G5QeP2fNwBxPi2Z","timestamp":1534334039,"txn_root_hash":"25bcrVdueiBjNxZacKYepadLH5RoSpmSLWy8aEzVpgWd","pool_state_root_hash":"EnM3GHaGZt1UhDdeZtyQbpr3uv1EVzbBdXv3x533CaAk","ledger_id":1},"signature":"R3sAMTpVVQNGVAS3qDL66opjeSWe6di3g9tXLVAWzq38KxRqadGtfiUdVaQtA7nkeX8fPE4u96VuRge5TwY2MieVSdhySsAkVRSwiREhnscwBeXPSPPPqKE4o3VSmcaDFHt9kgMF9e6s9SVwH3kR6CbHqmvdH3A8WMQh62PVRQU7oM","participants":["Node3","Node1","Node4"]},"root_hash":"HcAoehHuuz198Yo1KsZWhS6whVzo6G5QeP2fNwBxPi2Z"},"identifier":"55sHq7Vgd1pTu1xNfQEKpK","txnTime":1534334039,"reqId":1534334162827212700,"origin":"4sLjDjiv87Fry1u74V7s3X","type":"108","tag":"TAG1","ref":31,"data":{"primary":{"rctxt":"...","n":"...","s":"...","z":"...","r":{"degree":"...","average":"...","first_name":"...","status":"...","year":"...","ssn":"...","last_name":"..."},"rms":"..."}}}}'```

sklump (Wed, 15 Aug 2018 12:26:49 GMT):
```await ledger.parse_get_cred_def_response(resp_json)``` Get something like ``` { "type": "CL", "value": { ... }, "ver": "1.0", "id": "LjgpST2rjsoxYegQDRm7EL:3:CL:15:0", "schemaId": "15", "tag": "0" } ``` Peel out `15` from `schemaId` or the next-to-last token in `id` Get transaction sequence number 15 Assemble schema ID from its txn ['metadata']['from'], ['metadata']['data']['name'], ['metadata']['data']['version'] = schema-issuer (origin) ID, name, version If you want, confirm via ledger.build_get_schema_request() ledger.parse_get_schema_response() schema_id is at `id`.

sklump (Wed, 15 Aug 2018 12:26:49 GMT):
`await ledger.parse_get_cred_def_response(resp_json)` Get something like ``` { "type": "CL", "value": { ... }, "ver": "1.0", "id": "LjgpST2rjsoxYegQDRm7EL:3:CL:15:0", "schemaId": "15", "tag": "0" } ``` Peel out `15` from `schemaId` or the next-to-last token in `id` Get transaction sequence number 15 Assemble schema ID from its txn ['metadata']['from'], ['metadata']['data']['name'], ['metadata']['data']['version'] = schema-issuer (origin) ID, name, version If you want, confirm via ledger.build_get_schema_request() ledger.parse_get_schema_response() schema_id is at `id`.

sergey.minaev (Wed, 15 Aug 2018 13:39:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=2amskTkneALxpEuQW) @kdenhartog I don't remember any special reason to not implement detached versions. Most probably it wasn't required by our use cases. I've briefly check it now and don't see where is it requires unsafe block. Could you reference me?

tomislav (Wed, 15 Aug 2018 13:42:19 GMT):
I managed to run the SDK on Xamarin.iOS. I'd like to create a PR and amend the dotnet SDK with a project to also build xamarin library for this. The build process however is dependent on having static libraries added as references in the project, to be able to even build it. Is this OK to include them in a libs directory along the wrapper? Or maybe just have the xamarin library availabel on NuGet and add a sample project using it. Thoughts?

sergey.minaev (Wed, 15 Aug 2018 13:44:51 GMT):
@gudkov ^

marrowdev (Wed, 15 Aug 2018 14:35:43 GMT):
Hi, I get an error when using did.store_their_did I get error 213, 'WalletItemAlreadyExists'. I am trying to store a pairwise did, and it isn't already stored in the wallet. Anyone got an idea what this means?

marrowdev (Wed, 15 Aug 2018 14:35:43 GMT):
Hi, when using did.store_their_did I get error 213, 'WalletItemAlreadyExists'. I am trying to store a pairwise did, and it isn't already stored in the wallet. Anyone got an idea what this means?

tomislav (Wed, 15 Aug 2018 14:37:02 GMT):
Are you calling did.key_for_did before calling store_their_did?

marrowdev (Wed, 15 Aug 2018 14:38:21 GMT):
Yes, in the line before store_their_did

tomislav (Wed, 15 Aug 2018 14:39:18 GMT):
I found this actually stores their did already. This wasn't the case some versions ago, but now it does. So just skip the call to store_their_did, since it's already there

marrowdev (Wed, 15 Aug 2018 14:41:03 GMT):
The issue then is when I call set_did_metadata for the same did, I get 'WalletItemNotFound'

tomislav (Wed, 15 Aug 2018 14:43:10 GMT):
Interesting. Maybe a bug in the SDK? Perhaps someone on the dev team can shed some light on this. A workaround I guess would be to store the metadata using non_secrets API.

Dominic (Wed, 15 Aug 2018 17:23:16 GMT):
I noticed that wallets change between libindy 1.4 and 1.5. I'd like to get a better understanding of what was changed. Is the data the same, but encrypted? If so, is it possible for me, as the creator of the wallet (in v1.5+) to see the _unencrypted_ stored values?

n3m (Wed, 15 Aug 2018 17:27:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=YQyedb3PQxAsbhRHw) @Dominic @Dominic This document describes how the wallet works now: https://github.com/hyperledger/indy-hipe/tree/master/text/0013-wallets. It stores the same data as the previous wallet, just in a different way, and with a different encryption schema. Right now there is no way to have a unencrypted wallet, but that is something that is on the `indy-sdk` roadmap.

n3m (Wed, 15 Aug 2018 17:27:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=YQyedb3PQxAsbhRHw) @Dominic This document describes how the wallet works now: https://github.com/hyperledger/indy-hipe/tree/master/text/0013-wallets. It stores the same data as the previous wallet, just in a different way, and with a different encryption schema. Right now there is no way to have a unencrypted wallet, but that is something that is on the `indy-sdk` roadmap.

swcurran (Wed, 15 Aug 2018 17:29:38 GMT):
@Dominic - Here is a link to the wallet details - https://github.com/hyperledger/indy-hipe/tree/master/text/0013-wallets Currently, there is no way to get the unencrypted values put into the wallet. There is some discussion of having a null-encryption implementation for testing, but it's not there now.

swcurran (Wed, 15 Aug 2018 17:29:58 GMT):
What @n3m said :-)

Dominic (Wed, 15 Aug 2018 17:31:31 GMT):
Thanks @n3m and @swcurran

jacobsaur (Wed, 15 Aug 2018 18:47:44 GMT):
Has joined the channel.

ShivVenkatraman (Thu, 16 Aug 2018 01:34:40 GMT):
I am a Indy newbie. I managed to have a node up and runny locally on Ubuntu with the steps in https://github.com/hyperledger/indy-node/blob/master/docs/start-nodes.md. Can some please post steps to run the Java sample program on Ubuntu (https://github.com/hyperledger/indy-sdk/tree/master/samples/java). I would like to just create a wallet via a Java program and check if the local node is running

AvikHazra (Thu, 16 Aug 2018 06:32:48 GMT):
hello, I`m trying to create credential schema with issuerCreateSchema. sometime it returns schema with seqNo but mostly it return schema with seqNo NULL. Can anyone please help me what is wrong ?

baconsandwich (Thu, 16 Aug 2018 07:56:07 GMT):
I am trying to follow the [python write-did-and-query-verkey tutorial](https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/write-did-and-query-verkey/python/README.md) and get the following error message: ``` $ RUST_LOG=debug python indy-test/indy-test.py 1. Create new pool ledger configuration to connect to ledger. INFO|command_executor | src/commands/mod.rs:75 | Worker thread started INFO|indy::commands | src/commands/mod.rs:115 | PoolCommand command received INFO|pool_command_executor | src/commands/pool.rs:57 | Create command received DEBUG|indy::commands::pool | src/commands/pool.rs:139 | create >>> name: "indy-test-0", config: Some("{\"genesis_txn\": \"/home/user/repositories/indy-sdk/cli/docker_pool_transactions_genesis\"}") ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Pool ledger config already exists Pool ledger config file with name "indy-test-0" already exists _indy_loop_callback: Function returned error 306 INFO|indy::commands | src/commands/mod.rs:115 | PoolCommand command received INFO|pool_command_executor | src/commands/pool.rs:61 | Delete command received DEBUG|indy::commands::pool | src/commands/pool.rs:149 | delete >>> name: "indy-test-0" DEBUG|indy::commands::pool | src/commands/pool.rs:153 | delete << res: () INFO|indy::commands | src/commands/mod.rs:115 | PoolCommand command received INFO|pool_command_executor | src/commands/pool.rs:57 | Create command received DEBUG|indy::commands::pool | src/commands/pool.rs:139 | create >>> name: "indy-test-0", config: Some("{\"genesis_txn\": \"/home/user/repositories/indy-sdk/cli/docker_pool_transactions_genesis\"}") DEBUG|indy::commands::pool | src/commands/pool.rs:143 | create << res: () 2. Open ledger and get handle INFO|indy::commands | src/commands/mod.rs:115 | PoolCommand command received INFO|pool_command_executor | src/commands/pool.rs:132 | SetProtocolVersion command received DEBUG|indy::commands::pool | src/commands/pool.rs:228 | set_protocol_version >>> version: 2 DEBUG|indy::commands::pool | src/commands/pool.rs:237 | set_protocol_version <<< INFO|indy::commands | src/commands/mod.rs:115 | PoolCommand command received INFO|pool_command_executor | src/commands/pool.rs:65 | Open command received DEBUG|indy::commands::pool | src/commands/pool.rs:159 | open >>> name: "indy-test-0", config: None DEBUG|indy::commands::pool | src/commands/pool.rs:174 | open <<< DEBUG|indy::services::pool::networker| src/services/pool/networker.rs:331 | _get_socket: open new socket for node 0 DEBUG|indy::services::pool::networker| src/services/pool/networker.rs:331 | _get_socket: open new socket for node 1 DEBUG|indy::services::pool::networker| src/services/pool/networker.rs:331 | _get_socket: open new socket for node 2 DEBUG|indy::services::pool::networker| src/services/pool/networker.rs:331 | _get_socket: open new socket for node 3 DEBUG|zmq |/home/indy/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-0.8.2/src/lib.rs:503 | socket dropped DEBUG|zmq |/home/indy/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-0.8.2/src/lib.rs:503 | socket dropped DEBUG|zmq |/home/indy/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-0.8.2/src/lib.rs:503 | socket dropped DEBUG|zmq |/home/indy/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-0.8.2/src/lib.rs:503 | socket dropped DEBUG|zmq |/home/indy/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-0.8.2/src/lib.rs:410 | context dropped INFO|indy::commands | src/commands/mod.rs:115 | PoolCommand command received INFO|indy::commands::pool | src/commands/pool.rs:69 | OpenAck handle 1, pool_id 1, result Err(Timeout) ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Timeout _indy_loop_callback: Function returned error 307 Error occurred: ErrorCode.PoolLedgerTimeout ``` Can you give me some hints of what could be the problem or how to debug this further? I have had no experience with Rust yet?

sergey.minaev (Thu, 16 Aug 2018 08:01:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=hxtmrWrBqKJHaFTJG) @marrowdev Current version of IndySDK doesn't allow to store DID metadata for TheirDid If I understand your case correctly you already have TheirDid entity in the wallet but don't have this DID as MyDID. If you actually operate with pairwise - take a look on pairwise API. Here you can specify pairwise. TheirDid will be used as primary key. Also this API allow to set metadata for this pairwise

sergey.minaev (Thu, 16 Aug 2018 08:01:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=hxtmrWrBqKJHaFTJG) @marrowdev Current version of IndySDK doesn't allow to store DID metadata for TheirDid. There is an issue in our JIRA https://jira.hyperledger.org/browse/IS-872 and we even have a hotfix for it. But there is no final decision is current or fixed behavior is more correct. If I understand your case correctly you already have TheirDid entity in the wallet but don't have this DID as MyDID. If you actually operate with pairwise - take a look on pairwise API. Here you can specify pairwise. TheirDid will be used as primary key. Also this API allow to set metadata for this pairwise

sergey.minaev (Thu, 16 Aug 2018 08:01:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=hxtmrWrBqKJHaFTJG) @marrowdev Current version of IndySDK doesn't allow to store DID metadata for TheirDid. There is an issue in our JIRA https://jira.hyperledger.org/browse/IS-872 and we even have a hotfix for it. But there is no final decision is current or fixed behavior more correct. If I understand your case correctly you already have TheirDid entity in the wallet but don't have this DID as MyDID. If you actually operate with pairwise - take a look on pairwise API. Here you can specify pairwise. TheirDid will be used as primary key. Also this API allow to set metadata for this pairwise

sergey.minaev (Thu, 16 Aug 2018 08:03:37 GMT):
@baconsandwich please take a look on https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker there is helpful hint in the 2nd point here (applicable for any usecases) > To connect to the pool the IP addresses in /var/lib/indy/sandbox/pool_transactions_genesis (in docker) and the pool configuration you use in your mobile app must match.

baconsandwich (Thu, 16 Aug 2018 09:00:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ZBjWXzdvBzZM25JrJ) @sergey.minaev thank you very much, that was the cause

baconsandwich (Thu, 16 Aug 2018 09:01:37 GMT):
although I am stuck at wallet.create_wallet() now. the tutorial seems to assume five parameters but the method now only has two. will need to figure out how to do this myself

sergey.minaev (Thu, 16 Aug 2018 09:20:54 GMT):
@baconsandwich HowTos doesn's supported by core team and may be outdated against actual code. But for wallet we already have PR with update: https://github.com/hyperledger/indy-sdk/pull/1066/files

baconsandwich (Thu, 16 Aug 2018 09:28:08 GMT):
is there another source, something like a referece documentation except the doc in the methods themselves?

sergey.minaev (Thu, 16 Aug 2018 09:53:53 GMT):
There is migration guides about API changes between stable versions. For with wallet's changes you can check https://github.com/hyperledger/indy-sdk/blob/master/doc/migration-guide-1.5.0-1.6.0.md#wallet-api

sergey.minaev (Thu, 16 Aug 2018 09:53:53 GMT):
There is migration guides about API changes between stable versions. For latest wallet's changes you can check https://github.com/hyperledger/indy-sdk/blob/master/doc/migration-guide-1.5.0-1.6.0.md#wallet-api

baconsandwich (Thu, 16 Aug 2018 10:14:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=tDBiZKvS2pRQv5DXE) @sergey.minaev thank you, I will check them out

xnopre (Thu, 16 Aug 2018 12:45:16 GMT):
Hi all :-) . I try to rewrite the "Alice" script in NodeJs with different processes for each actor. To send request for "Job-Application Proof" to Alice, Acme need to known the `faber_transcript_cred_def_id`. In the Python script, there is only one script, so that the `faber_transcript_cred_def_id` is known and "shared". In separated processes, like in "real life", how can Acme know or retrieve this `faber_transcript_cred_def_id`: 1) Should Faber send (for example via HTTP or socket) this ID ? 2) Can Acme retrieve this ID from ledger ? 3) other way ? Thanks for your help :-)

pimotte (Thu, 16 Aug 2018 12:58:38 GMT):
@xnopre It's number 1 :) Because the fact that Acme filters on that cred_def_id means that they specify "We only accept this origin", so they would at least have some sort of connection to Faber in the real world

xnopre (Thu, 16 Aug 2018 13:28:09 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Z2GShref9RJcBRFot) @pimotte Hi @pimotte , thank you for your answer ! :-) . I will do like that, but I asked me if there would be a solution for Acme to retrieve this ID from ledger ?

xnopre (Thu, 16 Aug 2018 13:28:09 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Z2GShref9RJcBRFot) Hi @pimotte , thank you for your answer ! :-) . I will do like that, but I asked me if there would be a solution for Acme to retrieve this ID from ledger ?

ShivVenkatraman (Thu, 16 Aug 2018 19:09:06 GMT):
I have an indy_node running on Ubuntu with 'start_indy_node' using the instructions in https://github.com/hyperledger/indy-node/blob/master/docs/start-nodes.md. I tried to run the sample program from 'https://github.com/hyperledger/indy-sdk/tree/master/samples/java/' and I get the following error: "java -classpath ../indy-sdk-java-sample-0.0.1.jar:../dependency/indy-1.5.0-dev -625.jar:../dependency/jna-4.4.0.jar:../dependency/json-20160810.jar:../dependency/hamcrest-core-1.3.jar:../dependency/commons-io-2.5.jar:../dependency/commons-lang3-3.5.jar Main Anoncreds sample -> started CURVE I: cannot open client HELLO -- wrong server key? CURVE I: cannot open client HELLO -- wrong server key? CURVE I: cannot open client HELLO -- wrong server key? CURVE I: cannot open client HELLO -- wrong server key? CURVE I: cannot open client HELLO -- wrong server key?" Where do I specify the server key from the Java client program?

smithbk (Thu, 16 Aug 2018 21:08:47 GMT):
I have some questions about the master secret. Is the user required to remember or store it in order to reuse it each time the wallet is opened? Or suppose I generate a unique master secret each time I open my wallet by calling `indy_prover_create_master_secret` with a null `master_secret_id`. What are the consequences of doing this? Thanks

swcurran (Thu, 16 Aug 2018 22:06:32 GMT):
@smithbk - a link secret (the new name of "master secret") is used to prove that each credential you have was issued to you. Every time you request a credential be issued to it, a bit of crypto, based on the link secret, is given to the Issuer, and they in turn embed that in the Credential. When you Prove a credential, you use the link secret to prove that you own the link secret associated with that Credential. That's what proves it was issued to you. If you want to be able to prove in a single Proof that all the claims from different Credentials were all Issued to you, you must use the same Link Secret for all of them. So with that - the Link Secret needs to be created once, stored and reused each time you Request a Credential and create a Proof. It's really important that you hold on to it.

swcurran (Thu, 16 Aug 2018 22:06:32 GMT):
@smithbk - a link secret (the new name of "master secret") is used to prove that each credential you have was issued to you. Every time you request a credential be issued to you, a bit of crypto, based on your link secret, is given to the Issuer (a blinded link secret), and the Issuer in turn embeds that crypto in the Credential. When you Prove a claim from the Credential, you use the link secret to prove that you own the link secret associated with that Claim. That's what proves the cliaim was "issued to you". If you want to be able to prove in a single Proof that all the claims from different Credentials were all Issued to you, you must use the same Link Secret for all of them. So with that - the Link Secret needs to be created once, stored and reused each time you Request a Credential and create a Proof. It's really important that you hold on to it.

xnopre (Fri, 17 Aug 2018 08:43:10 GMT):
@swcurran Thank you for this interesting explications ! :-) I have some questions : 1/ It seems to be a new name, renaming "master secret" by "link secret" : will the SDK be migrated ? which version ? 2/ Where do we store this link secret ? In the wallet ? If so, with which method ? Thanks

sergey.minaev (Fri, 17 Aug 2018 10:40:53 GMT):
@xnopre link(master) secret is stored in the wallet and identified by ID. If you pass specific ID in create call it will be used. If you pass null - it will be generated by libindy and returned as result. You have to use same ID for future calls for the Prover

sergey.minaev (Fri, 17 Aug 2018 10:40:53 GMT):
@xnopre link(master) secret is stored (during `indy_prover_create_master_secret`) in the wallet and identified by ID. If you pass specific ID in create call it will be used. If you pass null - it will be generated by libindy and returned as result. You have to use same ID (your or generated) for future calls for the Prover

sergey.minaev (Fri, 17 Aug 2018 10:40:53 GMT):
@xnopre link(master) secret is stored (during `indy_prover_create_master_secret`) in the wallet and identified by ID. If you pass specific ID into create call it will be used. If you pass null - it will be generated by libindy and returned as result. You have to use same ID (your or generated) for future calls for the Prover

gudkov (Fri, 17 Aug 2018 10:54:55 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=rKZXtuQHw8sb32h6X) @xnopre link secret is a generic name of secret attribute in CL crypto. master secret is a name of link secret used to link multiple credentials to one identity. We don't have plan to rename it, but in the future new link secrets can be added to credentials. For example, to link credential to edge device.

vtech (Fri, 17 Aug 2018 11:25:55 GMT):
Hi, is there any way to use Indy as login management for fabric ?

smithbk (Fri, 17 Aug 2018 11:56:56 GMT):
@vtech Not currently, but I have been thinking of enhancing the fabric-ca-server to allow enrollment based on an indy verification flow. As such, the fabric-ca-server would become a sort-of middleman in converting an indy proof into an x509 cert which would be usable in fabric

xnopre (Fri, 17 Aug 2018 11:57:13 GMT):
@sergey.minaev @gudkov Thanks for your answers ! My master secret is generated (I call `indy_prover_create_master_secret` with `null`). For future uses, I don't see method to retrieve this key from my wallet. Do I have to store it manually, in my own other storage, or in the wallet using `non_secrets` ?

gudkov (Fri, 17 Aug 2018 12:02:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=tGcAbPqA27XzMJojR) @xnopre indy_prover_create_master_secret returns identifier of the secret stored already in a secure wallet. You will need this identifier for credential request creation.

sergey.minaev (Fri, 17 Aug 2018 12:03:10 GMT):
So this identifier can be stored anywhere as it's not sensitive information

sergey.minaev (Fri, 17 Aug 2018 12:03:10 GMT):
So this identifier (master secret name) can be stored anywhere as it's not sensitive information. But master secret itself is sensitive data and can't be fetched from the wallet

smithbk (Fri, 17 Aug 2018 12:06:47 GMT):
@swcurran @gudkov @sergey.minaev Thanks for info on link secret

marrowdev (Fri, 17 Aug 2018 15:30:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nStv4g7aqfMoXJPer) @sergey.minaev Thanks! The pairwise API seems to be exactly what I was looking for

PatrikStas (Mon, 20 Aug 2018 03:04:07 GMT):
Has joined the channel.

PatrikStas (Mon, 20 Aug 2018 03:06:12 GMT):
Hi everyone. I am starting to play around with indy sdk, but I have series of questions. I am running indy pool locally as docker container. I’ll start with my first question about genesis file: - When I run indy-cli and run `pool create` or `create_pool_ledger_config` with SDK, what is this really doing? It’s just way of supplying information to the client/sdk about where the pool runs and what it looks like? Or is this action actually submitting some sort of genesis transactions to ledger, as the name of the file and its structure actually suggests?

PatrikStas (Mon, 20 Aug 2018 06:42:46 GMT):
Looking at rust code, it seems like it only creates local configuration for the sdk - At point of `create` operation, sdk does not interact with the ledger, right? Now this leaves me a bit puzzled. For instance, in the `docker_pool_transactions_genesis` provided in SDK repo, the example Genesis file which I am supposed to use with dockerized indy pool, contains very specific pieces of data, such as ``` "services":["VALIDATOR"]},"dest":"Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv"},"metadata":{"from":"Th7MpTaRZVRYnPiabds81Y"},"type":"0"},"txnMetadata":{"seqNo":1,"txnId":"fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62"} ``` If this is not actually submitted to ledger on the `pool create` operation, does it mean that this transaction data was already included in the docker instance of indy ledger and genesis file provided to SDK is only supposed to match those initial transactions?

andrewtan (Mon, 20 Aug 2018 07:29:44 GMT):
Hi, I was following the steps on the example found under https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/write-did-and-query-verkey/python/README.md.

andrewtan (Mon, 20 Aug 2018 07:31:07 GMT):
However, I have faced the following error message"line 17, in from indy import pool, ledger, wallet, did ModuleNotFoundError: No module named 'indy'"

andrewtan (Mon, 20 Aug 2018 07:31:22 GMT):
Any idea what I have done wrong?

xnopre (Mon, 20 Aug 2018 08:04:19 GMT):
@andrewtan Which language, which step, which file ? ;-)

sergey.minaev (Mon, 20 Aug 2018 08:32:58 GMT):
@PatrikStas > what is this really doing? create just verify format of file with genesis transactions and copy it from user location to internal. > It’s just way of supplying information to the client/sdk about where the pool runs and what it looks like? yes > At point of `create` operation, sdk does not interact with the ledger, right? yes > If this is not actually submitted to ledger on the `pool create` operation, does it mean that this transaction data was already included in the docker instance of indy ledger and genesis file provided to SDK is only supposed to match those initial transactions? exactly. These genesis transactions (for pool ledger) contain information about nodes in the pool. Later (at open/connect operation) SDK read genesis, connect to nodes and obtain updates about nodes (new nodes, changed addresses or keys, etc).

andrewtan (Mon, 20 Aug 2018 08:46:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5SACd3JWoJ4H5AcPm) @xnopre I am doing it in Python. I have followed through the various steps to understand the codes before running the script, i.e. write_DID.py

sergey.minaev (Mon, 20 Aug 2018 09:01:59 GMT):
@andrewtan have you installed python wrapper from SDK? https://github.com/hyperledger/indy-sdk/tree/master/wrappers/python#indy-sdk-for-python

andrewtan (Mon, 20 Aug 2018 09:06:07 GMT):
Yes I did. I have done the native compilation following the steps for Mac OS

andrewtan (Mon, 20 Aug 2018 09:06:38 GMT):
And the pip install python3-Indy is fine

sergey.minaev (Mon, 20 Aug 2018 10:13:50 GMT):
@andrewtan I suggest to double-check your environment. The error sounds like the environment where you try run sample haven't python3-indy wrapper installed in it (python virtual env? sudo/root/user ? pip2 vs pip3?).

PatrikStas (Mon, 20 Aug 2018 10:58:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=2JoFiRiXjvHFKR8fR) @sergey.minaev @sergey.minaev Thanks a lot! If that's so, I have at least 2 more questions about genesis in context of docker instance of indy pool. 1. According to the docker genesis file, the pool by default contains 4 transactions, each containing following piece`"services":["VALIDATOR"]`. I suppose these 4 transactions grants VALIDATOR roles, right? What does VALIDATOR in this vocabulary means? It's not matching roles described in https://docs.google.com/spreadsheets/d/1TWXF7NtBjSOaUIBeIH77SyZnawfo91cJ_ns4TR-wsq4/edit#gid=0 2. Another part of these transactions which is unclear to me is this: ``` "client_ip":"10.0.0.2","client_port":9702,"node_ip":"10.0.0.2","node_port":9701, ``` Well, I guess what it's saying is that the indy node with the fore-mentioned `VALIDATOR` role is the services exposed on port 9701. But what is the client on port 9702?

PatrikStas (Mon, 20 Aug 2018 10:58:00 GMT):
@sergey.minaev Thanks a lot! If that's so, I have at least 2 more questions about genesis in context of docker instance of indy pool. 1. According to the docker genesis file, the pool by default contains 4 transactions, each containing following piece`"services":["VALIDATOR"]`. I suppose these 4 transactions grants VALIDATOR roles, right? What does VALIDATOR in this vocabulary means? It's not matching roles described in https://docs.google.com/spreadsheets/d/1TWXF7NtBjSOaUIBeIH77SyZnawfo91cJ_ns4TR-wsq4/edit#gid=0 2. Another part of these transactions which is unclear to me is this: ``` "client_ip":"10.0.0.2","client_port":9702,"node_ip":"10.0.0.2","node_port":9701, ``` Well, I guess what it's saying is that the indy node with the fore-mentioned `VALIDATOR` role is the services exposed on port 9701. But what is the client on port 9702?

PatrikStas (Mon, 20 Aug 2018 10:58:00 GMT):
@sergey.minaev Thanks a lot! If that's so, I have at least 2 more questions about genesis in context of docker instance of indy pool. 1. According to the docker genesis file, the pool by default contains 4 transactions, each containing following piece `"services":["VALIDATOR"]`. I suppose these 4 transactions grants VALIDATOR roles, right? What does VALIDATOR in this vocabulary means? It's not matching roles described in https://docs.google.com/spreadsheets/d/1TWXF7NtBjSOaUIBeIH77SyZnawfo91cJ_ns4TR-wsq4/edit#gid=0 2. Another part of these transactions which is unclear to me is this: ``` "client_ip":"10.0.0.2","client_port":9702,"node_ip":"10.0.0.2","node_port":9701, ``` Well, I guess what it's saying is that the indy node with the fore-mentioned `VALIDATOR` role is the services exposed on port 9701. But what is the client on port 9702?

PatrikStas (Mon, 20 Aug 2018 10:58:00 GMT):
@sergey.minaev Thanks a lot! If that's so, I have at least 2 more questions about genesis in context of docker instance of indy pool. 1. According to the docker genesis file, the pool by default contains 4 transactions, each containing following piece `"services":["VALIDATOR"]`. I suppose these 4 transactions grants VALIDATOR roles, right? What does VALIDATOR in this vocabulary means? It's not matching roles described in https://docs.google.com/spreadsheets/d/1TWXF7NtBjSOaUIBeIH77SyZnawfo91cJ_ns4TR-wsq4/edit#gid=0 2. Another part of these transactions which is unclear to me is this: ``` "client_ip":"10.0.0.2","client_port":9702,"node_ip":"10.0.0.2","node_port":9701 ``` Well, I guess what it's saying is that the indy node with the fore-mentioned `VALIDATOR` role is the services exposed on port 9701. But what is the client on port 9702?

sergey.minaev (Mon, 20 Aug 2018 12:07:58 GMT):
@PatrikStas please ask in #indy-node channel about documentation about roles in pool ledger. In short: validators are nodes which handle write requests. Node2Node communication and Node2Client communication can be performed via different networks => different Host Address => different fields in transaction.

sklump (Mon, 20 Aug 2018 12:24:17 GMT):
Hello, At present the fixture for wallet credentials in `indy-sdk/wrappers/python/tests/conftest.py`; i.e., `'{"key":"key", "key_derivation_method": "ARAGON2I_INT"}'`, doesn't work with the test code: ``` test_interaction.py ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid structure: Can't derive key: Invalid structure: Errno { code: 22, description: Some("Invalid argument") } WARNING:indy.libindy:_indy_loop_callback: Function returned error 113 ``` Taking out the key derivation method and allowing it to default restores test operation. I have version 1.6.2-dev-713 installed.

sergey.minaev (Mon, 20 Aug 2018 12:25:02 GMT):
@Artemkaaas ^

Christian (Mon, 20 Aug 2018 20:48:22 GMT):
Hi. I have setup IndyNode network and a Steward. I want to onboard Faber as a trust anchor, i have Faber as a separate VM, i havent been able to find any documentation on how exactly to generate a connection request from Steward and how to send back the Connection response from Faber to Steward. Any help

andrewtan (Tue, 21 Aug 2018 02:56:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jjvWT856fKc65zjGp) @sergey.minaev Now I am really lost. I am running the code within PyCharm. Does that mean I need to do something different?

sergey.minaev (Tue, 21 Aug 2018 07:32:12 GMT):
@andrewtan in pycharm I suggest to create separate virtual environment based on python 3.5 and install python3-indy into it.

MaheshSharma (Tue, 21 Aug 2018 12:12:23 GMT):
Has joined the channel.

PhillipGibb (Tue, 21 Aug 2018 13:34:31 GMT):
Hi, a question about Information Sharing Agreements or Consent Proofs. I assume that they can be treated in the same way as credentials/proofs in that there will be a schema associated with them and can be revoked but : 1. they are stored on the ledger (there is no info other than the list of entities pertaining to the agreement) 2. They are multi signed because agreements are between 2 parties or is there no distinction between a sharing agreement and an accepted request for proof? I add the word accepted because a request for proof needs to be accepted first before there can be an agreement between parties that can expire or be revoked

Aschi (Tue, 21 Aug 2018 14:14:00 GMT):
Hello, Im rewriting the Python "How To's" to NodeJS and using the Sovrin test network since these are missing but I keep stumbling on the PoolLedgerTimeout error. Its possible to retrieve something from the sovrin network but I keep getting the Timeout error when I try sending for example a gym request to it. I tried all the genesis files on the stable sovrin branch and an old one that I found on the sovrin forum (https://forum.sovrin.org/t/indyerror-poolledgertimeout-when-connecting-to-sovrin-sandbox-network/820/4) but none of these seem to work. Anyone that can help me with this?

Dominic (Tue, 21 Aug 2018 14:29:03 GMT):
Hi, This is probably a dumb question, but what prevents someone from impersonating my DID? From what I can tell, we can specify a DID with `(did, verkey) = await did.create_and_store_my_did(wallet, '{"did": "DominicsDID"}')`, so how does it identify me personally?

sklump (Tue, 21 Aug 2018 14:32:11 GMT):
Your wallet contains the private key that (cryptographically verifiably) corresponds to your DID. Your wallet credentials control the opening of your wallet. So (only) whoever has your wallet credentials can be you. The indy-sdk operations that require your private key take a handle to your wallet, which must already be open.

Dominic (Tue, 21 Aug 2018 14:34:35 GMT):
Is my DID my "public key"? If so, I don't understand what prevents someone else from running `create_and_store_my_did` as done above with their own `wallet`.

sklump (Tue, 21 Aug 2018 14:41:17 GMT):
Your DID is either your public key or else its first 21-or-22 binhex-encoded characters.

sklump (Tue, 21 Aug 2018 14:41:17 GMT):
Your DID is either your public key or else the first 21-or-22 hex digits of its binhex encoding.

sklump (Tue, 21 Aug 2018 14:41:17 GMT):
Your DID is either your public key or else the first 21-or-22 hex digits of its base58 encoding.

sklump (Tue, 21 Aug 2018 14:42:57 GMT):
Generating your DID from scratch would mean Oscar would need to get your cryptographic seed. Do protect your cryptographic seed as private data.

Dominic (Tue, 21 Aug 2018 14:56:15 GMT):
I guess what I'm asking is what happens when you specify the DID upfront on creation `did.create_and_store_my_did(wallet, '{"did": "VsKV7grR1BUE29mG2Fm2kX"}')`. The documentation says "if provided, then keys will be replaced - key rotation use case)" - I don't really know what that means. How can you specify a DID if you don't know the corresponding private key? If I had to guess, I'd say something on the public ledger probably says how to verify a DID owner's identity.

sklump (Tue, 21 Aug 2018 15:03:54 GMT):
I don't know, actually! After all this time!

Dominic (Tue, 21 Aug 2018 15:21:25 GMT):
In that case, I'll let you know if I find out :upside_down:

tomislav (Tue, 21 Aug 2018 15:25:04 GMT):
The DID is a base58 of the first 32 (I think) bytes of the verkey. If you specify it in the create_and_store, it will use that DID, instead deriving it from the verkey. But... I think the documentation is outdated. Right now it throws invalid structure error

Dominic (Tue, 21 Aug 2018 15:33:05 GMT):
I haven't tested this, but what would happen if a fraudulent actor wanted to create a fake drivers' license by quickly creating an issuer and specifying the government DID, and then giving themselves a credential? Would they be able to create a proof with this credential and fool a verifier who specifies an issuer_did restriction such as `'restrictions': [{'issuer_did': 'VsKV7grR1BUE29mG2Fm2kX'}]`?

tomislav (Tue, 21 Aug 2018 15:37:01 GMT):
No. The issuer must be a trust anchor, their nym on the ledger, and publish a definition on that ledger. The verifier will pull the definitions from the ledger, which won't match with the fraudulent actor proof, so verification will fail.

tomislav (Tue, 21 Aug 2018 15:40:37 GMT):
Well, to be exact, they would be able to issue themselves a credential, but it won't pass verification.

Dominic (Tue, 21 Aug 2018 15:41:48 GMT):
Okay, thanks! @sklump answers above ↑

PhillipGibb (Tue, 21 Aug 2018 19:05:48 GMT):
I am not sure how revocation works: if hardly anything is store on the ledger how can we trust that someone will check if something is revoked? If I have issued a proof to someone and then later revoke it, sure the schema and credential definition is on the ledger, but there is no mutual agreement to handle revocation. I don't see how it can enforced.

tomislav (Tue, 21 Aug 2018 19:12:39 GMT):
There's a revocation registry on the ledger for credentials who support revocation

tomislav (Tue, 21 Aug 2018 19:12:39 GMT):
There's a revocation registry on the ledger for credentials that support revocation

Dominic (Tue, 21 Aug 2018 19:12:53 GMT):
You need a rev_reg_def and rev_reg_delta on the ledger, as well as a public tails file. When the verifier verifies the proof, he uses those variables. This doc gives a pretty good overview: https://github.com/hyperledger/indy-sdk/blob/master/doc/cred-revocation.md

Dominic (Tue, 21 Aug 2018 19:12:53 GMT):
You need a rev_reg_def and rev_reg_delta on the ledger, as well as a public tails file. When the verifier verifies the proof, he may use those variables to check for revocation. This doc gives a pretty good overview: https://github.com/hyperledger/indy-sdk/blob/master/doc/cred-revocation.md

tomislav (Tue, 21 Aug 2018 19:16:04 GMT):
I haven't seen a sample of using revocation on the ledger. Most samples just skip the ledger part, I would love to see one that does full end to end issuance to revocation

PhillipGibb (Tue, 21 Aug 2018 19:19:28 GMT):
Thanks, I am going to try implement that.

claudiobizzotto (Tue, 21 Aug 2018 20:27:51 GMT):
Has joined the channel.

Dominic (Tue, 21 Aug 2018 21:17:32 GMT):
Is there some good documentation on how DIDs work/are implemented in the Indy SDK? I'm unable to find anything that discusses DIDs in depth..

tomislav (Tue, 21 Aug 2018 22:30:27 GMT):
Does anyone know how can a prover uniquely correlate a received credential to the credential request they sent earlier? There is no data in the received credential that would map it back to the request/offer created earlier.

jljordan_bcgov (Wed, 22 Aug 2018 02:44:46 GMT):
@tomislav We have revocation implemted in Von-anchor. @sklump can provide the details

jljordan_bcgov (Wed, 22 Aug 2018 02:46:42 GMT):
https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/master/README.rst

jljordan_bcgov (Wed, 22 Aug 2018 02:47:12 GMT):
https://github.com/PSPC-SPAC-buyandsell/von_tails

xnopre (Wed, 22 Aug 2018 07:55:32 GMT):
Hi all. After interactions with the ledger or the wallet, is it possible to retrieve historical of this interactions (events or actions) ?

gudkov (Wed, 22 Aug 2018 08:10:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RriYFGNS7j6pyWfnd) @xnopre You can get any transaction from the ledger with GET_TXN request.

sklump (Wed, 22 Aug 2018 11:10:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=gvuZ2xmnERGvnC8Jm) @tomislav indy-sdk/wrapper/python/interation/test_interaction.py

sklump (Wed, 22 Aug 2018 11:10:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=gvuZ2xmnERGvnC8Jm) @tomislav `indy-sdk/wrapper/python/interation/test_interaction.py` note mispelling [although the number of times I've come back to this excellent sample, it is more like iteration than interaction]

sklump (Wed, 22 Aug 2018 11:10:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=gvuZ2xmnERGvnC8Jm) @tomislav `indy-sdk/wrapper/python/interation/test_interaction.py` note misspelling [although the number of times I've come back to this excellent sample, it is more like iteration than interaction]

sklump (Wed, 22 Aug 2018 11:10:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=gvuZ2xmnERGvnC8Jm) @tomislav `indy-sdk/wrappers/python/tests/interation/test_interaction.py` note misspelling [although the number of times I've come back to this excellent sample, it is more like iteration than interaction]

RubenGeo (Wed, 22 Aug 2018 11:29:55 GMT):
Has joined the channel.

tomislav (Wed, 22 Aug 2018 13:22:49 GMT):
Fantastic, thanks @sklump and @jljordan_bcgov - you helped me figure out the problem I was stuck on. I wasn't sending `build_revoc_reg_entry_request` right after `build_revoc_reg_def_request` with the initial state. So my calls to `reg_entry` right after credential issuance were failing.

tomislav (Wed, 22 Aug 2018 13:35:34 GMT):
Would be great to be able to update the tails location on the revoc reg def for use with IPFS

sklump (Wed, 22 Aug 2018 13:45:03 GMT):
Nothing stopping you from deploying von_tails and then monitoring the holder-prover side to shovel out tails files as they come in

sklump (Wed, 22 Aug 2018 13:45:03 GMT):
Nothing stopping you from deploying von_tails and then monitoring the holder-prover side to shovel out tails files as they come in, or adding to `von_tails/src/sync/sync.py` to pull from server to push to IPFS, or to bypass the server completely and pull from issuer local storage to push to IPFS. Alternatively, much as I don't know anything significant about IPFS, once it looks like local storage, von_tails supports it out of the box with appropriate configuration.

sklump (Wed, 22 Aug 2018 13:45:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=peTkxJqh8eabLLiq8) @AlexanderVtyurin The *Issuer* creates the revocation registry *entry* when creating the revocation registry. The *Issuer* updates the revocation registry entry with a *delta* on every credential issue and on every credential revocation, using the (Java) *buildRevocRegEntryReq()* call. The *Prover* gets the revocation registry *delta*, for any time between `from` and `to`, to perform proof creation. The *Verifier* gets the accumulator state via (Java) *buildGetRevocRegReq()*, at any timestamp within `[from, to]` to perform proof verification. The `from` and `to` parameters delimit the range of timestamps acceptable to the party requesting proof (i.e., the *Verifier*). They do not mean to assert non-revocation throughout this time period.

AvikHazra (Thu, 23 Aug 2018 04:44:17 GMT):
hello, I upload the indy-sdk in a server with ubuntu 16.04. but after that i cant run the demo. it`s throwing Segmentation fault (core dumped). can anyone please help me ?

AxelNennker (Thu, 23 Aug 2018 14:39:03 GMT):
How are the java wrappers generated or is this done by hand?

Dominic (Thu, 23 Aug 2018 14:53:51 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=eLoeyZ7W3xiKJYHc5) @AvikHazra What are you running? The indy-cli or a wrapper? Link to the demo you're talking about?

AlexanderVtyurin (Thu, 23 Aug 2018 14:54:25 GMT):
Has joined the channel.

Dominic (Thu, 23 Aug 2018 15:00:46 GMT):
In this description of Indy https://wiki.hyperledger.org/projects/indy , it says this: "Verifiable Claims are interoperable format for exchange of digital identity attributes and relationships currently in the standardization pipeline at the W3C". Is this true? Looking at W3C's data model ( https://w3c.github.io/vc-data-model/ ), it seems to differ a good amount from the cred_json that issuers generate from the Indy SDK.

jljordan_bcgov (Thu, 23 Aug 2018 15:06:20 GMT):
The Universal Resolver is one approach to transforming the data from the Indy ledger to the evolving Verifiable Credential working group spec ... https://medium.com/decentralized-identity/a-universal-resolver-for-self-sovereign-identifiers-48e6b4a5cc3c

AlexanderVtyurin (Thu, 23 Aug 2018 15:14:07 GMT):
Hello guys. I'm playing around with revocation using java sdk (libindy 1.5.0). Everything works fine except retrieving revocation registry delta from ledger. There are two methods to retrieve delta from ledger (Ledger.buildGetRevocRegEntryReq and Ledger.buildGetRevocRegDeltaReq) and only one to store (Ledger.buildRevocRegEntryReq) it. Which one should i use and when? What should i put in 'from' and 'to' arguments when retrieving delta and how these two time moments are correlating with timestamp used to retrieve entry? Right now my test (based on https://github.com/hyperledger/indy-sdk/blob/master/samples/java/src/main/java/AnoncredsRevocation.java but with ledger operations instead of in-memory caching stuff) fails on verify step. Looking through jsons in two tests (mine and AnoncredsRevocation from indy-sdk repository) i see that delta received from ledger is missing {prev_accum: "true 0 0 0 0...."} part. I tried different combinations of 'from' and 'to' parameters - it makes no sense, ledger always returns me the last state of revocation accumulator (or prev_accum identical to accum when, for example, from=now-10 and to=now). Please, help me.

jljordan_bcgov (Thu, 23 Aug 2018 15:14:24 GMT):
There is an instance of the resolver .. https://uniresolver.io .. but seems it needs a bit of attention as it isn't resolving the sample DID

Dominic (Thu, 23 Aug 2018 15:17:02 GMT):
I'm confused how I would go about using this resolver to convert an Indy credential to W3C format

Dominic (Thu, 23 Aug 2018 15:17:02 GMT):
I'm confused how I would go about using this resolver to convert an Indy credential to W3C format (or if that's even something that can be done with it)

jljordan_bcgov (Thu, 23 Aug 2018 15:29:51 GMT):
So, I think the simplest way to think of it is a data transform ... a DID Doc is a particular format for a JSON record .. the resolver is able to look up the relevant transactions on the sovrin (Indy) ledger and assemble the individual transactions into the DID Doc format

Dominic (Thu, 23 Aug 2018 15:35:52 GMT):
just to be sure we're on the same page, when you say DID Doc, does an Indy credential fall under the definition of a DID doc?

jljordan_bcgov (Thu, 23 Aug 2018 15:36:40 GMT):
Oops ... my bad ... DID Doc and Verifiable Credential are different ... need more coffee

jljordan_bcgov (Thu, 23 Aug 2018 15:37:23 GMT):
So ... Verifiable Credentials are not stored on the ledger ... they are something that agents would exchange

sklump (Thu, 23 Aug 2018 15:44:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=peTkxJqh8eabLLiq8) @AlexanderVtyurin The *Issuer* creates the revocation registry *entry* when creating the revocation registry. The *Issuer* updates the revocation registry entry with a *delta* on every credential issue and on every credential revocation, using the (Java) *buildRevocRegEntryReq()* call. The *Prover* gets the revocation registry *delta*, for any time between `from` and `to`, to perform proof creation. The *Verifier* gets the accumulator state via (Java) *buildGetRevocRegReq()*, at any timestamp within `[from, to]` to perform proof verification. The `from` and `to` parameters delimit the range of timestamps acceptable to the party requesting proof (i.e., the *Verifier*). They do not mean to assert non-revocation throughout this time period.

AlexanderVtyurin (Thu, 23 Aug 2018 15:48:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=vbaf4XXqQ3JQ6YRps) @sklump @sklump Thank you. One more question: does nonRevoked field of proof request makes sense? I've read your old question here about that, did you figured that out?

AlexanderVtyurin (Thu, 23 Aug 2018 15:48:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=vbaf4XXqQ3JQ6YRps) @sklump Thank you. One more question: does nonRevoked field of proof request makes sense? I've read your old question here about that, did you figured that out?

AlexanderVtyurin (Thu, 23 Aug 2018 15:48:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=vbaf4XXqQ3JQ6YRps) @sklump Thank you. One more question: does nonRevoked field of proof request make sense? I've read your old question here about that, did you figured that out?

sklump (Thu, 23 Aug 2018 15:54:56 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Swx8Nafphnzw33coQ) @AlexanderVtyurin It means that the party submitting the proof request (typically the *Verifier*), is OK getting a proof for that attribute or predicate [1] on any timestamp coming back between `from` and `to` inclusive. If the requesting party is only interested in a single `timestamp`, then `from` = `to` = `timestamp`. [1] Note that it is not possible to revoke an attribute, only a credential. So the non-revocation interval specification should be the same, as far as I understand, on all requested attributes and predicates of a credential definition.

AlexanderVtyurin (Thu, 23 Aug 2018 15:56:10 GMT):
@sklump Very thankful.

Dominic (Thu, 23 Aug 2018 15:56:53 GMT):
@jljordan_bcgov no worries haha that explains my confusion. That said, I still don't know why W3C verifiable claims are mentioned on the [Hyperledger Indy spec](https://wiki.hyperledger.org/projects/indy). It seems to me that Indy uses a format that is not interoperable (not standardized)

sklump (Thu, 23 Aug 2018 16:01:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Yayx4uz3ZZzchv6Eq) @AlexanderVtyurin Mr. Slava Gudkov set me straight, I had been confused too. A proof is at a timestamp. A proof request is for any timestamp in an interval. Note that this can produce some strange results. For example imagine times t0=midnight < t1=01:00 < t3=credential revocation < t3=now. If the prover has a cached revocation delta at time=t1, and the verifier asks for a proof on [t0, t3], then an acceptable outcome is that the proof asserts non-revocation status 'not revoked' as of time=t1. If the prover is ambitious and (expensively) always polls to the latest instant, the proof will assert revocation status 'revoked' as of time=t3. Both are OK to the verifier. If the verifier is only interested in the present moment, the verifier should specify [from, to] = [t3, t3] in the request. Buyer beware.

sklump (Thu, 23 Aug 2018 16:01:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Yayx4uz3ZZzchv6Eq) @AlexanderVtyurin Mr. Slava Gudkov set me straight - I had been confused too. A proof is at a timestamp. A proof request is for any timestamp in an interval. Note that this can produce some strange results. For example imagine times t0=midnight < t1=01:00 < t2=credential revocation < t3=now. If the prover has a cached revocation delta at time=t1, and the verifier asks for a proof on [t0, t3], then an acceptable outcome is that the proof asserts non-revocation status 'not revoked' as of time=t1. If the prover is ambitious and (expensively) always polls to the latest instant, the proof will assert revocation status 'revoked' as of time=t3. Both are OK to the verifier. If the verifier is only interested in the present moment, the verifier should specify [from, to] = [t3, t3] in the request. Buyer beware.

swcurran (Thu, 23 Aug 2018 16:07:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nYrJp5bASp6TTo3gZ) @Dominic The W3C VC WG is still finalizing the spec to put forth for the next phase of standardization. The HL Indy team has (as we type) put forth the some Pull Requests against the Spec to leave room for Indy-style ZKPs. The WG calls over the last couple of weeks have been going over those PRs, and that work will continue for the next several weeks. The hope/expectation is that in this version of the Spec, VCs that are capable of ZKPs and Selective Disclosure will be supportable in a W3C VC Spec. It's going to be tight given the current timeline, but I'm pretty certain it will happen at some point.

swcurran (Thu, 23 Aug 2018 16:07:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nYrJp5bASp6TTo3gZ) @Dominic The W3C VC WG is still finalizing the spec to put forth for the next phase of standardization. The HL Indy team has (as we type) put forth the some Pull Requests against the Spec to leave room for Indy-style ZKPs. The WG calls over the last couple of weeks have been going over those PRs, and that work will continue for the next several weeks. The hope/expectation is that in this version of the Spec, VCs that are capable of ZKPs and Selective Disclosure will be supportable based on the W3C VC Spec. It's going to be tight given the current timeline, but I'm pretty certain it will happen at some point.

Dominic (Thu, 23 Aug 2018 16:10:34 GMT):
Thanks for the info @swcurran !

PhillipGibb (Thu, 23 Aug 2018 18:03:49 GMT):
Hi, has anyone tried out https://github.com/IBM-Blockchain-Identity/indy-ssivc-tutorial I am having timeouts connecting to the Nodes from the von network

PhillipGibb (Thu, 23 Aug 2018 18:25:32 GMT):
also getting a port already in use for the Permitify agents: ERROR: for a87712df6f4f_docker_person_1 Cannot start service person: driver failed programming external connectivity on endpoint docker_person_1 (5c8b7a059766142bea2082faf1d32a26278502116be3b13dd4557784e3e7351c): Bind for 0.0.0.0:5000 failed: port is already allocated ERROR: for person Cannot start service person: driver failed programming external connectivity on endpoint docker_person_1 (5c8b7a059766142bea2082faf1d32a26278502116be3b13dd4557784e3e7351c): Bind for 0.0.0.0:5000 failed: port is already allocated ERROR: Encountered errors while bringing up the project.

PhillipGibb (Thu, 23 Aug 2018 18:27:19 GMT):
actually ignore that. docker ps showed me my problem

RyanWest (Thu, 23 Aug 2018 18:35:12 GMT):
Has joined the channel.

RyanWest (Thu, 23 Aug 2018 18:36:49 GMT):
When trying to cargo build the indy-sdk CLI (after building libindy successfully, using https://github.com/hyperledger/indy-sdk/blob/master/doc/rhel-build.md), I get the following error: ``` Compiling linefeed v0.3.0 ... = note: /usr/bin/ld: cannot find -lncursesw collect2: error: ld returned 1 exit status ``` using this command: `RUSTFLAGS="-L ../libindy/target/debug" cargo build` Is this a dependency that now needs to be installed? I've succesfully compiled the sdk-cli before, but now it is no longer working

RyanWest (Thu, 23 Aug 2018 18:38:52 GMT):
using this command: `RUSTFLAGS="-L ../libindy/target/debug" cargo build`

RyanWest (Thu, 23 Aug 2018 18:44:30 GMT):
Is this a dependency that now needs to be installed? I've succesfully compiled the sdk-cli before, but now it is no longer working

Dominic (Thu, 23 Aug 2018 19:08:07 GMT):
Is there a way for a verifier to check the DID of a prover? eg. Alice went to Faber University, and wants to apply for a job at Acme Corp, so she sends a transcript (credential) proof that she went to Faber University. How does Acme Corp verify that the transcript they received is from the same Alice that is applying for a job at their office?

Dominic (Thu, 23 Aug 2018 19:10:48 GMT):
A malicious Alice who did not go to Faber University could ask her friend who went to Faber University to send the proof instead of her

swcurran (Thu, 23 Aug 2018 19:34:55 GMT):
@Dominic - When Alice receives the credential from Faber, there is some crypto (blinded link secret) in the Credential that only she can prove because she holds the master (link) secret.

Dominic (Thu, 23 Aug 2018 19:46:17 GMT):
But suppose Alice doesn't have a University degree, so upon receiving the proof request, she forwards it to her friend who _does_ have a degree, and that friend sends a proof. How does the verifier know that the proof wasn't sent by Alice? allow Alice to create proofs for her own credentials?

Dominic (Thu, 23 Aug 2018 19:49:37 GMT):
I may be wrong about this, but I thought the master (link) secret only helped prove that the credential is issued by the issuer.

swcurran (Thu, 23 Aug 2018 19:50:47 GMT):
Interesting. No - the link secret is used to tie together the credentials to proof they were all issued to the same Identity (owner of the Master Secret).

canadaduane (Thu, 23 Aug 2018 19:51:26 GMT):
Has joined the channel.

swcurran (Thu, 23 Aug 2018 19:51:50 GMT):
So, for sure, ACME could ask for other identifying information in the proof request that they knew to ensure that what they didn't know was about the same perdon.

swcurran (Thu, 23 Aug 2018 19:52:41 GMT):
But I think you are right that if they just ask "What was your grade in Basket Weaving", you could get a proof from a more successful weaver.

Dominic (Thu, 23 Aug 2018 19:56:24 GMT):
So a verifier (ACME Corp) has to ask for personal information that only Alice would have in order to trust that the received information they care about (the grade in Basked Weaving) was actually from her?

Dominic (Thu, 23 Aug 2018 19:57:36 GMT):
I swear there must be something I'm forgetting and it's driving me insane haha

Dominic (Thu, 23 Aug 2018 20:01:10 GMT):
I'm wondering how to issue a credential to the person who created the proof.

Dominic (Thu, 23 Aug 2018 20:01:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WQH6NrmkBdsGtBHhc) @swcurran hmm, issuing a credential to Alice and then requesting it is a pretty clever solution

swcurran (Thu, 23 Aug 2018 20:12:41 GMT):
It doesn't necessarily have to be personal information. As you say, ACME could issue a credential to Alice and then include that in the proof request. Seems onerous though. We've done some thinking about offline proofs and we were able to implement that. In working through that scenario, we did realize that the only DIDs involved in a Proof process is the Issuer's DID used in the Cred Def. There is no need for the Prover and Verifier to exchange DIDs,

swcurran (Thu, 23 Aug 2018 20:12:41 GMT):
It doesn't necessarily have to be personal information. As you say, ACME could issue a credential to Alice and then include a claims from that in the proof request. Seems onerous though. We've done some thinking about offline proofs and we were able to implement that. In working through that scenario, we did realize that the only DIDs involved in a Proof process is the Issuer's DID used in the Cred Def. There is no need for the Prover and Verifier to exchange their DIDs,

swcurran (Thu, 23 Aug 2018 20:14:02 GMT):
We think that will be the likely mechanism to be used for in-person verifications - e.g. Driver's License proof at a bar, packet pickup at a Race (proof of age), etc.

swcurran (Thu, 23 Aug 2018 20:16:05 GMT):
The two parties will not exchange DIDs - the prover will just prepare a proof based on a stock proof request, deliver the 10kb of the proof somehow (e.g. bluetooth, file share) to the verifier and the Verifier can verify the proof based on knowledge of the Issuer (Cred Def, Issuer DID, Revocation Data).

Dominic (Thu, 23 Aug 2018 20:21:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WQH6NrmkBdsGtBHhc) @swcurran @swcurran hmm, issuing a credential to Alice and then requesting it is a pretty clever solution

Dominic (Thu, 23 Aug 2018 20:21:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WQH6NrmkBdsGtBHhc) @swcurran hmm, issuing a credential to Alice and then requesting it is a pretty clever solution

Dominic (Thu, 23 Aug 2018 20:21:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WQH6NrmkBdsGtBHhc) @swcurran @swcurran I've given it more thought, and I still think the "token credential" method is flawed. Alice and her friend could still be malicious. All they would have to do is make her friend receive the credential token, and have her friend send all the proofs, but still have Alice generate the cred requests. Then the credential would be made for Alice despite none of the proofs being sent by Alice. So this still doesn't guarantee that the credential will go to the creator of the proof. It seems flawed if there is no built-in way to guarantee that a credential is issued to the sender of a proof. I don't see how any claim can be trusted in a system like that.

RyanWest (Thu, 23 Aug 2018 23:03:02 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qocDxHfBgScELaYRY) I've found that running `sudo dnf install ncurses-devel` solves this. However, the guide should be updated to reflect this dependency.

RyanWest (Thu, 23 Aug 2018 23:16:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=A4c3xHKHyJXJvJcQm) Compiling indy-sdk CLI now works, but actually running it on fedora 28 gives this error: `./indy-cli: symbol lookup error: ./indy-cli: undefined symbol: indy_submit_action`

sans8119 (Fri, 24 Aug 2018 01:10:54 GMT):
Has joined the channel.

sans8119 (Fri, 24 Aug 2018 01:16:21 GMT):
Hi I am new to Indy . Please help me in understanding where I am going wrong.The docker is run and I can see 4 running nodes. But when ever I use the method Pool.createPoolLedgerConfig it throws a NullPointer exception.

sans8119 (Fri, 24 Aug 2018 01:16:36 GMT):
Following code always throws a NullPointerException: String walletName = "myWallet"; String poolName = "pool"; String stewardSeed = "000000000000000000000000Steward1"; String configJson={“genesis_txn":"{\"reqSignature\":{},\"txn\":{\"data\":{\"data\":{\"alias\":\"Node1\",\"blskey\":\"4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba\",\"client_ip\":\"192.168.0.100\",\"client_port\":9702,\"node_ip\":\"192.168.0.100\",\"node_port\":9701,\"services\":[\"VALIDATOR\"]},\"dest\":\"Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv\"},\"metadata\":{\"from\":\"Th7MpTaRZVRYnPiabds81Y\"},\"type\":\"0\"},\"txnMetadata\":{\"seqNo\":1,\"txnId\":\"fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62\"},\"ver\":\"1\"} {\"reqSignature\":{},\"txn\":{\"data\":{\"data\":{\"alias\":\"Node2\",\"blskey\":\"37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk\",\"client_ip\":\"192.168.0.100\",\"client_port\":9704,\"node_ip\":\"192.168.0.100\",\"node_port\":9703,\"services\":[\"VALIDATOR\"]},\"dest\":\"8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb\"},\"metadata\":{\"from\":\"EbP4aYNeTHL6q385GuVpRV\"},\"type\":\"0\"},\"txnMetadata\":{\"seqNo\":2,\"txnId\":\"1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc\"},\"ver\":\"1\"} "} Pool.createPoolLedgerConfig("Default", configJson).get();

sans8119 (Fri, 24 Aug 2018 01:16:53 GMT):
Following is from the docker : indy> connect sandbox Saved wallet "Default" restored (/home/indy/.indy-cli/wallets/sandbox/default.wallet) Active wallet set to "Default" indy27b727 updated its pool parameters: f 1, totalNodes 4,minNodesToConnect 2, quorums {'f': 1, 'election': Quorum(3), 'reply': Quorum(2), 'ledger_status_last_3PC': Quorum(2), 'propagate_primary': Quorum(2), 'view_change_done': Quorum(3), 'same_consistency_proof': Quorum(2), 'bls_signatures': Quorum(3), 'consistency_proof': Quorum(2), 'view_change': Quorum(3), 'timestamp': Quorum(2), 'propagate': Quorum(2), 'commit': Quorum(3), 'observer_data': Quorum(2), 'prepare': Quorum(2), 'ledger_status': Quorum(2), 'checkpoint': Quorum(2)} Client indy27b727 initialized with the following node registry: Node1C listens at 192.168.0.100 on port 9702 Node2C listens at 192.168.0.100 on port 9704 Node3C listens at 192.168.0.100 on port 9706 Node4C listens at 192.168.0.100 on port 9708 Active client set to indy27b727 CONNECTION: GP4gVKLR23tXP6Gs2S6aSAB4XqaayxbmRNh9MHwxTMGp listening for other nodes at 0.0.0.0:6002 CONNECTION: GP4gVKLR23tXP6Gs2S6aSAB4XqaayxbmRNh9MHwxTMGp looking for Node2C at 192.168.0.100:9704 CONNECTION: GP4gVKLR23tXP6Gs2S6aSAB4XqaayxbmRNh9MHwxTMGp looking for Node4C at 192.168.0.100:9708 CONNECTION: GP4gVKLR23tXP6Gs2S6aSAB4XqaayxbmRNh9MHwxTMGp looking for Node3C at 192.168.0.100:9706 CONNECTION: GP4gVKLR23tXP6Gs2S6aSAB4XqaayxbmRNh9MHwxTMGp looking for Node1C at 192.168.0.100:9702 Connecting to sandbox... GP4gVKLR23tXP6Gs2S6aSAB4XqaayxbmRNh9MHwxTMGp's connections changed from set() to {'Node4C'} CONNECTION: GP4gVKLR23tXP6Gs2S6aSAB4XqaayxbmRNh9MHwxTMGp now connected to Node4C GP4gVKLR23tXP6Gs2S6aSAB4XqaayxbmRNh9MHwxTMGp's connections changed from {'Node4C'} to {'Node2C', 'Node4C', 'Node3C'} CONNECTION: GP4gVKLR23tXP6Gs2S6aSAB4XqaayxbmRNh9MHwxTMGp now connected to Node2C CONNECTION: GP4gVKLR23tXP6Gs2S6aSAB4XqaayxbmRNh9MHwxTMGp now connected to Node3C GP4gVKLR23tXP6Gs2S6aSAB4XqaayxbmRNh9MHwxTMGp's connections changed from {'Node2C', 'Node4C', 'Node3C'} to {'Node2C', 'Node4C', 'Node3C', 'Node1C'} CONNECTION: GP4gVKLR23tXP6Gs2S6aSAB4XqaayxbmRNh9MHwxTMGp now connected to Node1C CATCH-UP: GP4gVKLR23tXP6Gs2S6aSAB4XqaayxbmRNh9MHwxTMGp completed catching up ledger 0, caught up 0 in total Connected to sandbox.

sans8119 (Fri, 24 Aug 2018 01:20:28 GMT):
The docker is run in MacOs and the java code is run from eclipse in the same MacOS laptop.

Dominic (Fri, 24 Aug 2018 15:00:22 GMT):
@swcurran I've given it more thought, and I still think the "token credential" method is flawed. Alice and her friend could still be malicious. All they would have to do is make her friend receive the credential token, and have her friend send all the proofs, but still have Alice generate the cred requests. Then the credential would be made for Alice despite none of the proofs being sent by Alice. So this still doesn't guarantee that the credential will go to the creator of the proof. It seems flawed if there is no built-in way to guarantee that a credential is issued to the sender of a proof.

AxelNennker (Fri, 24 Aug 2018 15:07:48 GMT):
@sans8119 which line gives a NPE? One reason for NPE with the java wrapper might be that JNA does not load libindy so the variable `api` is null. If that is so in your case please check that libindy.so is found in a place where JNA is locking for it e.g. /usr/lib/libindy.so `ignisvulpis@namenlos:~/development/hyperledger/indy-agent$ find /usr/ -name libindy.so /usr/lib/libindy.so ignisvulpis@namenlos:~/development/hyperledger/indy-agent$ `

AxelNennker (Fri, 24 Aug 2018 15:08:23 GMT):
Or set LD_LIBRARY_PATH to where your libindy.so is

sans8119 (Fri, 24 Aug 2018 16:33:26 GMT):
@AxelNennker Thank you for replying. NPE happens at org.hyperledger.indy.sdk.pool.Pool.createPoolLedgerConfig(Pool.java:98). In my MacBook DYLD_LIBRARY_PATH and LD_LIBRARY_PATH do not point to libindy.so ; they were pointing to indy-sdk directory where the sdk was cloned and built for MacOS using instructions at https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md . After building libindy on MacOS a libindy.dylib was created in the folder $Home//indy-sdk/libindy/target/debug. I will set envir

sans8119 (Fri, 24 Aug 2018 16:34:30 GMT):
@AxelNennker I will set environment variable LD_LIBRARY_PATH to point to $Home//indy-sdk/libindy/target/debug/ libindy.dylib and try running the sample.

sans8119 (Fri, 24 Aug 2018 17:42:14 GMT):
@AxelNennker the library is loaded and Pool.openPoolLedger is successful. Thank you.

xum7331 (Sat, 25 Aug 2018 02:38:41 GMT):
Has joined the channel.

AxelNennker (Sat, 25 Aug 2018 16:04:09 GMT):
I find it confusing that the method anonCrypt in indy-agent takes a did as the first parameter that is then resolved to a verkey while the method anonCrypt in indy-sdk java wrappers takes a verkey directly. https://github.com/hyperledger/indy-sdk/blob/master/wrappers/java/src/main/java/org/hyperledger/indy/sdk/crypto/Crypto.java#L481 https://github.com/hyperledger/indy-agent/blob/master/nodejs/indy/src/crypto/index.js#L19 Also because everything in the java wrappers is a String the developer (me) has no chance to notice this mixup - at least no help from the compiler (Yes, I like strongly typed languages)

swcurran (Sat, 25 Aug 2018 18:45:01 GMT):
@mhailstone ^^^ What are your thoughts on this - passing DID vs. verkey? As I recall from the Agent WG discussions, the functions should take verkeys, not DIDs - the DID resolution is left to the Agent code above the Indy-SDK.

xum7331 (Sat, 25 Aug 2018 18:59:55 GMT):
Hi everyone, I'm new here. I've finished reading the Getting Started guide (https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md) but found it a bit confusing (and quite overwhelming). All I wanna do is connect my local client (on Ubuntu) to the live "testnet". Can anybody point me in the right direction?

sans8119 (Sun, 26 Aug 2018 06:13:35 GMT):
Response of a credential definition request is failing with response: {"op":"REQNACK","reqId":1535263393607580000,"reason":"client request invalid: InsufficientCorrectSignatures(0, 1)","identifier":"PNtQtmjuNTQgFaFYueVGqe"} Any information in understanding the above error message will be very helpful. Creating a CredDef request in java is as follows: String credDefRequest = buildCredDefRequest(trustAnchorDID,data).get(); The credDefRequest string is like: { "reqId": 1535263393607580000, "identifier": "PNtQtmjuNTQgFaFYueVGqe", "operation": { "ref": 92, "data": { "primary": { "n": "1", "s": "2", "r": { "name": "1", "master_secret": "3" }, "rctxt": "1", "z": "1" } }, "type": "102", "signature_type": "CL", "tag": "TAG_1" }, "protocolVersion": 2 }

sans8119 (Sun, 26 Aug 2018 08:16:38 GMT):
Online information says that 'signature' should be present as one of the keys of the request json. The value should be Submitter's signature as a base58-encoded string. How to get the Submitter's signature ?

sans8119 (Sun, 26 Aug 2018 08:37:34 GMT):
Shouldn't this 'signature' key and its value be added the the request json when we submit a request using Ledger.signAndSubmitRequest method ?

sans8119 (Sun, 26 Aug 2018 14:54:32 GMT):
The issue is resolved; I was passing wrong value for submitterDID

swcurran (Sun, 26 Aug 2018 16:37:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5X8GsSfoFEpCPqy3Q) @sans8119 Just as a matter of interest - what were you passing and how did you correct it? We are trying to determine if a Trust Anchor (TA) can create a CredDef on behalf of an Issuer that is not a TA. In theory it should be possible, but it doesn't seem like you can pass in two DIDs - one for the TA to submit the request and a second for the Issuer. I'm wondering if you can confirm that or not. Thanks

sans8119 (Mon, 27 Aug 2018 04:22:10 GMT):
@swcurran It is possible for TA to create a CredDef on behalf of an issuer that is not a TA. An agent was created with a common role. This agent's DID was used as a second parameter in issuerCreateAndStoreCredentialDef method. TA's DID was used as a first parameter in buildCredDefRequest method and 3rd parameter in signAndSubmitRequest method.

sklump (Mon, 27 Aug 2018 11:28:57 GMT):
I need to find a way to (1) start the `indy_pool` that ships with indy-sdk on indy-node protocol 1.3 (2) register some trust anchors, have Issuer issue some credentials [with revocation support] (3) upgrade it to protocol 1.4 (4) have Prover create proof, Verifier verify it Is this possible?

sklump (Mon, 27 Aug 2018 11:28:57 GMT):
I need to find a way to (1) start the `indy_pool` that ships with indy-sdk on indy-node protocol 1.3 (2) register some trust anchors, have Issuer issue some credentials [with revocation support] (3) upgrade the pool to indy-node protocol 1.4 (4) have Prover create proof, Verifier verify it Is this possible?

sklump (Mon, 27 Aug 2018 11:37:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4Hux2BTgvi7GWc29T) @sans8119 But then, the cred def private key will live in the wallet of the TA - the Issuer will only be able to issue credentials via the TA? In effect, that makes the Issuer not an Issuer at all but some kind of go-between?

Dominic (Mon, 27 Aug 2018 13:54:53 GMT):
@swcurran I've given it more thought, and I still think the "token credential" method is flawed. Alice and her friend could still be malicious. All they would have to do is make her friend receive the credential token, and have her friend send all the proofs, but still have Alice generate the cred requests. Then the credential would be made for Alice despite none of the proofs being sent by Alice. So this still doesn't guarantee that the credential will go to the creator of the proof. It seems flawed if there is no built-in way to guarantee that a credential is issued to the sender of a proof. I don't see how any claim can be trusted in a system like that.

xnopre (Mon, 27 Aug 2018 14:18:37 GMT):
Hi all. I'm exploring the possibilities to get history from the ledger. After @gudkov 's answer, I have tried `GET_TXN`. It's OK to get information for a specified transactions from its `seq_no`. But is it possible to retrieve the list of all `seq_no` and/or retrieve the last transactions ? Thanks

mhailstone (Mon, 27 Aug 2018 14:27:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=FEGcXbp83xE9sLesE) @swcurran As I recall from a recent discussion on a call, the auth-crypt value contains the public key with which it was encrypted, so if you pass in the DID, it will be able to resolve from looking at the headers of the auth-crypt data and the DID that is passed in how to decrypt it. Because the crypto knows how to read the header data on the encrypted bytes passed into the function, it does the work of resolving the DID to the key needed to decrypt it from the public key read off the header. That's my assumption anyway. @saholman any other thoughts?

swcurran (Mon, 27 Aug 2018 14:34:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=MRPhFrdzTWrBEtwa4) @Dominic It's the generation of the Cred Req where the "blinded link secret" is created and that then gets put into the Credential. So by having Alice create the credential request, only she can use it. So as long as Faber makes sure the Cred Req comes from the same Identity that proved they were Alice, all is good.

saholman (Mon, 27 Aug 2018 15:05:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RGRwK7EyXALZTiX7S) @AxelNennker These functions in the indy-agent repo are simply abstractions or wrappers around the indy-sdk node.js wrapper for the purpose of this agent implementation only. If you look closely at the links you posted, those functions are calling cryptoAnonCrypt and cryptoAuthCrypt with the keys (not dids). @swcurran Agreed. Since we want to support multiple keys for a did in the future, I think AnonCrypt and AuthCrypt should only take verkeys as parameters.

saholman (Mon, 27 Aug 2018 15:05:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RGRwK7EyXALZTiX7S) @mhailstone @AxelNennker These functions in the indy-agent repo are simply abstractions or wrappers around the indy-sdk node.js wrapper for the purpose of this agent implementation only. If you look closely at the links you posted, those functions are calling cryptoAnonCrypt and cryptoAuthCrypt with the keys (not dids). @swcurran Agreed. Since we want to support multiple keys for a did in the future, I think AnonCrypt and AuthCrypt should only take verkeys as parameters.

Dominic (Mon, 27 Aug 2018 15:16:48 GMT):
Oh I see, so if Alice tried to use her friend's credentials, it would go something like this (applicantID is token): Friend send cred (applicantID) req → Friend receive applicantID ← Friend send proof w/ applicantID → Alice sends cred request →

sans8119 (Mon, 27 Aug 2018 15:18:25 GMT):
@sklump DID for the agent with a common role was stored in a new wallet where TA’s DID was not present. This new wallet is passed as 1st parameter to Anoncreds.issuerCreateAndStoreCredentialDef . 2nd parameter is the common role agents did. With this Anoncreds.issuerCreateAndStoreCredentialDef gave a good response. I am not very sure but from this may be we can say that cred def private key will live in the wallet of the common role agent and not in the wallet of TA.

AxelNennker (Mon, 27 Aug 2018 15:28:51 GMT):
@saholman I think it is confusing that methods with the same name take different arguments which have different semantics but the same type string.

saholman (Mon, 27 Aug 2018 15:31:33 GMT):
@AxelNennker Agreed. The indy-agent node.js implementation was a proof of concept reference agent based on old ideas. The official node.js wrapper takes the expected parameters. https://www.npmjs.com/package/indy-sdk#cryptoauthcrypt--wh-sendervk-recipientvk-messageraw----encryptedmsgraw

AxelNennker (Mon, 27 Aug 2018 15:35:45 GMT):
'official'... I think indy-agent is official :-)

swcurran (Mon, 27 Aug 2018 15:37:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=59YB3M74ts9yKLLri) @Dominic Something like that would work. When establishing the connections, Faber links the DID Alice gives to her internal FaberID (StudentID or the like) and the DID her Friend gives to the friend's FaberID. Each DID becomes like the login ID that we use today. When a CredReq comes in from either of them, Faber would use the requester's DID to figure out what data to put into the Credential.

swcurran (Mon, 27 Aug 2018 15:37:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=59YB3M74ts9yKLLri) @Dominic Something like that would work. When establishing the connections, Faber links the DID Alice provides to her internal FaberID (StudentID or the like) and the DID her Friend provides to the friend's FaberID. Each DID becomes like the login ID that we use today. When a CredReq comes in from either of them, Faber would use the requester's DID to figure out what data to put into the Credential.

smithbk (Mon, 27 Aug 2018 15:40:14 GMT):
Is there a way to look up a credential schema ID from the ledger by name and version?

smithbk (Mon, 27 Aug 2018 15:41:15 GMT):
I only see this currently: ```build_get_schema_request(submitter_did: str, id_: str) -> str:```

sklump (Mon, 27 Aug 2018 15:45:37 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=PZEzJrox4xujBPQpi) @smithbk You need the transaction number, or else the origin DID, name, version baked into a schema_id.

saholman (Mon, 27 Aug 2018 16:11:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=vkrad7xhXAtaXNz9d) @AxelNennker I agree with you to some degree, but its important to understand that the SDK is the common code that many different agents will be built on top of. Each agent builder then has the liberty to do what they would like with that code base to accomplish their purposes. In Indy-Agent I assumed that we would only ever have one key per DID so I wrote convenient helper functions to simplify the process of encrypting and decrypting a message. Since the purpose of that project was to simply create an agent that works and is capable of the key concepts of Sovrin/Indy, it makes a lot of sense to add that abstraction. I'd be happy to walk you through the code and explain the reasons behind why decisions were made. If you have interest in using the node.js agent code, lets move this conversation to the #indy-agent channel and see if we can help you out. If you do decide to use the code, please note that many of the concepts implemented there are no longer aligned with current A2A protocol and other agents are in the works from several different organizations.

saholman (Mon, 27 Aug 2018 16:11:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=vkrad7xhXAtaXNz9d) @AxelNennker I agree with you to some degree, but its important to understand that the SDK is the common code that many different agents will be built on top of. Each agent builder then has the liberty to do what they would like with that code base to accomplish their purposes. In Indy-Agent I assumed that we would only ever have one key per DID so I wrote a convenient helper function to simplify the process of encrypting and decrypting a message. Since the purpose of that project was to simply create an agent that works and is capable of the key concepts of Sovrin/Indy, it makes a lot of sense to add that abstraction. I'd be happy to walk you through the code and explain the reasons behind why decisions were made. If you have interest in using the node.js agent code, lets move this conversation to the #indy-agent channel and see if we can help you out. If you do decide to use the code, please note that many of the concepts implemented there are no longer aligned with current A2A protocol and other agents are in the works from several different organizations.

Dominic (Mon, 27 Aug 2018 18:08:40 GMT):
Can a verifier request that a specific attribute be revealed in a proof request, or is that always up to the prover?

swcurran (Mon, 27 Aug 2018 18:16:42 GMT):
The verifier requests it in the proof request. The prover can choose to do it or not. There is the concept of a "proof offer", which the prover might send to the verifier in response to a proof request as part of a negotiation sequence. "You want me to prove this, but how about this instead?". A full implementation of such a negotiation is currently left as an exercise for the reader :-)

Dominic (Mon, 27 Aug 2018 18:19:33 GMT):
Interesting, I'd love to see an example of how such an interaction can be implemented. I assume this is something that is being worked on with Indy-Agent?

Dominic (Mon, 27 Aug 2018 18:23:26 GMT):
And out of curiosity, why use an interaction instead of having the verifier just say "I will accept any of the following attribute combinations: (attr1 and attr2 and attr3) or (attr1 and attr4) or (attr2 and attr4)"?

xnopre (Tue, 28 Aug 2018 14:23:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mx7LSDKZMacH7S3Mb) Hi all. No idea for my question ? Thanks :-)

gudkov (Tue, 28 Aug 2018 14:36:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=BuGmp7vdfjChyuaCD) @xnopre Ledger supports this request, but it isn't exposed by libindy.

swcurran (Tue, 28 Aug 2018 14:49:15 GMT):
@Dominic - that is a model that has been discussed. Not sure where it stands from an implementation perspective. This was last looked at in the Dec/Jan timeframe when there was an expansion of the schema and/or CredDef and/or attributeName feature was added. I'm not sure if there are technical reasons not to implement what you propose on top of that.

akuma921 (Tue, 28 Aug 2018 15:48:25 GMT):
hi all, I am getting bellow error while running the ledger to try node-sdk E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial-updates/universe/binary-amd64/by-hash/SHA256/3f8f33badda65737faef9817ef1e8e5492288629bfbfc6f584d202568065fa44 Hash Sum mismatch Seems like an intermittent issue, as things were fine till few days back

akuma921 (Tue, 28 Aug 2018 15:48:42 GMT):
any quick help on this will be appreciated

akuma921 (Wed, 29 Aug 2018 03:43:46 GMT):
C02TK1N5GTFM:nodejs akuma921$ npm start > gettingstarted@1.0.0 start /Users/akuma921/work/hyperledger-indy/indy-sdk/indy-sdk/samples/nodejs > node gettingStarted.js Getting started -> started Open Pool Ledger: pool1 (node:15995) UnhandledPromiseRejectionWarning: IndyError: CommonInvalidState at Object.callback (/Users/akuma921/work/hyperledger-indy/indy-sdk/indy-sdk/samples/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10) (node:15995) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1) (node:15995) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

akuma921 (Wed, 29 Aug 2018 03:45:39 GMT):
I am getting below error, while running nodejs sample. I tried rebuilding the ledger with --no-cache option as well (node:15995) UnhandledPromiseRejectionWarning: IndyError: CommonInvalidState at Object.callback (/Users/akuma921/work/hyperledger-indy/indy-sdk/indy-sdk/samples/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10) (node:15995) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1) (node:15995) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

akuma921 (Wed, 29 Aug 2018 06:25:19 GMT):
when ran with info level RUST logging, below is the error ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid library state: Ledger merkle tree doesn't acceptable for current tree. (node:16982) UnhandledPromiseRejectionWarning: IndyError: CommonInvalidState

xnopre (Wed, 29 Aug 2018 07:35:32 GMT):
@gudkov Thank you for your answer. Si, finally, as it is now, just with this functionnality, I just can iterate all transaction from #1, so it is not really useable to retrieve the recent history of my transactions ? I'm a little newbie with Ledger and Indy. Do that make sens to try to retrieve history ? If it is, would it be possible to update (complete) libindy to implement this functionnalities ? :-)

sklump (Wed, 29 Aug 2018 11:23:53 GMT):
*I'm asking this again. We need a way to back-date the indy-node protocol temporarily, or else start with an old one and upgrade to a new one.* I need to find a way to (1) start the `indy_pool` that ships with indy-sdk on indy-node protocol 1.3 (2) register some trust anchors, have Issuer issue some credentials [with revocation support] (3) upgrade the pool to indy-node protocol 1.4 (4) have Prover create proof, Verifier verify it I've found `ledger.build_pool_upgrade_request()` and `ledger.build_pool_restart_request()`, but it looks like the update request cannot backdate. Also, is there any further documentation on these parameters? For example, what is the sha256 hash of? If I can't backdate, and must start from an indy-node pool on 1.3, how does the ledger know how to find 1.4? Is it otherwise possible to configure the pool to start with 1.3 instead of 1.4?

gudkov (Wed, 29 Aug 2018 11:33:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5z7kPQQAFcYdj9yRs) @sklump I suggest to ask in indy-node channel.

gudkov (Wed, 29 Aug 2018 11:35:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=equhLMGqxtGjsogrW) @xnopre The most of Indy use cases don't require to touch Node often especially writing transactions. In the most of use cases you need to just ask the state of some domain entity that is identified in a some way.

sklump (Wed, 29 Aug 2018 15:43:08 GMT):
*Item*: `ledger.py`. What is the protocol version to use for indy-node 1.6? Thanks. ``` """ Set PROTOCOL_VERSION to specific version. There is a global property PROTOCOL_VERSION that used in every request to the pool and specified version of Indy Node which Libindy works. By default PROTOCOL_VERSION=1. :param protocol_version: Protocol version will be used: 1 - for Indy Node 1.3 2 - for Indy Node 1.4 :return: Error code """ ```

sklump (Wed, 29 Aug 2018 15:43:08 GMT):
*Item*: `ledger.py:set_protocol_version()`. What is the protocol version to use for indy-node 1.6? Thanks. ``` """ Set PROTOCOL_VERSION to specific version. There is a global property PROTOCOL_VERSION that used in every request to the pool and specified version of Indy Node which Libindy works. By default PROTOCOL_VERSION=1. :param protocol_version: Protocol version will be used: 1 - for Indy Node 1.3 2 - for Indy Node 1.4 :return: Error code """ ```

sklump (Wed, 29 Aug 2018 15:43:08 GMT):
*Item*: `ledger.py:set_protocol_version()`. What is the protocol version to use for indy-node 1.6? Please confirm that (1) 1.6 is a renaming of 1.4, to align with indy-sdk 1.6 (2) There is no 1.5 ? Thanks. ``` """ Set PROTOCOL_VERSION to specific version. There is a global property PROTOCOL_VERSION that used in every request to the pool and specified version of Indy Node which Libindy works. By default PROTOCOL_VERSION=1. :param protocol_version: Protocol version will be used: 1 - for Indy Node 1.3 2 - for Indy Node 1.4 :return: Error code """ ```

tomislav (Wed, 29 Aug 2018 20:20:57 GMT):
Protocol format changed with node 1.4. Use protocol version 2 with node 1.6. No other values other than 1 and 2 are accepted

RyanWest (Thu, 30 Aug 2018 16:27:31 GMT):
I just updated indy-sdk to master, and now libindy is no longer building: ``` sov@ubuntu:~/git/indy-sdk/libindy$ cargo build Compiling indy v1.6.4 (file:///home/sov/git/indy-sdk/libindy) error[E0658]: non-reference pattern used to match a reference (see issue #42640) --> src/utils/crypto/pwhash_argon2i13/sodium.rs:24:13 | 24 | KeyDerivationMethod::ARGON2I_MOD => (crypto_pwhash_opslimit_moderate(), crypto_pwhash_me mlimit_moderate()), | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: consider using a reference: `&KeyDerivationMethod ::ARGON2I_MOD` ``` All the dependencies, including libsodium, should be met, because I was just able to successfully cargo build libindy. But updating master seems to break it.

RyanWest (Thu, 30 Aug 2018 16:27:31 GMT):
I just updated indy-sdk to master, and now libindy is no longer building: ``` sov@ubuntu:~/git/indy-sdk/libindy$ cargo build Compiling indy v1.6.4 (file:///home/sov/git/indy-sdk/libindy) error[E0658]: non-reference pattern used to match a reference (see issue #42640) --> src/utils/crypto/pwhash_argon2i13/sodium.rs:24:13 | 24 | KeyDerivationMethod::ARGON2I_MOD => (crypto_pwhash_opslimit_moderate(), crypto_pwhash_me mlimit_moderate()), | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: consider using a reference: `&KeyDerivationMethod ::ARGON2I_MOD` (26 more errors like this) ``` All the dependencies, including libsodium, should be met, because I was just able to successfully cargo build libindy. But updating master seems to break it.

RubenLassau-Strauven (Fri, 31 Aug 2018 06:10:27 GMT):
Has joined the channel.

baconsandwich (Fri, 31 Aug 2018 14:07:35 GMT):
Hey, I started trying the python wrapper with Django, but the realized that Django is sequential but the python wrappers are all async. What is the best solution here? Any clean solution of combining both or will I have to use a different web framework?

baconsandwich (Fri, 31 Aug 2018 14:07:35 GMT):
Hey, I started trying the python wrapper with Django, but then realized that Django is sequential but the python wrappers for Indy are all async. Any clean solution of combining both or will I have to use a different (async) web framework?

sklump (Fri, 31 Aug 2018 14:18:16 GMT):
https://github.com/PSPC-SPAC-buyandsell/von_conx/blob/master/src/app/service/eventloop.py Then wrap async calls in `do()`

sureshtedla (Fri, 31 Aug 2018 17:30:25 GMT):
Has joined the channel.

RyanWest (Fri, 31 Aug 2018 20:31:34 GMT):
I was wondering why, when sending a NYM transaction to the ledger, the verkey attribute is optional. It seems like it should be required to me. Here's a short description found in indy-node/docs: Target verification key as base58-encoded string. It can start with "~", which means that it's an abbreviated verkey and should be 16 bytes long when decoded, otherwise it's a full verkey which should be 32 bytes long when decoded. If not set, then either the target identifier (did) is 32-bit cryptonym CID (this is deprecated), or this is a user under guardianship (doesn't own the identifier yet). *Verkey can be changed to "None" by owner, it means that this user goes back under guardianship*. What is guardianship?

baconsandwich (Sun, 02 Sep 2018 13:43:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=87bk9XnoLfpENytxF) @RyanWest Maybe this helps: >a dependent—an entity who is not currently in a position to control the private keys for this identity. This DDO was created by a guardian—a separate identity owner with its own DID that serves as a trustee for the dependent. Note that while this DDO asserts a set of service endpoints, it does not yet contain a set of key descriptions because the dependent does not yet have its own set of private keys

baconsandwich (Sun, 02 Sep 2018 13:43:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=87bk9XnoLfpENytxF) @RyanWest Maybe this helps: >A guardian is an identity owner who creates and maintains an identity record for a dependent who is not in a position to hold or control the necessary cryptographic keys (e.g., a parent creating an identity record for a child). In this case, there are no owner keys to represent the ultimate identity owner.

baconsandwich (Sun, 02 Sep 2018 13:43:48 GMT):
source: https://docs.google.com/document/d/1Z-9jX4PEWtyRFD5fEyyzEnWK_0ir0no1JJLuRu8O9Gs

andrewtan (Tue, 04 Sep 2018 00:41:31 GMT):
Appreciate any help on this as I am trying out on ubuntu. Environment has been setup following the steps under https://github.com/hyperledger/indy-node/blob/master/docs/setup-dev.md However, do not seem to be able to get Docker Build running and unable to go through the How-To Tutorial under Indy-SDK Python wrapper.

andrewtan (Tue, 04 Sep 2018 00:41:53 GMT):

Error_Screen.docx

andrewtan (Tue, 04 Sep 2018 00:42:15 GMT):
Attaching the screen shots. Any help appreciated.

sergey.minaev (Tue, 04 Sep 2018 08:13:15 GMT):
@andrewtan I suggest to use https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker for IndySDK How-To or other sdk-related tasks.

tkdp (Tue, 04 Sep 2018 09:11:45 GMT):
Has joined the channel.

andrewtan (Tue, 04 Sep 2018 09:51:52 GMT):
@sergey.minaev I did follow that section but it returns an error as captured in the earlier screen shots and hence I am not sure where I have gone wrong.

sergey.minaev (Tue, 04 Sep 2018 10:01:55 GMT):
@andrewtan I see some standard docker error for build on your screenshot. It should be easier to google what's wrong with docker against dealing with dev setup of indy-node :)

andrewtan (Tue, 04 Sep 2018 10:10:56 GMT):
@sergey.minaev I am doing that right now and will reach out again if I face challenges

sergey.minaev (Tue, 04 Sep 2018 10:48:05 GMT):
If you will find something interesting and would like to share it this community (e.g. some typical conflict in env) - fill free to send a PR to update IndySDK readme

AvikHazra (Tue, 04 Sep 2018 11:57:31 GMT):
hello all, I'm trying to run evernym SDK from https://github.com/evernym/sdk/tree/master/vcx. In both, mac and ubuntu getting some errors. Could not compile `libvcx`. Can you please help me or give me some setup guide ? I am trying from https://github.com/evernym/sdk/tree/master/vcx/libvcx/build_scripts/.

wightman (Tue, 04 Sep 2018 13:31:34 GMT):
@AvikHazra take a look at the README: https://github.com/hyperledger/indy-sdk/blob/master/vcx/README.md It has instructions for building on ubuntu using cargo.

PhillipGibb (Tue, 04 Sep 2018 14:00:30 GMT):
@AvikHazra If you are trying to build for mac the documentation is incorrect. e.g. step 6 : `./mac.03.libindy.build.sh > mac.03.libindy.build.sh 2<&1` does nothing because it should be outputting to .out also if you open that file it has the macos relevant stuff commented out so who knows what else is wrong

PhillipGibb (Tue, 04 Sep 2018 14:06:30 GMT):
@AvikHazra also check the contents of 06

andrewtan (Tue, 04 Sep 2018 15:29:22 GMT):
I am now getting the "_indy_loop_callback: Function returned error 114" when trying to run the Write_DID.py tutorial.

andrewtan (Tue, 04 Sep 2018 15:29:52 GMT):
am I missing out certain steps?

andrewtan (Tue, 04 Sep 2018 15:47:22 GMT):

Clipboard - September 4, 2018 11:45 PM

PhillipGibb (Tue, 04 Sep 2018 20:00:17 GMT):
I managed to create libvcx.dylib for the mac using the cargo build and not the mac.build.md sequence, but when I initialize vcx I get an unknown libindy error, hmmmm.

arunwij (Wed, 05 Sep 2018 00:55:46 GMT):
Hello. I was building an application with indy-sdk. It worked fine. Suddenly the pool stoped responding and i get "PoolLedgerTimeout" error. Indy_pool Docker container is up and i cannot figure out what cause the problem. I am running exact same program. I am using Mac Os. Any suggestion or help highly appreciate. Thank you. :slight_smile:

arunwij (Wed, 05 Sep 2018 00:55:46 GMT):
Hello. I was building an application with indy-sdk. It worked fine. Suddenly the pool stoped responding and i get "PoolLedgerTimeout" error. Indy_pool Docker container is up and i cannot figure out what cause the problem. I am running exact same program. I am using Mac Os. Anyone have an idea about this? I highly appreciate your help. Thank you. :slight_smile:

arunwij (Wed, 05 Sep 2018 00:55:46 GMT):
Hello. I was building an application with indy-sdk. It worked fine. Suddenly the pool stoped responding and i get "PoolLedgerTimeout" error. Indy_pool Docker container is up and i cannot figure out what cause the problem. I am running exact same program. I am using Mac Os. Anyone have an idea about this? I highly appreciate your help. Thank you.

gudkov (Wed, 05 Sep 2018 09:00:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=SLY9FyguES4SP4hoz) @arunwij It is hard to help without logs. Problem can be in your docker configuration.

SRibeiro (Wed, 05 Sep 2018 12:59:56 GMT):
Has joined the channel.

PhillipGibb (Wed, 05 Sep 2018 13:01:33 GMT):
Trying to build vcx for iOS on XCode, is there a repo containing the framework libs so I can get past "ld: library not found for -lvcx" stepping thru the build sequence in ios/mac is unnecessary and complicated to achieve something that should be common.

arunwij (Wed, 05 Sep 2018 13:04:24 GMT):
@gudkov Thank you. This is the message i get when i run the *docker run -it -p 9701-9708:9701-9708 indy_pool* `Traceback (most recent call last): File "/usr/bin/supervisord", line 9, in load_entry_point('supervisor==3.2.0', 'console_scripts', 'supervisord')() File "/usr/lib/python2.7/dist-packages/supervisor/supervisord.py", line 359, in main options = ServerOptions() File "/usr/lib/python2.7/dist-packages/supervisor/options.py", line 437, in __init__ existing_directory, default=tempfile.gettempdir()) File "/usr/lib/python2.7/tempfile.py", line 275, in gettempdir tempdir = _get_default_tempdir() File "/usr/lib/python2.7/tempfile.py", line 217, in _get_default_tempdir ("No usable temporary directory found in %s" % dirlist)) IOError: [Errno 2] No usable temporary directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/']`

arunwij (Wed, 05 Sep 2018 13:06:17 GMT):
@gudkov Thank you. This is the message i get when i run the *docker run -it -p 9701-9708:9701-9708 indy_pool* Seems my docker container closing immediately after starting it. Is there any other way to access logs? ``` Traceback (most recent call last): File "/usr/bin/supervisord", line 9, in load_entry_point('supervisor==3.2.0', 'console_scripts', 'supervisord')() File "/usr/lib/python2.7/dist-packages/supervisor/supervisord.py", line 359, in main options = ServerOptions() File "/usr/lib/python2.7/dist-packages/supervisor/options.py", line 437, in __init__ existing_directory, default=tempfile.gettempdir()) File "/usr/lib/python2.7/tempfile.py", line 275, in gettempdir tempdir = _get_default_tempdir() File "/usr/lib/python2.7/tempfile.py", line 217, in _get_default_tempdir ("No usable temporary directory found in %s" % dirlist)) IOError: [Errno 2] No usable temporary directory found in ['/tmp', '/var/tmp', '/usr/tmp', '/'] ```

PhillipGibb (Wed, 05 Sep 2018 13:21:34 GMT):
@arunwij The ip address in the genesis file: are they 10.0.0.2 or 127.0.0.1? I run the indy pool on my mac and had to change the genesis file to use 127.0.0.1 in order for my app to connect

sklump (Wed, 05 Sep 2018 13:22:24 GMT):
@arunwij also python2.7 is a red flag - indy needs >=3.5

arunwij (Wed, 05 Sep 2018 14:35:13 GMT):
@PhillipGibb yes i use 127.0.0.1. @sklump I have installed both versions of python. How can i make this to work with python3? PS: The application ran fine before i came across this problem :slight_smile: . I successfully ran the gettingStarted samples as well. Do you think there is storage issue with docker? ``` $ df -h Filesystem Size Used Avail Capacity iused ifree %iused Mounted on /dev/disk1s1 234Gi 207Gi 23Gi 90% 4100692 9223372036850675115 0% / devfs 189Ki 189Ki 0Bi 100% 652 0 100% /dev /dev/disk1s4 234Gi 2.0Gi 23Gi 8% 2 9223372036854775805 0% /private/var/vm map -hosts 0Bi 0Bi 0Bi 100% 0 0 100% /net map auto_home 0Bi 0Bi 0Bi 100% 0 0 100% /home /Users/mymac/Downloads/Hyper.app 234Gi 206Gi 25Gi 90% 4092457 9223372036850683350 0% /private/var/folders/yf/gz8nthpn6qs0w8ybhhpkpqfh0000gn/T/AppTransloca tion/30C2968E-8AE1-4971-AD7F-ABC451A49B90 ```

PhillipGibb (Wed, 05 Sep 2018 16:07:23 GMT):
@arunwij how about delete those images and starting again, also are you using the docker file in the indy-sdk/ci?

arunwij (Wed, 05 Sep 2018 16:20:54 GMT):
It worked after i delete unwanted containers. Thank you for your suggestions. @PhillipGibb @sklump

PhillipGibb (Wed, 05 Sep 2018 16:47:39 GMT):
yayy

PhillipGibb (Wed, 05 Sep 2018 16:47:58 GMT):
Trying to build the iOS libs for libvcx : Could not resolve host: repo.corp.evernym.com

sklump (Wed, 05 Sep 2018 16:49:50 GMT):
This one looks solvable. https://repo.evernym.com/

PhillipGibb (Wed, 05 Sep 2018 16:55:35 GMT):
true, except https://repo.evernym.com/filely/ios/libsovtoken_0.9.1-201808311521-ca7b339_all.zip does not exist

PhillipGibb (Thu, 06 Sep 2018 07:16:09 GMT):
anyone know where I can download libsovtoken?

AxelNennker (Thu, 06 Sep 2018 08:55:39 GMT):
While trying out the nodejs wrapper I get this ``` ignisvulpis@namenlos:~/development/hyperledger/indy-sdk/wrappers/nodejs$ npm install --save indy-sdk npm ERR! code ENOSELF npm ERR! Refusing to install package with name "indy-sdk" under a package npm ERR! also called "indy-sdk". Did you name your project the same npm ERR! as the dependency you're installing? npm ERR! npm ERR! For more information, see: npm ERR! npm ERR! A complete log of this run can be found in: npm ERR! /home/ignisvulpis/.npm/_logs/2018-09-06T08_54_34_652Z-debug.log ignisvulpis@namenlos:~/development/hyperledger/indy-sdk/wrappers/nodejs$ ```

marrowdev (Thu, 06 Sep 2018 10:07:07 GMT):
Hi, I am having an issue with "prover_search_credentials_for_proof_req", giving me error 113 InvalidStructure.

marrowdev (Thu, 06 Sep 2018 10:07:07 GMT):
Hi, I am having an issue with "prover_search_credentials_for_proof_req", giving me error 113 InvalidStructure. My proof request looks like: ``` { "name": "Job Application", "nonce": 17949284834566692534, "requested_attributes": { "attr1_referent": { "name": "First Name" }, "attr2_referent": { "name": "Last Name" }, "attr3_referent": { "name": "Job Title", "restrictions": [ { "cred_def_id": "Lu3qFL2uKcBYBBQTcJJnrm:3:CL:33:TrEn" } ] }, "attr4_referent": { "name": "Start Date", "restrictions": [ { "cred_def_id": "Lu3qFL2uKcBYBBQTcJJnrm:3:CL:33:TrEn" } ] }, "attr5_referent": { "name": "End Date", "restrictions": [ { "cred_def_id": "Lu3qFL2uKcBYBBQTcJJnrm:3:CL:33:TrEn" } ] } }, "requested_predicates": {}, "version": "1.0" } ```

marrowdev (Thu, 06 Sep 2018 10:37:56 GMT):
Also, after updating libindy to the latest version `export RUST_LOG=trace` no longer shows logging in std out?

sklump (Thu, 06 Sep 2018 10:44:15 GMT):
Does the cred def support revocation? If so it needs non-revocation interval(s).

marrowdev (Thu, 06 Sep 2018 10:45:18 GMT):
No it doesn't, I'm just trying to get a basic credential working at the moment

sklump (Thu, 06 Sep 2018 11:10:31 GMT):
Nonce should be a numeric string

sklump (Thu, 06 Sep 2018 11:10:57 GMT):
Attribute names can have spaces here, but you are going to hamstring yourself on that decision. Don't do it.

marrowdev (Thu, 06 Sep 2018 11:13:59 GMT):
That might be it, I'll try changing it now. What is the issue with having spaces in the attribute names?

sklump (Thu, 06 Sep 2018 11:17:39 GMT):
They're stored in some data structures canonicalized (spaces stripped, lower-case), so when you look for attributes on their name, you won't find them.

sklump (Thu, 06 Sep 2018 11:19:05 GMT):
It's the nonce as a number that makes this proof request invalid though.

marrowdev (Thu, 06 Sep 2018 12:01:53 GMT):
Ok good to know! Thanks a lot, you were right about the nonce so now the proof is being created successfully

PhillipGibb (Thu, 06 Sep 2018 13:12:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3Sts3PjB6hSCiucKp) @AxelNennker just use : `npm i` `npm i indy-sdk` if you are using it in a different project or if locally `npm i /development/hyperledger/indy-sdk/wrappers/nodejs`

sklump (Thu, 06 Sep 2018 16:14:13 GMT):
Hello, I notice that the most recent version in pypi is 1.6.5-rc-21. On github, the current master wrappers/python/setup.py specifies version 1.6.4. Please confirm that these versions are the same?

sklump (Thu, 06 Sep 2018 16:22:19 GMT):
In release candidate 1.6.5-rc-21, `wrappers/python/indy/pool.py`, function `async def set_protocol_version()`mouse-copies ``` if not hasattr(delete_pool_ledger_config, "cb"): logger.debug("set_protocol_version: Creating callback") delete_pool_ledger_config.cb = create_cb(CFUNCTYPE(None, c_int32, c_int32)) res = await do_call('indy_set_protocol_version', protocol_version, delete_pool_ledger_config.cb) ``` where it should be looking for attribute `set_protocol_version`, as per the current master. The master appears to have some log/trace comforts set in `libindy.py` and corrects a log string interpolation mismatch in `crypto.py` function `async def crypto_verify()` as well. I believe the release candidate is broken and needs a version bump, then propagation to pypi.

sklump (Thu, 06 Sep 2018 16:22:19 GMT):
In release candidate 1.6.5-rc-21, `wrappers/python/indy/pool.py`, function `async def set_protocol_version()`mouse-copies ``` if not hasattr(delete_pool_ledger_config, "cb"): logger.debug("set_protocol_version: Creating callback") delete_pool_ledger_config.cb = create_cb(CFUNCTYPE(None, c_int32, c_int32)) res = await do_call('indy_set_protocol_version', protocol_version, delete_pool_ledger_config.cb) ``` where it should be looking for attribute `set_protocol_version`, as per the current master. The master also: - defines some log/trace comforts set in `libindy.py` - corrects a log string interpolation mismatch in `crypto.py` function `async def crypto_verify()` - touches up a then/than doc typo in `wallet.py`. I believe the release candidate is broken (should not become the release) and needs a version bump, then propagation to pypi.

ShivVenkatraman (Thu, 06 Sep 2018 21:44:21 GMT):
When running the Java SDK samples https://github.com/hyperledger/indy-sdk/blob/master/samples/java (on Ubuntu), all the demo variants work except signAndSubmitRequest(pool, trusteeWallet, trusteeDid, nymRequest).get() in Ledger.java -- it gives a TimeoutException. Has anyone been able to run it successfully? Exception in thread "main" java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.ledger.TimeoutException: Timeout happens for ledger operation. at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895) at Ledger.demo(Ledger.java:60) at Main.main(Main.java:6) Caused by: org.hyperledger.indy.sdk.ledger.TimeoutException: Timeout happens for ledger operation. at org.hyperledger.indy.sdk.IndyException.fromSdkError(IndyException.java:120) at org.hyperledger.indy.sdk.IndyJava$API.checkResult(IndyJava.java:90) at org.hyperledger.indy.sdk.ledger.Ledger.access$100(Ledger.java:24) at org.hyperledger.indy.sdk.ledger.Ledger$1.callback(Ledger.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:520) at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:551)

mawi (Fri, 07 Sep 2018 09:23:30 GMT):
Has left the channel.

PhillipGibb (Fri, 07 Sep 2018 09:56:39 GMT):
What kind of validation is done on writing an endpoint attribute to the ledger? I am setting my DID endpoint to https://eas01.pps.evernym.com and I am receiving validation errors: `"{\"reason\":\"client request invalid: InvalidClientRequest(\'validation error [ClientAttribOperation]: invalid endpoint address (ha=https:\\/\\/eas01.pps.evernym.com)\',)\",\"identifier\":\"LJ8DWD3UU48cDqekrK5LMF\",\"reqId\":1536313836180387000,\"op\":\"REQNACK\"}"`

PhillipGibb (Fri, 07 Sep 2018 10:24:12 GMT):
seems like you have to add a port

PhillipGibb (Fri, 07 Sep 2018 10:29:01 GMT):
and you have to use an ip address

sklump (Fri, 07 Sep 2018 10:55:10 GMT):
Hello - is a release of 1.6.5 on github imminent? I'd like to synchronize the python wrapper with the virtual env package and if they are about to align, I might as well wait for the update.

sklump (Fri, 07 Sep 2018 10:55:10 GMT):
Hello - is a release of 1.6.5 on github imminent? I'd like to synchronize the shared library with the virtual env package and if they are about to align, I might as well wait for the update.

jacobsaur (Fri, 07 Sep 2018 23:11:31 GMT):
Is there any way to retrieve a credential definition that's stored in a wallet? The way I understand it is that the issuer only needs to have one credential definition in their wallet for one schema, and then they could issue multiple credentials to different provers using the same credential definition. The first time through things are fine because we have a schemaId and can call issuerCreateAndStoreCredentialDef() (I'm using the nodejs sdk wfi) to get the credDefId and credDefJson and go through the whole flow. But then on the second time through, how can I start with the same info (ie schemaId) and get the credDefId and credDefJson again - calling create results in an already exists error.

ShivVenkatraman (Fri, 07 Sep 2018 23:55:24 GMT):
How is encoded value generated in samples/../java/Anoncreds.java: String credValuesJson = new JSONObject("{\n" + " \"sex\": {\"raw\": \"male\", \"encoded\": \"594465709955896723921094925839488742869205008160769251991705001\"},\n" + " \"name\": {\"raw\": \"Alex\", \"encoded\": \"1139481716457488690172217916278103335\"},\n" + " \"height\": {\"raw\": \"175\", \"encoded\": \"175\"},\n" + " \"age\": {\"raw\": \"28\", \"encoded\": \"28\"}\n" + " }").toString();

arunwij (Sat, 08 Sep 2018 04:26:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=sPMTTJJ5fL4gAuQBA) @ShivVenkatraman I had the same issue. Encoding is not standardized yet in Indy-SDK. You can refer to these links to get more information. https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/master/von_anchor/codec.py https://jira.hyperledger.org/browse/IS-786

arunwij (Sat, 08 Sep 2018 12:46:12 GMT):
Hello, When creating a credential definition using *issuerCreateAndStoreCredentialDef* it takes about 15 seconds to complete the request. Is this behavior normal? I am using Node JS Wrapper of the Indy-SDK.

PhillipGibb (Sat, 08 Sep 2018 16:17:48 GMT):
trustee

PhillipGibb (Sat, 08 Sep 2018 16:18:47 GMT):
what is the difference between a steward and a trustee?

baconsandwich (Sat, 08 Sep 2018 17:55:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=PhJpKisKgPcrevHBC) @PhillipGibb A Trustee is allowed to "do" more like adding new Stewards, but a Stewards can only add new Trust Anchors (can "sign" claims) and Identity Owners. Imho a Trustee is like a global admin, but a Steward lacks more "global" privileges. And of course the Stewards main role goal is to run a node that is part of the plenum ledger.

baconsandwich (Sat, 08 Sep 2018 17:56:03 GMT):
See this for detailed permissions: https://docs.google.com/spreadsheets/d/1TWXF7NtBjSOaUIBeIH77SyZnawfo91cJ_ns4TR-wsq4/edit#gid=0

PhillipGibb (Sat, 08 Sep 2018 18:24:10 GMT):
thanks @baconsandwich . So then when a genesis txn file is put together, is there a relationship with trustee and stewards to that file

PhillipGibb (Sun, 09 Sep 2018 06:22:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=vr5wSsZpqmfw4zttc) @burdettadam Hi, I am attempting to use vcx but I keep getting *item not found* when I create/build a connection.

baconsandwich (Sun, 09 Sep 2018 17:08:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qoyb2zRtKgBe32qxu) @PhillipGibb I don't understand the question

baconsandwich (Sun, 09 Sep 2018 17:10:56 GMT):
Is it possible and sensible to have a "list all Stewards" when accessing the ledger? I mean, we only know the DIDs and afaik the Trustee verifies the DIDs of Stewards, right? I mean in general could an agent have a function to list all "administrative" identity owners? And is there such a thing in the indy-sdk? I could not find anyhting

PhillipGibb (Mon, 10 Sep 2018 08:00:04 GMT):
Please check out the stackoverflow proposal for questions concerning Indy (that would include sovrin, vcx, etc) https://area51.stackexchange.com/proposals/120021/hyperledger-indy?referrer=2Kckofvf6W-eWWrqyLlr9A2 I think that if there are some well defined questions in a contextual and better searchable place we can better develop SSI applications based on indy seems to require a lot of questions and votes so we'll need a bit of a group effort if we want this on stackoverflow

AxelNennker (Mon, 10 Sep 2018 08:52:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=CfWaRBPr5uWz3KQig) Have you found the reasoning why the endpoint on the ledger is ip-address:port but no url? There are in indy-node and in indy-plenum tests for this but I could not find any documentation on why url are not allowed https://github.com/hyperledger/indy-node/blob/master/indy_common/types.py#L193 https://github.com/hyperledger/indy-plenum/blob/master/plenum/common/util.py#L557 indy-sdk does not enforce any restriction on endpoint, it is just a string. https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/domain/ledger/attrib.rs#L88 The problem with ip_address:port is that it makes the protocol hardcoded.

PhillipGibb (Mon, 10 Sep 2018 10:58:51 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kdpcj67LG5X99S9Tz) @AxelNennker Seems that the error is coming from the node and that plenum only accepts ip addresses - which means that setting ab endpoint in the sdk will require a socket.gethostbyname (python) or dns.lookup (node)

arunwij (Mon, 10 Sep 2018 11:23:08 GMT):
Hello, ``` ```

arunwij (Mon, 10 Sep 2018 11:27:17 GMT):
Hi, ``` 'attr3_referent': { 'name': 'degree', 'restrictions': [{ 'cred_def_id': faberTranscriptCredDefId }] }, 'attr4_referent': { 'name': 'status', 'restrictions': [{ 'cred_def_id': faberTranscriptCredDefId }] }, ``` When creating proof request, Can I use *schema_id* instead *of cred_def_id* for restrictions field?

sklump (Mon, 10 Sep 2018 11:38:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=THL4TcCirsiXG4LRa) @arunwij Sure, you can use any of: ``` "schema_id": string, (Optional) "schema_issuer_did": string, (Optional) "schema_name": string, (Optional) "schema_version": string, (Optional) "issuer_did": string, (Optional) "cred_def_id": string, (Optional) ```

arunwij (Mon, 10 Sep 2018 13:01:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=xfb4G9uKYZYQ2LZgP) @sklump Thank you :thumbsup:. Is there any documentation where I can refer these?

PhillipGibb (Mon, 10 Sep 2018 13:06:01 GMT):
If I attempt to add create and store a DID from a seed, but the DID already exists. How can I obtain the DID and VerKey for that seed?

sklump (Mon, 10 Sep 2018 13:17:03 GMT):
Suggest you hash the seed and store it in metadata on creation, then search the wallet for the hash. Alternative is to create a temporary throwaway wallet on the seed, extract the data, destroy the wallet. The metadata approach is better because it will survive key rotation.

PhillipGibb (Mon, 10 Sep 2018 13:18:00 GMT):
thanks

PhillipGibb (Mon, 10 Sep 2018 13:19:41 GMT):
What about listing DIDs with meta - I see that there is nothing there to indicate the role that the DID has e.g. TRUST_ANCHOR, STEWARD or TRUSTEE? because that is really want to to find - the STEWARD DID that I have stored in the wallet

sklump (Mon, 10 Sep 2018 13:23:27 GMT):
I guess, more metadata then

PhillipGibb (Mon, 10 Sep 2018 13:30:43 GMT):
:)

sklump (Mon, 10 Sep 2018 13:42:47 GMT):
Sample seed wrangling at https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/99c6e8d3ebb2bad9de71d6a9e4d86539538c1beb/von_anchor/wallet.py#L257, https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/99c6e8d3ebb2bad9de71d6a9e4d86539538c1beb/von_anchor/wallet.py#L184

sklump (Mon, 10 Sep 2018 13:54:55 GMT):
Alternatively you could scrape out the DID, then query the ledger for the nym per DID, then stop when you find the one with `"role": "2"` (for STEWARD, among: ``` pub const STEWARD: &str = "2"; pub const TRUSTEE: &str = "0"; pub const TRUST_ANCHOR: &str = "101"; pub const TGB: &str = "100"; pub const ROLE_REMOVE: &str = ""; ``` )

PhillipGibb (Mon, 10 Sep 2018 15:09:04 GMT):
thanks @sklump

sklump (Mon, 10 Sep 2018 15:53:32 GMT):
Is there a road map regarding what 1.6.x release incorporates what features?

n3m (Mon, 10 Sep 2018 15:58:06 GMT):
Maybe you can perform a search of JIRA with something like this: https://jira.hyperledger.org/browse/IS-926?jql=project%20%3D%20%22IS%22%20AND%20fixVersion%20%3D%201.6.5 I am not sure about the road map. @gudkov knows more about that.

sklump (Mon, 10 Sep 2018 16:04:38 GMT):
The Jira entries ought to suffice, thanks

gudkov (Mon, 10 Sep 2018 16:12:56 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/CHANGELOG.md

burdettadam (Mon, 10 Sep 2018 16:16:58 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=7AeawfwviPJv4X5Ao) @PhillipGibb libvcx is currently experimental, I did not get my fork working completely yet. Libvcx has a new home in indysdk and is progressively being open-sourced. I suggest using libvcx as an example for now, don't spend too much time with it yet.

sklump (Mon, 10 Sep 2018 17:48:36 GMT):
Small detail: python wrapper `indy-sdk/wrappers/python/indy/crypto.py` line 172 method `async crypto_verify()` continues to be out of sync with master: release candidate 1.6.6-rc-22 is short one %r slot; i.e., ``` logger.debug("crypto_verify: >>> my_vk: %r, signed_msg: %r", signer_vk, msg, signature) ``` while master has had ``` logger.debug("crypto_verify: >>> my_vk: %r, signed_msg: %r, signature: %r", signer_vk, msg, signature) ``` for a few releases now.

sklump (Mon, 10 Sep 2018 17:48:36 GMT):
Small detail: python wrapper `indy-sdk/wrappers/python/indy/crypto.py` line 172 method `async crypto_verify()` continues to be out of sync with master: release candidate 1.6.6-rc-22 is short one `%r` formatting slot; i.e., ``` logger.debug("crypto_verify: >>> my_vk: %r, signed_msg: %r", signer_vk, msg, signature) ``` while master has had ``` logger.debug("crypto_verify: >>> my_vk: %r, signed_msg: %r, signature: %r", signer_vk, msg, signature) ``` for a few releases now.

gudkov (Tue, 11 Sep 2018 08:09:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=2vrHs3zmuDWpkJMkH) @sklump Thanks, could you send PR ?

xnopre (Tue, 11 Sep 2018 08:39:52 GMT):
Hi all, 1/ For a prover, is it mandatory to receive a "credential offer" to be able to send a "credential request" ? Or how can an actor send a "credential request" to an issuer without "credential offer" ? 2/ How can a prover retrieve a "credential definition" (apparently to be done by an issuer) ? Thanks

marrowdev (Tue, 11 Sep 2018 08:48:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9zd2mnzswWCuwfva2) @xnopre For 1) I think an initial offer is required, because when `anoncreds.issuer_create_credential` is called the parameters include a credential offer, and a credential request. For 2) the following code is what I have been using: ``` get_cred_def_request = await ledger.build_get_cred_def_request(prover_did, cred_def_id) get_cred_def_response = await ledger.submit_request(pool_handle, get_cred_def_request) (cred_def_id, cred_def_json) = await ledger.parse_get_cred_def_response(get_cred_def_response) ``` So as long as the prover has the cred_def_id, they can submit the request shown above to retrieve the contents of the credential definition from the ledger (cred_def_json). Retrieving a schema definition works in the same way

marrowdev (Tue, 11 Sep 2018 08:52:57 GMT):
Does anyone know why calling `issuer_create_and_store_revoc_reg` seems to either freeze up and never complete, or take an extremely long time? I can't seem to get logging to work anymore since updating, so I can't view messages from the API

sklump (Tue, 11 Sep 2018 10:33:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=xLDsJwqgD45qPiF7o) @marrowdev How many credentials are you specifying for `max_cred_num`? Expect about a quarter second per, if you've built libindy in debug mode. Build it in release mode for much better performance.

sklump (Tue, 11 Sep 2018 10:33:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=xLDsJwqgD45qPiF7o) @marrowdev How many credentials are you specifying for `max_cred_num`? Expect about a quarter second per, with issuance on demand (longer for issuance by default) if you've built libindy in debug mode. Build it in release mode for much better performance.

sklump (Tue, 11 Sep 2018 10:33:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=xLDsJwqgD45qPiF7o) @marrowdev How many credentials are you specifying for `max_cred_num`? Expect about a quarter second per, with issuance on demand (longer for issuance by default) if you've built libindy in debug mode. Build it in release mode for much better performance. Oh yeah, it's tails file creation that is computationally very heavy.

sklump (Tue, 11 Sep 2018 10:33:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=xLDsJwqgD45qPiF7o) @marrowdev How many credentials are you specifying for `max_cred_num`? Expect about a quarter second per, with issuance on demand (longer for issuance by default) if you've built libindy in debug mode. Build it in release mode for much better performance. Oh yeah, it's tails file creation that is computationally thirsty.

marrowdev (Tue, 11 Sep 2018 10:45:23 GMT):
Ah, I didn't specify so it defaulted to 100,000. That was definitely the issue thanks @sklump

RuWander (Tue, 11 Sep 2018 11:22:04 GMT):
Hi All, I think this has been asked before but I can't find it. Is it possible to get the handle for an opened wallet if you have "lost" the wallet handle, OR what is the best way to go about closing or regaining control of an opened wallet?

xnopre (Tue, 11 Sep 2018 12:57:16 GMT):
@marrowdev Thanks for your answers ! :-) 1/ I saw that `issuer_create_credential`, I don't really understand why, if someone has an explanation ? 2/ Thanks for the solution :-)

PhillipGibb (Tue, 11 Sep 2018 13:12:50 GMT):
What key spec is being used to create the signing and ver keys?

sklump (Tue, 11 Sep 2018 13:25:52 GMT):
ed25519

PhillipGibb (Tue, 11 Sep 2018 13:30:34 GMT):
thanks

baconsandwich (Tue, 11 Sep 2018 15:57:33 GMT):
```indy_list_wallets``` was recently removed because "The main idea is avoid maintaining created wallet list on libindy side.". But then how do I see which wallets are available on a machine? Afaics the wallets are curently stored in ~/.indy_client. Should I read the file system and check whats stored there? I want to show a user a list of available wallets.

baconsandwich (Tue, 11 Sep 2018 15:57:33 GMT):
`indy_list_wallets` was recently removed because "The main idea is avoid maintaining created wallet list on libindy side.". But then how do I see which wallets are available on a machine? Afaics the wallets are curently stored in ~/.indy_client. Should I read the file system and check whats stored there? I want to show a user a list of available wallets.

n3m (Tue, 11 Sep 2018 16:24:28 GMT):
are you asking for an API way to do this, or a hack?

ShivVenkatraman (Tue, 11 Sep 2018 19:04:12 GMT):
I am using the Java samples and wrapper as the basis for my prototype. I see the wallet stores data in sqllite (in ~/.indy_client by default). Is the personal data stored (e.g. Alex, his age in sample code) there? Is there a way to change the default storage from sqllite to some other database? Also, the specs (https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2016/blob/master/draft-documents/did-implementer-draft-10.md) mention that DDO has public keys and service end points? How do I take advantage of the service endpoints? The samples don't illustrate that. Got this for the DDO: {"reqId":1536622295997096205,"identifier":"TxrbtY4WfjXV51iymfuo7V","operation":{"type":"120","dest":"N7Yb8XkwheMk6R68ay58eA"},"protocolVersion":2}

n3m (Tue, 11 Sep 2018 19:21:07 GMT):
Currently there is only the default SQLite wallet

n3m (Tue, 11 Sep 2018 19:21:35 GMT):
libIndy allows you to write your own DB plugin for any kind of database and load it

n3m (Tue, 11 Sep 2018 19:22:16 GMT):
there is an API that you have to match and write a C callable database plugin

n3m (Tue, 11 Sep 2018 19:23:06 GMT):
if it is a prototype I doubt you will be doing this, but just saying that there is that possibility if you are evaluating libindy for some different wallet backend i.e. MySQL, MongoDB....

n3m (Tue, 11 Sep 2018 19:33:09 GMT):
Personal data -- the credential in the sample is stored in the secure wallet in an encrypted form

ShivVenkatraman (Tue, 11 Sep 2018 20:47:09 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6d2NArnz47vpkiHTH) @n3m Thanks, @n3m For multiple provers (identity owners) will each prover have to create his wallet to store the personal data? I see 2 folders -- issuerWallet and proverWallet -- getting created in ~/.indy_client directory. If each prover has to create his wallet; won't there be too many folders created (particularly if there are 1000s of provers)? Or can each prover create his own did using a common prover wallet; and use that (and credential request etc.) to store his credentials in the common wallet?

ShivVenkatraman (Tue, 11 Sep 2018 20:51:57 GMT):
I think I found the answer via AnoncredsIntegrationTest.java. Yes, looks like a common wallet can be used; with each credential distinguished by credentialId

ShivVenkatraman (Tue, 11 Sep 2018 21:42:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ydt5H6voBcvF3RvEe) @arunwij Thanks @arunwij . Any thoughts on how the encoding is done in the sample (and wrapper) Java code? Is there a built-in API?

haggs (Tue, 11 Sep 2018 21:50:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4c8eW8eKDr5qpgjcJ) Here's the current issue being tracked, https://jira.hyperledger.org/browse/IS-786

haggs (Tue, 11 Sep 2018 21:50:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4c8eW8eKDr5qpgjcJ) Here's the current issue being tracked, https://jira.hyperledger.org/browse/IS-786 @ShivVenkatraman

ShivVenkatraman (Tue, 11 Sep 2018 23:51:25 GMT):
In the Java SDK APIs, when a credential stored, which API has the issuer (and prover) signing the credential or claim? Does verifierVerifyProof access the ledger to verify the proof? How are the prover's public keys passed around? Does the sample code have an example?

jljordan_bcgov (Wed, 12 Sep 2018 04:55:14 GMT):
My understanding is that all nodes are discoverable in the config ledger and they are added by consensus... DNS is not trustworthy and therefore is not relied upon for resolving IP addresses for nodes @AxelNennker [ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kdpcj67LG5X99S9Tz)

PhillipGibb (Wed, 12 Sep 2018 07:16:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=hr2rJ3brdMOPjn26Gb) @jljordan_bcgov That makes sense. What of protocol and context? Maybe :433 will cater for https, but what if the endpoint is a context like 10.0.0.2:8080/ssi ?

AxelNennker (Wed, 12 Sep 2018 09:49:33 GMT):
@jljordan_bcgov naming this 'endpoint' leads app developers / libindy user to think this is a (https) url and implementors of cloud agents might want https 'endpoints' to be stored in the ledger. I am not arguing about DNS. IP addresses are safer but harder to maintain. My test node's changed ip addresses twice and then I had to tell the ledger. Which is OK but something to keep in mind as a validator operator. I think there is an issue in jira to maybe change the protocol from zmq to https which then would require a https://10.10.10.10:9707/ to be possible. I have put a comment in indy api to state the string endpoint is ip_address:port which helps developers to do the right thing. But I would like it if the api would check all parameters early and improve the documentation of the api more so that 'meaningful' types allow the wrappers to lead the developer in the right path. I understand the choice to have a string based api but also this makes it hard to guess what valid values are.

AxelNennker (Wed, 12 Sep 2018 09:53:00 GMT):
https://github.com/hyperledger/indy-sdk/pull/1131 (merged)

AxelNennker (Wed, 12 Sep 2018 09:53:02 GMT):
https://github.com/hyperledger/indy-sdk/pull/1132

AxelNennker (Wed, 12 Sep 2018 09:55:39 GMT):
I wish the wrappers had more meaningful parameter types and contructors that check for validity - at least for typed languages

sklump (Wed, 12 Sep 2018 10:45:40 GMT):
issuerCreateCredential() creates a credential; the operation includes signing it. E.g.,: ``` { "schema_id": "LjgpST2rjsoxYegQDRm7EL:2:non-revo:1.0", "cred_def_id": "LjgpST2rjsoxYegQDRm7EL:3:CL:16:tag", "rev_reg_id": null, "values": { "MustHave": { "raw": "chicken", "encoded": "127980826690676078" }, "PreferredName": { "raw": "Chicken Hawk", "encoded": "120861721625717118270508726123" } }, "signature": { "p_credential": { "m_2": "12793445067895681333541008404571656028744585880834393854282654815765098811607", "a": "64658412087674583984522643355097968479639007840172563333718644488430364798682202508324779588007493744855750412273334040635700475436443368168918949513275579636682847308701773898890406763533434448649080648713897508371116908547104235392791069932750931866076887330394359591466683431021705443907546476848559883683227958201384994284140867091815937926700267234774300193599670134263325141255684578158138329172862797399788308402744539536125165663684121814749139560932285851835509378616870573174733741016157298717993003380753186386951647319026415425560742994538891269900781264340237700848845634517020637142460898690539075017186", "e": "259344723055062059907025491480697571938277889515152306249728583105665800713306759149981690559193987143012367913206299323899696942213235956742929936763285962668260681278834646741013", "v": "6694371571392195940117111501213515130177895045875405387729898624221916746667264613167416239565192068352488705118709754578339388401007592667430889918057764939989418599757158387842936885051896262491056016307007802191060159402165688717376925980144305046061270912746965648640470667768022573909273444911379869668415344560152633225489785538563582541218572011346213384250960867927732781813474939969772354253543307606328167458340307554102693558865924156220459295754318932688938139264178157005011050004968085729921916050137710688183108669716237810919685813727595967971846320650736232028040904175896075750553418542268945366220150161195039418024590591819546263924948010400956072615183055785043879771132833796796244231700399486737574627869480277409492205176684390488168271097747442762011431970450080336870110296782050060090304513632" }, "r_credential": null }, "signature_correctness_proof": { "se": "6647156946860328261533947494620766654348024390698316519554619674104285690919019897651381750730629050930093041696658330932729751123347025803905804406021134651419084235327711533284738584707562979655945538880466931751596739927075612431331934891779313381405425888395675889030462977135576623282340657968699343966897181449444006154123713292516596354378670840214351551850631051594246717494994189530383721664831816762713693564497762543196555200155573092909650977174228573160841469016397914423747857153111560169352440837585163251297311387891105581702019296108476118223793618693520228377671162913618465837041051092584604240981", "c": "98249089969355070637056889957813524185356544936753953373026706813253056860824" }, "rev_reg": null, "witness": null }```

sklump (Wed, 12 Sep 2018 10:52:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=uDWqvpQTdrJKeouQS) @ShivVenkatraman Function issuerCreateCredential() signs the credential upon its issue. Function verifierVerifyProof needs access to the ledger only if any credential in the proof includes revocation support. The proof includes public keys to verify its correctness. There are heaps of examples in `indy-sdk/wrappers/java/src/test/java/org/hyperledger/indy/sdk/anoncreds/`.

sklump (Wed, 12 Sep 2018 10:52:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=uDWqvpQTdrJKeouQS) @ShivVenkatraman Function `issuerCreateCredential()` signs the credential upon its issue. Function `verifierVerifyProof()` needs access to the ledger only if any credential in the proof includes revocation support. The proof includes public keys to verify its correctness. There are heaps of examples in `indy-sdk/wrappers/java/src/test/java/org/hyperledger/indy/sdk/anoncreds/`.

PhillipGibb (Wed, 12 Sep 2018 12:41:08 GMT):
I am trying to open a wallet with indy-cli protocol=1 then key is correct but I get Wallet "acme" not found or unavailable

MaheshSharma (Wed, 12 Sep 2018 14:16:57 GMT):
We have run command indy-cli but showing Error :mountain_bicyclist_tone3: symbol lookup error:indy-sdk/libindy/target/debug/libindy.so: undefined symbol: crypto_pwhash

MaheshSharma (Wed, 12 Sep 2018 14:16:57 GMT):
We have run command indy-cli but showing Error mountain_bicyclist_tone3: symbol lookup error:indy-sdk/libindy/target/debug/libindy.so: undefined symbol: crypto_pwhash

sklump (Wed, 12 Sep 2018 14:23:29 GMT):
@MaheshSharma update libsodium: ``` bash -c "LC_ALL=C.UTF-8 add-apt-repository -y ppa:ondrej/php" apt update -y && apt install -y libsodium-dev ```

sklump (Wed, 12 Sep 2018 14:23:29 GMT):
@MaheshSharma update libsodium to libsodium.so.23.*: ``` bash -c "LC_ALL=C.UTF-8 add-apt-repository -y ppa:ondrej/php" apt update -y && apt install -y libsodium-dev ```

kenebert (Wed, 12 Sep 2018 16:54:19 GMT):
Has joined the channel.

joseflorido1980 (Wed, 12 Sep 2018 18:17:13 GMT):
Has joined the channel.

joseflorido1980 (Wed, 12 Sep 2018 18:19:48 GMT):
Hi guys, I following the instructions of the page https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md; and when trying to run the TEST: RUST_TEST_THREADS=1 cargo test I am getting the following error: test ledger_demo_works ... FAILED. Has anyone got the same error?. Thanks!!

n3m (Wed, 12 Sep 2018 18:21:09 GMT):
@joseflorido1980 sorry for asking this, but you have a local ledger running on your machine while running tests right?

joseflorido1980 (Wed, 12 Sep 2018 18:21:57 GMT):
Thanks n3m... I hope so... I am quite new in this, so I am following the instructions to the letter... I will double-check just in case...

n3m (Wed, 12 Sep 2018 18:26:04 GMT):
@joseflorido1980 this part of the documentation should cover that: https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker. You can confirm by listing all docker containers with `sudo docker container ls`

joseflorido1980 (Wed, 12 Sep 2018 18:26:49 GMT):
thanks a lot!

ShivVenkatraman (Wed, 12 Sep 2018 18:32:26 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=E7E8FwDqoErfYqbbH) @sklump Thanks @sklump. Sorry, I am a newbie. I am looking at the examples of issuerCreateCredential() in wrappers/Tests/ ... and I am not able to figure where/how the public/private keys are used to sign the credential; and if the proof includes public key. code snippet from IssuerCreateCredentialTest.java Anoncreds.issuerCreateCredential(wallet, issuer1GvtCredOffer, issuer1GvtCredReq, credValues, null, - 1).get();

sklump (Wed, 12 Sep 2018 19:16:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=C7rmQHZ6jFJ8Ret8Y) @ShivVenkatraman https://groups.csail.mit.edu/cis/pubs/lysyanskaya/cl02b.pdf If you want to know deeper than 'the indy-sdk shared library applies them', start reading

arjanvaneersel (Thu, 13 Sep 2018 11:05:01 GMT):
@nage During the hyperledger hackfest you told me that somebody already created a Go wrapper for Indy. Do you know the state of this wrapper and where to find it?

arjanvaneersel (Thu, 13 Sep 2018 11:05:01 GMT):
@nage During the hyperledger hackfest in Amsterdam you told me that somebody already created a Go wrapper for Indy. Do you know the state of this wrapper and where to find it?

MaheshSharma (Thu, 13 Sep 2018 11:15:11 GMT):
Hello,We have Build indy-cli cd cli/ RUSTFLAGS=" -L ../libindy/target/debug" cargo build Showing error indy-cli: symbol lookup error:indy-sdk/libindy/target/debug/libindy.so: undefined symbol: crypto_pwhash

sklump (Thu, 13 Sep 2018 11:21:04 GMT):
@MaheshSharma update libsodium to libsodium.so.23.*: ``` # LC_ALL=C.UTF-8 add-apt-repository -y ppa:ondrej/php # apt update -y && apt install -y libsodium-dev ```

MaheshSharma (Thu, 13 Sep 2018 11:32:19 GMT):
@sklump Thanks. we have run these command but showing same error when we have run INDY-CLI and cd wrappers/python pytest.

sklump (Thu, 13 Sep 2018 11:34:44 GMT):
Did you rebuild libindy against the new libsodium? ``` $ cd indy-sdk/libindy $ cargo build --release ```

MaheshSharma (Thu, 13 Sep 2018 11:48:16 GMT):
@sklump We have rebuild libindy .

MaheshSharma (Thu, 13 Sep 2018 11:49:02 GMT):
@sklump Run these command again ? # LC_ALL=C.UTF-8 add-apt-repository -y ppa:ondrej/php # apt update -y && apt install -y libsodium-dev

sklump (Thu, 13 Sep 2018 11:50:21 GMT):
(With the # as the sudo prompt, not a comment). I think you have to update libsodium, then rebuild libindy against it. I've run into this, months ago, and I think that was how I fixed it.

sklump (Thu, 13 Sep 2018 11:50:40 GMT):
I'm assuming you're on ubuntu 16. OS ubuntu 18 is not supported yet.

MaheshSharma (Thu, 13 Sep 2018 11:52:29 GMT):
@sklump cargo build --release working fine and we have used ubuntu 16.04

MaheshSharma (Thu, 13 Sep 2018 12:11:22 GMT):
@sklump After cargo build --release we have run cd indy-sdk/cli RUSTFLAGS=" -L ../libindy/target/debug" cargo build and indy-sdk/wrappers/python$ pytest showing same error according screenshot.

MaheshSharma (Thu, 13 Sep 2018 12:11:38 GMT):

Screenshot from 2018-09-13 17-38-07.png

MaheshSharma (Thu, 13 Sep 2018 12:13:09 GMT):

Screenshot from 2018-09-13 17-37-30.png

sklump (Thu, 13 Sep 2018 12:15:11 GMT):
What do you get from `ls -l /usr/lib/x86_64-linux-gnu/libsodium.so` ?

gudkov (Thu, 13 Sep 2018 12:15:42 GMT):
@MaheshSharma On Unbuntu 16.4 default libsodium is too old. Check build documentation on how to mitigate it https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md

gudkov (Thu, 13 Sep 2018 12:16:15 GMT):
for ubuntu 16.04 we link libsodium statically in our debian packages

MaheshSharma (Thu, 13 Sep 2018 12:19:15 GMT):
@gudkov so we have re install libsodium ?

MaheshSharma (Thu, 13 Sep 2018 12:19:36 GMT):
@gudkov like curl https://download.libsodium.org/libsodium/releases/libsodium-1.0.14.tar.gz

MaheshSharma (Thu, 13 Sep 2018 12:20:35 GMT):
@gudkov or We have run this command ls -l /usr/lib/x86_64-linux-gnu/libsodium.so (as you provided).

MaheshSharma (Thu, 13 Sep 2018 12:20:35 GMT):
@gudkov or We have run this command ls -l /usr/lib/x86_64-linux-gnu/libsodium.so (as @sklump provided).

MaheshSharma (Thu, 13 Sep 2018 12:23:07 GMT):
@sklump We get lrwxrwxrwx 1 root root 19 Jan 4 2018 /usr/lib/x86_64-linux-gnu/libsodium.so -> libsodium.so.23.1.0

sklump (Thu, 13 Sep 2018 12:23:39 GMT):
The version looks good, I have no further tricks here.

MaheshSharma (Thu, 13 Sep 2018 12:25:25 GMT):
@gudkov hello we have checked libsodium throw this comment ls -l /usr/lib/x86_64-linux-gnu/libsodium.so

MaheshSharma (Thu, 13 Sep 2018 12:25:45 GMT):
@gudkov We get lrwxrwxrwx 1 root root 19 Jan 4 2018 /usr/lib/x86_64-linux-gnu/libsodium.so -> libsodium.so.23.1.0

MaheshSharma (Thu, 13 Sep 2018 12:29:51 GMT):
@gudkov Please check my libsodium version correct or not ?

MaheshSharma (Thu, 13 Sep 2018 13:02:43 GMT):
Hello, We have run cd indy-sdk/cli RUSTFLAGS=" -L ../libindy/target/debug" cargo build and indy-sdk/wrappers/python$ pytest showing same error "libindy.so: undefined symbol: crypto_pwhash(Indy-cli),OSError debug/libindy.so: undefined symbol: crypto_pwhash(With pytest in wrappers/python)"

gudkov (Thu, 13 Sep 2018 13:05:52 GMT):
@MaheshSharma Most probably during build you use correct version, but when you run you dynamically link with another libsodium installed on your system

MaheshSharma (Thu, 13 Sep 2018 13:10:26 GMT):
@gudkov but we run command according this one (https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md)

gudkov (Thu, 13 Sep 2018 13:16:35 GMT):
I suggest to build with *--features sodium_static*. It will solve your problem in reliable way.

Rantwijk (Thu, 13 Sep 2018 13:16:56 GMT):
Has joined the channel.

MaheshSharma (Thu, 13 Sep 2018 13:18:18 GMT):
@gudkov We have run this one? RUSTFLAGS=" -L ../libindy/target/debug" cargo build --features sodium_static

MaheshSharma (Thu, 13 Sep 2018 13:18:18 GMT):
@gudkov We will run this one? RUSTFLAGS=" -L ../libindy/target/debug" cargo build --features sodium_static

gudkov (Thu, 13 Sep 2018 13:20:35 GMT):
You need --features sodium_static during libindy build, not cli

MaheshSharma (Thu, 13 Sep 2018 13:20:59 GMT):
@gudkov ok

MaheshSharma (Thu, 13 Sep 2018 13:29:54 GMT):
@gudkov WE have run sudo cargo build --features sodium_static and we get ..."Compiling indy v1.6.5 (file:///home/prateek/indy-sdk/libindy) Finished dev [unoptimized + debuginfo] target(s) in 2m 48s"

sklump (Thu, 13 Sep 2018 13:31:43 GMT):
I hate to bring bad news, but for 1.6.6 release, `wrappers/python/setup.py` still has version 1.6.5.

MaheshSharma (Thu, 13 Sep 2018 13:44:43 GMT):
@gudkov thanks for help. RUSTFLAGS=" -L ../libindy/target/debug cargo build working fine.

MaheshSharma (Thu, 13 Sep 2018 14:07:23 GMT):
@gudkov we have run pool connect pool1 command and get Pool "pool1" has not been connected.

MaheshSharma (Thu, 13 Sep 2018 14:13:24 GMT):
We have run pool connect pool1 command and get issue Pool "pool1" has not been connected.

nage (Thu, 13 Sep 2018 14:18:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=vCEK4TNpM9akYRsXj) @arjanvaneersel I do not know the state of this wrapper, but @dkulic was working on that effort. We have also heard from some folks at SecureKey that they had plans for such a wrapper.

xnopre (Thu, 13 Sep 2018 14:23:26 GMT):
Hi all :-) . 1/ With `prover_store_credential`, I can store a received credential. But is it possible to delete this credential from my wallet ? 2/ Where can I find informations for "revocation" (and "revocation state") ? Which actor has to do revocation ? What consequences ? ... Thanks

MaheshSharma (Thu, 13 Sep 2018 14:28:16 GMT):
@sklump We have run pool connect pool1 command and get issue Pool "pool1" has not been connected.

sklump (Thu, 13 Sep 2018 14:31:10 GMT):
Is this indy-sdk? Perhaps you want indy-node.

sklump (Thu, 13 Sep 2018 14:31:10 GMT):
@MaheshSharma Is this indy-sdk? Perhaps you want indy-node.

sklump (Thu, 13 Sep 2018 14:33:04 GMT):
@xnopre https://github.com/hyperledger/indy-sdk/blob/master/doc/cred-revocation.md The issuer is responsible for revocation. See `indy-sdk/wrapper/python/tests/interation/test_interaction.py`

sklump (Thu, 13 Sep 2018 14:33:04 GMT):
@xnopre https://github.com/hyperledger/indy-sdk/blob/master/doc/cred-revocation.md Indy-sdk does not present an API call to delete a credential from a wallet. You can create a new wallet, select all credentials but the one you want to delete (via WQL), and store each into the new wallet. Not great. The issuer is responsible for revocation. See `indy-sdk/wrapper/python/tests/interation/test_interaction.py`

PhillipGibb (Thu, 13 Sep 2018 14:43:34 GMT):
Unable to open a wallry

MaheshSharma (Thu, 13 Sep 2018 14:43:43 GMT):
@sklump We have Started the test pool on localhost accordind this command "docker build -f ci/indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9708:9701-9708 indy_pool" and after go to indy-cli

PhillipGibb (Thu, 13 Sep 2018 14:47:38 GMT):
Unable to Open (cli) a wallet created with VCX (that uses libindy 1.3.0) although I am using libindy 1.3.0 and it's cli It does not see the wallet with: `wallet list` but thinks that it is encrypted if I import it although I supplied the correct key Has anyone seen this?

sklump (Thu, 13 Sep 2018 14:48:45 GMT):
@MaheshSharma my experience is only within the indy-sdk itself. I'm a relying developer like yourself - I don't work for sovrin/indy.

sklump (Thu, 13 Sep 2018 14:48:45 GMT):
@MaheshSharma my experience is mainlywithin the indy-sdk itself. I'm a relying developer like yourself - I don't work for sovrin/indy.

sklump (Thu, 13 Sep 2018 14:48:45 GMT):
@MaheshSharma my experience is mainly within the indy-sdk itself. I'm a relying developer like yourself - I don't work for sovrin/indy.

sklump (Thu, 13 Sep 2018 18:21:52 GMT):
Hello, is it possible to change the wallet's access credentials - i.e., to change the `key` value required to open it?

n3m (Thu, 13 Sep 2018 18:25:50 GMT):
yes, you need to perform a `rekey`

n3m (Thu, 13 Sep 2018 18:26:19 GMT):
when opening a wallet you provide the new key in the the credentials JSON

n3m (Thu, 13 Sep 2018 18:26:25 GMT):
here is a snipplet

n3m (Thu, 13 Sep 2018 18:26:28 GMT):
``` JSONObject defaultJsonCreds = new JSONObject(credentials); defaultJsonCreds.put("rekey", rekey); wallet = Wallet.openWallet(config, defaultJsonCreds.toString()).get(); ```

n3m (Thu, 13 Sep 2018 18:27:04 GMT):
place the new key with the rekey key in the json, open the wallet, and that should change the key

n3m (Thu, 13 Sep 2018 18:27:13 GMT):
if that was the question @sklump

n3m (Thu, 13 Sep 2018 18:28:05 GMT):
after closing the wallet, just use the new key as youy key in the JSON

n3m (Thu, 13 Sep 2018 18:28:05 GMT):
after closing the wallet, just use the new key as your key in the JSON

n3m (Thu, 13 Sep 2018 18:28:10 GMT):
too many keys...

ShivVenkatraman (Thu, 13 Sep 2018 21:23:00 GMT):
basic question: what is the difference between requested_attributes and requested_predicates in proof_request? Are predicates used just for value comparison (e.g. age>18)? Can either of them (requested_attributes/requested_predicates) be empty in proverGetCredentialsForProofReq? In the json response, the API proverGetCredentialsForProofReq gets the credentials (in attrs json attribute) of all the provers. The filter used in requested_predicates is applied only in predicates json attribute

mccown (Fri, 14 Sep 2018 01:12:39 GMT):
I'm using the Java wrapper for libindy and was curious about listing the contents of my wallet. I only seem to be able to do management functions (e.g., create, open, delete), but I'm not sure how to list the contents. Any pointers?

QinghuaLu (Fri, 14 Sep 2018 01:48:03 GMT):
Has joined the channel.

QinghuaLu (Fri, 14 Sep 2018 01:48:11 GMT):
Hi, I got a 114 error when i tried to run write_did.py example. The error message is _indy_loop_callback: Function returned error 114 Error occurred: ErroCode.CommonIOError Anyone knows how to address this issue? Thanks

MaheshSharma (Fri, 14 Sep 2018 07:29:32 GMT):
I'm using Indy-cli: We have run command pool(pool1):wallet(alice_wallet):did(Av6...4c3):indy> ledger nym did= adddid but we have get from this command:Transaction has been rejected: Can not find verkey for DID.

n3m (Fri, 14 Sep 2018 07:55:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=FLstWSaPLrGrbCdXx) @QinghuaLu That error is a bit too generic to really know what is happening. Maybe you can turn the logs on with `RUST_LOG=trace` variable just so we have a trace and idea what is happening in the executing code that is triggering this error

n3m (Fri, 14 Sep 2018 07:55:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=FLstWSaPLrGrbCdXx) @QinghuaLu That error is a bit too generic to really know what is happening. Maybe you can turn the logs on with `RUST_LOG=trace` variable in your execution environment just so we have a trace and an idea what is happening in the executing code that is triggering this error

MaheshSharma (Fri, 14 Sep 2018 07:57:44 GMT):
I'm using Indy-cli: We have run command pool(pool1):wallet(alice_wallet):did(Av6...4c3):indy> ledger nym did= adddid verkey= add verkey but we have get from this command:Transaction has been rejected: Invalid format of command params. Please check format of posted JSONs, Keys, DIDs and etc...

PhillipGibb (Fri, 14 Sep 2018 08:00:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=YBrFMRgsTQkbSY4QJ) @MaheshSharma the did that you are using to sent the nym (Av6....) is that a did that is ledgered?

MaheshSharma (Fri, 14 Sep 2018 08:02:48 GMT):
@PhillipGibb Yes, we have used DID sent the nym (Av6....) .

n3m (Fri, 14 Sep 2018 08:03:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jw6LahbvSGwWJNcFw) @mccown You can perform a search of the wallet without a search condition. This will in tern return all items from a wallet.

MaheshSharma (Fri, 14 Sep 2018 08:03:09 GMT):
@PhillipGibb With verkey.

PhillipGibb (Fri, 14 Sep 2018 08:03:24 GMT):
@MaheshSharma hmmm, and you can confirm that with a get-nym?

n3m (Fri, 14 Sep 2018 08:35:58 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=XJ3owzNqhHrCBWJny) @baconsandwich One way to go about this is for your app to keep a list of all wallets created, Or you can play with the filesystem and extract info from there

MaheshSharma (Fri, 14 Sep 2018 09:13:04 GMT):
@PhillipGibb No, We have run get-nym with did : NYM not found

fmjbs (Fri, 14 Sep 2018 18:19:59 GMT):
Has joined the channel.

dkulic (Sat, 15 Sep 2018 15:02:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=cTKAyxTuYxzfXyAZD) @nage actualy, @jankokrstic is working on that wrapper.

AxelNennker (Sat, 15 Sep 2018 15:40:01 GMT):
bumped rust openssl version to 0.10.12 in indy-crypto and indy-sdk which used openssl 1.1.1 which support ed25519, tls1.3 and has better Android support https://github.com/hyperledger/indy-crypto/pull/126 https://github.com/hyperledger/indy-sdk/pull/1142

ysz (Sat, 15 Sep 2018 15:42:25 GMT):
Has joined the channel.

ysz (Sat, 15 Sep 2018 15:42:30 GMT):
hello

ysz (Sat, 15 Sep 2018 16:05:10 GMT):
My name is Yakov. I'm bootstrapping my Estonian company YSZ which pivoted to building distributed ledger for personal data portability (GDPR). It was freshGDPR.com. I signed an agreement with law firm from Milan who wants to "sign up 6-8 new clients". I'm looking to get minimal viable ecosystem for blockchain (Indy) running with biggest Italian companies (clients of law firm)

ysz (Sat, 15 Sep 2018 16:06:14 GMT):
I'm here to learn and start hacking Indy

arunwij (Sun, 16 Sep 2018 07:40:04 GMT):
Hi, when i try to ged did info for steward did i get this type of response, ``` { result: { identifier: 'W2RuP3TT7BFc6yqkoJ2rdh',reqId: 1537083304978967000, [gov] type: '105', [gov] seqNo: null, [gov] dest: 'Th7MpTaRZVRYnPiabds81Y', [gov] data: null, [gov] txnTime: null }, [gov] op: 'REPLY' } ```

arunwij (Sun, 16 Sep 2018 07:44:06 GMT):
Hi, when I try to get did info for steward did, I get this response, with null *data* field. Steward did generated by seed provided in the samples. What is the reason for that? Any thaughts? ``` { result: { identifier: 'W2RuP3TT7BFc6yqkoJ2rdh',reqId: 1537083304978967000, type: '105', seqNo: null, dest: 'Th7MpTaRZVRYnPiabds81Y', data: null, txnTime: null }, op: 'REPLY' } ```

arunwij (Sun, 16 Sep 2018 07:44:06 GMT):
Hi, when I try to get did info for steward did, I get this response, with null *data* field. Steward did generated by seed provided in the samples. What is the reason for that? Any thoughts? ``` { result: { identifier: 'W2RuP3TT7BFc6yqkoJ2rdh',reqId: 1537083304978967000, type: '105', seqNo: null, dest: 'Th7MpTaRZVRYnPiabds81Y', data: null, txnTime: null }, op: 'REPLY' } ```

arunwij (Sun, 16 Sep 2018 07:44:06 GMT):
Hi, when I try to get did info for steward did, I get this response, with null *data* field. Steward did generated by seed provided in the samples. What is the reason for that? Any thoughts? ``` { result: { identifier: 'W2RuP3TT7BFc6yqkoJ2rdh', reqId: 1537083304978967000, type: '105', seqNo: null, dest: 'Th7MpTaRZVRYnPiabds81Y', data: null, txnTime: null }, op: 'REPLY' } ```

arunwij (Sun, 16 Sep 2018 07:44:06 GMT):
Hi, when I try to get did info for steward did, I get this response, with null *data* field. Steward did generate by seed provided in the samples. What is the reason for that? Any thoughts? ``` { result: { identifier: 'W2RuP3TT7BFc6yqkoJ2rdh', reqId: 1537083304978967000, type: '105', seqNo: null, dest: 'Th7MpTaRZVRYnPiabds81Y', data: null, txnTime: null }, op: 'REPLY' } ```

xnopre (Mon, 17 Sep 2018 07:57:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3Da2MvauQoKCNEsDB) @sklump Thank you for your answer ! And is it possible to delete a credential from the wallet ?

PhillipGibb (Mon, 17 Sep 2018 14:19:34 GMT):
Retrieving a DID from a seed? If my wallet already has the DID but I no longer know which DID in my wallet was created with that seed: How do I retrieve the DID? I can get the VerKey from the seed, but not the DID thanks

PhillipGibb (Mon, 17 Sep 2018 15:14:39 GMT):
After building and using the debug libs that have resulted from cargo build: How do I activate logging?

n3m (Mon, 17 Sep 2018 15:16:08 GMT):
you need to set the `RUST_LOG` variable

n3m (Mon, 17 Sep 2018 15:16:08 GMT):
@PhillipGibb you need to set the `RUST_LOG` variable

n3m (Mon, 17 Sep 2018 15:16:16 GMT):
```RUST_LOG=trace```

n3m (Mon, 17 Sep 2018 15:16:23 GMT):
this will be very detailed

n3m (Mon, 17 Sep 2018 15:16:49 GMT):
and it will output the logs on the screen (stderr)

gudkov (Mon, 17 Sep 2018 15:22:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jy939W7EBoKvMP3vZ) @n3m It depends on what version of libindy is used. If it is 1.6 stable than setting RUST_LOG will help. Master version of libindy uses different approach. It allows application to register handlers for emitted log events by call indy_set_logger. It is possible to fallback to the old behavior by calling ind_set_default_logger. Java and python wrappers perform automatic logs bridging to python logger and slf4j facades.

n3m (Mon, 17 Sep 2018 15:24:39 GMT):
@PhillipGibb listen to @gudkov :)

n3m (Mon, 17 Sep 2018 15:25:11 GMT):
I was not aware of this behavior

PhillipGibb (Mon, 17 Sep 2018 16:36:12 GMT):
@n3m @gudkov I see some mention in the python wrapper but not in the nodejs otherwise I tried setting the backtrace and the rust log, but no effect is this something that has to be done when I build the libs?

n3m (Mon, 17 Sep 2018 18:38:08 GMT):
Nah, it is a runtime thing

n3m (Mon, 17 Sep 2018 18:39:41 GMT):
I do not know the status of nodejs wrapper

PhillipGibb (Mon, 17 Sep 2018 18:41:56 GMT):
@n3m it did work at some stage but I have switch between version so often I can't remember when

PhillipGibb (Mon, 17 Sep 2018 19:14:36 GMT):
@n3m I am suspecting that my logger (winston) is supressing the rust logging, it is a guess but I am grabbing at straws

n3m (Mon, 17 Sep 2018 20:20:24 GMT):
@PhillipGibb, hm, I do not know how to help you with that. Maybe the best option is to let this sit until tomorrow and we can ask some folks that are maintaining indy-sdk and know nodejs

ShivVenkatraman (Tue, 18 Sep 2018 00:12:06 GMT):
I have the following sequence: (i) AnonCreds.proverStoreCredential() (ii) AnonCreds.proverCreateProof() In (i), I store values like name, age, gender, height etc. In (ii), I pass in just name and age in the proofRequest json. Yet, the returned proof returns other data like gender, height etc. How do I filter so that the returned proof contains just name and age? The verifier should not see the other data.

ShivVenkatraman (Tue, 18 Sep 2018 00:12:06 GMT):
I have the following sequence: (i) AnonCreds.proverStoreCredential() (ii) AnonCreds.proverCreateProof() In (i), I store values like name, age, gender, height etc. In (ii), I pass in just name and age in the proofRequest json. While the revealed_attrs in the proofRequest json has the attribute I would like to expose to verifier, I also see height etc (albeit encoded) in "m" attribute of proofRequest json. How do I filter so that the returned proof contains just name and age? The verifier should not see the other data.

kdenhartog (Tue, 18 Sep 2018 00:55:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3BSTtezGZczr9jpaY) @burdettadam This may help you with the logging you wanted on Friday

PhillipGibb (Tue, 18 Sep 2018 04:27:23 GMT):
opening an existing wallet with cli: after creating and storing a few DIDs I attempt to open my wallet in indy-cli using the libs built off master connect to pool1 with protocol version 1 wallets list show no wallets attempting to import the wallet with the same name = wallet already exists import with a different name : cannot import, with no other info

PhillipGibb (Tue, 18 Sep 2018 05:32:50 GMT):
b.t.w. If I delete the wallet, create it in indi-cli then I can use it in both cli and my agent

KanupriyaPandey (Tue, 18 Sep 2018 07:15:05 GMT):
docker

gudkov (Tue, 18 Sep 2018 07:50:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ntjA265Z36KEB64cK) @PhillipGibb We discussed with @farskipper that we need to implement log event emitter for NodeJS wrapper or at least expose set_default_logger call in NodeJS API.

PhillipGibb (Tue, 18 Sep 2018 09:49:37 GMT):
Concerning Credential Definitions: 1. When a definition is created by an issuer, the defn is stored on the ledger along with the issuer's did, verkey for that defn and the schema it uses? 2. The issuer stores the signing key that will be used to sign creds for that cred defn? 3. Is that the same key for and credential signed by the issuer that uses that cred defn? 4. The keys for that cred defn are not the same keys associated with the issuer's DID or the PW relationship DID that is associated with the person the cred is for?

ThomasKrech (Tue, 18 Sep 2018 10:28:55 GMT):
hi i have three questions regarding to credential issuing and something like creation-date-time 1. how can i get the information when a credential was created? i'm currently using ```` let [debitCardCredential] = await sdk.issuerCreateCredential(stewardClient.wallet, debitCardCredOffer, debitCardCredRequest, debitCardValues); return await sdk.proverStoreCredential(indyClient.wallet, null, debitCardRequestMetadata, debitCardCredential, debitCardCredDef); ``` 2. i tried to store this information in metadata ```` let [debitCardCredRequest, debitCardRequestMetadata] = await sdk.proverCreateCredentialReq(indyClient.wallet, indyClient.endpointDid, debitCardCredOffer, debitCardCredDef, await DidHandler.getInstance().getEndpointDidAttribute(indyClient, 'master_secret_id')); debitCardRequestMetadata.createdAt = Date.now(); ``` but where can i get the metadata in the sdk 3. in the sdk i'm using ```sdk.proverGetCredentials``` here the creation date is also not contained

ThomasKrech (Tue, 18 Sep 2018 10:28:55 GMT):
hi i have three questions regarding to credential issuing and something like creation-date-time 1. how can i get the information when a credential was created? i'm currently using ```` let [debitCardCredential] = await sdk.issuerCreateCredential(stewardClient.wallet, debitCardCredOffer, debitCardCredRequest, debitCardValues); return await sdk.proverStoreCredential(indyClient.wallet, null, debitCardRequestMetadata, debitCardCredential, debitCardCredDef); ``` 2. i tried to store this information in metadata ``` let [debitCardCredRequest, debitCardRequestMetadata] = await sdk.proverCreateCredentialReq(indyClient.wallet, indyClient.endpointDid, debitCardCredOffer, debitCardCredDef, await DidHandler.getInstance().getEndpointDidAttribute(indyClient, 'master_secret_id')); debitCardRequestMetadata.createdAt = Date.now(); ``` but where can i get the metadata in the sdk 3. in the sdk i'm using ```sdk.proverGetCredentials``` here the creation date is also not contained

baconsandwich (Tue, 18 Sep 2018 11:46:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=DZYu2v5Wd5Lj5fFvp) @n3m So, there is no "canonical" solution, yet?

tomislav (Tue, 18 Sep 2018 13:52:09 GMT):
Are there any demo script or tests out there on how to use the Payment interface? I'm looking through the vcx code, and things get a bit clearer, but I thought I should ask. Speaking of vcx, the creation of schema and credential definition have payment info attached on them. Is this where a premium credential is defined or is that application specific and just communicated using payment address/amount when creating an offer?

gudkov (Tue, 18 Sep 2018 14:37:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6mmvXBuhcPPNnA68c) @baconsandwich It is *impossible* to provide canonical solution. Let's consider high load cloud agent that executes in different processes on different hosts, but uses one wallet inside of shared database. Additional example is iOS application that can't share files between processes in a secure way. As result the way to resolve wallets is different for different application use cases and this responsibility was removed from libindy.

baconsandwich (Tue, 18 Sep 2018 15:05:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=R7Sggi4YedNkeb7Sr) @gudkov I see, thanks for the explanation. But how does indy.open_wallet() know where to open the wallet? I struggle to understand the rust code which seems to call a c function.

baconsandwich (Tue, 18 Sep 2018 15:10:33 GMT):
Nevermind, I found the documentation in open_wallet in the python wrapper

darienhess (Tue, 18 Sep 2018 19:45:14 GMT):
Has joined the channel.

darienhess (Tue, 18 Sep 2018 19:48:47 GMT):
Is it possible to access environment variables within the indy-cli?

n3m (Tue, 18 Sep 2018 21:33:43 GMT):
@baconsandwich not sure what you mean by `But how does indy.open_wallet() know where to open the wallet?`. If you take a look at https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/api/wallet.rs, you can find `indy_open_wallet` function inside along with the doc strings that describe that API call -- how you target a storage, where you store config files, how you provide connection params etc... Does that help? What you see as a C function is just a C callable API that libindy exposes. This allows libindy to be wrapped in a lot of languages, but underneath is plain Rust.

n3m (Tue, 18 Sep 2018 21:33:43 GMT):
@baconsandwich not sure what you mean by `But how does indy.open_wallet() know where to open the wallet?`. If you take a look at https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/api/wallet.rs, you can find `indy_open_wallet` function inside along with the doc strings that describe that API call works-- how you target a storage, where you store config files, how you provide connection params etc... Does that help? What you see as a C function is just a C callable API that libindy exposes. This allows libindy to be wrapped in a lot of languages, but underneath is plain Rust.

animeshdas (Wed, 19 Sep 2018 00:00:19 GMT):
hi guys, I just updated the code from 1.5 to 1.6.6 of the rc branch. Earlier there was a "libIndy/build-libindy-ios.sh" file that was used to generated the Indy.framework. But the build-libindy-ios.sh is no longer there in 1.6.6. So how to build Indy.framework in 1.6.6? Thanks for the help.

animeshdas (Wed, 19 Sep 2018 00:00:19 GMT):
hi guys, I just updated the code from 1.5 to 1.6.6 of the rc branch. Earlier there was a "libIndy/build-libindy-ios.sh" file that was used to compile Indy. But the build-libindy-ios.sh is no longer there in 1.6.6. So how to build Indy? Thanks for the help.

Rantwijk (Wed, 19 Sep 2018 12:29:30 GMT):
Hello. I'm running into an issue that I hope has a simple explanation. When I use API calls (NodeJS) to create a wallet, it doesn't show up when I use indy-cli (>wallet list) but I can't make another wallet with the same name. Is there something I need to do to have it show up? Code: return indy.createWallet({"id":name}, {"key":"password"}); Output of incy-cli: indy> wallet list +-------+---------+ | Name | Type | +-------+---------+ | ben | default | +-------+---------+ | Alice | default | +-------+---------+ indy> wallet create Hank key Enter value for key: Wallet "Hank" already exists

Rantwijk (Wed, 19 Sep 2018 12:47:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jzmzYDZdWqYrBHWGz) @PhillipGibb Same issue as this, were you able to solve it @PhillipGibb ?

MaheshSharma (Wed, 19 Sep 2018 12:54:10 GMT):
Actually, I need Sovrin on my website for KYC kind of process. I want to fetch and verify user's data from their verified resource. Or if possible, I'll use sovrin for Auth process like Login with Facebook.

n3m (Wed, 19 Sep 2018 13:02:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=GirYCzxnHGwDBZRYL) @Rantwijk I think it goes something like this. The CLI `wallet list` command only lists wallets that are specifically created using the CLI, so this excludes any wallets created using the SDK. In the background, both CLI and and the SDK calls use the same backend, so it is possible that you already created a wallet via SDK that will not show up on the `wallet list output` and are trying to create it again. There is no wallet list command that will show you all wallets that are currently created.

n3m (Wed, 19 Sep 2018 13:02:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=GirYCzxnHGwDBZRYL) @Rantwijk I think it goes something like this. The CLI `wallet list` command only lists wallets that are specifically created using the CLI, so this excludes any wallets created using the SDK. In the background, both CLI and and the SDK calls use the same backend, so it is possible that you already created a wallet via SDK that will not show up on the `wallet list` output and are trying to create it again. There is no wallet list command that will show you all wallets that are currently created.

n3m (Wed, 19 Sep 2018 13:02:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=GirYCzxnHGwDBZRYL) @Rantwijk @PhillipGibb I think it goes something like this. The CLI `wallet list` command only lists wallets that are specifically created using the CLI, so this excludes any wallets created using the SDK. In the background, both CLI and and the SDK calls use the same backend, so it is possible that you already created a wallet via SDK that will not show up on the `wallet list` output and are trying to create it again. There is no wallet list command that will show you all wallets that are currently created.

gudkov (Wed, 19 Sep 2018 13:11:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=hrmPyaiMsQD8ub9Wf) @n3m I near ready to send PR with new CLI commands *wallet attach* and *wallet detach* that will allow to attach wallet creation outside of CLI to CLI wallets list

n3m (Wed, 19 Sep 2018 13:16:25 GMT):
@gudkov Sounds good. @PhillipGibb @Rantwijk you should be aware of this PR, may be a solution for your problems.

PhillipGibb (Wed, 19 Sep 2018 14:05:19 GMT):
@gudkov @n3m thanks

gudkov (Wed, 19 Sep 2018 14:11:53 GMT):
@PhillipGibb the PR https://github.com/hyperledger/indy-sdk/pull/1149

Rantwijk (Wed, 19 Sep 2018 14:16:16 GMT):
Thanks for the information @gudkov! That clears up my confusion.

Rantwijk (Wed, 19 Sep 2018 14:19:16 GMT):
@n3m as well

tomislav (Wed, 19 Sep 2018 15:12:50 GMT):
It's under `ci` now @animeshdas

mccown (Wed, 19 Sep 2018 20:29:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=F5a4Bgf83a6h4tieP) @n3m Is there any documentation on how to do this? I found an Indy file called WalletSearch.java and called the WalletSearch.open(...) function. It runs, but isn't returning any records. This is undoubtedly because I don't have the parameters set properly (i.e., wallet, type, queryJson, optionsJson). The wallet param is obvious, but I'm not sure what's expected for the others. I am reading the source, but do you know of any API/design docs that could lend some additional insight?

n3m (Wed, 19 Sep 2018 20:35:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3yaTutREj9sdiqXH7) @mccown Try with https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/api/non_secrets.rs and look at `indy_open_wallet_search`. Maybe you can gain more insight from tests https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/services/wallet/wallet.rs -- they are in Rust but provide those parameters in a raw object form If that does not help I might be able to dig up a example for Java SDK: ```protected static final String SEARCH_OPTIONS_ALL = "{\"retrieveTags\": true, \"retrieveValue\": true, \"retrieveType\": true, " + "\"retrieveTotalCount\": true, \"retrieveRecords\": true}"; wallet = Wallet.openWallet(config, credentials).get(); WalletSearch search = WalletSearch.open(wallet, type, "{}", SEARCH_OPTIONS_ALL).get(); String searchRecordsJson = search.fetchNextRecords(wallet, 0).get(); search.close();```

n3m (Wed, 19 Sep 2018 20:35:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3yaTutREj9sdiqXH7) @mccown Try with https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/api/non_secrets.rs and look at `indy_open_wallet_search`. Maybe you can gain more insight from tests https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/services/wallet/wallet.rs -- they are in Rust but provide those parameters in a raw object form If that does not help I might be able to dig up a example for Java: ```protected static final String SEARCH_OPTIONS_ALL = "{\"retrieveTags\": true, \"retrieveValue\": true, \"retrieveType\": true, " + "\"retrieveTotalCount\": true, \"retrieveRecords\": true}"; wallet = Wallet.openWallet(config, credentials).get(); WalletSearch search = WalletSearch.open(wallet, type, "{}", SEARCH_OPTIONS_ALL).get(); String searchRecordsJson = search.fetchNextRecords(wallet, 0).get(); search.close();```

arunwij (Thu, 20 Sep 2018 04:02:42 GMT):
Is it possible to use Indy-SDK with React Native or use android

arunwij (Thu, 20 Sep 2018 04:04:01 GMT):
Is it possible to use Indy-SDK with React Native or use Android/iOS build with React Native somehow?

tomislav (Thu, 20 Sep 2018 12:42:17 GMT):
@arunwij Evernym recently released their mobile app as a reference edge agent written in react native - No way to resolve conflict between "System.Runtime.Serialization

tomislav (Thu, 20 Sep 2018 12:42:17 GMT):
@arunwij Evernym recently released their mobile app as a reference edge agent written in react native - https://github.com/evernym/sovrin-connector-preview

arunwij (Thu, 20 Sep 2018 13:40:28 GMT):
Thank you @tomislav I will check that.

RuWander (Thu, 20 Sep 2018 18:58:17 GMT):
Hi all, Can someone please help me? I am trying to store a DID for reference later with the `store_their_did` command, it seems as though the function was successful (no errors) but when I list the DIDs with the `list_my_dids_with_meta` method I cannot find the DID. When I run the function again it does throw an error: `indy.error.IndyError: ErrorCode.WalletItemAlreadyExists` This is the function that I am using with the debug logs: ``` w = await wallet.open_wallet(steward_wallet_config, steward_wallet_credentials) did_info = json.dumps({"did":body['connection_response']['did'],"verkey":body['connection_response']['verkey']}) print(did_info) await did.store_their_did(w,did_info) await wallet.close_wallet(w) ``` ``` INFO|indy::commands | src/commands/mod.rs:119 | DidCommand command received INFO|indy::commands::did | src/commands/did.rs:143 | StoreTheirDid command received DEBUG|indy::commands::did | src/commands/did.rs:272 | store_their_did >>> wallet_handle: 13, their_did_info_json: "{\"did\": \"6kyuanTe2mLZ1DFq2oDopg\", \"verkey\": \"492oYcNLppynKBmfBNkXP72U3tty3oqs1hwKo8ert9fB\"}" DEBUG|indy::commands::did | src/commands/did.rs:283 | store_their_did <<< INFO|indy::commands | src/commands/mod.rs:123 | WalletCommand command received DEBUG|wallet_command_executor | src/commands/wallet.rs:97 | Close command received ``` Am I doing something wrong? Is the "their DIDs" stored in a different place?

ianco (Thu, 20 Sep 2018 20:47:56 GMT):
@danielhardman I think you were the one who asked - I have tested exporting a postgres wallet and imported it into a sqlite wallet and everything seemed to work.

n3m (Thu, 20 Sep 2018 20:49:04 GMT):
I think @nage was the one who asked this during the previous Indy WG call

n3m (Thu, 20 Sep 2018 20:49:04 GMT):
I think @nage was the one who asked this during the previous Indy WG call, but I may be mistaken

nage (Thu, 20 Sep 2018 20:51:58 GMT):
@ianco++ (yes @n3m, I asked in the WG call)

ianco (Thu, 20 Sep 2018 22:18:59 GMT):
:+1:

pranav_kirtani (Fri, 21 Sep 2018 04:30:21 GMT):
Has joined the channel.

pranav_kirtani (Fri, 21 Sep 2018 04:32:19 GMT):
Hi All, I am new to hyperledger indy and I was exploring the example given on the https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md page, I was able to create a indy_node pool via docker as specified but I am confused about the part where agent connects to the pool, is this via indy-sdk?

pranav_kirtani (Fri, 21 Sep 2018 04:32:38 GMT):
I am referring to this code

pranav_kirtani (Fri, 21 Sep 2018 04:32:39 GMT):
pool_name = 'pool1' pool_genesis_txn_path = get_pool_genesis_txn_path(pool_name) pool_config = json.dumps({"genesis_txn": str(pool_genesis_txn_path)}) await pool.create_pool_ledger_config(pool_name, pool_config) pool_handle = await pool.open_pool_ledger(pool_name, None)

AxelNennker (Fri, 21 Sep 2018 08:07:01 GMT):
new jira issue https://jira.hyperledger.org/browse/IS-1002

wangdong (Fri, 21 Sep 2018 08:41:30 GMT):
For the ios wrapper, I can not under stand the doc.

wangdong (Fri, 21 Sep 2018 08:41:34 GMT):
source 'https://github.com/hyperledger/indy-sdk.git'

wangdong (Fri, 21 Sep 2018 08:43:01 GMT):
should I do something before this line?

wangdong (Fri, 21 Sep 2018 09:00:29 GMT):
And I can not find the file build-libindy-core-ios.sh

tomislav (Fri, 21 Sep 2018 12:36:14 GMT):
@wangdong You add the line `source 'https://github.com/hyperledger/indy-sdk' to your Podfile. The ios build script is under `ci` folder.

tomislav (Fri, 21 Sep 2018 12:36:14 GMT):
@wangdong You add the line `source 'https://github.com/hyperledger/indy-sdk'` to your Podfile. The ios build script is under `ci` folder.

freeman (Fri, 21 Sep 2018 12:41:43 GMT):
Has joined the channel.

animeshdas (Sat, 22 Sep 2018 06:34:51 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=f8Tf4LXf4ZDzPhLFx) @tomislav @tomislav I checked out rc 1.6.6. When I execute "ios-build.sh", nothing happens. No error, no log statements.. nothing. Any idea what am I missing? P.S I compiled and used 1.5 successfully for past few months.

animeshdas (Sat, 22 Sep 2018 06:34:51 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=f8Tf4LXf4ZDzPhLFx) @tomislav Thank you for your suggestion. I checked out rc 1.6.6. When I execute "ios-build.sh", nothing happens. No error, no log statements.. nothing. Any idea what am I missing? Your help is highly appreciated. P.S I compiled and used 1.5 successfully for past few months.

AxelNennker (Sat, 22 Sep 2018 14:31:27 GMT):
should `cargo bench` work? Does not compile for me. ```error[E0432]: unresolved import `utils::non_secrets::NonSecretsUtils` --> benches/wallet.rs:38:5 | 38 | use utils::non_secrets::NonSecretsUtils; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `NonSecretsUtils` in `utils::non_secrets` error[E0432]: unresolved import `utils::wallet::WalletUtils` --> benches/wallet.rs:37:5 | 37 | use utils::wallet::WalletUtils; | ^^^^^^^^^^^^^^^^^^^^^^^^^^ no `WalletUtils` in `utils::wallet` error[E0432]: unresolved import `utils::test::TestUtils` --> benches/wallet.rs:39:5 | 39 | use utils::test::TestUtils; | ^^^^^^^^^^^^^^^^^^^^^^ no `TestUtils` in `utils::test` error[E0432]: unresolved import `utils::sequence::SequenceUtils` --> benches/wallet.rs:44:5 | 44 | use utils::sequence::SequenceUtils; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ no `SequenceUtils` in `utils::sequence` ```

AxelNennker (Sat, 22 Sep 2018 15:26:16 GMT):
It seems openssl can be removed from libindy. It is still in libcrypto though. https://github.com/hyperledger/indy-sdk/pull/1154

tomislav (Sun, 23 Sep 2018 01:45:03 GMT):
How to specify a uri_pattern in the blob storage API that would affect the tailsLocation info posted on the ledger?

wangdong (Mon, 24 Sep 2018 02:37:48 GMT):
@tomislav I think you mean the file ios-build.sh, is it a different file?

wangdong (Mon, 24 Sep 2018 02:38:44 GMT):
From the name of the two file, I wonder if they got different function?

pranav_kirtani (Mon, 24 Sep 2018 07:08:15 GMT):
Hi

pranav_kirtani (Mon, 24 Sep 2018 07:08:31 GMT):
i am getting the following error when i try to run the sample node.js code

pranav_kirtani (Mon, 24 Sep 2018 07:08:33 GMT):
(node:29110) UnhandledPromiseRejectionWarning: IndyError: CommonInvalidState

pranav_kirtani (Mon, 24 Sep 2018 07:12:37 GMT):
followed thr steps given here https://github.com/hyperledger/indy-sdk/tree/master/samples/nodejs

DirkT (Mon, 24 Sep 2018 14:27:56 GMT):
revocation

xnopre (Mon, 24 Sep 2018 14:44:13 GMT):
Hi all. An issuer can create a credential with `issuerCreateCredential` (NodeJS SDK). Is this credential stored in the wallet ? Is it possible to retrieve this credential ? Is it possible to remove it ? thanks

tomislav (Mon, 24 Sep 2018 14:51:15 GMT):
@xnopre It is not stored in the issuer wallet, only in the holder. If the definition supports revocation, it can be revoked, not deleted. An application can store some information about this credential, outside the AnonCreds API.

xnopre (Mon, 24 Sep 2018 15:01:28 GMT):
Thanks @tomislav . And can the holder remove the credential from its wallet ?

tomislav (Mon, 24 Sep 2018 15:03:54 GMT):
They can't, afaik. There's no delete support in the API - https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/api/anoncreds.rs

xnopre (Mon, 24 Sep 2018 15:14:31 GMT):
Thanks @tomislav

mccown (Mon, 24 Sep 2018 21:21:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=SeT6wCwYCrhB7G2qz) @n3m @n3m: Thanks for the link to the rust files, they have good documentation on the function's parameters' purposes. However, I'm not finding a description of valid values. For example, the function header describes the "type" parameter as: /// type_: allows to separate different record types collections From this and the code, I know that it accepts a string. However, it doesn't specify what string values are accepted, does it accept 'wildcards', etc. If you have a sample call (java or otherwise) that shows how to call this function, I would be grateful.

baconsandwich (Tue, 25 Sep 2018 06:42:32 GMT):
Is there a function call (python wrapper) that can "list all stewards"" in a pool or "list all trustees". I am not sure if this makes sense conceptually. I can only see a GET_NYM request. But how would I list all Stewards in an admin interface?

Rantwijk (Tue, 25 Sep 2018 10:29:51 GMT):
Is there a code base available for a mobile PoC? For instance an app that allows you to connect to a local/live network (eg. Sovrin) and manage your DIDs/Verified Claims? I'm specifically interested in the UI/UX aspect of such an app.

freeman (Tue, 25 Sep 2018 11:40:19 GMT):
@Rantwijk connect.me but you wont have the code available, it is a beta ios app built by evernym

sebastian (Tue, 25 Sep 2018 14:23:46 GMT):
Has joined the channel.

sebastian (Tue, 25 Sep 2018 15:14:19 GMT):
``` # Acme Agent job_application_proof_request_json = json.dumps({ 'nonce': '1432422343242122312411212', 'name': 'Job-Application', 'version': '0.1', 'requested_attributes': { 'attr1_referent': { 'name': 'first_name' }, 'attr2_referent': { 'name': 'last_name' }, 'attr3_referent': { 'name': 'degree', 'restrictions': [{'cred_def_id': faber_transcript_cred_def_id}] <--- ? }, 'attr4_referent': { 'name': 'status', 'restrictions': [{'cred_def_id': faber_transcript_cred_def_id}] <----- ? }, 'attr5_referent': { 'name': 'ssn', 'restrictions': [{'cred_def_id': faber_transcript_cred_def_id}] <------? }, 'attr6_referent': { 'name': 'phone_number' } }, 'requested_predicates': {} } }) ``` Hi, anyone who could help me with a procedural problem. In a real world application where is the client (here: ACME) supposed to get the cred_def_id's to form a viable proof request (seen above)? Is Alice supposed to transmit every credential definition id she owns or is there another solution, to fill the restrictions?

TelegramSam (Tue, 25 Sep 2018 15:50:49 GMT):
Building Indy using this guide: https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md Indy is failing on the compile when I run `RUST_TEST_THREADS=1 cargo test`. Any ideas?

ianco (Tue, 25 Sep 2018 16:31:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WsdkuGQ7nSCqfE9DT) @TelegramSam Make sure you have the most recent version of Rust

mccown (Tue, 25 Sep 2018 17:06:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=TnPPGoaEKBxPfEkxk) @ianco For me, apt-get installed an older version of Rust, so I had to download the current version from the Rust website (https://www.rust-lang.org/en-US/install.html).

mccown (Tue, 25 Sep 2018 17:06:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=TnPPGoaEKBxPfEkxk) @TelegramSam For me, apt-get installed an older version of Rust, so I had to download the current version from the Rust website (https://www.rust-lang.org/en-US/install.html).

ianco (Tue, 25 Sep 2018 17:08:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=BhaNbG5yzoFhcfFrG) @mccown ... or just use "rustup"

TelegramSam (Tue, 25 Sep 2018 17:32:48 GMT):
I did use the website install version for rust. now chasing a different error. Back in a bit if I need help there.

TelegramSam (Tue, 25 Sep 2018 18:26:59 GMT):
had to re-run the rust install, now tests passing. Thanks for the help.

ShivVenkatraman (Wed, 26 Sep 2018 01:07:42 GMT):
I have a question on revocation. Suppose my credential schema has attributes name, age, height. Can the revocation be done on specific attributes like name etc. or is it done for all the attributes defined in the credential schema? The example in IssuerRevokeCredentialTest.java seems to suggest the latter. Can someone please confirm if attribute level revocation can be done?

swcurran (Wed, 26 Sep 2018 02:00:43 GMT):
Answered on the indy channel.

wangdong (Wed, 26 Sep 2018 06:44:30 GMT):
>After building libindy, add the path containing the library the LD_LIBRARY_PATH and DYLD_LIBRARY_PATH environment variables

wangdong (Wed, 26 Sep 2018 06:44:30 GMT):
what are these two env?>After building libindy, add the path containing the library the LD_LIBRARY_PATH and DYLD_LIBRARY_PATH environment variables

wangdong (Wed, 26 Sep 2018 06:44:30 GMT):
what are these two env?/n>After building libindy, add the path containing the library the LD_LIBRARY_PATH and DYLD_LIBRARY_PATH environment variables

wangdong (Wed, 26 Sep 2018 06:45:45 GMT):
>After building libindy, add the path containing the library the LD_LIBRARY_PATH and DYLD_LIBRARY_PATH environment variables

wangdong (Wed, 26 Sep 2018 06:46:32 GMT):
what are these two env var? what does they point to?

wangdong (Wed, 26 Sep 2018 06:47:14 GMT):
the DYLD_LIBRARY_PATH points to libindy.dylib

wangdong (Wed, 26 Sep 2018 06:47:39 GMT):
then what about LD_LIBRARY_PATH?

wangdong (Wed, 26 Sep 2018 06:51:44 GMT):
because after my build and install, when I try to issue the sdk cli, I got an error.

wangdong (Wed, 26 Sep 2018 06:51:46 GMT):
dyld: Library not loaded: /Users/dong/repos/indy-sdk/libindy/target/debug/deps/libindy.dylib Referenced from: /Users/dong/repos/indy-ios/indy-sdk/cli/target/debug/./indy-cli Reason: image not found

wangdong (Wed, 26 Sep 2018 06:51:46 GMT):
**dyld: Library not loaded: /Users/dong/repos/indy-sdk/libindy/target/debug/deps/libindy.dylib Referenced from: /Users/dong/repos/indy-ios/indy-sdk/cli/target/debug/./indy-cli Reason: image not found **

wangdong (Wed, 26 Sep 2018 06:51:46 GMT):
dyld: Library not loaded: /Users/repos/indy-sdk/libindy/target/debug/deps/libindy.dylib Referenced from: /Users/repos/indy-ios/indy-sdk/cli/target/debug/./indy-cli Reason: image not found

wangdong (Wed, 26 Sep 2018 06:56:32 GMT):
dyld: Library not loaded: /Users/dong/repos/indy-sdk/libindy/target/debug/deps/libindy.dylib Referenced from: /Users/dong/repos/indy-ios/indy-sdk/cli/target/debug/./indy-cli Reason: image not found

wangdong (Wed, 26 Sep 2018 07:01:36 GMT):
I missed some thing here?

wangdong (Wed, 26 Sep 2018 07:07:45 GMT):
I have to set the DYLD PATH in all the terminal

wangdong (Wed, 26 Sep 2018 07:07:53 GMT):
It is addressed.

pranav_kirtani (Wed, 26 Sep 2018 10:27:23 GMT):
Hi, does indy support zero knowledge proofs when it comes to verifiable claims?

tomislav (Wed, 26 Sep 2018 12:08:40 GMT):
@pranav_kirtani https://github.com/hyperledger/indy-anoncreds/tree/master/docs

tomislav (Wed, 26 Sep 2018 12:09:36 GMT):
@wangdong If you're on a Mac, all you have to do is copy libindy.dylib to /usr/local/lib

wangdong (Wed, 26 Sep 2018 12:10:05 GMT):
yes, I set the env var and it works.

wangdong (Wed, 26 Sep 2018 12:10:06 GMT):
thanks

VitalijReicherdt (Wed, 26 Sep 2018 13:29:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Q68hNjvH44hZzxmE5) @sebastian have the same problem

pranav_kirtani (Wed, 26 Sep 2018 13:46:04 GMT):
thanks @tomislav , can you also guide me on a good document for explaining the master secret concept?

Rantwijk (Wed, 26 Sep 2018 15:44:06 GMT):
I've searched around but am unable to find out how to connect to the Sovrin provisional network. Is there info on this somewhere? The local docker container based network works fine.

Rantwijk (Wed, 26 Sep 2018 15:46:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JKhA4KNDhG7SnoYkq) @freeman Thanks for the reply, I was aware of the beta program and enrolled a while back. Will it be closed source upon release?

Rantwijk (Wed, 26 Sep 2018 17:27:43 GMT):
I'm running into an issue trying to run the android version of https://github.com/evernym/sovrin-connector-preview. Could not resolve all files for configuration ':app:debugCompileClasspath'. > Could not find com.sovrin:vcx:1.0.0-23-08-2018T16-48-02. Could someone advise me on how to solve this?

mboyd (Wed, 26 Sep 2018 20:23:43 GMT):
@Rantwijk what device are you building for? This code base isn't meant to be built yet, but really just to be studied. In the next couple of weeks/months we should have a better repository to work from. That said, we may be able to make some progress

dbluhm (Wed, 26 Sep 2018 23:03:28 GMT):
@n3m I had a chat with @mccown today and he brought up a good question. Is it possible to show the contents of the wallet? We have the non-secrets wallet search but, as I understand it, that does not include "secrets," or DIDs, Keys, Credentials and such. Is that correct?

dbluhm (Wed, 26 Sep 2018 23:05:29 GMT):
Ah, just discovered `list_my_dids_with_meta` which at least partially answers that question

ShivVenkatraman (Thu, 27 Sep 2018 00:00:22 GMT):
Has anyone got signAndSubmitRequest in samples/Ledger.java (Java SDK) to work? The rest of the demo works; but this one gives timeout error. Caused by: org.hyperledger.indy.sdk.ledger.TimeoutException: Timeout happens for ledger operation. at org.hyperledger.indy.sdk.IndyException.fromSdkError(IndyException.java:120) at org.hyperledger.indy.sdk.IndyJava$API.checkResult(IndyJava.java:90) at org.hyperledger.indy.sdk.ledger.Ledger.access$100(Ledger.java:24) at org.hyperledger.indy.sdk.ledger.Ledger$1.callback(Ledger.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:520) at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:551)

ShivVenkatraman (Thu, 27 Sep 2018 00:00:22 GMT):
Has anyone got signAndSubmitRequest in samples/Ledger.java (Java SDK) to work? The rest of the sample components (in Java SDK) work; but this one gives timeout error. Caused by: org.hyperledger.indy.sdk.ledger.TimeoutException: Timeout happens for ledger operation. at org.hyperledger.indy.sdk.IndyException.fromSdkError(IndyException.java:120) at org.hyperledger.indy.sdk.IndyJava$API.checkResult(IndyJava.java:90) at org.hyperledger.indy.sdk.ledger.Ledger.access$100(Ledger.java:24) at org.hyperledger.indy.sdk.ledger.Ledger$1.callback(Ledger.java:43) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:520) at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:551)

ShivVenkatraman (Thu, 27 Sep 2018 01:46:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ok9L5zYYtCDrA3cve) Interestingly, making 2 separate calls -- Ledger.signRequest followed by Ledger.submitRequest (where I pass the signed message in the request body) does not throw timeout errors

n3m (Thu, 27 Sep 2018 09:33:24 GMT):
@dbluhm like you said there is a non-secrets, and this was created for the purpose of listing the contents of the wallet but excluding "secrets" -- secrets being private keys. If you have stored credentials and you use search with the credentials type it should show up in the search result. `indy_list_my_dids_with_meta` is just a search: ``` fn list_my_dids_with_meta(&self, wallet_handle: i32) -> Result { debug!("list_my_dids_with_meta >>> wallet_handle: {:?}", wallet_handle); let mut did_search = self.wallet_service.search_indy_records::(wallet_handle, "{}", &SearchOptions::id_value())?; let mut dids: Vec = Vec::new();```

n3m (Thu, 27 Sep 2018 09:33:24 GMT):
@dbluhm like you said there is a non-secrets search, and this was created for the purpose of listing the contents of the wallet but excluding "secrets" -- secrets being private keys. If you have stored credentials and you use search with the credentials type it should show up in the search result. `indy_list_my_dids_with_meta` is just a search: ``` fn list_my_dids_with_meta(&self, wallet_handle: i32) -> Result { debug!("list_my_dids_with_meta >>> wallet_handle: {:?}", wallet_handle); let mut did_search = self.wallet_service.search_indy_records::(wallet_handle, "{}", &SearchOptions::id_value())?; let mut dids: Vec = Vec::new();```

n3m (Thu, 27 Sep 2018 09:33:24 GMT):
@dbluhm like you said there is a non-secrets search, and this was created for the purpose of listing the contents of the wallet but excluding "secrets" -- secrets being private keys. If you have stored credentials and you use search with the credentials type all of your credentials should show up in the search result. `indy_list_my_dids_with_meta` is just a search: ``` fn list_my_dids_with_meta(&self, wallet_handle: i32) -> Result { debug!("list_my_dids_with_meta >>> wallet_handle: {:?}", wallet_handle); let mut did_search = self.wallet_service.search_indy_records::(wallet_handle, "{}", &SearchOptions::id_value())?; let mut dids: Vec = Vec::new();``` So, it is possible to write a specific search function for your needs, but indy-sdk is conservative in what convenience methods it provides.

n3m (Thu, 27 Sep 2018 09:33:24 GMT):
@dbluhm like you said there is a non-secrets search, and this was created for the purpose of listing the contents of the wallet but excluding "secrets" -- secrets being private keys. If you have stored credentials and you use search with the credentials type all of your credentials should show up in the search result. `indy_list_my_dids_with_meta` is just a search: ``` fn list_my_dids_with_meta(&self, wallet_handle: i32) -> Result { debug!("list_my_dids_with_meta >>> wallet_handle: {:?}", wallet_handle); let mut did_search = self.wallet_service.search_indy_records::(wallet_handle, "{}", &SearchOptions::id_value())?; let mut dids: Vec = Vec::new();``` So, it is possible to write a specific search function for your needs, but indy-sdk is conservative in what convenience methods it provides. But there is no API exposed to get a full listing of all records.

n3m (Thu, 27 Sep 2018 09:39:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=KeoeWg3Bp5FgHHMSY) @mccown I somehow missed this one

n3m (Thu, 27 Sep 2018 09:43:06 GMT):
`type_` is a string, but what specific values indy uses for dids, creds and etc I would not know. This is probably something you would need to ask other folks on this chat, or go though the code.

baconsandwich (Thu, 27 Sep 2018 09:50:21 GMT):
What does "cid" stand for? I find it in several methods that create or access DIDs. From what I can gather it is an alias I can set for a DID but does it stand for?

n3m (Thu, 27 Sep 2018 09:52:17 GMT):
Well if it is in the contect of credentials, I would supose it means Credential ID

n3m (Thu, 27 Sep 2018 09:52:17 GMT):
Well if it is in the context of credentials, I would suppose it means Credential ID

baconsandwich (Thu, 27 Sep 2018 09:53:51 GMT):
Correction, it is actually a boolean value and seems to affect whether the full verkey is used for a new DID or only the first 16 bit.

baconsandwich (Thu, 27 Sep 2018 09:54:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=7zSHA3bqAqAtxBvmb) @n3m Afaics no credentials are involved, so I don't see why it would stand for "Credential ID"

n3m (Thu, 27 Sep 2018 09:54:59 GMT):
@baconsandwich It was a shot in the dark :)

sklump (Thu, 27 Sep 2018 10:56:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Q68hNjvH44hZzxmE5) @sebastian Suppose that the client knows the schema-issuer (origin) DID, schema name and schema version, plus the credential issuer DID. The client can get the schema from the ledger [ `ledger.build_get_schema_request()`, `ledger.submit_request()`, `ledger.parse_get_schema_response()`] and retrieve its sequence number. From there, the client can assemble the cred def id ``` :3:CL::tag ``` (assuming the issuer uses the default tag), and confirm its existence on the ledger [ `ledger.build_get_cred_def_request()`, `ledger.submit_request()`, `ledger.parse_get_cred_def_response()`] and retrieve its cred def id, ensuring that it is as constructed. Cred def ids are immutable and so they can be set as configuration data. Alternatively, some of the emerging libvcx functionality appears to be help on the way. In the meantime, if using von_anchor, `Issuer.get_box_ids()` returns all schema ids, cred def ids, and revocation registry ids on which the issuer has issued, or is prepared to issue, credentials.

sklump (Thu, 27 Sep 2018 10:56:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Q68hNjvH44hZzxmE5) @sebastian Suppose that the client knows the schema-issuer (origin) DID, schema name and schema version, plus the credential issuer DID. The client can get the schema from the ledger [`ledger.build_get_schema_request()`, `ledger.submit_request()`, `ledger.parse_get_schema_response()`] and retrieve its sequence number. From there, the client can assemble the cred def id ``` :3:CL::tag ``` (assuming the issuer uses the default tag), and confirm its existence on the ledger [`ledger.build_get_cred_def_request()`, `ledger.submit_request()`, `ledger.parse_get_cred_def_response()`] and retrieve its cred def id. At some point last year I vaguely remember there being some chatter about being able to search the ledger for schema/cred defs by origin/issuer/name/version, but I think other priorities intervened. The way I have it right now looks laborious and baroque at first glance, but it's what we have for the moment and, on the other hand, cred def ids are immutable and so they can be set as configuration data.

sklump (Thu, 27 Sep 2018 10:56:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Q68hNjvH44hZzxmE5) @sebastian Suppose that the client knows the schema-issuer (origin) DID, schema name and schema version, plus the credential issuer DID. The client can get the schema from the ledger [ `ledger.build_get_schema_request()`, `ledger.submit_request()`, `ledger.parse_get_schema_response()`] and retrieve its sequence number. From there, the client can assemble the cred def id ``` :3:CL::tag ``` (assuming the issuer uses the default tag), and confirm its existence on the ledger [ `ledger.build_get_cred_def_request()`, `ledger.submit_request()`, `ledger.parse_get_cred_def_response()`] and retrieve its cred def id. At some point last year I vaguely remember there being some chatter about being able to search the ledger for schema/cred defs by origin/issuer/name/version, but I think other priorities intervened. The way I have it right now looks laborious and baroque at first glance, but it's what we have for the moment and, on the other hand, cred def ids are immutable and so they can be set as configuration data.

sklump (Thu, 27 Sep 2018 10:56:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Q68hNjvH44hZzxmE5) @sebastian Suppose that the client knows the schema-issuer (origin) DID, schema name and schema version, plus the credential issuer DID. The client can get the schema from the ledger [ `ledger.build_get_schema_request()`, `ledger.submit_request()`, `ledger.parse_get_schema_response()`] and retrieve its sequence number. From there, the client can assemble the cred def id ``` :3:CL::tag ``` (assuming the issuer uses the default tag), and confirm its existence on the ledger [ `ledger.build_get_cred_def_request()`, `ledger.submit_request()`, `ledger.parse_get_cred_def_response()`] and retrieve its cred def id, ensuring that it is as constructed. At some point last year I vaguely remember there being some chatter about being able to search the ledger for schemata/cred defs by origin/issuer/name/version, but I think other priorities intervened. The way I have it right now looks laborious and baroque at first glance, but it's what we have for the moment and, on the other hand, cred def ids are immutable and so they can be set as configuration data.

n3m (Thu, 27 Sep 2018 10:57:40 GMT):
@baconsandwich I asked people who know what this is and C in CID stands for Cryptonym, Indy-Node use them as Node identifiers, and it just means that `did` will be the same as `verkey` when we pass cid=true

baconsandwich (Thu, 27 Sep 2018 11:09:13 GMT):
@n3m Well that kind of helps.

MaheshSharma (Thu, 27 Sep 2018 11:11:15 GMT):
How to send Trust Anchor proof request to issuer throw Indy-cli? Like: according indy-agent node js demo,Alice agent send proof request to bob's agent and faber university. if possible send Trust Anchor proof request to issuer (faber university,Acme Corporation)throw Indy-cli?

baconsandwich (Thu, 27 Sep 2018 11:14:34 GMT):
Are there restrictions on the seed during DID creation? Does it always have a size of 32 byte? Or is this a max or min length?

sklump (Thu, 27 Sep 2018 13:56:43 GMT):
@baconsandwich 32 bytes is the size. It is a max and a min length.

esplinr (Thu, 27 Sep 2018 14:00:05 GMT):
This sprint we prepared a guide for those interested in using LibVCX: https://github.com/hyperledger/indy-sdk/blob/master/vcx/docs/getting-started/getting-started.md

ShivVenkatraman (Thu, 27 Sep 2018 23:17:42 GMT):
Is there a way (Java sdk) to query the wallet or ledger for issuer's and prover's DIDs?

ShivVenkatraman (Thu, 27 Sep 2018 23:17:42 GMT):
Is there a way (Java sdk) to query the wallet or ledger for issuer's and prover's DIDs? I would like to have a CRUD type operation. List all DIDs, delete them etc

mccown (Thu, 27 Sep 2018 23:30:26 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=bguFM8r4xfA5vLhq7) @n3m @n3m & @dbluhm Thank you both for the pointers. I read through a lot of code and am still not sure what 'type' value is used when the system stores dids. That makes it hard to use the WalletSearch.open() function, which requires the type value. If you (or anyone) comes across some additional detail, I'm interested. I am using another method to list what's in a Wallet. The Did.getListMyDidsWithMeta(...) method returns a list of dids and then I can iterate through them. It doesn't give as fine-grained searching as WalletSearch, but it also doesn't require the 'type' as a parameter.

mccown (Thu, 27 Sep 2018 23:30:26 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=bguFM8r4xfA5vLhq7) @n3m & @dbluhm Thank you both for the pointers. I read through a lot of code and am still not sure what 'type' value is used when the system stores dids. That makes it hard to use the WalletSearch.open() function, which requires the type value. If you (or anyone) comes across some additional detail, I'm interested. I am using another method to list what's in a Wallet. The Did.getListMyDidsWithMeta(...) method returns a list of dids and then I can iterate through them. It doesn't give as fine-grained searching as WalletSearch, but it also doesn't require the 'type' as a parameter.

dbluhm (Thu, 27 Sep 2018 23:46:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ppGYZxCmZ3DEEX8rk) @mccown After spending some time examining the code, I believe the type string used for did's created using the sdk is `MyDidInfo`. However, as noted above, the wallet search api does not search through DIDs and keys. The method to use for that is the one you mentioned, `Did.getListMyDidsWithMeta()`. To search the wallet for credentials (I haven't personally tested this yet), it appears that a wallet search with the type string "Credential" should work.

baconsandwich (Fri, 28 Sep 2018 05:29:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=soqgjWxpKkfPKKWHT) @sklump JSON allows all unicode characters except `"`and `\`. Is this what can be used as a seed as well? Or just ASCII? Because of the former I can't just use 32 random bytes.

baconsandwich (Fri, 28 Sep 2018 05:31:33 GMT):
If you could point me to the rust code, that might be helpful. I wasn't able to find it myself with all the "async" calls and middlewares. :)

karthick15v (Fri, 28 Sep 2018 06:21:52 GMT):
Has joined the channel.

dbluhm (Fri, 28 Sep 2018 12:34:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ppGYZxCmZ3DEEX8rk) @mccown Worked with @n3m and verified that the non_secrets wallet search function is indeed restricted and cannot access Dids. I'll have to test this but i think credentials may be restricted as well.

n3m (Fri, 28 Sep 2018 12:41:16 GMT):
@dbluhm talked to the experts and they said: With the non secrets API you can only search things that are stored with the non secrets API. Non Secrets does not have access to entities stored by any other API function, so credentials are not searchable by his interface. There is a `indy_prover_search_credentials` function in Anoncreds API to search credentials.

sklump (Fri, 28 Sep 2018 13:20:57 GMT):
@baconsandwich As far as the rust is concerned, it's complicated: I've thrown a couple of hours into tracing what the boundaries are and am about to let it go with a stipulation that there are surprises. For example, there is a heuristic that assumes that any seed ending in `=` is a base64-encoding, so best avoid that character too (`indy-sdk/libindy/src/services/crypto/mod.rs::pub fn convert_seed()`). It doesn't like whitespace either. A safe bet is to stick with ``` from random import choice from string import ascii_letters, digits # ... SEED_PUNCT = "!#$%&'()*+,-./:;<>?@[]^_`{|}~" # ... seed = ''.join(choice(ascii_letters + digits + SEED_PUNCT) ``` . Although there may be a few other bytes that are OK if you want to push the envelope, this ought to provide plenty of entropy.

sklump (Fri, 28 Sep 2018 13:20:57 GMT):
@baconsandwich As far as the rust is concerned, it's complicated: I've thrown a couple of hours into tracing what the boundaries are and am about to let it go with a stipulation that there are surprises. For example, there is a heuristic that assumes that any seed ending in `=` is a base64-encoding, so best avoid that character too ( `indy-sdk/libindy/src/services/crypto/mod.rs::pub fn convert_seed()` ). It doesn't like whitespace either. A safe bet is to stick with ``` from random import choice from string import ascii_letters, digits # ... SEED_PUNCT = "!#$%&'()*+,-./:;<>?@[]^_`{|}~" # ... seed = ''.join(choice(ascii_letters + digits + SEED_PUNCT) ``` . Although there may be a few other bytes that are OK if you want to push the envelope, this ought to provide plenty of entropy.

sklump (Fri, 28 Sep 2018 13:20:57 GMT):
@baconsandwich As far as the rust is concerned, it's complicated: I've thrown a couple of hours into tracing what the boundaries are and am about to let it go with a stipulation that there are surprises. For example, there is a heuristic that assumes that any seed ending in `=` is a base64-encoding, so best avoid that character too ( `indy-sdk/libindy/src/services/crypto/mod.rs::pub fn convert_seed()` ). It doesn't like whitespace either. A safe bet is to stick with ``` from random import choice from string import ascii_letters, digits # ... SEED_PUNCT = "!#$%&'()*+,-./:;<>?@[]^_`{|}~" # ... seed = ''.join(choice(ascii_letters + digits + SEED_PUNCT) for _ in range(32)) ``` . Although there may be a few other bytes that are OK if you want to push the envelope, this ought to provide plenty of entropy.

sklump (Fri, 28 Sep 2018 13:20:57 GMT):
@baconsandwich As far as the rust is concerned, it's complicated: I've thrown a couple of hours into tracing what the boundaries are and am about to let it go with a stipulation that there are surprises. For example, there is a heuristic that assumes that any seed ending in `=` is a base64-encoding, so best avoid that character too ( `indy-sdk/libindy/src/services/crypto/mod.rs::pub fn convert_seed()` ). It doesn't like whitespace either. A safe bet is to stick with ``` from secrets import choice # was random originally from string import ascii_letters, digits # ... SEED_PUNCT = "!#$%&'()*+,-./:;<>?@[]^_`{|}~" # ... seed = ''.join(choice(ascii_letters + digits + SEED_PUNCT) for _ in range(32)) ``` . Although there may be a few other bytes that are OK if you want to push the envelope, this ought to provide plenty of entropy.

baconsandwich (Fri, 28 Sep 2018 13:58:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=YFCR3TaCak5ZGgZWS) @sklump thanks a lot!

baconsandwich (Fri, 28 Sep 2018 13:58:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=YFCR3TaCak5ZGgZWS) @sklump thanks a lot! I would use secrets.choice() instead of the normal one for better randomness.

baconsandwich (Fri, 28 Sep 2018 13:58:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=YFCR3TaCak5ZGgZWS) @sklump thanks a lot for the work! Regarding the code: I would use secrets.choice() instead of the normal one for better randomness.

dbluhm (Fri, 28 Sep 2018 14:06:28 GMT):
For anyone looking for the Agent call this morning, we had to switch zoom rooms. Here is the link to the new room: https://zoom.us/j/691024912

baconsandwich (Sun, 30 Sep 2018 10:47:47 GMT):
Question regarding python function `indy.did.list_my__dids_with_meta()`: I always get an empty `metadata` value for all DIDs, although `did.get_key_metadata()` correctly returns metadata that I previously stored for a DID. Is this a bug or is this not the same metadata?

baconsandwich (Sun, 30 Sep 2018 12:50:27 GMT):
In `build_get_nym_request(submitter_did: str, target_did: str)`, why is there a `submitter_did`? Is there some kind of authorization going on? I mean, if I just want to retrieve a DID, why does it matter who is asking?

ShivVenkatraman (Sun, 30 Sep 2018 19:02:43 GMT):
I am using the Java SDK and looking at the samples/wrapper unit tests for reference. I have a basic question on the difference between AnoncredsIntegrationTest.java and LedgerIntegrationTest.java. Does the end-to-end flow (issuer issues claims and prover proves claims) use the ledger/blockchain or just the local waller in ~/.indy_client? Are the claims/schema stored in ledger AnoncredsIntegrationTest.java? Does LedgerIntegrationTes.java store the schema and claims on the ledger instead of local wallet? Also, where the pair wise did creation (between govt and issuer) come into play in these test cases?

ShivVenkatraman (Sun, 30 Sep 2018 23:59:12 GMT):
How does one query and fetch the different schemas created and stored by the issuer? Typically a prover (or user) would come to the issuer and request for his claim to be created. For this to occur, the issuer must fetch the appropriate schema depending on type of claim. Where is this fetched from (which Java API)?

ShivVenkatraman (Mon, 01 Oct 2018 05:10:13 GMT):
Is there an API (Java) to get credentialDefJson from a credentialDefId? The result of Anoncreds.issuerCreateAndStoreCredentialDef is credentialDefJson. When an offer is made by issuer to prover; both credentialDefId and credentialDefJson are needed. It will be good if these can be retrieved from the issuer wallet (or ledger)? I don't see an API for this

ShivVenkatraman (Mon, 01 Oct 2018 05:10:13 GMT):
Is there an API (Java) to get credentialDefJson from a credentialDefId? The result of Anoncreds.issuerCreateAndStoreCredentialDef is credentialDefJson. When the prover makes credential request (proverCreateCredentialReq); both credentialDefId and credentialDefJson are needed. It will be good if these can be retrieved from the issuer wallet (or ledger)? I don't see an API for this

ShivVenkatraman (Mon, 01 Oct 2018 05:10:13 GMT):
Is there an API (Java) to get credentialDefJson from a credentialDefId? The result of Anoncreds.issuerCreateAndStoreCredentialDef is credentialDefJson. When the prover makes credential request (proverCreateCredentialReq); credentialDefJson is needed. It will be good if this can be retrieved from the issuer wallet (or ledger) using a credentialDefIf or ever better using a issuer DID. Given a issuer DID, a useful API would be to list the all credentialDefJsons; which is needed for the prover

tomislav (Mon, 01 Oct 2018 12:56:00 GMT):
@ShivVenkatraman You can retrieve the definition from the ledger using `ledger.buildGetCredDefRequest + submitRequest + parseGetCredDefRespone`. This assumes that the issuer has sent the definition to the ledger using 'buildCredDefRequest`

tomislav (Mon, 01 Oct 2018 12:56:51 GMT):
Same applies to retrieving schemas, per your previous question

AxelNennker (Mon, 01 Oct 2018 16:39:40 GMT):
https://jira.hyperledger.org/browse/IS-1019 I suggest to remove all z from version x.y.z in dependencies. I think we can trust crate developers to not break the api contract when changing the version. So e.g. `openssl = { version = "=0.10.12", optional = true }` should be replaced by `openssl = { version = "=0.10", optional = true }` So we can benefit from bug fixes and other improvements.

phaniac (Mon, 01 Oct 2018 18:07:32 GMT):
Has joined the channel.

smithbk (Mon, 01 Oct 2018 18:38:55 GMT):
In the standard issuance flow of Alice getting a transcript (https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md#alice-gets-a-transcrip), how would Alice check the values of the attributes which Faber is offering before accepting it? For example, suppose Faber issued a credential with the wrong average. Alice would want to review the attributes and reject the credential if she doesn't agree with them. It would seem reasonable to include the attribute values in the credential offer so that Alice could review them before accepting the offer, but the offer doesn't contain the attribute values. Any thoughts on how to allow the user to review the attribute values (and attribute predicate values) before accepting the credential offer?

ShivVenkatraman (Mon, 01 Oct 2018 19:23:55 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=YSqtyaXEJYmh6NFnH) @tomislav Thanks, that worked, once I passed the correct credDefId in buildGetCredDefRequest. Is there a way to get all credDefIds for a given issuer DID

arunwij (Tue, 02 Oct 2018 01:48:18 GMT):
Hi, Does Indy-SDK 1.6.2 Node JS wrapper compatible with Libindy 1.6.5? or do i need to use Libindy 1.6.2 for make it work? Thank you.

Taaanos (Tue, 02 Oct 2018 06:37:31 GMT):
Hey everyone, is anything implemented for IoT? If yes could somebody point me to the right location? As far as I am concerned, Sovrin has a Thing as an Entity and a Thing Controller as well.

sklump (Tue, 02 Oct 2018 10:31:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Dj4EQmFgXELwSHdbs) @smithbk If Alice doesn't want to store the credential Faber created, she doesn't need to. She can remonstrate out of band and arrange for another offer. The issuer (Faber) does not hold credentials, the holder/prover (Alice) does.

smithbk (Tue, 02 Oct 2018 11:36:20 GMT):
@sklump Thanks, but let me clarify my question. What is recommended from a UX (user experience) perspective? That is, when is Alice's approval required? It seems the options are: 1) Ask for Alice's approval once just before storing the credential, but do not prompt Alice for approval to accept the credential offer. This way Alice can review the attribute values for correctness and Alice is prompted only once per issuance flow. Is there a DoS attack possible if a rogue issuer floods Alice with bad credential offers? 2) Ask for Alice's approval twice: once to accept the credential offer from Faber and once before storing the credential. This doesn't seem desirable from a UX perspective. 3) The issuer includes a commitment to the attribute values together with (or inside) the credential offer. Alice is prompted once for approval of the credential offer from Faber including the attribute values. I'm curious which of these options is recommended?

sklump (Tue, 02 Oct 2018 11:45:01 GMT):
@smithbk indy-sdk does not make recommendations on UX. Do what you think is best.

sklump (Tue, 02 Oct 2018 11:45:01 GMT):
@smithbk indy-sdk does not make recommendations on UX. Do what you think is best. It might be best not to put too much weight on the one sample use case. It might be for elevators negotiating which one picks up on 17 going to 30.

sklump (Tue, 02 Oct 2018 11:45:01 GMT):
@smithbk indy-sdk does not make recommendations on UX. Do what you think is best. It might be best not to put too much weight on the one sample use case. The software might be for elevators negotiating which one picks up on 17 going to 30.

smithbk (Tue, 02 Oct 2018 11:50:15 GMT):
@sklump ok, thanks

smithbk (Tue, 02 Oct 2018 13:21:25 GMT):
I'm getting the following exception on a call to ledger.parse_get_cred_def_response and am not seeing what I am doing wrong. Could someone help? Thanks ``` TRACE|indy::services::ledger | src/services/ledger/mod.rs:570 | parse_response >>> response "{\"result\":{\"signature_type\":\"CL\",\"ref\":12,\"identifier\":\"9ddbHBLkebY8kKif25D6x5\",\"txnTime\":null,\"data\":null,\"reqId\":1538484051121755000,\"origin\":\"G2wgqagp2broAaiqYUdaXp\",\"seqNo\":null,\"tag\":\"TAG1\",\"state_proof\":{\"proof_nodes\":\"+QLz+QGctjcyd2dxYWdwMmJyb0FhaXFZVWRhWHA6Mjppc28xODAxMy0xX2RyaXZlcl9saWNlbnNlOjEuMLkBYvkBX7kBXHsibHNuIjoxMiwibHV0IjoxNTM4NDg0MDMxLCJ2YWwiOnsiYXR0cl9uYW1lcyI6WyJ3ZWlnaHQiLCJleWVfY29sb3IiLCJsYXN0X25hbWUiLCJkb2IiLCJleHBpcmF0aW9uX2RhdGUiLCJzdGF0ZSIsImRhdGVfb2ZfaXNzdWUiLCJjaXR5IiwiY3VzdG9tZXJfaWRlbnRpZmllciIsImhhaXJfY29sb3IiLCJyY2lfY29kZXMiLCJ2ZWhpY2xlX2NsYXNzIiwiYWRkcmVzc19saW5lXzEiLCJ6aXBfY29kZSIsImNhcmRob2xkZXJfc2V4Iiwic2lnbmF0dXJlIiwiZW5kb3JzZW1lbnRzIiwiYWRkcmVzc19saW5lXzIiLCJkb2N1bWVudF9kaXNjcmltaW5hdG9yIiwicG9ydHJhaXQiLCJoZWlnaHQiLCJmaXJzdF9uYW1lIl19ffkBUaDT0j9uCbFabO0LnyutnB5uDC61QaWLtVTJU4XCa4sWo6Cu8P6tOdS2oq7b\\/Qg1dpnT0ruCEcxzNrMjBarI2OJA5YCgmpq6PvRB\\/76zSDjdvXO+dATJAmHaV82rEVG2ZoAO+TCgd2gRfgV4h0oWhHLkcb1kT1rKVWCECWsaitgIAqwSegigWvjgihcWw21zakNweIVSZtot3vIT35KzOROUDs9u0gmgRACCCbNLp\\/Y1alRAAWwlk5HNK8m01axYGilOiw+nIhmAgICAoCRyJt6FDmJQ60JcPeVA5EXTnNrRiLBPYNq9dgI6SYlCgKB9JVxOO1bVJRb8Jwgua4GPO\\/Juk6XhGUySCneElMV7aqAb0qE5bnVw9F5IUz5uGMXwnAHQmog75MzPMOjuL+f3taA7Ohl8US\\/Ipw9m90WNb\\/7n5LAxzanxSmitjBCIzSGcGoA=\",\"root_hash\":\"6Gyt9iSeUuuq6xWc5tZUFHbYBH3FNxAVfUptVtKfhS2n\",\"multi_signature\":{\"signature\":\"R1Ce1Mfa7a9jcyc93MhPtsHHVWDP4KGQfrjyTmpQiH9VipSEAZ1vaPsmjq3puTiMQy5sa36Gz6HWh1LSHaV6cgbsSj9NsFvkTCwG83BRJNacx6HdcWLV2SWoo5V1YjF6Lf94Gr2zU1rAqf7EkkuCC9Nw7vJa9obvMNcoA2YRX4JyzX\",\"value\":{\"state_root_hash\":\"6Gyt9iSeUuuq6xWc5tZUFHbYBH3FNxAVfUptVtKfhS2n\",\"pool_state_root_hash\":\"35qFDfjHYayGD65orPLPJ7x1hozpkjnEruUJY7GhJJAg\",\"timestamp\":1538484045,\"ledger_id\":1,\"txn_root_hash\":\"4XCnX9hseDv7Gm41BKN9CoMvqiXGzUUqn8udxgPiYHgf\"},\"participants\":[\"Node2\",\"Node1\",\"Node4\"]}},\"type\":\"108\"},\"op\":\"REPLY\"}" ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid transaction: Cannot deserialize transaction Response: Error("data did not match any variant of untagged enum Reply", line: 0, column: 0) ```

sklump (Tue, 02 Oct 2018 13:35:41 GMT):
@smithbk Is it reproducible or a once-in-thousands occurrence? See https://github.com/hyperledger/indy-sdk/blob/db3bf4534b9a7aa7764c540bd0e8383ce97764ed/wrappers/python/tests/ledger/test_submit_request.py#L231 for a sample that waits for a cred-def transaction to appear definitively on the ledger before proceeding. For whatever reason, and this may be wrong, it appears that the indy-sdk hands off submissions to the node pool and then proceeds, which introduces a race condition. If unlucky and quick, a subsequent query for the transaction on the ledger might precede its actual negotiation onto the blockchain.

sklump (Tue, 02 Oct 2018 13:36:17 GMT):
... if it's reproducible, I'd love to know how you do it. It nagged me for weeks.

smithbk (Tue, 02 Oct 2018 13:37:36 GMT):
Yeh, it is very reproducible but in the context of a lot of other code. I could gather any trace, add other debug, etc to help to diagnose though

sklump (Tue, 02 Oct 2018 13:39:37 GMT):
That's OK, the way forward for me has been to wait as in the sample, in sending schemata and cred-defs, for the sequence number.

smithbk (Tue, 02 Oct 2018 13:42:19 GMT):
ok, thanks

smithbk (Tue, 02 Oct 2018 17:11:42 GMT):
@sklump That didn't fix for me, so I looked at trace for `ledger.sign_and_submit_request` when pushing the cred def to the ledger and I see the following: ``` INFO|indy::services::pool | src/services/pool/mod.rs:692 | RemoteNode::recv_msg Node3 {"reqId":1538498117841794100,"identifier":"YHqAHwi6jq6cU2rcBE3owp","op":"REQNACK","reason":"client request invalid: InsufficientCorrectSignatures(0, 1)"} DEBUG|indy::services::pool::transaction_handler|src/services/pool/transaction_handler.rs:176 | TransactionHandler::process_reject: >>> response: ResponseV0(ResponseV0 { req_id: 1538498117841794100 }), raw_msg: "{\"reqId\":1538498117841794100,\"identifier\":\"YHqAHwi6jq6cU2rcBE3owp\",\"op\":\"REQNACK\",\"reason\":\"client request invalid: InsufficientCorrectSignatures(0, 1)\"}" ``` Any ideas what causes this? I was wondering if it is collecting steward node signatures to reach consensus but I don't see any success later

sklump (Tue, 02 Oct 2018 17:18:26 GMT):
The only time I've seen that is with incorrect Genesis transactions. Have you recently upgraded the indy pool to protocol 1.4=1.6=2?

smithbk (Tue, 02 Oct 2018 17:25:08 GMT):
no, and I have my versions locked as follows to prevent things changing underneath me ```ARG indy_plenum_ver=1.4.419 ARG indy_anoncreds_ver=1.0.32 ARG indy_node_ver=1.4.480 ARG python3_indy_crypto_ver=0.4.1 ARG indy_crypto_ver=0.4.0 ```

sklump (Tue, 02 Oct 2018 17:25:47 GMT):
I'm afraid this one is for the core guys then - please let me know what they find, if anything.

smithbk (Tue, 02 Oct 2018 17:26:11 GMT):
ok, so in indy-node channel?

sklump (Tue, 02 Oct 2018 17:30:14 GMT):
I think that's likely the best guess

smithbk (Tue, 02 Oct 2018 19:58:30 GMT):
@sklump It looks like the problem goes away if we decrease the number of attribute names in the schema :-)

dono (Tue, 02 Oct 2018 21:28:06 GMT):
Has joined the channel.

dono (Tue, 02 Oct 2018 21:28:15 GMT):
Hello anyone here?

Dubh3124 (Wed, 03 Oct 2018 03:04:01 GMT):
Has joined the channel.

aniv (Wed, 03 Oct 2018 09:13:24 GMT):
Has joined the channel.

aniv (Wed, 03 Oct 2018 09:47:32 GMT):
Hi there! I'm trying to run https://github.com/hyperledger/indy-sdk/blob/v1.6.6/samples/python/src/ledger.py against local test node. However it falls off with timeout on nym sending (L41-42). And after like half a minute node is showing following message. `2018-10-03 09:38:07,183|WARNING|replicas.py|Unordered request with reqId: 4926c5dd8d13870f1ab2bd3fadefc439014d3c12aa0f9921891b2af425b40fe0 was not found in prePrepares. Prepares count: 0, Commits count: 0` Tried to increase timeout, with no success, unfortunately. Can you give me an idea which direction I should look?

MaheshSharma (Wed, 03 Oct 2018 10:44:33 GMT):

Screenshot from 2018-10-03 16-11-28.png

MaheshSharma (Wed, 03 Oct 2018 10:44:39 GMT):
We have run indy-sdk/wrappers/python/tests/demo$ pytest Showing Error :indy.error.IndyError: ErrorCode.PoolLedgerTimeout

sklump (Wed, 03 Oct 2018 11:06:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=pXDm8FKzqM9HKYfjh) @smithbk Tremendous! How many were there? One of our applications is looking at 30-ish and I wonder if it'll be a worry. _update: I managed to get one recurrence of this error around 320 attributes, but not subsequently -- I'm currently running a test that's managing over 2500 attributes in a test schema and so far no recurrence_

sklump (Wed, 03 Oct 2018 11:06:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=pXDm8FKzqM9HKYfjh) @smithbk Tremendous! How many were there? One of our applications is looking at 30-ish and I wonder if it'll be a worry. _update: I managed to get one recurrence of this error around 320 attributes, but not subsequently -- I'm currently running a test that's coping with over ~2500~ 3200 attributes in a test schema and so far no recurrence_

sklump (Wed, 03 Oct 2018 11:06:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=pXDm8FKzqM9HKYfjh) @smithbk Tremendous! How many were there? One of our applications is looking at 30-ish and I wonder if it'll be a worry. _update: I managed to get one recurrence of this error around 320 attributes, but not subsequently -- I'm currently running a test that's coping with over ~2500~ 3800 attributes in a test schema and so far no recurrence_

fabienpe (Wed, 03 Oct 2018 14:41:09 GMT):
The getting started guide proposes a way for a trust anchor to onboard with a Steward but the protocol of the "Connecting the Establishment" section seems incomplete and seems to assume that the unencrypted connection request is sent somehow securely. Furthermore at no point does the Steward verify that Faber has possession of the key associated to the DID sent in the response. To complete the protocol Faber should send a nonce as part of the response and Steward should send a final encrypted ack with Faber's nonce. Don't you think?

AxelNennker (Wed, 03 Oct 2018 16:44:58 GMT):
tails.rs has a sha256 hasher but finalize is never called and removing the hasher has no effect on `RUST_TEST_THREADS=1 cargo test lib`. What is the bug here? 1) hashes are processed but not used or 2) final hash is not computed and not used? Or am I missing something? https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/commands/anoncreds/tails.rs#L90

AxelNennker (Wed, 03 Oct 2018 16:53:55 GMT):
service.finalize calls _a_ hasher.finalize but not the same hasher the is used in tails.rs

swcurran (Thu, 04 Oct 2018 04:41:32 GMT):
@gudkov - at a meeting the other day about revocation, there was a mention that a prover might be able to do some tails file processing at credential receipt time to reduce the calculation time at proof generation time. Is that accurate? If between processing the tails file and proving non-revocation, some number of credentials were revoked, the Prover has to get the witness deltas, and then (as I understand it), calculate the updated witness using data in the tails file and the prover's private factor. Is work done previously (as described above) going to decrease the time for that calculation? A yes or no answer is probably sufficient, but if you can point out how or other details, that would be helpful. Thanks!

AxelNennker (Thu, 04 Oct 2018 05:40:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=cw2noRBYcBME93h2Y) created https://jira.hyperledger.org/browse/IS-1026

AxelNennker (Thu, 04 Oct 2018 09:00:41 GMT):
PR is here https://github.com/hyperledger/indy-sdk/pull/1181

sklump (Thu, 04 Oct 2018 10:23:56 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=DEy3RLuam2dfCJ9wh) @swcurran @swcurran von_anchor already implements this in the cache layer

sklump (Thu, 04 Oct 2018 10:26:15 GMT):
@swcurran I believe the private factor only comes into play in creating proof. It is possible to pre-compute and cache known witness deltas to revocation registries as they become available: von_anchor revocation cache already does this.

swcurran (Thu, 04 Oct 2018 12:50:44 GMT):
Thanks - I think I get it. Do the math on the whole tails file, save the result, and then process the witness deltas either as they occur or at proof time based on the pre-computed result. Either way, fewer operations. Is that more or less it?

sklump (Thu, 04 Oct 2018 13:04:37 GMT):
The Issuer creates the tails file for a revocation registry in time to issue a credential against it. From the moment of its creation, it will have an initial state (with an initial accumulator) and a witness for each random number as indexed. Any subsequent revocation (delta) affects witness values and it goes onto the ledger; any delta rolls up the prior delta _(I think?)_ so getting the most recent before any given time of interest ought to suffice. The prover won't know about any delta until it consults the ledger, but if a good-enough value is cached for the revocation registry, it can use the one from the cache (https://github.com/PSPC-SPAC-buyandsell/von_base/blob/master/doc/pic/revo-cache-reg-upd-frames.png illustrates).

sklump (Thu, 04 Oct 2018 13:04:37 GMT):
The Issuer creates the tails file for a revocation registry in time to issue a credential against it. From the moment of its creation, it will have an initial state (with an initial accumulator) and a witness for each random number as indexed. Any subsequent revocation (delta) affects witness values and it goes onto the ledger; any delta rolls up the prior deltas cumulatively _(I think?)_ so getting the most recent before any given time of interest ought to suffice. The prover won't know about any delta until it consults the ledger, but if a good-enough value is cached for the revocation registry, it can use the one from the cache (https://github.com/PSPC-SPAC-buyandsell/von_base/blob/master/doc/pic/revo-cache-reg-upd-frames.png illustrates).

rikgig (Thu, 04 Oct 2018 14:13:24 GMT):
Has joined the channel.

baconsandwich (Thu, 04 Oct 2018 15:50:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=TzpDs6NRk54DZ27P2) @MaheshSharma Check if the IP set in the genesis transaction is the IP of the pool (probalby the machine this is running on)

sergey.minaev (Thu, 04 Oct 2018 17:09:53 GMT):
@MaheshSharma more details about docker setup: https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker

mgbailey (Thu, 04 Oct 2018 21:37:54 GMT):
Are there logs for the indy-cli? There were for the old python cli, but I don't find them for the current one.

Elakkiyaselvan (Fri, 05 Oct 2018 08:31:16 GMT):
Has joined the channel.

Elakkiyaselvan (Fri, 05 Oct 2018 08:33:45 GMT):
Hi

Elakkiyaselvan (Fri, 05 Oct 2018 08:34:04 GMT):
im beginner to HYPERLEGER-INDY

Elakkiyaselvan (Fri, 05 Oct 2018 08:34:39 GMT):
anyone please help with Indy installation details

Elakkiyaselvan (Fri, 05 Oct 2018 09:56:34 GMT):
i tried to install indy-sdk by using command in cmd.exe

Elakkiyaselvan (Fri, 05 Oct 2018 09:56:41 GMT):
gyp ERR! stack at ChildProcess.onExit (C:\Users\Admin\AppData\Roaming\npm\no de_modules\npm\node_modules\node-gyp\lib\build.js:262:23) gyp ERR! stack at emitTwo (events.js:126:13) gyp ERR! stack at ChildProcess.emit (events.js:214:7) gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_proces s.js:198:12) gyp ERR! System Windows_NT 6.3.9600 gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\Users\\Admin\\AppDat a\\Roaming\\npm\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "r ebuild" gyp ERR! cwd C:\WINDOWS\system32\node_modules\indy-sdk gyp ERR! node -v v8.11.3 gyp ERR! node-gyp -v v3.8.0 gyp ERR! not ok npm WARN enoent ENOENT: no such file or directory, open 'C:\WINDOWS\system32\pac kage.json' npm WARN system32 No description npm WARN system32 No repository field. npm WARN system32 No README data npm WARN system32 No license field. npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR! indy-sdk@1.6.2 install: `node-gyp rebuild` npm ERR! Exit status 1

Elakkiyaselvan (Fri, 05 Oct 2018 09:57:05 GMT):
anyone help to resolve this

sergey.minaev (Fri, 05 Oct 2018 11:48:19 GMT):
@mgbailey for stable IndyCLI and old master you can set `RUST_LOG=trace` env variable and obtain logs from libindy and cli. But it will be not user-friendly and in stdout together with IndyCLI output For up-to-date masters builds (~ last 1.5 month) there is new logger available please see help of the command or setup config as indy-cli parameter https://github.com/hyperledger/indy-sdk/tree/master/cli#options Example configuration for master can be found at https://github.com/hyperledger/indy-sdk/blob/master/cli/logger.yml

mgbailey (Fri, 05 Oct 2018 13:52:53 GMT):
thanks @sergey.minaev

baconsandwich (Fri, 05 Oct 2018 20:13:06 GMT):
`did.set_endpoint_for_did()` sets the endpoint that identifies how to contact a DID, right? basically I get_nym a DID, see the endpoint and then now how to contact that user agent, right?

srottem (Sun, 07 Oct 2018 08:19:56 GMT):
indy-pool

bootstrapsp (Sun, 07 Oct 2018 14:21:05 GMT):
Has joined the channel.

bootstrapsp (Sun, 07 Oct 2018 17:44:54 GMT):
hello all, I see there were some discussions around Go wrapper earlier this year - is there any update around that ...

wangdong (Mon, 08 Oct 2018 04:18:09 GMT):
when I run the test case of cli in my Mac, most of the cases failed. When I enabled the trace, I got the info.

wangdong (Mon, 08 Oct 2018 04:18:52 GMT):
panicked at 'called `Result::unwrap()` on an `Err` value: ()', libcore/result.rs:945

wangdong (Mon, 08 Oct 2018 04:19:24 GMT):
the failure got the same panic error message. Anyone got some clue on this?

wangdong (Mon, 08 Oct 2018 04:21:23 GMT):
As I found it from the source code of rust, but i am not sure how to improve it.

wangdong (Mon, 08 Oct 2018 04:21:26 GMT):
#[unstable(feature = "inner_deref", reason = "newly added", issue = "50264")] impl Result { /// Converts from `&Result` to `Result<&T::Target, &E>`. /// /// Leaves the original Result in-place, creating a new one with a reference /// to the original one, additionally coercing the `Ok` arm of the Result via /// `Deref`. pub fn deref_ok(&self) -> Result<&T::Target, &E> { self.as_ref().map(|t| t.deref()) } }

wangdong (Mon, 08 Oct 2018 04:29:44 GMT):
I ran rust --version: got rustc 1.29.0 (aa3ca1994 2018-09-11)

srottem (Mon, 08 Oct 2018 09:43:35 GMT):
Hi guys, I'm in the process of bringing the test suite for the .NET framework up to date and I'm getting some failures. I can see that the ProverGetCredentialsForProofReqAsync is marked as deprecated since version 1.6.1 - should it still work with 1.6.4 anyway?

xnopre (Mon, 08 Oct 2018 11:03:41 GMT):
Hi all. Is it possible to update a credential provided by the issuer and stored by the prover ? In my POC, if I run twice the scenario (prover sending credential request to issuer, and storing the received credential), and I have a "213" error ("DUPLICATE_WALLET_RECORD") calling `proverStoreCredential`. Thank you for your help :-)

sergey.minaev (Mon, 08 Oct 2018 12:42:35 GMT):
@wangdong I suggest to run libindy tests before experiments with tests of cli.

tomislav (Mon, 08 Oct 2018 13:46:12 GMT):
@xnopre The concept of updating a credential is equal to revoking old credential by issuer and issuing a new one. Prover can then store the "updated" credential, which is essentially entirely new credential. Prover will end up with two credentials, one of which would produce invalid proof is used. An application library (such as VCX) could communicate the rejection/revocation back to the prover so they can mark the old credential as invalid, but this behavior isn't available out of the box with indy sdk.

malonj (Mon, 08 Oct 2018 17:48:29 GMT):
Has joined the channel.

ianco (Mon, 08 Oct 2018 20:48:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=uhMLpPBYiwN8FRWBm) @wangdong Try to find the first failed test. I think if a test fails and doesn't cleanup properly (delete wallet etc) then it's possible that further tests will fail. I also suggest running the tests with a single thread (--test-threads=1) to prevent any concurrency issues.

wangdong (Tue, 09 Oct 2018 01:17:10 GMT):
@ianco ok. I will try that. Thanks for the advice.

xnopre (Tue, 09 Oct 2018 07:56:16 GMT):
@tomislav Thank you for your answer. Actually, the prover call `proverStoreCredential` with a specified `credId`, but with a new credential, calling this function failed with error `DUPLICATE_WALLET_RECORD`. I suppose I have to unset this parameter, so that it is a random one, but then, how can I find the last "good" credential ? I suppose I have to use `proverGetCredentials` (instead of `proverGetCredential` with `credId`) but how to filter the `credentials` result to get the last good credential ? And if I understand, I have to self manage all the process if a credential can be updated (prover sending credential request to issuer, and storing the received credential) ? Thanks :-)

sklump (Tue, 09 Oct 2018 10:32:52 GMT):
@xnopre, if your intent is to make your test suite reproducible, my advice is to wipe out ~/.indy_client and restart the pool on every iteration, then run everything from NYM anchor transactions in the test suite.

sklump (Tue, 09 Oct 2018 10:32:52 GMT):
@xnopre, if the intent is to make your test suite reproducible, one approach is to wipe out ~/.indy_client and restart the pool on every iteration, then run everything from NYM anchor transactions in the test suite. Otherwise, you can add a unique attribute for each iteration (e.g., epoch time) so it doesn't clobber an existing credential from a prior run.

dono (Tue, 09 Oct 2018 15:16:59 GMT):
hello anyone here willing to help out a beginner

sklump (Tue, 09 Oct 2018 16:33:28 GMT):
@dono have you checked out the samples?

dono (Tue, 09 Oct 2018 17:03:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=cYXiLkH5ijEKyaC4N) @sklump I have looked at them yes but I received errors running pytest to test the installation on Windows. I'm setting up a xenial VM right now to try there instead

ShivVenkatraman (Tue, 09 Oct 2018 23:36:36 GMT):
Is there any known limit on (i) number of attributes that be defined for a credential (ii) size of values set for credential (what happens if someone sets a huge value like image to a credential value instead of the example we have like age etc.)?

haggs (Wed, 10 Oct 2018 01:46:32 GMT):
@ShivVenkatraman That's a good point, I would assume some serialized data could come out of that. However I imagine theres a set standard to a .png, .jpeg, or vector if you'd like to point to that. https://www.evernym.com/wp-content/uploads/2017/07/What-Goes-On-The-Ledger.pdf

haggs (Wed, 10 Oct 2018 01:53:31 GMT):
You might be better off pointing to a URL or a schema for an image format in your DDO and served privately or whatnot. Right now there's a decently active discussion about size of ledger writing in overlays-service as it pertains to schemas. Now, I might be assuming you're talking about writing some form of this to the public ledger (most likely). I don't know your use case but writing to the ledger that you verified a biometric (like a face, thumbprint, vocal noise, etc.) is a credential in most cases rather than actually having it set to a huge value in memory/storage. So for example: verifiable credential might be that they look like the person on their driver's license - that involves pictures and pictures of ID's, but the credential as given by the issuer is a true or false value (or a maybe, who knows!). Good question though as a bloated ledger is a fear and the hope is that 99% stays off ledger in microledgers for performance and lack of correlation's sake. :D

ldaponte (Wed, 10 Oct 2018 15:22:28 GMT):
Has joined the channel.

ldaponte (Wed, 10 Oct 2018 15:25:35 GMT):
Hello all. I've gotten the test nodes working and the examples and I'm trying to create a new pool from scratch - not a test pool but one of my own making. I've issued a init_indy_keys for my first node but I don't know how to create the pool_transactions_genesis. I've found copies of this file in the SDK but assume I need to create one of these from scratch based on the output of init_indy_keys

ldaponte (Wed, 10 Oct 2018 15:27:06 GMT):
Do I need to create this file in a text editor? I've found some scripts that generate these but they all have four nodes and some predefined BLS keys

ldaponte (Wed, 10 Oct 2018 15:32:57 GMT):
Looks like maybe I need to issue a send NODE from the CLI

ldaponte (Wed, 10 Oct 2018 15:33:26 GMT):
but the CLI isn't connected to anything yet

sergey.minaev (Wed, 10 Oct 2018 15:52:42 GMT):
@ldaponte IndyNode will create genesis file after first run AFAIR, or may be even at init_indy_keys, not sure. After it you can copy this file to SDK and use it with CLI. Latest version of IndyNode creates this file at `/var/lib/indy//pool_transactions_genesis`

ldaponte (Wed, 10 Oct 2018 15:55:34 GMT):
Hi Sergey, init_indy_keys does not generate the genesis file. I've started the first node and it complains that the file is not there: 2018-10-10 14:52:44,156|NOTIFICATION|genesis_txn_initiator_from_file.py|File that should be used for initialization of Ledger does not exist: /var/lib/indy/novartis/domain_transactions_genesis

ldaponte (Wed, 10 Oct 2018 15:56:43 GMT):
I know where the file should go - /var/lib/indy/xxx/domain_transactions_genesis where xxx is the pool name

ldaponte (Wed, 10 Oct 2018 16:01:21 GMT):
Same goes for creating the domain_transactions_genesis

ldaponte (Wed, 10 Oct 2018 16:04:37 GMT):
Coming to the conclusion that I need to use generate_indy_pool_transactions [https://github.com/hyperledger/indy-node/blob/master/docs/start-nodes.md]

ldaponte (Wed, 10 Oct 2018 16:39:30 GMT):
yup, that seems to work. Trying to add a new node now and it seems I need to import the did that I generated as part of the generate_indy_pool_transactions

ldaponte (Wed, 10 Oct 2018 16:40:29 GMT):
Getting this error when I try to add a node using indy-cli: Transaction has been rejected: client request invalid: InsufficientCorrectSignatures(0, 1)

ShivVenkatraman (Wed, 10 Oct 2018 19:39:55 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=pXvqRBKmpCmbWRWBT) @haggs Is there a limit on number of attributes that can be defined for a schema (since the schema/claim definition is stored on the ledger)?

haggs (Wed, 10 Oct 2018 21:01:33 GMT):
@ShivVenkatraman I'm not quite sure and not quite sure that's been decided yet. Good question, anyone else with thoughts? I assume there is for sure an attribute limit. Check out this HIPE PR in working view: https://github.com/jonathanworkday/indy-hipe/tree/master/text/schema-overlays Courtesy of Jonathan Reynolds

haggs (Wed, 10 Oct 2018 21:03:21 GMT):
One of the major possible drawbacks of Overlays on the ledger is: "[The] Need to manage proliferation of overlays since they increase the size of the ledger." I'm hoping there will be some great active discussion about that drawback that might help answer your question!

swcurran (Thu, 11 Oct 2018 00:51:04 GMT):
A question @pimotte asked back in April - has anyone done any work with compiling libindy to webassembly? This is new to us, but seems like it could be a great way to create sufficiently rich Agents to run on browsers - including mobile. Anyone with any experience in that domain?

wangdong (Thu, 11 Oct 2018 06:39:40 GMT):
Hi， I try to make sdk run in MacOS. when I run test cases of libindy. I got error like this:

wangdong (Thu, 11 Oct 2018 06:39:50 GMT):
src/services/pool/pool.rs:537 | received pool event:.......

wangdong (Thu, 11 Oct 2018 06:39:59 GMT):
src/services/pool/pool.rs:409 | Unexpected timeout:

wangdong (Thu, 11 Oct 2018 06:40:22 GMT):
and it just put out these two lines consistently.

wangdong (Thu, 11 Oct 2018 06:41:47 GMT):
Above is the trace error log.

wangdong (Thu, 11 Oct 2018 06:42:05 GMT):
when I remove trace log, it just pends on function: open_pool_ledger_works_after_error

wangdong (Thu, 11 Oct 2018 06:42:05 GMT):
when I remove trace log, it just pends on this single test case: open_pool_ledger_works_after_error

wangdong (Thu, 11 Oct 2018 06:43:16 GMT):
But when I run it alone, it can be passed.

wangdong (Thu, 11 Oct 2018 06:45:27 GMT):
anyone got any idea about this?

srunpengsreang (Thu, 11 Oct 2018 07:03:42 GMT):
Has joined the channel.

srunpengsreang (Thu, 11 Oct 2018 07:09:24 GMT):
Hello guys here, right now I am researching this indy-sdk for iOS and I have questions about

srunpengsreang (Thu, 11 Oct 2018 07:10:40 GMT):
My question is that we use only this indy-sdk for creating iOS app

srunpengsreang (Thu, 11 Oct 2018 07:11:04 GMT):
Or we need to use other tools to build along with?

srunpengsreang (Thu, 11 Oct 2018 07:11:36 GMT):
Please help answer my question

wangdong (Thu, 11 Oct 2018 07:40:07 GMT):
@srunpengsreang i am working on this too.

wangdong (Thu, 11 Oct 2018 07:40:20 GMT):
there is a doc but not so good.

srunpengsreang (Thu, 11 Oct 2018 07:40:32 GMT):
Okay nice to meet you here @wangdong

srunpengsreang (Thu, 11 Oct 2018 07:40:53 GMT):
I am using Xcode 10

wangdong (Thu, 11 Oct 2018 07:40:53 GMT):
I think you can build it on Mac

wangdong (Thu, 11 Oct 2018 07:41:16 GMT):
or some OS with the framework.

srunpengsreang (Thu, 11 Oct 2018 07:41:39 GMT):
@wangdong Have you build success on Mac?

wangdong (Thu, 11 Oct 2018 07:41:48 GMT):
I am trying to build the libindy in MacOS.

wangdong (Thu, 11 Oct 2018 07:41:51 GMT):
not yet.

wangdong (Thu, 11 Oct 2018 07:41:59 GMT):
the test cases got some problem

wangdong (Thu, 11 Oct 2018 07:42:10 GMT):
trying to fix that

srunpengsreang (Thu, 11 Oct 2018 07:42:55 GMT):
@wangdong which Xcode version did you use to build ?

wangdong (Thu, 11 Oct 2018 07:43:41 GMT):
I did not build iOS now. before this, I will have to enable it on Mac

wangdong (Thu, 11 Oct 2018 07:43:50 GMT):
iOS is for next step

wangdong (Thu, 11 Oct 2018 07:44:25 GMT):
my xcode version is also 10.0

srunpengsreang (Thu, 11 Oct 2018 07:44:51 GMT):
I have built with iOS but the sdk supports 4.1.2 swift compiler

srunpengsreang (Thu, 11 Oct 2018 07:45:19 GMT):
Right now I am installing Xcode 9 to test to build it

wangdong (Thu, 11 Oct 2018 07:46:40 GMT):
ok. you have built it successfully ?

srunpengsreang (Thu, 11 Oct 2018 07:47:38 GMT):
Not yet, I am downloading Xcode 9

srunpengsreang (Thu, 11 Oct 2018 07:47:54 GMT):
But one question @wangdong

wangdong (Thu, 11 Oct 2018 07:48:15 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/wrappers/ios/README.md

wangdong (Thu, 11 Oct 2018 07:48:26 GMT):
pleaser refer to this readme

srunpengsreang (Thu, 11 Oct 2018 07:49:19 GMT):
Do we need only this indy-sdk to build for testing in iOS or we need other tools to support it too?

srunpengsreang (Thu, 11 Oct 2018 07:50:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=umuiG3iKRHvH5rWWm) @wangdong yes I follow this one

wangdong (Thu, 11 Oct 2018 07:51:02 GMT):
indy-sdk is enough I think

srunpengsreang (Thu, 11 Oct 2018 07:51:24 GMT):
But one more thing

wangdong (Thu, 11 Oct 2018 07:51:24 GMT):
for test, you will have to boot a test network pool.

srunpengsreang (Thu, 11 Oct 2018 07:52:20 GMT):
@wangdong have you read Alice's scenario ?

srunpengsreang (Thu, 11 Oct 2018 07:52:57 GMT):
I have read it but I only understand some parts

wangdong (Thu, 11 Oct 2018 08:02:12 GMT):
This build got little with that scenario.

srunpengsreang (Thu, 11 Oct 2018 08:06:42 GMT):
Yes I think so

srunpengsreang (Thu, 11 Oct 2018 08:07:36 GMT):
That is why I don't know where to start it

srunpengsreang (Thu, 11 Oct 2018 08:11:11 GMT):
@wangdong Do you where we ask developers to update this Indy-Idk for iOS to support Xcode 10?

srunpengsreang (Thu, 11 Oct 2018 08:11:11 GMT):
@wangdong Do you know where we ask developers to update this Indy-Idk for iOS to support Xcode 10?

wangdong (Thu, 11 Oct 2018 08:11:50 GMT):
here is the place, I think.

wangdong (Thu, 11 Oct 2018 08:12:46 GMT):
is there any info about this? I mean sdk now does not support Xcode 10, is there any explicit info about this?

wangdong (Thu, 11 Oct 2018 08:13:07 GMT):
@srunpengsreang

srunpengsreang (Thu, 11 Oct 2018 08:14:57 GMT):
@wangdong I don't know now. I just read the comments and they mentioned this sdk support 4.1.2 swift compiler.

srunpengsreang (Thu, 11 Oct 2018 08:15:30 GMT):
And I want to ask them to update this sdk

wangdong (Thu, 11 Oct 2018 08:16:07 GMT):
ok. here is the place. or you can open a PR.

srunpengsreang (Thu, 11 Oct 2018 08:16:45 GMT):
Sorry @wangdong what is PR?

wangdong (Thu, 11 Oct 2018 08:17:26 GMT):
you can open a ticket in jira. The dev team will see this.

srunpengsreang (Thu, 11 Oct 2018 08:18:08 GMT):
Okay I do it

srunpengsreang (Thu, 11 Oct 2018 08:30:28 GMT):
@wangdong I can't log in into PR. May I ask you to do this?

wangdong (Thu, 11 Oct 2018 08:35:24 GMT):
you need a linux foundation account.

wangdong (Thu, 11 Oct 2018 08:35:50 GMT):
go and register one.

sergey.minaev (Thu, 11 Oct 2018 11:11:20 GMT):
@srunpengsreang some quote from my DM to wangdong > there are 2 iOS pods for IndySDK 1) `libindy-objc` - libindy + ObjC wrapper. libindy already included into this iOS framework 2) `libindy` - just libindy, compiled as universal library for iOS > both of them are not published to central CocoaPods, you have to specify custom source as mentioned in https://github.com/hyperledger/indy-sdk/tree/master/wrappers/ios#how-to-install So you can create minimal Podfile like ``` source 'https://github.com/hyperledger/indy-sdk.git' def appPods pod 'libindy-objc', "1.6.1" end ``` in this case, there is no need to build libindy from source

sergey.minaev (Thu, 11 Oct 2018 11:11:20 GMT):
@srunpengsreang some quote from my DM to wangdong > there are 2 iOS pods for IndySDK > 1) `libindy-objc` - libindy + ObjC wrapper. libindy already included into this iOS framework > 2) `libindy` - just libindy, compiled as universal library for iOS > both of them are not published to central CocoaPods, you have to specify custom source as mentioned in https://github.com/hyperledger/indy-sdk/tree/master/wrappers/ios#how-to-install So you can create minimal Podfile like ``` source 'https://github.com/hyperledger/indy-sdk.git' def appPods pod 'libindy-objc', "1.6.1" end ``` in this case, there is no need to build libindy from source

srunpengsreang (Thu, 11 Oct 2018 11:27:20 GMT):
Yes thank you @sergey.minaev

srunpengsreang (Thu, 11 Oct 2018 11:28:32 GMT):
But this version 1.6.1 does not support Xcode 10

sergey.minaev (Thu, 11 Oct 2018 11:39:48 GMT):
Actually this iOS wrapper is not tier 1 (libindy-objc), as result there is no iOS developer in core IndySDK team. Please create the task in our Jira about support Xcode 10 for this wrapper, but I can't estimate priority for this task and the time to fix it by core team. But any contribution is appreciated and core team will try to help community to implement this task

mountbranch (Thu, 11 Oct 2018 12:22:03 GMT):
Hi, which specific algorithm is being used for the accumulator in the revocation list?

sergey.minaev (Thu, 11 Oct 2018 12:48:47 GMT):
@mountbranch https://github.com/hyperledger/indy-crypto/blob/master/libindy-crypto/docs/AnonCred.pdf

mountbranch (Thu, 11 Oct 2018 13:30:57 GMT):
Yeah, I read that, but there's no reference as to what the type of accumulator is, or is itjust called the anoncred accumulator?

pimotte (Thu, 11 Oct 2018 13:39:01 GMT):
@mountbranch They mention a CKS accumulator, which I think refers to this paper: https://eprint.iacr.org/2008/539.pdf

osesov (Thu, 11 Oct 2018 15:07:26 GMT):
Has joined the channel.

mountbranch (Thu, 11 Oct 2018 16:21:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wC6X2yHHRG9TS5GYi) @pimotte Thanks!

ShivVenkatraman (Thu, 11 Oct 2018 18:49:42 GMT):
Suppose a user has credential values with age = 28. And he creates (or attempts to) a (invalid) proof with age > 28. Can the exception thrown be more than friendlier than the one below? "Caused by: org.hyperledger.indy.sdk.InvalidStructureException: A value being processed is not valid. at org.hyperledger.indy.sdk.IndyException.fromSdkError(IndyException.java:72) at org.hyperledger.indy.sdk.IndyJava$API.checkResult(IndyJava.java:90)"

aknudsen (Fri, 12 Oct 2018 08:15:50 GMT):
Has joined the channel.

aknudsen (Fri, 12 Oct 2018 08:21:07 GMT):
I'm trying to build WASM bindings of libindy-crypto's BLS component. I've succeeded in building them (through a fork of libindy-crypto), but when trying to sign a message, I get multiplication overflow error in amcl

aknudsen (Fri, 12 Oct 2018 08:21:55 GMT):
Might anyone be able to help in debugging this overflow issue? I'll be happy to share how to reproduce. Might the underlying cause be that WASM is a 32-bit architecture?

aknudsen (Fri, 12 Oct 2018 08:23:43 GMT):
My WASM bindings branch is here https://github.com/aknuds1/indy-crypto/tree/wasm-binding

faisal00813 (Fri, 12 Oct 2018 09:29:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jKtJdLq4HyBAucnHt) @aknudsen Try building (cargo build --release) in release mode.

faisal00813 (Fri, 12 Oct 2018 09:29:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jKtJdLq4HyBAucnHt) @aknudsen Try building in release mode (cargo build --release).

xnopre (Fri, 12 Oct 2018 09:42:31 GMT):
Hi all. Based on this script (https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.ipynb), I have rewritten the story until "Alice -> Store 'Job-Certificate' Credential", with NodeJs SDK wrapper, and separating each actors (Steward, Alice, Faber and Acme) in different processes, especially to separate operations for each actor, and to implement (and show) communications and data exchanged between actors. All is packaged to run in different docker containers, with "make" commands to simply run the script. I think it can be interesting to share it, as example (demo). And I can share it :-) . But the question is who or where ? Perhaps it could be integrated in https://github.com/hyperledger/indy-sdk with a pull request ? Or elsewhere ? What do you think about ? Thanks :-) [posted on #general and #indy-sdk ]

kdenhartog (Fri, 12 Oct 2018 09:50:59 GMT):
@xnopre can you send me a link to this?I've just done something similar to build an easy Indy development environment, and one of the things I want to add next is node.js support. Here's a link if you'd like to make a PR to it. https://github.com/kdenhartog/Indy-dev

kdenhartog (Fri, 12 Oct 2018 09:50:59 GMT):
@xnopre can you send me a link to this?

kdenhartog (Fri, 12 Oct 2018 09:54:31 GMT):
I just put together a simple development environment to run IndySDK code in a docker environment. If anyone is having trouble getting IndySDK setup or wants an easy way to develop with the SDK on any OS, check out this repo. https://github.com/kdenhartog/Indy-dev

LucW (Fri, 12 Oct 2018 10:01:30 GMT):
Hey, did any of you guys manage to install the SDK on debian stretch ?

gudkov (Fri, 12 Oct 2018 10:23:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=7eabDhhLEnmYiSwmj) @aknudsen Overflow are necessary for any crypto math and expected here. Modern rust provides API to avoid runtime overflow checks in debug mode, but we applied these changes only to 64bit version of AMCL. For the moment to work with 32bit version you need to build it in release mode only.

aknudsen (Fri, 12 Oct 2018 11:04:01 GMT):
@faisal00813 @gudkov Thanks for the answers! I'm gonna try release mode

aknudsen (Fri, 12 Oct 2018 11:11:27 GMT):
Yes, it no longer crashes in release mode!

tobowers (Fri, 12 Oct 2018 11:12:36 GMT):
_is getting very excited for WASM BLS signatures_

xnopre (Fri, 12 Oct 2018 12:43:38 GMT):
@kdenhartog Discussion to follow on #indy ;-)

gudkov (Fri, 12 Oct 2018 13:01:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ciBTEgnwsgScoyQRd) @xnopre PR to indy-sdk repo can be a good start.

jakubkoci (Fri, 12 Oct 2018 13:18:48 GMT):
Hi to all. I am developing mobile app around libindy (app for identity). I know that to open the wallet you need its name and seed passphrase. My question is where and how to store this seed securely. I would like to secure the app with the PIN or Touch ID, but I don't want to user to enter seed passphrase whenever he opens the app.

jakubkoci (Fri, 12 Oct 2018 13:18:48 GMT):
Hi to all. I am developing mobile app around libindy (app for identity). I know that to open the wallet you need its name and seed passphrase. My question is where and how to store this seed securely? I would like to secure the app with the PIN or Touch ID, but I don't want to user to enter seed passphrase whenever he opens the app.

tobowers (Fri, 12 Oct 2018 13:20:08 GMT):
@jakubkoci both IOS and Android have secure keychains you can use... I'm most familiar with IOS which specifically let's you describe what apps can see it, etc and has facilities for touchid

jakubkoci (Fri, 12 Oct 2018 13:27:11 GMT):
@tobowers Oh I see, that's great. Thanks.

LucW (Fri, 12 Oct 2018 14:00:27 GMT):
So hard to install the npm indy-sdk package, there's always stuff with node-gyp screwing around. Not the first time I stumble upon that with node.

ldaponte (Fri, 12 Oct 2018 15:25:33 GMT):
indy-cli is giving the error invalid network ip address - is it not possible to add a new node to an existing pool using the FQDN of the new node?

sklump (Fri, 12 Oct 2018 16:05:35 GMT):
Check the genesis transactions - they cement in an IP address.

wangdong (Sat, 13 Oct 2018 02:04:57 GMT):
>Run Archive process for Indy target

wangdong (Sat, 13 Oct 2018 02:04:57 GMT):
I am not sure what is Archive process.>Run Archive process for Indy target

kdenhartog (Sat, 13 Oct 2018 06:45:26 GMT):
@ldaponte try doing it through http://github.com/kdenhartog/indy-dev

trthhrtz (Sun, 14 Oct 2018 10:03:02 GMT):
python `pairwise.create_pairwise` raises `ErrorCode.WalletItemNotFound`. Bug on Jira: https://jira.hyperledger.org/browse/IS-1039

smithbk (Sun, 14 Oct 2018 15:38:57 GMT):
The indy-sdk has wallet APIs to export and import a wallet. Suppose you wanted to merge two wallets. Is there any way to do this currently? If not, are there any plans or discussion about supporting in the future? Thanks

wangdong (Mon, 15 Oct 2018 02:36:00 GMT):
when I try to run `xcodebuild test -workspace Indy.xcworkspace -scheme Indy-demo -destination 'platform=iOS Simulator,name=iPhone X IndySDK,OS=11.2`

wangdong (Mon, 15 Oct 2018 02:36:25 GMT):
I got a error as below: `xcodebuild: error: Unable to find a destination matching the provided destination specifier: { platform:iOS Simulator, OS:11.2`

wangdong (Mon, 15 Oct 2018 02:36:25 GMT):
I got a error as below: 'xcodebuild: error: Unable to find a destination matching the provided destination specifier: { platform:iOS Simulator, OS:11.2'

wangdong (Mon, 15 Oct 2018 02:36:59 GMT):
`xcodebuild: error: Unable to find a destination matching the provided destination specifier: { platform:iOS Simulator, OS:11.2`

wangdong (Mon, 15 Oct 2018 02:37:16 GMT):
`xcodebuild: error: Unable to find a destination matching the provided destination specifier: { platform:iOS Simulator, OS:11.2`

wangdong (Mon, 15 Oct 2018 02:38:38 GMT):
`Ineligible destinations for the "Indy-demo" scheme: { platform:iOS, id:dvtdevice-DVTiPhonePlaceholder-iphoneos:placeholder, name:Generic iOS Device } { platform:iOS Simulator, id:dvtdevice-DVTiOSDeviceSimulatorPlaceholder-iphonesimulator:placeholder, name:Generic iOS Simulator Device`

wangdong (Mon, 15 Oct 2018 02:39:54 GMT):
If I missed something or there is a misconfig for ios platform between this line and the Indy-demo.

wangdong (Mon, 15 Oct 2018 02:40:25 GMT):
I got this command line from CI script.

wangdong (Mon, 15 Oct 2018 02:40:26 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/Jenkinsfile.ci#L233

wangdong (Mon, 15 Oct 2018 02:47:39 GMT):
And i saw from the Podfile :platform :ios, '10.2'

wangdong (Mon, 15 Oct 2018 02:48:32 GMT):
but the command line has 11.2 and iPhone X. But it still fails when I changed the command line to 10.2

sergey.minaev (Mon, 15 Oct 2018 09:49:52 GMT):
@smithbk there is now API now to merge 2 (or more) wallets into single one. Import will always create new wallet (or fail).

sergey.minaev (Mon, 15 Oct 2018 09:49:52 GMT):
@smithbk there is no API now to merge 2 (or more) wallets into single one. Import will always create new wallet (or fail).

sergey.minaev (Mon, 15 Oct 2018 09:52:15 GMT):
Internally (in core IndySDK team) we discuss this topic time to time, but there was no strong use cases detected yet. So our feeling now is "it's possible to do it, but we don't see real usage". Feel free to create new task in our backlog and describe your motivation

sergey.minaev (Mon, 15 Oct 2018 10:04:24 GMT):
@gudkov FYI ^

gudkov (Mon, 15 Oct 2018 10:10:02 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=rkSHiMnTaxkuniPo8) @sergey.minaev The current decision is to don't allow wallets merge. At least such functionality causes obvious conflicts problem and opens the door for some vulnerabilities. Until there is no obvious use case for this it seems better to avoid such functionality.

sergey.minaev (Mon, 15 Oct 2018 10:37:42 GMT):
@gudkov obvious conflicts problem has obvious solution) but of course it will not just one-line-change and require some additional protection and more complex API rather current one. @smithbk I agree with @gudkov summary: > Until there is no obvious use case for this it seems better to avoid such functionality. and would like to append: "... and redundant API complexity"

dono (Mon, 15 Oct 2018 19:04:56 GMT):
Can anyone tell me why I keep getting cargo build failures

dono (Mon, 15 Oct 2018 19:05:05 GMT):
on indy-sdk/libindy

n3m (Mon, 15 Oct 2018 20:21:23 GMT):
@dono What erros are you getting?

dono (Mon, 15 Oct 2018 20:33:26 GMT):
Varrying packages fail to compile

dono (Mon, 15 Oct 2018 20:33:36 GMT):
its almost a different package everytime I try

n3m (Mon, 15 Oct 2018 20:38:18 GMT):
@dono that is usually because you are missing some dependencies

n3m (Mon, 15 Oct 2018 20:38:52 GMT):
that should be installed first, and until you install those you will get errors: zeromq, openssl, libsodium...

n3m (Mon, 15 Oct 2018 20:38:52 GMT):
that should be installed first, and until you install those you will get errors: zeromq, openssl, libsodium, sqlite...

n3m (Mon, 15 Oct 2018 20:38:52 GMT):
they should be installed first, and until you install those you will get errors: zeromq, openssl, libsodium, sqlite...

kevin.chan (Mon, 15 Oct 2018 23:26:42 GMT):
hi all, can anybody confirm whether or not custom wallet support exists in any of the wrappers in SDK 1.6, it seems to me that it used to be there in 1.5 and it's still a work in progress in 1.6? I can see the rust api for registering wallets but I checked the python and java wrappers in master and looks like the register wallet calls have been removed.

kevin.chan (Mon, 15 Oct 2018 23:27:03 GMT):
is this a refactor that is in progress?

ewangplay (Tue, 16 Oct 2018 03:26:42 GMT):
Has joined the channel.

ewangplay (Tue, 16 Oct 2018 04:04:22 GMT):
Can anyone help me? when I ran the indy-sdk/samples/python/src/main , I got some errors.

ewangplay (Tue, 16 Oct 2018 04:04:40 GMT):

屏幕快照 2018-10-16 下午12.00.35.png

ewangplay (Tue, 16 Oct 2018 04:10:20 GMT):
this is the screenshot. I have builded and installed the libindy dll on my mac, and setup an allinone indy-pool env

ldaponte (Tue, 16 Oct 2018 08:48:12 GMT):
@kdenhartog @sklump Thanks both. I'm able to create a new pool + genesis file, the issue I'm having is adding a new node to an existing pool. I'm deploying this to both Azure and AWS container services and I don't know the public IP address ahead of time but I do have control over the host name. I'm able to generate a genesis file for the existing pool using host names but when adding a new node to an existing pool, indy-cli won't allow the host name, it will only take an IP address. Maybe a limitation in indy-cli. I'll try adding a new node through indylib and some Python

ldaponte (Tue, 16 Oct 2018 08:50:04 GMT):
What is the minimum number of nodes for a viable indy pool? Two?

kdenhartog (Tue, 16 Oct 2018 16:42:23 GMT):
4 to handle 1 faulty node. The generalized solution is 3F+1 where f represents the number of acceptable faulty nodes and the solution represents the total nodes needed in the pool to support that many faulty nodes while remaining in consensus.

kdenhartog (Tue, 16 Oct 2018 16:44:34 GMT):
@ldaponte im not sure how to do this through the cli, but you can do it through libindy with ledger.build_node_request()

sklump (Tue, 16 Oct 2018 16:54:57 GMT):
Submitted PR for indy-hipe #0021, universal codec. Further discussion required.

alexeidebono (Tue, 16 Oct 2018 17:26:47 GMT):
Has joined the channel.

kdenhartog (Tue, 16 Oct 2018 23:42:10 GMT):
@gudkov to submit a schema to the ledger, should I use anoncreds.issuer_create_schema() or should I use ledger.build_schema_request() As far as I can tell they do the same thing.

kdenhartog (Tue, 16 Oct 2018 23:42:10 GMT):
@gudkov @sergey.minaev to submit a schema to the ledger, should I use anoncreds.issuer_create_schema() or should I use ledger.build_schema_request() As far as I can tell they do the same thing.

jljordan_bcgov (Wed, 17 Oct 2018 03:13:46 GMT):
Only possible to use IP addresses for nodes ... DNS is effectively a centralized service and not trustworthy enough @ldaponte [ ](https://chat.hyperledger.org/channel/indy-sdk?msg=AwA7XknxHD9eWGNPS)

sergey.minaev (Wed, 17 Oct 2018 09:35:42 GMT):
@kdenhartog anoncreds.issuer_create_schema actually create schema, and ledger.build_schema_request just prepare request to publish previously created schema to ledger

gudkov (Wed, 17 Oct 2018 12:03:11 GMT):
@kdenhartog You should: 1. Create schema with issuer_create_schema 2. Build ledger request with build_schema_request (passing result from 1) 3. Sign and submit request with ledger.sign_and_submit_request

wangdong (Wed, 17 Oct 2018 14:02:05 GMT):
When I run pod install in wrapper/ios/libindy-pod, I got something like:

wangdong (Wed, 17 Oct 2018 14:02:09 GMT):
`cp: file.tgz: No such file or directory`

wangdong (Wed, 17 Oct 2018 14:02:35 GMT):
does anyone get this ? I am not sure what is wrong with it.

jcnauta (Wed, 17 Oct 2018 15:00:07 GMT):
Has joined the channel.

alexeidebono (Wed, 17 Oct 2018 15:12:43 GMT):
Can anyone explain solutions to the timeout error with the python library ? (_indy_loop_callback: Function returned error 307 Error occurred: ErrorCode.PoolLedgerTimeout) I tried the 3 docker indy pool methods listed on the GitHub page but none worked.

gudkov (Wed, 17 Oct 2018 15:27:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=xuWa5CpY5BKhgnxG4) @alexeidebono most probably you use incorrect genesis file or incorrectly configured network. You can just telnet to ip:address provided in genesis files from the host you run python tests and check this connection.

mark.hadley (Wed, 17 Oct 2018 16:20:00 GMT):
The information that is linked in the 'how to conrtibute' portion of the github readme points to a presentation. http://bit.ly/2ugd0bq And the slide regarding PR review points to #indy-pr-review, which doesnt exist. What channel should PRs be announced for indy-sdk?

jjensenevernym (Wed, 17 Oct 2018 16:57:58 GMT):
Has joined the channel.

jjensenevernym (Wed, 17 Oct 2018 16:59:01 GMT):
@gudkov Is there an easy way for a user to delete credentials they have received from their Indy wallet?

alexeidebono (Wed, 17 Oct 2018 18:11:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ttjSpghk3msGtTCXn) @gudkov You're right because i can't telnet to it. I'm using 10.0.0.2 method and telnet keeps "Trying". This is my first time running docker so im still understanding it - I did an inspection on my container and noticed that in network settings, the ip address is blank. The "10.0.0.2" address is listed under "networks". Not sure if that is whats wrong.

alexeidebono (Wed, 17 Oct 2018 18:12:16 GMT):

Clipboard - October 17, 2018 8:11 PM

sklump (Wed, 17 Oct 2018 19:05:37 GMT):
Is it expected behaviour that I can't call `blob_storage.open_writer()` from a subprocess? It hangs.

ShivVenkatraman (Wed, 17 Oct 2018 21:46:34 GMT):
Why don't I see the issuer_id in the identifier section of my retrieved proof? I am comparing my version with one from Indy World Demo (https://indyworld.vcreds.org/en/org/53/cert/141). Here is identifier (which has different attributes from that of Indy World Demo). "identifiers": [{ "cred_def_id": "KXPzeQT61vZuGSMChy9E4X:3:CL:1072:tag1", "rev_reg_id": "KXPzeQT61vZuGSMChy9E4X:4:KXPzeQT61vZuGSMChy9E4X:3:CL:1072:tag1:CL_ACCUM:tag1", "schema_id": "KXPzeQT61vZuGSMChy9E4X:2:gvt:1.0", "timestamp": 1539811852 }], From Indy World demo: "identifiers": { "claim::1c7efcaf-73fa-417c-b72f-ca9183cc00ee": { "rev_reg_seq_no": null, "schema_key": { "did": "7VkdE3erBDJnrQMVbEnRzg", "name": "entity.person", "version": "0.0.1" }, "issuer_did": "7VkdE3erBDJnrQMVbEnRzg" } },

esplinr (Wed, 17 Oct 2018 22:28:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ws9fK7XhGA2bSbDfx) @jjensenevernym Not currently. We treat the wallet as an "append-only" database, and haven't implemented APIs for deleting items. This is tolerable because large items should be stored external to the database.

jjensenevernym (Wed, 17 Oct 2018 23:01:46 GMT):
Thanks

esplinr (Wed, 17 Oct 2018 23:15:25 GMT):
I need to search the backlog for a story about deleting from the wallet, and create one if it doesn't exist. But I'm out of time today.

ClearFoundation (Thu, 18 Oct 2018 05:05:33 GMT):
Has joined the channel.

ClearFoundation (Thu, 18 Oct 2018 05:17:03 GMT):
Hello, Now the concern is that if we move to STN then what will we have some already issuer and verifier, those will verify our data or should we move to directly on the live server?

kdenhartog (Thu, 18 Oct 2018 05:44:46 GMT):
@alexeidebono if you're looking to run the getting-started guide checkout https://github.com/kdenhartog/indy-dev its designed to address these common issues around network setup and libindy dependency issues.

ShubhamSingh18 (Thu, 18 Oct 2018 11:18:01 GMT):
Has joined the channel.

ShubhamSingh18 (Thu, 18 Oct 2018 11:18:24 GMT):
tell me steps to work with indy sdk

ShubhamSingh18 (Thu, 18 Oct 2018 11:18:24 GMT):
getting error while running python sample shubhamsingh@Shubham:~/indy-sdk-master/samples/python$ python3 -m src.main Traceback (most recent call last): File "/usr/lib/python3.5/runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "/usr/lib/python3.5/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/shubhamsingh/indy-sdk-master/samples/python/src/main.py", line 3, in from src import anoncreds, anoncreds_revocation, crypto, ledger, getting_started File "/home/shubhamsingh/indy-sdk-master/samples/python/src/anoncreds.py", line 3, in from indy import anoncreds, wallet ImportError: cannot import name 'anoncreds'

esplinr (Thu, 18 Oct 2018 13:41:48 GMT):
@ShubhamSingh18 https://github.com/hyperledger/indy-sdk#how-to-tutorials

esplinr (Thu, 18 Oct 2018 13:42:28 GMT):
@ClearFoundation I don't understand your question. Are you asking if people are currently issuing credentials on the Sovrin Test Net?

ShubhamSingh18 (Thu, 18 Oct 2018 13:48:47 GMT):
Your step by step guidence or document

gudkov (Thu, 18 Oct 2018 14:47:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=MZ75z4SE9xuxvAWgf) @ShivVenkatraman cred_def_id includes issuer id as part of identifier KXPzeQT61vZuGSMChy9E4X

ClearFoundation (Thu, 18 Oct 2018 15:53:29 GMT):
@ShubhamSingh18 Our target is to make a user KYC process for our site, We have done browser user interface using node.js and python. in this interface stored credentials for Trust Anchor,Now the concern is that if we move to STN then what will we have some already issuer( for credentials) and verifier(for my users data verify) , those will verify our data Now our concern is that if user has already DID(registered on Sovrin) or already verified by Sovrin then how user will connect with us (Should we make client app to connect with user that has already DID).

ShivVenkatraman (Thu, 18 Oct 2018 23:06:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=PaNbanRoiGLEZeMfQ) @gudkov Yes, the issuer_did can be inferred from the 1st part of the other ids. But the identifier section looks different in IndyWorld demo. For example, claim, schema_key etc. are not seen in the proof I retrieve

gudkov (Fri, 19 Oct 2018 08:32:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=BoBM4Ew3PJYRYz8ca) @ShivVenkatraman Unfortunately i don't know anything about IndyWorld demo and what software stack it uses.

wangdong (Fri, 19 Oct 2018 09:30:57 GMT):
ld: library not found for -lcrypto

wangdong (Fri, 19 Oct 2018 09:30:57 GMT):
> ld: library not found for -lcrypto

wangdong (Fri, 19 Oct 2018 09:31:23 GMT):
I got this error when run ios test cases.

wangdong (Fri, 19 Oct 2018 09:31:32 GMT):
I am not sure how to fix.

AlwaysFurther (Fri, 19 Oct 2018 09:31:42 GMT):
Has joined the channel.

wangdong (Fri, 19 Oct 2018 09:33:08 GMT):
Is this crypto indy-crypto? or something else?

AlwaysFurther (Fri, 19 Oct 2018 10:58:47 GMT):
Hi all - I am trying to understand the proof process of the indy-sdk. I am using the `proverSearchCredentialsForProofRequest` and the `proverFetchCredentialForProofRequest`. In the fetch process I need to specify the item_referent of the proof request for which I am trying to get the credential for. However, for each item_referent that I am using I get the same result which is the the whole credential. (I am requesting four item_referent from the same credential definition ). I would expect it returns only the matching attribute in the credential, not the whole credential because in the end I end up with four times the same data. I also don’t understand the concept of retrieving credentials by small batches. First of all in which case would you have several credentials from the same definition ? Secondly, if someone wants to choose between several credentials from the same definition then he might want to see them all, and not just 1,2 or 10, before choosing and thus using `proverGetCredentialsForProofReq` seems more appropriate. Thank you in advance for your answers

superafro12 (Fri, 19 Oct 2018 12:17:14 GMT):
Has joined the channel.

superafro12 (Fri, 19 Oct 2018 12:46:08 GMT):
Hello! I'm following the 'Indy-SDK Getting-Started Guide' and I'm coding in Java. I'm under "Getting Verinym" in step 5. "Steward decrypts the received message by calling 'crypto.auth_decrypt". In Java the Steward decrypts the message with the function Crypto.authCrypt. This function returns the verkey for the sender of the encrypted message and the decrypted message. It does however not return the did for the sender. In the guide they use 'faber_did_info = json.loads(authdecrypted_faber_did_info_json)'. They simply load what's returned from crypto.auth_decrypt into 'faber_did_info'. Now, here's where I face problems. In next step they call 'did.key_for_did' with faber_did_info['did'] to receive the verkey for the sender of the message. This would mean that 'crypto.auth_decrypt' returns the did. But, 'Crypto.authCrypt' doesn't return the did, only the verkey and decrypted message. The verkey received from 'did.key_for_did' is used to verify the verkey received from 'crypto.auth_decrot'. How are you supposed to verify the verkey from the sender if you don't receive the did from the sender? Thanks for your time!

superafro12 (Fri, 19 Oct 2018 12:57:48 GMT):
I now also realized that you need the senders (faber) did for creating the NYM request as well, that's the next step. So basically the did, that's sent within the encrypted message (with Crypto.authCrypt) for the sender (faber) is not received by the receiver (steward) when decrypting the message.

UsmanMukaty1912 (Fri, 19 Oct 2018 23:17:47 GMT):
Has joined the channel.

ShubhamSingh18 (Mon, 22 Oct 2018 06:52:12 GMT):
I run this docker file https://github.com/hyperledger/indy-sdk/blob/master/libindy/ci/ubuntu.dockerfile and already setup the indy network I am getting error while executing the command Run integration tests: Start local nodes pool with Docker If you use this method then you have to specify the TEST_POOL_IP as specified below when running the tests. It can be useful if we want to launch integration tests inside another container attached to the same docker network. Run tests cd libindy RUST_TEST_THREADS=1 cargo test It is possible to change ip of test pool by providing of TEST_POOL_IP environment variable: RUST_TEST_THREADS=1 TEST_POOL_IP=10.0.0.2 cargo test Build indy-cli (Optional) indy-cli is dependent on libindy and should be built after it. cd cli/ RUSTFLAGS=" -L ../libindy/target/debug" cargo build If you have followed the instructions to build libindy above, the default build type will be debug Make sure to add the libindy to the path. Replace /path/to with the actual path to the libindy directory. Using bash: echo "export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/libindy/target/{BUILD TYPE}" >> ~/.bashrc sudo ldconfig source ~/.bashrc To run indy-cli, navigate to cli/target/debug and run ./indy-cli

cguerin (Mon, 22 Oct 2018 09:19:46 GMT):
Has joined the channel.

cguerin (Mon, 22 Oct 2018 09:30:06 GMT):
Hi, I've an error when i call indy.createPoolLedger method, my config is: { genesis_txn: '/home/indy/sandbox/pool_transactions_genesis' } The file exist, everything is looking good but i've the error 114: 'CommonIOError', i don't understand what is going wrong here. I use node.js SDK version, all is run inside a docker container and works well for others developers. Thanks for your time

gudkov (Mon, 22 Oct 2018 12:06:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=GwdZfZx3p4opNRn5S) @cguerin You need to enable logging. There will be enough information to understand the cause.

ShubhamSingh18 (Mon, 22 Oct 2018 12:12:34 GMT):
Getting error while running python samplesshubhamsingh@Shubham:~/indy-sdk-master/samples/python$ python3 -m src.main Traceback (most recent call last): File "/usr/lib/python3.5/runpy.py", line 193, in _run_module_as_main "__main__", mod_spec) File "/usr/lib/python3.5/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/shubhamsingh/indy-sdk-master/samples/python/src/main.py", line 3, in from src import anoncreds, anoncreds_revocation, crypto, ledger, getting_started File "/home/shubhamsingh/indy-sdk-master/samples/python/src/anoncreds.py", line 3, in from indy import anoncreds, wallet ImportError: cannot import name 'anoncreds'

cguerin (Mon, 22 Oct 2018 15:33:05 GMT):
@gudkov could you tell me how to enable logging(indy? system?) please?

gudkov (Mon, 22 Oct 2018 16:00:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Sk2DxfLza4KjAS8ps) @cguerin What version and programming language do you use? If stable than you need to add env variable RUST_LOG=indy=trace to get logs printed to stdout. For master version libindy uses logging facade specific for this programming language. Python logger or slf4j for java.

ShubhamSingh18 (Tue, 23 Oct 2018 07:47:53 GMT):
I am getting this error while running python sample indy@Shubham:~/samples/python/src$ python3 main.py Traceback (most recent call last): File "main.py", line 3, in from src import anoncreds, anoncreds_revocation, crypto, ledger, getting_started ImportError: No module named 'src'

ShubhamSingh18 (Tue, 23 Oct 2018 11:55:26 GMT):
How to solve this error please help while executing the python sample indy@Shubham:~/samples/python$ python3 -m src.main INFO:src.getting_started:Getting started -> started INFO:src.getting_started:Open Pool Ledger: pool1 ERROR:indy.libindy:_load_cdll: Can't load libindy: libindy.so: cannot open shared object file: No such file or directory Traceback (most recent call last): File "/usr/lib/python3.5/runpy.py", line 184, in _run_module_as_main "__main__", mod_spec) File "/usr/lib/python3.5/runpy.py", line 85, in _run_code exec(code, run_globals) File "/home/indy/samples/python/src/main.py", line 16, in run_coroutine(main) File "/home/indy/samples/python/src/utils.py", line 47, in run_coroutine loop.run_until_complete(coroutine()) File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception File "/usr/lib/python3.5/asyncio/tasks.py", line 239, in _step result = coro.send(None) File "/home/indy/samples/python/src/main.py", line 8, in main await getting_started.run() File "/home/indy/samples/python/src/getting_started.py", line 26, in run await pool.set_protocol_version(PROTOCOL_VERSION) File "/home/indy/.local/lib/python3.5/site-packages/indy/pool.py", line 208, in set_protocol_version delete_pool_ledger_config.cb) File "/home/indy/.local/lib/python3.5/site-packages/indy/libindy.py", line 24, in do_call err = getattr(_cdll(), name)(command_handle, File "/home/indy/.local/lib/python3.5/site-packages/indy/libindy.py", line 90, in _cdll _cdll.cdll = _load_cdll() File "/home/indy/.local/lib/python3.5/site-packages/indy/libindy.py", line 121, in _load_cdll raise e File "/home/indy/.local/lib/python3.5/site-packages/indy/libindy.py", line 116, in _load_cdll res = CDLL(libindy_name) File "/usr/lib/python3.5/ctypes/__init__.py", line 347, in _init_ self._handle = _dlopen(self._name, mode) OSError: libindy.so: cannot open shared object file: No such file or directory indy@Shubham:~/samples/python$

gudkov (Tue, 23 Oct 2018 13:14:56 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=H8dPmNuobmjgZXaZe) @ShubhamSingh18 You need to have libindy in your LD_PATH. You can build it or install it as a debian package.

louisk (Tue, 23 Oct 2018 13:17:08 GMT):
Has joined the channel.

ShubhamSingh18 (Tue, 23 Oct 2018 13:20:25 GMT):
@gudkov can you give me command

louisk (Tue, 23 Oct 2018 13:21:18 GMT):
@ShubhamSingh18 if you're on mac os: https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md

louisk (Tue, 23 Oct 2018 13:21:30 GMT):
otherwise in the same doc folder has other build instructions for libindy

louisk (Tue, 23 Oct 2018 13:21:36 GMT):
they include adding it to your path

ShubhamSingh18 (Tue, 23 Oct 2018 13:22:04 GMT):
Linux

louisk (Tue, 23 Oct 2018 13:22:39 GMT):
if you already built, you may just need to do something like `ln -s /PATH_TO_/indy-sdk/libindy/target/debug/libindy.dylib /usr/local/lib/` (this was from osx, so /user/local/lib may be different for you

louisk (Tue, 23 Oct 2018 13:22:57 GMT):
the .md in the indy-sdk repo will have the answer

ShubhamSingh18 (Tue, 23 Oct 2018 13:48:23 GMT):
@louisk i have libindy.so in usr/lib and usr/local/lib/

ShubhamSingh18 (Tue, 23 Oct 2018 13:49:24 GMT):
@louisk Then also this error is coming OSError: libindy.so: cannot open shared object file: No such file or directory

ShubhamSingh18 (Wed, 24 Oct 2018 04:54:51 GMT):
Do anyone have made demo in python or java

sergey.minaev (Wed, 24 Oct 2018 09:18:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kn34N6HfvcsCavCAJ) @wangdong it's system library, not indy-crypto not sure about MacOS, but for ubuntu - libcrypto is a part (or dependency) of libssl package AFAIR. Most probably you have to check system openssl libraries

superafro12 (Wed, 24 Oct 2018 11:22:18 GMT):
Hello! Can someone please explain this for me? Im following "Indy-SDK Getting-Started Guide" and something is wrong in "Step 4: Onboarding Faber, Acme, Thrift and Government by Steward". When you have created two DIDs used for interaction between steward and faber. Faber creates a new DID for Verinym, prepares a message with the new DID, decrypts it and sends it to steward. When steward decrypts the message he receives the new DID and also the verkey of the sender. In the guide they then use the did from the message to look up the verkey from the ledger with Did.keyForDid(). But, this did hasn't been published to the ledger yet. How is this working? And, even if the did was published to the ledger it won't return the same verkey as the sender's verkey. To sum up to make it a little easier to understand: Faber's new DID = { newDid, newKey }. Faber encrypts with senderKey (key from DID to interact with steward). Steward decrypts and gets the new DID as well as senderKey. Use newDid to lookup key with Did.keyForDid(newDiD). Receives newKey ofc. But, this key should be the same as the senderKey, which it's apparently not. What am I missing?? Thanks!

PhillipGibb (Wed, 24 Oct 2018 12:20:13 GMT):
I have setup a nodejs project and have: `export RUST_LOG=indy=trace` but no logging any ideas?

gudkov (Wed, 24 Oct 2018 13:38:58 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aEYSJTxJaix6zvff9) @PhillipGibb Do you use master or stable libindy?

PhillipGibb (Wed, 24 Oct 2018 13:39:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mBQ2XaoY3oPxsawqC) @gudkov master

gudkov (Wed, 24 Oct 2018 13:40:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Dnoztw6dbqaDDqxCA) @PhillipGibb For master it is better to wait a bit when this PR will be merged https://github.com/hyperledger/indy-sdk/pull/1152 It will expose set_default_logger to keep the same behaviour as in stable or allow your app to register custom logging handler

PhillipGibb (Wed, 24 Oct 2018 13:46:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=cwxSP7xkpMC3hCWMs) @gudkov cool, so I can use stable for now and the logging will be as before?

PhillipGibb (Wed, 24 Oct 2018 14:40:49 GMT):
I am looking up a did on STN : {"reqId":1540391887747806000,"identifier":"RbTrA8BX6gZdEW9LUyFQv7","operation":{"type":"120","dest":"V4SGRU86Z58d6TV7PBUe6f"},"protocolVersion":2} request: {"identifier":"RbTrA8BX6gZdEW9LUyFQv7","reqId":1540391887747806000,"reason":"client request invalid: InvalidClientRequest('invalid type: 120',)","op":"REQNACK"}

gudkov (Wed, 24 Oct 2018 15:28:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=7js4iZat5BhcBPuRy) @PhillipGibb Yes

mark.hadley (Wed, 24 Oct 2018 15:53:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=44xrTJExC26hiozck) @superafro12 `But, this did hasn't been published to the ledger yet` Yes, it seems that it in the 'Getting Verinym' subsection, on step 1, where this confusion is occurring, it is implied that since Faber has Trust Anchor privileges (From *Step 1: Getting Trust Anchor Credentials for Faber, Acme, Thrift and Government*) that the DID that Faber creates in this step needs to be also written to the ledger. As far as the second part of your question 'even if the did was published to the ledger it won't return the same verkey as the sender's verkey.' I'm in agreement, and I'm researching this. I'll get some more feedback soon.

mark.hadley (Wed, 24 Oct 2018 15:53:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=44xrTJExC26hiozck) @superafro12 `But, this did hasn't been published to the ledger yet` ~Yes, it seems that it in the 'Getting Verinym' subsection, on step 1, where this confusion is occurring, it is implied that since Faber has Trust Anchor privileges (From *Step 1: Getting Trust Anchor Credentials for Faber, Acme, Thrift and Government*) that the DID that Faber creates in this step needs to be also written to the ledger. As far as the second part of your question 'even if the did was published to the ledger it won't return the same verkey as the sender's verkey.' I'm in agreement, and I'm researching this. ~ I'll get some more feedback soon.

mark.hadley (Wed, 24 Oct 2018 15:53:42 GMT):
@superafro12 I'll get some more feedback soon.

mark.hadley (Wed, 24 Oct 2018 15:53:42 GMT):
@superafro12 I'll get some more feedback soon, I understand your questions and I'm working to see how we can clear up the confusion.

mark.hadley (Wed, 24 Oct 2018 15:53:42 GMT):
@superafro12 I'll get some more feedback soon, I understand your questions and I'm working to see how we can clear up the confusion. I think there's a typo in the python example code: ``` # Steward Agent faber_verkey = await did.key_for_did(pool_handle, from_wallet, ~faber_did_info['did'])~ steward_faber_did ```

mark.hadley (Wed, 24 Oct 2018 15:53:42 GMT):
@superafro12 I'll get some more feedback soon, I understand your questions and I'm working to see how we can clear up the confusion. I think there's a typo in the python example code: ``` faber_verkey = await did.key_for_did(pool_handle, from_wallet, faber_did_info['did']) ``` Should instead be ``` faber_verkey = await did.key_for_did(pool_handle, from_wallet, steward_faber_did) ```

mark.hadley (Wed, 24 Oct 2018 15:53:42 GMT):
@superafro12 I'll get some more feedback soon, I understand your questions and I'm working to see how we can clear up the confusion. So after looking through it some more, I think there's a typo in the python example code: ``` faber_verkey = await did.key_for_did(pool_handle, from_wallet, faber_did_info['did']) ``` Should instead be ``` faber_verkey = await did.key_for_did(pool_handle, from_wallet, steward_faber_did) ```

mark.hadley (Wed, 24 Oct 2018 17:13:23 GMT):
@superafro12 Feel free to add any changes along with my branch that I've started. https://github.com/hadleym/indy-sdk/tree/Refactor-Getting-Started-Guide-Mark1

smithbk (Wed, 24 Oct 2018 18:22:25 GMT):
Can someone tell me what is wrong with my proof request? I don't see anything obvious. ```2018-10-24 18:00:19,286 DEBUG prover_get_credentials_for_proof_req: >>> wallet_handle: 25, proof_request_json: '{"version": "1.0", "requested_predicates": {"predicate1_referent": {"name": "average", "restrictions": [{"cred_def_id": "F3ZApwKegqXa2pVSrsXNkP:3:CL:20:TAG1"}], "p_type": ">=", "p_value": 4}}, "id": "Job-Application:1.0", "name": "Job-Application", "requested_attributes": {"last_name_referent": {"name": "last_name"}, "phone_number_referent": {"name": "phone_number"}, "status_referent": {"restrictions": [{"cred_def_id": "F3ZApwKegqXa2pVSrsXNkP:3:CL:20:TAG1"}], "name": "status"}, "first_name_referent": {"name": "first_name"}, "ssn_referent": {"restrictions": [{"cred_def_id": "F3ZApwKegqXa2pVSrsXNkP:3:CL:20:TAG1"}], "name": "ssn"}, "degree_referent": {"restrictions": [{"schema_key": {"version": "1.1", "name": "Transcript"}}], "name": "degree"}}, "nonce": "DrjYM4TezBJQFLw5c2JWwK5D"}' 2018-10-24 18:00:19,286 DEBUG prover_get_credentials_for_proof_req: Creating callback 2018-10-24 18:00:19,286 DEBUG create_cb: >>> cb_type: .CFunctionType'> 2018-10-24 18:00:19,287 DEBUG create_cb: <<< res: 2018-10-24 18:00:19,287 DEBUG do_call: >>> name: indy_prover_get_credentials_for_proof_req, args: (c_int(25), c_char_p(140336378770032), ) TRACE|indy::api::anoncreds | src/api/anoncreds.rs:941 | indy_prover_get_credentials_for_proof_req: >>> wallet_handle: 25, proof_request_json: 0x7fa29c017270 TRACE|indy::api::anoncreds | src/api/anoncreds.rs:946 | indy_prover_get_credentials_for_proof_req: entities >>> wallet_handle: 25, proof_request_json: "{\"version\": \"1.0\", \"requested_predicates\": {\"predicate1_referent\": {\"name\": \"average\", \"restrictions\": [{\"cred_def_id\": \"F3ZApwKegqXa2pVSrsXNkP:3:CL:20:TAG1\"}], \"p_type\": \">=\", \"p_value\": 4}}, \"id\": \"Job-Application:1.0\", \"name\": \"Job-Application\", \"requested_attributes\": {\"last_name_referent\": {\"name\": \"last_name\"}, \"phone_number_referent\": {\"name\": \"phone_number\"}, \"status_referent\": {\"restrictions\": [{\"cred_def_id\": \"F3ZApwKegqXa2pVSrsXNkP:3:CL:20:TAG1\"}], \"name\": \"status\"}, \"first_name_referent\": {\"name\": \"first_name\"}, \"ssn_referent\": {\"restrictions\": [{\"cred_def_id\": \"F3ZApwKegqXa2pVSrsXNkP:3:CL:20:TAG1\"}], \"name\": \"ssn\"}, \"degree_referent\": {\"restrictions\": [{\"schema_key\": {\"version\": \"1.1\", \"name\": \"Transcript\"}}], \"name\": \"degree\"}}, \"nonce\": \"DrjYM4TezBJQFLw5c2JWwK5D\"}" TRACE|indy::api::anoncreds | src/api/anoncreds.rs:964 | indy_prover_get_credentials_for_proof_req: <<< res: Success INFO|indy::commands | src/commands/mod.rs:102 | AnoncredsCommand command received DEBUG|indy::commands::anoncreds::prover| src/commands/anoncreds/prover.rs:339 | get_credentials_for_proof_req >>> wallet_handle: 25, proof_req_json: "{\"version\": \"1.0\", \"requested_predicates\": {\"predicate1_referent\": {\"name\": \"average\", \"restrictions\": [{\"cred_def_id\": \"F3ZApwKegqXa2pVSrsXNkP:3:CL:20:TAG1\"}], \"p_type\": \">=\", \"p_value\": 4}}, \"id\": \"Job-Application:1.0\", \"name\": \"Job-Application\", \"requested_attributes\": {\"last_name_referent\": {\"name\": \"last_name\"}, \"phone_number_referent\": {\"name\": \"phone_number\"}, \"status_referent\": {\"restrictions\": [{\"cred_def_id\": \"F3ZApwKegqXa2pVSrsXNkP:3:CL:20:TAG1\"}], \"name\": \"status\"}, \"first_name_referent\": {\"name\": \"first_name\"}, \"ssn_referent\": {\"restrictions\": [{\"cred_def_id\": \"F3ZApwKegqXa2pVSrsXNkP:3:CL:20:TAG1\"}], \"name\": \"ssn\"}, \"degree_referent\": {\"restrictions\": [{\"schema_key\": {\"version\": \"1.1\", \"name\": \"Transcript\"}}], \"name\": \"degree\"}}, \"nonce\": \"DrjYM4TezBJQFLw5c2JWwK5D\"}" 2018-10-24 18:00:19,288 DEBUG do_call: Function indy_prover_get_credentials_for_proof_req returned err: 0 ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid structure: Cannot deserialize ProofRequest: InvalidStructure("Invalid structure: An OpenSSL error stack at line 1 column 788") ```

smithbk (Wed, 24 Oct 2018 18:22:25 GMT):
Can someone tell me what is wrong with my proof request, or what else may be causing this? I don't see anything obvious. ```2018-10-24 18:00:19,286 DEBUG prover_get_credentials_for_proof_req: >>> wallet_handle: 25, proof_request_json: '{"version": "1.0", "requested_predicates": {"predicate1_referent": {"name": "average", "restrictions": [{"cred_def_id": "F3ZApwKegqXa2pVSrsXNkP:3:CL:20:TAG1"}], "p_type": ">=", "p_value": 4}}, "id": "Job-Application:1.0", "name": "Job-Application", "requested_attributes": {"last_name_referent": {"name": "last_name"}, "phone_number_referent": {"name": "phone_number"}, "status_referent": {"restrictions": [{"cred_def_id": "F3ZApwKegqXa2pVSrsXNkP:3:CL:20:TAG1"}], "name": "status"}, "first_name_referent": {"name": "first_name"}, "ssn_referent": {"restrictions": [{"cred_def_id": "F3ZApwKegqXa2pVSrsXNkP:3:CL:20:TAG1"}], "name": "ssn"}, "degree_referent": {"restrictions": [{"schema_key": {"version": "1.1", "name": "Transcript"}}], "name": "degree"}}, "nonce": "DrjYM4TezBJQFLw5c2JWwK5D"}' 2018-10-24 18:00:19,286 DEBUG prover_get_credentials_for_proof_req: Creating callback 2018-10-24 18:00:19,286 DEBUG create_cb: >>> cb_type: .CFunctionType'> 2018-10-24 18:00:19,287 DEBUG create_cb: <<< res: 2018-10-24 18:00:19,287 DEBUG do_call: >>> name: indy_prover_get_credentials_for_proof_req, args: (c_int(25), c_char_p(140336378770032), ) TRACE|indy::api::anoncreds | src/api/anoncreds.rs:941 | indy_prover_get_credentials_for_proof_req: >>> wallet_handle: 25, proof_request_json: 0x7fa29c017270 TRACE|indy::api::anoncreds | src/api/anoncreds.rs:946 | indy_prover_get_credentials_for_proof_req: entities >>> wallet_handle: 25, proof_request_json: "{\"version\": \"1.0\", \"requested_predicates\": {\"predicate1_referent\": {\"name\": \"average\", \"restrictions\": [{\"cred_def_id\": \"F3ZApwKegqXa2pVSrsXNkP:3:CL:20:TAG1\"}], \"p_type\": \">=\", \"p_value\": 4}}, \"id\": \"Job-Application:1.0\", \"name\": \"Job-Application\", \"requested_attributes\": {\"last_name_referent\": {\"name\": \"last_name\"}, \"phone_number_referent\": {\"name\": \"phone_number\"}, \"status_referent\": {\"restrictions\": [{\"cred_def_id\": \"F3ZApwKegqXa2pVSrsXNkP:3:CL:20:TAG1\"}], \"name\": \"status\"}, \"first_name_referent\": {\"name\": \"first_name\"}, \"ssn_referent\": {\"restrictions\": [{\"cred_def_id\": \"F3ZApwKegqXa2pVSrsXNkP:3:CL:20:TAG1\"}], \"name\": \"ssn\"}, \"degree_referent\": {\"restrictions\": [{\"schema_key\": {\"version\": \"1.1\", \"name\": \"Transcript\"}}], \"name\": \"degree\"}}, \"nonce\": \"DrjYM4TezBJQFLw5c2JWwK5D\"}" TRACE|indy::api::anoncreds | src/api/anoncreds.rs:964 | indy_prover_get_credentials_for_proof_req: <<< res: Success INFO|indy::commands | src/commands/mod.rs:102 | AnoncredsCommand command received DEBUG|indy::commands::anoncreds::prover| src/commands/anoncreds/prover.rs:339 | get_credentials_for_proof_req >>> wallet_handle: 25, proof_req_json: "{\"version\": \"1.0\", \"requested_predicates\": {\"predicate1_referent\": {\"name\": \"average\", \"restrictions\": [{\"cred_def_id\": \"F3ZApwKegqXa2pVSrsXNkP:3:CL:20:TAG1\"}], \"p_type\": \">=\", \"p_value\": 4}}, \"id\": \"Job-Application:1.0\", \"name\": \"Job-Application\", \"requested_attributes\": {\"last_name_referent\": {\"name\": \"last_name\"}, \"phone_number_referent\": {\"name\": \"phone_number\"}, \"status_referent\": {\"restrictions\": [{\"cred_def_id\": \"F3ZApwKegqXa2pVSrsXNkP:3:CL:20:TAG1\"}], \"name\": \"status\"}, \"first_name_referent\": {\"name\": \"first_name\"}, \"ssn_referent\": {\"restrictions\": [{\"cred_def_id\": \"F3ZApwKegqXa2pVSrsXNkP:3:CL:20:TAG1\"}], \"name\": \"ssn\"}, \"degree_referent\": {\"restrictions\": [{\"schema_key\": {\"version\": \"1.1\", \"name\": \"Transcript\"}}], \"name\": \"degree\"}}, \"nonce\": \"DrjYM4TezBJQFLw5c2JWwK5D\"}" 2018-10-24 18:00:19,288 DEBUG do_call: Function indy_prover_get_credentials_for_proof_req returned err: 0 ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid structure: Cannot deserialize ProofRequest: InvalidStructure("Invalid structure: An OpenSSL error stack at line 1 column 788") ```

mark.hadley (Wed, 24 Oct 2018 18:39:36 GMT):
I saw this recently when I had mis-matched attribute lists (the attr list for the cred offer was not the same as the attr list of the cred request). Do you have the cred offer?

smithbk (Wed, 24 Oct 2018 18:51:33 GMT):
This is happening in the verification flow when trying to create a proof given a proof request, and I thought it was happening when just trying to deserialize the proof request string but hadn't started trying to match the requested attributes in the proof request to previously issued credentials. I can paste my cred request or offer or the previously issued cred, but wanted to make sure you weren't thinking this was an error from the issuance flow rather than from the verification flow.

smithbk (Wed, 24 Oct 2018 18:51:33 GMT):
@mark.hadley This is happening in the verification flow when trying to create a proof given a proof request, and I thought it was happening when just trying to deserialize the proof request string but hadn't started trying to match the requested attributes in the proof request to previously issued credentials. I can paste my cred request or offer or the previously issued cred, but wanted to make sure you weren't thinking this was an error from the issuance flow rather than from the verification flow.

mark.hadley (Wed, 24 Oct 2018 18:58:41 GMT):
You dont have to paste, its just a quick sanity check you could do that the `cred offer` attribute list and `cred request` attribute list are the same. I just happen to have made that mistake earlier today, so its fresh in my mind of a place I tripped up.

mark.hadley (Wed, 24 Oct 2018 19:01:43 GMT):
Yeah, I dont think my input is very helpful, looking at it now.

mark.hadley (Wed, 24 Oct 2018 19:03:22 GMT):
(but *maybe* check the proof offer?)

mark.hadley (Wed, 24 Oct 2018 19:03:22 GMT):
~(but *maybe* check the proof offer?)~

mark.hadley (Wed, 24 Oct 2018 19:06:07 GMT):
(i've had too much coffee today and not making sense)

smithbk (Wed, 24 Oct 2018 19:08:26 GMT):
thanks anyway ... btw, I'm using libindy 1.5. I'm now trying to upgrade to the latest in master of indy-sdk to see if it makes a difference, but it seems the wallet APIs have changed so is taking longer to try. Anyway, I would appreciate it if someone could help as the "An OpenSSL error stack" error is confusing to me

mark.hadley (Wed, 24 Oct 2018 19:15:04 GMT):
Yeah, if you get up to 1.6.7 (master) it will be easier to assist. (Hopefully the wallet api changes aren't too bad for you, just mostly condensed parameters iirc. We used https://github.com/hyperledger/indy-sdk/blob/v1.6.0/doc/migration-guide-1.5.0-1.6.0.md#wallet-api when we were refactoring)

smithbk (Wed, 24 Oct 2018 19:33:44 GMT):
@mark.hadley thanks, i'm getting the same error with master. What else can I provide or do?

mark.hadley (Wed, 24 Oct 2018 19:42:50 GMT):
Is it still the `InvalidStructure("InvalidStructure: An OpenSSL ...)`?

smithbk (Wed, 24 Oct 2018 19:44:14 GMT):
yes, it looks the same to me but here is the latest: ```2018-10-24 19:31:51,276 DEBUG Using selector: EpollSelector 2018-10-24 19:31:51,276 DEBUG prover_get_credentials_for_proof_req: >>> wallet_handle: 28, proof_request_json: '{"requested_predicates": {"predicate1_referent": {"p_type": ">=", "name": "average", "restrictions": [{"cred_def_id": "U4YKBjmiRnKpBqxCkARJyo:3:CL:20:TAG1"}], "p_value": 4}}, "version": "1.0", "nonce": "dXggx55BSc0VlY3gSh6WXcnC", "name": "Job-Application", "id": "Job-Application:1.0", "requested_attributes": {"status_referent": {"name": "status", "restrictions": [{"cred_def_id": "U4YKBjmiRnKpBqxCkARJyo:3:CL:20:TAG1"}]}, "phone_number_referent": {"name": "phone_number"}, "ssn_referent": {"name": "ssn", "restrictions": [{"cred_def_id": "U4YKBjmiRnKpBqxCkARJyo:3:CL:20:TAG1"}]}, "first_name_referent": {"name": "first_name"}, "last_name_referent": {"name": "last_name"}, "degree_referent": {"name": "degree", "restrictions": [{"schema_key": {"version": "1.1", "name": "Transcript"}}]}}}' 2018-10-24 19:31:51,276 DEBUG prover_get_credentials_for_proof_req: Creating callback 2018-10-24 19:31:51,277 DEBUG create_cb: >>> cb_type: .CFunctionType'> 2018-10-24 19:31:51,277 DEBUG create_cb: <<< res: 2018-10-24 19:31:51,277 DEBUG do_call: >>> name: indy_prover_get_credentials_for_proof_req, args: (c_int(28), c_char_p(140649576172320), ) TRACE|indy::api::anoncreds | src/api/anoncreds.rs:1186| indy_prover_get_credentials_for_proof_req: >>> wallet_handle: 28, proof_request_json: 0x7feb88068b20 TRACE|indy::api::anoncreds | src/api/anoncreds.rs:1188| Invalid structure: An OpenSSL error stack at line 1 column 228 2018-10-24 19:31:51,278 DEBUG do_call: Function indy_prover_get_credentials_for_proof_req returned err: 113 2018-10-24 19:31:51,278 WARNING _do_call: Function indy_prover_get_credentials_for_proof_req returned error 113 2018-10-24 19:31:51,278 DEBUG do_call: <<< ,)>```

smithbk (Wed, 24 Oct 2018 19:50:01 GMT):
I see this in the comments in anoncreds.rs? ```/// NOTE: This method is deprecated because immediately returns all fetched credentials. /// Use to fetch records by small batches.```

mark.hadley (Wed, 24 Oct 2018 20:07:50 GMT):
The flow is now (python): -`prover_search_credentials_for_proof_req` which returns a search handle (passing the proof req. json). -`prover_fetch_credentials_for_proof_req` passing the search handle and the number of hits you want, and the 'referent' (ie "ssn_referent") from your proof request. You can do this multiple times if your referents were in different credentials. But if everything is in one credential, then you only have to do this once (not 100% on that part). This test shows the flow in the rust code: https://github.com/hyperledger/indy-sdk/blob/8157226e34ac06913fdfaa9bcee42c7573bff41a/libindy/tests/anoncreds.rs#L2482 Looks like we need to update the python wrapper documentation.

mark.hadley (Wed, 24 Oct 2018 20:07:50 GMT):
The flow is now (python): -`prover_search_credentials_for_proof_req` which returns a search handle (passing the proof req. json). -```prover_fetch_credentials_for_proof_req``` passing the search handle and the number of hits you want, and the 'referent' (ie "ssn_referent") from your proof request. You can do this multiple times if your referents were in different credentials. But if everything is in one credential, then you only have to do this once (not 100% on that part). This test shows the flow in the rust code: https://github.com/hyperledger/indy-sdk/blob/8157226e34ac06913fdfaa9bcee42c7573bff41a/libindy/tests/anoncreds.rs#L2482 Looks like we need to update the python wrapper documentation.

mark.hadley (Wed, 24 Oct 2018 20:07:50 GMT):
The flow is now (python): -`prover_search_credentials_for_proof_req` which returns a search handle (passing the proof req. json). -`prover_fetch_credentials_for_proof_req` passing the search handle and the number of hits you want, and the 'referent' (ie "ssn_referent") from your proof request. You can do this multiple times if your referents were in different credentials. But if everything is in one credential, then you only have to do this once (not 100% on that part). - and then close the search handle with `prover_close_credentials_search_for_proof_req` This test shows the flow in the rust code: https://github.com/hyperledger/indy-sdk/blob/8157226e34ac06913fdfaa9bcee42c7573bff41a/libindy/tests/anoncreds.rs#L2482 Looks like we need to update the python wrapper documentation.

mark.hadley (Wed, 24 Oct 2018 20:07:50 GMT):
The flow is now (python): -`prover_search_credentials_for_proof_req` which returns a search handle (passing the proof req. json). -`prover_fetch_credentials_for_proof_req` passing the search handle and the number of hits you want, and the 'referent' (ie "ssn_referent") from your proof request. You can do this multiple times if your referents were in different credentials. But if everything is in one credential, then you only have to do this once (not 100% on that part). - and then close the search handle with `prover_close_credentials_search_for_proof_req` This test shows the flow in the rust code: https://github.com/hyperledger/indy-sdk/blob/8157226e34ac06913fdfaa9bcee42c7573bff41a/libindy/tests/anoncreds.rs#L2482 ~Looks like we need to update the python wrapper documentation.~

smithbk (Wed, 24 Oct 2018 20:09:21 GMT):
yes, i see i need to update since it is deprecated, but not sure that is the issue as they are still supported, right?

smithbk (Wed, 24 Oct 2018 20:10:40 GMT):
i think it will still fail to parse the proof request if I'm looking at code correctly

mark.hadley (Wed, 24 Oct 2018 20:16:13 GMT):
Yeah, I think you're right.

smithbk (Wed, 24 Oct 2018 20:20:35 GMT):
based on the column number in each of the previous errors, it appears to be objecting to the "nonce" field

smithbk (Wed, 24 Oct 2018 20:22:02 GMT):
in proof_request.rs, I see ```pub struct ProofRequest { pub nonce: Nonce,```

mark.hadley (Wed, 24 Oct 2018 20:25:47 GMT):
I think your nonce has to be an integer

smithbk (Wed, 24 Oct 2018 20:26:14 GMT):
Has that changed?

smithbk (Wed, 24 Oct 2018 20:34:11 GMT):
ah ... yes, our nonce function changed. They both return strings but the previous version was a string which could be converted to an int ```-def nonce() -> str: - return str(int(time() * 1000)) +def nonce(N=24) -> str: + return ''.join(random.choice(string.ascii_uppercase + string.ascii_lowercase + string.digits) for _ in range(N))```

smithbk (Wed, 24 Oct 2018 20:35:03 GMT):
So apparently it doesn't accept a generic string for nonce

thPart (Thu, 25 Oct 2018 07:17:53 GMT):
Hi, I am trying to find out best strategy to test our Indy network. It looks like that even if I shutting down all of the 4 nodes I have the network still responding while sending tx in the ledger (NYM and so on)... any help on how I can build a proper testing script with consistent results?

ShubhamSingh18 (Thu, 25 Oct 2018 08:18:21 GMT):
Where the ledger detail and wallet detail can be seen in local machine after running the nodejs demo

PhillipGibb (Thu, 25 Oct 2018 09:41:32 GMT):
I am trying to pull schemas from the ledger

PhillipGibb (Thu, 25 Oct 2018 09:45:38 GMT):
Hi, I am trying to pull schemas and credential definitions from the STN ledger. I have ledger a few using a DID, but I want to query them. Branch: 1.6.x Seems that the sdk call: `buildGetAttribRequest ( submitterDid, targetDid, hash, raw, enc ) -> request` should be: `buildGetAttribRequest ( submitterDid, targetDid, raw, hash, enc ) -> request` i.e. hash and and raw switched around. also one of those (raw, hash, enc) needs to be used. But what do I use? 'schema' or 'schemas' just return data: null

ShubhamSingh18 (Thu, 25 Oct 2018 11:01:35 GMT):
What can be developed by using indy by using indy sdk code

ShubhamSingh18 (Thu, 25 Oct 2018 11:01:51 GMT):
By current status

ianco (Thu, 25 Oct 2018 16:34:38 GMT):
Hi folks, just curious if anyone has developed a wallet storage plug-in, according to the latest design for the indy-sdk (https://github.com/hyperledger/indy-sdk/tree/master/doc/design/003-wallet-storage). I've developed a plug-in for Postgres (it's in an open PR right now), and would be interested in discussing my experiences, and getting pointers from anyone else who has been down this road ...

PhillipGibb (Thu, 25 Oct 2018 19:10:11 GMT):
Good evening from South Africa :) I am pulling a credential definition from the ledger and I am not sure what to do with it. It has rctxt, master_secret, n,r,z and I am not sure what those mean. is there a place that provides an easy decription of these? thanks

smithbk (Thu, 25 Oct 2018 19:43:21 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md#step-1-getting-trust-anchor-credentials-for-faber-acme-thrift-and-government says `Becoming a Trust Anchor requires contacting a person or organization who already has the Trust Anchor role on the ledger.`, but https://docs.google.com/spreadsheets/d/1TWXF7NtBjSOaUIBeIH77SyZnawfo91cJ_ns4TR-wsq4/edit#gid=0 says a trust anchor can not add a trust anchor (i.e. must be at least a steward). Which one is true? And are there any plans to change it? I "think" the later is currently true unless it has changed.

PhillipGibb (Fri, 26 Oct 2018 08:19:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ZTAkjT3Grsc8rLgwq) @smithbk As far as I understand: a Trust Anchor can ledger identities (not that you should) onto the ledger but not with the role of Trust Anchor - for that you need to be a trustee or steward

ShubhamSingh18 (Fri, 26 Oct 2018 12:11:32 GMT):
Wallet will be stored in the file {path}/{id}/sqlite.db means

ShubhamSingh18 (Fri, 26 Oct 2018 12:11:32 GMT):
Defaults to $HOME/.indy_client/wallet. Wallet will be stored in the file {path}/{id}/sqlite.db means

ShubhamSingh18 (Fri, 26 Oct 2018 12:11:44 GMT):
what is path and id here

ShubhamSingh18 (Fri, 26 Oct 2018 12:11:44 GMT):
how to find the id (Identifier of the wallet)

mhailstone (Fri, 26 Oct 2018 13:52:47 GMT):
The agent call will begin in 10 minutes: https://byu.zoom.us/j/2627891784

sklump (Fri, 26 Oct 2018 17:12:27 GMT):
*Folks!* Trouble with indy-sdk and multithreading. I have two threads, one to create a revocation registry and another to do anything else. Unfortunately, as soon as ``` await anoncreds.issuer_create_and_store_revoc_reg(...) ``` starts, all other threads wait until it's done. I thought indy-sdk was thread safe. Is that not the case? Or am I doing it wrong? This is a very expensive operation. I would appreciate any advice the indy crew would have to run this task concurrently or at least in parallel. I can't have the world block for potentially minutes for this task.

sklump (Fri, 26 Oct 2018 17:12:27 GMT):
*Folks!* Trouble with indy-sdk and multithreading. I have two threads, one to create a revocation registry and another to do anything else. Unfortunately, as soon as ``` await anoncreds.issuer_create_and_store_revoc_reg(...) ``` starts, all other threads wait until it's done - even though they have their own event loops. This is a very expensive operation. I would appreciate any advice the indy crew would have to run this task concurrently or at least in parallel. I can't have the world block for potentially minutes for this task.

sklump (Fri, 26 Oct 2018 17:12:27 GMT):
*Folks!* Trouble with indy-sdk and multithreading. I have two threads, one to create a revocation registry and another that's trying to sign and submit a totally independent ledger request. Unfortunately, as soon as ``` await anoncreds.issuer_create_and_store_revoc_reg(...) ``` starts, all other threads using indy-sdk wait until it's done - even though they have their own event loops. This is a very expensive operation. I would appreciate any advice the indy crew would have to run this task concurrently or at least in parallel. I can't have the world block for potentially minutes for this task.

sklump (Fri, 26 Oct 2018 17:12:27 GMT):
*Folks!* Trouble with indy-sdk and multithreading. I have two threads, one to create a revocation registry and another that's trying to sign and submit a totally independent ledger request. Unfortunately, as soon as ``` await anoncreds.issuer_create_and_store_revoc_reg(...) ``` starts, all other threads using indy-sdk wait until it's done - even though they have their own event loops. This is a very expensive operation. I would appreciate any advice the indy crew might have make this task not block, if possible. I can't have the world stop for potentially minutes to do this.

sklump (Fri, 26 Oct 2018 17:12:27 GMT):
*Folks!* Trouble with indy-sdk and multithreading. I have two threads, one to create a revocation registry and another that's trying to sign and submit a totally independent ledger request. Unfortunately, as soon as ``` await anoncreds.issuer_create_and_store_revoc_reg(...) ``` starts, all other threads using indy-sdk wait until it's done - even though they have their own event loops. This is a very expensive operation. I would appreciate any advice the indy crew might have to make this task not block, if possible. I can't have the world stop for potentially minutes to do this.

daveryIBM (Fri, 26 Oct 2018 19:57:48 GMT):
Has joined the channel.

daveryIBM (Fri, 26 Oct 2018 20:05:31 GMT):
What's the best way to implement "alternative credentials" in a proof request? Say I had users with a Canadian ID, and users with a US ID. The Canadian IDs have a `province` attribute, while the US IDs have a `state` attribute. I'd like to be able to accept either credential in my proof request to the user. My understanding is that asking for `state` in the proof request will disqualify the Canadian IDs and prevent the canadian users from being able to fulfill the proof request. Is there a concept of an OR between attributes in an indy proof request? Is there an alternative approach I should consider?

mgbailey (Fri, 26 Oct 2018 20:07:40 GMT):
@sklump The default wallet database is sqlite, which is not multi-thread compatible. It is possible to set up a different database connector, but I fear that you are heading off into untested territory in multi-threading. Actually I want you to figure this out, and tell the rest of us about it!

daveryIBM (Fri, 26 Oct 2018 20:29:04 GMT):
I suppose prefiltering users with a question like "Which country are you from?" and sending specific proof requests for each country based on their answer would be the simplest approach. I thought I'd check to see if there was a way to avoid this friction though.

mgbailey (Fri, 26 Oct 2018 20:30:50 GMT):
Related to the question of @daveryIBM , do we have the ability to have non-required attributes in a proof request? Could we make both state and province optional, and not fail the proof if one is not provided?

dbluhm (Fri, 26 Oct 2018 20:35:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=8732ZNeRqMgEEku6w) @daveryIBM I believe this touches on one of the use cases for overlays but I may be mistaken. Paul Knowles (@pknowles on sovrin slack) is the leader of the overlays WG

dbluhm (Fri, 26 Oct 2018 20:36:21 GMT):
He might be the one to reach out to

daveryIBM (Fri, 26 Oct 2018 20:38:55 GMT):
@dbluhm thanks for the tip. I'll reach out to him

swcurran (Sat, 27 Oct 2018 01:31:07 GMT):
@daveryIBM - overlays probably won't help you here. They would allow you to suggest to the agent to display different prompts ("Prov" vs. "State"), but the underlying schema would be the same. So if the Canadian Credenital has a different underlying schema than the American one (your assumption above), then Overlays won't help. If the schema are the same in Canada and the US, an overlay can localize the presentation. Indy provides a couple of techniques. First, a Proof Request can indicate that a claim can come from one of a number sources - different schema, or different Credential Definition (Issuer+schema). This allows you to say the claims can be satisifed from a US-used schema OR from a Canadian-used schema. Second, Indy has the concept of a "Proof Offer" that a Holder can use to say "Hey, I can offer you this type of Credential, wll that work?" so that the Verifier can adjust their Proof Request to ask for that Credential schema+issuer. As always, the Verifier would have to know/figure out who issued the claim and whether the Verifier trusts claims issued by the Issuer.

swcurran (Sat, 27 Oct 2018 01:31:07 GMT):
@daveryIBM - overlays probably won't help you here. They would allow you to suggest to the agent to display different prompts ("Prov" vs. "State"), but the underlying schema would have to be the same. So if the Canadian Credenital has a different underlying schema than the American one (your assumption above), then Overlays won't help. If the schema are the same in Canada and the US, an overlay can localize the presentation. Indy provides a couple of techniques. First, a Proof Request can indicate that a claim can come from one of a number sources - different schema, or different Credential Definition (Issuer+schema). This allows you to say the claims can be satisifed from a US-used schema OR from a Canadian-used schema. Second, Indy has the concept of a "Proof Offer" that a Holder can use to say "Hey, I can offer you this type of Credential, wll that work?" so that the Verifier can adjust their Proof Request to ask for that Credential schema+issuer. As always, the Verifier would have to know/figure out who issued the claim and whether the Verifier trusts claims issued by the Issuer.

ShubhamSingh18 (Sat, 27 Oct 2018 11:57:33 GMT):
Can anyone me provide the architecture of indy

ShubhamSingh18 (Sat, 27 Oct 2018 11:57:44 GMT):
architecture component

VaibhavSharma (Sun, 28 Oct 2018 13:52:35 GMT):
Has joined the channel.

VaibhavSharma (Sun, 28 Oct 2018 13:54:54 GMT):
While building a credential definition using anoncreds this is json that is built :- {"reqId":1540752567839327461,"identifier":"G2qBsja7kWNwVTBBZiz7pG","operation":{"ref":0,"data":{"primary":{"n":"9825696685902......} can anyone tell me what does "ref" refers to and why it should be greater than 0?

ShubhamSingh18 (Mon, 29 Oct 2018 07:14:00 GMT):
Can anyone tell me the architecture of hyperledger indy and how the components are connected to each other

ShubhamSingh18 (Mon, 29 Oct 2018 07:18:38 GMT):
if any diagram please give

manishcm (Mon, 29 Oct 2018 09:24:34 GMT):
Has joined the channel.

sklump (Mon, 29 Oct 2018 12:04:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=dHeTZ7oyRmF7sHhtd) @mgbailey I've also tried to generate tails files in a separate process, but the indy-sdk then blocks on ``` await blog_storage.open_writer(...) ``` which is puzzling. This is just trying to open a file as far as I can see, and should not care that another process is also running the indy-sdk, which links as a *SHARED* library. It puts the lie to the `s` in `.so`. This call doesn't even need a wallet handle. Is it possible to build indy-sdk as a static-link library, then rewrite my own indy/libindy.py in a new wrapper? Gosh. I could use any ideas here. I'm pretty close to tapped out. What I want to do is precompute tails files for when I will need them, without throwing the indy-sdk into vapour lock for minutes at a time; * asyncio: nope (of course: green threads don't propagate through to the rust layer) * multithreading: nope (wallet design: not multithreaded) * multiprocessing: nope (tails writer can only open in first process to grab the library?) Next up, building out a separate docker box with .indy_client mapped and seeing if that corrupts stuff. But this approach seem like design overkill for such a humble feature. I don't think I can go to a purely separate OS installation for this because the revocation registry creator wallet has to have the same private keys as the cred def issuer (OK by DID, but thena single routine key rotation will blow this contrivance up).

sklump (Mon, 29 Oct 2018 12:04:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=dHeTZ7oyRmF7sHhtd) @mgbailey I've also tried to generate tails files in a separate process, but the indy-sdk then blocks on ``` await blog_storage.open_writer(...) ``` which is puzzling. This is just trying to open a file as far as I can see, and should not care that another process is also running the indy-sdk, which links as a *SHARED* library. It puts the lie to the `s` in `.so`. This call doesn't even need a wallet handle. Is it possible to build indy-sdk as a static-link library, then rewrite my own indy/libindy.py in a new wrapper? Gosh. I could use any ideas here. I'm pretty close to tapped out. What I want to do is precompute tails files for when I will need them, without throwing the indy-sdk into vapour lock for minutes at a time; * asyncio: nope (of course: green threads don't propagate through to the rust layer) * multithreading: nope (wallet design: not multithreaded) * multiprocessing: nope (tails writer can only open in first process to grab the library?) Next up, building out a separate docker box with a RESTful service and `~/.indy_client` mapped, and seeing if that corrupts stuff. But this approach seem like design overkill for such a humble feature. I don't think I can go to a purely separate OS installation for this because the revocation registry creator wallet has to have the same private keys as the cred def issuer (OK by DID, but thena single routine key rotation will blow this contrivance up).

sklump (Mon, 29 Oct 2018 12:04:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=dHeTZ7oyRmF7sHhtd) @mgbailey I've also tried to generate tails files in a separate process, but the indy-sdk then blocks on ``` await blog_storage.open_writer(...) ``` which is puzzling. This is just trying to open a file as far as I can see, and should not care that another process is also running the indy-sdk, which links as a *SHARED* library. It puts the lie to the `s` in `.so`. This call doesn't even need a wallet handle. Is it possible to build indy-sdk as a static-link library, then rewrite my own indy/libindy.py in a new wrapper? Gosh. I could use any ideas here. I'm pretty close to tapped out. What I want to do is precompute tails files for when I will need them, without throwing the indy-sdk into vapour lock for minutes at a time; * asyncio: nope (of course: green threads don't propagate through to the rust layer) * multithreading: nope (wallet design: not multithreaded) * multiprocessing: nope (tails writer can only open in first process to grab the library?) Next up, building out a separate docker box with a RESTful service and `~/.indy_client` mapped, and seeing if that corrupts stuff. But this approach seems like design overkill for such a humble feature. I don't think I can go to a purely separate OS installation for this because the revocation registry creator wallet has to have the same private keys as the cred def issuer (OK by DID, but thena single routine key rotation will blow this contrivance up).

sklump (Mon, 29 Oct 2018 12:04:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=dHeTZ7oyRmF7sHhtd) @mgbailey I've also tried to generate tails files in a separate process, but the indy-sdk then blocks on ``` await blog_storage.open_writer(...) ``` which is puzzling. This is just trying to open a file as far as I can see, and should not care that another process is also running the indy-sdk, which links as a *SHARED* library. It puts the lie to the `s` in `.so`. This call doesn't even need a wallet handle. Is it possible to build indy-sdk as a static-link library, then rewrite my own indy/libindy.py in a new wrapper? Gosh. I could use any ideas here. I'm pretty close to tapped out. What I want to do is precompute tails files for when I will need them, without throwing the indy-sdk into vapour lock for minutes at a time; * asyncio: nope (of course: green threads don't propagate through to the rust layer) * multithreading: nope (wallet design: not multithreaded) * multiprocessing: nope (tails writer can only open in first process to grab the library?) Next up, building out a separate docker box with a RESTful service and `~/.indy_client` mapped, and seeing if that corrupts stuff. But this approach seems like design overkill for such a humble feature. I don't think I can go to a purely separate OS installation for this because the revocation registry creator wallet has to have the same private keys as the cred def issuer (OK by DID, but then a single routine key rotation will blow this contrivance up).

sklump (Mon, 29 Oct 2018 12:04:50 GMT):
* _EDIT: all of this comment is tentative. I'm still debugging and none of this is necessarily 100% true _* [ ](https://chat.hyperledger.org/channel/indy-sdk?msg=dHeTZ7oyRmF7sHhtd) @mgbailey I've also tried to generate tails files in a separate process, but the indy-sdk then blocks on ``` await blog_storage.open_writer(...) ``` which is puzzling. This is just trying to open a file as far as I can see, and should not care that another process is also running the indy-sdk, which links as a *SHARED* library. It puts the lie to the `s` in `.so`. This call doesn't even need a wallet handle. Is it possible to build indy-sdk as a static-link library, then rewrite my own indy/libindy.py in a new wrapper? Gosh. I could use any ideas here. I'm pretty close to tapped out. What I want to do is precompute tails files for when I will need them, without throwing the indy-sdk into vapour lock for minutes at a time; * asyncio: nope (of course: green threads don't propagate through to the rust layer) * multithreading: nope (wallet design: not multithreaded) * multiprocessing: nope (tails writer can only open in first process to grab the library?) Next up, building out a separate docker box with a RESTful service and `~/.indy_client` mapped, and seeing if that corrupts stuff. But this approach seems like design overkill for such a humble feature. I don't think I can go to a purely separate OS installation for this because the revocation registry creator wallet has to have the same private keys as the cred def issuer (OK by DID, but then a single routine key rotation will blow this contrivance up).

sklump (Mon, 29 Oct 2018 12:04:50 GMT):
* _EDIT: all of this comment is tentative. I'm still troubleshooting and none of this is necessarily 100% true _* [ ](https://chat.hyperledger.org/channel/indy-sdk?msg=dHeTZ7oyRmF7sHhtd) @mgbailey I've also tried to generate tails files in a separate process, but the indy-sdk then blocks on ``` await blog_storage.open_writer(...) ``` which is puzzling. This is just trying to open a file as far as I can see, and should not care that another process is also running the indy-sdk, which links as a *SHARED* library. It puts the lie to the `s` in `.so`. This call doesn't even need a wallet handle. Is it possible to build indy-sdk as a static-link library, then rewrite my own indy/libindy.py in a new wrapper? Gosh. I could use any ideas here. I'm pretty close to tapped out. What I want to do is precompute tails files for when I will need them, without throwing the indy-sdk into vapour lock for minutes at a time; * asyncio: nope (of course: green threads don't propagate through to the rust layer) * multithreading: nope (wallet design: not multithreaded) * multiprocessing: nope (tails writer can only open in first process to grab the library?) Next up, building out a separate docker box with a RESTful service and `~/.indy_client` mapped, and seeing if that corrupts stuff. But this approach seems like design overkill for such a humble feature. I don't think I can go to a purely separate OS installation for this because the revocation registry creator wallet has to have the same private keys as the cred def issuer (OK by DID, but then a single routine key rotation will blow this contrivance up).

sklump (Mon, 29 Oct 2018 12:04:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=dHeTZ7oyRmF7sHhtd) @mgbailey I've also tried to generate tails files in a separate process, but the indy-sdk then blocks on ``` await blog_storage.open_writer(...) ``` which is puzzling. This is just trying to open a file as far as I can see, and should not care that another process is also running the indy-sdk, which links as a *SHARED* library. It puts the lie to the `s` in `.so`. This call doesn't even need a wallet handle. _edit: my gut says I must be doing something esoterically wrong here; still troubleshooting_ Is it possible to build indy-sdk as a static-link library, then rewrite my own indy/libindy.py in a new wrapper? Gosh. I could use any ideas here. I'm pretty close to tapped out. What I want to do is precompute tails files for when I will need them, without throwing the indy-sdk into vapour lock for minutes at a time; * asyncio: nope (of course: green threads don't propagate through to the rust layer) * multithreading: nope (wallet design: not multithreaded) * multiprocessing: nope (tails writer can only open in first process to grab the library?) Next up, building out a separate docker box with a RESTful service and `~/.indy_client` mapped, and seeing if that corrupts stuff. But this approach seems like design overkill for such a humble feature. I don't think I can go to a purely separate OS installation for this because the revocation registry creator wallet has to have the same private keys as the cred def issuer (OK by DID, but then a single routine key rotation will blow this contrivance up).

sklump (Mon, 29 Oct 2018 12:04:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=dHeTZ7oyRmF7sHhtd) @mgbailey I've also tried to generate tails files in a separate process, but the indy-sdk then blocks on ``` await blog_storage.open_writer(...) ``` which is puzzling. This is just trying to open a file as far as I can see, and should not care that another process is also running the indy-sdk, which links as a *SHARED* library. It puts the lie to the `s` in `.so`. This call doesn't even need a wallet handle. _edit: my gut says I must be doing something esoterically wrong here; still troubleshooting_ ~Is it possible to build indy-sdk as a static-link library, then rewrite my own indy/libindy.py in a new wrapper?~ Gosh. I could use any ideas here. I'm pretty close to tapped out. What I want to do is precompute tails files for when I will need them, without throwing the indy-sdk into vapour lock for minutes at a time; * asyncio: nope (of course: green threads don't propagate through to the rust layer) * multithreading: nope (wallet design: not multithreaded) * multiprocessing: nope (tails writer can only open in first process to grab the library?) Next up, building out a separate docker box with a RESTful service and `~/.indy_client` mapped, and seeing if that corrupts stuff. But this approach seems like design overkill for such a humble feature. I don't think I can go to a purely separate OS installation for this because the revocation registry creator wallet has to have the same private keys as the cred def issuer (OK by DID, but then a single routine key rotation will blow this contrivance up).

sklump (Mon, 29 Oct 2018 16:40:54 GMT):
*_continued: _* So far, I see no block if the process to create revocation registries, as the Issuer anchor, is totally separate from the credential issue process. If the revocation registry creation process is a subprocess, the `blob_storage.open_writer()` blocks. Puzzling. It would be best for our applications if we could have a subprocess, I will spend some more time to this end.

ShivVenkatraman (Mon, 29 Oct 2018 19:54:09 GMT):
I have a question on generate_indy_pool_transactions in https://github.com/hyperledger/indy-node/blob/master/docs/start-nodes.md. Why it the number of clients 1 more than number of nodes? What/who are the the clients here?

mark.hadley (Mon, 29 Oct 2018 21:20:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=zknk7m2WsPYkevR4b) @ShivVenkatraman This might be better addressed in #indy-node

swcurran (Mon, 29 Oct 2018 21:59:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=zknk7m2WsPYkevR4b) The number of nodes is 3F + 1, where F is the number of Faults allowed for the network to function. Thus, in a minimal sandbox network, 4 is the minimum number of nodes. The number of clients using the network is unbounded. I assume what you are looking at happens to have 5 clients, not "one more than the number of nodes".

swcurran (Mon, 29 Oct 2018 21:59:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=zknk7m2WsPYkevR4b) The number of nodes is 3F + 1, where F is the number of Faults allowed for the network to function (F = 1). Thus, in a minimal sandbox network, 4 is the minimum number of nodes. The number of clients using the network is unbounded. I assume what you are looking at happens to have 5 clients, not "one more than the number of nodes".

swcurran (Mon, 29 Oct 2018 21:59:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=zknk7m2WsPYkevR4b) The number of nodes is 3F + 1, where F is the number of Faults allowed for the network to function. Thus, in a minimal sandbox network, 4 is the minimum number of nodes (F = 1). The number of clients using the network is unbounded. I assume what you are looking at happens to have 5 clients, not "one more than the number of nodes".

ShivVenkatraman (Mon, 29 Oct 2018 23:02:23 GMT):
What is the difference between credential definition and schema definition? The schema definition is used for credential definition. There are 2 separate APIs (Java SDK): issuerCreateSchema and issuerCreateAndStoreCredentialDef. Is there a reason to have these APIs as separate and not combine them into one and just use the one for credential definition? The issue of claims (by issuer to prover) seems to be dependent only on credential definition and not schema definition directly.

ShivVenkatraman (Mon, 29 Oct 2018 23:07:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=oRtYjHZyPiD2RHuN3) @swcurran The section here https://github.com/hyperledger/indy-node/blob/master/docs/start-nodes.md#generating-keys-and-test-genesis-transaction-files-for-a-test-network is not too clear on number clients to being unbounded. "--nodes specifies a total number of nodes in the pool, --clients specifies a number of pre-configured clients in the pool"

swcurran (Tue, 30 Oct 2018 00:10:36 GMT):
Schema definitions define just that - a schema - the claims (data elements) within a Credential. A schema is defined by the triple: DID of the Creator, the schema Name, and the schema Version. A Credential Definition links a Schema and the DID of an Issuer for the purpose of that entity Issuing Credentials. A Credential Definition also has public keys for the Claims in the Credential, and is optionally related to one or more Revocation Registries. The terminology used in that "getting started" document you reference is odd. The "clients" from a port perspective are the same as "agents' - as in "users of Indy that make requests to read/update the ledger". As such, there is no inherent limit on those. This specific script is (I think) designed to set up a fixed test case. Others may know more about that specific script. In our environment, we had a developer define a docker image and docker-compose scripts so that we never had to worry about indy-node. We will never do indy-node development, so we don't need to worry about how to set it up or how it works.

ShivVenkatraman (Tue, 30 Oct 2018 00:32:06 GMT):
Does the Java SDK have an example of storing public claims on the ledger? This link https://www.evernym.com/wp-content/uploads/2017/07/What-Goes-On-The-Ledger.pdf refers to that ability (as long as issuer is fine with it)

MichaelLitchev (Tue, 30 Oct 2018 00:38:46 GMT):
Has joined the channel.

MichaelLitchev (Tue, 30 Oct 2018 00:38:52 GMT):
Hey everybody!

MichaelLitchev (Tue, 30 Oct 2018 00:39:13 GMT):
Anyone have any insight into a Indy 309 error when trying parseGetSchemaResponse with Node.js? ``` Credential Definition Creation Failed { IndyError: 309 at Object.callback (/Users/User/Workspace/path/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10) name: 'IndyError', message: '309' } ``` I am able to buildGetSchemaRequest and submitRequest before trying parseGetSchemaResponse MichaelLitchev 6:15 PM The schema response here: ``` { op: 'REPLY', result: { identifier: 'Th7MpTaRZVRYnPiabds81Y', type: '107', seqNo: null, dest: 'Th7MpTaRZVRYnPiabds81Y', data: { name: 'Job-Certificate', version: '0.4' }, state_proof: { multi_signature: [Object], root_hash: '2hm6BKvUN7kWB3L35MmVtA7JVMHis3mkQkPJJkRaMmXr', proof_nodes: '+QJJ+E2rFoN01wVGFSWlZSWW5QaWFiZHM4MVk6MjpKb2ItQ2VydGlmaWNhdGU6MC46A0gu04c/S9PGGFteyoKvY8w7YHgWVanNbGlIMcrBhJ+fhRgICgFFt30OCiL35tq0D1dJyHqpGy26PEEz6TsT142FF2HKagcC0hfFu26r493Ie28NFKD1r/wcQrGz/zl2WkmoRQARmAgICAgICAgICAgICA+HGAgKAUPg6mVmen7z4kcqQruwLeq1J/HaPMThFQdknqBaqCdYCgWU1Tp4I+0vSUbdPmCNpCpVlJUsRuIfBe4HMwqAQXEH+AgICAoJV5rbFmUQXVZCUwGyRvGOGUlca1vnw/C6DRlRJPCOqkgICAgICAgPkBMaDT0j9uCbFabO0LnyutnB5uDC61QaWLtVTJU4XCa4sWo4CAoJqauj70Qf++s0g43b1zvnQEyQJh2lfNqxFRtmaADvkwoDlUizp+IRP1lzDsR/Wo1iALcaYjm73n0/uChjB/EVaHoEl/dKBYFprHPaG5CdLlvDjghcF7Q7pwBZRSzn77TyVyoEQAggmzS6f2NWpUQAFsJZORzSvJtNWsWBopTosPpyIZgICAgKAkcibehQ5iUOtCXD3lQORF05za0YiwT2DavXYCOkmJQoCgfSVcTjtW1SUW/CcILmuBjzvybpOl4RlMkgp3hJTFe2qgG9KhOW51cPReSFM+bhjF8JwB0JqIO+TMzzDo7i/n97WgOzoZfFEvyKcPZvdFjW/+5+SwMc2p8UporYwQiM0hnBqA' }, reqId: 1540850921557444000, txnTime: null } ``` This is my first post on this chat - is this channel the best place for such questions?

MichaelLitchev (Tue, 30 Oct 2018 00:39:13 GMT):
Anyone have any insight into a Indy 309 error when trying parseGetSchemaResponse with Node.js? ``` Credential Definition Creation Failed { IndyError: 309 at Object.callback (/Users/User/Workspace/path/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10) name: 'IndyError', message: '309' } ``` I am able to buildGetSchemaRequest and submitRequest before trying parseGetSchemaResponse The schema response here: ``` { op: 'REPLY', result: { identifier: 'Th7MpTaRZVRYnPiabds81Y', type: '107', seqNo: null, dest: 'Th7MpTaRZVRYnPiabds81Y', data: { name: 'Job-Certificate', version: '0.4' }, state_proof: { multi_signature: [Object], root_hash: '2hm6BKvUN7kWB3L35MmVtA7JVMHis3mkQkPJJkRaMmXr', proof_nodes: '+QJJ+E2rFoN01wVGFSWlZSWW5QaWFiZHM4MVk6MjpKb2ItQ2VydGlmaWNhdGU6MC46A0gu04c/S9PGGFteyoKvY8w7YHgWVanNbGlIMcrBhJ+fhRgICgFFt30OCiL35tq0D1dJyHqpGy26PEEz6TsT142FF2HKagcC0hfFu26r493Ie28NFKD1r/wcQrGz/zl2WkmoRQARmAgICAgICAgICAgICA+HGAgKAUPg6mVmen7z4kcqQruwLeq1J/HaPMThFQdknqBaqCdYCgWU1Tp4I+0vSUbdPmCNpCpVlJUsRuIfBe4HMwqAQXEH+AgICAoJV5rbFmUQXVZCUwGyRvGOGUlca1vnw/C6DRlRJPCOqkgICAgICAgPkBMaDT0j9uCbFabO0LnyutnB5uDC61QaWLtVTJU4XCa4sWo4CAoJqauj70Qf++s0g43b1zvnQEyQJh2lfNqxFRtmaADvkwoDlUizp+IRP1lzDsR/Wo1iALcaYjm73n0/uChjB/EVaHoEl/dKBYFprHPaG5CdLlvDjghcF7Q7pwBZRSzn77TyVyoEQAggmzS6f2NWpUQAFsJZORzSvJtNWsWBopTosPpyIZgICAgKAkcibehQ5iUOtCXD3lQORF05za0YiwT2DavXYCOkmJQoCgfSVcTjtW1SUW/CcILmuBjzvybpOl4RlMkgp3hJTFe2qgG9KhOW51cPReSFM+bhjF8JwB0JqIO+TMzzDo7i/n97WgOzoZfFEvyKcPZvdFjW/+5+SwMc2p8UporYwQiM0hnBqA' }, reqId: 1540850921557444000, txnTime: null } ``` This is my first post on this chat - is this channel the best place for such questions?

swcurran (Tue, 30 Oct 2018 00:55:35 GMT):
@ShivVenkatraman I looked up the "getting started" code behind the "--clients 5" parameter and while I'm not completely certain, it certainly looks like it's creating clients for a test scenario it is setting up, not because it is needed in the normal operation of Indy.

swcurran (Tue, 30 Oct 2018 00:59:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wtqTu5qDDMXCmdZ9c) @ShivVenkatraman No claims, public or private ever go in the ledger with Indy. I reviewed that document and I don't see that anywhere - as the last page underlines. As such, there are no examples of that. :-)

ShivVenkatraman (Tue, 30 Oct 2018 01:03:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aMskGEXzcWEEw2HLB) @swcurran You are right, @swcurran. The 2018 version of the document does not refer to public claims. Sorry, I had downloaded a 2017 version of the same doc and it had a section on Public claims -- "While Evernym’s policy is to keep private data off any type of ledger, there are many situations where public data may be stored on Sovrin as a public claim or as part of a DDO. For example, a company or organisation may elect to publish digitally verifiable versions of data that is already part of the public record. For example the company’s registration information, the list of directors, the company’s address. The company could also publish verifiable claims from regulatory authorities that confirm the company’s licence to trade particular goods for example. Sovrin can therefore be used as a repository for public claims, as long as the issuer has a clear understanding that what they are publishing is a permanent record of that data which cannot be deleted."

NikitaVolkov (Tue, 30 Oct 2018 11:54:25 GMT):
Has joined the channel.

NikitaVolkov (Tue, 30 Oct 2018 12:01:10 GMT):
Hi How can I get libindy's rust logs when I use java wrapper in Android application? I see logs with "info" level, but I can not set env variable RUST_LOG on device to change it to "trace". If this question should be replaced somewhere in specific chat - let me know. Thanks.

NikitaVolkov (Tue, 30 Oct 2018 12:01:10 GMT):
Hi How can I get libindy's rust logs when I use java wrapper in Android application (I run app through Android Studio IDE)? I see logs with "info" level, but I can not set env variable RUST_LOG on device to change it to "trace". If this question should be replaced somewhere in specific chat - let me know. Thanks.

NikitaVolkov (Tue, 30 Oct 2018 12:01:10 GMT):
Hi How can I get libindy's rust logs with level "trace" when I use java wrapper in Android application (I run app through Android Studio IDE)? I see logs with "info" level, but I can not set env variable RUST_LOG on device to change it to "trace". If this question should be replaced somewhere into specific chat - let me know. Thanks. UPD even when I have changed RUST_LOG to trace in code (with Libcore trick) and System.getenv("RUST_LOG") returns "trace" I do not see trace logs of my calls (just info)

xnopre (Tue, 30 Oct 2018 13:42:21 GMT):
Creating credential with `credValues`, what is the `encoded` parameter for each attribute ? How do I have to generate it ? Thanks

sklump (Tue, 30 Oct 2018 14:05:40 GMT):
That is up to you. The toolkit needs to have (signed) 32-bit integers encoded to their stringified representations to support predicates, but otherwise the sky is the limit. Some use SHA-256 encoding and then `int.from_bytes()`. The current von_anchor impl is at https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/master/von_anchor/codec.py. I have a HIPE in to standardize this in the rust layer, but it is an experimental approach that may not satisfy all requirements.

MichaelLitchev (Tue, 30 Oct 2018 14:47:22 GMT):
Anyone have any insight into my 309 error I've posted above?

MichaelLitchev (Tue, 30 Oct 2018 14:54:43 GMT):
I don't like asking for help on technical stuff, but this issue is really blocking me...

mark.hadley (Tue, 30 Oct 2018 15:23:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ZW6LpBczmKpmSndkK) @MichaelLitchev 309 is 'LedgerNotFound' which really means the item is not found ON the ledger, so probably the schema you wrote to the ledger is not being found. So probably what you are passing into the create cred def is not correct. It would be helpful to see what your transaction you are submitting to the ledger to create the credential definition

VaibhavSharma (Tue, 30 Oct 2018 16:08:57 GMT):
credential

MichaelLitchev (Tue, 30 Oct 2018 16:20:03 GMT):
@mark.hadley as usual, I figured it out.. was not requesting the correct schema-name...

MichaelLitchev (Tue, 30 Oct 2018 16:20:29 GMT):
The schema was correctly written to the ledger, I was just not programatically pulling it correctly

MichaelLitchev (Tue, 30 Oct 2018 16:20:36 GMT):
Anyway, HAPPY DAYS!

sklump (Tue, 30 Oct 2018 17:29:03 GMT):
*Folks:* I'm going to rattle on a bit about the indy-sdk code base and then I hope someone will tell my what what I'm doing is wrong. For an indy-sdk call, (1) the wrapper calls to the indy shared object (library) (2) the libindy api layer takes the call, instantiates a CommandExecutor, and sends it the corresponding command (3) the libindy api layer translates the result to an error code and returns it up the chain. *Sequence A:* Start a process, make an indy-sdk call. *Sequence B:* Start a process, have it start a subprocess to make the indy-sdk call. In *Sequence A*, the CommandExecutor gets the call and dispatches its corresponding operations. In *Sequence B*, the CommandExecutor NEVER GETS the call and the result stays in a state forever. Why? How can I work around this? Can someone who's familiar with the design shed any light?

sklump (Tue, 30 Oct 2018 17:29:03 GMT):
*Folks:* I'm going to rattle on a bit about the indy-sdk code base and then I hope someone will have a good guess what I'm doing is wrong. For an indy-sdk call, (1) the wrapper calls to the indy shared object (library) (2) the libindy api layer takes the call, instantiates a CommandExecutor, and sends it the corresponding command (3) the libindy api layer translates the result to an error code and returns it up the chain. *Sequence A:* Start a process, make an indy-sdk call. *Sequence B:* Start a process, have it start a subprocess to make the indy-sdk call. In *Sequence A*, the CommandExecutor gets the call and dispatches its corresponding operations. In *Sequence B*, the CommandExecutor NEVER GETS the call and the result stays in a state forever. Why? How can I work around this? Can someone who's familiar with the design shed any light?

ShivVenkatraman (Tue, 30 Oct 2018 18:01:27 GMT):
Is there an API to introspect the tails file contents; and monitor its growth?

ianco (Tue, 30 Oct 2018 18:03:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=bRGX6tSa4J7RkwRkt) @sklump @sklump can you share your test code (that's making the sdk call)?

sklump (Tue, 30 Oct 2018 18:10:23 GMT):
@ianco, I have to strip it down to a minimal example, I will post one tomorrow morning early.

JamieLi (Tue, 30 Oct 2018 18:25:01 GMT):
Has joined the channel.

JamieLi (Tue, 30 Oct 2018 18:26:13 GMT):
There is a warning in the indy-sdk Java Wrapper "Not ready for production use! Not all commands work properly! Use at your own risk!". The page URL is "https://github.com/hyperledger/indy-sdk/tree/master/wrappers/java". Is this warning still valid? Does this mean that we should avoid using Java for development?

sklump (Tue, 30 Oct 2018 18:36:50 GMT):
@ianco et al., *(1)* Paste this as `test_mproc.py` in `indy-sdk/wrappers/python/tests/did`: ``` import os import pytest from indy import did @pytest.mark.asyncio async def test_key_for_local_did_works_for_my_did(wallet_handle, identity_trustee1): (_did, verkey) = identity_trustee1 received_key = await did.key_for_local_did(wallet_handle, _did) assert verkey == received_key if os.fork(): print('parent process {} returning'.format(os.getpid())) else: os.setsid() print('Child process {} done set-sid'.format(os.getpid())) if not os.fork(): print('Grandchild process {} calling key_for_local_did({})'.format(os.getpid(), _did), flush=True) received_key = await did.key_for_local_did(wallet_handle, _did) print('Grandchild process {} got key {}'.format(os.getpid(), received_key), flush=True) assert verkey == received_key print('Grandchild process {} passed assertion'.format(os.getpid()), flush=True) print('process {} exiting'.format(os.getpid())) os._exit(0) ``` *(2)* Edit `indy-sdk/wrappers/python/tests/conftest.py` to hush logging: ``` logging.basicConfig(level=logging.WARNING) ``` *(3)* Run the unit test as standard and see that the forked process never comes back from indy-sdk. You must kill it manually by its pid; the double-fork detaches it. e.g., ``` $ pipenv run pytest -s test_mproc.py ================================================= test session starts ================================================== platform linux -- Python 3.7.0, pytest-3.6.4, py-1.7.0, pluggy-0.7.1 rootdir: /home/sklump/indy-sdk/wrappers/python, inifile: plugins: asyncio-0.8.0 collected 1 item test_mproc.py parent process 7338 returning .Child process 7352 done set-sid process 7352 exiting \[color{green}=============================================== 1 passed in 0.06 seconds ===============================================\] Grandchild process 7353 calling key_for_local_did(V4SGRU86Z58d6TV7PBUe6f) ```

sklump (Tue, 30 Oct 2018 18:36:50 GMT):
@ianco et al., *(1)* Paste this as `test_mproc.py` in `indy-sdk/wrappers/python/tests/did`: ``` import os import pytest from indy import did @pytest.mark.asyncio async def test_key_for_local_did_works_for_my_did(wallet_handle, identity_trustee1): (_did, verkey) = identity_trustee1 received_key = await did.key_for_local_did(wallet_handle, _did) assert verkey == received_key if os.fork(): print('parent process {} returning'.format(os.getpid())) else: os.setsid() print('Child process {} done set-sid'.format(os.getpid())) if not os.fork(): print('Grandchild process {} calling key_for_local_did({})'.format(os.getpid(), _did), flush=True) received_key = await did.key_for_local_did(wallet_handle, _did) print('Grandchild process {} got key {}'.format(os.getpid(), received_key), flush=True) assert verkey == received_key print('Grandchild process {} passed assertion'.format(os.getpid()), flush=True) print('process {} exiting'.format(os.getpid())) os._exit(0) ``` *(2)* Edit `indy-sdk/wrappers/python/tests/conftest.py` to hush logging: ``` logging.basicConfig(level=logging.WARNING) ``` *(3)* Run the unit test as standard and see that the forked process never comes back from indy-sdk. You must kill it manually by its pid; the double-fork detaches it. e.g., ``` $ pipenv run pytest -s test_mproc.py ================================================= test session starts ================================================== platform linux -- Python 3.7.0, pytest-3.6.4, py-1.7.0, pluggy-0.7.1 rootdir: /home/sklump/indy-sdk/wrappers/python, inifile: plugins: asyncio-0.8.0 collected 1 item test_mproc.py parent process 7338 returning .Child process 7352 done set-sid process 7352 exiting \[color{green}{=============================================== 1 passed in 0.06 seconds ===============================================}\] Grandchild process 7353 calling key_for_local_did(V4SGRU86Z58d6TV7PBUe6f) ```

sklump (Tue, 30 Oct 2018 18:36:50 GMT):
@ianco et al., *(1)* Paste this as `test_mproc.py` in `indy-sdk/wrappers/python/tests/did`: ``` import os import pytest from indy import did @pytest.mark.asyncio async def test_key_for_local_did_works_for_my_did(wallet_handle, identity_trustee1): (_did, verkey) = identity_trustee1 received_key = await did.key_for_local_did(wallet_handle, _did) assert verkey == received_key if os.fork(): print('parent process {} returning'.format(os.getpid())) else: os.setsid() print('Child process {} done set-sid'.format(os.getpid())) if not os.fork(): print('Grandchild process {} calling key_for_local_did({})'.format(os.getpid(), _did), flush=True) received_key = await did.key_for_local_did(wallet_handle, _did) print('Grandchild process {} got key {}'.format(os.getpid(), received_key), flush=True) assert verkey == received_key print('Grandchild process {} passed assertion'.format(os.getpid()), flush=True) print('process {} exiting'.format(os.getpid())) os._exit(0) ``` *(2)* Edit `indy-sdk/wrappers/python/tests/conftest.py` to hush logging: ``` logging.basicConfig(level=logging.WARNING) ``` *(3)* Run the unit test as standard and see that the forked process never comes back from indy-sdk. You must kill it manually by its pid; the double-fork detaches it. e.g., ``` $ pipenv run pytest -s test_mproc.py ================================================= test session starts ================================================== platform linux -- Python 3.7.0, pytest-3.6.4, py-1.7.0, pluggy-0.7.1 rootdir: /home/sklump/indy-sdk/wrappers/python, inifile: plugins: asyncio-0.8.0 collected 1 item test_mproc.py parent process 7338 returning .Child process 7352 done set-sid process 7352 exiting =============================================== 1 passed in 0.06 seconds =============================================== Grandchild process 7353 calling key_for_local_did(V4SGRU86Z58d6TV7PBUe6f) ```

sklump (Tue, 30 Oct 2018 18:36:50 GMT):
@ianco et al., *(1)* Paste this as `test_mproc.py` in `indy-sdk/wrappers/python/tests/did`: ``` import os import pytest from indy import did @pytest.mark.asyncio async def test_key_for_local_did_works_for_my_did(wallet_handle, identity_trustee1): (_did, verkey) = identity_trustee1 received_key = await did.key_for_local_did(wallet_handle, _did) assert verkey == received_key if os.fork(): print('parent process {} returning'.format(os.getpid())) else: os.setsid() print('Child process {} done set-sid'.format(os.getpid())) if not os.fork(): print('Grandchild process {} calling key_for_local_did({})'.format(os.getpid(), _did), flush=True) received_key = await did.key_for_local_did(wallet_handle, _did) print('Grandchild process {} got key {}'.format(os.getpid(), received_key), flush=True) assert verkey == received_key print('Grandchild process {} passed assertion'.format(os.getpid()), flush=True) print('process {} exiting'.format(os.getpid())) os._exit(0) ``` *(2)* Edit `indy-sdk/wrappers/python/tests/conftest.py` to hush logging: ``` logging.basicConfig(level=logging.WARNING) ``` *(3)* Run the unit test as standard and see that the forked process never comes back from indy-sdk. You must kill it manually by its pid; the double-fork detaches it. e.g., ``` $ pipenv run pytest -s test_mproc.py ================================================= test session starts ================================================== platform linux -- Python 3.7.0, pytest-3.6.4, py-1.7.0, pluggy-0.7.1 rootdir: /home/sklump/indy-sdk/wrappers/python, inifile: plugins: asyncio-0.8.0 collected 1 item test_mproc.py parent process 7338 returning .Child process 7352 done set-sid process 7352 exiting =============================================== 1 passed in 0.06 seconds =============================================== Grandchild process 7353 calling key_for_local_did(V4SGRU86Z58d6TV7PBUe6f) $ kill 7353 $ kill 7353 -bash: kill: (7353) - No such process $ ```

sklump (Tue, 30 Oct 2018 18:47:35 GMT):
[\int_{-\infty}^infty\hat f(\xi)\,e^2 \pi i \xi x}\, d\xi]

ShivVenkatraman (Tue, 30 Oct 2018 19:04:57 GMT):
How does one "unrevoke" a revoked credential? The link https://github.com/hyperledger/indy-sdk/blob/master/doc/cred-revocation.md says that revocation is reversible. AnonCreds (Java SDK) has a issuerRevokeCredential API but non "unrevoke" API

MichaelLitchev (Tue, 30 Oct 2018 19:18:17 GMT):
Is there anything stopping a government entity from issuing a schema, then creating a credential definition for the schema it published itself?

swcurran (Tue, 30 Oct 2018 20:12:08 GMT):
Nope. We (BC Gov) are doing that regularly. Government or anyone can do that.

ianco (Tue, 30 Oct 2018 20:31:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jatARkBv9hWDnSRxE) @sklump I haven't tried to run this yet but I suspect it will block on access to the wallet. You're passing a wallet handle across different processes and I'm not sure what the expected behaviour is ...

jacobsaur (Tue, 30 Oct 2018 21:21:01 GMT):
Is it possible to get all historical values for an attribute? I see that there is buildGetAttribRequest (Builds a GET_ATTRIB request. Request to get information about an Attribute for the specified DID.) I'd like similar functionality for for all historical values.

smithbk (Wed, 31 Oct 2018 06:34:33 GMT):
Hi, I need a "string ends with" predicate but if I'm looking the correct place in the code, it appears that the only predicate supported is ">=". Is this correct?t seems the only predicate currently supported is ">=". Is this true? I need a "string ends with" predicate. ``` pub fn attribute_satisfy_predicate(&self, predicate: &PredicateInfo, attribute_value: &str) -> Result { trace!("attribute_satisfy_predicate >>> predicate: {:?}, attribute_value: {:?}", predicate, attribute_value); let res = match predicate.p_type { PredicateTypes::GE => { let attribute_value = attribute_value.parse::() .map_err(|err| CommonError::InvalidStructure(format!("Credential attribute value \"{:?}\" is invalid: {:?}", attribute_value, err)))?; Ok(attribute_value >= predicate.p_value) } }; trace!("attribute_satisfy_predicate <<< res: {:?}", res); res } ```

smithbk (Wed, 31 Oct 2018 06:34:33 GMT):
Hi, I need a "string ends with" predicate but if I'm looking the correct place in the code, it appears that the only predicate supported is ">=". Is this correct? I see the following in indy-sdk/src/services/anoncreds/prover.rs. ``` pub fn attribute_satisfy_predicate(&self, predicate: &PredicateInfo, attribute_value: &str) -> Result { trace!("attribute_satisfy_predicate >>> predicate: {:?}, attribute_value: {:?}", predicate, attribute_value); let res = match predicate.p_type { PredicateTypes::GE => { let attribute_value = attribute_value.parse::() .map_err(|err| CommonError::InvalidStructure(format!("Credential attribute value \"{:?}\" is invalid: {:?}", attribute_value, err)))?; Ok(attribute_value >= predicate.p_value) } }; trace!("attribute_satisfy_predicate <<< res: {:?}", res); res } ```

swcurran (Wed, 31 Oct 2018 06:46:33 GMT):
As of now, >= is the only predicate available. I recall hearing others are on the way, but I don't know the details.

ShubhamSingh18 (Wed, 31 Oct 2018 07:44:41 GMT):
How indy is different from the fabric as fabric can also customized for identity management system

sergey.khoroshavin (Wed, 31 Oct 2018 08:46:25 GMT):
@ShubhamSingh18 fabric

sergey.khoroshavin (Wed, 31 Oct 2018 08:48:47 GMT):
@ShubhamSingh18 Fabric is oriented for private use (installations are inaccessible for general public), but Indy is public permissioned ledger

ShubhamSingh18 (Wed, 31 Oct 2018 09:42:26 GMT):
@sergey.khoroshavin Can you explain in detail

sergey.khoroshavin (Wed, 31 Oct 2018 09:54:26 GMT):
@ShubhamSingh18 as far as I know Fabric was designed to run in closed (cross-)corporate environment with restricted direct access. Node also can be used this way, but its nodes were designed to be run in public network, with read access by anyone. Write access is of course restricted to those who have permissions, but is also done from public network.

sergey.khoroshavin (Wed, 31 Oct 2018 09:54:26 GMT):
@ShubhamSingh18 as far as I know Fabric was designed to run in closed (cross-)corporate environment with restricted direct access. Indy node also can be used this way, but its nodes were designed to be run in public network, with read access by anyone. Write access is of course restricted to those who have permissions, but is also done from public network.

sergey.khoroshavin (Wed, 31 Oct 2018 09:54:26 GMT):
@ShubhamSingh18 as far as I know Fabric was designed to run in closed (cross-)corporate environment with restricted direct access. Indy node also can be used this way, but it was designed to be run in public network, with read access by anyone. Write access is of course restricted to those who have permissions, but is also done from public network.

ShubhamSingh18 (Wed, 31 Oct 2018 10:00:52 GMT):
What is difference between public DID and private DID

sklump (Wed, 31 Oct 2018 10:32:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=KzCy5j3ijmCkGwWxW) @jacobsaur You could roll through all transactions and filter for SET_ATTRIB on the request of interest. Terrible but academically possible.

sklump (Wed, 31 Oct 2018 11:51:55 GMT):
@ianco, it's nothing to do with a wallet handle. It blocks the same on calls that don't take a wallet handle. It's the command executor that just doesn't get its message. See: ``` import json import os import pytest from indy import blob_storage @pytest.mark.asyncio async def test_fork(path_home): tails_writer_config = json.dumps({'base_dir': str(path_home.joinpath("tails")), 'uri_pattern': ''}) if os.fork(): print('parent process {} returning'.format(os.getpid())) else: os.setsid() print('Child process {} done set-sid'.format(os.getpid())) if not os.fork(): print('Grandchild process {} calling blob_storage.open_writer()'.format(os.getpid()), flush=True) tails_writer = await blob_storage.open_writer('default', tails_writer_config) print('Grandchild process {} got tails_writer {}'.format(os.getpid(), id(tails_writer)), flush=True) print('process {} exiting'.format(os.getpid())) os._exit(0) ```

sklump (Wed, 31 Oct 2018 11:51:55 GMT):
@ianco, it's nothing to do with a wallet handle. It blocks the same on calls that don't take a wallet handle. It's the command executor that just doesn't get its message. See: `indy-sdk/wrappers/python/tests/ledger/test_fork.py` ``` import json import os import pytest from indy import blob_storage @pytest.mark.asyncio async def test_fork(path_home): tails_writer_config = json.dumps({'base_dir': str(path_home.joinpath("tails")), 'uri_pattern': ''}) if os.fork(): print('parent process {} returning'.format(os.getpid())) else: os.setsid() print('Child process {} done set-sid'.format(os.getpid())) if not os.fork(): print('Grandchild process {} calling blob_storage.open_writer()'.format(os.getpid()), flush=True) tails_writer = await blob_storage.open_writer('default', tails_writer_config) print('Grandchild process {} got tails_writer {}'.format(os.getpid(), id(tails_writer)), flush=True) print('process {} exiting'.format(os.getpid())) os._exit(0) ``` then from `indy-sdk/wrappers/python/tests/ledger/` ``` $ pipenv run pytest -s test_fork.py ================================================= test session starts ================================================== platform linux -- Python 3.7.0, pytest-3.6.4, py-1.7.0, pluggy-0.7.1 rootdir: /home/sklump/indy-sdk/wrappers/python, inifile: plugins: asyncio-0.8.0 collected 1 item test_fork.py parent process 17740 returning . =============================================== 1 passed in 0.03 seconds =============================================== Child process 17750 done set-sid process 17750 exiting Grandchild process 17751 calling blob_storage.open_writer() $ kill 17751 $ kill 17751 -bash: kill: (17751) - No such process ```

sklump (Wed, 31 Oct 2018 11:51:55 GMT):
@ianco, it's nothing to do with a wallet handle. It blocks the same on calls that don't take a wallet handle. It's the command executor that just doesn't get its message. See: `indy-sdk/wrappers/python/tests/ledger/test_fork.py` ``` import json import os import pytest from indy import blob_storage @pytest.mark.asyncio async def test_fork(path_home): tails_writer_config = json.dumps({'base_dir': str(path_home.joinpath("tails")), 'uri_pattern': ''}) if os.fork(): print('parent process {} returning'.format(os.getpid())) else: os.setsid() print('Child process {} done set-sid'.format(os.getpid())) if not os.fork(): print('Grandchild process {} calling blob_storage.open_writer()'.format(os.getpid()), flush=True) tails_writer = await blob_storage.open_writer('default', tails_writer_config) print('Grandchild process {} got tails_writer {}'.format(os.getpid(), id(tails_writer)), flush=True) # note that we never get here print('process {} exiting'.format(os.getpid())) os._exit(0) ``` then from `indy-sdk/wrappers/python/tests/ledger/` ``` $ pipenv run pytest -s test_fork.py ================================================= test session starts ================================================== platform linux -- Python 3.7.0, pytest-3.6.4, py-1.7.0, pluggy-0.7.1 rootdir: /home/sklump/indy-sdk/wrappers/python, inifile: plugins: asyncio-0.8.0 collected 1 item test_fork.py parent process 17740 returning . =============================================== 1 passed in 0.03 seconds =============================================== Child process 17750 done set-sid process 17750 exiting Grandchild process 17751 calling blob_storage.open_writer() $ kill 17751 $ kill 17751 -bash: kill: (17751) - No such process ```

dnnn (Wed, 31 Oct 2018 14:20:31 GMT):
Has joined the channel.

dnnn (Wed, 31 Oct 2018 14:37:31 GMT):
Hi everyone! I was not aware of this channel, so posted this message in #indy before. Sorry for spam. But maybe someone could help me in this channel. I am trying to run demo application of iOS wrapper from indy-sdk repo and am facing an issue with missing "platform.hpp" file while the dependency pod `libzmq` is built. Could you please share some advice on how to fix it? I am using xcode 10

bhagadorn (Wed, 31 Oct 2018 19:00:22 GMT):
Has joined the channel.

jacobsaur (Wed, 31 Oct 2018 19:50:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5aCh7kMzm9AgtX7Ph) @sklump Thanks @sklump , I think that's good enough for the proof of concept I'm working on. It's terribly inefficient, I just iterate over all seqNo's calling buildGetTxnRequest() and only including the ones with type ATTRIB from the target DID. A better transaction search function sounds like it would be fairly straightforward to add to the sdk if there was enough demand.

jljordan_bcgov (Wed, 31 Oct 2018 20:46:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=i6AEfSeRwKDkZLCfk) @ShubhamSingh18 I think reading the Sovrin Whitepaper https://sovrin.org/wp-content/uploads/2018/03/Sovrin-Protocol-and-Token-White-Paper.pdf is likely a good starting point ... Hyperledger Indy is the technology that powers the Sovrin network

NateThelen (Wed, 31 Oct 2018 22:00:48 GMT):
Has joined the channel.

PhillipGibb (Thu, 01 Nov 2018 08:17:45 GMT):
Hi, Can someone please help me with a get credential definition, I get this error using my agent DID to lookup a cred def : `client request invalid: InvalidClientRequest(\"validation error [ClientClaimDefG│ bundle.js 2.7 MiB main [emitted] main etOperation]: should not contain the following chars [\'I\']` yes the DID has an [\I\] in it

PhillipGibb (Thu, 01 Nov 2018 08:17:45 GMT):
Hi, Can someone please help me with a get credential definition, I get this error using my agent DID to lookup a cred def : ` client request invalid: InvalidClientRequest(\"validation error [ClientClaimDefG│ bundle.js 2.7 MiB main [emitted] main etOperation]: should not contain the following chars [\'I\'] ` yes the DID has an [\I\] in it

PhillipGibb (Thu, 01 Nov 2018 08:17:45 GMT):
Hi, Can someone please help me with a get credential definition, I get this error using my agent DID to lookup a cred def : ``` client request invalid: InvalidClientRequest(\"validation error [ClientClaimDefG│ bundle.js 2.7 MiB main [emitted] main etOperation]: should not contain the following chars [\'I\'] ``` yes the DID has an [\I\] in it

PhillipGibb (Thu, 01 Nov 2018 08:34:01 GMT):
using a cred def that was ledgered with DID - without n I: ``` data did not match any variant of untagged enum Reply ```

PhillipGibb (Thu, 01 Nov 2018 08:34:01 GMT):
using a cred def that was ledgered with DID - without an I: ``` data did not match any variant of untagged enum Reply ```

PhillipGibb (Thu, 01 Nov 2018 09:32:10 GMT):
ok, the first error occurs because the VCX verity-ui displays the DID all in caps. yet, after sorting that out I still get: ``` data did not match any variant of untagged enum Reply ```

sergey.minaev (Thu, 01 Nov 2018 11:47:12 GMT):
@PhillipGibb DID is assumed as base58-encoded string. How did you create your DID with `I` inside it? This symbol is not allowed in base58 alphabet

PhillipGibb (Thu, 01 Nov 2018 11:50:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=dWZz2otn9XeEKrEBF) @sergey.minaev Sorry, I pulled the DID from the VCX verity-ui. it displayed the Cred def all in uppercase - that is where the '''I''' came from

sergey.minaev (Thu, 01 Nov 2018 11:58:02 GMT):
@PhillipGibb ok, got it. Sorry, I've missed your last not as same trace is attached. what version of libindy do you use? Probably it's not a latest master (e.g. latest stable) and this error is shown by parser for get_cred_def for case of appropriate entity is not found. Could you check raw result from `indy_sign_and_submit_request` , before trying to parse it in `parse_get_cred_def_response`?

sergey.minaev (Thu, 01 Nov 2018 11:58:02 GMT):
@PhillipGibb ok, got it. Sorry, I've missed your last note as same trace is attached. what version of libindy do you use? Probably it's not a latest master (e.g. latest stable) and this error is shown by parser for get_cred_def for case of appropriate entity is not found. Could you check raw result from `indy_sign_and_submit_request` , before trying to parse it in `parse_get_cred_def_response`?

PhillipGibb (Thu, 01 Nov 2018 12:02:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jNq8QbsLKFHMxNpX8) @sergey.minaev stable

sergey.minaev (Thu, 01 Nov 2018 12:04:44 GMT):
in this case the most popular reason of `indy_sign_and_submit_request` is not found entity on ledger.

sergey.minaev (Thu, 01 Nov 2018 12:04:44 GMT):
in this case the most popular reason of ~`indy_sign_and_submit_request`~ `data did not match any variant of untagged enum Reply` is not found entity on ledger.

sergey.minaev (Thu, 01 Nov 2018 12:04:44 GMT):
in this case the most popular reason of ~indy_sign_and_submit_request~ `data did not match any variant of untagged enum Reply` is not found entity on ledger.

PhillipGibb (Thu, 01 Nov 2018 12:09:56 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Mf5ofxsHRETFuZxEg) @sergey.minaev hmmmm, I do notice a massive response, but "data":null I am fairly convinced that the Credential def was ledgered

PhillipGibb (Thu, 01 Nov 2018 12:21:11 GMT):
@sergey.minaev this is interesting, right now I 'ledgered' a schema and cred defn using vcx but only the schema was available from the schema, not the cred defn. Is there a naming convention for definitions? or is that up to the issuer?

sasiedu (Thu, 01 Nov 2018 14:52:00 GMT):
Has joined the channel.

sasiedu (Thu, 01 Nov 2018 14:54:52 GMT):
hi all, anyone know if it's possible to connect a node libindy sdk to an agent?

NathanielHayes (Thu, 01 Nov 2018 15:54:27 GMT):
Has joined the channel.

ShivVenkatraman (Thu, 01 Nov 2018 17:35:50 GMT):
From the indy channel: "Verkey is different than issuance key. Verkey is to verify the connection to the issuer. Issuance key is used to verify credential signatures. Verkey is meant to be pairwise so rotating it only changes the connection to you not to everyone else. If the issuer did indeed rotate the issuance key in the credential definition, then that doesn't necessarily invalidate existing credentials. It just means newer credentials are not using the older key. If the issuer wanted to revoke all issued credentials, they would zero out the revocation registry." Does the SDK have an example of issuance key vs verkey?

PhillipGibb (Thu, 01 Nov 2018 19:36:44 GMT):
ripping my hair out with this sudden error: ``` "name":"IndyError","message":"CommonInvalidStructure","indyCode":113,"indyName":"CommonInvalidStructure","level":"error" ```

PhillipGibb (Thu, 01 Nov 2018 19:36:44 GMT):
ripping my hair out with this sudden error when creating a wallet: ``` "name":"IndyError","message":"CommonInvalidStructure","indyCode":113,"indyName":"CommonInvalidStructure","level":"error" ```

smithbk (Thu, 01 Nov 2018 19:43:23 GMT):
Is there any way to look up a credential schema id from the ledger given the schema name and version?

PhillipGibb (Thu, 01 Nov 2018 19:47:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=B2s4bmFjbm5SJF8Wi) ahhh, I had to: ``` return await sdk.openWallet( { "id": `"${config.walletName}}"` }, { "key": `"${config.walletKey}}"` } ); ```

swcurran (Thu, 01 Nov 2018 19:49:46 GMT):
@smithbk - not yet as a search through indy-node. We've started a ledger browser that (amongst other features) periodically queries nodes for the latest transactions and stores them in a local database. Queries such as you suggest become trivial. No docs yet :-( but the server code is a fairly simple python server: https://github.com/bcgov/von-network/tree/master/server An earlier version of the browser is here http://159.89.115.24/. The "Domain Ledger" JSON dump has recently been updated with formatted display, paging and drilldown. Search and connections (such as schema to Cred Def) is coming Real Soon Now. PRs accepted :-).

PhillipGibb (Thu, 01 Nov 2018 19:53:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=NyCwGCGteCLGadPgX) @swcurran nice, I am writing a lookup web app for DID, NYM, Schema, but I get stuck on credential definitions - they are added via vcx but lookups with an id returns null

adamjbradley (Thu, 01 Nov 2018 20:23:59 GMT):
Has joined the channel.

adamjbradley (Thu, 01 Nov 2018 20:24:13 GMT):
Morning all!

adamjbradley (Thu, 01 Nov 2018 20:24:46 GMT):
Wondering if there might be a set of Docker images which would let me deploy a complete environment? Thanks!

ShivVenkatraman (Thu, 01 Nov 2018 20:25:40 GMT):
Has someone tried to compile indy_sdk (libindy) using the instructions here: https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md ?The cargo build is stuck at " Compiling rust-base58 v0.0.4"

adamjbradley (Thu, 01 Nov 2018 20:27:41 GMT):
_is embarassed_

adamjbradley (Thu, 01 Nov 2018 20:27:48 GMT):
Found it, duh. Apologies

ShivVenkatraman (Thu, 01 Nov 2018 20:28:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=HXChjbpFuTm5XjthK) @adamjbradley Where did you find it?

smithbk (Thu, 01 Nov 2018 21:05:23 GMT):
@swcurran Thanks ... what are the privilege requirements for this server to be able to query the nodes for latest transactions?

smithbk (Thu, 01 Nov 2018 21:09:27 GMT):
I've recently run into the following error when creating a cred def and am not aware of any changes I've made. Any suggestions are appreciated. ``` INFO|indy::commands | src/commands/mod.rs:111 | LedgerCommand command received DEBUG|indy::commands::ledger | src/commands/ledger.rs:621 | parse_get_schema_response >>> get_schema_response: "{\"op\":\"REPLY\",\"result\":{\"txnTime\":null,\"dest\":\"HGruKhUqowACgK7PEQz9aW\",\"identifier\":\"HGruKhUqowACgK7PEQz9aW\",\"seqNo\":null,\"reqId\":1541105932488845048,\"type\":\"107\",\"data\":{\"version\":\"1.0\",\"name\":\"DriversLicense\"}}}" INFO|indy::services::ledger | src/services/ledger/mod.rs:414 | parse_get_schema_response >>> get_schema_response: "{\"op\":\"REPLY\",\"result\":{\"txnTime\":null,\"dest\":\"HGruKhUqowACgK7PEQz9aW\",\"identifier\":\"HGruKhUqowACgK7PEQz9aW\",\"seqNo\":null,\"reqId\":1541105932488845048,\"type\":\"107\",\"data\":{\"version\":\"1.0\",\"name\":\"DriversLicense\"}}}" TRACE|indy::services::ledger | src/services/ledger/mod.rs:546 | parse_response >>> response "{\"op\":\"REPLY\",\"result\":{\"txnTime\":null,\"dest\":\"HGruKhUqowACgK7PEQz9aW\",\"identifier\":\"HGruKhUqowACgK7PEQz9aW\",\"seqNo\":null,\"reqId\":1541105932488845048,\"type\":\"107\",\"data\":{\"version\":\"1.0\",\"name\":\"DriversLicense\"}}}" ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid transaction: Cannot deserialize transaction Response: Error("data did not match any variant of untagged enum Reply", line: 0, column: 0) ```

ShivVenkatraman (Thu, 01 Nov 2018 22:37:58 GMT):
I upgraded libindy (https://github.com/hyperledger/indy-sdk/blob/master/README.md#ubuntu-based-distributions-ubuntu-1604) with 'sudo apt-get install -y libindy' and I am seeing the following errors when running 'init_indy_node Node ...": Traceback (most recent call last): File "/usr/local/bin/init_indy_keys", line 6, in from plenum.common.keygen_utils import initNodeKeysForBothStacks File "/usr/local/lib/python3.5/dist-packages/plenum/common/keygen_utils.py", line 3, in from plenum.bls.bls_crypto_factory import create_default_bls_crypto_factory File "/usr/local/lib/python3.5/dist-packages/plenum/bls/bls_crypto_factory.py", line 5, in from crypto.bls.indy_crypto.bls_crypto_indy_crypto import BlsGroupParamsLoaderIndyCrypto, BlsCryptoSignerIndyCrypto, \ File "/usr/local/lib/python3.5/dist-packages/crypto/bls/indy_crypto/bls_crypto_indy_crypto.py", line 9, in from indy_crypto.bls import BlsEntity, Generator, VerKey, SignKey, Bls, \ ImportError: cannot import name 'ProofOfPossession'

arunwij (Fri, 02 Nov 2018 04:50:30 GMT):
Hi, I get a weird response when using predicates. I sent this proof request with this predicate. ``` ```

arunwij (Fri, 02 Nov 2018 04:55:30 GMT):
Hi, I get a weird response when using predicates. I sent this proof request with this predicate. ``` 'requested_predicates': { 'predicate1_referent': { 'name': 'gpa', 'p_type': '>=', 'p_value': 4 } } ``` And I found this credential for that proof request(even thought credential gpa value is 1.2) ``` { referent: '2cd44a37-a585-4994-8e5c-0b2c926e32fc', attrs: { first_name: 'jane', degree: 'IT', last_name: 'doe', *gpa: '1.2'* }, schema_id: 'Nf6LPd2QvDmzsyUm2EcRWq:2:Transcript:1.0', cred_def_id: 'Nf6LPd2QvDmzsyUm2EcRWq:3:CL:427:Result', rev_reg_id: null, cred_rev_id: null } ``` And I could successfully verify the proof with `verifierVerifyProof` method. I am using NodeJS SDK. How this suppose to work? What am I missing here?

arunwij (Fri, 02 Nov 2018 04:55:30 GMT):
Hi, I get a weird response when using predicates. I sent this proof request with this predicate. ``` 'requested_predicates': { 'predicate1_referent': { 'name': 'gpa', 'p_type': '>=', 'p_value': 4 } } ``` And I found this credential for that proof request(even thought credential gpa value is 1.2) ``` { referent: '2cd44a37-a585-4994-8e5c-0b2c926e32fc', attrs: { first_name: 'jane', degree: 'IT', last_name: 'doe', *gpa: '1.2'* }, schema_id: 'Nf6LPd2QvDmzsyUm2EcRWq:2:Transcript:1.0', cred_def_id: 'Nf6LPd2QvDmzsyUm2EcRWq:3:CL:427:Result', rev_reg_id: null, cred_rev_id: null } ``` And I could successfully verify the proof with `verifierVerifyProof` method. How this suppose to work? What am I missing here? (I am using NodeJS SDK)

arunwij (Fri, 02 Nov 2018 04:55:30 GMT):
Hi, I get a weird response when using predicates. I sent this proof request with this predicate. ``` 'requested_predicates': { 'predicate1_referent': { 'name': 'gpa', 'p_type': '>=', 'p_value': 4 } } ``` And the credential search result for the proof request (even thought credential gpa value is 1.2) ``` { referent: '2cd44a37-a585-4994-8e5c-0b2c926e32fc', attrs: { first_name: 'jane', degree: 'IT', last_name: 'doe', *gpa: '1.2'* }, schema_id: 'Nf6LPd2QvDmzsyUm2EcRWq:2:Transcript:1.0', cred_def_id: 'Nf6LPd2QvDmzsyUm2EcRWq:3:CL:427:Result', rev_reg_id: null, cred_rev_id: null } ``` And I could successfully verify the proof with `verifierVerifyProof` method. How this suppose to work? What am I missing here? (I am using NodeJS SDK)

arunwij (Fri, 02 Nov 2018 04:55:30 GMT):
Hi, I get a weird response when using predicates. I sent this proof request with this predicate. ``` 'requested_predicates': { 'predicate1_referent': { 'name': 'gpa', 'p_type': '>=', 'p_value': 4 } } ``` And the credential search result for the proof request (even thought credential gpa value is 1.2) ``` { referent: '2cd44a37-a585-4994-8e5c-0b2c926e32fc', attrs: { first_name: 'jane', degree: 'IT', last_name: 'doe', *gpa: '1.2'* }, schema_id: 'Nf6LPd2QvDmzsyUm2EcRWq:2:Transcript:1.0', cred_def_id: 'Nf6LPd2QvDmzsyUm2EcRWq:3:CL:427:Result', rev_reg_id: null, cred_rev_id: null } ``` And I could successfully verify the proof with `verifierVerifyProof` method. I get verification even the p_value < 4, How this suppose to work? What am I missing here? (I am using NodeJS SDK)

arunwij (Fri, 02 Nov 2018 04:55:30 GMT):
Hi, I get a weird response when using predicates. I sent this proof request with this predicate. (I sent the proof request without restrictions [] is it okay? ) ``` 'requested_predicates': { 'predicate1_referent': { 'name': 'gpa', 'p_type': '>=', 'p_value': 4 } } ``` And the credential search result for the proof request (even thought credential gpa value is 1.2) ``` { referent: '2cd44a37-a585-4994-8e5c-0b2c926e32fc', attrs: { first_name: 'jane', degree: 'IT', last_name: 'doe', *gpa: '1.2'* }, schema_id: 'Nf6LPd2QvDmzsyUm2EcRWq:2:Transcript:1.0', cred_def_id: 'Nf6LPd2QvDmzsyUm2EcRWq:3:CL:427:Result', rev_reg_id: null, cred_rev_id: null } ``` And I could successfully verify the proof with `verifierVerifyProof` method. I get verification even the p_value < 4, How this suppose to work? What am I missing here? (I am using NodeJS SDK)

arunwij (Fri, 02 Nov 2018 04:55:30 GMT):
Hi, I get a weird response when using predicates. I sent this proof request with this predicate. (I sent the proof request without restrictions [] is it okay? ) ``` 'requested_predicates': { 'predicate1_referent': { 'name': 'gpa', 'p_type': '>=', 'p_value': 4 } } ``` And the credential search result for the proof request (even thought credential gpa value is 1.2) ``` { referent: '2cd44a37-a585-4994-8e5c-0b2c926e32fc', attrs: { first_name: 'jane', degree: 'IT', last_name: 'doe', *gpa: '1.2'* }, schema_id: 'Nf6LPd2QvDmzsyUm2EcRWq:2:Transcript:1.0', cred_def_id: 'Nf6LPd2QvDmzsyUm2EcRWq:3:CL:427:Result', rev_reg_id: null, cred_rev_id: null } ``` And I could *successfully verify* the proof with `verifierVerifyProof` method. I get verification even the p_value < 4, How this suppose to work? What am I missing here? (I am using NodeJS SDK)

arunwij (Fri, 02 Nov 2018 04:55:30 GMT):
Hi, I get a weird response when using predicates. I sent this proof request with this predicate. (I sent the proof request without restrictions [] is it okay? ) ``` 'requested_predicates': { 'predicate1_referent': { 'name': 'gpa', 'p_type': '>=', 'p_value': 4 } } ``` And the credential search result for the proof request (even thought credential gpa value is 1.2) ``` { referent: '2cd44a37-a585-4994-8e5c-0b2c926e32fc', attrs: { first_name: 'jane', degree: 'IT', last_name: 'doe', *gpa: '1.2'* }, schema_id: 'Nf6LPd2QvDmzsyUm2EcRWq:2:Transcript:1.0', cred_def_id: 'Nf6LPd2QvDmzsyUm2EcRWq:3:CL:427:Result', rev_reg_id: null, cred_rev_id: null } ``` And I could *successfully verify* the proof with `verifierVerifyProof` method. I get verification even the gpa < 4, How this suppose to work? What am I missing here? (I am using NodeJS SDK)

arunwij (Fri, 02 Nov 2018 04:55:30 GMT):
Hi, I get a weird response when using predicates. I a proof request with this predicate. (I sent the proof request without restrictions: [ ] is it okay? ) ``` 'requested_predicates': { 'predicate1_referent': { 'name': 'gpa', 'p_type': '>=', 'p_value': 4 } } ``` And the credential search result for the proof request (even thought credential gpa value is 1.2) ``` { referent: '2cd44a37-a585-4994-8e5c-0b2c926e32fc', attrs: { first_name: 'jane', degree: 'IT', last_name: 'doe', *gpa: '1.2'* }, schema_id: 'Nf6LPd2QvDmzsyUm2EcRWq:2:Transcript:1.0', cred_def_id: 'Nf6LPd2QvDmzsyUm2EcRWq:3:CL:427:Result', rev_reg_id: null, cred_rev_id: null } ``` And I could *successfully verify* the proof with `verifierVerifyProof` method. I get verification even the gpa < 4, How this suppose to work? What am I missing here? (I am using NodeJS SDK)

arunwij (Fri, 02 Nov 2018 04:55:30 GMT):
Hi, I get a weird response when using predicates. I a proof request with this predicate. (I sent the proof request without `restrictions: [ ]` is it okay? ) ``` 'requested_predicates': { 'predicate1_referent': { 'name': 'gpa', 'p_type': '>=', 'p_value': 4 } } ``` And the credential search result for the proof request (even thought credential gpa value is 1.2) ``` { referent: '2cd44a37-a585-4994-8e5c-0b2c926e32fc', attrs: { first_name: 'jane', degree: 'IT', last_name: 'doe', *gpa: '1.2'* }, schema_id: 'Nf6LPd2QvDmzsyUm2EcRWq:2:Transcript:1.0', cred_def_id: 'Nf6LPd2QvDmzsyUm2EcRWq:3:CL:427:Result', rev_reg_id: null, cred_rev_id: null } ``` And I could *successfully verify* the proof with `verifierVerifyProof` method. I get verification even the gpa < 4, How this suppose to work? What am I missing here? (I am using NodeJS SDK)

arunwij (Fri, 02 Nov 2018 04:55:30 GMT):
Hi, I get a weird response when using predicates. I a proof request with this predicate. (I sent the proof request without `restrictions: []` is it okay? ) ``` 'requested_predicates': { 'predicate1_referent': { 'name': 'gpa', 'p_type': '>=', 'p_value': 4 } } ``` And the credential search result for the proof request (even thought credential gpa value is 1.2) ``` { referent: '2cd44a37-a585-4994-8e5c-0b2c926e32fc', attrs: { first_name: 'jane', degree: 'IT', last_name: 'doe', *gpa: '1.2'* }, schema_id: 'Nf6LPd2QvDmzsyUm2EcRWq:2:Transcript:1.0', cred_def_id: 'Nf6LPd2QvDmzsyUm2EcRWq:3:CL:427:Result', rev_reg_id: null, cred_rev_id: null } ``` And I could *successfully verify* the proof with `verifierVerifyProof` method. I get verification even the gpa < 4, How this suppose to work? What am I missing here? (I am using NodeJS SDK)

arunwij (Fri, 02 Nov 2018 04:55:30 GMT):
Hi, I get a weird response when using predicates. I a proof request with this predicate. (I sent the proof request without `restrictions: []` is it okay? ) ``` 'requested_predicates': { 'predicate1_referent': { 'name': 'gpa', 'p_type': '>=', 'p_value': 4 } } ``` And the credential search result for the proof request (even thought credential gpa value is 1.2) ``` { referent: '2cd44a37-a585-4994-8e5c-0b2c926e32fc', attrs: { first_name: 'jane', degree: 'IT', last_name: 'doe', *gpa: '1.2'* }, schema_id: 'Nf6LPd2QvDmzsyUm2EcRWq:2:Transcript:1.0', cred_def_id: 'Nf6LPd2QvDmzsyUm2EcRWq:3:CL:427:Result', rev_reg_id: null, cred_rev_id: null } ``` And I could *successfully verify* the proof with `verifierVerifyProof` method. I get verification even the gpa < 4, How this suppose to work? What am I missing here? (I am using NodeJS SDK v1.62)

arunwij (Fri, 02 Nov 2018 04:55:30 GMT):
Hi, I get a weird response when using predicates. I sent a proof request with this predicate. (I sent the proof request without `restrictions: []` is it okay? ) ``` 'requested_predicates': { 'predicate1_referent': { 'name': 'gpa', 'p_type': '>=', 'p_value': 4 } } ``` And the credential search result for the proof request (even thought credential gpa value is 1.2) ``` { referent: '2cd44a37-a585-4994-8e5c-0b2c926e32fc', attrs: { first_name: 'jane', degree: 'IT', last_name: 'doe', *gpa: '1.2'* }, schema_id: 'Nf6LPd2QvDmzsyUm2EcRWq:2:Transcript:1.0', cred_def_id: 'Nf6LPd2QvDmzsyUm2EcRWq:3:CL:427:Result', rev_reg_id: null, cred_rev_id: null } ``` And I could *successfully verify* the proof with `verifierVerifyProof` method. I get verification even the gpa < 4, How this suppose to work? What am I missing here? (I am using NodeJS SDK v1.62)

PhillipGibb (Fri, 02 Nov 2018 09:26:44 GMT):
wrote a sovrin lookup webapp that uses the sovrin test net: https://github.com/phillipgibb/sovrin_tools I'll setup an aws instance and run it there. Can look up dids, nyms, schemas, got an issue with credential definitions

swcurran (Fri, 02 Nov 2018 13:16:43 GMT):
You need to control a DID to sign the requests to get the transactions.

sklump (Fri, 02 Nov 2018 14:00:16 GMT):
@swcurran Not necessarily so: indy-sdk takes unsigned submissions for read-only transactions.

sklump (Fri, 02 Nov 2018 14:00:16 GMT):
@swcurran Vacuously true, but indy-sdk accepts unsigned submissions for read-only transactions.

MALodder (Fri, 02 Nov 2018 17:15:00 GMT):
is there an indy-crypto channel or is this it?

TammyPlatero (Fri, 02 Nov 2018 19:50:46 GMT):
Has joined the channel.

TammyPlatero (Fri, 02 Nov 2018 19:52:32 GMT):
Hi Guys, I am new here does anybody know where is the Documentation for the .NET wrapper for indy? the link in broken on https://github.com/hyperledger/indy-sdk/blob/master/wrappers/dotnet/README.md I downloaded the indy-sdk-dotnet and copied the libindy dlls but when I run the Samples solution I get a 307 error. I tried running as an administrator but then got a 306 error. Anyone have any tips or reference material to install the .net sdk?

TammyPlatero (Fri, 02 Nov 2018 19:53:00 GMT):
And run the Samples solution?

MALodder (Fri, 02 Nov 2018 22:11:43 GMT):
Just added a PR to Indy crypto to do all inequalities for predicates. See https://github.com/hyperledger/indy-crypto/pull/132

MALodder (Fri, 02 Nov 2018 22:12:09 GMT):
Once that’s merged I’ll raise a PR for the necessary changes in Indy-sdk to call it

Rowan_Shedden (Sat, 03 Nov 2018 03:18:33 GMT):
Has joined the channel.

Rowan_Shedden (Sat, 03 Nov 2018 03:22:41 GMT):
Hi, just joined ... I'm having trouble when performing a credential search .... I get inconsistent returns from the Libindy api call, sometimes it works just fine other times I get the Invalid Structure return code 113. I can submit the exact same input parameters running against the same wallet, yet the call will fail sometimes. There is no pattern to the failure. Has anyone come across a similar issue? And, is there a way to see the RUST debug logs, as that might help me figure it out?

dbluhm (Sat, 03 Nov 2018 18:53:43 GMT):
You should be able to see the debug output from Indy SDK by using `RUST_LOG=trace`

dbluhm (Sat, 03 Nov 2018 18:54:59 GMT):
This can be set for the all future processes run from your terminal by using the `export` command or set for just a single command by simply pretending `RUST_LOG=trace` to your command

swcurran (Sun, 04 Nov 2018 03:12:55 GMT):
Or prepending 😀

ShivVenkatraman (Mon, 05 Nov 2018 18:52:07 GMT):
Is it possible to build indy-node on Mac? I see instructions for libindy (and cli) for Mac; but none for the server component (indy-node; plenum etc.)

swcurran (Mon, 05 Nov 2018 18:56:26 GMT):
@ShivVenkatraman - no. Currently, indy-node only compiles for the Ubuntu 16.04 LTS platform. There are certain dependencies for the code that are only on that platform. This is a source of angst on the team and community, but it has not yet been addressed.

swcurran (Mon, 05 Nov 2018 18:57:59 GMT):
Docker is your friend if you want to run it locally. There is really no need to use anything other than docker for Indy work unless you are able to (you are a crypto guru) contribute to Indy-Node.

JamieLi (Mon, 05 Nov 2018 21:34:59 GMT):
Comparing indy_node/indy_client and indy_sdk, which is the recommended way? Looks like both works. It is hard to decide which way to go.

JamieLi (Mon, 05 Nov 2018 21:56:54 GMT):
I think I should use the indy-sdk.

dbluhm (Mon, 05 Nov 2018 23:20:37 GMT):
@JamieLi Indy-SDK is usually what people are looking for.

Rowan_Shedden (Tue, 06 Nov 2018 05:37:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=8b16779f-741e-4b60-95a5-00a82e239c53) @dbluhm Thanks, that got me the output I was looking for .... doesn't help with solving the problem :) but at least I now know the error, which is: Cannot deserialize ProofRequest: Error("Invalid structure: An OpenSSL error stack", line: 1, column: 578). Next step is to figure out what's causing that ......

xnopre (Tue, 06 Nov 2018 15:22:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=B9S5d8aad9vqfXHj6) @sklump Hi @sklump . Sorry for the delay of my reaction, and thanks for your answer. I'm using the NodeJS Wrapper. What can I use to generate this `encoded` values ? :-)

xnopre (Tue, 06 Nov 2018 15:25:13 GMT):
Where can I find samples for credential revocation ? I have read this page https://github.com/hyperledger/indy-sdk/blob/master/doc/cred-revocation.md. I have rewritten the Python script https://github.com/hyperledger/indy-sdk/blob/master/samples/python/src/anoncreds_revocation.py in NodeJS (I can share it with a pull request). But if I good understand, this script is for "no revocation", but I don't understand how I can revocate a credential. Thank you for any help :-)

sklump (Tue, 06 Nov 2018 16:22:43 GMT):
@xnopre, you must write your own encoding. An example of revocation is at indy-sdk/wrappers/python/tests/interation/test_interaction.py. It has not apparently made it to the nodejs tests, but the function calls ought to be about the same.

sklump (Tue, 06 Nov 2018 16:22:43 GMT):
@xnopre, you must write your own encoding or find an implementation. An example of revocation is at indy-sdk/wrappers/python/tests/interation/test_interaction.py. It has not apparently made it to the nodejs tests, but the function calls ought to be about the same.

sklump (Tue, 06 Nov 2018 16:22:43 GMT):
@xnopre, you must write your own encoding or find an implementation. At this point I have to recommend not using the one in von_anchor but a stringify-and-SHA-256 approach ought to work. An example of revocation is at indy-sdk/wrappers/python/tests/interation/test_interaction.py. It has not apparently made it to the nodejs tests, but the function calls ought to be about the same.

JamieLi (Tue, 06 Nov 2018 18:14:31 GMT):
@dbluhm Thanks for your response.

sklump (Tue, 06 Nov 2018 18:16:30 GMT):
Can someone tell me what the maximum encoded attribute value is for indy-sdk? What if it goes over 256 bits? I have heard in conversation that it will raise an exception, but haven't encountered one yet. Please, this could affect millions of credentials very soon.

JamieLi (Tue, 06 Nov 2018 19:00:44 GMT):
In the VCX demo, when Alice applies for a job at Acme, the "degree" of the proof-attributes is tagged by faber_transacript_cred_def_id. However, in real use case, shouldn't the degree be the credential schema that is accepted? ' {'name': 'degree', 'restrictions': [{'cred_def_id': faber_transcript_cred_def_id}]},

JamieLi (Tue, 06 Nov 2018 19:01:40 GMT):
It is strange that Acme would want the degree from Faber College specifically.

sklump (Tue, 06 Nov 2018 19:02:50 GMT):
A government issues (originates) the schema; the college issues the credential definition. I wouldn't worry about the example being contrived. It is possible to specify a restriction by schema id instead of cred def id if preferred.

JamieLi (Tue, 06 Nov 2018 19:08:30 GMT):
@sklump Thanks. That would make a lot of sense.

JamieLi (Tue, 06 Nov 2018 19:16:54 GMT):
What is the status of the indy-sdk Java wrapper? How is it compare to other wrappers, especially Python and NodeJS?

Rowan_Shedden (Tue, 06 Nov 2018 21:50:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=LsZqQtJcASuYp6zoy) @JamieLi Hi JamieLi, I've been using the Java wrapper quite successfully in a project I'm working on as a PoC. It doesn't have all the libindy API calls covered, but certainly enough of them have been implemented to be useful. I can't do a comparison against the other wrappers because I haven't used them, but there is less functionality available from what I can tell just by looking at the examples.

Rowan_Shedden (Tue, 06 Nov 2018 21:55:47 GMT):
Hi All, I seem to have stumbled upon a bug in the libindy api call "indy_prover_search_credentials_for_proof_req". If I send in proof request with certain nonce values in the message then it fails, other times, with different nonce values it works. Here's an example: This one works: 67dbd5ab-95e3-432c-8335-3639558bde57 This one doesn’t: d9ae652e-0c72-4f8d-baf8-26261f0418c6

JamieLi (Tue, 06 Nov 2018 21:57:40 GMT):
@Rowan_Shedden Thanks Rowan for sharing your experiences.

JamieLi (Tue, 06 Nov 2018 21:58:46 GMT):
Currently the libindy handles the encryption in wallet storage. Is there a way to disable the encryption and delegate the encryption to the wallet implementation?

ianco (Tue, 06 Nov 2018 22:24:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=8wLdjLLJLDFhicFbP) @JamieLi No

arunwij (Wed, 07 Nov 2018 09:52:35 GMT):
can we have one credential signed by multiple entities?

arunwij (Wed, 07 Nov 2018 09:52:35 GMT):
Can we have one credential signed by multiple entities?

haggs (Wed, 07 Nov 2018 10:08:01 GMT):
@Rowan_Shedden Taking a shot in the dark here but it could be due the wrong flow, check this reference to Anoncreds here: https://github.com/hyperledger/indy-sdk/blob/58c571f427e8db0cc7504b8bbda8024b18d5a2c1/doc/migration-guide-1.5.0-1.6.0.md#anoncreds-api

haggs (Wed, 07 Nov 2018 10:16:57 GMT):
Are you using this flow to open and then close? Not sure if it's using the `box` Search credentials for proof request - ```indy_prover_search_credentials_for_proof_req -> indy_prover_fetch_credentials_for_proof_req -> indy_prover_close_credentials_search_for_proof_req```

haggs (Wed, 07 Nov 2018 10:18:14 GMT):
search, fetch, then close might be the best flow? Are you using a wrapper or Rust?

haggs (Wed, 07 Nov 2018 10:20:50 GMT):
Curious to the answer when you find it!

LucW (Wed, 07 Nov 2018 10:43:33 GMT):
createWallet

xnopre (Wed, 07 Nov 2018 11:11:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mMm6PzcRidEJhYhYS) @sklump @sklump Thanks for your answers. For the encoding, what are the requirements ? I don't understood if there are some specifications to respect or implements ? In other words, can I push whatever in this fields ? Or are they checked or verified somewhere ?

Taaanos (Wed, 07 Nov 2018 11:12:04 GMT):
Has left the channel.

xnopre (Wed, 07 Nov 2018 11:13:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mMm6PzcRidEJhYhYS) @sklump Thanks for the link to the script, I will take a look, and perhaps rewrite it in NodeJS....

sklump (Wed, 07 Nov 2018 11:48:56 GMT):
@xnopre 32-bit integers must encode to their decimal string representations; e.g., -1234 -> '-1234', '42' -> '42'. Otherwise, I believe ZKP requires encodings to fit into (stringified) 256-bit integers but as you can see above, nobody really appears to know. It is an underdeveloped facet of the sdk. The von_anchor project has had a 3 or 4 codecs over its short life, and promises to evolve yet another soon.

sklump (Wed, 07 Nov 2018 11:48:56 GMT):
@xnopre 32-bit integers must encode to their decimal string representations; e.g., -1234 -> '-1234', '42' -> '42'. Otherwise, I believe ZKP requires encodings to fit into (stringified) 256-bit integers but as you can see above, nobody really appears to know. It is an underdeveloped facet of the sdk. The von_anchor project has had 3 or 4 codecs over its short life, and promises to evolve yet another soon.

sklump (Wed, 07 Nov 2018 11:48:56 GMT):
@xnopre 32-bit integers must encode to their decimal string representations; e.g., -1234 -> '-1234', 42 -> '42'. Otherwise, I believe ZKP requires encodings to fit into (stringified) 256-bit integers but as you can see above, nobody really appears to know. It is an underdeveloped facet of the sdk. The von_anchor project has had 3 or 4 codecs over its short life, and promises to evolve yet another soon.

swcurran (Wed, 07 Nov 2018 15:28:09 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Gh3GzLYfK4W8eowvh) @arunwij No. A credential is issued related to a single DID and hence a single identity. What/Who is behind that identity is use case specific.

solocez (Wed, 07 Nov 2018 15:58:37 GMT):
Has joined the channel.

solocez (Wed, 07 Nov 2018 16:02:50 GMT):
Hello, it' s related to *iOS Indy SDK *. Is't stable and ready to use ? I tried an approach described here - " https://github.com/hyperledger/indy-sdk/blob/master/wrappers/ios/README.md" - via cocapods - it does not work. Getting an error: "_Unable to find a specification for `libindy-objc`_"

solocez (Wed, 07 Nov 2018 19:16:48 GMT):
@wangdong Hi, I do the same as, i guess , you do - trying to build iOS framework of Indy. Were your attempts successful? What were your steps? I try to build universal Indy.framework: cd /indy-sdk/wrappers/ios/libindy-pod pod install But getting an error: "Unable to find a specification for `libindy (= 1.6.1)`" .

solocez (Wed, 07 Nov 2018 19:20:17 GMT):
@sergey.minaev Hello, I deal with iOS wrapper of Indy: do you have any up to date description of how to build framework? Steps from "https://github.com/hyperledger/indy-sdk/blob/master/wrappers/ios/README.md" do not work. Neither "How to install", nor "How to build" (build-libindy-core-ios.sh is not present anymore) (ios-build.sh -does not work as well. it requires some parameter - i do not know wich).

wangdong (Thu, 08 Nov 2018 01:42:32 GMT):
@solocez I can help you. The readme is not complete.

wangdong (Thu, 08 Nov 2018 01:43:24 GMT):
But I do not succeed either because of the some other issue, version conflict I can say.

wangdong (Thu, 08 Nov 2018 01:43:42 GMT):
Or I will update the readme.

wangdong (Thu, 08 Nov 2018 01:50:25 GMT):
You can refer to the Jenkins.CI file. There is a segment about iOS test.

wangdong (Thu, 08 Nov 2018 01:50:35 GMT):
you will find what you need.

wangdong (Thu, 08 Nov 2018 01:59:54 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/Jenkinsfile.ci#L160

LucW (Thu, 08 Nov 2018 09:15:35 GMT):
Hi guys. Trying to setup the how-tos first step (creating DID and get Verkey). I code won't connect to the ledger. I suspect it to be my pool configuration. So, my docker runs on 0.0.0.0:9701->9708, but my configuration says that *node_ip* is 10.0.0.2 etc. I think this conf was generated by the "create_pool_ledger_config", so it must be able to set the nodes IPs, right ? I would appreciate to have a ref for the python wrapper. Thanks.

LucW (Thu, 08 Nov 2018 09:57:13 GMT):
It works fine when I edit myself

LucW (Thu, 08 Nov 2018 09:57:13 GMT):
It works fine when I edit myself *docker_pool_transaction_genesis* with the IP addresses of the docker. But I wonder why the default is set to 10.0.0.2 ? And how to edit it from code/config instead of editting the file afterwards ?

LucW (Thu, 08 Nov 2018 10:02:25 GMT):
Also, I wonder what a *verkey* usually refers to. Is this a private key ? The master key of the DID ?

mxs1491 (Thu, 08 Nov 2018 10:41:15 GMT):
Has joined the channel.

sergey.minaev (Thu, 08 Nov 2018 11:44:20 GMT):
@solocez you have to add our podspec repo in your system and specify source in podfile (source 'https://github.com/hyperledger/indy-sdk.git') do not forget `pod repo update` and other commands related to fetching podspecs

sergey.minaev (Thu, 08 Nov 2018 11:44:20 GMT):
@solocez you have to add our podspec repo in your system (command to check `pod repo list`) and specify source in podfile (source 'https://github.com/hyperledger/indy-sdk.git') do not forget `pod repo update` and other commands related to fetching podspecs

sergey.minaev (Thu, 08 Nov 2018 11:47:40 GMT):
@LucW 10.0.0.2 is just example from our CI our docker image allows to specify IP as build parameter while `docker build` https://github.com/hyperledger/indy-sdk/blob/master/ci/indy-pool.dockerfile#L88

sergey.minaev (Thu, 08 Nov 2018 11:49:41 GMT):
3 typical cases are described in main readme https://github.com/hyperledger/indy-sdk#1-starting-the-test-pool-on-localhost

LucW (Thu, 08 Nov 2018 13:15:52 GMT):
Ok, thanks. Another remark, the *negotiate_proof.py* how-to part is not up-to date. ( https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/negotiate-proof/python/README.md )

sklump (Thu, 08 Nov 2018 16:35:23 GMT):
@LucW I believe that the anchor uses the private signing key corresponding to the verification key (*verkey*) to sign those transactions to the node pool that require signatures. The nodes use the verification key to verify that the anchor signed such transactions.

sklump (Thu, 08 Nov 2018 16:35:23 GMT):
@LucW I believe that the anchor uses the private signing key corresponding to the verification key ( *verkey* ) to sign those transactions to the node pool that require signatures. The nodes use the verification key to verify that the anchor signed such transactions.

solocez (Thu, 08 Nov 2018 17:50:59 GMT):
@wangdong @sergey.minaev thanks . that helped me a lot. seems i ve built Indy.framework successfully.

baconsandwich (Thu, 08 Nov 2018 18:20:18 GMT):
After I stored a a schema to the ledger using `indy.ledger.sign_and_submit_request()`, is it my responsibility to store it? Or else how can I retreive all available schemas?

sklump (Thu, 08 Nov 2018 18:44:58 GMT):
I was looking for the PR that broadened predicates from GE to include GT, LT, LE, NE -- it's gone and not apparently merged: did the team retract this PR? Was it not the right time to put this in the indy-sdk? Any idea what happened to it? Or was it all just a vivid dream?

sklump (Thu, 08 Nov 2018 18:44:58 GMT):
I was looking for the PR that broadened predicates from GE to include GT, LT, LE, ~NE~ -- it's gone and not apparently merged: did the team retract this PR? Was it not the right time to put this in the indy-sdk? Any idea what happened to it? Or was it all just a vivid dream?

jljordan_bcgov (Thu, 08 Nov 2018 19:06:22 GMT):
https://github.com/hyperledger/indy-crypto/pull/132 ... looks like it was merged 20 mins ago

kannancet (Thu, 08 Nov 2018 20:53:33 GMT):
Has joined the channel.

kannancet (Thu, 08 Nov 2018 20:55:39 GMT):
Hello everyone, I am getting started with indy-sdk. Go stuck at `OSError: dlopen(libindy.dylib, 6): image not found` trying to run python boilerplate script for creating DIDs. Any help would be appreciated.

baconsandwich (Thu, 08 Nov 2018 21:10:52 GMT):
@kannancet looks like an OS problem to me and not something related to undy

baconsandwich (Thu, 08 Nov 2018 21:10:52 GMT):
@kannancet looks like an OS problem to me and not something related to indy

kdenhartog (Thu, 08 Nov 2018 21:11:05 GMT):
@kannancet I believe this is an issue caused by not having the IndySDK binaries installed properly. If you want to get setup and play with the IndySDK quickly checkout this repo I built around a docker image to run indySDK in. https://github.com/kdenhartog/Indy-dev

kdenhartog (Thu, 08 Nov 2018 21:15:58 GMT):
@LucW give that repo I linked to above a try and let me know how it works. I'm still working on improving it some.

kannancet (Thu, 08 Nov 2018 21:19:49 GMT):
@kdenhartog - Thanks for the repo. I tried the docker image you suggested. `make start` takes me inside this terminal `indy@linuxkit-025000000001:~$`. If I want to run the python client script for interacting with the ledger should I run it from inside this terminal or in a new terminal ?

kdenhartog (Thu, 08 Nov 2018 21:21:41 GMT):
yea inside the one indy@....

kdenhartog (Thu, 08 Nov 2018 21:21:55 GMT):
that's the docker image with the environment built

kannancet (Thu, 08 Nov 2018 22:11:30 GMT):
@kdenhartog - Thanks for the instructions. ``` _indy_loop_callback: Function returned error 113 Error occurred: ErrorCode.CommonInvalidStructure ```

kannancet (Thu, 08 Nov 2018 22:11:30 GMT):
@kdenhartog - Thanks for the instructions. Stuck here now. ``` _indy_loop_callback: Function returned error 113 Error occurred: ErrorCode.CommonInvalidStructure ```

ShivVenkatraman (Thu, 08 Nov 2018 22:12:55 GMT):
I am running the vcx faber-Alice example at https://github.com/hyperledger/indy-sdk/tree/master/vcx/wrappers/python3/demo. While I am able to run it, I am curious where the schema is created. Isn't it supposed to be created on the ledger? I looked at the files in /var/lib/indy/sandbox/data/Node1..4; and none of the files there had the timestamp updated

baconsandwich (Thu, 08 Nov 2018 22:53:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=yFdv49hd9bkNR5m3d) @kannancet you probalby passing an invalid JSON structure

baconsandwich (Thu, 08 Nov 2018 22:53:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qa27a4mTEYzHqkiQQ) anyone has an idea regarding this?

haggs (Fri, 09 Nov 2018 01:29:56 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=yFdv49hd9bkNR5m3d) @kannancet Hey Kannancet I think that's some residual error, I remember running into it. What step were you at when you got there?

haggs (Fri, 09 Nov 2018 01:29:56 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=yFdv49hd9bkNR5m3d) @kannancet Hey Kannancet I think that's some residual error from a PR that doesn't cleanup ```_pycache_```, I remember running into it. What step were you at when you got there?

haggs (Fri, 09 Nov 2018 01:41:06 GMT):
In the meantime, doing an ```rm -rf .indy_client``` in the main directory should help as well as ```python/src/__pycache__``` deletion as well

haggs (Fri, 09 Nov 2018 01:41:06 GMT):
In the meantime, doing an `rm -rf .indy_client` in the main directory should help as well as ```python/src/__pycache__``` deletion as well

haggs (Fri, 09 Nov 2018 03:23:43 GMT):
Or, if you run the getting started guide make sure to cleanup and restart it all when doing the how-to's @kannancet

ShivVenkatraman (Fri, 09 Nov 2018 06:52:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9LwCusqAeimZeTe6p) @swcurran Can you please point me to the docker link for macos (both for indy node and and libindy)? I was looking at https://github.com/hyperledger/indy-sdk/blob/master/ci/indy-pool.dockerfile but that seems to Ubuntu specific (no apt-get on Mac)

faisal00813 (Fri, 09 Nov 2018 07:36:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=f4Df7kba9Go8u7cNP) @ShivVenkatraman @ShivVenkatraman Those commands (apt-get) executes on linux inside docker. You will have to install docker on OSX and can use the same dockerfile on it.

faisal00813 (Fri, 09 Nov 2018 07:36:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=f4Df7kba9Go8u7cNP) @ShivVenkatraman Those commands (apt-get) executes on linux inside docker. You will have to install docker on OSX and can use the same dockerfile on it.

LucW (Fri, 09 Nov 2018 09:32:16 GMT):
@kdenhartog I haven't dwelved into the details, but so far I've got it running like a charm, and it might be really useful sometimes to perform quick tests. I wonder why it works with python3.5 where in the hyperledger repo it's written that the wrapper needs python3.6

haggs (Fri, 09 Nov 2018 10:04:31 GMT):
@LucW actually that should be revisited, https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.dockerfile still uses 3.5 so i think that's why

haggs (Fri, 09 Nov 2018 10:06:35 GMT):
and getting started is somewhat of a litmus test for the env, however with the how-tos or general wrapper stuff that isn't good

haggs (Fri, 09 Nov 2018 10:06:35 GMT):
and gettingstarted.py is somewhat of a litmus test for the env and takes you through the whole process, however I can see with later and greater version increases we might need to lock down the version of libindy.

haggs (Fri, 09 Nov 2018 10:06:35 GMT):
and getting started is somewhat of a litmus test for the env, however with the how-tos or general wrapper stuff that isn't good

LucW (Fri, 09 Nov 2018 10:36:28 GMT):
Ok, I see. Another big issue with this project is the lack of API reference. Maybe for now it's evolving too fast to be able to setup a fixed documentation ?

haggs (Fri, 09 Nov 2018 13:56:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=SxpZkKpraSmiTdmwR) @LucW I'd say this project is interesting in that there are a lot of conceptual things to understand until the API's make sense, whereas traditionally you might know all the CRUD operations an API might have. So a lot of how-to's https://github.com/hyperledger/indy-sdk/tree/master/doc/how-tos (lots of content there) really help understand the concepts a lot, understanding the jargon, and agreed it's quite quick with lots of development. Here are some things that might help: https://wiki.hyperledger.org/projects/indy (the definite go-to and drop-off point) and this video https://www.youtube.com/watch?v=RllH91rcFdE.

haggs (Fri, 09 Nov 2018 13:58:02 GMT):
I'm fairly new so that's my limited opinion. Definitely evolving quickly!

haggs (Fri, 09 Nov 2018 14:00:20 GMT):
Questions asked, in my experience, no matter what skill level you are extremely egalitarian and supportive. A definite bonus!

LucW (Fri, 09 Nov 2018 15:24:59 GMT):
@haggs Thanks. I've been looking at the how-tos recently, and it's indeed working well, except for some steps: negotiate_proof.py is currently not up-to-date

haggs (Fri, 09 Nov 2018 15:26:58 GMT):
Thanks for the update! Would you mind filing an issue in the repo with your parts that aren't working in detail? Would really appreciate that as these things are hard to reproduce sometimes. Will address them

LucW (Fri, 09 Nov 2018 15:32:13 GMT):
@haggs I'd love to, but I don't see the "issue" tab in the indy-sdk repo. Am I missing something ?

haggs (Fri, 09 Nov 2018 15:33:15 GMT):
Ahh thought you were in the Indy-dev repo, actually just go ahead and post it to me or make a google doc if you have the time

haggs (Fri, 09 Nov 2018 15:34:29 GMT):
are you doing python wrapper?

haggs (Fri, 09 Nov 2018 15:35:31 GMT):
if so would you mind posting this: `docker -v; docker-compose -v; pip -V;python --version;` result for some context?

LucW (Fri, 09 Nov 2018 15:36:11 GMT):
I'm using the Python Wrapper indeed

haggs (Fri, 09 Nov 2018 15:36:34 GMT):
Awesome!

LucW (Fri, 09 Nov 2018 15:37:15 GMT):
https://gyazo.com/bdd0f0a9ab7cb402c0fd253dd17e8bbf

LucW (Fri, 09 Nov 2018 15:40:01 GMT):
@haggs So basically, when I recreate the file negotiate_proof.py using step2, step3 etc., and then run it (with python3.6 as you saw), I get an error on create_wallet() (takes 2 positional arguments but 5 were given). So I assume this code is still using an old version of the wrapper.

LucW (Fri, 09 Nov 2018 15:40:41 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/negotiate-proof/python/step2.py See *line 4* for example

LucW (Fri, 09 Nov 2018 15:43:42 GMT):
I tried to modify the method to match the ones from the previous how-tos (which all work with only minor fixes such as the genesis file path), but I couldn't get a grasp on how the wallet config should be built.

MALodder (Fri, 09 Nov 2018 15:55:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=cfmB6her7RR4QovYp) @sklump It was merged. I'm working to submit the PR to take advantage of this in indy-sdk right now

sklump (Fri, 09 Nov 2018 19:21:48 GMT):
@MALodder thanks, my next feature will support all of them in von_anchor as well.

stanleyc-trustscience (Fri, 09 Nov 2018 19:25:08 GMT):
hi guys, regarding non_secrets API ... what are example of non_secret data that we'd want to store in the wallet?

stanleyc-trustscience (Fri, 09 Nov 2018 19:25:08 GMT):
hi guys, I notice non_secrets API is added ... what are example of non_secret data that we'd want to store in the wallet?

stanleyc-trustscience (Fri, 09 Nov 2018 19:33:01 GMT):
hmm rather, what's the security around non_secret record stored on the wallet?

stanleyc-trustscience (Fri, 09 Nov 2018 19:42:15 GMT):
Ah nevermind, the doc explains ... (answering my own question :) ) https://github.com/vimmerru/indy-sdk/blob/9579a87832c7bb4ceb0ae6a4f2beac04b98f082e/doc/design/wallet/wallet-components.puml

stanleyc-trustscience (Fri, 09 Nov 2018 19:42:15 GMT):
Ah nevermind, the doc explains ... https://github.com/vimmerru/indy-sdk/blob/9579a87832c7bb4ceb0ae6a4f2beac04b98f082e/doc/design/wallet/wallet-components.puml

ShivVenkatraman (Fri, 09 Nov 2018 20:57:37 GMT):
I am running the indy cli commands using the examples in https://github.com/hyperledger/indy-sdk/tree/master/doc/design/001-cli. While the did is getting successfully created with the did new command (Did "5uHge2j4S91WErEtPgKJSt" has been created with "~BCX68TCXJf6o6bpnvGgXbj” verkey); sending the did to ledger gives an error " ledger nym did=5uHge2j4S91WErEtPgKJSt verkey=~BCX68TCXJf6o6bpnvGgXbj Transaction has been rejected: Can not find verkey for 5uHge2j4S91WErEtPgKJSt"

MALodder (Fri, 09 Nov 2018 22:52:19 GMT):
Is there a way to start the pool in the getting started guide with log output set to DEBUG?

MALodder (Fri, 09 Nov 2018 22:53:31 GMT):
I need to see the formatted messages in raw JSON

stanleyc-trustscience (Fri, 09 Nov 2018 23:02:45 GMT):
@ShivVenkatraman You will need to be TRUST_ANCHOR or some other privileged role to submit NYM request I believe

kannancet (Sun, 11 Nov 2018 04:20:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=dmyE7WRJNx2ogaYwx) @haggs @haggs - This didn't help. Still same issue

haggs (Mon, 12 Nov 2018 02:18:58 GMT):
@kannancet When are you free? happy to jump on a call with you tomorrow to help

JamieLi (Mon, 12 Nov 2018 07:09:34 GMT):
I got the following error "indy.error.IndyError: ErrorCode.PoolIncompatibleProtocolVersion" when calling "pool.open_pool_ledger(pool_name, None)". Any pointers/

JamieLi (Mon, 12 Nov 2018 07:09:37 GMT):
?

JamieLi (Mon, 12 Nov 2018 07:10:58 GMT):
Cannot figure out where to set the protocol version correctly.

JamieLi (Mon, 12 Nov 2018 07:21:20 GMT):
nvm. I am using version 1.6.x. I set the protocol_version to "2" and the error goes away.

kdenhartog (Mon, 12 Nov 2018 15:25:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=yFdv49hd9bkNR5m3d) @kannancet If that's in how-to #5 i still need to fix it. If it's in another one please file an issue on the repo so I can track it and fix it.

kdenhartog (Mon, 12 Nov 2018 15:26:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=XHSruFyLfS8zparQs) @LucW Good point I'll add that update to the docker file.

kdenhartog (Mon, 12 Nov 2018 15:31:59 GMT):
@LucW the issue with negotiate_proof is because I haven't been able to figure out the new APIs yet for finishing it. I'm working through comparing it to the getting started guide to see where I'm submitting bad data because it's been updated by this how to hasn't been yet.

smithbk (Mon, 12 Nov 2018 16:36:28 GMT):
Hi, I have a very basic revocation question. Who is allowed to revoke a credential? Only the issuer ... or are other identities allowed and if so, who? Thanks

swcurran (Mon, 12 Nov 2018 16:41:37 GMT):
Only the issuer at this point.

LucW (Mon, 12 Nov 2018 16:43:59 GMT):
Basically look for the "DEPRECATED" comment, and from that point it's not working. I will try to adapt it using your getting_started.py but it's shaped in a different way so I might have trouble dealing with it.

smithbk (Mon, 12 Nov 2018 16:44:27 GMT):
@swcurran thanks

LucW (Mon, 12 Nov 2018 16:46:15 GMT):
@kdenhartog your getting_started.py seems to use the latest py API version, isn't it ?

kdenhartog (Mon, 12 Nov 2018 16:58:38 GMT):
Yeah the getting_started.py does, where as the how-tos haven't been fully updated yet.

haggs (Mon, 12 Nov 2018 18:29:52 GMT):
@kdenhartog See any value in switching the latest version to stable instead of master?

kdenhartog (Mon, 12 Nov 2018 18:39:28 GMT):
@haggs I don't believe so, but it's worth trying.

haggs (Mon, 12 Nov 2018 18:40:29 GMT):
Ok just seeing that new commoninvalidstate

JamieLi (Mon, 12 Nov 2018 19:18:17 GMT):
In the test_ledger.py:34, the "my_did" was created with the "seed_trustee1". It was later used as the submitter_did to write a NYM for the user_did. Shouldn't we use the "seed_steward1" insstead?

JamieLi (Mon, 12 Nov 2018 19:18:24 GMT):
# 6. Create Their DID from Trustee1 seed (their_did, their_verkey) = await did.create_and_store_my_did(their_wallet_handle, json.dumps({"seed": seed_trustee1}))

mhailstone (Mon, 12 Nov 2018 20:56:09 GMT):
Is it possible to issue a credential to myself (the creator of the credential definition)? Here is the sequence that I'm thinking: ```sdk.issuerCreateCredentialOffer sdk.proverCreateCredentialReq sdk.issuerCreateCredential``` When creating the credential request, would I just put in the DID that created the credential definition?

mhailstone (Mon, 12 Nov 2018 20:57:51 GMT):
If I create an identity credential, like a verifiable student ID credential, I'd like to create an ID credential for BYU so that the student's can do a proof against BYU's enterprise agent to know that it's BYU. Maybe I'm missing the correct business scenario, though.

JamieLi (Tue, 13 Nov 2018 01:11:12 GMT):
How do I get the list of schemas created under an issuer?

JamieLi (Tue, 13 Nov 2018 01:15:41 GMT):
From the ledger...

mhailstone (Tue, 13 Nov 2018 04:39:03 GMT):
This actually worked: ``` let endpointDID = await indy.did.getEndpointDid(); let wallet = await indy.wallet.get(); let pool = await indy.pool.get(); let credentialOffer = await sdk.issuerCreateCredentialOffer(wallet, credentialDefinitionId); try { credentialOffer.data = JSON.parse(credentialData); } catch (e) { credentialOffer.data = {}; console.log(e); } let [, credentialDefinition] = await indy.issuer.getCredDef(pool, endpointDID, credentialOffer.cred_def_id); let masterSecretId = await indy.did.getEndpointDidAttribute('master_secret_id'); let [credRequestJson, credRequestMetadataJson] = await sdk.proverCreateCredentialReq(wallet, endpointDID, credentialOffer, credentialDefinition, masterSecretId); let schema = await indy.issuer.getSchema(credentialOffer.schema_id); let credentialValues = {}; for (let attr of schema.attrNames) { if (credentialOffer.data[attr]) { credentialValues[attr] = {raw: credentialOffer.data[attr], encoded: indy.credentials.encode(credentialOffer.data[attr])}; } } let [credential] = await sdk.issuerCreateCredential(wallet, credentialOffer, credRequestJson, credentialValues); await sdk.proverStoreCredential(wallet, null, credRequestMetadataJson, credential, credentialDefinition); ```

danielhardman (Tue, 13 Nov 2018 05:37:52 GMT):
I have proposed a HIPE for conventions around how to enable message tracing, for troubleshooting purposes: https://github.com/hyperledger/indy-hipe/pull/60

JamieLi (Tue, 13 Nov 2018 07:13:52 GMT):
Hi, there, I think I hit a bug. I have the following code:`submitter_did = 'V4SGRU86Z58d6TV7PBUe6f' schema_json='{"ver":"1.0","id":"HHN1CvBEWdvokHnCCqsdyR:2:deploma_v9:1.0","name":"deploma_v9","version":"1.0","attrNames":["height","age","sex","name"],"seqNo":null}' schema_request = await ledger.build_schema_request(submitter_did, schema_json) `

JamieLi (Tue, 13 Nov 2018 07:14:13 GMT):
``submitter_did = 'V4SGRU86Z58d6TV7PBUe6f' schema_json='{"ver":"1.0","id":"HHN1CvBEWdvokHnCCqsdyR:2:deploma_v9:1.0","name":"deploma_v9","version":"1.0","attrNames":["height","age","sex","name"],"seqNo":null}' schema_request = await ledger.build_schema_request(submitter_did, schema_json) ``

JamieLi (Tue, 13 Nov 2018 07:14:49 GMT):
After execution, the schema_request has the following result.

JamieLi (Tue, 13 Nov 2018 07:15:03 GMT):
`schema_request='{"reqId":1542093016767998141,"identifier":"V4SGRU86Z58d6TV7PBUe6f","operation":{"type":"101","data":{"name":"deploma_v9","version":"1.0","attr_names":["age","sex","height","name"]}},"protocolVersion":2}'`

JamieLi (Tue, 13 Nov 2018 07:15:38 GMT):
Shouldn't it has {"id": "HHN1CvBEWdvokHnCCqsdyR:2:deploma_v9:1.0"} in the operation?

JamieLi (Tue, 13 Nov 2018 07:16:19 GMT):
``` submitter_did = 'V4SGRU86Z58d6TV7PBUe6f' schema_json='{"ver":"1.0","id":"HHN1CvBEWdvokHnCCqsdyR:2:deploma_v9:1.0","name":"deploma_v9","version":"1.0","attrNames":["height","age","sex","name"],"seqNo":null}' schema_request = await ledger.build_schema_request(submitter_did, schema_json) ```

JamieLi (Tue, 13 Nov 2018 07:16:30 GMT):
Result is

JamieLi (Tue, 13 Nov 2018 07:16:50 GMT):
``` schema_request='{"reqId":1542093016767998141,"identifier":"V4SGRU86Z58d6TV7PBUe6f","operation":{"type":"101","data":{"name":"deploma_v9","version":"1.0","attr_names":["age","sex","height","name"]}},"protocolVersion":2}' ```

JamieLi (Tue, 13 Nov 2018 07:17:08 GMT):
Shouldn't it expect something like:

JamieLi (Tue, 13 Nov 2018 07:17:42 GMT):
``` schema_request='{"reqId":1542093016767998141,"identifier":"V4SGRU86Z58d6TV7PBUe6f","operation":{"type":"101","data":{"id": "HHN1CvBEWdvokHnCCqsdyR:2:deploma_v9:1.0", "name":"deploma_v9","version":"1.0","attr_names":["age","sex","height","name"]}},"protocolVersion":2}' ```

JamieLi (Tue, 13 Nov 2018 07:17:56 GMT):
Please help.

JamieLi (Tue, 13 Nov 2018 07:28:43 GMT):
I cannot get the issuer ID written to the ledger. It always uses the Trustee ID as part of the schema_id.

vuthy-bronx (Tue, 13 Nov 2018 09:27:32 GMT):
Has joined the channel.

neilb14 (Tue, 13 Nov 2018 16:52:14 GMT):
Has joined the channel.

smithbk (Tue, 13 Nov 2018 18:28:36 GMT):
Hi, I'm trying to debug a performance issue. Is there any way to get timestamps in the indy logs? I'm setting `RUST_LOG=indy=trace` but no timestamps. Thanks

vuthy-bronx (Wed, 14 Nov 2018 06:52:18 GMT):
Hello, I'm new to indy-sdk. I'm trying to install indy-sdk by run: npm install --save indy-sdk and it shows errors as the screenshot

vuthy-bronx (Wed, 14 Nov 2018 06:53:14 GMT):

Screen Shot 2018-11-14 at 1.49.49 PM.png

vuthy-bronx (Wed, 14 Nov 2018 06:53:19 GMT):
any help please?

vuthy-bronx (Wed, 14 Nov 2018 09:27:53 GMT):
Hello all, I got an error after I run npm install inside indy-sdk/samples/nodejs/

vuthy-bronx (Wed, 14 Nov 2018 09:27:53 GMT):
Hello all, I got an error after I run npm install inside indy-sdk/samples/nodejs/ Note: I'm using macOS high Sierra and already have libindy.dylib at /usr/local/lib/libindy.dylib

vuthy-bronx (Wed, 14 Nov 2018 09:28:54 GMT):

Screen Shot 2018-11-14 at 4.24.45 PM.png

vuthy-bronx (Wed, 14 Nov 2018 09:42:43 GMT):
Any help please?

sklump (Wed, 14 Nov 2018 15:25:18 GMT):
... and so I've got indy-sdk to raise a ``` ERROR | indy.libindy.native.indy.errors.indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid structure: Credential attribute value ""34085183419374667633983612413781562793959748668700133102342892695969246381675"" is invalid: ParseIntError { kind: Overflow } indy.error.IndyError: ErrorCode.CommonInvalidStructure ``` on an attribute value encoding as above, which is exactly 255 bits: `log(34085183419374667633983612413781562793959748668700133102342892695969246381675)/log(2) = 254.23567995794204`. Does anyone actually know what the limit is? I need an answer to this before my main client can re-issue over a million credentials on the updated SLN. +1 to all for having updated the SLN, by the way.

sklump (Wed, 14 Nov 2018 15:25:18 GMT):
... and so I've got indy-sdk to raise a ``` ERROR | indy.libindy.native.indy.errors.indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid structure: Credential attribute value ""34085183419374667633983612413781562793959748668700133102342892695969246381675"" is invalid: ParseIntError { kind: Overflow } indy.error.IndyError: ErrorCode.CommonInvalidStructure ``` on an attribute value encoding as above, which is exactly 255 bits: `log(34085183419374667633983612413781562793959748668700133102342892695969246381675)/log(2) = 254.23567995794204`. Incredible dumb luck on my part. Does anyone actually know what the limit is? I need an answer to this before my main client can re-issue over a million credentials on the updated SLN. +1 to all for having updated the SLN, by the way.

sklump (Wed, 14 Nov 2018 15:25:18 GMT):
... and so I've got indy-sdk to raise a ``` ERROR | indy.libindy.native.indy.errors.indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid structure: Credential attribute value ""34085183419374667633983612413781562793959748668700133102342892695969246381675"" is invalid: ParseIntError { kind: Overflow } indy.error.IndyError: ErrorCode.CommonInvalidStructure ``` on an attribute value encoding as above, which is exactly 255 bits: `log(34085183419374667633983612413781562793959748668700133102342892695969246381675)/log(2) = 254.23567995794204`. Incredible dumb luck on my part. Does anyone actually know what the limit is? I need an answer to this before my main client can re-issue over a million credentials on the updated SLN. +1 to all for having updated the SLN, by the way. *ADDENDUM*: I've got another one on 12736901970554440943707562975236300314230782205582167042352380138466, which is 223 bits.

sklump (Wed, 14 Nov 2018 17:22:30 GMT):
Hello, the current master of indy-sdk doesn't cargo build: ``` sklump@ubu102:~/indy-sdk/libindy$ RUST_BACKTRACE=1 cargo build --release Compiling openssl v0.9.24 error: failed to run custom build command for `openssl v0.9.24` process didn't exit successfully: `/home/sklump/indy-sdk/libindy/target/release/build/openssl-d95cc14a80be27c4/build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'Unable to detect OpenSSL version', /home/sklump/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/build.rs:16:14 stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49 1: std::sys_common::backtrace::print at libstd/sys_common/backtrace.rs:71 at libstd/sys_common/backtrace.rs:59 2: std::panicking::default_hook::{{closure}} at libstd/panicking.rs:211 3: std::panicking::default_hook at libstd/panicking.rs:227 4: std::panicking::rust_panic_with_hook at libstd/panicking.rs:511 5: std::panicking::begin_panic 6: build_script_build::main 7: std::rt::lang_start::{{closure}} 8: std::panicking::try::do_call at libstd/rt.rs:59 at libstd/panicking.rs:310 9: __rust_maybe_catch_panic at libpanic_unwind/lib.rs:105 10: std::rt::lang_start_internal at libstd/panicking.rs:289 at libstd/panic.rs:392 at libstd/rt.rs:58 11: main 12: __libc_start_main 13: _start ``` Any advice?

sklump (Wed, 14 Nov 2018 17:22:30 GMT):
Hello, the current master of indy-sdk doesn't cargo build: ``` error: failed to run custom build command for `openssl v0.9.24` process didn't exit successfully: `/home/sklump/indy-sdk/libindy/target/release/build/openssl-d95cc14a80be27c4/build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'Unable to detect OpenSSL version', /home/sklump/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/build.rs:16:14 note: Run with `RUST_BACKTRACE=1` for a backtrace. sklump@ubu102:~/indy-sdk/libindy$ RUST_BACKTRACE=1 cargo build --release Compiling openssl v0.9.24 error: failed to run custom build command for `openssl v0.9.24` process didn't exit successfully: `/home/sklump/indy-sdk/libindy/target/release/build/openssl-d95cc14a80be27c4/build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'Unable to detect OpenSSL version', /home/sklump/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/build.rs:16:14 stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49 1: std::sys_common::backtrace::print at libstd/sys_common/backtrace.rs:71 at libstd/sys_common/backtrace.rs:59 2: std::panicking::default_hook::{{closure}} at libstd/panicking.rs:211 3: std::panicking::default_hook at libstd/panicking.rs:227 4: std::panicking::rust_panic_with_hook at libstd/panicking.rs:511 5: std::panicking::begin_panic 6: build_script_build::main 7: std::rt::lang_start::{{closure}} 8: std::panicking::try::do_call at libstd/rt.rs:59 at libstd/panicking.rs:310 9: __rust_maybe_catch_panic at libpanic_unwind/lib.rs:105 10: std::rt::lang_start_internal at libstd/panicking.rs:289 at libstd/panic.rs:392 at libstd/rt.rs:58 11: main 12: __libc_start_main 13: _start ``` Any advice?

sklump (Wed, 14 Nov 2018 17:22:30 GMT):
Hello, the current master of indy-sdk doesn't cargo build: ``` error: failed to run custom build command for `openssl v0.9.24` process didn't exit successfully: `/home/sklump/indy-sdk/libindy/target/release/build/openssl-d95cc14a80be27c4/build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'Unable to detect OpenSSL version', /home/sklump/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/build.rs:16:14 note: Run with `RUST_BACKTRACE=1` for a backtrace. ``` 111 sklump@ubu102:~/indy-sdk/libindy$ RUST_BACKTRACE=1 cargo build --release Compiling openssl v0.9.24 error: failed to run custom build command for `openssl v0.9.24` process didn't exit successfully: `/home/sklump/indy-sdk/libindy/target/release/build/openssl-d95cc14a80be27c4/build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'Unable to detect OpenSSL version', /home/sklump/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/build.rs:16:14 stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49 1: std::sys_common::backtrace::print at libstd/sys_common/backtrace.rs:71 at libstd/sys_common/backtrace.rs:59 2: std::panicking::default_hook::{{closure}} at libstd/panicking.rs:211 3: std::panicking::default_hook at libstd/panicking.rs:227 4: std::panicking::rust_panic_with_hook at libstd/panicking.rs:511 5: std::panicking::begin_panic 6: build_script_build::main 7: std::rt::lang_start::{{closure}} 8: std::panicking::try::do_call at libstd/rt.rs:59 at libstd/panicking.rs:310 9: __rust_maybe_catch_panic at libpanic_unwind/lib.rs:105 10: std::rt::lang_start_internal at libstd/panicking.rs:289 at libstd/panic.rs:392 at libstd/rt.rs:58 11: main 12: __libc_start_main 13: _start ``` Any advice?

sklump (Wed, 14 Nov 2018 17:22:30 GMT):
Hello, the current master of indy-sdk doesn't cargo build: ``` error: failed to run custom build command for `openssl v0.9.24` process didn't exit successfully: `/home/sklump/indy-sdk/libindy/target/release/build/openssl-d95cc14a80be27c4/build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'Unable to detect OpenSSL version', /home/sklump/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/build.rs:16:14 note: Run with `RUST_BACKTRACE=1` for a backtrace. ``` ... then, with backtrace, ``` sklump@ubu102:~/indy-sdk/libindy$ RUST_BACKTRACE=1 cargo build --release Compiling openssl v0.9.24 error: failed to run custom build command for `openssl v0.9.24` process didn't exit successfully: `/home/sklump/indy-sdk/libindy/target/release/build/openssl-d95cc14a80be27c4/build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'Unable to detect OpenSSL version', /home/sklump/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/build.rs:16:14 stack backtrace: 0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace at libstd/sys/unix/backtrace/tracing/gcc_s.rs:49 1: std::sys_common::backtrace::print at libstd/sys_common/backtrace.rs:71 at libstd/sys_common/backtrace.rs:59 2: std::panicking::default_hook::{{closure}} at libstd/panicking.rs:211 3: std::panicking::default_hook at libstd/panicking.rs:227 4: std::panicking::rust_panic_with_hook at libstd/panicking.rs:511 5: std::panicking::begin_panic 6: build_script_build::main 7: std::rt::lang_start::{{closure}} 8: std::panicking::try::do_call at libstd/rt.rs:59 at libstd/panicking.rs:310 9: __rust_maybe_catch_panic at libpanic_unwind/lib.rs:105 10: std::rt::lang_start_internal at libstd/panicking.rs:289 at libstd/panic.rs:392 at libstd/rt.rs:58 11: main 12: __libc_start_main 13: _start ``` Any advice?

sklump (Wed, 14 Nov 2018 17:53:01 GMT):
... I think it's to do with the latest openssl 1.1.1 release. I look in Cargo.lock and it gets [[package]] openssl 0.9.24 from somewhere, which is too old now?

mhailstone (Wed, 14 Nov 2018 20:09:45 GMT):
Agent Call is happening now: https://zoom.us/j/856588081

AlexanderVtyurin (Thu, 15 Nov 2018 12:08:27 GMT):
Hello, everyone! I've got several questions about ids in libindy: 1. What is the purpose of the `schemaSeqNo`? Why it is used to construct `credentialDefinitionId` instead of `schemaId`? Can I query ledger for a schema using `schemaSeqNo`? 2. What is the purpose of "tag" in `credentialDefinitionId`? Doesn't it mean one can create multiple credential definitions using exact one schema? If it so, why would someone do that? +Exact same question about "tag" in `revocationRegistryDefinitionId`: what, why, how can I take advantage of it?

sklump (Thu, 15 Nov 2018 12:40:36 GMT):
1. The origin/issuer constructs schema identifier before sending it to the ledger, and so the schema seq no is unknowable when creating the schema. By the time the issuer is issuing a cred def, the schema and its transaction number on the ledger are already known, so the schema seq no can tie the schema to the cred def in the cred def id. You may query the ledger for a schema using schema seq no. 2. "tag" in cred def id is mainly for historical reasons. Generally, one issuer will create one cred def id per schema: specify a tag value of `tag`. However, there is a feasible use case of one issuer issuing two cred defs on a schema: with and without revocation support. Revocation registries can cover only a fixed number of credentials. Once one is exhausted, the issuer must generate a new revocation registry, tied to the cred def; its tag identifies it.

AlexanderVtyurin (Thu, 15 Nov 2018 12:48:58 GMT):
Thank you very much, it becomes much cleaner. Okay, I understand that schemaSeqNo is needed to prevent situations when a credential definition is published to a ledger before schema. But what about revocation registry then? Its id is also composed from `credentialDefinitionId` + `some other stuff`. So, I'm actually able to store revocation registry to ledger before credential definition. Am I missing something?

sklump (Thu, 15 Nov 2018 12:49:40 GMT):
I guess you could if you wanted your software not to work.

sklump (Thu, 15 Nov 2018 12:50:32 GMT):
There may be cryptographic considerations that require the cred def to be on the ledger first.

sklump (Thu, 15 Nov 2018 12:51:30 GMT):
I don't think schema seq no was required as such, it's just how the definitions coalesced. It's not my favourite because given a cred def id, it requires a double-tap to the ledger to get the cred def, then the schema.

sklump (Thu, 15 Nov 2018 12:52:05 GMT):
These things can be cached though - the ledger is immutable after all.

AlexanderVtyurin (Thu, 15 Nov 2018 12:55:18 GMT):
I understand. My question actually was: "why there is some interface-level protection for schema/credential definition, but none for credential definition/revocation registry definition then?". Is there some point for it?

sklump (Thu, 15 Nov 2018 13:00:17 GMT):
I don't think it was a design decision as such. At the time when revocation support was going in, the structures of the identifiers were a work in progress and that's just how it came out. I am sure there is absolutely no appetite to revisit this.

AlexanderVtyurin (Thu, 15 Nov 2018 13:00:38 GMT):
Okay. Thank you.

sklump (Thu, 15 Nov 2018 13:31:21 GMT):
Is an update to indy-sdk forthcoming to accommodate the present-day openssl version?

canadaduane (Thu, 15 Nov 2018 18:36:56 GMT):
Is there a feature list describing all of the capabilities of indy-sdk anywhere?

MattRaffel (Thu, 15 Nov 2018 18:59:14 GMT):
Has joined the channel.

simonwanggh (Fri, 16 Nov 2018 01:05:17 GMT):
Has joined the channel.

simonwanggh (Fri, 16 Nov 2018 09:10:51 GMT):
Can verifier get any identity related information from a proof?

simonwanggh (Fri, 16 Nov 2018 09:14:21 GMT):
Or any identity related inforamtion just can be verified by proofrequest indirectly. right?

arunwij (Fri, 16 Nov 2018 09:58:37 GMT):
Why we need master secret id to prove ownership of a credential. Why not using the owner's DID when issuing the credential?( to relate credential and the owner? )

arunwij (Fri, 16 Nov 2018 09:58:37 GMT):
Why we need master secret to prove ownership of a credential. Why not using the owner's DID when issuing the credential?( to relate credential and the owner? )

arunwij (Fri, 16 Nov 2018 09:58:37 GMT):
Why we need master secret to prove ownership of a credential. Why can't we use the owner's DID when issuing the credential?( to relate credential and the owner? )

arunwij (Fri, 16 Nov 2018 09:58:37 GMT):
Why we need master secret to prove ownership of a credential. Why can't we use the owner's DID when issuing the credential?( to relate the credential and the owner? )

arunwij (Fri, 16 Nov 2018 09:58:37 GMT):
Why we need a master secret to prove ownership of a credential. Why can't we use the owner's DID when issuing the credential? ( to relate the credential and the owner)

DCSnail (Fri, 16 Nov 2018 10:02:23 GMT):
Has joined the channel.

gudkov (Fri, 16 Nov 2018 12:46:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6oqXHLf3hy5FiD3cD) @arunwij - Master secret is part of protocol that allows proving that multiple credentials in one proof are owned by one owner. It is important that Prover doesn't share master secret at all and nobody can correlate him. It is impossible to determine that 2 proofs were made by the same Prover. - It is important to understand that the most of identity owners don't have DIDs used to communicate with multiple parties. DIDs are pairwise and identity owner generates new DID for each connection.

MALodder (Fri, 16 Nov 2018 16:32:02 GMT):
if you used a DID then you couldn't port the credentials across relationships since DID's are tied to relationships. master secret makes it DID agnostic

mboyd (Fri, 16 Nov 2018 18:45:58 GMT):
Many people have asked about how to find documentation for the recently open-sourced vcx library. Here's a reminder that you can build the documentation from source within the wrappers: For Node.js https://github.com/hyperledger/indy-sdk/tree/master/vcx/wrappers/node For Python: https://github.com/hyperledger/indy-sdk/tree/master/vcx/wrappers/python3

ShivVenkatraman (Sat, 17 Nov 2018 01:18:12 GMT):
I installed libindy on Ubuntu with sudo apt-get install -y libindy; and when running the python sample scripts; I get the error: AttributeError: /usr/lib/libindy.so: undefined symbol: indy_set_logger. When I checked for symbols with readelf -Ws /usr/lib/libindy.so|grep logger; I did not find indy_set_logger in it

MALodder (Sat, 17 Nov 2018 19:17:33 GMT):
The Java Wrapper is very out of date and doesn't work

MALodder (Sat, 17 Nov 2018 19:19:22 GMT):
I've been trying it with a bunch of students

MALodder (Sat, 17 Nov 2018 19:19:33 GMT):
and they want to use it

MALodder (Sat, 17 Nov 2018 19:25:38 GMT):
if it isn't out of date, then the samples folders are not working

MALodder (Sat, 17 Nov 2018 19:25:46 GMT):
and the instructions are out of date

arunwij (Sun, 18 Nov 2018 02:19:46 GMT):
@gudkov @MALodder Thank you for the responses. I don't get this point, "It is impossible to determine that 2 proofs were made by the same Prover". How this is possible with master secret? Can we use multiple master secrets for each credential request from issuers? ( I think if i understand the cryptographic concept behind the master secret, I will understand this scenario. If you know the name of the concept please let me know :) )

CodinIosif (Sun, 18 Nov 2018 09:52:08 GMT):
Has joined the channel.

MALodder (Sun, 18 Nov 2018 09:52:41 GMT):
@arunwij Proofs are unique per presentation. This is achieved by using random numbers for every proof that is used to blind values

srottem (Mon, 19 Nov 2018 02:58:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=tz33RZpq2FKnbWqfo) @TammyPlatero The reason the .NET docs aren't accessible is because the hyperledger github repo isn't correctly set up to serve it. You can find a working copy here: https://srottem.github.io/indy-sdk/wrappers/dotnet/docs/index.html

DCSnail (Mon, 19 Nov 2018 03:07:10 GMT):
The libindy-objc.podspec.json for version 1.6.7 has an error. The source address is inavailable in that json file, so i can't use the version 1.6.7. Therefore, i have to use the version 1.6.1 by Xcode9 or before. #indy-sdk Anyone kown the latest version 1.6.7 where can be download? Thanks.

DCSnail (Mon, 19 Nov 2018 03:07:10 GMT):
The libindy-objc.podspec.json for version 1.6.7 has an error. The source address is unavailable in that json file, so i can't use the version 1.6.7. Therefore, i have to use the version 1.6.1 by Xcode9 or before. #indy-sdk Anyone kown the latest version 1.6.7 where can be download? Thanks.

arunwij (Mon, 19 Nov 2018 04:16:14 GMT):
Hello all, When issuing a credential what are the transactions written in the ledger? From the documents, there is `NYM, ATTRIB, SCHEMA, CLAIM_DEF` ledger transaction types. I want to know which of these used when issuing credential and how. I highly appreciate if you can point me a document or the source code. :)

arunwij (Mon, 19 Nov 2018 04:16:14 GMT):
Hello all, When issuing a credential what are the transactions written in the ledger? From the documents, there is `NYM, ATTRIB, SCHEMA, CLAIM_DEF` ledger transaction types. I want to know which of these used when issuing a credential and how. I highly appreciate if you can point me a document or in the source code. :)

arunwij (Mon, 19 Nov 2018 04:16:14 GMT):
Hello all, When issuing a credential what are the transactions written in the ledger? From the documents, there is `NYM, ATTRIB, SCHEMA, CLAIM_DEF` ledger transaction types. I want to know which of these used when issuing a credential and how. I highly appreciate if you can point me a document or in the source code. :) Thank you.

srottem (Mon, 19 Nov 2018 07:05:00 GMT):
Who is responsible for the Hyperledger Indy Github repo? The current .NET wrapper's README.md points to the Hyperledger repo for the .NET docs but it's not working because the repo needs to be configured with "Github Pages" with the source as the Master branch. See here for details: https://help.github.com/articles/configuring-a-publishing-source-for-github-pages/

gudkov (Mon, 19 Nov 2018 07:37:55 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=sQZh3gWazhgzCZyx8) @MALodder All wrappers are up to date. They are tested and delivered for each commit. You only need to make sure that you use the same version of libindy and wrapper from one release channel/

gudkov (Mon, 19 Nov 2018 07:39:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JAj2ezo3f4BBLEBjr) @ShivVenkatraman Yo use indy_set_logger you need to use master release channel. Re-check README.md about available release channels.

gudkov (Mon, 19 Nov 2018 07:39:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JAj2ezo3f4BBLEBjr) @ShivVenkatraman To use indy_set_logger you need to use master release channel. Re-check README.md about available release channels.

gudkov (Mon, 19 Nov 2018 08:00:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nJMzZ8jHdwuaFTgqj) The exception can be .net wrapper as it doesn't included to CI for the moment

DCSnail (Mon, 19 Nov 2018 08:37:17 GMT):

The URL of libindy-objc(1.6.7) can not find.

gudkov (Mon, 19 Nov 2018 10:46:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=MwFwQJuSytRrwP5de) @DCSnail We plan to fix this soon. You can contact @sergey.minaev about progress and expected date.

yisheng (Mon, 19 Nov 2018 11:17:11 GMT):
Has joined the channel.

nage (Mon, 19 Nov 2018 19:09:48 GMT):
If you are working on schemas or overlays please join us in #indy-semantics where we will be continuing conversations on json-ld, updates to anoncreds protocol and other encoding, types and schema related stuff. (yes this is a cross-post to interested channels)

vishumanvi (Mon, 19 Nov 2018 21:06:32 GMT):
Has joined the channel.

stanleyc-trustscience (Mon, 19 Nov 2018 22:41:25 GMT):
I notice indy web shim is discussed in the following slide https://docs.google.com/presentation/d/10yKcg8-Ktd6SKoz-YvfMdFN-9czPDVHMXibFsUWVFP4/edit#slide=id.g445b3970a1_0_104 Anyone know if there is a development effort for indy web shim currently?

DCSnail (Tue, 20 Nov 2018 01:41:48 GMT):
Thank you very much

PhillipGibb (Tue, 20 Nov 2018 13:19:25 GMT):
Hi, When it comes to Range Proofs, e.g. >18 yrs old is this something that is part of a credential definition or a predicate that can be applied to a Date or Birth Credential? So if I as a holder of a verified Date of Birth: Who does the work in creating a verifiable proof that I am > 18 without me sending the date of birth?

swcurran (Tue, 20 Nov 2018 14:52:38 GMT):
The Proof Request data structure from the verifier would specify the predicate needed - e.g. DOB claim (from a specified Credential Definition or Schema) > 18. The Prover would do the work of creating the proof. The verifier that the proof was successfully created.

sklump (Tue, 20 Nov 2018 15:18:36 GMT):
@PhillipGibb note that at present the only predicate in scope is `GE` (aka `>=` aka `$gte`), although the effort to accommodate `GT`, `LE`, `LT` is underway. As such using the date of birth is not going to help, unless you store a kind of negative date of birth in negative time and then invert queries accordingly. It's contrived, but help is on the way.

sklump (Tue, 20 Nov 2018 15:18:36 GMT):
@PhillipGibb Predicates apply to attribute values, as the credential definition's corresponding schema introduces them. Note that at present the only predicate in scope is `GE` (aka `>=` aka `$gte`), although the effort to accommodate `GT`, `LE`, `LT` is underway. As such using the date of birth is not going to help, unless you store a kind of negative date of birth in negative time and then invert queries accordingly. It's contrived, but help is on the way.

sklump (Tue, 20 Nov 2018 15:18:36 GMT):
@PhillipGibb Predicates apply to attribute values, as the credential definition's corresponding schema introduces them, and only to 32-bit ints. Note that at present the only predicate in scope is `GE` (aka `>=` aka `$gte`), although the effort to accommodate `GT`, `LE`, `LT` is underway. As such using the date of birth is not going to help, unless you store a kind of negative date of birth in negative time and then invert queries accordingly. To complete the example, suppose a cred def has a negative epoch for date of birth (say, 0 - epoch on midnight of date of birth). The proof request would include attributes to reveal (say, name and favourite drink) and predicates of interest on non-revealed attributes (say, negative date of birth >= -974678400). _(This may have an error by one day)_ for age 18 or higher. It's contrived, but help is on the way.

sklump (Tue, 20 Nov 2018 15:18:36 GMT):
@PhillipGibb Predicates apply to attribute values, as the credential definition's corresponding schema introduces them, and only to 32-bit ints. Note that at present the only predicate in scope is `GE` (aka `>=` aka `$gte`), although the effort to accommodate `GT`, `LE`, `LT` is underway. As such using the date of birth is not going to help, unless you store a kind of negative date of birth in negative time and then invert queries accordingly. To complete the example, suppose a cred def has a negative epoch for date of birth (say, 0 - epoch on midnight, Zulu time, of date of birth). The proof request would include attributes to reveal (say, name and favourite drink) and predicates of interest on non-revealed attributes (say, negative date of birth >= -974678400). _(This may have an error by one day)_ for age 18 or higher. It's contrived, but help is on the way.

sklump (Tue, 20 Nov 2018 15:18:36 GMT):
@PhillipGibb Predicates apply to attribute values, as the credential definition's corresponding schema introduces them, and only to 32-bit ints. Note that at present the only predicate in scope is `GE` (aka `>=` aka `$gte`), although the effort to accommodate `GT`, `LE`, `LT` is underway. As such using the date of birth is not going to help, unless you store a kind of negative date of birth in negative time and then invert queries accordingly. To complete the example, suppose a cred def has a negative epoch for date of birth (say, 0 - epoch on midnight, Zulu time, of date of birth). The proof request would include attributes to reveal (say, name and favourite drink) and predicates of interest on non-revealed attributes (say, negative date of birth >= -974678400) _(this may have an error by one day)_ for age 18 or higher. Then the proof would return name and age, plus assertion that the credential satisfies the predicate. It's contrived, but help is on the way.

PhillipGibb (Tue, 20 Nov 2018 18:44:38 GMT):
@sklump so, at the moment we can only apply a >= against an already verified value? Not a calculation? If I received a VC stating my age then I could use that, but then I need a new one every year

PhillipGibb (Tue, 20 Nov 2018 18:47:52 GMT):
@sklump "requested_predicates": { "predicate1_referent": {"name": "epoch_dob", "p_type": ">=", "p_value": current_epoch_dob*1000*60.....*18} }

adamjbradley (Tue, 20 Nov 2018 19:54:44 GMT):
Morning all!

MattRaffel (Tue, 20 Nov 2018 21:18:58 GMT):
other than code, is there documentation on the API calls and the data structures for issuing a credential offer (aka everything up to and including making this call indy_prover_create_credential_req)?

TammyPlatero (Wed, 21 Nov 2018 00:04:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5hghe3eijHRLmsfw9) @srottem Thank you!

srottem (Wed, 21 Nov 2018 03:20:02 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=YPMNExyENbRo37hyc) @TammyPlatero Note that the docs you'll find there match the version of the wrapper at the head of my repo - there may have been changes in the hyperledger repo that don't necessarily match the docs in my repo. I wouldn't expect there to be many differences though.

arunwij (Wed, 21 Nov 2018 05:48:29 GMT):
When issuing a credential to an identity owner. What information will be stored in the ledger? Eg. Issuing a Transcript Credential.

arunwij (Wed, 21 Nov 2018 05:48:29 GMT):
*When issuing a credential to an identity owner. What information will be stored in the ledger?* Eg. Issuing a Transcript Credential.

arunwij (Wed, 21 Nov 2018 05:50:32 GMT):
Is there any documentation where I can find these info? I looked in the ledger transactions in docs. But I cannot figure out what information will be stored when issuing a credential, or what type of transaction is used.

arunwij (Wed, 21 Nov 2018 05:51:11 GMT):
Highly appreciate any help. Thanks.

swcurran (Wed, 21 Nov 2018 07:04:49 GMT):
@arunwij - when issuing a credential to the identity owner no data is put on the ledger. A Credential Request goes from the Identity to the Issuer, and the Issuer uses some data from that (the blinder link secret) and then isssues the Credential to the Identity. Nothing goes to the ledger.

handicraftswoman (Wed, 21 Nov 2018 07:51:16 GMT):
Has joined the channel.

handicraftswoman (Wed, 21 Nov 2018 07:57:00 GMT):
I am using the libIndy-objc v1.6.1, but when I call method "openPoolLedgerWithName:poolConfig:completion" of Class IndyPool, it never goes into the completion callback, so I can't get the poolHandle. I have checked the pool_1.txt file content, I didn't find any problem`- (NSError *)openPoolLedger:(NSString *)poolName config:(NSString *)config poolHandler:(IndyHandle *)handle { __block NSError *err = nil; __block IndyHandle poolHandle = 0; NSString *configStr = (config) ? config : nil; dispatch_group_t group = dispatch_group_create(); dispatch_group_enter(group); [IndyPool openPoolLedgerWithName:poolName poolConfig:configStr completion:^(NSError *error, IndyHandle blockHandle) { err = error; poolHandle = blockHandle; dispatch_group_leave(group); }]; // dispatch_group_wait(group, DISPATCH_TIME_FOREVER); dispatch_group_wait(group, dispatch_time(DISPATCH_TIME_NOW, (int64_t)(15*NSEC_PER_SEC))); if (handle) {*handle = poolHandle;} return err; }`

arunwij (Wed, 21 Nov 2018 09:40:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=x5dBYM3GxqX5Ss3KE) @swcurran Thank you. Identity owner can prove the information is belongs to them by link secret. But how they verify the integrity of the credential? (Attributes are not changed). Does issuer signs attribute values when issuing? correct

arunwij (Wed, 21 Nov 2018 09:40:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=x5dBYM3GxqX5Ss3KE) @swcurran Thank you. Identity owner can prove the information belongs to them by link secret. But how they verify the integrity of the credential? (Attributes are not changed). Does issuer signs attribute values when issuing? When verification happens, Does verifier only needs the public key of the issuer from the ledger? Correct me if I am wrong.

arunwij (Wed, 21 Nov 2018 09:40:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=x5dBYM3GxqX5Ss3KE) @swcurran Thank you. Identity owner can prove the information belongs to them by link secret. But how they verify the integrity of the credential? (Attributes are not changed). Does issuer signs attribute values when issuing? When verification happens, does verifier only need the public key of the issuer from the ledger? Correct me if I am wrong.

swcurran (Wed, 21 Nov 2018 09:54:29 GMT):
When they prove the claims from the credential, the proof verifies who issued the claim (credential definition has DID of Issuer), it was issued to the holder (link secret), not tampered with (hash of claim), and not revoked (revocation registry checked).

arunwij (Wed, 21 Nov 2018 09:56:39 GMT):
@swcurran Got it. Thanks! :thumbsup:

handicraftswoman (Wed, 21 Nov 2018 10:24:59 GMT):
@swcurran I am using the libIndy-objc v1.6.1, but when I call method "openPoolLedgerWithName:poolConfig:completion" of Class IndyPool, it never goes into the completion callback, so I can't get the poolHandle. I have checked the pool_1.txt file content, I didn't find any problem`- (NSError *)openPoolLedger:(NSString *)poolName config:(NSString *)config poolHandler:(IndyHandle *)handle { __block NSError *err = nil; __block IndyHandle poolHandle = 0; NSString *configStr = (config) ? config : nil; dispatch_group_t group = dispatch_group_create(); dispatch_group_enter(group); [IndyPool openPoolLedgerWithName:poolName poolConfig:configStr completion:^(NSError *error, IndyHandle blockHandle) { err = error; poolHandle = blockHandle; dispatch_group_leave(group); }]; // dispatch_group_wait(group, DISPATCH_TIME_FOREVER); dispatch_group_wait(group, dispatch_time(DISPATCH_TIME_NOW, (int64_t)(15*NSEC_PER_SEC))); if (handle) {*handle = poolHandle;} return err; }`

sklump (Wed, 21 Nov 2018 12:19:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ems8ZX3jAAdDqJoiN) @PhillipGibb _(Note that this comparison checks age of minority, not majority. Hence my negative date of birth awkwardness above)_. And yes, only >= for the moment, on 32-bit ints (which must encode to their decimal stringified representations). Other predicates (<=, >, <) are in the works but 32-bit ints will be the domain for predicates for the foreseeable future.

sklump (Wed, 21 Nov 2018 12:19:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ems8ZX3jAAdDqJoiN) @PhillipGibb Yes, only >= for the moment, on 32-bit ints (which must encode to their decimal stringified representations). Other predicates (<=, >, <) are in the works but 32-bit ints will be the domain for predicates for the foreseeable future. _(Note that the comparison below checks age of minority, not majority. Hence my negative date of birth awkwardness above. Another way out, as you noted, could be to arrange a credential issue on each birthday)_

solocez (Wed, 21 Nov 2018 18:18:11 GMT):
iOS Indy SDK. Trying to port *getting_started.py* sample/scenario to *iOS* (_for internal Demo reasons_). Opened Ledger Successfully. Opened Wallets of Steward and Faber successfully. Opened corresponding Steward/Faber DIDs for connection successfully. Sending request from Steward to Faber. On Faber's side trying to retrieve appropriate Key for a given DID (_Steward's_) using "*keyForDid:poolHandle:walletHandle:completion:*" - getting an error - *WalletItemNotFound = 212* What might be wrong there ? On Faber's side i use Faber's wallet handle.

solocez (Wed, 21 Nov 2018 18:18:11 GMT):
iOS Indy SDK. Trying to port *getting_started.py* sample/scenario to *iOS* (_ for internal Demo reasons _). Opened Ledger Successfully. Opened Wallets of Steward and Faber successfully. Opened corresponding Steward/Faber DIDs for connection successfully. Sending request from Steward to Faber. On Faber's side trying to retrieve appropriate Key for a given DID (_Steward's_) using "*keyForDid:poolHandle:walletHandle:completion:*" - getting an error - *WalletItemNotFound = 212* What might be wrong there ? On Faber's side i use Faber's wallet handle.

solocez (Wed, 21 Nov 2018 18:18:11 GMT):
iOS Indy SDK. Trying to port *getting_started.py* sample/scenario to *iOS* ( _ for internal Demo reasons _ ). Opened Ledger Successfully. Opened Wallets of Steward and Faber successfully. Opened corresponding Steward/Faber DIDs for connection successfully. Sending request from Steward to Faber. On Faber's side trying to retrieve appropriate Key for a given DID (_Steward's_) using "*keyForDid:poolHandle:walletHandle:completion:*" - getting an error - *WalletItemNotFound = 212* What might be wrong there ? On Faber's side i use Faber's wallet handle.

solocez (Wed, 21 Nov 2018 18:18:11 GMT):
iOS Indy SDK. Trying to port *getting_started.py* sample/scenario to *iOS* ( _ for internal Demo reasons _ ). Opened Ledger Successfully. Opened Wallets of Steward and Faber successfully. Opened corresponding Steward/Faber DIDs for connection successfully. Sending request from Steward to Faber. On Faber's side trying to retrieve appropriate Key for a given DID ( _Steward's_ ) using "*keyForDid:poolHandle:walletHandle:completion:*" - getting an error - *WalletItemNotFound = 212* What might be wrong there ? On Faber's side i use Faber's wallet handle.

solocez (Wed, 21 Nov 2018 18:18:11 GMT):
iOS Indy SDK. Trying to port *getting_started.py* sample/scenario to *iOS* ( _ for internal Demo reasons _ ). Opened Ledger Successfully. Opened Wallets of Steward and Faber successfully. Opened corresponding Steward/Faber DIDs for connection successfully. Sending request from Steward to Faber. On Faber's side trying to retrieve appropriate Key for a given DID ( _Steward's_ ) using " *keyForDid:poolHandle:walletHandle:completion:* " - getting an error - *WalletItemNotFound = 212* What might be wrong there ? On Faber's side i use Faber's wallet handle.

stanleyc-trustscience (Wed, 21 Nov 2018 19:20:23 GMT):
@solocez Does faber's wallet contain the DID and VerKey pair for Steward? if it doesn't, the method will look up VerKey on the ledger ... it might be that Steward's DID and VerKey pair (in the form of NYM transaction) is not on the ledger

solocez (Wed, 21 Nov 2018 19:22:19 GMT):
@stanleyc-trustscience How to check that - if Faber's wallet contain DID:VerKey for Steward ? I thought " *keyForDid:poolHandle:walletHandle:completion:* " serves for that reason

solocez (Wed, 21 Nov 2018 19:23:06 GMT):
I have another question - what's granularity of Wallet idiom? I create two wallets within one Process - will that work ?

stanleyc-trustscience (Wed, 21 Nov 2018 19:23:43 GMT):
yeah that will work, but at any point in time, did faber save Steward's DID/VerKey to its wallet?

solocez (Wed, 21 Nov 2018 19:24:04 GMT):
no

stanleyc-trustscience (Wed, 21 Nov 2018 19:24:35 GMT):
Or did Steward's DID/VerKey pair get saved to the indy ledger in the form of NYM transaction

stanleyc-trustscience (Wed, 21 Nov 2018 19:24:43 GMT):
If not, then you'd need to do that

solocez (Wed, 21 Nov 2018 19:26:44 GMT):
@stanleyc-trustscience got it. will check. thanks for now

stanleyc-trustscience (Wed, 21 Nov 2018 19:28:07 GMT):
@solocez Pay attention to `def onboarding` method in getting_started.py

stanleyc-trustscience (Wed, 21 Nov 2018 19:28:07 GMT):
@solocez Pay attention of def onboarding method in getting_started.py

stanleyc-trustscience (Wed, 21 Nov 2018 19:29:15 GMT):
When steward onboards a trust anchor, the stewards send two NYM transactions to the ledger for the two pairwise DID - DID from steward to trust anchor - DID from trust anchor to steward

stanleyc-trustscience (Wed, 21 Nov 2018 19:29:15 GMT):
When steward onboards a trust anchor, the steward sends two NYM transactions to the ledger for the two pairwise DIDs - DID from steward to trust anchor - DID from trust anchor to steward

stanleyc-trustscience (Wed, 21 Nov 2018 19:29:15 GMT):
When steward onboards a trust anchor, the stewards send two NYM transactions to the ledger for the two pairwise DIDs - DID from steward to trust anchor - DID from trust anchor to steward

stanleyc-trustscience (Wed, 21 Nov 2018 19:29:20 GMT):
You might be missing this step

adamjbradley (Wed, 21 Nov 2018 20:00:30 GMT):
Finally have my environment up and running!

stanleyc-trustscience (Wed, 21 Nov 2018 21:15:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ftQuwABH4GELgBx3H) @handicraftswoman @handicraftswoman Just answering your question here. Hope it'd be helpful If you set a debug point in or print out the poolHandle value just below this line, do you see >0 value? if so, you're getting the handle back alright ``` completion:^(NSError *error, IndyHandle blockHandle) { err = error; poolHandle = blockHandle; ``` I believe the poolHandle in this line always evaluated to null ``` if (handle) {*handle = poolHandle;} ``` because poolHandle is only assigned a value when the completion block is called, not when this method is about to return I'd suggest moving code that requires poolHandle) into completion block

stanleyc-trustscience (Wed, 21 Nov 2018 21:15:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ftQuwABH4GELgBx3H) @handicraftswoman @handicraftswoman Just answering your question here. Hope it'd be helpful If you set a debug point in or print out the poolHandle value just below this line, do you see non-zero value? if so, you're getting the handle back alright ``` completion:^(NSError *error, IndyHandle blockHandle) { err = error; poolHandle = blockHandle; ``` I believe the poolHandle in this line always evaluated to null ``` if (handle) {*handle = poolHandle;} ``` because poolHandle is only assigned a value when the completion block is called, not when this method is about to return I'd suggest moving these code into completion block, although I'm not sure what dispatch_group_wait does ``` dispatch_group_wait(group, dispatch_time(DISPATCH_TIME_NOW, (int64_t)(15*NSEC_PER_SEC))); if (handle) {*handle = poolHandle;} return err; ```

stanleyc-trustscience (Wed, 21 Nov 2018 21:15:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ftQuwABH4GELgBx3H) @handicraftswoman @handicraftswoman Just answering your question here. Hope it'd be helpful If you set a debug point in or print out the poolHandle value just below this line, do you see non-zero value? if so, you're getting the handle back alright ``` completion:^(NSError *error, IndyHandle blockHandle) { err = error; poolHandle = blockHandle; ``` I believe the poolHandle in this line always evaluated to null ``` if (handle) {*handle = poolHandle;} ``` because poolHandle is only assigned a value when the completion block is called, not when this method is about to return I'd suggest moving these code (stuff that requires poolHandle) into completion block, although I'm not sure what dispatch_group_wait does ``` dispatch_group_wait(group, dispatch_time(DISPATCH_TIME_NOW, (int64_t)(15*NSEC_PER_SEC))); if (handle) {*handle = poolHandle;} return err; ```

stanleyc-trustscience (Wed, 21 Nov 2018 21:15:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ftQuwABH4GELgBx3H) @handicraftswoman @handicraftswoman Just answering your question here. Hope it'd be helpful If you set a debug point in or print out the poolHandle value just below this line, do you see >0 value? if so, you're getting the handle back alright ``` completion:^(NSError *error, IndyHandle blockHandle) { err = error; poolHandle = blockHandle; ``` I believe the poolHandle in this line always evaluated to null ``` if (handle) {*handle = poolHandle;} ``` because poolHandle is only assigned a value when the completion block is called, not when this method is about to return I'd suggest moving these code (stuff that requires poolHandle) into completion block, although I'm not sure what dispatch_group_wait does ``` dispatch_group_wait(group, dispatch_time(DISPATCH_TIME_NOW, (int64_t)(15*NSEC_PER_SEC))); if (handle) {*handle = poolHandle;} return err; ```

stanleyc-trustscience (Wed, 21 Nov 2018 21:15:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ftQuwABH4GELgBx3H) @handicraftswoman @handicraftswoman Just answering your question here. Hope it'd be helpful If you set a debug point in or print out the poolHandle value just below this line, do you see >0 value? if so, you're getting the handle back alright ``` completion:^(NSError *error, IndyHandle blockHandle) { err = error; poolHandle = blockHandle; ``` I believe the poolHandle in this line always evaluated to null ``` if (handle) {*handle = poolHandle;} ``` because poolHandle is only assigned a value when the completion block is called, not when this method is about to return I'd suggest moving these code (stuff that requires poolHandle) into completion block, although I'm not sure what dispatch_group_wait does for you ``` dispatch_group_wait(group, dispatch_time(DISPATCH_TIME_NOW, (int64_t)(15*NSEC_PER_SEC))); if (handle) {*handle = poolHandle;} return err; ```

stanleyc-trustscience (Wed, 21 Nov 2018 21:28:08 GMT):
@handicraftswoman Here's some discussion about asynchronous nature of completion handler https://stackoverflow.com/questions/39806800/how-can-i-return-value-from-completion-block-to-use-it-in-other-viewcontroller

stanleyc-trustscience (Wed, 21 Nov 2018 21:35:26 GMT):
One possible way to return value from completion handler is to use promise.

stanleyc-trustscience (Wed, 21 Nov 2018 21:35:26 GMT):
One possible way to return value from completion handler is to use promise. Perhaps, u could give this promise framework a try, and let me know how it works for you :) https://github.com/google/promises

stanleyc-trustscience (Wed, 21 Nov 2018 21:35:26 GMT):
One possible way to return value from completion handler is to use promise. Perhpas, u could give this a try, and let me know how it works for you :) https://github.com/google/promises/blob/master/g3doc/index.md#the-problem-with-async-code

stanleyc-trustscience (Wed, 21 Nov 2018 21:35:26 GMT):
One possible way to return value from completion handler is to use promise. Perhpas, u could give this promise framework a try, and let me know how it works for you :) https://github.com/google/promises

stanleyc-trustscience (Wed, 21 Nov 2018 23:13:54 GMT):
Essentially, what it'd look like in the completion handler would be something like this: ``` FBLPromise *promise = [FBLPromise onQueue:dispatch_get_main_queue() async:^(FBLPromiseFulfillBlock fulfill, FBLPromiseRejectBlock reject) { // Called asynchronously on the dispatch queue specified. if (success) { // Resolve with a value. fulfill(@"Hello world."); } else { // Resolve with an error. reject(someError); } }]; ``` You would call `fulfill` or `reject` in the completion handler. In the fulfill method, you'd pass in the poolHandle. For reject, you can pass in a error object (exception, error message, etc)

GEEKTEDDY (Thu, 22 Nov 2018 06:41:21 GMT):
Has joined the channel.

handicraftswoman (Thu, 22 Nov 2018 09:36:20 GMT):
@stanleyc-trustscience when I using the libindy-objc v1.6.1

handicraftswoman (Thu, 22 Nov 2018 09:41:53 GMT):
@stanleyc-trustscience when I using the libindy-objc v1.6.1，I call the method of createAndStoreMyDid:wallethandle:completion of Class IndyDid, I found that it return the error of code 113, and the input parameter I check is ok, myDidJson: {"seed":"something....."} walletHandle is 3

swcurran (Thu, 22 Nov 2018 13:17:11 GMT):
@stanleyc-trustscience - thanks for following up on the question. @handicraftswoman - sorry I didn't have a handy answer for that. Stanley was WAY more useful than I would have been.

sklump (Thu, 22 Nov 2018 15:29:49 GMT):
*Item:* ``` E AttributeError: module 'indy.did' has no attribute 'encode' ../../.local/share/virtualenvs/sklump-Vm_I80wM/lib/python3.7/site-packages/indy/did.py:313: AttributeError ``` Unfortunately named `did` parameter is shadowed by `did.py` module in same package. Probably others like it. Easy enough to patch locally, but annoying.

sklump (Thu, 22 Nov 2018 15:29:49 GMT):
*Item:* ``` E AttributeError: module 'indy.did' has no attribute 'encode' ../../.local/share/virtualenvs/sklump-Vm_I80wM/lib/python3.7/site-packages/indy/did.py:313: AttributeError ``` Unfortunately named `did.py` shadows `did` parameter. Probably others like it. Easy enough to patch locally, but annoying.

sklump (Thu, 22 Nov 2018 15:29:49 GMT):
*Item:* ``` E AttributeError: module 'indy.did' has no attribute 'encode' ../../.local/share/virtualenvs/sklump-Vm_I80wM/lib/python3.7/site-packages/indy/did.py:313: AttributeError ``` Unfortunately named `did.py` shadows `did` parameter. Probably others like it. Easy enough to patch locally, but annoying. *Update:* I"ve renamed these to `did_`, but still the error comes up. It's getting weird.

stanleyc-trustscience (Thu, 22 Nov 2018 20:23:55 GMT):
@handicraftswoman That error indicates some error with input parameter. Perhaps there is some restriction on the seed value (length, etc). Maybe try this as your myDidJson `{'seed': '000000000000000000000000Steward1'}`

stanleyc-trustscience (Thu, 22 Nov 2018 20:24:27 GMT):
If that works, then just modify the string to your liking

stanleyc-trustscience (Thu, 22 Nov 2018 20:41:40 GMT):
@swcurran No worries :) I'm no expert by any means, just sharing what I know and giving back :grinning:

stanleyc-trustscience (Thu, 22 Nov 2018 20:41:40 GMT):
@swcurran I'm no expert by any means, just sharing what I know and giving back :grinning:

carsten (Fri, 23 Nov 2018 03:59:20 GMT):
Has joined the channel.

stanleyc-trustscience (Mon, 26 Nov 2018 19:52:01 GMT):
Anyone has knowledge of how to switch the underlying default persistence (sqlite) to some other persistence (eg, aws s3, or some other relational db like ms sql)

stanleyc-trustscience (Mon, 26 Nov 2018 20:24:58 GMT):
Looks we can can call `indy_register_wallet_storage`, is this do-able from wrapper layer?

stanleyc-trustscience (Mon, 26 Nov 2018 20:24:58 GMT):
Looks we can can call `indy_register_wallet_storage`, is this the default storage implementation swappable from wrapper layer?

stanleyc-trustscience (Mon, 26 Nov 2018 20:24:58 GMT):
Looks we can can call `indy_register_wallet_storage`, is the default storage implementation swappable from wrapper layer?

stanleyc-trustscience (Mon, 26 Nov 2018 20:28:42 GMT):
Looks doable for java since Callback parameters are passed in ``` public int indy_register_wallet_storage(int command_handle, String type, Callback create, Callback open, Callback close, Callback delete, Callback add_record, Callback update_record_value, ``` Anyone know how to make it work for python?

kdenhartog (Mon, 26 Nov 2018 22:52:14 GMT):
@stanleyc-trustscience It doesn't appear the functionality is built into the python wrapper, but it is possible to do this using indy_register_wallet_storage which is built into the rust APIs. @sergey.minaev @ianco or @gudkov will likely be able to help you with the implementation details of what needs to go in the parameters of the APIs.

kdenhartog (Mon, 26 Nov 2018 22:52:56 GMT):
It's the top function here: https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/api/wallet.rs

kdenhartog (Mon, 26 Nov 2018 22:55:14 GMT):
once you've completed this, it looks like you can create a wallet using the newly created wallet_storage using the storage type defined when registered with the call before.

JamieLi (Tue, 27 Nov 2018 00:01:17 GMT):
KeyValueStorageRocksdbIntKeys.open ignores the "read_only" flag. Can it be fixed?

JamieLi (Tue, 27 Nov 2018 00:01:43 GMT):
` def open(self): opts = self._get_db_opts() opts.comparator = IntegerComparator() # self._db = rocksdb.DB(self._db_path, opts, read_only=self._read_only) self._db = rocksdb.DB(self._db_path, opts)`

JamieLi (Tue, 27 Nov 2018 00:02:12 GMT):
` def open(self): opts = self._get_db_opts() opts.comparator = IntegerComparator() # self._db = rocksdb.DB(self._db_path, opts, read_only=self._read_only) self._db = rocksdb.DB(self._db_path, opts)`

kdenhartog (Tue, 27 Nov 2018 00:36:47 GMT):
@JamieLi This looks like it's code from Indy-node or Indy-plenum try checking in at #indy-node where you'll be more likely to get help.

adamjbradley (Tue, 27 Nov 2018 00:50:00 GMT):
Ok. Having trouble getting Indy Pool and the indy-cli working on a Mac

adamjbradley (Tue, 27 Nov 2018 00:50:26 GMT):
Docker VM starts (yay). Port is mapped. I can telnet to the port, but can't connect from indy-cli

adamjbradley (Tue, 27 Nov 2018 00:50:59 GMT):
Will try recreating the VM's using VirtualBox not the inbuilt hypervisor Docker uses

JamieLi (Tue, 27 Nov 2018 00:57:10 GMT):
@kdenhartog You are right. I will post there.

ianco (Tue, 27 Nov 2018 01:37:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4qr57tYraeYWdEYcT) @kdenhartog @stanleyc-trustscience I've added that functionality to the python wrapper, it's in a PR right now

ianco (Tue, 27 Nov 2018 01:45:57 GMT):
https://github.com/hyperledger/indy-sdk/blob/2d508a4171060130c3cfc4ca007f56629828dbbf/wrappers/python/indy/wallet.py#L14

kdenhartog (Tue, 27 Nov 2018 04:31:20 GMT):
@ianco thanks for pointing that out. I completely missed that which is hard to believe given that list of parameters.

kdenhartog (Tue, 27 Nov 2018 04:32:02 GMT):
@adamjbradley check out https://github.com/kdenhartog/Indy-dev

sergey.minaev (Tue, 27 Nov 2018 11:15:30 GMT):
@stanleyc-trustscience @ianco @kdenhartog , @gudkov has some concerns about including `indy_register_wallet_storage` in official IndySDK wrappers. Probably it will be removed from Java. btw it's more or less stable C API, so if you really would like to implement storage in python, you can do it by minimal wrapper functions in your app. But we don't see real use case. One of the purpose of pluggable storage is implement something with better performance and/or scale rather default one. So it's unlikely to have this production-ready solution in python. As far as I know there is proprietary usage of this API (plugged storage) by c/c++ implementation of storage.

MALodder (Tue, 27 Nov 2018 16:21:12 GMT):
@sergey.minaev what is your recommendation for passing an array of enums where the Enums are like this over the C calleable API: ``` pub enum MessageAddress { Did(String), KeyId(String) } ```

MALodder (Tue, 27 Nov 2018 16:22:24 GMT):
my thoughts are to have it look like this ``` pub extern fn indy_pack_message(command_handle: i32, wallet_handle: i32, message_raw: *const u8, message_len: u32, receivers: *const c_char, sender: *const c_char, cb: Option) -> ErrorCode; ```

MALodder (Tue, 27 Nov 2018 16:25:12 GMT):
sender is optional, e.g. if no sender is specified then the recipient will not have non-reputiable proof who the message came from

ianco (Tue, 27 Nov 2018 17:14:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5hRpLouYAQi3RaeA2) @sergey.minaev Right I haven't had a chance yet to look at your recommended approach to loading and initializing plug-ins

kdenhartog (Tue, 27 Nov 2018 19:48:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ZYM83h8aPaeQumdSo) @MALodder Why is this taking in message_raw and message_len rather than just a *const c_char json string?

MALodder (Tue, 27 Nov 2018 22:06:16 GMT):
because in C you do not know the length of the string and need a separate argument for that

kdenhartog (Tue, 27 Nov 2018 23:09:12 GMT):
Is it possible for our wrappers to handle this so that the API of the wrapper is a string, but the rust APIs match this?

smithbk (Wed, 28 Nov 2018 03:59:33 GMT):
Hi, I need to guarantee that two verifiers which verify the same proof will get the same result. In other words, I need to make verification **deterministic**. Let V1 be the verification of one verifier and V2 the verification of the other verifier. I think the results of the verifications could be different if either of the following happened between V1 and V2: 1) the verkey was changed or 2) a credential which was used to build the proof was revoked There may be other reasons, but I think they could be guaranteed to be the same if there were a way to

smithbk (Wed, 28 Nov 2018 04:01:36 GMT):
Hi, I need to guarantee that two verifiers which verify the same proof will get the same result. In other words, I need to make verification *deterministic*. I think the results of the two verifications would be different if either of the two happened between the verifications: 1) the verkey was changed or 2) a credential which was used to build the proof was revoked There may be other reasons, but I think the two verifications could be guaranteed to be the same if we

smithbk (Wed, 28 Nov 2018 04:02:00 GMT):
Hi, I need to guarantee that two verifiers which verify the same proof will get the same result. In other words, I need to make verification *deterministic*. I think the results of the two verifications would be different if either of the two happened between the verifications: 1) the verkey was changed or 2) a credential which was used to build the proof was revoked There may be other reasons, but I think the two verifications could be guaranteed to be the same if we

smithbk (Wed, 28 Nov 2018 04:29:06 GMT):
Hi, is there a way to make ledger operations during verification processing retrieve values from the ledger as they were at some time in the past? The reason I'm asking is that I need to guarantee that multiple verifications of a single proof will get the same result, even though the verifications are performed at different times. In other words, I'd like to make verification **deterministic**. I think we could get different results if either of the following happens between the two verifications: 1) the verkey was changed or 2) a credential which was used to build the proof was revoked And maybe there are other reasons. However, if all values retrieved from the ledger during verification are the same and we don't use any cached values in the wallet, I "think" the results of multiple verifications would all be the same. Does this sound correct? Any recommendations are appreciated. Thanks

swcurran (Wed, 28 Nov 2018 05:56:02 GMT):
@smithbk - I think the only scenario that could change the result is the revocation - I'm pretty sure there is not a verkey that could change that could affect the proof. Regards proofing "in the past". The prover and the verifier have to be able to align on the time of verification because if they are using different accumulators, the proof of non-revocation will not work. For example, suppose I do a proof, send it to you and before you verify the non-revocation part, the issuer revokes some credentials (and so changes the on ledger accumulator). If you get the new accumulator, and not the one I used for the proof, the verification would fail. Having said that, I'm not _exactly _ sure how that all works. I would suggest looking at the revocation work that @sklump has done in von_anchor. He has implemented quite a lot of functionality around revocation and tails file generation/management. In his docs, there is a section on revocation timing - https://von-anchor.readthedocs.io/en/latest/revocation-and-tails-files.html#revocacheentry. The same ReadTheDocs documentation has holder/prover (https://von-anchor.readthedocs.io/en/latest/von_anchor_roles.html#module-von_anchor.anchor.holderprover) and verifier documentation and code.

swcurran (Wed, 28 Nov 2018 05:56:02 GMT):
@smithbk - I think the only scenario that could change the result is the revocation - I'm pretty sure there is not a verkey that could change that could affect the proof. Regards proofing "in the past". The prover and the verifier have to be able to align on the time of verification because if they are using different accumulators, the proof of non-revocation will not work. For example, suppose I do a proof, send it to you and before you verify the non-revocation part, the issuer revokes some credentials (and so changes the on ledger accumulator). If you get the new accumulator, and not the one I used for the proof, the verification would fail. There must be a way for the prover and verifier to synchronize on that. That implies that a prover could use a "far in the past" time to do the proof - perhaps to fool the verifier since the credential was subsequently forgotten. This is addressed by the verifier saying how old they are willing to accept a proof of non-revocation. Having said that, I'm not _exactly _ sure how that all works - other than reading and thinking through the ramifications. I would suggest looking at the revocation work that @sklump has done in von_anchor. He has implemented quite a lot of functionality around revocation and tails file generation/management. In his docs, there is a section on revocation timing - https://von-anchor.readthedocs.io/en/latest/revocation-and-tails-files.html#revocacheentry. The same ReadTheDocs documentation has holder/prover (https://von-anchor.readthedocs.io/en/latest/von_anchor_roles.html#module-von_anchor.anchor.holderprover) and verifier documentation and code.

swcurran (Wed, 28 Nov 2018 05:56:02 GMT):
@smithbk - I think the only scenario that could change the result is the revocation - I'm pretty sure there is not a verkey that could change that could affect the proof. Regards proofing "in the past". The prover and the verifier have to be able to align on the time of verification because if they are using different accumulators, the proof of non-revocation will not work. For example, suppose I do a proof, send it to you and before you verify the non-revocation part, the issuer revokes some credentials (and so changes the on ledger accumulator). If you get the new accumulator, and not the one I used for the proof, the verification would fail. There must be a way for the prover and verifier to synchronize on that. That implies that a prover could use a "far in the past" time to do the proof - perhaps to try to fool the verifier since the credential was subsequently revoked. This is addressed by the verifier saying how old they are willing to accept a proof of non-revocation - refusing to accept a proof that is too old. Having said that, I'm not _exactly _ sure how that all works - other than reading and thinking through the ramifications. I would suggest looking at the revocation work that @sklump has done in von_anchor. He has implemented quite a lot of functionality around revocation and tails file generation/management. In his docs, there is a section on revocation timing - https://von-anchor.readthedocs.io/en/latest/revocation-and-tails-files.html#revocacheentry. The same ReadTheDocs documentation has holder/prover (https://von-anchor.readthedocs.io/en/latest/von_anchor_roles.html#module-von_anchor.anchor.holderprover) and verifier documentation and code.

sklump (Wed, 28 Nov 2018 11:31:37 GMT):
@smithbk ... but fundamentally, no, there is no way to query a general quantity's value in the past. Only the revocation registries track state by delta.

sklump (Wed, 28 Nov 2018 11:31:37 GMT):
@smithbk ... but fundamentally, no, there is no way to query a general quantity's value in the past. Only the revocation registries track state by delta. And querying those nets out to polling the ledger for a transaction marking the times of interest as quantities - i.e., getting a current value with markings that match, not a true archival approach. That being said, ledger content is immutable once written so the difference is academic in practice.

sergey.minaev (Wed, 28 Nov 2018 12:58:54 GMT):
@kdenhartog @MALodder I don't understand purpose of `message_raw` / `_len` parameters after question from @kdenhartog and response from @MALodder ... What is message here? String/text? Bytes (e.g. text after encryption)? or something else?

sergey.minaev (Wed, 28 Nov 2018 13:00:22 GMT):
@sklump @smithbk @swcurran in theory it's possible to implement new feature in Indy Node to be able to request anything in the past, but now it's implemented only for revocation registry as must-have feature for revocation flow

MALodder (Wed, 28 Nov 2018 14:51:16 GMT):
@sergey.minaev message_raw and _len are the message to be encrypted

MattRaffel (Wed, 28 Nov 2018 15:34:12 GMT):
@MALodder technically you would know the lengthof the string since C strings are null terminated. If the input can have nulls in it and length is required then I suggest input type be changed to byte

MALodder (Wed, 28 Nov 2018 15:34:49 GMT):
if you look at all the indy API functions, they all follow this pattern

MALodder (Wed, 28 Nov 2018 15:35:00 GMT):
you can't do lengthof in C

MALodder (Wed, 28 Nov 2018 15:35:13 GMT):
so C must know the length of the data

MALodder (Wed, 28 Nov 2018 15:36:33 GMT):
@MattRaffel ^^

MattRaffel (Wed, 28 Nov 2018 15:37:46 GMT):
if this helps: Use std::ffi::CStr to wrap the pointer. CStr will compute the length of the string based on the terminating NUL. This requires an unsafe block as we will be dereferencing a raw pointer, which the Rust compiler cannot verify meets all the safety guarantees so the programmer must do it instead. http://jakegoulding.com/rust-ffi-omnibus/string_arguments/

MattRaffel (Wed, 28 Nov 2018 15:39:06 GMT):
I wasnt trying to argue the design. Just sharing info I've learned.

MALodder (Wed, 28 Nov 2018 16:00:21 GMT):
yeah if you look at the rust wrapper for indy-sdk, I use that everywhere

smithbk (Wed, 28 Nov 2018 16:34:48 GMT):
@swcurran @sklump @sergey.minaev Thanks much for the info. But I'm not sure why a key rotation to change the verkey would not also be an issue. Could someone explain?

handicraftswoman (Thu, 29 Nov 2018 07:50:57 GMT):
@smithbk Trying to build the iOS libs for libvcx : Could not resolve host: repo.corp.evernym.com

handicraftswoman (Thu, 29 Nov 2018 07:51:17 GMT):
@sergey.minaev Trying to build the iOS libs for libvcx : Could not resolve host: repo.corp.evernym.com

handicraftswoman (Thu, 29 Nov 2018 08:53:45 GMT):
@stanleyc-trustscience Trying to build the iOS libs for libvcx : Could not resolve host: repo.corp.evernym.com

GEEKTEDDY (Thu, 29 Nov 2018 09:24:30 GMT):
I have a problem about revocation.

GEEKTEDDY (Thu, 29 Nov 2018 09:29:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=B6miJJcrQWEPijiXM) Think about the situation. If verifier gets the proof from prover, and meanwhile, the credential which created the proof is revoked by issuer. For now, the proof can still be verified on verifier side, but it doesn't make sense. So is there any solution to void this?

gy8409i (Thu, 29 Nov 2018 10:58:52 GMT):
Has joined the channel.

sergey.minaev (Thu, 29 Nov 2018 11:27:40 GMT):
@GEEKTEDDY check "is proof revoked or not" is performed against some state of public available revocation registry. 1) Verifier can specify in proof request acceptable time interval (e.g. few minutes ago or newer) 2) Proover choose particular timestamp and present proof for this timestamp 3) At validating Verifier should check that chosen (by proover) timestamp is acceptable and fetch revocation registry state for this particular moment, not the latest one. Otherwise validation may fail. It's recommended way. As an option (before validation) Verifier can read the latest state on the ledger and analyze it. Or fetch delta from proover timestamp to now and be sure that there is no revocation in this interval. Or even use the latest state rather chosen by proover. But in this case false-negative result is possible. And the reasons may be different - someone (may be the proover, may be another one) is revoked, or new credential issued - any change in revocation registry accumulator between proover timestamp and verifier will results in validation fail. This is a reason why 1-3 steps are recommended

smithbk (Thu, 29 Nov 2018 14:47:51 GMT):
Suppose an issuer re-issues a credential to a holder. Is it best practice for the holder to delete the old credential after successfully storing the newly issued credential? I can't think of a reason that a holder would need to hold on to the old credential but maybe I'm missing a use case. Anyone, any thoughts on this? Thanks

gudkov (Thu, 29 Nov 2018 15:07:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=eMtGMMPRcdsBhkNTi) @smithbk In my vision it can be handled on application level. Wallet for the moment doesn't support deletions, but application can logically mark such credential as deleted.

gudkov (Thu, 29 Nov 2018 15:08:45 GMT):
If you think that deletion/replacement is important i suggest to create HIPE or at least Jira ticket for this.

smithbk (Thu, 29 Nov 2018 15:17:04 GMT):
@gudkov Thanks and good to know, but my question is higher level. I'm wondering if anyone knows of a reason/use-case which would require a holder to need to access an old credential. For example, any use case for someone needing to prove that they possessed a credential at some time in the past (e.g. 3 years ago) even though that credential might have expired. I think the answer to this question will drive whether to open a jira.

jljordan_bcgov (Thu, 29 Nov 2018 15:17:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=i6WwEYSWX5Gs447nF) @canadaduane https://wiki.hyperledger.org/projects/indy/roadmap ... not sure if someone answered you @canadaduane ... I'm behind on my chats!

gudkov (Thu, 29 Nov 2018 15:23:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=sxxMq4u67Z4ykDhzL) @smithbk In my vision there can be use cases to store old credentials. For example, you get a new passport with changed name. Old one can be revoked, but you can still make proof that in the past you owned passport with your old name.

smithbk (Thu, 29 Nov 2018 15:32:36 GMT):
@gudkov Thanks, a good real-world use case

tomislav (Thu, 29 Nov 2018 15:38:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5hRpLouYAQi3RaeA2) @sergey.minaev Are you referring to concerns including specific implementations of plugged storage or the actual wrapper for the `indy_register_wallet_storage` function? I'm asking since I submitted a PR for the dotnet wrapper - just want to know if there's anything I can address

xnopre (Thu, 29 Nov 2018 16:23:42 GMT):
I try to write a NodeJs script to improve revocation process (when ended and running well, I will share this script in a Pull Request in `indy-sdk` ;-) ). I'm taking some informations from sample `anoncreds_revocation.py` that I have rewritten and shared in sample `anoncredsRevocation.js`. Calling `issuerCreateCredential` returns a `revRegDelta` (for issuer). To verify the proof, the verifier call `verifierVerifyProof` and needs `revRegDelta`. How verifier can retrieve this `revRegDelta` created by issuer ? Similar question... How prover can retrieve `revRegDelta` and `credRevId` to call `createRevocationState` ?

sklump (Thu, 29 Nov 2018 18:35:31 GMT):
@xnopre, the issuer writes rev reg deltas and (accumulator) states to the ledger. The prover gets them from the ledger (build get revoc reg request, parse get revoc reg response). The verifier gets the state from the ledger along the same lines (build get revoc reg request, parse get revoc reg response). `from`/`to` are the goalposts of what timestamp range is acceptable: any timestamp for which the prover has information inside these bounds (inclusively) will do - it might save a trip to the ledger. The prover generates a proof on a timestamp of its choice from between the input `from`/`to` values (inclusively). If the inspector/verifier is only interested in one timestamp, set `from` and `to` the same.

sklump (Thu, 29 Nov 2018 18:35:31 GMT):
@xnopre, the issuer writes rev reg deltas and (accumulator) states to the ledger. The prover gets them from the ledger (build get revoc reg request, parse get revoc reg response). The verifier gets the state from the ledger along the same lines (build get revoc reg request, parse get revoc reg response). `from` / `to` are the goalposts of what timestamp range is acceptable: any timestamp for which the prover has information inside these bounds (inclusively) will do - it might save a trip to the ledger. The prover generates a proof on a timestamp of its choice from between the input `from`/`to` values (inclusively). If the inspector/verifier is only interested in one timestamp, set `from` and `to` the same.

sklump (Thu, 29 Nov 2018 18:35:31 GMT):
@xnopre, the issuer writes rev reg deltas and (accumulator) states to the ledger. The prover gets them from the ledger (build get revoc reg request, parse get revoc reg response). The verifier gets the state from the ledger along the same lines (build get revoc reg request, parse get revoc reg response). `from` / `to` are the goalposts of what timestamp range is acceptable: any timestamp for which the prover has information inside these bounds (inclusively) will do - it might save a trip to the ledger. The prover generates a proof on a timestamp of its choice from between the input `from` / `to` values (inclusively). If the inspector/verifier is only interested in one timestamp, set `from` and `to` the same.

GEEKTEDDY (Fri, 30 Nov 2018 00:55:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=74fSskmjjmesNmkFJ) @sergey.minaev @sergey.minaev thank you! yes, the 3 steps make sense. So if verifier fetched delta from prover timestamp to now and found the revocation when he got the proof, maybe verifier should re-send the proof request? cause verifier must make sure the proof is still available.

GEEKTEDDY (Fri, 30 Nov 2018 01:01:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=74fSskmjjmesNmkFJ) @sergey.minaev @sergey.minaev thank you! yes, the 3 steps make sense. So if verifier fetched delta from prover timestamp to now and found the revocation when he got the proof, maybe verifier should re-send the proof request? cause verifier must make sure the proof is still available. vb bm b vbb jhj johg cvgffrxz\

arunwij (Fri, 30 Nov 2018 04:22:39 GMT):

sovrin_connection_transaction.png

arunwij (Fri, 30 Nov 2018 04:22:41 GMT):
Is it necessary to have a public DID for each identity owner? If it is not necessary... When Alice and Bob make a connection (they don't have a public DID), their *connection offer* and *connection request* messages will be unencrypted( is it?). How can we improve security of those requests? I am referring sovrin connection flow.

arunwij (Fri, 30 Nov 2018 04:22:41 GMT):
Is it necessary to have a public DID for each identity owner? If it is not necessary... When Alice and Bob make a connection (they don't have public DIDs), their *connection offer* and *connection request* messages will be unencrypted( is it?). How can we improve security of those requests? I am referring sovrin connection flow.

arunwij (Fri, 30 Nov 2018 04:23:09 GMT):

sovrin_connection_transaction.png

dbluhm (Fri, 30 Nov 2018 04:35:29 GMT):
@arunwij the connection protocol is under active discussion in the Agent community. We're not quite pleased with it as it is **yet**. Join us in #indy-agent to engage in the discussion.

arunwij (Fri, 30 Nov 2018 05:34:24 GMT):
@dbluhm Yes. Thank you. Is this the protocol using now?

mtfk (Fri, 30 Nov 2018 10:36:08 GMT):
Has joined the channel.

mtfk (Fri, 30 Nov 2018 10:40:42 GMT):
Hi everyone, I am trying to grasp how to use SDK indy to interact with the nodes (my goal is to create DID and use it to exchange credentials). Basically I am following the getting started doc with Alice, Faber, Acme corp, Thrift etc. But I think I am missing something. If I may ask few question to help me out: 1) Is there sovrin test net which I can connect to (become Trust Anchor) and create my own DID's? 2) I started poll locally from docker container (since didn't found how to connect to test poll from sovrin) but no idea how to interact with it. Is there any guide for that?

sklump (Fri, 30 Nov 2018 11:22:51 GMT):
@GEEKTEDDY "... Or fetch delta from proover timestamp to now and be sure that there is no revocation in this interval" Be careful here. These are not the semantics of `(from, to)`. Even if there is a revocation in-between, the request implies that _any_ timestamp within `(from, to)` will do. It is not a non-revocation interval in the X.509/PKIX sense.

sklump (Fri, 30 Nov 2018 11:34:57 GMT):
More chronic version lock-in rot: python requests 2.20.x apparently requires pip 18+. However, there is a security alert on requests<2.20.x and python3-indy can only take up to pip 9, so now indy-sdk is an anti-requisite for requests in the same environment. This is a significant loss of amenity: python requests is so close to being core python that the http.client documentation recommends it implementation: https://docs.python.org/3/library/http.client.html# (first yellow box). If nobody on the team can spare the cycles to maintain the dependency chain, problems like this are going to sprout. Admittedly, python is only a wrapper and one could argue that we should all just use rust, but there is a lot of code now hanging off the python wrapper.

sklump (Fri, 30 Nov 2018 11:34:57 GMT):
More chronic version lock-in rot: python requests 2.20.x apparently requires pip 18+. However, there is a security alert on requests<2.20.x and python3-indy can only take up to pip 9, so now indy-sdk is an anti-requisite for requests in the same environment. This is a significant loss of amenity: python requests is so close to being core python that the http.client documentation recommends its adoption: https://docs.python.org/3/library/http.client.html# (first yellow box). If nobody on the team can spare the cycles to maintain the dependency chain, problems like this are going to sprout. Admittedly, python is only a wrapper and one could argue that we should all just use rust, but there is a lot of code now hanging off the python wrapper.

mwherman2000 (Fri, 30 Nov 2018 12:43:29 GMT):
Has joined the channel.

xnopre (Fri, 30 Nov 2018 14:23:23 GMT):
@sklump Thanks for you answer. I found methods to set delta to ledger and then get it : OK. My next blocking question to finish my script is : how can the prover know the `cred rev id` to call `create revocation state`, this `cred rev id` is known by issuer after calling `issuer create credential` ?

ardagumusalan (Fri, 30 Nov 2018 14:29:30 GMT):
Has joined the channel.

sklump (Fri, 30 Nov 2018 14:35:47 GMT):
It's in the cred_info as attribute `cred_rev_id`. The best sample for revocation is in `wrappers/python/tests/interation/test_interaction.py`.

sklump (Fri, 30 Nov 2018 14:35:47 GMT):
It's in every credential's `cred_info` dict as attribute `cred_rev_id`. (Its value is null if the cred def does not support revocation). The best sample for revocation is in `wrappers/python/tests/interation/test_interaction.py`.

xnopre (Fri, 30 Nov 2018 14:43:38 GMT):
@sklump Yes ! Great ! Thanks ! Is there some document, or information, or sequence schema to understand recovation (and concepts as state, delta, from, to, ....) ? I see that there are many questions about this subject (cc @GEEKTEDDY ) and only source script are not enough to good understand (for me)... Thanks :-)

sklump (Fri, 30 Nov 2018 14:46:42 GMT):
https://github.com/hyperledger/indy-hipe/tree/master/text/0011-cred-revocation

sklump (Fri, 30 Nov 2018 14:46:42 GMT):
https://github.com/hyperledger/indy-hipe/tree/master/text/0011-cred-revocation You have to toy with the samples and tweak and prod and suffer for a while. Indy revocation is hard. Think of it as job security.

mgbailey (Fri, 30 Nov 2018 15:05:12 GMT):
@mtfk Send me the DID and verkey of the Trust Anchor that you want added to the TestNet. The genesis file for TestNet is at https://raw.githubusercontent.com/sovrin-foundation/sovrin/master/sovrin/pool_transactions_sandbox_genesis

donqui (Fri, 30 Nov 2018 15:34:37 GMT):
Has joined the channel.

xnopre (Fri, 30 Nov 2018 16:08:27 GMT):
@sklump Thanks for the link. I know this page. I will re-read it one again ;-) , but I was hopping for something else, more explicitly and concret... Perhaps my script would be helpful for future users... (this script will be push as MR in indy-sdk samples). And thanks for your encouragements :-P

xnopre (Fri, 30 Nov 2018 16:10:10 GMT):
@sklump What is the use of `timestamp` returned by `Get Revoc Reg Delta` ?

sklump (Fri, 30 Nov 2018 16:14:32 GMT):
@xnopre it is the timestamp on which the ledger wrote the delta. It could be anywhere between `from` and `to` inclusively in the response from `await ledger.build_get_revoc_reg_delta_request(self.did, rr_id, fro, to)`.

sklump (Fri, 30 Nov 2018 16:14:32 GMT):
@xnopre it is the timestamp on which the ledger wrote the delta. It could be anywhere between `fro` and `to` inclusively in the response from `await ledger.build_get_revoc_reg_delta_request(self.did, rr_id, fro, to)`.

ardagumusalan (Fri, 30 Nov 2018 19:10:03 GMT):
Hi @sklump ; i have been looking into credential revocation recently had some good progress but ran into a problem. I described it in https://jira.hyperledger.org/browse/IS-1100 do you mind having a look at it when you have the time? Thanks in advance

sklump (Fri, 30 Nov 2018 19:15:31 GMT):
@ardagumusalan that's going to have to be a core indy-sdk developer. I'm a user like you. This looks interesting though.

adamjbradley (Fri, 30 Nov 2018 21:39:45 GMT):
Morning all!

adamjbradley (Fri, 30 Nov 2018 21:41:00 GMT):
Anyone using indy-sdk on Windows? I've got the Node up and running but I'm having a few connectivity issues

dbluhm (Fri, 30 Nov 2018 21:52:56 GMT):
@burdettadam ^^^

adamjbradley (Fri, 30 Nov 2018 21:54:31 GMT):
Also having trouble building dummy-cloud-agent

adamjbradley (Fri, 30 Nov 2018 21:55:51 GMT):
indy.dll.lib not found - I only have the binary distribution which includes a DLL

adamjbradley (Fri, 30 Nov 2018 21:56:08 GMT):
Assume I need to build indk-sdk to get the .lib file

adamjbradley (Fri, 30 Nov 2018 21:58:04 GMT):
Better still, does anyone have an eli5 article for setting indk-sdk on Windows

adamjbradley (Fri, 30 Nov 2018 21:58:09 GMT):
Will check medium!

MattRaffel (Fri, 30 Nov 2018 22:00:03 GMT):
https://stackoverflow.com/questions/9360280/how-to-make-a-lib-file-when-have-a-dll-file-and-a-header-file

MattRaffel (Fri, 30 Nov 2018 22:00:19 GMT):
look up tool called dumpbin

adamjbradley (Fri, 30 Nov 2018 22:00:37 GMT):
I do actually have both of those :)

adamjbradley (Fri, 30 Nov 2018 22:00:42 GMT):
Thanks @MattRaffel

burdettadam (Fri, 30 Nov 2018 22:02:02 GMT):
@adamjbradley I suggest using docker. I have docker running in windows with Ubuntu Shell in windows subsystem for linux (WSL). Then you can follow this https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md.

adamjbradley (Fri, 30 Nov 2018 22:03:45 GMT):
Can!

adamjbradley (Fri, 30 Nov 2018 22:03:52 GMT):
Kicked off now, thanks

adamjbradley (Fri, 30 Nov 2018 22:05:37 GMT):
Got the Node running in Docker already

adamjbradley (Fri, 30 Nov 2018 22:07:39 GMT):
I keep discounting WSL

adamjbradley (Fri, 30 Nov 2018 22:07:46 GMT):
Forgetting that is

adamjbradley (Fri, 30 Nov 2018 22:08:01 GMT):
Just because it can't do X11, doesn't mean it can't do other things

adamjbradley (Fri, 30 Nov 2018 22:16:31 GMT):
Building @burdettadam

adamjbradley (Fri, 30 Nov 2018 23:15:43 GMT):
Working a treat!

adamjbradley (Fri, 30 Nov 2018 23:15:48 GMT):
Thanks guys

stanleyc-trustscience (Sat, 01 Dec 2018 04:09:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mfAFJxoaB83coStdc) @handicraftswoman @handicraftswoman Sorry, never tried that before, you might have to reach out to evernym

adamjbradley (Sat, 01 Dec 2018 21:48:18 GMT):
Morning all!

swcurran (Sun, 02 Dec 2018 12:28:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=GXC5ZL2q9AG6xeqgH) @smithbk The only DID verkey involved in the issuance and proving of a Credential is the DID of the Issuer that is defined in the Credential Definition. Since that must be a DID on the ledger, the Verifier will get the DIDDoc associated with that DID at any time, always getting the latest verkey. No concern there. There are also verkeys associated with each claim of the Credential via the Credential Definition. AFAIK, those keys cannot be rotated, as that would make creating and verifying a proof impossible. Rather, if there is a concern with with the keypairs, a new Credential Definition would be created to be used to issue new Credentials, such that already existing Credentials would not be affected. So again, there is no issue with a verkey being rotated. Hope that makes sense.

tplooker (Mon, 03 Dec 2018 09:19:22 GMT):
Has joined the channel.

bootstrapsp (Mon, 03 Dec 2018 17:10:03 GMT):
Looking for some help on understanding what should be the network name and is the indy_config.py is the right file to set this parameter in?

bootstrapsp (Mon, 03 Dec 2018 17:10:03 GMT):
Looking for some help on understanding what should be the network name and is the indy_config.py is the right file to set this parameter in? Installed the IndyNode using the deb pacakge for ubuntu so its basically a non docker installation

gudkov (Mon, 03 Dec 2018 17:28:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=xA2kxtjcboEZhbjn8) @bootstrapsp Hi, I suggest to ask in #indy-node channel

bootstrapsp (Mon, 03 Dec 2018 19:25:49 GMT):
@gudkov Hey, thanks didn't know about that channel, will do

MainframeBatch10 (Tue, 04 Dec 2018 08:07:52 GMT):
Has joined the channel.

MainframeBatch10 (Tue, 04 Dec 2018 08:12:07 GMT):
I have installed indy-sdk as per GitHub documentation. But don't know how to write programs for creating DID , managing proofs etc.. What are all other softwares I need to install.. Can anyone share some video tutorials regarding identity management using indy-sdk

donqui (Tue, 04 Dec 2018 08:17:27 GMT):
@MainframeBatch10 indy-sdk does not require additional software, just a wrapper through which you will use it. all of the requirements needed for ledger communication, DID generation, wallet communication, credentials/proofs should be installed along with it. I do not know about video tutorials but there is a getting started page that guides you through how to create DIDs, store DIDs, etc...: https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md. There are also HowTos that illustrate how to perform specific actions using IndySDK: https://github.com/hyperledger/indy-sdk/tree/master/doc/how-tos

donqui (Tue, 04 Dec 2018 08:17:27 GMT):
@MainframeBatch10 indy-sdk does not require additional software, just a wrapper through which you will use it. All of the requirements needed for ledger communication, DID generation, wallet communication, credentials/proofs should already be installed along with indy-sdk. I do not know about video tutorials but there is a getting started page that guides you through how to create DIDs, store DIDs, etc...: https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md. There are also HowTos that illustrate how to perform specific actions using IndySDK: https://github.com/hyperledger/indy-sdk/tree/master/doc/how-tos

xnopre (Tue, 04 Dec 2018 10:02:53 GMT):
Hi all :-) . Sometimes, I have this error : `IndyError: CommonInvalidStructure` that is very not expressive of what is the problem... :-( ... If I restart my script with `RUST_LOG=indy=trace`, I have more informations, for example `Invalid structure: Cannot deserialize ProofRequest: InvalidStructure("missing field `requested_predicates` at line 1 column 151")` which is very helpful to find the problem. Could there be a solution to have this details in `IndyError: CommonInvalidStructure` without having to activate Rust debug trace level ? Thanks :-)

adamjbradley (Tue, 04 Dec 2018 12:08:23 GMT):
Howdy all

adamjbradley (Tue, 04 Dec 2018 12:09:27 GMT):
Wondering if anyone has an end-to-end Login (DID Auth) Demo

adamjbradley (Tue, 04 Dec 2018 12:10:32 GMT):
Does anyone have any experience working with the bcgov examples?

louisk (Tue, 04 Dec 2018 13:30:54 GMT):
wow @xnopre thank you for that tip

louisk (Tue, 04 Dec 2018 13:31:06 GMT):
i too have been battling up that error

ardagumusalan (Tue, 04 Dec 2018 15:18:58 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=atFaqdaQHcdozSfr7) @xnopre =trace is also what my team uses

ardagumusalan (Tue, 04 Dec 2018 15:22:14 GMT):
Hi everyone. I can see that for credential revocation the following two information is needed: rev_reg_def_id, cred_rev_id. It is not clear to me which of these is only known by the issuer of the credential. Can someone elaborate please?

MALodder (Tue, 04 Dec 2018 15:24:17 GMT):
both are know by the issuer, one is to find the revocation registry on the ledger, the other is the revocation id assigned to the credential held by the Prover

ardagumusalan (Tue, 04 Dec 2018 15:24:48 GMT):
are they only know by the issuer?

ardagumusalan (Tue, 04 Dec 2018 15:24:48 GMT):
are they only known by the issuer?

MALodder (Tue, 04 Dec 2018 15:25:10 GMT):
rev_reg_def_id is public and on the ledger

MALodder (Tue, 04 Dec 2018 15:25:19 GMT):
cred_rev_id is know to the issuer and the prover

MALodder (Tue, 04 Dec 2018 15:25:19 GMT):
cred_rev_id is known to the issuer and the prover

MALodder (Tue, 04 Dec 2018 15:25:46 GMT):
The issuer needs to know it so they can revoke it if needed

MALodder (Tue, 04 Dec 2018 15:25:55 GMT):
the prover needs to know it to prove non-revocation

ardagumusalan (Tue, 04 Dec 2018 15:25:55 GMT):
ok so is it possible for the prover to revoke that credential then?

MALodder (Tue, 04 Dec 2018 15:26:03 GMT):
no

MALodder (Tue, 04 Dec 2018 15:26:26 GMT):
to revoke, they would have to possess the private key for the revocation registry which only the issuer holds

ardagumusalan (Tue, 04 Dec 2018 15:26:38 GMT):
got it thanks

MALodder (Tue, 04 Dec 2018 15:26:59 GMT):
to do ZKPs, you must know all the attribute values which is why the prover knows it

sklump (Tue, 04 Dec 2018 16:15:02 GMT):
I notice that apparently a trust anchor with a null role can still sign and submit a NYM request to change its verification key. Is this expected behaviour? What signed transactions can an anchor with null role submit? Thanks in advance.

sklump (Tue, 04 Dec 2018 16:15:02 GMT):
I notice that apparently a trust anchor with a null role can still sign and submit a NYM request to change its verification key. Is this expected behaviour? It's delightful but I expected it to choke. What signed transactions can an anchor with null role submit? Thanks in advance.

cguerin (Tue, 04 Dec 2018 16:28:35 GMT):
Hi, I'm currently trying to build indy-lib and on the cargo step i've the following error: ``` error: glob imports in `use` groups are experimental (see issue #44494) --> src/services/pool/events.rs:7:35 | 7 | use services::pool::{PoolService, types::*}; | ^^^^^^^^ error: paths in `use` groups are experimental (see issue #44494) --> src/services/pool/state_proof/mod.rs:12:33 | 12 | use domain::ledger::{constants, request::ProtocolVersion}; | ^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors error: Could not compile `libindy`. ``` Thanks for your help

KitHat (Tue, 04 Dec 2018 16:29:34 GMT):
@cguerin what are your cargo and rust versions?

cguerin (Tue, 04 Dec 2018 16:30:37 GMT):
@KitHat cargo 0.25.0 How i can know my rust version?

cguerin (Tue, 04 Dec 2018 16:31:07 GMT):
rust -V give me a command not found, maybe it's my rust install that failed?

KitHat (Tue, 04 Dec 2018 16:31:14 GMT):
`rustc --version`

cguerin (Tue, 04 Dec 2018 16:31:33 GMT):
thx

cguerin (Tue, 04 Dec 2018 16:31:34 GMT):
cargo 0.25.0

cguerin (Tue, 04 Dec 2018 16:31:44 GMT):
rustc 1.24.1

KitHat (Tue, 04 Dec 2018 16:31:50 GMT):
Try to update it to 1.27 using `rustup` and it should work

KitHat (Tue, 04 Dec 2018 16:31:59 GMT):
It should be no more experimental

cguerin (Tue, 04 Dec 2018 16:32:01 GMT):
Ok, i'm gonna try

cguerin (Tue, 04 Dec 2018 16:32:06 GMT):
thank you :)

cguerin (Tue, 04 Dec 2018 16:32:29 GMT):
rustup need to be installed?

KitHat (Tue, 04 Dec 2018 16:32:59 GMT):
Weird, they are usually installed together.

cguerin (Tue, 04 Dec 2018 16:33:09 GMT):
O_o

KitHat (Tue, 04 Dec 2018 16:33:12 GMT):
What OS are you using?

cguerin (Tue, 04 Dec 2018 16:33:20 GMT):
Debian V9.0

KitHat (Tue, 04 Dec 2018 16:34:47 GMT):
I guess you have installed it from repos -- it is a bit outdated there.

KitHat (Tue, 04 Dec 2018 16:34:54 GMT):
https://rustup.rs/ -- try it out

cguerin (Tue, 04 Dec 2018 16:35:06 GMT):
Ok, i'm gonna try

cguerin (Tue, 04 Dec 2018 16:56:23 GMT):
it seems that i can't switch to 1.27 version..

MiguelFJimenezSola (Tue, 04 Dec 2018 19:25:51 GMT):
Has joined the channel.

user7429 (Wed, 05 Dec 2018 05:18:51 GMT):
Has joined the channel.

PhillipGibb (Wed, 05 Dec 2018 06:44:59 GMT):
Hi, I am playing around with a mobile app, taking a look at evernym's sovrin-connector-preview Are there prebuild binaries/libs for certain phones? I am struggling to understand how to build something I can use for my phone, the documentation is parse thanks

user7429 (Wed, 05 Dec 2018 07:47:41 GMT):
Hi, I have setup indy node on GCP without using docker. Now I am trying to establish connection from my local system to remote indy using python.

user7429 (Wed, 05 Dec 2018 07:47:41 GMT):
Hi, I have setup indy node on GCP without using docker. Now I am trying to establish connection from my local system to remote indy using python. My question is where shall i pass the remote VM ip in my local client code?

kdenhartog (Wed, 05 Dec 2018 09:49:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=faMZHPhgAE5nMTaef) @sklump This is likely a better question for #indy-node @ashcherbakov would be the person who could answer if this is expected

kdenhartog (Wed, 05 Dec 2018 09:51:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=M8fJwwQeh3ePyYLka) @PhillipGibb I don't believe this was included. I know this is still in preview mode at this point so the transition from proprietary work to open source as well as support for A2A protocol is still in progress

ashcherbakov (Wed, 05 Dec 2018 09:52:42 GMT):
@sklump If this is TrustAnchor's DID, then this is expected, since any user has a full control over his own data, and can rotate his keys. If this is a new NYM, or a NYM created for another user, then this is bug.

PhillipGibb (Wed, 05 Dec 2018 09:57:57 GMT):
@kdenhartog seems that https://repo.sovrin.org/android is the place but it is not clear in the preview how these are included in the build there is also sovrin-connector-preview/android/scripts/full.stack.build.sh which seems to build everything but has a vagrant machine dependency. It would be good to speak to the devs just to get a build going

kdenhartog (Wed, 05 Dec 2018 10:06:05 GMT):
@PhillipGibb Can you DM about this? I'll see what I can do to help.

user7429 (Wed, 05 Dec 2018 11:00:31 GMT):
exit

superafro12 (Wed, 05 Dec 2018 11:49:31 GMT):
Hello!

superafro12 (Wed, 05 Dec 2018 11:55:20 GMT):
I've followed the indy sdk getting started guide, but I don't understand the usage of the nonce that's used when Steward and Faber establish two DIDs for secure communication. According to the guide, "Steward authenticates Faber by the comparison of Nonce.". I can't seem to understand how this nonce can be used to authenticate the Faber. Can't a MITM read the nonce from the connection request and send a connection response with that nonce? The guide states that Faber signs the nonce. I assume that it signs the nonce with its private key from the DID created for interaction with the Steward. However, that DID isn't added to the ledger yet and Steward has no way of getting the verkey of that DID. How and why is this nonce (challenge) used? Thank you!

sklump (Wed, 05 Dec 2018 13:00:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5pn3diZ5hGvru6Byb) @ashcherbakov It works exactly according to plan then.

mgbailey (Wed, 05 Dec 2018 15:05:59 GMT):
@user7429 a client uses a genesis transaction file to learn the IP addresses and ports of the indy nodes in a validator pool. The client randomly choses among the validators one to connect to.

smithbk (Wed, 05 Dec 2018 17:35:02 GMT):
Hi, is it possible to use the indy-sdk APIs to perform a non-interactive verification flow? That is, suppose the prover already knows what the verifier needs to know. Is it possible for the prover to generate a proof, pass it to the verifier, and then the verifier verifies the proof without further communication with the prover? Thanks

sklump (Wed, 05 Dec 2018 19:07:54 GMT):
@smithbk sure, a proof is self-contained. The verifier needs only the proof request, the proof, and access to the ledger for cited schemata, cred defs, and revocation registry definitions & states. It is fine for the prover to generate the proof request if the prover knows what should constitute it: the proof request has no cryptographic artifacts.

sklump (Wed, 05 Dec 2018 19:07:54 GMT):
@smithbk Sure: the verifier needs only the proof request, the proof, and access to the ledger for cited schemata, cred defs, and revocation registry definitions & states. It is fine for the prover to generate the proof request if the prover knows what should constitute it: the proof request has no cryptographic artifacts.

MALodder (Thu, 06 Dec 2018 03:26:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=as66fzFyNLD8mpHm3) @smithbk Yes because the proofs are already non-interactive

MALodder (Thu, 06 Dec 2018 03:27:14 GMT):
They are NIZKPs

MALodder (Thu, 06 Dec 2018 03:29:27 GMT):
The only thing the prover needs is a nonce from the verifier so the verifier knows this interaction is unique the messages can be asynchronous

AvikHazra (Thu, 06 Dec 2018 11:07:03 GMT):
when i`m trying to build cargo i`m getting failed to run custom build command for `openssl v0.9.24` error. can anyone help me please ?

KitHat (Thu, 06 Dec 2018 11:18:50 GMT):
@AvikHazra what OS are you using and which `openssl` version is installed?

AvikHazra (Thu, 06 Dec 2018 11:21:04 GMT):
I'm using ubuntu 16.04 and openssl -v OpenSSL 1.1.0h

AvikHazra (Thu, 06 Dec 2018 11:21:04 GMT):
I'm using ubuntu 16.04 and OpenSSL 1.1.0h

donqui (Thu, 06 Dec 2018 11:28:34 GMT):
@AvikHazra could you paste the entire error?

KitHat (Thu, 06 Dec 2018 11:29:30 GMT):
At the moment libindy needs both 1.0.x version and 1.1.0 version for build. (1.0.x for the libindy and 1.1.0 for libindy-crypto) Try to install both versions and rebuild.

AvikHazra (Thu, 06 Dec 2018 11:30:25 GMT):
this is the entire error :heart_eyes: Compiling openssl v0.9.24 error: failed to run custom build command for `openssl v0.9.24` process didn't exit successfully: `/var/www/html/indy-sdk/libindy/target/debug/build/openssl-90ac3274c6e2d0b4/build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'Unable to detect OpenSSL version', /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/build.rs:16:14 note: Run with `RUST_BACKTRACE=1` for a backtrace.

AvikHazra (Thu, 06 Dec 2018 11:30:25 GMT):
this is the entire error Compiling openssl v0.9.24 error: failed to run custom build command for `openssl v0.9.24` process didn't exit successfully: `/var/www/html/indy-sdk/libindy/target/debug/build/openssl-90ac3274c6e2d0b4/build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'Unable to detect OpenSSL version', /home/ubuntu/.cargo/registry/src/github.com-1ecc6299db9ec823/openssl-0.9.24/build.rs:16:14 note: Run with `RUST_BACKTRACE=1` for a backtrace.

donqui (Thu, 06 Dec 2018 11:34:19 GMT):
Like @KitHat said this is due to the OpenSSL library version that is installed on your system. You will most likely have to downgrade your OpenSSL installation. EDIT: I missed the entire comment made my @KitHat, do what he advised above: have both versions installed and try

donqui (Thu, 06 Dec 2018 11:34:19 GMT):
Like @KitHat said this is due to the OpenSSL library version that is installed on your system. You will most likely have to downgrade your OpenSSL installation. EDIT: I missed the entire comment made by @KitHat, do what he advised above: have both versions installed and try @AvikHazra

donqui (Thu, 06 Dec 2018 11:34:19 GMT):
Like @KitHat said this is due to the OpenSSL library version that is installed on your system. You will most likely have to downgrade your OpenSSL installation. EDIT: I missed the entire point of the comment made by @KitHat, do what he advised above: have both versions installed and try @AvikHazra

donqui (Thu, 06 Dec 2018 11:34:19 GMT):
Like @KitHat said this is due to the OpenSSL library version that is installed on your system. You will most likely have to downgrade your OpenSSL installation. EDIT: I missed the entire point of the comment made by @KitHat, do what he advised above: have both versions installed and try @AvikHazra if downgrading does not work. For me it works with `openssl version OpenSSL 1.1.0i-fips 14 Aug 2018`

donqui (Thu, 06 Dec 2018 11:34:19 GMT):
Like @KitHat said this is due to the OpenSSL library version that is installed on your system. You will most likely have to downgrade your OpenSSL installation. EDIT: I missed the entire point of the comment made by @KitHat, do what he advised above: have both versions installed and try @AvikHazra if downgrading does not work. For me it works with `1.1.0i-fips`

AvikHazra (Thu, 06 Dec 2018 11:35:01 GMT):
ok, let me check

sklump (Thu, 06 Dec 2018 11:47:47 GMT):
Yes - openssl-1.1.0i works OK for me. Then remember to issue ``` cargo clean ``` before rebuilding if it still gets caught. Version lock-in is creeping up in quite a few places now: python 3.5/3.6, pytest, pip, now openssl.

AvikHazra (Thu, 06 Dec 2018 11:53:56 GMT):
Tried this one now, didn't work. Same issue.

sklump (Thu, 06 Dec 2018 12:07:22 GMT):
``` wget https://www.openssl.org/source/openssl-1.1.0j.tar.gz tar -xpvzf openssl-1.1.0j.tar.gz cd openssl-1.1.0j ./configure make sudo make install openssl version ```

AvikHazra (Thu, 06 Dec 2018 12:43:20 GMT):
for openssl-1.1.0j same issue

sklump (Thu, 06 Dec 2018 13:03:34 GMT):
Are you sure you issued `cargo clean` in `indy-sdk/libindy` ?

sklump (Thu, 06 Dec 2018 13:03:47 GMT):
I just built it on my ubuntu 16.04 VM

donqui (Thu, 06 Dec 2018 13:09:28 GMT):
@sklump can you execute `ldconfig -p | grep libssl` just want to confirm something?

sklump (Thu, 06 Dec 2018 13:12:35 GMT):
``` libssl.so.1.1 (libc6,x86-64) => /usr/local/lib/libssl.so.1.1 libssl.so.1.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libssl.so.1.1 libssl.so.1.0.0 (libc6,x86-64) => /lib/x86_64-linux-gnu/libssl.so.1.0.0 libssl.so (libc6,x86-64) => /usr/local/lib/libssl.so libssl.so (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libssl.so ```

donqui (Thu, 06 Dec 2018 13:14:03 GMT):
I found that I also have two versions, one 1.1 and the other 1.0, and that might be the reason why I am not experiencing problems - my packet manager installed the new 1.1 version and 1.0 compatable version for all app that are not 1.1 compatible

donqui (Thu, 06 Dec 2018 13:14:47 GMT):
as KitHat said you might nedd to have both versions installed so that the compiler can use the version that is right for each dependancy

donqui (Thu, 06 Dec 2018 13:14:47 GMT):
as KitHat said you might need to have both versions installed so that the compiler can use the version that is right for each dependency

sklump (Thu, 06 Dec 2018 13:15:27 GMT):
This is bordering on silly. It has to become a priority to keep track of modern openssl for a cryptographic offering.

sklump (Thu, 06 Dec 2018 13:16:14 GMT):
Assuming rust hasn't got caught with its pants down on this

KitHat (Thu, 06 Dec 2018 13:16:58 GMT):
It is because old indy-crypto version in libindy still used. in the next release I hope it will be aligned (around libindy and libindy-crypto) on the same latest version.

AvikHazra (Thu, 06 Dec 2018 13:42:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mfHqXE3a7oN3FfCgy) @sklump yes. it worked but still Compiling for so long.

sklump (Thu, 06 Dec 2018 13:43:59 GMT):
Compilation takes a long time. That means you're doing it right.

sklump (Thu, 06 Dec 2018 13:43:59 GMT):
Compilation takes a long time - especially in `--release`. That means you're doing it right.

AvikHazra (Thu, 06 Dec 2018 13:44:26 GMT):
ok let see. thanks a lot :)

xnopre (Thu, 06 Dec 2018 15:12:33 GMT):
Hi all. I just spent some time to explore the "recovation" process. I have written a sample script in NodeJs, and I have just opened a Pull Request #1339 on ìndy-sdk` repository. This script `anoncredsRevocationScenario.js` (https://github.com/hyperledger/indy-sdk/blob/af163f2a5a04374b10cab7fb5171868a50225b41/samples/nodejs/src/anoncredsRevocationScenario.js) is an extension of `anoncredsRevocation.js` that I migrated in NodeJs from `anoncreds_revocation.py` sample. This script contains the revocation of a credential and then the verification (true or false) of the proof. My question is : how Alice can revoke (or disable or block or whatever...) the proof issued to the verifier ? Is there a mechanic for this case ? Thanks (

sklump (Thu, 06 Dec 2018 15:18:23 GMT):
Only the issuer can revoke a credential.

xnopre (Thu, 06 Dec 2018 15:46:14 GMT):
@sklump Yes, I known, for revocation of credential. But how a user can revoke (or other word for this action) a proof provided to a verifier ? Imagine, Alice share its residence credential with a bank, and after some months, she does not want anymore to share this information, so she want to revoke this data sharing with this bank. How to do that ?

sklump (Thu, 06 Dec 2018 16:08:26 GMT):
Too late, it's out there.

sklump (Thu, 06 Dec 2018 16:08:30 GMT):
As far as I know.

KitHat (Thu, 06 Dec 2018 16:13:22 GMT):
As far as I know we just making a proof of predicate given by the bank and do not share the credential itself

sklump (Thu, 06 Dec 2018 16:17:05 GMT):
Sure, but if a prior proof reveals an attribute value then there is not taking it back.

donqui (Thu, 06 Dec 2018 16:17:10 GMT):
I believe that if you are using proofs that disclose information there is no real way to prevent a entity on the other side to store it

donqui (Thu, 06 Dec 2018 16:17:10 GMT):
I believe that if you are using proofs that disclose information there is no real way to prevent a entity on the other side from storing it

xnopre (Thu, 06 Dec 2018 16:27:02 GMT):
Thanks @sklump @KitHat @donqui for your answers. I agree, the user share a proof, not a credential itself. My need is to know if there is a way, via the ledger, to invalidate the sharing of proof, to inform the issuer that the user does not want anymore to share this information.

louisk (Thu, 06 Dec 2018 16:27:54 GMT):
hey all, i've been working on issuing credentials and answering proof requests, mostly going well. i am unable to activate extra logs with `RUST_LOG=indy=trace`. I'm using macOS 10.14.1, indy / libindy 1.6.7, running an indy-pool in docker per the getting started guide, everything else is running locally on macOS.

louisk (Thu, 06 Dec 2018 16:28:15 GMT):
everything works great until i'm trying to store an issued credential using `proverStoreCredential`. I assume that's a coding error, but the extra logs would help a lot

louisk (Thu, 06 Dec 2018 16:29:07 GMT):
i've tried sourcing it as part of my `.env`, and `echo $RUST_LOG` returns `indy=trace` as expected. i'm using the node.js wrapper, and can see the env variable in node

louisk (Thu, 06 Dec 2018 16:30:13 GMT):
to be extra clear, from the README we have `proverStoreCredential $ wh, credId, credReqMetadata, cred, credDef, revRegDef $`

louisk (Thu, 06 Dec 2018 16:30:13 GMT):
to be extra clear, from the README we have `proverStoreCredential ( wh, credId, credReqMetadata, cred, credDef, revRegDef )`

louisk (Thu, 06 Dec 2018 16:31:02 GMT):
i'm passing it: `this.wallet, null, requestJson, credentialJson, credentialDefinition, null`, where req & credential JSON are the full output of the respective create calls

louisk (Thu, 06 Dec 2018 16:31:02 GMT):
i'm passing it: `this.wallet, null, requestJson, credentialJson, credentialDefinition, null`, where request & credential JSON are the full output of the respective create calls

MattRaffel (Thu, 06 Dec 2018 16:39:03 GMT):
@louisk for logging, you now have to hook in a logger as well as set the environment variable. indy-sdk now has a logging API

MattRaffel (Thu, 06 Dec 2018 16:39:03 GMT):
@louisk for logging, you now have to hook in a logger as well as set the environment variable. indy-sdk now has a logging API. I believe (anyone correct me if I am wrong) this was a change in 1.6.7

louisk (Thu, 06 Dec 2018 16:39:48 GMT):
ah cool!

swcurran (Thu, 06 Dec 2018 16:41:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=xdSgevigahX5seq6E) @xnopre No, there is no way to do that. There is no ledger writes in doing a proof, and no method to "revoke a proof".

louisk (Thu, 06 Dec 2018 16:42:19 GMT):
thanks @MattRaffel - i'll get `indy.setLogger` hooked into my logger

louisk (Thu, 06 Dec 2018 16:48:58 GMT):
truly life changing.

xnopre (Thu, 06 Dec 2018 16:50:42 GMT):
@louisk it works ? What have you done ?

xnopre (Thu, 06 Dec 2018 16:51:18 GMT):
@swcurran Oups.... Sure ? No way perhaps with key rotation, or other ? ...

louisk (Thu, 06 Dec 2018 16:52:03 GMT):
simply: ``` indy.setLogger((level, target, message, modulePath, file, line) => { if (config.debug && level > 4) { console.log(`[LIBINDY]: l: ${level}, t: ${target}, m: ${message}, p: ${modulePath}`) } })```

louisk (Thu, 06 Dec 2018 16:53:22 GMT):
`indy::api::anoncreds, m: missing field `master_secret_blinding_data` at line 1 column 1910` <-- guessing this means i incorrectly applied the master secret when creating the request? a wallet should have a new master secret for each request, yes?

louisk (Thu, 06 Dec 2018 16:53:22 GMT):
`indy::api::anoncreds, m: missing field master_secret_blinding_data at line 1 column 1910` <-- guessing this means i incorrectly applied the master secret when creating the request? a wallet should have a new master secret for each request, yes?

swcurran (Thu, 06 Dec 2018 16:57:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=CNNAwwDBESjxbKnh5) @xnopre Nope.

sklump (Thu, 06 Dec 2018 17:05:06 GMT):
@xnopre, if the cred def supports revocation, then the proof is only valid at its timestamp. So the information in it becomes stale as time advances. It's up to policy how fresh a proof has to be to count as good enough.

MattRaffel (Thu, 06 Dec 2018 17:05:40 GMT):
@louisk if you can tell me exactly which input field is the problem I can get you the structure. otherwise I can look it up but it will be later this afternoon

xnopre (Thu, 06 Dec 2018 17:10:34 GMT):
@MattRaffel I'm surprised. I'm running samples script under `indy-sdk` project (I'm contributing to the project writting samples scripts in NodeJs ;-) ) (I'm on last version), and I can activate Rust log with `RUST_LOG=indy=trace` environment variable... But @louisk cannot do this... Any idea ?

MattRaffel (Thu, 06 Dec 2018 17:12:30 GMT):
@xnopre what version of the rust compiler are you using?

xnopre (Thu, 06 Dec 2018 17:15:47 GMT):
@MattRaffel Oups, I think I have not rebuild the wrapper and/or the indy lib... I will do it... What do I have to rebuild (wrapper / indy lib) ?

xnopre (Thu, 06 Dec 2018 17:32:22 GMT):
@MattRaffel That's it ! I did not have rebuild my indy lib, so `RUST_LOG=indy=trace` was working for me... Now, I have rebuild my lib and this way (`RUST_LOG=indy=trace`) does not work anymore, I have to use `setLogger` as indicated by you and @louisk, thanks :-)

sklump (Thu, 06 Dec 2018 18:45:30 GMT):
sodium

kdenhartog (Thu, 06 Dec 2018 19:40:11 GMT):
Indy-Crypto now throwing these errors ``` error[E0596]: cannot borrow field `self.bn` of immutable binding as mutable --> /Users/kyle/.cargo/registry/src/github.com-1ecc6299db9ec823/indy-crypto-0.4.3/src/pair/amcl.rs:473:12 | 472 | pub fn to_string(&self) -> Result { | ----- use `&mut self` here to make mutable 473 | Ok(self.bn.to_hex()) | ^^^^^^^ cannot mutably borrow field of immutable binding error[E0596]: cannot borrow field `self.bn` of immutable binding as mutable --> /Users/kyle/.cargo/registry/src/github.com-1ecc6299db9ec823/indy-crypto-0.4.3/src/pair/amcl.rs:516:53 | 515 | fn fmt(&self, f: &mut Formatter) -> Result<(), Error> { | ----- use `&mut self` here to make mutable 516 | write!(f, "GroupOrderElement {{ bn: {} }}", self.bn.to_hex()) | ^^^^^^^ cannot mutably borrow field of immutable binding ```

kdenhartog (Thu, 06 Dec 2018 20:45:49 GMT):
Changing the version in the toml file to `indy-crypto = { version = "=0.5.0-rc-24", optional = true }` fixed this issue

kdenhartog (Thu, 06 Dec 2018 20:47:22 GMT):
for some reason the crates.io versions have some weird dates. For example, `0.4.5` is dated before `0.4.4-dev-71`

kdenhartog (Thu, 06 Dec 2018 20:47:26 GMT):
https://crates.io/crates/indy-crypto/versions

xnopre (Fri, 07 Dec 2018 09:15:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=atFaqdaQHcdozSfr7) I try to repost my question. Is it possible to have more details in `IndyError` we can catch, without activating "trace logger" level ? For example, avec `IndyError: CommonInvalidStructure("missing field requested_predicates at line 1 column 151")` in place of just `IndyError: CommonInvalidStructure` ?

xnopre (Fri, 07 Dec 2018 09:15:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=atFaqdaQHcdozSfr7) I try to repost my question. Is it possible to have more details in `IndyError` we can catch, without activating "trace logger" level ? For example, to have `IndyError: CommonInvalidStructure("missing field requested_predicates at line 1 column 151")` in place of just `IndyError: CommonInvalidStructure` ?

pimotte (Fri, 07 Dec 2018 09:21:25 GMT):
@xnopre I created this issue https://jira.hyperledger.org/projects/IS/issues/IS-1105 for another error that also suffers from a lack of informativeness. If you tag on a minimal example that yields the problem you're talking about I'll try and see if I can improve that message as well

HiranKumar (Fri, 07 Dec 2018 09:54:10 GMT):
Has joined the channel.

HiranKumar (Fri, 07 Dec 2018 09:54:17 GMT):
hi

HiranKumar (Fri, 07 Dec 2018 09:54:32 GMT):
While executing sdk.issuerCreateAndStoreCredentialDef using the schema ["Th7MpTaRZVRYnPiabds81Y:2:userinfor126:1.2",{"ver":"1.0","id":"Th7MpTaRZVRYnPiabds81Y:2:userinfor126:1.2","name":"userinfor126","version":"1.2","attrNames":["name","password","place","username","age"],"seqNo":92}] I got the error CommonInvalidstructiure -113 Would you please help me to solve this issue

xnopre (Fri, 07 Dec 2018 09:55:48 GMT):
[Revocation] I understand that credential can be revoked by issuer, and then verification by verifier fails. cc @sklump @swcurran 1/ "then the proof is only valid at its timestamp" : I'm not sure to understand... In this sample script (https://github.com/hyperledger/indy-sdk/blob/af163f2a5a04374b10cab7fb5171868a50225b41/samples/nodejs/src/anoncredsRevocationScenario.js), the proof can be verified (or not) at different timestamp (now, or the timestamp the proof was provided). So a proof validation depends on the timestamp used in verification, no ? 2/ A search how a user can stop sharing information with issuer, or notifiy it (by the ledger) that he does not want anymore the issuer uses the provided information. How is it possible ? In the video (https://drive.google.com/file/d/1FxdgkYwwLfpln6MnsZJAwnYjM6LpCoP0/view), Daniel talks about "revocation of keys". What is the usage of this revocation ? Can it be used for my need ? Thanks :-)

sklump (Fri, 07 Dec 2018 11:41:10 GMT):
@xnopre the proof request has a non-revocation interval in which any proof timestamp suffices. But the proof has a timestamp. The same proof but on a new timestamp would need a new proof, which only the holder/prover can create. _(This is an oversimplification - in practice each requested attribute or predicate can have its own timestamp in the proof request, but since a proof can refer to only one credential per cred def, in effect there will be a timestamp per cred def in the proof, or no timestamp if the cred def does not support revocation)_

sklump (Fri, 07 Dec 2018 11:41:10 GMT):
@xnopre the proof request has a non-revocation interval in which any proof timestamp suffices. But the proof has a timestamp. The same proof but on a new timestamp would need a new proof, which only the holder/prover can create. _(This is an oversimplification - in practice each requested attribute or predicate can have its own timestamp in the proof request, but since a proof can refer to only one credential per cred def, in effect there will be a timestamp per cred def in the proof -- typically all the same timestamp -- or no timestamp for any cred def not supporting revocation)_

xnopre (Fri, 07 Dec 2018 13:35:46 GMT):
I'm working on `indy-sdk/samples` with NodeJS wrapper. I have merge my sources with the repository. I have rebuild "indylib". Now, I cannot do `npm install`, I have this error : ```npm ERR! prepareGitDep In file included from ../src/indy.cc:425: npm ERR! prepareGitDep ../src/indy_codegen.h:1649:19: error: use of undeclared identifier 'indy_get_response_metadata' npm ERR! prepareGitDep indyCalled(icb, indy_get_response_metadata(icb->handle, arg0, getResponseMetadata_cb)); ``` Any idea to help me ? Thanks

KitHat (Fri, 07 Dec 2018 13:45:18 GMT):
It looks like you have libindy from stable stream and nodejs wrapper from master branch

KitHat (Fri, 07 Dec 2018 13:45:31 GMT):
There are some new symbols introduced in master

xnopre (Fri, 07 Dec 2018 13:58:36 GMT):
@KitHat Thanks for your answer. Yes, I'm working on `indy-sdk` project, collaborating on samples scripts. I'm on master (up to date). What do I have to do ? Rebuild the lib

KitHat (Fri, 07 Dec 2018 13:59:17 GMT):
Yes, rebuild the lib from master, and place it to your library location (e.g. `/usr/lib`)

KitHat (Fri, 07 Dec 2018 13:59:37 GMT):
Or add it to you path any way you want

xnopre (Fri, 07 Dec 2018 15:07:12 GMT):
@KitHat Yes ! It was that ! But I had to clean some directories (`rm -rf include/ && rm -rf node_modules/ && rm -rf build/`) in `indy-sdk/wrappers/nodejs` directory... What do you think about if I try to add a `clean` command in `package.json` in `indy-sdk/wrappers/nodejs` ?

KitHat (Fri, 07 Dec 2018 15:09:59 GMT):
You can create an issue in Indy SDK jira (https://jira.hyperledger.org/browse/IS) and create a PR and we will review it :)

dnnn (Fri, 07 Dec 2018 16:21:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4rWATvambHbnasAGj) Hi all, could you please advise how to set explicit logging in python wrapper? will help a lot!

dnnn (Fri, 07 Dec 2018 16:21:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4rWATvambHbnasAGj) @xnopre Hi all, could you please advise how to set explicit logging in python wrapper? will help a lot!

louisk (Fri, 07 Dec 2018 16:59:08 GMT):
@xnopre can i help contribute anything to your effort? are these sample scripts for the getting started / how to docs?

xnopre (Fri, 07 Dec 2018 17:11:40 GMT):
@louisk Thanks. There are other "sample" script in "python" that can perhaps to be rewritten in NodeJS ? From my side, I'm working on "how-tos" scripts, I'm rewritting `write-did-and-query-verkey` in NodeJs, and then I will do the same for `rotate-key` (and put it in Pull Requests ;-) ) . Anyway, does anyone have an opinion if it is interesting to keep `template + step2, step3, step4 and step5` in separated files ?

louisk (Fri, 07 Dec 2018 17:14:14 GMT):
i can definitely help you with this, i have the code in node.js to do some other how-tos, and all of getting started up until "apply for job"

louisk (Fri, 07 Dec 2018 17:14:37 GMT):
but it is a little more structured than the scripts

xnopre (Fri, 07 Dec 2018 17:16:34 GMT):
I'm rewritting the "how-tos" script as there are in other languages (python, java, ....), without any changes

xnopre (Fri, 07 Dec 2018 17:16:54 GMT):
If you have other samples, perhaps the good place is in "samples" ?

xnopre (Fri, 07 Dec 2018 17:18:44 GMT):
I have also a more full sample, with 3 process (steward, alice, bank), written in NodeJs, and with "real" exchanges between each process (via HTTP), it's more explicit for the process, and the data exchange between each actors, point that is not present in other script, where the data are shared between actors in local variables in the script

kdenhartog (Fri, 07 Dec 2018 17:46:46 GMT):
@xnore

kdenhartog (Fri, 07 Dec 2018 17:46:46 GMT):
@xnore I've don't a bit of editting to the Python ones so that they run correctly. All of them appear to be working, but number 5. You can find them at https://github.com/kdenhartog/indy-dev

kdenhartog (Fri, 07 Dec 2018 17:47:55 GMT):
I'm not sure if that will help you any, but thank you for helping to get these updated.

AxelNennker (Fri, 07 Dec 2018 20:27:41 GMT):
Today I looked at https://github.com/rust-embedded/cross which should make cross-compiling libindy easier. Well, it might but cross builds inside docker containers and mounts the current directory read-only. Problem with libindy is that wrappers/rust are written to which does not work with the read-only system. What is the easiest way to exclude wrappers/rust? They are not needed on neither Android nor iOS, I guess.

AvikHazra (Sat, 08 Dec 2018 09:31:52 GMT):
Hello, Facing a weird problem. Currently I have a server which is under "t2.micro" plan in AWS. It has 1 GB RAM in it and 8 GB Hard-drive. Previously when we were trying to install INDY SDK from https://github.com/hyperledger/indy-sdk/, we were facing an issue about OPENSSL. Then we tried to solve it using these command lines 1. wget https://www.openssl.org/source/openssl-1.1.0j.tar.gz --no-check-certificate 2. tar -xpvzf openssl-1.1.0j.tar.gz 3. cd openssl-1.1.0j 4. ./config 5. make 6. sudo make install 7. openssl version 8. cargo clean 9. Then cargo build from the indy-sdk/libindy directory After this, we didn't see the OPENSSL issue occurring. But during installation after a while the process is getting stuck without an error. Also, when we are trying to log in to the server from a different tab in terminal, it is not letting up log in. The question is, what is causing this halt in between installation process.? Any help will be great. Thank you.

louisk (Sun, 09 Dec 2018 03:50:50 GMT):
@AvikHazra - I'm sure you tried many things already, sometimes for me an EC2 server will run out of RAM, and cause the ssh sessions to hang / the server to become unresponsive. Restarting the server might help, you also might need a bigger server to successfully run indy?

PhillipGibb (Sun, 09 Dec 2018 13:03:33 GMT):
Has anyone been able to build the sovrin connector preview? I can only so far because or openssl issues. The default openssl of ubuntu does not work well with the connector preview android build script, looks that it requires a manual openssl install but then results in incompatible target issues Which is strange because libindy builds fine in the ubuntu vagrant box, but not through the script that the preview uses has anyone been able to work through this?

DJ_HC (Sun, 09 Dec 2018 14:57:47 GMT):
Has joined the channel.

AndrewHughes3000 (Sun, 09 Dec 2018 17:12:57 GMT):
Has joined the channel.

SanjayJain (Sun, 09 Dec 2018 19:12:25 GMT):
Has joined the channel.

SanjayJain (Sun, 09 Dec 2018 19:14:22 GMT):
I have installed connect.me app on Android. What are some simple interesting things I can do with this app to play around, any ideas?

AvikHazra (Mon, 10 Dec 2018 05:45:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JhicDznmC2vPTBx63) @louisk Now, trying with a bigger server, let see what happens

PhillipGibb (Mon, 10 Dec 2018 08:28:39 GMT):
Has anyone been able to build the sovrin connector preview? I am guessing only the developers

JeromeK13 (Mon, 10 Dec 2018 09:10:11 GMT):
Has joined the channel.

xnopre (Mon, 10 Dec 2018 09:19:14 GMT):
@kdenhartog Hi. Sorry but I don't understand... At which questions of mine are you answering ? What do you meen with your depo ? .... Thanks

dbluhm (Mon, 10 Dec 2018 16:51:58 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kdYReq8xqAdnYu4Sn) @PhillipGibb @burdettadam ^^?

mboyd (Mon, 10 Dec 2018 21:06:23 GMT):
@PhillipGibb the connector preview is now officially hosted by the sovrin foundation at https://github.com/sovrin-foundation/connector-app @burdettadam is the closest to building it that I've found

Tairea (Mon, 10 Dec 2018 22:32:33 GMT):
Has joined the channel.

PhillipGibb (Tue, 11 Dec 2018 06:39:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aLpoC9gkyR5zwH8hn) @mboyd I am interested in finding out how this can be built on a mac machine - using the script to push commands to the vagrant box. it does not work - sorry for the dramatic statement, but I have wasted a lot of time tries to figure out the missing parts, especially openssl - the default openssl is not compatible with this build neither is 1.0.1/2 Also the command in the script: pushd /home/vagrant/indy-sdk/libindy/build_scripts/android cannot work because the git repo does not have a build_scripts dir in libindy (or libnullpay for that matter)

sergey.minaev (Tue, 11 Dec 2018 10:43:03 GMT):
@DCSnail @wangdong I see a lot of useful updates about IndySDK iOS wrapper from you. Could you share your experience and status here, may be you will find some intersection. @Artemkaaas FYI

sergey.minaev (Tue, 11 Dec 2018 10:43:03 GMT):
@DCSnail @wangdong I see a lot of useful updates about IndySDK iOS wrapper from you. Thank you a lot. Could you share your experience and status here, may be you will find some intersection. @Artemkaaas FYI

MattRaffel (Tue, 11 Dec 2018 16:51:58 GMT):
@PhillipGibb I build indy-sdk on Mac. Its been a while, so if you are finding problems with the following link, let me know and I will research. I am not building libindy for iOS. I am building it for running on mac only. https://github.com/hyperledger/indy-sdk/blob/master/wrappers/ios/README.md

MattRaffel (Tue, 11 Dec 2018 16:51:58 GMT):
@PhillipGibb I build indy-sdk on Mac. Its been a while but I followed the instructions in the link below. If you are finding problems with the following link, let me know and I will research. I am not building libindy for iOS (those steps didn't exist when I followed the instructions). I am building it for running on mac only--I am able to build and consume libindy and use indy-cli. https://github.com/hyperledger/indy-sdk/blob/master/wrappers/ios/README.md

MattRaffel (Tue, 11 Dec 2018 16:51:58 GMT):
@PhillipGibb I build indy-sdk on Mac. Its been a while but I followed the instructions in the link below. If you are finding problems with the following link, let me know and I will research. I am not building libindy for iOS (those steps didn't exist when I followed the instructions). I am building it for running on mac only--I am able to build and consume libindy and use indy-cli. Note: I run the nodes in docker. I haven't been able to get nodes running outside of a docker image. https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md

PhillipGibb (Tue, 11 Dec 2018 19:17:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JKoi4Fmm5FDZZQwzW) @MattRaffel Hi, thanks Matt, I have built libindy multiple times successfully. My problem is with then connector app - it cannot be build without some secret sauce that has yet to be documented - can you sense my frustration

kdenhartog (Tue, 11 Dec 2018 19:45:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=MA9iqvSkqS46u2qtj) @xnopre Sorry I was replying to this chunk of messages

kdenhartog (Tue, 11 Dec 2018 19:50:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nfFWf3WuSDJuvNRqd) @xnopre I prefer keeping the steps in as it helps to break out the individual functionality and allows for more specific descriptions around what the SDK calls are doing in combination with each other. As far as keeping them in separate files, I don't know that it's absolutely necessary, but I do believe having an interactive instance which allows the developer to track along is useful. What would be even better is to make the interactive version run a similar but different use case. This would be similar to Math problems in text books where there's examples, and then homework assignments with different problems.

kdenhartog (Tue, 11 Dec 2018 20:02:50 GMT):
@MattRaffel He's referring to the open-source version of Connect.me. I think only the Connect.me team knows how to do this still. @PhillipGibb I apologize that you've had a frustrating time getting this working. My guess is you won't be too pleased once you're able to figure out the build. Last I heard it still had a dependency on Evernym Agencies, and uses specific communication that isn't compatible with A2A work yet. The Sovrin team responding @mboyd @burdettadam will be the best ones to stay in sync with on this as they're helping to remove the dependencies, so we have an app that can be built on.

wombletron (Tue, 11 Dec 2018 20:09:18 GMT):
Has joined the channel.

MattRaffel (Tue, 11 Dec 2018 21:12:09 GMT):
Gotcha. There are some internal questions about how build the open source version of Connect.me as well. This is very much work in progress.

adamjbradley (Tue, 11 Dec 2018 21:23:31 GMT):
Morning!

sam-kaw (Tue, 11 Dec 2018 22:06:33 GMT):
Has joined the channel.

SanjayJain (Wed, 12 Dec 2018 00:38:26 GMT):
does anyone know how to read a schema from the indy ledger if I do NOT know the schema version number?

SanjayJain (Wed, 12 Dec 2018 00:38:26 GMT):
does anyone know how to read a schema from indy ledger if I do NOT know the schema version number?

tplooker (Wed, 12 Dec 2018 00:40:14 GMT):
@SanjayJain what do you know about the schema you want to read from the ledger?

SanjayJain (Wed, 12 Dec 2018 00:43:52 GMT):
name and DID (of originator, I believe).

SanjayJain (Wed, 12 Dec 2018 00:43:52 GMT):
@tplooker schema name and DID (of originator, I believe).

kdenhartog (Wed, 12 Dec 2018 02:04:21 GMT):
@SanjayJain AFAIK this is not possible. Support is only based on Schema IDs at this point using the build_get_schema_request() call in the Ledger APIs.

tplooker (Wed, 12 Dec 2018 07:24:50 GMT):
@SanjayJain yeah as @kdenhartog said I'm not aware either of any way to resolve a schema from the ledger with just that information atm.

xnopre (Wed, 12 Dec 2018 08:44:55 GMT):
@kdenhartog I have kept the step3 to step5 in separate files (https://github.com/hyperledger/indy-sdk/pull/1350), copied (inspired) form Python and Java versions, mais in my opinion, I'm not sure it is a useful way... Not sure that a new developper on indy will follow this steps, cpying each to a new file. On the other hand, I think that each main script file (i.e. `rotateKeyOnTheLedger.js` ) could be more commented, with steps and explanation to help the developper/reader to follow and understand each step.... ;-)

pimotte (Wed, 12 Dec 2018 09:27:19 GMT):
Hi all. I reported https://jira.hyperledger.org/projects/IS/issues/IS-1105 regarding unclear errors and I might have some time to work on it, but I would really appreciate some feedback from someone with a better high-level overview of the codebase before venturing into areas that are not useful.

Rantwijk (Wed, 12 Dec 2018 10:04:39 GMT):
@mboyd @esplinr @burdett

Rantwijk (Wed, 12 Dec 2018 10:04:39 GMT):
@mboyd @esplinr @burdettadam I posted this in the Sovrin rocketchat as well but I was pointed here. I'm currently working on a project incorporating Sovrin in order to complete my thesis on SSI. I saw the progression on the connector-app (https://github.com/sovrin-foundation/connector-app) and was hoping to clear up some questions I had about the codebase. -What was missing from the codebase provided by the ConnectMe project? I see many references to ConnectMe in the source code. -Where can I best stay updated on progress efforts made towards compilation? I understand it was written with a proprietary build process in mind and likely requires components such as macstadium. -Is there any similar project (open source app/software with credential management and a UI)? -How can "outside" devs like myself help with the connector-app?

Rantwijk (Wed, 12 Dec 2018 10:06:07 GMT):
I see the discussion above with @PhillipGibb , I'm very interested in progression of this codebase!

DCSnail (Wed, 12 Dec 2018 10:46:55 GMT):
Hi. My project will crashes at startup when i use the libindy-objc-1.6.8 that i add by Cocoapods. And this problem only appear at Xcode10. I tried many methond, but don't work. The Details in pictures blow. Anyone meet it?

DCSnail (Wed, 12 Dec 2018 10:47:51 GMT):
Hi. My project will crashes at startup when i use the libindy-objc-1.6.8 that i added by Cocoapods. And this problem only appear at Xcode10. I tried many methond, but don't work. The Details in pictures blow. Anyone meet it?

DCSnail (Wed, 12 Dec 2018 10:49:03 GMT):

First Error.png

DCSnail (Wed, 12 Dec 2018 10:49:09 GMT):

second.png

DCSnail (Wed, 12 Dec 2018 10:55:00 GMT):
I don't know the cause of the problem. But now i can use libindy-objc by adding framework manually. It can meet my needs. I discussed this question with @sergey.minaev and he gave me so much help. Thank you. I hope that I can help some people. I also hope to learn how to use libIndy-objc-1.6.8 with Cocoapods at Xcode10.

HiranKumar (Wed, 12 Dec 2018 11:53:41 GMT):
I am getting the error Indycode -304 LedgerInvalidTransaction while executing sdk.parseGetSchemaResponse

HiranKumar (Wed, 12 Dec 2018 11:54:29 GMT):
SchemaResponse is like as shown below

HiranKumar (Wed, 12 Dec 2018 11:54:33 GMT):
{ result: { reqId: 1544615303888890000, seqNo: null, type: '107', data: { name: 'userinfo1', version: '0.2' }, identifier: '9zQxxRbTz5hVmsnBCzBUuC', state_proof: { root_hash: 'Fpj61ppZhNnunmZdPnTAFfaYNiuqtJ7fSDoEnoB6J2H7', proof_nodes: '+QGr+JWgO8mlngpweK03LQ03AT2+SdHe+L0AtpGBaEyN3RlYPyK4cvhwuG57ImlkZW50aWZpZXIiOiJWNFNHUlU4Nlo1OGQ2VFY3UEJVZTZmIiwicm9sZSI6IjIiLCJzZXFObyI6MywidHhuVGltZSI6bnVsbCwidmVya2V5IjoiflJIR050ZnZrZ1BFVVF6UU50TnhMTnUiffkBEaDT0j9uCbFabO0LnyutnB5uDC61QaWLtVTJU4XCa4sWo4CAoJqauj70Qf++s0g43b1zvnQEyQJh2lfNqxFRtmaADvkwgKBNOVG34ZQh8gQCgECrCUeFTz5tozWmXPWm8xWXa0G5KqBEAIIJs0un9jVqVEABbCWTkc0rybTVrFgaKU6LD6ciGYCAgICgJHIm3oUOYlDrQlw95UDkRdOc2tGIsE9g2r12AjpJiUKAoH0lXE47VtUlFvwnCC5rgY878m6TpeEZTJIKd4SUxXtqoBvSoTludXD0XkhTPm4YxfCcAdCaiDvkzM8w6O4v5/e1oDs6GXxRL8inD2b3RY1v/ufksDHNqfFKaK2MEIjNIZwagA==', multi_signature: [Object] }, dest: '9zQxxRbTz5hVmsnBCzBUuC', txnTime: null }, op: 'REPLY' }

HiranKumar (Wed, 12 Dec 2018 11:54:47 GMT):
Please help me to solve this

xnopre (Wed, 12 Dec 2018 14:29:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=2727cX5HiLKGhkD63) @louisk @louisk Hi :-) . If you want, to can migrate some other "how-tos" script to NodeJs, you can inspire you with my last contribution : https://github.com/hyperledger/indy-sdk/tree/master/doc/how-tos/rotate-key/nodejs ;-)

xnopre (Wed, 12 Dec 2018 14:43:04 GMT):
I try to rebuild my NodeJs Wrapper. In `indy-sdk/wrappers/nodejs`, I launch `npm run rebuild` but I have this error. Any idea? ```> node codegen && node-gyp rebuild internal/modules/cjs/loader.js:711 throw err; ^ SyntaxError: /Users/xnopre/Documents/workspaces/workspace.twinpeek/indy-sdk/wrappers/nodejs/codegen/api.json: Unexpected token in JSON at position 82391 at JSON.parse () at Object.Module._extensions..json (internal/modules/cjs/loader.js:708:27) ```

xnopre (Wed, 12 Dec 2018 15:54:43 GMT):
I found a way, perhaps... In `api.json` (https://raw.githubusercontent.com/hyperledger/indy-sdk/master/wrappers/nodejs/codegen/api.json#) , line 921, for `indy_get_my_did_with_meta`, there a `TAB` character at the middle of `(after rotation is finished),\n \"metadata\": string` (just after `\n`.

xnopre (Wed, 12 Dec 2018 16:05:09 GMT):
But now, I have this error : ```/Users/xnopre/Documents/workspaces/workspace.twinpeek/indy-sdk/wrappers/nodejs/codegen/apiFunctions.js:72 throw new Error('Expected a command_handle as the first argument: ' + fn.name) ^ Error: Expected a command_handle as the first argument: indy_set_runtime_config at /Users/xnopre/Documents/workspaces/workspace.twinpeek/indy-sdk/wrappers/nodejs/codegen/apiFunctions.js:72:15 at Array.forEach () ```

xnopre (Wed, 12 Dec 2018 16:07:31 GMT):
I don't understand the process, but it seems that `indy_set_runtime_config` does not have a `command_handle` as first parameter, as expected in `apiFunctions.js` line 71....

xnopre (Wed, 12 Dec 2018 16:09:09 GMT):
This `xxx` method seems to have been added by @sergey.minaev in the commit (no ?) : https://github.com/hyperledger/indy-sdk/commit/0272dcf58a1dd22d8b39013c43ca80a30c22badc#diff-31f3901fc91f0f12c204203d11eb271b @sergey.minaev any idea ? Now I'm blocked trying to build my NodeJs Wrapper et I cannot run any of my scripts.... :-(

xnopre (Wed, 12 Dec 2018 16:09:09 GMT):
This `indy_set_runtime_config ` method seems to have been added by @sergey.minaev in the commit (no ?) : https://github.com/hyperledger/indy-sdk/commit/0272dcf58a1dd22d8b39013c43ca80a30c22badc#diff-31f3901fc91f0f12c204203d11eb271b @sergey.minaev any idea ? Now I'm blocked trying to build my NodeJs Wrapper et I cannot run any of my scripts.... :-(

xnopre (Wed, 12 Dec 2018 16:09:09 GMT):
This `indy_set_runtime_config ` method seems to have been added by @sergey.minaev in this commit (or not ?) : https://github.com/hyperledger/indy-sdk/commit/0272dcf58a1dd22d8b39013c43ca80a30c22badc#diff-31f3901fc91f0f12c204203d11eb271b @sergey.minaev any idea ? Now I'm blocked trying to build my NodeJs Wrapper et I cannot run any of my scripts.... :-(

xnopre (Wed, 12 Dec 2018 16:34:40 GMT):
And trying to skip this step, there is another error always for this `indy_set_runtime_config ` function : ```/Users/xnopre/Documents/workspaces/workspace.twinpeek/indy-sdk/wrappers/nodejs/codegen/apiFunctions.js:78 throw new Error('Expected a callback as the as the last argument: ' + fn.name) ``` Seems like there is a problem with this method and its signature not ?

xnopre (Wed, 12 Dec 2018 16:36:23 GMT):
If I remove the section for `indy_set_runtime_config` in the file `codegen/api.json` , I can build my NodeJs wrapper, and run my scripts....

mboyd (Wed, 12 Dec 2018 17:10:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Q43P4dybBmjjtADyn) @Rantwijk Welcome! Happy to have you here. These are the right questions to be asking. - *What is missing?* Lot's of things, most of which we haven't found yet. :) From the work that @PhillipGibb and @burdettadam have done, there are build dependancies that are still missing. We will need to work together to revise the build scripts and help slowly migrate the dependancies from its closed source past. - *Where do I get involved?* Because this is housed within the Sovrin Foundation, I have created a public channel on the Sovrin foundation chat for anyone to stay updated on the progress made on the app. Anyone who is actively working on a mobile application that will use Sovrin can use this channel to collaborate. Link here: https://chat.sovrin.org/channel/connector-app - *Other similar projects?* From what I can tell, the best open source work that includes a fully working credentials exchange ecosystem is that of @swcurran and @jjordan. You can peruse their work here: https://vonx.io (is that right, guys?) - *How can I help?* We would like to take the excellent work that is being done in the #indy-agent group, and begin to incorporate it into an open source mobile edge agent. I'm not entirely sure the best way to approach this, but I think helping to get the Connector App to build is a good first step.

mboyd (Wed, 12 Dec 2018 17:11:59 GMT):
Let me know if you (or anyone else) has more questions. I expect we'll do an introductory call next week some time to see who is working on what with the Connector App.

esplinr (Thu, 13 Dec 2018 00:31:36 GMT):
@Rantwijk * Our team tells me that the build instructions for the Sovrin Connector App work if they are followed exactly. We are working on a script to pull some of the dependencies automatically to make it easier. * The app is almost the same as Evernym's Connect.Me. We removed branding and analytics. * The app currently depends on Evernym's Cloud Agent. Our next project is to release a reference cloud agent to Indy Agent, but that will take a couple more months.

sasiedu (Thu, 13 Dec 2018 08:28:53 GMT):
Hi guys, how do I get access to Hyperledger JIRA

PhillipGibb (Thu, 13 Dec 2018 08:33:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=bHYcppPfb3g2ysCa8) @mboyd Ok, I have managed to build and run the connector app on an emulator on m mac. :woo: What I will do is document the extra steps I did to achieve this.

donqui (Thu, 13 Dec 2018 09:13:23 GMT):
@sasiedu you should be able to log in via your Linux Foundation ID

sasiedu (Thu, 13 Dec 2018 09:43:02 GMT):
@donqui thanks,

kdenhartog (Thu, 13 Dec 2018 11:18:23 GMT):
Thanks @PhillipGibb

mboyd (Thu, 13 Dec 2018 14:35:18 GMT):
@PhillipGibb great to hear! We'd love to see that doc when you have it ready

farskipper (Thu, 13 Dec 2018 14:40:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aujKy6iqL8RxpGWPC) @xnopre I've been making those releases manually, we're in the process of automating those deploys: https://github.com/hyperledger/indy-sdk/pull/715 @Artemkaaas is working on finishing it up

xnopre (Thu, 13 Dec 2018 15:38:14 GMT):
@farskipper Great ! And until it will be working, is it possible to publish last version ?

HiranKumar (Thu, 13 Dec 2018 16:13:23 GMT):
I got CommonInvalidStructre error while executing issuerCreateAndStoreCredentialDef using the schema = { ver: "1.0", id: "Th7MpTaRZVRYnPiabds81Y:2:userinfo4:1.2", name: "userinfo4", version: "1.2", attrNames: ["username", "password", "name"], seqNo: 24 } Is there anyhting wrong

CHempel (Thu, 13 Dec 2018 16:26:10 GMT):
Has joined the channel.

MattRaffel (Thu, 13 Dec 2018 17:07:29 GMT):
@HiranKumar it looks correct. my test uses this ```{"seqNo":1,"id":"id","name":"name","version":"1.1","ver":"1.0","attrNames":["age","height","sex","name"]}```

MattRaffel (Thu, 13 Dec 2018 17:07:29 GMT):
@HiranKumar it looks correct. my test, which passes, uses this structure which is effectively yours. just different data ```{"seqNo":1,"id":"id","name":"name","version":"1.1","ver":"1.0","attrNames":["age","height","sex","name"]}``` if you set RUST_LOG=trace, look for the call to indy_issuer_create_and_store_credential_def and check the output from there. Im expecting a line number which we can look in the rust code to see where its failing your output will look something like this ```10:17:36 Info schemaJson = {"seqNo":1,"id":"id","name":"name","version":"1.1","ver":"1.0","attrNames":["age","height","sex","name"]} 10:17:36 Trace src/api/anoncreds.rs:143 | indy_issuer_create_and_store_credential_def: >>> wallet_handle: 4, issuer_did: 0x70000826c440, schema_json: 0x7ffa36f223b0, tag: 0x70000826c430, signature_type: 0x70000826c420, config_json: 0x70000826c3c0 10:17:36 Trace src/api/anoncreds.rs:153 | indy_issuer_create_and_store_credential_def: entities >>> wallet_handle: 4, issuer_did: "LCkV6KnxTyietVccw9wi1p", schema_json: SchemaV1(SchemaV1 { id: "id", name: "name", version: "1.1", attr_names: {"sex", "height", "name", "age"}, seq_no: Some(1) }), tag: "TAG", signature_type: Some("CL"), config_json: Some(CredentialDefinitionConfig { support_revocation: true }) 10:17:36 Trace src/api/anoncreds.rs:177 | indy_issuer_create_and_store_credential_def: <<< res: Success 10:17:36 Info src/commands/mod.rs:114 | AnoncredsCommand command received 10:17:36 Info src/commands/anoncreds/mod.rs:50 | Issuer command received 10:17:36 Info src/commands/anoncreds/issuer.rs:167 | CreateAndStoreCredentialDefinition command received 10:17:36 Debug src/commands/anoncreds/issuer.rs:248 | create_and_store_credential_definition >>> wallet_handle: 4, issuer_did: "LCkV6KnxTyietVccw9wi1p", schema: SchemaV1 { id: "id", name: "name", version: "1.1", attr_names: {"sex", "height", "name", "age"}, seq_no: Some(1) }, tag: "TAG", type_: Some("CL"), config: Some(CredentialDefinitionConfig { support_revocation: true }) 10:17:36 Trace src/services/crypto/mod.rs:412 | validate_did >>> did: "LCkV6KnxTyietVccw9wi1p" 10:17:36 Trace src/services/crypto/mod.rs:424 | validate_did <<< res: ()```

HiranKumar (Fri, 14 Dec 2018 04:09:14 GMT):
@MattRaffel Thanks for your good information

xnopre (Fri, 14 Dec 2018 08:45:19 GMT):
Hi all. I recall that it seems to me that there is a problem building current version of NodeJs wrapper (see my 6 previous messages starting here https://chat.hyperledger.org/channel/indy-sdk?msg=PB2fNniLeHW7MFkfm). I have identified 2 problems that are blocking the build : 1/ `codegen/api.json` line 921 : there is a TAB character in place of spaces between `(after rotation is finished),\n' and `\"metadata\": string` . I can fix it and do a PR if this file is manually edited (but perhaps it is generated from other data ?) 2/ the `indy_set_runtime_config` block is not compatible with checks done in `apiFunctions.js`: first parameter is expected to be `{"name": "command_handle", "type": "indy_handle_t"}` and last parameter must be a callback function. I don't know what is this function, what is the real problem... I can help but I don't really know how ? .... :-/

sergey.minaev (Fri, 14 Dec 2018 09:20:29 GMT):
@Artemkaaas ^^^

xnopre (Fri, 14 Dec 2018 09:44:38 GMT):
Other point. I have created this demand (https://jira.hyperledger.org/browse/IS-1116) to have more details in errors, I don't know if creating an issuer in Jira is the good way ?

donqui (Fri, 14 Dec 2018 09:47:19 GMT):
@xnopre yes that is the right way to report bugs and propose enhancements.

SergioShevchenko (Fri, 14 Dec 2018 09:59:37 GMT):
Has joined the channel.

xnopre (Fri, 14 Dec 2018 10:04:49 GMT):
@donqui If I have a little information or way to work, I can try to help to improve this point (more details in error) but the stack seems to be a little tricky....

Artemkaaas (Fri, 14 Dec 2018 10:11:18 GMT):
``` 2/ the `indy_set_runtime_config` block is not compatible with checks done in `apiFunctions.js`: first parameter is expected to be `{"name": "command_handle", "type": "indy_handle_t"}` and last parameter must be a callback function. I don't know what is this function, what is the real problem... ``` @xnopre `indy_set_runtime_config` is synchronous function unlike others Lbindy function. It seems like that failed validation was added for asynchronous functions but not synchronous. So, we need skip `forEch` on 69 line for `indy_set_runtime_config` function. @farskipper could you correct me if I wrong?

bdeva (Fri, 14 Dec 2018 16:45:54 GMT):
Hi all, indy-sdk's ZKP keeps failing on me when verifying a proof with negative values for both attribute value and the predicate value, e.g. -1 >= -2 fails when verifying the proof. With positive values there is no issue whatsoever. Also 2 >= -2 works fine. Did anyone experience such an issue?

farskipper (Fri, 14 Dec 2018 20:18:24 GMT):
@xnopre @Artemkaaas I just sent a PR that fixes this and some other minor things https://github.com/hyperledger/indy-sdk/pull/1360

xnopre (Mon, 17 Dec 2018 14:25:14 GMT):
Hi all. In a proof request, it is possible to request an attribute from a credential, using `requested_attributes > attr_referent > restrictions > cred_def_id` . The name of the attributes is specified in `name` field, which is the same as the attribute in the credential (and in the initial schema) (in all examples or tests I have seen). Question : is it possible to have another name for the attribute in the proof than the attribute name in the credential ? For example, with this code : ```'attr4_referent': { 'name': 'status', 'restrictions': [{'cred_def_id': faber_transcript_cred_def_id}] },``` the proof will contain an attribute `name` which must exist in `faber_transcript_cred_def_id`. How can I require this attribute but renaming it in the proof, for example as `faberTranscriptStatus` ?

sergey.minaev (Tue, 18 Dec 2018 09:53:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=pN3MPo3X6s5sSyiPa) @bdeva Could you create a bug in IndySDK JIRA, please? Probably this case doesn't covered by our tests and there is some bug here.

sergey.minaev (Tue, 18 Dec 2018 10:21:10 GMT):
@xnopre attribute name should be same from schema up to proof entity for now.

AvikHazra (Tue, 18 Dec 2018 12:07:18 GMT):
hello, I want to know about credDefId, suppose my credDefId is like *5zekMQNwJfYrJhMyvetN8K:3:CL:406:TAG1*, what are those in credDefId, like 5zekMQNwJfYrJhMyvetN8K is issuer did, tag is String - allows to distinct between credential definitions for the same issuer and schema CL is signatureType. But what are the other parameters. can anyone provide any link ?

xnopre (Tue, 18 Dec 2018 13:27:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5kkhuoSepTzPn2ANH) @sergey.minaev Hi @sergey.minaev . It's a pitty ! ... :-/ ... In a proof, I want to aggregate data from different credentials. If 2 or more credentials have the same name for attribute (i.e. `date` or `status` for example), I have no solution to create a proof request. The only solution now is to set more complex name in schema to avoid the conflict between 2 attributes with the same name. However, there is a `restrictions` block, which could precise the `name` of the attribute in the targeted `cred_def_id`, for example : ```'attr4_referent': { *'name': 'transcriptStatus', // custom name in the proof * 'restrictions': [{ 'cred_def_id': faber_transcript_cred_def_id, *'name': 'status' // name of the targeted attribute in the credential * }] },```

xnopre (Tue, 18 Dec 2018 13:27:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5kkhuoSepTzPn2ANH) @sergey.minaev Hi @sergey.minaev . It's a pitty ! ... :-/ ... In a proof, I want to aggregate data from different credentials. If 2 or more credentials have the same name for attribute (i.e. `date` or `status` for example), I have no solution to create a proof request. The only solution now is to set more complex name in schema to avoid the conflict between 2 attributes with the same name. However, there is a `restrictions` block, which could precise the `name` of the attribute in the targeted `cred_def_id`, for example : ```'attr4_referent': { *'name': 'transcriptStatus', // custom name in the proof * 'restrictions': [{ 'cred_def_id': faber_transcript_cred_def_id, 'name': 'status' // name of the targeted attribute in the credential }] },```

xnopre (Tue, 18 Dec 2018 13:27:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5kkhuoSepTzPn2ANH) @sergey.minaev Hi @sergey.minaev . It's a pitty ! ... :-/ ... In a proof, I want to aggregate data from different credentials. If 2 or more credentials have the same name for attribute (i.e. `date` or `status` for example), I have no solution to create a proof request. The only solution now is to set more complex name in schema to avoid the conflict between 2 attributes with the same name. However, there is a `restrictions` block, which could precise the `name` of the attribute in the targeted `cred_def_id`, for example : ```'attr4_referent': { 'name': 'transcriptStatus', // <-- custom name in the proof 'restrictions': [{ 'cred_def_id': faber_transcript_cred_def_id, 'name': 'status' // <-- name of the targeted attribute in the credential }] },```

dnnn (Tue, 18 Dec 2018 13:33:04 GMT):
Hi all, have anybody tried to use `libindy-objc` via CocoaPod? I am getting "The following binaries use incompatible versions of Swift" for binaries of my sample app and `Indy.framework`. Have tried to build my sample app using swift versions 3, 4, 4.2 (with cleaning app and Derived Data after each build) but still the same exception. If anybody had successfully used this pod, would you be so kind to share tips on how to make it work.

dnnn (Tue, 18 Dec 2018 13:38:16 GMT):
Also I am not an experienced ios dev, but as Indy project becomes somewhat like a hobby to me, maybe I could contribute into ios part. Could you please share some thoughts where I can start? :)

sergey.minaev (Tue, 18 Dec 2018 14:24:56 GMT):
@xnopre Could you describe in more details, why restrictions doesn't solve the conflict? Have you considered something like ``` attr1_ref : { name: status, restrictions: { schema: schema_id } }, attr2_ref : { name: status, restrictions: { schema: another_schema_id } }, ``` Is it enough for your use case? Most probably there is no such tests in indy sdk in general, but my expectation - technically it should work. As result create_proof will return complex proof with 2 parts and in requested_proof appropriate mapping will be available.

sergey.minaev (Tue, 18 Dec 2018 14:26:39 GMT):
Also you may construct attr_ref as something like SchemaNameAttrName

sergey.minaev (Tue, 18 Dec 2018 14:26:39 GMT):
Also you may construct `attr_ref`s as something like SchemaNameAttrName

Infitude (Wed, 19 Dec 2018 01:29:10 GMT):
Has joined the channel.

tomislav (Wed, 19 Dec 2018 03:27:27 GMT):
@dnnn I always had trouble using the pod, seems to be built with outdated version. It doesn't take a lot of effort to build your own framework following the iOS build steps.

dnnn (Wed, 19 Dec 2018 14:11:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mafsCfNubSfmhmLyA) @tomislav Tomislav, thanks you very much for you answer. Would love to give it a try. But I cannot locate script `build-libindy-core-ios.sh` (which is a part of building process) in repository. Is it located somewhere else?

dnnn (Wed, 19 Dec 2018 14:18:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=XbEZDn6JgWGrJWMi9) have found another script `ios-build.sh` in `ci/` directory. will try to use it instead.

dnnn (Wed, 19 Dec 2018 14:18:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=XbEZDn6JgWGrJWMi9) have found another script 'ios-build.sh

josh.hill (Wed, 19 Dec 2018 20:29:47 GMT):
Has joined the channel.

dnnn (Wed, 19 Dec 2018 20:44:20 GMT):
@solocez @wangdong Hi! Thanks for your discussion earlier in this chat. Helped me a lot to build `libindy.a`. But when I try to use it to build `Indy.framework` I am facing the issue with `libzmq`: `'platform.hpp' file not found`. Have you seen something like this? Or maybe you have some suggestions how it can be resolved?

tomislav (Wed, 19 Dec 2018 20:58:29 GMT):
Did you do pod update?

wangdong (Thu, 20 Dec 2018 04:24:54 GMT):
@dnnn did you follow the steps? I did not get this error. ios-build.sh is the right script to build libindy.a

dnnn (Thu, 20 Dec 2018 09:02:10 GMT):
mc

dnnn (Thu, 20 Dec 2018 09:30:42 GMT):
@tomislav yes, I did. @wangdong yes, I followed the steps from `Jenkinsfile.ci`. what I cannot do from those steps is to install version `4.2.3` of `zeromq`. there is only version `4.2.5` available via brew. But unfortunately I have no clue if it can affect `Indy.framework` build. Do you think it can?

wangdong (Thu, 20 Dec 2018 14:33:26 GMT):
you have to follow the iOS wrapper readme first to install all the dependencies. @dnnn

wangdong (Thu, 20 Dec 2018 14:33:51 GMT):
I think zeromq 4.2.5 is fine.

xnopre (Thu, 20 Dec 2018 15:43:52 GMT):
@sergey.minaev Hi. Yes, you're right. I have just tried with 2 schemas containing both a `name` attribute. I have generated a proof that is looking like this : ``` "revealed_attrs": { "attr1_referent": { "sub_proof_index": 1, "raw": "Alex", "encoded": "1139481716457488690172217916278103335" }, "attr2_referent": { "sub_proof_index": 0, "raw": "Bob", "encoded": "1139481716457488690172217916278103335" } }, ...``` I have two `name` values in the proof, and effectively, I can differentiate each of them, depending on `attr1_referent` or `attr2_referent` path. But my need (or idea) was to be able to specify a custom name in the proof for each attribute that could be different than the attribute name in the credential.

HiranKumar (Fri, 21 Dec 2018 07:08:32 GMT):
How can we find the credential offer from ledger using sdk?

HiranKumar (Fri, 21 Dec 2018 07:08:32 GMT):
ProofRequest is as shown below

HiranKumar (Fri, 21 Dec 2018 07:08:36 GMT):
any method?

mgbailey (Fri, 21 Dec 2018 16:49:26 GMT):
Credential offers are agent to agent, without ledger involvement. No record of it is on the ledger.

esplinr (Fri, 21 Dec 2018 22:24:17 GMT):
@HiranKumar The SDK contains a library "libvcx" that can help with processing credential offers.

aappddeevv (Thu, 27 Dec 2018 21:28:11 GMT):
Has joined the channel.

ashokkj (Fri, 28 Dec 2018 09:23:44 GMT):
Has joined the channel.

ashokkj (Fri, 28 Dec 2018 09:27:50 GMT):
Hi, I want to know when NYM transaction is registered, what are its content, I mean what are the parameters that are stored at the Ledger?

calvingerling (Fri, 28 Dec 2018 15:48:41 GMT):
Has joined the channel.

swcurran (Fri, 28 Dec 2018 18:32:32 GMT):
If you just want to see an example, BC Gov runs a Ledger that we use for testing and have a ledger browser. You can look at the transaction of the Ledger here - http://159.89.115.24/browse/domain and filter on each transaction type. You can also see the node status at: http://159.89.115.24. This is not the Sovrin network, but the transaction information is the same.

swcurran (Fri, 28 Dec 2018 18:32:32 GMT):
If you just want to see an example, BC Gov runs an Indy Ledger that we use for testing and have a ledger browser. You can look at the transaction of the Ledger here - http://159.89.115.24/browse/domain and filter on each transaction type. You can also see the node status at: http://159.89.115.24. This is not the Sovrin network, but the transaction information is the same.

swcurran (Fri, 28 Dec 2018 18:32:32 GMT):
If you just want to see an example, BC Gov runs an Indy Ledger that we use for testing and have a ledger browser. You can look at the transactions of the Ledger here - http://159.89.115.24/browse/domain and filter on each transaction type. You can also see the node status at: http://159.89.115.24. This is not the Sovrin network, but the transaction information is the same.

HiranKumar (Tue, 01 Jan 2019 06:47:37 GMT):
While executing proverCreateProof I got a CommonInvalidStructure error

HiranKumar (Tue, 01 Jan 2019 06:49:15 GMT):
ProofRequest is as shown below { name: 'General-Identity', version: '0.2', requested_attributes: { attr1_referent: { name: 'name' }, attr2_referent: { name: 'username' }, attr3_referent: { name: 'password' } }, requested_predicates: {}, nonce: '11412170453676996595091990710115' }

HiranKumar (Tue, 01 Jan 2019 06:49:52 GMT):
Requested Credentials like

HiranKumar (Tue, 01 Jan 2019 06:49:54 GMT):
{ requested_attributes: { attr1_referent: { cred_id: 'f63f7df4-8694-434a-8b56-3010a9f26856', revealed: true }, attr2_referent: { cred_id: 'f63f7df4-8694-434a-8b56-3010a9f26856', revealed: true }, attr3_referent: { cred_id: 'f63f7df4-8694-434a-8b56-3010a9f26856', revealed: true } } }

HiranKumar (Tue, 01 Jan 2019 06:50:18 GMT):
schema is

HiranKumar (Tue, 01 Jan 2019 06:50:19 GMT):
{ 'Th7MpTaRZVRYnPiabds81Y:2:userinfo12:1.2': { ver: '1.0', id: 'Th7MpTaRZVRYnPiabds81Y:2:userinfo12:1.2', name: 'userinfo12', version: '1.2', attrNames: [ 'password', 'name', 'username' ], seqNo: 186 } }

HiranKumar (Tue, 01 Jan 2019 06:50:29 GMT):
schema credentials like

HiranKumar (Tue, 01 Jan 2019 06:50:47 GMT):
{ 'Th7MpTaRZVRYnPiabds81Y:3:CL:186:IDRAMP': { ver: '1.0', id: 'Th7MpTaRZVRYnPiabds81Y:3:CL:186:IDRAMP', schemaId: '186', type: 'CL', tag: 'IDRAMP', value: { primary: [Object] } } }

HiranKumar (Tue, 01 Jan 2019 06:51:08 GMT):
revocStates like {}

HiranKumar (Tue, 01 Jan 2019 06:51:38 GMT):
masterSecretId is 786e0855-6210-4b17-8e34-551b45324c59

HiranKumar (Tue, 01 Jan 2019 06:51:52 GMT):
await sdk.proverCreateProof(this.objIndy.wallet.wallet, proofRequest, requestedCreds.requested_attributes, masterSecretId, schemas,credDefs, revocStates).then(data=> { proof = data; }).catch(ex=>{ logger.debug(ex); });

HiranKumar (Tue, 01 Jan 2019 06:52:08 GMT):
I got the commoninvalid structure error

HiranKumar (Tue, 01 Jan 2019 06:52:31 GMT):
Would you please suggest,which one have a wrong json structure

ashokkj (Wed, 02 Jan 2019 02:33:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ZaDASPoy4rLAAN7vn) @swcurran Thank you @swcurran for the pointers.

GEEKTEDDY (Wed, 02 Jan 2019 03:07:40 GMT):
Hi, Is there any api to update the credentials in prover's wallet? For example, the issuer adds some attributes in credential schema or credential definition, and he/she wants to update this change to prover's credential which has already sent to prover and stored in prover's wallet.

sklump (Wed, 02 Jan 2019 11:53:58 GMT):
The origin cannot change a schema. The issuer cannot change a credential definition. A delta must take a new version number at least, and entails a new entry on the ledger. The issuer can issue new credentials against the new cred def.

smithbk (Wed, 02 Jan 2019 19:38:27 GMT):
I'm getting a timeout when trying to do a ledger sendnym. Any ideas what I may be doing wrong? Here are the logs ```TRACE|indy::services::pool::networker| src/services/pool/networker.rs:319 | _send_msg_to_one_node >> idx 3, req_id 1546455875168661173, req {"identifier":"Th7MpTaRZVRYnPiabds81Y","operation":{"dest":"AnnPwUnczgYV2ywETgqC32","role":"101","type":"1","verkey":"6LTjLHHTCBYamGhHjSVSC7uKewWuDDdouif2SrRB8yeD"},"protocolVersion":2,"reqId":1546455875168661173,"signature":"61SaUVS1PpXiYqYZ8Z1uiWv7BvJGTY4dihUaD4sCWzHT1kSGdQTwnkMfHBqTNfmr7bgKPDjh2eYXF4cGEjYBpAZd"} DEBUG|indy::services::pool::networker| src/services/pool/networker.rs:331 | _get_socket: open new socket for node 3 TRACE|indy::services::pool::networker| src/services/pool/networker.rs:325 | _send_msg_to_one_node << TRACE|indy::services::pool::networker| src/services/pool/networker.rs:285 | send_request << TRACE|indy::services::pool::pool | src/services/pool/pool.rs:537 | received pool event: Some(NodeReply("{\"reqId\":1546455875168661173,\"identifier\":\"Th7MpTaRZVRYnPiabds81Y\",\"op\":\"REQACK\"}", "Node3")) TRACE|indy::services::pool::pool | src/services/pool/pool.rs:384 | received reply from node "Node3": "{\"reqId\":1546455875168661173,\"identifier\":\"Th7MpTaRZVRYnPiabds81Y\",\"op\":\"REQACK\"}" TRACE|indy::services::pool::pool | src/services/pool/pool.rs:537 | received pool event: Some(NodeReply("{\"op\":\"REQACK\",\"reqId\":1546455875168661173,\"identifier\":\"Th7MpTaRZVRYnPiabds81Y\"}", "Node1")) TRACE|indy::services::pool::pool | src/services/pool/pool.rs:384 | received reply from node "Node1": "{\"op\":\"REQACK\",\"reqId\":1546455875168661173,\"identifier\":\"Th7MpTaRZVRYnPiabds81Y\"}" TRACE|indy::services::pool::pool | src/services/pool/pool.rs:537 | received pool event: Some(NodeReply("{\"reqId\":1546455875168661173,\"identifier\":\"Th7MpTaRZVRYnPiabds81Y\",\"op\":\"REQACK\"}", "Node4")) TRACE|indy::services::pool::pool | src/services/pool/pool.rs:384 | received reply from node "Node4": "{\"reqId\":1546455875168661173,\"identifier\":\"Th7MpTaRZVRYnPiabds81Y\",\"op\":\"REQACK\"}" TRACE|indy::services::pool::pool | src/services/pool/pool.rs:537 | received pool event: Some(NodeReply("{\"identifier\":\"Th7MpTaRZVRYnPiabds81Y\",\"reqId\":1546455875168661173,\"op\":\"REQACK\"}", "Node2")) TRACE|indy::services::pool::pool | src/services/pool/pool.rs:384 | received reply from node "Node2": "{\"identifier\":\"Th7MpTaRZVRYnPiabds81Y\",\"reqId\":1546455875168661173,\"op\":\"REQACK\"}" TRACE|indy::services::pool::pool | src/services/pool/pool.rs:537 | received pool event: Some(Timeout("1546455875168661173", "Node3")) TRACE|indy::services::pool::networker| src/services/pool/networker.rs:248 | is_active >> time worked: Duration { secs: 60, nanos: 102126791 } TRACE|indy::services::pool::networker| src/services/pool/networker.rs:250 | is_active << false TRACE|indy::services::pool::pool | src/services/pool/pool.rs:537 | received pool event: Some(Timeout("1546455875168661173", "Node1")) TRACE|indy::services::pool::networker| src/services/pool/networker.rs:248 | is_active >> time worked: Duration { secs: 60, nanos: 102348840 } TRACE|indy::services::pool::networker| src/services/pool/networker.rs:250 | is_active << false TRACE|indy::services::pool::pool | src/services/pool/pool.rs:537 | received pool event: Some(Timeout("1546455875168661173", "Node4")) TRACE|indy::services::pool::networker| src/services/pool/networker.rs:248 | is_active >> time worked: Duration { secs: 60, nanos: 102513005 } TRACE|indy::services::pool::networker| src/services/pool/networker.rs:250 | is_active << false TRACE|indy::services::pool::networker| src/services/pool/networker.rs:127 | removing pool connection 10 INFO|indy::commands | src/commands/mod.rs:111 | LedgerCommand command received ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Timeout TRACE|indy::api::ledger | src/api/ledger.rs:67 | indy_sign_and_submit_request: request_result_json: ""```

kdenhartog (Wed, 02 Jan 2019 21:01:33 GMT):
@smithbk likely an issue with the sdk not communicating with your pool properly. Are you able to submit any other transactions to the ledger or is it only a problem with nym transactions?

smithbk (Wed, 02 Jan 2019 21:07:08 GMT):
It is early after the pool is created but it seems that there is some successful communication, though I'm not positive I'm interpreting the trace appropriately. For example, I see this earlier in logs. ```TRACE|indy::services::pool::pool | src/services/pool/pool.rs:537 | received pool event: Some(NodeReply("{\"protocolVersion\":2,\"viewNo\":null,\"txnSeqNo\":4,\"ppSeqNo\":null,\"merkleRoot\":\"6wYd9eopVmE9xmR1ZFi4mp5yhhwRhtFiEzj8cFwFR5K8\",\"ledgerId\":0,\"op\":\"LEDGER_STATUS\"}", "Node4")) ```

smithbk (Wed, 02 Jan 2019 21:08:02 GMT):
@kdenhartog Doesn't this indicate that it is communicating with the ledger successfully?

kdenhartog (Wed, 02 Jan 2019 22:55:29 GMT):
yeah that does appear to be setting up the pool properly from what I can tell in the code and where the log is spit out at. From that log you're posting it appears that it's getting a response from all 4 nodes and then the networker.rs portion is failing. If I get some time to dig into it tonight I'll post back here. Otherwise @sergey.minaev @Artemkaaas or @gudkov would be the best ones to help tonight.

GEEKTEDDY (Thu, 03 Jan 2019 03:29:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3TsRfBHhwAusJ8Pic) @sklump Thanks, If an issuer create a new cred def which is based on the old one and add some new attributes(it can be treated as the new version of old cred def), so the old cred def is useless now, then how to deal with the credential against the old cred def on the prover's wallet? revoke all the old credentials and issuer new one based on the new cred def? is there any api to update credentials?

sklump (Thu, 03 Jan 2019 12:02:39 GMT):
The old cred is not necessarily useless. There could be multiple contemporaneous versions. The issuer may revoke old credentials to replace them if need be. There is no API to modify credentials: cryptographic protections etch their content in stone at issue.

xnopre (Thu, 03 Jan 2019 14:21:07 GMT):
Hi all. With last version 1.7.0, I have this error : `issuerCreateCredential expects Number for blobStorageReaderHandle` . It seems that there has been some changes, and now, `blobStorageReaderHandle` parameter is mandatory calling `issuerCreateCredential` ? Can someone confirm ? And perhaps give me some explications ? Thanks

sklump (Thu, 03 Jan 2019 14:31:01 GMT):
@xnopre, the tails file reader handle has been there for a while. It's optional in that credential definitions need not support revocation. If the cred def supports revocation, this parameter is mandatory. Coroutine `async def blob_storage.open_reader()` returns the reader handle to use here.

xnopre (Thu, 03 Jan 2019 17:40:21 GMT):
@sklump Thank you for your answer. I know this parameter ;-) . For example, I have written and share this script : https://github.com/hyperledger/indy-sdk/blob/master/samples/nodejs/src/anoncredsRevocationScenario.js . But we have a POC that was running on Indy 1.6.7, without revocation and `blobStorageReaderHandle` was `undefined` calling `issuerCreateCredential`: no problem. But today, upgrading to 1.7.0, we had the mentioned error. I have fixed the problem only getting a `blobStorageReaderHandle` calling `openBlobStorageReader` , and using it calling `issuerCreateCredential`, no other changes in our code.... That's why I'm surprised... It seem like there has been some changes in the SDK and/or in the NodeJS Wrapper... @farskipper ? @sergey.minaev ? @Artemkaaas ? ;-)

sklump (Thu, 03 Jan 2019 18:06:51 GMT):
My bet is that the change is in the wrapper - my unit tests run fine on 1.7.0-dev-916 and they include credentials on credential definitions that do not support revocation.

sklump (Thu, 03 Jan 2019 18:06:51 GMT):
My bet is that the change is in the wrapper - my unit tests run fine on (the python wrapper for) 1.7.0-dev-916 and they include credentials on credential definitions that do not support revocation.

smithbk (Thu, 03 Jan 2019 18:20:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=CtQYmYvd2XWB3HNM8) @kdenhartog @kdenhartog @sergey.minaev @Artemkaaas @gudhov Any help on this is appreciated. I'm still blocked on this and not sure what has changed to cause this.

SaraInadam (Fri, 04 Jan 2019 11:34:27 GMT):
Has joined the channel.

HiranKumar (Fri, 04 Jan 2019 12:21:49 GMT):
I can able to connect the network using indy-cli (1.7.0).But using sdk(nodejs) could not able to open the pool using same genesis file,I got a PoolLedgerTimeout error.Please help me to resolve it

HiranKumar (Fri, 04 Jan 2019 14:22:20 GMT):
OpenPoolLedger of sdk returned PoolLedgerTimeOut error.What might be the reason?

xnopre (Fri, 04 Jan 2019 14:31:29 GMT):
Can an issuer #2 generate a credential, based on a `cred_def_id` created by another issuer #1 ? Trying this, I have a problem, I think the `cred_def_id` must be in the wallet of issuer #2... Can someone confirm ? If true, is it possible to put the `cred_def_id` (get from issuer #1) in the wallet of issuer #2 ? Thanks

sklump (Fri, 04 Jan 2019 14:43:22 GMT):
By definition the cred def issuer is the cred issuer. The issuer may differ from the schema origin.

mgbailey (Fri, 04 Jan 2019 15:03:42 GMT):
@xnopre The cred def contains public/private keys, and so must exist in the wallet of an issuer. It is possible to have an entity other than the issuer write the public part of the cred def to the ledger, which had been transmitted from the issuer to the entity posting it to the ledger. I have helped a customer to do this to provide a means of issuer delegation until a more complete solution is developed.

HiraSiddiqui (Fri, 04 Jan 2019 15:29:14 GMT):
Has joined the channel.

HiraSiddiqui (Fri, 04 Jan 2019 15:31:17 GMT):
Hi, I am very new to indy and trying to register a trust anchor on the sovrin test network link here: https://s3.us-east-2.amazonaws.com/evernym-cs/sovrin-STNnetwork/www/trust-anchor.html I have created my DID and verkey through indy CLI, when I try to register it through this dashboard, it returns me 502 internal server error. Can someone please guide me what is it I'm missing? Thanks

MujtabaIdrees (Fri, 04 Jan 2019 15:47:57 GMT):
Has joined the channel.

mgbailey (Fri, 04 Jan 2019 15:52:57 GMT):
@HiraSiddiqui The anchor registration web page is broken. Just send your did and verkey to me and I will post them to the ledger.

DuckLover (Sun, 06 Jan 2019 22:53:03 GMT):
Hello, i was setting up Indy-SDK for NodeJS locally with VS Code as an IDE but got a few problems. Can someone help me out?

DuckLover (Sun, 06 Jan 2019 22:53:46 GMT):
After "npm install" seems like "/usr/bin/ld: cannot find -lindy" causes that it fails to do so

DuckLover (Sun, 06 Jan 2019 22:53:46 GMT):
After "npm install" to install the dependencies. It seems like "/usr/bin/ld: cannot find -lindy" is the reason that it dont work

xnopre (Mon, 07 Jan 2019 09:22:13 GMT):
@DuckLover Which OS ? Which version of Indy-sdk ? Is it your own project or a public project (like "sample" or "how-tos" in "indy-sdk" project) ?

DuckLover (Mon, 07 Jan 2019 10:57:09 GMT):
@xnopre I cloned from this source https://github.com/hyperledger/indy-agent and using VS Code on Ubuntu 18.04.1 LTS.

bdeva (Mon, 07 Jan 2019 14:05:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=CQtqwoKQthDtz2LA4) @sergey.minaev https://jira.hyperledger.org/browse/IS-1130

DuckLover (Mon, 07 Jan 2019 18:06:57 GMT):
Is this instruction for setup party deprecated? (https://github.com/hyperledger/indy-sdk). As mentioned above im struggling a little bit with setting up indy-sdk. This part for example "sudo add-apt-repository "deb https://repo.sovrin.org/sdk/deb xenial {release channel}" " just dont seems to work for me (only me?) :thinking:

MattRaffel (Mon, 07 Jan 2019 18:21:45 GMT):
@DuckLover what OS are you using?

DuckLover (Mon, 07 Jan 2019 18:23:22 GMT):
ubuntu 18.04 lts

sklump (Mon, 07 Jan 2019 18:51:16 GMT):
16.04 is supported

sklump (Mon, 07 Jan 2019 18:51:30 GMT):
If 18 is now, that's news to me and it would be lovely

DuckLover (Mon, 07 Jan 2019 19:14:40 GMT):
damn. Didnt thought about the obvious reason. Would a VirtualBox with 16.04 do it?

sklump (Mon, 07 Jan 2019 19:29:07 GMT):
It's all I use

HiranKumar (Tue, 08 Jan 2019 10:29:26 GMT):
Hi

HiranKumar (Tue, 08 Jan 2019 10:33:51 GMT):
while executing sdk.proverCreateProof,I got a ComonInvalidStructure error, proverCreateProof ( wh, proofReq, requestedCredentials, masterSecretName, schemas, credentialDefs, revStates ) -> proof wh 6 proofReq { name: 'General-Identity', version: '0.2', requested_attributes: { attr1_referent: { name: 'name' }, attr2_referent: { name: 'username' }, attr3_referent: { name: 'password' } }, requested_predicates: {}, nonce: '79069089185839494242704518282647' } requestedCredentials { self_attested_attributes: {}, requested_attributes: { attr1_referent: { cred_id: '068098c9-36b2-4bb5-9d48-85101d8b9767', revealed: true }, attr2_referent: { cred_id: '068098c9-36b2-4bb5-9d48-85101d8b9767', revealed: true }, attr3_referent: { cred_id: '068098c9-36b2-4bb5-9d48-85101d8b9767', revealed: true } }, requested_predicates: {} } masterSecretName df840341-d8b7-4511-bb60-11ab46bc86c9 schemas [ 'Th7MpTaRZVRYnPiabds81Y:2:userinfo:1.2', { ver: '1.0', id: 'Th7MpTaRZVRYnPiabds81Y:2:userinfo:1.2', name: 'userinfo', version: '1.2', attrNames: [ 'name', 'password', 'username' ], seqNo: 13 } ] credentialDefs [ 'Th7MpTaRZVRYnPiabds81Y:3:CL:13:IDRAMP', { ver: '1.0', id: 'Th7MpTaRZVRYnPiabds81Y:3:CL:13:IDRAMP', schemaId: '13', type: 'CL', tag: 'IDRAMP', value: { primary: [Object] } } ] revStates {} Please help me to solve this issue

xnopre (Tue, 08 Jan 2019 11:58:25 GMT):
@HiranKumar Which language (wrapper) ? Try to set a logger to have more details, like that in NodeJs : ```indy.setLogger(function (level, target, message, modulePath, file, line) { console.log('libindy said:', level, target, message, modulePath, file, line) }) ```

sklump (Tue, 08 Jan 2019 12:54:15 GMT):
*Rust experts:* is there a `RUST_LOG=` environment variable value I can set to shut off rust logs? Alternatively, a level tighter than `ERROR` would suffice, such as `FATAL` or `CRITICAL`. Thanks a million. I am amazed I can't find this in the usual hunting grounds.

sklump (Tue, 08 Jan 2019 12:54:15 GMT):
*Rust experts:* is there a `RUST_LOG=` environment variable value I can set to shut off rust logs? Alternatively, a level higher than `ERROR` would suffice, such as `FATAL` or `CRITICAL`. Thanks a million. I am amazed I can't find this in the usual hunting grounds.

HiranKumar (Tue, 08 Jan 2019 14:25:31 GMT):
@xnopre ,I am working in nodejs wrapper.

xnopre (Tue, 08 Jan 2019 15:34:16 GMT):
@HiranKumar OK, so you can set a logger as mentionned previously, and just before the `ComonInvalidStructure` , you should find 1 or 2 lines with more details for the problem

MattRaffel (Tue, 08 Jan 2019 18:16:21 GMT):
@sklump you could skip logger initialization, then you wouldnt get log output. You can alos configure the environment variable to log per module/app. I haven't used this myself so I am unsure if indy-sdk works with that. see https://docs.rs/env_logger/0.6.0/env_logger/

Im5tu (Tue, 08 Jan 2019 22:00:00 GMT):
Has joined the channel.

Im5tu (Tue, 08 Jan 2019 22:00:25 GMT):
Hey, i don't suppose anyone has libindy building on alpine?

PatrikStas (Wed, 09 Jan 2019 11:02:34 GMT):
@Im5tu do you mean docker image with libindy based on alpine? Actually about to try build it within this week. I would like to get Minimal image with libindy and node.

PatrikStas (Wed, 09 Jan 2019 11:02:34 GMT):
@Im5tu do you mean docker image with libindy based on alpine? Actually about to try build it within this week. I would like to get minimal image with libindy and node.

HiranKumar (Wed, 09 Jan 2019 12:20:56 GMT):
issuerCreateCredential expects numer for openBlobStorageReader.I got an error like this while executing issuerCreateCredential .

HiranKumar (Wed, 09 Jan 2019 12:21:12 GMT):
How can I solve it

JeromeK13 (Wed, 09 Jan 2019 12:36:25 GMT):
Hey Guys I have some problems to get a connection to the "getting_started" pool. (Timeout) I running it on an amazonaws machine -> Does the node_ip have to be "X.X.X.X" or can it also be "... .compute.amazonaws.com" ? Greets Jerome

JeromeK13 (Wed, 09 Jan 2019 12:38:34 GMT):

Clipboard - January 9, 2019 1:38 PM

AxelNennker (Wed, 09 Jan 2019 12:41:51 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=GZtELaQzYvisCckBD) @HiranKumar Maybe a look here helps: https://github.com/hyperledger/indy-sdk/blob/master/libindy/tests/demo.rs#L274

AxelNennker (Wed, 09 Jan 2019 12:55:52 GMT):
Somebody @ianco defined IndyHandle `pub type IndyHandle = i32;` https://github.com/hyperledger/indy-sdk/commit/80fe5fe626d6714f077af119e67d02a160649233#diff-3c16e24de8cf241da02ed726237a1046R9 That is a good step forward to type safety for handles. I would add more type definitions for WalletHandle, PoolHandle and CommandHandle and later introduce type-safety using Rust's newtype pattern https://rust-lang-nursery.github.io/api-guidelines/type-safety.html#c-newtype This would then prevent usage of e.g. a WalletHandle when a PoolHandle is needed. Doing this is quite straight forward with the exception that the test do a walletHandle+1 to generate a invalid handle

HiraSiddiqui (Wed, 09 Jan 2019 12:56:01 GMT):
I am trying to setup an indy pool using the official docker-compose file. Can somebody tell me why is jupyter notebook being used in it and what's it used for?

HiraSiddiqui (Wed, 09 Jan 2019 12:56:17 GMT):
and would it be okay if I don't use it?

sergey.minaev (Wed, 09 Jan 2019 13:19:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=swxvpRwh256s8wfLS) @smithbk If I understand attached logs correctly you have received ACKs from all nodes but no one REPLY. It may be issue on Indy Node side or just some slowness. I suggest to increase timeouts (please see API comments for pool open call) and try again. If large timeout will not help - please re-post into #indy-node channel and mention the problem symptom (acks received, replies - no). In this case the next step will be collecting logs from nodes...

ardagumusalan (Wed, 09 Jan 2019 13:35:01 GMT):
Hi everyone. Are there any plans regarding a tails management mechanism for revocation?

sklump (Wed, 09 Jan 2019 13:38:26 GMT):
@ardagumusalan consider tracking of https://github.com/PSPC-SPAC-buyandsell/von_tails

sklump (Wed, 09 Jan 2019 13:38:26 GMT):
@ardagumusalan consider tracking https://github.com/PSPC-SPAC-buyandsell/von_tails It's still under development but should come together in a semi-robust state by early next week at the latest.

sklump (Wed, 09 Jan 2019 13:38:26 GMT):
@ardagumusalan consider tracking https://github.com/PSPC-SPAC-buyandsell/von_tails It's still under development but should come together (again, on von_anchor 1.7.x) in a semi-robust state by early next week at the latest.

ardagumusalan (Wed, 09 Jan 2019 13:50:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nZadpCgcF2SeMjYTA) @sklump Thanks. Can you elaborate more on why you consider it to be semi-robust?

swcurran (Wed, 09 Jan 2019 13:51:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=LMJDAA7JEqgWTunon) @PatrikStas We (BC Gov) have been using nicely optimized images for awhile with von-image: https://hub.docker.com/r/bcgovimages/von-image/ - github repo: https://github.com/PSPC-SPAC-buyandsell/von-image It creates a pretty small image with indy-sdk and indy-node, python and the VON components we need. A lot of time was spent in making this pretty efficient, so it might be a good place to start.

swcurran (Wed, 09 Jan 2019 13:52:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=oGqePkEmS5hkLLawT) @ardagumusalan The quick answer is that Mr. Klump has pretty high standards :-).

sklump (Wed, 09 Jan 2019 14:00:06 GMT):
@ardagumusalan it currently uses von_anchor 1.6 series and is not more than a file server with a RESTful API. I am plumbing in some tails file vetting via indy-sdk. That means that server and issuers and admin client have to be von_anchors under the covers, which brings in the indy pool, which brings in docker-compose networking; also, anchors need to be on the ledger ... it got a complicated.

AxelNennker (Wed, 09 Jan 2019 16:59:28 GMT):
I created an Jira issue https://jira.hyperledger.org/browse/IS-1134 regarding replacing i32 by e.g. WalletHandle for type-safety

DuckLover (Wed, 09 Jan 2019 18:04:55 GMT):
Anybody got an advice how to debug the code (https://github.com/swcurran/education/tree/master/LFS171x/indy-material/nodejs) especially the communication between the different docker container aka Alice, Bob, ...?

kdenhartog (Wed, 09 Jan 2019 22:40:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qgdkkmaiuhWsFQQ2S) @sergey.minaev I was able to help him a bit, but we weren't able to resolve the problem. He was going to try checking logs on the Node side, because it looked to be a problem cause by that. @smithbk were you able to find a solution to this?

kdenhartog (Wed, 09 Jan 2019 22:42:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=8t4mqbe7vefbXJFCH) @AxelNennker Thanks for adding this. I've seen that these changes have been started somewhat already.

xnopre (Thu, 10 Jan 2019 08:43:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=GZtELaQzYvisCckBD) @HiranKumar @HiranKumar You have to specifiy : ``` const tailsWriterConfig = {'base_dir': "./tails", 'uri_pattern': ''} const blobStorageReaderHandle = await indy.openBlobStorageReader('default', tailsWriterConfig)``` Which script are you running ? Your own or a script in the `indy-sdk` (how-tos or samples) ? In that case, I'm interesting to know and to try to correct it...

xnopre (Thu, 10 Jan 2019 08:43:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=GZtELaQzYvisCckBD) @HiranKumar @HiranKumar There was some changes in the last NodeJs wrapper version, now you have to specifiy the `blobStorageReaderHandle` parameter with this : ``` const tailsWriterConfig = {'base_dir': "./tails", 'uri_pattern': ''} const blobStorageReaderHandle = await indy.openBlobStorageReader('default', tailsWriterConfig)``` Which script are you running ? Your own or a script in the `indy-sdk` (how-tos or samples) ? In that case, I'm interesting to know and to try to correct it...

HiranKumar (Thu, 10 Jan 2019 09:04:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=g33pdZRdbNgZK2kd7) @xnopre Thanks.Now it is working.

xnopre (Thu, 10 Jan 2019 09:09:34 GMT):
@HiranKumar What have you changed ? And please, answer my question, is it your own script or a script in `indy-sdk` (samples or how-tos) ?

xnopre (Thu, 10 Jan 2019 09:09:34 GMT):
@HiranKumar Great ! What have you changed ? And please, answer my question, is it your own script or a script in `indy-sdk` (samples or how-tos) ?

HiranKumar (Thu, 10 Jan 2019 09:17:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=emJG2RsGfhZN4v25J) @xnopre I added the code you mentioned that returns the blobStorageReaderHandle.I used this handle for issuerCreateCredential.

HiranKumar (Thu, 10 Jan 2019 09:18:03 GMT):
@xnopre .this script is my own

dnnn (Thu, 10 Jan 2019 10:15:36 GMT):
Hi! Is my understanding correct that method `indy_set_endpoint_for_did` only sets endpoint locally in the wallet? If so, what is the recommended approach to storing endpoints of `did`s written to the ledger (verinyms)?

HiraSiddiqui (Thu, 10 Jan 2019 11:14:05 GMT):
What is the n & s & z in the primary key? ledger cred-def schema_id=1 signature_type=CL primary={"n":"1","s":"2","rms":"3","r":{"age":"4","name":"5"},"rctxt":"6","z":"7"} There isn't anything about this in the official docs

sklump (Thu, 10 Jan 2019 11:38:32 GMT):
@dnnn ``` attr_json = json.dumps({ 'endpoint': { 'endpoint': endpoint } # indy-sdk needs value itself to be a dict; {'endpoint': '...'} is no good }) req_json = await ledger.build_attrib_request(self.did, self.did, None, attr_json, None) # ... sign and submit. ```

smithbk (Thu, 10 Jan 2019 12:14:46 GMT):
@kdenhartog @sergey.minaev Thanks for the help and reply. No, I haven't found a solution yet due to week-long meetings. If adjusting timeout values doesn't resolve, I'll likely ask for more help. Again, thanks.

HiraSiddiqui (Thu, 10 Jan 2019 15:15:25 GMT):
well, if this rocket chat is not the correct forum for asking questions, maybe the documentation should be updated instead of inviting to ask any queries here!

sklump (Thu, 10 Jan 2019 15:19:44 GMT):
@Hara

sklump (Thu, 10 Jan 2019 15:19:44 GMT):
@HiraSiddiqui https://www.freehaven.net/anonbib/cache/ccs2008:camenisch.pdf

sklump (Thu, 10 Jan 2019 15:22:08 GMT):
Quibble: I notice that the pool.list_pools() returns a string that is not quite JSON: it uses single quotes where pedantic JSON requires double quotes.

sklump (Thu, 10 Jan 2019 15:22:08 GMT):
*Quibble:* I notice that `pool.list_pools()` returns a string that is not quite JSON: it uses single quotes where pedantic JSON requires double quotes.

tuckerg (Thu, 10 Jan 2019 16:25:20 GMT):
Has joined the channel.

abdfaye (Thu, 10 Jan 2019 17:34:49 GMT):
Has joined the channel.

abdfaye (Thu, 10 Jan 2019 17:40:07 GMT):
Hello, is the indy node sdk support issuerCreateAndStoreRevocReg? I am getting IndyError: CommonInvalidStructure running the following code: ` var tailsWriterConfig = { 'base_dir': path.join(__dirname, 'tails'), 'uri_pattern': '' } var tailsWriterHandle = await sdk.openBlobStorageWriter('default', tailsWriterConfig) console.log(tailsWriterHandle); var [revocRegId, revocRegDef, revocRegEntry] = await sdk.issuerCreateAndStoreRevocReg(await indy.wallet.get(), await indy.did.getEndpointDid(), null, tag, credDefId, { max_cred_num: 5 }, tailsWriterHandle); let revocRegDefRequest = await sdk.buildRevocRegDefRequest(await indy.did.getEndpointDid(), revocRegDef); await sdk.signAndSubmitRequest(await indy.pool.get(), await indy.wallet.get(), await indy.did.getEndpointDid(), revocRegDefRequest); let revocRegEntryRequest = await sdk.buildRevocRegEntryRequest(await indy.did.getEndpointDid(), revocRegId, null, revocRegEntry); await sdk.signAndSubmitRequest(await indy.pool.get(), await indy.wallet.get(), await indy.did.getEndpointDid(), revocRegEntryRequest);

abdfaye (Thu, 10 Jan 2019 17:40:07 GMT):
Hello, is the indy node sdk support issuerCreateAndStoreRevocReg? I am getting IndyError: CommonInvalidStructure running the following code: `` var tailsWriterConfig = { 'base_dir': path.join(__dirname, 'tails'), 'uri_pattern': '' } var tailsWriterHandle = await sdk.openBlobStorageWriter('default', tailsWriterConfig) console.log(tailsWriterHandle); var [revocRegId, revocRegDef, revocRegEntry] = await sdk.issuerCreateAndStoreRevocReg(await indy.wallet.get(), await indy.did.getEndpointDid(), null, tag, credDefId, { max_cred_num: 5 }, tailsWriterHandle); let revocRegDefRequest = await sdk.buildRevocRegDefRequest(await indy.did.getEndpointDid(), revocRegDef); await sdk.signAndSubmitRequest(await indy.pool.get(), await indy.wallet.get(), await indy.did.getEndpointDid(), revocRegDefRequest); let revocRegEntryRequest = await sdk.buildRevocRegEntryRequest(await indy.did.getEndpointDid(), revocRegId, null, revocRegEntry); await sdk.signAndSubmitRequest(await indy.pool.get(), await indy.wallet.get(), await indy.did.getEndpointDid(), revocRegEntryRequest);`

abdfaye (Thu, 10 Jan 2019 17:40:07 GMT):
Hello, is the indy node sdk support issuerCreateAndStoreRevocReg? I am getting IndyError: CommonInvalidStructure running the following code: var tailsWriterConfig = { 'base_dir': path.join(__dirname, 'tails'), 'uri_pattern': '' } var tailsWriterHandle = await sdk.openBlobStorageWriter('default', tailsWriterConfig) console.log(tailsWriterHandle); var [revocRegId, revocRegDef, revocRegEntry] = await sdk.issuerCreateAndStoreRevocReg(await indy.wallet.get(), await indy.did.getEndpointDid(), null, tag, credDefId, { max_cred_num: 5 }, tailsWriterHandle); let revocRegDefRequest = await sdk.buildRevocRegDefRequest(await indy.did.getEndpointDid(), revocRegDef); await sdk.signAndSubmitRequest(await indy.pool.get(), await indy.wallet.get(), await indy.did.getEndpointDid(), revocRegDefRequest); let revocRegEntryRequest = await sdk.buildRevocRegEntryRequest(await indy.did.getEndpointDid(), revocRegId, null, revocRegEntry); await sdk.signAndSubmitRequest(await indy.pool.get(), await indy.wallet.get(), await indy.did.getEndpointDid(), revocRegEntryRequest);

abdfaye (Thu, 10 Jan 2019 17:40:07 GMT):
Hello, is the indy node sdk support issuerCreateAndStoreRevocReg? I am getting IndyError: CommonInvalidStructure running the following code: `var tailsWriterConfig = { 'base_dir': path.join(__dirname, 'tails'), 'uri_pattern': '' } var tailsWriterHandle = await sdk.openBlobStorageWriter('default', tailsWriterConfig) console.log(tailsWriterHandle); var [revocRegId, revocRegDef, revocRegEntry] = await sdk.issuerCreateAndStoreRevocReg(await indy.wallet.get(), await indy.did.getEndpointDid(), null, tag, credDefId, { max_cred_num: 5 }, tailsWriterHandle); let revocRegDefRequest = await sdk.buildRevocRegDefRequest(await indy.did.getEndpointDid(), revocRegDef); await sdk.signAndSubmitRequest(await indy.pool.get(), await indy.wallet.get(), await indy.did.getEndpointDid(), revocRegDefRequest); let revocRegEntryRequest = await sdk.buildRevocRegEntryRequest(await indy.did.getEndpointDid(), revocRegId, null, revocRegEntry); await sdk.signAndSubmitRequest(await indy.pool.get(), await indy.wallet.get(), await indy.did.getEndpointDid(), revocRegEntryRequest);`

abdfaye (Thu, 10 Jan 2019 17:40:07 GMT):
Hello, is the indy node sdk support issuerCreateAndStoreRevocReg? I am getting IndyError: CommonInvalidStructure running the following code: ``` var tailsWriterConfig = { 'base_dir': path.join(__dirname, 'tails'), 'uri_pattern': '' } var tailsWriterHandle = await sdk.openBlobStorageWriter('default', tailsWriterConfig) console.log(tailsWriterHandle); var [revocRegId, revocRegDef, revocRegEntry] = await sdk.issuerCreateAndStoreRevocReg(await indy.wallet.get(), await indy.did.getEndpointDid(), null, tag, credDefId, { max_cred_num: 5 }, tailsWriterHandle); let revocRegDefRequest = await sdk.buildRevocRegDefRequest(await indy.did.getEndpointDid(), revocRegDef); await sdk.signAndSubmitRequest(await indy.pool.get(), await indy.wallet.get(), await indy.did.getEndpointDid(), revocRegDefRequest); let revocRegEntryRequest = await sdk.buildRevocRegEntryRequest(await indy.did.getEndpointDid(), revocRegId, null, revocRegEntry); await sdk.signAndSubmitRequest(await indy.pool.get(), await indy.wallet.get(), await indy.did.getEndpointDid(), revocRegEntryRequest); ```

abdfaye (Thu, 10 Jan 2019 17:40:07 GMT):
Hello, does the indy sdk support issuerCreateAndStoreRevocReg? I am getting IndyError: CommonInvalidStructure running the following code: ``` var tailsWriterConfig = { 'base_dir': path.join(__dirname, 'tails'), 'uri_pattern': '' } var tailsWriterHandle = await sdk.openBlobStorageWriter('default', tailsWriterConfig) console.log(tailsWriterHandle); var [revocRegId, revocRegDef, revocRegEntry] = await sdk.issuerCreateAndStoreRevocReg(await indy.wallet.get(), await indy.did.getEndpointDid(), null, tag, credDefId, { max_cred_num: 5 }, tailsWriterHandle); let revocRegDefRequest = await sdk.buildRevocRegDefRequest(await indy.did.getEndpointDid(), revocRegDef); await sdk.signAndSubmitRequest(await indy.pool.get(), await indy.wallet.get(), await indy.did.getEndpointDid(), revocRegDefRequest); let revocRegEntryRequest = await sdk.buildRevocRegEntryRequest(await indy.did.getEndpointDid(), revocRegId, null, revocRegEntry); await sdk.signAndSubmitRequest(await indy.pool.get(), await indy.wallet.get(), await indy.did.getEndpointDid(), revocRegEntryRequest); ```

dnnn (Fri, 11 Jan 2019 08:12:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=vFZqYXcEgRqceh4PB) @sklump thanks for clarification!

xnopre (Fri, 11 Jan 2019 13:21:05 GMT):
@abdfaye You can set a logger to have more details in the "trace" lines just before the error : ```indy.setLogger(function (level, target, message, modulePath, file, line) { console.log('libindy said:', level, target, message, modulePath, file, line) })````

Im5tu (Fri, 11 Jan 2019 16:37:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=LMJDAA7JEqgWTunon) @PatrikStas Yup - I want to run my .net app on Alpine but will need a version of libindy to do so. I haven't got very far in my endevaours at the moment due to my lack of rust and linux type skills xD

MattRaffel (Fri, 11 Jan 2019 16:58:35 GMT):
@Im5tu (not entirely sure but) I would think the libindy deb packages should be good enough on alpine.

MattRaffel (Fri, 11 Jan 2019 16:58:35 GMT):
@Im5tu (I haven't done it myself but) I would think the libindy deb packages should be good enough on alpine.

firewater (Fri, 11 Jan 2019 19:33:59 GMT):
Has joined the channel.

firewater (Sat, 12 Jan 2019 03:33:55 GMT):
is cred definition need to be created once only and reuse or created everytime before issuer create credential for same schema?

tplooker (Sun, 13 Jan 2019 19:04:55 GMT):
@im5tu is the .net app targeting .net framework? I.e required to run on windows, if not you could use this as your image base https://github.com/streetcred-id/docker

PhillipGibb (Mon, 14 Jan 2019 12:48:40 GMT):
Interesting Read about CL Signatures: https://medium.com/@wip.abramson/cl-signatures-for-anonymous-credentials-93980f720d99 The section on "CL Signatures in practice" seems to have a few questions attached. If anyone familiar with this could confirm, that will be great in helping better understand

GEEKTEDDY (Mon, 14 Jan 2019 13:37:18 GMT):
schema = { 'seqNo': seq_no, 'dest': steward_did, 'data': { 'id': '1', 'name': 'gvt', 'version': '1.0', 'ver': '1.0', 'attrNames': ['age', 'sex', 'height', 'name'] } }

GEEKTEDDY (Mon, 14 Jan 2019 13:39:15 GMT):
``` I have a schema like { 'data': { 'attrNames': ['name'] } } ```

GEEKTEDDY (Mon, 14 Jan 2019 13:51:12 GMT):
For the "attrNames" in schema and the attributes in credential, is there any limitation for their length? And if I have a lot of very long 'attrNames' in a schema, will I face the efficiency problem while I am using the schema to create the following cred def and credential(i think it maybe inefficient to communicate with the ledger)? also, if I have a lot of long value for the attribute in credential, like i have a very long name, will I face the efficiency problem?

GEEKTEDDY (Mon, 14 Jan 2019 13:59:45 GMT):
Is there any mature business product or solution which using indy inside? maybe sovrin is one of them.

dnnn (Mon, 14 Jan 2019 17:59:24 GMT):
Hi all, today I have tried to build rust `libindy` on another machine, also MacOS Mojave as previous time. Followed the same instructions from: https://github.com/hyperledger/indy-sdk/blob/master/doc/mac-build.md. But this time with no luck. Has got the following problem

dnnn (Mon, 14 Jan 2019 17:59:36 GMT):
``` --- stderr thread 'main' panicked at 'Unable to locate libzmq: `"pkg-config" "--libs" "--cflags" "libzmq >= 3.2"` did not exit successfully: exit code: 1 --- stderr Package libzmq was not found in the pkg-config search path. Perhaps you should add the directory containing `libzmq.pc' to the PKG_CONFIG_PATH environment variable No package 'libzmq' found ', /Users/denn/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-sys-0.8.2/build.rs:31:17 note: Run with `RUST_BACKTRACE=1` for a backtrace.```

dnnn (Mon, 14 Jan 2019 17:59:36 GMT):
``` --- stderr thread 'main' panicked at 'Unable to locate libzmq: `"pkg-config" "--libs" "--cflags" "libzmq >= 3.2"` did not exit successfully: exit code: 1 --- stderr Package libzmq was not found in the pkg-config search path. Perhaps you should add the directory containing `libzmq.pc' to the PKG_CONFIG_PATH environment variable No package 'libzmq' found ', /Users/bait/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-sys-0.8.2/build.rs:31:17 note: Run with `RUST_BACKTRACE=1` for a backtrace.```

dnnn (Mon, 14 Jan 2019 18:01:49 GMT):
what I have noticed (not sure that this is the root of a problem though) that there is new version of `zeromq` in brew. `4.3.1` vs `4.2.5` used during previous installation. Has anyone build `libindy` from scratch recently? And if so, have you faced any problems?

dnnn (Mon, 14 Jan 2019 18:01:49 GMT):
what I have noticed (not sure that this is the root of a problem though) that there is new version of `zeromq` in brew. `4.3.1` vs `4.2.5` used during previous installation. Has anyone built `libindy` from scratch recently? And if so, have you faced any problems?

MattRaffel (Mon, 14 Jan 2019 18:26:16 GMT):
just curious what does `brew info zmq` show?

dnnn (Mon, 14 Jan 2019 18:52:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=iZSACgquponBweQHR) @MattRaffel unfortunately, I am away from that machine now, so am not able satisfy your curiosity :(

dnnn (Mon, 14 Jan 2019 18:54:24 GMT):
But I have managed to get a successful build after installing `libzmq` version 4.2.5 from source

MALodder (Mon, 14 Jan 2019 20:33:53 GMT):
See my instructions here to see if they help ``` https://github.com/mikelodder7/indy-building ```

DuckLover (Mon, 14 Jan 2019 20:46:06 GMT):
Anyone also got problems with accessing Alice (on port 3000) in this Demo Setup? https://github.com/swcurran/education/tree/master/LFS171x/indy-material/nodejs

jacobsaur (Mon, 14 Jan 2019 21:46:00 GMT):
Is there currently a way to delete a credential that you've saved to your wallet? If not, is this something that's planned, or that the team would appreciate a pull request on?

haniavis (Mon, 14 Jan 2019 22:25:04 GMT):
Has joined the channel.

haniavis (Mon, 14 Jan 2019 22:29:37 GMT):
Hi, I am going through the How-to Tutorials in the indy-sdk readme page. So the "Negotiate a Proof" for Python, seems to be based on outdated code, right? all calls receive an error mostly because of parameters. e.g. wallet.open_wallet(pool_name, issuer_wallet_name, None, None, None) this calls for opening a wallet is different than the other how-to tutorials

haniavis (Mon, 14 Jan 2019 22:29:37 GMT):
Hi, I am going through the How-to Tutorials in the indy-sdk readme page. So the "Negotiate a Proof" for Python, seems to be based on outdated code, right? all calls receive an error mostly because of parameters. e.g. wallet.open_wallet(pool_name, issuer_wallet_name, None, None, None) this call for opening a wallet is different than the other how-to tutorials

kdenhartog (Tue, 15 Jan 2019 00:53:22 GMT):
@haniavis checkout https://github.com/kdenhartog/indy-dev I've gone and updated the how to guides, but haven't gotten around to pushing them to the SDK repo yet.

HiranKumar (Tue, 15 Jan 2019 06:52:43 GMT):
Indy sdk for dotnet supports which version of dotnet framework?.

HiranKumar (Tue, 15 Jan 2019 06:52:54 GMT):
is it supports 4.5?

firewater (Tue, 15 Jan 2019 12:38:29 GMT):
assuming that an issuer issue few schemas and creds. how can it be possible for the issuer display all the schema (latest version) and corresponding creds (latest version) created ? in short what function of the sdk should i used to get the list of latest schema and corresponding creds ids to be display on issuer cloud agent?

firewater (Tue, 15 Jan 2019 12:38:34 GMT):
I would expect something as simple as sdk.listSchemaIds(walletHandle, filter) and sdk.listCredIds(walletHandle, filter)

firewater (Tue, 15 Jan 2019 12:38:34 GMT):
I would expect something as simple as sdk.listSchemaIds(walletHandle, filter) and sdk.listCredIds(walletHandle, filter) without need of communicating with the pool

tomislav (Tue, 15 Jan 2019 14:26:40 GMT):
@HiranKumar Indy SDK supports .netstandard2.0 which is compatible wit netframework 4.7.2. It also supports 4.5.2.

tomislav (Tue, 15 Jan 2019 14:29:01 GMT):
Current nuget is somewhat outdated, it's not yet part of the CI pipeline, but you can find updated packages at this repo as well. https://www.myget.org/feed/agent-framework/package/nuget/Hyperledger.Indy.Sdk

tomislav (Tue, 15 Jan 2019 14:31:58 GMT):
@firewater Libindy doesn't support retrieving a list of schemas or definitions natively. You would need to use a higher level library for this that keeps track of issued definitions. I'm not aware of any nodejs versions for this, but if you're looking for dotnet, here's one - https://agent-framework.readthedocs.io/en/latest/quickstart.html#schemas-and-definitions

firewater (Tue, 15 Jan 2019 14:36:05 GMT):
@tomislav i see. but does the schema id and cred id is stored in the issuer wallet itself?

tomislav (Tue, 15 Jan 2019 15:10:07 GMT):
@firewater The definition is stored in the issue wallet, yes. It contains private crypto keys and is used to sign credentials. The schema, however is not stored in the wallet. `sdk.createSchema` doesn't ask for a wallet parameter, it's just a method to format the schemaJson and Id to a format the ledger will accept.

sklump (Tue, 15 Jan 2019 16:06:08 GMT):
In attempting to cargo build indy-sdk/libindy from master, I get: ``` $ cd indy-sdk/libindy $ cargo build --release ... error: failed to run custom build command for `zmq-sys v0.8.2` process didn't exit successfully: `/home/sklump/indy-sdk/libindy/target/release/build/zmq-sys-eed71cbf82f01f69/build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'Unable to locate libzmq: `"pkg-config" "--libs" "--cflags" "libzmq >= 3.2"` did not exit successfully: exit code: 1 --- stderr Package krb5-gssapi was not found in the pkg-config search path. Perhaps you should add the directory containing `krb5-gssapi.pc' to the PKG_CONFIG_PATH environment variable Package 'krb5-gssapi', required by 'libzmq', not found ``` Is there a new package requirement? Please and thanks.

sklump (Tue, 15 Jan 2019 16:06:08 GMT):
In attempting to cargo build indy-sdk/libindy from master (1.7.0-dev-930), I get: ``` $ cd indy-sdk/libindy $ cargo build --release ... error: failed to run custom build command for `zmq-sys v0.8.2` process didn't exit successfully: `/home/sklump/indy-sdk/libindy/target/release/build/zmq-sys-eed71cbf82f01f69/build-script-build` (exit code: 101) --- stderr thread 'main' panicked at 'Unable to locate libzmq: `"pkg-config" "--libs" "--cflags" "libzmq >= 3.2"` did not exit successfully: exit code: 1 --- stderr Package krb5-gssapi was not found in the pkg-config search path. Perhaps you should add the directory containing `krb5-gssapi.pc' to the PKG_CONFIG_PATH environment variable Package 'krb5-gssapi', required by 'libzmq', not found ``` Is there a new package requirement? Please and thanks. _update_: a workaround is to install `libkrb5-dev`, then `libpgm-dev` and `libnorm-dev`. Docs should take an update if this is the proper way forward?

xnopre (Tue, 15 Jan 2019 16:46:57 GMT):
Hi all. After many weeks working with "Indy SDK NodeJs Wrapper" on my POC, I'm taking a look at the VCX lib. Unlike for the SDK (samples and how-tos), I have not found any samples for the usage of the VCX lib. Where can I found some samples ? Thanks

smithbk (Tue, 15 Jan 2019 21:37:19 GMT):
Can someone tell me how to debug a verification failure? It just returns false but I don't see any indication in the debug logging of why it failed. Thanks in advance for the help.

smithbk (Tue, 15 Jan 2019 21:42:34 GMT):
Can someone tell me how to debug a verification failure? In the debug trace, I see verify_proof being called and returning false, but no indication of what it didn't like. How can I tell what part of the proof request failed during verification? Thanks

tomislav (Tue, 15 Jan 2019 22:07:10 GMT):
SDK API only supports binary true/false result. Do you expect to see which attribute/predicate supplied failed? I'd like to know if this is possible as well

swcurran (Wed, 16 Jan 2019 00:50:45 GMT):
A binary pass/fail definitely needs to be addressed when revocation is included. A proof that passes all but revocation still may be acceptable to a verifier.

swcurran (Wed, 16 Jan 2019 00:50:45 GMT):
A beyond binary pass/fail feature needs to be added when revocation is included. A proof that passes all but revocation still may be acceptable to a verifier.

GEEKTEDDY (Wed, 16 Jan 2019 03:02:00 GMT):
Hi, I want to use indy on Android, how can I use the SDK casue I can't find the indy SDK for Android. Or Is there an easy way to use indy with SDK for other platform on Android?

AvikHazra (Wed, 16 Jan 2019 07:11:50 GMT):
can anyone help me ? when i'm running gettingStarted.js it's showing (node:14202) UnhandledPromiseRejectionWarning: IndyError: CommonInvalidState . what is wrong ?

gudkov (Wed, 16 Jan 2019 14:12:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9EsHsSGkrNvevGsmK) @GEEKTEDDY There is android version. I suggest to re-check readme.md

gudkov (Wed, 16 Jan 2019 14:14:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=hsy2jyXjP3xvrW9xS) @AvikHazra For the moment you need to check indy logs. In a few days there will be new version in master branch that will return much more error information include list of causes and indy backtrace.

tomislav (Wed, 16 Jan 2019 14:18:39 GMT):
I'd like to help setup CI for the SDK dotnet wrapper, so we can publish updated packages to Nuget (or myget) regularly. I can help set this up either with Jenkins, Azure Ppelines, etc. How do I go about initiating this?

xnopre (Wed, 16 Jan 2019 14:40:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ygkmm8uJhr9jDpsXX) @Artemkaaas @KitHat @sergey.minaev @dkulic ? :-)

Artemkaaas (Wed, 16 Jan 2019 14:41:40 GMT):
I think it is the best one https://github.com/hyperledger/indy-sdk/tree/master/vcx/wrappers/python3/demo

xnopre (Wed, 16 Jan 2019 17:22:12 GMT):
@Artemkaaas Thanks. 1/ Is there somewhere some demo or sample for NodeJs wrapper for VCX ? 2/ Are all wrappers (especially python and node) with the same content ? same features ? same state of progress ? 3/ If I good see, VCX lib is always working with a "cloud router agent" (`dummy-cloud-agent` for the demo you pointed) ? 4/ Do you think that this demo can be migrated in NodeJs ? Easy or difficult or impossible ? ;-)

smithbk (Wed, 16 Jan 2019 18:18:51 GMT):
@gudkov @sergey.minaev Can you tell me how to debug a verification failure? I have `RUST_LOG` set to `indy=trace` and am only seeing the following trace statements: ```2019-01-14 20:13:18,892 DEBUG src/commands/anoncreds/verifier.rs:56 | verify_proof >>> proof_req: ProofRequest ... 2019-01-14 20:13:18,920 INFO /home/indy/.cargo/registry/src/github.com-1ecc6299db9ec823/indy-crypto-0.5.0/src/cl/verifier.rs:246 | Verifier verify proof -> done 2019-01-14 20:13:18,921 DEBUG src/commands/anoncreds/verifier.rs:127 | verify_proof <<< result: false ``` Is there some other trace I can enable which tells me why it failed?

esplinr (Wed, 16 Jan 2019 20:13:34 GMT):
@xnopre Remember that LibVCX has only been a released part of the SDK for about a month. There aren't many examples yet.

gudkov (Wed, 16 Jan 2019 20:24:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Qqq3SoDbNcmEFHn2t) @tomislav Pipelines are public. You can look to Jenkins.ci/Jenkins.cd files in repo root. Technically you can make PR and contact @sergey.minaev and @andkononykhin for permissions setup.

gudkov (Wed, 16 Jan 2019 20:26:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ABiRSEvCd48PZqeur) @swcurran Prover can proof that credential was non-revoked in the past now. From my point of view it solves this use case.

GEEKTEDDY (Thu, 17 Jan 2019 02:48:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9yekzB27DNXpaheMc) @gudkov could you give me a right link? cause this 'readme.md' will lead me to somewhere strange

adamjbradley (Thu, 17 Jan 2019 05:01:50 GMT):
Heh! Is it possible to complete a DID Auth flow headless?

kdenhartog (Thu, 17 Jan 2019 06:44:07 GMT):
What do you mean by headless?

kdenhartog (Thu, 17 Jan 2019 06:44:07 GMT):
@adamjbradley What do you mean by headless?

xnopre (Thu, 17 Jan 2019 09:02:30 GMT):
@esplinr OK, thanks. And do you have some answers for my other questions ? ;-)

Artemkaaas (Thu, 17 Jan 2019 09:52:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=q72pmEuZ95wJFmFMk) @xnopre 1) I think there is not any complete sample. There is a set of tests each of them cover particular function 2) I hope yes. 3) dummy-cloud-agent is a simple public alternative which can be used for playing with vcx 4) I believe it should not be hard.

firewater (Thu, 17 Jan 2019 11:26:32 GMT):
does a wallet contain only a master key or multiple? and what is master key use for

HiranKumar (Thu, 17 Jan 2019 12:27:05 GMT):
How can we get the schema defention using schema

HiranKumar (Thu, 17 Jan 2019 12:27:06 GMT):
?

xnopre (Thu, 17 Jan 2019 13:42:04 GMT):
Question about keys... When I call `const [did, key] = await indy.createAndStoreMyDid(wallet, options)`, I get a `DID` and a `key`. Is it correct to say that `key` is also sometimes called `verkey` and is a public key ? And that a private key is associated to this key, is stored in the wallet, is used to crypt message, and is not visible by me (developper) ? Thanks

MattRaffel (Thu, 17 Jan 2019 15:55:05 GMT):
@xnopre yes. and yes. the verkey is public

swcurran (Thu, 17 Jan 2019 17:49:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=MMEuwqFiqqDxK7ei6) @gudkov Sure but unnecessarily complex. I would want a more nuanced answer from the proof operation than just "pass/fail" - as in "pass/fail + fail reason". Or from the HTTP world - "200" if all good and a bunch of other numbers for the various reasons. The Prover would know the reason in preparing the proof and could choose to share (or not) the proof with the Verifier.

sklump (Thu, 17 Jan 2019 19:18:46 GMT):
*Item*: from von-anchor 1.7.6, the node pool initializer will only need the genesis transaction path if the pool's indy control files don't yet exist. Genesis transactions aren't secrets though. There is no harm in keeping them and passing a pool's genesis transaction path around, unless its content disagrees with a pool existing on the same name: in that case, the von_anchor node pool will refer to the existing one rather than replacing it on the new genesis transaction file content. I will submit this tomorrow with follow-through on test cases, tails server. The von_anchor 1.7.6 release will also pick up indy-sdk 1.7.0-dev-933.

sahanmal (Fri, 18 Jan 2019 05:15:25 GMT):
Has joined the channel.

sahanmal (Fri, 18 Jan 2019 05:19:20 GMT):
Hi When i try to create a revocation registry using indy-sdk node.js library i get CommonInvalidStructure error I can not find what is wrong with the parameters i pass as error is not specific. below is my code await indy.issuerCreateAndStoreRevocReg(wh, issuerDid, null, 'tag2', indyDoc.credDefId, { "max_cred_num": 1000}, tailsWriterHandle) can anyone point me out what is the issue Thanks

sahanmal (Fri, 18 Jan 2019 05:19:20 GMT):
Hi Everyone I am currently facing two problems 1. When i try to create a revocation registry using indy-sdk node.js library i get CommonInvalidStructure error I can not find what is wrong with the parameters i pass as error is not specific. below is my code await indy.issuerCreateAndStoreRevocReg(wh, issuerDid, null, 'tag2', indyDoc.credDefId, { "max_cred_num": 1000}, tailsWriterHandle) can anyone point me out what is the issue 2. If we do not create a revocation registy due to above arror can we call proverCreateProof method without revStates parameter ? Thanks

Yair (Fri, 18 Jan 2019 11:01:55 GMT):
Has joined the channel.

xnopre (Fri, 18 Jan 2019 12:52:53 GMT):
@sahanmal 1. Set a logger to have more information about the problem. You will find a more detailed log trace juste before your error : ```indy.setLogger(function (level, target, message, modulePath, file, line) { console.log('libindy said:', level, target, message, modulePath, file, line) })``` 2. Yes, with empty parameter `{}` , take a look at "samples" or "how-tos" directories

sahanmal (Fri, 18 Jan 2019 13:32:24 GMT):
@xnopre thanks setLogger help to fix the issue :) it was i did not add below config when create and storing the credentials via "issuerCreateAndStoreCredentialDef" { support_revocation: true }

alkopnin (Fri, 18 Jan 2019 14:18:21 GMT):
Hi there! @TelegramSam recommended to send message here. I just copy-paste it from indy-agent channel =) Our team (@AlexanderVtyurin) is working on Corda Agent (part of HL-lab) and in order to implement agent we made some fixes in vcx java wrapper. We would like to be synchronized with you and contribute the code. Do you have someone responsible for vcx java wrapper? https://github.com/seniorjoinu/indy-sdk/commit/8ab8c0ce6f6efd441a7e2d09fb6ca9a0a080f36e - here is the commit with vcx java wrapper fixes. Some method signatures was incorrect and some native function invocations was incorrect too.

sahanmal (Fri, 18 Jan 2019 14:19:22 GMT):
one last question I have an issuer, prover and validator (3 users lets say) now i created a credential using issuer and store it in the prover's wallet. Then prover creeate a proof request using the credentials just saved to his wallet and send that to the validator. when validator ties to validate the proof request it returns false. (according to the doc false means wrong signature). Is this because proof created from provers wallet instead the original issuer's wallet ?

smithbk (Fri, 18 Jan 2019 18:21:10 GMT):
@sahanmal A proof is always creates by using credentials from the prover's wallet. The term "validator" is typically used for a steward node. I assume you mean "verifier" above. The verifier creates a proof request, sends it to the prover who uses it to generate a proof. The prover then gives the proof to the verifier who uses both the proof request and proof to perform the verification. If the verification returns false, it is not possible for the verifier to know which part of the proof request was not satisfied.

kdenhartog (Fri, 18 Jan 2019 22:35:47 GMT):
@alkopnin I've forward this message onto a VCX maintainer.

sahanmal (Sat, 19 Jan 2019 03:22:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=eHcacxCHDkGQNxyqY) @smithbk I have locally setup a credential issueer, prover, and verifier to test these. Every time I validate a proof request sent to verifier it is false. Is there any way to debug what is wrong with the proof request ? (I already have system logs but i cant find any log related to why false returns)

Dubh3124 (Sun, 20 Jan 2019 19:30:03 GMT):
From reading the indy-sdk docs (unless I missed something) I do not see a way to get a master_secret_id after creating a master secret initially i.e besides from the return. Can it be queried from somewhere? If not, is it a security issue if I store the master secret id as a non_secret?

Dubh3124 (Sun, 20 Jan 2019 19:31:18 GMT):
FYI, I am using the python sdk

kdenhartog (Mon, 21 Jan 2019 06:22:40 GMT):
@Dubh3124 I would strongly urge not storing the master_secret in the non_secrets api. This would create a potential security vulnerability for you. What is it that you're trying to acheive with the master_secret where you need to have access to it?

Dubh3124 (Mon, 21 Jan 2019 08:23:04 GMT):
@kdenhartog Let me clarify, I am referring to the master_secret_id not the actual master_secret that is stored in the wallet (According to the Secrets API, I am assuming ids are how to access secrets in wallets). From following along the Getting Started Walk through where Alice has to call anoncreds.prover_create_credential_req(), the master_secret_id is needed. I know in the step by step guide its done previously but in a real world situation, Alice will need the master_secret_id. So should this id be treated as some kind of password even though its just an id?

Dubh3124 (Mon, 21 Jan 2019 08:23:04 GMT):
@kdenhartog Let me clarify, I am referring to the master_secret_id not the actual master_secret that is stored in the wallet (According to the Secrets API, I am assuming ids are how to access secrets in wallets). From following along the Getting Started Walk through where Alice has to call anoncreds.prover_create_credential_req(), the master_secret_id is needed. I know in the step by step guide its as been created in a previous step but in a real world situation, Alice will need the master_secret_id. So should this id be treated as some kind of password even though its just an id?

kdenhartog (Mon, 21 Jan 2019 08:24:39 GMT):
ahh, in the case of the master_secret_id, yeah that's fine to store in non-secrets.

kdenhartog (Mon, 21 Jan 2019 08:24:39 GMT):
ahh, in the case of the master_secret_id, I believe that's fine to store in non-secrets. I'll do some investigation to make sure that the id, isn't connected to the master_secret in anyway, but I'm about 40% positive without checking that it's not.

xnopre (Mon, 21 Jan 2019 08:27:26 GMT):
@sahanmal Take a look at the "how-tos" scripts (i.e. https://github.com/hyperledger/indy-sdk/blob/master/doc/how-tos/negotiate-proof/nodejs/negotiateProof.js) and "samples" script (i.e. https://github.com/hyperledger/indy-sdk/blob/master/samples/nodejs/src/anoncredsRevocation.js)

kdenhartog (Mon, 21 Jan 2019 08:29:47 GMT):
I just double checked, the master_secret_id is not cryptographically linked to the actual master_secret. It's just a lookup value. Also worth noting, the optional string `master_secret_name` is a way to specify the `master_secret_id` which could be useful, because then you could make it something deterministic based upon your app.

kdenhartog (Mon, 21 Jan 2019 08:31:10 GMT):
@xnopre I saw that you completed some of the how-tos for node.js. Have you completed all of them yet or did that PR you originally submitted include all of them?

Dubh3124 (Mon, 21 Jan 2019 08:36:24 GMT):
That is good to know because I have been using uuids for record Ids when storing certain record types to wallet i.e {"totalCount":1,"records":[{"type":"masterSecretID","id":"0cba1b51eebd5151b2","value":"ef69b768-6a6c-433b-8c58-86a9adbb189e","tags":{}}]}

Dubh3124 (Mon, 21 Jan 2019 08:38:13 GMT):
Actually I store all id type values to wallet records. I am not sure if that is the right thing to do but it has helped me with get them easily later

Dubh3124 (Mon, 21 Jan 2019 08:45:58 GMT):
In regards to the python sdk pairwise module, what does it do exactly? I thought the return json of create_pairwise would have a pairwise DID created, but I was wrong.

xnopre (Mon, 21 Jan 2019 10:39:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=bzitfn3tHKPXXkNAC) @kdenhartog I d'ont really understand you question. I have added some "how-tos" script for NodeJs, and I had done PR for each script (#1347, #1350, #1374). I had also done some PR to add some "samples" scripts for NodeJs (#1269 and #1344). Can you clarify your question ? :-)

sergey.minaev (Mon, 21 Jan 2019 14:52:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=e5YHvfef885sTnBNF) @smithbk most probably not. `Ok(false)` means that math verification failed: all data parsed from jsons successfully an correct input is constructed for IndyCrypto calls but final math check is failed. @smithbk do you have test/scenario to reproduce this error? @Artemkaaas please track this thread

smithbk (Mon, 21 Jan 2019 15:00:33 GMT):
@sergey.minaev Thanks. I don't know how to reproduce. It works most of the time but gets in this state occasionally and haven't yet seen a pattern.

kdenhartog (Mon, 21 Jan 2019 16:04:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=EB679rGtNyRXjpECC) @xnopre I went in and saw which how-tos had already been finished and figured it out. I was trying to figure out if all of the nodejs how-to guides had been finished yet.

xnopre (Mon, 21 Jan 2019 16:18:14 GMT):
@kdenhartog No, they are not all available in NodeJs. I had migrated some of the "samples" or "how-tos" depending on my needs ;-) . What is you need now ?

kdenhartog (Mon, 21 Jan 2019 16:26:03 GMT):
None at the moment, but when you've completed it I'm planning to migrate them over to a side project that allows users to setup a nodejs environment quickly and go through those guides. Here's a link of it's current state. https://github.com/kdenhartog/indy-dev

sklump (Tue, 22 Jan 2019 13:39:27 GMT):
Hey indy-sdk fans! I am feeling magnanimous, so I bestow a trade secret onto all before this comment scrolls off the end. In a schema, do not call an attribute `hash`. It is reserved. The origin can write the schema to the ledger, but sending the cred def to the ledger returns a mysterious and otherwise un-troubleshoot-able ``` von_anchor.error.BadLedgerTxn: (1012) Ledger rejected transaction request: client request invalid: InsufficientCorrectSignatures(0, 1) ```

sklump (Tue, 22 Jan 2019 13:39:27 GMT):
Hey indy-sdk fans! I am feeling magnanimous, so I bestow a trade secret onto all before this comment scrolls off the end. In a schema, do not call an attribute `hash`. It is reserved. The origin can write the schema to the ledger, but sending the cred def to the ledger returns a mysterious and otherwise un-troubleshoot-able ``` (1012) Ledger rejected transaction request: client request invalid: InsufficientCorrectSignatures(0, 1) ``` This lesson cost me 5 hours but is yours for the time it took to read this comment.

sklump (Tue, 22 Jan 2019 13:39:27 GMT):
Hey indy-sdk fans! I am feeling magnanimous, so I bestow a trade secret onto all before this comment scrolls off the end. In a schema, do not call an attribute `hash`. It is reserved. The origin can write the schema to the ledger, but sending the cred def to the ledger returns a mysterious and otherwise un-troubleshoot-able ``` Ledger rejected transaction request: client request invalid: InsufficientCorrectSignatures(0, 1) ``` This lesson cost me 5 hours but is yours for the time it took to read this comment.

sklump (Tue, 22 Jan 2019 13:39:27 GMT):
Hey indy-sdk fans! I am feeling magnanimous, so I bestow a trade secret onto all before this comment scrolls off the end. In a schema, do not call an attribute `hash`. It is reserved. The origin can write the schema to the ledger, but sending the cred def to the ledger returns a mysterious and otherwise un-troubleshoot-able ``` client request invalid: InsufficientCorrectSignatures(0, 1) ``` This lesson cost me 5 hours but is yours for the time it took to read this comment.

kdenhartog (Tue, 22 Jan 2019 13:55:00 GMT):
I bet that was an annoying bug to discover. Let's start an SDK consumer FMM (Frequent mistakes made) doc that includes knowledge like this.

sklump (Tue, 22 Jan 2019 14:20:11 GMT):
The fact that indy-sdk does so much, so difficult, so well, gives it a pass for the quibbles like this.

vsadriano (Tue, 22 Jan 2019 15:52:51 GMT):
Has joined the channel.

xnopre (Tue, 22 Jan 2019 16:27:41 GMT):
Trying to install libVCX, I follow https://github.com/hyperledger/indy-sdk/tree/master/vcx and when I try to run `sudo apt-get install -y libvcx` , I have this error `Unable to locate package libvcx`... What's happening ? What's wrong ? Thanks for your help :-)

xnopre (Tue, 22 Jan 2019 16:34:08 GMT):
I try ti run `demo` of VCX (), and I have this error (I'm newbie in Python) : ```$ python3 faber.py Traceback (most recent call last): File "faber.py", line 9, in from vcx.api.connection import Connection ImportError: No module named 'vcx'``` Thanks for your help :-)

xnopre (Tue, 22 Jan 2019 16:34:08 GMT):
I try ti run `demo` of VCX (https://github.com/hyperledger/indy-sdk/tree/master/vcx/wrappers/python3/demo), and I have this error (I'm newbie in Python) : ```$ python3 faber.py Traceback (most recent call last): File "faber.py", line 9, in from vcx.api.connection import Connection ImportError: No module named 'vcx'``` Thanks for your help :-)

MattRaffel (Tue, 22 Jan 2019 17:38:45 GMT):
@sklump this should actually be documented some where. I will write a jira ticket

MattRaffel (Tue, 22 Jan 2019 17:38:45 GMT):
@sklump this should actually be documented some where (or fixed). I will write a jira ticket

MattRaffel (Tue, 22 Jan 2019 17:38:45 GMT):
@sklump this should actually be documented some where (or fixed). I have written a jira ticket for it: https://jira.hyperledger.org/browse/IS-1158

rajeshkalaria (Wed, 23 Jan 2019 03:01:21 GMT):
Has joined the channel.

HLFPOC (Wed, 23 Jan 2019 05:21:56 GMT):
Has joined the channel.

HLFPOC (Wed, 23 Jan 2019 05:28:02 GMT):
Hello Team, I have a usecase in which i want to create a mobile based wallet which should have the capability to upload/download documents so that verification can be done by other organizations present in Hyperledger Indy network. I was going through Indy SDK documentation can see that there are wrappers available for iOS but for Android, it says that it may have some bug as it is not production grade. So can anyone of you can guide me how to achieve this feature to have mobile based wallets (for both Android and iOS). Also kindly suggest how documents can be handled in wallets.

ShivanshVij (Wed, 23 Jan 2019 21:01:02 GMT):
Has joined the channel.

DuckLover (Thu, 24 Jan 2019 00:12:10 GMT):
Hello,

DuckLover (Thu, 24 Jan 2019 00:14:34 GMT):
Hello, I am playing with the reference agents and tried to change the govID a little. I want to change "email" to "address" and "tax_id" to "day_of_birth". I thought i changed it everywhere but i get this bug.

DuckLover (Thu, 24 Jan 2019 00:14:50 GMT):

govID_problem.png

swcurran (Thu, 24 Jan 2019 05:13:07 GMT):
Just a guess here --- If you are using the same ledger and wallet - did you change the version? If the schema already exists on the ledger you are using, you have to bump the schema version or it reuses the old one. If you are starting fresh, it wouldn't be that.

DuckLover (Thu, 24 Jan 2019 09:42:57 GMT):
i did change the following things, maybe someone can tell me where i missed something

DuckLover (Thu, 24 Jan 2019 09:43:14 GMT):
``` async function issueGovernmentIdCredential() { let schemaName = 'Government-ID'; let schemaVersion = '1.1'; let signatureType = 'CL'; let govIdSchema; let govIdSchemaId = `${stewardDid}:2:${schemaName}:${schemaVersion}`; try { govIdSchema = await indy.issuer.getSchema(govIdSchemaId); } catch(e) { [govIdSchemaId, govIdSchema] = await sdk.issuerCreateSchema(stewardDid, schemaName, schemaVersion, [ 'name', 'address', 'day_of_birth' ]); await indy.issuer.sendSchema(await indy.pool.get(), stewardWallet, stewardDid, govIdSchema); govIdSchema = await indy.issuer.getSchema(govIdSchemaId); } let govIdCredDef; [govIdCredDefId, govIdCredDef] = await sdk.issuerCreateAndStoreCredentialDef(stewardWallet, stewardDid, govIdSchema, 'GOVID', signatureType, '{"support_revocation": false}'); await indy.issuer.sendCredDef(await indy.pool.get(), stewardWallet, stewardDid, govIdCredDef); exports.setEndpointDidAttribute('govIdCredDefId', govIdCredDefId); let govIdCredOffer = await sdk.issuerCreateCredentialOffer(stewardWallet, govIdCredDefId); let [govIdCredRequest, govIdRequestMetadata] = await sdk.proverCreateCredentialReq(await indy.wallet.get(), endpointDid, govIdCredOffer, govIdCredDef, await indy.did.getEndpointDidAttribute('master_secret_id')); let govIdValues = { name: {"raw": config.userInformation.name, "encoded": indy.credentials.encode(config.userInformation.name)}, address: {"raw": config.userInformation.address, "encoded": indy.credentials.encode(config.userInformation.address)}, day_of_birth: {"raw": config.userInformation.day_of_birth, "encoded": indy.credentials.encode(config.userInformation.day_of_birth)}, }; let [govIdCredential] = await sdk.issuerCreateCredential(stewardWallet, govIdCredOffer, govIdCredRequest, govIdValues); let res = await sdk.proverStoreCredential(await indy.wallet.get(), null, govIdRequestMetadata, govIdCredential, govIdCredDef); } ```

DuckLover (Thu, 24 Jan 2019 09:43:52 GMT):
in the config.js ``` // This information is used to issue your "Government ID" userInformation: { name: process.env.NAME || 'Alice Garcia', address: process.env.ADDRESS || 'Sovrinstreet123', day_of_birth: process.env.DAY_OF_BIRTH || '10-11-1993', username: process.env.USERNAME || 'alice', password: process.env.PASSWORD || '123' }, ```

DuckLover (Thu, 24 Jan 2019 09:44:33 GMT):
and in the docker compose file ``` alice: image: indy-agentjs build: context: . command: "bash -c 'npm start'" environment: - PORT=3000 - NAME=Alice - ADDRESS=Indystreet123 - DAY_OF_BIRTH=11-11-1990 - PASSWORD=123 - USERNAME=alice - PUBLIC_DID_ENDPOINT=173.17.0.150:3000 - DOCKERHOST=${DOCKERHOST} - RUST_LOG=${RUST_LOG} - TEST_POOL_IP=${TEST_POOL_IP} ports: - 3000:3000 depends_on: - pool networks: services: ipv4_address: 173.17.0.150 ```

AlexanderVtyurin (Thu, 24 Jan 2019 11:52:00 GMT):
Hello, everyone. I'm trying to create one but right now I'm facing some problems with `libnullpay_arm64`. When I try to do this to init `libnullpay` from repo.sovrin in my Kotlin app, it crashes. ``` interface Nullpay: Library { // load via JNA companion object { val JNA_LIBRARY_NAME = "nullpay" val INSTANCE: Nullpay = Native.load(JNA_LIBRARY_NAME, Nullpay::class.java) } fun nullpay_init(): Int } // and then in the calling code - this line crashes Nullpay.INSTANCE.nullpay_init() ``` The error message says almost nothing: `A/libc: Fatal signal 11 (SIGSEGV), code 2, fault addr 0x7fd3401fb0 in tid 30666 (.androidvcxdemo), pid 30666 (.androidvcxdemo)` Without `libnullpay` everything works fine (like provisioning and wallet-pool creation), but I'm unable to issue credentials and so on. I'm also tried to rebuild `libnullpay` from source and I succeed with x86 abi build, but aarch64 abi build crashes with something like: ``` /usr/bin/ld: /home/alex/IdeaProjects/indy-sdk-fork/libnullpay/target/aarch64-linux-android/debug/deps/nullpay.119fuqwn8tn953rw.rcgu.o: Relocations in generic ELF (EM: 183) /usr/bin/ld: /home/alex/IdeaProjects/indy-sdk-fork/libnullpay/target/aarch64-linux-android/debug/deps/nullpay.119fuqwn8tn953rw.rcgu.o: Relocations in generic ELF (EM: 183) /usr/bin/ld: /home/alex/IdeaProjects/indy-sdk-fork/libnullpay/target/aarch64-linux-android/debug/deps/nullpay.119fuqwn8tn953rw.rcgu.o: Relocations in generic ELF (EM: 183) /home/alex/IdeaProjects/indy-sdk-fork/libnullpay/target/aarch64-linux-android/debug/deps/nullpay.119fuqwn8tn953rw.rcgu.o: error adding symbols: File in wrong format ``` So, my questions are: 1. Is there a working android app example using libvcx:0.2.0? 2. Is there a possibility that libnullpay_arm64 from repo.sovrin was built incorrectly? 3. Is there a way to get some working version of libnullpay_arm64 to make my app work?

AlexanderVtyurin (Thu, 24 Jan 2019 11:52:00 GMT):
Hello, everyone. I'm trying to create an android app but right now I'm facing some problems with `libnullpay_arm64`. When I try to do this to init `libnullpay` from repo.sovrin in my Kotlin app, it crashes. ``` interface Nullpay: Library { // load via JNA companion object { val JNA_LIBRARY_NAME = "nullpay" val INSTANCE: Nullpay = Native.load(JNA_LIBRARY_NAME, Nullpay::class.java) } fun nullpay_init(): Int } // and then in the calling code - this line crashes Nullpay.INSTANCE.nullpay_init() ``` The error message says almost nothing: `A/libc: Fatal signal 11 (SIGSEGV), code 2, fault addr 0x7fd3401fb0 in tid 30666 (.androidvcxdemo), pid 30666 (.androidvcxdemo)` Without `libnullpay` everything works fine (like provisioning and wallet-pool creation), but I'm unable to issue credentials and so on. I'm also tried to rebuild `libnullpay` from source and I succeed with x86 abi build, but aarch64 abi build crashes with something like: ``` /usr/bin/ld: /home/alex/IdeaProjects/indy-sdk-fork/libnullpay/target/aarch64-linux-android/debug/deps/nullpay.119fuqwn8tn953rw.rcgu.o: Relocations in generic ELF (EM: 183) /usr/bin/ld: /home/alex/IdeaProjects/indy-sdk-fork/libnullpay/target/aarch64-linux-android/debug/deps/nullpay.119fuqwn8tn953rw.rcgu.o: Relocations in generic ELF (EM: 183) /usr/bin/ld: /home/alex/IdeaProjects/indy-sdk-fork/libnullpay/target/aarch64-linux-android/debug/deps/nullpay.119fuqwn8tn953rw.rcgu.o: Relocations in generic ELF (EM: 183) /home/alex/IdeaProjects/indy-sdk-fork/libnullpay/target/aarch64-linux-android/debug/deps/nullpay.119fuqwn8tn953rw.rcgu.o: error adding symbols: File in wrong format ``` So, my questions are: 1. Is there a working android app example using libvcx:0.2.0? 2. Is there a possibility that libnullpay_arm64 from repo.sovrin was built incorrectly? 3. Is there a way to get some working version of libnullpay_arm64 to make my app work?

AlexanderVtyurin (Thu, 24 Jan 2019 11:52:00 GMT):
Hello, everyone. I'm trying to create an android app but right now I'm facing some problems with `libnullpay_arm64`. When I try to init `libnullpay` from repo.sovrin in my Kotlin app, it crashes. ``` interface Nullpay: Library { // load via JNA companion object { val JNA_LIBRARY_NAME = "nullpay" val INSTANCE: Nullpay = Native.load(JNA_LIBRARY_NAME, Nullpay::class.java) } fun nullpay_init(): Int } // and then in the calling code - this line crashes Nullpay.INSTANCE.nullpay_init() ``` The error message says almost nothing: `A/libc: Fatal signal 11 (SIGSEGV), code 2, fault addr 0x7fd3401fb0 in tid 30666 (.androidvcxdemo), pid 30666 (.androidvcxdemo)` Without `libnullpay` everything works fine (like provisioning and wallet-pool creation), but I'm unable to issue credentials and so on. I'm also tried to rebuild `libnullpay` from source and I succeed with x86 abi build, but aarch64 abi build crashes with something like: ``` /usr/bin/ld: /home/alex/IdeaProjects/indy-sdk-fork/libnullpay/target/aarch64-linux-android/debug/deps/nullpay.119fuqwn8tn953rw.rcgu.o: Relocations in generic ELF (EM: 183) /usr/bin/ld: /home/alex/IdeaProjects/indy-sdk-fork/libnullpay/target/aarch64-linux-android/debug/deps/nullpay.119fuqwn8tn953rw.rcgu.o: Relocations in generic ELF (EM: 183) /usr/bin/ld: /home/alex/IdeaProjects/indy-sdk-fork/libnullpay/target/aarch64-linux-android/debug/deps/nullpay.119fuqwn8tn953rw.rcgu.o: Relocations in generic ELF (EM: 183) /home/alex/IdeaProjects/indy-sdk-fork/libnullpay/target/aarch64-linux-android/debug/deps/nullpay.119fuqwn8tn953rw.rcgu.o: error adding symbols: File in wrong format ``` So, my questions are: 1. Is there a working android app example using libvcx:0.2.0? 2. Is there a possibility that libnullpay_arm64 from repo.sovrin was built incorrectly? 3. Is there a way to get some working version of libnullpay_arm64 to make my app work?

DuckLover (Thu, 24 Jan 2019 12:40:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=duKzYQPSm8MkdNnkF) @swcurran i do docker-compose build it after every change

DuckLover (Thu, 24 Jan 2019 12:49:50 GMT):
Seems like docker-compose build didnt clean the ledger. Is that right? With a different schema name and cred name i get no errors

MattRaffel (Thu, 24 Jan 2019 15:43:45 GMT):
@AlexanderVtyurin we are experiencing similar issues with android. we are looking into it.

MattRaffel (Thu, 24 Jan 2019 15:43:45 GMT):
@AlexanderVtyurin we are experiencing similar issues with android. we are looking into it. I hope I can report an update soon.

swcurran (Thu, 24 Jan 2019 16:26:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=73S9CDbQxLTf3riDs) @DuckLover A build doesn't delete the ledger or wallet - if the volumes stay around, then the ledger and wallets that are on those volumes remain. Look at the -v options on the docker-compose `down` and `rm` sub-commands. If the wallets and ledgers remain around from run to run (which is sometimes OK - for example if you are just changing UI code), that will require that you do things like bump the schema version when you change it.

AlexanderVtyurin (Thu, 24 Jan 2019 16:49:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4Fxz3ezSQxApsSynR) @MattRaffel I'm able to build `libnullpay` for arm64 abi. To do so, you have to remove the `cdylib` flag from `crate-type` in `cargo.toml`, but I'm not sure now if it is possible to somehow pass static library to Android. Please, `@` me if you'll have an update.

cguerin (Thu, 24 Jan 2019 16:55:41 GMT):
Hi, I currently work with the nodejs version of the SDK. I've an error 210 occured but i've change nothing on my code and it works on others computers. This is detailled logs: ```bash INDY: 1 (indy::errors::indy) Casting error to ErrorCode: Wallet storage error occurred. Description: IO error during storage operation: near ")": syntax error (indy::errors::indy / src/errors/indy.rs:73) INDY: 5 (indy::api::anoncreds) indy_prover_search_credentials_for_proof_req: search_handle: 0 (indy::api::anoncreds / src/api/anoncreds.rs:1282) catch: { IndyError: 210 at Object.callback (/home/indy/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10) name: 'IndyError', message: '210' } ``` Does anyone have an idea to solve this issue? Thx, Cédric

sklump (Thu, 24 Jan 2019 17:36:05 GMT):
At present, indy-sdk 1.7.0-dev-950 libindy does not build with the most recent rust (1.32.0): ``` # ... Compiling lazy_static v0.2.11 Compiling zeroize v0.5.2 error: Edition 2018 is unstable and only available for nightly builds of rustc. error: Could not compile `zeroize`. ```

sklump (Thu, 24 Jan 2019 17:36:05 GMT):
At present, indy-sdk 1.7.0-dev-950 libindy does not build with the most recent rust (1.32.0): ``` $ cd ~/indy-sdk/libindy $ cargo build --release ... Compiling lazy_static v0.2.11 Compiling zeroize v0.5.2 error: Edition 2018 is unstable and only available for nightly builds of rustc. error: Could not compile `zeroize`. ```

DuckLover (Thu, 24 Jan 2019 23:17:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Sk9BbwAqtaJfPu77Y) @swcurran i tried the docker-compose rm (-v) commands but the ledger is still not in the origin state. Is there no option to get a "empty" ledger?

swcurran (Thu, 24 Jan 2019 23:21:51 GMT):
Ah....I'm not completely familiar with how that repo works, but maybe you run the nodes outside of the docker-compose? If so, the docker-compose volume commands wouldn't help. If you are running things in docker then it is somewhere that you have to delete the volumes.

jjensenevernym (Fri, 25 Jan 2019 02:11:55 GMT):
Any ideas as to what would cause periodic corruption of the local pool config in .indy_client/pool?

Dubh3124 (Fri, 25 Jan 2019 03:25:41 GMT):
@jjensenevernym What error message are you getting? I ran into something similar a while back and thought the same thing. But I found that I was leaving the pool handle open somewhere.

LucW (Fri, 25 Jan 2019 11:38:33 GMT):
Hi. I noticed that in the universal resolver project, there are the ips of many live pools, for many different projects, including Sovrin which uses libindy. Is it allowed to connect to those pools and experiment with them ?

MikeRichardson (Fri, 25 Jan 2019 15:16:20 GMT):
Has joined the channel.

jjensenevernym (Fri, 25 Jan 2019 21:30:34 GMT):
@Dubh3124 It's an invalid state error.

haggs (Fri, 25 Jan 2019 21:35:31 GMT):
@jjensenevernym I remember running into these issues using the getting started repo curteous of @kdenhartog, https://github.com/kdenhartog/indy-dev, blasting away the `.indy_client` directory worked, but that doesn't answer the root to your problem. I think I remember there are a few things which the getting started opens but doesn't close (like @Dubh3124 mentioned about the pool handle being left open?). Mind sharing what line of code brings you to the invalid state error?

firewater (Sat, 26 Jan 2019 14:15:38 GMT):
after i create a schema and cred def with a wallet, how can i search all the schema and cred def that i created with that wallet before

firewater (Sat, 26 Jan 2019 14:16:21 GMT):
eg: sdk.searchSchema(walletHandle), sdk.searchCredDef(walletHandle)

firewater (Sat, 26 Jan 2019 14:16:46 GMT):
is there some function like that, if not how can i get the schema and cred def that i created?

mwherman2000 (Sat, 26 Jan 2019 22:59:54 GMT):
Where/how does one post an issue against the Indy-SDK? ...I don't see the Issues tab here: https://github.com/hyperledger/indy-sdk

mwherman2000 (Sat, 26 Jan 2019 22:59:54 GMT):
Where/how does someone post an issue against the Indy-SDK? ...I don't see the Issues tab here: https://github.com/hyperledger/indy-sdk

kdenhartog (Sat, 26 Jan 2019 23:09:27 GMT):
Tickets should be filed in Jira at jira.hyperledger.org

mwherman2000 (Sat, 26 Jan 2019 23:12:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=3a5a7e75-924c-42ec-8569-9aed6b0b94ae) @kdenhartog Please check my DM

DuckLover (Sun, 27 Jan 2019 04:22:00 GMT):
Hello guys,

DuckLover (Sun, 27 Jan 2019 04:28:25 GMT):
Hello guys, maybe some of you can help me out here. I am working on the indy-agent reference implementation and trying to find a easy way to debug it. I changed the follwing part in the docker-compose.yml file ``` alice: image: indy-agentjs build: context: . command: "bash -c 'node --inspect-brk=9229 ./bin/www'" environment: - PORT=3000 - VORNAME=Alice - NAME=Ducklove - GEBURTSTAG=01.11.1990 - GEBURTSORT=Ducktown - ANSCHRIFT= quackstreet 123 - PASSWORD=123 - USERNAME=alice - PUBLIC_DID_ENDPOINT=173.17.0.150:3000 - DOCKERHOST=${DOCKERHOST} - RUST_LOG=${RUST_LOG} - TEST_POOL_IP=${TEST_POOL_IP} ports: - 3000:3000 depends_on: - pool networks: services: ipv4_address: 173.17.0.150 ``` to debug this container. And it looks like it work ``` Creating network "nodejs_services" with the default driver Creating nodejs_pool_1 ... done Creating nodejs_alice_1 ... done Creating nodejs_acme_1 ... done Creating nodejs_bob_1 ... done Creating nodejs_thrift_1 ... done Creating nodejs_faber_1 ... done Attaching to nodejs_pool_1, nodejs_alice_1, nodejs_acme_1, nodejs_faber_1, nodejs_bob_1, nodejs_thrift_1 pool_1 | 2019-01-27 04:16:56,711 CRIT Set uid to user 1000 alice_1 | Debugger listening on ws://127.0.0.1:9229/05557174-a3a2-4958-bffc-5eb276075832 alice_1 | For help see https://nodejs.org/en/docs/inspector ``` but it didnt show me any remote target in chrome (chrome://inspect/#devices) What could be the problem?

vijayanandsudhakar (Sun, 27 Jan 2019 16:14:21 GMT):
Has joined the channel.

vijayanandsudhakar (Mon, 28 Jan 2019 07:35:36 GMT):
Hi..i have a problem with credentials that do not match a predicate. In my test, i am trying to get proverFetchCredentialsForProofReq() to fail when i pass a predicate that does not satisfy any credential in the wallet, but i get back a valid credential. Following is the log - ---------------------------------------------------------------------------------------------------------------------------------------------------IndyPOC_1 | TRACE|indy::api::anoncreds | src/api/anoncreds.rs:1338| indy_prover_fetch_credentials_for_proof_req: >>> search_handle: 98, count: 100 IndyPOC_1 | TRACE|indy::api::anoncreds | src/api/anoncreds.rs:1343| indy_prover_fetch_credentials_for_proof_req: entities >>> search_handle: 98, count: 100 IndyPOC_1 | INFO|indy::commands | src/commands/mod.rs:114 | AnoncredsCommand command received IndyPOC_1 | INFO|anoncreds_command_executor | src/commands/anoncreds/mod.rs:54 | Prover command received IndyPOC_1 | INFO|prover_command_executor | src/commands/anoncreds/prover.rs:206 | FetchCredentialForProofReq command received IndyPOC_1 | TRACE|indy::commands::anoncreds::prover| src/commands/anoncreds/prover.rs:526 | fetch_credential_for_proof_request >>> search_handle: 98, item_referent: "predicate1_referent", count: 100 IndyPOC_1 | TRACE|indy::services::anoncreds::prover| src/services/anoncreds/prover.rs:266 | get_credential_values_for_attribute >>> credential_attrs: {"year": AttributeValues { raw: "2020", encoded: "1050048050048" }, "ssn": AttributeValues { raw: "123-45-6666", encoded: "1049050051045052053045054054054054" }, "first_name": AttributeValues { raw: "Alice", encoded: "1065108105099101" }, "average": AttributeValues { raw: "1.5", encoded: "1049046053" }, "degree": AttributeValues { raw: "Bachelor of Science, Marketing", encoded: "1066097099104101108111114032111102032083099105101110099101044032077097114107101116105110103" }, "last_name": AttributeValues { raw: "Garcia", encoded: "1071097114099105097" }, "status": AttributeValues { raw: "graduated", encoded: "1103114097100117097116101100" }}, requested_attr: "average" IndyPOC_1 | TRACE|indy::services::anoncreds::prover| src/services/anoncreds/prover.rs:272 | get_credential_values_for_attribute <<< res: Some(AttributeValues { raw: "1.5", encoded: "1049046053" }) IndyPOC_1 | TRACE|indy::services::anoncreds::prover| src/services/anoncreds/prover.rs:360 | attribute_satisfy_predicate >>> predicate: PredicateInfo { name: "average", p_type: GE, p_value: 4, restrictions: None, non_revoked: None }, attribute_value: "1049046053" IndyPOC_1 | TRACE|indy::services::anoncreds::prover| src/services/anoncreds/prover.rs:370 | attribute_satisfy_predicate <<< res: Ok(true) IndyPOC_1 | TRACE|indy::commands::anoncreds::prover| src/commands/anoncreds/prover.rs:540 | fetch_credential_for_proof_request <<< requested_credentials_json: "[{\"cred_info\":{\"referent\":\"e7d05cb7-76ee-4be6-929c-94ab372dda13\",\"attrs\":{\"ssn\":\"123-45-6666\",\"first_name\":\"Alice\",\"average\":\"1.5\",\"status\":\"graduated\",\"last_name\":\"Garcia\",\"year\":\"2020\",\"degree\":\"Bachelor of Science, Marketing\"},\"schema_id\":\"VBh5nLSiKS7RMqJwpZP6kY:2:Transcript:1.2\",\"cred_def_id\":\"S8G9uKJ8MhtiTuuiYCZ8oS:3:CL:14:TAG1\",\"rev_reg_id\":null,\"cred_rev_id\":null},\"interval\":null}]" IndyPOC_1 | TRACE|indy::api::anoncreds | src/api/anoncreds.rs:1354| indy_prover_fetch_credentials_for_proof_request: credentials_json: "[{\"cred_info\":{\"referent\":\"e7d05cb7-76ee-4be6-929c-94ab372dda13\",\"attrs\":{\"ssn\":\"123-45-6666\",\"first_name\":\"Alice\",\"average\":\"1.5\",\"status\":\"graduated\",\"last_name\":\"Garcia\",\"year\":\"2020\",\"degree\":\"Bachelor of Science, Marketing\"},\"schema_id\":\"VBh5nLSiKS7RMqJwpZP6kY:2:Transcript:1.2\",\"cred_def_id\":\"S8G9uKJ8MhtiTuuiYCZ8oS:3:CL:14:TAG1\",\"rev_reg_id\":null,\"cred_rev_id\":null},\"interval\":null}]" IndyPOC_1 | TRACE|indy::api::anoncreds | src/api/anoncreds.rs:1362| indy_prover_fetch_credentials_for_proof_req: <<< res: Success ------------------------------------------------------------------------------------------------------------------------------------------------------Any idea what is wrong? I am using indy-sdk 1.6.7

vijayanandsudhakar (Mon, 28 Jan 2019 07:35:36 GMT):
Hi..i have a problem with credentials that do not match a predicate. In my test, i am trying to get proverFetchCredentialsForProofReq() to fail when i pass a predicate that does not satisfy any credential in the wallet (average is 1.5 and predicate is average>=4), but i get back a valid credential. Following is the log - ---------------------------------------------------------------------------------------------------------------------------------------------------IndyPOC_1 | TRACE|indy::api::anoncreds | src/api/anoncreds.rs:1338| indy_prover_fetch_credentials_for_proof_req: >>> search_handle: 98, count: 100 IndyPOC_1 | TRACE|indy::api::anoncreds | src/api/anoncreds.rs:1343| indy_prover_fetch_credentials_for_proof_req: entities >>> search_handle: 98, count: 100 IndyPOC_1 | INFO|indy::commands | src/commands/mod.rs:114 | AnoncredsCommand command received IndyPOC_1 | INFO|anoncreds_command_executor | src/commands/anoncreds/mod.rs:54 | Prover command received IndyPOC_1 | INFO|prover_command_executor | src/commands/anoncreds/prover.rs:206 | FetchCredentialForProofReq command received IndyPOC_1 | TRACE|indy::commands::anoncreds::prover| src/commands/anoncreds/prover.rs:526 | fetch_credential_for_proof_request >>> search_handle: 98, item_referent: "predicate1_referent", count: 100 IndyPOC_1 | TRACE|indy::services::anoncreds::prover| src/services/anoncreds/prover.rs:266 | get_credential_values_for_attribute >>> credential_attrs: {"year": AttributeValues { raw: "2020", encoded: "1050048050048" }, "ssn": AttributeValues { raw: "123-45-6666", encoded: "1049050051045052053045054054054054" }, "first_name": AttributeValues { raw: "Alice", encoded: "1065108105099101" }, "average": AttributeValues { raw: "1.5", encoded: "1049046053" }, "degree": AttributeValues { raw: "Bachelor of Science, Marketing", encoded: "1066097099104101108111114032111102032083099105101110099101044032077097114107101116105110103" }, "last_name": AttributeValues { raw: "Garcia", encoded: "1071097114099105097" }, "status": AttributeValues { raw: "graduated", encoded: "1103114097100117097116101100" }}, requested_attr: "average" IndyPOC_1 | TRACE|indy::services::anoncreds::prover| src/services/anoncreds/prover.rs:272 | get_credential_values_for_attribute <<< res: Some(AttributeValues { raw: "1.5", encoded: "1049046053" }) IndyPOC_1 | TRACE|indy::services::anoncreds::prover| src/services/anoncreds/prover.rs:360 | attribute_satisfy_predicate >>> predicate: PredicateInfo { name: "average", p_type: GE, p_value: 4, restrictions: None, non_revoked: None }, attribute_value: "1049046053" IndyPOC_1 | TRACE|indy::services::anoncreds::prover| src/services/anoncreds/prover.rs:370 | attribute_satisfy_predicate <<< res: Ok(true) IndyPOC_1 | TRACE|indy::commands::anoncreds::prover| src/commands/anoncreds/prover.rs:540 | fetch_credential_for_proof_request <<< requested_credentials_json: "[{\"cred_info\":{\"referent\":\"e7d05cb7-76ee-4be6-929c-94ab372dda13\",\"attrs\":{\"ssn\":\"123-45-6666\",\"first_name\":\"Alice\",\"average\":\"1.5\",\"status\":\"graduated\",\"last_name\":\"Garcia\",\"year\":\"2020\",\"degree\":\"Bachelor of Science, Marketing\"},\"schema_id\":\"VBh5nLSiKS7RMqJwpZP6kY:2:Transcript:1.2\",\"cred_def_id\":\"S8G9uKJ8MhtiTuuiYCZ8oS:3:CL:14:TAG1\",\"rev_reg_id\":null,\"cred_rev_id\":null},\"interval\":null}]" IndyPOC_1 | TRACE|indy::api::anoncreds | src/api/anoncreds.rs:1354| indy_prover_fetch_credentials_for_proof_request: credentials_json: "[{\"cred_info\":{\"referent\":\"e7d05cb7-76ee-4be6-929c-94ab372dda13\",\"attrs\":{\"ssn\":\"123-45-6666\",\"first_name\":\"Alice\",\"average\":\"1.5\",\"status\":\"graduated\",\"last_name\":\"Garcia\",\"year\":\"2020\",\"degree\":\"Bachelor of Science, Marketing\"},\"schema_id\":\"VBh5nLSiKS7RMqJwpZP6kY:2:Transcript:1.2\",\"cred_def_id\":\"S8G9uKJ8MhtiTuuiYCZ8oS:3:CL:14:TAG1\",\"rev_reg_id\":null,\"cred_rev_id\":null},\"interval\":null}]" IndyPOC_1 | TRACE|indy::api::anoncreds | src/api/anoncreds.rs:1362| indy_prover_fetch_credentials_for_proof_req: <<< res: Success ------------------------------------------------------------------------------------------------------------------------------------------------------Any idea what is wrong? I am using indy-sdk 1.6.7

vijayanandsudhakar (Mon, 28 Jan 2019 08:56:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4E2jS43a3q7K2aKBC) @DuckLover Try adding the following to ports: - 3000:3000 -9229:9229

jakubkoci (Mon, 28 Jan 2019 09:09:28 GMT):
Morning, I've built an iOS app in React Native using Indy.Framework and I'm trying to upload it from Xcode to TestFlight, but I get this error: ERROR ITMS-90087: "Unsupported Architectures. The executable for IdentityWallet.app/Frameworks/Indy.framework contains unsupported architectures '[x86_64, i386]'." An unknown error occurred. Does anybody know how to solve this issue?

jakubkoci (Mon, 28 Jan 2019 10:32:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=8Z6hqQ4xrbDNqXoJL) Problem solved (by this http://ikennd.ac/blog/2015/02/stripping-unwanted-architectures-from-dynamic-libraries-in-xcode, if anyone would be insterested :))

AlexanderVtyurin (Mon, 28 Jan 2019 11:00:24 GMT):
@MattRaffel I'm able to run `nullpay_init()` on android. Something wrong with nullpay logger, so if you'll comment all logger-related code and pass this new lib to android - everything will be fine.

edisinovcic (Mon, 28 Jan 2019 13:31:01 GMT):
Has joined the channel.

smithbk (Mon, 28 Jan 2019 14:17:15 GMT):
Hi, how are others writing verifiers which want to look up a cred schema DID by name/version, as well as looking up cred def DIDs for a schema DID?

AlexanderVtyurin (Mon, 28 Jan 2019 15:11:56 GMT):
UPD: nevermind.

xnopre (Mon, 28 Jan 2019 15:58:28 GMT):
Hi all :-) . With `keyForDid` method, it is possible to get the key from a DID. Is it possible to retrieve, from the ledger, when and who has got the key for a specified DID ? My need is to retrieve which user or actor has got a key for a specific DID and when. Thanks :-)

MattRaffel (Mon, 28 Jan 2019 16:41:55 GMT):
@AlexanderVtyurin thanks. I've passed that over the someone that was looking at the issue.

jjensenevernym (Mon, 28 Jan 2019 23:13:04 GMT):
@haggs @Dubh3124 I was asking on behalf of a client and I don't have their code. The answer you've given that a pool handle may have been left open is all I need for now. Thank you for your help.

DuckLover (Tue, 29 Jan 2019 02:09:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=zkNpfotykyNcNQDPe) @vijayanandsudhakar "Port 9229 is already in use" exited with code 1 :thinking:

vijayanandsudhakar (Tue, 29 Jan 2019 07:15:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aK7JAygLSN9iLevZb) @DuckLover Can you try this - "node --inspect-brk=*0.0.0.0*:9229 ./bin/www". Also note that if you want to debug all agents (not only Alice), the PORT mapping should be different from each agent -``` version: '3' networks: services: ipam: config: - subnet: 173.17.0.0/24 services: # # Pool # pool: build: context: . dockerfile: indy-pool.dockerfile args: - pool_ip=173.17.0.100 ports: - 9701-9708:9701-9708 networks: services: ipv4_address: 173.17.0.100 # # Agents # alice: image: indy-agentjs build: context: . command: "bash -c 'npm start'" environment: - PORT=3000 - NAME=Alice - EMAIL=alice@faber.edu - PASSWORD=123 - USERNAME=alice - PUBLIC_DID_ENDPOINT=173.17.0.150:3000 - DOCKERHOST=${DOCKERHOST} - RUST_LOG=${RUST_LOG} - TEST_POOL_IP=${TEST_POOL_IP} ports: - 3000:3000 - 9229:9229 depends_on: - pool networks: services: ipv4_address: 173.17.0.150 # # bob: image: indy-agentjs command: "bash -c 'npm start'" environment: - PORT=3001 - NAME=Bob - EMAIL=bob@byu.edu - PASSWORD=123 - USERNAME=bob - PUBLIC_DID_ENDPOINT=173.17.0.160:3001 - DOCKERHOST=${DOCKERHOST} - RUST_LOG=${RUST_LOG} - TEST_POOL_IP=${TEST_POOL_IP} ports: - 3001:3001 - 9230:9229 depends_on: - pool - alice networks: services: ipv4_address: 173.17.0.160 faber: image: indy-agentjs command: "bash -c 'npm start'" environment: - PORT=3002 - NAME=Faber University - EMAIL=admin@faber.edu - PASSWORD=123 - USERNAME=faber - PUBLIC_DID_ENDPOINT=173.17.0.170:3002 - DOCKERHOST=${DOCKERHOST} - RUST_LOG=${RUST_LOG} - TEST_POOL_IP=${TEST_POOL_IP} ports: - 3002:3002 - 9231:9229 depends_on: - pool - alice networks: services: ipv4_address: 173.17.0.170 acme: image: indy-agentjs command: "bash -c 'npm start'" environment: - PORT=3003 - NAME=Acme Corporation - EMAIL=boss@acme.com - PASSWORD=123 - USERNAME=acme - PUBLIC_DID_ENDPOINT=173.17.0.180:3003 - DOCKERHOST=${DOCKERHOST} - RUST_LOG=${RUST_LOG} - TEST_POOL_IP=${TEST_POOL_IP} ports: - 3003:3003 - 9232:9229 depends_on: - pool - alice networks: services: ipv4_address: 173.17.0.180 thrift: image: indy-agentjs command: "bash -c 'npm start'" environment: - PORT=3004 - NAME=Thrift Bank - EMAIL=owner@thrift.com - PASSWORD=123 - USERNAME=thrift - PUBLIC_DID_ENDPOINT=173.17.0.190:3004 - DOCKERHOST=${DOCKERHOST} - RUST_LOG=${RUST_LOG} - TEST_POOL_IP=${TEST_POOL_IP} ports: - 3004:3004 - 9233:9229 depends_on: - pool - alice networks: services: ipv4_address: 173.17.0.190 ```

vijayanandsudhakar (Tue, 29 Jan 2019 07:15:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aK7JAygLSN9iLevZb) @DuckLover Can you try this - "node --inspect-brk=0.0.0.0:9229 ./bin/www". Also note that if you want to debug all agents (not only Alice), the PORT mapping should be different from each agent -``` version: '3' networks: services: ipam: config: - subnet: 173.17.0.0/24 services: # # Pool # pool: build: context: . dockerfile: indy-pool.dockerfile args: - pool_ip=173.17.0.100 ports: - 9701-9708:9701-9708 networks: services: ipv4_address: 173.17.0.100 # # Agents # alice: image: indy-agentjs build: context: . command: "bash -c 'npm start'" environment: - PORT=3000 - NAME=Alice - EMAIL=alice@faber.edu - PASSWORD=123 - USERNAME=alice - PUBLIC_DID_ENDPOINT=173.17.0.150:3000 - DOCKERHOST=${DOCKERHOST} - RUST_LOG=${RUST_LOG} - TEST_POOL_IP=${TEST_POOL_IP} ports: - 3000:3000 - 9229:9229 depends_on: - pool networks: services: ipv4_address: 173.17.0.150 # # bob: image: indy-agentjs command: "bash -c 'npm start'" environment: - PORT=3001 - NAME=Bob - EMAIL=bob@byu.edu - PASSWORD=123 - USERNAME=bob - PUBLIC_DID_ENDPOINT=173.17.0.160:3001 - DOCKERHOST=${DOCKERHOST} - RUST_LOG=${RUST_LOG} - TEST_POOL_IP=${TEST_POOL_IP} ports: - 3001:3001 - 9230:9229 depends_on: - pool - alice networks: services: ipv4_address: 173.17.0.160 faber: image: indy-agentjs command: "bash -c 'npm start'" environment: - PORT=3002 - NAME=Faber University - EMAIL=admin@faber.edu - PASSWORD=123 - USERNAME=faber - PUBLIC_DID_ENDPOINT=173.17.0.170:3002 - DOCKERHOST=${DOCKERHOST} - RUST_LOG=${RUST_LOG} - TEST_POOL_IP=${TEST_POOL_IP} ports: - 3002:3002 - 9231:9229 depends_on: - pool - alice networks: services: ipv4_address: 173.17.0.170 acme: image: indy-agentjs command: "bash -c 'npm start'" environment: - PORT=3003 - NAME=Acme Corporation - EMAIL=boss@acme.com - PASSWORD=123 - USERNAME=acme - PUBLIC_DID_ENDPOINT=173.17.0.180:3003 - DOCKERHOST=${DOCKERHOST} - RUST_LOG=${RUST_LOG} - TEST_POOL_IP=${TEST_POOL_IP} ports: - 3003:3003 - 9232:9229 depends_on: - pool - alice networks: services: ipv4_address: 173.17.0.180 thrift: image: indy-agentjs command: "bash -c 'npm start'" environment: - PORT=3004 - NAME=Thrift Bank - EMAIL=owner@thrift.com - PASSWORD=123 - USERNAME=thrift - PUBLIC_DID_ENDPOINT=173.17.0.190:3004 - DOCKERHOST=${DOCKERHOST} - RUST_LOG=${RUST_LOG} - TEST_POOL_IP=${TEST_POOL_IP} ports: - 3004:3004 - 9233:9229 depends_on: - pool - alice networks: services: ipv4_address: 173.17.0.190 ```

xnopre (Tue, 29 Jan 2019 10:58:59 GMT):
Hi all. With Indy, Alice and Bob can exchange crypted data with `cryptoAuthCrypt / cryptoAuthDecrypt`. I'm searching a solution so that Bob will store the crypted data, and decrypt this data when needed. But I want a solution for Alice to block this decryption. My idea is to do a key rotation for Alice, but the `cryptoAuthDecrypt` method has only the Bob verkey as parameter. Is there a solution for this need ? Is this the good way (key rotation) ? Thanks for you help :-)

xnopre (Tue, 29 Jan 2019 13:46:17 GMT):
Other point. I'm "dockering" `indy-sdk/vcx/wrappers/python3/demo` :-) , I will do a Pull Request to share it :-) . I need a "libindy" docker image, I find inspiration in the file `vcx/ci/libindy.dockerfile`, but in this file, there are this lines : ``` add-apt-repository 'deb https://repo.corp.evernym.com/deb evernym-agency-dev-ubuntu main' && \ curl https://repo.corp.evernym.com/repo.corp.evenym.com-sig.key | apt-key add -``` This does not work because `repo.corp.evernym.com` is unreachable from my computer. What are the utility of this lines ? How can this repo be reachable ? (if it is an internal repo, unreachable from internet, it is a little surprising for an open source project.... :thinking: )

tomislav (Tue, 29 Jan 2019 14:03:39 GMT):
Decryption is done off ledger, Alice can't impact Bob's decryption, once Bob got his message, since decryption uses Bob's key, not Alice's.

tomislav (Tue, 29 Jan 2019 14:05:03 GMT):
Here's a docker with libindy and dotnet. Simply remove the dotnet section. https://github.com/streetcred-id/docker/blob/master/dotnet-indy.dockerfile

xnopre (Tue, 29 Jan 2019 14:13:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=w25NJtXgBAZrmeBxt) @tomislav Thank you for your answer ! :-) OK, but `cryptoAuthCrypt` attempt the 2 keys, Alice's and Bob's key. What is the use of Alice's key in AuthCrypt ? And is there a solution for my need : allow Alice to block decryption by Bob ?

sklump (Tue, 29 Jan 2019 15:17:57 GMT):
Question: how do I update a pairwise did/verkey association in a wallet? I can call `did.store_their_did()` to set one in the first place. Now suppose the other party rekeys and I want to update the association in my wallet, or else I just fat-fingered it somehow. Calling it again with a new identify using the same DID but a new verkey raises a uniqueness exception as expected, but I don't see a way to delete or overwrite such an association. Anyone?

sklump (Tue, 29 Jan 2019 15:17:57 GMT):
*Question:* how do I update a pairwise did/verkey association in a wallet? I can call `did.store_their_did()` to set one in the first place. Now suppose the other party rekeys and I want to update the association in my wallet, or else I just fat-fingered it somehow. Calling it again with a new identify using the same DID but a new verkey raises a uniqueness exception as expected, but I don't see a way to delete or overwrite such an association. If I have 50 foreign DIDs in my wallet and I have to update one, surely I don't have to start a new wallet _(terrible solution)_ ? Anyone?

sklump (Tue, 29 Jan 2019 15:25:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=bv9wLsC3CiEaYHdLq) @xnopre Alice's key provides proof of origin to Bob (defeating man-in-the-middle). There is no way to stop Bob from decrypting a message encrypted for his public key.

sklump (Tue, 29 Jan 2019 15:25:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=bv9wLsC3CiEaYHdLq) @xnopre Alice's key provides proof of origin to Bob (it's the auth in authcrypt). There is no way to stop Bob from decrypting a message encrypted for his public key.

theoturner (Tue, 29 Jan 2019 15:27:39 GMT):
Has joined the channel.

tomislav (Tue, 29 Jan 2019 15:45:47 GMT):
@sklump, good question. How does one update their key? Calling store_their_did twice currently throws.

sklump (Tue, 29 Jan 2019 15:47:06 GMT):
@tomislav, if we could delete remote keys (and pairwise dids too), that would be a workaround. Should I write up a JIRA or maybe I am missing the obvious?

tomislav (Tue, 29 Jan 2019 15:48:39 GMT):
There's no API to delete keys (or pairwise), that would solve the problem.

tomislav (Tue, 29 Jan 2019 15:50:58 GMT):
Pairwise seems to be superseded by nonsecrets, which has full support for update/delete. In our framework we use a custom nonsecrets type to make associations (in addition to pairwise), but pairwise doesn't seem to be tied to the rest of libindy

xnopre (Tue, 29 Jan 2019 15:51:26 GMT):
I have "dockerized" `indy-sdk/vcx/wrappers/python3/demo`, it's running ! :-) BUT... it's OK on `rc` branch, not on `master` branch. I have this error running `cargo run config.json` : ```Compiling indy v1.7.0 (/home/vcx/wrappers/rust) ... error: linking with `cc` failed: exit code: 1 = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/vcx/.rustup/t[.....] ... = note: /home/vcx/intermediate/dummy-cloud-agent/target/debug/deps/libindyrs-f9413e02a815ca86.rlib(indyrs-f9413e02a815ca86.alq2xjclm8qt6g5.rcgu.o): In function `indyrs::IndyError::new::h108b5a8fce09c47a': /home/vcx/wrappers/rust/src/lib.rs:339: undefined reference to `indy_get_current_error' collect2: error: ld returned 1 exit status``` It seems to me that the `indy_get_current_error` function is new, to have more details in errors. Who can help me ? Thanks

sklump (Tue, 29 Jan 2019 15:56:32 GMT):
@tomislav if pairwise is obsolete then it oughtn't be in the API. I thought pairwise generated a new DID structure, and some kind of metadata deep in the wallet, given a remote DID with a verification key in the wallet? Or is it just a spot to store remote DIDs? In short, can I use non_secrets to do whatever pairwise does?

sklump (Tue, 29 Jan 2019 15:56:32 GMT):
@tomislav if pairwise is obsolete then it oughtn't be in the API. I thought pairwise generated a new DID structure, and some kind of metadata deep in the wallet, given a remote DID with a verification key already stored in the wallet? Or is it just a spot to store remote DIDs? In short, can I use non_secrets to do whatever pairwise does?

swcurran (Tue, 29 Jan 2019 15:57:48 GMT):
@TelegramSam Any inputs into the pairwise discussion above? Can you summarize what VCX and/or indy-agent/python is doing?

tomislav (Tue, 29 Jan 2019 15:59:41 GMT):
@sklump pairwise is just a custom type with id=mydid and value=theirdid. You can definitely use a custom type instead pairwise, and the rest of libindy API wouldn't care or be impacted. Pairwise is an agent concept.

TelegramSam (Tue, 29 Jan 2019 16:02:42 GMT):
@sklump there are a few gaps in indysdk to allow for peer DID maintenance, and storing a new key for another's DID is one of them.

sklump (Tue, 29 Jan 2019 16:02:46 GMT):
@tomislav thanks, since there is a way to update/delete non_secrets, I have a way forward.

TelegramSam (Tue, 29 Jan 2019 16:03:22 GMT):
Writing up a ticket for this feature is a great idea.

TelegramSam (Tue, 29 Jan 2019 16:03:51 GMT):
We can get around it in the short term with non-secrets, but this will be neither standard or desirable in the long term.

tomislav (Tue, 29 Jan 2019 16:04:11 GMT):
@sklump I just looked into the code, while we call storing pairwise, we don't ever resolve using it, instead use the custom type, and I haven't noticed it until you just mentioned

tomislav (Tue, 29 Jan 2019 16:05:05 GMT):
Definitely, would be great to at least add support for updating their key

sklump (Tue, 29 Jan 2019 16:05:39 GMT):
Au contraire, if pairwise is a subset of non-secrets, why not just get rid of it? It's cost me 3/4 of a day and it's about to cost @tomislav's group more time, and provides no net new amenity. Keep in mind I may have no idea what I'm talking about here.

TelegramSam (Tue, 29 Jan 2019 16:07:07 GMT):
I believe the intent of pairwise goes beyond it's current feature set. Raising the issue with the SDK team will start the right conversation.

tomislav (Tue, 29 Jan 2019 16:07:11 GMT):
Pairwise has been around since the beginning, it's what the trust model in indy/sovrin is based on, so it's an "identity" feature.

sklump (Tue, 29 Jan 2019 16:08:48 GMT):
It's become a "crippled" feature since we could reseed, and nobody even noticed. I will put a JIRA on my list of things, but it is going to come later.

theoturner (Tue, 29 Jan 2019 16:09:09 GMT):
Hi all, i'm running the python wrapper with a pool of local nodes. Everything seems to run fine, but one of the tests for the wrapper fails with Indy error `unauthorizedClientRequest(actor must be owner)` Specifically this line: https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/tests/anoncreds/conftest.py#L51 with a StopIteration Everything seems to run ok otherwise, just thought I'd report.

xnopre (Tue, 29 Jan 2019 16:11:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=NPgxBtQNbeev4ZN3L) I think I have found a way... My docker image contains libindy:1.7.0 from public repo, I think I have to rebuild the `libindy` with current sources... :-/ ... I go to try...

DuckLover (Tue, 29 Jan 2019 16:45:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=GeFCKz6S63gMF7sQr) @vijayanandsudhakar I tried this and it seems like the agent dont start at all. Also the endpoint for debugging is not reachable. Here the docker-compose.yml for Bob (or Alice, i tried it now with Bob) ``` bob: image: indy-agentjs command: "bash -c 'node --inspect-brk=0.0.0.0:9229 ./bin/www'" environment: - PORT=3001 - NAME=Bob - ADDRESS=Indystreet 123 - DAY_OF_BIRTH=11.11.1990 - PASSWORD=123 - USERNAME=bob - PUBLIC_DID_ENDPOINT=173.17.0.160:3001 - DOCKERHOST=${DOCKERHOST} - RUST_LOG=${RUST_LOG} - TEST_POOL_IP=${TEST_POOL_IP} ports: - 3001:3001 - 9229:9229 depends_on: - pool - alice networks: services: ipv4_address: 173.17.0.160 ```

firewater (Tue, 29 Jan 2019 16:47:43 GMT):
anyone successfully build indy-sdk inside ubuntu 18.0.4?

firewater (Tue, 29 Jan 2019 16:47:43 GMT):
anyone successfully build indy-sdk in ubuntu 18.0.4?

sklump (Tue, 29 Jan 2019 16:48:41 GMT):
@firewater only ubuntu 16 is supported.

firewater (Tue, 29 Jan 2019 16:49:12 GMT):
i see.

firewater (Tue, 29 Jan 2019 16:50:09 GMT):
how can i remove a did in a wallet?

firewater (Tue, 29 Jan 2019 16:50:41 GMT):
i am thinking that sdk.deleteWalletRecord can acheive that

firewater (Tue, 29 Jan 2019 16:50:50 GMT):
but not sure whats the proper peram to pass in

firewater (Tue, 29 Jan 2019 16:50:50 GMT):
but not sure whats the proper param to pass in

firewater (Tue, 29 Jan 2019 16:52:05 GMT):
my use case is to delete ununused did from wallet (eg no connection established) after a period of time.

firewater (Tue, 29 Jan 2019 16:52:05 GMT):
my use case is to delete ununused did from wallet (eg did that is created but no connection established) after a period of time.

firewater (Tue, 29 Jan 2019 16:52:09 GMT):
not sure if there are such feature

AlexanderVtyurin (Tue, 29 Jan 2019 16:53:29 GMT):
@firewater `rm -r ~/.indy_client` will erase all your wallets completely. That's all I got. Look through this directory, maybe you'll find something useful.

firewater (Tue, 29 Jan 2019 16:54:19 GMT):
i only want to delete certain did record from wallet by id after search filter by metadata

firewater (Tue, 29 Jan 2019 16:54:27 GMT):
not to remove entire wallet with linux command

sklump (Tue, 29 Jan 2019 16:55:00 GMT):
@firewater you will have to kludge around it with metadata, store some kind of 'deleted' indicator.

firewater (Tue, 29 Jan 2019 16:55:28 GMT):
@sklump so u mean i actually can't erase the did from wallet??

firewater (Tue, 29 Jan 2019 16:55:49 GMT):
only can put a delete flag on that in metadata?

sklump (Tue, 29 Jan 2019 16:56:25 GMT):
Correct

firewater (Tue, 29 Jan 2019 16:57:10 GMT):
so the deleteWalletRecord sdk is only able to used for delte wallet record that is created by addWalletRecord?

sklump (Tue, 29 Jan 2019 17:03:11 GMT):
These are non_secrets API calls, not for keyed info such as verification keys, cred defs, etc

sklump (Tue, 29 Jan 2019 17:03:11 GMT):
These are non_secrets API calls, not for keyed info such as credentials, cred defs, etc

sklump (Tue, 29 Jan 2019 17:12:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4AmodysCWkwauMWtA) Why is id=mydid necessary? In the wallet, of course our side of the relationship will be our own DID - would it be wrong to use id=their_did, value=verkey ?

sklump (Tue, 29 Jan 2019 17:12:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4AmodysCWkwauMWtA) @tomislav Why is id=mydid necessary? In the wallet, of course our side of the relationship will be our own DID - would it be wrong to use id=their_did, value=verkey ?

tomislav (Tue, 29 Jan 2019 17:43:35 GMT):
@sklump I was just giving example. You're right, pairwise uses theirDid for the id. You can use an entirely new identifier even, something that makes sense for the business model. We generate a guid for the Id and have my and their did as value (in a json object)

tomislav (Tue, 29 Jan 2019 17:44:54 GMT):
The unique key in nonsecrets is the (id, type)

tomislav (Tue, 29 Jan 2019 17:46:08 GMT):
Actually,we store the did's as tags, so we can search for them

Dubh3124 (Tue, 29 Jan 2019 20:15:44 GMT):
Yeah same here, I use the wallet storage for all things DID or id related (i.e schema_id, cred_def_id, master_secret_id).

firewater (Wed, 30 Jan 2019 05:12:18 GMT):
where should i stored the nonce of a connection request initiated? in the wallet storage?

firewater (Wed, 30 Jan 2019 05:12:18 GMT):
where should i stored the nonce of a connection request initiated so that i could keep track of it? in the wallet storage?

xnopre (Wed, 30 Jan 2019 08:52:40 GMT):
Hi all. Trying to run `x`, I have this error : `/usr/bin/ld: cannot find -lindy`. I'm trying to dockerize `indy-sdk/vcx/wrappers/python3/demo` on `master` branch, so I cannot (apt) install `libindy`. I have build `libindy` from source, I have copied the `target/debug` content in a `/home/vcx/lib` directory, I have set `LD_LIBRARY_PATH:/home/vcx/lib` ... What is missing or what is wrong ? Thanks for your help :-)

xnopre (Wed, 30 Jan 2019 08:52:40 GMT):
Hi all. Trying to run `dummy-cloud-agent`, I have this error : `/usr/bin/ld: cannot find -lindy`. I'm trying to dockerize `indy-sdk/vcx/wrappers/python3/demo` on `master` branch, so I cannot (apt) install `libindy`. I have build `libindy` from source, I have copied the `target/debug` content in a `/home/vcx/lib` directory, I have set `LD_LIBRARY_PATH:/home/vcx/lib` ... What is missing or what is wrong ? Thanks for your help :-)

kdenhartog (Wed, 30 Jan 2019 09:26:23 GMT):
@xnopre along with the `LD_LIBRARY_PATH` var, try doing this ``` Create the file /etc/ld.so.conf.d/indy.conf with the path "path/to/indy-sdk/libindy/target/debug" (replace with your path) run sudo ldconfig ```

kdenhartog (Wed, 30 Jan 2019 09:26:23 GMT):
@xnopre along with the `LD_LIBRARY_PATH` var, try doing this ``` 1. go to indy-sdk and run `cargo build` inside libindy 2. Create the file /etc/ld.so.conf.d/indy.conf with the path "path/to/indy-sdk/libindy/target/debug" (replace with your path) 3. run sudo ldconfig ```

xnopre (Wed, 30 Jan 2019 10:26:54 GMT):
@kdenhartog Thank you for your message and your help. Unfortunately, it doesn't work... :-( ... My configuration seems to be OK, running `ldconfig -p | grep indy` I have this ouuput `libindy.so (libc6,x86-64) => /home/vcx/libindy/libindy.so`, so the lib is found and stored in cache, but I still have `note: /usr/bin/ld: cannot find -lindy`... :-( ... It work if `libindy` is installed with apt-get, but I have to run with current `master` branch, so I cannot do this install, I have to run with my own build `libindy`.... Any other idea ?

xnopre (Wed, 30 Jan 2019 10:26:54 GMT):
@kdenhartog Thank you for your message and your help. Unfortunately, it doesn't work... :-( ... My configuration seems to be OK, running `ldconfig -p | grep indy` I have this ouuput `libindy.so (libc6,x86-64) => /home/vcx/libindy/libindy.so`, so the lib is found and stored in cache, but I still have `note: /usr/bin/ld: cannot find -lindy`... :-( ... It works if `libindy` is installed with apt-get, but I have to run with current `master` branch, so I cannot do this install, I have to run with my own build `libindy`.... Any other idea ?

xnopre (Wed, 30 Jan 2019 10:37:15 GMT):
If I do `apt-get install libindy=1.7.0` , I have this error `/home/vcx/wrappers/rust/src/lib.rs:339: undefined reference to `indy_get_current_error'` (which is normal because sources have changed, and libindy:1.7.0 is no more up to date with current sources... But it shows that the `indy` is found by `cargo run` . So what is the problem trying to install my own libindy build from current sources ? Can the problem be with another depending lib ? ... cc @kdenhartog

sklump (Wed, 30 Jan 2019 13:27:12 GMT):
*Question* re: non-secrets WQL query by pattern match? WQL spec https://github.com/hyperledger/indy-sdk/tree/master/doc/design/011-wallet-query-language cites non-secrets explicitly and specifies '$like', but indy-sdk doc https://docs.rs/indy/1.7.0/indyrs/wallet/fn.open_wallet_search.html specifies '$regex'. Does WQL support regex matching? Thanks.

sklump (Wed, 30 Jan 2019 13:27:12 GMT):
*Question* re: non-secrets WQL query by pattern match? WQL spec https://github.com/hyperledger/indy-sdk/tree/master/doc/design/011-wallet-query-language cites non-secrets explicitly and specifies `$like`, but indy-sdk doc https://docs.rs/indy/1.7.0/indyrs/wallet/fn.open_wallet_search.html specifies `$regex`. Does WQL support regex matching for the non-secrets API? Thanks.

tomislav (Wed, 30 Jan 2019 13:41:23 GMT):
There's unit tests for all operators except $regex - https://github.com/hyperledger/indy-sdk/blob/8eecce436b20d0fcd247c982aa4f49c98160c28f/libindy/tests/non_secrets.rs#L735

sklump (Wed, 30 Jan 2019 14:02:47 GMT):
OK, I will try it and see

sklump (Wed, 30 Jan 2019 14:08:09 GMT):
... nope: Unknown operator '$regex'. Too bad.

tomislav (Wed, 30 Jan 2019 15:09:31 GMT):
How cool would it be to also support embedded scripting language, too! `"$gluon": "let func x = x <* spaces"`

sklump (Wed, 30 Jan 2019 16:19:13 GMT):
If you can't get it in regex, you need to study more regex.

sklump (Wed, 30 Jan 2019 16:19:13 GMT):
If you can't get it in regex, you need to study more regex. It's like when a friend mused, "what's the next level after chess?"; my answer, "better chess".

sklump (Wed, 30 Jan 2019 16:19:13 GMT):
If one can't get it in regex, one needs to study more regex. It's like when a friend mused, "what's the next level after chess?"; my answer, "better chess".

kdenhartog (Wed, 30 Jan 2019 19:16:49 GMT):
@xnopre try running `cargo clean` and `cargo update` before `cargo build`

mwherman2000 (Thu, 31 Jan 2019 02:22:18 GMT):
Why does `did.create_and_store_my_did()` not return a syntactically valid DID (i.e. with the `did:` schema and some sort of `mymethod:`). Code reference: https://github.com/kdenhartog/indy-dev/blob/20eb31e03dbe7ff7d01c04241acf41b8c7ca03ce/python/getting_started.py#L53 What you get back (for this specific call) is: ``` INFO:__main__:1.0.2 "Sovrin Steward" -> Create and store in Wallet DID from seed Sovrin Steward DID: Th7MpTaRZVRYnPiabds81Y ``` I would expect there to be some sort of config settings or something in the Indy SDK/API that lets me state that the "domain" (my terminology) for all DIDs in this app is (for example): `did:mymethod:`.

mwherman2000 (Thu, 31 Jan 2019 02:22:18 GMT):
Why does `did.create_and_store_my_did()` not return a syntactically valid DID (i.e. with the `did:` schema and some sort of `mymethod:`)? Code reference: https://github.com/kdenhartog/indy-dev/blob/20eb31e03dbe7ff7d01c04241acf41b8c7ca03ce/python/getting_started.py#L53 What you get back (for this specific call) is: ``` INFO:__main__:1.0.2 "Sovrin Steward" -> Create and store in Wallet DID from seed Sovrin Steward DID: Th7MpTaRZVRYnPiabds81Y ``` I would expect there to be some sort of config settings or something in the Indy SDK/API that lets me state that the "domain" (my terminology) for all DIDs in this app is (for example): `did:mymethod:`.

mwherman2000 (Thu, 31 Jan 2019 02:22:18 GMT):
Why does `did.create_and_store_my_did()` not return a syntactically valid DID (i.e. with the `did:` schema and some sort of `mymethod:`)? Code reference: https://github.com/kdenhartog/indy-dev/blob/20eb31e03dbe7ff7d01c04241acf41b8c7ca03ce/python/getting_started.py#L53 What you get back (for this specific call) is: ``` INFO:__main__:1.0.2 "Sovrin Steward" -> Create and store in Wallet DID from seed Sovrin Steward DID: Th7MpTaRZVRYnPiabds81Y ``` I would expect there to be some sort of config settings or something in the Indy SDK/API that lets me state that the "domain" (my terminology) for all DIDs in this app is (for example): `did:mymethod:` ...or something like that.

mwherman2000 (Thu, 31 Jan 2019 02:22:18 GMT):
Why does `did.create_and_store_my_did()` not return a syntactically valid DID (i.e. with the `did:` schema and some sort of `mymethod:`)? Code reference: https://github.com/mwherman2000/indy-dev/blob/master/python/getting_started-verbose.py#L54 What you get back (for this specific call) is: ``` INFO:__main__:1.0.2 "Sovrin Steward" -> Create and store in Wallet DID from seed Sovrin Steward DID: Th7MpTaRZVRYnPiabds81Y ``` I would expect there to be some sort of config settings or something in the Indy SDK/API that lets me state that the "domain" (my terminology) for all DIDs in this app is (for example): `did:mymethod:` ...or something like that.

mwherman2000 (Thu, 31 Jan 2019 02:22:18 GMT):
Why does `did.create_and_store_my_did()` not return a syntactically valid DID (i.e. prefixed the `did:` schema and some sort of `mymethod:`)? Code reference: https://github.com/mwherman2000/indy-dev/blob/master/python/getting_started-verbose.py#L54 What you get back (for this specific call) is: ``` INFO:__main__:1.0.2 "Sovrin Steward" -> Create and store in Wallet DID from seed Sovrin Steward DID: Th7MpTaRZVRYnPiabds81Y ``` I would expect there to be some sort of config settings or something in the Indy SDK/API that lets me state that the "domain" (my terminology) for all DIDs in this app is (for example): `did:mymethod:` ...or something like that.

mwherman2000 (Thu, 31 Jan 2019 02:22:18 GMT):
Why does `did.create_and_store_my_did()` not return a syntactically valid DID (i.e. prefixed the `did:` schema and some sort of `mymethod:`)? Code reference: https://github.com/mwherman2000/indy-dev/blob/master/python/getting_started-verbose.py#L54 What you get back (for this specific call) is: ``` INFO:__main__:1.0.2 "Sovrin Steward" -> Create and store in Wallet DID from seed Sovrin Steward DID: Th7MpTaRZVRYnPiabds81Y ``` I would expect there to be some sort of config settings or something in the Indy SDK/API that lets me state that the "domain" (my terminology) for all DIDs created this app is (for example): `did:mymethod:` ...or something like that.

dbluhm (Thu, 31 Jan 2019 05:01:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jLGjjr7WTtcnusWFc) @mwherman2000 I've wondered the same thing...

haardikkk (Thu, 31 Jan 2019 05:06:02 GMT):
Has joined the channel.

haardikkk (Thu, 31 Jan 2019 05:06:50 GMT):
hey guys, coming over from Fabric to Indy here -- have a high level understanding as I went through the CLI Alice tutorial and saw the BC-Gov video of doing the same using webpages

haardikkk (Thu, 31 Jan 2019 05:07:40 GMT):
Question: How do I set up an Indy network on the cloud? Can I just create new Agents willy-nilly as well from code through sort of an 'Admin' client? Finally, is there a Golang SDK?

haardikkk (Thu, 31 Jan 2019 05:21:42 GMT):
Also, it looks like Sovrin would require individual organizations aiming to become Agents to be a Steward? My company is looking to build a network to help some of our partners share information across each other and to their end consumers, would it be us registering on Sovrin or would it be our partners individually registering on Sovrin?

SergeyBrazhnik (Thu, 31 Jan 2019 07:34:28 GMT):
Hello everyone. Does anybody know if indy support any additional predicates except GREATER and EQUALS when creating proof request?

sklump (Thu, 31 Jan 2019 13:27:32 GMT):
@SergeyBrazhnik At present indy-sdk supports only GE (>=). Support for the remaining inequality predicates is in discussion, but it would break the current proof request structure and so it has to wait for a protocol update (?) or at least some deep digging and restructuring of existing code.

SergeyBrazhnik (Thu, 31 Jan 2019 14:38:54 GMT):
@sklump Thanks for replay

xnopre (Thu, 31 Jan 2019 15:10:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=bLRxdwJvuy2A2SsvY) @kdenhartog @kdenhartog Thanks for you answer. The problem is (was... ;-) ) to find where to put the libindy.so and/or do some settings so that the cargo build can find it. It seems that the solution is using `LIBRARY_PATH`. And then, I had some errors because some dependencies were missing, but I found the list of dependencies (`libssl1.0.0, libsqlite0, libzmq5, build-essential`), and I have install them in Docker image. That seems to work, I'm doing some tests, and if OK, I will put that in a new PR ;-)

swcurran (Thu, 31 Jan 2019 15:44:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jLGjjr7WTtcnusWFc) @mwherman2000 I believe the answer to this is that indy-sdk does not provide full DID doc support and that what you are looking for will happen when that occurs. What has been done was a change in the naming of that entity you are talking about from "nym" in the original indy code to "did". This was intended to reduce confusion on the intention of the identifier.

mwherman2000 (Thu, 31 Jan 2019 15:54:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=pQ5yRmiooMXexqaxa) @swcurran The https://github.com/mwherman2000/indy-dev/blob/master/python/getting_started-verbose.py script has nothing to do with/does use DID Documents. It's an implementation of the the plain old _Alice buys a car_ scenario. My question still stands (separate from whether the indy-sdk supports DID Documents or not): Why does `did.create_and_store_my_did()` not return a syntactically valid DID (i.e. prefixed the `did:` schema and some sort of `mymethod:`)?

mwherman2000 (Thu, 31 Jan 2019 15:54:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=pQ5yRmiooMXexqaxa) @swcurran The https://github.com/mwherman2000/indy-dev/blob/master/python/getting_started-verbose.py script has nothing to do with/does _not_ use DID Documents. It's an implementation of the the plain old _Alice buys a car_ scenario. My question still stands (separate from whether the indy-sdk supports DID Documents or not): Why does `did.create_and_store_my_did()` not return a syntactically valid DID (i.e. prefixed the `did:` schema and some sort of `mymethod:`)?

mwherman2000 (Thu, 31 Jan 2019 15:58:11 GMT):
@swcurran RE: _This was intended to reduce confusion on the intention of the identifier._ For developers, this actually makes it more confusing when a method is supposed to return a DID and it doesn't/

mwherman2000 (Thu, 31 Jan 2019 15:58:11 GMT):
@swcurran RE: _This was intended to reduce confusion on the intention of the identifier._ For developers, this actually makes it more confuding when a method is supposed to return a DID and it doesn't.

haggs (Thu, 31 Jan 2019 16:03:21 GMT):
Thanks for that clarification @swcurran

haggs (Thu, 31 Jan 2019 16:03:21 GMT):
Thanks for that clarification @swcurran!

ianco (Thu, 31 Jan 2019 16:17:53 GMT):
VCX question - in the python Alice/Faber demo, it looks like the messages aren't getting cleared off the queue when they are read (?) I.e. when Faber sends Alice a credential offer, Alice calls "offers = await Credential.get_offers(my_connection)" to get the offer (and then process it). However if Alice makes the same call a second time (or later on, to see if there are any more credential offers available) then the same (original) message is there. So currently Alice has to keep track of any processed offers so they are not processed a second time (?) Also if Faber subsequently calls "Credential.get_offers(my_connection)" with their own connection (to see if anyone is offering credentials to Faber) then I get an error (looks like Faber is trying to read the message intended for Alice?) Check for and handle offers src/messages/mod.rs:123 | could not deserialize bundle with i8, will try u8 src/utils/libindy/error_codes.rs:24 | indy-sdk error code: 113 src/api/credential.rs:319 | vcx_credential_get_offers_cb(command_handle: 64, rc: This Credential Error had a value: 1080, msg: null) Traceback (most recent call last): File "faber-pg.py", line 156, in loop.run_until_complete(main()) File "/usr/local/Cellar/python/3.7.1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/asyncio/base_events.py", line 573, in run_until_complete return future.result() File "faber-pg.py", line 140, in main await handle_messages(my_connection, handled_offers, handled_requests) File "/Users/icostanzo/Projects/indy-sdk/vcx/wrappers/python3/demo/demo_utils.py", line 124, in handle_messages offers = await Credential.get_offers(my_connection) File "/Users/icostanzo/Projects/indy-sdk/vcx/wrappers/python3/vcx/api/credential.py", line 144, in get_offers Credential.get_offers.cb) vcx.error.VcxError: ErrorCode.LibindyInvalidStructure Note - example code is in the PR https://github.com/hyperledger/indy-sdk/pull/1446/files#diff-1cf91bc1e1f616bd97ef154e6a8f8ea4R142

mwherman2000 (Thu, 31 Jan 2019 17:12:38 GMT):
RE: _Why does `did.create_and_store_my_did()` not return a syntactically valid DID (i.e. prefixed the `did:` schema and some sort of `mymethod:`)?_ I tried adding in the following helper method... ``` async def create_and_store_my_valid_did(wallet, did_info): (idstring, key) = await did.create_and_store_my_did(wallet, did_info) valid_did = "did:mymethod:" + idstring return valid_did, key ``` It works when called but then `send_nym()` breaks when a valid DID is passed as an argument. I guess the ledger methods aren't draft DID spec compatible? ...here's the output... ``` INFO:__main__:1.1.1 "Sovrin Steward" -> Create and store in Wallet "Sovrin Steward Government" DID (from to) Create and store DID from DID: did:mymethod:Th7MpTaRZVRYnPiabds81Y Create and store DID from_to DID: did:mymethod:3aWJkKv4674RepeUVpD9Ka INFO:__main__:1.1.2 "Sovrin Steward" -> Send NYM for "Sovrin Steward Government" DID (from to) to Ledger WARNING:indy.libindy:_indy_loop_callback: Function returned error 113 Traceback (most recent call last): File "getting_started-verbose.py", line 962, in run_coroutine(run) File "/indy-dev/python/src/utils.py", line 47, in run_coroutine loop.run_until_complete(coroutine()) File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in run_until_complete return future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception File "/usr/lib/python3.5/asyncio/tasks.py", line 241, in _step result = coro.throw(exc) File "getting_started-verbose.py", line 65, in run "Government", None, government_wallet_config, government_wallet_credentials) File "getting_started-verbose.py", line 788, in onboarding await send_nym(pool_handle, from_wallet, from_did, from_to_did, from_to_key, None) File "getting_started-verbose.py", line 875, in send_nym nym_request = await ledger.build_nym_request(_did, new_did, new_key, None, role) File "/usr/local/lib/python3.5/dist-packages/indy/ledger.py", line 294, in build_nym_request build_nym_request.cb) File "/usr/lib/python3.5/asyncio/futures.py", line 361, in __iter__ yield self # This tells Task to wait for completion. File "/usr/lib/python3.5/asyncio/tasks.py", line 296, in _wakeup future.result() File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result raise self._exception indy.error.IndyError: ErrorCode.CommonInvalidStructure ``` Any recommendations in terms of how to fix this?

MattRaffel (Thu, 31 Jan 2019 17:26:18 GMT):
I didn't think any of the did spec changes were implemented yet. I may be wrong

sklump (Thu, 31 Jan 2019 17:55:55 GMT):
The whole DID spec thing is a draft, and relatively recent at that. Indy-sdk has enough new stuff going on that revisiting the core data structures might not be in the immediate plan.

mwherman2000 (Thu, 31 Jan 2019 17:57:51 GMT):
I understand but this makes it really really confuding for new developers ...esp. in light of the upcoming developer workshops.

swcurran (Thu, 31 Jan 2019 18:00:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=LkqiLsM6C3AP2aDmJ) @sklump The did-spec is not new. It is being evolved continuously (hence the very recent date on it), but the core concepts have not changed in quite some time - probably 8 months.

swcurran (Thu, 31 Jan 2019 18:01:12 GMT):
Which is relevant because we can fairly confidently build on it. I think it's on the roadmap for indy projects - just not immediately.

sklump (Thu, 31 Jan 2019 18:07:52 GMT):
I have tartar sauce older than 8 months

sklump (Thu, 31 Jan 2019 18:07:52 GMT):
I have tartar sauce older than 8 months :-)

mwherman2000 (Thu, 31 Jan 2019 19:06:19 GMT):
For https://github.com/mwherman2000/indy-dev/blob/master/python/getting_started-verbose.py to use valid DIDs (and not idstrings), I wrote some idstring <> DID wrappers: https://github.com/mwherman2000/indy-dev/blob/master/python/getting_started-verbose.py#L771-L815 Now `getting_started-verbose.py` only uses DIDs from a [workshop] developer perspective. For example, ``` INFO:__main__:1.1.1 "Sovrin Steward" -> Create and store in Wallet "Sovrin Steward Government" DID (from to) Create and store DID from DID: did:mymethod:Th7MpTaRZVRYnPiabds81Y Create and store DID from_to DID: did:mymethod:WDFUCaFHrqQdMhCgbVMZ6h INFO:__main__:1.1.2 "Sovrin Steward" -> Send NYM for "Sovrin Steward Government" DID (from to) to Ledger SEND_NYM: {"reqId":1548960780222513800,"identifier":"Th7MpTaRZVRYnPiabds81Y","operation":{"dest":"WDFUCaFHrqQdMhCgbVMZ6h","type":"1","verkey":"GvRZogqnpDf73aVCDLsWwoE8wHN4BZS5RQnj45zoZp2M"},"protocolVersion":2} INFO:__main__:1.1.3 "Sovrin Steward" -> Send Connection Request to Government with "Sovrin Steward Government" DID and Nonce (simulated) Connection Request: {"did": "did:mymethod:WDFUCaFHrqQdMhCgbVMZ6h", "nonce": 123456789} ``` idstrings are still used on the Ledger.

mwherman2000 (Thu, 31 Jan 2019 19:06:19 GMT):
FYI: For https://github.com/mwherman2000/indy-dev/blob/master/python/getting_started-verbose.py to use valid DIDs (and not idstrings), I wrote some idstring <> DID wrappers: https://github.com/mwherman2000/indy-dev/blob/master/python/getting_started-verbose.py#L771-L815 Now `getting_started-verbose.py` only uses DIDs from a [workshop] developer perspective. For example, ``` INFO:__main__:1.1.1 "Sovrin Steward" -> Create and store in Wallet "Sovrin Steward Government" DID (from to) Create and store DID from DID: did:mymethod:Th7MpTaRZVRYnPiabds81Y Create and store DID from_to DID: did:mymethod:WDFUCaFHrqQdMhCgbVMZ6h INFO:__main__:1.1.2 "Sovrin Steward" -> Send NYM for "Sovrin Steward Government" DID (from to) to Ledger SEND_NYM: {"reqId":1548960780222513800,"identifier":"Th7MpTaRZVRYnPiabds81Y","operation":{"dest":"WDFUCaFHrqQdMhCgbVMZ6h","type":"1","verkey":"GvRZogqnpDf73aVCDLsWwoE8wHN4BZS5RQnj45zoZp2M"},"protocolVersion":2} INFO:__main__:1.1.3 "Sovrin Steward" -> Send Connection Request to Government with "Sovrin Steward Government" DID and Nonce (simulated) Connection Request: {"did": "did:mymethod:WDFUCaFHrqQdMhCgbVMZ6h", "nonce": 123456789} ``` idstrings are still used on the Ledger.

mwherman2000 (Thu, 31 Jan 2019 19:06:19 GMT):
FYI: For https://github.com/mwherman2000/indy-dev/blob/master/python/getting_started-verbose.py to use syntactically valid DIDs (and not idstrings), I wrote some idstring <> DID wrappers: https://github.com/mwherman2000/indy-dev/blob/master/python/getting_started-verbose.py#L771-L815 Now `getting_started-verbose.py` only uses DIDs from a [workshop] developer perspective. For example, ``` INFO:__main__:1.1.1 "Sovrin Steward" -> Create and store in Wallet "Sovrin Steward Government" DID (from to) Create and store DID from DID: did:mymethod:Th7MpTaRZVRYnPiabds81Y Create and store DID from_to DID: did:mymethod:WDFUCaFHrqQdMhCgbVMZ6h INFO:__main__:1.1.2 "Sovrin Steward" -> Send NYM for "Sovrin Steward Government" DID (from to) to Ledger SEND_NYM: {"reqId":1548960780222513800,"identifier":"Th7MpTaRZVRYnPiabds81Y","operation":{"dest":"WDFUCaFHrqQdMhCgbVMZ6h","type":"1","verkey":"GvRZogqnpDf73aVCDLsWwoE8wHN4BZS5RQnj45zoZp2M"},"protocolVersion":2} INFO:__main__:1.1.3 "Sovrin Steward" -> Send Connection Request to Government with "Sovrin Steward Government" DID and Nonce (simulated) Connection Request: {"did": "did:mymethod:WDFUCaFHrqQdMhCgbVMZ6h", "nonce": 123456789} ``` idstrings are still used on the Ledger.

kdenhartog (Thu, 31 Jan 2019 20:00:53 GMT):
@mwherman2000 this is a known issue that has been deprioritized. To follow the discussion or contribute this work to the SDK checkout this jira ticket. https://jira.hyperledger.org/browse/IS-451https://jira.hyperledger.org/browse/IS-451

mwherman2000 (Thu, 31 Jan 2019 20:38:47 GMT):
@kdenhartog I'll check it out. It sometimes feels like we building a house-of-cards on a foundation of quicksand ...not all the time but sometimes.

vo2vo (Fri, 01 Feb 2019 04:40:03 GMT):
Has joined the channel.

vijayanandsudhakar (Fri, 01 Feb 2019 09:49:38 GMT):
ssn

vijayanandsudhakar (Fri, 01 Feb 2019 09:49:38 GMT):
Hi..is there an example out there showing an entity proving the existence of a valid SSN without revealing the actual SSN ? How do we use a predicate here?

phillip.gibb (Fri, 01 Feb 2019 10:51:33 GMT):
Has joined the channel.

vo2vo (Fri, 01 Feb 2019 14:48:22 GMT):
Don't know if anyone can give me a hint. I was following this guide https://github.com/hyperledger/indy-sdk/blob/master/README.md#how-to-start-local-nodes-pool-with-docker and was able to build the test pool on a docker (on top of a Ubuntu server). I copied the pool_transactions_genesis file to another Ubuntu server and use the indy-cli to connect to the pool just fine. When run "pool connect sandbox" it show connected. Now I want to create Steward and Trust Anchor but totally lost... I still have the output when starting the pool like seed, public key, BLS Public key, etc... but I don't know how to use the indy-cli to make myself a Steward...

danielhardman (Fri, 01 Feb 2019 16:37:33 GMT):
@sergey.minaev @mboyd The link to Indy SDK's Getting Started Guide is broken in /README.md. It points to https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/getting-started.md, which doesn't exist. The index.rst in that folder doesn't appear to be complete. I am unable to find the GSG content anymore. Can you please help me? I need to be able to link to the GSG reliably from the outside world, and we probably just created a whole bunch of broken links to GSG that are scattered in dozens or hundreds of docs.

danielhardman (Fri, 01 Feb 2019 16:38:41 GMT):
@esplinr ^^

mwherman2000 (Fri, 01 Feb 2019 16:54:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=M6BTEdiJ34rAZM77D) @danielhardman Daniel, we should have a quick chat about some significant updates I'm making the to Python GSG. RE: https://github.com/mwherman2000/indy-dev/tree/master/python

Doug-K1 (Fri, 01 Feb 2019 19:06:27 GMT):
Has joined the channel.

SJDFord (Sat, 02 Feb 2019 01:00:04 GMT):
Has joined the channel.

ianco (Sat, 02 Feb 2019 16:32:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=CMFjkJ5Ytqi3M44F7) It looks like in the VCX python demo Alice and Faber are using the same DID, is this correct?

DuckLover (Sat, 02 Feb 2019 16:54:04 GMT):
Hello, can someone maybe supply some information about the establishment of an secure connection between 2 Agents. Based on this video https://www.youtube.com/watch?v=9WZxlrGMA3s. I would like to create a sequence diagram this but not quite sure about the details

SergeyBrazhnik (Mon, 04 Feb 2019 10:41:23 GMT):
Hello everyone! I have found that in restriction section for *proverGetCredentialsForProofReq* call there is *issuer_did* parameter. That means that in claim there is information about issuer_did. Im just wondering if restrictions has some sort of "prover_did"? That will mean that in claim there is also information about *to whom* this claim is issued

xaviervila (Mon, 04 Feb 2019 10:45:00 GMT):
Has joined the channel.

AlexanderVtyurin (Mon, 04 Feb 2019 10:56:06 GMT):
@SergeyBrazhnik, prover can only have credentials issued to himself. So you actually don't need `prover_did` param, because you can only get credentials for yourself. `issuer_did` is needed to prove that you have particular credential from exactly that issuer.

SergeyBrazhnik (Mon, 04 Feb 2019 10:58:34 GMT):
@AlexanderVtyurin Thanks for reply!

mondraymond (Mon, 04 Feb 2019 12:18:26 GMT):
Has joined the channel.

vijayanandsudhakar (Mon, 04 Feb 2019 13:59:20 GMT):
zkp

dnnn (Mon, 04 Feb 2019 14:15:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=M6BTEdiJ34rAZM77D) @danielhardman I agree with Daniel, not finding it at the usual place is quite confusing

SergeyBrazhnik (Mon, 04 Feb 2019 18:04:41 GMT):
Hello everyone! Trying to revoke credentials. When posting request after *issuerRevokeCredential* to ledger Im receiving next error _Sign and submit failed. Reason: client request invalid: InvalidClientRequest('The current accumulator value: 1 0000000000000000000000000000000000000000000000000000000000000000 1 0000000000000000000000000000000000000000000000000000000000000000 2 095E45DDF417D05FB10933FFC63D474548B7FFFF7888802F07FFFFFF7D07A8A8 1 0000000000000000000000000000000000000000000000000000000000000000 1 0000000000000000000000000000000000000000000000000000000000000000 1 0000000000000000000000000000000000000000000000000000000000000000 must be equal to the last accumulator value: None in transaction',)_ What am I doing wrong?

sklump (Mon, 04 Feb 2019 18:10:18 GMT):
If you haven't found `indy-sdk/wrappers/python/tests/interation/test_interaction.py`, study it for the sequence exercising revocation from start to finish.

harmitfans (Mon, 04 Feb 2019 18:43:36 GMT):
Has joined the channel.

DuckLover (Mon, 04 Feb 2019 18:59:16 GMT):
Hello, i changing the reference agent setup a little bit. I created two crendentials that Alice gets at startup. Its is a GovID-like Credentials and one from her school. When i try to send a connection request to faber and establishing a relationship it throws me an error ``` alice_1 | TypeError: Cannot read property 'cred_info' of undefined alice_1 | at Object.exports.prepareRequest (/~/nodejs/indy/src/proofs/index.js:82:64) alice_1 | at alice_1 | (node:16) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'cred_info' of undefined alice_1 | at Object.exports.prepareRequest (/~/nodejs/indy/src/proofs/index.js:82:64) alice_1 | at alice_1 | (node:16) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function withouta catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1) alice_1 | (node:16) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code. ```

DuckLover (Mon, 04 Feb 2019 19:02:27 GMT):
In the ``` exports.prepareRequest = async function(message) { let pairwise = await indy.pairwise.get(message.origin); let proofRequest = await indy.crypto.authDecrypt(pairwise.my_did, message.message); ```

DuckLover (Mon, 04 Feb 2019 19:03:20 GMT):
the proofRequest ist generated with "name:General-Identity" is this kind of a set name that it has to look up?

tomislav (Mon, 04 Feb 2019 19:39:42 GMT):
It's the name of the example schema that the sample uses. @DuckLover

DuckLover (Mon, 04 Feb 2019 20:02:43 GMT):
So if i changes the createGovID function to the following: ``` async function issuePersonIdCredential() { let schemaName = 'Person-ID'; let schemaVersion = '1.2'; let signatureType = 'CL'; let personIdSchema; ```

DuckLover (Mon, 04 Feb 2019 20:02:48 GMT):
...

DuckLover (Mon, 04 Feb 2019 20:03:06 GMT):
I have to change Genral-Identity to Person-ID?

mboyd (Mon, 04 Feb 2019 21:08:25 GMT):
@danielhardman @dnnn Sorry for all the confusion, I understand that migrating our documentation is messy, and I'm working to make it as smooth as possible. The file you are looking for lives at https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/indy-walkthrough.md. I changed it from its original title of `getting-started.md` to make room for additional getting-started content on that page. I've just submitted a [pr](https://github.com/hyperledger/indy-sdk/pull/1453) to Indy-sdk to fix the broken link. Regarding broken links outside of the repository, besides fixing them 1 by 1, do you know any other solutions that might work? I assumed it was normally the duty of the linkee to create a permalink when linking to content that might be updated. What would be best in this situation?

DuckLover (Mon, 04 Feb 2019 21:13:01 GMT):
I dont really get it why this error happens. The CredsForProofRequest is still empty even after i change the "General-Identity" to "Person-ID". This function throws the error, maybe someone can read something out of the debug information

DuckLover (Mon, 04 Feb 2019 21:13:09 GMT):
``` exports.prepareRequest = async function(message) { let pairwise = await indy.pairwise.get(message.origin); let proofRequest = await indy.crypto.authDecrypt(pairwise.my_did, message.message); let credsForProofRequest = await sdk.proverGetCredentialsForProofReq(await indy.wallet.get(), proofRequest); let credsForProof = {}; for(let attr of Object.keys(proofRequest.requested_attributes)) { credsForProof[`${credsForProofRequest['attrs'][attr][0]['cred_info']['referent']}`] = credsForProofRequest['attrs'][attr][0]['cred_info']; } ```

DuckLover (Mon, 04 Feb 2019 21:13:32 GMT):

debug1.png

DuckLover (Mon, 04 Feb 2019 21:13:42 GMT):

debug2.png

DuckLover (Tue, 05 Feb 2019 00:43:44 GMT):
Anyone expericend the bug that the "accept" button in the message section in the reference agent dont work?

haggs (Tue, 05 Feb 2019 01:18:16 GMT):
@DuckLover Python reference agent? Also what OS and are you running in docker? Might want to take this to #indy-agent

DuckLover (Tue, 05 Feb 2019 09:58:03 GMT):
Nodejs running it on a ubtunt 16.04 LTS

DuckLover (Tue, 05 Feb 2019 15:51:19 GMT):
Not sure if it correlate with it but after clicking on accept the relationship is not named, there is still the DID value. Can someone maybe point me to the code where the name for the relationship comes from?

DuckLover (Tue, 05 Feb 2019 15:57:20 GMT):
Because relationship object dont store a name variable, not sure why

nehalshah50 (Tue, 05 Feb 2019 16:38:03 GMT):
Has joined the channel.

dbluhm (Tue, 05 Feb 2019 16:38:34 GMT):
@DuckLover Unfortunately, the NodeJS implementation is not being actively maintained at the moment. For an up-to-date reference of agents, please see the Python Reference Agent.

dbluhm (Tue, 05 Feb 2019 16:38:34 GMT):
@DuckLover Unfortunately, the NodeJS implementation is not being actively maintained at the moment. For an up-to-date reference on agents and agent standards, please see the Python Reference Agent.

dbluhm (Tue, 05 Feb 2019 16:39:04 GMT):
Also, to second what @haggs said, #indy-agent is the best channel for questions about agents :slightly_smiling_face:

nehalshah50 (Tue, 05 Feb 2019 16:40:10 GMT):
Hi, I am trying to do some development on Mac machine using LIBVCX. I tried following some online guide on github and was able to generate libindy.dylib and com.evernym-vcx-0.2.1.jar file. Is that enough to start writing some JAVA code to test out??

nehalshah50 (Tue, 05 Feb 2019 16:40:10 GMT):
Hi, I am trying to do some development on Mac machine using LIBVCX. I tried following some online guide on github and was able to generate libindy.dylib and java wrapper com.evernym-vcx-0.2.1.jar file. Is that enough to start writing some JAVA code to test out??

nehalshah50 (Tue, 05 Feb 2019 16:40:10 GMT):
==NEED HELP==== Hi, I am trying to do some development on Mac machine using LIBVCX. I tried following some online guide on github and was able to generate libindy.dylib and java wrapper com.evernym-vcx-0.2.1.jar file. Is that enough to start writing some JAVA code to test out??

MALodder (Tue, 05 Feb 2019 17:41:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=39BAzXfC3GxQnJfuC) @nehalshah50 I haven't used the evernym vcx jar before, but my guess is you will need to compile vcx to have a libvcx.dylib available, and include in your java project the jna.jar library also

nehalshah50 (Tue, 05 Feb 2019 17:48:41 GMT):
so you would need libindy.dylib, libvcx.dylib and vcx java wrapper file com.evernym-vcx-0.2.1.jar to communicate to network using java??

MattRaffel (Tue, 05 Feb 2019 17:53:50 GMT):
@nehalshah50 you will probably also need libnullpay (or implement your own). I believe vcx will not function without registering a handler

MALodder (Tue, 05 Feb 2019 17:58:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=RsBadCh2ivK63NzAg) @nehalshah50 yes, libvcx links to linindy

ianco (Tue, 05 Feb 2019 18:19:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=oogbX7HdtgcN6Gn26) @MALodder You also need the dummy-cloud-agent. I don't know if there is a Java demo, but you can take a look at the Alice/Faber python demo to see how it all fits together

MALodder (Tue, 05 Feb 2019 18:48:18 GMT):
That sounds right

swcurran (Tue, 05 Feb 2019 19:01:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=y2cctbGqiMSCWZcxE) @DuckLover I think this might answer your question - In the "original" nodejs agent, the name came from a behind-the-scenes proof request/proof process between a the connected parties based on a government credential that each party "magically" had on startup. A recent PR from @mhailstone added the government as a real agent, and has each participant explicitly has to connect with the gov agent and get the ID credential. That then allows the behind-the-scenes proof request/proof to work as the other agents connect. The PR is: https://github.com/hyperledger/indy-agent/pull/58

ardagumusalan (Tue, 05 Feb 2019 21:36:51 GMT):
Hi. Let's say an issuer creates a credential definition with max credential is set to 10 for the tails file. What is the right behavior for the issuer if it fill the tails file and is about the issuer 11th credential for the aforementioned credential definition?

ardagumusalan (Tue, 05 Feb 2019 21:36:51 GMT):
Hi. Let's say an issuer creates a credential definition with max credential is set to 10 for the tails file. What is the right behavior for the issuer if it fill the tails file and is about tto issue its 11th credential for the aforementioned credential definition?

nehalshah50 (Tue, 05 Feb 2019 22:08:35 GMT):
I am trying to initialize VcxAPI using a config file and I am getting following error. Any idea? com.evernym.sdk.vcx.VcxException: An unmapped error with the code '1087' was returned by the SDK

ianco (Wed, 06 Feb 2019 01:38:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=KxPfyvLnK4G97gSv6) @nehalshah50 src/utils/error.rs:101:pub static MISSING_PAYMENT_METHOD: Error = Error{ code_num: 1087, message: "Configuration is missing the Payment Method parameter"};

vijayanandsudhakar (Wed, 06 Feb 2019 05:06:49 GMT):
hi..I am trying to understand when unrevealed attributes would be used in constructing a proof request. From what i understand about the proofs so far, predicates can be used to prove certain values/conditions without revealing the actual value. How is this different from marking an attribute as unrevealed in the proof that is sent to verifier? Appreciate any advice on this.

xnopre (Wed, 06 Feb 2019 14:12:58 GMT):
I have written some NodeJs scripts in `indy-sdk` (https://github.com/hyperledger/indy-sdk/blob/master/docs/how-tos/write-did-and-query-verkey/nodejs/writeDidAndQueryVerkey.js, https://github.com/hyperledger/indy-sdk/commits/master/docs/how-tos/rotate-key/nodejs, ...) but I don't see my name as contributor. Strange... What is the explanation ? Thanks cc @Artemkaaas @sergey.minaev ...

swcurran (Wed, 06 Feb 2019 14:46:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ysmNcdLwd6yDhmx3v) @vijayanandsudhakar If a claim is unrevealed, no data is sent. It is known that there is some value there, but the value is not known. When a predicate is used a true/false value is sent that indcates if the claim meets the predicate. So if the claim is "Date of Birth", and the value is "greater than 21 years ago", then the (proven) correct value of "True" or "False" is set. The Date of Birth is not revealed, but the verifier will know if that date was greater than or less than 21 years ago.

nehalshah50 (Wed, 06 Feb 2019 15:04:26 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=R3xjpH727NsSBcqGj) @ianco Is there a sample config file which I can use? Whatever example I could find about config file doesn't contain payment method parameter

nanspro (Wed, 06 Feb 2019 15:30:01 GMT):
Has joined the channel.

ardagumusalan (Wed, 06 Feb 2019 15:37:24 GMT):
Hi. Let's say an issuer issued a cred_def with a tails file of entry size 10. If this issuer were to issue its 11th credential with aforementioned cred_def, what should be issuer do first? issue a new cred_def? is it possible to publish a new tails file perhaps with a different tails_writer_config? Thanks.

ardagumusalan (Wed, 06 Feb 2019 15:37:24 GMT):
Hi. Let's say an issuer issued a cred_def with a tails file of entry size 10. If this issuer were to issue its 11th credential with aforementioned cred_def, what should the issuer do first? issue a new cred_def? is it possible to publish a new tails file perhaps with a different tails_writer_config? Thanks.

sklump (Wed, 06 Feb 2019 15:48:17 GMT):
You will get an `ErrorCode.AnoncredsRevocationRegistryFullError`. Create a new revocation registry on the same cred def but with a new tag. Then issue the credential, citing the new revocation registry.

ardagumusalan (Wed, 06 Feb 2019 15:51:42 GMT):
ah a new tag! I have been getting wallet item already exists error. new TAG will solve it I assume. Thanks!

ianco (Wed, 06 Feb 2019 15:52:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=h6gq9knPQkRiF46hx) @nehalshah50 I haven't looked at the Java wrapper, but in the Python wrapper (and demo) you can just set to null: https://github.com/hyperledger/indy-sdk/blob/master/vcx/wrappers/python3/demo/faber.py#L26

ianco (Wed, 06 Feb 2019 15:55:17 GMT):
... or maybe "null" :-D

nehalshah50 (Wed, 06 Feb 2019 15:59:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=EEMaXaHLAYJKeFkXf) @ianco Great. Thx

AlexanderVtyurin (Wed, 06 Feb 2019 16:22:34 GMT):
Guys, I've posted an issue to Jira (https://jira.hyperledger.org/browse/IS-1170). What should I do next? How can I gather your feedback?

ianco (Wed, 06 Feb 2019 17:09:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wW5uuSXfKq7PvnQsf) @AlexanderVtyurin Hi, took a quick look at your JIRA. Not an official answer (maybe one of the VCX devs can weigh in) but I think VCX does what you're asking for already. Regarding the transport, it currently uses an agency ("dummy-cloud-agent" in the indy-sdk git repo) however my understanding is that VCX is going to migrate to the "standard" Indy agent protocol.

AlexanderVtyurin (Wed, 06 Feb 2019 17:14:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JykyLdA6MxFiZsvmg) @ianco Thanks for reply! Where can I find dummy vs. standard agent comparison?

ianco (Wed, 06 Feb 2019 17:15:05 GMT):
The dummy agent is here: https://github.com/hyperledger/indy-sdk/tree/master/vcx/dummy-cloud-agent

ianco (Wed, 06 Feb 2019 17:15:30 GMT):
The "agent" protocol is being defined through the HIPE process, best place to go is probably the indy-agent channel

ianco (Wed, 06 Feb 2019 17:15:30 GMT):
The "agent" protocol is being defined through the HIPE process, best place to go is probably the indy-agent channel, they can point you to the most recent/relevant info

nehalshah50 (Wed, 06 Feb 2019 17:29:16 GMT):
Hello, I keep getting following error. I am using VCX java wrapper. Any idea? com.evernym.sdk.vcx.LibVcx.native.vcx.utils.libindy.error_codes - src/utils/libindy/error_codes.rs:24 | indy-sdk error code: 204 com.evernym.sdk.vcx.LibVcx.native.vcx.api.vcx - src/api/vcx.rs:148 | Init Wallet Error 1079.

ianco (Wed, 06 Feb 2019 17:33:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=rhAEPix2XkJLcPMRT) @nehalshah50 src/api/mod.rs:134: WalletNotFoundError = 204,

ianco (Wed, 06 Feb 2019 17:35:04 GMT):
VCX should create the wallet if it's not already there

nehalshah50 (Wed, 06 Feb 2019 17:49:09 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=J4MneBbP6Hdv8k6JR) @ianco VCX didn't create wallet. So I used indy-cli to create a wallet first and then my code started working. Not sure if there is a way to tell VCX Java wrapper to create wallet automatically?? Now I have following error when trying to create schema com.evernym.sdk.vcx.LibVcx.native.vcx.api.schema - src/api/schema.rs:70 | vcx_schema_create_cb(command_handle: 2, rc: 1080-Object (json, config, key, credential and etc...) passed to libindy has invalid structure, handle: 0) source_id: 123

ianco (Wed, 06 Feb 2019 17:54:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kBtG6HBt4AmqcYLL2) @nehalshah50 I haven't looked at the Java wrapper, but one thing you can do is take a look at the Python demo (it's wrapping the same VCX code after all) and compare to what you are doing. The "Faber" persona creates a schema here: https://github.com/hyperledger/indy-sdk/blob/master/vcx/wrappers/python3/demo/faber.py#L79

nehalshah50 (Wed, 06 Feb 2019 18:01:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=yWdm2XLrKCYBJKnFp) @ianco I am doing what phyton demo is doing. But not sure why it's not liking it creating schema with source_id: 123, name: test111, issuer_did: 2YbuEaSyorW2ex939pFFG5 com.evernym.sdk.vcx.LibVcx.native.vcx.utils.libindy.error_codes - src/utils/libindy/error_codes.rs:24 | indy-sdk error code: 113 com.evernym.sdk.vcx.LibVcx.native.vcx.api.schema - src/api/schema.rs:70 | vcx_schema_create_cb(command_handle: 2, rc: 1080-Object (json, config, key, credential and etc...) passed to libindy has invalid structure, handle: 0) source_id: 123 11:00:05.573 [Thread-401] DEBUG SchemaApi - callback() called with: commandHandle = [2], err = [1080], schemaHandle = [0]

nehalshah50 (Wed, 06 Feb 2019 18:01:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=yWdm2XLrKCYBJKnFp) @ianco I am doing what phyton demo is doing. But not sure why it's not liking it `creating schema with source_id: 123, name: test111, issuer_did: 2YbuEaSyorW2ex939pFFG5 com.evernym.sdk.vcx.LibVcx.native.vcx.utils.libindy.error_codes - src/utils/libindy/error_codes.rs:24 | indy-sdk error code: 113 com.evernym.sdk.vcx.LibVcx.native.vcx.api.schema - src/api/schema.rs:70 | vcx_schema_create_cb(command_handle: 2, rc: 1080-Object (json, config, key, credential and etc...) passed to libindy has invalid structure, handle: 0) source_id: 123 SchemaApi - callback() called with: commandHandle = [2], err = [1080], schemaHandle = [0]`

nehalshah50 (Wed, 06 Feb 2019 18:02:17 GMT):
`test`

MattRaffel (Wed, 06 Feb 2019 18:06:07 GMT):
error code 113 is invalid structure. It could be any one of the inputs. I know that doesnt help much. I would start by comparing each input structures from the demo

ianco (Wed, 06 Feb 2019 18:11:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=cNBSJFBc5uNmjdCYq) @nehalshah50 Can you post your code? (Or PM it to me and I can take a look later today)

nehalshah50 (Wed, 06 Feb 2019 18:11:31 GMT):
It looks like for schema definition each attributes needs to be surrounded with double quotes vs single quotes...this is for the VCX Java wrapper. `val schemaData = "[\"attr1\", \"attr2\", \"height\", \"weight\"]"` Now I am able to proceed further and now stuck on next error which is *src/utils/libindy/error_codes.rs:24 | indy-sdk error code: 700*

ianco (Wed, 06 Feb 2019 18:12:08 GMT):
src/api/mod.rs:221: PaymentUnknownMethodError = 700,

MattRaffel (Wed, 06 Feb 2019 18:18:09 GMT):
vcx requires the use of a payment handler. libnullpay in the indy-sdk repo is an example of payment handler. addresses determine which payment handler to use. I cannot tell if its expecting libnullpay, but I would start with that

MattRaffel (Wed, 06 Feb 2019 18:18:09 GMT):
vcx requires the use of a payment handler. libnullpay in the indy-sdk repo is an example of payment handler. addresses determine which payment handler to use. I cannot tell if what you are doing is expecting libnullpay or another payment handler, but I would start with that

ardagumusalan (Wed, 06 Feb 2019 20:07:04 GMT):
When I look at anoncreds.py, I do not get much information regarding rev_reg_def_id. Can someone eloborate on that a bit? Thanks.

harmitfans (Wed, 06 Feb 2019 21:54:52 GMT):

Clipboard - February 6, 2019 1:54 PM

harmitfans (Wed, 06 Feb 2019 21:57:18 GMT):
I am new to Hyperledger INDY and have recently started evaluating indy-sdk. I need help to refine my understanding. Above extract details what i am able to do and difficulty i am facing understanding the API. APIs work as designed but not able to understand the flow of events.

harmitfans (Wed, 06 Feb 2019 21:58:18 GMT):
It seems to be an attachment but just details the flow i used to evaluate.

harmitfans (Wed, 06 Feb 2019 21:58:41 GMT):
Thanks for all help and support.

harmitfans (Wed, 06 Feb 2019 22:35:17 GMT):
Pasting the document content in chat for easy readability I am able to start a Docker indy node instance and use indy-sdk to 1. Create a Steward Wallet 2. Create Organization Wallet, Generate DID 3. Register a Organization DID 4. Configure Organization (schema, credentials, Revocation Config & Registry) 5. Create a wallet for User 6. User gets his / her credentials signed by Organization (Credential Offer, Master Secret, Create Credentials Request, Retrieve Signed Credentials from Organization, Store Signed Credentials in local wallet) 7. User generates proof (Get proof request, Generate Proof with self & organization attestation) 8. Verify proof by 3rd party (BAR) 9. Revoke credentials by the Organization 10. Verify proof by 3rd party … fail In the above flow part of the indy-sdk usage lot of data was being shared / passed between the User, Organization and 3rd party verifier (BAR) E.g. To generate proof there is a need for schemaJson, credDefJson, revRegDefJson, revRegDeltaJson etc. Organization needs to pass all this information to user. There may be number of wallets in market and user may use any one, how can organizations standardize on the data sharing format? Does Indy standardize that interaction? Same standardization will be needed when user presents the proof to the verifier same data can be sent via QRCode, NFC, Bluetooth, link, email etc. but it has to be standardized Verify API requires schemaJson, credDefJson, revRegDefJson, revRegDeltaJson etc. Is the expectation that user will provide all this information via wallet or verifier needs to know about all this information before hand on their infrastructure? Will the credential related information passed via underlying Distributed Ledger? Revoke credential api responds with revRegDelta and same has to be used for verification process. If credentials are revoked due to fraud why will malicious user use this updated new data to be send along for proof verification. Is there a way verifier can have this information from underlying DLT or verify API can use this info why should it be provided. Tails access is needed during proof generation, is the expectation that 3rd party wallets need to have access to this all the time and organizations need to have this data hosted online? How will the organization pass this information to the wallets? How can enterprise secure the URL? Thank you for all the help & support.

kdenhartog (Thu, 07 Feb 2019 00:00:55 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aCem7aYYwLH8xaq7W) @xnopre It looks like you've received credit in the repository, but when @mboyd restructured the directory (probably for indy-docs support) git did a delete of the old file and an add of the new file. https://github.com/hyperledger/indy-sdk/commits?author=xnopre I think it would be acceptable if you add a contributor tag to the top of the How-to guides. Something like "Original contribution by Xnopre" would be fine and you could link to your commit history to the repository. Speaking of which, thank you for adding these in here! I know I have plans to move them to my (indy-dev repository)[https://github.com/kdenhartog/indy-dev] and learn from them.

kdenhartog (Thu, 07 Feb 2019 00:00:55 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aCem7aYYwLH8xaq7W) @xnopre It looks like you've received credit in the repository, but when @mboyd restructured the directory (probably for indy-docs support) git did a delete of the old file and an add of the new file. https://github.com/hyperledger/indy-sdk/commits?author=xnopre I think it would be acceptable if you add a contributor tag to the top of the How-to guides. Something like "Original contribution by Xnopre" would be fine and you could link to your commit history to the repository. Speaking of which, thank you for adding these in here! I know I have plans to move them to my indy-dev repository https://github.com/kdenhartog/indy-dev and learn from them. I'd greatly appreciate the PR if you want to do that instead and get the credit you deserve for them in that repo as well.

vijayanandsudhakar (Thu, 07 Feb 2019 06:18:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=LGZMdTpyp5J3qcufa) @swcurran Hi..thanks for the explanation. So, would a verifier find an unrevealed attribtue as acceptable proof of a claim ? For example, an entity could send a proof of their GovID (drawing from the getting started guide) with SSN as an unrevealed attribute. The verifier could then accept this as proof that the entity has a valid SSN without knowing the actual SSN? Of course, it also depends on the degree of trust the verifier has on issuer of GovID..

xnopre (Thu, 07 Feb 2019 08:45:15 GMT):
@kdenhartog Hi. - Thank you for explanations on git history - I don't understand what you want me to do about "contributor tag", I don't know what to do, where and how... ;-) - For you `indy-dev`, I don't really understand what does this repo bring more ? Do you want me to copy something (what) from `indy-sdk` to `indy-dev` ? Or preferaly contribute to this repo rather than `indy-sdk` ? ... Thank you for more details :-)

kdenhartog (Thu, 07 Feb 2019 09:52:00 GMT):
Indy-dev makes it easier to setup a playground for IndySDK. In the past many people have struggled with setting it up and were unable to work with the wrappers. I'll copy the how-to guides you've submitted to the IndySDK repo and add a note that you wrote these originally. That way you get attribution even if the commits don't appear in Indy-dev. I was just thinking in the readme files you add "contributed by xnopre" is all.

sklump (Thu, 07 Feb 2019 14:25:22 GMT):
I notice that in `did.py`, method `set_endpoint_for_did()` takes a wallet handle, but `get_endpoint_for_did()` also takes a pool handle. How does endpoint (meta)data get to the ledger? Or is this an extraneous parameter? At present we work with endpoints, but write them to the ledger as attributes on NYM records. Is this approach wrong or deprecated? Thanks in advance.

xnopre (Thu, 07 Feb 2019 14:41:52 GMT):
@kdenhartog > Indy-dev makes it easier to setup a playground for IndySDK. Why not to include all necessary in `indy-sdk` (and `indy-agent`) all necessary to help developper to have running environment ? It's a pitty to have 2 different repos, not ? > I'll copy the how-to guides you've submitted to the IndySDK repo and add a note that you wrote these originally. Same remark or question, but why copying into another repo ? If things will change in `indy-sdk` , they will not change in your repo, and vice-versa... > That way you get attribution even if the commits don't appear in Indy-dev. I was just thinking in the readme files you add "contributed by xnopre" is all. OK, understood, and thank you for the mention :-)

MattRaffel (Thu, 07 Feb 2019 16:03:36 GMT):
@xnopre we are working on improving that. any community help would be appreciated as well. there's a few "big" items that need to be improved and simply merging into another repo only makes some of those items "larger"

swcurran (Thu, 07 Feb 2019 16:30:03 GMT):
@vijayanandsudhakar - whether a verifier would accept knowing the SSN exists vs. knowing its value depends on the business case. A bank that must report information to the IRS by SSN must know the value. Another organization may just need to know you have one. So it's really a use case question. You have the tools to know the SSN exists, was issued by the IRS to the holder, and was not forged. What you do with those tools depends on what you are doing.

phillip.gibb (Thu, 07 Feb 2019 16:33:52 GMT):
Hi there, morning for some, evening for me, and everyone in between; howzit I am tearing my hair out trying to get libindy to initialize on a x86 emulator: `Unable to load library 'indy': Native library (android-x86/libindy.so) not found in resource path (.)`

phillip.gibb (Thu, 07 Feb 2019 16:34:48 GMT):
it is the right build and the right abi etc, but it just does not believe me when I put the libs in the correct place hell, I am put them everywhere

MattRaffel (Thu, 07 Feb 2019 16:35:16 GMT):
@phillip.gibb is this during building?

MattRaffel (Thu, 07 Feb 2019 16:35:16 GMT):
@phillip.gibb is this during compiling?

MattRaffel (Thu, 07 Feb 2019 16:35:16 GMT):
@phillip.gibb is this during compiling or during execution?

AlexanderVtyurin (Thu, 07 Feb 2019 17:07:39 GMT):
@phillip.gibb 1. make sure you have this guy in your dependencies in build.gradle `implementation 'net.java.dev.jna:jna:4.5.1@aar'` (but extract libjnidispatch.so out of it - see step 4) 2. make sure you have this in defaultConfig in build.gradle `ndk { abiFilters 'x86' }` 3. each IDE has it's own default JNI directory - for IntelliJ it is `src/main/jniLibs/` 4. make sure you put `libgnustl_shared.so` and `libjnidispatch.so` in your default JNI directory alongside with `libindy.so` 5. make sure you delete application from phone eventually (sometimes it breaks and doesn't update your .so files)

MALodder (Thu, 07 Feb 2019 19:09:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=R7R9kC5waRvwcnMjP) @phillip.gibb Have you tried setting `LD_LIBRARY_PATH` to where the libindy.so file is

phillip.gibb (Thu, 07 Feb 2019 19:33:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Lg4tBcBcvJNEk4Ydz) @MALodder how does one specify the LD_LIBRARY_PATH in android?

phillip.gibb (Thu, 07 Feb 2019 19:37:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=HgiywkSwndgfBBKHD) @AlexanderVtyurin I am following all that - except I don't have libgnustl_shared.so

phillip.gibb (Thu, 07 Feb 2019 19:55:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=X752XsSPLrxyG2Wxi) @MattRaffel execution

phillip.gibb (Thu, 07 Feb 2019 19:58:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=52R9uyhYdKydfQA5s) found it: https://github.com/urho3d/android-ndk/blob/master/sources/cxx-stl/gnu-libstdc%2B%2B/4.9/libs/x86/libgnustl_shared.so Works now thanks

brycebudd (Thu, 07 Feb 2019 20:06:36 GMT):
Has joined the channel.

MALodder (Thu, 07 Feb 2019 20:17:22 GMT):
The other thing you can do is call `loadLibrary` with the specific path to your dependencies

vijayanandsudhakar (Fri, 08 Feb 2019 07:20:33 GMT):
@swcurran thanks for the clarification!

xnopre (Fri, 08 Feb 2019 09:48:50 GMT):
I have questions about encryption, and public and private key. `cryptoAuthCrypt` expect `senderVk` and `recipientVk`. (Note : I'm using NodeJs wrapper and I'm reading its documentation https://github.com/hyperledger/indy-sdk/tree/master/wrappers/nodejs#cryptoauthcrypt--wh-sendervk-recipientvk-messageraw----encryptedmsgraw) 1/ This keys are "public" keys, am I right ? 2/ I suppose that "private" keys are store in the wallet, right ? 3/ If yes, I suppose that there is an association to retrieve the private key from public key or another information ? 4/ Is it possible to have access to this private keys ? 5/ With `cryptoAuthCrypt`, the message is signed with `senderVk` and encrypted with `recipientVk`, but not encrypted with both keys, right ? Thanks for you answer and help :-)

Artemkaaas (Fri, 08 Feb 2019 10:16:41 GMT):
1) yes 2) yes. an object {verkey, signkey} stores. 3,4 ) there is no public way to get secret key from wallet. 5) this function encrypts message using the sender's secret key correspondent to verkey and the receiver's verkey

Artemkaaas (Fri, 08 Feb 2019 10:16:41 GMT):
1) yes 2) yes. an object {verkey, signkey} stores in wallet. 3,4 ) there is no public way to get secret key from wallet. 5) this function encrypts message using the sender's secret key correspondent to verkey and the receiver's verkey

xnopre (Fri, 08 Feb 2019 10:32:14 GMT):
@Artemkaaas Thanks for your answer ! :-) . For 5), are you sure ? I read (in documentation or in this channel, I don't remember), that message is only "crypted" with receiver's key, and sender's key is used to sign the message (before or after encryption ?). Anyway, `cryptoAuthDecrypt` expect `recipientVk` and not `senderVk`... :thinking:

Artemkaaas (Fri, 08 Feb 2019 10:47:20 GMT):
no. actually, it uses `crypto_box_curve25519xsalsa20poly1305` internally

Artemkaaas (Fri, 08 Feb 2019 10:47:20 GMT):
no. actually, it uses `crypto_box_curve25519xsalsa20poly1305` internally from NaCl

Artemkaaas (Fri, 08 Feb 2019 10:47:20 GMT):
no. actually, it uses NaCl `crypto_box_curve25519xsalsa20poly1305` internally

Artemkaaas (Fri, 08 Feb 2019 10:47:20 GMT):
no. actually, it uses combination of NaCl `crypto_box_curve25519xsalsa20poly1305` and `crypto_box_seal` internally

Artemkaaas (Fri, 08 Feb 2019 10:47:56 GMT):
as I remember

ardagumusalan (Fri, 08 Feb 2019 14:00:37 GMT):
Hi all. Is there a recommended minimum tails file entry size?

sklump (Fri, 08 Feb 2019 14:12:54 GMT):
The smaller you make it, the quicker it fills up and the more files you will have to co-ordinate between issuers and provers. The bigger you make it, the longer it takes. While indy-sdk is creating a tails file, it is not doing anything else in its process or any subprocess.

sklump (Fri, 08 Feb 2019 14:13:58 GMT):
Be sure to have compiled indy-sdk in release mode `cd indy-sdk/libindy; cargo build --release; sudo cp target/release/libindy.so /usr/lib` if generating tails files.

ardagumusalan (Fri, 08 Feb 2019 14:31:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=F2KEP5FHnyTCrxdAe) @sklump My concern is rather from the security point of view. In the description it states tails file are typically has hundreds of thousands to tens of millions. I just ran some tests with tails file size set to 500,000 and it takes quite some time to created a credential definition also send the tails file to the prover. I just wanted to see if a tails file of very small let's say 100 can be reverse-engineered?

ardagumusalan (Fri, 08 Feb 2019 14:31:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=F2KEP5FHnyTCrxdAe) @sklump My concern is rather from the security point of view. In the description it states tails file are typically has hundreds of thousands to tens of millions. I just ran some tests with tails file size set to 500,000 and it takes quite some time to create a credential definition also send the tails file to the prover. I just wanted to see if a tails file of very small let's say 100 can be reverse-engineered?

ardagumusalan (Fri, 08 Feb 2019 14:31:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=F2KEP5FHnyTCrxdAe) @sklump My concern is rather from the security point of view. In the description it states tails file are typically has hundreds of thousands to tens of millions entries. I just ran some tests with tails file size set to 500,000 and it takes quite some time to create a credential definition also send the tails file to the prover. I just wanted to see if a tails file of very small let's say 100 can be reverse-engineered?

xnopre (Fri, 08 Feb 2019 14:39:52 GMT):
I'm reading again documentation for `cryptoAuthCrypt ` (https://github.com/hyperledger/indy-sdk/blob/master/wrappers/nodejs/README.md#cryptoauthcrypt--wh-sendervk-recipientvk-messageraw----encryptedmsgraw). > Sender can encrypt a confidential message specifically for Recipient, using Sender's public key. Sure ? I'm surprised... Unless I'm mistaken, message is signed with Sender's public key and encrypted with Recipient's public key, no ? > Using Recipient's public key, Sender can compute a shared secret key. Using Sender's public key and his secret key, Recipient can compute the exact same shared secret key. That shared secret key can be used to verify that the encrypted message was not tampered with, before eventually decrypting it. If I good understand, sender and recipient can compute the same "shared secret" (from its own private key (?) and the public key of the other actor), and this "shared secret" is used to verify the signature of the message, right ? But this is not used for encryption/decryption, right ? cc @Artemkaaas @danielhardman

xnopre (Fri, 08 Feb 2019 14:39:52 GMT):
Hi all. I'm reading again documentation for `cryptoAuthCrypt ` (https://github.com/hyperledger/indy-sdk/blob/master/wrappers/nodejs/README.md#cryptoauthcrypt--wh-sendervk-recipientvk-messageraw----encryptedmsgraw). > Sender can encrypt a confidential message specifically for Recipient, using Sender's public key. Sure ? I'm surprised... Unless I'm mistaken, message is signed with Sender's public key and encrypted with Recipient's public key, no ? > Using Recipient's public key, Sender can compute a shared secret key. Using Sender's public key and his secret key, Recipient can compute the exact same shared secret key. That shared secret key can be used to verify that the encrypted message was not tampered with, before eventually decrypting it. If I good understand, sender and recipient can compute the same "shared secret" (from its own private key (?) and the public key of the other actor), and this "shared secret" is used to verify the signature of the message, right ? But this is not used for encryption/decryption, right ? cc @Artemkaaas @danielhardman

Artemkaaas (Fri, 08 Feb 2019 14:42:36 GMT):
`sender and recipient can compute the same "shared secret" (from its own private key (?) and the public key of the other actor), and this "shared secret` it's true

Artemkaaas (Fri, 08 Feb 2019 14:42:52 GMT):
`crypto_box_curve25519xsalsa20poly1305` does it

dnnn (Fri, 08 Feb 2019 14:54:37 GMT):
Hi all, does anyone has any tips on how to get explicit logging in obj-c wrapper?

Artemkaaas (Fri, 08 Feb 2019 15:02:11 GMT):
there is `setLogger` function which accept callback will be used by Libindy to log recoreds

Artemkaaas (Fri, 08 Feb 2019 15:02:11 GMT):
@denn there is `setLogger` function which accept callback will be used by Libindy to log recoreds

Artemkaaas (Fri, 08 Feb 2019 15:02:11 GMT):
@dnnn there is `setLogger` function which accept callback will be used by Libindy to log recoreds

Artemkaaas (Fri, 08 Feb 2019 15:02:15 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/wrappers/ios/libindy-pod/Indy/Utils/IndyLogger.h#L30

Artemkaaas (Fri, 08 Feb 2019 15:02:44 GMT):
here is simple test which demonstraits hot to use `https://github.com/hyperledger/indy-sdk/blob/master/wrappers/ios/libindy-pod/Indy-demoTests/Demo%20Tests/LoggerDemo.mm`

dnnn (Fri, 08 Feb 2019 15:05:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=gpd89Z4QpmEvisPoM) @Artemkaaas will have a look. BIG THANKS!

sklump (Fri, 08 Feb 2019 15:17:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=dEQWJDLhEckzCQdhF) @ardagumusalan Tails files are immutable and public. There is no value in reverse-engineering one.

sklump (Fri, 08 Feb 2019 15:17:38 GMT):
*QUESTION*: I notice that in `did.py`, method `set_endpoint_for_did()` takes a wallet handle, but `get_endpoint_for_did()` also takes a pool handle. How does endpoint (meta)data get to the ledger? Or is this an extraneous parameter? At present we work with endpoints, but write them to the ledger as attributes on NYM records. Is this approach wrong or deprecated? Thanks in advance.

sklump (Fri, 08 Feb 2019 15:18:07 GMT):
*Question*

sklump (Fri, 08 Feb 2019 15:22:23 GMT):
*QUESTION 1*: I notice that in `did.py`, method `set_endpoint_for_did()` takes a wallet handle, but `get_endpoint_for_did()` also takes a pool handle. How does endpoint (meta)data get to the ledger? Or is this an extraneous parameter? At present we work with endpoints, but write them to the ledger as attributes on NYM records. Is this approach wrong or deprecated? Thanks in advance. *QUESTION 2*: Regarding node pool configuration as indy-sdk creates it via the wrapper tests, `~/.indy_client/pool/pool1/config.json` contains ``` {"genesis_txn":"/tmp/indy_client/pool1.txn"} ``` But this is a temp file, which can not be expected to be present forever. Once it's created, does anything rely on the config.json pointing to a file that is there, or is this historical information as long as the `pool1/pool1.txn` is present and correct?

sklump (Fri, 08 Feb 2019 15:22:23 GMT):
*QUESTION 1*: I notice that in `did.py`, method `set_endpoint_for_did()` takes a wallet handle, but `get_endpoint_for_did()` also takes a pool handle. How does endpoint (meta)data get to the ledger? Or is this an extraneous parameter? At present we work with endpoints, but write them to the ledger as attributes on NYM records. Is this approach wrong or deprecated? Thanks in advance. *QUESTION 2*: Regarding node pool configuration as indy-sdk creates it via the wrapper tests, `~/.indy_client/pool/pool1/config.json` contains ``` {"genesis_txn":"/tmp/indy_client/pool1.txn"} ``` But this is a temp file, which can not be expected to be present forever. Once it's created, does anything rely on `config.json` pointing to a file that is there, or is this historical information as long as the `pool1/pool1.txn` is present and correct?

ardagumusalan (Fri, 08 Feb 2019 15:26:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Kjc6dJ9apezdXaDG8) @sklump this makes me wonder why there is a statement regarding hundreds of thousands or tens of millions per tails file? Am I reading this wrong? my concern is the idea is for the prover to prove non-revocation without correlation. Do small tails files hurt this expectation?

ardagumusalan (Fri, 08 Feb 2019 15:26:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Kjc6dJ9apezdXaDG8) @sklump this makes me wonder why there is a statement regarding hundreds of thousands or tens of millions per tails file? Am I reading this wrong? my concern is the idea that is for the prover to prove non-revocation without correlation. Do small tails files hurt this expectation?

ardagumusalan (Fri, 08 Feb 2019 15:26:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Kjc6dJ9apezdXaDG8) @sklump (reverse-engineering was a wrong term to be used, did not describe what I meant). However, you answer makes me wonder why there is a statement regarding hundreds of thousands or tens of millions per tails file? Am I reading this wrong? my concern is the idea that is for the prover to prove non-revocation without correlation. Do small tails files hurt this expectation?

DuckLover (Fri, 08 Feb 2019 15:30:21 GMT):
Can someone help me out with this error : Casting error to ErrorCode: Invalid structure: Schema name not found in: zeugnis?

DuckLover (Fri, 08 Feb 2019 15:30:34 GMT):
Maybe some more background info about it ...

DuckLover (Fri, 08 Feb 2019 15:30:50 GMT):
coming soon

DuckLover (Fri, 08 Feb 2019 15:32:01 GMT):

invalid structure.png

smithbk (Fri, 08 Feb 2019 19:02:14 GMT):
It is possible to build a proof request with a logical OR, correct? For example, attribute foo from cred_def_id1 OR cred_def_id2. Can someone point me to a sample or doc on the syntax of how to do this?

danielhardman (Fri, 08 Feb 2019 19:07:05 GMT):
@xnopre AuthCrypt is signed using sender

danielhardman (Fri, 08 Feb 2019 19:07:05 GMT):
@xnopre AuthCrypt is signed using sender's *private* key.

danielhardman (Fri, 08 Feb 2019 19:07:05 GMT):
@xnopre AuthCrypt is encrypted/signed using sender's *private* key.

smithbk (Fri, 08 Feb 2019 19:18:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=92uGK9hQdsdHgYCf4) nm, found it ... just an array of issuer DIDs ... https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/tests/anoncreds/test_prover_get_credentials_for_proof_req.py#L220

sklump (Fri, 08 Feb 2019 19:44:58 GMT):
@smithbk I believe those are ANDs but I could be wrong

DuckLover (Fri, 08 Feb 2019 22:05:32 GMT):
how do i get an id of a schema that already exists by using the name in nodejs?

mgbailey (Fri, 08 Feb 2019 22:56:46 GMT):
@DuckLover Since this would be done infrequently, I would just use indy-cli to do it, and then store the result in a config parameter: pool(testnet):wallet(testnet_wallet):did(Mo9...Fxe):indy> ledger get-schema did=CCTmyMYVyqGaYyopJWfxe6 name="degree schema" version=0.5 Following Schema has been received. Metadata: +------------------------+-----------------+---------------------+---------------------+ | Identifier | Sequence Number | Request ID | Transaction time | +------------------------+-----------------+---------------------+---------------------+ | Mo9gRPFVhRhKPRZxdPeFxe | 31288 | 1549666436004063893 | 2019-02-07 21:15:20 | +------------------------+-----------------+---------------------+---------------------+ Data: +---------------+---------+----------------------+ | Name | Version | Attributes | +---------------+---------+----------------------+ | degree schema | 0.5 | "major","name","gpa" | +---------------+---------+----------------------+

mgbailey (Fri, 08 Feb 2019 22:57:00 GMT):
The sequence number is what you want

Dubh3124 (Sat, 09 Feb 2019 00:02:52 GMT):
@DuckLover I usually store the schema as a wallet record of whoever created the schema.

DuckLover (Sat, 09 Feb 2019 00:17:01 GMT):
thanks guys i got it. Fighting with the next bug now :D

DuckLover (Sat, 09 Feb 2019 00:17:38 GMT):
Can someone give me a hint what the problem is when ""AnoncredsCredDefAlreadyExistsError"" happens

DuckLover (Sat, 09 Feb 2019 00:18:08 GMT):
I was calling this function

DuckLover (Sat, 09 Feb 2019 00:18:09 GMT):
await sdk.signAndSubmitRequest(await indy.pool.get(), await indy.wallet.get(), await indy.did.getEndpointDid(), credDefRequest);

DuckLover (Sat, 09 Feb 2019 00:19:05 GMT):
"IndyError: CommonInvalidParam3" Thats what the log says :thinking:

DuckLover (Sat, 09 Feb 2019 01:07:48 GMT):
Maybe someone can give me a hint on my current problem. I created in in the demo based on nodejs a button for issueing Alice her Transcript directly and created for this a new api endpoint: ``` router.post('/issuer/send_transcript_credential_offer', auth.isLoggedIn, async function (req, res) { try { await indy.issuer.createSchema("zeugnis", "1.0", "[\"name\", \"hochschule\", \"studiengang\", \"matrikelnummer\"]"); } catch (e) { console.warn('create schema failed with message: ' + e.message); throw e; } let credDefId; try { let schemaId= "" + await indy.did.getEndpointDid() + ":2:zeugnis:1.0"; //await indy.issuer.createCredDef(schema_id, "WHS_Zeugnis"); let schema = await indy.issuer.getSchema(schemaId); let [credDefId, credDefJson] = await sdk.issuerCreateAndStoreCredentialDef(await indy.wallet.get(), await indy.did.getEndpointDid(), schema, 'WHS_Zeugnis', 'CL', '{"support_revocation": false}'); let credDefRequest = await sdk.buildCredDefRequest(await indy.did.getEndpointDid(), credDefJson); await sdk.signAndSubmitRequest(await indy.pool.get(), await indy.wallet.get(), await indy.did.getEndpointDid(), credDefRequest); await indy.did.pushEndpointDidAttribute('credential_definitions', credDefJson); } catch (e) { console.warn('create CredDef failed with message: ' + e.message); throw e; } finally { //await indy.issuer.getCredDefByTag("WHS_Zeugnis") await indy.credentials.sendOffer(req.body.their_relationship_did, credDefId); } res.redirect('/#issuing'); }); ``` I dont see where i create this CredDef before and why this error occurs: "faber_1 | ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Credential definition already exists: CredentialDefinition for cred_def_id: "6AzDfk6bPJLp31e7wy1FQd:3:CL:24:WHS_Zeugnis" already exists"

DuckLover (Sat, 09 Feb 2019 01:08:39 GMT):
It seems like it break at await sdk.signAndSubmitRequest

DuckLover (Sat, 09 Feb 2019 15:39:54 GMT):
I shortend my api method: ``` router.post('/issuer/send_transcript_credential_offer', auth.isLoggedIn, async function (req, res) { try { await indy.issuer.createSchema("zeugnis", "1.0", "[\"name\", \"hochschule\", \"studiengang\", \"matrikelnummer\"]"); } catch (e) { console.warn('create schema failed with message: ' + e.message); throw e; } let credDef; try { let schemaId= "" + await indy.did.getEndpointDid() + ":2:zeugnis:1.0"; await indy.issuer.createCredDef(schemaId, "WHS_Zeugnis"); credDef = await indy.issuer.getCredDefByTag("WHS_Zeugnis"); } catch (e) { console.warn('create CredDef failed with message: ' + e.message); throw e; } finally { await indy.credentials.sendOffer(req.body.their_relationship_did, credDef.id); } res.redirect('/#issuing'); }); ``` and added ` if(await exports.getCredDefByTag(tag)==null) { `

haardikkk (Sun, 10 Feb 2019 05:11:11 GMT):
Has left the channel.

xnopre (Mon, 11 Feb 2019 08:47:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Y2AFDtR8CznetKJZd) Hi. What is your solution to get the shema ID from its name ?

xnopre (Mon, 11 Feb 2019 08:47:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Y2AFDtR8CznetKJZd) @DuckLover Hi. What is your solution to get the shema ID from its name ?

xnopre (Mon, 11 Feb 2019 09:09:37 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=B6fkJeitNyW8YAeEE) @danielhardman Hi Daniel. Thanks for your answer. If I good understand, can I say the following : - Authcrypt encrypts the message with a symmetric key produced with Diffie-Hellman : . By sender with its private key and the public key of receiver . By receiver with its private key and the public key of the sender - AuthCrypt signs the message with sender public key - Sender public key is associated to this authcrypted message, and all this block is anoncrypted Is it right ? I was a little disturbed because in Indy SDK, the method `cryptoAuthDecrypt` take only `recipientVk` as parameter, no `senderVk`. But if I'm right, it's not necessary because this sender's key is embedded in the "anoncrypted" layer of the authcrypted message. Is it right ?

xnopre (Mon, 11 Feb 2019 09:09:37 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=B6fkJeitNyW8YAeEE) @danielhardman Hi Daniel. Thanks for your answer. If I good understand, can I say the following : - Authcrypt encrypts the message with a symmetric key produced with Diffie-Hellman by sender with its private key and the public key of receiver - Receiver can produce the same symmetric key with its private key and the public key of the sender, to decrypt the authcrypted layer - AuthCrypt signs the message with sender public key - Sender public key is associated to this authcrypted message, and all this block is anoncrypted Is it right ? I was a little disturbed because in Indy SDK, the method `cryptoAuthDecrypt` take only `recipientVk` as parameter, no `senderVk`. But if I'm right, it's not necessary because this sender's key is embedded in the "anoncrypted" layer of the authcrypted message. Is it right ?

SergeyBrazhnik (Mon, 11 Feb 2019 11:03:27 GMT):
Hello everyone! Do somebody know according what principe function *issuerCreateAndStoreRevocReg* generates blob file names. Need to understand it to distinguish this file from others in directory.

sklump (Mon, 11 Feb 2019 11:56:36 GMT):
@SergeyBrazhnik it is a hash of the tails file content. Changing the file name presents problems. https://github.com/PSPC-SPAC-buyandsell/von_anchor/ uses symbolic links, rev reg id to tails file.

sklump (Mon, 11 Feb 2019 12:02:10 GMT):
QUESTION 1*: I notice that in `did.py`, method `set_endpoint_for_did()` takes a wallet handle, but `get_endpoint_for_did()` also takes a pool handle. How does endpoint (meta)data get to the ledger? Or is this an extraneous parameter? At present we work with endpoints, but write them to the ledger as attributes on NYM records. Is this approach wrong or deprecated? Thanks in advance. *QUESTION 2*: Regarding node pool configuration as indy-sdk creates it via the wrapper tests, `~/.indy_client/pool/pool1/config.json` contains ``` {"genesis_txn":"/tmp/indy_client/pool1.txn"} ``` But this is a temp file, which can not be expected to be present forever. Once it's created, does anything rely on `config.json` pointing to a file that is there, or is this historical information as long as the `pool1/pool1.txn` is present and correct?

sklump (Mon, 11 Feb 2019 12:02:10 GMT):
*QUESTION 1*: I notice that in `did.py`, method `set_endpoint_for_did()` takes a wallet handle, but `get_endpoint_for_did()` also takes a pool handle. How does endpoint (meta)data get to the ledger? Or is this an extraneous parameter? At present we work with endpoints, but write them to the ledger as attributes on NYM records. Is this approach wrong or deprecated? Thanks in advance. *QUESTION 2*: Regarding node pool configuration as indy-sdk creates it via the wrapper tests, `~/.indy_client/pool/pool1/config.json` contains ``` {"genesis_txn":"/tmp/indy_client/pool1.txn"} ``` But this is a temp file, which can not be expected to be present forever. Once it's created, does anything rely on `config.json` pointing to a file that is there, or is this historical information as long as the `pool1/pool1.txn` is present and correct?

SergeyBrazhnik (Mon, 11 Feb 2019 12:47:50 GMT):
@sklump Thanks for response!

TelegramSam (Mon, 11 Feb 2019 15:13:43 GMT):
It appears that crypto.crypto_verify() in the python wrapper (indy_crypto_verify in the indysdk api layer) will only validate a signature if the signer_vk is stored in the wallet. Is that true?

TelegramSam (Mon, 11 Feb 2019 15:54:08 GMT):
nevermind. it apears that validating the key does nothing useful at this point.

tomislav (Mon, 11 Feb 2019 16:00:31 GMT):
crypto_verify doesn't take a wallet as parameter, unlike crpto_sign, since it needs the private key

theoturner (Mon, 11 Feb 2019 16:03:16 GMT):
Hello all, I am using the Python wrapper and getting a `CommonInvalidStructure` error on proof creation, specifically in `prover_search_credentials_for_proof_req()`. The error is intermittent, if run on the exact same data, it occurs approx 1 in every 3 runs.

theoturner (Mon, 11 Feb 2019 16:05:26 GMT):
Any ideas?

theoturner (Mon, 11 Feb 2019 16:11:35 GMT):
That function in the code: https://github.com/hyperledger/indy-sdk/blob/6c75148f6bfa77902c3dec46f6a2a228d76885cc/wrappers/python/indy/anoncreds.py#L933

theoturner (Mon, 11 Feb 2019 16:12:03 GMT):
Currently, my workaround is to tear down the connection and ask the actors to try again.

TelegramSam (Mon, 11 Feb 2019 16:13:59 GMT):
@tomislav Errors I'm chasing: ```_indy_loop_callback: Function returned error (, 'Error: Wallet item not found\n Caused by: Walelt item not found\n') _indy_loop_callback: Function returned error (, 'Error: Invalid structure\n Caused by: Invalid bytes for "Signature"\n')```

theoturner (Mon, 11 Feb 2019 16:16:21 GMT):
Good to see it's on the roadmap :)

theoturner (Mon, 11 Feb 2019 16:16:34 GMT):
Loving the Python wrapper

theoturner (Mon, 11 Feb 2019 16:20:10 GMT):
The error code: `WARNING:indy.libindy:_do_call: Function indy_prover_search_credentials_for_proof_req returned error 113`

tomislav (Mon, 11 Feb 2019 16:49:35 GMT):
@TelegramSam 212 code thrown when calling "crypto_verify"?

TelegramSam (Mon, 11 Feb 2019 16:50:01 GMT):
@tomislav yes.

tomislav (Mon, 11 Feb 2019 16:54:34 GMT):
Looks like you found a bug. I just did a quick run and I'm getting 113 if signature isn't ok, otherwise true/false, but not a 212

TelegramSam (Mon, 11 Feb 2019 16:59:54 GMT):
in a minute I'll verify that's happening.

theoturner (Mon, 11 Feb 2019 17:00:01 GMT):
@TelegramSam I may have worked out the issue my end.

theoturner (Mon, 11 Feb 2019 17:00:21 GMT):
I was using hex as my proof request nonce, changed to full numeric and now no longer failing.

TelegramSam (Mon, 11 Feb 2019 17:01:08 GMT):
@theoturner I'm not using proofs, just verifying a signature.

theoturner (Mon, 11 Feb 2019 17:01:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=YQyZ4fc36GWHxhWjw) In reference to this

TelegramSam (Mon, 11 Feb 2019 17:02:12 GMT):
Ah, sorry for the confusion.

TelegramSam (Mon, 11 Feb 2019 17:05:41 GMT):
@tomislav the 212 was caused by something else, not the `crypto_verify()`

TelegramSam (Mon, 11 Feb 2019 17:11:38 GMT):
I figured out my `crypto_verify()` issue: Had some bytes vs strings differences I sorted out.

sklump (Mon, 11 Feb 2019 17:16:37 GMT):
QUESTION 1*: I notice that in `did.py`, method `set_endpoint_for_did()` takes a wallet handle, but `get_endpoint_for_did()` also takes a pool handle. How does endpoint (meta)data get to the ledger? Or is this an extraneous parameter? At present we work with endpoints, but write them to the ledger as attributes on NYM records. Is this approach wrong or deprecated? Thanks in advance. *QUESTION 2*: Regarding node pool configuration as indy-sdk creates it via the wrapper tests, `~/.indy_client/pool/pool1/config.json` contains ``` {"genesis_txn":"/tmp/indy_client/pool1.txn"} ``` But this is a temp file, which can not be expected to be present forever. Once it's created, does anything rely on `config.json` pointing to a file that is there, or is this historical information as long as the `pool1/pool1.txn` is present and correct?

sklump (Mon, 11 Feb 2019 17:16:37 GMT):
*QUESTION 1*: I notice that in `did.py`, method `set_endpoint_for_did()` takes a wallet handle, but `get_endpoint_for_did()` also takes a pool handle. How does endpoint (meta)data get to the ledger? Or is this an extraneous parameter? At present we work with endpoints, but write them to the ledger as attributes on NYM records. Is this approach wrong or deprecated? Thanks in advance. *QUESTION 2*: Regarding node pool configuration as indy-sdk creates it via the wrapper tests, `~/.indy_client/pool/pool1/config.json` contains ``` {"genesis_txn":"/tmp/indy_client/pool1.txn"} ``` But this is a temp file, which can not be expected to be present forever. Once it's created, does anything rely on `config.json` pointing to a file that is there, or is this historical information as long as the `pool1/pool1.txn` is present and correct?

tomislav (Mon, 11 Feb 2019 18:17:03 GMT):
@sklump Endpoint gets written using ledger_build_attrib_request. There's a magic format that "endpoint" attribute must conform to, otherwise the node will throw error. Format is { "ha": "[ip_address]", "verkey": "key" }. https://github.com/hyperledger/indy-sdk/blob/79b06d9bdfebd9513989f3aefd236c0420f478b4/libindy/src/domain/ledger/attrib.rs#L87 `set_endpoint` allows you to set the endpoint information locally, for your pairwise did's. `get_endpoint` will fetch it from the ledger and set it locally as well. It will be set as did metadata.

tomislav (Mon, 11 Feb 2019 18:17:03 GMT):
@sklump Endpoint gets written using ledger_build_attrib_request. There's a magic format that "endpoint" attribute must conform to, otherwise the node will throw error. Format is { "ha": "[ip_address:port]", "verkey": "key" }. https://github.com/hyperledger/indy-sdk/blob/79b06d9bdfebd9513989f3aefd236c0420f478b4/libindy/src/domain/ledger/attrib.rs#L87 `set_endpoint` allows you to set the endpoint information locally, for your pairwise did's. `get_endpoint` will fetch it from the ledger and set it locally as well. It will be set as did metadata.

tomislav (Mon, 11 Feb 2019 18:22:18 GMT):
Additionally, address must be an IP, not a host or a URL. There's a bug that's tracking this - https://jira.hyperledger.org/browse/INDY-1456 Because of this bug, agent implementations track agent endpoints locally, and negotiate the addresses during the connection handshake

swcurran (Mon, 11 Feb 2019 18:38:09 GMT):
@tomislav - I'm hoping that endpoint issue is pretty high on the Agent builders wish list for indy-sdk and indy-node? As well as being necessary for Agent development, without that, there really is no way to build a universal resolver, since the "endpoint" convention is left to the agent - never gets to the ledger.

tomislav (Mon, 11 Feb 2019 18:40:45 GMT):
It's definitely pretty high and important to make sure agent identities are "anchored" to the ledger, it's not a blocker currently - which is probably why it's taking a bit for the team to implement it.

tomislav (Mon, 11 Feb 2019 18:41:57 GMT):
The connection protocol already defines resolvable did's, and this will push need for supporting URIs in endpoint attribute

swcurran (Mon, 11 Feb 2019 18:42:44 GMT):
Got it - thanks.

sklump (Mon, 11 Feb 2019 18:43:46 GMT):
@tomislav "ha" is not a good choice. It means high availability. Is it meant to signify 'host address' here maybe?

sklump (Mon, 11 Feb 2019 18:44:24 GMT):
I know it's been there since 2017, but I just want to register this useless quibble :-/

tomislav (Mon, 11 Feb 2019 18:46:47 GMT):
`ha` stands for "Ha! You can't use URLs here"

sklump (Mon, 11 Feb 2019 18:48:10 GMT):
And about the configuration file in pools that points to what is likely no longer a file? Is this for anything? I notice that everything runs fine once the original genesis txn file is gone, as long as the copy in the pool ledger config directory is extant.

tomislav (Mon, 11 Feb 2019 18:51:00 GMT):
I think so. The file contents seems to be copied over in the config directory and ready from there.

tomislav (Mon, 11 Feb 2019 18:51:00 GMT):
I think so. The file contents seems to be copied over in the config directory and read from there.

theoturner (Mon, 11 Feb 2019 19:25:00 GMT):
I have 2 steps: 1. Setup pool ledger config. 2. Setup Steward (i.e. create wallet). If I put these functions one after the other in the same file, the Steward handle is 4. If I put them in two separate files and run sequentially, the Steward wallet handle is 2. Why is this?

theoturner (Mon, 11 Feb 2019 19:33:15 GMT):
(Python wrapper)

sklump (Mon, 11 Feb 2019 19:49:51 GMT):
Two processes, running sequentially, will each load the library. Indy-sdk doesn't reuse handles within a process. Do not imbue any meaning to a handle ordinal in any case.

nehalshah50 (Mon, 11 Feb 2019 20:53:58 GMT):
NEED HELP ========

nehalshah50 (Mon, 11 Feb 2019 20:53:58 GMT):
NEED HELP ======== I keep getting following error when I try to run demo using Java LIBVCX wrapper ...mimicing what Pyhton demo does. Any idea? I am running everything local `com.evernym.sdk.vcx.LibVcx.native.vcx.utils.libindy.payments - src/utils/libindy/payments.rs:226 | pay_for_txn(req: {"reqId":1549918397569651000,"identifier":"V4SGRU86Z58d6TV7PBUe6f","operation":{"type":"101","data":{"name":"test111","version":"0.0.1","attr_names":["weight","attr1","height","attr2"]}},"protocolVersion":2}, txn_type: 101) 13:53:17.572 [Thread-496] INFO com.evernym.sdk.vcx.LibVcx.native.indy.commands - src/commands/mod.rs:156 | PaymentsCommand command received 13:53:17.572 [Thread-498] INFO com.evernym.sdk.vcx.LibVcx.native.payments_command_executor - src/commands/payments.rs:231 | BuildGetTxnFeesReq command received 13:53:17.574 [Thread-502] ERROR com.evernym.sdk.vcx.LibVcx.native.indy.commands.payments - src/commands/payments.rs:555 | Error: Invalid wallet handle was passed Caused by: Unknown wallet handle`

ianco (Mon, 11 Feb 2019 21:58:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=GKnSRRmHTt7m9FcZR) @nehalshah50 I suspect your wallet has been closed

nehalshah50 (Tue, 12 Feb 2019 02:37:36 GMT):
If I would like to test Java wrapper for VCX which git branch should I use? Which one is stable? I tried using 'rc' but it seems to be not stable

xtrycatchx (Tue, 12 Feb 2019 06:04:57 GMT):
Has joined the channel.

xtrycatchx (Tue, 12 Feb 2019 06:05:43 GMT):
hello. newbie questions here, may i know whats the reasoning behind why DID is in base58 encoding?

rasviitanen (Tue, 12 Feb 2019 06:57:57 GMT):
Has joined the channel.

theoturner (Tue, 12 Feb 2019 09:50:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Ruv5Bswzf2JMd4cvQ) @nehalshah50 Master works OK my end macOS & Ubuntu

theoturner (Tue, 12 Feb 2019 09:54:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=EBSvefaPtmmNZF2pP) @xtrycatchx Base58 came about with bitcoin removing 0, O, I, and l from account addresses to stop two addresses looking identical in certain fonts. + and / are also excluded vs base64 since they're alphanumeric. It is now mostly the standard in the blockchain space.

theoturner (Tue, 12 Feb 2019 09:54:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=EBSvefaPtmmNZF2pP) @xtrycatchx Base58 came about with bitcoin removing 0, O, I, and l from account addresses to stop two addresses looking identical in certain fonts. + and / are also excluded vs base64 since they're not alphanumeric. It is now mostly the standard in the blockchain space.

theoturner (Tue, 12 Feb 2019 09:59:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=2ckMF97QnKiBQyYQq) @sklump Onboarding references the handles. To broaden the question, how do I then go about onboarding actors not on the same machine?

sklump (Tue, 12 Feb 2019 11:55:38 GMT):
As long as they are all talking to the same node pool/ledger.

sklump (Tue, 12 Feb 2019 11:55:46 GMT):
no problem.

theoturner (Tue, 12 Feb 2019 11:58:39 GMT):
Let me expand, `onboarding(from, to)` which is required for virtually all inter-agent communication, demands both the `from` agent and `to` agent data structures to be fed in.

theoturner (Tue, 12 Feb 2019 11:59:24 GMT):
Unless I re-write indy's own function s to communicate sending of dids and verkeys, I can't really do anything but have all of my actors run in the same process.

theoturner (Tue, 12 Feb 2019 11:59:24 GMT):
Unless I re-write indy's own functions to communicate sending of dids and verkeys, I can't really do anything but have all of my actors run in the same process.

theoturner (Tue, 12 Feb 2019 12:00:12 GMT):
i.e. the onboarding abstractions as implemented currently are not useable in real-world applications.

theoturner (Tue, 12 Feb 2019 12:00:18 GMT):
Or is there something I'm missing?

sklump (Tue, 12 Feb 2019 12:04:43 GMT):
I don't know that part of the sdk. Others?

theoturner (Tue, 12 Feb 2019 12:09:56 GMT):
I'm guessing that `onboarding` is meant as an example use of the underlying `ledger`, `wallet` and `did` libraries, rather than as a function to be used for onboarding. Will try to set up my own inter-agent communication and report back, hopefully can contribute a nice 'onboarding' abstraction.

theoturner (Tue, 12 Feb 2019 12:10:29 GMT):
Likewise `get_verinym()`

theoturner (Tue, 12 Feb 2019 13:38:50 GMT):
Before I can call auth_crypt as Alice, Bob needs to have sent the key he has for Alice. ``` crypto.auth_crypt(alice['wallet'], alices_key_for_bob, bobs_key_for_alice, alice['did_info'].encode('utf-8')) ``` Do I need to implement Bob sending his key for Alice to Alice, or is there some way to get `bobs_key_for_alice` from the ledger as Alice given what I know about Bob?

theoturner (Tue, 12 Feb 2019 14:07:19 GMT):
It is seemingly a public key if I'm interpreting code comments correctly.

rasviitanen (Tue, 12 Feb 2019 14:07:43 GMT):
Hey, I recently discovered indy-sdk and decided to check the rust how-to's. The rust-wrapper export to a crate named "indyrs", which means that the "extern crate indy;" that is seen in every import of the rust how-to's does not compile. I just wanted to double check if this indeed is a bug, of if I am mistaken, should I report this in jira?

ianco (Tue, 12 Feb 2019 14:42:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ZYS63WTDMtYJPG8st) @theoturner You probably need a higher level agent-to-agent protocol. There are a few in development (and the protocols are in the process of being standardized), but you can look at VCX (in the indy-sdk repo) or the python version of indy-agent (separate repo)

ianco (Tue, 12 Feb 2019 14:42:57 GMT):
VCX is more "feature complete" (you can establish connections, issue credentials and request proofs) but indy-agent (python) is a slightly simpler implementation ... depending what you want

theoturner (Tue, 12 Feb 2019 15:22:55 GMT):
Thanks, yes ended up creating my own messaging.

theoturner (Tue, 12 Feb 2019 16:47:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ZYS63WTDMtYJPG8st) Answer to this was Alice sends DID in plain, Bob uses the `anon_crypt` scheme to send his `verkey` to Alice, Alice likewise to Bob, then it is possible to proceed with any `auth_crypt` stuff.

SergeyBrazhnik (Tue, 12 Feb 2019 18:15:20 GMT):
Hello everyone! Could someone advice why on *indy_prover_create_proof* I getting *Casting error to ErrorCode: Item not found* ?

MattRaffel (Tue, 12 Feb 2019 20:16:57 GMT):
@SergeyBrazhnik There's a number of steps before getting to the proint of creating a proof. Since its not clear, can you give more details? Also can you give us a trace of the output? if you haven't I suggest looking at one of the samples, such as https://github.com/hyperledger/indy-sdk/blob/e5bd53c498c5be2ce848bd70590ef86b3fe8996a/samples/java/src/main/java/Anoncreds.java#L130 my apologizes if you have. I didn't have much info to go on unfortunately

MattRaffel (Tue, 12 Feb 2019 20:16:57 GMT):
@SergeyBrazhnik There's a number of steps before getting to the proint of creating a proof. Since its not clear what steps got you to indy_create_proof, can you give more details? Also can you give us a trace of the output? if you haven't I suggest looking at one of the samples, such as https://github.com/hyperledger/indy-sdk/blob/e5bd53c498c5be2ce848bd70590ef86b3fe8996a/samples/java/src/main/java/Anoncreds.java#L130 my apologizes if you have. I didn't have much info to go on unfortunately

DuckLover (Tue, 12 Feb 2019 22:05:23 GMT):
Hello, i use Nodejs and im trying to add another Schema and CredentialDef to the ledger at the startup from an agent. I create it like the GovID ist created by using `[whsIdCredDefId, whsIdCredDef] = await sdk.issuerCreateAndStoreCredentialDef(stewardWallet, stewardDid, whsIdSchema, 'WID', signatureType, '{"support_revocation": false}')` but i get the error `alice_1 | ReferenceError: whsIdCredDefId is not defined alice_1 | at issueWhsIdCredential (/~/nodejs/indy/src/did/index.js:223:6) alice_1 | at ` What could be the problem?

DuckLover (Tue, 12 Feb 2019 22:05:23 GMT):
Hello, i use Nodejs and im trying to add another Schema and CredentialDef to the ledger at the startup from an agent. I create it like the GovID ist created by using `[whsIdCredDefId, whsIdCredDef] = await sdk.issuerCreateAndStoreCredentialDef(stewardWallet, stewardDid, whsIdSchema, 'WID', signatureType, '{"support_revocation": false}')` but i get the error ```alice_1 | ReferenceError: whsIdCredDefId is not defined alice_1 | at issueWhsIdCredential (/~/nodejs/indy/src/did/index.js:223:6) alice_1 | at ``` What could be the problem?

Artemkaaas (Wed, 13 Feb 2019 05:09:27 GMT):
@SergeyBrazhnik `Casting error to ErrorCode: Item not found* ` means some entity not found in prover wallet. For `indy_prover_create_proof` it can be thrown in two cases: * not found `MasterSecret` that correspond to passed `master_secret_id` * not found any of `Credentials` that correspond to `cred_id` insde `requested_credentials` json.

SergeyBrazhnik (Wed, 13 Feb 2019 09:22:19 GMT):
@Artemkaaas Thanks for reply! It turns out that problem was in cred_id name

SergeyBrazhnik (Wed, 13 Feb 2019 09:22:41 GMT):
It'w not good to store cred_id as json object :-)

uNmAnNeR (Wed, 13 Feb 2019 13:23:33 GMT):
Has joined the channel.

uNmAnNeR (Wed, 13 Feb 2019 13:27:41 GMT):
hi all! I wonder if indy is able to handle parallel requests to ledger? I run about 5 requests in parallel and constantly get `LedgerInvalidTransaction` exception, but none if running serially. May be there is some option in SDK or ledger to fix it?

uNmAnNeR (Wed, 13 Feb 2019 13:52:07 GMT):
indy error: `indy::errors::indy Casting error to ErrorCode: Invalid transaction: Invalid response type: Object({"op": String("REPLY"), "result": Object({...}) ... ... indy::errors::indy src\errors\indy.rs 73]`

mgbailey (Wed, 13 Feb 2019 14:59:56 GMT):
@uNmAnNeR The default database for libindy (wallets, etc.) is sqllite, which is *not* multithreaded.

mgbailey (Wed, 13 Feb 2019 14:59:56 GMT):
@uNmAnNeR The default database for libindy (wallets, etc.) is sqllite, which is *not* multithread-friendly

ShivanshVij (Wed, 13 Feb 2019 17:31:50 GMT):
Does anyone know the exact reason for this error: `(created_credential, _, _) = await anoncreds.issuer_create_credential(wallet_handle, json.dumps(cred_offer), json.dumps(cred_request), json.dumps(cred_values_json), None, None) File "/usr/local/lib/python3.7/site-packages/indy/anoncreds.py", line 325, in issuer_create_credential issuer_create_credential.cb) indy.error.IndyError: ErrorCode.CommonInvalidStructure`

theoturner (Wed, 13 Feb 2019 19:22:23 GMT):
@ShivanshVij Check your nonces/randoms. I had this repeatedly before and going fully numeric (rather than say hex) fixed it.

ShivanshVij (Wed, 13 Feb 2019 19:26:13 GMT):
Got it

ardagumusalan (Wed, 13 Feb 2019 20:36:18 GMT):
Hi @sklump For the record, I have been told today that a tails file entry size of at least 10000 is recommended.

nehalshah50 (Wed, 13 Feb 2019 20:49:54 GMT):
==NEED HELP=== I am trying to use VCX java wrapper to mimic what's done VCX python demo faber.py . I am having trouble creating and sending credential to Alice. After in-depth investigation and comparing how python demo works it looks like python is using *issuer_credential* api functions while for Java these functions are not available. For Java wrapper it is using *credential* api functions When i run my java code i keep getting following error com.evernym.sdk.vcx.LibVcx.native.vcx.utils.libindy.error_codes - src/utils/libindy/error_codes.rs:24 | indy-sdk error code: 113 13:40:28.354 [Thread-2846] WARN com.evernym.sdk.vcx.LibVcx.native.vcx.api.credential - src/api/credential.rs:271 | vcx_credential_send_request_cb(command_handle: 19, rc: This Credential Error had a value: 1080) source_id: alice_degree 13:40:28.354 [Thread-2847] DEBUG CredentialApi - callback() called with: command_handle = [19], err = [1080]

DuckLover (Thu, 14 Feb 2019 00:55:30 GMT):
Hello, can anyone help me with this line of code `let credOffer = await sdk.issuerCreateCredentialOffer(await indy.wallet.get(), credentialDefinitionId);` and why it throws a `Casting error to ErrorCode: Item not found` Error?

TammyPlatero (Thu, 14 Feb 2019 00:59:21 GMT):
Question about the cli. When I create a wallet in the cli I can see that it creates a wallet sqlite.db file and a wallet .json file in a folder named "wallets" in the .indy_client folder. However, when I run the create wallet and open wallet function in my code I only see the sqlite.db files created for wallets in a "wallet" folder in .indy_client. I'm assuming the json file is being created somewhere but I don't know where it's located. Or, is that something I need to add to my create wallets functions to return a wallet .json file?

xtrycatchx (Thu, 14 Feb 2019 04:05:33 GMT):
Thanks @theoturner , it makes sense now. Another question, what is the signing algorithm used in the indy_crypto_sign using my VerKey? hmacshasomething?

DuckLover (Thu, 14 Feb 2019 04:25:41 GMT):
Can anybody tell what this code mean and how to prevent it? `Casting error to ErrorCode: Invalid transaction: Cannot deserialize transaction Response: Error("data did not match any variant of untagged enum Reply"`

DuckLover (Thu, 14 Feb 2019 04:37:00 GMT):
i was trying to get a schema by its id when it happend

DuckLover (Thu, 14 Feb 2019 04:37:41 GMT):
`whsIdSchema = await indy.issuer.getSchema(whsIdSchemaId);`

Artemkaaas (Thu, 14 Feb 2019 06:05:13 GMT):
@DuckLover question 1 - it means that there is no `CredentialDefinition` stored with ``credentialDefinitionId` in the wallet correspondent to wallet handle returned by `await indy.wallet.get()` question 2 - could you share logs? what getSchema function does internally? Do you call `get_response_metadata` inside? It seems response you got for getSchema is broken.

Artemkaaas (Thu, 14 Feb 2019 06:11:12 GMT):
@TammyPlatero if you work with Libindy directly it will create `wallet` folder and store .db file there. Indy CLI creates additional `wallets` folder and stores json file there. This json contains some wallet configuration like `id`, `storage_type` and else to avoid passing these data as params on each wallet CLI command.

Artemkaaas (Thu, 14 Feb 2019 06:15:23 GMT):
@xtrycatchx Libindy use libsodium `crypto_sign_ed25519_detached` function.

xnopre (Thu, 14 Feb 2019 08:43:44 GMT):
Hi all. The python demo in lib VCX (https://github.com/hyperledger/indy-sdk/tree/master/vcx/wrappers/python3/demo) is using the `Dummy cloud agent` (https://github.com/hyperledger/indy-sdk/tree/master/vcx/dummy-cloud-agent) : is this agent usable "out of the box" ? Or is there missing some things or feature (perhaps persistent and other) ? Thanks

xnopre (Thu, 14 Feb 2019 08:43:44 GMT):
Hi all. 1/ The python demo in lib VCX (https://github.com/hyperledger/indy-sdk/tree/master/vcx/wrappers/python3/demo) is using the `Dummy cloud agent` (https://github.com/hyperledger/indy-sdk/tree/master/vcx/dummy-cloud-agent) : is this agent usable "out of the box" ? Or is there missing some things or feature (perhaps persistent and other) ? 2/ Reading this HIPE (https://github.com/hyperledger/indy-hipe/tree/master/text/0020-encryption-primitives), I don't understand how the receiver can decrypt the message (i.e. generate symmetric key) without knowledge about the random initial key ? The method `cryptoAnonDecrypt ( wh, recipientVk, encryptedMsg )` take only `recipientVk`... Unless the public random initial key is packed inside the encrypted message ? Thanks

uNmAnNeR (Thu, 14 Feb 2019 12:43:21 GMT):
@mgbailey thanks for reply. It seems the error occures while requesting entities from remote ledger. And also we use single-threaded nodejs server. If it still an issue unfortunately i was not able to find some way to change indy store from nodejs wrapper. Is it possible? Or may be you know what are some other reasons could be? Also i wonder if someone has tested indy performance. By our expirience indy is able to handle near 5 proof create-verify requests per second with many entity caches. But what to do if we want more?

SergeyBrazhnik (Thu, 14 Feb 2019 14:20:33 GMT):
Hello everyone. Could someone advice if I getting false on *verifierVerifyProof* how can I understand what exactly went wrong?

MattRaffel (Thu, 14 Feb 2019 14:21:58 GMT):
@SergeyBrazhnik the rust logs, while verbose, are usually the best. This is in the documentation so please verify I am right: set the environment variable `RUST_LOG` to trace

SergeyBrazhnik (Thu, 14 Feb 2019 14:22:28 GMT):
@MattRaffel thx for fast reply. Checking now

Artemkaaas (Thu, 14 Feb 2019 14:29:49 GMT):
@SergeyBrazhnik which wrapper do you use?

Artemkaaas (Thu, 14 Feb 2019 14:29:49 GMT):
@SergeyBrazhnik which wrapper do you use? setting env variable doesn't help now

SergeyBrazhnik (Thu, 14 Feb 2019 14:30:31 GMT):
@Artemkaaas nodejs

Artemkaaas (Thu, 14 Feb 2019 14:30:56 GMT):
call `setDefaultLogger` function

SergeyBrazhnik (Thu, 14 Feb 2019 14:31:14 GMT):
I have enabled log and got this *[17:29:49,709 DEBUG]-[indy::commands::anoncreds::verifier verify_proof <<< result: false indy::commands::anoncreds::verifier src/commands/anoncreds/verifier.rs 126]*

Artemkaaas (Thu, 14 Feb 2019 14:31:17 GMT):
in the beginning

SergeyBrazhnik (Thu, 14 Feb 2019 14:31:30 GMT):
not much info unfortunalelly

SergeyBrazhnik (Thu, 14 Feb 2019 14:31:30 GMT):
not much info unfortunatelly

Artemkaaas (Thu, 14 Feb 2019 14:33:36 GMT):
well... it means `proof` passed validation but calculations did not agree

Artemkaaas (Thu, 14 Feb 2019 14:33:54 GMT):
can you share code?

SergeyBrazhnik (Thu, 14 Feb 2019 14:35:09 GMT):
that means that *proof* that counerparty send was correctly generated?

mgbailey (Thu, 14 Feb 2019 15:03:26 GMT):
@uNmAnNeR I can't think of a reason related to loading of the ledger for an invalid transaction response. We regularly test loading (from muliple sources) and achieve 10 tps.

uNmAnNeR (Thu, 14 Feb 2019 15:07:44 GMT):
@mgbailey okay, 10 looks better, at least now i know exact indy limitations. Thanks!

TammyPlatero (Thu, 14 Feb 2019 17:45:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Q2MG4pSPY3A7PT9zb) @Artemkaaas Does the cli call the same libindy dll? I just want to create the same json the cli does.

ianco (Thu, 14 Feb 2019 18:18:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=KyG5LYWXxSM7ePBMY) @TammyPlatero Yes the CLI uses the same libindy dll. The json files are just so the CLI can keep track of its own (known) wallets

TammyPlatero (Thu, 14 Feb 2019 19:18:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=zu459F4BSPaRpdvfi) @ianco Ok, awesome. The reason I ask about the json is because I want to query the pool I've created (with the cli) with some existing wallets but the existing wallets are not listed when I do a "wallet list" command. But, I did notice it would list the wallets that had .json. So it sounds like the cli must need to know, or have those wallets exported to a json format so the cli knows about them.

ianco (Thu, 14 Feb 2019 19:34:00 GMT):
You can do a "wallet import" in the CLI, just a sec I'll look up the command

ianco (Thu, 14 Feb 2019 19:34:44 GMT):
Try "wallet attach help"

TammyPlatero (Thu, 14 Feb 2019 19:35:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=g9xQ4HbFZHNqionaf) @ianco Aw, thank you! I was messing around with that the other day - so I'll take another crack at it

nehalshah50 (Thu, 14 Feb 2019 20:05:38 GMT):
Getting error when trying to send credential. I am using Java VCX Wrapper to simulate Python Demo on a mac machine. Any help would be appreciated. Not sure it is because the message size is very big while sending credential?? # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fff6dc5d712, pid=55775, tid=0x000000000000a003 # # JRE version: Java(TM) SE Runtime Environment (8.0_152-b16) (build 1.8.0_152-b16) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.152-b16 mixed mode bsd-amd64 compressed oops) # Problematic frame: # C [libsystem_platform.dylib+0x1712] _platform_strlen+0x12 # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. #

nehalshah50 (Thu, 14 Feb 2019 20:05:38 GMT):
Getting error when trying to send credential. I am using Java VCX Wrapper to simulate Python Demo on a mac machine. Any help would be appreciated. Not sure it is because the message size is very big while sending credential?? 13:24:49.845 [Thread-4938] DEBUG com.evernym.sdk.vcx.LibVcx.native.vcx.issuer_credential - src/issuer_credential.rs:236 | issued credential: alice_degree # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007fff6dc5d712, pid=55775, tid=0x000000000000a003 # # JRE version: Java(TM) SE Runtime Environment (8.0_152-b16) (build 1.8.0_152-b16) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.152-b16 mixed mode bsd-amd64 compressed oops) # Problematic frame: # C [libsystem_platform.dylib+0x1712] _platform_strlen+0x12 # # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. #

TammyPlatero (Thu, 14 Feb 2019 23:40:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qeeYApTS8828wXaTM) yup! that was it, just wanted to thank you again :D

dphhyland (Fri, 15 Feb 2019 06:31:00 GMT):
Getting an error from Libindy when attempting to build a cred Def Request. Message I'm seeing is a 113 CommonInvaldStructure, when looking into the trace its seeming to fail on splitting the credDefId. INFO|indy::services::ledger | src/services/ledger/mod.rs:200 | build_get_cred_def_request >>> identifier: Some("Th7MpTaRZVRYnPiabds81Y"), id "Th7MpTaRZVRYnPiabds81Y:3:CL:Th7MpTaRZVRYnPiabds81Y:2:academicTranscript:2.0:TAG" ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Invalid structure: Schema ID not found in: Th7MpTaRZVRYnPiabds81Y:3:CL:Th7MpTaRZVRYnPiabds81Y:2:academicTranscript:2.0:TAG TRACE|indy::api::ledger | src/api/ledger.rs:836 | indy_build_get_cred_def_request: request_json: "" using a build from 1.6.x can't see what I'm doing wrong...

Artemkaaas (Fri, 15 Feb 2019 08:57:08 GMT):
@dphhyland It is important Get Schema from Ledger and parse it to get the correct Schema JSON and correspondent it seq_no in Ledger. After that we can create CredentialDefinition for received Schema(not for result of indy_issuer_create_schema) instead of `Th7MpTaRZVRYnPiabds81Y:3:CL:Th7MpTaRZVRYnPiabds81Y:2:academicTranscript:2.0:TAG` will be something like `Th7MpTaRZVRYnPiabds81Y:3:{schema_seq_no}:TAG`

xnopre (Fri, 15 Feb 2019 10:25:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=edq9DSvAZXcoxip4N) Any idea ? Nobody ? ... :-)

ianco (Fri, 15 Feb 2019 11:36:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=edq9DSvAZXcoxip4N) @xnopre I'm not the authoritative expert, but my understanding is the dummy-cloud-agent is usable "out-of-the-box" however it has some limitations (or maybe bugs). For example when a connection is established the credentials can only be sent in one direction. However all the other functionality that I've tested (connections, credentials, proofs) works.

DuckLover (Fri, 15 Feb 2019 16:03:09 GMT):
What could be the problem that ` [whsIdCredDefId, whsIdCredDef] = await sdk.issuerCreateAndStoreCredentialDef(stewardWallet, stewardDid, whsIdSchema, 'WID', signatureType, '{"support_revocation": false}');` throws the error: `ReferenceError: whsIdCredDefId is not defined`

DuckLover (Fri, 15 Feb 2019 16:59:27 GMT):
Can anyone help me why after calling this function `await indy.credentials.sendOffer((req.body.their_relationship_did, "Th7MpTaRZVRYnPiabds81Y:3:CL:17:WID"));` the following error happens `CommonInvalidParam3`

PatrikStas (Fri, 15 Feb 2019 17:00:19 GMT):
@xnopre I was playing with it just today and can confirm the python demo works like a charm together with the dummy agent. I am actually trying to port the python demo into nodejs right now.

PatrikStas (Fri, 15 Feb 2019 17:05:44 GMT):
@DuckLover Are you using libindy or libvcx? Is it javascript or python wrapper (or other?) ?

DuckLover (Fri, 15 Feb 2019 18:09:32 GMT):
i use nodejs

DuckLover (Fri, 15 Feb 2019 18:09:39 GMT):
extending the reference client

xnopre (Fri, 15 Feb 2019 18:11:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6HQsyA95apEaS8A2W) @PatrikStas Great for the migration from Python to NodeJS ! :+1: :-) . Will you share it into `indy-sdk` project with a PR ? ;-)

PatrikStas (Fri, 15 Feb 2019 18:52:40 GMT):
@xnopre for sure! I ported just a bit of faber.py, it's failing on creating schema, but it connects to dummy cloud agency, creates the "virtual agent" - that initia part works. So if you'd decide to try to push it further today or over the weekend, we can combine our work. Here's what I've done so far https://github.com/Patrik-Stas/indy-sdk/blob/feature/node-vcx-demo/vcx/wrappers/node/demo/faber.js

PatrikStas (Fri, 15 Feb 2019 18:53:32 GMT):
Btw I brought in babel-node dev-dep in there, but I'll remove it later

ardagumusalan (Fri, 15 Feb 2019 20:08:54 GMT):
Hi, what is the rule for the current timestamps format at indy? I usually see a large integer, asusming it indicate a time since some other time. Thanks

ardagumusalan (Fri, 15 Feb 2019 20:08:54 GMT):
Hi, what is the rule for the current timestamps format at indy? I usually see a large integer, asusming it indicates a time since some other time. Thanks

kdenhartog (Fri, 15 Feb 2019 22:25:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=edq9DSvAZXcoxip4N) @xnopre the ephemeral public key is appended to the ciphertext by the underlying APIs in libsodium. So the AnonDecrypt calls a function that knows how to parse the key off and use that to decrypt the message.

dphhyland (Sat, 16 Feb 2019 02:24:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=hpfNwPHyfArQGyNzf) @Artemkaaas Thanks @Artemkaaas so I can't use the cred def id provided within the offer? Do a need to build the id using the seq number I see I can get from the buildGetSchemaRequest?

Artemkaaas (Mon, 18 Feb 2019 05:36:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kpZMeffRBQuGqvTrh) @dphhyland cred def id within an offer will be correct if you created a cred def a proper way (got a schema from the ledger before creation)

Artemkaaas (Mon, 18 Feb 2019 05:42:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wv2HEqWSEDs9bcYHm) @ardagumusalan it's unix time stamp

dphhyland (Mon, 18 Feb 2019 09:35:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=DjdZHNGCRuZtJiMuh) @Artemkaaas Got it - perfect. Thanks

xnopre (Mon, 18 Feb 2019 10:55:31 GMT):
@PatrikStas Great ! For your information, I had contributed on "how-tos" scripts (for example https://github.com/hyperledger/indy-sdk/tree/master/docs/how-tos/write-did-and-query-verkey/nodejs, even if my name has disappeared...) and on "samples" script (for example https://github.com/hyperledger/indy-sdk/blob/master/samples/nodejs/src/anoncredsRevocation.js). You can take a look of what I put in place around NodeJs, perhaps to have something similar... And I will follow your work on migrating the demo to NodeJs ;-)

xnopre (Mon, 18 Feb 2019 11:23:11 GMT):
Hi all :-) . I have a message authcrypted. If I good understood, the message is encrypted twice : 1/ First with a symmetric key generated with DH with "private sender key" + "public receiver key" 2/ Second with a symmetric key generated with DH with "random key" + "public receiver key" (= anoncrypt) (source : https://github.com/hyperledger/indy-hipe/tree/master/text/0020-encryption-primitives) I try to "manual" decrypt my message following this two steps : 1/ I can "anondecrypt" the message with `cryptoAnonDecrypt()` function, it works, I get a new smaller buffer 2/ But then, who can I do the decryption with the symmetric key based on both sender and receiver key ? In `indy-sdk`, is there a function to do that ? Thanks (cc @kdenhartog @danielhardman )

kdenhartog (Mon, 18 Feb 2019 11:35:06 GMT):
To make sure I'm understanding this correctly, you're authcrypting a message then Anondecrypting the encrypted message? I'd suggest using auth_decrypt instead to fully decrypt the message. As far as I understand it is not possible to decrypt an authcrypted message any other way because the underlying function from libsodium called box requires a private key and there's not a publicly exposed API that returns a private key ever.

xnopre (Mon, 18 Feb 2019 12:36:00 GMT):
@kdenhartog Yes, that's it ! :-) I'm exploring a way to store crypted message, and decrypt it with sender key. Authcrypted message can of course be authdecrypted, using only receiver key (the sender public key is packed inside the crypted message). My idea is to do a first decryption of received message (this is the "anondecrypt" layer), store this result, and then, decrypt it. For this, if I good understood, I have to use sender public key+receiver private key. Hence my question ;-)

kdenhartog (Mon, 18 Feb 2019 14:13:04 GMT):
You could generate a separate key for storage and Anoncrypt everything for storage. Alternatively if it's just lightweight stuff you can use the wallet storage APIs and they encrypt the data using the wallet credentials. Blob storage may do this as well, but I haven't looked into that API much yet.

ardagumusalan (Mon, 18 Feb 2019 15:56:43 GMT):
Is there currently a way for a prover to respond to a proof request with whatever credential the prover thinks might be necessary? Let's assume the verifier sends a blank proof request and the prover knows what it is for. Is it possible for the prover to send a custom proof back in response to this black proof request? The sole role of verifier here is to verify the validity of the credentials included in the proof.

DuckLover (Mon, 18 Feb 2019 16:20:00 GMT):
Does anyone has implemented credential revocation in the nodejs reference agents? Saw some parameters in the functions but not sure what it needs to be done or how much time it needs to fully implement it

jljordan_bcgov (Mon, 18 Feb 2019 17:40:51 GMT):
unlikely

PatrikStas (Mon, 18 Feb 2019 17:56:18 GMT):
Hey guys, I am porting Python VCX demo to NodeJS but I bumped into a blocker. I am having trouble with logging and I can't figure it out. I have compiled `libindy`, `libvcx` and `libnullplay` by running `cargo build` and the result was always located in `./target/debug`, so it should have logging enabled. I can run the Rust `Dummy Cloud Agent` like this `RUST_LOG='indy=trace' cargo run sample-config.json` and I can see all the indy logs just fine. The problem comes when I run basically any wrapper code - whether it's python or nodejs. I do simple `RUST_LOG=trace`, yet I see nothing. To reproduce, you can take this code ``` var indy = require('./') var cuid = require('cuid') async function testWallet () { var walletConfig = { 'id': 'wallet-' + cuid() } var walletCredentials = { 'key': 'key' } await indy.createWallet(walletConfig, walletCredentials) await indy.openWallet(walletConfig, walletCredentials) } testWallet() ``` And place into file within root directory of `nodejs` wrapper for `indy-sdk`. Then run by `node `. Do you see any Indy logs? I don't have any. A guidance or any tips on this would be very appreciated!

PatrikStas (Mon, 18 Feb 2019 17:56:18 GMT):
Hey guys, I am porting Python VCX demo to NodeJS but I bumped into a blocker. I am having trouble with logging and I can't figure it out. I have compiled `libindy`, `libvcx` and `libnullplay` by running `cargo build` and the result was always located in `./target/debug`, so it should have logging enabled. I can run the Rust `Dummy Cloud Agent` like this `RUST_LOG='indy=trace' cargo run sample-config.json` and I can see all the indy logs just fine. The problem comes when I run basically any wrapper code - whether it's python or nodejs. I do simple `RUST_LOG=trace`, yet I see nothing. To reproduce, you can take this code ``` var indy = require('./') var cuid = require('cuid') async function testWallet () { var walletConfig = { 'id': 'wallet-' + cuid() } var walletCredentials = { 'key': 'key' } await indy.createWallet(walletConfig, walletCredentials) await indy.openWallet(walletConfig, walletCredentials) } testWallet() ``` And place into file within root directory of `nodejs` wrapper for `indy-sdk`. Then run by `RUST_LOG=trace node `. Do you see any Indy logs? I don't have any. A guidance or any tips on this would be very appreciated!

PatrikStas (Mon, 18 Feb 2019 17:58:50 GMT):
I was trying the libraries compiled off master branch, version 1.80 and 1.7.0. But no success.

PatrikStas (Mon, 18 Feb 2019 17:58:50 GMT):
I was trying the libraries compiled off master branch, version 1.8.0 and 1.7.0. But no success.

MattRaffel (Mon, 18 Feb 2019 18:00:09 GMT):
@PatrikStas have you added a logger? see indy_set_logger api

Alexi (Mon, 18 Feb 2019 18:08:32 GMT):
Has joined the channel.

Artemkaaas (Tue, 19 Feb 2019 05:19:00 GMT):
@PatrikStas libindy and libvcx init logs in another way. `RUST_LOG` doesn't make sense for them. Regarding nodejs wrapper, you have to call either `setDefaultLogger` function (it's equivalent of setting `RUST_LOG` for dummy-agent) or `setLogger` with passing custom log callback which will be called when ibndy log records.

xnopre (Tue, 19 Feb 2019 08:01:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=039e1d29-641e-447a-b01a-091da2fb3477) @kdenhartog My idea is to try to store the data encrypted with the sender's key, so that I can get its key from ledger when needed and decrypt the data unless the sender has done a key rotation...

xnopre (Tue, 19 Feb 2019 08:05:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ZSBzA2uDRpwytD2Lg) @DuckLover Hi. I had rewritten this scripts from Python to NodeJs : https://github.com/hyperledger/indy-sdk/blob/master/samples/nodejs/src/anoncredsRevocation.js and https://github.com/hyperledger/indy-sdk/blob/master/samples/nodejs/src/anoncredsRevocationScenario.js. Can this help you or answer your question ?

xnopre (Tue, 19 Feb 2019 08:07:51 GMT):
@PatrikStas To complete response from @Artemkaaas , here is an example : ```indy.setLogger(function (level, target, message, modulePath, file, line) { console.log('libindy said:', level, target, message, modulePath, file, line) })``` or with another output format : ```indy.setLogger(function (level, target, message, modulePath, file, line) { console.log(`INDY: ${level} (${target}) ${message} (${modulePath} / ${file}:${line})`) })````

xnopre (Tue, 19 Feb 2019 08:13:35 GMT):
Hi all. If I good seen, `libVCX` is running with `Dummy Cloud Agent`. "Agent" seems to be an emerging subject, in full discussions (HIPEs) and with very little code. How compatible is `libVCX` (and its Dummy Cloud Agent) with current agent subject (and idea, and messages standardization, messages formats, etc...) ? Is it a good idea to start now a new app with libVCX, or is it better to use `indy SDK` ? Thanks

PatrikStas (Tue, 19 Feb 2019 09:03:27 GMT):
@MattRaffel @Artemkaaas Thanks a lot. I'll try it again soon.

cguerin (Tue, 19 Feb 2019 10:20:37 GMT):
Hi, I just updated my version of `indy-sdk` to `1.8.1` and i want to try the new error fields but `indyMessage` and `indyBackTrace` are undefined, someone have any idea of why? I work with `node` wrapper. Thx

pimotte (Tue, 19 Feb 2019 13:54:16 GMT):
Does anyone know if something is up with https://repo.evernym.com/artifactory ? I keep getting a 502 when trying to fetch the indy-sdk java wrapper artifact

jakubkoci (Tue, 19 Feb 2019 15:40:42 GMT):
Hi. I’m trying to build Indy.framework from iOS wrapper (Product -> Archive, Xcode 10.1). The output contains only arm architectures which runs on a device correctly, but I would like to have also x86_64 and i386 architectures to run it on a simulator. Does anybody know how to set the Archive process to achieve that?

ryanwest6 (Tue, 19 Feb 2019 20:15:32 GMT):
Does anyone know how to get the total number of transactions for each ledger? I can't find an API command or request structure to do so.

sklump (Tue, 19 Feb 2019 20:16:19 GMT):
There is no such API call right now.

ryanwest6 (Tue, 19 Feb 2019 20:44:16 GMT):
Thanks for the info. On indyscan.io, it displays the last transactions written to each ledger on mainnet, testnet, etc. What I really want it a way to learn when a new transaction is written and/or how to retrieve that last transaction, as Indyscan is doing

sklump (Tue, 19 Feb 2019 20:48:28 GMT):
ugly algo: start from 1, double it until there is no transaction 2^(n+1) with 2^n having a transaction; Newton-search until (t, t+1) with transaction t existing and t+1 not. Then poll every few seconrds for t+1 until it exists and move the goalposts; repeat forever. No?

ryanwest6 (Tue, 19 Feb 2019 20:49:37 GMT):
Yes, this was what I was planning to do if there was no built-in way. I guess I'll go for that if there isn't a predefined way :) Thanks

ryanwest6 (Tue, 19 Feb 2019 20:51:41 GMT):
Looks like indyscan just polls for new transactions as well: https://github.com/Patrik-Stas/indyscan/blob/2b074295469b423e9f64c62737e7615508119448/daemon/index.js#L55

ianco (Tue, 19 Feb 2019 23:04:47 GMT):
Is there a specific version of rust that is recommended for building indy-sdk? I'm on 1.31.0 but I see 1.32.0 is the current version ...

dbluhm (Tue, 19 Feb 2019 23:39:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=h26Ye2x5xdNkzGhAd) @ianco If it's too old, you'll get errors while building but I haven't seen any specific recommendations otherwise.

ashokkj (Wed, 20 Feb 2019 03:09:48 GMT):
I have a question related to on boarding Trust anchor. Is Pairwise DID's of Steward and entity who wants to become Trust Anchor is stored in the ledger? From the doc "what goes on the ledger" I came to know that Pairwise DID's of User & Trust anchor will not goes to the Ledger. There only Cryptographic trust is established. While on boarding Trust anchor is Cryptographic Trust is good enough or Sovrin Trust is required too ?

ashokkj (Wed, 20 Feb 2019 03:12:08 GMT):
How Trust anchor can Trust it is Alice (User) to whom I am communicating & need to deliver the Transcript ? How Trust anchor can verify the user ?

PatrikStas (Wed, 20 Feb 2019 14:43:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nSBiQyHKQE36TBq83) @ryanwest6 @ryanwest6 was thinking of displaying this information on homepage and as I see there's at least 1 person interested, I'll add this feature to indyscan by the upcoming Sunday (and also a public API)

PatrikStas (Wed, 20 Feb 2019 14:49:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=8SSzn5KbD59mdq6DN) @ryanwest6 One of the things on my roadmap is to add websockets such that the homepage will update itself in the moment a new transaction comes (for any tx, whether domain/pool/config). So once that's in place, you could sub on the socket and listen for new txs. I am busy with other stuff these days, so I my pessimistic estimate for implementing this would be by the end of March.

mgbailey (Wed, 20 Feb 2019 15:18:43 GMT):
@ashokkj You are correct that pairwise DIDs that a trust anchor and an end user use to communicate with each other do not go on the ledger. However, the DID that a trust anchor uses to sign credentials issued to the end user does go onto the ledger. When connecting to an end user for the first time, if it is important to verify identity, a trust anchor will need to do some type of onboarding. This could involve indy (get a verified proof from the user) or not (see a driver's license).

ashokkj (Wed, 20 Feb 2019 15:53:36 GMT):
Mike, how about on boarding Trustanchor's Pairwise DIDs? i.e, entity who wants to become Trust anchor and Steward's (Who provides the entity the role of Trust Anchor) Pairwise DID.

ashokkj (Wed, 20 Feb 2019 15:55:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=uFDY2NQ54nxC6ALzE) @mgbailey Mike, how about on boarding Trustanchor's Pairwise DIDs? i.e, entity who wants to become Trust anchor and Steward's (Who provides the entity the role of Trust Anchor) Pairwise DID.

mgbailey (Wed, 20 Feb 2019 15:58:11 GMT):
@ashokkj A steward is able to add the trust anchor DID to the ledger, and must complete due diligence before doing so.

ashokkj (Wed, 20 Feb 2019 16:00:15 GMT):
Thank you Mike for the clarification.

ashokkj (Wed, 20 Feb 2019 16:10:51 GMT):
@mgbailey Do Ledger also stores the Public information of cred def issued by Trust anchor. Am I right? Then how verifier verify the Private info of Cred Def ? Do the verifier will contact the trust Anchor (Issuer) for verification of Private attributes of cred def? I want to know which are Private & public attributes in Cred Def. I guess Self attested Revealed attributes are public for sure. How about Encoded Revealed Attributes are they Public too ? I am guessing Predicates are private. Please let me know is my understanding is correct or not.

ashokkj (Wed, 20 Feb 2019 16:21:19 GMT):
@mgbailey , I have couple of other questions. I am dumping all 1# Do Cred Def contain Public private attributes? Do Ledger also stores the Public information of cred def issued by Trust anchor. 2# how verifier verify the Private info of Cred Def ? Do the verifier will contact the trust Anchor (Issuer) for verification of Private (non self attested ) attributes & predicate (zkp) attributes of cred def? 3# want to know who decides the Private & public attributes in Cred Def. 4# I guess Self attested Revealed attributes are public for sure. How about Encoded Revealed Attributes are they Public too ? I am guessing Predicates are private. Please let me know is my understanding is correct or not. Thanks in advance.

ryanwest6 (Wed, 20 Feb 2019 17:29:56 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ZJqGKeeAdtubLT3Nc) @PatrikStas I agree that that would be a nice addition. Thanks for the reply and for writing indyscan, it is very helpful!

mgbailey (Wed, 20 Feb 2019 18:04:55 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WaiJeC5HHrGK4Lodz) @ashokkj I am unsure that I understand your questions completely, but let me try to answer as I can. Items in a credential definition have a one-to-one relationship to the elements of a schema. The credential definition includes public keys to verify each item in an issued credential individually. The trust anchor that owns the credential definition has the corresponding private (signing) keys in his wallet. The issuer that owns a credential definition can then issue (virtually) any number of credentials from their credential definition. Issued credentials will contain all the items named in the schema, and all items in the credential will be signed using the private keys corresponding to the public keys that are published in the credential definition. The end user that gets such a credential can use items from the credential to form a proof, in response to a proof request from another party (the verifier). Not all items in a proof must come from a single credential. Items in a proof can also be self-attested by the end user, in which case those items are unverified. It is up to the verifier to determine whether to accept (or not) self-attested items in a proof.

ianco (Wed, 20 Feb 2019 18:14:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=gvw6XJCv2dusBRs8K) @xnopre This isn't an "official" answer, but my understanding is that VCX is not currently compatible with the emerging standards, HIPE's etc, however the team is moving towards standardization and interoperability. (For example this PR in progress https://github.com/hyperledger/indy-sdk/pull/1464) If you need to start building agent-to-agent application now you basically have 3 choices: (1) use VCX (VCX currently has the most functionality, as you can issue credentials and request/provide proofs); (2) wait for other community agents to emerge (or even participate in their development :-D ) or (3) roll your own agent. It also depends on what language you plan to use for development. VCX has multiple language bindings. There are community python and C# agents (and probably others, but language specific). There's a connect-athon currently running so probably some of those teams should weigh in.

Alexi (Wed, 20 Feb 2019 22:50:50 GMT):
Hey all quick question for when establishing connections: "A nonce is a random arbitrary number that can only be used one time. " what is the best practice that has been used when creating a nonce?

ashokkj (Wed, 20 Feb 2019 23:34:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Pi5yTPDD5qrxR6G8F) @mgbailey Thanks for the clarification. My confusion started when some one posted that "Cred def issued by the issuer contains public & private parts. During Agent to Agent communication only public part is sent across" is it true?

xnopre (Thu, 21 Feb 2019 09:06:31 GMT):
@ianco Thanks for your answer !! For you information, I have developped a POC using NodeJs SDK Wrapper (schema, cred def, credentials from issuer to prover, proof from prover to verifier, ...). I understand the 3 choices :-) . Waiting (choice (2)) is not a good way for the moment... Writing our own agent and solution, using SDK, is considered, and I can imagine what to do. My question is about VCX... I have read some docs and codes, I have ran the python demo (I have done a PR to dockerize this demo : https://github.com/hyperledger/indy-sdk/pull/1465), but I don't have a good vision if it is a good idea to use it now ? The "Dummy Cloud Agent" seems working for the demo, but for real life, is it OK ? I don't think so, especially without persistence of messages, ... I'm interested to use VCX if it helps me, but if it will all change (to be compatible with new agent concepts), and I have to rewrite my app wth a further new VCX lib, not sure to be interested... Do you understand my point of view ? What are you talking about ? :-)

feliperdelara (Thu, 21 Feb 2019 13:49:36 GMT):
Has joined the channel.

mgbailey (Thu, 21 Feb 2019 14:48:06 GMT):
@ashokkj Credential definitions are not sent between agents at all. They are data constructs that have 2 parts: a private part that exists in an issuer's wallet, and a public part that is written to the ledger.

izashkalov (Thu, 21 Feb 2019 14:59:45 GMT):
Has joined the channel.

ashokkj (Thu, 21 Feb 2019 15:00:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=rfp2o3antkotgYdM2) @mgbailey Thank you Mike. can I get more info on what is data constructs, I need to know more about it.

izashkalov (Thu, 21 Feb 2019 15:05:03 GMT):
Hello everyone, I am android developer. After update indy to version 1.7 the began to receive warning message: "2019-02-21 17:53:44.385 13204-13891/com.ledgerleopard.municipalityofamsterdam W/System.err: JNA: Callback org.hyperledger.indy.sdk.LibIndy$Logger$1@6a063a7 threw the following exception: 2019-02-21 17:53:44.385 13204-13891/com.ledgerleopard.municipalityofamsterdam W/System.err: java.lang.NoClassDefFoundError: Failed resolution of: Lorg/slf4j/LoggerFactory;". What am I doing wrong?

izashkalov (Thu, 21 Feb 2019 15:13:13 GMT):
I found decisions my problem, i added the library as dependency to my project

mgbailey (Thu, 21 Feb 2019 16:03:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4pKERuWndghMZk5fz) @ashokkj A typical schema is at https://indyscan.io/tx/SOVRIN_TESTNET/domain/34529. Note the attribute names. A credential definition that uses it is at https://indyscan.io/tx/SOVRIN_TESTNET/domain/34530. In both cases, the data of interest is in the txn field. The main things to look at in the cred def are the ref, which points to the schema, and the cryprogrphic keys associated with each field of the schema. The cred def in your wallet contains this same information, plus the private keys.

mgbailey (Thu, 21 Feb 2019 16:03:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4pKERuWndghMZk5fz) @ashokkj A typical schema is at https://indyscan.io/tx/SOVRIN_TESTNET/domain/34529. Note the attribute names. A credential definition that uses it is at https://indyscan.io/tx/SOVRIN_TESTNET/domain/34530. In both cases, the data of interest is in the txn field. The main things to look at in the cred def are the ref, which points to the schema, and the cryptographic keys associated with each field of the schema. The cred def in your wallet contains this same information, plus the private keys.

ianco (Thu, 21 Feb 2019 16:18:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ozviwy64o4R3zH3xC) @xnopre Hi @xnopre , my approach is (a) use VCX now to develop POC (I'm working on a project with the University of British Columbia using Indy to implement a consent process, so we are using Python and VCX), and then (b) at some point in the future either migrate to an updated VCX (that supports agent standards and interoperability) or a different agent. For example there is a lot of work underway right now to update the standard Python agent to implement all new agent standards etc. For me writing my own agent is not an option. If that's what you're thinking I suggest to try to find other people who are working in Node.js and collaborate. There's some Node.js code in the python-agent repo but I think it's a bit stale ... Regarding VCX, there are a few issues I have with the architecture, but I've communicated them to the team and if I end up sticking with VCX I may just fix them myself :-D

dklesev (Thu, 21 Feb 2019 18:18:00 GMT):
could someone give a brief description (without needing to read PhD papers) how to provide `primary={"n":"1","s":"2","rms":"3","r":{"age":"4","name":"5"},"rctxt":"6","z":"7"}` when using the cli?

dklesev (Thu, 21 Feb 2019 18:18:00 GMT):
could someone give a brief description (without the need to read PhD papers) how to provide `primary={"n":"1","s":"2","rms":"3","r":{"age":"4","name":"5"},"rctxt":"6","z":"7"}` when using the cli?

feliperdelara (Thu, 21 Feb 2019 18:39:33 GMT):
Hey guysios

MALodder (Thu, 21 Feb 2019 18:47:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=YTBJkNW2eS4XNsF77) @dklesev This looks like a credential definition for a primary credential. This is the public key for the issuer. Each of those values are base10 and represent a value used to sign a credential and do proofs. CL signatures are RSA based. For RSA based systems you need a modulus which is `n`. In order to keep your attribute values from being discovered in the future we have what is called a `blinding factor`. The `blinding factor` keeps your attribute values from being cracked even if post quantum becomes a reality. This is called *perfectly hiding*. The `s` and `z` values are the blinding factors. The CL signature is a cryptographic commitment to attribute values. Each attribute needs a what we call a base or generator to create the commitment. So you see this for "age" and "name", the values for those represent the bases. `rms` is the base for what we call the *link secret*–a value that is used to prove all credentials were issued to the same person. `rctxt` is the base for an attribute created by an issuer. It is used to prove whether the credential is revoked or not. So now we have three categories: bases, blinding factors, and the modulus. Underneath the math work like this: age_base^(age_value) * name_base^(name_value) * s^(random_value) mod n. There is more than that but that is hopefully the elementary explaination. Hope that helps.

MALodder (Thu, 21 Feb 2019 18:47:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=YTBJkNW2eS4XNsF77) @dklesev This looks like a credential definition for a primary credential. This is the public key for the issuer. Each of those values are base10 and represent a value used to sign a credential and do proofs. CL signatures are RSA based. For RSA based systems you need a modulus which is `n`. In order to keep your attribute values from being discovered in the future we have what is called a `blinding factor`. The `blinding factor` keeps your attribute values from being cracked even if post quantum becomes a reality. This is called *perfectly hiding*. The `s` and `z` values are the blinding factors. The CL signature is a cryptographic commitment to attribute values. Each attribute needs a what we call a base or generator to create the commitment. So you see this for "age" and "name", the values for those represent the bases. `rms` is the base for what we call the *link secret*–a value that is used to prove all credentials were issued to the same person. `rctxt` is the base for an attribute created by an issuer. It is used to prove whether the credential is revoked or not. So now we have three categories: bases, blinding factors, and the modulus. Underneath the math work like this: age_base^(age_value) \* name_base^(name_value) \* s^(random_value) mod n. There is more than that but that is hopefully the elementary explaination. Hope that helps.

dklesev (Thu, 21 Feb 2019 18:53:05 GMT):
@MALodder perfect, thank you for the good explanation. So I see one needs to construct these yourself in the cli? I didn't see this anywhere in the samples when submitting credential definition.

MALodder (Thu, 21 Feb 2019 18:55:43 GMT):
I'm not familiar with the CLI, but using ursa or indy-crypto you create a credential schema then call Issuer::create_credential_def

MALodder (Thu, 21 Feb 2019 18:56:32 GMT):
the credential definition should create those values for you

MALodder (Thu, 21 Feb 2019 18:56:53 GMT):
creating a credential definition against a schema is how those values are generated

dklesev (Thu, 21 Feb 2019 19:01:29 GMT):
I suspected that already. Too bad that there are no simple examples for complete workflows with the Cli or I haven't found anything yet.

DuckLover (Thu, 21 Feb 2019 19:11:25 GMT):
ducklover

JoshCook (Thu, 21 Feb 2019 19:35:23 GMT):
Has joined the channel.

feliperdelara (Thu, 21 Feb 2019 19:57:24 GMT):
Hey everyone. I am trying to build the sdk for iOS and like many people I've been struggling with the tutorial - it mentions an inexistent “build-libindy-core-ios.sh” file and things seem outdated. Has anyone had any luck building this? I also searched for 'iOS' in this chat and read messages until past July. Apparently someone was about to make a PR with fixes, and they also had made available a ready-to-use Indy.framework. Sadly the the link is now broken. Any chance someone kept the changes or know how to proceed with the “how do build”?

JoshCook (Thu, 21 Feb 2019 19:58:40 GMT):
Hey everyone, i have been stuck on an issue, i am creating a indy app for my college for my final project, it will be similar to the alice and faber demo, my question is, : do i have to setup my own VON network for my college, or do i just create a regular agent, i want my college to basically be a trust anchor and be able to issue transcripts to alumni students.

IanHarris (Thu, 21 Feb 2019 20:02:56 GMT):
Has joined the channel.

MattRaffel (Thu, 21 Feb 2019 20:06:56 GMT):
@JoshCook you do not need to use von. the samples/how-tos are good patterns to follow. you will need access to "nodes". I believe this is in the documentation

MattRaffel (Thu, 21 Feb 2019 20:07:43 GMT):
@feliperdelara yes we are able to build libindy for ios. The instructions are out of date, unfortunately. can you provide the exact error?

JoshCook (Thu, 21 Feb 2019 20:14:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qPCHT2ye2bi5Mkn8F) @MattRaffel @MattRaffel Thank you, which how-tos are you referring to, indy node or indy sdk. I want to create a web app IOS and android would take too long for development for me.

MattRaffel (Thu, 21 Feb 2019 20:15:07 GMT):
@JoshCook see https://github.com/hyperledger/indy-sdk/tree/master/samples

JoshCook (Thu, 21 Feb 2019 20:18:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9Kz6kG83rnM5AfYif) @MattRaffel Thanks :)

feliperdelara (Thu, 21 Feb 2019 20:26:39 GMT):
@MattRaffel in this link https://github.com/hyperledger/indy-sdk/blob/master/wrappers/ios/README.md the instructions go smoothly until the step 6, in which the build-libindy-core-ios.sh does not exist in the repo. I wonder what changed from there and on.

emilyz5 (Thu, 21 Feb 2019 21:34:13 GMT):
Has joined the channel.

Alexi (Thu, 21 Feb 2019 23:08:29 GMT):
so in the alice getting started example, when explaining how to onboard someone steps 5 6 7 are as follows: ``` 5. Steward sends the connection request to Faber. 6. Faber accepts the connection request from Steward. 7. Faber creates a wallet if it does not exist yet. ``` since this connection request is sent by some outside means of communication I was wondering what the standard is that is being used, or if there is a best practice to exchange this information?

Alexi (Thu, 21 Feb 2019 23:08:29 GMT):
so in the alice getting started example (https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/indy-walkthrough.md), when explaining how to onboard someone steps 5 6 7 are as follows: ``` 5. Steward sends the connection request to Faber. 6. Faber accepts the connection request from Steward. 7. Faber creates a wallet if it does not exist yet. ``` since this connection request is sent by some outside means of communication I was wondering what the standard is that is being used, or if there is a best practice to exchange this information?

swcurran (Thu, 21 Feb 2019 23:42:01 GMT):
@MALodder - a question about a proof. Is there a timestamp in a Proof that can be used to audit exactly when a proof was created? If not, can you think of a way that the time of the proof can be audited?

runiner (Fri, 22 Feb 2019 00:15:29 GMT):
Has joined the channel.

Dubh3124 (Fri, 22 Feb 2019 03:33:13 GMT):
@Alexi Agent 2 Agent protocols are still being worked on so there isn't a standard yet.

Dubh3124 (Fri, 22 Feb 2019 03:34:55 GMT):
You can look at the HIPEs to see what discussion are be considered https://github.com/hyperledger/indy-hipe/tree/master/text

haggs (Fri, 22 Feb 2019 04:55:30 GMT):
@swcurran Does your question perhaps pertain to this issue at all? https://jira.hyperledger.org/browse/IS-1152 It came up at the connectathon recently and I've been pondering it. I believe the use case was preventing a fork during the transaction process. If not then disregard.

ruggero.montalto-tno (Fri, 22 Feb 2019 08:57:46 GMT):
Has joined the channel.

ruggero.montalto-tno (Fri, 22 Feb 2019 11:00:02 GMT):
Hi all, how can I join the global TestNet as a steward? I've got the whole procedure done up till generating a verkey, a BLS key and a PoP key by running the `sudo -i -u indy init_indy_node ` command.

ruggero.montalto-tno (Fri, 22 Feb 2019 11:00:39 GMT):
Do I need someone to accreditate me, or is there a way I can do it myself?

MALodder (Fri, 22 Feb 2019 14:51:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=zcWMWDfzXHehWrqi6) @swcurran The Verifier or Prover can include a timestamp into the challenge portion of the proof. The challenge portion comes from the NIZK part. It would just be metadata that both sides would have to know in order for the proof to validate. An auditor could then check it with the timestamp

mgbailey (Fri, 22 Feb 2019 15:09:58 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=SjvxE22sFAnNCvdoh) @ruggero.montalto-tno TNO already has a node on MainNet, are you wanting to contribute an additional node to another of the Sovrin networks? Lets move this conversation to chat.sovrin.org, in the stewards channel.

swcurran (Fri, 22 Feb 2019 16:35:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mtxGjRJhK3b8ci6cZ) @haggs It's not that precise problem, but the concept is the same - I want proof of the timestamp of an event in a way that neither the prover nor the verifier can manipulate. I'm not convinced that the example in the JIRA issue is an issue or if the proposed solution is necessary. A verifier should either tell the prover the point in time they are willing to accept or the prover should tell the verifier the point in time the proof was created. The fact that additional events occurred after is not really relevant. To express the time, I was thinking that rather than using a timestamp, an entry in the ledger can be used - e.g. the sequence number and hash of the entry.

swcurran (Fri, 22 Feb 2019 16:49:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5W7FAqGaJ346ZNioZ) @MALodder I assume anything can go in that section? For example, a hash of a ledger transaction could be used to prove that the proof was created after a point time. That would sort of work, but one or the other could use an older ledger entry if that was useful to them - indicating the event occured well before it actually occured. I'm looking for an auditable entry that was independent of the Prover and Verifier - so neither could manipulate it nor could they collude on it.

MALodder (Fri, 22 Feb 2019 16:50:21 GMT):
sure anything could go in there

danielhardman (Fri, 22 Feb 2019 19:08:04 GMT):
Conversations on the topic of DID Doc support and microledgers are unfolding in several different places -- rocket.chat, slack, google docs, jira. Not all of the same people are in each place, and I didn't want to copy and paste a lot of text all over. So I put some thoughts in a doc. Please have a look, and please forward this on to other people if you think they should be aware: https://docs.google.com/document/d/17qzu5jm2CIA32oArG4cRp7g0D_20cwUqB4sX4LIkodc/edit#

lynn.bendixsen (Fri, 22 Feb 2019 19:13:11 GMT):
Has joined the channel.

lynn.bendixsen (Fri, 22 Feb 2019 19:15:26 GMT):
Does the windows build here https://repo.sovrin.org/windows/indy-cli/stable/1.7.0/indy-cli_1.7.0.zip work on Windows 7? I have tried it and it works on Windows 10.

spacemandev (Fri, 22 Feb 2019 22:37:38 GMT):
Has joined the channel.

spacemandev (Fri, 22 Feb 2019 22:38:47 GMT):
trying to figure out what the difference between the "ver" and "version" in the same schema might be, anyone have any thoughts? https://github.com/hyperledger/indy-sdk/blob/master/docs/how-tos/save-schema-and-cred-def/python/README.md

nanspro (Sat, 23 Feb 2019 02:11:45 GMT):
Has left the channel.

DuckLover (Sat, 23 Feb 2019 23:03:28 GMT):
Are ZKPs and Selective Disclosure with the NodejS Wrapper possible?

swcurran (Sun, 24 Feb 2019 06:30:09 GMT):
Yes. It's used based on how you define the proof request. All Indy credential/proof capabilities are supported by the nodejs wrapper.

DuckLover (Sun, 24 Feb 2019 13:54:15 GMT):
@swcurran Selective Disclosure is able by selecting only a few attributes from an credential. Do you have an example or code that uses ZKP?

DuckLover (Sun, 24 Feb 2019 14:23:56 GMT):
I think i found something. I am going to try these: https://github.com/hyperledger/indy-sdk/blob/master/docs/how-tos/negotiate-proof/nodejs/negotiateProof.js

swcurran (Sun, 24 Feb 2019 15:28:35 GMT):
Selective disclosure means that when presenting a credential, you are only presenting some of the claims. In some verifiable credential models, you can't do that - you can only present the entire credential. With Indy, proofs are independent of credentials and populated by claims from credentials - it's all selective disclosure. You could in a proof request ask to receive all the claims in a credential, but you don't have to and often won't.

DuckLover (Sun, 24 Feb 2019 15:30:46 GMT):
Thanks for your clarification Stephen! :slight_smile:

DuckLover (Sun, 24 Feb 2019 15:33:15 GMT):
I tried to implement a quick ZKP but i seem to do anything wrong. Does someone has a hint for me? ``` proofRequests['SWH-Request'] = { name: 'SWH-Request', version: '1.5', requested_attributes: { attr1_referent: { name: 'name', restrictions: [{'cred_def_id': await indy.did.getPersonIdCredDefId()}] }, attr2_referent: { name: 'geburtstag', restrictions: [{'cred_def_id': await indy.did.getPersonIdCredDefId()}] }, attr3_referent: { name: 'hochschule', restrictions: [{'schema_name': 'WHS-ID'}] }, attr4_referent: { name: 'matrikelnummer', restrictions: [{'schema_name': 'WHS-ID'}] }, attr5_referent: { name: 'arbeitgeber', restrictions: [{'schema_name': 'IFIS-ID'}] }, /* attr6_referent: { name: 'gehalt', restrictions: [{'schema_name': 'IFIS-ID'}] } */ }, requested_predicates: { predicate1_referent: { name: 'gehalt', p_type: '>=', p_value: 350, restrictions: [] } } }; ``` And the error is: ``` alice_1 | ERROR|indy::errors::indy | src/errors/indy.rs:73 | Casting error to ErrorCode: Wallet storage error occurred. Description: IO error during storage operation: near "AND": syntax error alice_1 | IndyError: 210 alice_1 | at Object.callback (/~/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10) alice_1 | (node:16) UnhandledPromiseRejectionWarning: IndyError: 210 alice_1 | at Object.callback (/~/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10) alice_1 | (node:16) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function withouta catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2) ```

ianco (Sun, 24 Feb 2019 18:54:08 GMT):
Does it work without the ZKP? I suggest to try leaving off the restrictions from the zkp completely = predicate1_referent: { name: 'gehalt', p_type: '>=', p_value: 350 }

DuckLover (Sun, 24 Feb 2019 20:28:24 GMT):
Yes it worked without the ZKP. Without the restriction it doesnt throw an error anymore but didnt show anything about that. Its not mentioned in the requested attributes nor is it written in the Relationship information. Shouldnt it show soomething like "valid" or "true"?

ianco (Sun, 24 Feb 2019 21:46:44 GMT):
If you call the anoncreds "indy_verifier_verify_proof()" it will confirm if it is valid or not. It's buried in the proof somewhere but I'm not sure where. You can test this by force-feeding the proof (on the prover side) an invalid value (for example a credential with a 'gehalt' of 349)

DuckLover (Mon, 25 Feb 2019 00:13:17 GMT):
you mean by providing a credential that doesnt fit the ZKP cirteria?

ianco (Mon, 25 Feb 2019 04:10:18 GMT):
Yes

GEEKTEDDY (Mon, 25 Feb 2019 09:35:25 GMT):
``` I ran the project in /indy-sdk/samples/java, and found the following error: ```

GEEKTEDDY (Mon, 25 Feb 2019 09:37:04 GMT):
``` Anoncreds sample -> started Exception in thread "main" java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.InvalidStateException: The SDK library experienced an unexpected internal error. at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1895) at Anoncreds.demo(Anoncreds.java:27) at Main.main(Main.java:4) Caused by: org.hyperledger.indy.sdk.InvalidStateException: The SDK library experienced an unexpected internal error. at org.hyperledger.indy.sdk.IndyException.fromSdkError(IndyException.java:70) at org.hyperledger.indy.sdk.IndyJava$API.checkResult(IndyJava.java:90) at org.hyperledger.indy.sdk.pool.Pool.access$100(Pool.java:20) at org.hyperledger.indy.sdk.pool.Pool$1.callback(Pool.java:52) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:520) at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:551) ```

GEEKTEDDY (Mon, 25 Feb 2019 09:42:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=2rM63PBi9QByEHFKA) the pool is on the remote server , and I made a tunnel to mapping server's port to my localhost's so that I don't need to change the parameter "TEST_POOL_IP" in EnvironmentUtils.java

DuckLover (Mon, 25 Feb 2019 12:41:02 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9hxTZoRWbQMvM5MTA) @ianco i provided Alice an Credential with gehalt value 200 and it ignored the ZKP Attribute again completly

DuckLover (Mon, 25 Feb 2019 12:41:23 GMT):
No error displayed or value somewhere shown

DuckLover (Mon, 25 Feb 2019 13:02:40 GMT):
I tried it with those restrictions but again no error or value shown ``` requested_predicates: { predicate1_referent: { name: 'gehalt', p_type: '>=', p_value: 350, restrictions: [{'schema_name': 'IFIS-ID'}] } } ```

DuckLover (Mon, 25 Feb 2019 13:35:42 GMT):
okay, it seems like the nodejs reference agent didnt support it yet, i search for the function that parses my proof... ``` /* * This function is currently oversimplified. It does not support: * requested_predicates * self_attested_attributes * We are just selecting the first credential that fits, rather than letting the user select which they want to use. (indicated by [0] twice below) */ exports.prepareRequest = async function(message) { let pairwise = await indy.pairwise.get(message.origin); let proofRequest = await indy.crypto.authDecrypt(pairwise.my_did, message.message); let credsForProofRequest = await sdk.proverGetCredentialsForProofReq(await indy.wallet.get(), proofRequest); let credsForProof = {}; for(let attr of Object.keys(proofRequest.requested_attributes)) { credsForProof[`${credsForProofRequest['attrs'][attr][0]['cred_info']['referent']}`] = credsForProofRequest['attrs'][attr][0]['cred_info']; } let requestedCreds = { self_attested_attributes: {}, requested_attributes: {}, requested_predicates: {} }; for(let attr of Object.keys(proofRequest.requested_attributes)) { requestedCreds.requested_attributes[attr] = { cred_id: credsForProofRequest['attrs'][attr][0]['cred_info']['referent'], revealed: true } } return { origin: message.origin, type: message.type, message: { proofRequest: proofRequest, credsForProof: credsForProof, requestedCreds: requestedCreds } } }; ```

ianco (Mon, 25 Feb 2019 14:23:04 GMT):
That explains it :-D

DuckLover (Mon, 25 Feb 2019 15:17:38 GMT):
i tried to add those but i am not sure what i missed. I add a few lines in this function that it also reads the predicates but it didnt throw an error or shows some value. ``` exports.prepareRequest = async function(message) { let pairwise = await indy.pairwise.get(message.origin); let proofRequest = await indy.crypto.authDecrypt(pairwise.my_did, message.message); let credsForProofRequest = await sdk.proverGetCredentialsForProofReq(await indy.wallet.get(), proofRequest); let credsForProof = {}; for(let attr of Object.keys(proofRequest.requested_attributes)) { credsForProof[`${credsForProofRequest['attrs'][attr][0]['cred_info']['referent']}`] = credsForProofRequest['attrs'][attr][0]['cred_info']; } /////////////////////New/////////////////// for(let attr of Object.keys(proofRequest.requested_predicates)) { credsForProof[`${credsForProofRequest['predicates'][attr][0]['cred_info']['referent']}`] = credsForProofRequest['predicates'][attr][0]['cred_info']; } //////////////////////////////////////// let requestedCreds = { self_attested_attributes: {}, requested_attributes: {}, requested_predicates: {} }; for(let attr of Object.keys(proofRequest.requested_attributes)) { requestedCreds.requested_attributes[attr] = { cred_id: credsForProofRequest['attrs'][attr][0]['cred_info']['referent'], revealed: true } } /////////////////////New/////////////////// for(let attr of Object.keys(proofRequest.requested_predicates)) { requestedCreds.requested_predicates[attr] = { cred_id: credsForProofRequest['predicates'][attr][0]['cred_info']['referent'], //revealed: true } } /////////////////////////////////////////// return { origin: message.origin, type: message.type, message: { proofRequest: proofRequest, credsForProof: credsForProof, requestedCreds: requestedCreds } } }; ```

jakubkoci (Mon, 25 Feb 2019 17:17:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=TH5s42BKzm5QDSNua) @feliperdelara The correct script should be this one https://github.com/hyperledger/indy-sdk/blob/master/ci/ios-build.sh

esplinr (Mon, 25 Feb 2019 17:36:39 GMT):
Indy SDK Wishlist from the Sovrin Connect-a-thon last week: https://wiki.hyperledger.org/display/indy/Indy+SDK+Wishlist

esplinr (Mon, 25 Feb 2019 17:37:02 GMT):
Thank you for the reminder to get it posted @swcurran .

mwherman2000 (Tue, 26 Feb 2019 00:28:51 GMT):
@haggs Here

mwherman2000 (Tue, 26 Feb 2019 00:28:51 GMT):
@haggs Here's a sample of the "Sally buys a car" message size analysis ...high-level but it includes all of the details including the contents of each of the JSON messages exchanged. Please read the notes at the beginning to understand what I mean by "exchanged". https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-5.0%20Raw%20Message%20Flows.md

DuckLover (Tue, 26 Feb 2019 01:18:59 GMT):

ZKP.png

DuckLover (Tue, 26 Feb 2019 01:19:30 GMT):
Can anyone confirm that this is a valid ZKP format? And maybe tell how to access the value in the UI in the nodeJS wrapper?

Sreesha (Tue, 26 Feb 2019 04:22:25 GMT):
Has joined the channel.

xnopre (Tue, 26 Feb 2019 09:19:13 GMT):
@DuckLover What is your stack ? Are you using only Indy SDK ? NodeJS Wrapper ? Or also indy-agent ?

DuckLover (Tue, 26 Feb 2019 11:07:57 GMT):
@xnopre i use https://github.com/hyperledger/indy-agent/tree/master/nodejs

DuckLover (Tue, 26 Feb 2019 11:27:51 GMT):
here is the proof object but with revealed=true. Would really appreciate if anyone could check it out how to display the result of the ZKP.

DuckLover (Tue, 26 Feb 2019 11:28:01 GMT):

proof.txt

yahyaghardallou (Tue, 26 Feb 2019 13:50:09 GMT):
Has joined the channel.

yahyaghardallou (Tue, 26 Feb 2019 13:50:22 GMT):
sombody could help me ?

TammyPlatero (Tue, 26 Feb 2019 20:11:13 GMT):
I had a question about creating a client in a docker container. I noticed in the indy-pool.dockerfile line 90 (RUN generate_indy_pool_transactions --nodes 4 --clients 5 --nodeNum 1 2 3 4 --ips="$pool_ip,$pool_ip,$pool_ip,$pool_ip") it looks like there are 5 clients that are being created? Ideally, I want to have a separate client container to contact the node pool to verify a proof. Is the dockerfile already creating clients? Or, are the clients the validator nodes?

DuckLover (Tue, 26 Feb 2019 20:17:03 GMT):
Is anyone familiar with this script https://github.com/hyperledger/indy-sdk/blob/master/docs/how-tos/negotiate-proof/nodejs/negotiateProof.js ? How are ZKP used there? Does the verifiy fail if the requirement in the proof def is invalid (in this example the age)? Or is there a way to display the ZKP result?

tomislav (Tue, 26 Feb 2019 20:18:05 GMT):
It's a binary result, pass or fail

DuckLover (Tue, 26 Feb 2019 20:29:52 GMT):
So i can only check the whole proof but not get a "valid" or "invalid" from the the specific ZKP part of the proof?

DuckLover (Tue, 26 Feb 2019 20:31:10 GMT):
@tomislav

tomislav (Tue, 26 Feb 2019 20:52:36 GMT):
That's correct. It's an atomic operation that ends in valid/invalid overall

DuckLover (Tue, 26 Feb 2019 20:57:45 GMT):
@tomislav Well, how are those use cases implemented when someone want to know a few attributes and that someone is older then 18 years? You can deliver values for the wanted attributes and for the age zkp you set "valid" as default because if it would invalid the proofs wouldnt be used at all (including the other wanted attribute) ?

tomislav (Tue, 26 Feb 2019 21:02:58 GMT):
I'm not sure I understand. The entire proof is invalid if one attribute referent is invalid.

DuckLover (Tue, 26 Feb 2019 21:14:31 GMT):
@tomislav ok, i think i understand. I was trying to add an information for the user that shows that the ZKP of the age is valid. Because that cant be pulled out of the proof object like other attributes (name:Alice,...) i want to set it as "valid" on default (in the UI). Correct me if i am wrong on some point.

MALodder (Tue, 26 Feb 2019 21:23:04 GMT):
@DuckLover the reason for this is because if the credential proof fails but the range proof succeeds you shouldn't trust it. I can generate a valid range proof for age but you shouldn't trust it unless its the same value that was signed by a trusted issuer

Rowan_Shedden (Tue, 26 Feb 2019 23:13:47 GMT):
I’ve been through that walkthrough at https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/indy-walkthrough.md , and the scenario there works because the steward (or a trust anchor) can write the verkey to the ledger with a NYM message so that it can be picked up by anyone. And that’s how the other agents do get the verkey, i.e. from the ledger. However, that protocol doesn’t work when the agent making the connection_request is not a trust anchor or steward because they can’t write a NYM to the ledger.

Rowan_Shedden (Tue, 26 Feb 2019 23:14:36 GMT):
Let’s say we have 2 actors – Alice and Zulu (trust anchor) Alice receives a connection_offer (via a QR code) from Zulu. She now has Zulu’s did and verkey. Alice creates a did in her wallet for the connection to Zulu. She now has her did and verkey and Zulu’s did and verkey. All good for her, she’s got everything she needs. Alice sends a connection_request to Zulu. Zulu now has Alice’s did but not her verkey. Zulu has their did and verkey and Alice’s did at this point. Zulu sends an anon encrypted connection_response message to Alice with their did and verkey. Here’s the problem. The connection_response message contains the Zulu did and verkey anon encrypted. Zulu can only encrypt using its verkey at this stage because Zulu does not have Alice’s verkey. However, the message actually needs to be anon encrypted using Alice’s verkey so that when she receives it she can anon decrypt the message. If Alice tries to anon decrypt the message using Zulu’s verkey the SDK throws the following exception: org.hyperledger.indy.sdk.wallet.WalletItemNotFoundException: No value with the specified key exists in the wallet from which it was requested. If Zulu encrypts with Alice’s verkey (which it doesn’t have but I intervened and set) and Alice uses her verkey to anon decrypt then it works just fine. I may have misunderstood the documentation about the message flows, which I found here: https://hyperledger-indy.readthedocs.io/projects/agent/en/latest/README.html Can anyone shed some light on this?

daidoji (Wed, 27 Feb 2019 00:11:22 GMT):
Has joined the channel.

DuckLover (Wed, 27 Feb 2019 00:24:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=7TfFon8w6iAsaAJAC) @MALodder can you elaborate this? What do you mean by range proof? A single attribute in a proof? Do you have a resource on validating proofs or sum it up, I am not sure what defines a valid range proof

MALodder (Wed, 27 Feb 2019 02:58:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=CNcdngYaBXLALbrih) @DuckLover Sure thing, the credential just proves the attributes that were signed by the issuer. A range proof is where an attribute is still not revealed to a verifier but if it is less than a value or greater than a value or not equal. If *x* is my age then I can check if *x* > 17 which means I can purchase plane tickets, vote, or other things. *x* was signed by the issuer but I'm not revealing it to the verifier, just the _range_ it lies between

DuckLover (Wed, 27 Feb 2019 11:37:55 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nq7XfniSC75FuNmRG) @MALodder Thank you, i get it now :thumbup:

AxelNennker (Wed, 27 Feb 2019 12:43:18 GMT):
Created a new PR https://github.com/hyperledger/indy-sdk/pull/1503

AvikHazra (Wed, 27 Feb 2019 13:31:51 GMT):
Hello, Currently I am facing an issue. When Im trying to run the indy-sdk nodejs samples it's showing error `cd /indy-sdk/samples/nodejs/src/` `node gettingStarted.js` ~ Running Getting Started script...(terminal output) gettingStarted.js -> started Open Pool Ledger: pool1 node: symbol lookup error: /var/www/html/indy-sdk/wrappers/nodejs/build/Release/indynodejs.node: undefined symbol: indy_get_current_error

AxelNennker (Wed, 27 Feb 2019 13:50:23 GMT):
new sdk old pool? indy_get_current_error was introduced recently

AxelNennker (Wed, 27 Feb 2019 14:02:03 GMT):
I just cloned indy-sdk, build it and ran the tests with `RUST_TEST_TASKS=1 cargo test`. tests are failing. Not all. Do tests work for any of you?

ianco (Wed, 27 Feb 2019 14:08:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=SWE47bLSu9nq2fG9N) @AvikHazra You have an old version of the libindy.so library on your system somewhere

AxelNennker (Wed, 27 Feb 2019 14:27:45 GMT):
@faisal00813 Why does the indz-sdk README.md point to https://github.com/evernym/indy-android-dependencies/tree/v1.0.2 and not to https://github.com/sovrin-foundation/indy-android-dependencies which seems to be more current.

dbluhm (Wed, 27 Feb 2019 18:36:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=cpT2qaNPDtfZisWAS) @TammyPlatero What kind of client are you referring to? The containers being started in that indy-pool.dockerfile are nodes of a test network. I'm not sure the what exactly `--clients 5` is referring to but I'm fairly confident it's not what you're looking for

dbluhm (Wed, 27 Feb 2019 18:36:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=cpT2qaNPDtfZisWAS) @TammyPlatero What kind of client are you referring to? The containers being started in that indy-pool.dockerfile are nodes of a test network. I'm not sure what exactly `--clients 5` is referring to but I'm fairly confident it's not what you're looking for

Alexi (Wed, 27 Feb 2019 18:50:32 GMT):
hello I have a quick question: can a schema / credential definition only be created by a trust anchor / steward, or can it be created by anyone but only published to the ledger by a trust anchor steward? or am i confused entirely?

sklump (Wed, 27 Feb 2019 19:00:49 GMT):
Any trust anchor with a role of TRUST_ANCHOR, TRUSTEE, or STEWARD) can send a schema or cred def to the ledger. See https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md for current permission model.

sklump (Wed, 27 Feb 2019 19:00:49 GMT):
Any trust anchor with a role of TRUST_ANCHOR, TRUSTEE, or STEWARD can send a schema or cred def to the ledger. See https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md for current permission model.

jacobsaur (Wed, 27 Feb 2019 20:07:02 GMT):
Hi, I was wondering what the status is on the postgres storage plugin - I see it's experimental right now, I'm curious when it will move out of experimental, and when there will be a nodejs wrapper for it.

ianco (Wed, 27 Feb 2019 21:46:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=j7XaxZqsnXa9HEsQL) @jacobsaur Hi, the postgres storage plug-in is used directly by the sdk so there aren't any language wrappers directly. When you load the plugin it registers a new wallet storage type, and then you can create postgres wallets using any of the normal sdk wrappers (also the CLI, VCX etc.) You specify wallet type of 'postgres_storage' and there are some other parameters you need to supply, there is a README in the source directory.

ianco (Wed, 27 Feb 2019 21:47:47 GMT):
As far as it living in the 'experimental' folder I'm not sure if there is any specific criteria. It is in use right now in BC (in production) but I'm not aware it's in use anywhere else yet. There are some outstanding tickets and features in the backlog ...

ashlinSajan (Thu, 28 Feb 2019 03:54:06 GMT):
Has joined the channel.

Sreesha (Thu, 28 Feb 2019 06:16:15 GMT):
where can we get the certificates of users and pool validators

Sreesha (Thu, 28 Feb 2019 07:01:45 GMT):
How to use these certs in fabric

AxelNennker (Thu, 28 Feb 2019 09:09:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4aTTd7DozQ3eDnt8X) The correct command to run the tests is `cargo test -- --test-threads=1`

AxelNennker (Thu, 28 Feb 2019 09:33:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aE4Y2dwxHQXPgS2yG) or `RUST_TEST_THREADS=1 cargo test` That is what Indy does. Damn Internet `https://www.google.com/search?q=RUST_TEST_TASKS%3D1+cargo+test` does not work

DuckLover (Thu, 28 Feb 2019 12:13:21 GMT):
ashlin

swcurran (Thu, 28 Feb 2019 19:30:40 GMT):
@MALodder - in the Indy-SDK wish list from the connectathon, there are a couple of Ursa-related items. Could you provide a brief definition of these two terms? * Credential aggregation * Credential chaining Thanks!

MALodder (Thu, 28 Feb 2019 19:45:17 GMT):
I'm not quite sure what credential aggregation is

MALodder (Thu, 28 Feb 2019 19:48:45 GMT):
credential chaining is basically delegatable credentials. I issue a credential to someone else who can then issue credentials to someone and we create a chain of trust. As long as the chain can be verified (each node in the chain) then its verifiable. Now the root could revoke and then the entire chain is invalidated

swcurran (Thu, 28 Feb 2019 20:11:16 GMT):
OK - I wondered if it was that. I hadn't thought that would need underlying support in the SDK or Ursa. Would that remove the need for the one further delegating the authority from having to be an Issuer? Given the current approach of not having personal DIDs on the ledger, a person cannot Issue a credential, which (in my mind) precludes using Verifiable Credentials being used for personal delegation - a significant challenge.

MALodder (Thu, 28 Feb 2019 21:11:08 GMT):
Yes I imagine it being used for delegating authority and having chained issuers

PatrikStas (Fri, 01 Mar 2019 16:23:28 GMT):
Hi @xnopre, not sure if still relevant for you, but I just came back holiday and I've just mostly finished porting the Python VCX demo to NodeJS. Will submit pull request on Monday, for now you can check it out here https://github.com/Patrik-Stas/indy-sdk/commit/bef15d02f7317eff6853f07a7fb3a4a1adf2bf01

jacobsaur (Fri, 01 Mar 2019 18:24:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qRdszCbPcgNAvLDS3) @ianco Thanks @ianco. I guess my specific question then is around how to load the plugin in nodejs. There's a good example in the docs of how to do it with python in getting_started.py, but there's no analogous example for nodejs. I'm guessing that I'd have to update the binding.gyp file to include the libindystrgpostgres.so and the rebuild the indy-sdk with node-gyp, but I haven't been able to get it to work. Any other ideas? Are you using python In BC?

tomislav (Fri, 01 Mar 2019 19:38:04 GMT):
Can I aggregate the attribute restrictions in the proof request of the same type? ex `{ "issuerDid": "1", "issuerDid": "2" }` and are all processed with an OR logic?

nehalshah50 (Fri, 01 Mar 2019 21:31:39 GMT):
Hi..I am trying following JSON for the proof request with restrictions. But can't make it work in Java Wrapper....keep getting invalid JSON. "[{\"name\": \"name\", \"restrictions\": [{\"issuer_did\": config[\"institution_did\"]}]}]"

nehalshah50 (Fri, 01 Mar 2019 21:31:39 GMT):
Hi..I am trying following JSON for the proof request with restrictions. But can't make it work in Java Wrapper....keep getting invalid JSON. Problem seems to be in restrictions. "[{\"name\": \"name\", \"restrictions\": [{\"issuer_did\": config[\"institution_did\"]}]}]"

tomislav (Fri, 01 Mar 2019 22:19:28 GMT):
@nehalshah50 "restrictions" is an object, not an array - https://github.com/hyperledger/indy-sdk/blob/e46be37fcad8735b836e0bfe021df12932176c5d/libindy/src/api/anoncreds.rs#L885

nehalshah50 (Fri, 01 Mar 2019 22:23:24 GMT):
Does anyone have working example of this? I am going by demo here I am going with demo example here https://github.com/hyperledger/indy-sdk/blob/master/vcx/wrappers/python3/demo/faber.py And according to that restrictions is array proof_attrs = [ {'name': 'name', 'restrictions': [{'issuer_did': config['institution_did']}]}, {'name': 'date', 'restrictions': [{'issuer_did': config['institution_did']}]}, {'name': 'degree', 'restrictions': [{'issuer_did': config['institution_did']}]} ]

nehalshah50 (Fri, 01 Mar 2019 22:25:35 GMT):
Also another example is here https://github.com/hyperledger/indy-sdk/blob/e46be37fcad8735b836e0bfe021df12932176c5d/vcx/libvcx/src/api/proof.rs /// # Example requested_attrs -> "[{"name":"attrName","restrictions":["issuer_did":"did","schema_id":"id","schema_issuer_did":"did","schema_name":"name","schema_version":"1.1.1","cred_def_id":"id"}]]"

nehalshah50 (Fri, 01 Mar 2019 22:26:19 GMT):
I don't know which works. I am trying to put some restrictions while requsting proof. If attribute is not signed by a certain issuer then proof should not get verified

tomislav (Fri, 01 Mar 2019 22:28:22 GMT):
Interesting, the json in the comment you linked is not even valid json

tomislav (Fri, 01 Mar 2019 22:32:01 GMT):
``` "restrictions": (filter_json) { /// "schema_id": string, (Optional) /// "schema_issuer_did": string, (Optional) /// "schema_name": string, (Optional) /// "schema_version": string, (Optional) /// "issuer_did": string, (Optional) /// "cred_def_id": string, (Optional) /// } ``` This is in line with how the API documentation is showing. It's an object with optional properties.

ianco (Fri, 01 Mar 2019 22:56:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=fziepgpi4fFnrMfa7) @jacobsaur Yes I'm just using python

ianco (Fri, 01 Mar 2019 22:56:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=fziepgpi4fFnrMfa7) @jacobsaur Yes I'm just using python ... A quick google search gives me thig (https://nodejs.org/api/addons.html) ... but I'm not anode guy :-(

DuckLover (Sun, 03 Mar 2019 01:21:20 GMT):
Is there a way to get the byte-size of the users wallet or can anyone tell how big (in byte) a regular wallet in use is?

swcurran (Sun, 03 Mar 2019 16:16:07 GMT):
It's still so early, so that is a tough thing to say. We (OrgBook) have HUGE wallets since we hold so many credentials (~1.4M), but that could be used to give you the average size of a stored credential. I'll get that information for you. Beyond that, it's guestimating what a personal wallet would have in it. The other point of reference I use is that my LastPass vault has about 800 sets of credentials in it, so you might use that as a metric for what a user might have in terms of relationships. I suspect that those two data points would likely get you within an order of magnitude. I'll get the stats from our wallets.

DuckLover (Sun, 03 Mar 2019 21:26:28 GMT):
Thanks you. I am excited about your research on the data size.

xnopre (Mon, 04 Mar 2019 07:56:33 GMT):
@PatrikStas Hi. Thanks. But as I said, for us and for the moment, "agent" subject is not enough mature (advanced). And lib VCX does not bring much help. And be careful, agent subject is moving, you probably will have to regurlarly update your code, following changes on agent, dummy cloud agent and lib VCX ? But good job for the community ! :+1:

Sreesha (Mon, 04 Mar 2019 10:22:53 GMT):
onboarding

AvikHazra (Mon, 04 Mar 2019 11:18:45 GMT):
hello, When I trying to run in nodejs sample it showing *CommonInvalidState*. Can anyone help me ? It was worked properly 2 days ago

jacobsaur (Mon, 04 Mar 2019 13:46:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=oEtCYbBzixipB9mab) @AvikHazra Hi @AvikHazra , I've seen that error before with nodejs whenever my indy-sdk version is different from my indy ledger version. I believe the latest right now is 1.8.1 so make sure the npm version (https://www.npmjs.com/package/indy-sdk/v/1.8.1) matches your pool (https://github.com/hyperledger/indy-sdk/blob/v1.8.1/ci/indy-pool.dockerfile)

DuckLover (Mon, 04 Mar 2019 15:26:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=oEtCYbBzixipB9mab) @AvikHazra Also had it randomly. I was working with Docker-Compose and docker-compose down and rebuild helped me.

swcurran (Mon, 04 Mar 2019 17:56:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=z85r853uxn3DR9XeE) Based on our experience, for a moderate sized JSON Credential (probably in the 2k range, but varied based on the data), about 20k storage is taken up in the Wallet. Why so large? As a credential arrives and is stored in the wallet, a whole set of tags are created, and all the data+tags are stored as encrypted data. The tags are created automatically by Indy-SDK per claim to enable per claim equality searching in the wallet. If you need to support other expressions (>, <, etc.) to find specific credentials in a wallet, those will be claims must be added separately and unencrypted. So there you go...

swcurran (Mon, 04 Mar 2019 17:57:59 GMT):
That data is for a Postgres Database, but we ran with SQLite long enough to find the data volume was similar.

mwherman2000 (Mon, 04 Mar 2019 19:36:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=XNNXKKbuWQithEFin) @swcurran Here's a detailed analysis with actual JSON examples: https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-5.0%20Raw%20Message%20Flows.md#sample-message-sizes CC: @haggs

mwherman2000 (Mon, 04 Mar 2019 19:45:20 GMT):
@swcurran Here's a link to the table with the links to the JSON examples (with their sizes): https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-5.0%20Raw%20Message%20Flows.md#sample-message-files-and-sizes-bytes

swcurran (Mon, 04 Mar 2019 20:03:44 GMT):
Thanks @mwherman2000 - that's helpful and interesting.

nehalshah50 (Mon, 04 Mar 2019 20:07:46 GMT):
Hi...how to read disclosed proof when received? i.e. what are the key attributes to look for which may be useful for verification? Does it show anywhere who signed a given attribute?

mwherman2000 (Mon, 04 Mar 2019 20:15:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wMvoiGtDeWTJvHc6q) The numbering (e.g. `5.2.1`) correlates each JSON message with the actual code in the _verbose_ version of the `getting_started-verbose.py` script: https://github.com/mwherman2000/indy-dev/blob/master/python/getting_started-verbose.py#L545 as well as the console log output: https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-verbose.log#L409 . The console log output contains complete copies of all of the JSON messages.

mwherman2000 (Mon, 04 Mar 2019 20:15:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wMvoiGtDeWTJvHc6q) @swcurran The numbering (e.g. `5.2.1`) correlates each JSON message with the actual code in the _verbose_ version of the `getting_started-verbose.py` script: https://github.com/mwherman2000/indy-dev/blob/master/python/getting_started-verbose.py#L545 as well as the console log output: https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-verbose.log#L409 . The console log output contains complete copies of all of the JSON messages.

mwherman2000 (Mon, 04 Mar 2019 20:18:52 GMT):
...and the message flow diagrams: https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-5.0%20Raw%20Message%20Flows.md#52-message-flows

mwherman2000 (Mon, 04 Mar 2019 20:18:52 GMT):
...and the message flow diagrams: e.g. https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-5.0%20Raw%20Message%20Flows.md#52-message-flows

mwherman2000 (Mon, 04 Mar 2019 20:18:52 GMT):
...the numbering also correlates all of the above with the message flow diagrams: e.g. https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-5.0%20Raw%20Message%20Flows.md#52-message-flows

Alexi (Mon, 04 Mar 2019 22:23:01 GMT):
hello, i was wondering if keys generated are RSA or ECC

daidoji (Mon, 04 Mar 2019 23:49:53 GMT):
@Alexi I'm not an expert but I believe its consistently ECC (25519 curve if I'm not mistaken)

daidoji (Mon, 04 Mar 2019 23:49:53 GMT):
RSA is generally thought to be on its last legs and not a good choice these days

dbluhm (Tue, 05 Mar 2019 14:23:22 GMT):
The verkey and corresponding signing key are ed25519 keys that get converted to curve 25519 keys for encryption and decryption operations. I think RSA is still used in credentials (credential definitions? And proofs?) But the Hyperledger Ursa team is working to convert these to ECC as well. You can probably ping @MALodder if you have more detailed questions.

dbluhm (Tue, 05 Mar 2019 14:23:58 GMT):
@Alexi @daidoji ^^

Alexi (Tue, 05 Mar 2019 14:45:16 GMT):
@dbluhm thank you! @daidoji appreciate the response as we;;!

Alexi (Tue, 05 Mar 2019 14:45:16 GMT):
@dbluhm thank you! @daidoji appreciate the response as well!

GEEKTEDDY (Wed, 06 Mar 2019 04:07:14 GMT):
Hi, I started a pool on one server like the doc says. (https://github.com/GEEKTEDDY/indy-sdk#2-starting-the-test-pool-on-a-specific-ip-address), and then I ran the SDK's sample code on the same server, I tried to connect the pool using localhost ip(127.0.0.1), why can't it find the pool? I think they deployed on the same server, it could be worked.

ianco (Wed, 06 Mar 2019 04:41:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=WJevXntBbRXegCEjP) @GEEKTEDDY You have to connect on the IP the pool is listening on. If you want to connect on 127.0.0.1 use this: https://github.com/GEEKTEDDY/indy-sdk#1-starting-the-test-pool-on-localhost

izashkalov (Wed, 06 Mar 2019 08:14:11 GMT):
Hello everyone. I have a question. How correct connect libindy to the Android Project? Into description https://github.com/hyperledger/indy-sdk written that can use libindy.so wich contains all need dependencies, but if i add only this .so file, then LibIndy.api will be null. I added the dependencies libgnustl_shared.so, libcrypto.so and this mistake fix. Can you fix description about connect libindy to the project with additional dependencies (libgnustl_shared.so, libcrypto.so ) or give me link where this already described?

Diiaablo95 (Wed, 06 Mar 2019 11:48:25 GMT):
Has joined the channel.

Diiaablo95 (Wed, 06 Mar 2019 11:48:27 GMT):
Hey all guys! I am trying to setup an Indy pool, where I only have a trustee, a steward and a validator node. When running the generate_indy_pool_transactions script, only the node keys are saved, this means that no more steward and (hence) nodes can be added to the pool. On the other side, I tried to generate the needed keys and start a pool with only one trustee, one steward and one validator, but by debugging the indy-cli client, I found that the validator node shows a public key of [0, 0, 0]..., and the assertion rc == 0 (src/curve_client.cpp:267) stops the execution. Apparently, the generated test pool and domain transactions (with 1 node and 0 clients) and the my pool and domain transactions look the same in structure. Nevertheless, I cannot manage to connect the indy-cli client to the pool. Do you guys have any suggestions concerning this?

MattRaffel (Wed, 06 Mar 2019 15:58:33 GMT):
@izashkalov Have you seen the scripts for building libindy for android? there are several steps. Other groups are using these without any of the issues you listed. I would check that out.

magicindustries (Thu, 07 Mar 2019 01:28:28 GMT):
Has joined the channel.

magicindustries (Thu, 07 Mar 2019 01:29:24 GMT):
Has anyone looked at including libindy in a Unity app, or looked at a non-ios specific objective-c wrapper?

magicindustries (Thu, 07 Mar 2019 01:30:21 GMT):
I'm looking at creating a basic agent in Unity but the objective-c wrapper seems aimed at native ios apps

magicindustries (Thu, 07 Mar 2019 01:36:31 GMT):
failing that, could anyone help me translating the objective-c wrapper please? :)

magicindustries (Thu, 07 Mar 2019 04:11:06 GMT):
Duh not enough coffee, I'll try that again - has anyone done any work on a *c sharp* wrapper for libindy?

tplooker (Thu, 07 Mar 2019 08:30:10 GMT):
@magicindustries yeap there is a c# wrapper, have a look here https://github.com/hyperledger/indy-sdk/tree/master/wrappers/dotnet there is a nuget package for it, also https://github.com/streetcred-id/agent-framework might be of interest too.

SergeyBrazhnik (Thu, 07 Mar 2019 10:26:46 GMT):
Hello everyone! Can somebody point the document where I can find descriptions of how Ledger stores it's transactions. Especially can I find on Ledger user's private data?

dklesev (Thu, 07 Mar 2019 12:50:18 GMT):
@SergeyBrazhnik https://sovrin.org/wp-content/uploads/2018/10/What-Goes-On-The-Ledger.pdf if you run the local pool you can view all transactions with `read_ledger` f.e. or you can use https://indyscan.io/home/SOVRIN_MAINNET

JamesCarter (Thu, 07 Mar 2019 14:35:55 GMT):
Has joined the channel.

nehalshah50 (Thu, 07 Mar 2019 16:53:20 GMT):
The VCX Java wrapper uses Java Concurrent library from net.sourceforge.streamsupport: java9-concurrent-backport .... Is there a plan to upgrade it to Java 11? I am trying to use RxJava observable pattern in order to make servies reactive. Currently it is using this third party library it doesn't seem to be possible

nehalshah50 (Thu, 07 Mar 2019 16:56:56 GMT):
Hi.. Most of the VCX Java Wrapper API functions are using third party Java Concurrent library (java9.util.concurrent.CompletableFuture vs java.util.concurrent.CompletableFuture) from net.sourceforge.streamsupport: java9-concurrent-backport: 1.1.1 . Is there a plan to upgrade to use normal java libraries? I am trying to use RxJava observable pattern in order to make my services more reactive. Also is there a plan to make all API functions Asynchronous or pub/sub based or adding reactive support?

swcurran (Thu, 07 Mar 2019 17:29:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=KBjL7X5RnTonQjWgn) @SergeyBrazhnik And to be clear - no user private data goes on the ledger. That's an anti-pattern on any public ledger.

MattRaffel (Thu, 07 Mar 2019 17:43:18 GMT):
@SergeyBrazhnik this is a good document concerning what goes on the ledger. https://sovrin.org/wp-content/uploads/2018/10/What-Goes-On-The-Ledger.pdf

AxelNennker (Thu, 07 Mar 2019 19:12:19 GMT):
Could somebody please explain to me why this is needed? `indy = { path = "../wrappers/rust" }` https://github.com/hyperledger/indy-sdk/blob/master/libindy/Cargo.toml#L96 I think this breaks the Rust-plugin in IDEA (utils is privat) and it is the reason why the tests don't see `src` as other Rust projects do. Also it breaks cross-compiling tools that work using docker and and mount libindy but do not know about `../wrappers/rust`. Why was this introduced? Looks like an architectural error to me but please explain. Thanks.

theoturner (Thu, 07 Mar 2019 19:20:41 GMT):
Would like to do a PR with a mac installer. Would dump this in libindy folder as with android. Right location @TelegramSam ?

TelegramSam (Thu, 07 Mar 2019 19:23:42 GMT):
@esplinr would have a better opinion about the sdk repo.

esplinr (Thu, 07 Mar 2019 19:34:06 GMT):
:arrow_up: Passing on to @sergey.minaev (when he is back from holiday) and @MattRaffel in the interim.

theoturner (Thu, 07 Mar 2019 19:39:15 GMT):
While I'm at it I've also written a quite extensive guide for python - it's not clear whether to stick this in `wrappers/python`, `samples/python` or `docs`.

esplinr (Thu, 07 Mar 2019 20:04:14 GMT):
@theoturner Or it might be best to post it to your blog. Anything that goes in the repo has to be maintained.

theoturner (Thu, 07 Mar 2019 20:17:00 GMT):
I understand @esplinr. It breaks up the existing >1k `getting_started.py` which isn't very dev-friendly. The only thing it adds is the ability to run agents on different machines.

theoturner (Thu, 07 Mar 2019 20:17:00 GMT):
I understand @esplinr . It breaks up the existing >1k `getting_started.py` which isn't very dev-friendly. The only thing it adds is the ability to run agents on different machines.

theoturner (Thu, 07 Mar 2019 20:17:00 GMT):
I understand @esplinr . It breaks up the existing >1k lines `getting_started.py` which isn't very dev-friendly. The only thing it adds is the ability to run agents on different machines.

esplinr (Thu, 07 Mar 2019 20:52:45 GMT):
Sounds like a good addition.

MattRaffel (Thu, 07 Mar 2019 21:01:37 GMT):
@theoturner I would like to understand the need/problem to solve by having a mac installer. can you provide more information?

nehalshah50 (Thu, 07 Mar 2019 22:08:40 GMT):
Is cloud agency on Test is down or running slow? I have been sending messages in my test to Connect.Me and it takes lot of time to arrive

esplinr (Thu, 07 Mar 2019 22:59:20 GMT):
@nehalshah50 Thanks for raising the concern. We haven't seen any slowness, but we'll poke around and see if we see any problems.

esplinr (Thu, 07 Mar 2019 22:59:20 GMT):
@nehalshah50 Thanks for raising the concern. We haven't seen any slowness, but we'll poke around and see if we see what we uncover.

mgbailey (Thu, 07 Mar 2019 23:09:30 GMT):
@nehalshah50 I can confirm your observation. Looking into it.

magicindustries (Fri, 08 Mar 2019 00:52:04 GMT):
Thanks @tplooker, much appreciated

fhmarino (Fri, 08 Mar 2019 02:00:57 GMT):
Has joined the channel.

theoturner (Fri, 08 Mar 2019 10:02:49 GMT):
@MattRaffel Lots of steps split between various readmes. All fully scriptable so am just dumping those same steps into a bash script. End user: `./mac_install.sh`

theoturner (Fri, 08 Mar 2019 10:12:01 GMT):
This should also be easier to maintain.

cguerin (Fri, 08 Mar 2019 11:00:31 GMT):
Hi, Does anyone know how i can check if a credential is revoked or not (from the prover or from the issuer)? Thx

dnnn (Fri, 08 Mar 2019 13:12:23 GMT):
Hi all! has anybody encountered an issue with `operation ref` equal to `0` in the output of `build_cred_def_request`? Could you please share any hints on what could cause it?

MattRaffel (Fri, 08 Mar 2019 15:06:54 GMT):
@theoturner make the PR. the maintainers (including myself will take a look).

smithbk (Fri, 08 Mar 2019 17:50:39 GMT):
Can someone tell me how to issue a credential with an expiration? I thought that I heard that it was possible but am not seeing how. Thanks

swcurran (Fri, 08 Mar 2019 17:55:35 GMT):
That is not possible in the current implementation. You have to use revocation.

smithbk (Fri, 08 Mar 2019 18:02:40 GMT):
ok, thanks ... a follow up question pls. I had been writing pairwise DIDs to the ledger and verification with revocation was working. However, if I stop writing pairwise DIDs to the ledger, verification with revocation doesn't work. In particular, the call to `verifier_verify_proof` always returns failure. If I do not write pairwise DIDs to the ledger and disable revocation, then verification works again. Any ideas why this might be the case?

smithbk (Fri, 08 Mar 2019 18:02:40 GMT):
ok, thanks ... a follow up question pls. I had been writing pairwise DIDs to the ledger and verification with revocation was working. However, if I stop writing pairwise DIDs to the ledger, verification with revocation doesn't work. In particular, the call to `verifier_verify_proof` always returns False. If I do not write pairwise DIDs to the ledger and disable revocation, then verification works again. Any ideas why this might be the case?

nehalshah50 (Fri, 08 Mar 2019 18:04:19 GMT):
hi....we are noticing one issue with Connect.Me app....When we delete the connection it still keeps credentials from that old connection in the wallet

Alexi (Fri, 08 Mar 2019 18:30:34 GMT):
hello, i am having an odd issue that im not too sure how to resolve and was hoping someone might be able to help. In short im am building an api in python3 with the indy-sdk and am currently working on establishing connections. when I build the connection response which is encrypted with indy crypto.anon_crypt it returns bytes. When i get the encrypted response, I want my api to return these bytes in a json so it can be sent to the connection requester to accept and finalize the connection, but bytes are not json serializable so i have to decode first. However when i try to decode I get the following error: ``` UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb8 in position 0: invalid start byte ``` (obviously byte 0xb8 is not always 0xb8 it changes each time, but the error is always the same. Has anyone encountered this and found a solution and or how have people been working around this? example encrypted response: ``` b'\xb8\x95\x91\'"3\x10\xdd\xf2\xe0\x96\x1c\xa6\xd2\xf8\xc4p\xa6\x19u\xd5\xaf\x8d\xca\xa2|\x8e\x14\xef\x97Q\x01\xaeZ\xb5O\x03g3#\x1c\xd7)k\x17\x8f\xbfh}\xf5\xef/\x1az\x17\xad+\x1fb\xdaT\xcf,\xe8;\xbdT\xa1\xb4)\x92\xa3\xfa~V\xd6A:0\x0b\xea\xb6\xfb?\xb9\x13b\xf8\x0c\xd6\xf5\x91\xaf<\xb3~\xb2\x18/\xd9\x02h\xcfx\x8a\xff,\x98\x7f`I\xcc1IH\xcb\xa2\xda~\r\x16\xfbl%\x08\x84\x8f\x87\x94-\x83\xc75#\xd4\xee\x04\x0bb\xac\xd0Q\xec\xc3\xc1]\x19\x91\x9e\xbf\xecqG\xba\\Bb\x86d\x94\x9ad\x92\xcd\xfa\xc4\xf2U\xaf\x1f\xbfB\x8f\x12\xe0J\xe9\xce[\x1a\x12\xe0\xf2\xfc(\xd7\xf9\xf4[@\xbe\xfb\x86\xe3\x1e4\xd7@h\xf8\x8d\xb1w\x06\xcb\x18Pggk.\x92=\x02,\xec\xfe+\xd78\x97\x80\x19\xb8\xb1"\xed\\\xe7:\xe1n\x11\x1bg\x81\xf0()\x8d#\x9b\xd8\xe6)\x93\xda\x0bnU\xc8\xdc\x19\xf0wI8Y\xc4\x8e\x1a@\x19*(\xc9bJ\xef\xda`\xde\x90\x9b\xb7\xe8O\x88\xdfcF\xb2\x07:\xaf?I\x19\xcf\x1aE\xd2\xa9vs\xca\xba\xe2\xec\xca\xa91\x14' ```

dbluhm (Fri, 08 Mar 2019 18:35:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9AN8N8j6YyFxcAQNP) @Alexi Where are you getting the encrypted response from?

dbluhm (Fri, 08 Mar 2019 18:39:03 GMT):
Oh, I see, I think I misunderstood.

dbluhm (Fri, 08 Mar 2019 18:39:51 GMT):
The result of crypto.anon_crypt is raw encrypted bytes that are likely not going to be valid in unicode. If you want to be able to serialize bytes, you need to use something like base64_urlencode

Alexi (Fri, 08 Mar 2019 18:42:33 GMT):
@dbluhm i see, thank you. so what is the best way to send the bytes message if not through a serialized json to the connection sender?

dbluhm (Fri, 08 Mar 2019 18:46:51 GMT):
The convention that has been used so far has been to base64_urlencode bytes into a string and then passed as serialized json with other context for the message. These are great questions for the #indy-agent channel where the standardization efforts around the agent protocol are discussed :slight_smile:

dbluhm (Fri, 08 Mar 2019 18:50:04 GMT):
It's also notable that as of version 1.8, libindy now includes a crypto.pack_message and crypto.unpack_message that handles converting the message you want to send into an auth or anon crypted package suitable for transmission over the wire and converting back off the wire into your message on the other side

dbluhm (Fri, 08 Mar 2019 18:51:05 GMT):
For a good example of this, please see the python reference agent housed at http://github.com/hyperledger/indy-agent/python

dbluhm (Fri, 08 Mar 2019 18:51:05 GMT):
For a good example of this, please see the python reference agent housed at https://github.com/hyperledger/indy-agent/tree/master/python

dbluhm (Fri, 08 Mar 2019 18:51:46 GMT):
Sorry, fixed that link

Alexi (Fri, 08 Mar 2019 18:53:00 GMT):
@dbluhm awesome thanks!!! Really appreciate the help, did not know those functions were available

dbluhm (Fri, 08 Mar 2019 18:53:29 GMT):
Welcome :slight_smile:

AxelNennker (Sat, 09 Mar 2019 07:42:43 GMT):
new issue https://jira.hyperledger.org/browse/IS-1215

xnopre (Mon, 11 Mar 2019 13:38:37 GMT):
Hi all. When a credential is revoked by the issuer, how can the issuer or the prover check if the credential is revoked or not ? I had migrated (from Python) and extended this script (https://github.com/hyperledger/indy-sdk/blob/master/samples/nodejs/src/anoncredsRevocationScenario.js), so I know how to verify a proof, but here, my need is to be able, as a issuer or a prover, to check if a credential is revoked or not. Thanks

xnopre (Mon, 11 Mar 2019 13:38:37 GMT):
Hi all. When a credential is revoked by the issuer, how can the issuer or the prover check if the credential is revoked or not ? I had migrated (from Python) and extended this script (https://github.com/hyperledger/indy-sdk/blob/master/samples/nodejs/src/anoncredsRevocationScenario.js), so I know how to verify a proof, but here, my need is to be able, as an issuer or a prover, to check if a credential is revoked or not. Thanks

jacobsaur (Tue, 12 Mar 2019 14:35:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=DEkjN5mp4HivEFsLC) @ianco I figured it out! For the benefit of anyone following this thread the key was to use node-ffi to pull in the libindystrgpostgres library and expose postgresstorage_init. I could add a section to the readme if people thought it would be useful. Thanks for pointing me in the right direction @ianco !

ianco (Tue, 12 Mar 2019 14:37:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=QceeseZoKdBE74m6z) @jacobsaur Great! I think it would be helpful to add to the readme, all Indy plug-ins will work the same way (including payment plug-ins) so good to know!

DucaDellaForcoletta (Tue, 12 Mar 2019 16:20:26 GMT):
Has joined the channel.

smithbk (Tue, 12 Mar 2019 19:08:04 GMT):
Hi anyone, I'm seeing a long pause (> 30 secs) when creating a proof (with proof of non-revocation). It appears that a connection is being dropped and so am wondering if there is some network issue causing the delay, but in order to debug, I need to understand why a connection is being made. Could someone help? Here are the pertinent logs: ```2019-03-12 18:08:50,591 - DEBUG - prover_create_proof: >>> wallet_handle: 247, proof_req_json: '{"name": "Verify Name", "version": "1.0", "requested_attributes": {"first_name_referent": {"name": "first_name", "restrictions": [{"schema_name": "ADOT Drive 2019-03-12 18:08:50,593 - DEBUG - do_call: >>> name: indy_prover_create_proof, args: (c_int(247), c_char_p(140051637479792), c_char_p(140051840197048), c_char_p(140051840024728), c_char_p(140051637564224), c_char_p(140051636077440), c_char_p(14005163756 2019-03-12 18:08:50,596 - DEBUG - do_call: Function indy_prover_create_proof returned err: 0 2019-03-12 18:08:50,596 - INFO - src/commands/mod.rs:120 | AnoncredsCommand command received 2019-03-12 18:08:50,597 - DEBUG - do_call: <<< 2019-03-12 18:08:50,597 - INFO - src/commands/anoncreds/mod.rs:54 | Prover command received 2019-03-12 18:08:50,598 - INFO - src/commands/anoncreds/prover.rs:210 | CreateProof command received 2019-03-12 18:08:50,601 - DEBUG - src/commands/anoncreds/prover.rs:560 | create_proof >>> wallet_handle: 247, proof_req: ProofRequest { nonce: BigNumber { openssl_bn: 1552414109463 }, name: "Verify Name", version: "1.0", requested_attributes: {"la2019-03-12 18:08:55,322 - DEBUG - /home/indy/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-0.8.2/src/lib.rs:503 | socket dropped 2019-03-12 18:08:55,322 - DEBUG - /home/indy/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-0.8.2/src/lib.rs:410 | context dropped 2019-03-12 18:09:28,239 - DEBUG - src/commands/anoncreds/prover.rs:598 | create_proof <<< proof_json: "{\"proof\":{\"proofs\":[{\"primary_proof\":{\"eq_proof\":{\"revealed_attrs\":{\"first_name\":\"247411636479637505783349\",\"last_name\":\"251303```

JamesCarter (Tue, 12 Mar 2019 19:32:42 GMT):
Hello! I have a question for the situation where: You have gone to two different VC issuers for the same schema. (say you have two different transcripts at two different universities). You have put two different credentials in the same wallet. When a proof request comes in (prove your have an A in this course), either credentials can potentially be used for various parts of the proof. Reasonably a user may want to use either one at their discretion for the various credentials It feels like we would need to use indy_prover_search_credentials_for_proof_req to get a search handle to get a list of credentials, and then present that list and use their choices to build out the indy_prover_create_proof jsons Do the wrappers (say java) not include any of this functionality (even just get list of possible credentials for specific attributes in a proof request)?

JamesCarter (Tue, 12 Mar 2019 19:38:19 GMT):
@smithbk IIRC creating a proof requires getting schemas, cred defs, and, for non-revocation, revocation entries from the hyperledger, so it does need to connect.

smithbk (Tue, 12 Mar 2019 19:54:37 GMT):
@JamesCarter Thanks ... I thought the schema and cred def IDs associated with a credential would be in the wallet and not require going to the ledger. Generating the proof of non-revocation would require (I think) getting the accumulator value from the ledger. I tried disabling revocation but I still see the same delay. In looking at the trace, I see trace from commands/anoncreds/prover.rs but not from services/anoncreds/prover.rs. Do you know how to enable those trace statements?

Alexi (Tue, 12 Mar 2019 20:37:01 GMT):
can anyone point me to a good resource that explains how edge services work / how to implement them?

reithmayer (Wed, 13 Mar 2019 07:48:08 GMT):
Has joined the channel.

xnopre (Wed, 13 Mar 2019 08:05:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=de5gkLjvyaYF9LFWG) Any idea ? .... :-) (= how a prover can check if a credential is revoked or not ?)

theoturner (Wed, 13 Mar 2019 10:46:58 GMT):
Error: `OSError: dlopen(libindy.dylib, 6): image not found` on MacOS can be caused by a `libsodium` upgrade. Fix: Run tests (e.g. `pytest` in `wrappers/python`) to get where Indy is looking for `libsodium`, it will be in the format `libsodium.XX.dyld`. Go to `/usr/local/opt/libsodium/lib/`, make a copy of copy of your `libsodium.YY.dyld` and rename the copy to `libsodium.XX.dyld`.

theoturner (Wed, 13 Mar 2019 10:47:20 GMT):
Posting this here as multiple forum posts reference this channel for the issue but a search returns nothing.

ianco (Wed, 13 Mar 2019 15:26:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=uKz4xo6bjE6AdZfR9) @xnopre When you create a credential you can link it to a revocation registry, and then when you ask for a proof you can as for a proof of non-revoked. I don't know all the details offhand but the anoncreds api docs are pretty thorough.

xnopre (Wed, 13 Mar 2019 16:05:12 GMT):
@ianco Thanks for your answer. I'm using proof, revocation, and proof verifications (with `verifierVerifyProof`). This points are OK for me. But here, my question is : how a prover (Alice) can check if a credential (provided by an issuer and stored in its wallet) has been revoked or not ? ....

ianco (Wed, 13 Mar 2019 16:36:37 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=hT47yEy72aF6qFmnK) @xnopre I'm not sure of the details. When you fetch a credential from the wallet there's a revocation registry id, and the proof can figure it out, so there must be a way in there somewhere

mcemkilinc (Wed, 13 Mar 2019 18:31:46 GMT):
Has joined the channel.

xnopre (Thu, 14 Mar 2019 07:47:42 GMT):
@ianco Yes, sure, there is a way somewhere but not sure this is available in SDK layer.... :-/

MarvelFisher (Thu, 14 Mar 2019 15:26:28 GMT):
Has joined the channel.

charliez (Thu, 14 Mar 2019 16:30:00 GMT):
Has joined the channel.

charliez (Thu, 14 Mar 2019 16:30:17 GMT):
Hey, channel, I'm testing the sovrin test network by replaying the AnoncredsRevoc example under indy-sdk repo, and I got the following error message: `Indy Error[113]: Error: Invalid structure, Caused by: RevocationRegistry not found for timestamp: 1552565450` Anyone has any idea about this error? Thanks

MattRaffel (Thu, 14 Mar 2019 17:18:54 GMT):
@charliez I suspect the example is out of date. what example did you follow/use?

nbrempel (Thu, 14 Mar 2019 22:38:52 GMT):
Hey everyone, I'm seeing a new error that I'm having trouble tracking down. Can anyone help me with this one? I'm trying to write a credential definition to the ledger with `issuer_create_and_store_credential_def ` and I'm getting the following error: ``` indy.error.IndyError: (, 'Error: Invalid structure\n Caused by: Invalid Schema json has been passed\n Caused by: missing field `ver` at line 1 column 1335\n') ``` The schema is fetched from the ledger and looks like this: ``` { "reqId": 1552602485063783919, "dest": "4QxzWk3ajdnEA37NdNU5Kt", "state_proof": { "multi_signature": { "value": { "pool_state_root_hash": "65x39zVf1VcB4YJsnMQEcdiSg2HHDWkWM1b1D1Bh1dPj", "txn_root_hash": "GpebrtXzacruyFT8FbL2bkDFzZy9Q5NdLduo4HUjBy4S", "timestamp": 1552602461, "ledger_id": 1, "state_root_hash": "G1E32kjx1vkpHPJv12HUqzD8tnDn1wmWaGycceyj6RjR" }, "signature": "R5EkKe8232bHT9wFTT1EmERY4tejvz5owVpckLroheGZZnDgkjCzLwj4ZpN4LGYZMuUvfZADkgaT3GfJLHhjD9UBFTnuJ3Vva8CxHV9zkbcZ8mvtabLeCVpDpB9PzJwRWzvEBVU7zgyuwgbydwRktjQQ9KZvXMEUC76DLzPie3dhKm", "participants": [ "Node3", "Node4", "Node2" ] }, "proof_nodes": "+QFu+FGAgICAoLO6YFYioX1bLP1xXB9xo+dKuw8ah100u8gXLBaUbtV+gICAgICAoL8QgC6a78sPnRhjdbUStwqlPP4TOGrPyYC4FAYtN/A9gICAgID4ZqUgUXh6V2szYWpkbkVBMzdOZE5VNUt0OjI6bmFtZV8xOjEuMC4wuD74PLg6eyJsc24iOjcsImx1dCI6MTU1MjYwMjQ2MSwidmFsIjp7ImF0dHJfbmFtZXMiOlsic3RyaW5nIl19ffixoAxH9T0gTPPUbPPgeq16gtikXFOlR5Av7AZhhywIOWbqgICg0NVs9ZNRNX/1d79Cc1myUeByU3e5Ukhfcn2KMvBEHZqAoAIbx/TDY2y4OJtZiJtzVNjJICBQpJ4h68cXrBVl0wEvgICAgICAgKBI8XETsYgB1hUVAdjoZj2bkWLpSrA5m4QLdXH5iuNr0YCgOzoZfFEvyKcPZvdFjW/+5+SwMc2p8UporYwQiM0hnBqA", "root_hash": "G1E32kjx1vkpHPJv12HUqzD8tnDn1wmWaGycceyj6RjR" }, "txnTime": 1552602461, "type": "107", "identifier": "4QxzWk3ajdnEA37NdNU5Kt", "seqNo": 7, "data": { "name": "name_1", "version": "1.0.0", "attr_names": [ "string" ] } } ```

tplooker (Thu, 14 Mar 2019 22:58:55 GMT):
I can second that I have been having the same issue with AgentFramework @nbrempel what version of indy sdk are you using?

tplooker (Thu, 14 Mar 2019 22:59:25 GMT):
@nbrempel mine appears to be intermittent, is yours consistent?

nbrempel (Thu, 14 Mar 2019 23:00:25 GMT):
so far consistent

nbrempel (Thu, 14 Mar 2019 23:00:44 GMT):
let me check the version

nbrempel (Thu, 14 Mar 2019 23:09:56 GMT):
this should be on 1.8.0

tomislav (Fri, 15 Mar 2019 00:01:14 GMT):
I've never encountered this. That's very odd. I assume you pass the schema to the parse_get_schema_response and use that result in the `issuer_create_and_store_credential_def`?

tplooker (Fri, 15 Mar 2019 00:04:26 GMT):
@tomislav Im pretty sure this is what is causing our intermittent failure in one of our unit tests in AF

nbrempel (Fri, 15 Mar 2019 00:05:01 GMT):
I just realized I forgot to call `parse_get_schema_response`

nbrempel (Fri, 15 Mar 2019 00:05:06 GMT):
🤦🏼‍♂️

nbrempel (Fri, 15 Mar 2019 00:05:08 GMT):
thanks all!

ianco (Fri, 15 Mar 2019 00:52:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=rLonjtagChmcaGQJL) @xnopre A round-a-bout way would be to issue yourself a proof request and see if you had credentials (not revoked) to satisfy the proof request. Otherwise, if you have an idea of what the API should look like in the sdk, I suggest to create a JIRA ticket which will get the request into the development pipeline.

xnopre (Fri, 15 Mar 2019 08:43:58 GMT):
Hi all. I still have my question : how a prover can check if a credential (issued by an issuer) is revoked or not... The only way I have found, but that's very empirical. As a prover, if I `GetRevocRegDelta` for a `revRegDefId`, I can see that there a field `issued` that is an array containing the list of `credRevId`. So that, if the prover has the `credRevId`, he can check if this ID is in the array field `issued` in the result of `GetRevocRegDelta`. But not sure that this solution is secured and clean.... There is probably another better solution... Thanks for any idea or help :-) ... cc @ianco

theoturner (Fri, 15 Mar 2019 14:09:15 GMT):
@xnopre revocation is awkward, but for a good reason: it is supposed to be non-disclosing, and you check by seeing if you can produce a correct product of numbers as I understand it from https://github.com/hyperledger/indy-sdk/blob/master/docs/concepts/revocation/cred-revocation.md. The 'correct' way as far as I can tell is to construct a proof including revocation states and verifying it (from the prover). @TelegramSam @esplinr @MattRaffel correct me if I'm wrong.

theoturner (Fri, 15 Mar 2019 14:16:34 GMT):
I.e. the verification will return a failure, hence the credential is revoked.

theoturner (Fri, 15 Mar 2019 14:19:31 GMT):
Could anyone refer me to docs/guide for loading a pool for testnet/mainnet in the SDK? I tried to load [pool_transactions_sandbox_genesis](https://raw.githubusercontent.com/sovrin-foundation/sovrin/stable/sovrin/pool_transactions_sandbox_genesis) in the same way as the local genesis tx data is in `getting_started.py` but get back `Node is not a validator Invalid library state`. Unable to find a guide so far, maybe I'm just bad at looking :/

xnopre (Fri, 15 Mar 2019 14:45:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=LT6vdX6vCxsudY49X) Thank you for your answer, but as I said in previous posts, I have developped a POC for several months, with schema, credentials, proof and different processes (applications) for each actor (issuer, prover/user, verifier). So I know the verification for a proof based on a credential, revoked or not. Anyway I have developped and share this script : https://github.com/hyperledger/indy-sdk/blob/master/samples/nodejs/src/anoncredsRevocationScenario.js. But now, my question is : how a prover (user, i.e. Alice) can check if a credential is its wallet is revoked or not. I know that revocation is touchy because of non-disclosing. But a user is entitled to know if a credential on its wallet is revoked or not :-)

tomislav (Fri, 15 Mar 2019 14:59:53 GMT):
@xnopre Indy SDK doesn't offer a way to check this, but a workaround would be for Alice to create a proof request with the credential definition id of the credential she wants to check, and verify that proof by constructing the proof revocation details from the ledger.

xnopre (Fri, 15 Mar 2019 15:20:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=iKbAqqjAJs58NBKap) @tomislav We are trying this workaround. What do you think ?

xnopre (Fri, 15 Mar 2019 15:20:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=iKbAqqjAJs58NBKap) @tomislav Many thanks for your answer ! We are trying this workaround. What do you think ?

tomislav (Fri, 15 Mar 2019 15:22:34 GMT):
I think that's a good way to do it. The prover will know the revocation registry id, it should be disclosed with the issued credential. So they can always check the revocation state from the ledger.

tomislav (Fri, 15 Mar 2019 15:33:19 GMT):
@xnopre I need to correct myself. The holder will not know the credRevId, that's for the issuer only. They will know the revRegDefId and they can use the verify a proof by creating a "self-verification" proof request. I suggest not to inspect the result of the revocRegDelta manually, as that's not the intended way to check credential validity, and may change with the update to the revocation handling.

MALodder (Fri, 15 Mar 2019 15:53:59 GMT):
The prover doesn’t need to do anything but look at the revoked indices and see if his is one of them. No need for zkps.

swcurran (Fri, 15 Mar 2019 16:34:19 GMT):
@MALodder - I think the folks are looking for how that is done in the code. What does the agent code do to check that? ASIDE - I think we will have the DIDComm OfferCredential message (or another one) that an Issuer will send to the Holder to say, "hey, I've revoked your credential XX, and I have a new one for you". Our thought is that a Holder will be able to get an active instance of a Credential, and when revocation occurs the Issuer will be able to issue a new credential instance with new data.

swcurran (Fri, 15 Mar 2019 16:34:19 GMT):
@MALodder - I think the folks are looking for how that is done in code. What does the agent code do to check that? ASIDE - I think we will have the DIDComm OfferCredential message (or another one) that an Issuer will send to the Holder to say, "hey, I've revoked your credential XX, and I have a new one for you". Our thought is that a Holder will be able to get an active instance of a Credential, and when revocation occurs the Issuer will be able to issue a new credential instance with new data.

MALodder (Fri, 15 Mar 2019 16:35:39 GMT):
@swcurran I get that they want it in code, but I would need to look up how to get the revocation info from the SDK

MALodder (Fri, 15 Mar 2019 16:35:53 GMT):
I mainly pointing in a direction that I hope to be simpler

theoturner (Fri, 15 Mar 2019 17:42:42 GMT):
How do you check revoked indices using the SDK?

Dima12101 (Fri, 15 Mar 2019 19:42:09 GMT):
Has joined the channel.

MALodder (Fri, 15 Mar 2019 21:02:41 GMT):
I'm not sure, I would have to look at it

charliez (Sat, 16 Mar 2019 08:54:48 GMT):
@MattRaffel Hi Matt, thanks for your reply. I'm following this example https://github.com/hyperledger/indy-sdk/blob/master/samples/nodejs/src/anoncredsRevocationScenario.js and it works with the test network. But when I rewrote the scenario in Kotlin, I got the `Indy Error[113]: Error: Invalid structure` error at the step of fetching reovc registry from ledger... will double check again...

sergey.khoroshavin (Mon, 18 Mar 2019 07:22:22 GMT):
Has left the channel.

xnopre (Mon, 18 Mar 2019 09:17:28 GMT):
@tomislav Thanks for your answer. But I think that "self-verification" proof request is a little heavy... It's not a simple way for the holder to check its credentials... :confused: ... I'm surprised that, apparently, there is no simple solution for a holder (prover) to check if its credential are revoked or not. For me, it's very important, and very useful with many use cases ! As @swcurran said, there could be many use cases, and many solution, but for me, the first step (and the first need) is to be able for a holder to check a credential (and eventually be able to ask the issuer for a new credential). What do you think ? cc @MALodder @swcurran @theoturner and other ;-)

aronvanammers (Mon, 18 Mar 2019 14:14:06 GMT):
Has joined the channel.

jljordan_bcgov (Mon, 18 Mar 2019 15:20:24 GMT):
@xnopre I suspect that it is the nature of ZKP protocols in that they involve holder/prover, ledger and verifiers which prevents simple self-verifications. No single party to the protocol holds all the piece necessary to have full knowledge so this seems to be to be an acceptable trade off given the potential for improving the ability to have privacy respecting digital interactions

theoturner (Mon, 18 Mar 2019 15:32:18 GMT):
@xnopre It's a choice between non-disclosure and convenience. You may see higher-level interfaces evolve where for ex. the issuer app broadcasts revocation to the revokees (?), bypassing this issue.

theoturner (Mon, 18 Mar 2019 15:32:52 GMT):
In fact if you're building something where your app covers all of the issuers involved you could include this yourself.

theoturner (Mon, 18 Mar 2019 15:33:09 GMT):
And securely transfer using `authCrypt`

xnopre (Mon, 18 Mar 2019 15:37:36 GMT):
Hi all :-) . I try to run `cargo test` on `libindy` (updated `master` branch) but I got `36 failed` tests :-( ... I'm on MacOS. I have the same result running `cargo test` on MacOs or in Docker Linux environment. What's wrong ? Other problem (linked ?) : the result is not always the same : - sometimes I got different tests failed count (42, 64, ...) - sometimes I got this error : `error: process didn't exit successfully: `[...]/indy-sdk/libindy/target/debug/deps/indy-921a4dd71424c1b9` (signal: 10, SIGBUS: access to undefined memory)` Any idea for this problems ? Thanks for any help :-)

xnopre (Mon, 18 Mar 2019 15:37:36 GMT):
Hi all :-) . I try to run `cargo test` on `libindy` (on updated `master` branch) but I got `36 failed` tests :-( ... I'm on MacOS. I have the same result running `cargo test` on MacOs or in Docker Linux environment. What's wrong ? Other problem (linked ?) : the result is not always the same : - sometimes I got different tests failed count (42, 64, ...) - sometimes I got this error : `error: process didn't exit successfully: `[...]/indy-sdk/libindy/target/debug/deps/indy-921a4dd71424c1b9` (signal: 10, SIGBUS: access to undefined memory)` Any idea for this problems ? Thanks for any help :-)

xnopre (Mon, 18 Mar 2019 15:37:36 GMT):
Hi all :-) . I try to run `cargo test` on `libindy` (on updated `master` branch) but I got many failed tests :-( ... I'm on MacOS. I have the same result running `cargo test` on MacOs or in Docker Linux environment. What's wrong ? Other problem (linked ?) : the result is not always the same : - sometimes I got different tests failed count (42, 64, ...) - sometimes I got this error : `error: process didn't exit successfully: `[...]/indy-sdk/libindy/target/debug/deps/indy-921a4dd71424c1b9` (signal: 10, SIGBUS: access to undefined memory)` Any idea for this problems ? Thanks for any help :-)

xnopre (Mon, 18 Mar 2019 15:37:36 GMT):
Hi all :-) . I try to run `cargo test` on `libindy` (on updated `master` branch) but I got many failed tests :-( ... I'm on MacOS. I have the same result running `cargo test` on MacOs or in Docker Linux environment. What's wrong ? Other problem (linked ?) : the result is not always the same : - sometimes I got different tests failed count (42, 64, ...) - sometimes I got this error : `error: process didn't exit successfully: [...]/indy-sdk/libindy/target/debug/deps/indy-921a4dd71424c1b9 (signal: 10, SIGBUS: access to undefined memory)` Any idea for this problems ? Thanks for any help :-)

swcurran (Mon, 18 Mar 2019 16:17:21 GMT):
I agree with @xnopre that there should be an easy way for the holder to find out if their credential has been revoked. The passive way is to expect that the Issuer inform the Holder of the revocation, along with an offer of a new Credential to replace it. Not particularly foolproof. This is the push approach. The active process is to monitor updates to the Revocation Registry and to check the updates to see if the Holder's credential index has been added to the witnesses (I think that's the process) - aka what @MALodder said. It seems reasonable that such a function should be added to the indy-sdk. This is a polling approach, which can get pretty expensive if you are doing this for every credential you have. A cloud agent might be helpful for this - e.g. a full revo check or even just monitoring for updates of all of the revo registries you are using (if you don't want to share too much info with your cloud agent). And of course, constructing a proof to use the credential also works, and allows for discovery-on-use of the credential - not particularly helpful.

MALodder (Mon, 18 Mar 2019 16:32:19 GMT):
constructing a proof still requires you to know whether your index was revoked or not

MALodder (Mon, 18 Mar 2019 16:33:45 GMT):
A polling approach doesn't need to be expensive, think about how often the issuer is actually revoking credentials, if its only like once a month that a revocation occurs, then you could poll once a week

MALodder (Mon, 18 Mar 2019 16:33:55 GMT):
you'll have to do this anyway

MALodder (Mon, 18 Mar 2019 16:34:06 GMT):
whenever you go to prove something

xnopre (Mon, 18 Mar 2019 16:54:35 GMT):
Hi all. Running `cargo test` on `libindy` (on up to date `master` branch), I got always this errors : ```test ledger_demo_works ... FAILED failures: ---- ledger_demo_works stdout ---- thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Timeout', src/libcore/result.rs:997:5 stack backtrace: [...] 9: >::unwrap at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858/src/libcore/result.rs:798 10: demo::ledger_demo_works at tests/demo.rs:546 11: demo::ledger_demo_works::{{closure}} at tests/demo.rs:481 12: core::ops::function::FnOnce::call_once ``` Does someone have any idea on what's happening, and what is the solution ? Thanks

MattRaffel (Mon, 18 Mar 2019 17:01:29 GMT):
@xnopre have to ask what might seem like the obvious: do you have nodes accessible or running (like through a docker image)?

swcurran (Mon, 18 Mar 2019 20:35:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5vw8ZwBNQxp8Jpso8) @MALodder I think that indy-sdk calls to construct the proof handles the revocation check. The issue is that the logic to handle that check seems to not be exposed outside of the indy-sdk.

MALodder (Mon, 18 Mar 2019 20:35:45 GMT):
yes I agree

MALodder (Mon, 18 Mar 2019 20:35:49 GMT):
just looked at the code

swcurran (Mon, 18 Mar 2019 20:38:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=i3hngS3PkQ7R6FpRu) @MALodder There are some pretty common uses cases where the issuer will issue revocations much more often than that - e.g. driver's licence I would expect to be at least daily. For those that issue less than that, I would expect them to issue revocations in real time vs. waiting for long periods. Of course it will vary, but since the holder doesn't know the issuer's policies, the polling frequency will be based on how tight a bound the holder requires.

swcurran (Mon, 18 Mar 2019 20:42:41 GMT):
A question about encoding of claims in credentials. If you have a claim that you don't expect to ever be proven in zero-knowledge (e.g. never used with a predicate), does it have to be encoded in 32 bytes? For example, if you want to have an image as a claim, or a complex JSON structure (for example, a course list in a transcripts credential) that will never be used in a ZKP, does it need to be encoded to 32 bytes? For those fields, we would still want to use them selectively - e.g. not include them in a proof if not requested, but we would never handle them with a predicate.

Alexi (Mon, 18 Mar 2019 21:12:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=gsYy7R4RGG3TDDkX8) @tomislav I was reading through this revocation thread, this caught my attention. @tomislav would this mean that if lets say faber wanted to get proof from alice that she has a credential given to her from acme, faber would not be able to know if the credential was revoked as the issuer of the credential was acme and therefore faber does not have the credRevId?

tomislav (Tue, 19 Mar 2019 01:06:11 GMT):
@Alexi Faber can request a proof from Alice and specify restrictions for issuer Acme as well as add non-revocation details for the time range it requires valid proof. Alice would then need to provide proof of non-revocation. That's how Faber would verify Alice has Acme credential that's not revoked. On the previous issue, @MALodder mentioned a possible way how technically revocations can be verified, this is however not exposed thru libindy in an API that says "verify_my_credential". This is why I suggested that one way to do it is Alice self-verify through proof.

MALodder (Tue, 19 Mar 2019 02:43:13 GMT):
I think we should add this as a feature for indy-sdk

xnopre (Tue, 19 Mar 2019 07:49:31 GMT):
@swcurran @MALodder @tomislav If I good understand, actually, the only solution for holder/prover to check a credential is to request itself a proof based on the credential ? .... It's a little heavy... Is there another solution ? If not, is it possible to add this feature (very useful to me) ?

xnopre (Tue, 19 Mar 2019 07:55:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=uGZvze7LX9iekGvQr) @MattRaffel No. Why ? Is it necessary for this test ?

xnopre (Tue, 19 Mar 2019 07:55:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=uGZvze7LX9iekGvQr) @MattRaffel Ah OK, I have taken a look at the code, and this test need a running pool on 127.0.0.1:9701-9708... Not so great for a unit test (to expect an external system running)... :confused: ... Anyway, I have started a pool, and now, I have `CommonInvalidState` error instead of `Success`... :-( . What's wrong, what is the solution ?

roqs (Tue, 19 Mar 2019 09:46:19 GMT):
Has joined the channel.

roqs (Tue, 19 Mar 2019 11:10:04 GMT):
Hello, I'm wondering if a credential schema can have other json objects as attributes? There are some documentation that describe what kind of schema is current supported in Indy?

roqs (Tue, 19 Mar 2019 11:10:04 GMT):
Hello, I'm wondering if a credential schema can have other json objects as attributes, does anyone know if this is possible? Also, there are some documentation that describe what kind of schema is current supported in Indy?

roqs (Tue, 19 Mar 2019 11:10:04 GMT):
Hello, I'm wondering if a credential schema can have other json objects as attributes, does anyone know if this is possible? Also, are there some documentation that describe what kind of schema is current supported in Indy?

roqs (Tue, 19 Mar 2019 11:11:20 GMT):
The examples in the documentation that I found just show simple data types in the attributes list

feliperdelara (Tue, 19 Mar 2019 12:56:43 GMT):
Hi. Has anyone been successful in building the Indy.framework for use with iOS? The cocoapod file is outdated so archiving a new build seems the best solution, but it does not work on my xcode

xnopre (Tue, 19 Mar 2019 13:56:29 GMT):
Hi all. I see that `anonCrypt` and `authCrypt` are replaced by `packMessage` (and the same for uncrypt --> unpack). I have read the explications in https://github.com/hyperledger/indy-sdk/tree/master/wrappers/nodejs#packmessage--wh-message-receiverkeys-sendervk----jwe . Reading the 2 algorithmes explanations (authcrypt and anoncrypt), I don't understand where the message is used and stored ? And what are this parameters that I can view in algorithmes explanations : `cek_iv`, `iv`, `cek`, `tag`, ... And in this JWE format, is there a link with authcrypt and anoncrypt describes here : https://github.com/hyperledger/indy-hipe/tree/master/text/0020-encryption-primitives ? Thanks ! :-)

DucaDellaForcoletta (Tue, 19 Mar 2019 13:56:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=KxKi6rqGKNtZqJd9b) I've the same problem for IOS. Adding to the pod file as described in the README https://github.com/hyperledger/indy-sdk/blob/master/wrappers/ios/README.md#how-to-install the version 1.8.1 is automatically searched but not found on the repo path because the last useful version deployed is https://repo.sovrin.org/ios/libindy/stable/indy-objc/1.6.8/. Anyone know when the indy 1.8.1 will be published as stable in the pod repo?

feliperdelara (Tue, 19 Mar 2019 14:02:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=knTtoX5bw7xeYLdSn) @DucaDellaForcoletta Exactly. I found out that 1.6.8 works but only with swift 4.1.2 and Apple requires a more recent version to upload to the Store.

smithbk (Tue, 19 Mar 2019 15:07:55 GMT):
Hi anyone, when calling `anoncreds.issuer_create_credential`, how should I compute the `encoded` value of the attribute in the cred_values_json arg ``` :param cred_values_json: a credential containing attribute values for each of requested attribute names. Example: { "attr1" : {"raw": "value1", "encoded": "value1_as_int" }, "attr2" : {"raw": "value1", "encoded": "value1_as_int" } } ``` I had been using encode from https://github.com/bcgov/von-connector/blob/master/connector/von_agent/util.py#L14 but was told that the encoded value should not be greater than 256 bits and that I should use a sha256. When trying that, I'm getting the following error. Any help is appreciated. ```2019-03-18 19:26:41,313 - DEBUG - issuer_create_credential: >>> wallet_handle: 17, cred_offer_json: '{"schema_id":"6RE8bn54axxLqhPS67NrGc:2:Transcript:1.0","cred_def_id":"3kgezhfQPNygk3v4L3yYyG:3:CL:15:TAG1","key_correctness_proof":{"c":"11382111582197782 2019-03-18 19:26:41,313 - DEBUG - issuer_create_credential: Creating callback 2019-03-18 19:26:41,313 - DEBUG - create_cb: >>> cb_type: .CFunctionType'> 2019-03-18 19:26:41,314 - DEBUG - create_cb: <<< res: 2019-03-18 19:26:41,314 - DEBUG - do_call: >>> name: indy_issuer_create_credential, args: (c_int(17), c_char_p(140603337797584), c_char_p(140603337959488), c_char_p(140603337804976), c_char_p(140604155053232), c_int(99), 2019-03-18 19:26:41,316 - INFO - src/commands/mod.rs:120 | AnoncredsCommand command received 2019-03-18 19:26:41,316 - INFO - src/commands/anoncreds/mod.rs:50 | Issuer command received 2019-03-18 19:26:41,316 - INFO - src/commands/anoncreds/issuer.rs:185 | CreateCredential command received 2019-03-18 19:26:41,316 - DEBUG - src/commands/anoncreds/issuer.rs:502 | new_credential >>> wallet_handle: 17, cred_offer: "_", cred_req: "_", cred_values_json: "_", rev_reg_id: Some("3kgezhfQPNygk3v4L3yYyG:4:3kgezhfQPNygk3v4L3yYyG:3:CL:15:TAG1:CL_A 2019-03-18 19:26:41,318 - DEBUG - _get_error_details: >>> 2019-03-18 19:26:41,318 - DEBUG - _get_error_details: <<< error_details: {'backtrace': '', 'message': 'Error: Invalid library state\n Caused by: IndyCryptoError: Internal OpenSSL errorOpenSSL error\n'} 2019-03-18 19:26:41,318 - DEBUG - _indy_callback: >>> command_handle: 267, err (, 'Error: Invalid library state\n Caused by: IndyCryptoError: Internal OpenSSL errorOpenSSL error\n'), args: (b'', None, None)```

smithbk (Tue, 19 Mar 2019 15:07:55 GMT):
Hi anyone, when calling `anoncreds.issuer_create_credential`, how should I compute the `encoded` value of the attribute in the cred_values_json arg? ``` :param cred_values_json: a credential containing attribute values for each of requested attribute names. Example: { "attr1" : {"raw": "value1", "encoded": "value1_as_int" }, "attr2" : {"raw": "value1", "encoded": "value1_as_int" } } ``` I had been using encode from https://github.com/bcgov/von-connector/blob/master/connector/von_agent/util.py#L14 but was told that the encoded value should not be greater than 256 bits and that I should use a sha256. When trying that, I'm getting the following error. Any help is appreciated. ```2019-03-18 19:26:41,313 - DEBUG - issuer_create_credential: >>> wallet_handle: 17, cred_offer_json: '{"schema_id":"6RE8bn54axxLqhPS67NrGc:2:Transcript:1.0","cred_def_id":"3kgezhfQPNygk3v4L3yYyG:3:CL:15:TAG1","key_correctness_proof":{"c":"11382111582197782 2019-03-18 19:26:41,313 - DEBUG - issuer_create_credential: Creating callback 2019-03-18 19:26:41,313 - DEBUG - create_cb: >>> cb_type: .CFunctionType'> 2019-03-18 19:26:41,314 - DEBUG - create_cb: <<< res: 2019-03-18 19:26:41,314 - DEBUG - do_call: >>> name: indy_issuer_create_credential, args: (c_int(17), c_char_p(140603337797584), c_char_p(140603337959488), c_char_p(140603337804976), c_char_p(140604155053232), c_int(99), 2019-03-18 19:26:41,316 - INFO - src/commands/mod.rs:120 | AnoncredsCommand command received 2019-03-18 19:26:41,316 - INFO - src/commands/anoncreds/mod.rs:50 | Issuer command received 2019-03-18 19:26:41,316 - INFO - src/commands/anoncreds/issuer.rs:185 | CreateCredential command received 2019-03-18 19:26:41,316 - DEBUG - src/commands/anoncreds/issuer.rs:502 | new_credential >>> wallet_handle: 17, cred_offer: "_", cred_req: "_", cred_values_json: "_", rev_reg_id: Some("3kgezhfQPNygk3v4L3yYyG:4:3kgezhfQPNygk3v4L3yYyG:3:CL:15:TAG1:CL_A 2019-03-18 19:26:41,318 - DEBUG - _get_error_details: >>> 2019-03-18 19:26:41,318 - DEBUG - _get_error_details: <<< error_details: {'backtrace': '', 'message': 'Error: Invalid library state\n Caused by: IndyCryptoError: Internal OpenSSL errorOpenSSL error\n'} 2019-03-18 19:26:41,318 - DEBUG - _indy_callback: >>> command_handle: 267, err (, 'Error: Invalid library state\n Caused by: IndyCryptoError: Internal OpenSSL errorOpenSSL error\n'), args: (b'', None, None)```

nbrempel (Tue, 19 Mar 2019 18:19:13 GMT):
@smithbk what are the credential values that are being used for that call? Can you paste the `cred_values_json` that is being passed to `indy_issuer_create_credential`?

smithbk (Tue, 19 Mar 2019 18:41:06 GMT):
@nbrempel I just fixed my problem thanks to help from Mike Lodder. The problem causing the error was that I was sending hex characters but it expects a decimal string. Once I changed to decimal, I got another error saying that the number was too large. The fix for that was to not encode an attr value if the string only contained decimal integer characters.

nbrempel (Tue, 19 Mar 2019 19:40:09 GMT):
ok, great!

JoshCook (Tue, 19 Mar 2019 21:00:11 GMT):
Hey everyone, i been having a problem lately with indy CLI, i cannot connect to any pool. it just says cannot connect to pool

mgbailey (Tue, 19 Mar 2019 21:50:07 GMT):
I don't see this error on mine

swcurran (Tue, 19 Mar 2019 22:31:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=DKPzc36beZFQZvRMH) @MALodder @nage - any response to this?

MALodder (Tue, 19 Mar 2019 22:42:26 GMT):
Then what’s the reason to include them in the credential? @swcurran

MALodder (Tue, 19 Mar 2019 22:42:56 GMT):
Why not just send it to the other party?

swcurran (Tue, 19 Mar 2019 22:54:20 GMT):
Because I want them deliverable in a proof. Issuer gives them to me, and when appropriate, I give them to a verifier.

swcurran (Tue, 19 Mar 2019 22:54:20 GMT):
Because I want them deliverable in a proof. Issuer gives them to me, and when appropriate, I give them to a verifier. Verifier knows they are from the issuer.

MALodder (Tue, 19 Mar 2019 23:04:50 GMT):
Then yes you would encode them as 32 bytes to include in the credential and you could choose to reveal them or not. You could actually encode it as you want as long as both parties understand what the encoding is

MALodder (Tue, 19 Mar 2019 23:06:06 GMT):
That’s what schema 2.0 is about

MALodder (Tue, 19 Mar 2019 23:06:52 GMT):
Defining how attributes should be represented

swcurran (Tue, 19 Mar 2019 23:14:58 GMT):
I don't understand how I encode same, an image (headshot picture) as 32 bytes of data. Is the encoding intended to be reversible? In other words, I assume I provide the claim data and an algorithm encodes them. At the other end, the data is decoded to get the original. Based on what you are saying that is not the case?

swcurran (Tue, 19 Mar 2019 23:14:58 GMT):
I don't understand how I encode something, an image (headshot picture) as 32 bytes of data. Is the encoding intended to be reversible? In other words, I assume I provide the claim data and an algorithm encodes them. At the other end, the data is decoded to get the original. Based on what you are saying that is not the case?

swcurran (Tue, 19 Mar 2019 23:14:58 GMT):
I don't understand how I encode something, say, an image (headshot picture) as 32 bytes of data. Is the encoding intended to be reversible? In other words, I assume I provide the claim data and an algorithm encodes them. At the other end, the data is decoded to get the original. Based on what you are saying that is not the case?

kdenhartog (Wed, 20 Mar 2019 01:13:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=iciMdL24MLTpAnPfB) @xnopre the purpose of the message is for P2P agent communication at this point. In the future it will likely be used in other ways. I don't understand what you mean by algorithms explanations. The second link is old and should be deprecated once authcrypt and anoncrypt functions are deprecated.

kdenhartog (Wed, 20 Mar 2019 01:13:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=iciMdL24MLTpAnPfB) @xnopre the purpose of the message is to encrypt messages for P2P agent communication at this point. In the future it will likely be used in other ways. I don't understand what you mean by algorithms explanations. The second link is old and should be deprecated once authcrypt and anoncrypt functions are deprecated.

mcemkilinc (Wed, 20 Mar 2019 05:39:34 GMT):
Hello when I include indy framework to xcode I get below error : dyld: Library not loaded: @rpath/libswiftCore.dylib Referenced from: /Users/cemkilinc/Library/Developer/CoreSimulator/Devices/55B88717-A075-4D7E-AA26-30639055633C/data/Containers/Bundle/Application/7A69189F-5F59-4E2D-BDC8-400D969489E8/Runner.app/Frameworks/Indy.framework/Indy Reason: image not found

lovesh (Wed, 20 Mar 2019 07:30:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=2PMgugroEDHRrAA7t) @swcurran The encoding is not meant to be reversible. The other end does not decode the data back to original (during selective disclosure), but encodes the claim data and compares with the encoding of expected data. To be technical, any attribute of a credential has to be a element of a prime field which is 32 byte size in our case. To convert any arbitrarily long data to 32 bytes, you hash that to 32 bytes and create prime field element.

lovesh (Wed, 20 Mar 2019 07:30:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=2PMgugroEDHRrAA7t) @swcurran The encoding is not meant to be reversible. The other end does not decode the data back to original (during selective disclosure), but encodes the claim data and compares with the encoding of expected data. To be technical, any attribute of a credential has to be an element of a prime field which is 32 byte size in our case. To convert any arbitrarily long data to 32 bytes, you hash that to 32 bytes and create prime field element.

xnopre (Wed, 20 Mar 2019 14:23:39 GMT):
@kdenhartog In `packMessage` documentation (https://github.com/hyperledger/indy-sdk/tree/master/wrappers/nodejs#packmessage--wh-message-receiverkeys-sendervk----jwe), there is a code block, beginning with "using authcrypt alg" with explanation on how the JWE is generated (anon vs auth). But in this explanations, I don't understand what is `cek_iv`, `iv`, `cek`, `tag`.... and I don't understand where the encrypted message is stored in this JSON structures...

JeromeK13 (Wed, 20 Mar 2019 14:24:52 GMT):
Hey guys We have some questions for about the indy SDK. Feel free to look into our Google form and share some knowledge. https://docs.google.com/forms/d/e/1FAIpQLSed17UUQx3AtjBz9LYNiJlYoCbyD3vE4FwSmjNXb3DwXQpr7Q/viewform Greets, JeromeK, Skilletpan

xnopre (Wed, 20 Mar 2019 14:32:30 GMT):
Hi all :-) . Here is a (step #2 of) description of my need and the imagined solution, in part based on Indy anonCrypt/authCrypt : https://gist.github.com/xaviernopre/e427624bfc61b2dc948aa8ae86092fb9#the-data-under-the-control-of-the-user---idea-step-2 if you can help me with comment, questions, ideas, ... Thanks :-)

swcurran (Wed, 20 Mar 2019 15:08:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=usnqRDgPPB5f5wmyJ) @lovesh Thanks - that makes more sense than limiting the size of claim data. A couple of additional questions, please - hope you don't mind. You have used the terms attribute and claim - are they interchangeable? Finally, am I correct that for a field to be used in a predicate, the order of the data must be preserved in the encoding? In other words what's proven is the encoded value, not the claim data.

lreinink (Wed, 20 Mar 2019 15:29:03 GMT):
Has joined the channel.

lreinink (Wed, 20 Mar 2019 15:31:53 GMT):
Hi, I'm currently doing "Write a DID and Query Its Verkey" from the how-tos. I'm doing the Java version, and I keep getting an error about the amount of arguments of `Wallet.createWallet` and `Wallet.openWallet`. The code is just copied and pasted, so I'm a bit confused why it does not work. https://github.com/hyperledger/indy-sdk/blob/master/docs/how-tos/write-did-and-query-verkey/java/step2.java that's where the problem is, in the last 4 lines.

lovesh (Wed, 20 Mar 2019 17:11:20 GMT):
@swcurran You are welcome Stephen, i don't mind the extra questions :smile: Yes, by claim data, i meant attributes. You are correct about "what's proven is the encoded value, not the claim data." Hence the encoding should always lead to the result for all, issuers, provers and verifiers.

swcurran (Wed, 20 Mar 2019 17:26:49 GMT):
Thanks! Shouldn't we move away from "attributes" and always use "claims"?

MALodder (Wed, 20 Mar 2019 17:42:31 GMT):
:anguished: not another term change

dbluhm (Wed, 20 Mar 2019 19:53:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=MFnLCQBp3HX4GoD7n) @xnopre The pack format in indy-sdk is very similar to JWE's with the exception of the `recipients` block also being MACed in the header. For more info on what those values are, see the JWE spec: https://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-40 Search for those terms on the page and you should find definitions

dbluhm (Wed, 20 Mar 2019 19:56:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=LbeNz4DbimxDHgvvM) @xnopre I'm confused by what you're trying to accomplish here. Would you be able to restate in different words?

dbluhm (Wed, 20 Mar 2019 19:56:47 GMT):
In reference to: https://gist.github.com/xaviernopre/e427624bfc61b2dc948aa8ae86092fb9#the-data-under-the-control-of-the-user---idea-step-2

kdenhartog (Thu, 21 Mar 2019 03:01:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=MFnLCQBp3HX4GoD7n) @xnopre Ahh that makes sense. These are variables that I used specifically in the IndySDK implementation that map to the api calls for libsodium. For example, to produce a `ciphertext` and `tag` with authenticated symetrical encryption you require a key (`cek`) an `iv`. The cek_iv is then used as an iv to encrypt the cek which stands for "content encryption key". As @dbluhm pointed out this is designed to be very close to JWEs.

lovesh (Thu, 21 Mar 2019 05:53:09 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=FY5ooeyAZfXFR8tuj) @swcurran I prefer "attributes". Used claim data only because it was used in the comment i was replying to.

xnopre (Thu, 21 Mar 2019 08:46:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=LbeNz4DbimxDHgvvM) @dbluhm @kdenhartog If you can take a look at this and let some feedbacks :-)

xnopre (Thu, 21 Mar 2019 09:41:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=LbeNz4DbimxDHgvvM) test

xnopre (Thu, 21 Mar 2019 09:42:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=LbeNz4DbimxDHgvvM) https://twinpeek.atlassian.net/wiki/spaces/TDP/pages/724631561/Indy+R+D ()

xnopre (Thu, 21 Mar 2019 09:42:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=LbeNz4DbimxDHgvvM) https://twinpeek.atlassian.net/wiki/spaces/TDP/pages/724631561/Indy+R+D (click on the date to go to initial message ;-) )

xnopre (Thu, 21 Mar 2019 09:42:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=LbeNz4DbimxDHgvvM) @dbluhm @kdenhartog Can you take a look at my gist and give me some feedbacks ? Thanks (click on the date to go to initial message ;-) )

kdenhartog (Thu, 21 Mar 2019 10:15:02 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=FY5ooeyAZfXFR8tuj) @swcurran By w3c, is a single piece of data called claim or attribute. When I was talking with MSFT they said it's claim, but I've never dug into the VC spec.

kdenhartog (Thu, 21 Mar 2019 10:15:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=FY5ooeyAZfXFR8tuj) @swcurran By w3c, is a single piece of data called claim or attribute. When I was talking with MSFT they said it's claim, but I've never dug into the VC spec.

kdenhartog (Thu, 21 Mar 2019 10:15:04 GMT):
@swcurran By w3c, is a single piece of data called claim or attribute? When I was talking with MSFT they said it's claim, but I've never dug into the VC spec.

sklump (Thu, 21 Mar 2019 10:23:17 GMT):
A claim is a statement (assertion) on one property (attribute), no? A credential is a multiplicity of claims about the same entity. I wish they hadn't done this to the language (but they did) because everyone gets tripped up on this and then forgets the details and has to go back to the source.

kdenhartog (Thu, 21 Mar 2019 10:24:39 GMT):
Thanks @sklump I'll give that a refresher read tomorrow

kdenhartog (Thu, 21 Mar 2019 10:25:23 GMT):
The language you used sounds tricky and nuanced enough that I think it's right

DucaDellaForcoletta (Thu, 21 Mar 2019 13:22:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=65iNBtJsXkvvbXTjd) @lreinink Check the libindy version used. The createWallet api has been modified in the latest version and it not take the pool. Maybe you are using an old example with a new libindy version

smithbk (Fri, 22 Mar 2019 19:42:08 GMT):
Hi, is it possible to generate a proof of ownership of a credential based on a cred_def_id but to not reveal any attributes or predicates from that credential?

smithbk (Fri, 22 Mar 2019 19:42:08 GMT):
Hi anyone, is it possible to generate a proof of ownership of a credential based on a cred_def_id but to not reveal any attributes or predicates from that credential?

MALodder (Fri, 22 Mar 2019 19:48:10 GMT):
@smithbk that’s basically proof of a credential without revealing any attributes

MALodder (Fri, 22 Mar 2019 19:48:17 GMT):
Proof of signature

mgbailey (Fri, 22 Mar 2019 19:52:26 GMT):
(i.e. proof of possession SSN, without revealing it) I have discussed this with the build team, but it is not in the current product.

mgbailey (Fri, 22 Mar 2019 19:52:26 GMT):
(i.e. proof of possession of a SSN, without revealing it) I have discussed this with the build team, but it is not in the current product.

smithbk (Fri, 22 Mar 2019 19:54:57 GMT):
@MALodder @mgbailey Thanks ... yeh, it seems to just be an API restriction since the cred_def_ids are associated with the 'restrictions' section under an attribute ... or was wondering if it were possible to have a 'restrictions' section of a predicate without any operation perhaps ... but I guess not

xnopre (Mon, 25 Mar 2019 09:36:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=DJ5bvCF5FysjXWJpe) Hi all. Any help for this problem ? I have 1 error running unit tests on libindy... :-/ ... Thanks

pyraman (Mon, 25 Mar 2019 10:00:07 GMT):
Has joined the channel.

pyraman (Mon, 25 Mar 2019 10:00:19 GMT):
hi all! After 4 months study Hyperledger Fabric - now we win a project require Indy 🙂. Stick with Indy today I found some awesome tools to make a testnet. My question is! Does Indy offer a public network and smart contract engine so that I can deploy smart contract to the network and call API from client?

xnopre (Mon, 25 Mar 2019 12:28:39 GMT):
Many thanks to @Artemkaaas for his help. The problem was with internal pool IP on Docker container. The solution is to use a `indy-pool` image build without `pool_ip` (`127.0.0.1` is used by default) or to run the container with `--net` and `--ip` parameters to specify the same IP for the container os `pool_ip` parameter used when building image. :-)

sacchit (Mon, 25 Mar 2019 15:11:06 GMT):
Has joined the channel.

izashkalov (Mon, 25 Mar 2019 16:19:35 GMT):
Hello all! When i try call Anoncreds.issuerCreateAndStoreRevocReg() then recived error " E/indy: src/errors/indy.rs:73 | Casting error to ErrorCode: Permission denied (os error 13)". Can you tell me what accesses are necessary for correct work?

swcurran (Mon, 25 Mar 2019 16:25:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=cMHFpq22Q4wYoTsbo) @pyraman Indy does have a public permissioned network for production usage (Sovrin Mainnet), plus other public networks for testing (Sovrin Testnet - soon to be changed via a name). As you have found, you can also spin up your own environment for testing. There is not the concept of a smart contract in Indy. Indy is quite different from Fabric. I suggest that you look at the getting started materials to get an understand of the key concepts in Indy - notably DIDs and Verifiable Credentials. Once you get a handle on the VC Model, you will likely find that much that is done in private blockchains like Hyperledger Fabric can be done with Hyperledger Indy - no private blockchain needed.

bricg (Mon, 25 Mar 2019 16:35:28 GMT):
Has joined the channel.

bricg (Mon, 25 Mar 2019 16:39:39 GMT):
Hi, I'm trying to run an example of a proof_request containing the age verification predicate. I'm still on v1.4.0 and my proof request looks like this ```{ "required": false, "name": "Age_Profile", "version": "1.0.0", "nonce": "1275273812765872", "requested_attrs": {}, "requested_predicates": { "predicate1_referent": { "attr_name": "age", "p_type": ">=", "value": 18, "restrictions": [ { "schema_key": { "name": "entity.person" } } ] } } }```

bricg (Mon, 25 Mar 2019 16:42:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=bWJnPxhEx8xAWJnkp) but I don't think the response from the bcovrin construct-proof api I'm using is what its supposed to be ```{"proof": {"identifiers": {}, "proof": {"proofs": {}, "aggregated_proof": {"c_hash": "17581745934805546029946686208002082275069028869859377397144702764549275017729", "c_list": []}}, "requested_proof": {"unrevealed_attrs": {}, "revealed_attrs": {}, "predicates": {}, "self_attested_attrs": {}}}}```

bricg (Mon, 25 Mar 2019 16:44:15 GMT):
Can anyone confirm if my proof request looks correct, and if there are any examples of this use case that I could follow?

bricg (Mon, 25 Mar 2019 17:03:06 GMT):
Oh, I've just noticed that the bcovrin construct-proof api ProofRequestProcesser.py does not support predicates, which would explain the response. Is there any example python code for constructing a proof based on a proof request json?

cobear25 (Mon, 25 Mar 2019 18:13:34 GMT):
Has joined the channel.

cobear25 (Mon, 25 Mar 2019 18:45:48 GMT):
I know people have asked this before, but there seems to be some stuff missing in the iOS wrapper. Following the instructions doesn't work because it expects some things to be local on your machine but doesn't specify where to get them. Also the latest podspec is pointing to a non-existent directory. The latest version is 1.8.1 but as you can see here: https://repo.sovrin.org/ios/libindy/stable/indy-objc/ there is no version 1.8.1

Ryan2 (Tue, 26 Mar 2019 04:49:13 GMT):
Has joined the channel.

xnopre (Tue, 26 Mar 2019 07:38:16 GMT):
Hi all. Where is the CI server for the project (and perhaps the build chain) ? Is it public ?

izashkalov (Tue, 26 Mar 2019 07:48:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Pw3xQ8EneQ3Purxth) Can you help me?

izashkalov (Tue, 26 Mar 2019 09:35:09 GMT):
stack trace {code} I/issuer_command_executor: src/commands/anoncreds/issuer.rs:180 | CreateAndStoreRevocationRegistryRegistry command received E/indy: src/errors/indy.rs:73 | Casting error to ErrorCode: Permission denied (os error 13) W/System.err: java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.IOException: An IO error occurred. {code}

izashkalov (Tue, 26 Mar 2019 09:35:09 GMT):
stack trace : I/issuer_command_executor: src/commands/anoncreds/issuer.rs:180 | CreateAndStoreRevocationRegistryRegistry command received E/indy: src/errors/indy.rs:73 | Casting error to ErrorCode: Permission denied (os error 13) W/System.err: java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.IOException: An IO error occurred.

ivanpagac (Tue, 26 Mar 2019 11:38:14 GMT):
Has joined the channel.

ivanpagac (Tue, 26 Mar 2019 11:39:31 GMT):
Hi folks, first of all, you are doing great job. Second, trying to build at least the ios wrapper demo but with no success. Lot of missing things, is there a version to just clone & build & run? Thanks

ivanpagac (Tue, 26 Mar 2019 13:45:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JYQHDSwL37qBGtCxi) @dnnn could you please share the steps to build? I also ended up on step 7

sklump (Tue, 26 Mar 2019 14:16:29 GMT):
Quick easy question for those on this level of design: *Q:* is the purpose of a master secret in a prover's wallet to tie together claims in a proof to prove that they are about the same entity (and hence the claims together constitute a credential)? _(if so, it may lead to a slight ontological smear we can live with for the OrgBook shared, public wallet, sharing info for many entities)_

sklump (Tue, 26 Mar 2019 14:16:29 GMT):
Quick easy question for those on this level of design: *Q:* is the purpose of a master secret in a prover's wallet to tie together claims in a proof to prove that they are about the same entity (and hence the claims together constitute a credential)? _(if so, it may lead to a slight ontological smear we can live with for the OrgBook's shared, public wallet, which shares public info for many entities)_

sklump (Tue, 26 Mar 2019 14:16:29 GMT):
Quick easy question for those on this level of design: *Q:* is the purpose of a master secret in a prover's wallet to tie together claims in a proof to prove that they are about the same entity (and hence the claims together constitute a credential)? _(if so, it may lead to a slight ontological smear we can live with for the OrgBook's shared wallet, which shares public info for many entities)_

sklump (Tue, 26 Mar 2019 14:16:29 GMT):
Quick easy question for those on this level of design: *Q:* is the purpose of a master secret in a prover's wallet to tie together claims in a proof to prove that they are about the same entity (and hence the claims together constitute a W3C credential)? _(if so, it may lead to a slight ontological smear we can live with for the OrgBook's shared wallet, which shares public info for many entities)_

sklump (Tue, 26 Mar 2019 14:16:29 GMT):
Quick easy question for those on this level of design: *Q:* is the purpose of a master secret in a prover's wallet to tie together claims in a proof to prove that they are about the same entity (and hence the claims together constitute a W3C credential)? ~ _(if so, it may lead to a slight ontological smear we can live with for the OrgBook's shared wallet, which shares public info for many entities)_ ~

sklump (Tue, 26 Mar 2019 14:16:29 GMT):
Quick easy question for those on this level of design: *Q:* is the purpose of a master secret in a prover's wallet to tie together claims in a proof to prove that they are about the same entity ~(and hence the claims together constitute a W3C credential)~ ? *A:* the master secret proves that the same entity is presenting the claims - the claims need not be about the same principal ~ _(if so, it may lead to a slight ontological smear we can live with for the OrgBook's shared wallet, which shares public info for many entities)_ ~

MALodder (Tue, 26 Mar 2019 14:38:26 GMT):
@sklump yes mostly, the link secret is designed to be an attribute in each of an entity's credentials. Since the value is the same, the proof shows that attribute is the same across all credentials.

MALodder (Tue, 26 Mar 2019 14:39:19 GMT):
thus all the credentials belong to the same person. The holder is the only entity that knows this value and its never revealed

roqs (Tue, 26 Mar 2019 15:29:13 GMT):
Hello all, I have a doubt about the revocation process and the master secret (or link secret) that is used by a prover to creates a credential request. Is it works like a password? because I read in the code that is an optional parameter, and a random will be generated if none is given. And I would like to know what happen if the prover lost this secret, he also lose the ownership of that credential and need to request a new emission of it to the issuer? And suppose that this holder lost his wallet, that contained many previous credentials, he need to re-emit new credentials for all relationships that he previous had or is possible to just update the existent with his new identity? In the later case, the prover still able to prove the ownership of previous signed documents (signed with his first keys)? I mean, the new credentials (or updated versions) have some link with the previous (and now revoked)?

swcurran (Tue, 26 Mar 2019 15:39:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=8EAYkLR79uYaQCALu) @sklump I would not agree with this statement "(and hence the claims together constitute a W3C credential)". The credentials are received by the Holder/Prover from a variety of sources, each with an embedded blinded link secret that can be proven with the master (aka link) secret. On presentation, claims from different credentials can have the blinded link secrets proven with the same link secret. I don't think that has anything to do with linking the claims of a single credential to align with W3C.

sklump (Tue, 26 Mar 2019 15:41:41 GMT):
@swcurran https://www.w3.org/TR/verifiable-claims-data-model/#credentials Yes I see you are right: it is one entity making the claims, but there is nothing to say they must be about the same principal.

MALodder (Tue, 26 Mar 2019 16:21:27 GMT):
No the link secret is not like a password

MALodder (Tue, 26 Mar 2019 16:22:00 GMT):
first off, to do a proof, the holder must know the link secret AND have the credential signature

MALodder (Tue, 26 Mar 2019 16:25:02 GMT):
there is no requirement that says all credentials must be linked, however, a verifier certainly can ask for it

kdenhartog (Tue, 26 Mar 2019 23:17:51 GMT):
From an API point of view, I think it may be beneficial to begin deprecating inserting a seed to generate the master secret and we can fully make the transition once the DKMS work is standardized. This will allow us to better prevent people from sharing link secrets which seems to be an anti pattern. Given we can rely on wallet backup mechanism's and DKMS work this shouldn't be as big of a deal for recovery either. Thoughts @sergey.minaev @MALodder @danielhardman

danielhardman (Wed, 27 Mar 2019 04:49:37 GMT):
@roqs: The "secret" in link secret is more about privacy than it is about cybersecurity. It must be kept secret from verifiers and issuers. It should also be kept secret from others, but if it is not perfectly protected, the consequences are not dire. For more on this topic, see https://sovrin.org/library/lost-phone/

bricg (Wed, 27 Mar 2019 11:00:55 GMT):
Can anyone share an example structure what a proof should look like for proof request which only requests a predicate of age >= 18. e.g proof-request ```{ "required": false, "name": "Age_Profile", "version": "1.0.0", "nonce": "1275273812765872", "requested_attrs": {}, "requested_predicates": { "predicate1_referent": { "attr_name": "age", "p_type": ">=", "value": 18, "restrictions": [ { "schema_key": { "name": "entity.person" } } ] } } }```

bricg (Wed, 27 Mar 2019 11:00:55 GMT):
Can anyone share an example structure what a proof should look like for proof request which only requests a predicate of age >= 18. e.g proof-request ```{ "name": "Age_Profile", "version": "1.0.0", "nonce": "1275273812765872", "requested_attrs": {}, "requested_predicates": { "predicate1_referent": { "attr_name": "age", "p_type": ">=", "value": 18, "restrictions": [ { "schema_key": { "name": "entity.person" } } ] } } }```

roqs (Wed, 27 Mar 2019 11:33:52 GMT):
Thank you very much @danielhardman and @MALodder for the information, the document was very useful! Just one more thing about the impossible traceability of Alice's interactions that I didn't understand in the document, there is said that: _"He (Malfoy, the wallet thief) can’t correlate the secret to any of Alice’s proving interactions in the past or the future since it is only a randomly blinded form of the secret that is ever learned during proving."_ But a verifier needs to be able to make this correlation, no? At least this was what I understand from Alice's statement below: _"Here is proof of age from my passport, and proof of residence from my utility bill--and I can demonstrate that the credentials belong to me and can be stitched together because they both contain blinded values that derive from the same link secret that I alone know.” _ And I was thinking, why not Malfoy can do the same if Alice still using the same secret? The proofs aren't public?

MALodder (Wed, 27 Mar 2019 12:58:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=DHnZwfdfNtqNBpzCy) @kdenhartog You are allowed to share it with yourself so if the seed facilitates that then I'm okay with it

MALodder (Wed, 27 Mar 2019 13:01:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=cocDE3zEEfDjM58vx) @roqs Proofs are revealed to the verifier but the link secret is not revealed. What is revealed is Alice knows a link secret that is the same in all her credentials–that's it. So Alice cannot be correlated because Malfoy never sees it.

roqs (Wed, 27 Mar 2019 13:37:42 GMT):
Awesome, thanks @MALodder !

cobear25 (Wed, 27 Mar 2019 13:42:55 GMT):
Still no responses about the iOS wrapper. The biggest help would be for version 1.8.1 to be working in the podspec. https://repo.sovrin.org/ios/libindy/stable/indy-objc/

phillip.gibb (Wed, 27 Mar 2019 13:48:14 GMT):
Hi there, has this been moved? `https://repo.evernym.com/artifactory/libindy-maven-local`

MALodder (Wed, 27 Mar 2019 13:51:18 GMT):
@roqs Another way to think about this is to examine the properties required for a ZKP: 1- Completeness – the verifier is convinced. This happens because the verifier can choose the issuers they trust 2- Soundness - the prover can't cheat or lie that he knows the value(s). Since the verifier generates the nonce, this limits the cheating of the prover 3- Zero-knowledge – the verifier only learns what the proof reveals. This is designed into the protocol i.e. proof of knowledge of a signature

esplinr (Wed, 27 Mar 2019 14:05:41 GMT):
Link to the meeting agenda for the Indy SDK WG call: https://wiki.hyperledger.org/display/indy/Indy+SDK+Working+Group+Agenda+2019-03-27

Alexi (Wed, 27 Mar 2019 15:12:17 GMT):
@esplinr at what time does the call begin?

roqs (Wed, 27 Mar 2019 15:26:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nfif7GMT8QtpCqR7j) @MALodder Thanks! So the security is in certain way tied with the ownership of the devices/agents and not with the possession of the keys or secret (since this is more related with the user's privacy). So, I'm asking myself, how you bind this devices/agents with the user? There are some documentation about this process?

roqs (Wed, 27 Mar 2019 15:26:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nfif7GMT8QtpCqR7j) @MALodder Thanks! So the security is in certain way tied with the ownership of the devices/agents and not with the possession of the keys or secret (since this is more related with the user's privacy). So, I'm asking myself, how you bind these devices/agents with the user? There are some documentation about this process?

roqs (Wed, 27 Mar 2019 15:26:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=nfif7GMT8QtpCqR7j) @MALodder Thanks! So the security is in certain way tied with the ownership of the devices/agents and not with the possession of the keys or secret (since this is more related with the user's privacy). So, I'm asking myself, how you bind these devices/agents with the user? Are there some documentation about this process?

MALodder (Wed, 27 Mar 2019 16:07:21 GMT):
Yes we have plans for that using what we call the Authz policy. This binds credentials to authorized agents. If the agent is not in the authorized group then it can not prove using those credentials

smithbk (Wed, 27 Mar 2019 16:33:04 GMT):
What is the API to delete a credential? The prover_store_credential call stores it but what deletes it?

sklump (Wed, 27 Mar 2019 16:34:35 GMT):
At present there is no credential deletion.

smithbk (Wed, 27 Mar 2019 16:40:04 GMT):
yikes

smithbk (Wed, 27 Mar 2019 16:41:33 GMT):
Thanks ... is there any way to mark it so that it will not be selected for a proof?

sklump (Wed, 27 Mar 2019 16:43:00 GMT):
No.

sklump (Wed, 27 Mar 2019 16:43:48 GMT):
Each credential has a reference (UUID) in the wallet though; with these you can manage them outside indy

jakubkoci (Wed, 27 Mar 2019 16:47:05 GMT):
Hi, Is Hyperledger Indy SDK coordination call happening today?

kdenhartog (Wed, 27 Mar 2019 23:21:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=JBL9FAWZSTaCNR3Fp) @MALodder My concern is that consumers of this api shoot them self in the foot because they don't understand the implications. I suggested deprecating this because I thought they're other ways to sufficiently share the link secret to myself (encrypted backups, DKMS, etc), but I'm open to other ideas that address this concern.

MALodder (Wed, 27 Mar 2019 23:22:50 GMT):
@kdenhartog yes there are, I'm just speculating why its there and why I'm okay with it for now. I'm in favor of a better approach IF it exists. encrypted backups are okay but DKMS should allow you to just add a link secret as is, not as a seed

kdenhartog (Wed, 27 Mar 2019 23:24:47 GMT):
Gotcha, that makes more sense. I'm also ok with it for now until we have better "best practices" so to say. I just mentioned it since the discussion around seeds popped up. I'll bring it up again when it makes more sense to actually address this.

esplinr (Thu, 28 Mar 2019 03:22:58 GMT):
@Alexi Sorry that I missed your question. I posted the agenda as the call was beginning, and you asked after the call ended. Next call is in two weeks.

esplinr (Thu, 28 Mar 2019 03:25:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=F7XuCbKHHaz4f826h) @xnopre Most of the CI / CD infrastructure is being donated to the project by the Sovrin Foundation. The build scripts are public in the Indy GitHub. During a recent working group call, @MALodder took us through his proposal to replace the current Jenkins pipeline with one based on GitLab.

xnopre (Thu, 28 Mar 2019 08:21:09 GMT):
@esplinr Thanks for your answer. I known the scripts and Dockerfile in sources in the Github repo. My question is for server running the CI ? If I understand, it's not yet public ?

Artemkaaas (Thu, 28 Mar 2019 09:53:16 GMT):
Stable

xnopre (Thu, 28 Mar 2019 10:52:35 GMT):
Hi all. I try to use the "key replacement" feature using `replaceKeysStart` and `replaceKeysApply`. Sending the new key to ledger, I have timeout error... :-( ... And if there is an error, is there a method to cancel, something like `replaceKeysCancel` ou `replaceKeysAbort` ? Thanks

smithbk (Thu, 28 Mar 2019 12:37:46 GMT):
Hi, can someone tell me what would cause the following error or how to debug? Thanks. ```2019-03-27 18:35:18,818 - DEBUG - src/commands/anoncreds/prover.rs:560 | create_proof >>> wallet_handle: 57, proof_req: ProofRequest { nonce: BigNumber { openssl_bn: 1553711706477 }, name: "Bartender", version: "1.0", requested_attributes: {"first_name_referent": AttributeInfo { name: "first_name", restrictions: Some(Array([Object({"schema_name": String("Gov DMV Driver License"), "schema_version": String("1.2")})])), non_revoked: None }, "portrait_referent": AttributeInfo { name: "portrait", restrictions: Some(Array([Object({"schema_name": String("Gov DMV Driver License"), "schema_version": String("1.2")})])), non_revoked: None }, "dob_timestamp_referent": AttributeInfo { name: "dob_timestamp", restrictions: Some(Array([Object({"schema_name": String("Gov DMV Driver License"), "schema_version": String("1.2")})])), non_revoked: None }, "drink_order": AttributeInfo { name: "drink_order", restrictions: None, non_revoked: None }, "last_name_referent": AttributeInfo { name: "last_name", restrictions: Some(Array([Object({"schema_name": String("Gov DMV Driver License"), "schema_version": String("1.2")})])), non_revoked: None }}, requested_predicates: {"predicate1_referent": PredicateInfo { name: "dob_timestamp", p_type: GE, p_value: 89682, restrictions: Some(Array([Object({"schema_name": String("Gov DMV Driver License"), "schema_version": String("1.2")})])), non_revoked: None }}, non_revoked: None }, requested_credentials: RequestedCredentials { self_attested_attributes: {"drink_order": "Beer, Chips"}, requested_attributes: {"dob_timestamp_referent": RequestedAttribute { cred_id: "4f728f2d-6137-47e9-a3f5-c8c2a7081834", timestamp: None, revealed: true }, "first_name_referent": RequestedAttribute { cred_id: "4f728f2d-6137-47e9-a3f5-c8c2a7081834", timestamp: None, revealed: true }, "portrait_referent": RequestedAttribute { cred_id: "4f728f2d-6137-47e9-a3f5-c8c2a7081834", timestamp: None, revealed: true }, "last_name_referent": RequestedAttribute { cred_id: "4f728f2d-6137-47e9-a3f5-c8c2a7081834", timestamp: None, revealed: true }}, requested_predicates: {"predicate1_referent": ProvingCredentialKey { cred_id: "4f728f2d-6137-47e9-a3f5-c8c2a7081834", timestamp: None }} }, master_secret_id: "f9eefa76-be37-4746-8b1a-9f61f0ceec29", schemas: {"SGU43RhrhTWuvLmbgwRFHf:2:Gov DMV Driver License:1.2": SchemaV1 { id: "SGU43RhrhTWuvLmbgwRFHf:2:Gov DMV Driver License:1.2", name: "Gov DMV Driver License", version: "1.2", attr_names: {"signature", "country", "address_line_2", "cardholder_sex", "portrait", "customer_identifier", "first_name", "weight", "height", "eye_color", "date_of_issue", "vehicle_class", "card_front", "last_name", "zip_code", "dob_timestamp", "state", "dob", "city", "document_discriminator", "endorsements", "hair_color", "address_line_1", "card_back", "expiration_date", "rci_codes"}, seq_no: Some(18) }}, cred_defs: {"SGU43RhrhTWuvLmbgwRFHf:3:CL:18:TAG1": CredentialDefinitionV1 { id: "SGU43RhrhTWuvLmbgwRFHf:3:CL:18:TAG1", schema_id: "18", signature_type: CL, tag: "TAG1", value: CredentialDefinitionData { primary: CredentialPrimaryPublicKey { n: BigNumber { openssl_bn: ... }, s: BigNumber { openssl_bn: ... }, r: {"rci_codes": BigNumber { openssl_bn: ... }, "dob_timestamp": BigNumber { openssl_bn: ... }}, rctxt: BigNumber { openssl_bn: ... }, z: BigNumber { openssl_bn: ... } }, revocation: None } }}, rev_states: {} 2019-03-27 18:35:18,908 - DEBUG - _get_error_details: >>> 2019-03-27 18:35:18,908 - DEBUG - _get_error_details: <<< error_details: {'backtrace': '', 'message': "Error: Invalid structure\n Caused by: IndyCryptoError: Value by key 'dob_timestamp' not found in eq_proof.mtilde\n"} 2019-03-27 18:35:18,908 - DEBUG - _indy_callback: >>> command_handle: 269, err (, "Error: Invalid structure\n Caused by: IndyCryptoError: Value by key 'dob_timestamp' not found in eq_proof.mtilde\n"), args: (b'',) 2019-03-27 18:35:18,908 - DEBUG - _indy_callback: <<<```

Alexi (Thu, 28 Mar 2019 15:28:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=aPdvzNtcYaLiDpD6g) @esplinr No worries! I put it down on my calendar so i wont miss it next time :thumbsup:

Alexi (Thu, 28 Mar 2019 15:45:21 GMT):
@smithbk its a key error value meaning 'dob_timestamp' is missing in the input, or is put in as an input where it should not be, at some stage of the create_proof process. this could be caused by a number of things. First thing that I notice is that in your proof request you have 'dob_timestamp' as both a requested attribute and a requested predicate, this might be where the error lies. Otherwise posting the code that causes this error might help debug

sklump (Thu, 28 Mar 2019 16:00:04 GMT):
@Alexi good catch! It is an error to have the same attribute as a requested attribute and a requested predicate.

smithbk (Thu, 28 Mar 2019 16:20:51 GMT):
@Alexi @sklump Thanks!

cobear25 (Thu, 28 Mar 2019 18:59:29 GMT):
Is there anybody here that knows how to get the iOS wrapper working? Specifically with Swift 4.

cobear25 (Thu, 28 Mar 2019 19:43:17 GMT):
Or somebody I can reach out to for more direct help? It would be more convenient if we could file issues on github, but I'm guessing the maintainers don't want a flood of issues.

lukasA (Fri, 29 Mar 2019 09:46:10 GMT):
Has joined the channel.

Im5tu (Sat, 30 Mar 2019 16:12:03 GMT):
Is there any logging available in the .net sdk so that we can debug why we are receiving certain error codes?

tplooker (Sat, 30 Mar 2019 20:54:35 GMT):
@Im5tu are you using the indy sdk or agent-framework?

Im5tu (Mon, 01 Apr 2019 08:06:20 GMT):
@tplooker indy sdk :)

Zohaib_Sohail (Mon, 01 Apr 2019 09:21:16 GMT):
Has joined the channel.

roqs (Mon, 01 Apr 2019 12:33:39 GMT):
Hi, is there some important reason of why only the operator >= is implemented in indy-sdk? https://github.com/hyperledger/indy-sdk/blob/cdd7b6f65b242eaea12d67ddaffa8cb5f8103d08/libindy/src/services/anoncreds/prover.rs#L371 I mean, there are some limitation or constraint (like privacy leaks) to do other operations? For example, is possible to compare two hashes in a predicate?

sklump (Mon, 01 Apr 2019 13:02:36 GMT):
This was a placeholder for bigger things to come. Complete predicate support is on the radar, but would break compatibility with current artifact format. The math is plumbed in, but the release awaits a protocol version bump, which is a big change.

lukasA (Mon, 01 Apr 2019 13:26:46 GMT):
hi, i'm currently trying to build the docker container at https://github.com/hyperledger/indy-sdk/blob/master/ci/indy-pool.dockerfile however it seems like the indy-anoncreds debian package was removed from the master stream.. all other streams also didn't provide the `1.0.32` anoncreds packages. Does anybody know how to fix this?

smithbk (Mon, 01 Apr 2019 17:57:51 GMT):
I have the same probem as @lukasA ... anyone know what happened to that version in the sovrin repo?

smithbk (Mon, 01 Apr 2019 17:57:51 GMT):
I have the same problem as @lukasA above ... anyone know what happened to that version in the sovrin repo?

PMoura (Mon, 01 Apr 2019 20:13:42 GMT):
Has joined the channel.

PMoura (Mon, 01 Apr 2019 20:15:31 GMT):
Same problem as @lukasA and @smithbk.

Alexi (Mon, 01 Apr 2019 21:07:46 GMT):
Hello, I apologize for the long message in advance. I was playing with the getting started code to see how certain things worked. Long story short I wanted to get an error by making a proof request asking for an attribute with a credential restriction, sending back a proof with said attribute being self attested, and verifying said proof. However, I do not get an error. Here is what I am doing: this is the proof request (for this example i will be focusing on attribute 5 which as seen here has a restriction on the credential it must come from): ``` acme['job_application_proof_request'] = json.dumps({ 'nonce': '1432422343242122312411212', 'name': 'Job-Application', 'version': '0.1', 'requested_attributes': { 'attr1_referent': { 'name': 'first_name' }, 'attr2_referent': { 'name': 'last_name' }, 'attr3_referent': { 'name': 'degree', 'restrictions': [{'cred_def_id': faber['transcript_cred_def_id']}] }, 'attr4_referent': { 'name': 'status', 'restrictions': [{'cred_def_id': faber['transcript_cred_def_id']}] }, 'attr5_referent': { 'name': 'ssn', 'restrictions': [{'cred_def_id': faber['transcript_cred_def_id']}] }, 'attr6_referent': { 'name': 'phone_number', } }, 'requested_predicates': { 'predicate1_referent': { 'name': 'average', 'p_type': '>=', 'p_value': 4, 'restrictions': [{'cred_def_id': faber['transcript_cred_def_id']}] } } }) ``` After gathering the attributes from credentials, these are the requested credentials used for creating the proof: *Note how i commented out attr5 as a requested attribute and made it a self attested attribute* ``` alice['job_application_requested_creds'] = json.dumps({ 'self_attested_attributes': { 'attr1_referent': 'Alice', 'attr2_referent': 'Garcia', 'attr6_referent': '123-45-6789', 'attr5_referent': '123-45-6789' }, 'requested_attributes': { 'attr3_referent': {'cred_id': cred_for_attr3['referent'], 'revealed': True}, 'attr4_referent': {'cred_id': cred_for_attr4['referent'], 'revealed': True}, #'attr5_referent': {'cred_id': cred_for_attr5['referent'], 'revealed': True}, }, 'requested_predicates': {'predicate1_referent': {'cred_id': cred_for_predicate1['referent']}} }) ``` after sending the proof back to acme and running verify proof: ``` assert await anoncreds.verifier_verify_proof(acme['job_application_proof_request'], acme['job_application_proof'], acme['schemas'], acme['cred_defs'], acme['revoc_ref_defs'], acme['revoc_regs']) ``` I get no errors from this. ad the verify request is returns as true What then is the restriction actually doing? is it only for the provers side such that when searching the credentials it limits it to the ones in the restrictions? Is it on the verifier to check that the restrictions were upheld and not like in this case a self attested value was returned when it was asked to be from a credential?

Alexi (Mon, 01 Apr 2019 21:07:46 GMT):
Hello, I apologize for the long message in advance. I was playing with the getting started code to see how certain things worked. Long story short I wanted to get an error by making a proof request asking for an attribute with a credential restriction, sending back a proof with said attribute being self attested, and verifying said proof. However, I do not get an error. Here is what I am doing: this is the proof request (for this example i will be focusing on attribute 5 which as seen here has a restriction on the credential it must come from): ``` acme['job_application_proof_request'] = json.dumps({ 'nonce': '1432422343242122312411212', 'name': 'Job-Application', 'version': '0.1', 'requested_attributes': { 'attr1_referent': { 'name': 'first_name' }, 'attr2_referent': { 'name': 'last_name' }, 'attr3_referent': { 'name': 'degree', 'restrictions': [{'cred_def_id': faber['transcript_cred_def_id']}] }, 'attr4_referent': { 'name': 'status', 'restrictions': [{'cred_def_id': faber['transcript_cred_def_id']}] }, 'attr5_referent': { 'name': 'ssn', 'restrictions': [{'cred_def_id': faber['transcript_cred_def_id']}] }, 'attr6_referent': { 'name': 'phone_number', } }, 'requested_predicates': { 'predicate1_referent': { 'name': 'average', 'p_type': '>=', 'p_value': 4, 'restrictions': [{'cred_def_id': faber['transcript_cred_def_id']}] } } }) ``` After gathering the attributes from credentials, these are the requested credentials used for creating the proof: *Note how i commented out attr5 as a requested attribute and made it a self attested attribute* ``` alice['job_application_requested_creds'] = json.dumps({ 'self_attested_attributes': { 'attr1_referent': 'Alice', 'attr2_referent': 'Garcia', 'attr6_referent': '123-45-6789', 'attr5_referent': '123-45-6789' }, 'requested_attributes': { 'attr3_referent': {'cred_id': cred_for_attr3['referent'], 'revealed': True}, 'attr4_referent': {'cred_id': cred_for_attr4['referent'], 'revealed': True}, #'attr5_referent': {'cred_id': cred_for_attr5['referent'], 'revealed': True}, }, 'requested_predicates': {'predicate1_referent': {'cred_id': cred_for_predicate1['referent']}} }) ``` after creating and then sending the proof back to acme and running verify proof: ``` assert await anoncreds.verifier_verify_proof(acme['job_application_proof_request'], acme['job_application_proof'], acme['schemas'], acme['cred_defs'], acme['revoc_ref_defs'], acme['revoc_regs']) ``` I get no errors from this. and the verify request is returns as true What then is the restriction actually doing? is it only for the provers side such that when searching the credentials it limits it to the ones in the restrictions? Is it on the verifier to check that the restrictions were upheld and not like in this case a self attested value was returned when it was asked to be from a credential? If so what is the verify proof call doing if not checking the restrictions are being respected? I appreciate the help!

tomislav (Mon, 01 Apr 2019 21:18:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ic9qAd5SY35TrvdnG) @Im5tu Here are the codes libindy will throw, they will be bubbled up by the dotnet wrapper - https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/api/mod.rs Here's how you can hook into the logging support of libindy through the sdk - https://github.com/hyperledger/indy-sdk/blob/4e8d9a47e2a7d0368c26c26c0209caa6965c7b60/wrappers/dotnet/indy-sdk-dotnet-test/SetupAssemblyInitializer.cs

theoturner (Tue, 02 Apr 2019 10:25:35 GMT):
Hi all, as of yesterday I'm getting `E: Version '1.0.32' for 'indy-anoncreds' was not found` for the docker build of the node pool. Any thoughts?

theoturner (Tue, 02 Apr 2019 10:26:48 GMT):
Caused by this part of the dockerfile https://github.com/hyperledger/indy-sdk/blob/master/ci/indy-pool.dockerfile#L35

zzmane (Tue, 02 Apr 2019 11:30:35 GMT):
Has joined the channel.

zzmane (Tue, 02 Apr 2019 11:33:26 GMT):
Hi, does anyone know which is the maximum TPS for Indy? Looks like from this issue https://jira.hyperledger.org/browse/INDY-1002 it is only 10 TPS.

theoturner (Tue, 02 Apr 2019 12:10:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5KqMyxPNzQFS7vcnv) @zzmane The sustained goal is 10tps write and 100tps read, tests largely around 10-15tps write, 50-75tps read (INDY-1343 is a good place to start). Indy is not a traditional cryptocurrency trying to process payments as fast as possible, so TPS is not a good metric. Ledger writes involve lower-frequency actions like schema creation and public claims (most would be private).

theoturner (Tue, 02 Apr 2019 12:18:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Jk4Y7SWbAYXdu3QGM) If you import the Sovrin sources for apt, `indy-plenum`, `indy-node`, `python3-indy-crypto` and `libindy-crypto` are all found without issue. It seems `indy-anoncreds` has gone missing: ``` Package indy-anoncreds is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source ``` This seems quite high priority @Artemkaaas @sergey.minaev

tomislav (Tue, 02 Apr 2019 13:21:38 GMT):
@theoturner I'm having into the same issue. We package all services using docker with installed libindy.

tomislav (Tue, 02 Apr 2019 13:21:38 GMT):
@theoturner I'm running into the same issue. We package all services using docker with installed libindy which fails with the same error now.

MALodder (Tue, 02 Apr 2019 14:02:45 GMT):
it looks like the packages are there, but there is an apt issue

MALodder (Tue, 02 Apr 2019 14:02:48 GMT):
looking into it

Alexi (Tue, 02 Apr 2019 14:16:38 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=KcLqrCfW2cxZ6MKZi) Hello, was wondering if anyone had an answer to this?

jacobsaur (Tue, 02 Apr 2019 16:50:20 GMT):
Hi, I had a question about the postgres storage plugin. It looks like it creates a new postgres database for each wallet (with 4 tables inside each database). This introduces a lot of overhead and around 8MB per wallet/database even with nothing stored in it, which results in very high storage requirements at scale. Has anyone else run into this issue and have any suggestions (perhaps @ianco )? Right now I'm leaning towards modifying the postgres plugin to instead just use one database, and prefix each table with the wallet id.

kdenhartog (Tue, 02 Apr 2019 17:29:17 GMT):
@jacobsaur I'm not certain this would be a safe implementation. Is there a way to control reads to the database, such that one db query user can prevent another db query user from accessing their data?

ianco (Tue, 02 Apr 2019 17:31:48 GMT):
@jacobsaur an alternative would be to add a column to each table in the database to specify the wallet ...

ianco (Tue, 02 Apr 2019 17:32:37 GMT):
@kdenhartog each wallet is encrypted with the wallet key, so users shouldn't be able to read each others data

kdenhartog (Tue, 02 Apr 2019 17:33:47 GMT):
Could they overwrite others data? I'm new to the intricacies of Postgres.

ianco (Tue, 02 Apr 2019 17:34:36 GMT):
They need to authenticate with their wallet id and password (key), so as long as the storage respects this the user's data should be kept segregated

ianco (Tue, 02 Apr 2019 17:36:06 GMT):
@jacobsaur if you make changes to the postgres storage let me know I'll review the changes/test them out

jacobsaur (Tue, 02 Apr 2019 17:38:46 GMT):
Thanks for the feedback - @ianco I agree adding a column to each table would be a lot more efficient. I'll give it a shot and send it your way. Thanks!

kdenhartog (Tue, 02 Apr 2019 17:40:25 GMT):
Cool, thanks for the insights @ianco

ianco (Tue, 02 Apr 2019 17:44:38 GMT):
:+1:

nbrempel (Tue, 02 Apr 2019 21:06:28 GMT):
Hi everyone, has anyone run into this error when calling `anoncreds.prover_get_credentials_for_proof_req`? Thanks. ``` indy.error.IndyError: (, 'Error: Invalid library state\n Caused by: Unexpected sqlite error\n Caused by: near ")": syntax error\n') ```

ianco (Tue, 02 Apr 2019 21:09:03 GMT):
Is there a stack trace? I suspect it's something to do with your query syntax

nbrempel (Tue, 02 Apr 2019 21:11:20 GMT):
``` 2019-04-02 21:02:17,362 indy.anoncreds DEBUG prover_get_credentials_for_proof_req: >>> wallet_handle: 2, proof_request_json: '{"name": "7d7fb979-8713-4d72-9793-4f900a347817", "version": "00a83acf-e681-4d69-a214-ebc1bec99ce7", "nonce": "2f4b2d83-f3f3-4edf-9669-9fb9908aa201", "requested_attributes": {"6dc2f8f0-10a6-4ece-9af3-1570e461303c": {"name": "attr", "restrictions": []}}, "requested_predicates": {}}' 2019-04-02 21:02:17,362 indy.anoncreds DEBUG prover_get_credentials_for_proof_req: Creating callback 2019-04-02 21:02:17,362 indy.libindy DEBUG create_cb: >>> cb_type: .CFunctionType'> 2019-04-02 21:02:17,362 indy.libindy DEBUG create_cb: <<< res: 2019-04-02 21:02:17,363 indy.libindy DEBUG do_call: >>> name: indy_prover_get_credentials_for_proof_req, args: (c_int(2), c_char_p(139814077994320), ) 2019-04-02 21:02:17,367 indy.libindy DEBUG do_call: Function indy_prover_get_credentials_for_proof_req returned err: 0 2019-04-02 21:02:17,369 indy.libindy DEBUG do_call: <<< 2019-04-02 21:02:17,368 indy.libindy.native.indy.commands INFO src/commands/mod.rs:120 | AnoncredsCommand command received 2019-04-02 21:02:17,370 indy.libindy.native.anoncreds_command_executor INFO src/commands/anoncreds/mod.rs:54 | Prover command received 2019-04-02 21:02:17,372 indy.libindy.native.prover_command_executor INFO src/commands/anoncreds/prover.rs:193 | GetCredentialsForProofReq command received 2019-04-02 21:02:17,372 indy.libindy.native.indy.commands.anoncreds.prover DEBUG src/commands/anoncreds/prover.rs:434 | get_credentials_for_proof_req >>> wallet_handle: 2, proof_request: ProofRequest { nonce: BigNumber { openssl_bn: 38013795101008884147 }, name: "7d7fb979-8713-4d72-9793-4f900a347817", version: "00a83acf-e681-4d69-a214-ebc1bec99ce7", requested_attributes: {"6dc2f8f0-10a6-4ece-9af3-1570e461303c": AttributeInfo { name: "attr", restrictions: Some(Array([])), non_revoked: None }}, requested_predicates: {}, non_revoked: None } 2019-04-02 21:02:17,372 indy.libindy.native.indy.commands.anoncreds.prover DEBUG src/commands/anoncreds/prover.rs:708 | _query_requested_credentials >>> wallet_handle: 2, query_json: "{\"$and\":[{\"attr::attr::marker\":\"1\"},{\"$or\":[]}]}", predicate_info: None 2019-04-02 21:02:17,373 indy.libindy DEBUG _get_error_details: >>> 2019-04-02 21:02:17,373 indy.libindy DEBUG _get_error_details: <<< error_details: {'backtrace': '', 'message': 'Error: Invalid library state\n Caused by: Unexpected sqlite error\n Caused by: near ")": syntax error\n'} 2019-04-02 21:02:17,374 indy.libindy DEBUG _indy_callback: >>> command_handle: 50, err (, 'Error: Invalid library state\n Caused by: Unexpected sqlite error\n Caused by: near ")": syntax error\n'), args: (b'',) 2019-04-02 21:02:17,374 indy.libindy DEBUG _indy_callback: <<< 2019-04-02 21:02:17,375 indy.libindy DEBUG _indy_loop_callback: >>> command_handle: 50, err (, 'Error: Invalid library state\n Caused by: Unexpected sqlite error\n Caused by: near ")": syntax error\n'), args: (b'',) 2019-04-02 21:02:17,375 indy.libindy WARNING _indy_loop_callback: Function returned error (, 'Error: Invalid library state\n Caused by: Unexpected sqlite error\n Caused by: near ")": syntax error\n') 2019-04-02 21:02:17,375 indy.libindy DEBUG _indy_loop_callback <<< ```

nbrempel (Tue, 02 Apr 2019 21:11:54 GMT):
The proof request json is pretty basic: ``` { "name": "7d7fb979-8713-4d72-9793-4f900a347817", "version": "00a83acf-e681-4d69-a214-ebc1bec99ce7", "nonce": "2f4b2d83-f3f3-4edf-9669-9fb9908aa201", "requested_attributes": { "6dc2f8f0-10a6-4ece-9af3-1570e461303c": { "name": "attr", "restrictions": [] } }, "requested_predicates": {} } ```

nbrempel (Tue, 02 Apr 2019 21:25:38 GMT):
If I change the proof request to not include the empty restrictions array, it works. ``` ``` { "name": "7d7fb979-8713-4d72-9793-4f900a347817", "version": "00a83acf-e681-4d69-a214-ebc1bec99ce7", "nonce": "2f4b2d83-f3f3-4edf-9669-9fb9908aa201", "requested_attributes": { "6dc2f8f0-10a6-4ece-9af3-1570e461303c": { "name": "attr" } }, "requested_predicates": {} } ``` ```

nbrempel (Tue, 02 Apr 2019 21:25:38 GMT):
If I change the proof request to not include the empty restrictions array, it works. ``` { "name": "7d7fb979-8713-4d72-9793-4f900a347817", "version": "00a83acf-e681-4d69-a214-ebc1bec99ce7", "nonce": "2f4b2d83-f3f3-4edf-9669-9fb9908aa201", "requested_attributes": { "6dc2f8f0-10a6-4ece-9af3-1570e461303c": { "name": "attr" } }, "requested_predicates": {} } ```

nbrempel (Tue, 02 Apr 2019 21:29:31 GMT):
I also just tested it with restrictions, but with the array containing a single valid element: ``` { "name": "c0f27b52-2d31-4cd4-a364-37f3671fdcd0", "version": "cfcd115f-694c-4cad-9d80-8beac180bf87", "nonce": "999697b8-bbee-46bf-b42d-b6ebffb74f3d", "requested_attributes": { "4c0ee641-5c6a-40cb-872c-524731941d27": { "name": "attr", "restrictions": { "cred_def_id": "4QxzWk3ajdnEA37NdNU5Kt:3:CL:7:default" } } }, "requested_predicates": {} } ``` This also works. I think this is likely a bug. Or if there is some reason for this I think a more informational error message would be helpful.

nbrempel (Tue, 02 Apr 2019 21:29:31 GMT):
I also just tested it with restrictions, but with the array containing a single valid element which works: ``` { "name": "2d33c955-a818-4cb6-be3d-8a107c799e99", "version": "812663b6-9caa-4343-a52f-046937ed5ca9", "nonce": "1575d286-78a7-4891-a7f6-588efce71fe3", "requested_attributes": { "3b569ab4-ef3f-459a-acca-bc5a38645d3d": { "name": "attr", "restrictions": [ { "cred_def_id": "4QxzWk3ajdnEA37NdNU5Kt:3:CL:7:default" } ] } } } ``` ``` { "name": "c0f27b52-2d31-4cd4-a364-37f3671fdcd0", "version": "cfcd115f-694c-4cad-9d80-8beac180bf87", "nonce": "999697b8-bbee-46bf-b42d-b6ebffb74f3d", "requested_attributes": { "4c0ee641-5c6a-40cb-872c-524731941d27": { "name": "attr", "restrictions": { "cred_def_id": "4QxzWk3ajdnEA37NdNU5Kt:3:CL:7:default" } } }, "requested_predicates": {} } ``` I think this is likely a bug. Or if there is some reason for this I think a more informational error message would be helpful.

nbrempel (Tue, 02 Apr 2019 21:29:31 GMT):
I also just tested it with restrictions, but with the array containing a single valid element which works: ``` { "name": "2d33c955-a818-4cb6-be3d-8a107c799e99", "version": "812663b6-9caa-4343-a52f-046937ed5ca9", "nonce": "1575d286-78a7-4891-a7f6-588efce71fe3", "requested_attributes": { "3b569ab4-ef3f-459a-acca-bc5a38645d3d": { "name": "attr", "restrictions": [ { "cred_def_id": "4QxzWk3ajdnEA37NdNU5Kt:3:CL:7:default" } ] } } } ``` This also works. ``` { "name": "c0f27b52-2d31-4cd4-a364-37f3671fdcd0", "version": "cfcd115f-694c-4cad-9d80-8beac180bf87", "nonce": "999697b8-bbee-46bf-b42d-b6ebffb74f3d", "requested_attributes": { "4c0ee641-5c6a-40cb-872c-524731941d27": { "name": "attr", "restrictions": { "cred_def_id": "4QxzWk3ajdnEA37NdNU5Kt:3:CL:7:default" } } }, "requested_predicates": {} } ``` I think this is likely a bug. Or if there is some reason for this I think a more informational error message would be helpful.

tomislav (Tue, 02 Apr 2019 22:10:19 GMT):
@ianco Putting all data in a single table may have some serious scaling issues. Suppose a user with very few records wants to search for their data, the database would have to run the search on all records. The 8MB of initial cost you get for each table is just table provisioning costs, table size should scale normally from that point. We use CosmosDB storage and have table per wallet solution. It also makes sense architecturally, as each wallet data is isolated and indexed on its own.

ianco (Tue, 02 Apr 2019 22:17:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=QsJZABZ629Bd7xcKQ) @tomislav For sure, there are different options. Searches should all be indexed, so I wouldn't expect any search performance issues, as long as the wallet itself was part of the index. For the BC and Ontario deployments we have millions of credentials in a single wallet and no issues with wallet query performance. (Btw this translates to tens of millions of encrypted tag records.) I think both approaches (single table or multi table) could work.

andrew.whitehead (Tue, 02 Apr 2019 22:22:01 GMT):
Has joined the channel.

ianco (Wed, 03 Apr 2019 01:11:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=TenyiiWaf3BeGionx) @MALodder any update on indy-anoncreds? looks like apt is unable to find it?

MALodder (Wed, 03 Apr 2019 01:24:55 GMT):
yes @lynn.bendixsen mentioned this to me > Anoncreds was removed from dependencies (for the sovrin package) a few months ago and is no longer required iirc for validator nodes. I can't remember why...

ianco (Wed, 03 Apr 2019 01:32:08 GMT):
The docker build within indy-sdk still has the anoncreds dependency (docker build -f ci/indy-pool.dockerfile -t indy_pool .)

MALodder (Wed, 03 Apr 2019 01:32:47 GMT):
yes it should be removed

ianco (Wed, 03 Apr 2019 01:38:44 GMT):
ok that seems to work (remove the indy-anoncreds dependency from the Dockerfile) and it seems to build and run ok

MALodder (Wed, 03 Apr 2019 02:09:49 GMT):
@ianco glad to hear that

Artemkaaas (Wed, 03 Apr 2019 05:41:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kygKqTZk5sRMXWMBF) @nbrempel @nbrempel try to use the last stable version 1.8.2. This issue has been fixed no so long ago

Artemkaaas (Wed, 03 Apr 2019 05:41:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kygKqTZk5sRMXWMBF) @nbrempelnBraendle try to use the last stable version 1.8.2. This issue has been fixed no so long ago

Artemkaaas (Wed, 03 Apr 2019 05:41:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kygKqTZk5sRMXWMBF) @nbrempeln try to use the last stable version 1.8.2. This issue has been fixed no so long ago

Artemkaaas (Wed, 03 Apr 2019 05:41:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kygKqTZk5sRMXWMBF) @nbrempel try to use the last stable version 1.8.2. This issue has been fixed no so long ago

ashlinSajan (Wed, 03 Apr 2019 07:04:58 GMT):
Hi @kdenhartog @danielhardman I have created an indy-pool but don't know how to join nodes.Could you please me with the same

danielhardman (Wed, 03 Apr 2019 07:07:11 GMT):
You need to create a genesis file

ashlinSajan (Wed, 03 Apr 2019 07:08:45 GMT):
Can I use the default docker_pool_transactions_genesis file

midhun14 (Wed, 03 Apr 2019 08:58:22 GMT):
Has joined the channel.

pyraman (Wed, 03 Apr 2019 09:06:14 GMT):
Hi all! I've just configured Indy remote test network described here: https://github.com/hyperledger/indy-node/blob/master/docs/source/start-nodes.md. The network consists of 4 nodes. all these 4 nodes are running on a machine next to me. But dotnet sample (LedgerDemo.cs) thrown exception (at OpenPoolLedgerAsync()): e = {Hyperledger.Indy.InvalidStateException: The SDK library experienced an unexpected internal error. at Hyperledger.Indy.Samples.LedgerDemo.Execute() in C:\Users\quan.hoang\Desktop\indy\indy-sdk\samples\dotnet\Samples\LedgerDemo.cs:line 41}

theoturner (Wed, 03 Apr 2019 10:06:03 GMT):
@tomislav Any progress on the apt module? Still unable to spin up nodes :(

ashlinSajan (Wed, 03 Apr 2019 10:19:38 GMT):
How to join nodes to indy pool from indy cli

ashlinSajan (Wed, 03 Apr 2019 10:20:51 GMT):
Anyone has done that?

tomislav (Wed, 03 Apr 2019 12:55:56 GMT):
@theoturner See @MALodder comment above. Remove the "anoncreds" dependency from the dockerfile, as it's not needed anymore

tomislav (Wed, 03 Apr 2019 12:55:56 GMT):
@theoturner See @MALodder and @ianco comments above. Remove the "anoncreds" dependency from the dockerfile, as it's not needed anymore

theoturner (Wed, 03 Apr 2019 13:11:08 GMT):
Ah fantastic, thanks. Is this in a PR?

tomislav (Wed, 03 Apr 2019 13:20:57 GMT):
I can confirm that doing so fixed the build error for me

theoturner (Wed, 03 Apr 2019 13:21:21 GMT):
@tomislav @MALodder @ianco If you remove the `indy-anoncreds`, the build still fails due to dependency config order (docker compose 1.22 on Ubuntu). Can be fixed as by adding `python3-prompt-toolkit` and `python3-pygments` to the install environment.

tomislav (Wed, 03 Apr 2019 13:22:02 GMT):
Can you share the dockerfile you're using?

tomislav (Wed, 03 Apr 2019 13:23:44 GMT):
I was trying with https://github.com/hyperledger/indy-sdk/blob/master/ci/indy-pool.dockerfile - the proposed fix made this image build again

theoturner (Wed, 03 Apr 2019 13:24:31 GMT):
Yes this failed for me with removal of anoncreds

theoturner (Wed, 03 Apr 2019 13:25:30 GMT):

indy-pool.txt

theoturner (Wed, 03 Apr 2019 13:25:40 GMT):
Txt-ed it since .dockerfile not acceptes

theoturner (Wed, 03 Apr 2019 13:25:40 GMT):
Txt-ed it since .dockerfile not accepted

theoturner (Wed, 03 Apr 2019 13:27:44 GMT):
Error with the original: ``` dpkg: dependency problems prevent configuration of indy-plenum: indy-plenum depends on python3-prompt-toolkit (= 0.57-1); however: Package python3-prompt-toolkit is not configured yet. indy-plenum depends on python3-pygments (= 2.2.0); however: Package python3-pygments is not configured yet. ... [etc, resulting failures due to indy-plenum] ```

tomislav (Wed, 03 Apr 2019 14:03:07 GMT):
You're right. I was using a slightly older version that seems to work and doesn't require python3-prompt-toolkit and python3-pygments

tomislav (Wed, 03 Apr 2019 14:03:50 GMT):
Your changes should be added to the indy-sdk ci dockerfile, as many devs use it for local nodes

MALodder (Wed, 03 Apr 2019 14:05:23 GMT):
@tomislav thanks for finding that out. Can you submit a PR to indy-sdk for this and I can review it?

tomislav (Wed, 03 Apr 2019 14:06:01 GMT):
Sure thing

lynn.bendixsen (Wed, 03 Apr 2019 15:00:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Taodz87nNnL3WE2Tt) @ashlinSajan @ashlinSajan Here are some high level instructions. You will need to run a command from the node to generate some keys (use local ip addresses for this one) ```sudo -i -u indy init_indy_node ``` and then you will need to run the following from the CLI (use public ip addresses for this one): ```ledger node target= node_ip= node_port= client_ip= client_port= alias= services=VALIDATOR blskey= blskey_pop=``` For more detailed instructions you are welcome to follow the instructions in our Sovrin Steward Validator Preparation guide, but please remember to adapt the instructions for your test environment Network. https://docs.google.com/document/d/1AH618bj4q9U8FS1uyoIgbcvwNzaghBCQ1v44tNpZ2OU/edit#

lynn.bendixsen (Wed, 03 Apr 2019 15:00:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Taodz87nNnL3WE2Tt) @ashlinSajan Here are some high level instructions. You will need to run a command from the node to generate some keys (use local ip addresses for this one) ```sudo -i -u indy init_indy_node ``` and then you will need to run the following from the CLI (use public ip addresses for this one): ```ledger node target= node_ip= node_port= client_ip= client_port= alias= services=VALIDATOR blskey= blskey_pop=``` For more detailed instructions you are welcome to follow the instructions in our Sovrin Steward Validator Preparation guide, but please remember to adapt the instructions for your test environment Network. https://docs.google.com/document/d/1AH618bj4q9U8FS1uyoIgbcvwNzaghBCQ1v44tNpZ2OU/edit#

lynn.bendixsen (Wed, 03 Apr 2019 15:01:37 GMT):
and then you will need to run the following from the CLI (use public ip addresses for this one): ```ledger node target= node_ip= node_port= client_ip= client_port= alias= services=VALIDATOR blskey= blskey_pop=``` For more detailed instructions you are welcome to follow the instructions in our Sovrin Steward Validator Preparation guide, but please remember to adapt the instructions for your test environment Network. https://docs.google.com/document/d/1AH618bj4q9U8FS1uyoIgbcvwNzaghBCQ1v44tNpZ2OU/edit#

lynn.bendixsen (Wed, 03 Apr 2019 15:01:37 GMT):
and then you will need to run the following from the CLI using the output from the previous command. (use public ip addresses for this one): ```ledger node target= node_ip= node_port= client_ip= client_port= alias= services=VALIDATOR blskey= blskey_pop=``` For more detailed instructions you are welcome to follow the instructions in our Sovrin Steward Validator Preparation guide, but please remember to adapt the instructions for your test environment Network. https://docs.google.com/document/d/1AH618bj4q9U8FS1uyoIgbcvwNzaghBCQ1v44tNpZ2OU/edit#

Alexi (Wed, 03 Apr 2019 16:19:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=KcLqrCfW2cxZ6MKZi) hey all, sorry for continuous messages. Does anyone have an answer to this, I appreciate the help!

Alexi (Wed, 03 Apr 2019 16:25:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=KcLqrCfW2cxZ6MKZi) hey all, sorry for continuous messages. Does anyone have an answer to this, I appreciate the help!

tomislav (Wed, 03 Apr 2019 18:20:25 GMT):
@Alexi verification is checking if the provided signatures in the proof are good against the supplied definitions, including the restrictions. The verifier can still decide if this proof is good based on the fact the certain criteria wasn't met, specifically providing self-attested value for an attribute that was required in the proof request.

tomislav (Wed, 03 Apr 2019 18:20:25 GMT):
@Alexi verification is checking if the provided signatures in the proof are good against the supplied definitions, including the restrictions and revocations. The verifier can still decide if this proof is good based on the fact the certain criteria wasn't met, specifically providing self-attested value for an attribute that was required in the proof request.

tomislav (Wed, 03 Apr 2019 18:20:25 GMT):
@Alexi verification is checking if the provided signatures in the proof are good against the supplied definitions, including the restrictions and revocations. The verifier can still decide if this proof is good based on the fact the certain criteria wasn't met, specifically providing self-attested value for an attribute that was required in the proof request. This may be an acceptable use case.

tomislav (Wed, 03 Apr 2019 18:22:48 GMT):
@theoturner @MALodder I can't reproduce this anymore. Not sure if fixed in the meantime, but it seems to work for me. Trying off of master `docker build -f ci/indy-pool.dockerfile --no-cache .` builds just fine.

Alexi (Wed, 03 Apr 2019 18:36:01 GMT):
@tomislav OK that makes sense. I can see why this flexibility can be useful depending on the use case. The signature signatures in the proof always need to be valid, but the verifier has the flexibility to determine the validity of the information depending on the circumstance. Thanks!

Alexi (Wed, 03 Apr 2019 18:36:01 GMT):
@tomislav OK that makes sense. I can see why this flexibility can be useful depending on the use case. The signatures in the proof always need to be valid, but the verifier has the flexibility to determine the validity of the information depending on the circumstance. Thanks!

Alexi (Wed, 03 Apr 2019 18:47:33 GMT):
I was wondering if there was a reason as to why the same value cannot be a predicate and an attribute in a proof request? Since predicates do not return an actual value in the proof, I could see a case where one would want to have the value be above a certain value but also want to know what the value is.

tomislav (Wed, 03 Apr 2019 19:08:09 GMT):
One reason for predicates is to allow the prover to hide the information while providing some proof of it that's more than just ownership (which they can do anyway with regular attribute by setting "revealed: false"). If verifier requires the value to be revealed, they don't need to use predicate to verify range, just simple value inspection will do

daidoji (Thu, 04 Apr 2019 02:27:12 GMT):
Should tests pass on master without me doing anything in particular? I'm getting a lot of failures at the moment

daidoji (Thu, 04 Apr 2019 02:28:15 GMT):
or do I have to run the docker network in order for them to pass?

daidoji (Thu, 04 Apr 2019 02:28:41 GMT):
I guess I should be clear I ran `cargo test` in `libindy` and got some failures and am confused

daidoji (Thu, 04 Apr 2019 02:32:34 GMT):
oh weird, when I run the tests that failed explicitly like `cargo test services::wallet::tests::wallet_service_get_record_works_for_id_only` then that test passes

daidoji (Thu, 04 Apr 2019 02:32:46 GMT):
is this expected?

sklump (Thu, 04 Apr 2019 10:38:33 GMT):
There have been some variances in timing tolerances in the past. In `libindy/tests/*.rs`, try finding the test cases of interest and bumping up `(timeout::short_timeout()` to `(timeout::medium_timeout()` or similar.

sklump (Thu, 04 Apr 2019 10:38:33 GMT):
There have been some variances by computing base in timing tolerances in the past. In `libindy/tests/*.rs`, try finding the test cases of interest and bumping up `timeout::short_timeout()` to `timeout::medium_timeout()` or similar.

ianco (Thu, 04 Apr 2019 11:36:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=HmJr2hp2kEc8Y6RmD) @daidoji Try single-threading your tests, something like ```cargo test -- --nocapture --test-threads=1```

daidoji (Thu, 04 Apr 2019 13:19:25 GMT):
@ianco yeah that worked, in my quick glance at the issue last night it def seemed like a threading issue in regards to hitting an sqlite db that had been locked

daidoji (Thu, 04 Apr 2019 13:20:04 GMT):
@sklump okay, I will try that tonight

JamesCarter (Thu, 04 Apr 2019 16:31:38 GMT):
Hello! Each Credential Offer includes a unique nonce value. When I get back the corresponding Credential Request from a wallet, I thought I would be able to use the nonce in the credential request to find the original Credential Offer, since both are needed to generated the credential. However, this does not seem to be the case..... they are totally different values. Is the wallet hashing the nonce with its master secret or something? What is the point of these nonce values, and what are they meant to protect?

JamesCarter (Thu, 04 Apr 2019 16:31:38 GMT):
Hello! Each Credential Offer includes a unique nonce value. When I get back the corresponding Credential Request from a wallet, I thought I would be able to use the nonce in the credential request to find the original Credential Offer, since both are needed to generated the credential. However, this does not seem to be the case..... they are totally different values. The wallet is just creating a brand new nonce. fn create_credential_request(&self, wallet_handle: WalletHandle, prover_did: &str, cred_offer: &CredentialOffer, cred_def: &CredentialDefinitionV1, master_secret_id: &str) -> IndyResult<(String, String)> { ...... let nonce = new_nonce()?; So what is the point of these nonce values, and are they protecting against?

JamesCarter (Thu, 04 Apr 2019 16:31:38 GMT):
Hello! Each Credential Offer includes a unique nonce value. When I get back the corresponding Credential Request from a wallet, I thought I would be able to use the nonce in the credential request to find the original Credential Offer, since both are needed to generate the credential. However, this does not seem to be the case..... they are totally different values. The wallet is just creating a brand new nonce. fn create_credential_request(&self, wallet_handle: WalletHandle, prover_did: &str, cred_offer: &CredentialOffer, cred_def: &CredentialDefinitionV1, master_secret_id: &str) -> IndyResult<(String, String)> { ...... let nonce = new_nonce()?; So what is the point of these nonce values, and are they protecting against?

nbrempel (Thu, 04 Apr 2019 16:39:41 GMT):
Hi everyone, I'm seeing the following error and I'm wondering if anyone else has experienced this? ``` indy.error.IndyError: (, {'backtrace': '', 'message': 'Error: Invalid structure\n Caused by: Invalid ProofRequest json has been passed\n Caused by: Error: Invalid library state\nCaused by: Internal OpenSSL error\nCaused by: OpenSSL error\n at line 1 column 147\n'}) ``` The proof request: ``` {"name": "168a2570-88e6-40db-93a8-37b0da536d51", "version": "c6214912-66ab-43ca-b663-1c6ea51af436", "nonce": "fe3ea566-8c96-438c-98eb-69dfa9bc9bec", "requested_attributes": {"991f5aa5-eeec-467e-847e-05c2b34e3634": {"name": "attr1", "restrictions": [{"cred_def_id": "4QxzWk3ajdnEA37NdNU5Kt:3:CL:7:default"}]}}, "requested_predicates": {"780bd61f-53ef-40b7-b3d8-c817576d1627": {"name": "attr2", "restrictions": [{"cred_def_id": "4QxzWk3ajdnEA37NdNU5Kt:3:CL:7:default"}], "p_value": 1, "p_type": ">="}}} ``` The error appears intermittently.

nbrempel (Thu, 04 Apr 2019 16:42:26 GMT):
will try with a different nonce/name/version. Just realized I'm still shoving uuids in there.

nbrempel (Thu, 04 Apr 2019 16:42:26 GMT):
will try with a different nonce/name/version. Just realized I'm still shoving uuids in there. However, I did send the same proof request twice (with different name/version/nonce) and it succeeded once and failed once.

nbrempel (Thu, 04 Apr 2019 16:43:09 GMT):
Side note: Do the name/version have any purpose besides human-readable info?

nbrempel (Thu, 04 Apr 2019 16:59:50 GMT):
using a stringified int as the nonce seems to be working consistently. At least for the first 3 attempts. ` "nonce": "184948324753549367086067059032266913704`

sklump (Thu, 04 Apr 2019 17:13:53 GMT):
@nbrempel nonce, name, version are just text that the operation carries around. At least I thought so until I saw this business with the UUIDs.

tomislav (Thu, 04 Apr 2019 18:33:02 GMT):
@nbrempel @sklump The problem is in the first character in the nonce, it has to be numeric. Anything after it is accepted, even unicode characters. This is a bug in the SDK

nbrempel (Thu, 04 Apr 2019 18:45:51 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=MvSSguEN5MQxzwC4s) @tomislav thanks! good to know what to avoid

tomislav (Thu, 04 Apr 2019 20:06:12 GMT):
We use guid in AF, but always prepend a 0 to avoid this. Weird bug

hagenderouen (Fri, 05 Apr 2019 14:56:34 GMT):
Has joined the channel.

hagenderouen (Fri, 05 Apr 2019 15:00:06 GMT):
Attempting MacOS build. Couldn't find mac.build.sh file in the repo. Tried manual build but couldn't compile. I'm working in Mojave 10.14. Any help would be great

ianco (Fri, 05 Apr 2019 17:06:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=YjN8rf6etgMQteBTt) @hagenderouen What error are you getting? "cargo build" works for me, but you may be missing some dependencies

DonClaude (Sun, 07 Apr 2019 07:57:49 GMT):
Has joined the channel.

DonClaude (Sun, 07 Apr 2019 08:20:03 GMT):
Hello, I am trying to build the Indy-SDK on Windows. Error while executing the test command: <...>\indy-sdk\wrappers> py.test.exe DEBUG:indy.libindy:_load_cdll: >>> DEBUG:indy.libindy:_load_cdll: Detected OS name: win32 DEBUG:indy.libindy:_load_cdll: Resolved libindy name is: indy.dll ERROR:indy.libindy:_load_cdll: Can't load libindy: [WinError 126] The specified module could not be found How do I install the native indy library correctly? I've dowloaded the stable release from: https://repo.sovrin.org/windows/libindy/stable/1.8.2/ and set the environment varibles for path (is that correct?).

bricg (Mon, 08 Apr 2019 09:38:07 GMT):
Hi, I am able to create proofs (using indy-sdk anoncreds.indy_prover_create_proof) based on a proof-request which predicates for age >= to certain values. However I've noticed that the information in the generated proofs are the same regardless of what predicate value I use, age >= 18 and age>21 both result in this proof. I assume this can't be correct as I could simply pass off the same proof for proving I over any age. Can someone provide an example of what a proof should look like for a proof request containing a predicate? ```{"proof": {"proof": {"proofs": {}, "aggregated_proof": {"c_hash": "17581745934805546029946686208002082275069028869859377397144702764549275017729", "c_list": []}}, "requested_proof": {"revealed_attrs": {}, "unrevealed_attrs": {}, "self_attested_attrs": {}, "predicates": {"proof_of_age_over_18": "claim::c1aea61b-d029-44c1-af83-851d4c516f93"}}, "identifiers": {}}}```

bricg (Mon, 08 Apr 2019 09:38:07 GMT):
Hi, I am able to create proofs (using indy-sdk anoncreds.indy_prover_create_proof) for a proof-request which contains predicates for age >= to certain values. However I've noticed that the information in the generated proofs are the same regardless of what predicate value I use, age >= 18 and age>21 both result in this proof. I assume this can't be correct as I could simply pass off the same proof for proving I over any age. Can someone provide an example of what a proof should look like for a proof request containing a predicate? ```{"proof": {"proof": {"proofs": {}, "aggregated_proof": {"c_hash": "17581745934805546029946686208002082275069028869859377397144702764549275017729", "c_list": []}}, "requested_proof": {"revealed_attrs": {}, "unrevealed_attrs": {}, "self_attested_attrs": {}, "predicates": {"proof_of_age_over_18": "claim::c1aea61b-d029-44c1-af83-851d4c516f93"}}, "identifiers": {}}}```

bricg (Mon, 08 Apr 2019 09:38:07 GMT):
Hi, I am able to create proofs (using indy-sdk anoncreds.indy_prover_create_proof) for a proof-request which contains predicates for age >= to certain values. However I've noticed that the information in the generated proofs are the same regardless of what predicate value I use, age >= 18 and age >= 21 both result in this proof. I assume this can't be correct as I could simply pass off the same proof for proving I over any age. Can someone provide an example of what a proof should look like for a proof request containing a predicate? ```{"proof": {"proof": {"proofs": {}, "aggregated_proof": {"c_hash": "17581745934805546029946686208002082275069028869859377397144702764549275017729", "c_list": []}}, "requested_proof": {"revealed_attrs": {}, "unrevealed_attrs": {}, "self_attested_attrs": {}, "predicates": {"proof_of_age_over_18": "claim::c1aea61b-d029-44c1-af83-851d4c516f93"}}, "identifiers": {}}}```

bricg (Mon, 08 Apr 2019 09:38:07 GMT):
Hi, I am able to create proofs (using indy-sdk anoncreds.indy_prover_create_proof) for a proof-request which contains predicates for age >= to certain values. However I've noticed that the information in the generated proofs are the same regardless of what predicate value I use, age >= 18 and age >= 21 both result in this proof. I assume this can't be correct as I could simply pass off the same proof for proving I am over any age. Can someone please provide an example of what a proof should look like for a proof request containing a predicate? ```{"proof": {"proof": {"proofs": {}, "aggregated_proof": {"c_hash": "17581745934805546029946686208002082275069028869859377397144702764549275017729", "c_list": []}}, "requested_proof": {"revealed_attrs": {}, "unrevealed_attrs": {}, "self_attested_attrs": {}, "predicates": {"proof_of_age_over_18": "claim::c1aea61b-d029-44c1-af83-851d4c516f93"}}, "identifiers": {}}}```

tomislav (Mon, 08 Apr 2019 20:11:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9rs8mGwp8Fdc9BGZX) @bricg Does the proof pass as valid when proof requests asks for a value out range of the age in the issued credential? @bricg

tomislav (Mon, 08 Apr 2019 20:18:50 GMT):
@DonClaude That's correct. It may depend on the runtime wrapper you're using. Generally, adding the DLLs to the PATH environment variable is enough. `ctypes` in python should be able to find the DLL in your path.

bricg (Tue, 09 Apr 2019 09:25:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wBJzuQzu7jvvDizPN) @tomislav @tomislav No, it will fail if a specific proof request asks for value, and credential age is too low. However, as a constructed proof for 'age >=18' appears to be the same as a constructed proof for 'age >=21', couldn't the prover generate this proof let's say if they are 19 for age>=18, and simply return it to a verifier who has requested age >=21? Am I missing something obvious here? I should point out that I'm using an old version of indy-sdk (v1.3.1) due to other restraints in my PoC code base, so maybe the zkp wasn't fully implemented in this version.

bricg (Tue, 09 Apr 2019 10:54:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=R7NhS367WMWxkRuP2) @tomislav I've just noticed the nonce in the proof-request which does change the constructed proof. However if the nonce is not secret, I still think the prover could spoof the constructed proof

lovesh (Tue, 09 Apr 2019 12:33:36 GMT):
@bricg Is there a code snippet you can share?

jsh4rk (Tue, 09 Apr 2019 14:01:52 GMT):
Has joined the channel.

jsh4rk (Tue, 09 Apr 2019 14:06:37 GMT):
Hello everyone, im getting a NullPointerException when I try to use the java wrapper in android studio. I copied libindy.so and libgnustl_shared.so to app\src\main\jniLibs\x86 and set the compileOptions to java 8 in build.gradle. Not build errors occur, but when I try to invok Pool.setProtocolVersion(1) the app crashes and I get the following: Caused by: java.lang.NullPointerException: Attempt to invoke interface method 'int org.hyperledger.indy.sdk.LibIndy$API.indy_set_protocol_version(int, int, com.sun.jna.Callback)' on a null object reference at org.hyperledger.indy.sdk.pool.Pool.setProtocolVersion(Pool.java:246). Can someone give me an advice how to set up the sdk for android properly?

bricg (Tue, 09 Apr 2019 14:18:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=cECdk4noTrLCLNYNh) @lovesh I'm not really sure which code snippet to share but here is the flow I'm thinking of. Let's say Alice holds a credential something like this ```{ "name": "entity.person", "version": "0.0.3025", "attr_names": [ "first_name”:”Alice”, "last_name":“White”, "age":19, ] }```

bricg (Tue, 09 Apr 2019 14:19:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=gkyyahuH65dDzhPyc) Then another party send her a proof request as follows ```{ "name": "Age_Over_18", "version": "1.0.0", "nonce": "1986273812765873", "requested_attrs": {}, "requested_predicates": { "proof_of_age_over_18": { "attr_name": “age”, "p_type": “>=", "value": “18”, "restrictions": [ { "schema_key": { "name": "entity.person", "version": "0.0.3025" } } ] } } }```

bricg (Tue, 09 Apr 2019 14:19:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=gkyyahuH65dDzhPyc) Then another party send her a proof request as follows ```{ "name": "Age_Over_21", "version": "1.0.0", "nonce": "1986273812765873", "requested_attrs": {}, "requested_predicates": { "proof_of_age_over_21": { "attr_name": “age”, "p_type": “>=", "value": “21”, "restrictions": [ { "schema_key": { "name": "entity.person", "version": "0.0.3025" } } ] } } }```

bricg (Tue, 09 Apr 2019 14:25:31 GMT):
@lovesh Couldn't Alice potentially edit the incoming proof request so that the predicate value is 18, and therefore that allows her to construct a valid proof. From what I've seen the proofs look identical, regardless of the predicate value. Then Alice sends this proof back to requesting party as proof of being over 21, even though she only has a credential for being 19. I assume i am missing something obvious here and that the proofs I'm constructing are not fully formed. here is an example of one ```{"proof": {"proof": {"proofs": {}, "aggregated_proof": {"c_hash": "17581745934805546029946686208002082275069028869859377397144702764549275017729", "c_list": []}}, "requested_proof": {"revealed_attrs": {}, "unrevealed_attrs": {}, "self_attested_attrs": {}, "predicates": {"proof_of_age_over_18": "claim::c1aea61b-d029-44c1-af83-851d4c516f93"}}, "identifiers": {}}}```

bricg (Tue, 09 Apr 2019 14:25:31 GMT):
@lovesh Couldn't Alice potentially edit the incoming proof request so that the predicate value is 18, and therefore that allows her to construct a valid proof. From what I've seen the proofs look identical, regardless of the predicate value. Then Alice sends this proof back to requesting party as proof of being over 21, even though she only has a credential for being 19. I assume i am missing something obvious here and that the proofs I'm constructing are not fully formed. here is an example of one ```{"proof": {"proof": {"proofs": {}, "aggregated_proof": {"c_hash": "17581745934805546029946686208002082275069028869859377397144702764549275017729", "c_list": []}}, "requested_proof": {"revealed_attrs": {}, "unrevealed_attrs": {}, "self_attested_attrs": {}, "predicates": {"proof_of_age_over_21": "claim::c1aea61b-d029-44c1-af83-851d4c516f93"}}, "identifiers": {}}}```

sklump (Tue, 09 Apr 2019 15:27:09 GMT):
re: metadata. I see that pairwise metadata has no specification, but the wrapper appears to require non_secrets tags to be `{str:str}`, at most one level deep. While at Utah, I was sure that indy-sdk developers assured me that pairwise used non_secrets internally. Is this documentation ``` async def add_wallet_record(wallet_handle: int, type_: str, id_: str, value: str, tags_json: Optional[str]) -> None: """ Create a new non-secret record in the wallet :param wallet_handle: wallet handler (created by open_wallet). :param type_: allows to separate different record types collections :param id_: the id of record :param value: the value of record :param tags_json: the record tags used for search and storing meta information as json: { "tagName1": , // string tag (will be stored encrypted) "tagName2": , // string tag (will be stored encrypted) "~tagName3": , // string tag (will be stored un-encrypted) "~tagName4": , // string tag (will be stored un-encrypted) } :return: None """ ``` misleading? Or must "tags" follow `{str:str}` convention whereas metadata is a free-for-all? Puzzling evidence.

rchristman (Tue, 09 Apr 2019 16:03:42 GMT):
Has joined the channel.

rchristman (Tue, 09 Apr 2019 16:13:45 GMT):
What is the license agreement for libvcx? There are indications this is Evernym code yet it's under indy-sdk which has an Apache license.

AxelNennker (Tue, 09 Apr 2019 16:40:39 GMT):
Can somebody please tell me why libindy/src/services/pool/mod.rs https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/services/pool/mod.rs#L703 uses `let (vk, sk) = sodiumoxide::crypto::sign::ed25519::gen_keypair();` instead of zmq's `zmq_curve_keypair` http://api.zeromq.org/4-0:zmq-curve-keypair The tests in rust-zmq use that function https://github.com/erickt/rust-zmq/blob/master/tests/curve.rs#L12

AxelNennker (Tue, 09 Apr 2019 16:41:52 GMT):
Different curve, maybe?

lovesh (Tue, 09 Apr 2019 19:20:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=gkyyahuH65dDzhPyc) @bricg I was aksing about the code which shows that the information in the generated proofs are the same regardless of what predicate value you use, age >= 18 or age >= 21?

lovesh (Tue, 09 Apr 2019 19:24:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=BxHrzdGf3DC7gEPgW) @bricg On Alice editing proof request, she can but the verifier will not accept as he knows what proof request he sent. The proof looks odd as c_list is empty. Can share the code that result in such a proof?/

jsh4rk (Tue, 09 Apr 2019 20:08:52 GMT):
How can one connect to an existing pool on android?

PatrikStas (Tue, 09 Apr 2019 20:36:11 GMT):
Hey everyone, I found something I wonder about. https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/indy-walkthrough.md#connecting-the-establishment it would seem like in the step 3, steward is writing on ledger a pairwise DID for communication channel between `Steward -----> onboarded Faber`? Is this some sort of best practice specific for onboarded entities? I was writing answer to this https://stackoverflow.com/questions/55392723/which-verification-key-is-used-for-steward-in-indy but when I took a better look, I realiized I am also confused why the DID in 3rd step is being written on the ledger. The only thing I expected to be written on the ledger was the actual Faber's DID.

swcurran (Tue, 09 Apr 2019 20:43:19 GMT):
@PatrikStas - the writes to the ledger are in the getting started demo because at the time it was created, the pairwise DID concept had not been fleshed out enough and so all DIDs were written to the ledger. With the advancement of the connection protocol (https://github.com/hyperledger/indy-hipe/tree/master/text/0031-connection-protocol) and related HIPEs (some of which are still in progress), agents are using pairwise DIDs and are not writing those DIDs to the ledger.

swcurran (Tue, 09 Apr 2019 20:43:19 GMT):
@PatrikStas - the writes to the ledger are in the getting started demo because at the time it was created, the pairwise DID concept had not been fleshed out enough and so all DIDs in code were being written to the ledger. With the advancement of the connection protocol (https://github.com/hyperledger/indy-hipe/tree/master/text/0031-connection-protocol) and related HIPEs (some of which are still in progress), agents are using pairwise DIDs and are not writing those DIDs to the ledger.

PatrikStas (Tue, 09 Apr 2019 20:47:40 GMT):
@swcurran thanks, that makes sense. Maybe I'll post pull request on the tutorial, though I suppose there might be more things to fix other than this.

PatrikStas (Tue, 09 Apr 2019 20:48:12 GMT):
It would be good to update the walkthrough, it's probably the first place people look into when they are getting started

bricg (Wed, 10 Apr 2019 08:01:44 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=J5uRvqyqSb3pfKdx7) @lovesh You can see on visual inspection that the proofs are the same. The only information that they actually contain is the aggregated_proof.c_hash value "17581745934805546029946686208002082275069028869859377397144702764549275017729".

kdenhartog (Wed, 10 Apr 2019 15:11:31 GMT):
I've been working with the objective-C wrapper for an iOS app and noticed something interesting. Because there is a small amount of C code that was written in what appears to be Swift 3.x and is compilable by Swift 4.2, XCode 10 is necessary in order to compile it for a simulator. However, Mojave 10.14.4 (latest update) in combination with XCode 5.2 (latest update) now only has Swift 5.0 compiler. So, if you're looking to use the Objective C wrapper to build an iOS app and run it through a simulator you should download XCode 10 separately, so that you can build and run the app.

kdenhartog (Wed, 10 Apr 2019 15:13:06 GMT):
Also, I think it would be good for us to migrate the code to swift 5.0 syntax. (I'm looking at what needs to be done and hopefully will submit a PR for it)

swcurran (Wed, 10 Apr 2019 16:28:42 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=wrSbN9yQK8a3EXvkc) @PatrikStas Agreed - there is lots of improvement that could be made to the getting started. It's always been challenging as it is quite large, the implementation is changing rapidly and the audience is varied - those that want to understand Indy, those that want to contrbute to Indy and those that want to build things on Indy. It's a big undertaking, and most people are working on their own projects.

feliperdelara (Wed, 10 Apr 2019 19:34:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=gykcZ2nXmbCNxQriA) @kdenhartog Looking forward to this! I am using Xcode 10 for the same reasons but it will be a problem when I upload my app to the store since Apple does not allow swift 4.2 builds anymore...

pranavkirtani (Thu, 11 Apr 2019 03:36:51 GMT):
Has joined the channel.

pranavkirtani (Thu, 11 Apr 2019 03:37:10 GMT):
I am facing issues setting up indy-sdk on windows machine,please can you assist

pranavkirtani (Thu, 11 Apr 2019 03:37:24 GMT):
> indy-sdk@1.8.2 install D:\indy-sdk\indy-sdk\samples\nodejs\node_modules\indy-sdk > node-gyp rebuild D:\indy-sdk\indy-sdk\samples\nodejs\node_modules\indy-sdk>if not defined npm_config_node_gyp (node "C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild ) else (node "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js" rebuild ) Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch. indy.cc win_delay_load_hook.cc ..\src\indy.cc(1133): error C3861: 'indy_pack_message': identifier not found [D:\indy-sdk\indy-sdk\samples\nodejs\node_ modules\indy-sdk\build\indynodejs.vcxproj] ..\src\indy.cc(1154): error C3861: 'indy_unpack_message': identifier not found [D:\indy-sdk\indy-sdk\samples\nodejs\nod e_modules\indy-sdk\build\indynodejs.vcxproj] ..\src\indy.cc(2065): error C3861: 'indy_build_auth_rule_request': identifier not found [D:\indy-sdk\indy-sdk\samples\n odejs\node_modules\indy-sdk\build\indynodejs.vcxproj] ..\src\indy.cc(2097): error C3861: 'indy_build_get_auth_rule_request': identifier not found [D:\indy-sdk\indy-sdk\sampl es\nodejs\node_modules\indy-sdk\build\indynodejs.vcxproj] ..\src\indy.cc(2118): error C3861: 'indy_get_response_metadata': identifier not found [D:\indy-sdk\indy-sdk\samples\nod ejs\node_modules\indy-sdk\build\indynodejs.vcxproj] ..\src\indy.cc(2979): error C3861: 'indy_generate_wallet_key': identifier not found [D:\indy-sdk\indy-sdk\samples\nodej s\node_modules\indy-sdk\build\indynodejs.vcxproj]

Unni_1994 (Thu, 11 Apr 2019 06:09:52 GMT):
Has joined the channel.

mauricio (Thu, 11 Apr 2019 15:08:26 GMT):
Has joined the channel.

brentzundel (Thu, 11 Apr 2019 16:20:49 GMT):
Has left the channel.

PatrikStas (Sat, 13 Apr 2019 20:45:45 GMT):
@pranavkirtani You've already built indysdk right? And now you are trying to compile indysdk nodejs wrapper...? I am not sure, but my hunch. I think you've built indysdk library binaries from certain revision of indy-sdk repo but later you've checked out different version of sources. So you are now trying to built indysdk nodejs wrapper around binaries from different indysdk revision.

magicindustries (Sun, 14 Apr 2019 07:09:04 GMT):
Can any agent install become a trust anchor for themselves? IE could I have a verifier / steward able to register individuals as a limited trust anchor so they can issue a personal verifiable credential, say for authentication of followers to grant access to a feed?

PatrikStas (Sun, 14 Apr 2019 09:53:20 GMT):
Hi everyone , I've made a small bash tool for managing different version of your IndySDK binaries - `libindy` `libvcx` and `libnullpay`. Recently I had a need to switch versions often and this is what came out of that. Hope someone finds this useful https://github.com/Patrik-Stas/indyjump

PatrikStas (Sun, 14 Apr 2019 09:53:20 GMT):
Hi everyone , I've made a small bash tool `indyjump` for managing different version of your IndySDK binaries - `libindy` `libvcx` and `libnullpay`. Recently I had a need to switch versions often and this is what came out of that. Hope someone finds this useful https://github.com/Patrik-Stas/indyjump

nekia (Mon, 15 Apr 2019 01:10:11 GMT):
Has joined the channel.

pranavkirtani (Mon, 15 Apr 2019 03:15:45 GMT):
@PatrikStas :I followed the setps mentioned in the setup page of downloading the libindy zip,unzipping it and placing lib folder in PATH

pawanbhobe (Mon, 15 Apr 2019 06:18:09 GMT):
Has joined the channel.

MoonLee (Mon, 15 Apr 2019 13:12:43 GMT):
Has joined the channel.

mgbailey (Mon, 15 Apr 2019 14:15:50 GMT):
@magicindustries Any Sovrin Steward can write a transaction to any Sovrin validator pool establishing an entity’s DID as a Transaction Endorser (TE), which is a a new type of identity similar to a trust anchor in the new Sovrin governance framework. However, before doing so on the MainNet, the steward must assure that the appropriate pledges have been filed with the Sovrin Foundation. Currently, such pledges include an agreement to pay for ledger writes, for which the entity will be billed. In the future such payments will be automated by means of a digital token. Anyone wishing for a DID on the other Sovrin pools may get it for the asking from any steward, or by request from support@sovrin.org. There are no costs associated with the other validator pools.

anillewis (Mon, 15 Apr 2019 15:16:53 GMT):
Has joined the channel.

jacobsaur (Mon, 15 Apr 2019 15:33:44 GMT):
Hi all, I wanted to get some advice about verifiable images. My first approach was to base64 encode the image and include it in the verifiable credential but the indy sdk threw an error (understandable because it's so large). My workaround is to store the base64 image as a wallet record, and then just store the hash of the image in the verifiable credential. That way the holder can still share the image from their wallet, and it can still be verified by the verifier. I was wondering, first, if there was a better more official way to do this. Second, if not, is there a generic way to include the base64 image in the proof, eg a way of saying here is some extra data, use hash algorithm X and check against credential attribute Y to verify.

pawanbhobe (Mon, 15 Apr 2019 16:58:25 GMT):

Clipboard - April 15, 2019 10:28 PM

pawanbhobe (Mon, 15 Apr 2019 17:00:38 GMT):

Clipboard - April 15, 2019 10:30 PM

pawanbhobe (Mon, 15 Apr 2019 17:02:19 GMT):
I am installing Indy-sdk on macOS High Sierra 10.13.6 : Referring to https://github.com/hyperledger/indy-sdk/blob/master/docs/build-guides/mac-build.md Facing issue while installing libSodium . Please advice. Below 2 commands are failing : 1. Step 2 : brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/65effd2b617bade68a8a2c5b39e1c3089cc0e945/Formula/libsodium.rb 2. cargo build More details below Step 2 : brew install https://raw.githubusercontent.com/Homebrew/homebrew-core/65effd2b617bade68a8a2c5b39e1c3089cc0e945/Formula/libsodium.rb Warning: libsodium 1.0.17 is available and more recent than version 1.0.12. ==> Downloading https://homebrew.bintray.com/bottles/libsodium-1.0.12.sierra.bottle.tar.gz Already downloaded: /Users/pawan/Library/Caches/Homebrew/downloads/69599092a97fa907b1838164cea7aca2901a99b815a467fb84bf7534b67b46fd--libsodium-1.0.12.sierra.bottle.tar.gz Error: SHA256 mismatch Expected: e05aba6c665a7a5de297e135568882b6706728ce25820d609a6984b09b69086e Actual: 0a64df6bdd78eea1d141776def103b89ef7dad897e0785c14809ba130ad4c22c Archive: /Users/pawan/Library/Caches/Homebrew/downloads/69599092a97fa907b1838164cea7aca2901a99b815a467fb84bf7534b67b46fd--libsodium-1.0.12.sierra.bottle.tar.gz To retry an incomplete download, remove the file above. Warning: Bottle installation failed: building from source. ==> Downloading https://github.com/jedisct1/libsodium/releases/download/1.0.12/libsodium-1.0.12.tar.gz Already downloaded: /Users/pawan/Library/Caches/Homebrew/downloads/13d45b6f90b45328b73fe16b1c4a2fa213818db2dc27c08b20049c806cabd88a--libsodium-1.0.12.tar.gz ==> ./configure --prefix=/usr/local/Cellar/libsodium/1.0.12 ==> make check Last 15 lines from /Users/pawan/Library/Logs/Homebrew/libsodium/02.make: 2019-04-15 20:41:05 +0530 make check Making check in contrib /bin/sh: /Users/pawan/Desktop/New: is a directory make: *** [check-recursive] Error 1 Do not report this issue to Homebrew/brew or Homebrew/core! Error: Your Xcode (10.0) is outdated. Please update to Xcode 10.1 (or delete it). Xcode can be updated from the App Store. Command in the terminal : cargo build Gives error: failed to run custom build command for `libsodium-sys v0.0.16` process didn't exit successfully: `/Users/pawan/myspace/reactnative/sovrin-foundation/indynew/indy-sdk/libindy/target/debug/build/libsodium-sys-11ca1e77069cd920/build-script-build` (exit code: 101) --- stdout cargo:rerun-if-env-changed=SODIUM_LIB_DIR cargo:rerun-if-env-changed=SODIUM_STATIC --- stderr thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: "`\"pkg-config\" \"--libs\" \"--cflags\" \"libsodium\"` did not exit successfully: exit code: 1\n--- stderr\nPackage libsodium was not found in the pkg-config search path.\nPerhaps you should add the directory containing `libsodium.pc\'\nto the PKG_CONFIG_PATH environment variable\nNo package \'libsodium\' found\n"', src/libcore/result.rs:997:5 note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace. warning: build failed, waiting for other jobs to finish... error: build failed

PatrikStas (Mon, 15 Apr 2019 18:17:41 GMT):
Hi @pawanbhobe, seems like you need to update your Xcode? It says ``` Error: Your Xcode (10.0) is outdated. Please update to Xcode 10.1 (or delete it). Xcode can be updated from the App Store. ```

PatrikStas (Mon, 15 Apr 2019 18:22:15 GMT):
@pranavkirtani I didn't know there are precompiles for Windows. Which version of libindy exactly did you download? Can you refer to the page you've followed?

kdenhartog (Mon, 15 Apr 2019 21:33:04 GMT):
@jacobsaur the method you're using is close to the same way. The other way that could be used is to provide a link to the image, such that the verifier can hash it and see that it matches the signed hash in the credential. Some of these ideas have been included in the attachment HIPE https://github.com/hyperledger/indy-hipe/blob/e3e0b98040f5644f59eca9c6f641e757b7118f8d/text/attachments/README.md

magicindustries (Mon, 15 Apr 2019 21:43:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=tQEX42rCuBYSW3gWG) @mgbailey Thanks @mgbailey. Just to check - it's the steward who pays the ledger writing fees in that instance?

mbanerjee (Tue, 16 Apr 2019 00:18:41 GMT):
Has joined the channel.

wangdong (Tue, 16 Apr 2019 04:16:42 GMT):
`dyld: Library not loaded: @rpath/libswiftCore.dylib`

wangdong (Tue, 16 Apr 2019 04:17:13 GMT):
i got this error when to build app with indy-framework.

wangdong (Tue, 16 Apr 2019 04:17:44 GMT):
I tried many the methods found on the network. None works.

wangdong (Tue, 16 Apr 2019 04:17:54 GMT):
Does any one got this issue?

pranavkirtani (Tue, 16 Apr 2019 06:08:16 GMT):
@PatrikStas :I Followed steps from this link https://github.com/hyperledger/indy-sdk , in the "Windows" section

PatrikStas (Tue, 16 Apr 2019 08:13:32 GMT):
@pranavkirtani I see, well, it's important which version of IndySDK you've downloaded exactly. The version you download and the revision of source code you are using to build NodeJS Wrapper matters. I suggest you to: - Download `1.8.2` from stable https://repo.sovrin.org/windows/libindy/stable/1.8.2/ - Then in indy-sdk repo directory checkout `git checkout v1.8.2` - Try to rebuild

pranavkirtani (Tue, 16 Apr 2019 08:14:23 GMT):
ok thanks , I will try this

JeganSelvaraj (Tue, 16 Apr 2019 08:53:33 GMT):
Has joined the channel.

MichalRybarczyk (Tue, 16 Apr 2019 12:33:33 GMT):
Has joined the channel.

mgbailey (Tue, 16 Apr 2019 15:10:08 GMT):
@magicindustries Whoever writes a transaction to the ledger pays. So A steward who writes the DID of a new Transaction Endorser to the ledger would pay for that. When that Transaction Endorser later writes a schema and cred def to the ledger, the TE would need to pay for that.

magicindustries (Tue, 16 Apr 2019 15:33:36 GMT):
Lovely, thanks @mgbailey

magicindustries (Tue, 16 Apr 2019 15:37:18 GMT):
I'm working on an agent in Unity/C#, currently using the rust wrapper, but I'm getting error 113 trying to establish the pool config. As far as I can tell that means something to do with a missing or ill formed config but I can't work out how to debug it further. Can anyone point me to how to find out more detail about what's happening under the hood?

magicindustries (Tue, 16 Apr 2019 15:38:52 GMT):
I do have the test nodes/ledger up and running via the nodejs samples, and the tutorial nodejs code works running on docker for mac, but I'm not sure where the connection or config is going missing

PatrikStas (Tue, 16 Apr 2019 15:49:48 GMT):
@magicindustries I haven't try C# wrapper, but 113 is CommonInvalidStructure, which from my experience you'll typically see when you for example pass to some indysdk method an object instead of JSON, an invalid JSON, a JSON with some missing field or unexpected field/value. If you can figure out what the problem is, try to increase logging level. I don't know how it's done in C# wrapper, but according to this https://github.com/hyperledger/indy-sdk/tree/master/wrappers/dotnet seems like just expering `RUST_LOG={info|debug|trace}` as environment variable

PatrikStas (Tue, 16 Apr 2019 15:50:18 GMT):
@magicindustries by the way Unity3D and IndySDK? Cool! Curious what are you working on as a former Unity3D dev

magicindustries (Tue, 16 Apr 2019 15:50:48 GMT):
ahh thanks for that @PatrikStas I'll try the log level. I'm loading json from a file copied from the how-to, but perhaps unity isn't passing it the way I expect it to

magicindustries (Tue, 16 Apr 2019 16:07:45 GMT):
@PatrikStas working on an SSI based identity solution which will be tied to a bunch of other spatial web stuff

PatrikStas (Tue, 16 Apr 2019 16:08:42 GMT):
@magicindustries Oh, the `Unity` you mentions is probably something else than Unity3D, right?

PatrikStas (Tue, 16 Apr 2019 16:08:42 GMT):
@magicindustries Oh, the `Unity` you mention is probably something else than Unity3D, right?

magicindustries (Tue, 16 Apr 2019 16:08:47 GMT):
stupid question - if Unity is using the rust lib, how/where do I enable the log level?

magicindustries (Tue, 16 Apr 2019 16:08:58 GMT):
nope, it's unity 3d :)

magicindustries (Tue, 16 Apr 2019 16:09:14 GMT):
among other things it will be AR stuff based on this identity layer

magicindustries (Tue, 16 Apr 2019 16:10:36 GMT):
I've confirmed valid json is being passed in, so it must be something else. I might also have the method configured wrong, as I don't quite know what this rust method's return would translate to in c#: pub fn create_pool_ledger_config(pool_name: &str, pool_config: Option<&str>) -> Box>

PatrikStas (Tue, 16 Apr 2019 16:16:49 GMT):
@magicindustries I am really just guessing, maybe you have to call the Init method over here? https://github.com/hyperledger/indy-sdk/blob/4e8d9a47e2a7d0368c26c26c0209caa6965c7b60/wrappers/dotnet/indy-sdk-dotnet/Utils/Logger.cs

PatrikStas (Tue, 16 Apr 2019 16:20:32 GMT):
And seems like the wrapper version of the method you mention is `CreatePoolLedgerConfigAsync` in `PoolApi/Pool.cs`

magicindustries (Tue, 16 Apr 2019 16:21:07 GMT):
yeah I probably should have thought of that

magicindustries (Tue, 16 Apr 2019 16:21:40 GMT):
yeah I'm using the rust wrapper, but maybe I should try the dotnet one

magicindustries (Tue, 16 Apr 2019 16:36:08 GMT):
tried a few things and it's definitely not liking the json I've passed in. I'm using the contents of the pool.txn file that the nodejs howto creates, I'm not sure where else to get this config from

magicindustries (Tue, 16 Apr 2019 16:40:23 GMT):
I'm executing it like this: Debug.Log(indy_create_pool_ledger_config("pool", JsonUtility.ToJson(gen)));

magicindustries (Tue, 16 Apr 2019 16:40:40 GMT):
where "gen" is this: string gen = "{\"genesis_txn\":\"" + genpath + "\"}";

magicindustries (Tue, 16 Apr 2019 16:41:32 GMT):
and the contents of that file are this:

magicindustries (Tue, 16 Apr 2019 16:41:36 GMT):
{"reqSignature": {}, "txn": {"data": {"data": {"alias": "Node1", "blskey": "4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba", "blskey_pop": "RahHYiCvoNCtPTrVtP7nMC5eTYrsUA8WjXbdhNc8debh1agE9bGiJxWBXYNFbnJXoXhWFMvyqhqhRoq737YQemH5ik9oL7R4NTTCz2LEZhkgLJzB3QRQqJyBNyv7acbdHrAT8nQ9UkLbaVL9NBpnWXBTw4LEMePaSHEw66RzPNdAX1", "client_ip": "127.0.0.1", "client_port": 9702, "node_ip": "127.0.0.1", "node_port": 9701, "services": ["VALIDATOR"]}, "dest": "Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv"}, "metadata": {"from": "Th7MpTaRZVRYnPiabds81Y"}, "type": "0"}, "txnMetadata": {"seqNo": 1, "txnId": "fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62"}, "ver": "1"} {"reqSignature": {}, "txn": {"data": {"data": {"alias": "Node2", "blskey": "37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk", "blskey_pop": "Qr658mWZ2YC8JXGXwMDQTzuZCWF7NK9EwxphGmcBvCh6ybUuLxbG65nsX4JvD4SPNtkJ2w9ug1yLTj6fgmuDg41TgECXjLCij3RMsV8CwewBVgVN67wsA45DFWvqvLtu4rjNnE9JbdFTc1Z4WCPA3Xan44K1HoHAq9EVeaRYs8zoF5", "client_ip": "127.0.0.1", "client_port": 9704, "node_ip": "127.0.0.1", "node_port": 9703, "services": ["VALIDATOR"]}, "dest": "8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb"}, "metadata": {"from": "EbP4aYNeTHL6q385GuVpRV"}, "type": "0"}, "txnMetadata": {"seqNo": 2, "txnId": "1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc"}, "ver": "1"} {"reqSignature": {}, "txn": {"data": {"data": {"alias": "Node3", "blskey": "3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5", "blskey_pop": "QwDeb2CkNSx6r8QC8vGQK3GRv7Yndn84TGNijX8YXHPiagXajyfTjoR87rXUu4G4QLk2cF8NNyqWiYMus1623dELWwx57rLCFqGh7N4ZRbGDRP4fnVcaKg1BcUxQ866Ven4gw8y4N56S5HzxXNBZtLYmhGHvDtk6PFkFwCvxYrNYjh", "client_ip": "127.0.0.1", "client_port": 9706, "node_ip": "127.0.0.1", "node_port": 9705, "services": ["VALIDATOR"]}, "dest": "DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya"}, "metadata": {"from": "4cU41vWW82ArfxJxHkzXPG"}, "type": "0"}, "txnMetadata": {"seqNo": 3, "txnId": "7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4"}, "ver": "1"} {"reqSignature": {}, "txn": {"data": {"data": {"alias": "Node4", "blskey": "2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw", "blskey_pop": "RPLagxaR5xdimFzwmzYnz4ZhWtYQEj8iR5ZU53T2gitPCyCHQneUn2Huc4oeLd2B2HzkGnjAff4hWTJT6C7qHYB1Mv2wU5iHHGFWkhnTX9WsEAbunJCV2qcaXScKj4tTfvdDKfLiVuU2av6hbsMztirRze7LvYBkRHV3tGwyCptsrP", "client_ip": "127.0.0.1", "client_port": 9708, "node_ip": "127.0.0.1", "node_port": 9707, "services": ["VALIDATOR"]}, "dest": "4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA"}, "metadata": {"from": "TWwCRQRZ2ZHMJFn9TzLp7W"}, "type": "0"}, "txnMetadata": {"seqNo": 4, "txnId": "aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008"}, "ver": "1"}

helengarneau (Tue, 16 Apr 2019 16:53:03 GMT):
Has joined the channel.

feliperdelara (Tue, 16 Apr 2019 18:25:13 GMT):
ios

tomislav (Tue, 16 Apr 2019 18:52:07 GMT):
@magicindustries Did you maybe edit the TXN file with an editor that adds CRLF line endings, like Visual Studio? I have seen the same issue and I had to use "vim" to make edits to the file.

magicindustries (Tue, 16 Apr 2019 19:34:28 GMT):
@tomislav hrm good idea I shall check

magicindustries (Tue, 16 Apr 2019 19:41:40 GMT):
@tomislav checked in vi and copied on the command line, still getting the same error.

magicindustries (Tue, 16 Apr 2019 19:41:57 GMT):
I'm passing in this: { "genesis_txn" : "/Users/tobytremayne/work/Demo/Assets/StreamingAssets/pool.txn" }

magicindustries (Tue, 16 Apr 2019 19:42:17 GMT):
but I can't tell if it's failing on that or the contents of the file

magicindustries (Tue, 16 Apr 2019 19:51:37 GMT):
actually it doesn't change if I specify a non-existant fileename in the config so maybe it's the way the config string is being passed to the wrapper

magicindustries (Tue, 16 Apr 2019 19:58:36 GMT):
bah, even passing the string in directly gives me the same error

tomislav (Tue, 16 Apr 2019 22:10:03 GMT):
What's your environment setup?

tomislav (Tue, 16 Apr 2019 22:10:31 GMT):
@magicindustries Are you able to run the samples successfully? https://github.com/hyperledger/indy-sdk/tree/master/samples/dotnet/Samples

tomislav (Tue, 16 Apr 2019 22:11:02 GMT):
`dotnet run` should produce successful with a local ledger running against 127.0.0.1

tomislav (Tue, 16 Apr 2019 22:11:02 GMT):
`dotnet run` should produce successful runs with a local ledger running against 127.0.0.1

magicindustries (Wed, 17 Apr 2019 01:13:41 GMT):
@tomislav I've been using the rust wrapper in unity, I'll give the dotnet one another try

magicindustries (Wed, 17 Apr 2019 01:48:52 GMT):
Argh. the samples worked but asked me for sdk 2.1. when I try to build the wrapper in visual studio though, I get this error unless I uninstall everything but 2.0:

magicindustries (Wed, 17 Apr 2019 01:48:54 GMT):
Error: The version of the .NET Core SDK currently installed (/usr/local/share/dotnet/sdk/2.2.106/Sdks) is not supported and continuing to use it may result in a broken tooling experience. https://aka.ms/vs/mac/install-netcore (indy-sdk-dotnet)

tomislav (Wed, 17 Apr 2019 02:14:04 GMT):
@magicindustries You can try building the wrapper in console using `msbuild /t:build /p `

tomislav (Wed, 17 Apr 2019 02:14:04 GMT):
@magicindustries You can try building the wrapper in console using `msbuild /t:build /p:Configuration=Release `

tomislav (Wed, 17 Apr 2019 02:14:57 GMT):
Here's how you can enable logging in libindy thru the dotnet wrapper and see where the error throws in rust runtime - https://github.com/hyperledger/indy-sdk/blob/master/wrappers/dotnet/indy-sdk-dotnet-test/SetupAssemblyInitializer.cs

magicindustries (Wed, 17 Apr 2019 02:45:13 GMT):
Thanks @tomislav that works to build the dlls. My next problem is I can't get unity to recognize it. With the rust wrapper, it compiles to a dylib which I can reename to .bundle and unity picks it up. but the hyperledger.indy.sdk.dll doesn't work either in it's original extension or renamed (I get not found). Admittedly I'm groping in the dark here as my recent experience with dotnet tooling is woefully inadequate

magicindustries (Wed, 17 Apr 2019 02:46:09 GMT):
I think actually I'm even worse off than I thought :) What I have in there is the libindy rust library, which compilled to a dll

magicindustries (Wed, 17 Apr 2019 02:47:32 GMT):
when I run cargo build for the rust wrapper however, I'm confused by the results, I have libindyrs.d libindyrs.rlib and a bunch of other stuff

magicindustries (Wed, 17 Apr 2019 02:49:42 GMT):
I guess I was actually talking directly to libindy, itself, not the rust wrapper

magicindustries (Wed, 17 Apr 2019 02:50:12 GMT):
the libindy dylib imports fine into unity, but we go back to the original problem of always getting 113 errors

magicindustries (Wed, 17 Apr 2019 03:11:31 GMT):
am trying to find a simple function I can test to be sure it's working, but I'm a rust noob so I've no idea what I'm doing :D

tomislav (Wed, 17 Apr 2019 03:13:33 GMT):
`pool_set_protocol_version` is a good test

tomislav (Wed, 17 Apr 2019 03:13:33 GMT):
`pool_set_protocol_version` is a good test or `Pool.SetProtocolVersionAsync` in dotnet

magicindustries (Wed, 17 Apr 2019 03:23:40 GMT):
that requires a "CommandHandle" param according to the code, I'm not sure how to pass that in

pranavkirtani (Wed, 17 Apr 2019 03:34:07 GMT):
@PatrikStas :https://github.com/hyperledger/indy-sdk repo does not have branch for version 1.8.2

magicindustries (Wed, 17 Apr 2019 03:38:41 GMT):
@tomislav I managed to get a 102 then finally a 0 from indy_set_protocol_version by passing in a callback function for both commandhandle and cb params, so it looks like the library is working.

magicindustries (Wed, 17 Apr 2019 03:38:56 GMT):
Which wakes me back to my original problem of wtf is wrong with my genesis_txn config

magicindustries (Wed, 17 Apr 2019 03:41:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=mA2MokXXxkxM8TLkm) @tomislav Thanks for this, trying to work out how to target Hyperledger.Indy.Utils.Logger.Init() from Unity. In Unity C# I have to add calls like this to access pub extern functions in the rust library:

magicindustries (Wed, 17 Apr 2019 03:41:43 GMT):
[DllImport("libindy")] private static extern int indy_set_protocol_version(MyDelegate ch, int version, MyDelegate cb);

magicindustries (Wed, 17 Apr 2019 03:42:53 GMT):
There doesn't seem to be an extern fn for the Logger init

magicindustries (Wed, 17 Apr 2019 03:51:56 GMT):
this might be simpler to answer - since I'm working in Unity I can't set env variables like RUST_LOG as I would on the command line. Is there some way I can globally force the log level?

magicindustries (Wed, 17 Apr 2019 04:32:28 GMT):
ok I've managed to make a few other functions work, likee set_protocol_version etc, but still having this problem with indy_create_pool_ledger_config returning 113 even when I load the config from a json file

magicindustries (Wed, 17 Apr 2019 04:33:42 GMT):
I now have some more logs coming out, and I get this:

magicindustries (Wed, 17 Apr 2019 04:33:48 GMT):
TRACE|indy::api::pool | src/api/pool.rs:35 | indy_create_pool_ledger_config: >>> config_name: 0x145f2c750, config: 0x7ffeefbfb5b4 113

andrew.whitehead (Wed, 17 Apr 2019 05:07:56 GMT):
`string gen = "{\"genesis_txn\":\"" + genpath + "\"}";` looks suspect if there's any special characters in the path, especially on windows

andrew.whitehead (Wed, 17 Apr 2019 05:07:56 GMT):
`string gen = "{\"genesis_txn\":\"" + genpath + "\"}";` looks suspect if there's any special characters in the path, especially on Windows. This looks relevant: https://jira.hyperledger.org/browse/IS-219

magicindustries (Wed, 17 Apr 2019 05:29:23 GMT):
@andrew.whitehead it's on osx. I've tried pulling the json in from a file, and also making an object/class and using jsonutility.tojson

magicindustries (Wed, 17 Apr 2019 05:29:43 GMT):
currently trying to add some more traces to the rust code for libindy but for some reason my changes don't seem to be going itno the build

magicindustries (Wed, 17 Apr 2019 05:31:23 GMT):
I'm just editing api/pool.rs and re-running mac-build.sh so I'm not sure what I'm missing yet

magicindustries (Wed, 17 Apr 2019 05:33:42 GMT):
aha! Seems Unitty was hangin onto a cached version, a reload of unity fixed that bit

magicindustries (Wed, 17 Apr 2019 05:34:40 GMT):
so now I have more info but still this error 113.. The trace in indy_create_pool_ledger_configaaa shows: TRACE|indy::api::pool | src/api/pool.rs:36 | indy_create_pool_ledger_config: >>> config_name: 0x1435da410, config: 0x7ffeefbfb594

magicindustries (Wed, 17 Apr 2019 05:34:40 GMT):
so now I have more info but still this error 113.. The trace in indy_create_pool_ledger_config shows: TRACE|indy::api::pool | src/api/pool.rs:36 | indy_create_pool_ledger_config: >>> config_name: 0x1435da410, config: 0x7ffeefbfb594

magicindustries (Wed, 17 Apr 2019 05:35:17 GMT):
slowly getting further by brute force and ignorance!

magicindustries (Wed, 17 Apr 2019 06:24:09 GMT):
turns out the macro checking the json coming in is receiving "\n"

magicindustries (Wed, 17 Apr 2019 06:24:40 GMT):
so it's something to do with the way it's being passed in. I had thought I could just put it in as a string but it appears not.

magicindustries (Wed, 17 Apr 2019 06:25:01 GMT):
wondering if I somehow need to be passing a pointer or some other type of variable

magicindustries (Wed, 17 Apr 2019 06:29:52 GMT):
curiouser and curiouser. with my new traces I can see that if I pass a string directly, the output of the trace here:

magicindustries (Wed, 17 Apr 2019 06:30:01 GMT):
macro_rules! check_useful_opt_json { ($x:ident, $e:expr, $t:ty) => { let $x = match ctypes::c_str_to_string($x) { Ok(Some(val)) => Some(val), Ok(None) => None, _ => { return err_msg($e.into(), "Invalid pointer has been passed").into() }, }; let $x: Option<$t> = match $x { Some(val) => { trace!("the json: {:?}",val); parse_json!(val, $e, $t); Some(val) }, None => None }; } }

magicindustries (Wed, 17 Apr 2019 06:30:31 GMT):
shows me whatever the 6th character in my string is. So obviously I'm getting something basic wrong

magicindustries (Wed, 17 Apr 2019 06:30:31 GMT):
shows me whatever the last character in my string is. So obviously I'm getting something basic wrong

magicindustries (Wed, 17 Apr 2019 06:30:53 GMT):
output of that trace is : the json: "q"

magicindustries (Wed, 17 Apr 2019 09:14:09 GMT):
Got it! I had to pass the strings in as "Encoding.UTF8.GetBytes(data)", and I also had to pass in a callback delegate for the command handle *and* for the optional cb param at the end. I'm still not 100% on how the commandhanddle bit works but the indy_create_pool_ledger_config call is finally working.

magicindustries (Wed, 17 Apr 2019 09:14:15 GMT):
thanks for the assist all

PatrikStas (Wed, 17 Apr 2019 11:05:41 GMT):
@magicindustries Good job! Just curious though, why are you not using the .net wrapper?

magicindustries (Wed, 17 Apr 2019 13:09:53 GMT):
@PatrikStas two reasons: 1) I like Rust and plan to use it for more stuff in this project, and 2) the dotnet environment was giving me the shits and not building properly :)

sklump (Wed, 17 Apr 2019 15:13:52 GMT):
I'm trying to flesh out a partial implementation for credential deletion in indy-sdk. Is an indy rustacean available to help with details? I have some stuff working, but I am having a hard time getting it to do the right thing with errors.

ONRising (Wed, 17 Apr 2019 16:07:44 GMT):
Has joined the channel.

mccown (Wed, 17 Apr 2019 17:18:52 GMT):
We're using the iOS Wrapper and noticed that OpenSSL is included. Is Indy (iOS wrapper) indenting to use OpenSSL or is it being replaced with a newer kit?

esplinr (Wed, 17 Apr 2019 19:44:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=49ggkCnJgaTuAXNYj) @rchristman I noticed your unanswered question from last week. libvcx was donated to Indy by Evernym. It is under the Apache license, the same as other code in the Indy SDK.

esplinr (Wed, 17 Apr 2019 19:45:03 GMT):
@mccown LibIndy currently depends on openssl.

esplinr (Wed, 17 Apr 2019 19:56:15 GMT):
All: As a result of the last few discussions in the Indy SDK Working Group calls, we plan to change how the language wrappers are organized. The core Indy SDK will continue to house "thin" bindings in many languages, but they will be the minimum required to support integration testing with the other repositories. We are creating separate repositories to house "thick" language libraries that will contain more advanced language-specific helper functions. @nage is starting with indy-sdk-python (maintainer: @TelegramSam ). We are looking for maintainers who want to own repositories like indy-sdk-go and indy-sdk-dotnet. We also want to know if we should have an indy-sdk-ios, or separate repositories for indy-sdk-swift and indy-sdk-objectivec. Thoughts?

nage (Wed, 17 Apr 2019 21:43:46 GMT):
I like the idea of indy-sdk-ios to house both

nage (Wed, 17 Apr 2019 21:44:07 GMT):
just like scala and java could conceivably co-exist in one repo

kdenhartog (Thu, 18 Apr 2019 01:31:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=YoA8a4rif9JjzL4Sg) @wangdong Use XCode 10.0 MacOS updated to XCode 10.2 which changed the Swift compiler to 5.0 which is incompatible with the way the Obj-C is built right now.

wangdong (Thu, 18 Apr 2019 01:32:30 GMT):
yes, I have found t that.

wangdong (Thu, 18 Apr 2019 01:32:31 GMT):
thanks

wangdong (Thu, 18 Apr 2019 01:33:09 GMT):
It is the imcompatible issue.

kdenhartog (Thu, 18 Apr 2019 01:34:02 GMT):
Good to know it's a common issue. I thought it may have been a local env problem, but this helps me confirm what I originally thought. I'll get a ticket submitted to get the code updated to swift 5 compatibility.

wangdong (Thu, 18 Apr 2019 01:35:44 GMT):
So when to compile indy-sdk from latest version, like master, the lates xcode will be required.

wangdong (Thu, 18 Apr 2019 01:35:44 GMT):
So when to compile indy-sdk from latest version, like master, the latest xcode will be required.

kdenhartog (Thu, 18 Apr 2019 01:40:58 GMT):
Once it's updated then yes, that should be how it would work. However, right now I don't believe that would help. I didn't try it though, so if you do please let me know what the results are.

wangdong (Thu, 18 Apr 2019 01:49:24 GMT):
sure, if any info I will let you know.

tplooker (Thu, 18 Apr 2019 03:25:38 GMT):
@danielhardman @TelegramSam @swcurran and any others who were interesting in the discussion around the url encoded message format, here is the beginning of the thinking in a doc feel free to edit https://hackmd.io/jeUpzo4CTOCXQjNw32OmiA?view

tplooker (Thu, 18 Apr 2019 03:25:38 GMT):
@danielhardman @TelegramSam @swcurran and any others who were interested in the discussion around the url encoded message format, here is the beginning of the thinking in a doc feel free to edit https://hackmd.io/jeUpzo4CTOCXQjNw32OmiA?view

abdfaye (Thu, 18 Apr 2019 09:38:04 GMT):
Hello, is indy-sdk supports multi-signature NYM transactions to create a unique identity controlled by multiple entities?

rwadhwa (Thu, 18 Apr 2019 09:56:30 GMT):
Has joined the channel.

izashkalov (Thu, 18 Apr 2019 10:03:03 GMT):
Hello everyone! Can you help me with bug https://jira.hyperledger.org/browse/IS-1228 ?

sklump (Thu, 18 Apr 2019 13:06:57 GMT):
Hello, I've submitted JIRA 1242 for indy-sdk (https://jira.hyperledger.org/browse/IS-1242), linking to a PR submitted against indy-sdk master. It plumbs in credential deletion for prover wallets, and extends python, rust, and Java wrappers accordingly, plus unit tests for python and Java. I notice there are no anoncreds unit tests yet for rust, and that may be by design because the tests are already present in the libindy source code itself? In any case, I'm too out of my depth to take a stab at ios, dotnet, and javascript wrappers and unit tests.

sklump (Thu, 18 Apr 2019 14:08:53 GMT):
_OK there is still some drama with Java unit tests: as long as this line is here, it's still failing in CI and I am throwing code at the machine_

sklump (Thu, 18 Apr 2019 14:08:53 GMT):
_OK there is still some drama with Java wrapper tests: as long as this line is here, it's still failing in CI and I am throwing code at the machine_

esplinr (Thu, 18 Apr 2019 14:46:02 GMT):
@abdfaye Not yet.

esplinr (Thu, 18 Apr 2019 14:46:52 GMT):
Cool stuff @sklump . Thanks for doing that!

sklump (Thu, 18 Apr 2019 14:50:46 GMT):
@esplinr it's enlightened self interest. At present it fails some python non_secrets tests in test_delete_wallet_record_tags.py - but I see that the master also fails them. I'm going to ~call that acceptable for the moment and move on~ fix these and include them. It appears that `tag1` should be `~tag1` in `common.py`.

sklump (Thu, 18 Apr 2019 14:50:46 GMT):
@esplinr it's enlightened self interest. At present it fails some python `non_secrets` unit tests - but I see that the master also fails them. I'm going to ~call that acceptable for the moment and move on~ fix these and include them. It appears that `tag1` became `~tag1` in `common.py` somewhere along the line, and some unit tests needed the corresponding tweak.

JamesCarter (Thu, 18 Apr 2019 19:32:22 GMT):
Hello, when trying to create a revokable credential, I am calling: Anoncreds.issuerCreateCredential(....) and using the result of that to build up a Ledger.buildRevocRegEntryRequest and submitting it. But I keep getting a failure on submit like: ``` {"identifier":"B1ay2En4QtwMBcxGvQQJG3","reason":"client request invalid: InvalidClientRequest(\"Got 'prevAccum': 21 1180FB9E4F4D815CC3B9D4A11EFFC701E10507D3A06506A9355B3C34C9AF0EC7A 21 117D40853B47F5D4D4761487211558303E0D070DA4AA89C86F97934EF7EAEE7FD 6 7EE313630CAA1716E4EF72D968941C9B955C872517A4E304D0121D5273A3317E 4 141A82BA7ADF34DBBCB96F758B773981626C3EDAF8D33C83B8A121DD32415DDD 6 7E7C4F0416CD847BF1B2B0A8520832CC19EE9D68CB892470A94B731264AF9D70 4 1F6E3E3DF937BE1D07D6D02E9E0478F4E74A8AC6C458DEFF7F52804129F9A0A0 but there is no previous REVOC_REG_ENTRY\",)","op":"REJECT","reqId":1555613577820309000} ``` The initialization of the revocation registry goes fine, and I submit a first entry to it without issue. Has anyone come across this before?

JamesCarter (Thu, 18 Apr 2019 19:32:22 GMT):
Hello, when trying to create a revokable credential, I am calling: Anoncreds.issuerCreateCredential(....) and using the result of that to build up a Ledger.buildRevocRegEntryRequest and submitting it. But I keep getting a failure on submit like: ``` {"identifier":"B1ay2En4QtwMBcxGvQQJG3","reason":"client request invalid: InvalidClientRequest(\"Got 'prevAccum': 21 1180FB9E4F4D815CC3B9D4A11EFFC701E10507D3A06506A9355B3C34C9AF0EC7A 21 117D40853B47F5D4D4761487211558303E0D070DA4AA89C86F97934EF7EAEE7FD 6 7EE313630CAA1716E4EF72D968941C9B955C872517A4E304D0121D5273A3317E 4 141A82BA7ADF34DBBCB96F758B773981626C3EDAF8D33C83B8A121DD32415DDD 6 7E7C4F0416CD847BF1B2B0A8520832CC19EE9D68CB892470A94B731264AF9D70 4 1F6E3E3DF937BE1D07D6D02E9E0478F4E74A8AC6C458DEFF7F52804129F9A0A0 but there is no previous REVOC_REG_ENTRY\",)","op":"REJECT","reqId":1555613577820309000} ``` The initialization of the revocation registry goes fine, and I submit an initial entry to it right away without issue. Has anyone come across this before?

rangak (Thu, 18 Apr 2019 23:10:00 GMT):
Has joined the channel.

pimotte (Fri, 19 Apr 2019 07:22:32 GMT):
The maven repository hosting the java wrapper seems to be down, does anyone know what's going on? (https://jira.hyperledger.org/projects/IS/issues/IS-1244)

pimotte (Fri, 19 Apr 2019 08:24:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=5m5sWZqxXMh7MaWmQ) @esplinr We've written a relatively thick java library, which in scope falls somewhere between the java wrapper and libvcx, if anyone is picking up indy-sdk-java, feel free to adopt it and/or draw inspiration from it: https://github.com/Quintor/quindy

esplinr (Fri, 19 Apr 2019 14:46:39 GMT):
@pimotte We're looking into the problem with repo.sovrin.org

esplinr (Fri, 19 Apr 2019 14:46:43 GMT):
Thank you for reporting it.

izashkalov (Fri, 19 Apr 2019 15:55:33 GMT):
Hello everyone! Can you check link https://repo.evernym.com/artifactory/libindy-maven-local/org/hyperledger/indy/ ? I can not download prebuild indy.jar (

rchristman (Fri, 19 Apr 2019 16:49:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=9wb93cNFh7jxeLg6R) @esplinr thanks

esplinr (Fri, 19 Apr 2019 18:32:29 GMT):
@izashkalov We are aware and working on fixing it.

esplinr (Fri, 19 Apr 2019 18:41:50 GMT):
It should be resolved now.

izashkalov (Fri, 19 Apr 2019 19:18:30 GMT):
@esplinr i checked, but now it does not work (

esplinr (Fri, 19 Apr 2019 19:52:08 GMT):
^^ @SteveGoob

SteveGoob (Fri, 19 Apr 2019 19:57:57 GMT):
@izashkalov This resource (https://repo.evernym.com/artifactory/libindy-maven-local/org/hyperledger/indy/) is in an evernym repo and is not associated with the outage repo.sovrin.org had earlier. I think @esplinr may have accidentally gotten the two issues confused

SteveGoob (Fri, 19 Apr 2019 19:58:57 GMT):
@FelippeBurk, is this ^^ something you can fix?

FelippeBurk (Fri, 19 Apr 2019 19:58:57 GMT):
Has joined the channel.

esplinr (Fri, 19 Apr 2019 20:27:43 GMT):
Sorry, I did.

esplinr (Fri, 19 Apr 2019 20:27:43 GMT):
Sorry, I did confuse the two issues.

esplinr (Fri, 19 Apr 2019 20:28:58 GMT):
@rchristman Where did you get that URL? Evernym no longer hosts the Indy artifacts, as Sovrin picked them up. We do host builds with specific configurations for some of our customers. If you are one of those customers, you should contact Evernym Customer Success.

magicindustries (Sun, 21 Apr 2019 01:34:24 GMT):
What is the CommandHandle in libindy? I can see how it gets passed around and that it's an i32 but I'm not clear on what it's for or what it should be set to when invoking indy_create_pool_ledger_config for example

magicindustries (Sun, 21 Apr 2019 01:36:42 GMT):
is it just used so there's a single callback delegate from the caller and command handle is how you know where it started?

magicindustries (Sun, 21 Apr 2019 02:42:27 GMT):
In creating an error handler, i'd like to be able to lookup the full text error message from libindy rather than replicate them in my wrapper. Is there a built in way to do this that's exposed? My rust noob level isn't helping me heere

izashkalov (Mon, 22 Apr 2019 07:12:37 GMT):
Hello @esplinr! Can you check bug https://jira.hyperledger.org/browse/IS-1228 and tell me what am I doing wrong?

PatrikStas (Mon, 22 Apr 2019 18:33:15 GMT):
New easter features for indyscan.io - Transaction filtering by transaction type - Transactions JSONs field names are canonically sorted - Already older feature - but note that you can move between transactions using arrow keys - Refactored repo now includes indyscan http api client module, but I definitely don't consider it stable yet Here's an example of filtering https://indyscan.io/txs/SOVRIN_TESTNET/domain?page=1&pageSize=50&filterTxNames=["SCHEMA","CLAIM_DEF"] Aiming to add fulltext search and websocket notifications within next 2 months

mgbailey (Mon, 22 Apr 2019 20:19:14 GMT):
@PatrikStas Nice to see these improvements! I really appreciate your contributions to the community. I have one request for you to consider, and that is to add the newest network member of the Sovrin community: the BuilderNet. It's genesis file is at https://raw.githubusercontent.com/sovrin-foundation/sovrin/master/sovrin/pool_transactions_builder_genesis

mgbailey (Mon, 22 Apr 2019 20:20:26 GMT):
As an FYI, the network previously known as TestNet has been rebranded as StagingNet. It's not my choice; I am just the messenger.

PatrikStas (Mon, 22 Apr 2019 20:24:02 GMT):
@mgbailey thanks for heads up! I'll add the new network and rename TestNet to StagingNet through out this week

izashkalov (Tue, 23 Apr 2019 09:53:32 GMT):
Hello everyone. I try execute command "sudo bash android.build.sh -d arm64" on Mac and receive error: ignoring file /tmp/android_build/libzmq_arm64/lib/libzmq.so, file was built for unsupported file format ( 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ) which is not the architecture being linked (x86_64): /tmp/android_build/libzmq_arm64/lib/libzmq.so Undefined symbols for architecture x86_64: "_zmq_has", referenced from: build_script_build::main::he3c5e86fa4c4da09 in build_script_build-d7507fff860bdbd1.build_script_build.1ltjktvo-cgu.10.rcgu.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Can you help me with this problem?

sklump (Tue, 23 Apr 2019 10:44:01 GMT):
*Item: Flexible Credential Tagging* _Issue:_ Massively sShared wallets such as

sklump (Tue, 23 Apr 2019 10:44:01 GMT):
*Item: Flexible Credential Attribute Tagging* _Issue:_ Massively shared wallets such as org-books have millions of credentials, which can present a heavy load. _Mitigation:_ It would be desirable to be able to set tags for only attribute values of interest, for searching. Approach #1: * mark each attribute as searchable or not in the cred def on STORE-CRED-DEF operation * to prover wallet, write non-secret `indy_cred_def_tag_policy` record mapping cred def id to searchable attributes * consult policy record on credential storage and include only attribute tags to match --> requires at least a new parameter to prover STORE-CRED-DEF operation, or worse, change to CRED DEF data structure --> does not allow updates to attribute tag policy if requirements change Approach #2: * on every STORE-CRED operation, take parameter marking each attribute as searchable or not --> requires at least a new parameter to prover STORE-CRED operation --> makes for unknowable attribute tagging regime, blunting utility of WQL search and possibly unlocatable dark credentials Approach #3: * new prover SET-ATTR-TAG-POLICY operation writes a non-secret policy record as above, marking searchable attributes by cred def id - taking searchable attributes (sensible defaults or sentinels for NONE or ALL) - taking WQL to rewrite tags of interest on existing credentials, allowing compliance on old credentials to new policy updates (sensible defaults/sentinels for NONE or ALL) --> can retain existing familiar data structures and API signatures for storage calls; one new method encapsulates all new functionality. *My Opinion:* Approach #3 provides the most powerful tools on the most manageable API encapsulation. I'm going to start looking into how this might be done and packaged as a PR.

sklump (Tue, 23 Apr 2019 10:44:01 GMT):
*Item: Flexible Credential Attribute Tagging* _Issue:_ Massively shared wallets such as org-books have millions of credentials, which can present a heavy load. _Mitigation:_ It would be desirable to be able to set tags for only attribute values of interest to a known WQL search profile. Approach #1: * mark each attribute as searchable or not in the cred def on STORE-CRED-DEF operation * to prover wallet, write non-secret `indy_cred_def_tag_policy` record mapping cred def id to searchable attributes * consult policy record on credential storage and include only attribute tags to match --> requires at least a new parameter to prover STORE-CRED-DEF operation, or worse, change to CRED DEF data structure --> does not allow updates to attribute tag policy if requirements change Approach #2: * on every STORE-CRED operation, take parameter marking each attribute as searchable or not --> requires at least a new parameter to prover STORE-CRED operation --> makes for unknowable attribute tagging regime, blunting utility of WQL search and possibly unlocatable dark credentials Approach #3: * new prover SET-ATTR-TAG-POLICY operation writes a non-secret policy record as above, marking searchable attributes by cred def id - taking searchable attributes (sensible defaults or sentinels for NONE or ALL) - taking WQL to rewrite tags of interest on existing credentials, allowing compliance on old credentials to new policy updates (sensible defaults/sentinels for NONE or ALL) --> can retain existing familiar data structures and API signatures for storage calls; one new method encapsulates all new functionality. *My Opinion:* Approach #3 provides the most powerful tools on the most manageable API encapsulation. I'm going to start looking into how this might be done and packaged as a PR.

sklump (Tue, 23 Apr 2019 10:44:01 GMT):
*Item: Flexible Credential Attribute Tagging* _Issue:_ Massively shared wallets such as org-books have millions of credentials, which can present a heavy load. _Mitigation:_ It would be desirable to be able to set tags for only attribute values of interest to a known WQL search profile. Approach #1: * mark each attribute as searchable or not in the cred def on STORE-CRED-DEF operation * to prover wallet, write non-secret `indy_cred_def_tag_policy` record mapping cred def id to searchable attributes * consult policy record on credential storage and include only attribute tags to match --> requires at least a new parameter to prover STORE-CRED-DEF operation, or worse, change to CRED DEF data structure --> does not allow updates to attribute tag policy if requirements change: would need a new cred def version at least Approach #2: * on every STORE-CRED operation, take parameter marking each attribute as searchable or not --> requires at least a new parameter to prover STORE-CRED operation --> makes for unknowable attribute tagging regime, blunting utility of WQL search and possibly unlocatable dark credentials Approach #3: * new prover SET-ATTR-TAG-POLICY operation writes a non-secret policy record as above, marking searchable attributes by cred def id - taking searchable attributes (sensible defaults or sentinels for NONE or ALL) - taking WQL to rewrite tags of interest on existing credentials, allowing compliance on old credentials to new policy updates (sensible defaults/sentinels for NONE or ALL) --> can retain existing familiar data structures and API signatures for storage calls; one new method encapsulates all new functionality. *My Opinion:* Approach #3 provides the most powerful tools on the most manageable API encapsulation. I'm going to start looking into how this might be done and packaged as a PR.

sklump (Tue, 23 Apr 2019 10:44:01 GMT):
*Item: Flexible Credential Attribute Tagging* _Issue:_ Massively shared wallets such as org-books have millions of credentials, which can present a heavy load. _Mitigation:_ It would be desirable to be able to set tags for only attribute values of interest to a known WQL search profile. Approach #1: * mark each attribute as searchable or not in the cred def on STORE-CRED-DEF operation * to prover wallet, write non-secret `indy_cred_def_tag_policy` record mapping cred def id to searchable attributes * consult policy record on credential storage and include only attribute tags to match --> requires at least a new parameter to prover STORE-CRED-DEF operation, or worse, change to CRED DEF data structure --> does not allow updates to attribute tag policy if requirements change: would need a new cred def version at least Approach #2: * on every STORE-CRED operation, take parameter marking each attribute as searchable or not --> requires at least a new parameter to prover STORE-CRED operation --> makes for unknowable attribute tagging regime, blunting utility of WQL search and possibly unlocatable dark credentials Approach #3: * new prover SET-ATTR-TAG-POLICY operation writes a non-secret policy record as above, marking searchable attributes by cred def id - taking searchable attributes (sensible defaults or sentinels for NONE or ALL) - taking WQL to rewrite tags of interest on existing credentials matching query, allowing compliance on old credentials to new policy updates (sensible defaults/sentinels for NONE or ALL) --> can retain existing familiar data structures and API signatures for storage calls; one new method encapsulates all new functionality. *My Opinion:* Approach #3 provides the most powerful tools on the most manageable API encapsulation. I'm going to start looking into how this might be done and packaged as a PR.

sklump (Tue, 23 Apr 2019 10:44:01 GMT):
*Item: Flexible Credential Attribute Tagging* _Issue:_ Massively shared wallets such as org-books have millions of credentials, which can present a heavy load. _Mitigation:_ It would be desirable to be able to set tags for only attribute values of interest to a known WQL search profile. Approach #1: * on every STORE-CRED operation, take parameter marking each attribute as searchable or not --> requires at least a new parameter to prover STORE-CRED operation --> makes for unknowable attribute tagging regime, blunting utility of WQL search and possibly unlocatable dark credentials Approach #2: * new prover SET-ATTR-TAG-POLICY operation writes a non-secret policy record as above, marking searchable attributes by cred def id - taking searchable attributes (sensible defaults or sentinels for NONE or ALL) - taking WQL to rewrite tags of interest on existing credentials matching query, allowing compliance on old credentials to new policy updates (sensible defaults/sentinels for NONE or ALL) --> can retain existing familiar data structures and API signatures for storage calls; one new method encapsulates all new functionality. *My Opinion:* Approach #2 provides more powerful tools on more manageable API encapsulation. Are there other promising design options available here for such a feature?

sklump (Tue, 23 Apr 2019 10:44:01 GMT):
*Item: Flexible Credential Attribute Tagging* _Issue:_ Massively shared wallets such as org-books have millions of credentials, which can present a heavy load. _Mitigation:_ It would be desirable to be able to set tags for only attribute values of interest to a known WQL search profile. Approach #1: * on every STORE-CREDENTIAL operation, take parameter marking each attribute as searchable or not --> requires at least a new parameter to prover STORE-CREDENTIAL operation --> makes for unknowable attribute tagging regime, blunting utility of WQL search and possibly unlocatable dark credentials Approach #2: * new prover SET-CRED-ATTR-TAG-POLICY operation writes a non-secret policy record as above, marking searchable attributes by cred def id - taking searchable attributes (sensible defaults or sentinels for NONE or ALL) - taking WQL to rewrite tags of interest on existing credentials matching query, allowing compliance on old credentials to new policy updates (sensible defaults/sentinels for NONE or ALL) --> can retain existing familiar data structures and API signatures for storage calls; one new method encapsulates all new functionality. *My Opinion:* Approach #2 provides more powerful tools on more manageable API encapsulation. Are there other promising design options available here for such a feature?

sklump (Tue, 23 Apr 2019 10:44:01 GMT):
*Item: Flexible Credential Attribute Tagging* _Issue:_ Massively shared wallets such as org-books have millions of credentials, which can present a heavy load. _Mitigation:_ It would be desirable to be able to set tags for only attribute values of interest to a known WQL search profile. Approach #1: * on every STORE-CREDENTIAL operation, take parameter marking each attribute as searchable or not --> requires at least a new parameter to prover STORE-CREDENTIAL operation --> makes for unknowable attribute tagging regime or unmanageable adhocracy, blunting utility of WQL search and possibly unlocatable dark credentials Approach #2: * new prover SET-CRED-ATTR-TAG-POLICY operation writes a non-secret policy record as above, marking searchable attributes by cred def id - taking searchable attributes (sensible defaults or sentinels for NONE or ALL) - taking WQL to rewrite tags of interest on existing credentials matching query, allowing compliance on old credentials to new policy updates (sensible defaults/sentinels for NONE or ALL) * corresponding GET-CRED-ATTR-TAG-POLICY operation could retrieve current policy's tags of search interest for input cred def id (or could expose via non-secrets and know-how _could save a method but that seems batteries-not-included to me_) --> can retain existing familiar data structures and API signatures for storage calls; 2 relatively simple new methods encapsulate all new functionality. *My Opinion:* Approach #2 provides more powerful tools on more manageable API encapsulation. Are there other promising design options available here for such a feature?

sklump (Tue, 23 Apr 2019 10:44:01 GMT):
*Item: Flexible Credential Attribute Tagging* _Issue:_ Massively shared wallets such as org-books have millions of credentials, which can present a heavy load. _Mitigation:_ It would be desirable to be able to set tags for only attribute values of interest to a known WQL search profile. Approach #1: * on every STORE-CREDENTIAL operation, take parameter marking each attribute as searchable or not --> requires at least a new parameter to prover STORE-CREDENTIAL operation --> makes for unknowable attribute tagging regime or unmanageable adhocracy, blunting utility of WQL search and possibly unlocatable dark credentials Approach #2: * new prover SET-CRED-ATTR-TAG-POLICY operation writes a non-secret policy record as above, marking searchable attributes by cred def id - taking searchable attributes (sensible defaults or sentinels for NONE or ALL) - taking WQL to rewrite tags of interest on existing credentials matching query, allowing compliance on old credentials to new policy updates (sensible defaults/sentinels for NONE or ALL) * corresponding GET-CRED-ATTR-TAG-POLICY operation could retrieve current policy's tags of search interest for input cred def id (or could expose via non-secrets and know-how _which could save a method but that seems like a batteries-not-included culture to me_) --> can retain existing familiar data structures and API signatures for storage calls; 2 relatively simple new methods encapsulate all new functionality. *My Opinion:* Approach #2 provides more powerful tools on more manageable API encapsulation. Are there other promising design options available here for such a feature?

ianco (Tue, 23 Apr 2019 13:59:14 GMT):
@sklump your approach #2 is very elegant

ianco (Tue, 23 Apr 2019 13:59:24 GMT):
no changes required to the api

sklump (Tue, 23 Apr 2019 14:01:45 GMT):
... well, no changes to existing methods; probably 2 new API calls and a new indy non-secrets record type

ianco (Tue, 23 Apr 2019 14:01:50 GMT):
I think it's a "holder" policy though, no?

sklump (Tue, 23 Apr 2019 14:02:06 GMT):
w3c holder, indy prover: same thing

sklump (Tue, 23 Apr 2019 14:02:06 GMT):
w3c holder, indy prover: same thing *

sklump (Tue, 23 Apr 2019 14:02:47 GMT):
hence von-anchor 'holder-prover' frankenstein term

sklump (Tue, 23 Apr 2019 14:02:47 GMT):
hence von-anchor 'holder-prover' frankenstein term _ \* although, academically speaking, they need not be: a holder could submit credentials to a prover entity with the same wallet access to generate proof -- but so far we deal with these entities condensed into one _

sklump (Tue, 23 Apr 2019 14:02:47 GMT):
hence von-anchor 'holder-prover' frankenstein term _ * although, academically speaking, they need not be: a holder could submit credentials to a prover entity with the same wallet access to generate proof -- but so far we deal with these entities condensed into one _

abdfaye (Tue, 23 Apr 2019 16:09:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Dkho4PemJiZWScgPy) @esplinr Thanks for replying @esplinr. Just to be sure, is this feature not available on the Ledger side or just on the SDK? What happens if I send a multi-signed NYM txn to the ledger?

esplinr (Tue, 23 Apr 2019 16:20:08 GMT):
The SDK API supports multi-signature, but it is currently cumbersome to do multi-signature through the CLI.

esplinr (Tue, 23 Apr 2019 16:20:46 GMT):
In Indy Node 1.6 (the current stable release), the ledger only requires a single signature for a nym transaction. If you send it a multi-signature, I don't know if it will get accepted (because it has the minimum number of signatures) or rejected (because it has the wrong number of signatures).

esplinr (Tue, 23 Apr 2019 16:21:26 GMT):
In Indy Node 1.7 (currently master, until next week's release), you can configure the ledger to require multiple signatures for nym transactions.

ivanpagac (Wed, 24 Apr 2019 05:47:15 GMT):
Hi community! Can you give us a clue what could be wrong when the issuer issues the credentials and a prover wants to store them but we received failure q != q'? Issues is JS and prover is iOS, both versions are 1.8.2. Just a clue, thanks in adnvance.

ivanpagac (Wed, 24 Apr 2019 05:47:15 GMT):
Hi community! Can you give us a clue what could be wrong when the issuer issues the credentials and a prover wants to store them but we received failure q != q'? Issuer is JS and prover is iOS, both versions are 1.8.2. Just a clue, thanks in advance.

abdfaye (Wed, 24 Apr 2019 09:14:53 GMT):
@esplinr It's clear now ! Thank you !

lreinink (Wed, 24 Apr 2019 09:15:19 GMT):
Hi. I would like to create a Chrome extension using Indy SDK. Can someone help me find the best way to approach this? I've tried using the NodeJS wrapper using Browserify but that does not seem to work.

cobear25 (Wed, 24 Apr 2019 14:44:25 GMT):
Hi there, I'm working on an iOS project and just now noticed that the `libindy.a` framework doesn't have bitcode enabled. Is there a way to change that when I build, or do all apps using IndySDK require disabling bitcode?

esplinr (Wed, 24 Apr 2019 15:29:55 GMT):
@abdfaye I checked, and if a transaction with excess signatures is submitted to the ledger, it will be accepted because it meets the minimum signature requirement.

swcurran (Wed, 24 Apr 2019 16:33:08 GMT):
@sklump - I like the 2nd solution better as well. No impact on clients that don't care about the tagging being done, but gives flexibility to those that want the control. Nice!

esplinr (Wed, 24 Apr 2019 19:35:49 GMT):
@nage During the Indy SDK call this morning, we agreed it is time to create the following repos: indy-sdk-python: Sam Curren -- DONE indy-sdk-ruby: John Callahan (johncallahan) indy-sdk-go: need a maintainer indy-sdk-ios: Norm Jarvis (nsivraj) indy-sdk-java: Thomas Shelton (twshelton) indy-sdk-android: need a maintainer indy-sdk-dotnet: need a maintainer (nudge @tomislav ) Can you help us with this?

esplinr (Wed, 24 Apr 2019 19:36:33 GMT):
Or is there a better process we should follow for getting it done?

tplooker (Wed, 24 Apr 2019 19:55:37 GMT):
@esplinr what will these sdks contain? A wrapper or more like what we have done with agentframework

nage (Wed, 24 Apr 2019 19:57:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=c49Ng84ab7nPkGwTj) @esplinr Ack.

nage (Wed, 24 Apr 2019 19:58:26 GMT):
I can help request repositories for the items there that already have code and a maintainer

nage (Wed, 24 Apr 2019 19:58:56 GMT):
If they don't have a current code base it might be best to get that started in hyperledger-labs first

esplinr (Wed, 24 Apr 2019 21:31:43 GMT):
@nage There is code for all of these repos. You could list me as the maintainer until we find a better one. They can be in Hyperledger Labs if that is better. We just need a home for the code that we are rejecting from indy-sdk.

esplinr (Wed, 24 Apr 2019 21:32:32 GMT):
@tplooker These will be the "fat" idiomatic language libraries, which will allow us to keep only the "thin" language bindings in the core Indy SDK repo (minimum sufficient for CI / CD, and probably auto-generated).

tech9beta (Thu, 25 Apr 2019 09:08:34 GMT):
Has joined the channel.

sklump (Thu, 25 Apr 2019 10:40:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=598uPfpvCPmZ5z8vr) ... as it turns out, the design direction assumes too much. Since attribute tags are stored encrypted, WQL is blunted to exact equality/inequality search. Hence, feasible searches to pick credentials amount to not much finer grain than match-all or match-none, for much more complexity on the API than a straight boolean. My current approach (say #2.1) then is going to be a retroactivity boolean (default True?) parameter on the set-policy call, to (True) reset all existing credentials on the cred def id to match incoming policy or (False) leave them as-is.

sklump (Thu, 25 Apr 2019 10:40:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=598uPfpvCPmZ5z8vr) ... as it turns out, the design direction assumes too much. Since attribute tags are stored encrypted, WQL is blunted to exact equality/inequality search. Hence, feasible searches to pick credentials amount to not much finer grain than match-all or match-none, for much more complexity on the API than a straight boolean. *Re: credential attribute tag policy* My current approach (say #2.1) then is going to be a retroactivity boolean (default True?) parameter on the set-policy call, to (True) reset all existing credentials on the cred def id to match incoming policy or (False) leave them as-is.

sklump (Thu, 25 Apr 2019 10:40:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=598uPfpvCPmZ5z8vr) *Re: credential attribute tag policy* ... as it turns out, the design direction assumes too much. Since attribute tags are stored encrypted, WQL is blunted to exact equality/inequality search. Hence, feasible searches to pick credentials amount to not much finer grain than match-all or match-none, for much more complexity on the API than a straight boolean. My current approach (say #2.1) then is going to be a retroactivity boolean (default True?) parameter on the set-policy call, to (True) reset all existing credentials on the cred def id to match incoming policy or (False) leave them as-is.

twshelton (Thu, 25 Apr 2019 12:16:20 GMT):
Has joined the channel.

abdfaye (Thu, 25 Apr 2019 15:30:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=A7R3AB6J6cQiyMGhz) @esplinr Thanks ! That's what I also noticed. Tried it also for a CRED_DEF txn and still accepted. Isn't it the credential definition is supposed to be somehow linked to the issuer so that he is the only one capable of issuing credentials from it?

abdfaye (Thu, 25 Apr 2019 15:36:21 GMT):
If so how it is linked? Only with the DID of the sender or the Signers of the CRED_DEF txn?

abdfaye (Thu, 25 Apr 2019 15:36:21 GMT):
So the issuer DID is not currently part of the proof verification process?

esplinr (Thu, 25 Apr 2019 15:38:53 GMT):
No. The intention is that anyone can reuse a credential definition. That will make interoperability easier.

esplinr (Thu, 25 Apr 2019 15:39:54 GMT):
There is a proposal to add "proof presentations" to the ledger that will indicate to the verifier who are reliable issuers of a credential. But it is always up to verifiers to decide what to accept for their specific use case.

abdfaye (Thu, 25 Apr 2019 15:43:24 GMT):
So the issuer DID is not currently part of the proof verification process?

esplinr (Thu, 25 Apr 2019 15:43:52 GMT):
The issuer DID is not always the same as the DID of the person who wrote the credential def or the credential schema to the ledger.

abdfaye (Thu, 25 Apr 2019 15:46:49 GMT):
OK I understood that it was the case for the schema but not for the credential definition.

esplinr (Thu, 25 Apr 2019 15:47:24 GMT):
I'm sometimes wrong on the details.

abdfaye (Thu, 25 Apr 2019 15:52:59 GMT):
I actually went through the code and couldn't find any link. So I guess your are right...or maybe I am missing something...

swcurran (Thu, 25 Apr 2019 16:04:53 GMT):
The Cred Def must include the issuer's DID, and that is used by the verifier to determine who issued the credential - what DID. What the verifier does with that is up to them.

swcurran (Thu, 25 Apr 2019 16:05:47 GMT):
The Cred Def also relates the schema used for the credential and the revocation registry such that the "Proof of non-revocation" that the prover provides can be verified.

esplinr (Thu, 25 Apr 2019 16:33:59 GMT):
Yes, what @swcurran said is right. I was confusing things.

tomislav (Fri, 26 Apr 2019 13:21:42 GMT):
@esplinr I'd be happy to maintain the dotnet sdk repo

tomislav (Fri, 26 Apr 2019 15:14:52 GMT):
I'm trying to build indy-cli on Mac. Any thoughts what could be causing this? ``` = note: Undefined symbols for architecture x86_64: "_indy_build_get_auth_rule_request", referenced from: indyrs::ledger::_build_get_auth_rule_request::hc22b88ac03df2dda in libindyrs-c3fc06584799e70f.rlib(indyrs-c3fc06584799e70f.1joglt67xwguuo58.rcgu.o) "_indy_build_auth_rule_request", referenced from: indyrs::ledger::_build_auth_rule_request::h11209ad3170efeda in libindyrs-c3fc06584799e70f.rlib(indyrs-c3fc06584799e70f.1joglt67xwguuo58.rcgu.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ```

ianco (Fri, 26 Apr 2019 15:55:04 GMT):
@tomislav do you have all the latest code? maybe you are pointing at an old version of libindy

tomislav (Fri, 26 Apr 2019 16:59:16 GMT):
I may have a slightly older version installed. I'll try compiling a newer one first. Thanks for the tip.

tomislav (Fri, 26 Apr 2019 17:10:07 GMT):
It worked. Thanks @ianco

ianco (Fri, 26 Apr 2019 17:10:28 GMT):
:+1:

esplinr (Sat, 27 Apr 2019 15:58:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=B2GTCGuunx7AZedGx) @tomislav Yay! Thank you for "volunteering" @tomislav . cc @nage

Koptan (Sun, 28 Apr 2019 13:45:18 GMT):
Has joined the channel.

Koptan (Sun, 28 Apr 2019 13:45:35 GMT):
hello everyone .... i have 2 question , hope to find the answers here : 1- How to restore my wallet ? , do we have nomemic word like ethereum wallet ? 2- Do we have browser wallet in Indy-sdk ?

lreinink (Sun, 28 Apr 2019 13:46:54 GMT):
Hi, could someone explain to me how self-issuance would work? It was mentioned in one of Kyle's presentations and I have some questions. First of all, since a regular person is not a trust anchor, how can they issue a credential? And second, does a schema need to be published for this?

AxelNennker (Sun, 28 Apr 2019 18:40:34 GMT):
indy-sdk-android has the same source as indy-sdk-java plus some build scripts, right?

kdenhartog (Sun, 28 Apr 2019 22:46:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=bNm8HyjTC7AL9DFFj) @lreinink Self issued credentials can be created in a few different ways. Because it's self-issued, the provenance of the data a ledger is not necessary in order to "prove" the legitimacy of the data. As long as the verifier trusts enough that they're speaking to me then they can just get the data directly from me through a message sent over the wire message format. For example, if I ordered a package and they're asking for my address, the shipper wouldn't care what I provide because they already got paid. However, if they're shipping alcohol they may want proof that I'm over 21 using a DOT signed credential, but still may not care which address I want to ship it to and would be fine if I just told them it.

kdenhartog (Sun, 28 Apr 2019 22:49:12 GMT):
In the sense of self issued credential data, it's possible to do this today and I don't believe that I would need to sign a cred_def in order to provide the data. I'll have to dig into the SDK APIs to verify this.

SergeyBrazhnik (Mon, 29 Apr 2019 08:04:34 GMT):
Hello everyone. Is it any api in indy wallet to remove pairwise/did/claim?

SergeyBrazhnik (Mon, 29 Apr 2019 08:08:05 GMT):
Is it possible to remove claim from wallet by outCredId using deleteWalletRecord API ?

raj_shekhar (Mon, 29 Apr 2019 08:59:26 GMT):
Has joined the channel.

sklump (Mon, 29 Apr 2019 12:22:53 GMT):
@SergeyBrazhnik https://github.com/hyperledger/indy-sdk/pull/1588

sklump (Mon, 29 Apr 2019 12:22:53 GMT):
@SergeyBrazhnik https://github.com/hyperledger/indy-sdk/pull/1588 At present I have a PR in to expose credential deletion. The pairwise API does not include deletion, but an overhaul of pairwise DID treatment is coming pretty soon as I understand. VON anchor (among others) uses non_secrets to store pairwise relations because non_secrets has an API call for deletion. There is value to having a pairwise API to front non-secret storage of pairwise DIDs, to foster uniformity between agent software, and I expect to track libindy pairwise as it develops.

stefanopulzeic (Mon, 29 Apr 2019 12:54:00 GMT):
Ledger merkle tree is not acceptable for current tree.

SergeyBrazhnik (Mon, 29 Apr 2019 13:14:58 GMT):
@sklump Thanks for answer. Got it

SergeyBrazhnik (Mon, 29 Apr 2019 13:16:18 GMT):
Can anybody provide fresh actual document how to write indy-agent correctly? AFAIK the most actuals is this https://github.com/hyperledger/indy-agent/tree/master/docs/source

stefanopulzeic (Mon, 29 Apr 2019 13:44:40 GMT):
I'm tring to use libindy on macOS. I builded the library following the instruction on the official site. When I run my test they fail and the log said: "Ledger merkle tree is not acceptable for current tree." The same tests works fine on Ubuntu. I use the latest stable version of indy-node and indy-sdk Any suggestions?

JorgeDiaz3 (Mon, 29 Apr 2019 14:47:48 GMT):
Has joined the channel.

JorgeDiaz3 (Mon, 29 Apr 2019 14:50:57 GMT):
Hi I;m working with Indy for android, I was testing the Did creation and after a while I got an exception with the message "The anoncreds accumulator is full." I am not familiar with this accumulator concept, could someone point me out to some resources to solve this issue?

esplinr (Mon, 29 Apr 2019 16:25:58 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=BavTTcQuf25s5Trnm) @AxelNennker I don't think we have an answer for that yet. I'm told that "Enterprise Java" and "Android Java" are very different, but I suspect that there will be a lot of overlap. That shared architecture is probably best answered by the maintainers of those two repositories.

esplinr (Mon, 29 Apr 2019 16:28:20 GMT):
@JorgeDiaz3 https://github.com/hyperledger/indy-sdk/tree/master/docs/design/002-anoncreds https://github.com/hyperledger/indy-hipe/blob/c761c583b1e01c1e9d3ceda2b03b35336fdc8cc1/text/anoncreds-protocol/README.md

AxelNennker (Mon, 29 Apr 2019 17:51:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ejHbtJ4yCayGKEfCR) @esplinr Java is the same. There are many other things that need to be tweaked to get the Android libindy to be built and loaded

atomeel (Tue, 30 Apr 2019 07:53:05 GMT):
Has joined the channel.

theoturner (Tue, 30 Apr 2019 12:03:41 GMT):
@esplinr I'm looking through some older code which references https://repo.evernym.com/artifactory/libindy-maven-local - is an equivalent made available elsewhere?

JorgeDiaz3 (Tue, 30 Apr 2019 14:44:01 GMT):
@theoturner I don{t know if it helps you but I am using https://repo.sovrin.org/repository/maven-public in my project

JorgeDiaz3 (Tue, 30 Apr 2019 14:48:33 GMT):
When you generate a DID for a wallet using agiven steward seed, I understand that you cannot generate another DID for the same wallet with the same seed as it throws a DidAlreadyExistsException in Java. But what happens in the case that I want to recover the DID? I know that there are methods for the DID class that lets you recover the verkey using the DID but what happens if the DID is lost? Because I won't be able to generate a new one as a previous already exists in the wallet, what is the option for such case?

esplinr (Tue, 30 Apr 2019 16:29:51 GMT):
@theoturner We migrated all the Evernym artifacts to the Sovrin Foundation a couple of months ago. Those old references should be updated.

theoturner (Tue, 30 Apr 2019 16:38:19 GMT):
Thanks, indeed @JorgeDiaz3 has correct link. Cheers :)

lreinink (Wed, 01 May 2019 11:25:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6a769416-efec-4cc3-aba7-d05cf4293a27) @kdenhartog Thank you for your reply. I would like to self issue a credential, like you mention. If I omit the `ledger.sign_and_submit_request` I can indeed write one. I do have one more question, though. At step 4 of the Issue Credential how-to, it is stated that the issuer offering the credential is optional. However, if I omit `cred_offer_json` or put in empty JSON in `anoncreds.prover_create_credential_req`, I get `indy.error.IndyError: ErrorCode.CommonInvalidStructure`

lreinink (Wed, 01 May 2019 11:25:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6a769416-efec-4cc3-aba7-d05cf4293a27) @kdenhartog Thank you for your reply. I would like to self issue a credential, like you mention. If I omit the `ledger.sign_and_submit_request` I can indeed create one. I do have one more question, though. At step 4 of the Issue Credential how-to, it is stated that the issuer offering the credential is optional. However, if I omit `cred_offer_json` or put in empty JSON in `anoncreds.prover_create_credential_req`, I get `indy.error.IndyError: ErrorCode.CommonInvalidStructure`

lreinink (Wed, 01 May 2019 11:25:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6a769416-efec-4cc3-aba7-d05cf4293a27) @kdenhartog Thank you for your reply. I would like to self issue a credential, like you mention. If I omit the `ledger.sign_and_submit_request` I can indeed create one. I do have one more question, though. At step 4 of the Issue Credential how-to, it is stated that the issuer offering the credential is optional. However, if I omit `cred_offer_json` or put in empty JSON in `anoncreds.prover_create_credential_req`, I get `indy.error.IndyError: ErrorCode.CommonInvalidStructure`. How can I omit it, or is it not optional after all?

lreinink (Wed, 01 May 2019 11:25:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6a769416-efec-4cc3-aba7-d05cf4293a27) @kdenhartog Thank you for your reply. I would like to self issue a credential, like you mention. If I omit the `ledger.sign_and_submit_request` I can indeed create one. I do have one more question, though. At step 4 of the Issue Credential how-to, it is stated that the issuer offering the credential is optional. However, if I omit `cred_offer_json` or put empty JSON in `anoncreds.prover_create_credential_req`, I get `indy.error.IndyError: ErrorCode.CommonInvalidStructure`. How can I omit it, or is it not optional after all?

george.aristy (Wed, 01 May 2019 19:04:13 GMT):
Has joined the channel.

theoturner (Thu, 02 May 2019 10:37:47 GMT):
Any ideas as to the cause of `ledger.TimeoutException` on a `Pool.openPoolLedger()`? I am listening on the correct ports & pool is running.

theoturner (Thu, 02 May 2019 10:44:27 GMT):
Feeding it a `null` or config makes no difference

sklump (Fri, 03 May 2019 11:01:37 GMT):
*Cargo Testing Fails To Resolve New Code Artifacts* Maybe an indy-sdk developer has some insight here? I'm mustering a PR to allow configuration of what attributes generate tags to write in wallet records. I have code in `libindy/src/domain/anoncreds/credential_attr_tag_policy.rs` defining `CredentialAttrTagPolicy` class; its top lines look like this: ``` use serde::ser::{Serialize, Serializer, SerializeSeq}; use serde::de::{Deserializer, Deserialize}; use named_type::NamedType; use domain::anoncreds::schema::AttributeNames; use services::anoncreds::helpers::attr_common_view; ``` I have `pub mod credential_attr_tag_policy;` in `libindy/src/domain/anoncreds/mod.rs`. It cargo builds fine and all of its logic (plus that of its affected-by's) runs just fine through (new) corresponding python wrapper tests. In `libindy/tests/utils/anoncreds.rs` I have pass-throughs like this: ``` pub fn prover_set_credential_attr_tag_policy(wallet_handle: i32, cred_def_id: &str, tag_attrs_json: &str, retroactive: bool) -> Result<(), IndyError> { anoncreds::prover_set_credential_attr_tag_policy(wallet_handle, cred_def_id, tag_attrs_json, retroactive).wait() } pub fn prover_get_credential_attr_tag_policy(wallet_handle: i32, cred_def_id: &str) -> Result { anoncreds::prover_get_credential_attr_tag_policy(wallet_handle, cred_def_id).wait() } ``` However, cargo test chokes and dies on import: ``` $ cargo test --test anoncreds Compiling libindy v1.8.2 (/home/sklump/indy-sdk/libindy) error[E0433]: failed to resolve: did you mean `utils::domain`? --> tests/utils/../../src/domain/anoncreds/credential_attr_tag_policy.rs:6:5 | 6 | use domain::anoncreds::schema::AttributeNames; | ^^^^^^ did you mean `utils::domain`? error[E0433]: failed to resolve: maybe a missing `extern crate services;`? --> tests/utils/../../src/domain/anoncreds/credential_attr_tag_policy.rs:7:5 | 7 | use services::anoncreds::helpers::attr_common_view; | ^^^^^^^^ maybe a missing `extern crate services;`? error[E0425]: cannot find function `prover_set_credential_attr_tag_policy` in module `anoncreds` --> tests/utils/anoncreds.rs:92:16 | 92 | anoncreds::prover_set_credential_attr_tag_policy(wallet_handle, cred_def_id, tag_attrs_json, retroactive).wait() | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `anoncreds` help: possible candidate is found in another module, you can import it into scope | 3 | use utils::anoncreds::prover_set_credential_attr_tag_policy; | error[E0425]: cannot find function `prover_get_credential_attr_tag_policy` in module `anoncreds` --> tests/utils/anoncreds.rs:96:16 | 96 | anoncreds::prover_get_credential_attr_tag_policy(wallet_handle, cred_def_id).wait() | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `anoncreds` help: possible candidate is found in another module, you can import it into scope | 3 | use utils::anoncreds::prover_get_credential_attr_tag_policy; | ... ``` (and from here the errors cascade). What do I have to do to make the cargo test pick up these imports on the build step? Can anyone help here? Or is what I am doing fundamentally untenable in rust? *Conjecture*: cargo test picks up anoncreds from indyrs, which does not yet have the requisite code *Counter-evidence*: none of this manifested in the analogous `prover_delete_credential()` test plumbing

sklump (Fri, 03 May 2019 11:01:37 GMT):
*Cargo Testing Fails To Resolve New Code Artifacts* Maybe an indy-sdk developer has some insight here? I'm mustering a PR to allow configuration of what attributes generate tags to write in wallet records. I have code in `libindy/src/domain/anoncreds/credential_attr_tag_policy.rs` defining `CredentialAttrTagPolicy` class; its top lines look like this: ``` use serde::ser::{Serialize, Serializer, SerializeSeq}; use serde::de::{Deserializer, Deserialize}; use named_type::NamedType; use domain::anoncreds::schema::AttributeNames; use services::anoncreds::helpers::attr_common_view; ``` I have `pub mod credential_attr_tag_policy;` in `libindy/src/domain/anoncreds/mod.rs`. It cargo builds fine and all of its logic (plus that of its affected-by's) runs just fine through (new) corresponding python wrapper tests. In `libindy/tests/utils/anoncreds.rs` I have pass-throughs like this: ``` pub fn prover_set_credential_attr_tag_policy(wallet_handle: i32, cred_def_id: &str, tag_attrs_json: &str, retroactive: bool) -> Result<(), IndyError> { anoncreds::prover_set_credential_attr_tag_policy(wallet_handle, cred_def_id, tag_attrs_json, retroactive).wait() } pub fn prover_get_credential_attr_tag_policy(wallet_handle: i32, cred_def_id: &str) -> Result { anoncreds::prover_get_credential_attr_tag_policy(wallet_handle, cred_def_id).wait() } ``` However, cargo test chokes and dies on import: ``` $ cargo test --test anoncreds Compiling libindy v1.8.2 (/home/sklump/indy-sdk/libindy) error[E0433]: failed to resolve: did you mean `utils::domain`? --> tests/utils/../../src/domain/anoncreds/credential_attr_tag_policy.rs:6:5 | 6 | use domain::anoncreds::schema::AttributeNames; | ^^^^^^ did you mean `utils::domain`? error[E0433]: failed to resolve: maybe a missing `extern crate services;`? --> tests/utils/../../src/domain/anoncreds/credential_attr_tag_policy.rs:7:5 | 7 | use services::anoncreds::helpers::attr_common_view; | ^^^^^^^^ maybe a missing `extern crate services;`? error[E0425]: cannot find function `prover_set_credential_attr_tag_policy` in module `anoncreds` --> tests/utils/anoncreds.rs:92:16 | 92 | anoncreds::prover_set_credential_attr_tag_policy(wallet_handle, cred_def_id, tag_attrs_json, retroactive).wait() | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `anoncreds` help: possible candidate is found in another module, you can import it into scope | 3 | use utils::anoncreds::prover_set_credential_attr_tag_policy; | error[E0425]: cannot find function `prover_get_credential_attr_tag_policy` in module `anoncreds` --> tests/utils/anoncreds.rs:96:16 | 96 | anoncreds::prover_get_credential_attr_tag_policy(wallet_handle, cred_def_id).wait() | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `anoncreds` help: possible candidate is found in another module, you can import it into scope | 3 | use utils::anoncreds::prover_get_credential_attr_tag_policy; | ... ``` (and from here the errors cascade). *Question:* What do I have to do to make the cargo test pick up these imports on the build step? *Conjecture*: cargo test picks up anoncreds from indyrs, which does not yet have the requisite code *Counter-evidence*: none of this manifested in the analogous `prover_delete_credential()` test plumbing Can anyone help here? Or is what I am doing fundamentally untenable in rust?

sklump (Fri, 03 May 2019 11:01:37 GMT):
*Cargo Testing Fails To Resolve New Code Artifacts* Maybe an indy-sdk developer has some insight here? I'm mustering a PR to allow configuration of what attributes generate tags to write in wallet records. I have code in `libindy/src/domain/anoncreds/credential_attr_tag_policy.rs` defining `CredentialAttrTagPolicy` class; its top lines look like this: ``` use serde::ser::{Serialize, Serializer, SerializeSeq}; use serde::de::{Deserializer, Deserialize}; use named_type::NamedType; use domain::anoncreds::schema::AttributeNames; use services::anoncreds::helpers::attr_common_view; ``` I have `pub mod credential_attr_tag_policy;` in `libindy/src/domain/anoncreds/mod.rs`. It cargo builds fine and all of its logic (plus that of its affected-by's) runs just fine through (new) corresponding python wrapper tests. In `libindy/tests/utils/anoncreds.rs` I have pass-throughs like this: ``` pub fn prover_set_credential_attr_tag_policy(wallet_handle: i32, cred_def_id: &str, tag_attrs_json: &str, retroactive: bool) -> Result<(), IndyError> { anoncreds::prover_set_credential_attr_tag_policy(wallet_handle, cred_def_id, tag_attrs_json, retroactive).wait() } pub fn prover_get_credential_attr_tag_policy(wallet_handle: i32, cred_def_id: &str) -> Result { anoncreds::prover_get_credential_attr_tag_policy(wallet_handle, cred_def_id).wait() } ``` However, cargo test chokes and dies on import: ``` $ cargo test --test anoncreds Compiling libindy v1.8.2 (/home/sklump/indy-sdk/libindy) error[E0433]: failed to resolve: did you mean `utils::domain`? --> tests/utils/../../src/domain/anoncreds/credential_attr_tag_policy.rs:6:5 | 6 | use domain::anoncreds::schema::AttributeNames; | ^^^^^^ did you mean `utils::domain`? error[E0433]: failed to resolve: maybe a missing `extern crate services;`? --> tests/utils/../../src/domain/anoncreds/credential_attr_tag_policy.rs:7:5 | 7 | use services::anoncreds::helpers::attr_common_view; | ^^^^^^^^ maybe a missing `extern crate services;`? error[E0425]: cannot find function `prover_set_credential_attr_tag_policy` in module `anoncreds` --> tests/utils/anoncreds.rs:92:16 | 92 | anoncreds::prover_set_credential_attr_tag_policy(wallet_handle, cred_def_id, tag_attrs_json, retroactive).wait() | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `anoncreds` help: possible candidate is found in another module, you can import it into scope | 3 | use utils::anoncreds::prover_set_credential_attr_tag_policy; | error[E0425]: cannot find function `prover_get_credential_attr_tag_policy` in module `anoncreds` --> tests/utils/anoncreds.rs:96:16 | 96 | anoncreds::prover_get_credential_attr_tag_policy(wallet_handle, cred_def_id).wait() | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `anoncreds` help: possible candidate is found in another module, you can import it into scope | 3 | use utils::anoncreds::prover_get_credential_attr_tag_policy; | ... ``` (and from here the errors cascade). *Question:* What do I have to do to make the cargo test pick up these imports on the build step? *Conjecture*: cargo test picks up anoncreds from indyrs, which does not yet have the requisite code *Counter-evidence*: none of this manifested in the analogous `prover_delete_credential()` test plumbing for PR 1588 Can anyone help here? Or is what I am doing fundamentally untenable in rust?

sklump (Fri, 03 May 2019 11:01:37 GMT):
*Cargo Testing Fails To Resolve New Code Artifacts* Maybe an indy-sdk developer has some insight here? I'm mustering a PR to allow configuration of what attributes generate tags to write in wallet records. I have code in `libindy/src/domain/anoncreds/credential_attr_tag_policy.rs` defining `CredentialAttrTagPolicy` class; its top lines look like this: ``` use serde::ser::{Serialize, Serializer, SerializeSeq}; use serde::de::{Deserializer, Deserialize}; use named_type::NamedType; use domain::anoncreds::schema::AttributeNames; use services::anoncreds::helpers::attr_common_view; ``` I have `pub mod credential_attr_tag_policy;` in `libindy/src/domain/anoncreds/mod.rs`. It cargo builds fine and all of its logic (plus that of its affected-by's) runs just fine through (new) corresponding python wrapper tests. In `libindy/tests/utils/anoncreds.rs` I have pass-throughs like this: ``` pub fn prover_set_credential_attr_tag_policy(wallet_handle: i32, cred_def_id: &str, tag_attrs_json: &str, retroactive: bool) -> Result<(), IndyError> { anoncreds::prover_set_credential_attr_tag_policy(wallet_handle, cred_def_id, tag_attrs_json, retroactive).wait() } pub fn prover_get_credential_attr_tag_policy(wallet_handle: i32, cred_def_id: &str) -> Result { anoncreds::prover_get_credential_attr_tag_policy(wallet_handle, cred_def_id).wait() } ``` However, cargo test chokes and dies on import: ``` $ cargo test --test anoncreds Compiling libindy v1.8.2 (/home/sklump/indy-sdk/libindy) error[E0433]: failed to resolve: did you mean `utils::domain`? --> tests/utils/../../src/domain/anoncreds/credential_attr_tag_policy.rs:6:5 | 6 | use domain::anoncreds::schema::AttributeNames; | ^^^^^^ did you mean `utils::domain`? error[E0433]: failed to resolve: maybe a missing `extern crate services;`? --> tests/utils/../../src/domain/anoncreds/credential_attr_tag_policy.rs:7:5 | 7 | use services::anoncreds::helpers::attr_common_view; | ^^^^^^^^ maybe a missing `extern crate services;`? error[E0425]: cannot find function `prover_set_credential_attr_tag_policy` in module `anoncreds` --> tests/utils/anoncreds.rs:92:16 | 92 | anoncreds::prover_set_credential_attr_tag_policy(wallet_handle, cred_def_id, tag_attrs_json, retroactive).wait() | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `anoncreds` help: possible candidate is found in another module, you can import it into scope | 3 | use utils::anoncreds::prover_set_credential_attr_tag_policy; | error[E0425]: cannot find function `prover_get_credential_attr_tag_policy` in module `anoncreds` --> tests/utils/anoncreds.rs:96:16 | 96 | anoncreds::prover_get_credential_attr_tag_policy(wallet_handle, cred_def_id).wait() | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `anoncreds` help: possible candidate is found in another module, you can import it into scope | 3 | use utils::anoncreds::prover_get_credential_attr_tag_policy; | ... ``` (and from here the errors cascade). *Question:* What do I have to do to make the cargo test pick up these imports on the compilation step? *Conjecture*: cargo test picks up anoncreds from indyrs, which does not yet have the requisite code *Counter-evidence*: none of this manifested in the analogous `prover_delete_credential()` test plumbing for PR 1588 Can anyone help here? Or is what I am doing fundamentally untenable in rust?

sklump (Fri, 03 May 2019 11:01:37 GMT):
*Cargo Testing Fails To Resolve New Code Artifacts* Maybe an indy-sdk developer has some insight here? I'm mustering a PR to allow configuration of what attributes generate tags to write in wallet records. I have code in `libindy/src/domain/anoncreds/credential_attr_tag_policy.rs` defining `CredentialAttrTagPolicy` class; its top lines look like this: ``` use serde::ser::{Serialize, Serializer, SerializeSeq}; use serde::de::{Deserializer, Deserialize}; use named_type::NamedType; use domain::anoncreds::schema::AttributeNames; use services::anoncreds::helpers::attr_common_view; ``` I have `pub mod credential_attr_tag_policy;` in `libindy/src/domain/anoncreds/mod.rs`. It cargo builds fine and all of its logic (plus that of its affected-by's) runs just fine through (new) corresponding python wrapper tests. In `libindy/tests/utils/anoncreds.rs` I have pass-throughs like this: ``` pub fn prover_set_credential_attr_tag_policy(wallet_handle: i32, cred_def_id: &str, tag_attrs_json: &str, retroactive: bool) -> Result<(), IndyError> { anoncreds::prover_set_credential_attr_tag_policy(wallet_handle, cred_def_id, tag_attrs_json, retroactive).wait() } pub fn prover_get_credential_attr_tag_policy(wallet_handle: i32, cred_def_id: &str) -> Result { anoncreds::prover_get_credential_attr_tag_policy(wallet_handle, cred_def_id).wait() } ``` However, cargo test chokes and dies on import: ``` $ cargo test --test anoncreds Compiling libindy v1.8.2 (/home/sklump/indy-sdk/libindy) error[E0433]: failed to resolve: did you mean `utils::domain`? --> tests/utils/../../src/domain/anoncreds/credential_attr_tag_policy.rs:6:5 | 6 | use domain::anoncreds::schema::AttributeNames; | ^^^^^^ did you mean `utils::domain`? error[E0433]: failed to resolve: maybe a missing `extern crate services;`? --> tests/utils/../../src/domain/anoncreds/credential_attr_tag_policy.rs:7:5 | 7 | use services::anoncreds::helpers::attr_common_view; | ^^^^^^^^ maybe a missing `extern crate services;`? error[E0425]: cannot find function `prover_set_credential_attr_tag_policy` in module `anoncreds` --> tests/utils/anoncreds.rs:92:16 | 92 | anoncreds::prover_set_credential_attr_tag_policy(wallet_handle, cred_def_id, tag_attrs_json, retroactive).wait() | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `anoncreds` help: possible candidate is found in another module, you can import it into scope | 3 | use utils::anoncreds::prover_set_credential_attr_tag_policy; | error[E0425]: cannot find function `prover_get_credential_attr_tag_policy` in module `anoncreds` --> tests/utils/anoncreds.rs:96:16 | 96 | anoncreds::prover_get_credential_attr_tag_policy(wallet_handle, cred_def_id).wait() | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `anoncreds` help: possible candidate is found in another module, you can import it into scope | 3 | use utils::anoncreds::prover_get_credential_attr_tag_policy; | ... ``` (and from here the errors cascade). *Question:* What do I have to do to make the cargo test pick up these imports on the compilation step? *Conjecture*: cargo test picks up anoncreds from indyrs, which does not yet have the requisite code *Counter-evidence*: none of this manifested in the analogous `prover_delete_credential()` test plumbing for PR 1588 *Puzzling evidence*: even with no unit tests for CredentialAttrTagPolicy, the cargo test --test anoncreds still fails the same way. I have no idea even what buttons to push. Can anyone help here? Or is what I am doing fundamentally untenable in rust?

sklump (Fri, 03 May 2019 11:01:37 GMT):
*Cargo Testing Fails To Resolve New Code Artifacts* Maybe an indy-sdk developer has some insight here? I'm mustering a PR to allow configuration of what attributes generate tags to write in wallet records. I have code in `libindy/src/domain/anoncreds/credential_attr_tag_policy.rs` defining `CredentialAttrTagPolicy` class; its top lines look like this: ``` use serde::ser::{Serialize, Serializer, SerializeSeq}; use serde::de::{Deserializer, Deserialize}; use named_type::NamedType; use domain::anoncreds::schema::AttributeNames; use services::anoncreds::helpers::attr_common_view; ``` I have `pub mod credential_attr_tag_policy;` in `libindy/src/domain/anoncreds/mod.rs`. It cargo builds fine and all of its logic (plus that of its affected-by's) runs just fine through (new) corresponding python wrapper tests. In `libindy/tests/utils/anoncreds.rs` I have pass-throughs like this: ``` pub fn prover_set_credential_attr_tag_policy(wallet_handle: i32, cred_def_id: &str, tag_attrs_json: &str, retroactive: bool) -> Result<(), IndyError> { anoncreds::prover_set_credential_attr_tag_policy(wallet_handle, cred_def_id, tag_attrs_json, retroactive).wait() } pub fn prover_get_credential_attr_tag_policy(wallet_handle: i32, cred_def_id: &str) -> Result { anoncreds::prover_get_credential_attr_tag_policy(wallet_handle, cred_def_id).wait() } ``` However, cargo test chokes and dies on import: ``` $ cargo test --test anoncreds Compiling libindy v1.8.2 (/home/sklump/indy-sdk/libindy) error[E0433]: failed to resolve: did you mean `utils::domain`? --> tests/utils/../../src/domain/anoncreds/credential_attr_tag_policy.rs:6:5 | 6 | use domain::anoncreds::schema::AttributeNames; | ^^^^^^ did you mean `utils::domain`? error[E0433]: failed to resolve: maybe a missing `extern crate services;`? --> tests/utils/../../src/domain/anoncreds/credential_attr_tag_policy.rs:7:5 | 7 | use services::anoncreds::helpers::attr_common_view; | ^^^^^^^^ maybe a missing `extern crate services;`? error[E0425]: cannot find function `prover_set_credential_attr_tag_policy` in module `anoncreds` --> tests/utils/anoncreds.rs:92:16 | 92 | anoncreds::prover_set_credential_attr_tag_policy(wallet_handle, cred_def_id, tag_attrs_json, retroactive).wait() | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `anoncreds` help: possible candidate is found in another module, you can import it into scope | 3 | use utils::anoncreds::prover_set_credential_attr_tag_policy; | error[E0425]: cannot find function `prover_get_credential_attr_tag_policy` in module `anoncreds` --> tests/utils/anoncreds.rs:96:16 | 96 | anoncreds::prover_get_credential_attr_tag_policy(wallet_handle, cred_def_id).wait() | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ not found in `anoncreds` help: possible candidate is found in another module, you can import it into scope | 3 | use utils::anoncreds::prover_get_credential_attr_tag_policy; | ... ``` (and from here the errors cascade). *Question:* What do I have to do to make the cargo test pick up these imports on the compilation step? *Conjecture*: cargo test picks up anoncreds from indyrs, which does not yet have the requisite code *Counter-evidence*: none of this manifested in the analogous `prover_delete_credential()` test plumbing for PR 1588 *Further puzzling evidence*: even with no unit tests for CredentialAttrTagPolicy, `cargo test --test anoncreds` still fails the same way. I have no idea even what buttons to push. Can anyone help here? Or is what I am doing fundamentally untenable in rust?

jacobsaur (Fri, 03 May 2019 12:29:44 GMT):
Hi, I have a nodejs server with multiple wallets, I noticed that if 2 simultaneous requests come in to openWallet() with different credentials, the indy-sdk will sometimes return the same wallet handle. I've worked around this on my own server by putting a lock around all openWallet calls, but I'm wondering if other people have seen this issue and if there's a way to fix this within the openWallet call itself.

sklump (Fri, 03 May 2019 14:19:37 GMT):
_... re: cargo build shenanigans: many problems go away if I don't try to `use domain::anoncreds::schema::AttributeNames` or `services::anoncreds::helpers::attr_common_view` in source code file `libindy/src/domain/anoncreds/credential_attr_tag_policy`. I can repeat this code locally but that is clearly the Wrong Thing. I'd really prefer to use code already written for these - how to I get access to them without blowing up cargo test?

tplooker (Mon, 06 May 2019 03:27:26 GMT):
The Mattr team is pleased to announce the open sourcing of osma - an open source mobile agent built on top of AgentFramework (https://github.com/streetcred-id/agent-framework), this project is still in development but we hope it will be of great community value to accelerate the development of mobile agents. Check it out at https://github.com/mattrglobal/osma and get in touch if you have any queries!

rchristman (Mon, 06 May 2019 17:06:39 GMT):
Would someone please point me to documentation on tails files? I see references in the Indy docs, but haven't found a full explanation.

sklump (Mon, 06 May 2019 17:24:59 GMT):
@rchristman https://github.com/hyperledger/indy-sdk/blob/master/docs/concepts/revocation/cred-revocation.md

rchristman (Mon, 06 May 2019 17:25:42 GMT):
Thanks!

sklump (Mon, 06 May 2019 17:26:12 GMT):
You might enjoy: https://github.com/PSPC-SPAC-buyandsell/von_tails

hagenderouen (Mon, 06 May 2019 20:59:53 GMT):
Attempting to run dotnet samples and getting error for the .NET Core SDK version. What .NET version is supported in the indy-sdk?

kdenhartog (Mon, 06 May 2019 21:14:48 GMT):
I encountered this when I was trying to set it up as well. @tomislav or @tplooker would have the best info on it, but from what they informed me anything that is 2+ should work. What OS are you using @hagenderouen

tplooker (Mon, 06 May 2019 21:52:00 GMT):
@hagenderouen @kdenhartog the samples.csproj is targeting 2.1 so that should be the SDK version you will need installed. Run dotnet --version in your terminal or command prompt to check which version you have

tomislav (Tue, 07 May 2019 03:34:42 GMT):
This may be an issue with Xamarin Studio, if you're running the 2019 Preview. They have a fix for it, but hasn't been released.

sklump (Tue, 07 May 2019 17:31:53 GMT):
*Word to the wise re: cargo build shenanigans* The rust wrapper is not just another wrapper: it provides important exoskeleton to cargo tests for libindy. If adding APIs, be sure to update `indy-sdk/wrappers/rust/src` and `indy-sdk/wrappers/rust/indy-sys/src` code base accordingly -- otherwise libindy cargo test will not pass build step.

kdenhartog (Tue, 07 May 2019 17:37:25 GMT):
Thanks for adding this in here. I'm going to add to the bottom of my list (meaning u won't get to it for a bit) a guide on adding a feature to IndySDK where all these steps get outlined.

kdenhartog (Tue, 07 May 2019 17:37:25 GMT):
Thanks for adding this in here. I'm going to add to the bottom of my list (meaning I won't get to it for a bit) a guide on adding a feature to IndySDK where all these steps get outlined.

esplinr (Tue, 07 May 2019 18:50:36 GMT):
I'm glad you figured it out @sklump

DarionHernandez (Wed, 08 May 2019 19:41:37 GMT):
Has joined the channel.

sklump (Thu, 09 May 2019 12:35:03 GMT):
For consideration: credential attribute tagging policy https://jira.hyperledger.org/browse/IS-1258

sklump (Thu, 09 May 2019 14:10:34 GMT):
Oi! Did `proof['requested_proof']` really become `proof['requested']` without a protocol version bump? Very naughty!

sklump (Thu, 09 May 2019 14:10:34 GMT):
Oi! Did `proof['requested_proof']` really become `proof['requested']` without a protocol version bump? Very naughty if so. Puzzling evidence: my code does not raise an exception where it uses the 'requested_proof' key without a default. I will have to look deeper into what happened: a doc update in anticipation of a change, or something more mysterious?

sergey.minaev (Thu, 09 May 2019 14:23:49 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/domain/anoncreds/proof.rs#L8 it should be full form in my understanding

sklump (Thu, 09 May 2019 14:42:11 GMT):
My apologies: somehow I am looking at an ANCIENT revision that I thought was current. Sigh.

sklump (Thu, 09 May 2019 14:42:11 GMT):
My apologies: somehow I am looking at an ANCIENT revision that I thought was current. Sigh. Update: I am looking at the wrong remote. Ha ha!

BreizhIndy (Thu, 09 May 2019 15:03:04 GMT):
hey guys, how can i check which version of libindy i'm using? I want to know if I use the same than the one in my docker container

sklump (Thu, 09 May 2019 15:04:49 GMT):
`indy-sdk/libindy/Cargo.toml`. There may be others.

iamtxena (Fri, 10 May 2019 07:15:41 GMT):
Has joined the channel.

DonClaude (Sat, 11 May 2019 05:59:12 GMT):
Hello, I'm trying to get the indy sdk runnning on windows. -> https://github.com/hyperledger/indy-sdk/blob/master/docs/build-guides/windows-build.md I've get the following error building it: PS C:\Users\Don\Downloads\indy-sdk\libindy> cargo build Compiling proc-macro2 v0.4.26 Compiling winapi v0.3.6 [.....] Compiling base64 v0.6.0 Compiling etcommon-rlp v0.2.4 Compiling digest v0.7.6 error: could not find native static library `C`, perhaps an -L flag is missing? error: aborting due to previous error The following warnings were emitted during compilation: warning: expando.c error: Could not compile `openssl-sys`. warning: build failed, waiting for other jobs to finish... error: build failed PS C:\Users\Don\Downloads\indy-sdk\libindy> cargo build Compiling winapi-util v0.1.1 Compiling atty v0.2.11 Compiling rand v0.4.5 Compiling backtrace v0.3.11 Compiling time v0.1.42 Compiling dirs v1.0.4 Compiling errno v0.2.4 Compiling openssl-sys v0.9.40 Compiling libsqlite3-sys v0.9.3 Compiling libindy v1.8.2 (C:\Users\Don\Downloads\indy-sdk\libindy) Compiling serde_json v1.0.36 error: failed to run custom build command for `libindy v1.8.2 (C:\Users\Don\Downloads\indy-sdk\libindy)` process didn't exit successfully: `C:\Users\Don\Downloads\indy-sdk\libindy\target\debug\build\libindy-d4f3eddb94529ef3\build-script-build` (exit code: 101) --- stdout target=x86_64-pc-windows-msvc sodium_static=None --- stderr thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: NotPresent', src\libcore\result.rs:997:5 stack backtrace: 0: std::sys::windows::backtrace::set_frames at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\/src\libstd\sys\windows\backtrace\mod.rs:94 1: std::sys::windows::backtrace::unwind_backtrace at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\/src\libstd\sys\windows\backtrace\mod.rs:81 2: std::sys_common::backtrace::_print at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\/src\libstd\sys_common\backtrace.rs:70 3: std::sys_common::backtrace::print at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\/src\libstd\sys_common\backtrace.rs:58 4: std::panicking::default_hook::{{closure}} at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\/src\libstd\panicking.rs:200 5: std::panicking::default_hook at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\/src\libstd\panicking.rs:215 6: std::panicking::rust_panic_with_hook at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\/src\libstd\panicking.rs:478 7: std::panicking::continue_panic_fmt at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\/src\libstd\panicking.rs:385 8: std::panicking::rust_begin_panic at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\/src\libstd\panicking.rs:312 9: core::panicking::panic_fmt at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\/src\libcore\panicking.rs:85 10: core::result::unwrap_failed at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\src\libcore\macros.rs:16 11: core::result::Result::unwrap at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\src\libcore\result.rs:798 12: build_script_build::main at .\build.rs:19 13: std::rt::lang_start::{{closure}}<()> at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\src\libstd\rt.rs:64 14: std::rt::lang_start_internal::{{closure}} at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\/src\libstd\rt.rs:49 15: std::panicking::try::do_call at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\/src\libstd\panicking.rs:297 16: panic_unwind::__rust_maybe_catch_panic at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\/src\libpanic_unwind\lib.rs:92 17: std::panicking::try at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\/src\libstd\panicking.rs:276 18: std::panic::catch_unwind at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\/src\libstd\panic.rs:388 19: std::rt::lang_start_internal at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\/src\libstd\rt.rs:48 20: std::rt::lang_start<()> at /rustc/2aa4c46cfdd726e97360c2734835aa3515e8c858\src\libstd\rt.rs:64 21: main 22: invoke_main at d:\agent\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78 23: __scrt_common_main_seh at d:\agent\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288 24: BaseThreadInitThunk 25: RtlUserThreadStart

DonClaude (Sat, 11 May 2019 05:59:22 GMT):
warning: build failed, waiting for other jobs to finish... error: could not find native static library `C`, perhaps an -L flag is missing? error: aborting due to previous error The following warnings were emitted during compilation: warning: expando.c error: Could not compile `openssl-sys`. warning: build failed, waiting for other jobs to finish... error: build failed Seems to similar to https://github.com/rust-lang/rust/issues/54900 but couldnÄt find a solution so far. And these are the variables I've set: $env:SODIUM_LIB_DIR="C:\BIN\x64\lib" $env:SODIUM_STATIC="C:\BIN\x64\lib" $env:X86_64_PC_WINDOWS_MSVC_OPENSSL_STATIC="C:\Users\Don\.cargo\registry\src\github.com-1ecc6299db9ec823\openssl-sys-0.9.40" $env:X86_64_PC_WINDOWS_MSVC_OPENSSL_LIB_DIR="C:\Users\Don\.cargo\registry\src\github.com-1ecc6299db9ec823\openssl-sys-0.9.40" $env:X86_64_PC_WINDOWS_MSVC_OPENSSL_INCLUDE_DIR="C:\BIN\x64\include" $env:OPENSSL_LIBS="C:\BIN\rust-openssl-master\openssl" $env:LIBZMQ_PREFIX="C:\BIN\x64\lib" $env:RUST_BACKTRACE=1 Any ideas? Running Windows 10, with MSVS2017C Cheers,

mccown (Tue, 14 May 2019 12:40:49 GMT):
All, I am trying to enable bitcode support when I import the Indy SDK into iOS. So far xcode is throwing an error stating that bitcode is not enabled in libindy.a despite my recompiling libindy.a and enabling it. Has anyone been able to use bitcode support for iOS buiilds? Here are some debug steps I've been taking: To help track this down, I built a simple rust library and a simple iOS app, which I did to help eliminate any of Indy’s complexities from being the culprit. I was able to duplicate the following error in my code: ld: '/Users/mccown/Development/rust/test/rust-ios-example/hello-rust/libs/librust.a(std-c55509d1ae313b6a.std.cpnfq1qe-cgu.0.rcgu.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) Part of what I’ve found is that contemporary versions of rustc are supposed to use bitcode by default. I also found that rust's nightly builds enable the passing of parameters through to rustc / cargo / Xcode. This command is supposed to enable bitcode using that method: RUSTFLAGS="-Z embed-bitcode" cargo lipo --release However, the error persists. I did find that on macOS 10.15.5 that apple is using "Apple LLVM version 10.0.1 (clang-1001.0.46.4)” while rust is using "LLVM version: 8.0”. I’m current tracking down whether this difference is presenting some incompatibility. Has anyone successfully used the Indy SDK in an iOS app where bitcode is required? If so, I would really appreciate hearing from you.

kdenhartog (Tue, 14 May 2019 12:49:20 GMT):
@mccown what version of XCode are you running? I found that I was having issues because I was using Xcode 10.2 which no longer supports Swift 3 Code. I downloaded XCode 10 and was able to build on a simulator.

kdenhartog (Tue, 14 May 2019 12:50:28 GMT):
Also, this was when I was using the binaries that are available on the artifact server (repo.sovrin.org) with cocoapods. My error was more to the effect that it couldn't find some libswiftcore.dylib package, so they may be different.

mccown (Tue, 14 May 2019 12:57:59 GMT):
I'm using Xcode 10.2.1 and Swift 4.2 (also testing with 5). The code always works in the simulator (not sure why), but when it's when you deploy to an actual phone that the bitcode error is thrown. The error is thrown (when deploying to the phone) regardless of whether the app is built for debug or release. We initially observed this with the pre-compiled indy cocoapod. I'm only tracing through the rust builds to see where the issue is... :-)

kdenhartog (Tue, 14 May 2019 13:30:52 GMT):
I see there's a flag to `enable_bitcode` when calling `xcodebuild` maybe try setting that param to `no` instead of `yes`

kdenhartog (Tue, 14 May 2019 13:31:02 GMT):
For context this is what's giving me this idea https://forums.developer.apple.com/thread/70583

kdenhartog (Tue, 14 May 2019 13:33:31 GMT):
Wait just realized I was mixing things up from what you said originally. maybe it should be set to `yes` instead of `no`

mccown (Tue, 14 May 2019 16:13:09 GMT):
@kdenhartog xcode enables the enable_bitcode by default now, so it's set to yes. If I turn it off, the app builds & deploys just fine. However, since our app's a larger app, we need to enable it.

tomislav (Tue, 14 May 2019 18:00:56 GMT):
@mccown `libindy.a` from repo.sovrin.org is compiled using bitcode, you can check with `otool -l libindy.a | grep LLVM` (or `otool -l libindy.a | grep bitcode` less reliable). This library passes the AppStore bitcode check, we're using it successfully in Xamarin projects.

jadhavajay (Tue, 14 May 2019 20:08:01 GMT):
Has joined the channel.

evanv03 (Tue, 14 May 2019 20:13:49 GMT):
Has joined the channel.

evanv03 (Tue, 14 May 2019 20:13:51 GMT):
Hello all, I am attempting to begin development using the indy-sdk node.js wrapper but I am having trouble with installation. npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR! indy-sdk@1.8.3-dev-1088 install: `node-gyp rebuild` npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the indy-sdk@1.8.3-dev-1088 install script. npm ERR! This is probably not a problem with npm. There is likely additional logging output above. npm ERR! A complete log of this run can be found in: npm ERR! C:\Users\name\AppData\Roaming\npm-cache\_logs\2019-05-14T20_06_38_305Z-debug.log

evanv03 (Tue, 14 May 2019 20:13:51 GMT):
Hello all, I am attempting to begin development using the indy-sdk node.js wrapper but I am having trouble with installation. upon running npm install indy-sdk I get the following error message npm ERR! code ELIFECYCLE npm ERR! errno 1 npm ERR! indy-sdk@1.8.3-dev-1088 install: `node-gyp rebuild` npm ERR! Exit status 1 npm ERR! npm ERR! Failed at the indy-sdk@1.8.3-dev-1088 install script. npm ERR! This is probably not a problem with npm. There is likely additional logging output above. npm ERR! A complete log of this run can be found in: npm ERR! C:\Users\name\AppData\Roaming\npm-cache\_logs\2019-05-14T20_06_38_305Z-debug.log

evanv03 (Tue, 14 May 2019 20:15:06 GMT):
Has anyone encountered this before?

vindard (Tue, 14 May 2019 20:58:52 GMT):
Has joined the channel.

mccown (Tue, 14 May 2019 23:25:18 GMT):
@tomislav many thanks for the response. That's both interesting and encouraging. We can't get it to link with bitcode enabled in the app. Does your xamarin project pass the enable-bitcode param down to xcode? What version of xcode are you using?

tomislav (Wed, 15 May 2019 00:04:19 GMT):
@mccown Xcode 10.2. Xamarin build process uses Mtouch, which in turn calls Xcode. It builds with bitcode enabled by default, with an option to disable it.

mccown (Wed, 15 May 2019 05:32:01 GMT):
@tomislav I am able to see the bitcode in the compiled libindy.a. However, I just can't seem to get Xcode 10.2.1 to recognize it when bitcode is enabled in the build options. When "Enable bitcode" set to "No", everything works. Strange issue. Which versions of rust and clang are you using to build your ios app? LLVM versions? Thanks for the assistance.

Unni_1994 (Wed, 15 May 2019 13:03:55 GMT):
Hi all , How the steward is added in the indy network for the first time?

mgbailey (Wed, 15 May 2019 14:00:13 GMT):
After all agreements are signed and approval is granted, a Trustee writes the steward DID and verkey to the ledger. The most widely used public networks are managed by the Sovrin foundation. You can go to their website for more information www.sovrin.org

feliperdelara (Wed, 15 May 2019 17:29:45 GMT):
Does anyone else have the feeling that there could be an indy sdk channel for each platform? I am saying this by my individual experience, most of the times I am trying to find conversations regarding the iOS platform but they get blown over by other subjects and maybe it happens with other people… anyway it's just my two cents

gsantos (Wed, 15 May 2019 17:59:02 GMT):
Has joined the channel.

gsantos (Wed, 15 May 2019 18:02:31 GMT):
Hi all, how can I get the schemas that are written on the ledger without having their id's? That is, if one entity writes a schema, how can another entity have access to it without knowing it's id?

mauricio (Thu, 16 May 2019 03:06:54 GMT):
Has left the channel.

AxelNennker (Thu, 16 May 2019 05:39:57 GMT):
Rust and security https://github.com/mozilla-services/websec-check/blob/master/rust.md - use cargo audit in CI - don't have Cargo.lock in repo for libraries

MeSSeRz (Thu, 16 May 2019 07:07:24 GMT):
Has joined the channel.

MeSSeRz (Thu, 16 May 2019 07:07:24 GMT):
Hi all. I am trying to build an android app using indy SDK. I made all preparations and installed/copied all required libraries. My `jniLibs` folder contains `libindy.so`, `libjnidispatch.so` and `libgnustl_shared.so` files for all necessary architectures. I am not using android emulator. Application works correctly on Mi8 Lite phone (Android 9, api level 28). But fails on Samsung GT-I9500 (Android 5.0.1, api level 21). Both devices uses `armeabi-v7a` instructions. Here is my error which is fired when I am trying to load `libindy` with `System.loadLibrary("indy")`: ``` E/art: dlopen("/data/app/com.mobi.indytest-1/lib/arm/libindy.so", RTLD_LAZY) failed: dlopen failed: cannot locate symbol "logbl" referenced by "libindy.so"... D/AndroidRuntime: Shutting down VM E/AndroidRuntime: FATAL EXCEPTION: main Process: com.mobi.indytest, PID: 3087 java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "logbl" referenced by "libindy.so"... at java.lang.Runtime.loadLibrary(Runtime.java:371) at java.lang.System.loadLibrary(System.java:989) at com.mobi.indytest.MainActivity.onCreate(MainActivity.kt:18) ``` UPD: tested with `arm64-v8a` architecture on Mi8 Lite and got the following error: ``` D/AndroidRuntime: Shutting down VM E/AndroidRuntime: FATAL EXCEPTION: main Process: com.mobi.indytest, PID: 11171 java.lang.UnsatisfiedLinkError: dlopen failed: file offset for the library "/data/app/com.mobi.indytest-5xZTjhsr2qket_Ize66Mbw==/lib/arm64/libindy.so" >= file size: 0 >= 0 at java.lang.Runtime.loadLibrary0(Runtime.java:1016) at java.lang.System.loadLibrary(System.java:1669) at com.mobi.indytest.MainActivity.onCreate(MainActivity.kt:18) ```

Unni_1994 (Thu, 16 May 2019 09:16:40 GMT):
Thanks, So from what my understanding is trustees are adding the steward to the network if they satisfies the agreements. This Stewards can add other parties to the network as Trust Anchors . The identity owner have to develop a relationship with the Trust Anchors to get register with the network .Once the identity is verified , new identifier is registered to the network. Am I right?

kdenhartog (Thu, 16 May 2019 10:40:51 GMT):
Looks like you're missing some dependencies in your build.gradle file Do you have this line in there? ```// https://mvnrepository.com/artifact/ch.qos.logback/logback-core compile group: 'ch.qos.logback', name: 'logback-core', version: '1.2.3'```

MeSSeRz (Thu, 16 May 2019 12:12:57 GMT):
I added this dependency, but error still appears. Here is my dependencies: ``` dependencies { implementation fileTree(dir: 'libs', include: ['*.jar']) implementation fileTree(dir: 'libs', include: ['*.so']) implementation"org.jetbrains.kotlin:kotlin-stdlib-jdk7:$kotlin_version" implementation 'com.android.support:appcompat-v7:28.0.0' implementation 'com.android.support.constraint:constraint-layout:2.0.0-beta1' implementation 'com.android.support:design:28.0.0' implementation 'net.java.dev.jna:jna:5.2.0' implementation 'ch.qos.logback:logback-core:1.2.3' implementation 'org.apache.commons:commons-lang3:3.7' implementation 'commons-io:commons-io:2.6' testImplementation 'junit:junit:4.13-beta-3' androidTestImplementation 'com.android.support.test:runner:1.0.2' androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2' api 'org.hyperledger:indy:1.8.1-dev-985' } ```

mgbailey (Thu, 16 May 2019 13:50:36 GMT):
This is all correct, however there is typically little reason to write an identity owner's DID to the ledger. Typically such DIDs are only known and shared between the two edge agents involved, and there is no reason for them to be on a public ledger.

esplinr (Thu, 16 May 2019 18:47:40 GMT):
I'll reply here where it might benefit others.

esplinr (Thu, 16 May 2019 18:48:45 GMT):
The Evernym team hit the same problem late last year. We weren't able to get Rust to compile with Bitcode support. We got our app small enough without it, but we are very interested if others find a solution.

esplinr (Thu, 16 May 2019 18:49:53 GMT):
And as an FYI, the term "Trust Anchor" is migrating to "Endorser".

esplinr (Thu, 16 May 2019 18:54:22 GMT):
I expect this is where we are going to need to go as the ecosystem grows. We are in the process of creating language specific libraries, and it would be good to create a channel as each of those repos are created. But maybe it would be better to make those libraries at the aries layer instead of the Indy SDK layer?

pimotte (Fri, 17 May 2019 08:33:39 GMT):
Feel free to compare with: https://github.com/Quintor/StudyBitsWallet as well. We're a couple versions behind, but it might help you figure out what you're missing

circlespainter (Sat, 18 May 2019 07:35:35 GMT):
Has joined the channel.

AxelNennker (Sat, 18 May 2019 14:35:41 GMT):
Indy CI seems to be down. I get a `gateway error`. https://build.sovrin.org/job/indy-sdk/job/indy-sdk-ci/job/PR-1585/33/display/redirect

mboyd (Sat, 18 May 2019 16:38:25 GMT):
^^ @SteveGoob

SteveGoob (Mon, 20 May 2019 17:14:13 GMT):
I can't replicate the issue with your link. Are you still experiencing issues?

AxelNennker (Mon, 20 May 2019 17:47:27 GMT):
I guess it was a network error that is now fixed. It was reported by nginx. The build system is quite brittle. Do you know when the move to gitlab will be finished?

esplinr (Mon, 20 May 2019 23:03:31 GMT):
The team at the Sovrin Foundation has been working on it. They want GitLab running for Indy SDK side-by-side with Jenkins in June.

kdenhartog (Tue, 21 May 2019 01:47:26 GMT):
Thanks for your team and the Sovrin Foundation team's help on getting it there!

smithbk (Tue, 21 May 2019 15:28:25 GMT):
Hi, I am trying to build indy-sdk for ios according to https://github.com/hyperledger/indy-sdk/blob/master/wrappers/ios/README.md#how-to-build and when running pod install am seeing the following error. Can someone help? ```$ pod install Analyzing dependencies Fetching podspec for `CoreBitcoin` from `https://raw.github.com/oleganza/CoreBitcoin/master/CoreBitcoin.podspec` Downloading dependencies Installing CoreBitcoin (0.6.8.1) Installing ISO8601DateFormatter (0.8) Installing OpenSSL (1.0.210) [!] Error installing OpenSSL Verification checksum was incorrect, expected bdfbdb416942f666865fa48fe13c2d0e588df54f, got fee7b5baff9cb40fac9129f9073ca7e394393472```

feliperdelara (Tue, 21 May 2019 19:46:03 GMT):
try using pod 'libindy-objc', "1.8.2"

smithbk (Tue, 21 May 2019 20:01:48 GMT):
I changed Podfile to ```def appPods pod 'libsodium' pod 'libzmq',"4.2.3" pod 'OpenSSL' pod 'libindy-objc', "1.8.2" end ``` and no difference. It is failing for OpenSSL though which is before libindy, so wouldn't I need to change the `pod 'OpenSSL'` line somehow?

feliperdelara (Tue, 21 May 2019 20:35:33 GMT):
Oh now I see that you are trying to build, not just run the sdk... When I got this error a while ago, apparently OpenSSL was deprecated. There is a new pod for it with a slightly different name.

smithbk (Tue, 21 May 2019 20:39:21 GMT):
I'm trying to find a pod name other than 'OpenSSL' to use, but not finding it. If you know it or can find it, I'd appreciate it

smithbk (Tue, 21 May 2019 20:44:48 GMT):
looks like using `OpenSSL-Universal` worked ... or seems to have

ilya1w (Wed, 22 May 2019 03:51:38 GMT):
Has joined the channel.

izashkalov (Wed, 22 May 2019 08:02:21 GMT):
Hello everyone, How can I enable indy logs to Android projects? I use this code {code} LibIndy.api.indy_set_default_logger("TRACE"); {code} . But I don`t see trace into Logcat.

izashkalov (Wed, 22 May 2019 08:02:21 GMT):
Hello everyone, How can I enable indy logs to Android projects? I use this code ` LibIndy.api.indy_set_default_logger("TRACE");` . But I don`t see trace into Logcat.

DarionHernandez (Wed, 22 May 2019 18:32:38 GMT):
Hello everyone, im getting a NullPointerException when I try to use the java wrapper in android studio. I copied libindy.so and libgnustl_shared.so to app\src\main\jniLibs\x86 and set the compileOptions to java 8 in build.gradle. Not build errors occur, but when I try to invok Pool.setProtocolVersion(1) the app crashes and I get the following: Caused by: java.lang.NullPointerException: Attempt to invoke interface method 'int org.hyperledger.indy.sdk.LibIndy$API.indy_set_protocol_version(int, int, com.sun.jna.Callback)' on a null object reference at org.hyperledger.indy.sdk.pool.Pool.setProtocolVersion(Pool.java:246). Can someone give me an advice how to set up the sdk for android properly?

DarionHernandez (Wed, 22 May 2019 18:32:38 GMT):
Hello everyone, im getting a NullPointerException when I try to use the java wrapper in android studio. I copied libindy.so and libgnustl_shared.so to app\src\main\jniLibs\x86 and set the compileOptions to java 8 in build.gradle. Not build errors occur, but when I try to invoke Pool.setProtocolVersion(1) the app crashes and I get the following: Caused by: java.lang.NullPointerException: Attempt to invoke interface method 'int org.hyperledger.indy.sdk.LibIndy$API.indy_set_protocol_version(int, int, com.sun.jna.Callback)' on a null object reference at org.hyperledger.indy.sdk.pool.Pool.setProtocolVersion(Pool.java:246). Can someone give me an advice how to set up the sdk for android properly?

smithbk (Wed, 22 May 2019 21:45:30 GMT):
Hi, when trying to build for ios in xcode, I successfully ran `ci/ios-build.sh`, `pod repo update` and `pod install`. After starting xcode, opening `Indy.xcworkspace`, and trying to build/run `Indy-demo`, I am getting the following error: ```Directory not found for option '-L/Users/keith/tid/indy-sdk/wrappers/ios/libindy-pod/build/Debug-iphoneos'``` There is no `build` directory in the `libindy-pod` directory. What is supposed to create that directory? Can someone point me in the right direction please? Thanks `

AxelNennker (Fri, 24 May 2019 07:02:19 GMT):
The API wrapper is not initialized so the object is null. Can't currently remember when this happens. https://github.com/hyperledger/indy-sdk/blob/master/wrappers/java/src/main/java/org/hyperledger/indy/sdk/LibIndy.java#L201 does not seem to work probably because the library is not found.

AxelNennker (Fri, 24 May 2019 07:03:59 GMT):
I guess the directory structure of the project has the library in the wrong folder

pimotte (Fri, 24 May 2019 09:33:22 GMT):
I'm trying to get a backtrace from the sdk for an issue I'm debugging. I've compiled libindy in debug mode, have RUST_BACKTRACE=1 in the environment, but all I'm getting is: ```stack backtrace: 0: (0x7ffb2fb8bd63) 1: (0x7ffb2fb8a99d) 2: (0x7ffb2f85dc01) 3: (0x7ffb2ee8778d) 4: (0x7ffb2ee87c7d) 5: (0x7ffb2ede3963) 6: (0x7ffb2f29307c)```

pimotte (Fri, 24 May 2019 09:33:41 GMT):
Does anyone know how I can get a backtrace with information?

pimotte (Fri, 24 May 2019 09:36:15 GMT):
(this is through the java wrapper, which makes the call to libindy to retrieve the backtrace when an exception occurs)

sklump (Fri, 24 May 2019 11:11:22 GMT):
*ALERT* Latest indy-sdk master does not `cargo build --release`: ``` ... Compiling curve25519-dalek v1.1.4 Compiling sha2 v0.8.0 Compiling sha3 v0.8.2 Compiling blake2 v0.8.0 Compiling sha3 v0.7.3 Compiling sha2 v0.7.1 Compiling synstructure v0.10.1 Compiling darling_core v0.9.0 Compiling serde_derive v1.0.91 Compiling derivative v1.0.2 Compiling rmp-serde v0.13.7 Compiling zmq v0.8.2 Compiling env_logger v0.5.13 Compiling darling_macro v0.9.0 Compiling num v0.2.0 error: Could not compile `curve25519-dalek`. Caused by: process didn't exit successfully: `rustc --crate-name curve25519_dalek /home/sklump/.cargo/registry/src/github.com-1ecc6299db9ec823/curve25519-dalek-1.1.4/src/lib.rs --color always --crate-type lib --emit=dep-info,link -C opt-level=3 --cfg 'feature="alloc"' --cfg 'feature="rand_core"' --cfg 'feature="std"' --cfg 'feature="subtle"' --cfg 'feature="u64_backend"' -C metadata=d240492610bcc67c -C extra-filename=-d240492610bcc67c --out-dir /home/sklump/indy-sdk/libindy/target/release/deps -L dependency=/home/sklump/indy-sdk/libindy/target/release/deps --extern byteorder=/home/sklump/indy-sdk/libindy/target/release/deps/libbyteorder-de2149b8a6a54ffe.rlib --extern clear_on_drop=/home/sklump/indy-sdk/libindy/target/release/deps/libclear_on_drop-611f968b39ccd1a4.rlib --extern digest=/home/sklump/indy-sdk/libindy/target/release/deps/libdigest-1d8ec72aa8cef337.rlib --extern rand_core=/home/sklump/indy-sdk/libindy/target/release/deps/librand_core-fee6b361733f9446.rlib --extern subtle=/home/sklump/indy-sdk/libindy/target/release/deps/libsubtle-3e3a76e8984232cb.rlib --cap-lints allow --cfg 'feature="stage2_build"' -L native=/home/sklump/indy-sdk/libindy/target/release/build/clear_on_drop-03f1f2eea4285bdf/out` (signal: 11, SIGSEGV: invalid memory reference) ``` Anyone who creates revocation registries requires a release build. Please advise.

bricg (Fri, 24 May 2019 14:42:47 GMT):
Hi, I'm trying out the node.js libindy wrapper and calling the parseGetCredDefResponse ( getCredDefResponse ) , to get the necessary credential definition data from the ledger that would be needed to verify a proof relating to the credential definition. I noticed that the response I get includes a value for master-secret, which makes me question if this is correct. 'master-secret' implies this data field shouldn't be on the public ledger. Can any clarify this for me? Here's the response I'm getting ```{ "ver": "1.0", "id": "QoKYDBXz1iRTLq8GGh5a8P:3:CL:245", "schemaId": "245", "type": "CL", "tag": "", "value": { "primary": { "n": "8515905273555601667162272...", "s": "785140242405896404102728...", "r": { "age": "64138955990336...", "name": "3709328438919363...", "height": "73016893588343484...", "master_secret": "651122267225211770832753..." }, "rctxt": "386095421...", "z": "69346269423195..." } } } }```

bricg (Fri, 24 May 2019 14:42:47 GMT):
Hi, I'm trying out the node.js libindy wrapper and calling the parseGetCredDefResponse ( getCredDefResponse ) , to get the necessary credential definition data from the ledger that would be needed to verify a proof relating to the credential definition. I noticed that the response I get includes a value for master-secret, which makes me question if this is correct. 'master-secret' implies this data field shouldn't be on the public ledger. Can anyone clarify this for me? Thanks! Here's the response I'm getting ```{ "ver": "1.0", "id": "QoKYDBXz1iRTLq8GGh5a8P:3:CL:245", "schemaId": "245", "type": "CL", "tag": "", "value": { "primary": { "n": "8515905273555601667162272...", "s": "785140242405896404102728...", "r": { "age": "64138955990336...", "name": "3709328438919363...", "height": "73016893588343484...", "master_secret": "651122267225211770832753..." }, "rctxt": "386095421...", "z": "69346269423195..." } } } }```

SergeyBrazhnik (Fri, 24 May 2019 16:07:10 GMT):
Hello guys. could somebody advise why I could get this decript error `ERROR indy::errors::indy Casting error to ErrorCode: Invalid structure: Can't deserialize ComboBox: Syntax("invalid type: integer `123`, expected struct ComboBox") indy::errors::indy F:src/errors/indy.rs`

SergeyBrazhnik (Fri, 24 May 2019 16:07:10 GMT):
Hello guys. could somebody advise why I could get this decript error executing indy_crypto_auth_decrypt `ERROR indy::errors::indy Casting error to ErrorCode: Invalid structure: Can't deserialize ComboBox: Syntax("invalid type: integer `123`, expected struct ComboBox") indy::errors::indy F:src/errors/indy.rs`

SergeyBrazhnik (Mon, 27 May 2019 08:58:49 GMT):
solved my issue. Turned out that I have beed used authDecrypt insted of anonDecrypt

sklump (Mon, 27 May 2019 13:45:00 GMT):
Is the CI subsystem that PR updates to github invokes known to be in a dodgy state? If anyone could take a look at PR#1648 (https://github.com/hyperledger/indy-sdk/pull/1648) and formulate an opinion on anything I could do to make its builds and tests pass, I would be very grateful for the advice. At present it fails nowhere near any changes I've made.

AxelNennker (Mon, 27 May 2019 14:17:22 GMT):
I think that the build might have been killed manually. I halted all 'merge master into branch' and build action. The core team is working hard on getting 1.9.0 out and sometime stops builds to free resources. Once 1.9.0 is out things should be normal. Also CI is currently being moved from Jenkins to gitlab CI hopefully allowing supporters to add build resources to ease the pain...

sklump (Mon, 27 May 2019 14:18:57 GMT):
Thanks @AxelNennker . Will the mechanism re-try the work item or will it lie with a scarlet letter X next to it until I make some kind of change?

AxelNennker (Mon, 27 May 2019 14:21:02 GMT):
I think it lies around until a change is made. Not very satisfying... but I guess if Jenkins could be configured to be nicer it would have been done.

sklump (Mon, 27 May 2019 14:24:53 GMT):
Sigh. I will make a note in the PR and the JIRA and see if it gets any traction. VON network could really use this update.

sklump (Mon, 27 May 2019 14:24:53 GMT):
Sigh. I will make a note in the PR and the JIRA (https://jira.hyperledger.org/projects/IS/issues/IS-1258) and see if it gets any traction. VON network could really use this update.

MarekStocki (Mon, 27 May 2019 14:32:16 GMT):
Has joined the channel.

MarekStocki (Mon, 27 May 2019 14:32:18 GMT):
Dear Indy experts, I have some questions: 1. While playing with the Hyperledger Indy Agent Demonstration for Node.js (which is great btw), we got stuck on adding the revocation functionality. Do you know if there is any plan to add it to this demo? Or is there any demo for credential revocation with Indy? 2. I was looking at revocation tests and they seem to store tail files on local file system, which I am afraid is not a solution for a real system. What kind of servers are supported by BlobStorageReader/Writer and what should be the content of the config JSON parameter in the call to openBlobStorageReader/Writer? 3. On another subject: verifierVerifyProof sometimes returns true for tampered proofs, where proof/proof/proofs/primary_proof/eq_proof/revealed_attrs do not match requested_proof/requested_proof/revealed_attrs/attr1_referent/encoded or requested_proof/requested_proof/revealed_attrs/attr1_referent/encoded do not match requested_proof/requested_proof/revealed_attrs/attr1_referent/raw. Is it the responsibility of libindy or the client code to check if these values match? Kind Regards, Marek Stocki

sklump (Mon, 27 May 2019 14:41:00 GMT):
@MarekStocki 1: see indy-sdk/wrappers/python/tests/interation/test_interaction.py for a demonstration of revocation 2: you might enjoy https://github.com/PSPC-SPAC-buyandsell/von_tails 3: consider an approach such as https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/35be2b7061c15efce4ee873aa7f2a5d5f99ed850/von_anchor/anchor/verifier.py#L414 to validate proof against corresponding proof request

sklump (Mon, 27 May 2019 14:41:00 GMT):
@MarekStocki 1: see indy-sdk/wrappers/python/tests/interation/test_interaction.py for a demonstration of revocation 2: you might enjoy https://github.com/PSPC-SPAC-buyandsell/von_tails. Note however that revocation will be different from anoncreds-2.0 onward and tails files are on the way out. 3: consider an approach such as https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/35be2b7061c15efce4ee873aa7f2a5d5f99ed850/von_anchor/anchor/verifier.py#L414 to validate proof against corresponding proof request as a first step in proof verification.

MarekStocki (Mon, 27 May 2019 14:48:52 GMT):
Thanks a lot!

swcurran (Mon, 27 May 2019 15:52:29 GMT):
@MarekStocki - there is an initiative starting on a new revocation method that works in a conceptually similar way, but eliminates the tails file. That work has started, but it probably 6 mos out to be released on the Sovrin network for a production use. Sooner for testing and demo apps.

swcurran (Mon, 27 May 2019 15:53:01 GMT):
That is part of Hyperledger Ursa and @MALodder is leading that effort.

nicola.attico (Mon, 27 May 2019 17:30:12 GMT):
Has joined the channel.

sklump (Tue, 28 May 2019 12:04:25 GMT):
Back on PR#1648. Much as I sympathise with how much work must have gone into the CI subsystem, I'm afraid it's not quite there. All tests pass but at present the pool teardown and cleanup has some kind of exit failure and ultimately terminates with exit code 1073741845. On Windows, it logs `Assertion failed: s != retired_fd (..\..\..\..\src\tcp_connecter.cpp:415)` before it crashes. In its current state, I don't see how any PR is going to pass.

sklump (Tue, 28 May 2019 12:04:25 GMT):
Back on PR#1648. Much as I sympathise with how much work must have gone into the CI subsystem, I'm afraid it's not quite there. All tests pass but at present the pool teardown and cleanup has some kind of exit failure and ultimately terminates with exit code 1073741845. On Windows, it logs `Assertion failed: s != retired_fd (..\..\..\..\src\tcp_connecter.cpp:415)` before it crashes. The only `tcp_connecter.cpp` (note spelling) I can find is in libzmq, which is promising, and it cites `retired_fd`, but it has less than 415 lines. Puzzling evidence. In its current state, I don't see how any PR is going to pass.

sklump (Tue, 28 May 2019 12:04:25 GMT):
Back on PR#1648. Much as I sympathise with how much work must have gone into the CI subsystem, I'm afraid it's not quite there. All tests pass but at present the pool teardown and cleanup has some kind of exit failure and ultimately terminates with exit code 1073741845. On Windows, it logs `Assertion failed: s != retired_fd (..\..\..\..\src\tcp_connecter.cpp:415)` before it crashes. The only `tcp_connecter.cpp` (note spelling) I can find is in libzmq, which is promising, and it cites `retired_fd`, but it has far fewer than 415 lines. Puzzling evidence. In its current state, I don't see how any PR is going to pass.

arati_baliga (Tue, 28 May 2019 12:27:49 GMT):
Has joined the channel.

sergey.minaev (Tue, 28 May 2019 14:19:54 GMT):
btw the previous run was successful on the CI as I can see. You are correct, this assertion from libzmq and it's out of our control right now. Hopefully it's just random crash for single build, will see how it will go for the next try

sklump (Tue, 28 May 2019 14:26:23 GMT):
Thanks @sergey.minaev . If I leave it in its current state, will the indy-sdk core group consider inclusion in 1.9.0? Shaping tag retention policy would be allow a big win in storage for VON network.

sklump (Tue, 28 May 2019 14:26:23 GMT):
Thanks @sergey.minaev . If I leave it in its current state, will the indy-sdk core group consider its inclusion in 1.9.0? Shaping tag retention policy would be allow a big win in storage for VON network.

sergey.minaev (Tue, 28 May 2019 14:58:13 GMT):
@sklump @esplinr AFAIR from IndySDK WG call this functionality is planned as part of 1.9.1 release in June, isn't it?

sklump (Tue, 28 May 2019 15:02:25 GMT):
Sure, I should have written 1.9.x.

sergey.minaev (Tue, 28 May 2019 15:12:23 GMT):
I hope CI will be minor concern here. There was some feedback about disclosure too much by tagging and it may be more critical question. But I've not checked neither proposal itself or the feedback correctness yet

sklump (Tue, 28 May 2019 15:35:22 GMT):
Prior to 1.6, credential storage kept zero tags; since then, the process stores all the tags. The credential attr tag policy (catpol) update allows a slider between these settings: if both were OK before, then all possibilities ought to be equally OK under catpol.

sklump (Tue, 28 May 2019 15:35:22 GMT):
Prior to 1.6, credential storage kept zero tags; since then, the operation stores all the tags. The credential attr tag policy (catpol) update allows a slider between these settings: if both were OK before, then all possibilities ought to be equally OK under catpol.

sklump (Tue, 28 May 2019 15:35:22 GMT):
Prior to 1.6, credential storage kept zero tags; since then, the operation stores all the tags (times two: marker and value). The credential attr tag policy (catpol) update allows a slider between these settings: if both were OK before, then all possibilities ought to be equally OK under catpol.

esplinr (Tue, 28 May 2019 16:11:55 GMT):
I'm surprised that the work on the tag retention policy is so mature. In our last discussion, Stephen Curran thought it was still a few weeks away. We are tracking it for inclusion in the June release (1.9.1). We have already produced the release candidate for the May release (1.9.0) and started testing, so adding code would delay it.

josh.graber (Wed, 29 May 2019 12:47:33 GMT):
Has joined the channel.

RodrigoMedeiros (Wed, 29 May 2019 17:12:48 GMT):
Has joined the channel.

SeanBohan (Wed, 29 May 2019 17:49:24 GMT):
Has joined the channel.

iamtxena (Thu, 30 May 2019 09:02:46 GMT):
Hey guys, we would like to use RSA keys to sign credentials. Does the indy-sdk support the RSA key types? It seems that it only supports ed25519 keys, but just asking, or if you know if someone is working on a HIPE doing that. Thanks in advance!

MALodder (Thu, 30 May 2019 12:30:24 GMT):
Indy doesn’t use ed25519 to sign credentials. Ed25519 keys are used for DIDs. Credential use Camenisch-Lysyanskaya signatures. CL sigs offer selective disclosure which you cannot do with RSA, EdDSA or ECDSA. Are you wanting to use RSA for DIDs not credentials?

iamtxena (Thu, 30 May 2019 14:50:05 GMT):
@MALodder Thanks for the answer. Ideally for both, but at least to sign credentials using RSA keys associated to a DID.

MALodder (Thu, 30 May 2019 14:52:10 GMT):
@iamtxena you don't need to sign credentials using RSA keys unless you don't want ZKPs. Also, credentials are not associated with any given DID that you have. Credentials live outside of your DIDs. Credentials are issued from an Issuer who has a public DID but thats the only DID tied to a credential. The idea is that you can use your credentials with any connection just like in the real world.

iamtxena (Thu, 30 May 2019 14:57:55 GMT):
@MALodder yep, but I would like that to issue a credential with the Issuer keys (that happens to be RSA), which will be linked to the public Issuer of a DID.

MALodder (Thu, 30 May 2019 14:58:28 GMT):
So you don't want ZKPs?

iamtxena (Thu, 30 May 2019 14:59:10 GMT):
For now it is not mandatory, but it can be useful.

MALodder (Thu, 30 May 2019 14:59:34 GMT):
then why even use indy? You get this with existing PKI systems

MALodder (Thu, 30 May 2019 15:03:41 GMT):
Indy is useful for having decentralized issuers and provides a network that doesn't require holders and verifiers to contact the issuer anytime they interact and share information. If you were to use RSA you're just implementing the existing PKI system on Indy. CL sigs don't require you to do selective disclosure. I'm failing to see why you wouldn't want ZKPs. Without them you are just requiring credentials holders to share everything in all presentations

iamtxena (Thu, 30 May 2019 15:11:00 GMT):
Yes, so the idea is to expand the use of PKI systems with decentralized issuers, so more companies coud be easy to make them do an onboarding to SSI Systems. And yes, ZKPs would be a great capability to use. So, for what I understand Indy is using Ed25519 for DIDs and CL sigs on credentials to use the selective disclosure.

MALodder (Thu, 30 May 2019 15:11:52 GMT):
Correct but I wouldn't try to let them continue to use RSA otherwise there aren't many benefits

Alexi (Thu, 30 May 2019 15:14:54 GMT):
Hello, I was wondering if someone from the bcgov team (or anyone that is familiar with their indy-catalyst project) could help me out. I've got an agent running per these instructions: https://github.com/bcgov/indy-catalyst/tree/master/agent however once it's running I was wondering what the http requests that can be made to it are as the documentation detailing this is not on there yet, namely connections and credentialing. Appreciate the help!

ianco (Thu, 30 May 2019 16:25:00 GMT):
Check out the demo here - it shows the basic Alice/Faber thread of connecting, issuing a credential and then asking for a proof: https://github.com/bcgov/indy-catalyst/tree/master/agent/demo

ianco (Thu, 30 May 2019 16:27:53 GMT):
You can also open up the swagger page for the admin port of the service

ianco (Thu, 30 May 2019 16:28:03 GMT):
... specified when you run the agent, as:

ianco (Thu, 30 May 2019 16:28:21 GMT):
``` --admin 0.0.0.0 ```

Alexi (Thu, 30 May 2019 16:36:00 GMT):
awesome, thanks for the tips!

ianco (Thu, 30 May 2019 16:36:45 GMT):
:+1:

paliwalg (Fri, 31 May 2019 08:22:58 GMT):
Has joined the channel.

bricg (Fri, 31 May 2019 10:58:25 GMT):
I have recently upgraded to indy-sdk 1.8.3 and indy-node 1.7.1 and am trying to create a new local indy-node network. I have include 3 transactions in the domain_transactions_genesis file to allocate 1 Trustee and 2 Stewards. When I read the ledger to get Nym information about one of the Stewards it returns role=2 as expected. Then I try to write to the ledger using the same Steward DID, however it fails with the following error. Has anyone seen this before or can they point me to what I might be doing wrong. Thanks. ```client request invalid: UnauthorizedClientRequest('Rule for this action is: 1 STEWARD signature is required OR 1 TRUSTEE signature is required', ```

bricg (Fri, 31 May 2019 10:58:25 GMT):
I have recently upgraded to indy-sdk 1.8.3 and indy-node 1.7.1 and am trying to create a new local indy-node network. I have included 3 transactions in the domain_transactions_genesis file to allocate 1 Trustee and 2 Stewards. When I read the ledger to get Nym information about one of the Stewards it returns role=2 as expected. Then I try to write to the ledger using the same Steward DID, however it fails with the following error. Has anyone seen this before or can they point me to what I might be doing wrong. Thanks. ```client request invalid: UnauthorizedClientRequest('Rule for this action is: 1 STEWARD signature is required OR 1 TRUSTEE signature is required', ```

bricg (Fri, 31 May 2019 10:58:25 GMT):
I have recently upgraded to indy-sdk 1.8.3 and indy-node 1.7.1 and am trying to create a new local indy-node network. I have included 3 transactions in the domain_transactions_genesis file to allocate 1 Trustee and 2 Stewards. When I read the ledger to get Nym information about one of the Stewards it returns role=2 as expected. Then I try to write to the ledger using the same Steward DID, however it fails with the following error. Has anyone seen this before or can they point me to what I might be doing wrong? Thanks. ```client request invalid: UnauthorizedClientRequest('Rule for this action is: 1 STEWARD signature is required OR 1 TRUSTEE signature is required', ```

bricg (Fri, 31 May 2019 10:58:25 GMT):
I have recently upgraded to indy-sdk 1.8.3 and indy-node 1.7.1, (so have switched from protocol 1 to 2, as I was on quite an old version beforehand) and am trying to create a new local indy-node network. I have included 3 transactions in the domain_transactions_genesis file to allocate 1 Trustee and 2 Stewards. When I read the ledger to get Nym information about one of the Stewards it returns role=2 as expected. Then I try to write to the ledger using the same Steward DID, however it fails with the following error. Has anyone seen this before or can they point me to what I might be doing wrong? Thanks. ```client request invalid: UnauthorizedClientRequest('Rule for this action is: 1 STEWARD signature is required OR 1 TRUSTEE signature is required', ```

bricg (Fri, 31 May 2019 14:02:26 GMT):
Ok, I have figured out the issue. In the the domain_transactions_genesis file, the role value needs to be a string (e.g. "2"), rather than an enum as integer suggested by the documentation.

smithbk (Fri, 31 May 2019 21:07:08 GMT):
Does anyone know if there are any typescript definitions for the node.js wrapper? I don't see any `.ts` files so I'm guessing not, but would like to make sure.

kdenhartog (Fri, 31 May 2019 23:15:45 GMT):
I don't believe there are. @joegenereux has been the one in the space I know that likes to use typescript. Maybe he may know something.

joegenereux (Fri, 31 May 2019 23:15:45 GMT):
Has joined the channel.

joegenereux (Fri, 31 May 2019 23:19:01 GMT):
@kdenhartog @smithbk are we talking about the Indy-SDK wrapper or the libvcx wrapper? Indy-sdk does not have typings (it really SHOULD), libvcx has typings

kdenhartog (Fri, 31 May 2019 23:19:19 GMT):
This would be IndySDK I believe

joegenereux (Fri, 31 May 2019 23:19:37 GMT):
Yeah well no luck there. Unfortunately it’s all native JS

smithbk (Sat, 01 Jun 2019 01:35:59 GMT):
Yes, I was asking about indy-sdk wrapper, not libvcx. Thanks

Dubh3124 (Sat, 01 Jun 2019 02:39:47 GMT):
Repost from #indy, seem better fitted here: I am trying to validate a user's DID is on the ledger before storing into a wallet, however, it seems when calling did.key_for_did the DID gets stored because when I call did.store_their_did I get Wallet item already exist error. Is validating a DID before storing the wrong way to go about it? Link to code https://codeshare.io/50Z6ln

Dubh3124 (Sat, 01 Jun 2019 02:39:47 GMT):
Repost from #indy, seem better fitted here: I am trying to validate a user's DID is on the ledger before storing into a wallet, however, it seems when calling `did.key_for_did` the DID gets stored because when I call `did.store_their_did` I get Wallet item already exist error. Is validating a DID before storing the wrong way to go about it? Link to code https://codeshare.io/50Z6ln

Dubh3124 (Sat, 01 Jun 2019 02:49:08 GMT):
Oh maybe I can user `ledger. build_get_ddo_request` thats a new one

Dubh3124 (Sat, 01 Jun 2019 02:49:08 GMT):
Oh maybe I can user `ledger. build_get_ddo_request` thats a new one ... atleast for me

Dubh3124 (Sat, 01 Jun 2019 03:16:01 GMT):
Ah figured it out, I can use `ledger.build_get_nym_request` and verify `data` key-value pair is not null

Dubh3124 (Sat, 01 Jun 2019 03:34:18 GMT):
....or even simpler use `did.key_for_did` to verify and store in a single call. Haha It gives a nice error message when the DID does not exist `, {'backtrace': '', 'message': "Error: Wallet item not found\n Caused by: Their DID isn't found on the ledger\n"`

Dubh3124 (Sat, 01 Jun 2019 03:59:03 GMT):
Downside of using `did.key_for_did`, you cannot store did metadata in one call like did.store_their_did, but still less work than building request, submitting request, verifying response and then storing did.

spacemandev (Mon, 03 Jun 2019 03:44:45 GMT):
hey all

paliwalg (Mon, 03 Jun 2019 04:18:04 GMT):
Hi, I tried running the Indy Demo, not sure how the agent connects to underlying indy node. No where in the code, see any configuration in the agent or sdk pointing to underlying Indy Node. In the genesis transaction there are details of 4 Indy Nodes but which one the agent connects to. I believe Alice agent connects to Node1 IndyNode but couldn't figure out this configuration. Thanks

kdenhartog (Mon, 03 Jun 2019 07:49:10 GMT):
@paliwalg the messages being sent to the nodes is handled by the rust code of the IndySDK. I believe more specifically that it's the pool service that is handling the message being sent to the nodes. As far as which node is contacted, i believe it tries one node first and then if it fails it will broadcast to more. However, the demo runs all 4 nodes in a single docker container at different ports, so typically if one fails they all fail in the demo. In production instances they are being ran on separate servers and the nodes are able to pass messages around through the plenum consensus algorithm.

spacemandev (Mon, 03 Jun 2019 08:38:25 GMT):
is there a way to build and package indy-sdk without needing to point to a path for libindy?

spacemandev (Mon, 03 Jun 2019 08:39:14 GMT):
ie, can indy-sdk be precompiled and then uploaded as a package with libindy part of the self contained package such that it doesn't need to built on npm install?

paliwalg (Mon, 03 Jun 2019 09:29:34 GMT):
ok, so in production, say Faber will be hosting hosting Indy Node 2(port 9703 and 9704) and its agent node in its infrastructure behind the firewall. Preferably faber agent will be allowed to access only port 9703. Access to other Indy Nodes for Faber agent will be obviously blocked, so Agent node should connect to Indy Node 2 only rather then try connecting to other Indy Nodes for efficiency reasons

paliwalg (Mon, 03 Jun 2019 11:10:16 GMT):
So I tried running indy nodes from https://github.com/hyperledger/indy-sdk/tree/master/samples/nodejs

paliwalg (Mon, 03 Jun 2019 11:10:16 GMT):
So I tried running indy nodes from https://github.com/hyperledger/indy-sdk/tree/master/samples/nodejs modified the script to expose ports 9701 only, and then tried running src/main.js script, it keeps on failing with PoolLedgerTimeOut. It got running successfully when I exposed ports from 9701 to 9704. Couldn't relate to understand this behaviour

glotov (Mon, 03 Jun 2019 12:09:51 GMT):
Has joined the channel.

glotov (Mon, 03 Jun 2019 12:10:28 GMT):
Hi! How can I install libindy to Ubuntu 18.04 bionic? Indy-sdk's readme only refers 16.04 xenial. Should I try to build it from source for 18.04?

sklump (Mon, 03 Jun 2019 12:15:39 GMT):
Only ubuntu 16 is supported

glotov (Mon, 03 Jun 2019 12:17:32 GMT):
huh, I tried ubuntu 16.04, but apt update complained `The repository 'https://repo.sovrin.org/sdk/deb xenial Release' does not have a Release file.`

sklump (Mon, 03 Jun 2019 12:59:44 GMT):
Try as per lines 36-41 https://github.com/PSPC-SPAC-buyandsell/von_base/blob/257a1102561b152f67034e7b108f34d2a7f5876d/setup#L38

sklump (Mon, 03 Jun 2019 12:59:44 GMT):
Try as per lines 36-41 https://github.com/PSPC-SPAC-buyandsell/von_base/blob/257a1102561b152f67034e7b108f34d2a7f5876d/setup#L38 perhaps?

sercher (Mon, 03 Jun 2019 13:42:41 GMT):
Has joined the channel.

sercher (Mon, 03 Jun 2019 13:42:41 GMT):
Hi everyone! I am trying to figure out how to build URSA-compatible (libindy 1.9.x) indy-pool docker image. In `indy-sdk/ci/indy-pool.dockerfile` I see that `libindy-crypto` version 0.4.5 is being installed. Can anyone help or point me at where to read about how to generate sn up to date indy-pool?

kdenhartog (Mon, 03 Jun 2019 16:23:34 GMT):
each node has 2 ports open. One port is specifically for communication between other nodes, while the other port is used to receive incoming requests and provide responses. Make sure that you're closing the proper ones.

evanv03 (Mon, 03 Jun 2019 16:50:37 GMT):
Hello all, I have a quick question. On an adapted version of the getting-started problem for python where I merely broke the code up into the separate clients my anoncreds.verifier_verify_proof is returning a false. Upon checking my own results for each of the factors that go into the function looking over it it seemed similar. I was wondering if there is anyway to test individual steps of the example to ensure that it is in fact running properly. Are there any functions that can check that proofs are being generated correctly/revocation registries are being used correctly that would throw an error if not?

evanv03 (Mon, 03 Jun 2019 16:51:47 GMT):
also does the "encoded" value within credentials actually have to be an encoding or can in be a random string of numbers so long as integers are encoded as themselves?

sklump (Mon, 03 Jun 2019 16:56:55 GMT):
@evanv03 there are no sanity checkers as such. I suggest you capture the output from each step on a straightforward known-good path, then compare against the experimental to see what's going wrong. Also, setting the log levels more chatty can help (`export RUST_BACKTRACE=full` in the shell). The encoding design particulars are currently out of scope for indy-sdk: the code operates on encoded values; it is up to the implementation to map from raw to encoded. I suggest SHA-256(string(original)).

sklump (Mon, 03 Jun 2019 16:57:49 GMT):
Known-good paths are generally available in code under indy-sdk/wrappers/python/tests/. Start from one of these and tweak one thing at a time.

evanv03 (Mon, 03 Jun 2019 16:59:30 GMT):
thanks

paliwalg (Tue, 04 Jun 2019 03:29:36 GMT):
correct, communication between nodes has no impact of NOT exposing the ports since they all are running with in the same docker container and I have used IP as 127.0.0.1. However the sample program (src/main.js) could't connect to the ledger

kdenhartog (Tue, 04 Jun 2019 05:42:41 GMT):
Doe it work when you don't shut down any ports? Also at a high level what are you trying to accomplish by turning ports off?

paliwalg (Tue, 04 Jun 2019 06:07:16 GMT):
yes , it works when I expose other ports. In production each party will have access to their own Indy Node only, so that's the reason I wanted to run the sample program(src/main.js) only with one port 9701 open

kdenhartog (Tue, 04 Jun 2019 06:11:21 GMT):
If you close the port where transactions are sent in the IndySDK won't be able to send any messages to the Nodes. The node is not designed to have transactions loaded into memory directly. It expects all messages to come over the network.

kdenhartog (Tue, 04 Jun 2019 06:12:20 GMT):
Also, how many nodes are you planning to run? If it's greater than about 25 consensus will significantly slow because it's O(n^2)

paliwalg (Tue, 04 Jun 2019 06:28:30 GMT):
correct, so 9701 port is for sdk to node communication, and I have it exposed. Since all the indy nodes are with in the same container, so node to node communication happens with no need to expose other ports

kdenhartog (Tue, 04 Jun 2019 07:53:00 GMT):
while they are contained within the same container, they still require a port to be open. Logically, they are separate even though they exist within the same container. They communicate over libZMQ which the nodes are looking for specific ports that are specified in the genesis_txn_file

lovesh (Tue, 04 Jun 2019 08:00:11 GMT):
A lot of methods in indy-crypto's as well as Ursa's FFI for anoncreds functions return success even if there is an error. This should not be the case. Or am i missing something? Have a look at this commit where i have fixed them in Ursa https://github.com/lovesh/ursa/commit/f8e04193e82bbe6737b1b2962ec7d019aeca0aa5. How is indy-sdk handling it? @MALodder @wightman @sergey.minaev

lovesh (Tue, 04 Jun 2019 08:00:11 GMT):
A lot of methods in indy-crypto's as well as Ursa's FFI for anoncreds functions *return success even if there is an error*. This should not be the case. Or am i missing something? Have a look at this commit where i have fixed them in Ursa https://github.com/lovesh/ursa/commit/f8e04193e82bbe6737b1b2962ec7d019aeca0aa5. How is indy-sdk handling it? @MALodder @wightman @sergey.minaev

lovesh (Tue, 04 Jun 2019 08:00:11 GMT):
A lot of methods in indy-crypto's as well as Ursa's FFI for anoncreds functions *return success even if there is an error*. This should not be the case. Or am i missing something? Have a look at this commit where i have fixed them in Ursa https://github.com/lovesh/ursa/commit/f8e04193e82bbe6737b1b2962ec7d019aeca0aa5 for the function names. How is indy-sdk handling it? @MALodder @wightman @sergey.minaev

lovesh (Tue, 04 Jun 2019 08:00:11 GMT):
A lot of methods in indy-crypto's as well as Ursa's FFI for anoncreds functions *return success even if there is an error*. This should not be the case. Or am i missing something? Have a look at this commit where i have fixed them in Ursa https://github.com/lovesh/ursa/commit/a81a8f2a91f78f6ab19a3220a3788c151d651e70 for the function names. How is indy-sdk handling it? @MALodder @wightman @sergey.minaev

glotov (Tue, 04 Jun 2019 08:42:35 GMT):
Hi, I managed to apt install libindy (1.9.0~75) to Ubuntu 16.04 as described in readme, but then, trying `npm install` in samples/nodejs, I see these compilation errors: ``` npm ERR! prepareGitDep > indy-sdk@1.9.0 install /home/DIR/denis.glotov/src/indy-sdk/wrappers/nodejs npm ERR! prepareGitDep > node-gyp rebuild npm ERR! prepareGitDep npm ERR! prepareGitDep make: Entering directory '/home/DIR/denis.glotov/src/indy-sdk/wrappers/nodejs/build' npm ERR! prepareGitDep CXX(target) Release/obj.target/indynodejs/src/indy.o npm ERR! prepareGitDep indynodejs.target.mk:105: recipe for target 'Release/obj.target/indynodejs/src/indy.o' failed npm ERR! prepareGitDep make: Leaving directory '/home/DIR/denis.glotov/src/indy-sdk/wrappers/nodejs/build' npm ERR! prepareGitDep npm ERR! prepareGitDep 2> npm WARN install Usage of the `--dev` option is deprecated. Use `--only=dev` instead. npm ERR! prepareGitDep ../src/indy.cc: In function ‘Nan::NAN_METHOD_RETURN_TYPE buildAcceptanceMechanismsRequest(Nan::NAN_METHOD_ARGS_TYPE)’: npm ERR! prepareGitDep ../src/indy.cc:2165:132: error: ‘indy_build_acceptance_mechanisms_request’ was not declared in this scope npm ERR! prepareGitDep indyCalled(icb, indy_build_acceptance_mechanisms_request(icb->handle, arg0, arg1, arg2, arg3, buildAcceptanceMechanismsRequest_cb)); npm ERR! prepareGitDep ^ npm ERR! prepareGitDep ../src/indy.cc: In function ‘Nan::NAN_METHOD_RETURN_TYPE buildGetAcceptanceMechanismsRequest(Nan::NAN_METHOD_ARGS_TYPE)’: npm ERR! prepareGitDep ../src/indy.cc:2188:133: error: ‘indy_build_get_acceptance_mechanisms_request’ was not declared in this scope npm ERR! prepareGitDep indyCalled(icb, indy_build_get_acceptance_mechanisms_request(icb->handle, arg0, arg1, arg2, buildGetAcceptanceMechanismsRequest_cb)); ```

glotov (Tue, 04 Jun 2019 08:45:48 GMT):
I used todays master branch, maybe should I use some stable tag of indy-sdk repo?

ibrahimel (Tue, 04 Jun 2019 08:51:30 GMT):
Has joined the channel.

sergey.minaev (Tue, 04 Jun 2019 10:55:07 GMT):
Indy Node and Plenum haven't been migrated to URSA as some required artifacts and CD steps missed for URSA. @MALodder has more details about schedule of that part of URSA delivery.

sercher (Tue, 04 Jun 2019 10:57:36 GMT):
Thank you for information.

DougKing (Tue, 04 Jun 2019 14:24:50 GMT):
Has joined the channel.

djathomson (Tue, 04 Jun 2019 22:01:52 GMT):
Has joined the channel.

djathomson (Tue, 04 Jun 2019 22:01:53 GMT):
Greetings all, I have a question around formatting proofRequests and credentials

djathomson (Tue, 04 Jun 2019 22:04:57 GMT):
Greetings all, I have a question around formatting proof requests with associated credentials. I have it able to validate, but not with a specific predicate, which always seems to return IndyError "CommonInvalidStructure" (JSON error), but I haven't been able to find good documentation on how these need to be formatted. https://github.com/hyperledger/indy-sdk/blob/master/docs/how-tos/negotiate-proof/nodejs/negotiateProof.js is one resource, but I haven't been able to get the right combination of attributes in the request, here is my json:``` ```

djathomson (Tue, 04 Jun 2019 22:05:01 GMT):
Proof req: { "requested_predicates": { "predicate1_referent": { "p_value": 21, "p_type": ">=", "name": "Age" } }, "requested_attributes": { "attr1_referent": { "restrictions": [ { "cred_def_id": "19691c38-1d53-42f8-843c-72db9df08b67" } ], "name": "UserName" } }, "version": "0.1", "name": "AgeProof", "nonce": "6997595590" } Proof cred: { "self_attested_attributes": {}, "requested_attributes": { "attr1_referent": { "cred_id": "19691c38-1d53-42f8-843c-72db9df08b67", "revealed": true } }, "requested_predicates": { "predicate1_referent": { "cred_id": "19691c38-1d53-42f8-843c-72db9df08b67" } } }

vsadriano (Wed, 05 Jun 2019 14:06:53 GMT):
Hi! I'm trying to add a new STEWARD and getting the error bellow: ```shell Transaction has been rejected: Client request is discarded since view change is in progress ``` What is it?

esplinr (Wed, 05 Jun 2019 14:06:57 GMT):
Indy SDK working group starting now: https://zoom.us/j/715671233

esplinr (Wed, 05 Jun 2019 14:07:17 GMT):
https://wiki.hyperledger.org/display/indy/2019-06-05+Indy+SDK+Working+Group+Agenda

lynn.bendixsen (Wed, 05 Jun 2019 15:05:28 GMT):
@vsadriano I have seen that error in a couple of different cases, but what it is literally saying is that the network is in the process of completing a view change (setting a new master and changing the primary nodes). The network will not add a new Steward while that process is occurring. Wait a few minutes for the view change to complete and then try again. If it continues to give the error over extended time, then there is a more serious issue and more details will be required to be able to diagnose it.

spacemandev (Wed, 05 Jun 2019 15:31:39 GMT):
hey so i am a little confused about how agents are built using indy-sdk: is the native compile step required for installing and using indy-sdk ie, trying to bundle wallet functionality into things like a chrome extension or serverless functions and trying to figure out how to 'bundlde' compiled libraries

smithbk (Wed, 05 Jun 2019 15:56:48 GMT):
Hi anyone, is it possible for the value of an attribute to be json rather than a string? Obviously an issuer could stringify the value and have the verifier unstringify, but just wondering if that is supposed to work without doing that.

sklump (Wed, 05 Jun 2019 16:12:38 GMT):
@smithbk the toolkit operates on strings.

swcurran (Wed, 05 Jun 2019 18:41:32 GMT):
@smithbk - json is a string though if you look at it in the right way :-). It would be treated as a single field, but nothing to prevent that.

swcurran (Wed, 05 Jun 2019 18:41:32 GMT):
@smithbk - json is a string though if you look at it in the right way :-). It would be treated as a single field, but nothing to prevent doing that.

smithbk (Wed, 05 Jun 2019 18:53:56 GMT):
@swcurran Yes, I was thinking the agent layer could stringify/unstringify but needs to keep metadata about which attributes have been stringified. And of course there would be no way to selectively disclose only part of the structure. Is that what you mean?

swcurran (Wed, 05 Jun 2019 19:00:09 GMT):
Exactly. I missed your earlier comment. Per Nathan et al. the crypto requirements are such that the schema structure needs to be a flat structure, so arrays and structures would not be selectively disclosed.

Dubh3124 (Thu, 06 Jun 2019 09:11:25 GMT):
I am trying to create a credential, however, I keep getting a "Wallet item not found" error; I am not sure what item I am missing since the log isn't specific. I notice cred_offer, cred_req and cred_vaules_json is "_" is that the proper response? I have confirmed I passed in the right parameters. https://codeshare.io/24de7j ``` DEBUG:indy.libindy.native.indy.commands.anoncreds.issuer: src/commands/anoncreds/issuer.rs:503 | new_credential >>> wallet_handle: WalletHandle(3), cred_offer: "_", cred_req: "_", cred_values_json: "_", rev_reg_id: Some("9H1Z5JXZWBRkP43Co2Qi7T:3:CL:37:GovCred s8_def"), blob_storage_reader_handle: Some(4) DEBUG:indy.libindy:_get_error_details: >>> DEBUG:indy.libindy:_get_error_details: <<< error_details: {'backtrace': '', 'message': 'Error: Wallet item not found\n Caused by: Wallet item not found\n'} DEBUG:indy.libindy:_indy_callback: >>> command_handle: 7, err (, {'backtrace': '', 'message': 'Error: Wallet item not found\n Caused by: Wallet item not found\n'}), args: (b'', None, None) DEBUG:indy.libindy:_indy_callback: <<< DEBUG:indy.libindy:do_call: Function indy_issuer_create_credential returned err: 0 DEBUG:indy.libindy:do_call: <<< DEBUG:indy.libindy:_indy_loop_callback: >>> command_handle: 7, err (, {'backtrace': '', 'message': 'Error: Wallet item not found\n Caused by: Wallet item not found\n'}), args: (b'', None, None) WARNING:indy.libindy:_indy_loop_callback: Function returned error (, {'backtrace': '', 'message': 'Error: Wallet item not found\n Caused by: Wallet item not found\n'}) DEBUG:indy.libindy:_indy_loop_callback <<< ERROR:indydev:Error while executing function: create_credential Traceback (most recent call last): File "/home/quart/maindir/indyutils/utils.py", line 29, in wrapped resp = await func(*args, **kwargs) File "/home/quart/maindir/indyutils/issuance.py", line 235, in create_credential await self.tails_reader File "/home/quart/venv/lib/python3.7/site-packages/indy/anoncreds.py", line 325, in issuer_create_credential issuer_create_credential.cb) indy.error.IndyError: (, {'backtrace': '', 'message': 'Error: Wallet item not found\n Caused by: Wallet item not found\n'}) ```

DucaDellaForcoletta (Thu, 06 Jun 2019 14:22:31 GMT):
Hi everyone, I'm checking the credential revocation flow. I've a doubt abount tails config: The function in blob_storage are not documented as the others. Looking the test_interation, the tails config is: tails_writer_config = json.dumps({'base_dir': str(path_home.joinpath("tails")), 'uri_pattern': ''}). What about the uri_pattern? Since also the prover should use a tails reader and the base dir is a local path, in order to create the revocation_state, in the uri pattern can be set the URI to the revocation registry file? Thanks for answers.

sklump (Thu, 06 Jun 2019 14:33:38 GMT):
@DucaDellaForcoletta you might enjoy https://github.com/PSPC-SPAC-buyandsell/von_tails to sync issuer and holder tails files against a tails file server.

sklump (Thu, 06 Jun 2019 14:33:38 GMT):
@DucaDellaForcoletta At present, indy supports only read/write on local file system. You might enjoy https://github.com/PSPC-SPAC-buyandsell/von_tails to sync issuer and holder tails files against a tails file server. Anoncreds-2.0 will likely eliminate tails files in a substantial revocation makeover.

DucaDellaForcoletta (Thu, 06 Jun 2019 14:56:35 GMT):
@sklump Thanks so much. I'll implement a service for the prover in the ssi-agent in order to serve the access to the tails for the prover and verifier. I do this also for the other service like get schema def and get credential defs. Do you know when anoncreds 2.0 will be released?

sklump (Thu, 06 Jun 2019 15:05:05 GMT):
* see the test code for boilerplate and the docs for some sample cron config on sync scripts for holder and issuer. * If you're putting in trust anchors, you might as well look at VON anchor to see if it meets your needs. They forecast anoncreds-2.0 for August, but that may slip because there is a lot of work for a few cryptographers and fellow travellers. You don't need any sync scripts or outside actors to co-ordinate schema, cred defs, revocation registry defs and states since they live on the ledger.

sklump (Thu, 06 Jun 2019 15:05:05 GMT):
* see the test code for boilerplate and the docs for some sample cron config on sync scripts for holder and issuer. * If you're putting in trust anchors, you might as well look at VON anchor to see if it meets your needs. They forecast anoncreds-2.0 for August, but _(my opinion only)_ that may slip because there is a lot of work for a few cryptographers and fellow travellers. You don't need any sync scripts or outside actors to co-ordinate schema, cred defs, revocation registry defs and states since they live on the ledger, and the consensus protocol ensures consistency.

DucaDellaForcoletta (Thu, 06 Jun 2019 15:14:11 GMT):
@sklump Thanks so much for the support.

sklump (Thu, 06 Jun 2019 15:15:40 GMT):
Welcome my son. Welcome to the machine.

sergey.minaev (Fri, 07 Jun 2019 16:55:37 GMT):
Hi, I suggest to enable logs and analyze or share few lines above the error. In log we will be able to find more context about the reason of the error.

smithbk (Fri, 07 Jun 2019 17:59:54 GMT):
Can someone tell me what exactly would cause this error ```Error: Invalid structure\n Caused by: IndyCryptoError: Credential doesn't correspond to credential schema``` Thanks

msgraber (Fri, 07 Jun 2019 19:38:43 GMT):
Has joined the channel.

msgraber (Fri, 07 Jun 2019 19:38:44 GMT):
We're trying to get the nodejs sample to build on Windows and encountering the following error: "npm ERR! prepareGitDep LINK : fatal error LNK1181: cannot open input file '.lib' [C:\SoftwareDevelopment\Unfolding\HyperLedger SDK\indy-sdk\wrappers\nodejs\build\indynodejs.vcxproj]" any ideas what would cause this?

msgraber (Fri, 07 Jun 2019 19:48:53 GMT):
In the samples/nodejs folder I ran npm install indy-sdk --save and encountered this error. I'm running on Windows 10 Professional.

josh.graber (Fri, 07 Jun 2019 20:34:47 GMT):
I'm working with Steve on resolving this issue, but we can't figure out how this `npm prepare` script ever works when installing from the global npm registry: https://github.com/hyperledger/indy-sdk/blob/master/wrappers/nodejs/package.json#L26

josh.graber (Fri, 07 Jun 2019 20:35:03 GMT):
It appears to copy files from a local folder which would not exist if pulling this from a registry

josh.graber (Fri, 07 Jun 2019 20:35:32 GMT):
*Clarification: it copies *.h files from a folder higher in the indy-sdk repository which are not included in the npm registry

josh.graber (Fri, 07 Jun 2019 20:35:32 GMT):
Clarification: it copies *.h files from a folder higher in the indy-sdk repository which are not included in the npm registry

josh.graber (Fri, 07 Jun 2019 20:39:43 GMT):
The binding.gyp file also appears to refer to a parent folder from the indy-sdk repo that it does not seem would be present when pulling from the npm registry: https://github.com/hyperledger/indy-sdk/blob/master/wrappers/nodejs/binding.gyp#L8

josh.graber (Fri, 07 Jun 2019 20:40:39 GMT):
I would expect only these files from the `indy-sdk/wrappers/nodejs` folder to be in the npm registry: https://github.com/hyperledger/indy-sdk/blob/master/wrappers/nodejs/package.json#L20-L24

josh.graber (Fri, 07 Jun 2019 20:41:01 GMT):
So ../../libindy/includes wouldn't resolve to anything meaningful?

josh.graber (Fri, 07 Jun 2019 20:41:01 GMT):
So `../../libindy/includes` wouldn't resolve to anything meaningful?

andrew.whitehead (Fri, 07 Jun 2019 22:21:27 GMT):
I believe `prepare` is only run when creating the npm package (ie. when you have the source available), not when installing the package from the global registry

josh.graber (Fri, 07 Jun 2019 22:23:21 GMT):
That would make more sense. This document implies it might happen in both cases: https://docs.npmjs.com/misc/scripts

josh.graber (Fri, 07 Jun 2019 22:24:01 GMT):
Also doesn't explain the relative path in `binding.gyp`

josh.graber (Fri, 07 Jun 2019 22:55:25 GMT):
The above npm document refers to local `npm install` but perhaps that is only talking about installing the dependencies of the nodejs indy-sdk wrapper, not when installing nodejs indy-sdk as a dependency. Doesn't explain the `binding.gyp` reference, but perhaps that is only optional?

josh.graber (Fri, 07 Jun 2019 22:55:49 GMT):
Not sure why Windows can't find the dll when running `npm install indy-sdk --save` then...

josh.graber (Fri, 07 Jun 2019 22:55:59 GMT):
`node-gyp` seems to fail when building or linking

josh.graber (Fri, 07 Jun 2019 22:56:15 GMT):
dlls are added to the path, but apparently not in the way something wants

josh.graber (Fri, 07 Jun 2019 22:57:43 GMT):
the include folder does make it into the npm registry, just confirmed that, so your explanation seems to fit perfectly

andrew.whitehead (Fri, 07 Jun 2019 23:13:35 GMT):
Are the dlls in LD_LIBRARY_PATH?

mccartneypaul (Tue, 11 Jun 2019 13:17:07 GMT):
Has joined the channel.

Alexi (Wed, 12 Jun 2019 21:57:55 GMT):
what is the best practice for the DID metadata? i.e what is it used for / what information generally is stored here

swcurran (Wed, 12 Jun 2019 22:58:26 GMT):
^^ @andrew.whitehead - Andrew, can you point out where in the indy-catalyst agent what data we're tracking for a connection and how it is stored?

andrew.whitehead (Wed, 12 Jun 2019 23:04:21 GMT):
https://github.com/bcgov/indy-catalyst/blob/master/agent/indy_catalyst_agent/messaging/connections/models/connection_record.py

andrew.whitehead (Wed, 12 Jun 2019 23:04:46 GMT):
There's a PR pending that changes some of that. Agent-framework also has a similar structure

ashlinSajan (Thu, 13 Jun 2019 06:46:33 GMT):
Hi mgba

ashlinSajan (Thu, 13 Jun 2019 06:48:46 GMT):
Hi @swcurran Can we recover if we lose control of the wallet?

swcurran (Thu, 13 Jun 2019 14:22:50 GMT):
That is the plan. There needs to be backups taken and secured for recovery of a lost wallet. There also needs to be steps taken to guard from losing control (fingerprint/face id before accessing wallet). Many of these techniques will be borrowed from other eco-systems (e.g. remotely wipe your phone), some will be developed specifically for this (e.g. sharding a key for recovery). All agree it is a priority. As well I have heard about a planned mechanism that Evernym is developing that will enable authorizing and de-authorizing a specific device. So if that mechanism is in place and you lose your phone, you can de-authorize the phone such that it cannot be used to prove any credentials.

Alexi (Thu, 13 Jun 2019 20:50:54 GMT):
hello, for this HIPE https://github.com/hyperledger/indy-hipe/blob/master/text/0031-connection-protocol/README.md the response detail specifies that the 'connection' part of the response needs to be signed but does not detail how: *The above message is required to be signed as described in HIPE ???. The connection attribute above will be base64URL encoded and included as part of the sig_data attribute of the signed field.* Should it just be signed using crypto_sign()?

AxelNennker (Fri, 14 Jun 2019 19:28:56 GMT):
I think libindy should .gitignore Cargo.lock https://jira.hyperledger.org/browse/IS-1295

kdenhartog (Fri, 14 Jun 2019 19:41:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=pu9TdaTmave9yAKrb) @Alexi I'd suggest using the Aries-RFC 0066 for this. I originally was working on the HIPE that was supposed to go in there and abandoned that method in favor of 0066. There's demo code in the folder as well. In essence what you're saying is correct.

AxelNennker (Sun, 16 Jun 2019 08:58:21 GMT):
This sounds cool for Indy https://dependabot.com/docs/config-file/ It automatically detects new versions of dependencies and creates a pull request for them. Also does security PRs dependabot was acquired by Github and is now free

AxelNennker (Sun, 16 Jun 2019 09:41:37 GMT):
Created https://jira.hyperledger.org/browse/IS-1296

swcurran (Sun, 16 Jun 2019 15:04:08 GMT):
@AxelNennker - very cool - thanks for pointing that out. We need that in our world.

reithmayer (Mon, 17 Jun 2019 11:39:38 GMT):
Hi, is there any technical documentation about the payment system? What is the current development state of the payment functionality in indy-sdk?

sergey.minaev (Mon, 17 Jun 2019 14:26:08 GMT):
I used this bot several time last week (for indy-sdk) without configuration file. I'm able to see security tab in GH repo view and on this tab I can see issues and there is an option to push the bot to raise a PR with hotfix. Last 3 autoreports was about NodeJS problems. 1) What are the benefits to have a config file? (more correct determining of nested projects?) 2) Security PRs: > Also does security PRs will it be created automatically per detection or only by request?

sergey.minaev (Mon, 17 Jun 2019 14:27:07 GMT):
https://github.com/hyperledger/indy-sdk/tree/master/docs/design/004-payment-interface

yutopyan (Tue, 18 Jun 2019 14:37:57 GMT):
Has joined the channel.

esplinr (Wed, 19 Jun 2019 14:02:39 GMT):
Starting the SDK call: https://zoom.us/j/715671233

evanv03 (Wed, 19 Jun 2019 17:46:09 GMT):
does anyone know what "attr::::marker" refers to?

evanv03 (Wed, 19 Jun 2019 17:47:41 GMT):
as it is a created tag in proverStoreCredential. It is referenced here(https://github.com/hyperledger/indy-sdk/blob/master/wrappers/nodejs/README.md) but i cannot seem to find it anywhere else

sklump (Wed, 19 Jun 2019 17:52:02 GMT):
It marks the fact that the attribute is present. You could include it in WQL searches, give me back any credential with a 'name' attribute.

sklump (Wed, 19 Jun 2019 17:52:02 GMT):
It marks the fact that the attribute is present. You could include it in WQL searches, give me back any credential with a 'name' attribute, which could be present over several cred defs.

sklump (Wed, 19 Jun 2019 17:53:22 GMT):
Note that searches on attributes are only exact matches/mismatches, and so there is no better way to get back attr=* as far as I can see.

sklump (Wed, 19 Jun 2019 17:53:22 GMT):
Note that searches on attributes are only exact matches/mismatches (they're encrypted), and so there is no better way to get back attr=* as far as I can see.

evanv03 (Wed, 19 Jun 2019 17:54:01 GMT):
thanks, is there any way to add a new tag to be tracked upon storing a credential?

sklump (Wed, 19 Jun 2019 17:58:23 GMT):
Not as such. By default, the attr tag policy is to set attr::name::marker = 1, attr::name::value = for every attribute in the cred def. Effective indy-sdk 1.10.0, and experimentally in master at present, the API includes set_credential_attr_tag_policy() and get_credential_attr_tag_policy() to profile what gets stored. The default (null) is to store all of the above, but if you know you won't search on all tags, you can specify a collection of tags of interest per cred def, with a retroactive (bool) flag to back-propagate the policy to any existing credentials in the wallet on the cred def in question. From then on, if you search on a tag that's not in the policy, you won't find the credential, but it reduces data storage requirements.

evanv03 (Wed, 19 Jun 2019 17:58:32 GMT):
thanks

sklump (Wed, 19 Jun 2019 17:59:06 GMT):
I will be demonstrating this new feature on tomorrow's call. It's almost as though you were planted :-D

sukalpomitra (Thu, 20 Jun 2019 02:25:50 GMT):
Has joined the channel.

SergeyBrazhnik (Thu, 20 Jun 2019 10:33:10 GMT):
Hello everyone! Question about attributes in schema. Right now there is only case to point only schema attribute names. But I want to add type/format to this attributes like { "name": { "type": "Strung" }, "date": { "format": "dd-MM-yyyy" } } Is it possible? Could somebody say a workaroud for this? Or I need to create feature request in Jira?

sklump (Thu, 20 Jun 2019 10:43:39 GMT):
At present schema attributes are necessarily strings. The evolving rich schema work https://github.com/hyperledger/indy-hipe/pull/119 aims to allow for some semantics that could work toward what you propose.

SergeyBrazhnik (Thu, 20 Jun 2019 11:08:01 GMT):
Any information when somebody will start implementing this? :-)

DucaDellaForcoletta (Thu, 20 Jun 2019 12:07:01 GMT):
Hello everyone, anyone has info about the compliance of the indy claims to the W3C Verifiable Claims?

DucaDellaForcoletta (Thu, 20 Jun 2019 12:07:01 GMT):
Hello everyone, anyone has info about the compliance of the indy credentials to the W3C Verifiable Claims?

arjanvaneersel (Thu, 20 Jun 2019 12:45:47 GMT):
I'm trying to install libindy on Ubuntu, but I am wondering whether the instructions on https://github.com/hyperledger/indy-sdk#installing-the-sdk are still accurate? I get an error on this line: add-apt-repository "deb https://repo.sovrin.org/sdk/deb xenial {release channel}". Also {release channel}" looks kind of strange to me. Am I supposed to replace that with something?

arjanvaneersel (Thu, 20 Jun 2019 12:47:58 GMT):
For what it's worth: I am not really running Ubuntu, but creating an Ubuntu based Docker image so that I can run my tests for aries-sdk-go in that container, as I myself use another linux distro.

josh.graber (Thu, 20 Jun 2019 20:25:31 GMT):
Using the SDK, what is the best way to tell if a did has been recorded on the ledger or not?

josh.graber (Thu, 20 Jun 2019 20:25:51 GMT):
I tried using `indy_key_for_did` but it checks in the wallet first

josh.graber (Thu, 20 Jun 2019 20:26:07 GMT):
So if you try to verify that your own did has been recorded on the ledger, it just returns it from your wallet instead

josh.graber (Thu, 20 Jun 2019 20:26:48 GMT):
Just looking for a way to check that an issuer has been established as a trust anchor

andrew.whitehead (Thu, 20 Jun 2019 20:31:05 GMT):
@josh.graber I believe you need to use build_nym_request directly

josh.graber (Thu, 20 Jun 2019 20:32:03 GMT):
I'll take a closer look at that, thanks

josh.graber (Thu, 20 Jun 2019 20:33:20 GMT):
Does the `build_nym` request not add a txn to the ledger then?

josh.graber (Thu, 20 Jun 2019 20:34:22 GMT):
This is what I want: https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/api/ledger.rs#L435

andrew.whitehead (Thu, 20 Jun 2019 20:34:25 GMT):
Sorry, I mean `build_get_nym_request`

andrew.whitehead (Thu, 20 Jun 2019 20:34:25 GMT):
Sorry, I mean `build_get_nym_request` (in the python wrapper)

josh.graber (Thu, 20 Jun 2019 20:35:00 GMT):
Yeah, that's what I found in the rust lib

josh.graber (Thu, 20 Jun 2019 20:35:06 GMT):
Thanks! That looks like what I need

evanv03 (Thu, 20 Jun 2019 20:55:18 GMT):
does anyone know if you can have multiple revoc_regs for a single credential-definition?

smithbk (Thu, 20 Jun 2019 21:00:23 GMT):
Hi, can someone help? I'm using the node sdk (v1.9) to open a local ledger and getting a `Ledger merkle tree is not acceptable for current tree` error.

smithbk (Thu, 20 Jun 2019 21:00:36 GMT):
Here are the indy logs:

smithbk (Thu, 20 Jun 2019 21:01:02 GMT):

smithbk - Thu Jun 20 2019 17:00:44 GMT-0400 (Eastern Daylight Time).txt

burdettadam (Thu, 20 Jun 2019 21:24:42 GMT):
I just started to set up my environment to join @kenebert and @brentzundel in rich schema efforts. I am still coming up to speed, but feel free to join the cause and message me with any questions you have.

josh.graber (Thu, 20 Jun 2019 21:27:22 GMT):
@andrew.whitehead worked like a charm, FYI... thanks again!

swcurran (Thu, 20 Jun 2019 21:49:36 GMT):
@evanv03 - Pretty sure you can. You pre-allocate a number of Creds and if you run out, you can create another revoc_reg for that. @sklump is the guru of revocation and can confirm or set me straight. He has a lot of code and test cases that look at revocation.

swcurran (Thu, 20 Jun 2019 21:49:36 GMT):
@evanv03 - Pretty sure you can. You pre-allocate a number of Creds and if you run out, you can create another revoc_reg for and keep on issuing. @sklump is the guru of revocation and can confirm or set me straight. He has a lot of code and test cases that look at revocation.

evanv03 (Thu, 20 Jun 2019 22:26:52 GMT):
thanks

sklump (Fri, 21 Jun 2019 10:23:19 GMT):
The rev reg id is a parameter in the credential creation. There is no reason in principle why the Issuer couldn't keep several going in parallel, though I've never thought to do that. When the Issuer attempts to create a credential on a full rev reg, indy-sdk raises an AnoncredsRevocationRegistryFullError, whereupon the Issuer should create another (or use an existing, non-full) new one and try again: https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/2c2f14794f2daba1f57721e2fc0c78ed659b2cd1/von_anchor/anchor/issuer.py#L537 Revocation registry creation is expensive. Be sure that you have compiled libindy in release mode ``` $ cd indy-sdk/libindy $ cargo build --release $ sudo cp target/release/libindy.so /usr/lib ``` or else the operation will starve your host for potentially minutes, locking out other indy-sdk operations in the meantime.

sklump (Fri, 21 Jun 2019 10:23:19 GMT):
The rev reg id is a parameter in the credential creation. There is no reason in principle why the Issuer couldn't keep several going in parallel, though this approach seems of dubious added value. When the Issuer attempts to create a credential on a full rev reg, indy-sdk raises an AnoncredsRevocationRegistryFullError, whereupon the Issuer should create another (or use an existing, non-full) new one and try again: https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/2c2f14794f2daba1f57721e2fc0c78ed659b2cd1/von_anchor/anchor/issuer.py#L537 Revocation registry creation is expensive. Be sure that you have compiled libindy in release mode ``` $ cd indy-sdk/libindy $ cargo build --release $ sudo cp target/release/libindy.so /usr/lib ``` or else the operation will starve your host for potentially minutes, locking out other indy-sdk operations in the meantime. See VON anchor RevRegBuilder and Issuer for revocation registry building workarounds that do not lock out indy-sdk for minutes at a time.

FarhanShafiq (Fri, 21 Jun 2019 12:36:24 GMT):
Has joined the channel.

Zohaib_Sohail (Fri, 21 Jun 2019 13:44:58 GMT):
can someone please tell me the proper way to test predicates while presenting a proof? because the predicate is always happened to be true while the condition is false. maybe i am missing something but dont know what! I am using nodejs agent

FarhanShafiq (Fri, 21 Jun 2019 13:46:55 GMT):
Is there any way to connect Nodejs SDK with remote pool network? because i'm reading SDK documentation and there is no where mentioning of any sort of configuration.

Zohaib_Sohail (Fri, 21 Jun 2019 13:55:10 GMT):
have you seen this function createPoolLedgerConfig?

FarhanShafiq (Fri, 21 Jun 2019 14:00:47 GMT):
Thanks i checked it now but didn't know how to connect by creating ledger config.

FarhanShafiq (Fri, 21 Jun 2019 14:00:47 GMT):
Thanks i checked it now but still didn't know how to connect by creating ledger config.

FarhanShafiq (Fri, 21 Jun 2019 14:00:47 GMT):
Thanks i checked it now but still don't know how to connect by creating ledger config.

FarhanShafiq (Fri, 21 Jun 2019 14:05:06 GMT):
"String - Name of the pool ledger configuration". what is pool ledger configuration name??

Zohaib_Sohail (Fri, 21 Jun 2019 14:08:02 GMT):
name can be anything because it creates a local pool ledger configuration

Zohaib_Sohail (Fri, 21 Jun 2019 14:08:15 GMT):
but you need a configuration second param

Zohaib_Sohail (Fri, 21 Jun 2019 14:08:46 GMT):
which is the path of genesis

Zohaib_Sohail (Fri, 21 Jun 2019 14:08:46 GMT):
which is the path of genesisTxn

Zohaib_Sohail (Fri, 21 Jun 2019 14:09:53 GMT):
here is the link where you can change you genesis_txn to connect with you pool nodes

Zohaib_Sohail (Fri, 21 Jun 2019 14:09:55 GMT):
https://github.com/hyperledger/indy-agent/blob/63f37586e03ceb52798b548fb1d4d027babeb995/nodejs/indy/src/pool/index.js#L42

sklump (Fri, 21 Jun 2019 14:20:09 GMT):
Operationally speaking, the pool name is the directory under `~/.indy_client/pool/` and the file name for its genesis transactions. For example, pool name `pool1` corresponds to `~/.indy_client/pool/pool1/pool1.txn`.

FarhanShafiq (Fri, 21 Jun 2019 14:27:17 GMT):
Thanks @Zohaib_Sohail @sklump

burdettadam (Fri, 21 Jun 2019 20:44:35 GMT):
I am new to revocation, but looking at this documentation for a cred_def https://github.com/hyperledger/indy-node/blob/master/docs/source/requests.md#claim_def, the only thing stored on the ledger is the revocation public key. And looking at https://github.com/hyperledger/indy-node/blob/master/docs/source/requests.md#revoc_reg_def a revocation definition has a credDefId. So from this documentation, it looks to me like the only dependency for creating multiple revoc_reg_def for a single cred_def/claim_def is the public key used for revocation file creation. If indy-sdk allows revocation creation using the same public key this would work. https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/api/anoncreds.rs#L224 takes an issuer did as a parameter and after some digging. https://github.com/hyperledger/ursa/blob/master/libursa/src/cl/issuer.rs#L145 it looks like the issuer did's public key ends up being used as the revocation public key. so it looks like if you use the same issuer did for each revocation registry you should be able to issue credentials using a single credential definition with multiple revocation registries.

FarhanShafiq (Tue, 25 Jun 2019 09:20:27 GMT):
Is there anyway to get the credential def from wallet? I have created a credential def in wallet but unable to find a way to get cred def and cred def have yet to store in ledger.

sklump (Tue, 25 Jun 2019 12:42:36 GMT):
Not directly, no. The API reads the ledger for cred defs. Once the cred def is in the wallet, it ought to be possible to crawl through the rust source to figure out a way to dig it out with the non-secrets API. But this approach comes close to running counter to the design intent. The issuer should send the cred def to the ledger once it's created - they're meant to be public.

FarhanShafiq (Tue, 25 Jun 2019 12:49:43 GMT):
Thanks @sklump

sklump (Tue, 25 Jun 2019 12:57:07 GMT):
I recommend looking through von_anchor docs (https://github.com/PSPC-SPAC-buyandsell/von_anchor) and code base to do pretty much everything you've asked for so far. It's what I do to answer questions like yours.

FarhanShafiq (Tue, 25 Jun 2019 12:59:30 GMT):
Thank you so much, i will look into it deeply :)

FarhanShafiq (Tue, 25 Jun 2019 13:01:45 GMT):
Another Question: Is it possible to revoke credential by user and/or issuer without cred def supporting revocation?

sklump (Tue, 25 Jun 2019 13:15:13 GMT):
Nope

FarhanShafiq (Tue, 25 Jun 2019 13:15:32 GMT):
for both user & issuer ??

sklump (Tue, 25 Jun 2019 13:15:48 GMT):
Only the issuer can revoke a credential in any case.

FarhanShafiq (Tue, 25 Jun 2019 13:16:44 GMT):
Perfect.

sklump (Tue, 25 Jun 2019 13:16:58 GMT):
Supporting revocation opens up a lot of complications. Anoncreds 2.0 will change revocation design, so if you can wait until (Northern) autumn it might be easier on the implementation side.

sklump (Tue, 25 Jun 2019 13:18:16 GMT):
Another approach is to house goodness metadata outside the system (à la OrgBook), which amounts to a CRL

sklump (Tue, 25 Jun 2019 13:18:16 GMT):
Another approach is to house credential status (revoked/not-revoked) outside the system (à la OrgBook), which amounts to a CRL

sklump (Tue, 25 Jun 2019 13:19:32 GMT):
Or to include effective-from/effective-to attributes in credentials and then not reissue.

FarhanShafiq (Tue, 25 Jun 2019 13:20:21 GMT):
Great! i will look into all approaches.

FarhanShafiq (Tue, 25 Jun 2019 13:20:46 GMT):
Thank you so much :)

SethiSaab (Tue, 25 Jun 2019 13:34:45 GMT):
Has joined the channel.

wadeking98 (Tue, 25 Jun 2019 20:52:27 GMT):
Has joined the channel.

FarhanShafiq (Wed, 26 Jun 2019 07:55:31 GMT):
I'm creating proof for alice job application using nodejs SDK but facing error: indyCode: 107, indyName: 'CommonInvalidParam8',indyCurrentErrorJson: '{"backtrace":"","message":"Error: Invalid parameter 8\\n Caused by: Invalid pointer has been passed\\n"}'

FarhanShafiq (Wed, 26 Jun 2019 07:55:31 GMT):
I'm creating proof for alice job application using nodejs SDK but facing error: Error: indyCode: 107, indyName: 'CommonInvalidParam8',indyCurrentErrorJson: '{"backtrace":"","message":"Error: Invalid parameter 8\\n Caused by: Invalid pointer has been passed\\n"}' Code: get_cred_def_request = await indy.buildGetCredDefRequest(alice_did, transcript_cred_def_id) cred_def = await indy.signAndSubmitRequest(pool_handler, handler, alice_did, get_cred_def_request); parsed_cred_def = await indy.parseGetCredDefResponse(cred_def) apply_job_proof = await indy.proverCreateProof(handler, job_application_proof_request, job_application_requested_creds, alice_master_id, {transcript_schema_id:parsed_schema[1]}, {"cred_def1_id":parsed_cred_def[1]}, null)

FarhanShafiq (Wed, 26 Jun 2019 07:55:31 GMT):
I'm creating proof for Alice job application using nodejs SDK but facing error: Error: indyCode: 107, indyName: 'CommonInvalidParam8',indyCurrentErrorJson: '{"backtrace":"","message":"Error: Invalid parameter 8\\n Caused by: Invalid pointer has been passed\\n"}' Code: get_cred_def_request = await indy.buildGetCredDefRequest(alice_did, transcript_cred_def_id) cred_def = await indy.signAndSubmitRequest(pool_handler, handler, alice_did, get_cred_def_request); parsed_cred_def = await indy.parseGetCredDefResponse(cred_def) apply_job_proof = await indy.proverCreateProof(handler, job_application_proof_request, job_application_requested_creds, alice_master_id, {transcript_schema_id:parsed_schema[1]}, {"cred_def1_id":parsed_cred_def[1]}, null)

FarhanShafiq (Wed, 26 Jun 2019 07:55:31 GMT):
I'm creating proof for Alice job application using nodejs SDK but facing error: Error: { IndyError: CommonInvalidStructure at Object.callback (/home/farhan/Documents/indy/indy-middleware/node_modules/indy-sdk/src/wrapIndyCallback.js:16:10) name: 'IndyError', message: 'CommonInvalidStructure', indyCode: 113, indyName: 'CommonInvalidStructure', indyCurrentErrorJson: null } Code: job_application_proof_request = JSON.stringify({ 'nonce': '1432422343242122312411212', 'name': 'Job-Application', 'version': '0.1', 'requested_attributes': { 'attr1_referent': { 'name': 'first_name' }, 'attr2_referent': { 'name': 'last_name' }, 'attr3_referent': { 'name': 'degree', 'restrictions': [{ 'cred_def_id': transcript_cred_def_id }] }, 'attr4_referent': { 'name': 'status', 'restrictions': [{ 'cred_def_id': transcript_cred_def_id }] }, 'attr5_referent': { 'name': 'ssn', 'restrictions': [{ 'cred_def_id': transcript_cred_def_id }] }, 'attr6_referent': { 'name': 'phone_number' } }, 'requested_predicates': { 'predicate1_referent': { 'name': 'average', 'p_type': '>=', 'p_value': 4, 'restrictions': [{ 'cred_def_id': transcript_cred_def_id }] } } }) creds_for_job_application_proof_request = await indy.proverGetCredentialsForProofReq(handler, job_application_proof_request) const credForAttr1 = creds_for_job_application_proof_request["attrs"]["attr1_referent"] const referent = credForAttr1[0].cred_info.referent job_application_requested_creds = JSON.stringify({ 'self_attested_attributes': { 'attr1_referent': 'Alice', 'attr2_referent': 'Garcia', 'attr6_referent': '123-45-6789' }, 'requested_attributes': { 'attr3_referent': { 'cred_id': referent, 'revealed': true }, 'attr4_referent': { 'cred_id': referent, 'revealed': true }, 'attr5_referent': { 'cred_id': referent, 'revealed': true }, }, 'requested_predicates': { 'predicate1_referent': { 'cred_id': referent } } }) schema_request = await indy.buildGetSchemaRequest(gov_did, transcript_schema_id) cred_schema = await indy.signAndSubmitRequest(pool_handler, handler, alice_did, schema_request); parsed_schema = await indy.parseGetSchemaResponse(cred_schema) get_cred_def_request = await indy.buildGetCredDefRequest(alice_did, transcript_cred_def_id) cred_def = await indy.signAndSubmitRequest(pool_handler, handler, alice_did, get_cred_def_request); parsed_cred_def = await indy.parseGetCredDefResponse(cred_def) const schemas = { "schema1_id": parsed_schema[1] } const credentialDefs = { "cred_def1_id": parsed_cred_def[1] } apply_job_proof = await indy.proverCreateProof(handler, job_application_proof_request, job_application_requested_creds, alice_master_id, schemas, credentialDefs, {})

FarhanShafiq (Wed, 26 Jun 2019 07:58:38 GMT):
cred_def: [ 'TUZ1iXZmqaf2JDNp8Hh1M8:3:CL:11:TAG1', { ver: '1.0', id: 'TUZ1iXZmqaf2JDNp8Hh1M8:3:CL:11:TAG1', schemaId: '11', type: 'CL', tag: 'TAG1', value: { primary: [Object] } } ]

MarcoPasotti (Wed, 26 Jun 2019 16:31:05 GMT):
Has joined the channel.

lynn.bendixsen (Wed, 26 Jun 2019 17:46:09 GMT):
Can anyone please share with me the way to set the taaAcceptanceMachanism in the Indy-CLI? I saw a demo where it was set through a config file, but I haven't found any documentation showing how to set the mechanism from the indy-cli> prompt. Thx

izashkalov (Thu, 27 Jun 2019 09:43:29 GMT):
Hello everyone. Yesterday I tried update libindy to v1.9.0 from v1.7.0 into my Android project. but application crasheds and I can not get errors from console. Can you help me with this problem?

DucaDellaForcoletta (Thu, 27 Jun 2019 09:51:01 GMT):
Hi everyone, is possible to delete a credential from the wallet? I'm not able to find a method in the sdk for that

DucaDellaForcoletta (Thu, 27 Jun 2019 10:06:14 GMT):
Hi everyone, I'm looking the sdk api for the credental_revocation. Is possible to know if a credential has been revoked? In the test_interaction.py, a proof is executed with only a true / false result.

DucaDellaForcoletta (Thu, 27 Jun 2019 11:17:31 GMT):
Hello everyone, I'm exploring the revocation feature. With the sdk api is a possible to know if a credential has been revoked? With a proof of non revocation the result is only a boolean without a reason of the failure.

sklump (Thu, 27 Jun 2019 11:33:28 GMT):
I believe that it is not possible to use the sdk to get direct knowledge regarding whether a credential has been revoked. If this is likely to be important information, you can bake an effective-since date into the credential and query for a proof on, say, its issue at time _t+0_ and _r_ seconds beyond (time _t+r_ ). The heuristic implementation would need to trust that the value of the credential is correct, and that any revocation would occur beyond _r_ seconds into its lifespan. Note that it produces an error to query a credential before the creation of its revocation registry, so a further band-aid on this horrible design would wait for a few seconds after producing a new cred def's first revocation registry before issuing its first credential.

sklump (Thu, 27 Jun 2019 11:33:28 GMT):
I believe that it is not possible to use the sdk to get direct knowledge regarding whether a credential has been revoked. If this is likely to be important information, you can bake an issued-at timestamp into the credential and query for a proof on, say, its issue at time _t+0_ and _r_ seconds beyond (time _t+r_ ). The heuristic implementation would need to trust that the value of the credential is correct, and that any revocation would occur beyond _r_ seconds into its lifespan. Note that it produces an error to query a credential before the creation of its revocation registry, so a further band-aid on this horrible design would wait for a few seconds after producing a new cred def's first revocation registry before issuing its first credential.

sklump (Thu, 27 Jun 2019 11:33:28 GMT):
I believe that it is not possible to use the sdk to get direct knowledge regarding whether a credential has been revoked. If this is likely to be important information, you can bake an issued-at timestamp attribute into the schema and query for a proof on, say, its issue at time _t+0_ and _r_ seconds beyond (time _t+r_ ). The heuristic implementation would need to trust that the value of the credential is correct, and that any revocation would occur beyond _r_ seconds into its lifespan. Note that it produces an error to query a credential before the creation of its revocation registry, so a further band-aid on this horrible design would wait for a few seconds after producing a new cred def's first revocation registry before issuing its first credential.

sklump (Thu, 27 Jun 2019 11:33:28 GMT):
I believe that it is not possible to use the sdk to get direct knowledge regarding whether a credential has been revoked. If this is likely to be important information, you can bake an issued-at timestamp attribute into the schema and query for a proof on, say, its issue at time _t+0_ and _r_ seconds beyond (time _t+r_ ). The heuristic implementation would need to trust that the issued-at value of the credential is correct, and that any revocation would occur beyond _r_ seconds into its lifespan. Note that it produces an error to query a credential before the creation of its revocation registry, so a further band-aid on this horrible design would wait for a few seconds after producing a new cred def's first revocation registry before issuing its first credential.

sklump (Thu, 27 Jun 2019 11:33:28 GMT):
I believe that it is not possible to use the sdk to get direct knowledge regarding whether a credential has been revoked. If this is likely to be important information, you can bake an issued-at timestamp attribute into the schema and query for a proof on, say, its issue at time _t+0_ and _r_ seconds beyond (time _t+r_ ). The heuristic implementation would need to trust that the issued-at value of the credential is correct, and that any revocation would occur beyond _r_ seconds into its lifespan. Note that the indy-sdk produces an error to query a credential before the creation of its revocation registry, so a further band-aid on this horrible design would wait for a few seconds after producing a new cred def's first revocation registry before issuing its first credential.

sklump (Thu, 27 Jun 2019 11:33:28 GMT):
I believe that it is not possible to use the sdk to get direct knowledge regarding whether a credential has been revoked. If this is likely to be important information, you can bake an issued-at timestamp attribute into the schema and query for a proof on, say, its issue at time _t+0_ and _r_ seconds beyond (time _t+r_ ). The heuristic implementation would need to trust that the issued-at value of the credential is correct, and that any revocation would occur beyond _r_ seconds into its lifespan. Note that the indy-sdk produces an error on query of a credential before the creation of its revocation registry, so a further band-aid on this horrible design would wait for a few seconds after producing a new cred def's first revocation registry before issuing its first credential.

sklump (Thu, 27 Jun 2019 11:33:28 GMT):
I believe that it is not possible to use the sdk to get direct knowledge regarding whether a credential has been revoked. If this is likely to be important information, you can bake an issued-at timestamp attribute into the schema and query for a proof on, say, its issue at time _t+0_ and _r_ seconds beyond (time _t+r_ ). The heuristic implementation would need to trust that the issued-at value of the credential is correct, and that any revocation would occur beyond _r_ seconds into its lifespan. Note that the indy-sdk produces an error on query of a credential's revocation status before the creation of its revocation registry, so a further band-aid on this horrible design would wait for a few seconds after producing a new cred def's first revocation registry before issuing its first credential.

DucaDellaForcoletta (Thu, 27 Jun 2019 12:18:33 GMT):
@sklump Thanks for the answer. In the sdk, within the proof service is already present the logic to check if a credential has been revoked. The limit is on the verify proof result, because only a boolean is returned so it is not possible to know if the false is for the revoked or for an invalid (tampered) credential.

sklump (Thu, 27 Jun 2019 12:20:43 GMT):
Exactly, and I think this is by design. I think the immediate use case was to avoid any stigma attached to a revoked credential (e.g., "this person is not a priest" carries less than "this person was defrocked")

josh.graber (Thu, 27 Jun 2019 15:18:13 GMT):
Anybody have any insight into how the get_endpoint_for_did api call works?

josh.graber (Thu, 27 Jun 2019 15:18:13 GMT):
Anybody have any insight into how the `get_endpoint_for_did` api call works?

josh.graber (Thu, 27 Jun 2019 15:18:38 GMT):
I'm calling it with a wallet handle, pool handle, and a did I know is in the wallet (with a set endpoint)

josh.graber (Thu, 27 Jun 2019 15:18:38 GMT):
I'm calling it with a wallet handle, pool handle, and a did that I know is in the wallet (with a set endpoint)

josh.graber (Thu, 27 Jun 2019 15:18:45 GMT):
And I'm getting a CommonInvalidState error

josh.graber (Thu, 27 Jun 2019 15:18:45 GMT):
And I'm getting a `CommonInvalidState` error

josh.graber (Thu, 27 Jun 2019 15:19:48 GMT):
This (https://github.com/hyperledger/indy-sdk/blob/master/samples/nodejs/README.md#troubleshooting) suggested that I build the ledger with `--no-cache` if you get that error... completed this and still getting the error

josh.graber (Thu, 27 Jun 2019 15:20:26 GMT):
Can anybody shed any light on this?

josh.graber (Thu, 27 Jun 2019 18:42:09 GMT):
Looks like this is the error that gets thrown if the did isn't found in the wallet or on the pool (at least with an endpoint)

josh.graber (Thu, 27 Jun 2019 18:42:26 GMT):
Turns out I was looking for my pairwise did not theirs, endpoint was registered against theirs.

josh.graber (Thu, 27 Jun 2019 18:42:30 GMT):
Seems to be working now

izashkalov (Fri, 28 Jun 2019 07:15:28 GMT):
Hello everyone, I found this bug https://jira.hyperledger.org/browse/IS-1229. Can you tell us about it? When are you going to fixing it?

smithbk (Fri, 28 Jun 2019 08:13:48 GMT):
Does anyone know why the delete_wallet call doesn't remove the entire directory? The sqlite impl creates 3 files: sqlite.db, sqlite.db-shm, and sqlite.db-wal. When I call `delete_wallet`, it doesn't delete sqlite.db, which means if I create, delete, and recreate a wallet with the same name, the recreate fails. Any help is appreciated.

sklump (Fri, 28 Jun 2019 09:58:00 GMT):
@smithbk Good catch, I bet this is a bug and you ought to submit a JIRA item.

smithbk (Fri, 28 Jun 2019 12:08:00 GMT):
ok, will do

wadeking98 (Fri, 28 Jun 2019 18:15:46 GMT):
hello everyone, I moved over from indy-catalyst to aries but I'm having a bit of trouble connecting two users. In indy catalyst I would create a connection invitation through the api and copy and paste the invitation json into the other user's recieve invitation section. I'm trying to do the same thing with aries but it throws an error saying ``` ERROR Message parsing failed \: Message does not contain '@type' parameter, sending problem report ``` except I do have the \@type parameter set in the invitation json. The invitation json typically looks something like this ``` { "@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/invitation", "@id": "255aefe3-c2ac-4b48-9638-2bc2e134d840", "serviceEndpoint": "http://192.168.65.3:8000", "routingKeys": [], "recipientKeys": [ "6YaoLaqE75JNZCXfWMKih4RcRZMpBy1D9HssJSS8scuN" ], "label": "faber" } ``` am I creating and recieving connections correctly or am I missing something?\n *note*: I have von-network running in the background and the command I'm using a basic bash script to start each user ```#!/usr/bin/env bash let "api_port = 5000 + $2" let "in_port = 8000 + $2" ip=$(docker run --net=host codenvy/che-ip) PORTS="$api_port:$api_port $in_port:$in_port" ./scripts/run_docker --admin 0.0.0.0 $api_port --inbound-tra nsport http 0.0.0.0 $in_port --outbound-transport http -e http://$ip:8000 --auto-ping-connection --accept- invites --accept-requests --genesis-url http://$ip:9000/genesis --seed 00000000000000000000000000000000 -- wallet-type indy --wallet-name $3 --wallet-key $4 -l $1 ```

swcurran (Fri, 28 Jun 2019 18:20:30 GMT):
I'm not able to debug this - perhaps @andrew.whitehead can help. We have a full tutorial on this almost ready - by Monday :-) that walks through all the steps.

swcurran (Fri, 28 Jun 2019 18:20:51 GMT):
BTW - should probably move this to the #aries channel.

andrew.whitehead (Fri, 28 Jun 2019 18:27:53 GMT):
@wadeking98 With the (limited) cli support in that demo, it's probably only accepting input up to the first line break, so I'd try removing those.

wadeking98 (Fri, 28 Jun 2019 18:30:45 GMT):
my mistake, I meant to post it in aries

wadeking98 (Fri, 28 Jun 2019 18:52:52 GMT):
I removed the line breaks from my invitation json but I'm still getting the same error. I'll just wait until the tutorial comes out on monday, cheers

rasviitanen (Sun, 30 Jun 2019 07:38:23 GMT):
Hi, IIRC there is someone trying to make the indy-sdk work in browser extensions by compiling everything to WASM. What's status on this? I would very much like this to be possible for a project im working on. I could propably help out if it is still in development.

DucaDellaForcoletta (Mon, 01 Jul 2019 12:24:37 GMT):
Hi everyone, I've a crash using indy sdk with android upon create proof without specify non revoked tag for a credential defined as revocable. In logcat I can see the following error and then a crash occurs src/api/anoncreds.rs:1575 | prepare_result_1: >>> Err(IndyError { inner: Timestamp not found Invalid structure })

josh.graber (Tue, 02 Jul 2019 00:35:18 GMT):
Are there any plans to abstract out the wallet implementations in indy-sdk so that we can use other more complex custom wallet implementations?

josh.graber (Tue, 02 Jul 2019 00:35:34 GMT):
Seems like this will become more and more important as we move towards more fully fleshed out DKMS solutions

josh.graber (Tue, 02 Jul 2019 00:35:46 GMT):
I'm assuming aries is already thinking about some of this as well

dbluhm (Tue, 02 Jul 2019 01:59:19 GMT):
Are you aware of the pluggable wallet interface in the SDK? https://github.com/hyperledger/indy-sdk/tree/master/docs/design/003-wallet-storage

dbluhm (Tue, 02 Jul 2019 02:01:51 GMT):
I'm personally not super fond of the mechanism but it does allow us to ensure that secrets are being encrypted, precluding developers of apps handling the secrets in insecure ways, etc.

dbluhm (Tue, 02 Jul 2019 02:02:51 GMT):
If that pluggable storage interface doesn't work for you, I'd be interested to hear what issues you run into so we can make a more widely usable wallet implementation for Aries

josh.graber (Tue, 02 Jul 2019 02:03:32 GMT):
I was aware that wallets were architecture as a distinct system. Presumably adding an implementation would require modifying libindy and writing rust code?

josh.graber (Tue, 02 Jul 2019 02:03:32 GMT):
I was aware that wallets were architectured as a distinct system. Presumably adding an implementation would require modifying libindy and writing rust code?

josh.graber (Tue, 02 Jul 2019 02:04:12 GMT):
Yeah I'll be interested to see how this matures in Aries

dbluhm (Tue, 02 Jul 2019 02:04:30 GMT):
You shouldn't have to modify libindy at all but it would require writing rust code

dbluhm (Tue, 02 Jul 2019 02:05:51 GMT):
Though, admittedly, I've never written a storage plugin for Indy SDK so I'm not sure about the details.

dbluhm (Tue, 02 Jul 2019 02:06:42 GMT):
The BC Gov team ( @swcurran ) wrote a postgres plugin, I'd be interested to hear how that went for them

swcurran (Tue, 02 Jul 2019 02:07:27 GMT):
@josh.graber - what is your definition of "more complex"? What features are you thinking about?

ianco (Tue, 02 Jul 2019 02:12:41 GMT):
It was pretty straightforward. You should be able to modify the postgres plugin in the indy-sdk if you need a different storage (other than postgres).

esplinr (Tue, 02 Jul 2019 02:15:18 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/cli/linux-sample-config.json

dbluhm (Tue, 02 Jul 2019 02:17:55 GMT):
Actually, looking at it again, it doesn't *have* to be written in rust. You just have to fulfill the interface with a C Callable API. So you could actually write a storage plugin in Python, C, C++, Java, Go, etc. etc.

dbluhm (Tue, 02 Jul 2019 02:17:55 GMT):
Actually, looking at it again, it doesn't *have* to be written in rust. You just have to fulfill the interface with a C Callable API.

esplinr (Tue, 02 Jul 2019 02:19:23 GMT):
You should report this as a bug in the Indy SDK project here: https://jira.hyperledger.org

dbluhm (Tue, 02 Jul 2019 02:27:55 GMT):
A better link to the part of that design doc that talks about plugin interface: https://github.com/hyperledger/indy-sdk/tree/master/docs/design/003-wallet-storage#wallet-api-and-storage-interface

DucaDellaForcoletta (Tue, 02 Jul 2019 06:51:41 GMT):
The issue can be followed here: https://jira.hyperledger.org/browse/IS-1306

sheru (Tue, 02 Jul 2019 14:49:41 GMT):
Has joined the channel.

sheru (Tue, 02 Jul 2019 14:49:43 GMT):
hi

sheru (Tue, 02 Jul 2019 14:51:35 GMT):
Hi all, I am a new to blockchain and hyperledger. Currently tried to working with Indy. Please guide me to understand the indy-cli. Is there any tutorial on indy-cli separately?

sheru (Tue, 02 Jul 2019 15:43:19 GMT):

Screenshot from 2019-07-02 21-09-39.png

esplinr (Tue, 02 Jul 2019 16:26:44 GMT):
@sheru Have you worked through the Getting Started guide?

lynn.bendixsen (Tue, 02 Jul 2019 16:53:06 GMT):
Hmmm, it appears that the only way to do it is through a config file. There is no CLI command to set the CLI's acceptance Mechanism.

esplinr (Tue, 02 Jul 2019 16:56:11 GMT):
Correct.

esplinr (Tue, 02 Jul 2019 16:56:40 GMT):
It is supposed to be set by the application developer who defined the user interaction, rather than allowing the user to arbitrarily claim they used an acceptance mechanism.

izashkalov (Wed, 03 Jul 2019 07:42:18 GMT):
Hello everyone. I am using libindy v 1.7.0. My Android application has function with export wallet. I think that exportWallet don`t cjeck password. Case: 1) created wallet with passPhrase "1"; 2) open wallet with passPhrase "1"; 3) try run function exportWallet with incorrect passPhrase: - create config {"path":"/storage/emulated/0/Android/data/application_name/files/wallet.export","key":"43222455644"} - call exportWallet(wallet, config) with already have opened wallet and have created config 4) the call exportWallet have been success finished with incorrect key. Can you help me with it? What is it "key" into config? It is passphrase for create and open wallet?

sheru (Wed, 03 Jul 2019 13:45:50 GMT):
@HimangshuPan Have you worked through the Getting Started guide?

janl (Wed, 03 Jul 2019 21:08:09 GMT):
I encountered a problem with the getting-started jupyter notebook build and was curious if this a problem in my clone of the indy-sdk or general problem. I get a complain when attempting to docker-compose build in doc/getting-started. The complain is in the lack of authentication in the indy stuff. The method I used to get around the error was to add --allow-unauthenticated to the dockerfile apt-get install row. Then it works. Thanks

josh.graber (Thu, 04 Jul 2019 00:45:32 GMT):
@swcurran sorry, didn't see that you tagged me, busy week. Specifically I was thinking about key recovery, sharding, redundancy, handling lost devices and scenarios like this. We've had conversations about the viability of saving and storing personal health information using this technology but it would be paramount to never lose access under any circumstances

josh.graber (Thu, 04 Jul 2019 00:47:27 GMT):
This is all advanced DKMS stuff that I see is being discussed on the Aries channel as well. I don't see support for this level of complexity in the sdk yet. And honestly I'm not convinced that's the right place for this either

ShamGir (Thu, 04 Jul 2019 07:08:01 GMT):
Has joined the channel.

ShamGir (Thu, 04 Jul 2019 07:08:02 GMT):
Hello guys, I am opening a indy pool in my android app, but getting exception "org.hyperledger.indy.sdk.pool.PoolConfig Not Created Exception: The requested pool cannot be opened because it does not have an existing configuration." any idea about this exception ??

swcurran (Thu, 04 Jul 2019 14:31:03 GMT):
@josh.graber - ah, that makes sense. The big issues :-). Yes - those do need to start to be addressed around now. We've been getting to the same point. We still aren't putting things in storage for which we don't have relatively painless recovery mechanisms, but secure, reliable backup and restore will be crucial pretty quickly.

josh.graber (Thu, 04 Jul 2019 14:32:55 GMT):
For now, I'm going to focus on trying to get caught up with all of the latest stuff happening in the Aries working group as I know these types of problems are being discussed. Thanks @swcurran :)

s.weidenbach (Thu, 04 Jul 2019 18:48:05 GMT):
Has joined the channel.

Hangyu (Mon, 08 Jul 2019 07:38:47 GMT):
Has joined the channel.

uNmAnNeR (Tue, 09 Jul 2019 07:13:32 GMT):
Hello! Is it ok to store verkeys in database or it should be placed only in wallet? If it should be in a wallet, then after unpack how to get did by verkey? It seems that listMyDidsWithMeta can be used, but i'am worry about performance. Getting all dids may be expensive in scale.

sheru (Tue, 09 Jul 2019 07:58:12 GMT):
You can also download and add into your system the public key of the repository and remove --allow-unauthenticated to install safely. I pasted the changes below... # Add repositories RUN echo 'Adding repositories and keys...' RUN for i in https://repo.sovrin.org/deb/pubkey.gpg https://repo.sovrin.org/sdk/deb/pubkey.gpg; do curl -s $i | apt-key add -; done RUN add-apt-repository "deb https://repo.sovrin.org/deb xenial master" RUN add-apt-repository "deb https://repo.sovrin.org/sdk/deb xenial stable" RUN apt-get update RUN echo 'Added repositories and keys'

swcurran (Tue, 09 Jul 2019 13:27:23 GMT):
@uNmAnNeR only in wallet. The private key never leaves the wallet, which is as it should be.

uNmAnNeR (Tue, 09 Jul 2019 13:28:52 GMT):
@swcurran ok, thanks for replying. but what about listMyDidsWithMeta? is it a reliable solution?

swcurran (Tue, 09 Jul 2019 13:37:55 GMT):
@ianco would better at answering that. Or @andrew.whitehead.

sklump (Tue, 09 Jul 2019 13:47:28 GMT):
@swcurran I'm not convinced of that - the verification key is public, I don't see the harm in putting it elsewhere. The design intent is certainly to keep it in the wallet. @uNmAnNeR listMyDidsWithMeta is a reliable solution, see the `did.js` unit test in the wrapper.

sklump (Tue, 09 Jul 2019 13:47:28 GMT):
@swcurran I'm not convinced of that - the verification key is public, I don't see the harm in copying it elsewhere. The design intent is certainly to keep it in the wallet. @uNmAnNeR listMyDidsWithMeta is a reliable solution, see the `did.js` unit test in the wrapper.

sklump (Tue, 09 Jul 2019 13:47:28 GMT):
@swcurran I'm not convinced of that - the verification key is public, I don't see the harm in copying it elsewhere (apart from source-of-truth arguments and synchronization). The design intent is certainly to keep it in the wallet. @uNmAnNeR listMyDidsWithMeta is a reliable solution, see the `did.js` unit test in the wrapper.

swcurran (Tue, 09 Jul 2019 13:53:12 GMT):
I took the question as should I take the DIDs out of the wallet - my interpretation was all attributes. Verkey, sure.

Amberbao (Thu, 11 Jul 2019 05:58:00 GMT):
Has joined the channel.

nhrishi (Thu, 11 Jul 2019 06:30:32 GMT):
Has joined the channel.

emis (Thu, 11 Jul 2019 07:59:17 GMT):
Has joined the channel.

emis (Thu, 11 Jul 2019 07:59:19 GMT):
Hello! I'm new to indy sdk. I want to use indy-sdk java wrappers. How is your experience with java wrappers since in documentation says "Not ready for production use! Not all commands work properly! Use at your own risk!"

edynox (Thu, 11 Jul 2019 12:36:44 GMT):
Has joined the channel.

edynox (Thu, 11 Jul 2019 12:36:44 GMT):
Hi guys, what's the status of the iOS wrapper? Cocoapods install is returning 404 for the latest release (https://repo.sovrin.org/ios/libindy/stable/indy-objc/1.9.0/libindy-objc.zip). I'm trying to build it myself, but after fixing dependencies (updating rusqlite and libsqlite) I'm stuck on many `E0308: mismatched types` errors. Should I stick to 1.8.2? Is there any chance to run it with Swift 5? (Or without Swift at all?)

mattatkiva (Thu, 11 Jul 2019 15:50:01 GMT):
Has joined the channel.

mattatkiva (Thu, 11 Jul 2019 15:51:47 GMT):
@emis when I last looked at the java wrapper, it was in a pretty good state. If you see any issues, and feel up for correcting them, please do so! The wrappers are community maintained so having your contributions are welcome

emis (Fri, 12 Jul 2019 08:21:25 GMT):
thanks @mattatkiva

BrajeshKumar (Fri, 12 Jul 2019 10:56:52 GMT):
Has joined the channel.

mattatkiva (Fri, 12 Jul 2019 15:40:35 GMT):
anyone seeing this error building indy-sdk: ``` Compiling rusqlite v0.13.0 error[E0119]: conflicting implementations of trait `std::convert::From<&_>` for type `types::to_sql::ToSqlOutput<'_>`: --> /root/.cargo/registry/src/github.com-1ecc6299db9ec823/rusqlite-0.13.0/src/types/to_sql.rs:26:1 | 18 | / impl<'a, T: ?Sized> From<&'a T> for ToSqlOutput<'a> 19 | | where &'a T: Into> 20 | | { 21 | | fn from(t: &'a T) -> Self { 22 | | ToSqlOutput::Borrowed(t.into()) 23 | | } 24 | | } | |_- first implementation here 25 | 26 | impl<'a, T: Into> From for ToSqlOutput<'a> { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `types::to_sql::ToSqlOutput<'_>` | = note: downstream crates may implement trait `std::convert::From<&_>` for type `types::value::Value` error: aborting due to previous error```

josh.graber (Fri, 12 Jul 2019 17:02:32 GMT):
Just added a PR for fixing the nodejs wrapper build / install on Windows platforms: https://github.com/hyperledger/indy-sdk/pull/1721

josh.graber (Fri, 12 Jul 2019 17:02:45 GMT):
If somebody would be willing to review and offer feedback that would be useful, thanks! :grinning:

andrew.whitehead (Fri, 12 Jul 2019 17:53:59 GMT):
Some discussion on the #indy channel but it probably belongs here. It builds if you switch to rust 1.34.0 (`./rustup --default-toolchain 1.34.0 -y`)

mattatkiva (Fri, 12 Jul 2019 17:54:42 GMT):
thank you. I was using rust 1.36.0. Changing it to 1.34.0 fixed my problems

ravip (Fri, 12 Jul 2019 19:39:03 GMT):
Has joined the channel.

ravip (Fri, 12 Jul 2019 19:39:05 GMT):
Is there a way to send key value pairs in proof requests alongside an attribute verification? For example, a proof request can ask for name verification and also send information in the form of key value pairs with the key as the reason and value as the actual reason for requesting name.

sumodgeorge (Sat, 13 Jul 2019 13:21:10 GMT):
Has joined the channel.

vindard (Mon, 15 Jul 2019 05:11:55 GMT):
Hi all, I'm trying to get the `libindy.so` file loaded onto a React Native Android project and for the life of me can't figure out how to properly do this. I've taken a first principles approach now, setting up a new bare bones React Native project from scratch and trying to do the import there. Each granular step I took is described from commit to commit. Could anyone advise how I can get the shared library integrated (Pull Requests also welcome if that's easier for explaining)? https://github.com/vindard/RNIndy01/commits/master

lukasA (Mon, 15 Jul 2019 11:03:23 GMT):
hi, in the build setup https://github.com/hyperledger/indy-sdk/blob/master/docs/build-guides/ubuntu-build.md step 3 says that indy-sdk requires the libsodium verison `1.0.14`. i installed the newest version (`1.0.18`) and the build seemed fine and was successful with no errors. does any functionality in the indy-sdk depend on the version `1.0.14`?

AvikHazra-klizos (Mon, 15 Jul 2019 13:34:39 GMT):
Has joined the channel.

AvikHazra-klizos (Mon, 15 Jul 2019 13:39:17 GMT):
Hello, when i tried submitRequest for schema it returns seqNo null. Can anyone help me please ?

priyashankar (Wed, 17 Jul 2019 14:06:45 GMT):
Has joined the channel.

MITomK (Wed, 17 Jul 2019 14:10:50 GMT):
Has joined the channel.

priyashankar (Wed, 17 Jul 2019 14:22:46 GMT):
I tried creating an asyncio event loop to handle a custom build-connection request between two participants. Every time I tried closing the event loop, an exception was thrown but the code worked fine without closing it.

emis (Wed, 17 Jul 2019 15:21:09 GMT):
Hi, I have a question about the reissuing of credentials. Let's suppose we have a user with a credential that has an expiration date. The credential expired and it was revoked. But, the credential's owner pays again for the service and the issuer needs to issue a new credential to the owner, but some attributes need to be carried over from the previous (expired) credential (for example ID). Is this possible in Indy-sdk?

sklump (Wed, 17 Jul 2019 15:28:46 GMT):
@emis credentials don't have an expiry as such. They may have an attribute that its users understand to represent such an end date, but there is no concept of expiry at the credential level. It's not an X.509 certificate. To copy attributes, a verifier could request and get a proof with attribute values of interest, then take the revealed attributes from that presentation (e.g., https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/28b1cdf5624d750a3b0e5f77deb36d84392685e2/von_anchor/util.py#L912 with sample invocation at https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/28b1cdf5624d750a3b0e5f77deb36d84392685e2/test/test_anchors.py#L1612).

emis (Thu, 18 Jul 2019 09:17:13 GMT):
Can this be done without revealing the attributes?

emis (Thu, 18 Jul 2019 09:17:48 GMT):
Some sort linking to the previous credential that was revoked?

PranayGandhi (Thu, 18 Jul 2019 09:47:35 GMT):
Has joined the channel.

PranayGandhi (Thu, 18 Jul 2019 09:47:36 GMT):
I am trying to call issuerCreateCredentialOffer and I am supposed to pass TranscriptCredDefId to it. Now can somebody let me know how can I retreive TranscriptCredDefId from any indy interface if I have the access to associated wallet which created and stored the credential definition.

PranayGandhi (Thu, 18 Jul 2019 09:47:40 GMT):
Thanks

Zohaib_Sohail (Thu, 18 Jul 2019 11:23:06 GMT):
indy.did.getEndpointDidAttribute('credential_definitions') this function returns credentialDefinitions in nodejs

PranayGandhi (Thu, 18 Jul 2019 11:28:50 GMT):
ohh

PranayGandhi (Thu, 18 Jul 2019 11:29:28 GMT):
I did not and still not able to see this function in indy-sdk documentation on github

PranayGandhi (Thu, 18 Jul 2019 11:29:36 GMT):
Thanks. Let me try it :)

Zohaib_Sohail (Thu, 18 Jul 2019 11:31:09 GMT):
which wrapper are you using?

PranayGandhi (Thu, 18 Jul 2019 11:33:23 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/wrappers/nodejs

PranayGandhi (Thu, 18 Jul 2019 11:33:46 GMT):
Also can you tell me one thing.

PranayGandhi (Thu, 18 Jul 2019 11:34:02 GMT):
In this indy.did.getEndpointDidAttribute('credential_definitions')

PranayGandhi (Thu, 18 Jul 2019 11:34:28 GMT):
How will the function get to know that which issuer's credential definitions I am interested in

PranayGandhi (Thu, 18 Jul 2019 11:35:03 GMT):
Since I am neither passing issuer wallet handle or any info nor I am calling this function from any issuer's instance

Zohaib_Sohail (Thu, 18 Jul 2019 11:39:34 GMT):
basically it was from a demo tutorial and you are right this function is not part of indy-sdk

Zohaib_Sohail (Thu, 18 Jul 2019 11:41:20 GMT):
what actually they does is when issuer issues credential, credDefJson is pushed with this function await indy.did.pushEndpointDidAttribute('credential_definitions', credDefJson);

Zohaib_Sohail (Thu, 18 Jul 2019 11:43:56 GMT):
this will give you answer regarding wallet handle

Zohaib_Sohail (Thu, 18 Jul 2019 11:43:57 GMT):
getEndpointDidAttribute = async function (attribute) { let metadata = await sdk.getDidMetadata(await indy.wallet.get(), endpointDid); metadata = JSON.parse(metadata); return metadata[attribute]; };

PranayGandhi (Thu, 18 Jul 2019 12:13:45 GMT):
Oooo

PranayGandhi (Thu, 18 Jul 2019 12:13:47 GMT):
Okay

PranayGandhi (Thu, 18 Jul 2019 12:14:05 GMT):
Now I completely got it after your extended explanation

PranayGandhi (Thu, 18 Jul 2019 12:15:34 GMT):
You are referred to https://github.com/hyperledger/education/tree/master/LFS171x/indy-material/nodejs/indy/src/did/index.js

PranayGandhi (Thu, 18 Jul 2019 12:15:34 GMT):
You referred to https://github.com/hyperledger/education/tree/master/LFS171x/indy-material/nodejs/indy/src/did/index.js

PranayGandhi (Thu, 18 Jul 2019 12:16:02 GMT):
Awesome. Thanks :)

sumodgeorge (Thu, 18 Jul 2019 16:00:49 GMT):
Hi, I was trying to build indy-sdk in macos and followed the steps mentioned in https://github.com/hyperledger/indy-sdk/blob/master/docs/build-guides/mac-build.md. While trying to build cli, i am getting the following error - error: linking with `cc` failed: exit code: 1. Can you tell me what I would need to do fix this error

sumodgeorge (Thu, 18 Jul 2019 16:47:02 GMT):
"/Users/Sumod/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcompiler_builtins-1be0692ae6dec4e9.rlib" "-lindy" "-lncurses" "-lSystem" "-lresolv" "-lc" "-lm" = note: ld: library not found for -lindy clang: error: linker command failed with exit code 1 (use -v to see invocation)

mattatkiva (Thu, 18 Jul 2019 16:53:51 GMT):
After building indy-sdk you have to either copy the dylib or set the environment variable that points to its location.

mattatkiva (Thu, 18 Jul 2019 16:54:57 GMT):
```Set your DYLD_LIBRARY_PATH and LD_LIBRARY_PATH environment variables to the path of indy-sdk/libindy/target/debug. You may want to put these in your .bash_profile to persist them. ```

mattatkiva (Thu, 18 Jul 2019 16:55:04 GMT):
did you do that step?

sumodgeorge (Thu, 18 Jul 2019 16:55:21 GMT):
I have not done that yet

sumodgeorge (Thu, 18 Jul 2019 16:56:01 GMT):
How do I set them

mattatkiva (Thu, 18 Jul 2019 16:56:06 GMT):
also the step above it...#6 ```To compile the CLI, libnullpay, or other items that depend on libindy: export LIBRARY_PATH=/path/to/sdk/libindy/target/ cd ../cli cargo build ```

sumodgeorge (Thu, 18 Jul 2019 16:57:05 GMT):
what does refer to

mattatkiva (Thu, 18 Jul 2019 16:58:01 GMT):
build type. if all you did was ```cargo build``` config would be ```debug```

mattatkiva (Thu, 18 Jul 2019 16:58:01 GMT):
build type. if all you did was `cargo build` config would be `debug`

sumodgeorge (Thu, 18 Jul 2019 16:58:26 GMT):
Yes I just did cargo build

sumodgeorge (Thu, 18 Jul 2019 16:58:39 GMT):
Thanks Mattakkiva

sumodgeorge (Thu, 18 Jul 2019 17:07:32 GMT):
I did step 6 and tried to do cargo build, now I am getting the error - = note: ld: warning: directory not found for option '-L/path/to/sdk/libindy/target/debug' ld: library not found for -lindy clang: error: linker command failed with exit code 1 (use -v to see invocation) When I checked the directory debug is present in target directory under libindy

mattatkiva (Thu, 18 Jul 2019 17:18:16 GMT):
whats the output of `echo $LD_LIBRARY_PATH`

sumodgeorge (Thu, 18 Jul 2019 17:31:42 GMT):
It is showing blank

sumodgeorge (Thu, 18 Jul 2019 17:32:20 GMT):
I inserted the following lines in .bash_profile export DYLD_LIBRARY_PATH=/Users/Sumod/indy-sdk/libindy/target/debug export LD_LIBRARY_PATH=/Users/Sumod/indy-sdk/libindy/target/debug

mattatkiva (Thu, 18 Jul 2019 17:39:22 GMT):
you need refresh your shell. run `source ~/.bash_profile`

sumodgeorge (Thu, 18 Jul 2019 17:41:30 GMT):
okay sure

sumodgeorge (Thu, 18 Jul 2019 17:43:15 GMT):
I refreshed the shell and when I typed echo $LD_LIBRARY_PATH , the output is /Users/Sumod/indy-sdk/libindy/target/debug

mattatkiva (Thu, 18 Jul 2019 17:44:13 GMT):
try building the cli now

sumodgeorge (Thu, 18 Jul 2019 17:44:20 GMT):
okay sure

sumodgeorge (Thu, 18 Jul 2019 17:45:50 GMT):
I am getting the following error again - = note: ld: warning: directory not found for option '-L/path/to/sdk/libindy/target/debug' ld: library not found for -lindy clang: error: linker command failed with exit code 1 (use -v to see invocation)

sumodgeorge (Thu, 18 Jul 2019 17:48:23 GMT):
I reran the cargo build after changing the LIBRARY_PATH to /User/Sumod/indy-sdk/target/debug and it complied successfully

sumodgeorge (Thu, 18 Jul 2019 17:48:56 GMT):
Thanks Mattatkiva for your help

mattatkiva (Thu, 18 Jul 2019 17:49:03 GMT):
glad you got it built

sklump (Thu, 18 Jul 2019 18:01:34 GMT):
One thing: indy-sdk python setup.py currently has ``` TEST_DEPS = [ 'pytest<3.7', 'pytest-asyncio', 'base58' ] ```

sklump (Thu, 18 Jul 2019 18:01:34 GMT):
One thing: indy-sdk python setup.py currently has ``` TEST_DEPS = [ 'pytest<3.7', 'pytest-asyncio', 'base58' ] ``` That's real old now. What would happen if it were 3.8? The trouble is that aries-cloudagent-python needs a higher version, and indy-sdk needs a lower version, so they can't coexist in a virtual environment.

andrew.whitehead (Thu, 18 Jul 2019 18:04:11 GMT):
Presumably it only matters if you're actually running the indy-sdk unit tests, I'm not sure why it's an install dependency. That said we don't really 'need' the higher version but I didn't want to standardize on an older one

sklump (Thu, 18 Jul 2019 18:08:39 GMT):
Nevertheless, installing indy-sdk after an aries does not work. The most expedient and certain approach is to wipe out the virtual environment and start again. I'm not casting aspersions at ACA or any other software, since pytest is up into the 5.x release now. I know 4.1 broke some backward-compatibility (with some decorators?) and plug-ins suffered.

lynn.bendixsen (Thu, 18 Jul 2019 18:25:24 GMT):
In a recent build of the indy-cli (1.10.0 or 1.10.1 I think) a feature that I enjoy has changed and I am wondering if it was done on purpose. The feature I like is the "use the up-arrow to scroll through/repeat previously run commands". This feature no longer retains commands that have failed and that is a significant loss in my opinion. In other words, I type in a very long command and miss a character or two causing it to fail, and now instead of hitting up-arrow and making a few minor changes, I have to start over. Was this an intentional "enhancement"?

mattatkiva (Thu, 18 Jul 2019 18:26:25 GMT):
@esplinr

mattatkiva (Thu, 18 Jul 2019 18:26:25 GMT):
@esplinr might have the best answer

andrew.whitehead (Thu, 18 Jul 2019 18:28:16 GMT):
Are you using the latest version? It looks like it was recently updated to move pytest to tests_require only. Here I was wondering why things in tests_require were being listed as dependencies.. https://github.com/hyperledger/indy-sdk/commit/840af484f3b0f615167adf9600263e0d8c2e3875#diff-3d22c67cd6d7705f7295cc4181770ea5

kdenhartog (Thu, 18 Jul 2019 18:34:59 GMT):
I think the indy-sdk requires the lower version because indy-node is dependent on the python wrapper still for testing. I'm not sure what the plan is for updating it. @sergey.minaev or @Artemkaaas may be able to help us figure out what the blocker is.

sklump (Thu, 18 Jul 2019 18:34:59 GMT):
I am trying to get 1.10.1 in place. pipenv install python3-indy==1.10.1 fails and fills the screen with every version of python3-indy. Anthropologically interesting

sklump (Thu, 18 Jul 2019 18:34:59 GMT):
I am trying to get 1.10.1 in place. pipenv install `python3-indy==1.10.1` fails and fills the screen with every version of python3-indy. Anthropologically interesting.

sklump (Thu, 18 Jul 2019 18:34:59 GMT):
I am trying to get 1.10.1 in place. `pipenv install python3-indy==1.10.1` fails and fills the screen with every version of python3-indy. Anthropologically interesting.

sklump (Thu, 18 Jul 2019 18:36:20 GMT):
I was surmising that it was the pytest version, but I could be wrong.

dbluhm (Thu, 18 Jul 2019 19:25:16 GMT):
That's interesting. I just ran a quick test myself, installing python3-indy into a clean virtual environment and didn't get any errors

esplinr (Thu, 18 Jul 2019 20:11:40 GMT):
That was a bug. The team caught it today. We are working on a fix. cc @vladimir.shishkin @Artemkaaas

esplinr (Thu, 18 Jul 2019 20:12:18 GMT):
It was an intentional enhancement because during testing we end up with a lot of garbage in the history, but was intended to be configurable.

lynn.bendixsen (Thu, 18 Jul 2019 21:12:44 GMT):
thx

sklump (Fri, 19 Jul 2019 10:39:40 GMT):
It installs fine into a clean virtual environment. It's if pytest>3.7 is already there that it blows up. I believe mine got there from aries-cloud-agent.

FarhanShafiq (Sun, 21 Jul 2019 09:01:47 GMT):
I'm trying to sign create_credential_definition_request from mobile java indy API while submitted signed request via Nodejs API using valid verkey but facing issue: reason: 'client request invalid: InsufficientCorrectSignatures(0, 1)' But when I both signed and submit request using nodejs API or mobile API, it's work perfectly. Please help me out, i'm trying to solve this issue for two days.

FarhanShafiq (Sun, 21 Jul 2019 09:01:47 GMT):
I'm trying to signing create_credential_definition_request from mobile java indy API while submitting signed request via Nodejs API using valid verkey but facing issue: reason: 'client request invalid: InsufficientCorrectSignatures(0, 1)' But when I both signed and submit request using nodejs API or mobile API, it's work perfectly. Please help me out, i'm trying to solve this issue for two days.

FarhanShafiq (Sun, 21 Jul 2019 09:01:47 GMT):
I'm trying to sign create_credential_definition_request from mobile java indy API while submit signed request via Nodejs API using valid verkey but facing issue: reason: 'client request invalid: InsufficientCorrectSignatures(0, 1)' But when I both signed and submit request using nodejs API or mobile API, it's work perfectly. Please help me out, i'm trying to solve this issue for two days.

wangdong (Sun, 21 Jul 2019 13:28:23 GMT):
I try to install indy-sdk from sudo add-apt-repository "deb https://repo.sovrin.org/sdk/deb xenial {release channel}"

wangdong (Sun, 21 Jul 2019 13:28:23 GMT):
I try to install indy-sdk from https://github.com/hyperledger/indy-sdk#installing-the-sdk

wangdong (Sun, 21 Jul 2019 13:29:04 GMT):
add-apt-repository "deb https://repo.sovrin.org/sdk/deb xenial {release channel}"

wangdong (Sun, 21 Jul 2019 13:29:29 GMT):
I replace {release channel} with stable, but it does not work.

wangdong (Sun, 21 Jul 2019 13:30:00 GMT):
The repo list link is broken?

wangdong (Mon, 22 Jul 2019 02:57:20 GMT):
I built the sdk from source and test it. And got some issue.

wangdong (Mon, 22 Jul 2019 02:57:28 GMT):
I will raise a PR for this

wangdong (Mon, 22 Jul 2019 02:57:41 GMT):
`test crypto_demo_works ... FAILED test ledger_demo_works ... FAILED`

wangdong (Mon, 22 Jul 2019 02:57:41 GMT):
`test crypto_demo_works ... FAILED` `test ledger_demo_works ... FAILED`

mattatkiva (Mon, 22 Jul 2019 13:28:09 GMT):
@wangdong try https://repo.sovrin.org/sdk/deb/dists/xenial/Release

mattatkiva (Mon, 22 Jul 2019 13:28:09 GMT):
@wangdong try https://repo.sovrin.org/sdk/deb/dists/xenial/

wangdong (Mon, 22 Jul 2019 14:05:24 GMT):
The format is bad.

wangdong (Mon, 22 Jul 2019 14:05:32 GMT):
I tried that too.

mattatkiva (Mon, 22 Jul 2019 14:20:51 GMT):
you still need to add the release after it

mattatkiva (Mon, 22 Jul 2019 21:11:07 GMT):
Im looking into the indysdk wallet API and I see callbacks for WalletDeleteRecord. Does WalletDeleteRecord functionality work

mattatkiva (Mon, 22 Jul 2019 21:11:07 GMT):
Im looking into the indysdk wallet API and I see callbacks for WalletDeleteRecord. Does WalletDeleteRecord functionality work....and how do I invoke delete record through the API?

lynn.bendixsen (Mon, 22 Jul 2019 21:53:33 GMT):
I have gotten that error message for at least 3 different reasons: 1. Bad Verkey: Doesn't seem likely to be your reason, but I didn't realize that the verkey in my wallet didn't match what was on the ledger until I ran "> ledger get-nym did=" and compared it to "> did list" from indy-cli 2. Not submitting my request with the same DID that I signed it with. This seems to be required for at least some requests. 3. Insufficient privileges on the DID that I used to sign or submit the request. You can adjust the privileges required using Auth_Rules or you can promote the user you are attempting to perform the action with to see if this one is the case for you.

wangdong (Tue, 23 Jul 2019 07:30:56 GMT):
Of course, it should be: `deb-src https://repo.sovrin.org/sdk/deb/dists/xenial stable`

JeromeK (Tue, 23 Jul 2019 11:37:16 GMT):
Has joined the channel.

JeromeK (Tue, 23 Jul 2019 11:37:17 GMT):
Hey Guys Just want to ask where i can get the latest new on the GO-Wrapper for Indy Greets Jérôme

JeromeK (Tue, 23 Jul 2019 11:37:17 GMT):
Hey Guys Just want to ask where I can get the latest news on the GO-Wrapper for Indy -> How far the development is etc Greets Jérôme

josh.graber (Tue, 23 Jul 2019 15:34:15 GMT):
Can I get a review from somebody with write access on my indy-sdk PR here: https://github.com/hyperledger/indy-sdk/pull/1721

josh.graber (Tue, 23 Jul 2019 15:34:45 GMT):
I did get a +1 from someone that doesn't have write access and all questions have been responded to, so this has had :eyes:

AxelNennker (Tue, 23 Jul 2019 15:43:09 GMT):
Why is this not fixed fast? https://jira.hyperledger.org/browse/IS-1319

sklump (Tue, 23 Jul 2019 15:49:32 GMT):
@AxelNennker Here is one implementation: https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/4bf1129588ce58c690d07a99fa4938d4271449e8/von_anchor/anchor/verifier.py#L471 calling https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/4bf1129588ce58c690d07a99fa4938d4271449e8/von_anchor/anchor/verifier.py#L414 Rich schemas and cred defs, coming soon, will likely defeat this too, but note that at present there is no "correct" encoding as far as indy-sdk is concerned; encoding is an externality. The von_anchor implementation assumes von_anchor (SHA-256) encoding.

AxelNennker (Tue, 23 Jul 2019 16:09:07 GMT):
It seems guidance for the calling apps is needed

MALodder (Tue, 23 Jul 2019 17:11:55 GMT):
Yes that’s a known problem that will be fixed by rich schemas

emis (Thu, 25 Jul 2019 14:19:59 GMT):
Hi , I want to when this hipe https://github.com/hyperledger/indy-hipe/tree/b0708395fd1669df33a9619efa7770a20c97006e/text/0012-concurrency-improvement for concurrency improvement is planned to be done? Is this approved?

dbluhm (Thu, 25 Jul 2019 14:27:32 GMT):
The threading model of the Indy-SDK and the future Aries-SDK is a point of discussion in next weeks morning Aries WG Call: https://wiki.hyperledger.org/pages/viewpage.action?pageId=16321917

emis (Thu, 25 Jul 2019 14:45:00 GMT):
thanks

emis (Thu, 25 Jul 2019 14:53:04 GMT):
I have one more question. Where can I read what types of predicates are currently implemented? I can see that "Rich schema objects" hipe is accepted. I want to know if there will be support for dates and times predicates.

ravip (Fri, 26 Jul 2019 17:54:47 GMT):
call

naresh_bls (Mon, 29 Jul 2019 14:57:15 GMT):

Screenshot 2019-07-29 at 11.05.43 AM.png

naresh_bls (Mon, 29 Jul 2019 14:59:15 GMT):
Has joined the channel.

naresh_bls (Mon, 29 Jul 2019 14:59:17 GMT):
Hi, When I am installing Hyper Ledger Indy VCX, I'm getting this error. I need help in installing Indy in my Mac.

naresh_bls (Mon, 29 Jul 2019 14:59:17 GMT):
Hi, When I am installing Hyper Ledger Indy VCX, I'm getting this error. I need your help in installing Indy in my Mac.

luckycharms810 (Mon, 29 Jul 2019 21:21:15 GMT):
Has joined the channel.

zixian5 (Tue, 30 Jul 2019 11:50:33 GMT):
Has joined the channel.

zixian5 (Tue, 30 Jul 2019 11:50:34 GMT):
Hey Guys ,

zixian5 (Tue, 30 Jul 2019 12:27:29 GMT):
Hi Guys, Does anyone know how to improve the performance of the SDK? Or is someone already doing this?

dbluhm (Tue, 30 Jul 2019 15:00:11 GMT):
Out of curiosity, what's your setup (standard wallet storage type or something else?) and what calls are you noticing performance issues on?

zixian5 (Tue, 30 Jul 2019 15:11:30 GMT):
I noticed that this method (issuer_create_and_store_revoc_reg) can use multithreading to improve performance, and I saw that someone proposed multithreading in the hipe project (https://github.com/hyperledger/indy-hipe/tree/b0708395fd1669df33a9619efa7770a20c97006e/text/0012-concurrency-improvement ). So I want to know if someone has done it?

dbluhm (Tue, 30 Jul 2019 15:18:16 GMT):
How threading is handled at the library level is a topic of discussion this week in the Aries WG Morning call (Agenda for the call with meeting time and zoom link, feel free to join us: https://wiki.hyperledger.org/pages/viewpage.action?pageId=16321917 ). So this is still an ongoing discussion topic. Notably, with the Anoncreds 2.0 efforts, I think we'll also see significant improvements in performance even in single threaded crypto calls. I believe we'll be moving to ECC instead of RSA for credentials and an improved revocation method is also being developed.

zixian5 (Tue, 30 Jul 2019 15:22:14 GMT):
Wow ,Thanks.I will continue to pay attention to the progress of the project.

sklump (Tue, 30 Jul 2019 17:39:51 GMT):
As an interim, @zixian5 you might enjoy the approach of https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/master/von_anchor/anchor/rrbuilder.py with a sample use at https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/master/test/test_tails_load.py. Neither multithreading nor green-threading primitives pass through the wrapper/shared-library barrier; subprocessing must occur early in the game before libindy sets up its dispatcher, as it operates in a separate thread(? message loop? it's been a while) that does not replicate over a fork (this is unix architecture not indy). In von_anchor, An external rev reg builder process uses file system semaphores as IPC, increases rev reg size as it scales up, and anticipates one rev reg in the future so that the issuer process never waits for a rev reg build.

AxelNennker (Wed, 31 Jul 2019 09:06:16 GMT):
Curious, how long does running the Indy test typically take? `RUST_BACKTRACE=1 RUST_TEST_THREADS=1 time cargo test` on Ubuntu 16.04 ``` 734.48user 6.85system 17:50.86elapsed 69%CPU (0avgtext+0avgdata 306144maxresident)k 876576inputs+452608outputs (2182major+2199148minor)pagefaults 0swaps 944.70user 20.50system 18:51.05elapsed 85%CPU (0avgtext+0avgdata 2103988maxresident)k 1604408inputs+4632792outputs (170major+6053812minor)pagefaults 0swaps ```

AxelNennker (Wed, 31 Jul 2019 09:06:16 GMT):
Curious, how long does running the Indy test typically take? `RUST_BACKTRACE=1 RUST_TEST_THREADS=1 time cargo test` These are my results on Ubuntu 16.04 ``` 734.48user 6.85system 17:50.86elapsed 69%CPU (0avgtext+0avgdata 306144maxresident)k 876576inputs+452608outputs (2182major+2199148minor)pagefaults 0swaps 944.70user 20.50system 18:51.05elapsed 85%CPU (0avgtext+0avgdata 2103988maxresident)k 1604408inputs+4632792outputs (170major+6053812minor)pagefaults 0swaps ```

sklump (Wed, 31 Jul 2019 10:36:58 GMT):
One more thing, be sure to compile libindy for release, not debug, if you are going to be building revocation registries. ``` $ cd indy-sdk/libindy $ cargo build --release ```

naresh_bls (Wed, 31 Jul 2019 10:50:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=6hhMuK4vfRgNgch3p) Hi, Can anyone help me in this?

ravip (Wed, 31 Jul 2019 16:33:20 GMT):
Problem: PoolLedgerTimeout error when calling createPoolLedgerConfig Initial diagnosis: I read somewhere that the cause might be that the IP addresses in the pool configuration and genesis file might not match. Environment: I have an agent (a nodejs web app) running in localhost and I have a pool of four indy validator nodes running in a docker container. I am using Mac OS. The docker containers have IP address ranging from 173.17.0.101 to 173.17.0.104 and the ports ranging from 9701 to 9708 and there is port forwarding to host enabled. The ledger browser is at 173.17.0.101:9000 and I can access the same using localhost:9000. In the genesis file that I supply to agent, I change the 173.17.0.101 to 127.0.0.1. What I did to connect: I made the genesis file (that was created during the start of the pool) available to the agent by passing the path of the file to createPoolLedgerConfig method as an argument. Can anyone please point out if I am missing something?

ravip (Wed, 31 Jul 2019 16:33:20 GMT):
Problem: PoolLedgerTimeout error when calling createPoolLedgerConfig Initial diagnosis: I read somewhere that the cause might be that the IP addresses in the pool configuration and genesis file might not match. Environment: I have an agent (a nodejs web app) running in localhost and I have a pool of four indy validator nodes running in a docker container. I am using Mac OS. The docker containers have IP address ranging from 173.17.0.101 to 173.17.0.104 and the ports ranging from 9701 to 9708 and there is port forwarding to host enabled. The ledger browser is at 173.17.0.101:9000 and I can access the same using localhost:9000. In the genesis file that I supply to agent, I change the 173.17 ip addresses to 127.0.0.1. What I did to connect: I made the genesis file (that was created during the start of the pool) available to the agent by passing the path of the file to createPoolLedgerConfig method as an argument. Can anyone please point out if I am missing something?

naresh_bls (Wed, 31 Jul 2019 16:36:52 GMT):
Hi How to install indy-cli in Macos?

naresh_bls (Wed, 31 Jul 2019 16:38:02 GMT):
I have also visited repo.sovrin.org But there is no folder for cli in macos.

mattatkiva (Wed, 31 Jul 2019 16:39:25 GMT):
@naresh_bls there is no install, per se. you have to build indy-sdk, and then build indy-cli. I use a ubuntu docker image which allows me to just install indy sdk and indy cli without have to create a build enviroment

naresh_bls (Wed, 31 Jul 2019 16:40:33 GMT):
@mattatkiva can you please help me to build indy-cli?

mattatkiva (Wed, 31 Jul 2019 16:41:52 GMT):
@naresh_bls follow the steps here: https://github.com/hyperledger/indy-sdk/blob/master/docs/build-guides/mac-build.md

Zohaib_Sohail (Thu, 01 Aug 2019 06:29:24 GMT):
I had the same issue, was trying to run pool and agent on two different machines and your initial diagnosis is correct you should have same IP addresses in your pool configuration and genesis file

Zohaib_Sohail (Thu, 01 Aug 2019 06:31:44 GMT):
https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker have a look at this and choose a solution depending on your requirement

PaulA (Thu, 01 Aug 2019 08:47:45 GMT):
Has joined the channel.

joshgraber (Fri, 02 Aug 2019 15:17:23 GMT):
Has joined the channel.

PranayGandhi (Mon, 05 Aug 2019 11:17:12 GMT):
I was going through the code base of indy-sdk nodejs sample example and I observed that in onboarding function we are sending the pairwise DIDs of the oboarder as well as the new ledger to the ledger. I also observed new user was able to Anoncrypt connection response for the onboarder using onboarder’s pairwise DID. And this pairwise DID of the onboarder was extracted by the new user through keyForDid function. And this was only possible because onboarder logged the pairwise did to the ledger. Now simuntaneously I also went through this document posted by evernym (https://www.evernym.com/wp-content/uploads/2017/07/What-Goes-On-The-Ledger.pdf) which stated this- “A DID added directly to the Sovrin public ledger is called a public DID, whereas a pairwise pseudonymous DID shared and stored privately “off-ledger” between the agents for two identity holders is called a private DID. The ability for Sovrin infrastructure to support both is fundamental to both its Privacy by Design architecture as well as its ability to scale.” Could somebody please put some opinions or thoughts on it like why the indy-sdk or the sample code is designed in such a way that we had to store pairwise Did into the ledger although contarary to this has been strongly stated in the document I mentioned above. Thanks

PranayGandhi (Mon, 05 Aug 2019 11:17:12 GMT):
I was going through the code base of indy-sdk nodejs sample example and I observed that in onboarding function we are sending the pairwise DIDs of the oboarder as well as the new ledger to the ledger. I also observed new user was able to Anoncrypt connection response for the onboarder using onboarder’s pairwise DID. And this pairwise DID of the onboarder was extracted by the new user through keyForDid function. And this was only possible because onboarder logged the pairwise did to the ledger. Now simultaneously I also went through this document posted by evernym (https://www.evernym.com/wp-content/uploads/2017/07/What-Goes-On-The-Ledger.pdf) which stated this- “A DID added directly to the Sovrin public ledger is called a public DID, whereas a pairwise pseudonymous DID shared and stored privately “off-ledger” between the agents for two identity holders is called a private DID. The ability for Sovrin infrastructure to support both is fundamental to both its Privacy by Design architecture as well as its ability to scale.” Could somebody please put some opinions or thoughts on it like why the indy-sdk or the sample code is designed in such a way that we had to store pairwise Did into the ledger although contrary to this has been strongly stated in the document I mentioned above. Thanks

PranayGandhi (Mon, 05 Aug 2019 12:12:32 GMT):
I observed the same issue but the issue wasn't consistent. Without doing any changes to the code or configuration file it sometimes used to occur and sometimes it didn't.

dbluhm (Mon, 05 Aug 2019 13:42:24 GMT):
To put it briefly, the sample code in the Indy SDK is out of date. It remains a good example of how to use the Indy SDK but it does not show best practices or demonstrate the agent to agent protocol.

PranayGandhi (Mon, 05 Aug 2019 13:45:14 GMT):
Yeah that could be the case. I have thought of passing the pairwise did to the new user as part of the connection request payload so that receiver doesn't have to look into the ledger for it. BTW thanks :)

dbluhm (Mon, 05 Aug 2019 13:45:52 GMT):
No problem! Are you familiar with Hyperledger Aries?

PranayGandhi (Mon, 05 Aug 2019 13:46:12 GMT):
No I haven't explored that much.

PranayGandhi (Mon, 05 Aug 2019 13:46:51 GMT):
I have got one more small doubt regarding indy-sdk

dbluhm (Mon, 05 Aug 2019 13:49:42 GMT):
I would actually recommend you take a look at the Aries Cloud Agent - Python project which contains an excellent getting started guide. Aries and Indy are closely related; Aries was born out of the Indy Agent community which developed standards for how to interact with your wallet and how to exchange credentials with others.

dbluhm (Mon, 05 Aug 2019 13:49:46 GMT):
Here is the GSG: https://github.com/hyperledger/aries-cloudagent-python/tree/master/docs/GettingStartedAriesDev

dbluhm (Mon, 05 Aug 2019 13:50:13 GMT):
Aries has a lot more to say about how to use Indy in actual applications

PranayGandhi (Mon, 05 Aug 2019 13:50:49 GMT):
Awesome. It should be a very helpful exploration for my project. Thanks a ton.

dbluhm (Mon, 05 Aug 2019 13:51:17 GMT):
:thumbsup:

PranayGandhi (Mon, 05 Aug 2019 14:00:56 GMT):
Hey

PranayGandhi (Mon, 05 Aug 2019 14:01:33 GMT):
Do you have any clue why different encryption schemas are being used in onboarding and getVernym functions?

PranayGandhi (Mon, 05 Aug 2019 14:02:27 GMT):
In onboarding they have used cryptoAnonCrypt function which in turn uses anonymous-encryption scheme.

PranayGandhi (Mon, 05 Aug 2019 14:03:03 GMT):
And in getVernym they have used cryptoAuthCrypt which in turn uses authenticated-encryption scheme.

dbluhm (Mon, 05 Aug 2019 14:05:47 GMT):
Again (unfortunately), I would not recommend you refer to the Indy SDK getting started guide for anything more than a reference of library calls. I'm not sure why in this case; someone else may be able to provide more insight.

PranayGandhi (Mon, 05 Aug 2019 14:07:03 GMT):
Okay.

PranayGandhi (Mon, 05 Aug 2019 14:07:03 GMT):
Thanks :)

Iso5786 (Mon, 05 Aug 2019 14:17:13 GMT):
Has joined the channel.

Iso5786 (Mon, 05 Aug 2019 14:17:14 GMT):
Hi, I am Daniel and I want to try to connect to the indy hyperledger via libindy with the IRMA project (https://irma.app/docs/what-is-irma/) for my master research. As the IRMA backend is written in go I can add libindy via cgo but I can only find examples in your docs how to use the lib via a python, java or rust wrapper. Could anyone help me out?

swcurran (Mon, 05 Aug 2019 17:18:35 GMT):
You might want to use Aries clients for the issuer, holder and verifier, and build your own DIDComm protocols on top of an Aries implementation (e.g. aries-cloudagent-python) that talk IRMA. That gets you a lot of the plumbing done and leaves you only with the IRMA part to bring it together. Note that I'm not familiar with IRMA, but it seems to be a verifiable credential model and that is what is being done with Indy. The purpose of Aries to support other VC models other than Indy.

Iso5786 (Mon, 05 Aug 2019 17:30:49 GMT):
Thx for quick reply! Just seeing that there exists an aries-framework for go (https://github.com/hyperledger/aries-framework-go). Maybe it's worth a look. I assume it would be better to post specific question w.r.t. aries to the channel #aries ?

sanchopansa (Tue, 06 Aug 2019 09:50:47 GMT):
Has joined the channel.

andrej-zirko (Tue, 06 Aug 2019 14:08:48 GMT):
Hello, I'm looking at indy-cloud-agent use case. I understand Aries is in the development and I have seen python aries agent, but I haven't found any Node.js implementation yet. I'm thinking about Node.js backend that will manage multiple wallets for me. Indy-sdk wallet now by default uses sqlite, which is fine for edge wallet. But what about cloud agent wallet? Postgres plugin is marked as experimental. Has anyone played with the postgres plugin? Is it stable? I'm basically thinking how to support wallet High Availability in the backend. Sqlite was never meant for HA scenario. Any thoughts?

swcurran (Tue, 06 Aug 2019 20:29:13 GMT):
We (BC Gov - @ianco specifically) developed the Postgres wallet and use it extensively in multiple use cases, including in managing wallets with up to about 7.5M credentials in Kubernetes environments. We would recommend it for high availability. We'll take a look at where it is marked as experimental and get a conversation going about whether or not it should be in that status.

AmanAgrawal (Wed, 07 Aug 2019 06:23:15 GMT):
Has joined the channel.

andrej-zirko (Wed, 07 Aug 2019 07:17:23 GMT):
Thank you for quick response. Postgres storage I'm referring to, lives in experimental/plugins folder in SDK - (https://github.com/hyperledger/indy-sdk/tree/master/experimental/plugins/postgres_storage) Thus I got a feeling it's experimental. Further in Outstanding Issues potential stability issues are mentioned. I also searched on JIRA for another outstanding issues and seen unmerged PR from december regarding code cleanup. I'd be happy to use Postgres storage if it can be considered stable.

swcurran (Wed, 07 Aug 2019 15:04:32 GMT):
Interesting. We'll look into that as we think it's likely been used as much as any other, particularly in production use cases.

swcurran (Wed, 07 Aug 2019 15:07:37 GMT):
@ianco is out of the office right now, but on his return we'll talk about and post about the potential stability issues. I suspect that the testing/production use has demonstrated this is fine, but he will know more.

mattatkiva (Wed, 07 Aug 2019 16:34:37 GMT):
I'll throw in that we (kiva) have chosen to use the postgres plug as well. our first use case will be for 5M wallets.

mattatkiva (Wed, 07 Aug 2019 16:34:37 GMT):
I'll throw in that we (kiva) have chosen to use the postgres plugin in a kubernetes environment, as well. Our first use case will be for 5M wallets.

andrej-zirko (Thu, 08 Aug 2019 12:46:22 GMT):
Thank you. I'll definitely look into the postgres plugin then. Is there a sample code how to load the plugin in Node.js? Or you rely on python for backend services?

ap (Thu, 08 Aug 2019 14:33:25 GMT):
Has joined the channel.

ap (Thu, 08 Aug 2019 14:35:27 GMT):
shree

smithbk (Thu, 08 Aug 2019 14:36:13 GMT):
Can anyone tell me how to debug the following? ```2019-08-08T14:07:18.748Z [indy] debug: target=indy::services::anoncreds::helpers module=indy::services::anoncreds::helpers file=src/services/anoncreds/helpers.rs line=44 message=build_credential_values >>> credential_values: {"first_name": AttributeValues { raw: "Alice", encoded: "3bc51062973c458d5a6f2d8d64a023246354ad7e064b1e4e009ec8a0699a3043" }, "ssn": AttributeValues { raw: "123-45-6789", encoded: "01a54629efb952287e554eb23ef69c52097a75aecc0e3a93ca0855ab6d7a31a0" }, "last_name": AttributeValues { raw: "Garcia", encoded: "2c3aaefea8267c66822f6edc0e42d9b7384695f9c0407eabda141770aab8901e" }, "big_attr": AttributeValues { raw: "small-attr", encoded: "97583a56b2e711d7a846dd26d230c5bec8570e4c6973bc71fbb05aec44a9ccc5" }, "degree": AttributeValues { raw: "Bachelor of Science, Marketing", encoded: "f62ecc1525940c395842bf3bacb6888d934649a0f5a8e4cf2b5ee9661bd725c0" }, "year": AttributeValues { raw: "2015", encoded: "2015" }, "status": AttributeValues { raw: "graduated", encoded: "b0c467ef1a19933b3f838ca56a2b6f38308b17babd3969376667d34fa753397c" }, "average": AttributeValues { raw: "5", encoded: "5" }} 2019-08-08T14:07:18.748Z [indy] debug: target=indy::api::anoncreds module=indy::api::anoncreds file=src/api/anoncreds.rs line=419 message=prepare_result_3: >>> Err(IndyError { inner: stack backtrace: 0: (0x7fc7a7bbddaf) 1: (0x7fc7a7bbd96f) 2: (0x7fc7a763541f) 3: (0x7fc7a76362cb) 4: (0x7fc7a77fc5fb) 5: (0x7fc7a77c0d9c) 6: (0x7fc7a77b75a2) 7: (0x7fc7a75de840) 8: (0x7fc7a763e243) 9: (0x7fc7a7be6869) 10: (0x7fc7a75d59ac) 11: (0x7fc7a7be5c2d) 12: start_thread (0x7fc7bf7a36b9) 13: clone (0x7fc7bf4d941c) 14: (0x0) UrsaCryptoError: Internal OpenSSL errorOpenSSL error Invalid library state }) 2019-08-08T14:07:18.748Z [indy] debug: target=indy::api::anoncreds module=indy::api::anoncreds file=src/api/anoncreds.rs line=420 message=indy_issuer_create_credential: cred_json: "_", revoc_id: "_", revoc_reg_delta_json: None 2019-08-08T14:07:18.751Z [main] error: IndyError: CommonInvalidState at Object.callback (/home/agent/bin/server/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10)``` I'm running in docker with the following dockerfile: ``` RUN apt update && \ apt upgrade -y && \ apt install -y apt-transport-https nano curl make g++ curl telnet net-tools netcat vim && \ apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 68DB5E88 && \ echo "deb https://repo.sovrin.org/sdk/deb xenial stable" > \ /etc/apt/sources.list.d/indy.list && \ curl -sSL https://deb.nodesource.com/gpgkey/nodesource.gpg.key | apt-key add - && \ echo "deb https://deb.nodesource.com/node_11.x xenial main" | \ tee /etc/apt/sources.list.d/nodesource.list && \ apt update && \ apt install -y node.js libindy && \ useradd -m -s /usr/bin/nologin agent ```

swcurran (Thu, 08 Aug 2019 14:54:45 GMT):
I don't think there are specific node.js examples, but it shouldn't matter. The wallet plugin is done at the indy-sdk level and implemented in rust, so works the same with all language wrappers. However, the python wrapper is more mature than that of node.js.

ap (Thu, 08 Aug 2019 15:33:05 GMT):
Hi all, I trying to generate proof request on prover side by using issuer proof. While executing the proverStoreCredential() method i am getting error - "org.hyperledger.indy.sdk.InvalidStructureException: A value being processed is not valid." How i can fix this ?

ap (Thu, 08 Aug 2019 15:33:59 GMT):

proof_request.png

ap (Thu, 08 Aug 2019 15:35:15 GMT):

Requested Credentials.png

sklump (Thu, 08 Aug 2019 16:32:40 GMT):
cred def ids are wrong

sklump (Thu, 08 Aug 2019 16:35:38 GMT):
should look like `:3:CL::`

fabian.wurster (Fri, 09 Aug 2019 14:01:25 GMT):
Has joined the channel.

fabian.wurster (Fri, 09 Aug 2019 14:01:26 GMT):
Hello, i am having a problem generating the android aar package of vcx which is described here: https://github.com/hyperledger/indy-sdk/blob/master/vcx/wrappers/java/README.md#aar I have the compiled `libvcx.so` but there is no folder `indy-sdk/vcx/wrappers/java/vcx`. So I put the so file in `indy-sdk/vcx/wrappers/java/android/src/main/jniLibs/aarm64/libvcx.so`. When I run `./gradlew clean build --project-dir=android` I get many errors saying: ``` ~/indy-sdk/vcx/wrappers/java/src/main/java/com/evernym/sdk/vcx/schema/SchemaApi.java:13: error: cannot find symbol import java.util.concurrent.CompletableFuture; ^ symbol: class CompletableFuture location: package java.util.concurrent ``` I have java 8 and 11 installed but java 8 is set as default. Do you have any idea where the error could be coming from? Regards, Fabian

AlexITC (Fri, 09 Aug 2019 15:59:35 GMT):
Has joined the channel.

sukalpomitra (Fri, 09 Aug 2019 17:04:32 GMT):
Check your java version. You should use atleast java 1.8

simran (Mon, 12 Aug 2019 10:51:50 GMT):
Has joined the channel.

JeromeK (Mon, 12 Aug 2019 13:13:42 GMT):
Hey I want to install a new Libindy-Version on Mac. So i used the script, provided within indy-sdk/libindy I get the following Rust-Error, after the execution of "cargo build". Any know bug or fixes? `missing delta bases; class=Indexer (15)`

JeromeK (Mon, 12 Aug 2019 13:13:42 GMT):
Hey, I want to install a new Libindy-Version on Mac. So i used the script, provided within indy-sdk/libindy I get the following Rust-Error, after the execution of "cargo build". Any know bug or fixes? ` Updating registry `https://github.com/rust-lang/crates.io-index` error: failed to fetch `https://github.com/rust-lang/crates.io-index` Caused by: missing delta bases; class=Indexer (15)`

JeromeK (Mon, 12 Aug 2019 13:13:42 GMT):
Hey, I want to install a new Libindy-Version on Mac. So i used the script, provided within indy-sdk/libindy I get the following Rust-Error, after the execution of "cargo build". Any know bug or fixes? `Updating registry "https://github.com/rust-lang/crates.io-index" error: failed to fetch `https://github.com/rust-lang/crates.io-index` Caused by: missing delta bases; class=Indexer (15)`

JeromeK (Mon, 12 Aug 2019 13:13:42 GMT):
Hey, I want to install a new Libindy-Version on Mac. So i used the script, provided within indy-sdk/libindy I get the following Rust-Error, after the execution of "cargo build". Any know bug or fixes? `Updating registry "https://github.com/rust-lang/crates.io-index" error: failed to fetch https://github.com/rust-lang/crates.io-index` Caused by: missing delta bases; class=Indexer (15)`

JeromeK (Mon, 12 Aug 2019 13:13:42 GMT):
Hey, I want to install a new Libindy-Version on Mac. So i used the script, provided within indy-sdk/libindy I get the following Rust-Error, after the execution of "cargo build". Any know bug or fixes? `Updating registry https://github.com/rust-lang/crates.io-index error: failed to fetch https://github.com/rust-lang/crates.io-index` Caused by: missing delta bases; class=Indexer (15)`

JeromeK (Mon, 12 Aug 2019 13:13:42 GMT):
Hey, I want to install a new Libindy-Version on Mac. So i used the script, provided within indy-sdk/libindy I get the following Rust-Error, after the execution of "cargo build". Any know bug or fixes? `Updating registry https://github.com/rust-lang/crates.io-index error: failed to fetch https://github.com/rust-lang/crates.io-index Caused by: missing delta bases; class=Indexer (15)`

JeromeK (Mon, 12 Aug 2019 13:13:42 GMT):
Hey, I want to install a new Libindy-Version on Mac. So i used the script, provided within indy-sdk/libindy I get the following Rust-Error, after the execution of "cargo build". Any know bug or fixes? ```Updating registry https://github.com/rust-lang/crates.io-index error: failed to fetch https://github.com/rust-lang/crates.io-index Caused by: missing delta bases; class=Indexer (15)```

JeromeK (Mon, 12 Aug 2019 13:13:42 GMT):
Hey, I want to install a new Libindy-Version on Mac. So i used the script, provided within indy-sdk/libindy I get the following Rust-Error, after the execution of `cargo build`. Any know bug or fixes? ```Updating registry https://github.com/rust-lang/crates.io-index error: failed to fetch https://github.com/rust-lang/crates.io-index Caused by: missing delta bases; class=Indexer (15)```

MALodder (Mon, 12 Aug 2019 14:13:31 GMT):
@JeromeK what is the Rust version you are using? Its the output from running `cargo -V`

JeromeK (Mon, 12 Aug 2019 14:16:41 GMT):
@JeromeK what is the Rust version you are using? Its the output from running `cargo -V`

JeromeK (Mon, 12 Aug 2019 14:17:05 GMT):
cargo 1.29.0 (524a578d7 2018-08-05)

MALodder (Mon, 12 Aug 2019 14:17:54 GMT):
@jerok

MALodder (Mon, 12 Aug 2019 14:18:08 GMT):
@JeromeK I believe version 1.36 is required now

JeromeK (Mon, 12 Aug 2019 14:22:27 GMT):
I upgraded my version but still recive the same error :/

MALodder (Mon, 12 Aug 2019 14:23:20 GMT):
@JeromeK okay, which script are you trying to run?

swcurran (Mon, 12 Aug 2019 15:09:58 GMT):
Not sure it's changed in the last couple of weeks, but @smithsamuelm found that rust version 1.35 was required. 1.36 did not work for some reason.

mattatkiva (Mon, 12 Aug 2019 15:43:43 GMT):
I had couple of errors on packages with 1.36. 1.35 worked. I didn't see the errors @JeromeK was experiencing though. I can't help wonder if its a different issue

mattatkiva (Mon, 12 Aug 2019 15:43:43 GMT):
I had couple of errors on indy-sdk dependency packages with 1.36. 1.35 worked. I didn't see the errors @JeromeK was experiencing though. I can't help wonder if its a different issue

ap (Mon, 12 Aug 2019 17:12:12 GMT):
@sklump Thanks for correcting my mistakes. I tried as per your suggestion and still i am facing the same issue while executing the proverStoreCredential() method. Error - "org.hyperledger.indy.sdk.InvalidStructureException: A value being processed is not valid." Please find below screen shot for more information.

ap (Mon, 12 Aug 2019 17:12:32 GMT):

Para1.png

ap (Mon, 12 Aug 2019 17:12:52 GMT):

credDefJson.png

ianco (Mon, 12 Aug 2019 17:18:29 GMT):
It looks like 1.36 is required now

tomislav (Mon, 12 Aug 2019 17:31:26 GMT):
Does anyone know what could be causing this error when trying to use ./mac.build.sh ? We use latest nightly rust toolchain. ``` error: proc-macro derive panicked --> src/utils/crypto/randombytes/sodium.rs:10:10 | 10 | #[derive(Zeroize)] | ^^^^^^^ | = help: message: unknown zeroize attribute: (drop) error: aborting due to previous error error: Could not compile `libindy`. To learn more, run the command again with --verbose. Error: failed on line 57. ```

sklump (Mon, 12 Aug 2019 18:26:40 GMT):
Are these supposed to be from the same example? The schema seq number is 33 but the cred def is for a schema at seq number 25.

MALodder (Mon, 12 Aug 2019 18:36:05 GMT):
@tomislav that error is from the zeroize crate, I think you need to be using rust 1.35

MALodder (Mon, 12 Aug 2019 18:36:08 GMT):
not nightly

MALodder (Mon, 12 Aug 2019 18:42:10 GMT):
The other possibility is that the Cargo.lock version was bumped to from zeroize 0.8 to 0.9

tomislav (Mon, 12 Aug 2019 21:45:59 GMT):
Thanks @MALodder it worked when building from "rc" branch.

ap (Tue, 13 Aug 2019 02:44:34 GMT):
@sklump Sorry , I upload wrong one , Please refer below one

ap (Tue, 13 Aug 2019 02:45:02 GMT):

CredDef Json.png

simran (Tue, 13 Aug 2019 05:48:24 GMT):
hello team when `prover store credentials `in wallet then after some time he wants to see the `credsvalue ` from the wallet so how he can see them ???/

JeromeK (Tue, 13 Aug 2019 06:44:44 GMT):
hmm i still recive the same error, even with the 1.35.0

AxelNennker (Tue, 13 Aug 2019 07:17:26 GMT):
some low hanging fruit here to improve libindy's code. Some topics to think deeper about. ``` ignisvulpis@namenlos:~/development/hyperledger/indy-sdk/libindy$ cargo clippy > /tmp/clippy.txt 2>&1 wc -l /tmp/cli ignisvulpis@namenlos:~/development/hyperledger/indy-sdk/libindy$ wc -l /tmp/clippy.txt 2535 /tmp/clippy.txt ignisvulpis@namenlos:~/development/hyperledger/indy-sdk/libindy$ vi /tmp/clippy.txt ignisvulpis@namenlos:~/development/hyperledger/indy-sdk/libindy$ grep -e '^warning' /tmp/clippy.txt | sort | uniq -c | sort -n 1 warning: casting i32 to i64 may become silently lossy if you later change the type 1 warning: explicit lifetimes given in parameter types where they could be elided (or replaced with `'_` if needed by type declaration) 1 warning: `if _ { .. } else { .. }` is an expression 1 warning: long literal lacking separators 1 warning: Matching on `Some` with `ok()` is redundant 1 warning: methods called `from_*` usually take no self; consider choosing a less ambiguous name 1 warning: the function has a cognitive complexity of 27 1 warning: the function has a cognitive complexity of 36 1 warning: the function has a cognitive complexity of 39 1 warning: the function has a cognitive complexity of 50 1 warning: the loop variable `i` is used to index `nodes` 1 warning: this function has too many arguments (10/7) 1 warning: this function has too many arguments (11/7) 1 warning: this function has too many arguments (15/7) 1 warning: this function has too many arguments (22/7) 1 warning: this function has too many arguments (24/7) 1 warning: this pattern takes a reference on something that is being de-referenced 1 warning: you seem to be trying to use `&Box`. Consider using just `&T` 2 warning: identical conversion 2 warning: this function has too many arguments (12/7) 2 warning: this function has too many arguments (26/7) 2 warning: You matched a field with a wildcard pattern. Consider using `..` instead 3 warning: called `map(f)` on an Option value where `f` is a unit closure 3 warning: module has the same name as its containing module 3 warning: this function has too many arguments (9/7) 4 warning: `assert!(false)` should probably be replaced 4 warning: `ref` on an entire `let` pattern is discouraged, take a reference with `&` instead 4 warning: useless use of `vec!` 8 warning: large size difference between variants 9 warning: you seem to be trying to use match for destructuring a single pattern. Consider using `if let` 10 warning: writing `&Vec<_>` instead of `&[_]` involves one more reference and cannot be used with non-Vec-based slices. 14 warning: this function has too many arguments (8/7) 67 warning: very complex type used. Consider factoring parts into `type` definitions 84 warning: use of `ok_or` followed by a function call ignisvulpis@namenlos:~/development/hyperledger/indy-sdk/libindy$ ```

simran (Tue, 13 Aug 2019 10:08:53 GMT):

Screenshot from 2019-08-13 15-21-58.png

andrew.whitehead (Tue, 13 Aug 2019 10:24:37 GMT):
A wallet handle should never be hard-coded like that. You would want to open the wallet and pass around the handle as a variable within the same process.

sklump (Tue, 13 Aug 2019 11:52:34 GMT):
It looks like your cred def supports revocation but your proof request does not specify any non-revocation intervals, for starters. I suggest you take another look at the unit tests in the wrappers.

superafro12 (Tue, 13 Aug 2019 11:56:20 GMT):
Has left the channel.

ap (Tue, 13 Aug 2019 12:09:46 GMT):
We tried creating proof without revocation, but we still faced the same issue. When we use Alice demo flow, it works fine, but when we try to customize the requested_attributes, we face the CommonInvalidStructure issue. We have cross checked the format. Earlier, out cred_def_id format was wrong, which we corrected. But the error still remains.

simran (Tue, 13 Aug 2019 12:51:36 GMT):
yes i have tried in same script file but not getting anything in records value @andrew.whitehead

simran (Tue, 13 Aug 2019 12:51:56 GMT):
`indyerror:212`

simran (Tue, 13 Aug 2019 12:52:09 GMT):
without passing this its work fine

AntonSvetin (Tue, 13 Aug 2019 14:22:10 GMT):
Has joined the channel.

AntonSvetin (Tue, 13 Aug 2019 14:24:31 GMT):
Hi, I have a question about pricing on the page https://sovrin.org/issue-credentials/ about DID write. For what types of DID the pricing is referring to? If this is the wrong chat to ask this. Where can I get that information. Thx

andrej-zirko (Tue, 13 Aug 2019 15:08:28 GMT):
I was interested how the storage plugin should be loaded in Node.js as it is dynamic library. I was able to figure it out. I pushed sample here (https://github.com/andrej-zirko/indy-sdk-storage) in case it would help anybody else. Thank you a lot for your help.

mattatkiva (Tue, 13 Aug 2019 15:57:35 GMT):
you will need to use the ffi package to load the postgres library. then you will need to postgresstorage_init and init_storagetype functions in postgres library. when you create wallet your wallet config must specify the postgres plugin

lynn.bendixsen (Tue, 13 Aug 2019 16:33:47 GMT):
The DID referred to in the pricing document boils down to any ADD NYM transaction written to the ledger. It does not apply to DID's that are just stored in a users Wallet and not written to the ledger.

AntonSvetin (Wed, 14 Aug 2019 06:47:33 GMT):
Thx for the explanation @lynn.bendixsen

AntonSvetin (Wed, 14 Aug 2019 06:51:38 GMT):
Hi, I am testing `indy-sdk` example and I am interested if I can look at ledger transaction that are created by the example.

AntonSvetin (Wed, 14 Aug 2019 06:57:24 GMT):
What about `Credential Definition` is this only for creating Credential Definition from the schema or is this every time you create a credential for the identity?

AntonSvetin (Wed, 14 Aug 2019 07:41:35 GMT):
And how is this payed? Is there a automatic system for this?

dbluhm (Wed, 14 Aug 2019 13:18:44 GMT):
Only one credential definition is needed to issue many credentials of that type

JeromeK (Wed, 14 Aug 2019 14:38:34 GMT):
Hey Guys Is there a way to "authenticate" a DID for example: If I want to create a Pairwise-Connection with my friend. And for some reasons my friend hands me wrong did - I will still be able to create the pairwise-connection.

lynn.bendixsen (Wed, 14 Aug 2019 18:23:32 GMT):
It is currently payed through the Sovrin Foundation sending an invoice to those using our MainNet (using our testing networks is free) and there is a plan in the works for an automated payment method.

esplinr (Thu, 15 Aug 2019 02:44:48 GMT):
Have you raised these in Jira?

esplinr (Thu, 15 Aug 2019 02:46:58 GMT):
You want to browse your local development ledger? Or are you wanting to browse one of the Sovrin networks?

smithbk (Thu, 15 Aug 2019 15:26:34 GMT):
Hi, I'm using the node.js wrapper and getting fairly frequent SIGSEGV's. Does anyone have any recommendations for debugging?

mattatkiva (Thu, 15 Aug 2019 16:00:56 GMT):
my first thought is this sounds like a mismatch in indy version and npm package. we are using it with no errors like that.

AntonSvetin (Thu, 15 Aug 2019 16:51:40 GMT):
Thx for the help guys!

AntonSvetin (Thu, 15 Aug 2019 16:52:40 GMT):
For now I wish to browse my local development ledger. But I would also like later to look at Sovrin networks.

AxelNennker (Thu, 15 Aug 2019 17:53:35 GMT):
New Rust version `stable-x86_64-unknown-linux-gnu updated - rustc 1.37.0 (eae3437df 2019-08-13)` brings 280 new warnings `trait objects without an explicit `dyn` are deprecated`

smithbk (Thu, 15 Aug 2019 18:17:26 GMT):
Thanks. Can you tell me which indy version and npm package you are using? I'm using the latest stable sovrin build and npm `"indy-sdk": "^1.9.0-dev-1148"`

mattatkiva (Thu, 15 Aug 2019 18:20:16 GMT):
`"indy-sdk": "^1.11.0",`

smithbk (Thu, 15 Aug 2019 18:20:49 GMT):
thx

mattatkiva (Thu, 15 Aug 2019 18:21:40 GMT):
`-rw-r--r-- 1 root root 10916968 Aug 14 12:43 libindy.so`

mattatkiva (Thu, 15 Aug 2019 18:21:59 GMT):
im not aware of any way to query the library to find a version

smithbk (Thu, 15 Aug 2019 18:22:16 GMT):
pwd

zzx02 (Fri, 16 Aug 2019 02:35:20 GMT):
Has joined the channel.

dkushagra (Fri, 16 Aug 2019 05:56:22 GMT):
Has joined the channel.

AntonSvetin (Fri, 16 Aug 2019 06:55:56 GMT):
Hey @esplinr is it possible even ?

AntonSvetin (Fri, 16 Aug 2019 08:12:51 GMT):
Hi, I have a question about creating / issuing credentials? What or when is something written to the ledger when credentials is being issued?

sukalpomitra (Fri, 16 Aug 2019 08:44:27 GMT):
I dont think anything gets written. In the ledger on the credential definition is written which is before you issue

sukalpomitra (Fri, 16 Aug 2019 08:44:27 GMT):
I dont think anything gets written. In the ledger only the credential definition is written which is before you issue

AntonSvetin (Fri, 16 Aug 2019 08:46:56 GMT):
Ok so everything is saved in the wallets then?

sukalpomitra (Fri, 16 Aug 2019 08:47:15 GMT):
yes

sukalpomitra (Fri, 16 Aug 2019 08:47:15 GMT):
yes, the credential record in the wallet has the credential definition id

AntonSvetin (Fri, 16 Aug 2019 08:49:57 GMT):
So how do you know or you can prove that some credential was issued by someone ?

AntonSvetin (Fri, 16 Aug 2019 08:50:15 GMT):
Just by credential definition id

sukalpomitra (Fri, 16 Aug 2019 08:50:30 GMT):
the credential definition is tagged to an issuer, the credenial definition id has the issuers public DID

AntonSvetin (Fri, 16 Aug 2019 08:55:48 GMT):
Ok, thx for the info. Do you maybe know how I can see what is written to the ledger from the example in indy-sdk repo. ?

AntonSvetin (Fri, 16 Aug 2019 08:57:32 GMT):
I am talking about the docker images I am running locally.

sukalpomitra (Fri, 16 Aug 2019 08:58:28 GMT):
which ledger are you pointing to? if its sovrin then maybe this one https://indyscan.io/home/sovmain. If it is BcGov. you are spinning up von netywork locally then just go to localhost:9000 and if you are using bcgoc test network then http://138.197.138.255/

sukalpomitra (Fri, 16 Aug 2019 08:58:28 GMT):
which ledger are you pointing to? if its Sovrin then maybe this one https://indyscan.io/home/sovmain. If you are spinning up von network locally then just go to localhost:9000 and if you are using BCGov test network then http://138.197.138.255/

AntonSvetin (Fri, 16 Aug 2019 08:59:44 GMT):
I am talking about this https://github.com/hyperledger/indy-sdk/blob/master/ci/indy-pool.dockerfile

sukalpomitra (Fri, 16 Aug 2019 09:00:35 GMT):
not sure about this one

AntonSvetin (Fri, 16 Aug 2019 09:06:13 GMT):
Ok thx for the help, I got some things cleared up :)

sukalpomitra (Fri, 16 Aug 2019 09:21:16 GMT):
:thumbsup:

sklump (Fri, 16 Aug 2019 14:52:29 GMT):
Here's something I found in indy-sdk 1.11.0: in python wrapper `tests/anoncreds/conftest.py`, the fixtures `issuer_1_gvt_cred_def_id`, `issuer_1_xyz_cred_def_id`, `issuer_2_gvt_cred_def_id` look like `"NcYxiDXkpYi6ov5FcYDi1e:3:CL:NcYxiDXkpYi6ov5FcYDi1e:2:gvt:1.0:tag1"` etc. These are not cred def ids as I have understood them in the node protocol v2; i.e., `:3:CL::` Has this specification changed recently? If so, shouldn't the node protocol version have incremented? I feel like I'm in some kind of Mandela effect. Only, it wasn't kind enough to update all the code I've written since 2017 accordingly :-/

sklump (Fri, 16 Aug 2019 14:52:29 GMT):
Here's something I found in indy-sdk 1.11.0: in python wrapper `tests/anoncreds/conftest.py`, the fixtures `issuer_1_gvt_cred_def_id`, `issuer_1_xyz_cred_def_id`, `issuer_2_gvt_cred_def_id` look like `"NcYxiDXkpYi6ov5FcYDi1e:3:CL:NcYxiDXkpYi6ov5FcYDi1e:2:gvt:1.0:tag1"` etc. These are not cred def ids as I have understood them in the node protocol v2; i.e., `:3:CL::` (protocol v2 added the `:`). Has this specification changed recently? If so, shouldn't the node protocol version have incremented? I feel like I'm in some kind of Mandela effect. Only, it wasn't kind enough to update all the code I've written since 2017 accordingly :-/

sklump (Fri, 16 Aug 2019 14:52:29 GMT):
Here's something I found in indy-sdk 1.11.0: in python wrapper `tests/anoncreds/conftest.py`, the fixtures `issuer_1_gvt_cred_def_id`, `issuer_1_xyz_cred_def_id`, `issuer_2_gvt_cred_def_id` look like `"NcYxiDXkpYi6ov5FcYDi1e:3:CL:NcYxiDXkpYi6ov5FcYDi1e:2:gvt:1.0:tag1"` etc. These are not cred def ids as I have understood them in the node protocol v2; i.e., `:3:CL::` (protocol v2 added the `:`). Has this specification changed recently? If so, shouldn't the node protocol version have incremented? I feel like I'm in some kind of Mandela effect. Only, it wasn't kind enough to update all the code I've written since 2017 accordingly :-/ The knock-on effects are going to be non-trivial.

sklump (Fri, 16 Aug 2019 14:52:29 GMT):
Here's something I found in indy-sdk 1.11.0: in python wrapper `tests/anoncreds/conftest.py`, the fixtures `issuer_1_gvt_cred_def_id`, `issuer_1_xyz_cred_def_id`, `issuer_2_gvt_cred_def_id` look like `"NcYxiDXkpYi6ov5FcYDi1e:3:CL:NcYxiDXkpYi6ov5FcYDi1e:2:gvt:1.0:tag1"` etc. These are not cred def ids as I have understood them in the node protocol v2; i.e., `:3:CL::` (protocol v2 added the `:`). Has this specification changed recently? If so, shouldn't the node protocol version have incremented? I feel like I'm in some kind of Mandela effect. Only, it wasn't kind enough to update all the code I've written since 2017 accordingly :-/ The knock-on effects are going to be non-trivial. _Update:_ it appears it has always been this way now. I have no idea how anything I've built ever worked. This is kind of blowing my mind.

sklump (Fri, 16 Aug 2019 18:08:36 GMT):
*Further peril:* there are 2 ways to specify a cred def id, and it requires a ledger check to see whether two cred def ids are equivalent (i.e., if the schema seq no in the short version corresponds to the schema id in the long version, all other elements being equal). Offline, this is unknowable. There could be a tiny bait-and-switch attack here if there are multiple schemas from the same origin that duplicate attribute names.

smithbk (Fri, 16 Aug 2019 19:05:39 GMT):
I'm still having problems. If you could share a portion of your dockerfile, that would be very helpful.

smithbk (Fri, 16 Aug 2019 19:07:42 GMT):
Here is mine: ```RUN apt update && \ apt upgrade -y && \ apt install -y apt-transport-https nano curl make g++ curl telnet net-tools netcat vim && \ apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 68DB5E88 && \ echo "deb https://repo.sovrin.org/sdk/deb xenial stable" > \ /etc/apt/sources.list.d/indy.list && \ curl -sSL https://deb.nodesource.com/gpgkey/nodesource.gpg.key | apt-key add - && \ echo "deb https://deb.nodesource.com/node_11.x xenial main" | \ tee /etc/apt/sources.list.d/nodesource.list && \ apt update && \ apt install -y node.js libindy && \ useradd -m -s /usr/bin/nologin agent```

swcurran (Fri, 16 Aug 2019 20:06:56 GMT):
@esplinr - See Stephen's comments about the two forms of Cred Def IDs. Do you have insight on whether there was a recent change in that area? Any background on it if it was a change? Should we assume that either format could be used at any given time, or is it more obvious than that?

esplinr (Sat, 17 Aug 2019 04:20:43 GMT):
There isn't an out-of-the-box ledger browser tool, but you can use the Indy CLI to look up each transaction you submit to the ledger.

esplinr (Sat, 17 Aug 2019 04:21:25 GMT):
Here are two ledger browsers you can set up: https://sovrin-mainnet-browser.vonx.io/browse/domain?page=1&query=&txn_type= https://indyscan.io/home/SOVRIN_MAINNET

esplinr (Sat, 17 Aug 2019 04:24:40 GMT):
I'm not familiar with this issue. Any thoughts @Artemkaaas or @sergey.minaev ?

AntonSvetin (Mon, 19 Aug 2019 07:09:59 GMT):
Thx @esplinr

simran (Mon, 19 Aug 2019 11:19:22 GMT):
hello guys i have one doubt in seed the value will be combination of string or int or only string, int of 32 bit value

simran (Mon, 19 Aug 2019 11:23:31 GMT):
when i want to pass the seed value dynamically

simran (Mon, 19 Aug 2019 11:25:50 GMT):
function`keyForDid` is working sometime and sometime not why is it so ???

simran (Mon, 19 Aug 2019 13:21:23 GMT):
`(node:25061) UnhandledPromiseRejectionWarning: IndyError: 212`

AntonSvetin (Mon, 19 Aug 2019 14:30:12 GMT):
This is because the did you are looking for is not on the ledger.

AntonSvetin (Mon, 19 Aug 2019 14:30:12 GMT):
This is because the DID you are looking for is not on the ledger.

swcurran (Mon, 19 Aug 2019 15:50:07 GMT):
Would really like to know about this.

sklump (Tue, 20 Aug 2019 10:23:29 GMT):
My guess is that effective indy-sdk 1.11.0 or so, all newly created cred-def-ids will come back long form on cred def creation and propagate thus everywhere they go. I too would like to know what happened. I've seen some code that was not mine anticipating a sequence number where there is now a whole schema-id, so I am satisfied I have not changed universes. The new form is better because it contains all info in the cred def id. However, today is going to be a day of retrofitting my existing code.

sklump (Tue, 20 Aug 2019 10:50:23 GMT):
_update_: it may be more complicated than I thought. I may have been operating under the wrong idea for a very long time and not noticed.

sklump (Tue, 20 Aug 2019 12:35:19 GMT):
_Update: It Gets Weirder Still_ 1: git clone indy-sdk 2: rustup update, cargo build release, copy library to /usr/lib 3: create python anoncreds no-op wrapper test, output cred def ids as conftest.py creates via `anoncreds.issuer_create_and_store_credential_def`: looks like `NcYxiDXkpYi6ov5FcYDi1e:3:CL:NcYxiDXkpYi6ov5FcYDi1e:2:gvt:1.0:tag1` 4: pipenv install 1.11.0-dev-1274, run same code via von_anchor `Issuer.send_cred_def()`, calling `anoncreds.issuer_create_and_store_credential_def`: looks like ` WgWxqztrNooG92RXvxSTWv:3:CL:15:tag`. Credentials created cite their respective cred def ids as created: long form stays long, short form stays short. Question: How does indy-sdk end up with two different cred def id forms through the same API? There must be something elementary I am missing.

sklump (Tue, 20 Aug 2019 12:35:19 GMT):
*_Update: It Gets Weirder Still_* 1: git clone indy-sdk 2: rustup update, cargo build release, copy library to /usr/lib 3: create python anoncreds no-op wrapper test, output cred def ids as conftest.py creates via `anoncreds.issuer_create_and_store_credential_def`: looks like `NcYxiDXkpYi6ov5FcYDi1e:3:CL:NcYxiDXkpYi6ov5FcYDi1e:2:gvt:1.0:tag1` 4: pipenv install 1.11.0-dev-1274, run same code via von_anchor `Issuer.send_cred_def()`, calling `anoncreds.issuer_create_and_store_credential_def`: looks like ` WgWxqztrNooG92RXvxSTWv:3:CL:15:tag`. Credentials created cite their respective cred def ids as created: long form stays long, short form stays short. Question: How does indy-sdk end up with two different cred def id forms through the same API? There must be something elementary I am missing. I am going to try to trace it down in the rust.

sklump (Tue, 20 Aug 2019 13:54:23 GMT):
*OK*, some clarity follows: https://github.com/hyperledger/indy-sdk/blob/da4da126c5fb81fa2bb2d6b8215374a8e53ce73a/libindy/src/commands/anoncreds/issuer.rs#L353 If the schema as the caller passes it to the create-and-store-cred-def API call comes fresh as created, never written back to ledger and then read back, picking up a sequence number, then its cred def id will forever take a clone of the schema id instead of the sequence number in (zero-based) slot#3. Since von_anchor always reads back any schema it from the ledger, it always gets the short form. However, different implementations with which we want to interoperate, can create the schema, write it, not update the local data structure, then create the cred def. This is IMO unnecessarily sloppy (indy-sdk should kick out any cred def id on a schema without a seq no) but we can accommodate it. I will have to have a think about how best to do so.

sklump (Tue, 20 Aug 2019 13:54:23 GMT):
*OK*, some clarity follows: https://github.com/hyperledger/indy-sdk/blob/da4da126c5fb81fa2bb2d6b8215374a8e53ce73a/libindy/src/commands/anoncreds/issuer.rs#L353 If the schema as the caller passes it to the create-and-store-cred-def API call comes fresh as created, never written back to ledger and then read back, hence never picking up a sequence number, then its cred def id will forever take a clone of the schema id instead of the sequence number in (zero-based) slot#3. Since von_anchor always reads back any schema it from the ledger, it always gets the short form. However, different implementations with which we want to interoperate, can create the schema, write it, not update the local data structure, then create the cred def. This is IMO unnecessarily sloppy (indy-sdk should kick out any call to create a cred def on a schema without a seq no) but we can accommodate it. I will have to have a think about how best to do so.

sklump (Tue, 20 Aug 2019 13:54:23 GMT):
*OK*, some clarity follows: https://github.com/hyperledger/indy-sdk/blob/da4da126c5fb81fa2bb2d6b8215374a8e53ce73a/libindy/src/commands/anoncreds/issuer.rs#L353 If the schema as the caller passes it to the create-and-store-cred-def API call comes fresh as created, never written back to ledger and then read back, hence never picking up a sequence number, then its cred def id will forever take a clone of the schema id instead of the sequence number in (zero-based) slot#3. Since von_anchor always reads back any schema it from the ledger, it always gets the short form. However, different implementations with which we want to interoperate, can create the schema, write it, not update the local data structure, then create the cred def. This is IMO unnecessarily sloppy (indy-sdk should kick out any call to create a cred def on a schema without a seq no, or else always clone the whole schema-id) but we can accommodate it. I will have to have a think about how best to do so.

sklump (Tue, 20 Aug 2019 13:54:23 GMT):
*OK*, some clarity follows: https://github.com/hyperledger/indy-sdk/blob/da4da126c5fb81fa2bb2d6b8215374a8e53ce73a/libindy/src/commands/anoncreds/issuer.rs#L353 If the schema as the caller passes it to the create-and-store-cred-def API call comes fresh as created, never written back to ledger and then read back, hence never picking up a sequence number, then its cred def id will forever take a clone of the schema id instead of the sequence number in (zero-based) slot#3. Since von_anchor always reads back any schema it from the ledger, it always gets the short form. However, different implementations with which we want to interoperate, can create the schema, write it, not update the local data structure, then create the cred def. This is IMO unnecessarily sloppy (indy-sdk should kick out any call to create a cred def on a schema without a seq no, or else, probably better, always clone the whole schema-id) but we can accommodate it. I will have to have a think about how best to do so.

sklump (Tue, 20 Aug 2019 13:54:23 GMT):
*OK*, some clarity follows: https://github.com/hyperledger/indy-sdk/blob/da4da126c5fb81fa2bb2d6b8215374a8e53ce73a/libindy/src/commands/anoncreds/issuer.rs#L353 If the schema as the caller passes it to the create-and-store-cred-def API call comes fresh as created, never written back to ledger and then read back, hence never picking up a sequence number, then its cred def id will forever take a clone of the schema id instead of the sequence number in (zero-based) slot#3. Since von_anchor always reads back any schema it from the ledger upon creation, it always gets the short form. However, different implementations with which we want to interoperate, can create the schema, write it, not update the local data structure, then create the cred def. This is IMO unnecessarily sloppy (indy-sdk should kick out any call to create a cred def on a schema without a seq no, or else, probably better, always clone the whole schema-id) but we can accommodate it. I will have to have a think about how best to do so.

esplinr (Tue, 20 Aug 2019 14:25:49 GMT):
I think this is the result of partially completed work from spring 2018, and was released in Indy Node 1.6.

esplinr (Tue, 20 Aug 2019 14:26:24 GMT):
See INDY-1375 for the Epic, and IS-567 for the work that needs to be completed.

esplinr (Tue, 20 Aug 2019 14:29:19 GMT):
Partially supported request format is documented here: https://github.com/hyperledger/indy-node/blob/c964f5c55bf5853799449aef1b6faad21d7ccbe6/docs/requests.md#common-request-structure

sklump (Tue, 20 Aug 2019 14:31:10 GMT):
Regardless, it is wrong IMO to waffle the format of a key identifier based on whether the data it has at the time is complete, when it ought to be necessarily available on the ledger -- in particular, including less info when the feedstock has more, and more when it has less. Does that make sense?

sklump (Tue, 20 Aug 2019 14:31:10 GMT):
Regardless, it is wrong IMO to waffle the format of an important identifier based on whether the data it has at the time is complete, when it ought to be necessarily available on the ledger -- in particular, including less info when the feedstock has more, and more when it has less. Does that make sense?

esplinr (Tue, 20 Aug 2019 14:34:17 GMT):
I added this to the backlog for a future conversation during an Indy Maintainers cal.

esplinr (Tue, 20 Aug 2019 14:34:17 GMT):
I added this to the backlog for a future conversation during an Indy Maintainers call.

sklump (Tue, 20 Aug 2019 14:34:42 GMT):
Thanks, feel free to ping me when it comes up and I can talk about it if it helps.

esplinr (Tue, 20 Aug 2019 15:17:58 GMT):
We have a number of issues to discuss together. I'm not sure how fast we will get to that one since it has been around for a long time. I recommend you attend as often as is practical.

esplinr (Tue, 20 Aug 2019 15:18:17 GMT):
We need to figure out together who is motivated to work on this problem.

esplinr (Tue, 20 Aug 2019 15:18:33 GMT):
(I recognize that the US AM call is the only one that fits your work schedule.)

esplinr (Tue, 20 Aug 2019 15:18:33 GMT):
If you join, you can raise the topic as a concern for you and we'll make sure to cover it. I recognize that the US AM call is the only one that fits your work schedule.

andrew.whitehead (Tue, 20 Aug 2019 22:06:22 GMT):
Quick questions about the `blob_storage` methods because I don't see them covered anywhere: Can it be assumed that reader and writer handles are automatically cleaned up (since there aren't methods to do that explicitly)? Also, can a reader handle be reused safely? That seems to work but I'm not sure it's officially supported

simran (Wed, 21 Aug 2019 05:20:24 GMT):
hello team can you please help me how i can create my own ledger for create the multiple users in indy

lynn.bendixsen (Wed, 21 Aug 2019 15:32:10 GMT):
Here a couple of links to get you started. Feel free to ask more specific questions here when you run into difficulties. https://medium.com/@smaldeniya/setup-hyperledger-indy-pool-in-local-linux-environment-using-docker-304d13eb86dc https://medium.com/@smaldeniya/setup-hyperledger-indy-pool-in-local-linux-environment-using-docker-304d13eb86dc

lynn.bendixsen (Wed, 21 Aug 2019 15:32:10 GMT):
Here are a couple of links to get you started. Feel free to ask more specific questions here when you run into difficulties. https://medium.com/@smaldeniya/setup-hyperledger-indy-pool-in-local-linux-environment-using-docker-304d13eb86dc https://medium.com/@smaldeniya/setup-hyperledger-indy-pool-in-local-linux-environment-using-docker-304d13eb86dc

SubramaniyamKMV (Thu, 22 Aug 2019 03:59:56 GMT):
Has joined the channel.

simran (Thu, 22 Aug 2019 05:14:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ybHnt9hRFewCQcdzW) Thanks alot:)

ap (Thu, 22 Aug 2019 12:42:28 GMT):
HI @Artemkaaas , Can you please help me to add IOS wrapper on Xcode? I follow the below steps but able to import the lib. in code file.

ap (Thu, 22 Aug 2019 12:42:41 GMT):
A wrapper is a private pod, so private podspec must be set. Put at the top of the Podfile: source 'https://github.com/hyperledger/indy-sdk.git' Cocoapod will search for spec files in the root Specs folder. Add pod to target: pod 'libindy-objc'

ap (Thu, 22 Aug 2019 12:43:24 GMT):
after making above change i run pod install.

RaviAsthana (Thu, 22 Aug 2019 13:07:34 GMT):
Has joined the channel.

RaviAsthana (Thu, 22 Aug 2019 13:07:36 GMT):
Hi all, is anyone here having experience in building using indy-sdk in iOS projects (obj-c). If YES, please share a working example of the how to use the sdk functions from iOS platform.

RaviAsthana (Thu, 22 Aug 2019 13:07:36 GMT):
Hi all, is anyone here having experience in building indy-sdk in iOS projects (obj-c). If YES, please share a working example of the how to use the sdk functions from iOS platform.

RaviAsthana (Thu, 22 Aug 2019 13:07:36 GMT):
Hi all, is anyone here having experience in building indy-sdk in iOS projects (obj-c). If YES, please share a working example of how to use the sdk functions from iOS platform.

nbrempel (Fri, 23 Aug 2019 19:06:53 GMT):
Hello everyone - can anyone see what is wrong here? If I include any "attr::::value" restrictions in my proof request it always fails.

nbrempel (Fri, 23 Aug 2019 19:07:06 GMT):
I've created a gist here with a full example of what I'm doing: https://gist.github.com/nrempel/f8a977b4be74648a2c9dbdcf9001b8a0

nbrempel (Fri, 23 Aug 2019 19:19:07 GMT):
is the `attr::::value` tag available for proof request restrictions?

ianco (Fri, 23 Aug 2019 21:00:33 GMT):
In this line of code here it seems that the "attr::...::marker" is supported by "attr::...::value" is not: https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/services/anoncreds/verifier.rs#L483

ianco (Fri, 23 Aug 2019 21:00:33 GMT):
In this line of code here it seems that the "attr::...::marker" is supported but "attr::...::value" is not: https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/services/anoncreds/verifier.rs#L483

ianco (Fri, 23 Aug 2019 21:00:33 GMT):
In this line of code here it seems that the `attr::...::marker` is supported but `attr::...::value` is not: https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/services/anoncreds/verifier.rs#L483

ianco (Fri, 23 Aug 2019 21:01:22 GMT):
``` fn _is_attr_operator(key: &str) -> bool { key.starts_with("attr::") && key.ends_with("::marker") } ```

nbrempel (Fri, 23 Aug 2019 21:03:16 GMT):
Thanks Ian, does anyone know if this is by design or should that check include `::value`?

nbrempel (Fri, 23 Aug 2019 21:28:40 GMT):
I opened a ticket here: https://jira.hyperledger.org/browse/IS-1363

RaviAsthana (Mon, 26 Aug 2019 08:44:00 GMT):

Screenshot 2019-08-26 at 2.12.16 PM.png

RaviAsthana (Mon, 26 Aug 2019 08:44:36 GMT):

Screenshot 2019-08-26 at 2.11.47 PM.png

lynn.bendixsen (Mon, 26 Aug 2019 16:38:33 GMT):
This is a test

PatrikStas (Wed, 28 Aug 2019 15:09:05 GMT):
Is there by a chance any documentation on vcx minimal and intended way of usage? I would like to try out and create some simple demo, but I am having trouble getting my head around how it shall be consumed. I am trying to use it from vcx nodejs wrapper. I can call `initMinimal` successfully, but don't know how to establish a connection. Seem like with initMinimal, I can not call `connection.connect` as it seems too be coupled with the concept of agency, consequently can't call `connection.inviteDetails`to generate the connection invitation. Am I missing something? I would like to just generate invitation, pass it to other party, presumably use vcx to generate connection response message, *implement the transport of connection response myself* and process the that message at the inviting party. But I can't pass even the first step - generating the invitation.

sukalpomitra (Wed, 28 Aug 2019 16:48:34 GMT):

Screenshot 2019-08-28 at 3.37.35 PM.png

sukalpomitra (Wed, 28 Aug 2019 16:49:13 GMT):
Hi All, After i build the libindy using cargo build command I cannot see the libindy.so file in the target folder. Where can I find it. I am using a Macbook

lynn.bendixsen (Wed, 28 Aug 2019 17:52:52 GMT):
I am using mac. It looks like mac builds a libindy.dylib instead of a .so file, those are essentially equivalent, if I am not mistaken.

lynn.bendixsen (Wed, 28 Aug 2019 17:52:52 GMT):
I am using mac. It looks like mac builds a libindy.dylib instead of a .so file. Those are essentially equivalent, if I am not mistaken.

PatrikStas (Wed, 28 Aug 2019 19:17:53 GMT):
@sukalpomitra on osx use `*.dylib` files instead of `*.so` (that's for linux)

RaviAsthana (Thu, 29 Aug 2019 06:40:42 GMT):
@lynn.bendixsen do you have any reference or idea on how to add indy-sdk to iOS project(obj-c)

RaviAsthana (Thu, 29 Aug 2019 06:40:42 GMT):
@lynn.bendixsen @sukalpomitra @PatrikStas do you have any reference or idea on how to add indy-sdk to iOS project(obj-c)

sukalpomitra (Thu, 29 Aug 2019 07:24:34 GMT):
Hey Ravi, I dont coz all of my experience is on Android. However "OSMA" (https://github.com/mattrglobal/osma) is in Xamarin and supports both IOS and Android. You may want to take a look at that.

RaviAsthana (Thu, 29 Aug 2019 07:30:35 GMT):
@sukalpomitra thanks for your reply:thumbsup: I will look into it

sukalpomitra (Thu, 29 Aug 2019 07:43:20 GMT):
Hi @PatrikStas and @lynn.bendixsen I tried with libindy.dylib. I placed it in the lib folder of the java wrapper and did a clean install. 52 tests ran, with 1 Failure and 13 errors. I am uploading one such failed surefire report. Not sure if the code is able to communicate with the dylib as I see the tests failed on timeout and the whole build failed after 11 mins!!

sukalpomitra (Thu, 29 Aug 2019 07:43:20 GMT):
Hi All, I tried with libindy.dylib. I placed it in the lib folder of the java wrapper and did a clean install. 52 tests ran, with 1 Failure and 13 errors. I am uploading one such failed surefire report. Not sure if the code is able to communicate with the dylib as I see the tests failed on timeout and the whole build failed after 11 mins!!

sukalpomitra (Thu, 29 Aug 2019 07:45:13 GMT):

org.hyperledger.indy.sdk.demo.CryptoDemoTest.txt

sukalpomitra (Thu, 29 Aug 2019 07:45:28 GMT):
Any guidance will be appreciated!

MALodder (Thu, 29 Aug 2019 12:45:41 GMT):
correct

sklump (Thu, 29 Aug 2019 13:01:20 GMT):
`target/debug/` or `target/release/` ?

sukalpomitra (Thu, 29 Aug 2019 15:52:38 GMT):
there is only debug

sukalpomitra (Thu, 29 Aug 2019 15:53:02 GMT):
bump!

swcurran (Thu, 29 Aug 2019 23:34:38 GMT):
This question has come up in a couple of area in our group and we don't have the answer. Does an Indy proof request support a way to do an "equals" predicate? Some way to say I want proof that a claim you have in your credential is equal to a given value?

swcurran (Thu, 29 Aug 2019 23:34:38 GMT):
This question has come up in a couple of areas in our group and we don't have the answer. Does an Indy proof request support a way to do an "equals" predicate? Some way to say I want proof that a claim you have in your credential is equal to a given value?

swcurran (Thu, 29 Aug 2019 23:35:07 GMT):
If not, is there a plan for how and where support for that will be added?

dbluhm (Fri, 30 Aug 2019 02:11:59 GMT):
The answer I've seen to that before has been to just reveal the attribute as that's effectively what an equals predicate would do anyways

swcurran (Fri, 30 Aug 2019 02:34:09 GMT):
Ah, yes. I've heard that to - I had forgotten the reasoning. That works from a privacy perspective. The use case we have in mind is that we're trying to use it as a selector to tell the holder how to choose from a set of credentials. For example, the holder may have a set of credentials that are the same type, but the verifier wants returned a specific one from that set. Basically, trying to use the proof request restrictions as a filter. I gather that is not the intended design of the proof request restrictions. The question is should it be part of the design? @smithsamuelm - this answers your question of why that restriction doesn't work - it's not supported. @nbrempel - this is why the approach we're trying to use for IndyCatalyst doesn't work. Not sure implementing that feature would achieve what we want. It might, but I think that there is more than filtering credentials needed to support an equals predicate - I think Ursa would have to support it. Does the "get_credentials_for_proof" function use the ">=" restriction as a filter? @MALodder - any input into the use case above and what effort adding an "=" predicate would take?

swcurran (Fri, 30 Aug 2019 02:34:09 GMT):
Ah, yes. I've heard that too - I had forgotten the reasoning. That works from a privacy perspective. The use case we have in mind is that we're trying to use it as a selector to tell the holder how to choose from a set of credentials. For example, the holder may have a set of credentials that are the same type, but the verifier wants returned a specific one from that set. Basically, trying to use the proof request restrictions as a filter. I gather that is not the intended design of the proof request restrictions. The question is should it be part of the design? @smithsamuelm - this answers your question of why that restriction doesn't work - it's not supported. @nbrempel - this is why the approach we're trying to use for IndyCatalyst doesn't work. Not sure implementing that feature would achieve what we want. It might, but I think that there is more than filtering credentials needed to support an equals predicate - I think Ursa would have to support it. Does the "get_credentials_for_proof" function use the ">=" restriction as a filter? @MALodder - any input into the use case above and what effort adding an "=" predicate would take?

swcurran (Fri, 30 Aug 2019 02:34:09 GMT):
Ah, yes. I've heard that too - I had forgotten the reasoning. That works from a privacy perspective. The use case we have in mind is that we're trying to use it as a selector to tell the holder how to choose from a set of credentials. For example, the holder may have a set of credentials that are the same type, but the verifier wants returned a specific one from that set. Basically, trying to use the proof request restrictions as a filter. I gather that is not the intended design of the proof request restrictions. The question is should it be part of the design? @smithsamuelm - this answers your question of why that restriction doesn't work - it's not supported. @nbrempel - this is why the approach we're trying to use for IndyCatalyst doesn't work. Not sure implementing just the wql feature would achieve what we want. It might, but I think that there is more than filtering credentials needed to support an equals predicate - I think Ursa would have to support it. Does the "get_credentials_for_proof" function use the ">=" restriction as a wql filter? @MALodder - any input into the use case above and what effort adding an "=" predicate would take?

smithsamuelm (Fri, 30 Aug 2019 02:34:09 GMT):
Has joined the channel.

sukalpomitra (Fri, 30 Aug 2019 02:59:48 GMT):
Hi @swcurran in my experiments also I have seen that a == predicate does not work. I also looked at the indy sdk and as of now only > < => and <= are supported.

kukgini (Fri, 30 Aug 2019 04:58:20 GMT):
Has joined the channel.

kukgini (Fri, 30 Aug 2019 04:59:29 GMT):
what do you mean by gvt when you saying GVT_SCHEMA_NAME?

Zohaib_Sohail (Fri, 30 Aug 2019 07:17:03 GMT):
Government

kukgini (Fri, 30 Aug 2019 07:18:43 GMT):
@Zohaib_Sohail Thank you :-)

sukalpomitra (Fri, 30 Aug 2019 08:11:26 GMT):
got it working. thx

AxelNennker (Fri, 30 Aug 2019 08:55:00 GMT):
I came across https://lib.rs/crates/cargo-deb that allows build deb packages from Cargo.toml. That seems to be used in vcx but neiter in cli nor in libindy. How is the libindy deb package currently build?

sklump (Fri, 30 Aug 2019 10:22:48 GMT):
It's tighter than that: only >= has support today, with a roadmap to <, <=, > in anoncreds 2.0

sklump (Fri, 30 Aug 2019 10:23:52 GMT):
It ought to have landed in /target/debug then.

Zohaib_Sohail (Fri, 30 Aug 2019 13:11:41 GMT):
how can I revoke a credential means steps required/flow to revoke a credential, any document/sample code would be better? @esplinr @Artemkaaas @SergeyBrazhnik @ashcherbakov @WadeBarnes

WadeBarnes (Fri, 30 Aug 2019 13:12:31 GMT):
@sklump, @andrew.whitehead ^

MALodder (Fri, 30 Aug 2019 13:17:47 GMT):
Ursa supports >=,>,<,<=

MALodder (Fri, 30 Aug 2019 13:17:59 GMT):
Equals is just a reveal attribute

MALodder (Fri, 30 Aug 2019 13:18:09 GMT):
==

MALodder (Fri, 30 Aug 2019 13:18:28 GMT):
== att_value is just reveal

MALodder (Fri, 30 Aug 2019 13:19:43 GMT):
Unless you are trying to prove across presentations that the same attribute values were used for each one with out revealing the values

MALodder (Fri, 30 Aug 2019 13:19:52 GMT):
But that’s a different mechanism

MALodder (Fri, 30 Aug 2019 13:21:07 GMT):
I guess I’m not clearly understanding why someone needs a == predicate

lynn.bendixsen (Fri, 30 Aug 2019 15:51:08 GMT):
What was it you did to get it working? Sorry for not responding, but I do not know the answer to the question you had.

sukalpomitra (Fri, 30 Aug 2019 16:03:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=bD8oHpjhEKRLvjarD) @lynn.bendixsen I posted about how the indy SDK java wrappers tests were failing

swcurran (Fri, 30 Aug 2019 16:12:23 GMT):
I'm mixing up restrictions with predicates - I thought they were combined in a proof request, but I believe they are separate. Restrictions use WQL to select the credentials to use for a proof; predicates provide the ability to prove an expression from the credential selected for the claim without revealing the claim. I think that is right. So what we want to implement is support for a restriction based on an equality, which we should be able to do independent of predicates (which was my concern). Nick is going to look into adding that to the Indy SDK.

esplinr (Fri, 30 Aug 2019 16:16:05 GMT):
Resources on LibVCX: * Getting started tutorial: https://github.com/hyperledger/indy-sdk/blob/master/vcx/docs/getting-started/getting-started.md * Getting started conversation from last September: https://www.youtube.com/watch?v=nFZ__vyv-vY

nbrempel (Fri, 30 Aug 2019 16:18:51 GMT):
For example, we are looking for a way for an issuer to request a credential with attribute `name == Alice`. In the case of an identity owner, the person could infer what credentials are needed to satisfy the proof request and select the correct proof. In our case – the controller (system) case – we need to be able to deterministically select a credential and construct the proof. To do this, we would like to use the proof request `restrictions` section. Though, it appears that `restrictions` does not support true wql (unlike `extra_query`) so the holder can select whatever it wants using extra_query, but the restrictions specified by the issuer only support the "big 6" – schema_id, cred_def_id, etc. https://jira.hyperledger.org/browse/IS-1363 `restrictions` cannot filter by tag. Specifically, in our case, we want to filter by the default tag `{attr::::value: }` I'm looking at adding full wql support to libindy for restrictions. However, I'm not sure if the support was left out for good reason or if it's simply a TODO. @MALodder

nbrempel (Fri, 30 Aug 2019 16:18:51 GMT):
For example, we are looking for a way for an issuer to request a credential with attribute `name == Alice`. In the case of an identity owner, the person could infer what credentials are needed to satisfy the proof request and select the correct credentials to construct the proof. In our case – the controller (system) case – we need to be able to deterministically select a credential and construct the proof. To do this, we would like to use the proof request `restrictions` section. Though, it appears that `restrictions` does not support true wql (unlike `extra_query`) so the holder can select whatever it wants using extra_query, but the restrictions specified by the issuer only support the "big 6" – schema_id, cred_def_id, etc. https://jira.hyperledger.org/browse/IS-1363 `restrictions` cannot filter by tag. Specifically, in our case, we want to filter by the default tag `{attr::::value: }` I'm looking at adding full wql support to libindy for restrictions. However, I'm not sure if the support was left out for good reason or if it's simply a TODO. @MALodder

MALodder (Fri, 30 Aug 2019 18:02:48 GMT):
That I don’t know why

djathomson (Fri, 30 Aug 2019 19:31:51 GMT):
Greetings all! I'm trying to create a public DID doc for an issuer DID that gets created once onboarded with a steward, which would then expose the endpoint and metadata necessary to interact with that issuer DID, for establishing pairwise connections, credential issuance, etc. I'm using the node wrapper at the moment, and I can't seem to find any examples of this flow. I think I'm able to set both endpoints and also DID metadata, but I can't figure out how to query that publicly. When I run buildgetDdoRequest, I get this error: Result: {"identifier":"CTJMErAr4zsgBb8rQhVSKo","reqId":1567191238741458000,"reason":"client request invalid: InvalidClientRequest('validation error [ClientAuthRuleOperation]: missed fields - auth_type, auth_action, constraint, field, new_value. ',)","op":"REQNACK"} Any suggestions or ideas would be appreciated, thanks so much!

AxelNennker (Sat, 31 Aug 2019 09:31:00 GMT):
I have build libindy on macos and now I want to run the tests but get the error message ``` Too many open files (src/kqueue.cpp:62) ``` Is this a cargo/rust problem or a macos problem?

AxelNennker (Sun, 01 Sep 2019 07:05:57 GMT):
I 'fixed' the macos problem with help of this post. But, I think, the underlying problem remains: on macos closing unused pools and wallet does not work as expected. This is my fifth day on macos and I am probably not the first to see this. Any advice?

AxelNennker (Sun, 01 Sep 2019 07:05:57 GMT):
I 'fixed' the macos problem with help of this post. https://medium.com/mindful-technology/too-many-open-files-limit-ulimit-on-mac-os-x-add0f1bfddde But, I think, the underlying problem remains: on macos closing unused pools and wallet does not work as expected. This is my fifth day on macos and I am probably not the first to see this. Any advice?

xtrycatchx (Tue, 03 Sep 2019 06:48:45 GMT):
Hello everyone. A small question regarding KEYS in indy wallet.. I understand to open the wallet you need a KEY(lets say KEYA) and to process proof or credential you need a master-key-ID that would refer to another KEY (lets say KEYB) to complete the process. And later KEY (KEYB) can be many. is my understanding correct?

Henrycoffin (Tue, 03 Sep 2019 12:57:45 GMT):
Has joined the channel.

swcurran (Tue, 03 Sep 2019 15:51:52 GMT):
I don't think so. - There is a key for the wallet. Within the wallet, you will also have other keys: - You will have did:peer pairwise DIDs for every relationship you have, and each such DID will have at least one key. - If you are an issuer, you must have a public DID on the ledger, and a key for that. - If you are an issuer, you have a credential definition for each type of credential issued. There is a key per claim (attribute) within each credential defintion. - Every wallet has a "Link Secret" that is used to prove that the credential you hold were issued to you. I think that's the full set.

nbrempel (Tue, 03 Sep 2019 20:46:19 GMT):
That appears to be the recommended approach. https://github.com/hyperledger/indy-sdk/blob/master/docs/build-guides/mac-build.md#ioerror-while-running-of-whole-set-of-tests-on-macos https://jira.hyperledger.org/browse/IS-1038

AxelNennker (Tue, 03 Sep 2019 21:43:30 GMT):
Is Rust not closing the files fast enough on MacOS? What is the difference to e.g. Ubuntu? Is the number of open files allowed on Ubuntu just higher by default or is this a Rust issue?

nbrempel (Tue, 03 Sep 2019 21:44:30 GMT):
I'm not sure about the root cause of the problem or a better solution - but I know the problem is unique to mac

DucaDellaForcoletta (Fri, 06 Sep 2019 14:32:46 GMT):
Hi Everyone, someone who has integrated the payment feature of indy?

swcurran (Fri, 06 Sep 2019 17:24:13 GMT):
AFAIK, only the Sovrin Foundation has done that.

lynn.bendixsen (Fri, 06 Sep 2019 20:06:42 GMT):
I have setup payment features for testing and use on the Sovrin BuilderNet and StagingNet, but I have not integrated any payment features into an app or any code. I used the indy CLI to setup and test the features.

sklump (Tue, 10 Sep 2019 12:18:13 GMT):
What is the use case for unrevealed attributes in a requested-attributes structure? Looking at proofs with (1) an unrevealed attribute and (2) no mention of the attribute at all in the requested-attributes structure, I can't see the difference. Is this: * a historical artifact? * a placeholder for future development? * a forgotten corner case? * something else that I am missing?

sklump (Tue, 10 Sep 2019 12:18:13 GMT):
What is the use case for unrevealed attributes in a `requested_attributes` structure? Looking at proofs with (1) an unrevealed attribute and (2) no mention of the attribute at all in the requested-attributes structure, I can't see the difference. The only mention of an unrevealed attribute in the `proof['requested_proof']['unrevealed_attributes']`. But since all attributes in the cred def are always in the proof (`primary_proof['m']`), why would one ever note that an attribute is in requested proof without revealing its value? Is an unrevealed attribute: * a historical artifact? * a placeholder for future development? * something else that I am missing?

sklump (Tue, 10 Sep 2019 12:18:13 GMT):
What is the use case for unrevealed attributes in a `requested_attributes` structure? Looking at proofs with (1) an unrevealed attribute and (2) no mention of the attribute at all in the requested-attributes structure, I can't see the difference. The only mention of an unrevealed attribute in the `proof['requested_proof']['unrevealed_attributes']`. But since all attributes in the cred def are always in the proof (`primary_proof['m']`), why would one ever note that an attribute is in requested proof without revealing its value? Is the unrevealed attribute, as a feature: * a historical artifact? * a placeholder for future development? * something else that I am missing?

SergeyBrazhnik (Tue, 10 Sep 2019 12:30:12 GMT):
Hello everyone. Could you advice where Im a wrong with this error ``` { "reason": "client request invalid: CouldNotAuthenticate('Can not find verkey for Jy2GF1LZ6WwiUdMCRvHS1g',)", "identifier": "Jy2GF1LZ6WwiUdMCRvHS1g", "reqId": 1568118546725604000, "op": "REQNACK" } ```

swcurran (Tue, 10 Sep 2019 15:46:03 GMT):
I've been bumping into this one as well. In the mobile agents I've seen (OSMA, Streetcred), both allow the prover to mark any attribute as "unrevealed". It seems like the verifier should be able to see "I need this attribute revealed" and not left to the prover. Especailly with the UIs being built, the prover will likely under reveal, resulting in an extra round trip where the verifier (somehow) says - "hey, not good enough...I need to see the values". I checked with @kenebert yesterday and it seems this will be a part of Rich Schema.

sklump (Tue, 10 Sep 2019 15:51:48 GMT):
Indy leaves the revealed/unrevealed choice to the prover. Not revealing an attribute presents a commitment within the proof the the value is unchanged in the credential from its issued value. So it does still prove integrity -- this is mathematically interesting but I was wondering, so what? What use is this? FWIW, I set all attributes to reveal in Aries#0037 impl in aca-py, with a note that allowing a toggle is a possibility.

sklump (Tue, 10 Sep 2019 15:51:48 GMT):
Indy leaves the revealed/unrevealed choice to the prover. Not revealing an attribute presents a commitment within the proof that the value is unchanged in the credential from its issued value. So it does still prove integrity -- this is mathematically interesting but I was wondering, so what? What use is this? FWIW, I set all attributes to reveal in Aries#0037 impl in aca-py, with a note that allowing a toggle is a possibility.

sklump (Tue, 10 Sep 2019 15:51:48 GMT):
Indy leaves the revealed/unrevealed choice to the prover. Not revealing an attribute presents a commitment within the proof that its value is unchanged in the credential from its issued value. So it does still prove integrity -- this is mathematically interesting but I was wondering, so what? What use is this? FWIW, I set all attributes to reveal in Aries#0037 impl in aca-py, with a note that allowing a toggle is a possibility.

swcurran (Tue, 10 Sep 2019 16:17:43 GMT):
I think there are use cases where you need to prove possession of a credential without revealing the data - that you have a BC Services card credential. The verifier might not want to have the data, just to know it exists (toxic data). And it is always up to the prover to reveal or not reveal whatever they choose. I think it is necessary that the verifier can express what they need from the prover to complete the transaction.

sklump (Tue, 10 Sep 2019 16:18:38 GMT):
If this is a feature you want in proof requests, it is imperative you impress its requirement on the anoncreds-2.0 group.

swcurran (Tue, 10 Sep 2019 16:19:37 GMT):
That's why I've been asking @kenebert about it :-). And look, I just pinged him again... Sorry Ken!

sklump (Tue, 10 Sep 2019 16:20:53 GMT):
I don't necessarily disagree, but the slant of indy is the individual, and they may balk at extending this agency to the inquisition side. I think it would be an improvement, net, because the prover can opt not to continue.

sklump (Tue, 10 Sep 2019 18:09:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=63tapoKsXn5nis52o) Coming back to this, though, operationally it is not possible to include some attributes of a credential and not others in a proof (only some will be revealed, the others will be committed). If the proof request explicitly allows specification of the commitment of an attribute without revelation (i.e., unrevealed attribute), then what does it mean for the attribute not to be present at all in the proof request? Explicitly setting an unrevealed attribute in a proof request (2.0) duplicates not asking for it at all but for some other attribute (by attribute or by predicate). A corner case this could address would be asking for no attribute values and no predicate, but proof of credential ownership. That could be useful, but note that one could kludge such a request today with requested_predicate {any-attribute>=-2^31} and no requested_attributes, as long as the schema included at least one 32-bit-integer-valued attribute. All this to come back to my original query: what does it mean to specify an attribute as present but unrevealed in a proof, operationally?

sklump (Tue, 10 Sep 2019 18:09:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=63tapoKsXn5nis52o) Coming back to this, though, operationally it is not possible to include some attributes of a credential and not others in a proof (only some will be revealed, the others will be committed). If the proof request explicitly allows specification of the commitment of attribute `a` without revelation (i.e., unrevealed attribute), then how does that differ from not specifying attribute `a` at all in the proof request [*]? Explicitly setting an unrevealed attribute in a proof request (2.0) duplicates not asking for it at all but for some other attribute (by attribute or by predicate). A corner case this could address would be asking for no attribute values and no predicate, but proof of credential ownership. That could be useful, but note that one could kludge such a request today with requested_predicate {any-attribute>=-2^31} and no requested_attributes, as long as the schema included at least one 32-bit-integer-valued attribute. All this to come back to my original query: what does it mean to specify an attribute as present but unrevealed in a proof, operationally? [*] OK, I think I've convinced myself that the use case would be to request inclusion of a credential in the proof without specifying any attribute values nor predicate values.

sklump (Tue, 10 Sep 2019 18:33:08 GMT):
... note that in effect, at present, every attribute in a cred def that the proof request does not ask for as an attribute, shows up as an unrevealed attribute in the proof. The only case that requesting unrevealed explicitly could advance would be the case to show credential ownership but absolutely no attribute values or predicates on them.

kenebert (Tue, 10 Sep 2019 21:02:20 GMT):
As part of the rich schemas work we will be enhancing the presentation request definition. As the HIPE is completed for the presentation definition, we will consider how to properly address this. In some cases, it is prudent to allow negotiation between the prover (holder) and verifier. In other cases the verifier doesn't have much flexibility in what in needed to satisfy their requirements. We think that a presentation definition should be able to specify required attributes so that most presentation requests can be satisfied with a single presentation and not require multiple round trips to complete a successful presentation.

lynn.bendixsen (Wed, 11 Sep 2019 18:28:56 GMT):
I am having trouble building libindy tag 1.11.1 on MAC. Any hints? ``` Compiling rusqlite v0.20.0 error[E0658]: use of unstable library feature 'maybe_uninit' (see issue #53491)```

Henrycoffin (Thu, 12 Sep 2019 08:48:36 GMT):
Hi Everyone. I have a question around using the attributes in a credential. We currently integrate with a number of third part solutions using SAML. My thinking is that I can extract the attributes from the proof supplied by the user and use them to build a SAML assertion. Does this sound feasible?

swcurran (Thu, 12 Sep 2019 14:46:47 GMT):
Yes. We're taking a similar approach with OpenID Connect tokens. We have a component that is an ID Provider that takes OIDC requests from an RP, talks DIDComm/Indy to request and receive a proof, and then puts the attributes from the proof into the OIDC token sent back to the RP.

swcurran (Fri, 13 Sep 2019 22:10:59 GMT):
Has any thought been given to the Sovrin DID method supporting multiple networks (e.g. did:sov:test:, did:sov:build, did:sov:main:). This might be useful to enable using the same DID method handling, but supporting the resolution of a DID that may reside one of several (ideally compatible) networks. This is helpful for testing, but may be needed in some of the production use cases I'm hearing about.

DucaDellaForcoletta (Mon, 16 Sep 2019 10:15:55 GMT):
Sure!, but as payment client, I think that all of us need to integrate the payment feature in our env in order to use the sovrin network. I'm searching documentation about payment or test integration of the feature, but I'haven't fount it.

DucaDellaForcoletta (Mon, 16 Sep 2019 10:17:24 GMT):
revocation

lynn.bendixsen (Mon, 16 Sep 2019 14:27:38 GMT):
Here is a document I recently made that might help. It is not quite complete, so feel free to ask questions and make comments in it to let me know what else might be helpful to include in it. It helps with setting up a test environment and understanding how test-tokens work, but again, is missing the agent coding part. The Sovrin BuilderNet and stagingnet already have test-tokens set up on them and is available for you to use for testing. Just send a payment address to support@sovrin.org to get your own test-tokens to use. https://docs.google.com/document/d/1iWj9kMvJGnmFMFxItP0w0F0yncS0OgXVwEvLsQrO6D4/edit

DucaDellaForcoletta (Mon, 16 Sep 2019 14:40:58 GMT):
Thanks so much for the document

tomislav (Mon, 16 Sep 2019 21:12:55 GMT):
@DucaDellaForcoletta In terms of sdk support, Aries for .NET supports both ledger payments and implements the payment RFC - https://github.com/hyperledger/aries-framework-dotnet/tree/master/test/AgentFramework.Core.Tests/Payments

DucaDellaForcoletta (Tue, 17 Sep 2019 14:32:09 GMT):
Hi everyone, I'm trying the ledger mint-prepare command from indy-cli, after the creation and the multi signature of the 3 TRUSTEE, when I execute the command ledger custom with the tx result of the last command, I obtain an error `Transaction has been rejected: invalid type: 10000`, Any suggest would be appreciated .

tomislav (Tue, 17 Sep 2019 15:11:04 GMT):
You may need sovtoken and sovtokenfees installed as well. Try this docker file for your local pool. https://github.com/hyperledger/aries-framework-dotnet/blob/master/docker/indy-pool.dockerfile

DucaDellaForcoletta (Tue, 17 Sep 2019 15:17:33 GMT):
Thanks, I'll try.

DucaDellaForcoletta (Tue, 17 Sep 2019 15:37:43 GMT):
with the docker suggested, it works. Thanks

agiledeveloper (Tue, 17 Sep 2019 22:17:09 GMT):
Has joined the channel.

mattatkiva (Wed, 18 Sep 2019 15:34:33 GMT):
there is a DeleteCredential method in indysdk but I do not see it in the nodejs wrapper. Is this a bug or is there a reason it is not exposed to nodejs?

swcurran (Wed, 18 Sep 2019 16:05:45 GMT):
It's a new feature that was recently added. My guess is that the nodejs wrapper hasn't been updated.

mattatkiva (Wed, 18 Sep 2019 16:06:56 GMT):
I am happy to update it and create a PR. I am not familiar with the process to updating nodejs though. Can I manually edit the source, or do we have instructions for how to build it?

DucaDellaForcoletta (Thu, 19 Sep 2019 14:05:40 GMT):
Hi everyone, I've a doubt about the add_request_fees method. This method take an input json and output_json with (recipient address, amount). I'm confused for the request of recipient address since the fee should be taken by the network without specify any dest address. What I'm wrong? Another doubt about this method:Could I use this method with a wallet different of the one built the initial request. (For example I want to pay the fee for others)?

tomislav (Thu, 19 Sep 2019 14:15:48 GMT):
The destination address specifies where the overspent amount will go. If you have 10 tokens and fees are 2 tokens, you want your 8 tokens back to an address that you own. You must calculate and specify the fees and amounts up front.

DucaDellaForcoletta (Thu, 19 Sep 2019 14:19:04 GMT):
Ok, so I can decide to put the same address in input and output or get the utxo result in a different address?

tomislav (Thu, 19 Sep 2019 14:19:54 GMT):
yes

tomislav (Thu, 19 Sep 2019 14:20:12 GMT):
inputs are sources (of an address), and output is just the address

DucaDellaForcoletta (Thu, 19 Sep 2019 14:21:23 GMT):
Thanks for the reply, Do you know if Could I use this method with a wallet different of the one built the initial request. (For example I want to pay the fee for others)?

tomislav (Thu, 19 Sep 2019 14:22:29 GMT):
You can. Someone else can create the request, and you can attach fees that are paid from address source you own

tomislav (Thu, 19 Sep 2019 14:22:44 GMT):
You can then give them back the original request to submit it, or you can submit it

DucaDellaForcoletta (Thu, 19 Sep 2019 14:23:06 GMT):
Perfect! Thanks very much

tomislav (Thu, 19 Sep 2019 14:23:21 GMT):
You're welcome

gorny (Thu, 19 Sep 2019 14:34:18 GMT):
Has joined the channel.

swcurran (Thu, 19 Sep 2019 18:00:22 GMT):
Does anyone have handy the URL of the Sovrin MainNet Browser? I can't find it my bookmarks and need it. BC Gov has one (I know it), but someone else posted another one.

swcurran (Thu, 19 Sep 2019 18:00:22 GMT):
Does anyone have handy the URL of the Sovrin MainNet Ledger Browser? I can't find it my bookmarks and need it. BC Gov has one (I know it), but someone else posted another one.

andrew.whitehead (Thu, 19 Sep 2019 18:14:57 GMT):
https://indyscan.io/home/sovmain

VenkateshSorapalli (Fri, 20 Sep 2019 12:04:14 GMT):
Has joined the channel.

VenkateshSorapalli (Fri, 20 Sep 2019 12:04:20 GMT):
When runs the docker-compose file of Hyperledger-indy, the necessary indy-sdk package will be installed from python script. What's the location of the indy-sdk package files?

VenkateshSorapalli (Fri, 20 Sep 2019 12:04:20 GMT):
When runs the docker-compose file of Hyperledger-indy, the necessary indy-sdk package will be installed from dockerfile. What's the location of the indy-sdk package files?

VenkateshSorapalli (Fri, 20 Sep 2019 12:04:20 GMT):
When runs the docker-compose file of Hyperledger-indy, the necessary indy-sdk package will be installed from .dockerfile. What's the location of the indy-sdk package files?

VenkateshSYS (Fri, 20 Sep 2019 12:09:29 GMT):
Has joined the channel.

donqui (Fri, 20 Sep 2019 12:22:47 GMT):
Repo for all packages is located at https://repo.sovrin.org/

VenkateshSorapalli (Fri, 20 Sep 2019 12:23:23 GMT):
How to access that node modules package for new js file

VenkateshSorapalli (Fri, 20 Sep 2019 12:28:23 GMT):
If I again npm install to generate node modules for new js file, already created endpoint for the agent via .dockerfile and access the agent endpoint through new node modules differs.. how to get the endpoint for tge agent as same as at the creation time

DucaDellaForcoletta (Fri, 20 Sep 2019 13:23:28 GMT):
Hi All, has anyone successfully used the build_payment_req function by passing the param "extra"?

Henrycoffin (Fri, 20 Sep 2019 15:10:23 GMT):
Hi. Does anyone know of any good tutorials for setting up connections using qrcodes? Or has anyone successfully done it?

VenkateshSYS (Sat, 21 Sep 2019 14:24:00 GMT):
can anybody tell me what are the background process when executes docker-compose build and docker-compose up in hyperledger indy

VenkateshSYS (Sat, 21 Sep 2019 14:24:00 GMT):
can anybody tell me what are the background process when executes docker-compose build and docker-compose up in hyperledger indy?

VenkateshSYS (Sun, 22 Sep 2019 14:58:25 GMT):
How to run custom nodejs express api (get/post) file in running container and how to access it

VenkateshSYS (Sun, 22 Sep 2019 14:58:25 GMT):
How to run custom nodejs express api (get/post) file in running container and how to access it?

VenkateshSYS (Sun, 22 Sep 2019 14:58:25 GMT):
How to run custom nodejs express api (get/post) file in running docker container and how to access it?

VenkateshSYS (Sun, 22 Sep 2019 15:48:53 GMT):
"scripts": { "startfile" : "node file.js" } How to write this in dockerfile CMD []

ptab-pawan (Mon, 23 Sep 2019 11:18:44 GMT):
Has joined the channel.

ptab-pawan (Mon, 23 Sep 2019 11:18:45 GMT):
@All: In mobile app when I call Pool.createPoolLedgerConfig(DEFAULT_POOL_NAME, createPoolLedgerConfigJSONParameter.toJson()).get(); the first time it works fine. The second time it gives an exception : rg.hyperledger.indy.sdk.pool.PoolLedgerConfigExistsException: A pool ledger configuration already exists with the specified name.My genesistxn path is : /data/user/0/com.indyssid/cache/indy/pool1.txn. Can you tell me how do I get around this issue ?

DucaDellaForcoletta (Mon, 23 Sep 2019 11:55:10 GMT):
You can't create a pool if it already exists with the same name. You can connect directly to the pool when it already exists if you are sure that has been created previously by you with the desired config. Otherwise, when you close the pool, you could call the delete pool in order to delete it and be able to create with the same name when necessary.

ptab-pawan (Mon, 23 Sep 2019 11:56:23 GMT):
@DucaDellaForcoletta :What is the method to directly connect to the pool If the pool already exist ?

DucaDellaForcoletta (Mon, 23 Sep 2019 11:59:13 GMT):
open_pool_ledger, after the create you have to connect to the pool in order to get the pool_handle

luckycharms810 (Mon, 23 Sep 2019 20:23:49 GMT):
Hello all, I'm trying to debug an issue where the presentation proof I've created is not being succesfully verified. Is there any additional information that would be able to check on why its not verified ? I think at the very least it would be useful to know which of the proofs is failing to verify ( cred def proof, master secret proof, non-revocation )

lynn.bendixsen (Mon, 23 Sep 2019 23:32:44 GMT):
What were you trying to add to the "extras"? It needs to be formatted correctly (which is probably why you are asking) so maybe the following can get you on the right track. Just last Friday I got the following to work for me. First I checked to see if the TAA existed on the ledger I was testing, then to add the TAA to a payment request I used the following code: ``` taa_req = await ledger.build_get_txn_author_agreement_request(steward_did, None) taa_resp_json = await ledger.sign_and_submit_request(pool_handle, wallet_handle, steward_did, taa_req) taa_resp=json.loads(taa_resp_json) if taa_resp["result"]["data"]: extras = await payment.prepare_payment_extra_with_acceptance_data(None, taa_resp["result"]["data"]["text"], taa_resp["result"]["data"]["version"], None, 'service_agreement', 1568937395) else: extras = None payment_req, payment_method = await payment.build_payment_req(wallet_handle, steward_did, json.dumps(inputs), json.dumps(outputs), extras)```

DucaDellaForcoletta (Tue, 24 Sep 2019 07:00:54 GMT):
I'm trying to add the extra in the build_payment_req, Looking to the API with this description: :param extra: // optional information for payment operation, I thought it was a parameter like transaction memo. I'll look to your example in order to better understand. in order to better document the apis I opened a ticket on jira. https://jira.hyperledger.org/browse/IS-1379.

ptab-pawan (Tue, 24 Sep 2019 18:26:43 GMT):
@DucaDellaForcoletta : my pool is on ubuntu VM. I am running the mobile app on macbook. So does it create a pool on my mobile memory ?

VenkateshSYS (Wed, 25 Sep 2019 06:04:01 GMT):
Can anybody tell me why this error occurs while executing this line? await sdk.createPairwise(await indy.wallet.get(), theirDid, myDid, meta); >> INDY error 212. what happens in the background of this code line?

jakubkoci (Wed, 25 Sep 2019 07:03:36 GMT):
I responed in indy channel. Sorry I missed your message is also here, because it's better place to discuss this issue :)

jakubkoci (Wed, 25 Sep 2019 07:03:36 GMT):
I responed in indy channel. Sorry I missed your message is also here, this is better place to discuss this issue :)

jakubkoci (Wed, 25 Sep 2019 07:04:14 GMT):
This error code means WalletItemNotFound. If I understand the Rust code in create_pairwise, the wallet tries to find dids in the wallet and that's what probably throws an error. Have you created theses dids by createAndStoreMyDid or similar before calling createPairwise?

DucaDellaForcoletta (Wed, 25 Sep 2019 07:18:03 GMT):
The pool config files are created in file system of the device where you execute the invocation to the library. (mobile)

DucaDellaForcoletta (Wed, 25 Sep 2019 07:18:03 GMT):
The nodes are on ubuntu vm, but the pool config files are created in file system of the device where you execute the invocation to the library. (mobile or server). Consider that the create_poll call creates only the file with the configuration in order to connect by mean the open_pool to the pool nodes (ubuntu vm in your case)

DucaDellaForcoletta (Wed, 25 Sep 2019 07:18:03 GMT):
The nodes are on ubuntu vm, but the pool config files are created in file system of the device where you execute the invocation to the library. (mobile or server). Consider that the create_pool call creates only the file with the configuration in order to connect by mean the open_pool to the pool nodes (ubuntu vm in your case)

VenkateshSYS (Wed, 25 Sep 2019 09:29:21 GMT):
Yeah! I did the createAndStoreMyDid step first then I call createPairwise step

VenkateshSYS (Wed, 25 Sep 2019 09:33:11 GMT):
Here is the code which I am trying to do... `` ` let [myDid, myVerkey] = await sdk.createAndStoreMyDid(await indy.wallet.get(), {}); let theirVerkey = await sdk.keyForDid(await indy.pool.get(), await indy.wallet.get(), theirDid); let meta = JSON.stringify({ theirEndpointDid: theirEndpointDid, verified: false // Indicates that the owner of the agent has confirmed they want to stay connected with this person. }); //FIXME: Check to see if pairwise exists await sdk.createPairwise(await indy.wallet.get(), theirDid, myDid, meta); `` `

VenkateshSYS (Wed, 25 Sep 2019 09:33:11 GMT):
Here is the code which I am trying to do... ` let [myDid, myVerkey] = await sdk.createAndStoreMyDid(await indy.wallet.get(), {}); let theirVerkey = await sdk.keyForDid(await indy.pool.get(), await indy.wallet.get(), theirDid); let meta = JSON.stringify({ theirEndpointDid: theirEndpointDid, verified: false // Indicates that the owner of the agent has confirmed they want to stay connected with this person. }); //FIXME: Check to see if pairwise exists await sdk.createPairwise(await indy.wallet.get(), theirDid, myDid, meta); `

VenkateshSYS (Wed, 25 Sep 2019 09:33:11 GMT):
Here is the code which I am trying to do... `` let [myDid, myVerkey] = await sdk.createAndStoreMyDid(await indy.wallet.get(), {}); let theirVerkey = await sdk.keyForDid(await indy.pool.get(), await indy.wallet.get(), theirDid); let meta = JSON.stringify({ theirEndpointDid: theirEndpointDid, verified: false // Indicates that the owner of the agent has confirmed they want to stay connected with this person. }); //FIXME: Check to see if pairwise exists await sdk.createPairwise(await indy.wallet.get(), theirDid, myDid, meta); ``

VenkateshSYS (Wed, 25 Sep 2019 09:33:11 GMT):
Here is the code which I am trying to do... ``` let [myDid, myVerkey] = await sdk.createAndStoreMyDid(await indy.wallet.get(), {}); let theirVerkey = await sdk.keyForDid(await indy.pool.get(), await indy.wallet.get(), theirDid); let meta = JSON.stringify({ theirEndpointDid: theirEndpointDid, verified: false // Indicates that the owner of the agent has confirmed they want to stay connected with this person. }); //FIXME: Check to see if pairwise exists await sdk.createPairwise(await indy.wallet.get(), theirDid, myDid, meta); ```

FarhanShafiq (Wed, 25 Sep 2019 09:35:51 GMT):
Is there any way to recover credential definition?

rtrive (Wed, 25 Sep 2019 18:26:13 GMT):
Has joined the channel.

ezamp (Wed, 25 Sep 2019 18:31:36 GMT):
Has joined the channel.

ezamp (Wed, 25 Sep 2019 18:31:37 GMT):
Hi All, I'm working on a project based on Hyperledger Indy. Actually I'm trying to import the indy framework into a new project on Xcode 11.0. I'm using cocapods but i have some problems with Podfile and 'libindy-objc' version. In the podfile I inserted the following lines: pod 'libindy' pod 'libindy-objc', '~> 1.8.2' After giving the "pod install" command, Xcode fails to find the framework image when compiling the code. Can somebody help me? Thanks

ezamp (Wed, 25 Sep 2019 18:31:54 GMT):
podfile

ezamp (Wed, 25 Sep 2019 18:36:05 GMT):
ioios

luckycharms810 (Wed, 25 Sep 2019 20:58:48 GMT):
issue

luckycharms810 (Wed, 25 Sep 2019 21:57:50 GMT):
@swcurran Any chance you have any tips here ?

PaulA (Thu, 26 Sep 2019 02:04:26 GMT):
Hi All,

swcurran (Thu, 26 Sep 2019 04:04:46 GMT):
Sorry...I don't know the details at that level :-( @kdenhartog might have some ideas?

kdenhartog (Thu, 26 Sep 2019 04:05:30 GMT):
Are you getting back an error code with a message?

kdenhartog (Thu, 26 Sep 2019 04:05:59 GMT):
Typically what I do when I'm debugging is look at the Error Code and message and do a github search in the IndySDK repo to figure out what part of the code is failing.

kdenhartog (Thu, 26 Sep 2019 04:06:32 GMT):
If you turn on logging in debug mode then the error messages appear there

kdenhartog (Thu, 26 Sep 2019 04:06:57 GMT):
As the errors move further up the stack though they tend to loose some of the specifics.

luckycharms810 (Thu, 26 Sep 2019 13:18:56 GMT):
Appreciate the help! So whats made it very difficult to dive in to the issue is that there is actually no error from invoking the `verifier_verify_proof` function. ( Errorcode.Success ) - The issue is that the result of the function is false.

luckycharms810 (Thu, 26 Sep 2019 14:12:06 GMT):
The trace logs have been somewhat helpful in following the code as its executed all the way down to the ursa level, although that code doesnt seem to indicate (via logging ) if individual proofs have been verified succesfully.

PaulA (Thu, 26 Sep 2019 14:26:18 GMT):
Hi Everyone I got the following errors while running #the Alice/Faber Python demo and vcx dummy-cloud-agent (https://github.com/hyperledger/indy-sdk/blob/master/vcx/dummy-cloud-agent/README.md) https://github.com/hyperledger/indy-sdk/tree/master/vcx/wrappers/python3/demo Command: cargo run /config/ Error: Finished dev [unoptimized + debuginfo] target(s) in 14.29s Running `target/debug/indy-dummy-agent /config/` thread 'main' panicked at 'Invalid configuration file: Os { code: 2, kind: NotFound, message: "No such file or directory" } Can't open config file', src/libcore/result.rs:999:5 note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace. Folder: /indy-sdk/vcx/wrappers/python3/demo Command: python3.5 faber.py Error: python3.5 faber.py Traceback (most recent call last): File "faber.py", line 10, in from demo_utils import file_ext File "/home/ameh/CODES/INDY/indy-sdk/vcx/wrappers/python3/demo/demo_utils.py", line 11, in from indy import wallet ImportError: No module named 'indy' I followed every installation processes. Any idea on what I could have missed out? Thanks

PaulA (Thu, 26 Sep 2019 14:26:18 GMT):
Hi Everyone I got the following errors while running #the Alice/Faber Python demo and vcx dummy-cloud-agent (https://github.com/hyperledger/indy-sdk/blob/master/vcx/dummy-cloud-agent/README.md) https://github.com/hyperledger/indy-sdk/tree/master/vcx/wrappers/python3/demo Command: cargo run /config/ Error: Finished dev [unoptimized + debuginfo] target(s) in 14.29s Running `target/debug/indy-dummy-agent /config/` thread 'main' panicked at 'Invalid configuration file: Os { code: 2, kind: NotFound, message: "No such file or directory" } Can't open config file', src/libcore/result.rs:999:5 note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace. Folder: /indy-sdk/vcx/wrappers/python3/demo Command: python3.5 faber.py Error: python3.5 faber.py Traceback (most recent call last): File "faber.py", line 10, in from demo_utils import file_ext File "/home/ameh/CODES/INDY/indy-sdk/vcx/wrappers/python3/demo/demo_utils.py", line 11, in from indy import wallet ImportError: No module named 'indy' I followed the installation steps on the Readme. Any idea on what i missed out? Thanks

luckycharms810 (Thu, 26 Sep 2019 14:49:34 GMT):
@kdenhartog Let me know if you have any other ideas I can try

swcurran (Thu, 26 Sep 2019 15:19:42 GMT):
Assuming you have lost the wallet in which it was created - no. A DID is generated from a seed and if you retain the seed, you can recreate the DID. However, a cred def is not created from a seed, so it can not be recreated in the same way.

lawkim (Thu, 26 Sep 2019 17:19:50 GMT):
Has joined the channel.

kdenhartog (Thu, 26 Sep 2019 23:45:17 GMT):
Are you providing restrictions on the proof request side of things? Might it be that the credential doesn't meet the restrictions you've set?

smithbk (Fri, 27 Sep 2019 12:32:12 GMT):
Has anyone seen the following when trying to build the indy-pool docker image? ``` $ cd indy-sdk/ci $ docker build -f indy-pool.dockerfile --no-cache . ... The following packages have unmet dependencies: indy-plenum : Depends: python3-pyzmq (= 17.0.0) but 18.1.0 is to be installed E: Unable to correct problems, you have held broken packages. The command '/bin/sh -c apt-get update -y && apt-get install -y indy-plenum=${indy_plenum_ver} indy-node=${indy_node_ver} python3-indy-crypto=${python3_indy_crypto_ver} libindy-crypto=${indy_crypto_ver} vim' returned a non-zero code: 100 ```

donqui (Fri, 27 Sep 2019 13:15:24 GMT):
yes. We added a new version of pyzmq, and now when older versions of sdk are installed pyzmq version must be specified. Probably @sergey.minaev has more info

donqui (Fri, 27 Sep 2019 13:16:24 GMT):
You can change the docker file and pin the version for pyzmq ``` python3-pyzmq=17.0.0 ```

donqui (Fri, 27 Sep 2019 13:16:24 GMT):
In the meanwhile you can change the docker file and pin the version for pyzmq ``` python3-pyzmq=17.0.0 ```

donqui (Fri, 27 Sep 2019 13:16:46 GMT):
I am not sure what the status of PRs that will fix this is.

donqui (Fri, 27 Sep 2019 13:16:46 GMT):
I am not sure what the status of a PR that will fix this is.

smithbk (Fri, 27 Sep 2019 13:32:28 GMT):
I changed to ```RUN apt-get update -y && apt-get install -y \ git \ wget \ python3-pyzmq=17.0.0 \ ``` but it can't find that package: ```Reading state information... E: Unable to locate package python3-pyzmq The command '/bin/sh -c apt-get update -y && apt-get install -y git wget python3-pyzmq=17.0.0 python3-pip python-setuptools python3-nacl apt-transport-https ca-certificates supervisor net-tools netcat curl telnet nano vim' returned a non-zero code: 100 ```

smithbk (Fri, 27 Sep 2019 13:34:31 GMT):
It was previously `python3.5` rather than `python3-pyzmq=17.0.0`

smithbk (Fri, 27 Sep 2019 13:34:57 GMT):
So exactly where should I make that change?

donqui (Fri, 27 Sep 2019 13:50:05 GMT):
In the dockerfile there is a apt install line ``` RUN apt-get update -y && apt-get install -y \ indy-plenum=${indy_plenum_ver} \ indy-node=${indy_node_ver} \ python3-indy-crypto=${python3_indy_crypto_ver} \ libindy-crypto=${indy_crypto_ver} \ vim ```

donqui (Fri, 27 Sep 2019 13:50:27 GMT):
pin it there, it should help

VenkateshSYS (Sun, 29 Sep 2019 19:16:21 GMT):
Hey guys! Can anybody tell why this error comes when running the node file which is depending on indy-sdk.. ```Error: Could not locate the bindings file. Tried: → /home/ubuntu/**************/node_modules/indy-sdk/build/indynodejs.node → /home/ubuntu/********************/node_modules/indy-sdk/build/Debug/indynodejs.node → /home/ubuntu/********************/node_modules/indy-sdk/build/Release/indynodejs.node → /home/ubuntu/********************/node_modules/indy-sdk/out/Debug/indynodejs.node → /home/ubuntu/********************/node_modules/indy-sdk/Debug/indynodejs.node → /home/ubuntu/********************/node_modules/indy-sdk/out/Release/indynodejs.node → /home/ubuntu/********************/node_modules/indy-sdk/Release/indynodejs.node → /home/ubuntu/********************/node_modules/indy-sdk/build/default/indynodejs.node → /home/ubuntu/********************/node_modules/indy-sdk/compiled/10.16.3/linux/x64/indynodejs.node → /home/ubuntu/********************/node_modules/indy-sdk/addon-build/release/install-root/indynodejs.node → /home/ubuntu/********************/node_modules/indy-sdk/addon-build/debug/install-root/indynodejs.node → /home/ubuntu/********************/node_modules/indy-sdk/addon-build/default/install-root/indynodejs.node → /home/ubuntu/********************/node_modules/indy-sdk/lib/binding/node-v64-linux-x64/indynodejs.node at bindings (/home/ubuntu/********************/node_modules/bindings/bindings.js:126:9) at Object. (/home/ubuntu/********************/node_modules/indy-sdk/src/index.js:3:31) at Module._compile (internal/modules/cjs/loader.js:778:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10) at Module.load (internal/modules/cjs/loader.js:653:32) at tryModuleLoad (internal/modules/cjs/loader.js:593:12) at Function.Module._load (internal/modules/cjs/loader.js:585:3) at Module.require (internal/modules/cjs/loader.js:692:17) at require (internal/modules/cjs/helpers.js:25:18) at Object. (/home/ubuntu/********************/indy/src/wallet/index.js:2:13) ```

stefanopulzeic (Mon, 30 Sep 2019 13:13:13 GMT):
revocation state ledger

luckycharms810 (Mon, 30 Sep 2019 13:16:07 GMT):
@kdenhartog - I did check to see that the credential matched the restrictions I had placed - I think if not the search handle for credentials would not bring back the appropriate credential.

luckycharms810 (Mon, 30 Sep 2019 13:17:36 GMT):
I did figure it out though - The issue was that the holder not storing the rev reg def json when calling 'prover_store_credential'

MALodder (Mon, 30 Sep 2019 15:45:49 GMT):
https://blog.rust-lang.org/2019/09/30/Security-advisory-for-cargo.html

kdenhartog (Mon, 30 Sep 2019 20:56:13 GMT):
Ahh that makes sense. I’m glad you figured out your problem. Was the logging helpful?

luckycharms810 (Mon, 30 Sep 2019 21:00:28 GMT):
Unfortunately, it wasn't terribly helpful. I used the getting_started.py script to create a wallet with credentials and then plugged that "working" wallet in to our system. Once i determined that the presentation code worked perfectly, it helped me narrow down the problem to the issuance workflow.

xtrycatchx (Wed, 02 Oct 2019 12:01:18 GMT):
apologies for the long reply. thanks for these, its very helpful :)

giancarloGiuffra (Thu, 03 Oct 2019 12:45:30 GMT):
Has joined the channel.

giancarloGiuffra (Thu, 03 Oct 2019 12:45:32 GMT):
Hello everyone, I was trying to run the https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/run-getting-started.md walkthrough. Unfortunately, when docker-compose tries to build the service indy_pool it stops with the following error: ``` ERROR: Service 'indy_pool' failed to build: The command '/bin/sh -c apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CE7709D068DB5E88' returned a non-zero code: 2 ``` I have searched the fingerprint CE7709D068DB5E88 in https://keyserver.ubuntu.com/ and it responds with Not Found.

lynn.bendixsen (Thu, 03 Oct 2019 16:13:15 GMT):
We at sovrin have instructed our stewards to run the following command and they have not had any issues... `apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CE7709D068DB5E88` It seems probably related to the docker environment... maybe be a firewall issue?

lynn.bendixsen (Thu, 03 Oct 2019 16:13:15 GMT):
We at Sovrin have instructed our stewards to run the following command and they have not had any issues... `apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CE7709D068DB5E88` It seems probably related to the docker environment... maybe you are having a firewall issue?

daidoji (Fri, 04 Oct 2019 02:36:48 GMT):
Who do we report broken links to?

daidoji (Fri, 04 Oct 2019 02:36:55 GMT):
```You may also want to look at the older guide that explored the ecosystem via command line. That material is being rewritten but still contains some useful ideas.```

daidoji (Fri, 04 Oct 2019 02:37:07 GMT):
in the README https://github.com/hyperledger/indy-sdk

giancarloGiuffra (Fri, 04 Oct 2019 09:31:37 GMT):
thanks @lynn.bendixsen for the reply. My understanding is that the public key is not present in the server. I went to the website https://keyserver.ubuntu.com/, searched for it and the server responded with "Not Found". Analogously, I tried the following command `gpg --keyserver keyserver.ubuntu.com --recv-key CE7709D068DB5E88` and the request times out.

lynn.bendixsen (Fri, 04 Oct 2019 13:43:23 GMT):
I get the the same result `not found` when searching for the key on the public keyserver. But when I run it on my Ubuntu server I get the following result showing that it found the key on the keyserver and that it is already installed on my server. I am not sure why it is failing during docker-compose, but it is not because the key doesn't exist: ```lynn.bendixsen@selfserve:~$ apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CE7709D068DB5E88 Executing: /tmp/apt-key-gpghome.tI9PgwkEWy/gpg.1.sh --keyserver keyserver.ubuntu.com --recv-keys CE7709D068DB5E88 gpg: key CE7709D068DB5E88: "Sovrin-Repo-Master (Master key for repo.sovring.org) " not changed gpg: Total number processed: 1 gpg: unchanged: 1```

mboyd (Fri, 04 Oct 2019 21:37:13 GMT):
is there anybody here working on a brew package for indy-sdk? I'd be interested to help further the initiative

agiledeveloper (Sat, 05 Oct 2019 11:46:21 GMT):
I am getting `java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.anoncreds.ProofRejectedException: The proof has been rejected.` error. Any suggestions where to check ?

agiledeveloper (Sat, 05 Oct 2019 11:46:21 GMT):
Second attempt on this error `java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.anoncreds.ProofRejectedException: The proof has been rejected.` error. Any suggestions where to check

zixian5 (Mon, 07 Oct 2019 07:46:40 GMT):
Hi guys, when i run the sdk on the Android ,i got this error: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "pthread_atfork" referenced by "libindy.so"...

zixian5 (Mon, 07 Oct 2019 07:47:28 GMT):
Hi guys, when i run the sdk on the Android ,i got this error: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "pthread_atfork" referenced by "libindy.so"...``` ``` Does anyone know how to solve it ? Thanks

zixian5 (Mon, 07 Oct 2019 07:47:49 GMT):
Hi guys, when i run the sdk on the Android ,i got this error: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "pthread_atfork" referenced by "libindy.so" Does anyone know how to solve it ? Thanks

zixian5 (Mon, 07 Oct 2019 07:48:57 GMT):
Hi guys, when i run the sdk on the Android ,i got this error: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "pthread_atfork" referenced by "libindy.so" Does anyone know how to solve it ? Thanks

Henrycoffin (Mon, 07 Oct 2019 09:48:42 GMT):
You need to bundle libindy and add make it available to Android. https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/build-guides/android-build.html It's something I am also figuring out at the moment. Happy to keep you updated on my progress.

agiledeveloper (Mon, 07 Oct 2019 12:53:12 GMT):
Second attempt on this error java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.anoncreds.ProofRejectedException: The proof has been rejected. error. Any suggestions where to check

SergeyBrazhnik (Mon, 07 Oct 2019 13:21:51 GMT):
what function are you using?

agiledeveloper (Mon, 07 Oct 2019 13:22:29 GMT):
`verifierVerifyProof(proofRequest, proof, schemas, credentialDefs, revRegDefs, revRegs).get();`

agiledeveloper (Mon, 07 Oct 2019 13:23:11 GMT):
I am just following the examples, it works there... it is for sure my code or something but I am not sure where to check

SergeyBrazhnik (Mon, 07 Oct 2019 13:23:12 GMT):
could it be that you revocked claim?

agiledeveloper (Mon, 07 Oct 2019 13:23:21 GMT):
no

SergeyBrazhnik (Mon, 07 Oct 2019 13:24:12 GMT):
you need to take a look at this

SergeyBrazhnik (Mon, 07 Oct 2019 13:24:13 GMT):
https://github.com/hyperledger/indy-sdk/tree/master/wrappers/nodejs#logger

SergeyBrazhnik (Mon, 07 Oct 2019 13:24:20 GMT):
and enable logger

SergeyBrazhnik (Mon, 07 Oct 2019 13:24:40 GMT):
it will point you out more detailed info about error then you have now

SergeyBrazhnik (Mon, 07 Oct 2019 13:26:24 GMT):
Hello everyone. Could somebody advise me why on a function *issuerCreateCredential* I could get ``` UrsaCryptoError: Value by key 'fieldname' not found in pk.r ```

agiledeveloper (Mon, 07 Oct 2019 13:33:44 GMT):
I enabled the simple log in the java wrapper... still same error not much details

agiledeveloper (Mon, 07 Oct 2019 13:34:00 GMT):
```[Thread-0] INFO org.hyperledger.indy.sdk.LibIndy.native.indy.commands - src/commands/mod.rs:126 | AnoncredsCommand command received [Thread-0] INFO org.hyperledger.indy.sdk.LibIndy.native.anoncreds_command_executor - src/commands/anoncreds/mod.rs:58 | Verifier command received [Thread-0] INFO org.hyperledger.indy.sdk.LibIndy.native.verifier_command_executor - src/commands/anoncreds/verifier.rs:40 | VerifyProof command received java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.anoncreds.ProofRejectedException: The proof has been rejected. at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395) at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1999) at Verifier.isVerified(Verifier.java:112) at Verifier.RunMe(Verifier.java:80) at Verifier.main(Verifier.java:28) Caused by: org.hyperledger.indy.sdk.anoncreds.ProofRejectedException: The proof has been rejected. at org.hyperledger.indy.sdk.IndyException.fromSdkError(IndyException.java:176) at org.hyperledger.indy.sdk.IndyJava$API.checkResult(IndyJava.java:92) at org.hyperledger.indy.sdk.anoncreds.Anoncreds.access$1300(Anoncreds.java:33) at org.hyperledger.indy.sdk.anoncreds.Anoncreds$7.callback(Anoncreds.java:149) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:520) at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:551)```

SergeyBrazhnik (Mon, 07 Oct 2019 13:36:28 GMT):
it's seems that you did not enabled it

SergeyBrazhnik (Mon, 07 Oct 2019 13:36:35 GMT):
cause you should get not only java log

SergeyBrazhnik (Mon, 07 Oct 2019 13:37:02 GMT):
it seems that you did not enable log correctly

SergeyBrazhnik (Mon, 07 Oct 2019 13:37:14 GMT):
because you should get not only java log

SergeyBrazhnik (Mon, 07 Oct 2019 13:37:37 GMT):
you should get rust log of execution of verifierVerifyProof

agiledeveloper (Mon, 07 Oct 2019 13:43:35 GMT):
thanks alot; now I can see the error :)

agiledeveloper (Mon, 07 Oct 2019 13:47:13 GMT):
worked now :thumbsup:

SergeyBrazhnik (Mon, 07 Oct 2019 13:49:40 GMT):
Hello everyone. Could somebody advise me why on a function *issuerCreateCredential* I could get ``` UrsaCryptoError: Value by key 'fieldname' not found in pk.r ```

giancarloGiuffra (Mon, 07 Oct 2019 14:57:55 GMT):
thanks @lynn.bendixsen , do you have any suggestion on what could be the reason? where to look? what to try? thanks

lynn.bendixsen (Mon, 07 Oct 2019 17:12:10 GMT):
I don't use the docker environment very often, but if I had the error you originally shared, I would look at networking issues. The error seems to indicate that at some level docker can't get to the keyserver. I found this when googling for the error you mentioned: https://github.com/docker-library/mysql/issues/170

zixian5 (Tue, 08 Oct 2019 10:22:42 GMT):
Thanks for replying.But I still got the result according to this document. Is there any thing wrong I may have done?

DucaDellaForcoletta (Thu, 10 Oct 2019 10:46:26 GMT):
issuer_merge_revocation_registry_deltas

smithbk (Fri, 11 Oct 2019 17:55:36 GMT):
Can someone tell me how to build the indy-cli? I tried ``` # RUST_FLAGS="-L $LD_LIBRARY_PATH" cargo build ... = note: /usr/bin/ld: cannot find -lindy collect2: error: ld returned 1 exit status # ls $LD_LIBRARY_PATH build deps examples incremental libindy.a libindy.d libindy.rlib libindy.so native ``` Any help is appreciated

smithbk (Fri, 11 Oct 2019 17:55:36 GMT):
Can someone tell me how to build the indy-cli? I tried the following from the cli directory after doing the `cargo build` in the libindy directory: ``` # RUST_FLAGS="-L $LD_LIBRARY_PATH" cargo build ... = note: /usr/bin/ld: cannot find -lindy collect2: error: ld returned 1 exit status # ls $LD_LIBRARY_PATH build deps examples incremental libindy.a libindy.d libindy.rlib libindy.so native ``` Any help is appreciated

lynn.bendixsen (Fri, 11 Oct 2019 18:49:05 GMT):
I have seen similar issues when I have an incompatible version of rust. Bad versions cause all kinds of weird errors for me. Sometimes a specific version is required, but I think right now using the latest version of rust will work. Also, you might try adding a LIBINDY_DIR env variable.

smithbk (Fri, 11 Oct 2019 19:26:41 GMT):
thanks, will give it a try

smithbk (Fri, 11 Oct 2019 19:45:59 GMT):
setting LIBINDY_DIR worked ... thanks

Alexi (Tue, 15 Oct 2019 00:24:01 GMT):
Hello, with the role of endorsers, is there a good tutorial / flow page about how an endorser can endorse a call (lets say sending a credential) form a non endorser wallet?

swcurran (Tue, 15 Oct 2019 01:52:57 GMT):
An endorser endorses a transaction that writes to the ledger, which would not include sending a credential. It would include writing to the ledger - a nym (a DID), an nym attribute, a schema, a credential definition, a revocation registry and a credential update. We (BC Gov) have been working on the flow of an transaction author creating transactions and sending to an endorser to send and send to the ledger. You can see the work done here - https://github.com/ianco/sovrin-write-txns. The process in that repo handles an author creating a DID, schema and creddef and having an endorser sign and send the transactions to the ledger. FYI - the trick in the process is that the author has to get the relevant data for the transaction into their Indy Wallet such that when the endorser sends the transaction to the ledger, the wallet and the ledger are in sync.

swcurran (Tue, 15 Oct 2019 01:52:57 GMT):
An endorser endorses a transaction that writes to the ledger, which would not include sending a credential. It would include writing to the ledger - a nym (a DID), an nym attribute, a schema, a credential definition, a revocation registry and a revocation update. We (BC Gov) have been working on the flow of an transaction author creating transactions and sending to an endorser to send and send to the ledger. You can see the work done here - https://github.com/ianco/sovrin-write-txns. The process in that repo handles an author creating a DID, schema and creddef and having an endorser sign and send the transactions to the ledger. FYI - the trick in the process is that the author has to get the relevant data for the transaction into their Indy Wallet such that when the endorser sends the transaction to the ledger, the wallet and the ledger are in sync.

Alexi (Tue, 15 Oct 2019 01:55:24 GMT):
awesome, thank you! This is great

swcurran (Tue, 15 Oct 2019 20:53:39 GMT):
@danielhardman - In a follow up email to IIW you mentioned that you did a presentation that included debunking these misconceptions about link secrets: 1. link secrets are not rotatable (false) 2. link secrets are transferrable (false) Are there materials to share about what you talked about at IIW related to these, particularly the first one? Thanks

danielhardman (Wed, 16 Oct 2019 01:49:27 GMT):
I have seen such materials, but I don't want you to get your hopes up. I was arguing about Siri, not about current state of implementation. There is a very clean way to apply a theory of making link secrets rotatable, and there are docks that are crypto people have used to discuss it. When I say our crypto people, I mean people that go to the Ursa or Sovereign crypto calls. But some of the discussion is mathematical, and it's still somewhat Raw. I don't know if they would be willing to interpret the math for all of us who are less mathematical, or if they want us to sit tight until they're ready to talk to a broader audience. It might be worth asking this question on an Ursa call. I will ask the question and see what I get, but if I don't give satisfaction, feel free to go fishing those Waters yourself too

danielhardman (Wed, 16 Oct 2019 01:50:03 GMT):
Haha. Crazy voice to text. I wasn't arguing about Apple's Siri, I was arguing about Theory

dkushagra (Wed, 16 Oct 2019 06:20:33 GMT):
Hi, I am getting following error when I try to run java sample in indy-sdk : - ```java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.InvalidStateException: The SDK library experienced an unexpected internal error.``` Any help? Thanks in advance

andrew.whitehead (Wed, 16 Oct 2019 07:31:05 GMT):
I think you’ll need to be more specific about what’s working, and where the demo is failing

sergey.minaev (Wed, 16 Oct 2019 17:54:11 GMT):
I suggest to attach logs more logs at maximal level https://github.com/hyperledger/indy-sdk/tree/master/wrappers/java#logging

jljordan_bcgov (Thu, 17 Oct 2019 02:46:01 GMT):
I believe @WadeBarnes has further refined this process and build some tooling into von-network

jljordan_bcgov (Thu, 17 Oct 2019 02:46:45 GMT):
I believe @WadeBarnes has further refined this process and build some tooling into von-network

WadeBarnes (Thu, 17 Oct 2019 02:48:07 GMT):
https://github.com/bcgov/von-network/pull/76

WadeBarnes (Thu, 17 Oct 2019 02:53:39 GMT):
@Alexi, ^^ these changes integrate and refine @ianco’s work into a fully Dockerized process so you don’t need the Indy SDK or any of its dependencies installed on your machine.

tomislav (Thu, 17 Oct 2019 17:49:43 GMT):
The `append_txn_author` endpoint specifies that a hash of the `version || text` can be calculated and submitted, instead the whole text. The hash (taa_digest) is a string representation of the hash. How is this string constructed? Is it a hex string? Utf8? base58?

andrew.whitehead (Thu, 17 Oct 2019 17:58:49 GMT):
It's sha256 in hex format: https://github.com/hyperledger/aries-cloudagent-python/blob/02e76ca834a701832399a1cc888209bf3bfdcab5/aries_cloudagent/ledger/indy.py#L701

ajayjadhav (Thu, 17 Oct 2019 18:10:40 GMT):
Has joined the channel.

tomislav (Thu, 17 Oct 2019 18:22:43 GMT):
Excellent, thanks @andrew.whitehead

Jack1477 (Fri, 18 Oct 2019 17:50:43 GMT):
Has joined the channel.

Jack1477 (Fri, 18 Oct 2019 17:50:44 GMT):
Hello everyone! I just started writing a wrapper for Indy SDK for the application I am developing. I setup local environemnt with Indy nodes and can connect / use it fine, but I am confused about the way the SDK exposes its API and the lack of authorization in it. My question is - how the ACL works with this SDK? How is the user executing given API call identified by Node? For example - how is it determined whether user is allowed to execute API to write data in opposition to read only calls? Is it only IP-based so its a scenario that user from an IP can execute all or not a single call at all?

Jack1477 (Fri, 18 Oct 2019 17:54:02 GMT):
The second question is - what exactly is the purpose and functional use of SDK call createPoolLedgerConfig? Is it a call to let the SDK know where to connect for future calls? This is what I would assume but from what I can tell it also dispatches remote request. Why? Does it try to ping the pool during cofngiuration to see whether it exists?

Jack1477 (Fri, 18 Oct 2019 17:54:59 GMT):
I am especially confused by the second one as it sounds to me like typical admin call, that just be restricted to CLI only when installing the node to give it some configuration. But I probably did not understand use of that call properly.

smithbk (Fri, 18 Oct 2019 20:01:15 GMT):
Hi, has anyone seen this error before and know what causes it? ```Generating genesis file at /var/lib/indy/sandbox/pool_transactions_genesis ... Generating keys for provided seed b'000000000000000000000000000Node1' Init local keys for client-stack Traceback (most recent call last): File "/usr/lib/python3.5/shutil.py", line 538, in move os.rename(src, real_dst) FileNotFoundError: [Errno 2] No such file or directory: '/var/lib/indy/sandbox/keys/__eDir/Node1C.key_secret' -> '/var/lib/indy/sandbox/keys/Node1C/private_keys/Node1C.key_secret' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/indy/bin/generate_indy_pool_transactions", line 19, in getTxnOrderedFields(), ConfigHelper, NodeConfigHelper) File "/usr/local/lib/python3.5/dist-packages/plenum/common/test_network_setup.py", line 246, in bootstrapTestNodes config_helper_class, node_config_helper_class) File "/usr/local/lib/python3.5/dist-packages/plenum/common/test_network_setup.py", line 129, in bootstrapTestNodesCore _, verkey, blskey, key_proof = initNodeKeysForBothStacks(nd.name, keys_dir, nd.sigseed, override=True) File "/usr/local/lib/python3.5/dist-packages/plenum/common/keygen_utils.py", line 49, in initNodeKeysForBothStacks initLocalKeys(client_stack_name, keys_dir, sigseed, use_bls=False, override=override) File "/usr/local/lib/python3.5/dist-packages/plenum/common/keygen_utils.py", line 13, in initLocalKeys pubkey, verkey = nodeStackClass.initLocalKeys(name, keys_dir, sigseed, override=override) File "/usr/local/lib/python3.5/dist-packages/stp_zmq/zstack.py", line 193, in initLocalKeys moveKeyFilesToCorrectLocations(eDir, pubDirPath, secretDirPath) File "/usr/local/lib/python3.5/dist-packages/stp_zmq/util.py", line 99, in moveKeyFilesToCorrectLocations os.path.join(skdir, key_file)) File "/usr/lib/python3.5/shutil.py", line 552, in move copy_function(src, real_dst) File "/usr/lib/python3.5/shutil.py", line 251, in copy2 copyfile(src, dst, follow_symlinks=follow_symlinks) File "/usr/lib/python3.5/shutil.py", line 114, in copyfile with open(src, 'rb') as fsrc: FileNotFoundError: [Errno 2] No such file or directory: '/var/lib/indy/sandbox/keys/__eDir/Node1C.key_secret'```

magicindustries (Sat, 19 Oct 2019 01:18:35 GMT):
I'm working on calling libindy from C#, and I'm a Rust noob so having trouble understanding what the Box part of this achieve:

magicindustries (Sat, 19 Oct 2019 01:18:38 GMT):
let result = CommandExecutor::instance() .send(Command::Pool(PoolCommand::Create( config_name, config, Box::new(move |result| { let err = prepare_result!(result); trace!("indy_create_pool_ledger_config:"); cb(command_handle, err) }) )));

magicindustries (Sat, 19 Oct 2019 01:19:03 GMT):
this is the signature it's calling: Create( String, // name Option, // config Box) + Send>),

magicindustries (Sat, 19 Oct 2019 01:20:11 GMT):
Somehow this call is causing the dll not to be unloaded properly or some memory / thread not being freed when I'm calling it as a native extension in Unity (C#). Basically It runs once, then the next execution freezes trying to load the library because something's stopped it from being unloaded.

magicindustries (Sat, 19 Oct 2019 01:20:42 GMT):
Would appreciate any pointers as to how or whether the use of Box here might be causing this, or if there's some way I can manually release something

kdenhartog (Sun, 20 Oct 2019 03:27:51 GMT):
I've not seen this one before. I suspect that during the generating keys step that the file is not being stored. Might be worth looking into what's happening on setup of the node. Also, posting this in the #indy-node channel may get you better help from the maintainers who work on Indy-node normally.

swcurran (Sun, 20 Oct 2019 18:46:32 GMT):
Was the indy-sdk bi-weekly Wednesday call notice that went out on the mailing list yesterday intended? It looked like an old notice from quite some time ago. Are we reviving that meeting on the weeks when there is not a morning Aries WG call? @esplinr

tomislav (Mon, 21 Oct 2019 00:06:08 GMT):
@magicindustries Assuming you're using the .NET wrapper https://www.nuget.org/packages/Hyperledger.Indy.Sdk/ - it should properly release resources if you're calling it in a `using` context as `IDisposable` is implemented on wallet and pool handles. Someone else has previously reported similar behavior and I would love to dive deeper into this and investigate why the runtime isn't unloading. Can you share more info how can I reproduce this in a simple project? In regards to Box with Rust, it allocates memory on the heap and moves the value in the allocated address. Reference counting in Rust should ensure that memory is reclaimed, if you release the handle, using `CloseAsync` in C# or just instantiating it with `using` statement.

tomislav (Mon, 21 Oct 2019 00:06:08 GMT):
@magicindustries Assuming you're using the .NET wrapper https://www.nuget.org/packages/Hyperledger.Indy.Sdk/ - it should properly release resources if you're calling it in a `using` context as `IDisposable` is implemented on wallet and pool handles. Someone else has previously reported similar behavior and I would love to dive deeper into this and investigate why the runtime isn't unloading. Can you share more info how can I reproduce this in a simple project? In regards to Box with Rust, it allocates memory on the heap and moves the value in the allocated address. Reference counting in Rust should ensure (and be compatible with CLR garbage collection) that memory is reclaimed, if you release the handle, using `CloseAsync` in C# or just instantiating it with `using` statement.

magicindustries (Mon, 21 Oct 2019 04:54:38 GMT):
Thanks @tomislav I actually tracked it down. The mutex lock in commands/mod.rs isn't being released, so a thread remains open. It mustn't be a problem in most cases, but when calling from Unity the loose thread causes a problem the second time you try to run the app.

magicindustries (Mon, 21 Oct 2019 04:55:48 GMT):
the basic solution is to put the lock inside the loop and call CommandExcutor::new() instead of CommandExcutor::instance() . Obviously that's a hack and I need to understand the purpose of the setup for instance in CommandExecutor better to work out a proper solution

magicindustries (Mon, 21 Oct 2019 04:57:46 GMT):
I was originally using the wrapper, but cut it out to ensure it wasn't part of the problem I was tracking down.

magicindustries (Mon, 21 Oct 2019 04:59:31 GMT):
Happy to do a walkthrough or post a project or something, whatever's easiest. I'd like to learn how to fix this in line with the way things are supposed to work and develop a PR

magicindustries (Mon, 21 Oct 2019 04:59:55 GMT):
I've got the same problem happening with the indy_set_logger command, though there's no mutex there so I'm not sure what that is yet

magicindustries (Mon, 21 Oct 2019 05:13:24 GMT):
In the logger, it seems line 121 of utils/logger.rs is the culprit. It's storing something in an AtomicUsize via (I think) the log crate. Which I would have thought was thread safe...

magicindustries (Mon, 21 Oct 2019 05:29:59 GMT):
I'm still a rust noob so I've no idea why the logger thing would be causing a problem

magicindustries (Mon, 21 Oct 2019 05:30:49 GMT):
the solution to the mutex problem is simplistic, it makes a lock that gets immediately released, so it stops my problem but it's not the right thing to be doing. Would like to chat to someone who understands the architecture about the right way to do it

magicindustries (Mon, 21 Oct 2019 06:14:19 GMT):
With the logger it's again only happening if there's a callback. If you pass null in for all the callbacks directly or in the wrapper, there's no problem. If you leave the callback in, only uncommenting out the "log::set_max_level(LevelFilter::Trace);" line stops the hung thread

magicindustries (Mon, 21 Oct 2019 06:14:38 GMT):
but I'm just poking things with sticks here at the moment

magicindustries (Mon, 21 Oct 2019 07:17:11 GMT):
Actually I spoke two soon. Comment out either line 120 or 121 and the problem is still there - comment out both and it goes away. Seems like touching the log crate is what makes it hang, but I don't know enough about that side to know what I'm talking about yet

magicindustries (Mon, 21 Oct 2019 07:17:11 GMT):
Actually I spoke too soon. Comment out either line 120 or 121 and the problem is still there - comment out both and it goes away. Seems like touching the log crate is what makes it hang, but I don't know enough about that side to know what I'm talking about yet

Jack1477 (Mon, 21 Oct 2019 09:27:06 GMT):
Hello everyone. Can someone answer the questions I gave on Friday? I heard this is the place to go to, but it seems there are no indy devs here? Should I move my questions somewhere else? What's the best place for technical questions then?

donqui (Mon, 21 Oct 2019 10:50:01 GMT):
Every client is identified by a DID. If you are sending a Read Request there is not authentication/authorization. If you are sending a Write Request: - PRECONDITION: Your DID needs to be previously 'registered' in a NYM transaction on the ledger. This sets your Public Key and your Role. This action needs to be done by an already trusted Client/User/Admin with an appropriate Role. - You sign the request with your Private Key and send it over - Node checks if your DID is on the ledger, and checks your signature against the Public Key to see if the signature is valid and if you are who you claim to be - Node then checks if your Role allows you to perform the provided command against the auth_rules (https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md)

donqui (Mon, 21 Oct 2019 10:50:01 GMT):
Every client is identified by a DID. If you are sending a Read Request there is no authentication/authorization. If you are sending a Write Request: - PRECONDITION: Your DID needs to be previously 'registered' in a NYM transaction on the ledger. This sets your Public Key and your Role. This action needs to be done by an already trusted Client/User/Admin with an appropriate Role. - You sign the request with your Private Key and send it over - Node checks if your DID is on the ledger, and checks your signature against the Public Key to see if the signature is valid and if you are who you claim to be - Node then checks if your Role allows you to perform the provided command against the auth_rules (https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md)

donqui (Mon, 21 Oct 2019 11:01:43 GMT):
Pool members can change, so the client always need to keep this fresh and get the current state from the ledger to be stored locally.

tomislav (Mon, 21 Oct 2019 12:07:34 GMT):
You're on to something @magicindustries . The way to approach this is to raise a bug with the team that can help track down the problem of this. I'm afraid this might be cause problems as well when using in mobile environments, which unmanaged resources not being properly released and potentially causing memory leaks. Indy SDK JIRA canoe found here - https://jira.hyperledger.org/secure/RapidBoard.jspa?rapidView=149&projectKey=IS I would copy/paste everything you mentioned here. @esplinr @sergey.minaev

tomislav (Mon, 21 Oct 2019 12:07:34 GMT):
You're on to something @magicindustries . The way to approach this is to raise a bug with the team that can help track down the problem of this. I'm afraid this might be cause problems as well when using in mobile environments, with unmanaged resources not being properly released and potentially causing memory leaks. Indy SDK JIRA can found here - https://jira.hyperledger.org/secure/RapidBoard.jspa?rapidView=149&projectKey=IS I would copy/paste everything you mentioned here. @esplinr @sergey.minaev

magicindustries (Mon, 21 Oct 2019 12:09:12 GMT):
ok great to know - I was tryin to avoid bothering everyone with a bug if it was just me. Just go add a ticket on Jira?

tomislav (Mon, 21 Oct 2019 12:11:40 GMT):
Yes please. The team will give you a better answer on the specific use of Mutex and will be able to address this issue. Someone else had the exact same issue with Unity and freeze on second run, but their chat handle escapes me now to tag them.

magicindustries (Mon, 21 Oct 2019 12:12:53 GMT):
ok will do. Might have been me, I chatted to you about it briefly ages ago

tomislav (Mon, 21 Oct 2019 12:16:41 GMT):
Could be. Did we connect on Skype?

magicindustries (Mon, 21 Oct 2019 12:17:04 GMT):
yep. must be a while ago now.

tomislav (Mon, 21 Oct 2019 12:17:42 GMT):
I remember. Happy to see you still working on the Unity/Indy integration - not so happy about this bug though

magicindustries (Mon, 21 Oct 2019 12:18:37 GMT):
well today I'm chuffed to have finally tracked it down, the rest is for tommorrow :)

DucaDellaForcoletta (Mon, 21 Oct 2019 15:09:27 GMT):
Hi everyone, has anyone used the issuer_merge_revocation_registry_deltas method?

andrew.whitehead (Tue, 22 Oct 2019 02:31:57 GMT):
For the read and write operations performed by the SDK, are you talking about ledger operations? Because the ACL there is determined by whether the key that signed the request has a registered nym and role on the ledger already. I don't know why createPoolLedgerConfig would be making remote calls

magicindustries (Tue, 22 Oct 2019 03:51:01 GMT):
Created a ticket in Jira - I can't see it, I assume there's a backlog I don't have access to?

magicindustries (Tue, 22 Oct 2019 03:52:08 GMT):
nvm I found it. IS-1410

magicindustries (Tue, 22 Oct 2019 04:07:23 GMT):
I'll file a separate one about the logger

AxelNennker (Tue, 22 Oct 2019 07:48:17 GMT):
Why does the rust/wrappers code not use more of the future's features like e.g. ```rust #[cfg(test)] mod test_build_get_attrib_request { use super::*; #[test] pub fn build_get_attrib_request_success() { let submitter_wallet = Wallet::new(); let wallet = Wallet::new(); let f1 = did::create_and_store_my_did(submitter_wallet.handle, "{}"); let f2 = did::create_and_store_my_did(wallet.handle, "{}"); f1.join(f2).map(|((submitter_did, _), (did, _))| { match ledger::build_get_attrib_request(Some(&submitter_did), &did, Some("{}"), None, None).wait() { Ok(_) => {}, Err(ec) => { assert!(false, "build_attrib_request failed with error {:?}", ec); } } }).wait().unwrap(); } } ``` I looked at that code because libindy/tests/demo.rs fails in the WalletHandle_TypeSafety PR because wallet_1 does not exist (?). That led me to thinking that the demo.rs should be in wrappers/rust and the demo code should only use higher-level wrapper stuff. No sane developer should use the low-level callback stuff. What do you think, should demo.rs be moved to wrappers/rust?

andrew.whitehead (Tue, 22 Oct 2019 07:59:10 GMT):
Seems like the sane thing to do :)

sklump (Tue, 22 Oct 2019 11:46:57 GMT):
Note that the rust wrapper is not a wrapper like the others if I recall correctly. Alas I can't remember the details, but it's an important part of the library itself in some way. "Be careful here", is all I remember at the moment.

sanket1211 (Tue, 22 Oct 2019 12:08:01 GMT):
Has joined the channel.

chuda (Tue, 22 Oct 2019 12:17:52 GMT):
Has joined the channel.

AxelNennker (Tue, 22 Oct 2019 13:18:30 GMT):
Yes, it is part of the library in an exspecially strange way. The libindy crate is using the wrappers/rust crate using `indy = { path = "../wrappers/rust" }` https://github.com/hyperledger/indy-sdk/blob/master/libindy/Cargo.toml#L90 This leads to all kind of terrible crate-import-and-renaming-Fu in libindy/tests which use the wrappers/rust. This also prevents https://github.com/rust-embedded/cross to work. I wished libindy would not do that ../wrapper/rust stuff. It is evil. Although I tried to change it and it is ... complicated. Maybe it gets easier after libindy is split into several crates. https://github.com/hyperledger/indy-sdk/pull/1927

sklump (Tue, 22 Oct 2019 13:20:14 GMT):
LOL@"Although I tried to change it and it is ... complicated."

Rick (Tue, 22 Oct 2019 13:37:11 GMT):
Has joined the channel.

Jack1477 (Tue, 22 Oct 2019 16:42:54 GMT):
Ok, so its this in-memory configuration for SDK client? Or does it set the configuration on a Node?

donqui (Tue, 22 Oct 2019 16:45:14 GMT):
in memory for the client

Jack1477 (Tue, 22 Oct 2019 16:51:37 GMT):
I understand the idea of signing transactions and having ledger-level ACL depend on that. But what about ACL to a single node? To give you comparison - in other blockachains you usually are able to create RPC or REST user that will be able to conenct to the node and use the node API to broadcast transactions. At the level of RPC/RESST user ACL it does not matter if I signed proper or improper transaction. If I don't have credentials to the node itself it will not allow me to connect to it. What's more - some platforms allow you to decide which calls you want to whitelist. For example in Geth you can decide on node startup to expose only some of the API families and/or expose different ones to different users. How it does in Indy? I do not see any way to configure my node-level credentials when using the SDK.

Jack1477 (Tue, 22 Oct 2019 16:51:59 GMT):
Why does client need to know the whole configuration file for the network?

Jack1477 (Tue, 22 Oct 2019 16:52:11 GMT):
Wouldn't it be enough for it to know just the endpoint of a node to connect with?

donqui (Tue, 22 Oct 2019 16:53:04 GMT):
this file is just caled that, it does not contain the coniguration for the network. This function just creates a local client config file from the contents of the genesis file.

donqui (Tue, 22 Oct 2019 16:53:04 GMT):
this file is just called that, it does not contain the configuration for the network. This function just creates a local client config file from the contents of the genesis file.

Jack1477 (Tue, 22 Oct 2019 16:54:07 GMT):
Ok, but there is no option to specify the endpoint to connect to, only this file. That means the client will try to conenct to the one from it, doesn't it?

donqui (Tue, 22 Oct 2019 16:58:33 GMT):
Yes, client tries to connect to one of the nodes specified in the file.

Jack1477 (Tue, 22 Oct 2019 16:59:25 GMT):
Does it mean that files is also a connection bootstrapping file for the client itself?

Jack1477 (Tue, 22 Oct 2019 17:00:04 GMT):
is there documentation for that behaviour? I would love to see some documentation that goes in details how the conenctions work with the SDK. How it deteremines where to connect, how it handles conenction failures , how it handles P2P and so on.

dkushagra (Wed, 23 Oct 2019 05:11:54 GMT):
I got this done, I had to reset my indy pool

dkushagra (Wed, 23 Oct 2019 05:22:05 GMT):
Hi, I am trying to replicate Getting - Started python script : - https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/getting-started.ipynb in java. When I call function ```Crypto.anondecrypt()``` the response I get is in byte[] array . The problem is that I am not able to decode this btye[] array to a usable form. Please help my work is stuck on this step. Following is the segment of code : - ```JSONObject toConnectionResponse = new JSONObject(); toConnectionResponse.put("did", toFromDID); toConnectionResponse.put("key", toFromVerKey); toConnectionResponse.put("nonce", connectionRequest.getInt("nonce")); to.put("connectionResponse", toConnectionResponse); byte[] anoncryptedConnectionResponse = Crypto.anonCrypt(fromToVerKey, toConnectionResponse.toString().getBytes("UTF-8")).get(); System.out.println(from.get("name") + " ---> Anondecrypt connection response from " + to.get("name")); byte[] fromConnectionResponse = Crypto.anonDecrypt(fromWallet, fromToKey, anoncryptedConnectionResponse).get();```

dkushagra (Wed, 23 Oct 2019 05:22:05 GMT):
Hi, I am trying to replicate Getting - Started python script : - https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/getting-started.ipynb in java. When I call function Crypto.anondecrypt() the response I get is in byte[] array . The problem is that I am not able to decode this btye[] array to a usable form. Please help my work is stuck on this step. Following is the segment of code : - ```JSONObject toConnectionResponse = new JSONObject(); toConnectionResponse.put("did", toFromDID); toConnectionResponse.put("key", toFromVerKey); toConnectionResponse.put("nonce", connectionRequest.getInt("nonce")); to.put("connectionResponse", toConnectionResponse); byte[] anoncryptedConnectionResponse = Crypto.anonCrypt(fromToVerKey, toConnectionResponse.toString().getBytes("UTF-8")).get(); System.out.println(from.get("name") + " ---> Anondecrypt connection response from " + to.get("name")); byte[] fromConnectionResponse = Crypto.anonDecrypt(fromWallet, fromToKey, anoncryptedConnectionResponse).get();```

JeromeK (Wed, 23 Oct 2019 07:58:08 GMT):
Hey Guys Is it possible to query alle Schema from the Ledger with some Kind of filter like: https://github.com/hyperledger/indy-node/blob/master/design/anoncreds.md#list_schema

JeromeK (Wed, 23 Oct 2019 07:58:08 GMT):
Hey Guys Is it possible to query all Schema from the Ledger with some Kind of filter like https://github.com/hyperledger/indy-node/blob/master/design/anoncreds.md#list_schema ?

zixian5 (Wed, 23 Oct 2019 12:32:07 GMT):
Hey Guys. Because Android NDK 18 has removed libgnustl_shared.so, i can't get the suitable libgnustl_shared for libindy while building libindy on Android. I built libindy1.6 successfully with libgnustl_shared.so in Android NDK16 , but i failed to build libindy1.12 with libgnustl_shared.so in Android NDK16 , and i can't get libgunstl_shared in NDK18 or higher. So does anyone know to solve it?

zixian5 (Wed, 23 Oct 2019 12:32:07 GMT):
Hey Guys. Because Android NDK 18 has removed libgnustl_shared.so, i can't get the suitable libgnustl_shared for libindy while building libindy on Android. I use libindy1.6 successfully with libgnustl_shared.so in Android NDK16 , but i failed to use libindy1.12 with libgnustl_shared.so in Android NDK16 , and i can't get libgunstl_shared in NDK18 or higher. So does anyone know to solve it?

swcurran (Wed, 23 Oct 2019 13:40:14 GMT):
No - there is no query/discovery mechanism built into the ledger. The approach used to this point is to read the entire ledger, store it in a database and query that. Public ledger browsers are here https://sovrin-mainnet-browser.vonx.io/ and https://indyscan.io/home/sovmain

JeromeK (Thu, 24 Oct 2019 07:26:47 GMT):
Got it, thanks for the answer :)

sukalpomitra (Thu, 24 Oct 2019 07:31:19 GMT):
Hi all, I have a doubt it seems from this line of code that when rev_reg_id in a proof json is null, the timestamp needs to be null too - https://github.com/hyperledger/indy-sdk/blob/30e2e487f144702f158454b55913deb1b65e2b60/libindy/src/services/anoncreds/verifier.rs#L82

sukalpomitra (Thu, 24 Oct 2019 07:31:45 GMT):
But when I call AnonCreds.ProverCreateProofAsync it generates the proof json with a timestamp

sukalpomitra (Thu, 24 Oct 2019 07:32:09 GMT):
```{\"proof\":{\"proofs\":[{\"primary_proof\":{\"eq_proof\":{\"revealed_attrs\":{\"email\":\"21513911572240909247520170420850068030201571957119989629464347627007329792651\"},\"a_prime\":\"81188381639744887907295155845781242768815931804677074344275228324514172277767613897885744252318064848755966569805797941133893022764842845462670614872840924355331382764827887946934789935676871938016646455167849807963483591327320437064111669368151947827640676237353948668966818361955373681124225601440865716533289317776456162387808952308247580896641617403957190594248534915867267743331592604044613121215273154341589383279652451667895551063771089846228195436470553104391212323199490294968533512155656196325190041872435121697819055523049062513349991957360116997142433239641651862323781165540175000295766593730824784287206\",\"e\":\"75737497098256720989680045924867058338586643049841191660101136180076263890664446397204591172455670286017377907176173866366522051779339493\",\"v\":\"1359665353879032339779126110998974420562533848726909723894463010200488817990211119576560984849875422222492992795450609333057906866213074822447983541190186645327976406166276165315505573992147507031489597933612875902854648414272249050360530938398510380473648515850837821730874302465253459632741029617723739195712718037380264820361855943832261665099730167198480395012879961785759867144184239807178870195003950060899383786879453635897662558192904806880299547164630723201282485004537372810659306505597430612571159200619992589198221215122072574667510488729587154350814631983583215789171447385867204512725163903874068762117376723957179517666076653603310109724590789223883501528682548327348684635730764843345398139856399251652281677632521634702420670459516934991753392006393660971980640482900448349952751720787742967797066133855449914587326879157933348691645673139342704009558544464170068753982991663752321026831003034586696744157\",\"m\":{\"time\":\"13020691702483743146273165583492974846105786284585268493331927331740041275126204527133084681803268049809343957346223524134878170903951896544910218896276942525116027511279402980239\",\"master_secret\":\"12244858554618070911151993642896361080503892361635424879466864589085284583718671244368644485278395752498384291131648864525688409830757072200551162323019135150460600437719842984814\"},\"m2\":\"15452163158521023889566102899592679202431760251025247132894586407332543995673947569650639145571604455440020462515699793721566406869815655601302538576025883915835019471795869015431\"},\"ge_proofs\":[]},\"non_revoc_proof\":null}],\"aggregated_proof\":{\"c_hash\":\"34316760316107461175679860121412957840651555461924819013201290635340401462499\",\"c_list\":[[2,131,34,200,36,70,191,171,184,161,52,237,132,144,101,165,172,138,252,233,233,214,248,30,126,65,212,8,222,101,8,79,120,134,121,168,121,227,238,206,239,103,140,125,57,161,166,168,214,220,117,135,66,207,246,124,236,155,117,96,24,89,108,83,189,34,160,93,176,183,47,167,33,170,228,214,235,130,30,190,91,235,127,59,25,143,125,78,47,211,113,3,148,114,228,135,131,121,147,110,188,22,184,180,225,50,206,11,187,67,171,128,233,135,19,151,68,85,159,14,35,68,146,42,59,112,247,132,221,81,129,183,98,255,96,54,184,82,186,249,69,124,217,215,247,41,223,188,170,27,80,115,232,193,28,171,173,150,9,25,38,249,33,254,119,72,136,87,56,112,98,218,245,140,225,46,184,54,70,73,158,246,87,117,122,79,130,201,77,49,253,13,49,69,45,22,26,178,191,91,148,73,24,42,172,22,120,211,50,146,81,252,101,220,76,147,70,130,80,44,140,174,253,25,143,165,66,1,235,109,73,95,188,52,198,213,250,195,166,185,245,228,81,162,248,40,153,16,9,47,184,120,32,23,15,149,230]]}},\"requested_proof\":{\"revealed_attrs\":{\"1b422a47-08c0-4776-99c6-0333efc90d65\":{\"sub_proof_index\":0,\"raw\":\"sukalpomitra@gmail.com\",\"encoded\":\"21513911572240909247520170420850068030201571957119989629464347627007329792651\"}},\"self_attested_attrs\":{},\"unrevealed_attrs\":{},\"predicates\":{}},\"identifiers\":[{\"schema_id\":\"MTYqmTBoLT7KLP5RNfgK3b:2:verified-email:1.2.2\",\"cred_def_id\":\"MTYqmTBoLT7KLP5RNfgK3b:3:CL:1054:default\",\"rev_reg_id\":null,\"timestamp\":1571814987071}]}```

sukalpomitra (Thu, 24 Oct 2019 07:32:51 GMT):
and thus it fails on verifier side with error_details: {'backtrace': '', 'message': 'Error: Invalid structure\n Caused by: Revocation Registry Id not found

sukalpomitra (Thu, 24 Oct 2019 07:33:04 GMT):
I am on libindy version 1.11.1

sukalpomitra (Thu, 24 Oct 2019 07:33:53 GMT):
what am I missing here?

ShrinivasDeshmukh (Thu, 24 Oct 2019 07:52:48 GMT):
Has joined the channel.

tomislav (Fri, 25 Oct 2019 12:33:54 GMT):
+1 upvote to @sukalpomitra question. Running into the same issue when using non revocable cred refs.

tomislav (Fri, 25 Oct 2019 12:33:54 GMT):
+1 upvote to @sukalpomitra question. Running into the same issue when using non revocable cred defs.

DucaDellaForcoletta (Fri, 25 Oct 2019 12:56:09 GMT):
Have you set the tag non_revoked in the proof_request?

sukalpomitra (Fri, 25 Oct 2019 17:39:11 GMT):
@DucaDellaForcoletta I am calling a anoncreds provercreateproofasync from libindy SDK. How can I set the tag? Or does the tag need to be set at the credential while saving it?

esplinr (Sun, 27 Oct 2019 05:50:03 GMT):
You are correct that we have cancelled the indy-sdk bi-weekly Wednesday calls. I don't see the notice that you saw, so I'm not sure what caused the error.

DucaDellaForcoletta (Mon, 28 Oct 2019 07:42:56 GMT):
Hi, I mean the tag non_revoked in the proof request. If only the primary proof is needed, the tag non_revoked can be omitted in the proof request https://github.com/hyperledger/indy-sdk/blob/9ac08096cd92c792e2b8be44be098493e26a1b05/wrappers/dotnet/indy-sdk-dotnet-test/InteractionTests/AnoncredsRevocationInteractionTest.cs#L204

sukalpomitra (Mon, 28 Oct 2019 07:44:03 GMT):
@andrew.whitehead @WadeBarnes can answer this one

DucaDellaForcoletta (Mon, 28 Oct 2019 07:47:44 GMT):
I also opened a bug on these issues https://jira.hyperledger.org/browse/IS-1306

DucaDellaForcoletta (Mon, 28 Oct 2019 10:03:52 GMT):
Hi all, is there a limit on the amount of data that can be inserted into an attribute of a credential?

sklump (Mon, 28 Oct 2019 10:34:09 GMT):
If the proof request specifies non_revoked, the prover must prove non-revocation for some (any) date in the non-revocation interval.

sklump (Mon, 28 Oct 2019 14:26:54 GMT):
Some spitballing suggests about 300kB.

smithbk (Mon, 28 Oct 2019 14:59:15 GMT):

smithbk - Mon Oct 28 2019 10:59:13 GMT-0400 (Eastern Daylight Time).txt

DucaDellaForcoletta (Mon, 28 Oct 2019 16:24:11 GMT):
I believe that if there is a limit, it is higher because from my some test, I've put in attribute base64 image of at least 2Mb.

smithbk (Mon, 28 Oct 2019 17:01:41 GMT):
Hi, is there a way to get a more verbose indy-sdk error message without setting the log level to trace? The json-stringified IndyError only has an error code that is very generic. The one-line error message at the bottom of the stack trace when the log level is set to trace is much more helpful, but I'd like to be able to get that without seeing the stack trace.

magicindustries (Tue, 29 Oct 2019 10:10:01 GMT):
Can someone explain what it means to have a function signature with a lifetime in it when it doesn't accept parameters? Like this:

magicindustries (Tue, 29 Oct 2019 10:10:04 GMT):
pub fn instance<'mutex>() -> MutexGuard<'mutex, CommandExecutor> {

magicindustries (Tue, 29 Oct 2019 10:10:11 GMT):
what is actually happening with the lifetimes there?

dkushagra (Tue, 29 Oct 2019 12:51:45 GMT):
Hi, I am working on indy-sdk on java, I am stuck on a problem with Crypto.anonDecrypt() function . I am not able to deCrypt the response from the function. The response is something like this : - [B@786d4df8 . Can anybody help me to get the de-crypted response from the function . Thanks in advance .

smithbk (Tue, 29 Oct 2019 15:28:44 GMT):
Given a credential definition ID, I need to get the credential schema ID so that I can get the schema name and version. /HERE

smithbk (Tue, 29 Oct 2019 15:28:44 GMT):
Given a credential definition ID, I need to get the credential schema ID so that I can get the schema name and version. Can someone tell me how to do this? For example, my credential definition ID is `E9cpugMSC3i2mTcrw5m9Xk:3:CL:837:TAG1` and this is what is returned when reading from the ledger: ```["E9cpugMSC3i2mTcrw5m9Xk:3:CL:837:TAG1",{"ver":"1.0","id":"E9cpugMSC3i2mTcrw5m9Xk:3:CL:837:TAG1","schemaId":"837","type":"CL","tag":"TAG1","value": ...}]``` . But my credential schema ID is `E9cpugMSC3i2mTcrw5m9Xk:2:Number:1.0` which I don't see in the cred def ledger read response. The prefix `E9cpugMSC3i2mTcrw5m9Xk` is the same as from the cred def id not the suffix.

smithbk (Tue, 29 Oct 2019 15:28:44 GMT):
Given a credential definition ID, I need to get the credential schema ID so that I can get the schema name and version. Can someone tell me how to do this? For example, my credential definition ID is `E9cpugMSC3i2mTcrw5m9Xk:3:CL:837:TAG1` and this is what is returned when reading from the ledger: ```["E9cpugMSC3i2mTcrw5m9Xk:3:CL:837:TAG1",{"ver":"1.0","id":"E9cpugMSC3i2mTcrw5m9Xk:3:CL:837:TAG1","schemaId":"837","type":"CL","tag":"TAG1","value": ...}]```But my credential schema ID is `E9cpugMSC3i2mTcrw5m9Xk:2:Number:1.0` which I don't see in the cred def ledger read response. The prefix `E9cpugMSC3i2mTcrw5m9Xk` is the same as from the cred def id not the suffix.

smithbk (Tue, 29 Oct 2019 15:28:44 GMT):
Given a credential definition ID, I need to get the credential schema ID so that I can get the schema name and version. Can someone tell me how to do this? For example, my credential definition ID is `E9cpugMSC3i2mTcrw5m9Xk:3:CL:837:TAG1` and this is what is returned when reading from the ledger: ```["E9cpugMSC3i2mTcrw5m9Xk:3:CL:837:TAG1",{"ver":"1.0","id":"E9cpugMSC3i2mTcrw5m9Xk:3:CL:837:TAG1","schemaId":"837","type":"CL","tag":"TAG1","value": ...}]```But my credential schema ID is `E9cpugMSC3i2mTcrw5m9Xk:2:Number:1.0` which I don't see in the cred def ledger read response. The prefix `E9cpugMSC3i2mTcrw5m9Xk` is the same as from the cred def id but not the suffix.

sklump (Tue, 29 Oct 2019 16:04:26 GMT):
Read transaction #837 from the ledger, parse it as a schema, and read out its "id" value.

sklump (Tue, 29 Oct 2019 16:08:11 GMT):
The cred def id includes the schema seq number if known when the issuer sends the cred def to the ledger -- the only time it won't be is if the issuer creates the schema, then creates the cred def from the schema without reading it back from the ledger to get its seq no. In the case where it isn't, the cred def id includes the schema id instead. Once a cred def id is set, all creds issued against the cred def will use that cred def id - otherwise corresponding wallet searches would be ambiguous.

magicindustries (Wed, 30 Oct 2019 09:00:57 GMT):
regarding the static ref to Mutex in commands/mod.rs, is there a way to manage this ability for everyone to share the CommandExecutor without putting the mutex in a static ref?

magicindustries (Wed, 30 Oct 2019 09:01:07 GMT):
apart from having every call make a lock on it's own?

magicindustries (Wed, 30 Oct 2019 09:01:28 GMT):
The current mechanism seems to cause a hung thread after commands have finished, which is breaking Unity where I'm calling libindy from

magicindustries (Wed, 30 Oct 2019 09:25:18 GMT):
anyone around who knows the architecture of the CommandExecutor?

Huid 1 (Wed, 30 Oct 2019 09:35:57 GMT):
Has joined the channel.

Sigisagi111 (Wed, 30 Oct 2019 13:14:25 GMT):
Has joined the channel.

Sigisagi111 (Wed, 30 Oct 2019 13:18:20 GMT):
Hi. I'm asking myself if there is a way of searching for certain matching DID in a wallet that have been requested in a proof. So a holder can proof a request for the connection to a certain other DID.

DucaDellaForcoletta (Wed, 30 Oct 2019 16:11:53 GMT):
You can search a paiwise using the paiwise list if it has been stored in the wallet, so you can retrieve the DIDs of a connection

mattatkiva (Wed, 30 Oct 2019 16:30:30 GMT):
what is the URL to indy-sdk jira backlog?

Sigisagi111 (Wed, 30 Oct 2019 17:14:26 GMT):
Do you have a link or documentation on that? Thanks for your help

sklump (Wed, 30 Oct 2019 17:21:56 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/tests/pairwise/test_get_pairwise.py No?

sklump (Wed, 30 Oct 2019 17:21:56 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/tests/pairwise/test_get_pairwise.py Do these test cases not cover it?

Sigisagi111 (Wed, 30 Oct 2019 17:36:59 GMT):
They may. I haven't looked into yet. Thanks for the link

sklump (Wed, 30 Oct 2019 17:38:48 GMT):
The libindy wrapper test cases are quite comprehensive and often the first place to look for samples.

Sigisagi111 (Wed, 30 Oct 2019 17:38:48 GMT):
That helps a lot. Thanks

Sigisagi111 (Wed, 30 Oct 2019 17:41:16 GMT):
Yes, you are absolutely right. Sometimes it's just too much to oversee especially when starting to get into a New topic

sklump (Wed, 30 Oct 2019 17:46:31 GMT):
In particular, the test under interation shows a nice long trip including (tricky) revocation.

rjones (Thu, 31 Oct 2019 10:17:32 GMT):
User User_1 added by rjones.

pedreviljoen (Thu, 31 Oct 2019 11:17:32 GMT):
Hey guys, We are trying to develop a React Native package, wrapping around the LibIndy SDK's available (iOS and Java) I am having issues with the iOS SDK, it relates to the following: https://forum.sovrin.org/t/ios-indy-sdk-image-not-found/1306 It may be an issue with the newer versions of XCode. A logic next step would be to downgrade XCode to an older version, but that may not be the best approach for a long term solution. Is there any chance a new version of the libindy-objc will be released? That is compatible with newer versions of XCode?

esplinr (Fri, 01 Nov 2019 13:51:54 GMT):
@mccown Has your team hit the issue described by @pedreviljoen ?

esplinr (Fri, 01 Nov 2019 13:53:19 GMT):
@mattatkiva https://jira.hyperledger.org/secure/RapidBoard.jspa?rapidView=149&view=planning.nodetail I believe that anyone can see it once they are logged in.

akshay.sood (Fri, 01 Nov 2019 16:44:32 GMT):
Has joined the channel.

akshay.sood (Fri, 01 Nov 2019 16:46:34 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Pa86NJyfHNxGBLpNs) @xnopre how did you install libzmq5?

mattatkiva (Mon, 04 Nov 2019 15:21:10 GMT):
I created this item: https://jira.hyperledger.org/browse/IS-1414 If I put it in the wrong jira board, please let me know. I am happy to recreate it in the correct one.

esplinr (Mon, 04 Nov 2019 17:41:29 GMT):
That is great. Thanks Matt!

nehalshah50 (Mon, 04 Nov 2019 17:51:18 GMT):
Hi, I have been getting following error when I try to use VCX Java wrapper src\api\vcx.rs:134 | Init Pool Error Error: Unknown libindy error Caused by: Error: Invalid library state Caused by: Consistency proof verification failed

nehalshah50 (Mon, 04 Nov 2019 22:12:56 GMT):
hi, i have been getting "Error Generating Proof" in my connect.me app ...anyone..any idea?

nehalshah50 (Mon, 04 Nov 2019 22:19:23 GMT):
does anyone know which version of libindy, libvcx, libnullpay works well? I am using sudo add-apt-repository "deb https://repo.sovrin.org/sdk/deb bionic stable" but keep getting errors

magicindustries (Tue, 05 Nov 2019 09:51:19 GMT):
Has anyone worked with libindy in wasm?

esplinr (Tue, 05 Nov 2019 14:56:50 GMT):
I've seen discussions of people compiling LibIndy to WASM. There was a problem with some of the dependencies.

DucaDellaForcoletta (Tue, 05 Nov 2019 15:31:43 GMT):
Hi, any news about anocred 2.0 where the tails should be removed?

nehalshah50 (Tue, 05 Nov 2019 15:53:27 GMT):
Today Connect.Me app is not able to setup connections using SMS. Anyone who can help?

esplinr (Tue, 05 Nov 2019 16:20:43 GMT):
@nehalshah50 That's a known issue which we are working to address. Evernym support can provide more details.

swcurran (Tue, 05 Nov 2019 16:35:53 GMT):
Several tech spikes have been done, but AFAIK, no focused effort to make it happen, nor have I seen documentation of roadblocks. @troyronda did a recent Aries experiment with this for the crypto needed for the Go framework. Not exactly the same as looking at Indy, but a comparable goal. He posted about his efforts on (I think) the aries channel.

esplinr (Tue, 05 Nov 2019 16:51:30 GMT):
@DucaDellaForcoletta Ursa contains the primitives for Anoncreds 2.0, but no one has yet committed to exposing them in Indy and Aries. (Not sure why RocketChat won't let me reply to the thread.)

DucaDellaForcoletta (Tue, 05 Nov 2019 16:54:16 GMT):
The tails file have bene removed in the 2.0? Any info about Plan of release?

esplinr (Tue, 05 Nov 2019 16:58:42 GMT):
The ability to use Merkel trees instead of tails files is currently present in Ursa.

esplinr (Tue, 05 Nov 2019 16:58:48 GMT):
They have not been removed from Indy yet.

esplinr (Tue, 05 Nov 2019 16:58:57 GMT):
No one has committed to do the work yet.

esplinr (Tue, 05 Nov 2019 16:59:00 GMT):
So no plans.

esplinr (Tue, 05 Nov 2019 16:59:12 GMT):
PRs are encouraged.

DucaDellaForcoletta (Tue, 05 Nov 2019 17:00:26 GMT):
Than

DucaDellaForcoletta (Tue, 05 Nov 2019 17:01:37 GMT):
Thanks so much

esplinr (Tue, 05 Nov 2019 17:03:08 GMT):
@sergey.minaev is the architected that. He documented it here: https://github.com/hyperledger/indy-sdk/blob/master/docs/architecture/libindy_layers.md

esplinr (Tue, 05 Nov 2019 17:03:32 GMT):
This is also helpful: https://github.com/hyperledger/indy-sdk/tree/master/docs/design/012-libindy-architecture-overview

esplinr (Tue, 05 Nov 2019 17:03:52 GMT):
And: https://github.com/hyperledger/indy-sdk/blob/master/docs/how-tos/how-to-add-a-new-API-call.md

esplinr (Tue, 05 Nov 2019 17:05:55 GMT):
cc @sergey.minaev @Artemkaaas

esplinr (Tue, 05 Nov 2019 17:12:28 GMT):
cc @sergey.minaev @Artemkaaas

swcurran (Tue, 05 Nov 2019 17:17:14 GMT):
Checked - it was in the aries-sdk channel.

Sigisagi111 (Tue, 05 Nov 2019 17:29:13 GMT):
If I understood correctly, then Sovrin is the Framework, the governance of the Blockchain/Hyperledger, whereas Indy is the concrete technology behind it. Is this a differentiation that you would except? If yes, and one asked me what is the Blockchain, should I answer "Sovrin" or "Indy"?

Sigisagi111 (Tue, 05 Nov 2019 17:29:52 GMT):
*accept

daidoji (Tue, 05 Nov 2019 17:40:15 GMT):
@Sigisagi111 The Ledger is Sovrin an instantiation of Hyperledger-Indy is how I would put it

daidoji (Tue, 05 Nov 2019 17:41:01 GMT):
However, there could be other instantiations of Hyperledger-Indy in the future

Sigisagi111 (Tue, 05 Nov 2019 17:55:10 GMT):
Thats the other way round. So confusing...

daidoji (Tue, 05 Nov 2019 18:00:10 GMT):
@Sigisagi111 what are you confused about?

daidoji (Tue, 05 Nov 2019 18:00:33 GMT):
Sovrin is a ledger governed by a "governing framework" that is an instantiation of the Hyperledger-Indy project

daidoji (Tue, 05 Nov 2019 18:01:07 GMT):
the governing framework establishes a nonprofit foundation which manages the framework and arbitrates within that framework

daidoji (Tue, 05 Nov 2019 18:01:22 GMT):
there are a lot of moving parts that are all named similarly though I'll give you that

daidoji (Tue, 05 Nov 2019 18:01:49 GMT):
note the ledger is an instantiation of Hyperledger-Indy not the governing framework

daidoji (Tue, 05 Nov 2019 18:02:13 GMT):
you could spin up your own Indy chain today and govern however you see fit

Sigisagi111 (Tue, 05 Nov 2019 18:04:22 GMT):
Confusing is that some say Indy is the chain and some say sovrin. In Addition in the Definition of DIDs the scheme Part Shows "sov" which defines on which chain it is.

donqui (Tue, 05 Nov 2019 18:10:47 GMT):
I think it depends on what you want to say. I see it like this, other may see it differently: Sovrin is a philosophy. It defines how identity should be managed, what a wallet is, who the participants are, the idea of reputability, it is opinionated about crypto, ZKPs and how things are proved, it is worried about correlation and defines flows that protect you from it... The governance is shaped by that philosophy, and the underlying tech is chosen with it in mind. Indy-Node (identity layer) and Indy-Plenum (general ledger) and represent a blockchain/DLT technology stack that allows Sovrin to make their philosophy a reality, by converting it into a real deployment of a network that people can use. Sovrin may switch to a new ledger tomorrow, but the principles will stay the same. Indy stack can be deployed by someone else, but it does not need to follow the same set of rules as a Sovrin deployment. I think the answer should depend on if you are wanting to say that you are using a network with it's rules and a philosophy, or a if you want to specify the underlying technology.

donqui (Tue, 05 Nov 2019 18:10:47 GMT):
I think it depends on what you want to say. I see it like this, other may see it differently: Sovrin is a philosophy. It defines how identity should be managed, what a wallet is, who the participants are, the idea of reputability, it is opinionated about crypto, ZKPs and how things are proved, it is worried about correlation and defines flows that protect you from it... The governance is shaped by that philosophy, and the underlying tech is chosen with it in mind. Indy-Node (identity layer) and Indy-Plenum (general ledger) represent a blockchain/DLT technology stack that allows Sovrin to make their philosophy a reality, by converting it into a real deployment of a network that people can use. Sovrin may switch to a new ledger tomorrow, but the principles will stay the same. Indy stack can be deployed by someone else, but it does not need to follow the same set of rules as a Sovrin deployment. I think the answer should depend on if you are wanting to say that you are using a network with it's rules and a philosophy, or a if you want to specify the underlying technology.

donqui (Tue, 05 Nov 2019 18:10:47 GMT):
I think it depends on what you want to say. I see it like this, other may see it differently: Sovrin is a philosophy. It defines how identity should be managed, what a wallet is, who the participants are, the idea of reputability, it is opinionated about crypto, ZKPs and how things are proved, it is worried about correlation and defines flows that protect you from it... The governance is shaped by that philosophy, and the underlying tech is chosen with it in mind. Indy-Node (identity layer) and Indy-Plenum (general ledger) and Indy-SDK represent a blockchain/DLT technology stack that allows Sovrin to make their philosophy a reality, by converting it into a real deployment of a network that people can use. Sovrin may switch to a new ledger tomorrow, but the principles will stay the same. Indy stack can be deployed by someone else, but it does not need to follow the same set of rules as a Sovrin deployment. I think the answer should depend on if you are wanting to say that you are using a network with it's rules and a philosophy, or a if you want to specify the underlying technology.

Sigisagi111 (Tue, 05 Nov 2019 18:14:33 GMT):
Thank you so much. This is a Sound answer. I like this Chat very much. Finaly one Chat that helps people without mocking one all the time for things one doesn't know.

magicindustries (Wed, 06 Nov 2019 10:16:43 GMT):
Thanks for that, I'll look it up

magicindustries (Wed, 06 Nov 2019 10:18:19 GMT):
Thanks!

magicindustries (Wed, 06 Nov 2019 11:26:53 GMT):
@sergey.minaev if you have time I'd love to chat to you about this. There's a threading issues caused when we call libindy from Unity, and we tracked it as far as the mutex lock in the CommandExecutor. I've been trying to learn enough Rust to come up with an acceptable alternative to the lazy static just to see if that's the problem

magicindustries (Wed, 06 Nov 2019 11:30:30 GMT):
Am I right in thinking the Rust wrapper in indy-sdk is an example for essentially writing bolt-ons or other forms of wrappers?

sergey.minaev (Wed, 06 Nov 2019 12:16:56 GMT):
hi @magicindustries , AFAIR for this particular case you have to specify lifetime of the mutex in the result so it just peak the lifetime of the reference to call the function

sergey.minaev (Wed, 06 Nov 2019 12:16:56 GMT):
hi @magicindustries , AFAIR for this particular case you have to specify lifetime of the mutex in the result so it just peaks the lifetime of the reference to call the function

sergey.minaev (Wed, 06 Nov 2019 12:18:37 GMT):
could you describe the case in more detail. I didn't get the point. Fill free to DM me

nehalshah50 (Wed, 06 Nov 2019 19:10:35 GMT):
how do i get the specific version of libindy,libvcx & libnullpay for Ubuntu? I am using following command and would like to get v1.8.1 add-apt-repository "deb c bionic stable" && \ apt-get update && \ apt-get install -y libindy libnullpay libvcx

nehalshah50 (Wed, 06 Nov 2019 19:10:35 GMT):
how do i get the specific version of libindy,libvcx & libnullpay for Ubuntu? I am using following command and would like to get v1.8.1 add-apt-repository "deb https://repo.sovrin.org/sdk/deb bionic stable" && \ apt-get update && \ apt-get install -y libindy libnullpay libvcx

donqui (Wed, 06 Nov 2019 19:28:35 GMT):
you need to specify the version in apt: `apt-get install -y libindy=1.8.1 libnullpay libvcx`

nehalshah50 (Wed, 06 Nov 2019 19:37:24 GMT):
i tried but it doesn't work. What should be the repository URL?

donqui (Wed, 06 Nov 2019 19:40:02 GMT):
what is the error?

nehalshah50 (Wed, 06 Nov 2019 19:40:12 GMT):
library not found

nehalshah50 (Wed, 06 Nov 2019 19:40:39 GMT):
i want 1.8.1 for libindy and libnull and 0.4.2 for libvcx

nehalshah50 (Wed, 06 Nov 2019 19:40:54 GMT):
it seems to be finding libvcx but not others

donqui (Wed, 06 Nov 2019 19:41:59 GMT):
could you paste the full output of apt

nehalshah50 (Wed, 06 Nov 2019 19:44:37 GMT):
i am doing docker build. Here is the docker file FROM adoptopenjdk/openjdk11 USER root ARG LIB_INDY_VERSION ARG LIB_VCX_VERSION=0.4.2 RUN apt-get -y update # install sovrin indy-sdk build dependencies RUN apt-get install -y --no-install-recommends gnupg dirmngr software-properties-common apt-transport-https git-core && \ apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CE7709D068DB5E88 RUN add-apt-repository "deb https://repo.sovrin.org/sdk/deb bionic stable" && \ apt-get update && \ apt-get install -y libindy=${LIB_INDY_VERSION} libnullpay=${LIB_INDY_VERSION} libvcx=${LIB_VCX_VERSION} WORKDIR /apps ENTRYPOINT ["sh"]

nehalshah50 (Wed, 06 Nov 2019 19:46:07 GMT):
error is E: Version '1.8.1' for 'libindy' was not found E: Version '1.8.1' for 'libnullpay' was not found The command '/bin/sh -c add-apt-repository "deb https://repo.sovrin.org/sdk/deb bionic stable" && apt-get update && apt-get install -y libindy=${LIB_INDY_VERSION} libnullpay=${LIB_INDY_VERSION} libvcx=${LIB_VCX_VERSION}' returned a non-zero code: 100

nehalshah50 (Wed, 06 Nov 2019 19:46:28 GMT):
libvcx pulls fine

nehalshah50 (Wed, 06 Nov 2019 19:47:54 GMT):
it seems 1.8.1 is not available at repo : https://repo.sovrin.org/sdk/deb bionic stable

nehalshah50 (Wed, 06 Nov 2019 19:49:37 GMT):
looking at here https://repo.sovrin.org/sdk/lib/apt/bionic/stable/ it has only 1.11.1 and 1.12.0

donqui (Wed, 06 Nov 2019 19:50:29 GMT):
I think support for bionic was introduced after version 1.8.1 so that package is not available ther> And I think you are trying to install incompatible versions f libvcx and libindy ```─ $ ▶ apt show libvcx=0.4.2 Package: libvcx Version: 0.4.2 Priority: extra Section: devel Maintainer: Hyperledger Installed-Size: 9830 kB Depends: libindy (= 1.12.0) ```

donqui (Wed, 06 Nov 2019 19:50:29 GMT):
I think support for bionic was introduced after version 1.8.1 so that package is not available there because of that And I think you are trying to install incompatible versions f libvcx and libindy ```─ $ ▶ apt show libvcx=0.4.2 Package: libvcx Version: 0.4.2 Priority: extra Section: devel Maintainer: Hyperledger Installed-Size: 9830 kB Depends: libindy (= 1.12.0) ```

donqui (Wed, 06 Nov 2019 19:50:29 GMT):
I think support for bionic was introduced after version 1.8.1 so that package is not available there because of that And I think you are trying to install incompatible versions of libvcx and libindy ```─ $ ▶ apt show libvcx=0.4.2 Package: libvcx Version: 0.4.2 Priority: extra Section: devel Maintainer: Hyperledger Installed-Size: 9830 kB Depends: libindy (= 1.12.0) ```

donqui (Wed, 06 Nov 2019 19:50:45 GMT):
I do not have bionic, so I cannot test that for you

nehalshah50 (Wed, 06 Nov 2019 19:51:14 GMT):
ok..np

nehalshah50 (Wed, 06 Nov 2019 19:51:54 GMT):
which libvcx version works for 1.8.1 of libindy?

magicindustries (Wed, 06 Nov 2019 20:28:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=4mdDym7c22xhgPbpx) perfect, thank you

kdenhartog (Wed, 06 Nov 2019 23:12:36 GMT):
The anoncrypt/authcrypt APIs were deperecated because it's not possible to detect if the message was auth or anoncrypted as the recipient of the message. I'd suggest using the pack/unpack APIs instead.

nehalshah50 (Thu, 07 Nov 2019 00:56:50 GMT):
Does anyone have any example of sending an image in the credential?

pwalimbe (Thu, 07 Nov 2019 04:36:52 GMT):
Has left the channel.

conanoc (Thu, 07 Nov 2019 06:18:54 GMT):
Has joined the channel.

DibbsZA (Thu, 07 Nov 2019 09:15:20 GMT):
EVERYONE here didn't know things in the beginning and it's only right that we help each other on the journey. Glad to have you here

lohan.spies (Thu, 07 Nov 2019 18:33:36 GMT):
Maybe this might be of some help as well https://github.com/Patrik-Stas/indyjump

MikaLindela (Fri, 08 Nov 2019 12:36:47 GMT):
Has joined the channel.

MikaLindela (Fri, 08 Nov 2019 12:45:53 GMT):
hi, is there an example available on an android implementation that uses 1.12.0 version of libindy? or should I just switch to an older version?

gordon_hkpkiforum (Mon, 11 Nov 2019 10:30:19 GMT):
Has joined the channel.

conanoc (Tue, 12 Nov 2019 03:34:31 GMT):
Is there any API documents for libIndy? I can see there is indy_create_pool_ledger_config() function in indy_pool.h, but there are no comments for the function. There seems no API documents for Indy SDKs exist in general. Right?

bansatya (Tue, 12 Nov 2019 07:10:55 GMT):
Has joined the channel.

knagware9 (Tue, 12 Nov 2019 07:35:21 GMT):
Has joined the channel.

donqui (Tue, 12 Nov 2019 11:25:30 GMT):
There usually are comments, but not in all of the places. Hre I think the comments are at the place where the implementation lives: https://github.com/hyperledger/indy-sdk/blob/9ac08096cd92c792e2b8be44be098493e26a1b05/libindy/src/api/pool.rs

JeromeK (Tue, 12 Nov 2019 15:37:08 GMT):
Hey Guys I'm currently working with the Sovrin-Builder-Network -> I create a Schema, which I want now to use in Cred-Def but I get the following error: `{'reqId': 1573572629275836000, 'identifier': 'E8tg4FWVUhTNExPt8ARreB', 'reason': "client request invalid: InvalidClientTaaAcceptanceError('Txn Author Agreement acceptance is required for ledger with id 1',)", 'op': 'REJECT'}` Any fixes? `async def create_cred_def(wh: int, did: str, ph: int): schema_id = 'E8tg4FWVUhTNExPt8ARreB:2:labor:1.0' build_get_schema_request = await Ledger.get_schema_request(sender_did="", schema_id=schema_id) get_schema_response = await Ledger.submit_request(pool_handle=ph, request=build_get_schema_request) schema_id, schema = await Ledger.parse_get_schema_response(get_schema_response) print(schema) credential_def_id, credential_def = await Anoncreds.create_credential_definition(wallet_handle=wh, cred_def_did=did, cred_def_schema=schema, cred_def_tag='lab2', cred_def_type='', cred_def_type_config={ "support_revocation": False}) print(credential_def_id, credential_def) build_credential_definition_request = await Ledger.cred_def_request(sender_did=did, cred_def_data=credential_def) definition_response = await Ledger.sign_and_submit_request(pool_handle=ph, wallet_handle=wh, signing_did=did, request=build_credential_definition_request) return definition_response`

JeromeK (Tue, 12 Nov 2019 15:37:46 GMT):
Code Here: `async def create_cred_def(wh: int, did: str, ph: int): schema_id = 'E8tg4FWVUhTNExPt8ARreB:2:labor:1.0' build_get_schema_request = await Ledger.get_schema_request(sender_did="", schema_id=schema_id) get_schema_response = await Ledger.submit_request(pool_handle=ph, request=build_get_schema_request) schema_id, schema = await Ledger.parse_get_schema_response(get_schema_response) print(schema) credential_def_id, credential_def = await Anoncreds.create_credential_definition(wallet_handle=wh, cred_def_did=did, cred_def_schema=schema, cred_def_tag='lab2', cred_def_type='', cred_def_type_config={ "support_revocation": False}) print(credential_def_id, credential_def) build_credential_definition_request = await Ledger.cred_def_request(sender_did=did, cred_def_data=credential_def) definition_response = await Ledger.sign_and_submit_request(pool_handle=ph, wallet_handle=wh, signing_did=did, request=build_credential_definition_request)`

eduelias (Tue, 12 Nov 2019 15:59:51 GMT):
Has joined the channel.

conanoc (Wed, 13 Nov 2019 02:20:01 GMT):
Thanks. I didn't expect the comments of the functions were written in the source files not header files.

VenkateshSorapalli (Wed, 13 Nov 2019 08:24:42 GMT):
How to generate multiple wallets for single agent ? Is this possible or not?

JeromeK (Wed, 13 Nov 2019 08:28:43 GMT):
Are you using aries?

VenkateshSorapalli (Wed, 13 Nov 2019 08:28:54 GMT):
No

JeromeK (Wed, 13 Nov 2019 08:29:53 GMT):
Yes in my opinion its possible - Just name the wallets and back that idea with your business logic

VenkateshSorapalli (Wed, 13 Nov 2019 08:30:48 GMT):
Is there any example for multiple wallet generation for a single agent

VenkateshSorapalli (Wed, 13 Nov 2019 08:30:48 GMT):
Is there any example to generate multiple wallets for a single agent

JeromeK (Wed, 13 Nov 2019 08:33:40 GMT):
Well you can just loop the creation if you already know how many wallets you need with names etc

JeromeK (Wed, 13 Nov 2019 08:34:16 GMT):
or provide some endpoints to create wallets

VenkateshSorapalli (Wed, 13 Nov 2019 08:35:54 GMT):
I didn't get you what exactly you are talking about

JeromeK (Wed, 13 Nov 2019 08:37:29 GMT):
Okay let me try to wrap it up :P As far as i know, there is currently no function in Indy to create multiple Wallets with one call. So you would need to loop that creation if you want to create more than one wallet.

VenkateshSorapalli (Wed, 13 Nov 2019 08:39:08 GMT):
If we create multiple wallets, then how transactions are validated, how they come to know is this transaction is done by this wallet or not?

JeromeK (Wed, 13 Nov 2019 08:39:45 GMT):
you always need to open the wallet which results in a wallet_handle to identify the wallet your currently using

VenkateshSorapalli (Wed, 13 Nov 2019 08:40:48 GMT):
Okk

JeromeK (Wed, 13 Nov 2019 08:41:06 GMT):
https://github.com/hyperledger/education/blob/master/LFS171x/docs/introduction-to-hyperledger-indy.md#agents-and-wallets

JeromeK (Wed, 13 Nov 2019 08:41:15 GMT):
maybe this can help you

VenkateshSorapalli (Wed, 13 Nov 2019 08:41:57 GMT):
Ok

JeromeK (Wed, 13 Nov 2019 08:52:00 GMT):
:thumbsup:

JeromeK (Wed, 13 Nov 2019 09:12:43 GMT):
Does anybody (on Mac) also expierence this Error `AttributeError: dlsym(0x7f88a7d798e0, indy_build_get_txn_author_agreement_request): symbol not found` when trying to call `txn_auth = await indy.ledger.build_get_txn_author_agreement_request('', '')`?

JeromeK (Wed, 13 Nov 2019 09:13:13 GMT):
* I have build Libindy 2 days ago

JeromeK (Wed, 13 Nov 2019 09:13:13 GMT):
* I build Libindy 2 days ago

JeromeK (Wed, 13 Nov 2019 09:13:13 GMT):
* I built Libindy 2 days ago

ayushmanss (Wed, 13 Nov 2019 13:35:31 GMT):
Has joined the channel.

ayushmanss (Wed, 13 Nov 2019 13:35:33 GMT):
Hi all, I am new to hyperledger projects and wanted to use indy. I have a mac and tried to install the sdk but couldn't start the cli. It says

ayushmanss (Wed, 13 Nov 2019 13:35:36 GMT):
└─> ./indy-cli dyld: Library not loaded: /Users/jenkins/workspace/indy-sdk_indy-sdk-cd_rc/libindy/target/release/deps/libindy.dylib

ayushmanss (Wed, 13 Nov 2019 13:36:06 GMT):
I followed the steps to download all stable builds and updated the LIBRARY_PATH accordingly

ayushmanss (Wed, 13 Nov 2019 13:36:39 GMT):
but it seems the cli points to some other location for libindy binary

ayushmanss (Wed, 13 Nov 2019 13:36:56 GMT):
can someone help as to how to run the given alice example

ayushmanss (Wed, 13 Nov 2019 13:38:09 GMT):
I dont know if this is the right platform to asks such question. If not, can someone point me in the right direction

donqui (Wed, 13 Nov 2019 13:54:17 GMT):
I must preface I do not use mac and haven't tried running this myself, but a error like this smells like the library that is loaded does not have the symbols the wrapper is trying to link and use. On my machine I can check if the lib contains such a symbol by doing something like this: ``` └─ $ ▶ readelf -Ws libindy.so | grep indy_build_get_txn_author_agreement_request 314: 00000000004cc850 4018 FUNC GLOBAL DEFAULT 11 indy_build_get_txn_author_agreement_request ```

donqui (Wed, 13 Nov 2019 13:54:17 GMT):
I must preface I do not use mac and haven't tried running this myself, but an error like this smells like the library that is loaded does not have the symbols the wrapper is trying to link and use. On my machine I can check if the lib contains such a symbol by doing something like this: ``` └─ $ ▶ readelf -Ws libindy.so | grep indy_build_get_txn_author_agreement_request 314: 00000000004cc850 4018 FUNC GLOBAL DEFAULT 11 indy_build_get_txn_author_agreement_request ```

donqui (Wed, 13 Nov 2019 13:54:50 GMT):
Are you sure you are loading the freshly built version of libindy and not some older version that is hiding somewhere on your system?

ianco (Wed, 13 Nov 2019 17:55:46 GMT):
It looks like you have an old version of libindy installed. This method "indy_build_get_txn_author_agreement_request" was added relatively recently, I don't know the version offhand ...

ianco (Wed, 13 Nov 2019 17:56:23 GMT):
Find your libindy.dylib, delete it, and then install the most recent version

ianco (Wed, 13 Nov 2019 18:02:05 GMT):
Rather than update LIBRARY_PATH (I think it's actually LD_LIBRARY_PATH or DYLD_LIBRARY_PATH on a mac) just link your library as follows: `ln -s /usr/local/lib/libindy.dylib` ... this will create a sym link in your

lynn.bendixsen (Wed, 13 Nov 2019 18:16:33 GMT):
You might be missing the `LIBINDY_DIR` env variable

JeromeK (Thu, 14 Nov 2019 08:25:07 GMT):
Hey Guys Thanks for the Helo but sadly it didnt fixed my problem here all the needed Infos OS: macOS Mojave 10.14.6 Libindy: `Compiling libindy v1.12.0 (/Users/jerome/Documents/GitHub/indy-sdk/libindy)` ENV: `export LIBRARY_PATH=/Users/jerome/Documents/GitHub/indy-sdk/libindy/target/debug/libindy.dylib`

JeromeK (Thu, 14 Nov 2019 08:25:07 GMT):
Hey Guys Thanks for the Help but sadly it didn't fix my problem here all the needed Infos OS: macOS Mojave 10.14.6 Libindy: `Compiling libindy v1.12.0 (/Users/jerome/Documents/GitHub/indy-sdk/libindy)` ENV: `export LIBRARY_PATH=/Users/jerome/Documents/GitHub/indy-sdk/libindy/target/debug/libindy.dylib`

JeromeK (Thu, 14 Nov 2019 08:25:43 GMT):
I have build a new Libindy logs can be seen in the next post

JeromeK (Thu, 14 Nov 2019 08:26:07 GMT):

JeromeK - Thu Nov 14 2019 09:26:01 GMT+0100 (Mitteleuropäische Normalzeit).txt

JeromeK (Thu, 14 Nov 2019 08:29:08 GMT):
Also the Cargo.toml locks correct

JeromeK (Thu, 14 Nov 2019 08:29:08 GMT):
Also the Cargo.toml looks correct

JeromeK (Thu, 14 Nov 2019 08:29:35 GMT):

Cargo Kopie.txt

JeromeK (Thu, 14 Nov 2019 08:38:43 GMT):

Symbol-Log for Libindy

JeromeK (Thu, 14 Nov 2019 08:38:55 GMT):
here you can find my Symbol-Log i did on the new libindy

JeromeK (Thu, 14 Nov 2019 08:39:15 GMT):
`000000000041d170 T _indy_build_get_txn_author_agreement_request``

JeromeK (Thu, 14 Nov 2019 08:39:21 GMT):
so its does exist

JeromeK (Thu, 14 Nov 2019 08:39:43 GMT):
but it does not reference the same pointer? dlsym(0x7f875fc81230, indy_build_get_txn_author_agreement_request):

donqui (Thu, 14 Nov 2019 08:56:48 GMT):
can you place a ```x = input()``` before the line in question, and do a ```lsof -p $PID``` to see if the correct library has been loaded.

donqui (Thu, 14 Nov 2019 08:56:48 GMT):
can you place a `x = input()` before the line in question, and do a `lsof -p $PID` to see if the correct library has been loaded.

donqui (Thu, 14 Nov 2019 08:58:00 GMT):
if it is the right one, maybe there is a mismatch between the wrapper and the library itself; incompatible versions or something

JeromeK (Thu, 14 Nov 2019 09:21:30 GMT):
yes thank you very much @donqui I have found the error

JeromeK (Thu, 14 Nov 2019 09:21:51 GMT):
i had an old-version of libindy in my /usr/local/lib folder

JeromeK (Thu, 14 Nov 2019 09:22:00 GMT):
i just replaced it and now it works

eduelias (Thu, 14 Nov 2019 09:39:47 GMT):
Hello, I've asked this at the Indy channel but got no "usable" answers. I need to access/export the private keys from the wallet. I'm trying to make the "did list" CLI command return the private keys but I'm still failing. Can anyone help me? The reason is that we're trying to make it possible to use the Private Keys for other purposes, like SSH auth and those kind of stuff.

JeromeK (Thu, 14 Nov 2019 09:49:43 GMT):
Are you talking about the verkeys oder the key to access the wallet?

JeromeK (Thu, 14 Nov 2019 09:49:43 GMT):
Are you talking about the verkeys or the key to access the wallet?

eduelias (Thu, 14 Nov 2019 09:50:11 GMT):
No, the private key that generates the public key and the verkey

dkushagra (Thu, 14 Nov 2019 09:51:17 GMT):
I am trying to write a create a schema and store it on the ledger. I am successful in doing this. But if someone tries to fetch the schema following error is shown : - ```org.hyperledger.indy.sdk.pool.LedgerNotFoundException: Item not found on ledger exception``` . I am being stuck at it and have no clue to solve it, any help or suggestion is welcomed .

eduelias (Thu, 14 Nov 2019 09:51:31 GMT):
You see, when you send a NYM, you need to encrypt the message with your private key, so the ledger will accept your transaction as being yours. This is done by indy-sdk. What I want it's this private key.

JeromeK (Thu, 14 Nov 2019 09:55:33 GMT):
if I understand this correctly you can generate your DID and Verkey out of a SEED

JeromeK (Thu, 14 Nov 2019 09:57:31 GMT):
So your DID and verkey are generated by a random SEED, if you dont define it

JeromeK (Thu, 14 Nov 2019 10:01:40 GMT):
maybe you will find something here

JeromeK (Thu, 14 Nov 2019 10:01:41 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/indy/crypto.py

JeromeK (Thu, 14 Nov 2019 10:05:21 GMT):
Hey You could use the CLI to create and get schemas

JeromeK (Thu, 14 Nov 2019 10:06:43 GMT):
or maybe check the schema_id -> could be a typo

JeromeK (Thu, 14 Nov 2019 10:07:43 GMT):
and did you submit the request to the ledger with Ledger.sign_and_submit_request ?

JeromeK (Thu, 14 Nov 2019 10:08:40 GMT):
So what im doing is the following: Anoncred.create_schema Ledger.schema_request Ledger.sign_and_submit_request

JeromeK (Thu, 14 Nov 2019 10:08:40 GMT):
So what im doing is the following: Anoncred.create_schema() Ledger.schema_request() Ledger.sign_and_submit_request()

eduelias (Thu, 14 Nov 2019 10:11:58 GMT):
Yeah ... that's not a private key. If you don't provide any seed, the indy-sdk generate a seedless private key for you. And this PK will be stored inside your wallet. And I really understand that it's quite hard to get those privkeys back.

eduelias (Thu, 14 Nov 2019 10:16:07 GMT):
Yeah, the code you've shown it's the starting point of what I need but, when you go deep inside the sdk's code, I got lost on HOW those PKs are stored. If you wanna understand where I am, I'm tampering with this function (https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/commands/did.rs#L307) to return the private keys from each did, now.

JeromeK (Thu, 14 Nov 2019 10:41:23 GMT):
Okay the last thing i could suggest would be to have a look at the storage https://github.com/hyperledger/indy-sdk/blob/9ac08096cd92c792e2b8be44be098493e26a1b05/libindy/indy-wallet/src/storage/default/mod.rs#L48

JeromeK (Thu, 14 Nov 2019 10:41:23 GMT):
Okay the last thing I could suggest would be to have a look at the storage https://github.com/hyperledger/indy-sdk/blob/9ac08096cd92c792e2b8be44be098493e26a1b05/libindy/indy-wallet/src/storage/default/mod.rs#L48

JeromeK (Thu, 14 Nov 2019 10:41:40 GMT):
maybe this could help

eduelias (Thu, 14 Nov 2019 10:42:12 GMT):
Yeah! :D That's what I'm talking about! Now we're on the same page! :D Thanks man! I'll give it a try!

JeromeK (Thu, 14 Nov 2019 10:42:25 GMT):
Np, let me updated

JeromeK (Thu, 14 Nov 2019 10:43:48 GMT):
@eduelias https://github.com/hyperledger/indy-sdk/blob/9ac08096cd92c792e2b8be44be098493e26a1b05/libindy/indy-wallet/src/storage/default/mod.rs#L333

eduelias (Thu, 14 Nov 2019 10:48:32 GMT):
Ouch, sorry, I'm looking here, the one you've sent its PRIMARY key, not private key ... heehhe the second link it's more close to it ... if you wanna understand, the value I need is here: https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/services/crypto/mod.rs#L151

dkushagra (Thu, 14 Nov 2019 10:52:25 GMT):
Thanks Jerome for responding Yes, I have done all the three steps and got no error in them , yet I am skeptical about ledger. Can you help me in using CLI to create and get schemas? I think I must find a way to see my ledger .

JeromeK (Thu, 14 Nov 2019 11:41:32 GMT):
Here is a tutorial from sovrin where they also show how to interact with the ledger (schema creation etc.) through the cli https://zoom.us/recording/play/cAGYJPUH-2CF2kglfhHq3idRA0Yio-El_cgmVlupMBmoKM2XVTYufewqfUYrdj7i?continueMode=true

JeromeK (Thu, 14 Nov 2019 11:41:52 GMT):
this should answer your question and you should be able to apply it to your network

JeromeK (Thu, 14 Nov 2019 11:53:01 GMT):
ups :sweat_smile: Okay, thanks I will open my eyes for that but i think its a really tricky task you want to solve - cya

JeromeK (Thu, 14 Nov 2019 11:53:01 GMT):
ups :sweat_smile: Okay, thanks I will open my eyes for that but I think its a really tricky task you want to solve - good luck

eduelias (Thu, 14 Nov 2019 11:54:05 GMT):
yeah ... I know ... not being a Rust programmer it's not helping at all. As soon as I figure it out, I'll let you know! Thanks for your attention and help! :D

dkushagra (Thu, 14 Nov 2019 13:12:15 GMT):
Thanks a lot for the link !! Will look into it

dkushagra (Thu, 14 Nov 2019 13:19:11 GMT):
Is there anything other than indy-cli , which would enable me to connect with the ledger ?

JeromeK (Thu, 14 Nov 2019 13:20:18 GMT):
well your sdk with the genesis.txn :P

JeromeK (Thu, 14 Nov 2019 13:20:18 GMT):
well your sdk-code with the genesis.txn :P

bansatya (Thu, 14 Nov 2019 13:20:56 GMT):
@dkushagra , You can use libvcx or indy sdk to create schema and fetch from ledger

dkushagra (Thu, 14 Nov 2019 13:23:45 GMT):
@JeromeK Where is this genesis.txn present?

dkushagra (Thu, 14 Nov 2019 13:26:10 GMT):
@bansatya I have created and written schema on the ledger. But I am unable to fetch it. I was searching for tools to check if the schema is actually written on the ledger.

bansatya (Thu, 14 Nov 2019 13:28:47 GMT):
One option is Indy-cli and another to use schema look up to get it from ledger

dkushagra (Thu, 14 Nov 2019 13:30:11 GMT):
How can I use schema look up option?

bansatya (Thu, 14 Nov 2019 13:33:52 GMT):
Please refer vcx api

dkushagra (Thu, 14 Nov 2019 13:34:24 GMT):
Thanks a lot @bansatya

domwoe (Thu, 14 Nov 2019 15:06:00 GMT):
Has joined the channel.

Jack1477 (Thu, 14 Nov 2019 17:19:07 GMT):
Where does Libindy save configuration file created with createPoolLedgerConfig() ?

donqui (Thu, 14 Nov 2019 18:22:57 GMT):
My guess would be here `~/.indy_client/pool/pool_name_*`

donqui (Thu, 14 Nov 2019 18:22:57 GMT):
My guess would be here `~/.indy_client/pool/pool_name_*/config.json`

donqui (Thu, 14 Nov 2019 18:22:57 GMT):
My guess would be here `~/.indy_client/pool/pool_name_*/`

Jack1477 (Thu, 14 Nov 2019 18:43:26 GMT):
Yes, you are right. Thank you

domwoe (Thu, 14 Nov 2019 19:35:49 GMT):
Is it correct that the indy-sdk is verify the pool ledger from genesis to current state? Then, given the current list of nodes, how are responses to requests (say give me this did document) verified? Are multiple nodes asked? Does the indy-sdk keep track of the merkle root and ask for inclusion proofs? Can you point me also to the code where I can reproduce what's happening?

bansatya (Fri, 15 Nov 2019 15:01:03 GMT):
HI , I am trying to build a VCX server which will expose REST endpoints. Can I build multiple agents using same VCX server? I am using dummy cloud agent for communication between agents.

PatrikStas (Fri, 15 Nov 2019 15:16:57 GMT):
@bansatya VCX is "stateful", what I mean is that when you are using VCX you have to call some `init` function a specify what wallet shall be used. So within the same process, you can't manage multiple vcx wallets. Actually you could, but that would scale very badly (you could free all VCX resources and reinitialize VCX for different wallet (agent) ). So instead you might build vcx application representing single agent only and have them running on separate ports? Or I can imagine building a wrapper server around this which would create some abstraction around managing these processes so you could deal with agent names instead of ports

PatrikStas (Fri, 15 Nov 2019 15:16:57 GMT):
@bansatya VCX is "stateful", what I mean is that when you are using VCX you have to call some `init` function a specify what wallet shall be used (and some information about the initialized VCX wallet/agent is then maintaned in memory). So within the same process, you can't manage multiple vcx wallets. Actually you could, but that would scale very badly (you could free all VCX resources and reinitialize VCX for different wallet (agent) ). So instead you might build vcx application representing single agent only and have them running on separate ports? Or I can imagine building a wrapper server around this which would create some abstraction around managing these processes so you could deal with agent names instead of ports

bansatya (Fri, 15 Nov 2019 15:22:49 GMT):
@PatrikStas, Thanks a lot.

bansatya (Fri, 15 Nov 2019 15:26:56 GMT):
Can we achieve something more out of libvcx if we use aries agent ( supported now, I believe) ?

PatrikStas (Fri, 15 Nov 2019 15:32:01 GMT):
@bansatya the aries part of vcx mean that it will talk bit different language but as far as I know the core architecture of the library stays as is

PatrikStas (Fri, 15 Nov 2019 15:36:33 GMT):
correct me if I am wrong - you want to build API which will enable you to create multiple agents right? What's your use case? Do you want different actors to create their own agents on this via the API?

bansatya (Fri, 15 Nov 2019 15:37:33 GMT):
yes,

bansatya (Fri, 15 Nov 2019 15:38:18 GMT):
Each will have separate DID in the ledger

bansatya (Fri, 15 Nov 2019 15:38:50 GMT):
However, they will use same vcx server

PatrikStas (Fri, 15 Nov 2019 15:40:05 GMT):
how many do you think you there might be?

bansatya (Fri, 15 Nov 2019 15:41:51 GMT):
to start with, it may be 5 , but down the line it might be more than 100

bansatya (Fri, 15 Nov 2019 15:45:45 GMT):
so, as per current architecture, we need to host 5 server in different 5 ports for 5 agents?

bansatya (Fri, 15 Nov 2019 15:45:45 GMT):
Constant shut down and initialize will have impact in performance also.

PatrikStas (Fri, 15 Nov 2019 15:48:46 GMT):
well that's I think one of the simple ways to do it right now. The bottom line is you need separate processes (Or maybe separate threads would be enough? I don't know, never tried) to avoid constant VCX shutdowns are re-initializations

PatrikStas (Fri, 15 Nov 2019 15:55:57 GMT):
Basically this is the issue: https://github.com/hyperledger/indy-sdk/blob/master/vcx/libvcx/src/settings.rs There's this whole bunch of data stored in memory of process which call vcx init. If we could somewhat abstract this out, I think VCX could then support multiple agents. But that would be I suppose quite big change. Also I don't know what other issue there might be, I am only a user of VCX myself. So maybe there's better solutions to this issue I am not aware of

PatrikStas (Fri, 15 Nov 2019 15:55:57 GMT):
Basically this is the issue https://github.com/hyperledger/indy-sdk/blob/master/vcx/libvcx/src/settings.rs There's this whole bunch of data stored in memory of process which call vcx init. If we could somewhat abstract this out, I think VCX could then support multiple agents. But that would be I suppose quite big change. Also I don't know what other issue there might be, I am only a user of VCX myself. So maybe there's better solutions to this issue I am not aware of

bansatya (Fri, 15 Nov 2019 16:01:37 GMT):
Thanks Patrik . This helps. I will check if I get any thoughts from other folks. I am building two agents now for POC . However, persisting connection (serializing) in one call and using it in another (by de-serializing) fails to issue credentials. Can u plz share ur thoughts. Here is the code.

bansatya (Fri, 15 Nov 2019 16:03:07 GMT):
data = await request.json() connection = data['connection'] connectionobj = await Connection.deserialize(connection) print("get credential offer") print(connectionobj) offers = await Credential.get_offers(connectionobj)

bansatya (Fri, 15 Nov 2019 16:04:15 GMT):
it fails in last line while offering credential.

PatrikStas (Fri, 15 Nov 2019 16:09:02 GMT):
@bansatya not really sure, it looks alright. Using reusing vcx object after serialization and deseerialization works fine for me

PatrikStas (Fri, 15 Nov 2019 16:09:02 GMT):
@bansatya not really sure, it looks alright. Reusing vcx object after serialization and deseerialization works fine for me

PatrikStas (Fri, 15 Nov 2019 16:09:05 GMT):
what's the error?

ekubilay (Mon, 18 Nov 2019 12:32:28 GMT):
Has joined the channel.

ekubilay (Mon, 18 Nov 2019 12:32:30 GMT):
Hi all, could any of you please elaborate on why Indy SDK for Java is at the moment risky to use? As the information provided here: https://github.com/hyperledger/indy-sdk/tree/master/wrappers/java is highly limited. I'd also like to know which SDK would be recommended for production use. Many thanks in advance.

knagware9 (Tue, 19 Nov 2019 07:11:09 GMT):
NOde SDK

JeromeK (Tue, 19 Nov 2019 12:13:05 GMT):
I would go with the Python one

esplinr (Tue, 19 Nov 2019 22:24:34 GMT):
@ekubilay Did you get your question answered in a different channel? It seems like we had this discussion recently?

esplinr (Tue, 19 Nov 2019 22:24:41 GMT):
If not, I can look it up and point you to it.

Sigisagi111 (Wed, 20 Nov 2019 11:02:28 GMT):
Hi everybody. I'm wondering if there is a way to add a claim into a proof request that allows the requester to forward the proof to a selected DID-connection stored in the receivers wallet. So I want to request a certain proof and then have the proof (automatically) forwarded to a connection that the receiver of the proof request has made up before.

foravneet (Wed, 20 Nov 2019 12:32:55 GMT):
Has joined the channel.

ankita.p (Wed, 20 Nov 2019 13:56:40 GMT):
Has joined the channel.

ankita.p (Thu, 21 Nov 2019 05:48:03 GMT):
Hello everyone! I am trying to verify my proof request. But the function verifierVerifyProdof(...) returns *false* everytime. All parameters needed to create the proof request & proof are passed. I compared the structure with the sample provided here - *https://github.com/hyperledger/indy-sdk/blob/master/samples/nodejs/src/anoncredsRevocation.js* The difference I found is : cred_def_id in nodejs sample is in the form of *:3:CL::* but the one I am using is aligned with the latest comment I read here, i.e, *:3:CL::*. Can you please suggest on which to use?

lohan.spies (Thu, 21 Nov 2019 09:17:59 GMT):
Is there any link to the NodeJS development that is being ported from Indy to Aries? The Aries repo is created but no code commits, which tells me it is being developed somewhere else and will be transfered to Aries repo later? We are very interested in the NodeJS Aries work and would be great to collaborate on this. Any pointers in the right direction would be appreciated

esplinr (Thu, 21 Nov 2019 15:44:03 GMT):
#aries-javascript is the best place to ask.

esplinr (Thu, 21 Nov 2019 15:45:15 GMT):
I think the code is here: https://github.com/hyperledger/aries-sdk-javascript

esplinr (Thu, 21 Nov 2019 15:45:25 GMT):
The plan is to build an aries-framework-javascript on top of the thin SDK.

SwapnaliDive (Fri, 22 Nov 2019 11:44:12 GMT):
Has joined the channel.

ankita.p (Fri, 22 Nov 2019 12:20:30 GMT):
Hi All, looking for help in verifying the proof. I am using function *verifierVerifyProof* from node sdk. Referred to the sample given at *https://github.com/hyperledger/indy-sdk/blob/master/samples/nodejs/src/anoncredsRevocationScenario.js* Please refer to the screenshots below of all the parameter passed to the function call.

ankita.p (Fri, 22 Nov 2019 12:20:30 GMT):
Hi All, looking for help in verifying the proof. It return *false* everytime. I am using function *verifierVerifyProof* from node sdk. Referred to the sample given at *https://github.com/hyperledger/indy-sdk/blob/master/samples/nodejs/src/anoncredsRevocationScenario.js* Please refer to the screenshots below of all the parameter passed to the function call.

ankita.p (Fri, 22 Nov 2019 12:20:56 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=2w967uat9Ln2Rx4Qc)
proofReq+proof.png

ankita.p (Fri, 22 Nov 2019 12:21:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=2w967uat9Ln2Rx4Qc)
schema+credDef.png

ankita.p (Fri, 22 Nov 2019 12:21:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=T94qSAnXEiSNNeznY)
revRegDEf+revReg.png

ankita.p (Fri, 22 Nov 2019 13:19:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=qbvK2P4PvSzjzqjFL) @esplinr can you please help on this?

esplinr (Fri, 22 Nov 2019 14:59:10 GMT):
Sorry, not my expertise.

domwoe (Fri, 22 Nov 2019 16:51:38 GMT):
How does the indy-sdk know of the current nodes in the pool. Does an instantiation of the indy-sdk verify the pool ledger ?

domwoe (Fri, 22 Nov 2019 16:51:38 GMT):
*current* :)

Jack1477 (Sun, 24 Nov 2019 22:14:04 GMT):
Is (potential) credential holder required to have his DID written to the ledger to be able to receive credentials from credential Issuer(s) and then use them?

ankita.p (Mon, 25 Nov 2019 05:30:06 GMT):
Thanks for the response @esplinr Can you suggest who can help on this.

ankita.p (Mon, 25 Nov 2019 05:30:06 GMT):
Thanks for the response @esplinr

ankita.p (Mon, 25 Nov 2019 05:32:51 GMT):
Is there anyone who worked on *verification*. Looking to understand what else needs to be done.

ankita.p (Mon, 25 Nov 2019 05:32:51 GMT):
Is there anyone who worked on *verification*. Looking to understand what else needs to be done. It returns *false* everytime

ankita.p (Mon, 25 Nov 2019 06:31:32 GMT):
@sklump , can you help with this.

ankita.p (Mon, 25 Nov 2019 06:31:32 GMT):
@sklump , can you help in this.

ankita.p (Mon, 25 Nov 2019 06:31:32 GMT):
@sklump , @sukalpomitra, @tomislav @swcurran can you help in this.

ap (Mon, 25 Nov 2019 09:27:48 GMT):
Hi, I am getting error bad gateway 502 on accessing https://repo.sovrin.org/repository/maven-public

MarcoPasotti (Mon, 25 Nov 2019 10:35:26 GMT):
me too

esplinr (Mon, 25 Nov 2019 15:38:10 GMT):
You give it the pool information in the genesis file.

swcurran (Mon, 25 Nov 2019 16:19:01 GMT):
No. Only the issuer must have a DID on the Ledger in the Indy ZKP model. Neither the holder nor the verifier need to have DIDs on the ledger.

domwoe (Mon, 25 Nov 2019 17:07:14 GMT):
The pool might have changed since the genesis file. How does an agent get from the genesis file to the current validator set?

athira (Mon, 25 Nov 2019 19:06:18 GMT):
Has joined the channel.

tomislav (Mon, 25 Nov 2019 20:13:53 GMT):
Has anyone encountered a behavior where `indy_verifier_verify_proof` returns `false` when it should pass specifically on Ubuntu 16.04?

esplinr (Mon, 25 Nov 2019 20:58:06 GMT):
It runs a catch-up algorithm.

esplinr (Mon, 25 Nov 2019 20:59:52 GMT):
There have been a few cases where things were true unexpectedly, but I'm not familiar with unexpected false results. Please create an Indy SDK Jira issue with details, and we'll look into it.

IWontDiscloseMyIdentity (Tue, 26 Nov 2019 04:54:05 GMT):
Has joined the channel.

ap (Tue, 26 Nov 2019 04:59:27 GMT):
@MarcoPasotti Working now

ankita.p (Tue, 26 Nov 2019 06:29:39 GMT):
Hi @tomislav is it working expected on 18.04?

ankita.p (Tue, 26 Nov 2019 06:29:39 GMT):
Hi @tomislav is it working expected on Ubuntu 18.04?

tomislav (Tue, 26 Nov 2019 13:36:57 GMT):
Yes @ankita.p . The exact same inputs that fail on 16.04, pass on 18.04, same libindy version.

esplinr (Tue, 26 Nov 2019 14:38:59 GMT):
That is very interesting. Please file an issue with the steps to reproduce and let me know the number.

IWontDiscloseMyIdentity (Wed, 27 Nov 2019 06:41:28 GMT):
Hi Team , Could you please help me , i need reference for the JSON format required to ask for the credentials or to create credentials

IWontDiscloseMyIdentity (Wed, 27 Nov 2019 06:42:29 GMT):
I want to have better understanding of how to create JSOn for requesting credentials and put restrictions on specific attributes to get disclosed

SergeyBrazhnik (Wed, 27 Nov 2019 06:56:32 GMT):
take a look at this

SergeyBrazhnik (Wed, 27 Nov 2019 06:56:32 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/wrappers/java/src/test/java/org/hyperledger/indy/sdk/interaction/AnoncredsRevocationInteractionTest.java

IWontDiscloseMyIdentity (Wed, 27 Nov 2019 07:07:18 GMT):
Thanks @SergeyBrazhnik

IWontDiscloseMyIdentity (Wed, 27 Nov 2019 07:08:57 GMT):
I also wanted to know , suppose when i open wallet .It provides me wallet handle ...which is a number when i pass the object directly to apis it works and when i directly pass the number of that wallet handle it doesn't work . Also i wanted to know the purpose or reaSON ... like how the things are working in backend that they are returning numbers for poolHandle and wallethandle

domwoe (Wed, 27 Nov 2019 08:29:34 GMT):
Thx!

lsl88 (Wed, 27 Nov 2019 12:14:47 GMT):
Has joined the channel.

iampukar (Thu, 28 Nov 2019 09:59:21 GMT):
Has joined the channel.

CHempel (Thu, 28 Nov 2019 11:13:20 GMT):
Yesterday I posted an issue on the #aries channel, maybe someone in here can help. The problem is about proofs for revocation supporting credentials. Thanks, Christopher https://chat.hyperledger.org/channel/aries?msg=XRbRxHRrieYEcnNhm

bansatya (Fri, 29 Nov 2019 07:45:07 GMT):
@swcurran , Would you like to specify any document with respect to ZKP implementation

donqui (Fri, 29 Nov 2019 10:20:44 GMT):
This explains credentials: https://github.com/hyperledger/indy-crypto/blob/master/libindy-crypto/docs/AnonCred.pdf This is the implementation of CL signatures: https://github.com/hyperledger/ursa/tree/master/libursa/src/cl

bansatya (Fri, 29 Nov 2019 12:32:33 GMT):
@donqui , Thanks for sharing this. I understand the cryptographic trust that framework is providing. However, what about human trust.How can we built it.?While Alice requests credential definition from Faber, how the trust is built between this two parties.

donqui (Fri, 29 Nov 2019 12:50:42 GMT):
Right now the idea is that Governance frameworks with ToIP (Trust over IP) should be used to define the rules of the game, and with that enable some level of trust. Some more info here: https://www.slideshare.net/SSIMeetup/internet-identity-workshop-29-highlights-with-drummond-reed (from slide 48) If you are talking about how can Faber trust that Alice is really Alice there are two ways: 1. Alice has credentials that Faber trusts as per frameworks he is using 2. If Alice does not have credentials, the trust needs to be established in the same way as today, probably in person.

donqui (Fri, 29 Nov 2019 12:50:42 GMT):
Right now the idea is that Governance frameworks with ToIP (Trust over IP) should be used to define the rules of the game, and with that enable some level of trust. Some more info here: https://www.slideshare.net/SSIMeetup/internet-identity-workshop-29-highlights-with-drummond-reed (from slide 48) If you are talking about how can Faber trust that Alice is really Alice there are two ways: 1. Alice has credentials that Faber trusts as per governance frameworks it trusts 2. If Alice does not have credentials, the trust needs to be established in the same way as today, probably in person.

SigmaS 1 (Fri, 29 Nov 2019 14:19:51 GMT):
Has joined the channel.

SigmaS 1 (Fri, 29 Nov 2019 14:19:55 GMT):
tste

anillewis (Fri, 29 Nov 2019 19:19:43 GMT):
Team...i was trying out the indy-sdk node.js wrapper for windows. While installing I saw libvcx errors (I had installed libindy before) but when i downloaded libvcx dlls the error went away (apart from setting the libs in the path and LD_LIBRARY_PATH)...is this correct? The downloaded indy-sdk@1.11.0

ItsOmerShafiq (Sun, 01 Dec 2019 22:27:40 GMT):
Has joined the channel.

heenas06 (Tue, 03 Dec 2019 08:27:48 GMT):
Has joined the channel.

heenas06 (Tue, 03 Dec 2019 08:28:12 GMT):
Hi All I am trying to do indy-sdk setup & while doing "npm run start" command i am getting this issue....will attach the snap....

heenas06 (Tue, 03 Dec 2019 08:28:47 GMT):

Screenshot .png

heenas06 (Tue, 03 Dec 2019 09:08:11 GMT):
Hi guys can anyone getting above error ...............?

dbluhm (Tue, 03 Dec 2019 19:15:20 GMT):
@heenas06 did you install libindy? The build appears to be failing because it can't find files that should have been installed when installing indy from a package or need to be placed in your LD_LIBRARY_PATH if you built from source

heenas06 (Wed, 04 Dec 2019 05:30:28 GMT):
yes i installed libindy and also i placed LD path ....but its not taking

SigmaS 1 (Wed, 04 Dec 2019 07:20:11 GMT):
did you install g++ ?

SigmaS 1 (Wed, 04 Dec 2019 09:49:16 GMT):
Hello, I have installed indy-sdk and I am playing with Walkthrough, my question is how could I get the did document in JSON format(with method, endpoints, public keys etc) or how could I resolve for example the "faberDID"?

JeromeK (Wed, 04 Dec 2019 10:35:36 GMT):
Hey Sigmas You should have a look at nym-transactions, maybe this could help :thumbsup:

SigmaS 1 (Wed, 04 Dec 2019 10:40:01 GMT):
Hey Jerome. Where exactly the NYM txs are stored? I'm looking inside docker container, /var/lib/indy but I can't find them.

JeromeK (Wed, 04 Dec 2019 10:41:29 GMT):
They are stored on the Ledger

JeromeK (Wed, 04 Dec 2019 10:41:31 GMT):
https://github.com/hyperledger/indy-node/blob/master/docs/source/requests.md#nym

JeromeK (Wed, 04 Dec 2019 10:42:06 GMT):
and you can request them

SigmaS 1 (Wed, 04 Dec 2019 10:45:00 GMT):
you mean with "ledger.build_nym_request" ?

JeromeK (Wed, 04 Dec 2019 10:47:04 GMT):
correct

SigmaS 1 (Wed, 04 Dec 2019 10:49:07 GMT):
also in the link you've sent me in reply example I don't see any methods etc. I have in my mind that the format of DID is: did:example:123456789abcdefghi

JeromeK (Wed, 04 Dec 2019 10:54:46 GMT):
I guess this up to your implementation how you resolve the did

JeromeK (Wed, 04 Dec 2019 10:55:05 GMT):
because there is no function (which i know) within indy to do that

SigmaS 1 (Wed, 04 Dec 2019 11:16:19 GMT):
ok thanks a lot

JeromeK (Wed, 04 Dec 2019 11:59:14 GMT):
:thumbsup:

SigmaS 1 (Wed, 04 Dec 2019 13:00:50 GMT):
Hello, is it possible to get Credential Schema from the ledger without knowing the SchemaID? If not, how each Credential Definition Issuer knows the SchemaID for every Credential Schema?

JeromeK (Wed, 04 Dec 2019 14:02:35 GMT):
Its me again ;) And close to the same answer as before... You need to somehow already know the schema_id to create the cred-def so again this can variete on how to get those. Good thing that the Schema can be merged create "manually" -> DID:2:SchemName:SchemaVersion

JeromeK (Wed, 04 Dec 2019 14:02:45 GMT):
maybe this helps

DucaDellaForcoletta (Thu, 05 Dec 2019 12:54:05 GMT):
Hi all, anyone know if in the latest version of sdk / postgresplugin an index has been added to the tags_encrypted table?

DucaDellaForcoletta (Thu, 05 Dec 2019 12:54:26 GMT):
I'm getting the following error when save the credential in the wallet: ERROR: index row requires 132920 bytes, maximum size is 8191

DucaDellaForcoletta (Thu, 05 Dec 2019 12:54:50 GMT):
With the previous version I was able to store data bigger than this case

pengyuc (Thu, 05 Dec 2019 21:13:26 GMT):
Has joined the channel.

bansatya (Fri, 06 Dec 2019 05:54:13 GMT):
@JeromeK , as an issuer while I register my DID in the ledger, ideally my DID document should be available in the ledger now onward. However, while I fetched the Nym transaction details from ledger, I only get the role of the DID but Question is how to get the JSON LD?

JeromeK (Fri, 06 Dec 2019 15:48:36 GMT):
Hey have a look at this function

JeromeK (Fri, 06 Dec 2019 15:48:40 GMT):
https://github.com/hyperledger/indy-sdk/blob/6079e7800f9bd6f5b56d8eb8973e7cfc5101ca0b/wrappers/python/indy/ledger.py#L304

JeromeK (Fri, 06 Dec 2019 15:49:07 GMT):
after you have registered your did you can add attributes, which could represend the JSON LD you need

spacemandev (Fri, 06 Dec 2019 20:21:24 GMT):
hey all i was trying to to figure out if the peer to peer based credentialing which was initially talked about with indy was a feature that was being planned or had been implented already? i can't seem to find anything about it

tomislav (Fri, 06 Dec 2019 21:35:06 GMT):
I'm not aware of any specific standardization for this. While it's technically possible to do this, there's no clear direction how this should be implemented

spacemandev (Fri, 06 Dec 2019 22:57:48 GMT):
how would you go about this? i thought indy required all credentials issued to be put on the ledger, no?

donqui (Sat, 07 Dec 2019 14:13:35 GMT):
credentials are not stored on the ledger: https://sovrin.org/wp-content/uploads/2018/10/What-Goes-On-The-Ledger.pdf

spacemandev (Sun, 08 Dec 2019 21:34:51 GMT):
^right but for someone (a peer) to issue a credential, they would need to have created a credential defintion on the ledger

spacemandev (Sun, 08 Dec 2019 21:35:11 GMT):
i'm asking about pure peer based creds that are *not* anchored on the ledger in any way

swcurran (Sun, 08 Dec 2019 22:19:28 GMT):
In theory you could create a credential def and share it p2p with a holder, and then either the holder or the issuer could further (p2p) share it with the verifier. We were thinking of using that as a way for a person to issue credentials without having to have a DID on the ledger. We think in theory it is possible with the current indy-sdk assuming you can get the cred-def into the wallets of the participants (w/o referencing the ledger). When indy-sdk runs anoncred it assumes you have already put the needed pieces in the wallet. That said, it has not been done (AFAIK). What's the use case you have in mind?

tomislav (Sun, 08 Dec 2019 22:35:06 GMT):
There's definitely unit tests in indy-sdk supporting this functionality. Peer credentials are the basis for design concepts like social key recovery. Would love to explore this idea further. Revocation may be tricky to solve though

swcurran (Mon, 09 Dec 2019 00:23:20 GMT):
I've not heard of social key recovery tied to that. Could you provide a quick summary of the idea?

swcurran (Mon, 09 Dec 2019 00:29:44 GMT):
Good idea checking the indy-sdk test cases for examples of this.

lgalabru (Mon, 09 Dec 2019 04:29:51 GMT):
Has joined the channel.

smithbk (Tue, 10 Dec 2019 14:32:24 GMT):
Has anyone seen the following failure when trying to build indy-sdk, problem with ursa? Any help is appreciated. ```Compiling ursa v0.1.1 error[E0277]: the trait bound `rand_chacha::ChaChaRng: rand_core::CryptoRng` is not satisfied --> /home/agency/.cargo/registry/src/github.com-1ecc6299db9ec823/ursa-0.1.1/src/signatures/ed25519.rs:27:21 | 27 | Keypair::generate(&mut rng) | ^^^^^^^^^^^^^^^^^ the trait `rand_core::CryptoRng` is not implemented for `rand_chacha::ChaChaRng` | = note: required by `ed25519_dalek::Keypair::generate` error[E0277]: the trait bound `rand_chacha::ChaChaRng: rand_core::RngCore` is not satisfied --> /home/agency/.cargo/registry/src/github.com-1ecc6299db9ec823/ursa-0.1.1/src/signatures/ed25519.rs:27:21 | 27 | Keypair::generate(&mut rng) | ^^^^^^^^^^^^^^^^^ the trait `rand_core::RngCore` is not implemented for `rand_chacha::ChaChaRng` | = note: required by `ed25519_dalek::Keypair::generate` error[E0277]: the trait bound `rand::rngs::OsRng: rand_core::CryptoRng` is not satisfied --> /home/agency/.cargo/registry/src/github.com-1ecc6299db9ec823/ursa-0.1.1/src/signatures/ed25519.rs:35:17 | 35 | Keypair::generate(&mut rng) | ^^^^^^^^^^^^^^^^^ the trait `rand_core::CryptoRng` is not implemented for `rand::rngs::OsRng` | = note: required by `ed25519_dalek::Keypair::generate` error[E0277]: the trait bound `rand::rngs::OsRng: rand_core::RngCore` is not satisfied --> /home/agency/.cargo/registry/src/github.com-1ecc6299db9ec823/ursa-0.1.1/src/signatures/ed25519.rs:35:17 | 35 | Keypair::generate(&mut rng) | ^^^^^^^^^^^^^^^^^ the trait `rand_core::RngCore` is not implemented for `rand::rngs::OsRng` | = note: required by `ed25519_dalek::Keypair::generate` error: aborting due to 4 previous errors```

AlexanderYenkalov (Tue, 10 Dec 2019 16:36:58 GMT):
Has joined the channel.

AlexanderYenkalov (Tue, 10 Dec 2019 16:36:58 GMT):
Hi Guys, We spotted an IndyError when tried to execute indy.issuerCreateAndStoreRevocReg Do you have any suggestions on what can be the root cause for underlying error? -- IndyError: CommonInvalidStructure at Object.callback (/opt/app/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10) name: 'IndyError', message: 'CommonInvalidStructure', indyCode: 113, indyName: 'CommonInvalidStructure', indyCurrentErrorJson: null } From indyCode 113 it seems that something is wrong with a structure type for some of parameters, but according to the spec it looks that Im doing it right... ///

/// Object (json, config, key, claim and etc...) passed by library caller has invalid structure ///

CommonInvalidStructure = 113, — wallet.handle is 4 wallet.didAddress is “YHim98ivvHJ9cbJa4sB9Ay” body.tag is tag1 body.cred_def_id is “YHim98ivvHJ9cbJa4sB9Ay:3:CL:79922:eID” tailsWriterHandle is 5 const [ revocRegId, revocRegDef, revocRegEntry ] = await indy.issuerCreateAndStoreRevocReg( wallet.handle, wallet.didAddress, 'CL', body.tag, body.cred_def_id, { max_cred_num: 1 }, tailsWriterHandle ) — Link to doc in JS https://github.com/hyperledger/indy-sdk/blob/master/wrappers/nodejs/README.md#issuercreateandstorerevocreg--wh-issuerdid-revocdeftype-tag-creddefid-config-tailswriterhandle-----revocregid-revocregdef-revocregentry- Link to example in JS https://github.com/hyperledger/aries-sdk-javascript/blob/710eb993f9444f5e3e3ea94142f440f8c6e6bb22/test/ledger.js

dbluhm (Tue, 10 Dec 2019 18:41:47 GMT):
@MALodder any thoughts?

ianco (Tue, 10 Dec 2019 21:24:04 GMT):
I think it's a mis-match of ursa and rand versions

ianco (Tue, 10 Dec 2019 21:24:40 GMT):
ursa 0.1.1 goes with rand 0.3 (?) and ursa 0.2.0 goes with rand 0.7 (?) ... or something like that ...

aaronr (Tue, 10 Dec 2019 21:27:59 GMT):
Has joined the channel.

nbrempel (Tue, 10 Dec 2019 21:46:46 GMT):
I'm seeing the same issue. Aligning ursa 0.2.0 and rand 0.7 didn't seem to help unfortunately

ianco (Tue, 10 Dec 2019 21:47:20 GMT):
Maybe a rustc version issue then? I've got 1.36.0

nbrempel (Tue, 10 Dec 2019 21:49:35 GMT):
testing that now

nbrempel (Tue, 10 Dec 2019 22:54:06 GMT):
no luck

ankita.p (Wed, 11 Dec 2019 11:06:21 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=ezWtkYy5f9P3Eva5W) In input parameters try with adding 'issuance_type' in config option : const [ revocRegId, revocRegDef, revocRegEntry ] = await indy.issuerCreateAndStoreRevocReg( wallet.handle, wallet.didAddress, 'CL', body.tag, body.cred_def_id, { max_cred_num: 1, issuance_type: 'ISSUANCE_ON_DEMAND' }, tailsWriterHandle )

AlexanderYenkalov (Wed, 11 Dec 2019 11:52:25 GMT):
Did anyone have such an issue with Node.JS wrapper?

fabienpe (Wed, 11 Dec 2019 12:50:31 GMT):
While doing some performance measurements on an Indy ledger (4 AWS VMs each running a node) I came across some behaviour I'm unable to explain and was wondering if anyone had some idea what the cause could be. From a 5th AWS VM, using some Python code, I send different types of requests (10,000 for each in sequence) and measure `time.time()` and `time.process_time()` around each `ledger.submit()` request. I do that for `GET_TXN`, `VALIDATOR_INFO`, `NYM`, `GET_NYM`, `REVOC_REG_ENTRY` (issuance), `REVOC_REG_ENTRY` (revocation). For all request, but `GET_NYM`, the average process time is few tens of milliseconds. That is what I expect. But for `GET_NYM`, the average process time (395 ms) represent most of the total time (430 ms) for the call to `ledger.submit_request()`. Any thoughts?

fabienpe (Wed, 11 Dec 2019 12:50:31 GMT):
While doing some performance measurements on an Indy ledger (4 AWS VMs each running a node) I came across some behaviour I'm unable to explain and was wondering if anyone had some idea what the cause could be. From a 5th AWS VM, using some Python code, I send different types of requests (10,000 for each in sequence) and measure `time.time()` and `time.process_time()` around each `ledger.submit_request()` request. I do that for `GET_TXN`, `VALIDATOR_INFO`, `NYM`, `GET_NYM`, `REVOC_REG_ENTRY` (issuance), `REVOC_REG_ENTRY` (revocation). For all request, but `GET_NYM`, the average process time is few tens of milliseconds. That is what I expect. But for `GET_NYM`, the average process time (395 ms) represent most of the total time (430 ms) for the call to `ledger.submit_request()`. Any thoughts?

fabienpe (Wed, 11 Dec 2019 12:50:31 GMT):
While doing some performance measurements on an Indy ledger (4 AWS VMs each running a node) I came across some behaviour I'm unable to explain and was wondering if anyone had some idea what the cause could be. From a 5th AWS VM, using some Python code, I send different types of requests (10,000 for each in sequence) and measure `time.time()` and `time.process_time()` around each `ledger.submit_request()` call. I do that for `GET_TXN`, `VALIDATOR_INFO`, `NYM`, `GET_NYM`, `REVOC_REG_ENTRY` (issuance), `REVOC_REG_ENTRY` (revocation). For all request, but `GET_NYM`, the average process time is few tens of milliseconds. That is what I expect. But for `GET_NYM`, the average process time (395 ms) represent most of the total time (430 ms) for the call to `ledger.submit_request()`. Any thoughts?

fabienpe (Wed, 11 Dec 2019 12:50:31 GMT):
While doing some performance measurements on an Indy ledger (4 AWS VMs each running a node) I came across some behaviour I'm unable to explain and was wondering if anyone had some idea what the cause could be. From a 5th AWS VM, using some Python code, I send different types of requests (10,000 for each in sequence) and measure `time.time()` and `time.process_time()` around each `ledger.submit_request()` call. I do that for `GET_TXN`, `VALIDATOR_INFO`, `NYM`, `GET_NYM`, `REVOC_REG_ENTRY` (issuance), `REVOC_REG_ENTRY` (revocation). For all requests, but `GET_NYM`, the average process time is few tens of milliseconds. That is what I expect. But for `GET_NYM`, the average process time (395 ms) represent most of the total time (430 ms) for the call to `ledger.submit_request()`. Any thoughts?

fabienpe (Wed, 11 Dec 2019 12:50:31 GMT):
While doing some performance measurements on an Indy ledger (4 AWS VMs each running a node) I came across some behaviour I'm unable to explain and was wondering if anyone had some idea what the cause could be. From a 5th AWS VM, using some Python code, I send different types of requests (10,000 for each in sequence) and measure `time.time()` and `time.process_time()` around each `ledger.submit_request()` call. I do that for `GET_TXN`, `VALIDATOR_INFO`, `NYM`, `GET_NYM`, `REVOC_REG_ENTRY` (issuance), `REVOC_REG_ENTRY` (revocation). For all requests, but `GET_NYM`, the average process time is about 30ms. That is what I expect. But for `GET_NYM`, the average process time (395ms) represent most of the total time (430ms) for the call to `ledger.submit_request()`. Any thoughts?

fabienpe (Wed, 11 Dec 2019 12:50:31 GMT):
While doing some performance measurements on an Indy ledger (4 AWS VMs each running a node) I came across some behaviour I'm unable to explain and was wondering if anyone had some idea what the cause could be. From a 5th AWS VM, using some Python code, I send different types of requests (10,000 for each in sequence) and measure `time.time()` and `time.process_time()` around each `ledger.submit_request()` call. I do that for `GET_TXN`, `VALIDATOR_INFO`, `NYM`, `GET_NYM`, `REVOC_REG_ENTRY` (issuance), `REVOC_REG_ENTRY` (revocation). For all requests, but `GET_NYM`, the average process time is about 30ms. That is what I expect (it's very small). But for `GET_NYM`, the average process time (395ms) represent most of the total time (430ms) for the call to `ledger.submit_request()`. Any thoughts?

fabienpe (Wed, 11 Dec 2019 12:50:31 GMT):
While doing some performance measurements on an Indy ledger (4 AWS VMs each running a node) I came across some behaviour I'm unable to explain and was wondering if anyone had some idea what the cause could be. From a 5th AWS VM, using some Python code, I send different types of requests (10,000 for each in sequence) and measure `time.time()` and `time.process_time()` around each `ledger.submit_request()` call. I do that for `GET_TXN`, `VALIDATOR_INFO`, `NYM`, `GET_NYM`, `REVOC_REG_ENTRY` (issuance), `REVOC_REG_ENTRY` (revocation). For all requests, but `GET_NYM`, the average process time is about 30ms. That is what I expect (it's very small). But for `GET_NYM`, the average process time (395ms) represents most of the total time (430ms) for the call to `ledger.submit_request()`. Any thoughts?

lsl88 (Wed, 11 Dec 2019 15:22:57 GMT):
Hi! I am trying to follow the walkthrough but using indy-cli instead of a wrapper. I can't find the command to retrieve the verkey from a did, may somebody help me? :) thanks!

jrallen (Wed, 11 Dec 2019 15:29:37 GMT):
Has joined the channel.

sklump (Wed, 11 Dec 2019 15:38:01 GMT):
Until 1.12.x, proof requests like ``` { "nonce": "1576075728", "name": "proof_req", "version": "0.0", "requested_attributes": { ... }, "requested_predicates": { "18_id_GE_uuid": { "name": "id", "p_type": ">=", "p_value": 4, "restrictions": [ { "cred_def_id": "LjgpST2rjsoxYegQDRm7EL:3:CL:18:tag" } ], "non_revoked": { "from": 1576075696, "to": 1576075696 } }, ... } } ``` were fine in prover.create_proof(). I see some text around `restrictions` has changed to cite WQL, and now a proof req like this makes indy-sdk 1.13.0 raise CommonInvalidStructure. Are lists no longer OK in requested_predicate restrictions? They still appear OK in requested_attributes. Puzzling.

sklump (Wed, 11 Dec 2019 15:38:01 GMT):
Until 1.12.x, proof requests like ``` { "nonce": "1576075728", "name": "proof_req", "version": "0.0", "requested_attributes": { ... }, "requested_predicates": { "18_id_GE_uuid": { "name": "id", "p_type": ">=", "p_value": 4, "restrictions": [ { "cred_def_id": "LjgpST2rjsoxYegQDRm7EL:3:CL:18:tag" } ], "non_revoked": { "from": 1576075696, "to": 1576075696 } }, ... } } ``` were fine in verifier.verify_proof(). I see some text around `restrictions` has changed to cite WQL, and now a proof req like this makes indy-sdk 1.13.0 raise CommonInvalidStructure. Are lists no longer OK in requested_predicate restrictions? They still appear OK in requested_attributes. Puzzling.

JeromeK (Wed, 11 Dec 2019 17:18:45 GMT):
just use did list -> Returns a Table of DID | Verkey

JeromeK (Wed, 11 Dec 2019 17:18:45 GMT):
just use `did list `-> Returns a Table of DID | Verkey

sklump (Wed, 11 Dec 2019 17:55:49 GMT):
Until recently (pre-ursa?) the restrictions in requested_predicates for a proof_request were a list of dicts. Now that structure causes libindy to raise a CommonInvalidStructure here: https://github.com/hyperledger/indy-sdk/blob/91f839d443250efc86334dbdeee604b39575f33b/libindy/src/services/anoncreds/prover.rs#L156 Just a word to the wise. This exception occurs in libursa (external crate) and I don't know how to troubleshoot this. For now I'm going to try to give it what I think it wants. Shades of Spock's Brain.

sklump (Wed, 11 Dec 2019 17:55:49 GMT):
Until recently (pre-ursa?) the restrictions in requested_predicates for a proof_request were a list of dicts. Now if non-empty, that structure causes libindy to raise a CommonInvalidStructure here: https://github.com/hyperledger/indy-sdk/blob/91f839d443250efc86334dbdeee604b39575f33b/libindy/src/services/anoncreds/prover.rs#L156 Just a word to the wise. This exception occurs in libursa (external crate) and I don't know how to troubleshoot this. For now I'm going to try to give it what I think it wants. Shades of Spock's Brain. *Update:* nope, still wrong. This is no good: { "nonce": "1576087348", "name": "proof_req", "version": "0.0", "requested_attributes": { "18_0_uuid": { "names": [ "endDate", "effectiveDate", "busId", "orgTypeId", "id", "legalName", "jurisdictionId" ], "restrictions": [ { "cred_def_id": "LjgpST2rjsoxYegQDRm7EL:3:CL:18:tag" } ], "non_revoked": { "from": 1576087338, "to": 1576087338 } } }, "requested_predicates": { "18_id_GE_uuid": { "name": "id", "p_type": ">=", "p_value": 4, "restrictions": { "cred_def_id": "LjgpST2rjsoxYegQDRm7EL:3:CL:18:tag" }, "non_revoked": { "from": 1576087338, "to": 1576087338 } }, "18_busid_GE_uuid": { "name": "busId", "p_type": ">=", "p_value": 11198760, "restrictions": { "cred_def_id": "LjgpST2rjsoxYegQDRm7EL:3:CL:18:tag" }, "non_revoked": { "from": 1576087338, "to": 1576087338 } } } }

sklump (Wed, 11 Dec 2019 17:55:49 GMT):
Until recently (pre-ursa?) the restrictions in requested_predicates for a proof_request were a list of dicts. Now if non-empty, that structure causes libindy to raise a CommonInvalidStructure here: https://github.com/hyperledger/indy-sdk/blob/91f839d443250efc86334dbdeee604b39575f33b/libindy/src/services/anoncreds/prover.rs#L156 Just a word to the wise. This exception occurs in libursa (external crate) and I don't know how to troubleshoot this. For now I'm going to try to give it what I think it wants. Shades of Spock's Brain. *Update:* nope, still wrong. This is no good: ``` { "nonce": "1576087348", "name": "proof_req", "version": "0.0", "requested_attributes": { "18_0_uuid": { "names": [ "endDate", "effectiveDate", "busId", "orgTypeId", "id", "legalName", "jurisdictionId" ], "restrictions": [ { "cred_def_id": "LjgpST2rjsoxYegQDRm7EL:3:CL:18:tag" } ], "non_revoked": { "from": 1576087338, "to": 1576087338 } } }, "requested_predicates": { "18_id_GE_uuid": { "name": "id", "p_type": ">=", "p_value": 4, "restrictions": { "cred_def_id": "LjgpST2rjsoxYegQDRm7EL:3:CL:18:tag" }, "non_revoked": { "from": 1576087338, "to": 1576087338 } }, "18_busid_GE_uuid": { "name": "busId", "p_type": ">=", "p_value": 11198760, "restrictions": { "cred_def_id": "LjgpST2rjsoxYegQDRm7EL:3:CL:18:tag" }, "non_revoked": { "from": 1576087338, "to": 1576087338 } } } } ```

sklump (Wed, 11 Dec 2019 18:06:32 GMT):
And neither is ``` ... "requested_predicates": { "18_id_GE_uuid": { "name": "id", "p_type": ">=", "p_value": 4, "restrictions": [{ "cred_def_id": "LjgpST2rjsoxYegQDRm7EL:3:CL:18:tag" }], "non_revoked": { "from": 1576087338, "to": 1576087338 } }, ... ```

sklump (Wed, 11 Dec 2019 18:06:32 GMT):
And neither is (note square brackets in "restrictions") ``` ... "requested_predicates": { "18_id_GE_uuid": { "name": "id", "p_type": ">=", "p_value": 4, "restrictions": [{ "cred_def_id": "LjgpST2rjsoxYegQDRm7EL:3:CL:18:tag" }], "non_revoked": { "from": 1576087338, "to": 1576087338 } }, ... ```

sklump (Wed, 11 Dec 2019 18:22:50 GMT):
Next stop: I'll try to tweak the wrapper tests and post a minimal breaking change. I should have started there.

sklump (Wed, 11 Dec 2019 18:22:50 GMT):
Next stop: I'll try to tweak the wrapper tests and post a minimal breaking change. I should have started there. *I can't seem to reproduce it there -- sigh -- I will keep the forum posted if and when I figure out what's up*

sklump (Wed, 11 Dec 2019 18:22:50 GMT):
Next stop: I'll try to tweak the wrapper tests and post a minimal breaking change. I should have started there. _I can't seem to reproduce it there -- sigh -- I will keep the forum posted if and when I figure out what's up_

tomislav (Wed, 11 Dec 2019 23:42:33 GMT):
Thanks @sklump - I'm curious what the outcome is.

lsl88 (Thu, 12 Dec 2019 15:02:55 GMT):
Thank you very much! Sorry, my question was not well formulated: what I would like to do is the equivalent of step 10: id.key_for_did(faber['pool'], faber['wallet'], connection_request['did']), but through the indy-cli, is that possible?

lsl88 (Thu, 12 Dec 2019 15:02:55 GMT):
Thank you very much! Sorry, my question was not well formulated: what I would like to do is the equivalent of step 10: did.key_for_did(faber['pool'], faber['wallet'], connection_request['did']), but through the indy-cli, is that possible?

SigmaS 1 (Thu, 12 Dec 2019 15:23:20 GMT):
Hello, cryptoAuthDecrypt API documentation refers to a shared secret key that will be used for verifying the encrypted message and for ensuring that this message was not tampered with. However there is no API for verifying. Is the verifying process occur automatically?

tomislav (Thu, 12 Dec 2019 19:22:06 GMT):
There's `indy_crypto_verify`. Is this what you're referring to? https://github.com/hyperledger/indy-sdk/blob/956bd402e1012263540d8271a603575685b910b0/libindy/src/api/crypto.rs#L249

sklump (Thu, 12 Dec 2019 20:21:01 GMT):
*partial update:* it is an error to request an attribute specified in predicates - it always was, I don't know how it could have worked before. There are some other subtleties in 'name' vs. 'names' but it looks like the problems are on my side.

sklump (Thu, 12 Dec 2019 20:21:01 GMT):
*partial update:* it is an error to request an attribute specified in predicates (`id`, `busId` above) - it always was, I don't know how it could have worked before. There are some other subtleties in 'name' vs. 'names' but it looks like the problems are on my side.

tomislav (Thu, 12 Dec 2019 20:29:22 GMT):
You mean it's an error to request an attribute both in attributes and predicates?

tomislav (Thu, 12 Dec 2019 20:30:11 GMT):
I wasn't aware about the `names` change. Is this going to be an array moving forward?

SigmaS 1 (Fri, 13 Dec 2019 09:39:32 GMT):
Thanks a lot. So if I understand right, the verify process is this: // Sender AGENT 1. signatureRaw = cryptoSing(senderWallet, senderRecipientKey, message) 2. encryptedMsgRaw = cryptoAuthCrypt(senderWallet, senderRecipientKey, RecipientSenderKey, message) //sends both signatureRaw and encryptedMsgRaw to Recipient // Recipient AGENT 3. [ senderRecipientKey, decryptedMsgRaw ]= cryptoAuthDecrypt (recipientWallet, RecipientSenderKey, encryptedMsgRaw ) 4. assert( cryptoVerify ( senderRecipientKey, decryptedMsgRaw, signatureRaw ) )

jrallen (Fri, 13 Dec 2019 09:45:22 GMT):
Hello, I'm looking for info on the state of the art of building mobile agents (i.e. for iOS). For example, I tried building https://github.com/sovrin-foundation/connector-app.git but it depends on a old version of vcx that is not available from Evernym, so I updated it to take vcx from indy-sdk, but there are compile errors on vcx.h.

jrallen (Fri, 13 Dec 2019 09:46:15 GMT):
I see that build.sovrin.org is building ad testing libindy for iOS, but it seems like vcx is not working in iOS anymore?

donqui (Fri, 13 Dec 2019 09:53:19 GMT):
I belie vcx is having some issues currently with the newsest version of xcode, but generally it works. There are some other frameworks for building mobile agents like: https://github.com/hyperledger/aries-framework-dotnet. THis was used to build the StreetCred app. As one already made solution that you can just build and use there is: https://github.com/mattrglobal/osma

donqui (Fri, 13 Dec 2019 09:53:19 GMT):
I belie vcx is having some issues currently with the newest version of xcode, but generally it works. There are some other frameworks for building mobile agents like: https://github.com/hyperledger/aries-framework-dotnet. THis was used to build the StreetCred app. As one already made solution that you can just build and use there is: https://github.com/mattrglobal/osma

donqui (Fri, 13 Dec 2019 09:53:19 GMT):
I belie vcx is having some issues currently with the newest version of xcode, but generally it works. There are some other frameworks for building mobile agents like: https://github.com/hyperledger/aries-framework-dotnet. This was used to write the StreetCred app, and was open-sourced by the same guys (https://streetcred.id/) As one already made solution that you can just build and use there is: https://github.com/mattrglobal/osma

donqui (Fri, 13 Dec 2019 09:53:19 GMT):
The connector app is very outdated and should not be used. I believe that vcx alone is having some issues currently with the newest version of xcode, but generally it should work. There are some other frameworks for building mobile agents like: https://github.com/hyperledger/aries-framework-dotnet. This was used to write the StreetCred app, and was open-sourced by the same guys (https://streetcred.id/) As one already made solution that you can just build and use there is: https://github.com/mattrglobal/osma

jrallen (Fri, 13 Dec 2019 10:03:51 GMT):
I'd noticed both of those, but was surprised that they are in C#. Is that a normal language for mobile apps now? I thought it was just for windows phones (rip).

donqui (Fri, 13 Dec 2019 10:09:35 GMT):
I have to preface this with saying that i am not a mobile dev, so take everything i say with a grain of salt. They are utilizing Xamarin, that is pretty much all I know :) Plenty of folks are using it, but it is not Swift, Kotlin or ReactNative If you want to go that route, the best way is to use libvcx cocoapod and buold around that.

jrallen (Fri, 13 Dec 2019 10:11:46 GMT):
ok, well it is good to know that I can/should at least try to Xamarin build. Fundamentally, what I'm looking for is a "white label" wallet app that I can hack on to add features related to my own PoC, in order to show sovereign id working in the context of the stuff I'm working on.

jrallen (Fri, 13 Dec 2019 10:12:20 GMT):
Surprised that I'm going to have to learn some C#, but why not. YOLO app dev, right? :)

donqui (Fri, 13 Dec 2019 10:15:05 GMT):
If you do not need to add functionality to the app and can only rely on the existing exposed APIs you can try using Streetcred, or Evernym's Connect.Me (both should be on the playstore). THey are not white-label but they can allow you to quickly create a simple POC. If white-label is what you need, and want to make changes to the look & feel + functionality of sorts I would try OSMA first.

sklump (Fri, 13 Dec 2019 12:07:02 GMT):
#1: yes, that is an error. #2: `names` is an array but `name` is singular in the proof request. The idea is that a proof request can demand several attributes from the same credential, whereas before there was a bait-and-switch possibility if the requirements were underspecified (e.g., verifier does not know the cred def id, only the schema id). Revealed `names` attributes in the proof request show up in the `proof[ requested_proof][revealed_attr_groups]`. There are subtleties (e.g. attribute name canonicalization in eq_proof['revealed_attrs'] but not in revealed attribute groups) that I haven't fully understood yet, but are not likely to trip anyone else up. I'm only under the hood for von_anchor tool maintenance to make it work with the new generation of proof data structure menagerie.

sklump (Fri, 13 Dec 2019 12:07:02 GMT):
#1: yes, that is an error. I vaguely recall that indy-sdk allows the verifier to build a proof request without `names` (only `name`) but fails on the verification. Don't quote this - I know it's never correct though. #2: `names` is an array but `name` is singular in the proof request. The idea is that a proof request can demand several attributes from the same credential, whereas before there was a bait-and-switch possibility if the requirements were underspecified (e.g., verifier does not know the cred def id, only the schema id). Revealed `names` attributes in the proof request show up in the `proof[ requested_proof][revealed_attr_groups]`. There are subtleties (e.g. attribute name canonicalization in eq_proof['revealed_attrs'] but not in revealed attribute groups) that I haven't fully understood yet, but are not likely to trip anyone else up. I'm only under the hood for von_anchor tool maintenance to make it work with the new generation of proof data structure menagerie.

leon_dobnik (Fri, 13 Dec 2019 21:16:17 GMT):
Has joined the channel.

leon_dobnik (Fri, 13 Dec 2019 21:16:20 GMT):
hello to everyone. I am trying to build libindy-sdk and then objc wrapper on top of it. I managed to build the library and prepare pods somehow, but the final step complains with the missing architectures. Is any mobile dev with working 1.13.0 build here? Thanks!

barrysieg (Sun, 15 Dec 2019 03:33:15 GMT):
Has joined the channel.

steveLiuu (Mon, 16 Dec 2019 02:42:58 GMT):
Has joined the channel.

SwapnaliDive (Mon, 16 Dec 2019 06:59:35 GMT):
Hello Everyone, Can anyone help to configure postgres with indy-sdk ? Need steps.

SigmaS 1 (Mon, 16 Dec 2019 07:22:48 GMT):
@tomislav

tomislav (Mon, 16 Dec 2019 13:01:15 GMT):
That looks right

tomislav (Mon, 16 Dec 2019 13:02:36 GMT):
Signing is redundant in the case you described, since it's signed by the same key, but still technically valid

FarhanShafiq (Mon, 16 Dec 2019 14:32:24 GMT):
Hey guys, indy-cli doesn't let me get the custom method did from wallet i.e did:let:VsKV7grR1BUE29mG2Fm2kX. Is there anyway to done that or I can only use sov method?

sklump (Mon, 16 Dec 2019 17:34:44 GMT):
Engineering notes for the curious on proof menagerie evolution, libindy-1.13.0 style: https://drive.google.com/open?id=1LMiylKwaFnI-fJPDjmJbNHy-2ES-C3ju

sklump (Mon, 16 Dec 2019 17:34:44 GMT):
Engineering notes for the curious on proof menagerie evolution, libindy-1.13.0 style: https://drive.google.com/open?id=1QJgmghL_v01ZlsVL0Tk-X4c3-EidWFp_

Yoroitchi (Tue, 17 Dec 2019 10:49:17 GMT):
Has joined the channel.

tomislav (Tue, 17 Dec 2019 13:21:09 GMT):
Wonderful, thank you for putting this together sir!

IWontDiscloseMyIdentity (Wed, 18 Dec 2019 05:58:22 GMT):
Hi Team ,I am thinking to develop a POC with mobile application but i am confused ,as we have liberaries from indy as well aries. I am confused ,in what way shall i implement those liberaries. Shall i use indy liberaries for the whole Project or aries As per my knowledge , Aries as of now doesn't have a mature library for nodejs and also for mobile qr scanning or mobile to mobile communication we need Aries libraries What you guys suggest ?

donqui (Wed, 18 Dec 2019 09:23:19 GMT):
do you need to build a mobile application, or could you use some of the existing apps? OSMA is an open source agent (https://github.com/mattrglobal/osma) built using https://github.com/hyperledger/aries-framework-dotnet Streetcred (https://streetcred.id/) was built using an Aries framework: https://github.com/hyperledger/aries-framework-dotnet Connect.Me (https://connect.me/) was built using Indy libs: https://github.com/hyperledger/indy-sdk/tree/master/vcx As for the Java Script libraries in Aries like https://github.com/hyperledger/aries-sdk-javascript, https://github.com/hyperledger/aries-framework-javascript/ these should be just migrated Indy wrappers, but I am not completely sure. I would post a question in the #aries channel for more info about this. At this moment I think that libvcx is still the most mature lib, and although it lives in the Indy repo efforts were made for it to be Aries compliant (as demonstrated a week or two ago to the wider community). It also has a node wrapper: https://github.com/hyperledger/indy-sdk/tree/master/vcx/wrappers/node More experienced mobile dev can chime in here and probably give you more/better advice.

redongjun (Wed, 18 Dec 2019 13:28:51 GMT):
Has joined the channel.

SergeyBrazhnik (Wed, 18 Dec 2019 14:06:54 GMT):
Hello everyone. Could somebody advise why I could receive this response on submitRequest which sends buildCredDefRequest ``` { "result": { "ref": 12, "origin": "9GaTA17XUh1CdhZGDxzqDN", "reqId": 1576663115601194000, "signature_type": "CL", "type": "108", "seqNo": null, "data": null, "txnTime": null, "tag": "TAG1", "identifier": "4x3t3h9DMiYQoSC3eL5XZw", "state_proof": { "root_hash": "2Q8MrvaWeABkW9813wb5mmJrzA9Pwgvfcx25jL6f3CiC", "proof_nodes": "+QEm+FGAgICAgKAU+NsZrV9qQyjosI61DIlIR5wArlOt1PEK6gDCwQLpwKDvzDh0sWQPW+dfj2NxzjTXlVmiey3G9WkzrIvvqfJWxoCAgICAgICAgID40aDoC9i9ddsFwSzDx9QOJrimJGdIVCjGtvVPrqFC0DWX3oCAoB9wwpllxA+X8t49Z\\/PFbLCJRvL+XxcC9rpPLcQyQQ1QoCNdM+ePW1jKGCkxyWjCvqd109+AjDFNvsbg19k+bwY+gKDC\\/iQV04UhyvMSjhs2DuyXJGM+712z8v7fdNVBqzLOOoCAgICAoPtjKWcl+m60t4zaFFe2hH9DBzwioTq1XIXhmjCIb8bLgICgXfEk6qNPV1HxwmosvUolWgp9i+qntkik5\\/R2dsw3v26A", "multi_signature": { "signature": "QzSn68nKUZL4Xc1XUig2DYSGg6FGtddkwiREinAheUufQP8Wda3GPZz6tsdZiGQpS6syeurRuAqXGUmNjnwJQEfefCEdCmjEytWeiLBkrZ5fmnkTiZP2oPEiiYuwA6BdJrvb2Ty7cRdTBHAiLkKPnyLAAqNqr5rgpvkSBKmBAyhYST", "value": { "ledger_id": 1, "state_root_hash": "2Q8MrvaWeABkW9813wb5mmJrzA9Pwgvfcx25jL6f3CiC", "timestamp": 1576662694, "pool_state_root_hash": "3utJ5Yb615WzQh9jaA3tFU56zze8XGqAcNZY43zakYvc", "txn_root_hash": "2ky1sVvH6wtMsqA6NmYaZ49ADnP6zqHYjUBeABnrM1w7" }, "participants": [ "Node1", "Node2" ] } } }, "op": "REPLY" } ```

SergeyBrazhnik (Wed, 18 Dec 2019 14:07:03 GMT):
data is null

harrywright (Wed, 18 Dec 2019 17:41:53 GMT):
Has joined the channel.

mwenyan (Thu, 19 Dec 2019 18:56:57 GMT):
Has joined the channel.

mwenyan (Thu, 19 Dec 2019 18:56:58 GMT):
I am getting "java.lang.UnsatisfiedLinkError: Unable to load library 'indy': Native library (darwin/libindy.dylib)" with java wrapper, I set -Djna.library.path=/usr/local/Cellar/openssl/1.0.2r/lib:/Users/mwenyan@tibco.com/indy/indy-sdk/libindy/target/debug, but indy-cli works with LD_LIBRARY_PATH AND DYLB_LIBRARY_PATH set to the value.

mwenyan (Thu, 19 Dec 2019 18:57:25 GMT):
has any one encountered the same issue? how to resolve this?

akshay.sood (Mon, 23 Dec 2019 11:52:47 GMT):
Hi guys I am trying to run sample java sdk but I am getting this error when running it using IntelliJ Idea ```/Library/Java/JavaVirtualMachines/openjdk-12.0.2.jdk/Contents/Home/bin/java "-javaagent:/Applications/IntelliJ IDEA.app/Contents/lib/idea_rt.jar=56103:/Applications/IntelliJ IDEA.app/Contents/bin" -Dfile.encoding=UTF-8 -classpath /Users/akshaysood/dev/INDY/indy-sdk/samples/java/target/classes:/Users/akshaysood/.m2/repository/junit/junit/4.12/junit-4.12.jar:/Users/akshaysood/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar:/Users/akshaysood/.m2/repository/org/apache/commons/commons-lang3/3.5/commons-lang3-3.5.jar:/Users/akshaysood/.m2/repository/commons-io/commons-io/2.5/commons-io-2.5.jar:/Users/akshaysood/.m2/repository/org/json/json/20160810/json-20160810.jar:/Users/akshaysood/.m2/repository/org/hyperledger/indy/1.10.1-dev-1219/indy-1.10.1-dev-1219.jar:/Users/akshaysood/.m2/repository/net/java/dev/jna/jna/4.4.0/jna-4.4.0.jar:/Users/akshaysood/.m2/repository/org/slf4j/slf4j-api/1.7.26/slf4j-api-1.7.26.jar Main Anoncreds sample -> started SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. Exception in thread "main" java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.InvalidStateException: The SDK library experienced an unexpected internal error. at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395) at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2070) at Anoncreds.demo(Anoncreds.java:27) at Main.main(Main.java:4) Caused by: org.hyperledger.indy.sdk.InvalidStateException: The SDK library experienced an unexpected internal error. at org.hyperledger.indy.sdk.IndyException.fromSdkError(IndyException.java:114) at org.hyperledger.indy.sdk.IndyJava$API.checkResult(IndyJava.java:92) at org.hyperledger.indy.sdk.pool.Pool.access$100(Pool.java:20) at org.hyperledger.indy.sdk.pool.Pool$1.callback(Pool.java:52) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:520) at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:551)```

jragard (Mon, 23 Dec 2019 23:12:17 GMT):
Has joined the channel.

jragard (Mon, 23 Dec 2019 23:12:19 GMT):
Hello all...I am a mid level developer looking to get more involved in blockchain development, and recently learned about this project. Very cool stuff. I am still learning (I have a couple of small side projects using Solidity smart contracts), but I would love to contribute in any way that I can. I have just opened a PR to correct a broken url and typo in the documentation. The Contributors Guide said I should announce it here...the JIRA ticket is here https://jira.hyperledger.org/browse/IS-1458 -- I have already changed the status to 'Code Review'...the PR is here https://github.com/hyperledger/indy-sdk/pull/2003 The Contributor's Guide also says to tag someone to review, and then assign the ticket to my reviewer...how does that work? Do I just pick someone in this channel, or the collaborators/maintainers list? Thanks for any help ahead of time

akshay.sood (Tue, 24 Dec 2019 14:02:45 GMT):
Hi guys I am trying to run the default INDY nodejs sample on my macos but I am getting this error ```(node:4810) UnhandledPromiseRejectionWarning: IndyError: PoolLedgerTimeout at Object.callback (/Users/akshaysood/dev/INDY/indy-sdk/samples/indy-demo/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10) (node:4810) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1) (node:4810) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.``` Where as the same setup is running on an ubuntu machine

RohitShitre (Tue, 24 Dec 2019 15:31:55 GMT):
Has joined the channel.

dalesupa22 (Tue, 24 Dec 2019 16:13:16 GMT):
Has joined the channel.

leon_dobnik (Thu, 26 Dec 2019 11:14:15 GMT):
I am working on iOS an trying to replicate Alice's client

leon_dobnik (Thu, 26 Dec 2019 11:16:00 GMT):
I plan to implement establish connection (receive invitation) - with exception of following the python's code, is there any flowChart, examples req/res how can such connection be established. As far as I know the Faber creates invitation, alice processes such invitation - but from here tracking via python's code is quite hard.

swcurran (Thu, 26 Dec 2019 17:24:02 GMT):
The flow is defined in https://github.com/hyperledger/aries-rfcs/tree/master/features/0160-connection-protocol However, what the agent does to respond to the invitation and prepare the `request` message is implementation specific, hence the complexity. Offhand it will likely be at least creating a message thread (to be able to recognize the `response`), creating a connection object, creating a DID for the connection object (including the keypair for the DID). There may be other things needed, depending on factors such as whether the agent uses a mediator.

biligunb (Fri, 27 Dec 2019 09:56:08 GMT):
Has joined the channel.

biligunb (Fri, 27 Dec 2019 10:20:21 GMT):
Hi guys I am a Fabric developer. Looking to integrate Fabric with Indy. Is there any tutorial or example projects that I can look over and try?

tomislav (Fri, 27 Dec 2019 15:31:23 GMT):
Only plans and designs how to do integration. Essentially, you're looking to update the authorization component of Fabric to work with DID's instead users and certificates

biligunb (Sun, 29 Dec 2019 23:00:46 GMT):
Yes. you are right. Fabric with Indy (instead of FabricCA) Can you point me to the url or such?

ShamGir (Thu, 02 Jan 2020 08:38:25 GMT):
Guys, how can we use interoperability in indy network and how can we follow W3C standards in Indy Identity

ShamGir (Thu, 02 Jan 2020 09:06:58 GMT):
Guys, how can I revoke any specific credential of a specific user ? *anoncreds.issuer_revoke_credential* revoke all credentials on specific schema or any specific credential ??

paliwalg (Thu, 02 Jan 2020 09:36:25 GMT):
I am using Aries .Net SDK with android mobile, and I am facing problem with the API call Pool.CreatePoolLedgerConfigAsync(poolName, poolConfig). It is failing with the exception IInvalidStructureException. My Pool Config is {"genesis_txn":"/data/user/0/com.osma/files/pool_genesis.txn"}. There is valid genesis file at the path "/data/user/0/com.osma/files/pool_genesis.txn". Not sure what I am missing here or doing wrong ? Does it have anything to do with slashes in the path ?

paliwalg (Thu, 02 Jan 2020 09:36:25 GMT):
I am using Aries .Net SDK with android mobile, and I am facing problem with the API call Pool.CreatePoolLedgerConfigAsync(poolName, poolConfig) of .Net Indy SDK. It is failing with the exception IInvalidStructureException. My Pool Config is {"genesis_txn":"/data/user/0/com.osma/files/pool_genesis.txn"}. There is valid genesis file at the path "/data/user/0/com.osma/files/pool_genesis.txn". Not sure what I am missing here or doing wrong ? Does it have anything to do with slashes in the path ?

sklump (Thu, 02 Jan 2020 11:58:23 GMT):
See https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/tests/interation/test_interaction.py: revocation operates on one credential, as its revocation registry id and credential revocation id specify.

ShamGir (Thu, 02 Jan 2020 12:03:13 GMT):
Yes I have it many times.

ShamGir (Thu, 02 Jan 2020 13:01:51 GMT):
Ohhh, it means we can revoke any specific credential with *anoncreds.issuer_revoke_credential*, thanks bro

ap (Fri, 03 Jan 2020 06:00:22 GMT):
]

tomislav (Sun, 05 Jan 2020 14:47:29 GMT):
This would either be an issue with read/write permissions on Android, or the genesis file content has been modified. Libindy can be picky about line endings. I suggest you copy a working file and see if that works before modifying it. Using an editor that adds CRLF endings will mess up libindy.

paliwalg (Tue, 07 Jan 2020 04:28:55 GMT):
It worked now, I think it was CRLF endings issue only, also Pool.OpenPoolLedgerAsync() was failing with error code 307. Passing the timeout in the config("{\"timeout\":20,\"extended_timeout\":80}") fixed it.

ashlinSajan (Tue, 07 Jan 2020 09:14:28 GMT):
@tomislav Pair wise DIDs used by Identities built on Indy are creating an issue for me. I need an identity to sign a message whose origin can be verified by any recipient of the message - I can assume that all recipients have a connection with the originating identity. I are using a signing facility provided by Indy/Aries agents but that seem to be specific to one pairwise connection even though signer uses a public DID. I am considering self-issued credentials as a work around but I would like to explore simpler options before I do that as it will proliferate the number of credentials created. A second option is to use Indy credentials as PKI certs with public key as an attribute. This requires that the key management, signing and verification to be done by the application external to the Aries/Indy agents. What is the recommended practice or is there a third option?

JeromeK (Tue, 07 Jan 2020 09:40:34 GMT):
Could this help? https://github.com/hyperledger/indy-sdk/blob/f708f496dd23ada341303db7a4e6a0a7e29a549f/wrappers/python/indy/crypto.py#L117

PatrikStas (Tue, 07 Jan 2020 09:47:28 GMT):
Hi all, announcing Indyscan 3.x, now with fulltext search, sorting and improved UI. Check out http://indyscan.io Also much easier to run on your localhost!

PatrikStas (Tue, 07 Jan 2020 09:47:28 GMT):
Hi all, announcing Indyscan 3.x, now with fulltext search, sorting and improved UI. Check out https://indyscan.io Also much easier to run on your localhost!

PatrikStas (Tue, 07 Jan 2020 09:47:28 GMT):
Hi all, announcing Indyscan 3.x, now with fulltext search, sorting and improved UI. Check out [indyscan.io](https://indyscan.io) Also much easier to run on your localhost!

ShamGir (Tue, 07 Jan 2020 14:18:57 GMT):
have you find any method to get this format ?? @SigmaS 1

SigmaS 1 (Tue, 07 Jan 2020 15:05:28 GMT):
Not yet, but I found this API https://github.com/hyperledger/indy-sdk/blob/master/docs/how-tos/fully-qualified-did-support.md and as I understand you could create the JSON format DID by yourself. Please let me know if you find something else.

aaronr (Tue, 07 Jan 2020 15:41:18 GMT):
Not sure if this is the right place to ask this, would appreciate pointers in the right direction if it is not. Consider a scenario where I have mutliple verifiable credentials that are all based on the same credential schema, possibly all from the same issuer (so cred def for all could be the same). Perhaps like Microsoft skills certifications or inspections issued by a city government. And I want to submit all of them or a subset of them in a proof response. Is that possible? All of the proof requests that I've seen examples of seem to only allow for the user to respond with one trait value from one qualifying credential for each requested trait in the proof request. Am I missing something? Or is this a scenario that is currently unsupported?

aaronr (Tue, 07 Jan 2020 15:41:18 GMT):
I guess I don't understand what you mean by "if a proof includes multiple credentials on the same credential definition". Do you mean if I have two credentials issued by the same issuer against the same cred def I can't satisfy a proof using traits from both (like my name from one and a phone number from the other)?

sklump (Tue, 07 Jan 2020 16:20:48 GMT):
You can prove multiple attributes from a credential, but there is a correlation attack vector if a proof includes multiple credentials on the same credential definition. So indy-sdk flags such a proof as invalid.

sklump (Tue, 07 Jan 2020 16:20:48 GMT):
You can prove multiple attributes from a credential, but there is a correlation attack vector (I don't know the details, I just took an indy dev's word for it years ago and tucked it away) if a proof includes multiple credentials on the same credential definition. So indy-sdk flags such a proof as invalid.

andrew.whitehead (Tue, 07 Jan 2020 16:23:42 GMT):
I wonder if correlation is a risk when each credential is on a separate proof?

sklump (Tue, 07 Jan 2020 16:25:27 GMT):
That's different: everything within one proof is linked together via the master secret, but one master secret commitment is not correlatable to another master secret commitment. Anyone may correct me when I make a mistake here.

sklump (Tue, 07 Jan 2020 16:29:07 GMT):
*Question:* Until recently, indy-sdk raised an `AnoncredsCredDefAlreadyExistsError` when an issuer tried to `anoncreds.issuer_create_and_store_credential_def()` for a cred def that already was in the wallet and/or on the ledger. I see now that it doesn't anymore. Would someone in the indy group please confirm that this is on purpose?

aaronr (Tue, 07 Jan 2020 16:37:20 GMT):
so you mean that I can't have two credentials from the same issuer and use parts of both to satisfy a proof (for example, my name from one and a phone number from another)?

aaronr (Tue, 07 Jan 2020 16:38:35 GMT):
even if the proof is only restricting based on credential schema and not credential definition?

aaronr (Tue, 07 Jan 2020 16:38:35 GMT):
even if the proof request is only restricting based on credential schema and not credential definition?

sklump (Tue, 07 Jan 2020 16:40:47 GMT):
You can have multiple creds from one issuer in the same proof if they are not on the same cred def. One could be for membership and the other for user preferences, for example.

sklump (Tue, 07 Jan 2020 16:42:20 GMT):
If you want multiple attributes from one cred, see the latest updates in proof request restrictions: https://drive.google.com/open?id=1QJgmghL_v01ZlsVL0Tk-X4c3-EidWFp_

sklump (Tue, 07 Jan 2020 16:42:20 GMT):
If you want multiple attributes from one cred, see the latest ("names" list for attributes) in proof request restrictions: https://drive.google.com/open?id=1QJgmghL_v01ZlsVL0Tk-X4c3-EidWFp_

aaronr (Tue, 07 Jan 2020 16:44:33 GMT):
sure, but I'm thinking of something like a renewing certification where I could acquire multiple of the same one or a community college that issues course completion credentials. So the courses would be different but would have the same cred def since coming from same issuer and have the same structure

sklump (Tue, 07 Jan 2020 16:50:28 GMT):
So as per the document, use ``` { "nonce": "1234567890", "name": "proof-req", "version": "0.0", "requested_attributes": { "18_uuid": { "names": ["realAnalysis", "physics"] "restrictions": { "schema_id": "LjgpST2rjsoxYegQDRm7EL:2:transcripts:1.0" } } }, "requested_predicates": {} } ```

aaronr (Tue, 07 Jan 2020 17:15:45 GMT):
Thank you for the document pointer, it was helpful. Along similar lines, lets say I have 3 certifications that conform to the same schema but issued by different institutions (like IBM, Microsoft and RedHat). If a proof request (e.g. job application) asks for a name of a certification conforming to the schema, is there a way for the prover to provide the values of all three certifications in the proof response?

aaronr (Tue, 07 Jan 2020 17:18:16 GMT):
If I am missing some obvious knowledge about proof requests and responses, would love a pointer to the documentation that discusses it. The knowledge I have is mostly from asking around and googling

sklump (Tue, 07 Jan 2020 17:26:02 GMT):
The prover can search wallet credentials on the six criteria: * schema id (=schema-issuer DID, schema name, schema version) * schema issuer DID * schema name * schema version * cred def id * cred def issuer DID. Any further criteria can go into supplemental WQL by referent (it's gnarly) or you can filter matches as they come out of the wallet. Some code lives here: https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/master/von_anchor/anchor/holderprover.py and in the indy-sdk wrapper tests.

sklump (Tue, 07 Jan 2020 17:26:02 GMT):
The prover can search wallet credentials on the six criteria: * schema id (combining schema-issuer DID, schema name, schema version) * schema issuer DID * schema name * schema version * cred def id (combining cred def issuer DID, schema id or (typically) seq no, tag) * cred def issuer DID. Any further criteria can go into supplemental WQL by referent (it's gnarly) or you can filter matches as they come out of the wallet. Some code lives here: https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/master/von_anchor/anchor/holderprover.py and in the indy-sdk wrapper tests.

smithbk (Wed, 08 Jan 2020 13:21:29 GMT):
According to @MALodder, there is no risk of correlation if a single proof is generated using multiple credentials with the same cred def id; therefore, this should be allowed. Mike, any other comment?

sklump (Wed, 08 Jan 2020 13:32:34 GMT):
_ Give me some time, I will see if indy-sdk still forbids proof creation on repeat cred def ids _

sklump (Wed, 08 Jan 2020 13:32:34 GMT):
_ Give me some time, I will see if indy-sdk still forbids proof creation and/or fails validation of same on repeat cred def ids _

MALodder (Wed, 08 Jan 2020 14:01:50 GMT):
I don’t understand why this restriction is in place. This should be allowed.

sbouma (Wed, 08 Jan 2020 15:29:43 GMT):
Has joined the channel.

sbouma (Wed, 08 Jan 2020 15:29:44 GMT):
Hi there, when I try to verify a proof that contains a revealed attribute it is rejected. Does anyone know why this happens and how I can generate proofs that will not be rejected?``` ```

sbouma (Wed, 08 Jan 2020 15:31:10 GMT):
Proof request ``` { "name": "user_profile", "requested_attributes": { "last_name_indy": { "name": "last_name", "restrictions": { "cred_def_id": "Th7MpTaRZVRYnPiabds81Y:3:CL:13:user_profile" } } }, "nonce": "585305624087965441715318", "version": "0.0.1", "requested_predicates": {} } ```

sbouma (Wed, 08 Jan 2020 15:31:10 GMT):
Proof request `{ "name": "user_profile", "requested_attributes": { "last_name_indy": { "name": "last_name", "restrictions": { "cred_def_id": "Th7MpTaRZVRYnPiabds81Y:3:CL:13:user_profile" } } }, "nonce": "585305624087965441715318", "version": "0.0.1", "requested_predicates": {} }`

sbouma (Wed, 08 Jan 2020 15:31:46 GMT):
Requested credentials``` { "self_attested_attributes": {}, "requested_predicates": {}, "requested_attributes": { "last_name_indy": { "cred_id": "37da7dd2-1773-4bbf-bf88-7df96a5d0c2a", "revealed": true } } } ```

sklump (Wed, 08 Jan 2020 15:39:47 GMT):
Nonce has to start with "1" if I recall correctly.

sklump (Wed, 08 Jan 2020 15:39:47 GMT):
Nonce has to start with "1" if I recall correctly?

sbouma (Wed, 08 Jan 2020 15:53:06 GMT):
I just gave that a try but the proof is still being rejected. The nonce is generated with the Indy SDK.

sbouma (Wed, 08 Jan 2020 15:54:58 GMT):
The proof passes the verification when the attribute is set to unrevealed.

sklump (Wed, 08 Jan 2020 16:09:05 GMT):
Does the cred def have revocation support? If so, the requested-creds structure needs timestamp(s).

sklump (Wed, 08 Jan 2020 16:23:41 GMT):
Otherwise, I don't see anything wrong.

sbouma (Wed, 08 Jan 2020 16:27:39 GMT):
No the cred def does not support revocation. I'll probably just have to play with the code a bit more.

sklump (Wed, 08 Jan 2020 16:39:56 GMT):
Start with the wrapper tests and work toward your objective one change at a time.

sbouma (Wed, 08 Jan 2020 16:55:34 GMT):
That's a good idea. Thanks!

MALodder (Wed, 08 Jan 2020 19:12:41 GMT):
Are you passing the raw revealed attribute value or the hash of it to verify?

sklump (Wed, 08 Jan 2020 19:20:49 GMT):
So it turns out that this restriction is no longer in place. I am certain that it used to be. That much sticks a fork in von_anchor for good, if anyone is still using it. There will be repercussions in aca-py proof presentation too, I will have to take a look.

ShamGir (Thu, 09 Jan 2020 06:39:38 GMT):
sure and Thanks

ShamGir (Thu, 09 Jan 2020 09:53:56 GMT):
Hi, guys I am facing issue in indy_quality_did java-sdk. Error: "Error looking up function 'indy_qualify_did': undefined symbol: indy_qualify_did"

sklump (Thu, 09 Jan 2020 11:29:11 GMT):
So it turns out that there is no such restriction. I am certain that it used to be there, but it's gone now. The implications are kind of seismic but I will put in fixes as soon as possible, starting with aca-py.

JeromeK (Thu, 09 Jan 2020 15:00:36 GMT):
https://chat.hyperledger.org/channel/indy?msg=BtiYLRZf5HGfJ3xqo Link to a question of mine. Could also be posted here

Sukalpo (Sun, 12 Jan 2020 13:43:40 GMT):
Has joined the channel.

sergey.minaev (Mon, 13 Jan 2020 09:17:44 GMT):
@sklump yes, it's on puprose. Now it just return the previously generated public part. For DID creation there are similar changes but with more nuances: it double checks, that input parameters doesn't contradict to existing info in a wallet

sergey.minaev (Mon, 13 Jan 2020 09:25:21 GMT):
the value of `key` parameter is used as an import for key derivation function. And the result of KDF is used for encryption inside the wallet service of libindy. You can find some info about encryption at design docs https://github.com/hyperledger/indy-sdk/tree/master/docs/design/003-wallet-storage#wallet-encryption . In general you SHOULD NOT decrypt the wallet as libindy user. But if you are trying to decrypt for debugging purpose - it may be fine

RunaStaph (Mon, 13 Jan 2020 14:48:14 GMT):
Has joined the channel.

ShamGir (Thu, 16 Jan 2020 11:27:42 GMT):
Hello guys, I am facing a problem on working indy-sdk version 1.14.1. When I run my Android application I got this error "library "libc++_shared.so" not found", But when I add it, my application crashed when I call create wallet method of indy-sdk.

rileyphughes (Thu, 16 Jan 2020 22:19:36 GMT):
Has joined the channel.

bariscimen (Sat, 18 Jan 2020 11:04:03 GMT):
Has joined the channel.

EdEykholt (Mon, 20 Jan 2020 03:32:08 GMT):
Has joined the channel.

ShamGir (Mon, 20 Jan 2020 09:53:17 GMT):
Hello guys, I am facing this issue when create a wallet in new indy-sdk version 1.14.1 Attempt to invoke interface method 'int org.hyperledger.indy.sdk.LibIndy$API.indy_create_wallet(int, java.lang.String, java.lang.String, com.sun.jna.Callback)' on a null object reference

ekubilay (Mon, 20 Jan 2020 16:35:02 GMT):
Hello everyone, could any of you tell me where the value of revRegDefTag(Revocation registry definition tag) is stored? Many thanks in advance!

ShamGir (Tue, 21 Jan 2020 07:56:47 GMT):
Hello guys, anyone can tell me, what data is stored in "setDidMetadata" method of indy-sdk ??

heenas06 (Wed, 22 Jan 2020 06:20:50 GMT):
Hi guys ,I have to develop one indy-sdk application so can you please guide me in this or else anyone having documents....

ShamGir (Wed, 22 Jan 2020 06:25:21 GMT):
You can read walk-through of indy-sdk. here is the link https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/indy-walkthrough.md

JeromeK (Wed, 22 Jan 2020 09:54:22 GMT):
Did somebody ever had this kind of error, while creating a Credential? Caused by: UrsaCryptoError: Value by key 'hash_payload' not found in pk.r

JeromeK (Wed, 22 Jan 2020 09:54:22 GMT):
Did somebody ever had this kind of error, while creating a Credential? Caused by: UrsaCryptoError: Value by key 'payload' not found in pk.r

JeromeK (Wed, 22 Jan 2020 09:54:22 GMT):
Did somebody ever had this kind of error, while creating a Credential? Caused by: UrsaCryptoError: Value by key 'payload' not found in pk.r (payload is an attribute of the cred)

dbukrek (Wed, 22 Jan 2020 11:16:21 GMT):
Has joined the channel.

futurama92 (Wed, 22 Jan 2020 20:20:17 GMT):
Has joined the channel.

futurama92 (Wed, 22 Jan 2020 20:20:18 GMT):
Hi guys, i'm build a proof with credentials, but right now the attributes are only self attributes. The method verify proof check also this attributes or only the requested? thanks

sklump (Thu, 23 Jan 2020 14:44:16 GMT):
There is no cryptographic verification of self-attested attributes. Anyone can make up any self-attested claim.

ShamGir (Fri, 24 Jan 2020 11:47:06 GMT):
Guys, where we add did-document on user-wallet or on Ledger ??

swcurran (Fri, 24 Jan 2020 15:09:10 GMT):
Both. If you are putting the DID on the ledger, you create it and store it in your wallet and then you create a transaction to write to the Ledger. Because Indy does not currently format the data as a DIDDoc yet, additional transactions to write attributes of the DID are written to the ledger as well, notably the endpoint of the DID. That has been evolving and I'm not exactly certain what additional ATTRIB transactions are needed. If you are creating a private, pairwise DID, you create it in your wallet and then you transmit it to the other party via a message. This is core to how Aries agents work - communicating using messages secured using private, pairwise DIDs.

FarhanShafiq (Mon, 27 Jan 2020 08:12:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=Q2R6JoHvkeyXWH53W) Thanks @swcurran and sorry for asking naive question, Is private did (pairwise did) should go to ledger or not and what it's applications compare to did on the ledger?

ShamGir (Mon, 27 Jan 2020 13:17:13 GMT):
Thanks @swcurran , for the response. It was the first time, I get response on my question :stuck_out_tongue_winking_eye: . I also though same solution as Indy is doesn't provide any facility to store document on Ledger. My question is that, "is it mandatory to store did-document on Ledger or it is optional ?"

swcurran (Mon, 27 Jan 2020 14:13:34 GMT):
A private DID does not go to the ledger. It is given directly to the entity you are establishing a connection with, and vice versa. They don't go on a ledger, because no one else has to see them - just the two parties involved. I did a video covering this for the edX course we created: https://www.youtube.com/watch?v=EKH7vjp_P9o&t=2s

ShamGir (Mon, 27 Jan 2020 14:38:26 GMT):
Thanks @swcurran , nice video and beautifully explained, I get all answers

drew-streetcred (Mon, 27 Jan 2020 16:05:17 GMT):
Has joined the channel.

mattatkiva (Mon, 27 Jan 2020 16:23:20 GMT):
I was wondering what the best practices are for deleting a credential. Is revocation working and should the credential be revoked first? and last question, if I delete a credential without revoking it, what happens if I try creating it again? thnx

brrussell (Mon, 27 Jan 2020 16:53:51 GMT):
Has joined the channel.

brrussell (Mon, 27 Jan 2020 16:53:51 GMT):
I'm trying to use libindy and libindy-objc wrapper. I can create a wallet, open the wallet, create and store my did, and create a pool, but then when I try to open the pool, I get "thread '' panicked at 'FIXME: Operation not supported', src/libcore/result.rs:1165:5". zmq says the context and socket are dropped. I've tried the same genesis file on Android and Python and it works there. Any suggestions?

brrussell (Mon, 27 Jan 2020 16:55:20 GMT):
I'm using the cocoapods for libindy, open ssl, zmq and libsodium. For the wrapper, I have to copy the files in directly because the pre-built framework is using an old version of swift that I can't build with

daveek (Mon, 27 Jan 2020 19:55:58 GMT):
Has joined the channel.

daveek (Mon, 27 Jan 2020 19:56:36 GMT):
I'm working with Hyperledger Indy-SDK Library. I want to connect indy-sdk with web server through REST Api and perform operations, how to do so? Forexample, Here is a tutorial of How To Write a DID and Query Its Verkey. So, for this, one has to run indy_pool in docker and paste this code in Python IDE and run it inorder to perform the task. Now, I want to write a Did or Issue a Did or perform any task by sending a request through API. Is this Possible and yes, then how? Thanks

daveek (Tue, 28 Jan 2020 07:57:44 GMT):
@swcurran

JeromeK (Tue, 28 Jan 2020 08:53:48 GMT):
Hey Guys Question: When calling this create_proof with a non-revoce credential I get the error that Revocation Registry ID not found. `async def prover_create_proof(wallet_handle: int, proof_req_json: str, requested_credentials_json: str, master_secret_name: str, schemas_json: str, credential_defs_json: str, rev_states_json: str) -> str:`

JeromeK (Tue, 28 Jan 2020 08:55:30 GMT):
Also when reading out the Credential from the Wallet there is no cred_rev_id. So is it now mandatory to only have rev-credentials?

JeromeK (Tue, 28 Jan 2020 08:56:20 GMT):
I assume it's not, so how can i structure the request to accept non-revoke-creds?

sklump (Tue, 28 Jan 2020 15:03:14 GMT):
The issuer is the only entity who can revoke a credential. The issuer gets the cred_rev_id upon creation of a credential on a cred def with revocation support. See `https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/tests/anoncreds/test_prover_create_proof.py` for a sample with proof creation on a non-revocable credential: use `rev_states_json={}`.

sklump (Tue, 28 Jan 2020 15:04:23 GMT):
For a worked example with revocable credentials, consult `https://github.com/hyperledger/indy-sdk/blob/master/wrappers/python/tests/interation/test_interaction.py`.

futurama92 (Tue, 28 Jan 2020 19:55:23 GMT):
thanks ;)

abdfaye (Wed, 29 Jan 2020 10:47:51 GMT):
Hi guys, I was wondering if there is a way to create a proof request with some optional attributes for the verification. Thanks

sklump (Wed, 29 Jan 2020 13:54:00 GMT):
No. Request the attributes you want to see. The holder can always refuse: asking is not telling.

Milos22 (Fri, 31 Jan 2020 09:42:04 GMT):
Has joined the channel.

Milos22 (Fri, 31 Jan 2020 09:42:05 GMT):
Hi @sklump thanks for your answeri, we do use rev_states_json={} in the create proof signature but we still get the Revocation Registry ID error

Milos22 (Fri, 31 Jan 2020 09:42:05 GMT):
Hi @sklump thanks for your answer, we do use rev_states_json={} in the create proof signature but we still get the Revocation Registry ID error

Milos22 (Fri, 31 Jan 2020 09:42:05 GMT):
Hi @sklump thanks for your answer, we still get error

Milos22 (Fri, 31 Jan 2020 09:42:05 GMT):
Hi @sklump thanks for your answer, we still get the same error

Milos22 (Fri, 31 Jan 2020 09:42:05 GMT):
Hi @sklump thanks for your answer, we still get the same error even using rev_states_json={}

sklump (Fri, 31 Jan 2020 11:58:13 GMT):
1: "non-revoce credential": what do you mean here: a credential that is not revoked, or a credential that is not revocable (its cred def has {"support_revocation": false} in its config)? 2: Who is trying to revoke? If it is the issuer, why are you going to the wallet? The issuer does not hold the credential: only the prover does.

Milos22 (Fri, 31 Jan 2020 12:41:55 GMT):
1: A credential that is not revocable, the cred def has "support_revocation:false"

Milos22 (Fri, 31 Jan 2020 12:41:55 GMT):
1: A credential that is not revocable, the cred def has "support_revocation:false" 2: We are not trying to revoke but to call create_proof for the verification flow

sklump (Fri, 31 Jan 2020 12:56:50 GMT):
OK, what does the proof request look like? It should look like this: ``` { "nonce": "1042130321436287373092476", "name": "proof_req", "version": "0.0", "requested_predicates": {}, "requested_attributes": { "17_preferredname_uuid": { "restrictions": [ { "cred_def_id": "LjgpST2rjsoxYegQDRm7EL:3:CL:17:0" } ], } "name": "favourite" } } } ``` Notably, it should have no `non_revoked` keys since the credential does not support revocation.

sklump (Fri, 31 Jan 2020 12:56:50 GMT):
OK, what does the proof request look like? It should look like this: ``` ... please stand by ... ``` Notably, it should have no `non_revoked` keys since the credential does not support revocation.

sklump (Fri, 31 Jan 2020 12:56:50 GMT):
OK, what does the proof request look like? It should look like this: ``` { "nonce": "1042130321436287373092476", "name": "proof_req", "version": "0.0", "requested_predicates": {}, "requested_attributes": { "unique_referent": { "restrictions": [ { "cred_def_id": "LjgpST2rjsoxYegQDRm7EL:3:CL:17:0" } ], "name": "favourite" } } } ``` Notably, it should have no `non_revoked` keys since the credential does not support revocation.

sklump (Fri, 31 Jan 2020 12:56:50 GMT):
OK, what does the proof request look like? It should look something like this: ``` { "nonce": "1042130321436287373092476", "name": "proof_req", "version": "0.0", "requested_predicates": {}, "requested_attributes": { "unique_referent": { "restrictions": [ { "cred_def_id": "LjgpST2rjsoxYegQDRm7EL:3:CL:17:0" } ], "name": "favourite" } } } ``` Notably, it should have no `non_revoked` keys since the credential does not support revocation. It may have `requested_predicates`, and the `restrictions` are optional too.

esplinr (Sat, 01 Feb 2020 01:18:36 GMT):
When you say "delete a credential" do you mean deleting from your identity wallet?

esplinr (Sat, 01 Feb 2020 01:21:15 GMT):
This is my understanding: * Revocation is for the issuer to ensure that a credential can't be proven as non-revoked. The issuer can't force the holder to delete anything. * The holder can delete a credential whenever he or she wants, but then cannot ever use it again. The issuer is not notified that the credential isn't available to the user anymore. * If the issuer sends a new credential to the holder that contains the same information, I believe it is treated as a new credential in the holder's wallet regardless of whether the previous credential still exists or is deleted.

esplinr (Sat, 01 Feb 2020 01:21:32 GMT):
This is my understanding: * Revocation is for the issuer to ensure that a credential can't be proven as non-revoked. The issuer can't force the holder to delete anything. * The holder can delete a credential whenever he or she wants, but then cannot ever use it again. The issuer is not notified that the credential isn't available to the user anymore. * If the issuer sends a new credential to the holder that contains the same information, I believe it is treated as a new credential in the holder's wallet regardless of whether the previous credential still exists or is deleted.

futurama92 (Sat, 01 Feb 2020 15:31:23 GMT):
Nonce has to start with "1" if I recall correctly?

futurama92 (Sun, 02 Feb 2020 09:07:41 GMT):
Hi guys, i've a question related to the example on github with alice and acme (https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/indy-walkthrough.md#apply-for-a-job). Acme proof request sets restrictions equal to faber['transcript_cred_def_id'] because it wants to know that attributes from faber's credential. My question is: how does acme know that schema id? is schema id public for "all the world"? Thanks for the answers!!

bootstrapsp (Sun, 02 Feb 2020 20:53:15 GMT):
Hi All, i hope this the right channel to ask this question : I am running into ERROR:indy.libindy:_load_cdll: Can't load libindy: Could not find module 'indy.dll'. Try using the full path with constructor syntax , on Windows platform - i am using the python wrapper in my project

bootstrapsp (Sun, 02 Feb 2020 20:54:30 GMT):
and I do have 1.14\lib (stable) release in my path

bootstrapsp (Sun, 02 Feb 2020 21:05:00 GMT):
do i need to set something other than the env path to get indy to reference the dlls? any hint will be really helpful - thanks!

andrew.whitehead (Sun, 02 Feb 2020 22:05:09 GMT):
@bootstrapsp Try setting LD_LIBRARY_PATH

ekubilay (Mon, 03 Feb 2020 08:54:22 GMT):
Hi everyone :) I'm getting this error when calling proverCreateProof() method of Java wrapper; Error: Invalid Structure Caused By: RevocationState not found by id: RevocationRegistryId("id"). Does anyone have an idea why it might happen? Thanks in advance!

JeromeK (Mon, 03 Feb 2020 10:16:54 GMT):
Okay thanks for the answer. Indeed we had the non_revoked attribute in our proof-request. But even after removing it, we still get the same error

JeromeK (Mon, 03 Feb 2020 10:17:17 GMT):
{'name': 'test', 'version': '1.0', 'nonce': '1510634098442799469896643569951357994022993220715425496984195539712692361492329516888496704695512454697753245809931714563695652834403252667856887149866379360229182738781245269419049974603639450', 'requested_attributes': {'attr1_referent': {'name': 'credentialValidFrom', 'restrictions': [{'cred_def_id': 'E8okL173qK1RctWAR6He3V:3:CL:81680:laborRights1.0'}]}, 'attr2_referent': {'name': 'credentialValidUntil', 'restrictions': [{'cred_def_id': 'E8okL173qK1RctWAR6He3V:3:CL:81680:laborRights1.0'}]}, 'attr3_referent': {'name': 'hashedPayload', 'restrictions': [{'cred_def_id': 'E8okL173qK1RctWAR6He3V:3:CL:81680:laborRights1.0'}]}, 'attr4_referent': {'name': 'payloadStructureID', 'restrictions': [{'cred_def_id': 'E8okL173qK1RctWAR6He3V:3:CL:81680:laborRights1.0'}]}}, 'requested_predicates': {}}

JeromeK (Mon, 03 Feb 2020 10:17:17 GMT):
````{'name': 'test', 'version': '1.0', 'nonce': '1510634098442799469896643569951357994022993220715425496984195539712692361492329516888496704695512454697753245809931714563695652834403252667856887149866379360229182738781245269419049974603639450', 'requested_attributes': {'attr1_referent': {'name': 'credentialValidFrom', 'restrictions': [{'cred_def_id': 'E8okL173qK1RctWAR6He3V:3:CL:81680:laborRights1.0'}]}, 'attr2_referent': {'name': 'credentialValidUntil', 'restrictions': [{'cred_def_id': 'E8okL173qK1RctWAR6He3V:3:CL:81680:laborRights1.0'}]}, 'attr3_referent': {'name': 'hashedPayload', 'restrictions': [{'cred_def_id': 'E8okL173qK1RctWAR6He3V:3:CL:81680:laborRights1.0'}]}, 'attr4_referent': {'name': 'payloadStructureID', 'restrictions': [{'cred_def_id': 'E8okL173qK1RctWAR6He3V:3:CL:81680:laborRights1.0'}]}}, 'requested_predicates': {}}```

JeromeK (Mon, 03 Feb 2020 10:17:20 GMT):
example

JeromeK (Mon, 03 Feb 2020 12:18:13 GMT):
I have exactly the same problem with the python wrapper, let me know if you find something :innocent:

JeromeK (Mon, 03 Feb 2020 12:18:46 GMT):
Did you check that you set the `support_revocation: False`during the cred-def creation?

JeromeK (Mon, 03 Feb 2020 12:19:07 GMT):
https://chat.hyperledger.org/channel/indy-sdk?msg=KutuymT8FGitEa4Xk

JeromeK (Mon, 03 Feb 2020 12:55:12 GMT):
Okay so apparently it works with 1.8.0 but not with a newer version

JeromeK (Mon, 03 Feb 2020 12:55:19 GMT):
Okay so apparently it works with 1.8.0 but not with a newer version

sklump (Mon, 03 Feb 2020 13:26:10 GMT):
https://drive.google.com/open?id=1JhDTPDsY1lKAboAwlBfSrgaV0J86AS5l I can't reproduce this failure. This sample goes into `wrappers/python/tests/interation/` for your consideration.

JeromeK (Mon, 03 Feb 2020 13:39:18 GMT):
Alright thanks, we will have a look and come back to this thread as soon as we fixed it

sklump (Mon, 03 Feb 2020 13:40:36 GMT):
Please do post findings. It will be instructive.

JeromeK (Mon, 03 Feb 2020 13:41:23 GMT):
sure

mwenyan (Mon, 03 Feb 2020 17:36:26 GMT):
trying to run vcx demo with dummy cloud agent, received this error: "POST failed with: IndyError { error_code: CommonInvalidStructure, message: "Error: Invalid structure\n Caused by: Unable to open sodium sealedbox\n", indy_backtrace: Some("") }", anyone know how to fix this? thanks

swcurran (Mon, 03 Feb 2020 17:44:43 GMT):
We could use some verification on a feature - has anyone tried this? We need to determine if we can do a restriction based on ["schema_name", "schema_version", "schema_author_did"] such that proofs that are based on credentials issued from any cred-defs that point to that specific schema are accepted. The idea is we have many issuers producing credentials from the same schema (all with separate cred defs) and a verifier can accept a credential from any of the issuers with out having to explicitly list each issuer. Our understanding is that such a scenario is supported, but our current testing is finding that is not the case and we are not sure why. Does anyone know if this works and even better, do you have test cases such that we could look at the code?

swcurran (Mon, 03 Feb 2020 17:44:43 GMT):
We could use some verification on a feature - has anyone tried this? We need to determine if we can do a restriction based on ["schema_name", "schema_version", "schema_issuer_did"] such that proofs that are based on credentials issued from any cred-defs that point to that specific schema are accepted. The idea is we have many issuers producing credentials from the same schema (all with separate cred defs) and a verifier can accept a credential from any of the issuers with out having to explicitly list each issuer. Our understanding is that such a scenario is supported, but our current testing is finding that is not the case and we are not sure why. Does anyone know if this works and even better, do you have test cases such that we could look at the code?

sklump (Mon, 03 Feb 2020 17:49:41 GMT):
schema_issuer_did

sklump (Mon, 03 Feb 2020 17:49:59 GMT):
If using schema_author_did, there's your problem :-/

swcurran (Mon, 03 Feb 2020 18:09:01 GMT):
We're not

swcurran (Mon, 03 Feb 2020 18:09:01 GMT):
We're not - correctted

swcurran (Mon, 03 Feb 2020 18:09:01 GMT):
We're not - corrected

swcurran (Mon, 03 Feb 2020 18:12:06 GMT):
In our ACA-Py to ACA-Py testing, we're getting a number of scenarios where the credentials are found regardless of the combination of schema_* fields we are using, but the verification is failing, which is very odd. In our other tests, the credentials are not being found by the prover.

swcurran (Mon, 03 Feb 2020 18:12:43 GMT):
The only case that is working through verification is when we just use "schema_id".

sklump (Mon, 03 Feb 2020 18:14:19 GMT):
I seem to be able to reproduce this informally. I am getting data to try with indy-sdk directly.

sklump (Mon, 03 Feb 2020 18:29:15 GMT):
I can create the proof from the proof request, but verification produces the stack trace: ``` File "/home/indy/aries_cloudagent/protocols/present_proof/v1_0/manager.py", line 430, in verify_presentation indy_proof_request, indy_proof, schemas, credential_definitions File "/home/indy/aries_cloudagent/verifier/indy.py", line 126, in verify_presentation json.dumps({}), File "/home/indy/.pyenv/versions/3.6.9/lib/python3.6/site-packages/indy/anoncreds.py", line 1705, in verifier_verify_proof verifier_verify_proof.cb) indy.error.AnoncredsProofRejected ```

swcurran (Mon, 03 Feb 2020 18:33:22 GMT):
We're getting that as well. But the very weird thing is that on another prover agent, we're getting the presentation request not finding any credentials that match. It looks like you are getting past that part - the prover is creating the proof.

sklump (Mon, 03 Feb 2020 18:40:44 GMT):
If the aca-py version is older, it won't supply creds for a proof request if there are plural matches in the wallet for the restrictions (on auto-respond-proof-presentation). Shot in the dark.

swcurran (Mon, 03 Feb 2020 18:46:12 GMT):
Yup...thinking about that.

sklump (Mon, 03 Feb 2020 18:47:23 GMT):
My proof request: ``` { "name": "Proof request", "version": "1.0", "nonce": "1234567890", "requested_attributes": { "0_icon_uuid": { "name": "icon", "restrictions": [ { "schema_issuer_did": "4QxzWk3ajdnEA37NdNU5Kt", "schema_name": "prefs", "schema_version": "1.0" } ] }, "0_favourite_uuid": { "name": "favourite", "restrictions": [ { "schema_issuer_did": "4QxzWk3ajdnEA37NdNU5Kt", "schema_name": "prefs", "schema_version": "1.0" } ] } }, "requested_predicates": {} } ``` Would someone in the know confirm this is correct in the restrictions? A list of one dict with three criteria to mean all apply?

andrew.whitehead (Mon, 03 Feb 2020 19:35:57 GMT):
That looks like what I was testing. Also tested with just `schema_issuer_did` as a restriction

sklump (Mon, 03 Feb 2020 19:40:10 GMT):
Check https://drive.google.com/open?id=1i4dEtPUr8hBfKzZq87aKC3r1ieQvJFQx for puzzling evidence. Drop into `wrappers/python/tests/interation/` and run it: it works fine on indy-sdk 1.14.x. The problem may come down to indy versions.

Artemkaaas (Tue, 04 Feb 2020 08:01:39 GMT):
you need to update dummy-agent config to use `protocol_type`:`2.0`

SigmaS 1 (Tue, 04 Feb 2020 08:23:53 GMT):
Hello people, in order to use fully qualified did e.g. sovrin method I have to update buildNymRequest or to create an new API call with regards to this https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html#crud-operation-definitions ?

JeromeK (Tue, 04 Feb 2020 09:54:23 GMT):
Okay we fixed it

JeromeK (Tue, 04 Feb 2020 09:55:07 GMT):
the problem was that in Libindy 1.8 you could have the timestamp in the create-proof

JeromeK (Tue, 04 Feb 2020 09:55:13 GMT):
which crashed then in 1.14

JeromeK (Tue, 04 Feb 2020 09:55:40 GMT):
so we removed the timestamp (we created it offline) from the proof aswell as the non_revoked as explained by you

JeromeK (Tue, 04 Feb 2020 09:55:49 GMT):
now we figure out something else

JeromeK (Tue, 04 Feb 2020 10:22:08 GMT):
Question: Can it be true that the presentation(libindy) creates a wrong hex-encoding as soon as the cred-values of the cred-attributes containing any "-"? Would be cool if somebody could verify this

JeromeK (Tue, 04 Feb 2020 10:22:40 GMT):
exp: if you have a credential with the following attributes: { "a": "a-b", }

JeromeK (Tue, 04 Feb 2020 10:22:40 GMT):
exp: if you have a credential with the following attributes: are you able to proof it? ```{ "a": "a-b", "b": "b-c", "c": "c-d" }```

sklump (Tue, 04 Feb 2020 11:53:01 GMT):
Libindy does not encode: it is up to the application to encode; https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/6019f0f871ca33b3da52534de8702f5ce9ed1b82/von_anchor/indytween.py#L32 I have proven a credential with the attributes above: https://drive.google.com/open?id=1mmEbB6EiWq3Cc46aLUeeV19Uw6Ci2xEj drop into `wrappers/python/tests/interation/`. You may be thinking of attribute names: use all small letters and no spaces to avoid unpleasant surprises - but hyphens and underscores are also OK.

sklump (Tue, 04 Feb 2020 11:53:01 GMT):
Libindy does not encode: it is up to the application to encode; https://github.com/hyperledger/aries-cloudagent-python/blob/1291e0ae5bf78547dc201c982e9fb9ed8b4f4ea6/aries_cloudagent/messaging/util.py#L106 implements convention. I have proven a credential with the attributes above: https://drive.google.com/open?id=1mmEbB6EiWq3Cc46aLUeeV19Uw6Ci2xEj drop into `wrappers/python/tests/interation/`. You may be thinking of attribute names: use all small letters and no spaces to avoid unpleasant surprises - but hyphens and underscores are also OK.

JeromeK (Wed, 05 Feb 2020 08:42:50 GMT):
Okay thanks for the test, we will have a look and come back to this thread as soon its fixed on our end :)

JeromeK (Wed, 05 Feb 2020 08:45:27 GMT):
Is it possible to get the `cred_id` from an already stored credential?

sklump (Wed, 05 Feb 2020 18:06:50 GMT):
cred_info["referent"]

sklump (Wed, 05 Feb 2020 18:06:50 GMT):
`cred_info["referent"]` holds the `cred_id`

midhun14 (Thu, 06 Feb 2020 10:41:33 GMT):
Has left the channel.

jakubkoci (Thu, 06 Feb 2020 16:55:21 GMT):
Hi all, I built vcx for iOS library recently with my custom bash script and wrote an article about it https://dev.to/jakubkoci/how-to-build-a-vcx-ios-library-f32 Bash script is linked there. If anyone is interested :)

bootstrapsp (Thu, 06 Feb 2020 20:55:42 GMT):
thanks @andrew.whitehead but it still didn't help i get the same error ERROR:wallet_service:Could not find module 'indy.dll'. Try using the full path with constructor syntax.

bootstrapsp (Thu, 06 Feb 2020 20:57:18 GMT):

Clipboard - February 6, 2020 9:57 PM

bootstrapsp (Thu, 06 Feb 2020 20:57:21 GMT):
in fact this time i even tried adding env variable both in Windows + also in Pycharm's config

sheldon.regular (Thu, 06 Feb 2020 21:03:18 GMT):
Has joined the channel.

andrew.whitehead (Thu, 06 Feb 2020 21:28:41 GMT):
Hm, it looks like it might use PATH on windows?

bootstrapsp (Thu, 06 Feb 2020 21:29:02 GMT):
have that in PATH as well

bootstrapsp (Thu, 06 Feb 2020 21:31:57 GMT):
've been really scratching my head on this for past some days, my setup works on Ubuntu 16 - but i have been trying to get this migrated to newer version of Indy but on Windows

bootstrapsp (Thu, 06 Feb 2020 21:33:14 GMT):
esp. to test my lib : https://github.com/bootstrapsp/miu

andrew.whitehead (Thu, 06 Feb 2020 21:42:53 GMT):
Not sure, I'm on a mac. Could be a file permissions error I suppose

jakubkoci (Fri, 07 Feb 2020 12:43:44 GMT):
I'm happy to announce an open-source React Native wrapper around indy library by Absa. It's for both iOS (Swift) and Android (Java). Any contributions are more than welcome. https://github.com/AbsaOSS/rn-indy-sdk

lynn.bendixsen (Fri, 07 Feb 2020 14:57:50 GMT):
In my env I had to set env vars LIBRARY_PATH LD_LIBRARY_PATH and LIBINDY_DIR all to the same place at various times to get different things to work on Mac. I also remember trying to copy the dll (not the approved method) to a place where other DLLs were already being found on Windows with some success last time I worked on windows. There are other env variables for windows mentioned here but I am not sure python uses those... https://github.com/hyperledger/indy-sdk/blob/master/docs/build-guides/windows-build.md

swcurran (Fri, 07 Feb 2020 17:40:12 GMT):
I don't really get the question. Can you add some detail? It looks interesting, but I'm not sure...

darrell.odonnell (Fri, 07 Feb 2020 20:38:26 GMT):
Should faber.py (indy-sdx/vcx/wrapper/python2/demo/faber.py) be working in the current (stable) git repo? I have been able to get as far as step #2 by changing the dummy agent protocol_type value to "2.0" (was "1.0") but that's it so far.

tomislav (Fri, 07 Feb 2020 21:10:26 GMT):
This is incredible work, and if I may add, long overdue for the community. Thank you for putting in the work in this!

jakubkoci (Fri, 07 Feb 2020 21:27:20 GMT):
Thanks a lot.

kukgini (Sun, 09 Feb 2020 03:00:38 GMT):
Hi. I'm trying to test java wrapper using `mvn clean test`.

kukgini (Sun, 09 Feb 2020 03:20:03 GMT):

kukgini - Sun Feb 09 2020 12:19:59 GMT+0900 (KST).txt

kukgini (Sun, 09 Feb 2020 03:20:49 GMT):
Hi. I'm trying to test java wrapper on OS X. indy-pool comes from public docker image and library was built from source code 1.14.2 I ran `mvn clean test` and I got this:

kukgini (Sun, 09 Feb 2020 03:20:49 GMT):
Hi. I'm trying to test java wrapper on OS X. indy-pool comes from public docker image and libindy shared library was built from source code 1.14.2 I ran `mvn clean test` and I got this:

kukgini (Sun, 09 Feb 2020 03:20:49 GMT):
Hi. I'm trying to test java wrapper on OS X. source code version was: 1.14.2 (current rc branch) indy-pool was built with `docker build -f ci/indy-pool.dockerfile -t indy_pool .` I built libindy and copy it to `lib/` and ran `mvn clean test` then I got this:

kukgini (Sun, 09 Feb 2020 03:21:24 GMT):

kukgini - Sun Feb 09 2020 12:21:21 GMT+0900 (KST).txt

kukgini (Sun, 09 Feb 2020 06:52:19 GMT):
Is this a bug or am I missing something?

kukgini (Sun, 09 Feb 2020 07:27:01 GMT):
``` Running org.hyperledger.indy.sdk.anoncreds.ProverDeleteCredentialTest TRACE org.hyperledger.indy.sdk.LibIndy.native.indy.api.anoncreds src/api/anoncreds.rs:1260 | indy_prover_delete_credential: >>> wallet_handle: WalletHandle(205), cred_id: 0x7f9c8874ed00 TRACE org.hyperledger.indy.sdk.LibIndy.native.indy.api.anoncreds src/api/anoncreds.rs:1278 | prepare_result: >>> Ok(()) TRACE org.hyperledger.indy.sdk.LibIndy.native.indy.api.anoncreds src/api/anoncreds.rs:1280 | indy_prover_delete_credential: <<< res: Success DEBUG org.hyperledger.indy.sdk.LibIndy.native.indy.commands src/commands/mod.rs:126 | AnoncredsCommand command received DEBUG org.hyperledger.indy.sdk.LibIndy.native.anoncreds_command_executor src/commands/anoncreds/mod.rs:60 | Prover command received DEBUG org.hyperledger.indy.sdk.LibIndy.native.prover_command_executor src/commands/anoncreds/prover.rs:210 | DeleteCredential command received TRACE org.hyperledger.indy.sdk.LibIndy.native.indy.commands.anoncreds.prover src/commands/anoncreds/prover.rs:663 | delete_credential >>> wallet_handle: WalletHandle(205), cred_id: "idX" TRACE org.hyperledger.indy.sdk.LibIndy.native.indy.api.anoncreds src/api/anoncreds.rs:1272 | prepare_result: >>> Ok(()) TRACE org.hyperledger.indy.sdk.LibIndy.native.indy.api.anoncreds src/api/anoncreds.rs:1273 | indy_prover_delete_credential: # # A fatal error has been detected by the Java Runtime Environment: # SUREFIRE-859: # SIGSEGV (0xb) at pc=0x00007fff659f9c92, pid=94191, tid=23811 # # JRE version: OpenJDK Runtime Environment (13.0.2+8) (build 13.0.2+8) SUREFIRE-859: # Java VM: OpenJDK 64-Bit Server VM (13.0.2+8, mixed mode, sharing, tiered, compressed oops, g1 gc, bsd-amd64) # Problematic frame: # C [libsystem_platform.dylib+0x1c92] _platform_strlen+0x12 # SUREFIRE-859: # No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /Users/.../D/hyperledger/indy/indy-sdk/wrappers/java/hs_err_pid94191.log Compiled method (n/a) 131869 1279 n 0 com.sun.jna.Native::getStringBytes (native) SUREFIRE-859: total in heap [0x0000000113351090,0x00000001133514d8] = 1096 SUREFIRE-859: relocation [0x00000001133511f0,0x0000000113351228] = 56 SUREFIRE-859: main code [0x0000000113351240,0x00000001133514d0] = 656 SUREFIRE-859: oops [0x00000001133514d0,0x00000001133514d8] = 8 Compiled method (n/a) 131876 1279 n 0 com.sun.jna.Native::getStringBytes (native) SUREFIRE-859: total in heap [0x0000000113351090,0x00000001133514d8] = 1096 SUREFIRE-859: relocation [0x00000001133511f0,0x0000000113351228] = 56 SUREFIRE-859: main code [0x0000000113351240,0x00000001133514d0] = 656 SUREFIRE-859: oops [0x00000001133514d0,0x00000001133514d8] = 8 # SUREFIRE-859: # If you would like to submit a bug report, please visit: # http://bugreport.java.com/bugreport/crash.jsp # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # /bin/sh: line 1: 94191 Abort trap: 6 /Library/Java/JavaVirtualMachines/openjdk-13.0.2.jdk/Contents/Home/bin/java -jar /Users/.../D/hyperledger/indy/indy-sdk/wrappers/java/target/surefire/surefirebooter4995280718055143876.jar /Users/.../D/hyperledger/indy/indy-sdk/wrappers/java/target/surefire/surefire14475985638816369989tmp /Users/.../D/hyperledger/indy/indy-sdk/wrappers/java/target/surefire/surefire_013928836008224572821tmp Results : Failed tests: ProverSearchCredentialsTest.testProverSearchCredentialsWorksForEmptyFilter:19 expected:<3> but was:<4> Tests run: 53, Failures: 1, Errors: 0, Skipped: 0 ```

bootstrapsp (Sun, 09 Feb 2020 08:03:02 GMT):
thanks

bootstrapsp (Sun, 09 Feb 2020 08:03:59 GMT):
thanks @lynn.bendixsen I'll give it a try as well

ap (Mon, 10 Feb 2020 10:23:05 GMT):
Hello all,

ap (Mon, 10 Feb 2020 10:23:05 GMT):
Hi everyone , could you please help me out. Not able to access the Url - https://repo.sovrin.org/repository/maven-public

lynn.bendixsen (Mon, 10 Feb 2020 14:55:34 GMT):
@MALodder ^^ ?

ap (Tue, 11 Feb 2020 06:54:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=msNDZtgRuBNguYF6Y) Any updates, @tomislav @jakubkoci @sklump

thanga_troondx (Tue, 11 Feb 2020 09:44:54 GMT):
Has joined the channel.

thanga_troondx (Tue, 11 Feb 2020 09:44:56 GMT):
Hello everyone, is there a way to integrate the DIDs (which are created using indy-sdk) in hyperledger-fabric ?

thanga_troondx (Tue, 11 Feb 2020 09:46:38 GMT):
it is kind of customized msp for hyperledger fabric. I can able to create DID using indy-sdk and I have created a Rest API from where I can onboard the vendors/users. but the thing I need a solution to use these DID in fabric.

thanga_troondx (Tue, 11 Feb 2020 09:46:50 GMT):
looking for help.

ankita.p (Tue, 11 Feb 2020 09:52:03 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=jrLRnFPYuGSewafvj) Anyone have any update on this?

thanga_troondx (Tue, 11 Feb 2020 11:09:17 GMT):
can we store indy wallet credentials in other formats rather than storing it as sqlite.db & sqlite.db-wal. can i store it in .pem or .cert format ?

thanga_troondx (Tue, 11 Feb 2020 11:09:41 GMT):
@lynn.bendixsen @tomislav

JeromeK (Tue, 11 Feb 2020 12:21:28 GMT):
I think you're mixing up the Wallets with credentials etc: please read about the anoncreds-flow here: https://github.com/hyperledger/indy-sdk/blob/master/docs/design/002-anoncreds/anoncreds-workflow.svg and about the wallet-storage here: https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/design/003-wallet-storage/README.html

NikhilPrakash (Wed, 12 Feb 2020 00:47:16 GMT):
Has joined the channel.

kukgini (Wed, 12 Feb 2020 02:05:09 GMT):
Hi everyone. Can anyone see above Java wrapper problem?

gut (Wed, 12 Feb 2020 15:14:38 GMT):
Has joined the channel.

gut (Wed, 12 Feb 2020 15:14:40 GMT):
hi all, im having a segmentation fault in indy-sdk when trying to create a pool with a random name a valid example configuration data. Is this issue already been reported or am I missing something?

jrallen (Thu, 13 Feb 2020 09:55:39 GMT):
Hi guys. I find it a bit of a bummer that if you make something in your wallet by mistake, you cannot delete it. I understand the reasoning that the wallet is "add only" to protect from losing private keys, but... it is hard to be a newbie and creating dumb/wrong/broken stuff and then have to wipe out your wallet to clean it up.

jrallen (Thu, 13 Feb 2020 09:56:17 GMT):
Today's example was that I added a payment address, but forgot to give seed=, even though I wanted to use a seed that I've got stored in 1Password.

smithbk (Fri, 14 Feb 2020 21:01:56 GMT):
Hi all, I'd like to bubble better error messages back up to users. For example, if an issuer tries to issue a cred with an attribute name which doesn't match the schema, verbose indy logging shows the following ursa error. ```UrsaCryptoError: Value by key 'course' not found in pk.r``` But when JSON.stringifying the exception in node, I only see the following: ```{"name":"IndyError","message":"CommonInvalidStructure","indyCode":113,"indyName":"CommonInvalidStructure","indyCurrentErrorJson":null}``` Is there a way to get the ursa error in my node app back to the user so they have some idea what they've done wrong? Thanks

smithbk (Fri, 14 Feb 2020 21:01:56 GMT):
Hi all, I'd like to bubble better error messages back up to users. For example, if an issuer tries to issue a cred with an attribute name which doesn't match the schema, verbose indy logging shows the following ursa error. `UrsaCryptoError: Value by key 'course' not found in pk.r` But when JSON.stringifying the exception in node, I only see the following: ```{"name":"IndyError","message":"CommonInvalidStructure","indyCode":113,"indyName":"CommonInvalidStructure","indyCurrentErrorJson":null}``` Is there a way to get the ursa error in my node app back to the user so they have some idea what they've done wrong? Thanks

futurama92 (Sat, 15 Feb 2020 18:15:54 GMT):
Hi guys, do you know if there's some limits on share the pool handle between services? Is there a maxinum number of connections ? Is in some way network performance affected by multiple connections? thanks

shamzarmy (Sat, 15 Feb 2020 22:48:01 GMT):
Has joined the channel.

kumar89 (Sun, 16 Feb 2020 10:08:09 GMT):
Has joined the channel.

shamzarmy (Sun, 16 Feb 2020 10:27:17 GMT):
Facing the same issue with 1.14.2

ankita.p (Mon, 17 Feb 2020 12:30:16 GMT):
Hello folks, Is there any way to give metadata of schema attributes( like datatype) while registering schema on ledger?

futurama92 (Mon, 17 Feb 2020 20:20:01 GMT):
Hi guys, i'm trying to send a message between trust anchor and user with packMessage() method. Is it possibile that someone can steal this message and does a replay attack?

sklump (Tue, 18 Feb 2020 11:49:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=E2iHpK6T95KH8wFqS) Schema attributes are always strings for this generation.

swcurran (Tue, 18 Feb 2020 15:59:56 GMT):
Not in the current version of Indy. If you look up the Rich Schema work being done in Indy and Aries you will see that support for that is being added.

ankita.p (Wed, 19 Feb 2020 07:33:30 GMT):
Thank you @swcurran

sklump (Wed, 19 Feb 2020 17:45:05 GMT):
So a thing that has never failed has begun failing consistently, on ubuntu 16 and ubuntu 18 both: ``` docker build --build-arg pool_ip=10.0.0.2 -f indy-pool.dockerfile -t . ``` Now works until ``` (... snip ...) Step 15/22 : RUN echo "[supervisord]\nlogfile = /tmp/supervisord.log\nlogfile_maxbytes = 50MB\nlogfile_backups=10\nlogLevel = error\npidfile = /tmp/supervisord.pid\nnodaemon = true\nminfds = 1024\nminprocs = 200\numask = 022\nuser = indy\nidentifier = supervisor\ndirectory = /tmp\nnocleanup = true\nchildlogdir = /tmp\nstrip_ansi = false\n\n[program:node1]\ncommand=start_indy_node Node1 0.0.0.0 9701 0.0.0.0 9702\ndirectory=/home/indy\nstdout_logfile=/tmp/node1.log\nstderr_logfile=/tmp/node1.log\n\n[program:node2]\ncommand=start_indy_node Node2 0.0.0.0 9703 0.0.0.0 9704\ndirectory=/home/indy\nstdout_logfile=/tmp/node2.log\nstderr_logfile=/tmp/node2.log\n\n[program:node3]\ncommand=start_indy_node Node3 0.0.0.0 9705 0.0.0.0 9706\ndirectory=/home/indy\nstdout_logfile=/tmp/node3.log\nstderr_logfile=/tmp/node3.log\n\n[program:node4]\ncommand=start_indy_node Node4 0.0.0.0 9707 0.0.0.0 9708\ndirectory=/home/indy\nstdout_logfile=/tmp/node4.log\nstderr_logfile=/tmp/node4.log\n">> /etc/supervisord.conf ---> Running in 810b64cf1643 ``` and then hangs and drops the terminal session. The disk isn't full. Has anyone seen this or have a guess how to get past it?

Yoroitchi (Thu, 20 Feb 2020 07:37:14 GMT):
Are you sure your command is correct ? On indy-sdk repo the command is as follow. ```docker build --build-arg pool_ip=10.0.0.2 -f ci/indy-pool.dockerfile -t indy_pool .```

sklump (Thu, 20 Feb 2020 11:32:15 GMT):
Yes, I was a directory up from you. I have it working on another VM and I am not touching anything until I get through my current work item. Then I will come back to it. I suspect something's gone wrong with my docker installations elsewhere. One time, a docker-compose version disappeared and my installation wrote a few of its files' content as '404: Not Found', which made a mess of several scripts. It might be something like that.

sklump (Thu, 20 Feb 2020 11:32:15 GMT):
Yes, I was a directory up from you. I have it working on another VM and I am not touching anything until I get through my current work item. Then I will come back to it. I suspect something's gone wrong with my docker installations elsewhere. One time, a docker-compose version disappeared from the site and my installation wrote a few of its files' content (in /usr/local/bin/, /etc/defaults/..., etcetera) as '404: Not Found', which made a mess of several scripts. It might be something like that.

sklump (Thu, 20 Feb 2020 11:32:15 GMT):
Yes, I was a directory down from you. I have it working on another VM and I am not touching anything until I get through my current work item. Then I will come back to it. I suspect something's gone wrong with my docker installations elsewhere. One time, a docker-compose version disappeared from the site and my installation wrote a few of its files' content (in /usr/local/bin/, /etc/defaults/..., etcetera) as '404: Not Found', which made a mess of several scripts. It might be something like that.

Yoroitchi (Thu, 20 Feb 2020 12:06:49 GMT):
OK, sounds weird. I'm not a Docker expert, i don't have any idea how to help you. Sorry Hope you will find the solution

sklump (Thu, 20 Feb 2020 12:16:59 GMT):
Thanks - the solution might be to salvage what I can from those VMs and discreetly delete them.

sklump (Thu, 20 Feb 2020 12:16:59 GMT):
Thanks - the solution might be to salvage what I can from those VMs and discreetly delete them. It's odd how I pick up an attachment to VMs I've had around for while though. A single tear.

sklump (Thu, 20 Feb 2020 14:06:39 GMT):
*Question:* Consider the following sequence on distinct timestamps `t`: * `t=0`: Issuer creates revocation registry `rr`. * `t=1`: Prover gets a credential on `rr`, with cred rev ids `crid[1]`. * `t=2`: Prover gets another credential on `rr`, with cred rev ids `crid[2]`. * `t=3`: Prover gets another credential on `rr`, with cred rev ids `crid[3]`. * `t=4`: Prover creates revocation registry state `rr_state["4"]` for `rr`. * `t=5`: Prover updates revocation registry state `rr_state["4,1,5"]` from delta against `rr_state["4"]` on cred rev id `crid[1]`; prover creates proof on cred with cred rev id `crid[1]`. * `t=5`: Prover creates revocation registry state `rr_state["4,2,5"]` from delta against `rr_state["4"]` on cred rev id `crid[2]`; prover creates proof on cred with cred rev id `crid[2]`. * `t=6`: Prover creates revocation registry state `rr_state["4,1,5,3,6"] from delta against `rr_state["4,1,5"]` on cred rev id `crid[3]`; prover creates proof on cred with cred rev id `crid[3]`. * `t=6`: Prover creates revocation registry state `rr_state["4,2,5,3,6"] from delta against `rr_state["4,2,5"]` on cred rev id `crid[3]`; prover creats proof on cred with cred rev id `crid[3]`. Will this produce valid proofs? Is it OK to take a rev reg state genenerated by delta on one cred rev id and use it to produce a (later) rev reg state by delta using a distinct cred rev id? Should it matter? Distinct cred rev ids produce rev reg states on the same timestamp with distinct witness omegas but the same accumulator values. It looks like I'm going to build out a test for this, but if anyone in indy knows offhand it could save me some time, thanks in advance.

sklump (Thu, 20 Feb 2020 14:06:39 GMT):
*Question:* Consider the following sequence on distinct timestamps `t`: * `t=0`: Issuer creates revocation registry `rr`. * `t=1`: Prover gets a credential on `rr`, with cred rev id `crid[1]`. * `t=2`: Prover gets another credential on `rr`, with cred rev id `crid[2]`. * `t=3`: Prover gets another credential on `rr`, with cred rev id `crid[3]`. * `t=4`: Prover creates revocation registry state `rr_state["4"]` for `rr`. * `t=5`: Prover updates revocation registry state `rr_state["4,1,5"]` from delta against `rr_state["4"]` on cred rev id `crid[1]`; prover creates proof on cred with cred rev id `crid[1]`. * `t=5`: Prover creates revocation registry state `rr_state["4,2,5"]` from delta against `rr_state["4"]` on cred rev id `crid[2]`; prover creates proof on cred with cred rev id `crid[2]`. * `t=6`: Prover creates revocation registry state `rr_state["4,1,5,3,6"] from delta against `rr_state["4,1,5"]` on cred rev id `crid[3]`; prover creates proof on cred with cred rev id `crid[3]`. * `t=6`: Prover creates revocation registry state `rr_state["4,2,5,3,6"] from delta against `rr_state["4,2,5"]` on cred rev id `crid[3]`; prover creats proof on cred with cred rev id `crid[3]`. Will this produce valid proofs? Is it OK to take a rev reg state genenerated by delta on one cred rev id and use it to produce a (later) rev reg state by delta using a distinct cred rev id? Should it matter? Distinct cred rev ids produce rev reg states on the same timestamp with distinct witness omegas but the same accumulator values. It looks like I'm going to build out a test for this, but if anyone in indy knows offhand it could save me some time, thanks in advance.

sklump (Thu, 20 Feb 2020 14:06:39 GMT):
*Question:* Consider the following sequence on distinct timestamps `t`: * `t=0`: Issuer creates revocation registry `rr`. * `t=1`: Prover gets a credential on `rr`, with cred rev id `crid[1]`. * `t=2`: Prover gets another credential on `rr`, with cred rev id `crid[2]`. * `t=3`: Prover gets another credential on `rr`, with cred rev id `crid[3]`. * `t=4`: Prover creates revocation registry state `rr_state["4"]` for `rr`. * `t=5`: Prover updates revocation registry state `rr_state["4,1,5"]` from delta against `rr_state["4"]` on cred rev id `crid[1]`; prover creates proof on cred with cred rev id `crid[1]`. * `t=5`: Prover creates revocation registry state `rr_state["4,2,5"]` from delta against `rr_state["4"]` on cred rev id `crid[2]`; prover creates proof on cred with cred rev id `crid[2]`. * `t=6`: Prover creates revocation registry state `rr_state["4,1,5,3,6"]` from delta against `rr_state["4,1,5"]` on cred rev id `crid[3]`; prover creates proof on cred with cred rev id `crid[3]`. * `t=6`: Prover creates revocation registry state `rr_state["4,2,5,3,6"]` from delta against `rr_state["4,2,5"]` on cred rev id `crid[3]`; prover creats proof on cred with cred rev id `crid[3]`. Will this produce valid proofs? Is it OK to take a rev reg state genenerated by delta on one cred rev id and use it to produce a (later) rev reg state by delta using a distinct cred rev id? Should it matter? Distinct cred rev ids produce rev reg states on the same timestamp with distinct witness omegas but the same accumulator values. It looks like I'm going to build out a test for this, but if anyone in indy knows offhand it could save me some time, thanks in advance.

CyrilLeung (Fri, 21 Feb 2020 02:24:56 GMT):
Has joined the channel.

neilmadhava (Sat, 22 Feb 2020 06:24:11 GMT):
Has joined the channel.

nacerix (Sun, 23 Feb 2020 14:33:57 GMT):
Has joined the channel.

Milos22 (Sun, 23 Feb 2020 16:53:25 GMT):
Hello, after building, signing and submitting the aml i get this error : REJECT","reason":"client request invalid: UnauthorizedClientRequest(\'Not enough TRUSTEE signatures

Milos22 (Sun, 23 Feb 2020 16:54:35 GMT):
I'm using the python wrapper, do you have any idea what that might be?

swcurran (Sun, 23 Feb 2020 20:26:05 GMT):
Likely the DID you are using to sign and submit the transaction is not an endorser. You need to get an endorser (aka trustee) on the network to also sign and submit the transaction.

andrew.whitehead (Sun, 23 Feb 2020 20:28:03 GMT):
This, except trustee is higher than endorser. Sounds like they're trying to update the AML so it needs to be signed by a steward or trustee

swcurran (Sun, 23 Feb 2020 20:29:14 GMT):
Ah, is that for adding a node? What is AML?

andrew.whitehead (Sun, 23 Feb 2020 20:29:39 GMT):
The acceptance mechanisms list associated with the TAA

swcurran (Sun, 23 Feb 2020 20:30:43 GMT):
Ah...nothing to do with nodes.

sklump (Mon, 24 Feb 2020 12:04:29 GMT):
Endorser is the old Trust Anchor, not Trustee. A trustee can also maintain software running on the nodes themselves. Here we see why they've moved to rebadge this role - I've made this conflation in my mind and on paper hundreds of times.

swcurran (Mon, 24 Feb 2020 14:51:06 GMT):
Thanks...I was missing that.

lynn.bendixsen (Mon, 24 Feb 2020 19:48:56 GMT):
Hi @Milos22 The reason for the error might lie in the Auth Rules for whatever network you are using. By default, setting the AML requires 1 TRUSTEE signature. That value is configurable and the way I check it is to run `indy-cli> ledger get-auth-rule` then look for the rule for TXN_AUTHR_AGRMT_AML to see what it is set to on your ledger.

thomas_kim (Tue, 25 Feb 2020 17:42:43 GMT):
Has joined the channel.

thomas_kim (Tue, 25 Feb 2020 17:42:44 GMT):
Hi, @swcurran @sergey.minaev I'm testing LibVCX python demo alice (aries protocol) with aries-cloudagent-python demo faber. When I put into the invitation to the alice agent, the connection is establised in the demo alice side. However, a connection of a demo faber side is not getting the status of "active" but "response"... Is it the compatibility issue in the LibVCX? Am I doing something wrong?

thomas_kim (Tue, 25 Feb 2020 17:42:44 GMT):
For some reasons, it is not promoting... I enabled the event flag when I ran the aries python faber demo

andrew.whitehead (Tue, 25 Feb 2020 18:09:17 GMT):
The connection should be promoted to active as soon as the VCX client sends an agent message

thomas_kim (Tue, 25 Feb 2020 18:30:57 GMT):
For some reasons, it is not promoting... I enabled the event flat when I ran the faber demo. ***************** Invitation: {"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/invitation", "@id": "0f0f207c-6efa-41dc-814f-05f0722d2a04", "label": "Faber Agent", "recipientKeys": ["DF8YRM8r2XBnD66h6KEekM8ajt2Vqa54wRsyP1gE3BeK"], "serviceEndpoint": "http://localhost:8020"} ***************** Waiting for connection... EVENT: Agent called controller webhook: handle_connections with payload: { "created_at": "2020-02-25 16:52:14.287677Z", "invitation_key": "DF8YRM8r2XBnD66h6KEekM8ajt2Vqa54wRsyP1gE3BeK", "state": "invitation", "routing_state": "none", "initiator": "self", "connection_id": "746c7e14-7c29-4e3b-adec-83e3c1d08b12", "updated_at": "2020-02-25 16:52:14.287677Z", "accept": "auto", "invitation_mode": "once" } EVENT: Agent called controller webhook: handle_connections with payload: { "created_at": "2020-02-25 16:52:14.287677Z", "invitation_key": "DF8YRM8r2XBnD66h6KEekM8ajt2Vqa54wRsyP1gE3BeK", "state": "request", "their_label": "alice", "routing_state": "none", "initiator": "self", "connection_id": "746c7e14-7c29-4e3b-adec-83e3c1d08b12", "updated_at": "2020-02-25 16:52:30.264611Z", "their_did": "6Coo6EN8x6EAh2RP56kuzd", "accept": "auto", "invitation_mode": "once" } EVENT: Agent called controller webhook: handle_connections with payload: { "created_at": "2020-02-25 16:52:14.287677Z", "invitation_key": "DF8YRM8r2XBnD66h6KEekM8ajt2Vqa54wRsyP1gE3BeK", "state": "response", "their_label": "alice", "routing_state": "none", "initiator": "self", "connection_id": "746c7e14-7c29-4e3b-adec-83e3c1d08b12", "updated_at": "2020-02-25 16:52:30.278099Z", "their_did": "6Coo6EN8x6EAh2RP56kuzd", "accept": "auto", "invitation_mode": "once", "my_did": "LLMKon3v779pxyuqSmnBQT" }

thomas_kim (Tue, 25 Feb 2020 18:30:57 GMT):
***************** Invitation: {"@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/invitation", "@id": "0f0f207c-6efa-41dc-814f-05f0722d2a04", "label": "Faber Agent", "recipientKeys": ["DF8YRM8r2XBnD66h6KEekM8ajt2Vqa54wRsyP1gE3BeK"], "serviceEndpoint": "http://localhost:8020"} ***************** Waiting for connection... EVENT: Agent called controller webhook: handle_connections with payload: { "created_at": "2020-02-25 16:52:14.287677Z", "invitation_key": "DF8YRM8r2XBnD66h6KEekM8ajt2Vqa54wRsyP1gE3BeK", "state": "invitation", "routing_state": "none", "initiator": "self", "connection_id": "746c7e14-7c29-4e3b-adec-83e3c1d08b12", "updated_at": "2020-02-25 16:52:14.287677Z", "accept": "auto", "invitation_mode": "once" } EVENT: Agent called controller webhook: handle_connections with payload: { "created_at": "2020-02-25 16:52:14.287677Z", "invitation_key": "DF8YRM8r2XBnD66h6KEekM8ajt2Vqa54wRsyP1gE3BeK", "state": "request", "their_label": "alice", "routing_state": "none", "initiator": "self", "connection_id": "746c7e14-7c29-4e3b-adec-83e3c1d08b12", "updated_at": "2020-02-25 16:52:30.264611Z", "their_did": "6Coo6EN8x6EAh2RP56kuzd", "accept": "auto", "invitation_mode": "once" } EVENT: Agent called controller webhook: handle_connections with payload: { "created_at": "2020-02-25 16:52:14.287677Z", "invitation_key": "DF8YRM8r2XBnD66h6KEekM8ajt2Vqa54wRsyP1gE3BeK", "state": "response", "their_label": "alice", "routing_state": "none", "initiator": "self", "connection_id": "746c7e14-7c29-4e3b-adec-83e3c1d08b12", "updated_at": "2020-02-25 16:52:30.278099Z", "their_did": "6Coo6EN8x6EAh2RP56kuzd", "accept": "auto", "invitation_mode": "once", "my_did": "LLMKon3v779pxyuqSmnBQT" }

swcurran (Tue, 25 Feb 2020 18:31:04 GMT):
This is because the RFC was defined with no final "ACK" message back to the initiator of the connection, so there is no way to know whether the connection is established. The RFC says something like "a message should follow the establishment of the connection", which is why Andrew's connection is to send a follow up message.

swcurran (Tue, 25 Feb 2020 18:31:28 GMT):
That doesn't help your problem though - just the source of the issue.

thomas_kim (Tue, 25 Feb 2020 18:42:44 GMT):
I got it. aries-cloudagent-python alice demo sends the final "ACK" back to the inviter, but LibVCX is not. Is Andrew saying that the connection should be promoted automatically even without the final "ACK"?

thomas_kim (Tue, 25 Feb 2020 18:42:44 GMT):
I got it. aries-cloudagent-python alice demo sends the final "ACK" back to the inviter, but LibVCX does not. Is Andrew saying that the connection should be promoted automatically even without the final "ACK"?

thomas_kim (Tue, 25 Feb 2020 18:47:33 GMT):
Are the RFC and the LibVCX going to be updated?

swcurran (Tue, 25 Feb 2020 18:48:49 GMT):
The RFC is unlikely to be changed. Not sure what to do about the LibVCX handling. @esplinr

andrew.whitehead (Tue, 25 Feb 2020 19:06:11 GMT):
I don't think that having the connection in the 'response' state should necessarily cause issues though

thomas_kim (Wed, 26 Feb 2020 02:00:36 GMT):
I think I can use the auto_complete option in order to promote connections. Thanks all.

rfu2k (Wed, 26 Feb 2020 17:38:46 GMT):
Has joined the channel.

rfu2k (Wed, 26 Feb 2020 17:38:47 GMT):
Hi I hope someone can help me or advise. I need access to source of v1.0.3 of libsovtoken but latest tagged on the git repo is v1.0.1. Anyone know how I can get access to the source code for this release? Thank you

burdettadam (Wed, 26 Feb 2020 19:10:37 GMT):
Hmm, no tags... @rfu2k , I think this is what you are looking for. https://github.com/sovrin-foundation/libsovtoken/tree/0e56341f88ee99e86eed0a264238912585ae1ce5 https://github.com/sovrin-foundation/token-plugin/tree/5b3fa58730b6cc2b378b832e4424082deea572b0 I found those looking at commit diff's in the history of the project: https://github.com/sovrin-foundation/libsovtoken/commit/0e56341f88ee99e86eed0a264238912585ae1ce5#diff-4ac32a78649ca5bdd8e0ba38b7006a1e https://github.com/sovrin-foundation/token-plugin/commit/5b3fa58730b6cc2b378b832e4424082deea572b0#diff-d6218dffb00a999f83427329bfacb8a3

anillewis (Wed, 26 Feb 2020 19:29:36 GMT):
Team, quick question...when indy-sdk submits the request to the ledger using the indy pool handle, does it wait for response from the two (default setting) nodes that the request was sent to or any one node (is it the primary? ) that responds with the REPLY message as per the plenum consensus?

thinhnnd (Thu, 27 Feb 2020 02:59:13 GMT):
Has joined the channel.

SergeyBrazhnik (Thu, 27 Feb 2020 08:22:09 GMT):
Hello everyone! Please advice. Could I using indy-sdk publish Did with did-documents on ledger?

sklump (Thu, 27 Feb 2020 18:12:25 GMT):
You can publish tham as attributes against a NYM, but the ledger's data formats precede the DIDDoc spec by quite some time. DIDDoc itself continues to evolve rapidly and the W3C intends to have something stable by summer.

sklump (Thu, 27 Feb 2020 18:12:25 GMT):
You can publish them as attributes against a NYM, but the ledger's data formats precede the DIDDoc spec by quite some time. DIDDoc itself continues to evolve rapidly and the W3C intends to have something stable by summer. Rolling your own attribute will likely present incompatibilities with other applications using the same ledger; it may be better to keep them off the ledger until indy and W3C converge, and the ledger takes them in a standard place.

sklump (Thu, 27 Feb 2020 18:12:25 GMT):
You can publish them as attributes against a NYM, but the ledger's data formats precede the DIDDoc spec by quite some time. DIDDoc itself continues to evolve rapidly and the W3C intends to have something stable by (northern) summer. Rolling your own attribute will likely present incompatibilities with other applications using the same ledger; it may be better to keep them off the ledger until indy and W3C converge, and the ledger takes them in a standard place.

echo.harker (Thu, 27 Feb 2020 19:52:43 GMT):
Has joined the channel.

biligunb (Fri, 28 Feb 2020 05:10:36 GMT):
Hi all. A quick question. Q: Is it possible to use `indy-sdk` in browser extension? (like chrome extension)

biligunb (Fri, 28 Feb 2020 05:10:59 GMT):
indy-sdk can do almost all things. I believe. you can make public DID using indy-sdk.

ayushmanss (Mon, 02 Mar 2020 09:02:41 GMT):
Hi all, I dont know if this question has been asked here or not, or if someone has tried it or not. As indy provides pluggable storage, is it possible to use google drive or dropbox as the storage. I want to run cloudagent for others with their respective clouds as storage. Basically I have trying to eliminate the need for an edge agent like smartphones without compromising privacy. Is it possible? I dont know where the master key that encrypts the wallet is stored though? Is it even possible to do this with just web agent?

saadrm (Mon, 02 Mar 2020 14:29:46 GMT):
Has joined the channel.

saadrm (Mon, 02 Mar 2020 14:29:49 GMT):
Hi All, I am using Libindy 1.8.2 and trying to import my wallet for recovery of my account after successful export wallet. However I am getting error from indy import method as: Error Domain=IndyErrorDomain Code=114 "(null)" UserInfo={message=Error: IO error Caused by: No such file or directory (os error 2) , indy_backtrace=} In import wallet I am sending: importConfigJson = {"path":"file:///var/mobile/Containers/Data/Application/D62D0B32-2FE4-4871-8B7D-ABFF84A574D1/Documents/walletData","key":"copens disuniting colossuses bunraku uppitynesses serviceablenesses brazenness lira bananas equipper adiabatically sorcery"} credentials = {"key":"GqcA6WLrVAUUwVgTYAiekbMScmUMjwQM1Jb2KzuyeMbc"} withConfig = {"id": "steward_wallet","storage_type":"default"} When I a try to give relative path in my importConfig that is: “/var/mobile/Containers/Data/Application/D62D0B32-2FE4-4871-8B7D-ABFF84A574D1/Documents/walletData” My app crashes due to memory issue. Can you please guide where I am making a mistake or any way around so I can import my wallet successfully. Thank you.

saadrm (Mon, 02 Mar 2020 14:29:49 GMT):
Hi All, I am using Libindy 1.8.2 and trying to import my wallet in iOS App for recovery of my account after successful export wallet. However I am getting error from indy import method as: Error Domain=IndyErrorDomain Code=114 "(null)" UserInfo={message=Error: IO error Caused by: No such file or directory (os error 2) , indy_backtrace=} In import wallet I am sending: importConfigJson = {"path":"file:///var/mobile/Containers/Data/Application/D62D0B32-2FE4-4871-8B7D-ABFF84A574D1/Documents/walletData","key":"copens disuniting colossuses bunraku uppitynesses serviceablenesses brazenness lira bananas equipper adiabatically sorcery"} credentials = {"key":"GqcA6WLrVAUUwVgTYAiekbMScmUMjwQM1Jb2KzuyeMbc"} withConfig = {"id": "steward_wallet","storage_type":"default"} When I a try to give relative path in my importConfig that is: “/var/mobile/Containers/Data/Application/D62D0B32-2FE4-4871-8B7D-ABFF84A574D1/Documents/walletData” My app crashes due to memory issue. Can you please guide where I am making a mistake or any way around so I can import my wallet successfully. Thank you.

sergey.minaev (Mon, 02 Mar 2020 14:50:56 GMT):
While extra testing of *RC IndySDK 1.14.3* we found the release flow (in the publishing part) issue: *Ubuntu 18.04* artifacts published at repo.sovrin.org *are incorrect*. For releases from 1.11.1 to 1.14.2 they are overlapped by artifacts for 16.04. We are going to fix it in 1.14.3 stable release this week. Few a bit optimistic things about them: The codebase and build process were fine, so it is possible to rebuild from stable tags for testings needs. The difference between 16.04 and 18.04 debs is minimal so 16.04 may be used at 18.04 But as soon as the mentioned above artifacts are not corresponds to our release flow and assumptions we are NOT recommend to use them and suggest to upgrade to the latest 1.14.3. Most probably we will remove them from the official repo in favor of the upcoming release.

sergey.minaev (Mon, 02 Mar 2020 14:50:56 GMT):
While extra testing of *RC IndySDK 1.14.3* we found the release flow (in the publishing part) issue: *Ubuntu 18.04* artifacts published at repo.sovrin.org *are incorrect*. For releases from 1.11.1 to 1.14.2 they are overlapped by artifacts for 16.04. We are going to fix it in 1.14.3 stable release this week. Few a bit optimistic things about them: The codebase and build process were fine, so it is possible to rebuild from stable tags for testings needs. The difference between 16.04 and 18.04 debs is minimal so 16.04 may be used at 18.04 But as soon as the mentioned above artifacts are not corresponds to our release flow and assumptions we are NOT recommend to use them and suggest to upgrade to the latest 1.14.3. Most probably we will remove old 18.04 artifacts from the official repo in favor of the upcoming release.

ShamGir (Mon, 02 Mar 2020 15:08:47 GMT):
@sergey.minaev @sklump

ShamGir (Mon, 02 Mar 2020 15:08:47 GMT):
@sergey.minaev @sklump , do you have any idea about this error .

sergey.minaev (Mon, 02 Mar 2020 15:16:54 GMT):
the second variant of importConfig seems correct. I suggest to try to import minimal (almost empty) wallet to check is the memory issue correlate with the wallet size

smithbk (Mon, 02 Mar 2020 22:03:43 GMT):
Hi anyone, suppose I have two credentials in my wallet with the same cred def id, one with attribute `foo=bar1` and the other with `foo=bar2`. I then receive a proof request to reveal the value of attr `foo`, so there is only a single referent in the proof request. Is it possible to generate a proof which includes the value of `foo` from both credentials? (i.e. both `bar1` and `bar2`). From looking at https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/api/anoncreds.rs#L1860, it seems that it is not possible without changing the proof request because the referents under `requested_credentials_json.requested_attributes` (there would be two in my example) must match a referent under `proof_request_json.requested_attributes` and since there is only one referent in the proof request, I can only have one referent in the requested credentials. Is my reasoning correct or am I missing something? Thanks

smithbk (Mon, 02 Mar 2020 22:03:43 GMT):
Hi anyone, suppose I have two credentials in my wallet with the same cred def id, one with attribute `foo=bar1` and the other with `foo=bar2`. I then receive a proof request to reveal the value of attr `foo`, so there is only a single referent in the proof request. Is it possible to generate a proof which includes the value of `foo` from both credentials? (i.e. both `bar1` and `bar2`). From looking at https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/api/anoncreds.rs#L1860, it seems that it is not possible without changing the proof request because the referents under `requested_credentials_json.requested_attributes` (there would need to be two in my example) must match a referent under `proof_request_json.requested_attributes` and since there is only one referent in the proof request, I can only have one referent in the requested credentials. Is my reasoning correct or am I missing something? Thanks

swcurran (Mon, 02 Mar 2020 22:30:43 GMT):
I think that is correct. I've wondered if it makes sense to send multiple proofs back in response to a proof request for situations like that. The user experience would be challenging, even if the tech wasn't that hard.

thhkmgl (Tue, 03 Mar 2020 12:09:24 GMT):
Has joined the channel.

thhkmgl (Tue, 03 Mar 2020 12:09:25 GMT):
Hello everyone! I have a problem. Link: https://stackoverflow.com/questions/60506855/hyperledger-indy-intellij-idea-samples-java-program-error

ShamGir (Tue, 03 Mar 2020 12:17:52 GMT):
Add org.junit.assert library in your project

thhkmgl (Tue, 03 Mar 2020 13:32:29 GMT):
I did it but it's not working

thhkmgl (Tue, 03 Mar 2020 13:32:58 GMT):
Added org.junit.assert, org.apache.commons.io, etc

ShamGir (Tue, 03 Mar 2020 13:36:36 GMT):
have you added "org.junit.assert" or "org.junit.Assert" ??

thhkmgl (Tue, 03 Mar 2020 13:37:36 GMT):
org.junit.Assert

ShamGir (Tue, 03 Mar 2020 13:39:15 GMT):
then sync your gradle and send what error you got

thhkmgl (Tue, 03 Mar 2020 18:46:05 GMT):
I solved library problems. And I have a new problem now.

thhkmgl (Tue, 03 Mar 2020 18:46:09 GMT):
Error: /usr/lib/jvm/java-8-openjdk-amd64/bin/java -javaagent:/snap/intellij-idea-community/208/lib/idea_rt.jar=45481:/snap/intellij-idea-community/208/bin -Dfile.encoding=UTF-8 -classpath /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/charsets.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/cldrdata.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/dnsns.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/icedtea-sound.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/jaccess.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/java-atk-wrapper.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/localedata.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/nashorn.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/sunec.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/sunjce_provider.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/sunpkcs11.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/ext/zipfs.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/jce.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/jsse.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/management-agent.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/resources.jar:/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar:/home/hekimoglu/indy-sdk-master/samples/java/target/classes:/home/hekimoglu/.m2/repository/junit/junit/4.12/junit-4.12.jar:/home/hekimoglu/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar:/home/hekimoglu/.m2/repository/org/apache/commons/commons-lang3/3.5/commons-lang3-3.5.jar:/home/hekimoglu/.m2/repository/commons-io/commons-io/2.5/commons-io-2.5.jar:/home/hekimoglu/.m2/repository/org/json/json/20180130/json-20180130.jar:/home/hekimoglu/.m2/repository/org/hyperledger/indy/1.14.1-rc-120/indy-1.14.1-rc-120.jar:/home/hekimoglu/.m2/repository/net/java/dev/jna/jna/4.4.0/jna-4.4.0.jar:/home/hekimoglu/.m2/repository/org/slf4j/slf4j-api/1.7.26/slf4j-api-1.7.26.jar:/home/hekimoglu/.m2/repository/org/slf4j/slf4j-simple/1.7.5/slf4j-simple-1.7.5.jar Main Anoncreds sample -> started [Thread-0] INFO org.hyperledger.indy.sdk.LibIndy.native.command_executor - src/commands/mod.rs:101 | Worker thread started Exception in thread "main" java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.pool.PoolLedgerConfigExistsException: A pool ledger configuration already exists with the specified name. at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1908) at utils.PoolUtils.createPoolLedgerConfig(PoolUtils.java:48) at Anoncreds.demo(Anoncreds.java:26) at Main.main(Main.java:4) Caused by: org.hyperledger.indy.sdk.pool.PoolLedgerConfigExistsException: A pool ledger configuration already exists with the specified name. at org.hyperledger.indy.sdk.IndyException.fromSdkError(IndyException.java:162) at org.hyperledger.indy.sdk.IndyJava$API.checkResult(IndyJava.java:92) at org.hyperledger.indy.sdk.pool.Pool.access$400(Pool.java:20) at org.hyperledger.indy.sdk.pool.Pool$2.callback(Pool.java:70) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:520) at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:551)

thhkmgl (Tue, 03 Mar 2020 18:46:27 GMT):
Error: Anoncreds sample -> started [Thread-0] INFO org.hyperledger.indy.sdk.LibIndy.native.command_executor - src/commands/mod.rs:101 | Worker thread started Exception in thread "main" java.util.concurrent.ExecutionException: org.hyperledger.indy.sdk.pool.PoolLedgerConfigExistsException: A pool ledger configuration already exists with the specified name. at java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:357) at java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1908) at utils.PoolUtils.createPoolLedgerConfig(PoolUtils.java:48) at Anoncreds.demo(Anoncreds.java:26) at Main.main(Main.java:4) Caused by: org.hyperledger.indy.sdk.pool.PoolLedgerConfigExistsException: A pool ledger configuration already exists with the specified name. at org.hyperledger.indy.sdk.IndyException.fromSdkError(IndyException.java:162) at org.hyperledger.indy.sdk.IndyJava$API.checkResult(IndyJava.java:92) at org.hyperledger.indy.sdk.pool.Pool.access$400(Pool.java:20) at org.hyperledger.indy.sdk.pool.Pool$2.callback(Pool.java:70) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:520) at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:551)

thhkmgl (Tue, 03 Mar 2020 18:47:16 GMT):

errorSS.png

carlojbs (Wed, 04 Mar 2020 03:10:38 GMT):
Has joined the channel.

isvirin (Wed, 04 Mar 2020 06:56:21 GMT):
Has joined the channel.

isvirin (Wed, 04 Mar 2020 06:56:24 GMT):
Hello everyone! I need help. I use libindy in android app. It works correctly in version 11.0.0. But starting from 12.0.0 it doesn't work. App can't find native methods. What has been changed from 12.0.0 ? Do anybody has tested android libindy of 12.0.0 or 13.0.0 version? Is there any examples of test apps?

ShamGir (Wed, 04 Mar 2020 07:52:26 GMT):
You can read error, it says that you are creating a PoolLedger Config, that already exists.

ekubilay (Wed, 04 Mar 2020 14:18:18 GMT):
Hi everyone! I'm trying to run my indy java project in a docker container. However I'm getting Null Pointer Exceptions due to the fact that libindy cannot be loaded properly. I basically ran "cargo build" and put the resulting libindy.so into /usr/lib/local directory of the container. However the library still cant be loaded. Any ideas why this might happen? Many thanks in advance :)

sklump (Wed, 04 Mar 2020 14:21:36 GMT):
`/usr/local/lib` maybe? Check path.

ekubilay (Wed, 04 Mar 2020 14:22:13 GMT):
ah sorry typo, its already /usr/local/lib

thhkmgl (Wed, 04 Mar 2020 16:25:54 GMT):
I changed the default pool name.

thhkmgl (Wed, 04 Mar 2020 16:26:14 GMT):

indy-java-sample-error-2.png

SuperSeiyan (Thu, 05 Mar 2020 08:35:46 GMT):
Has joined the channel.

isvirin (Thu, 05 Mar 2020 10:57:48 GMT):
android indy 1.13.0 libs libc++_shared.so - from NDK r20 libindy.so - libindy_shared.so from indy library pack

pknowles (Fri, 06 Mar 2020 04:07:47 GMT):
Has joined the channel.

pknowles (Fri, 06 Mar 2020 04:07:48 GMT):
From one of the developers in our project team ... "I did an investigation of Indy SDK issues that we have been facing over the past two days. INDY-SDK function `verifierVerifyProof` throws an error *AnoncredsProofRejected*. We have seen this failure in the past when trying to use dashes (-) inside credential attribute values. Unfortunately, the INDY SDK doesn't want to handle it despite the fact that they claim support of integers and strings as valid Credential Attributes (see _A Note About Encoding Attributes_ excerpt at https://hyperledger-indy.readthedocs.io/projects/hipe/en/latest/text/0109-anoncreds-protocol/README.html )." Has anyone come across this issue and, if so, is there a workaround?

pknowles (Fri, 06 Mar 2020 04:07:48 GMT):
From one of the developers in our project team ... "I did an investigation of Indy SDK issues that we have been facing over the past two days. INDY-SDK function `verifierVerifyProof` throws an error "AnoncredsProofRejected". We have seen this failure in the past when trying to use dashes (-) inside credential attribute values. Unfortunately, the INDY SDK doesn't want to handle it despite the fact that they claim support of integers and strings as valid Credential Attributes (see _A Note About Encoding Attributes_ excerpt at https://hyperledger-indy.readthedocs.io/projects/hipe/en/latest/text/0109-anoncreds-protocol/README.html )." Has anyone come across this issue and, if so, is there a workaround?

thomas_kim (Fri, 06 Mar 2020 09:26:35 GMT):
Hi community. I'm playing with LibVCX on android, and I found that I can set webhooks when I provision the agent. Therefore, the webhook notification server gets notified when the dummy-cloud-agent gets messages, and I believe I can send push notifications to mobile devices at the end. However, when I get push notifications I need to know the type of the message, so that I can call corresponding update_state method in LibVCX. How can I make it? (Actually, I developed hybrid mobile applications with Xamarin using aries-framework-dotnet and mediator. Now, I'm developing the same thing with LibVCX aries protocol and dummy-cloud-agent) @sergey.minaev do you know the answer? FYI: With the aries-framework-dotnet (many thanks to @tomislav ), when the mobile device provisioning the agent for the first time I could register the device ID in the mediator cloud agent wallet. When the mediator receives messages it emits the event, and in the seperate service I could retrieve the device id in the wallet and send the push notification to a specific user. Once the mobile device receives the push notification, it fetches messages from mediator and processes the message which emits the event containing the type of message (such as, connection request, credential offer, proof request…) and the id. The application listens these events and updates data from mobile edge agent's wallet.

thomas_kim (Fri, 06 Mar 2020 09:26:35 GMT):
Hi community. I'm playing with LibVCX on android, and I found that I could set webhooks when I provision the agent. Therefore, the webhook notification server gets notified when the dummy-cloud-agent gets messages, and I believe I can send push notifications to mobile devices at the end. However, when I get push notifications I need to know the type of the message, so that I can call corresponding update_state method in LibVCX. How can I make it? (Actually, I developed hybrid mobile applications with Xamarin using aries-framework-dotnet and mediator. Now, I'm developing the same thing with LibVCX aries protocol and dummy-cloud-agent) @sergey.minaev do you know the answer? FYI: With the aries-framework-dotnet (many thanks to @tomislav ), when the mobile device provisioning the agent for the first time I could register the device ID in the mediator cloud agent wallet. When the mediator receives messages it emits the event, and in the seperate service I could retrieve the device id in the wallet and send the push notification to a specific user. Once the mobile device receives the push notification, it fetches messages from mediator and processes the message which emits the event containing the type of message (such as, connection request, credential offer, proof request…) and the id. The application listens these events and updates data from mobile edge agent's wallet.

thomas_kim (Fri, 06 Mar 2020 09:26:35 GMT):
Hi community. I'm playing with LibVCX on android, and I found that I could set webhooks when I provision the agent. Therefore, the webhook notification server gets notified when the dummy-cloud-agent gets messages, and I believe I can send push notifications to mobile devices at the end. However, when I get push notifications I need to know the type of the message, so that I can call corresponding update_state method in LibVCX. How can I determine the type of message? (Actually, I developed hybrid mobile applications with Xamarin using aries-framework-dotnet and mediator. Now, I'm developing the same thing with LibVCX aries protocol and dummy-cloud-agent) @sergey.minaev do you know the answer? FYI: With the aries-framework-dotnet (many thanks to @tomislav ), when the mobile device provisioning the agent for the first time I could register the device ID in the mediator cloud agent wallet. When the mediator receives messages it emits the event, and in the seperate service I could retrieve the device id in the wallet and send the push notification to a specific user. Once the mobile device receives the push notification, it fetches messages from mediator and processes the message which emits the event containing the type of message (such as, connection request, credential offer, proof request…) and the id. The application listens these events and updates data from mobile edge agent's wallet.

thomas_kim (Fri, 06 Mar 2020 09:26:35 GMT):
Hi community. I'm playing with LibVCX on android, and I found that I could set webhooks when I provision the agent. Therefore, the webhook notification server gets notified when the dummy-cloud-agent gets messages, and I believe I can send push notifications to mobile devices at the end. However, when I get push notifications I need to know the type of the message, so that I can call corresponding update_state method in LibVCX. How can I determine the type of messages? (Actually, I developed hybrid mobile applications with Xamarin using aries-framework-dotnet and mediator. Now, I'm developing the same thing with LibVCX aries protocol and dummy-cloud-agent) @sergey.minaev do you know the answer? FYI: With the aries-framework-dotnet (many thanks to @tomislav ), when the mobile device provisioning the agent for the first time I could register the device ID in the mediator cloud agent wallet. When the mediator receives messages it emits the event, and in the seperate service I could retrieve the device id in the wallet and send the push notification to a specific user. Once the mobile device receives the push notification, it fetches messages from mediator and processes the message which emits the event containing the type of message (such as, connection request, credential offer, proof request…) and the id. The application listens these events and updates data from mobile edge agent's wallet.

pknowles (Fri, 06 Mar 2020 16:49:02 GMT):
I just received a message from the developer that the issue is resolved as per a suggestion from @MALodder ... "To make this work I've added logic to verify data type of an attribute value before storing it to Indy Wallet (using indy-SDK function issuerCreateCredential) and encoding it properly before calling issuerCreateCredential. In case an attribute value is of "string" type = I first do sha256(stringValue) and get resulting hash as a hex value, then I convert that hash to number (in our case in JS we use https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/charCodeAt), the outcoming value goes to Credential attribute's encoded field, while raw field contains the value as it was before encoding."

SantosCastro (Sun, 08 Mar 2020 11:22:45 GMT):
Has joined the channel.

SantosCastro (Sun, 08 Mar 2020 11:26:01 GMT):
Hi, I asked this question in the indy channel, but I think this is the right one. Sorry for the repetition. :)

SantosCastro (Sun, 08 Mar 2020 11:26:11 GMT):
I created a basic workflow (issuer, prover, verifier) and found something weird so I'm probably doing something wrong.

SantosCastro (Sun, 08 Mar 2020 11:26:18 GMT):
If the prover modify the requested proof section of the proof before sending it to the verifier the proof pasees the verification.

SantosCastro (Sun, 08 Mar 2020 11:26:26 GMT):
So the prover can send fake data. Any idea about what am I doing wrong?

tomislav (Sun, 08 Mar 2020 19:03:04 GMT):
Related to value encoding as discussed here? https://github.com/hyperledger/aries-rfcs/issues/391

pknowles (Sun, 08 Mar 2020 19:35:56 GMT):
Yes. Thanks, @tomislav

pranav_kirtani (Mon, 09 Mar 2020 06:25:49 GMT):
Hi, we are noticing some performance lags when we use the java sdk for indy in mobile app

pranav_kirtani (Mon, 09 Mar 2020 06:26:01 GMT):
any remedy for this?

SantosCastro (Mon, 09 Mar 2020 07:44:30 GMT):
Thanks.

daveek (Mon, 09 Mar 2020 09:24:33 GMT):
Hi.. What Cryptographic Primitives are used in Indy & Aries?

sklump (Mon, 09 Mar 2020 10:31:45 GMT):
I get proof-rejected with the latest master on proofs with any zero-valued attributes (overzealous leading zero stripping). The indy-sdk group is aware of it and I imagine it's on the list to fix before official drop.

DulePop-Andov (Mon, 09 Mar 2020 11:18:36 GMT):
Has joined the channel.

DulePop-Andov (Mon, 09 Mar 2020 11:18:37 GMT):
Hi guys, we're having a bit of trouble with libindy on Mac, when loading it through C# DllImport we get a DllNotFoundException: Unable to load shared library 'indy' or one of its dependencies. This happens even though libindy is installed on the system in /usr/local/lib (1.14.2). After running a tool called MacDependency (sort of like DependencyWalker on Windows) I managed to track it down to it not being able to load libsodium. On my computer it was trying to load *libsodium.18.dylib*, but I had *libsodium.23.dylib*. After attempting to make a hack and renaming libsodium.23.dylib -> libsodium.18.dylib I managed to get the app up and running in a terminal via *dotnet run* but it still seems to fail in VS or any other IDE. Any ideas what could be the issue and how to solve it?

andrew.whitehead (Mon, 09 Mar 2020 13:37:17 GMT):
That looks like a different issue? I thought it was stripping the encoded value

pknowles (Mon, 09 Mar 2020 14:09:11 GMT):
Yes, that looks like a slightly different issue but good to see it discussed in this thread as it is closely related.

sergey.minaev (Tue, 10 Mar 2020 10:48:37 GMT):
there is `vcx_messages_download` API call and it can be used here. In old version of libvcx-dummy interaction the type was available in push notification but it requires to share the type with the mediator. In Aries flow standard forwarding is used, so the message should be downloaded and decrypted first

thomas_kim (Tue, 10 Mar 2020 14:45:28 GMT):
Thanks a lot.

dkulic (Wed, 11 Mar 2020 14:36:42 GMT):
Regarding connection redirection feature, redirect details added to a message look like ```RedirectDetail { DID: String, inviter pairwise did of the old connection verKey: String, inviter pairwise verKey of the old connection publicDID: Optional, String, inviter public did theirDID: String, invitee pairwise did of the old connection theirVerKey: String, invitee pairwise verKey of the old connection theirPublicDID: Optional, String, invitee public did signature: String, signature of concatenated theirDID and theirVerKey, so that invitee confirms possesion of private key for that DID to which it redirects the connection request. }```

dkulic (Wed, 11 Mar 2020 14:36:42 GMT):
Regarding connection redirection feature, redirect details added to a message look like ```RedirectDetail { DID: String, inviter pairwise did of the old connection verKey: String, inviter pairwise verKey of the old connection publicDID: Optional, String, inviter public did theirDID: String, invitee pairwise did of the old connection theirVerKey: String, invitee pairwise verKey of the old connection theirPublicDID: Optional, String, invitee public did signature: String, signature of concatenated theirDID and theirVerKey, so that invitee proves possesion of private key for that DID to which it redirects the connection request. }```

dkulic (Wed, 11 Mar 2020 14:36:42 GMT):
Regarding connection redirection feature, redirect details added to a message look like ```RedirectDetail { DID: String, inviter pairwise did of the old connection verKey: String, inviter pairwise verKey of the old connection publicDID: Optional, String, inviter public did theirDID: String, invitee pairwise did of the old connection theirVerKey: String, invitee pairwise verKey of the old connection theirPublicDID: Optional, String, invitee public did signature: String, signature of concatenated theirDID and theirVerKey, so that invitee proves possesion of private key for DID to which it redirects the connection request. }```

dkulic (Wed, 11 Mar 2020 14:36:42 GMT):
Regarding connection redirection feature, redirect details added to a message look like ```RedirectDetail { DID: String, inviter pairwise did of the old connection verKey: String, inviter pairwise verKey of the old connection publicDID: Optional, String, inviter public did theirDID: String, invitee pairwise did of the old connection theirVerKey: String, invitee pairwise verKey of the old connection theirPublicDID: Optional, String, invitee public did signature: String, signature of concatenated theirDID and theirVerKey, invitee proves possesion of private key for DID to which it redirects the connection request. }```

dkulic (Wed, 11 Mar 2020 14:39:49 GMT):
Other than that a new status is added `Redirected` with value `"MS-107"`

dkulic (Wed, 11 Mar 2020 14:45:16 GMT):
The message containing this looks very similar as standard answer message: ```ConnectionRequestRedirect { sendMsg: bool, @id: String, replyToMsgId: Optional, String, keyDlgProof: Optional, KeyDlgProof, senderDetail: SenderDetail, redirectDetail: RedirectDetail, senderAgencyDetail: ForwardAgentDetail, answerStatusCode: MessageStatusCode, ~thread: Thread, }``` with added `redirectDetail` data and `answerStatusCode` set to `Redirected` instead of `Accepted`.

dkulic (Wed, 11 Mar 2020 14:45:37 GMT):
@swcurran Hope this helps?

swcurran (Wed, 11 Mar 2020 14:52:01 GMT):
Yes - thanks!

thomas_kim (Thu, 12 Mar 2020 10:49:04 GMT):
Question about LibVCX. If I use libvcx, I need to serialize objects (connections, credential offers, presentaion requests ...) and store them in the wallet with a non-secrets APIs because libvcx doesn't store objects. What about credentials? When the credential.update_state() is called from the edge agent, I believe credentials are stored in the wallet of the edge agnet so that proof.get_creds() can retrieve credentials in the edge agent's wallet later. With that said, if I want to get / delete credentials, which APIs should I use? I can't find any APIs for getting / deleting credentials in the wallet. Do I need to use libIndy APIs instead of libvcx APIs for this?

thomas_kim (Thu, 12 Mar 2020 10:49:04 GMT):
@sergey.minaev Question about LibVCX. If I use libvcx, I need to serialize objects (connections, credential offers, presentaion requests ...) and store them in the wallet with a non-secrets APIs because libvcx doesn't store objects. What about credentials? When the credential.update_state() is called from the edge agent, I believe credentials are stored in the wallet of the edge agnet so that proof.get_creds() can retrieve credentials in the edge agent's wallet later. With that said, if I want to get / delete credentials, which APIs should I use? I can't find any APIs for getting / deleting credentials in the wallet. Do I need to use libIndy APIs instead of libvcx APIs for this?

thomas_kim (Thu, 12 Mar 2020 10:49:04 GMT):
@sergey.minaev Question about LibVCX. If I use libvcx, I need to serialize objects (connections, credentials, credential offers, presentaion requests ...) and store them in the wallet with a non-secrets APIs because libvcx doesn't store objects. What about credentials? When the credential.update_state() is called from the edge agent, I believe credentials are stored in the wallet of the edge agnet so that proof.get_creds() can retrieve credentials in the edge agent's wallet later. With that said, if I want to get / delete credentials, which APIs should I use? I can't find any APIs for getting / deleting credentials in the wallet. Do I need to use libIndy APIs instead of libvcx APIs for this?

thomas_kim (Thu, 12 Mar 2020 10:49:04 GMT):
@sergey.minaev Question about LibVCX. If I use libvcx, I need to serialize objects (connections, credentials, credential offers, presentaion requests ...) and store them in the wallet with a non-secrets APIs because libvcx doesn't store objects. What about credentials? When the credential.update_state() is called from the edge agent, I believe credentials are stored in the wallet of the edge agnet so that proof.get_creds() can retrieve credentials in the edge agent's wallet later. With that said, if I want to get credentials, I think I can utilize vcx_get_credential API. However, I can't find any API for deletion... Do I need to use libIndy APIs instead?

thomas_kim (Thu, 12 Mar 2020 10:49:04 GMT):
@sergey.minaev Question about LibVCX. Doesn't it provide a delete_credential API? If I use libvcx, I need to serialize objects (connections, credentials, credential offers, presentaion requests ...) and store them in the wallet with a non-secrets APIs because libvcx doesn't store objects. What about credentials? When the credential.update_state() is called from the edge agent, I believe credentials are stored in the wallet of the edge agnet so that proof.get_creds() can retrieve credentials in the edge agent's wallet later. With that said, if I want to get credentials, I think I can utilize vcx_get_credential API. However, I can't find any API for deletion... Do I need to use libIndy APIs instead?

thomas_kim (Thu, 12 Mar 2020 10:49:04 GMT):
@sergey.minaev Question about LibVCX. Doesn't it provide a delete_credential API? If I use libvcx, I need to serialize objects (connections, credentials, credential offers, presentaion requests ...) and store them in the wallet with a non-secrets APIs because libvcx doesn't store objects. What about credentials? When the credential.update_state() is called from the edge agent, I believe credentials are stored in the wallet of the edge agnet so that proof.get_creds() can retrieve credentials in the edge agent's wallet later. With that said, if I want to get credentials, I think I can utilize `vcx_get_credential` API. However, I can't find any API for deletion... Do I need to use libIndy APIs instead?

thomas_kim (Thu, 12 Mar 2020 10:49:04 GMT):
@sergey.minaev Question about LibVCX. Doesn't it provide a *delete_credential API*? If I use libvcx, I need to serialize objects (connections, credentials, credential offers, presentaion requests ...) and store them in the wallet with a non-secrets APIs because libvcx doesn't store objects. What about credentials? When the credential.update_state() is called from the edge agent, I believe credentials are stored in the wallet of the edge agnet so that proof.get_creds() can retrieve credentials in the edge agent's wallet later. With that said, if I want to get credentials, I think I can utilize `vcx_get_credential` API. However, I can't find any API for deletion... Do I need to use libIndy APIs instead?

Abhishekkishor (Thu, 12 Mar 2020 19:25:28 GMT):
Has joined the channel.

gut (Wed, 18 Mar 2020 13:46:15 GMT):
if someone has some experience debugging, check this libindy segfault: https://jira.hyperledger.org/browse/IS-1500, will help a lot

CyrilLeung (Thu, 19 Mar 2020 06:51:43 GMT):
Has left the channel.

DucaDellaForcoletta (Thu, 19 Mar 2020 10:41:58 GMT):
Anyone know when TAA will be activated on the mainnet?

ashcherbakov (Thu, 19 Mar 2020 11:06:01 GMT):
As I know, it has been already activated.

DucaDellaForcoletta (Thu, 19 Mar 2020 11:18:40 GMT):
:thumbsup: Yes, is activated. Thanks

xtianus79 (Fri, 20 Mar 2020 00:50:23 GMT):
Has joined the channel.

xtianus79 (Fri, 20 Mar 2020 00:50:24 GMT):
hello

eduelias (Fri, 20 Mar 2020 15:01:18 GMT):
Hello! I'm trying to run the NodeJS examples from indy-sdk but, after installing indy-sdk and adding it to the PATH (LD_LIBRARY_PATH), I'm getting 14 errors like this: `indy.obj : error LNK2001: unresolved external symbol indy_append_request_endorser [C:\Users\du7\reps\tykn\indy-sdk\samples\nodejs\node_modules\indy-sdk\build\indynodejs.vcxproj]`, Can someone help me please!?

PatrikStas (Fri, 20 Mar 2020 15:03:22 GMT):
I don't know details about indysdk on windows, but I the issue is that the nodejs cannot load up indysdk binaries on your system. Have you compiled indysdk? You need to do that, which I suppose on windows gives you some `.dll`s which then you have to put into some system library directory (don't know where is it on windows)

PatrikStas (Fri, 20 Mar 2020 15:03:50 GMT):
*compiled libindy

eduelias (Fri, 20 Mar 2020 15:04:14 GMT):
THanks for the fast answer. I've downloaded them compiled from the sovrin repo as the docs says

eduelias (Fri, 20 Mar 2020 15:04:22 GMT):
I'll try to compile it, then.

eduelias (Fri, 20 Mar 2020 16:38:29 GMT):
I'll leave this here: I was running npm i from master (sdk 1.14) but downloaded the 1.9 binaries. Changing them to 1.14 made it work.

conanoc (Mon, 23 Mar 2020 09:49:11 GMT):
Have you tried to make a symbolic link for libsodium.18.dylib instead of renaming libsodium.23.dylib ?

conanoc (Tue, 24 Mar 2020 03:30:35 GMT):
A question about the *master_secret_id* of the prover(or holder). The prover creates a master_secret_id in getting_started.py like this: `alice['master_secret_id'] = await anoncreds.prover_create_master_secret(alice['wallet'], None)`. It is used to request credentials and also used to create proofs for proof requests. Do "agents" have to save this master_secret_id themselves? If the master_secret_id is already saved in the wallet, is there any APIs to retrieve the master_secret_id from the wallet?

tomislav (Tue, 24 Mar 2020 12:46:39 GMT):
Yes, implementations need to save this id somewhere. You can use the `non_secrets` API to store records and retrieve them later.

pknowles (Tue, 24 Mar 2020 14:40:23 GMT):
Yes, that looks like a slightly different issue but good to see it discussed in this thread as it is closely related.

sklump (Tue, 24 Mar 2020 15:17:41 GMT):
Sample code: https://github.com/PSPC-SPAC-buyandsell/von_anchor/blob/7f39d1a6dcd3e5c0f363fe84a8838f0ec474aa21/von_anchor/wallet/wallet.py#L492

conanoc (Wed, 25 Mar 2020 03:06:09 GMT):
Thank you for your answers. Now I can understand that the master_secret_id is not a secret itself but a id or a name for the secret saved in the wallet.

domwoe (Wed, 25 Mar 2020 11:57:36 GMT):
For a use case I need to use the private key that controls the public DID outside of indy-sdk. Is there a way to export the private key or what would be the best approach to do this?

tomislav (Wed, 25 Mar 2020 12:55:03 GMT):
Correct. It's usually a guid reference

rileyphughes (Wed, 25 Mar 2020 15:39:20 GMT):
https://tykn.tech/how-to-find-private-keys-in-hyperledger-indy/

swcurran (Wed, 25 Mar 2020 16:12:27 GMT):
And IMHO it's a really bad idea.

swcurran (Wed, 25 Mar 2020 16:13:22 GMT):
For example, is there a way to achieve what you need without bringing the private key into the light?

tomislav (Wed, 25 Mar 2020 16:22:21 GMT):
Private keys are used for encryption and signing, and you can achieve both using libindy outside of any agent context.

tomislav (Wed, 25 Mar 2020 16:22:21 GMT):
Private keys are used for decryption and signing, and you can achieve both using libindy outside of any agent context.

domwoe (Wed, 25 Mar 2020 16:30:33 GMT):
The use case is to be able to sign "static" JWT-verifiable presentations with a key bound to the Indy DID and accessible via a simple REST interface. Yeah, I could do that with libindy.

conanoc (Thu, 26 Mar 2020 07:59:52 GMT):
In the "Indy Walkthrough", the verification scenario is somewhat unrealistic. Acme Corp is requesting Alice to provide a proof for the transcript of the Faber College. To make the request possible, Acme corp must have a list of all colleges including Faber. Acme corp must have a list of credential definition IDs of all colleges. And the credential schemas of all the colleges must have the same attribute names. Am I missing something?

mccown (Thu, 26 Mar 2020 12:29:00 GMT):
Just a reminder about the Identity Implementer's WG Call later today (9am MT). This is a chance to get updates on the WG calls you may have missed this week. Our guest, Cam Parra (Kiva), will be giving an overview and demonstration of the Kiva platform. Here is the calendar invite with times and Zoom details. https://tinyurl.com/wmtosxn

esplinr (Thu, 26 Mar 2020 12:46:38 GMT):
Currently, the list of valid issuers is managed by the verifier application. As part of the current work to adopt W3C Verifiable Credentials and Rich Schemas, it will be on the ledger as part of the proof presentation definition.

esplinr (Thu, 26 Mar 2020 12:54:10 GMT):
The verifying agent should be using the list of authorized issuers that is published by the credential governance authority accepted for their use case.

domwoe (Thu, 26 Mar 2020 13:50:03 GMT):
So given ACA-PY with wallet type indy-wallet and postgres storage. Is it possible to open the same wallet from another from another instance of libindy? E.g. I've Docker container with my postgres db, container with ACA-PY, and a third container with another instance of libindy that opens the same wallet from the postgres db.

domwoe (Thu, 26 Mar 2020 22:16:16 GMT):
Seems not to work :( I created a wallet with ACA-PY and tried to access the wallet from another container with indy-cli. If I just try to open the wallet I get wallet isn't attached. If I try to create a wallet with the same name I get Wallet already exists.

domwoe (Thu, 26 Mar 2020 22:16:16 GMT):
ok, there's also a wallet *attach* command :sweat_smile:

conanoc (Fri, 27 Mar 2020 01:11:58 GMT):
I see. Thanks.

Abhishekkishor (Fri, 27 Mar 2020 17:49:48 GMT):
Hello Guys, Hope you are doing well. I have a query. How to do performance testing of hyperledger indy? Is there any tool for that?

esplinr (Fri, 27 Mar 2020 20:38:59 GMT):
I responded in #indy

mohammadhossein73 (Sun, 29 Mar 2020 05:48:25 GMT):
Has joined the channel.

konda.kalyan (Wed, 01 Apr 2020 05:32:44 GMT):
Has joined the channel.

kdenhartog (Wed, 01 Apr 2020 12:49:51 GMT):
If you want more details of how that might work, take a look at this discussion https://github.com/hyperledger/aries-rfcs/issues/406 and this RFC in Aries: https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0430-machine-readable-governance-frameworks

sklump (Wed, 01 Apr 2020 13:59:52 GMT):
Indy-sdk 1.15.0 still has a problem with zero-valued credentials. Apply ``` --- a/wrappers/python/tests/interation/test_interaction.py +++ b/wrappers/python/tests/interation/test_interaction.py @@ -17,6 +17,7 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand(pool_nam issuer_wallet_handle = wallet_handle prover_did, _ = identity_my1 + ZERO = '0' # Prover Creates Wallet and Get Wallet Handle prover_wallet_config = '{"id":"prover_wallet"}' @@ -94,7 +95,7 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand(pool_nam cred_values_json = json.dumps({ "sex": { "raw": "male", "encoded": "5944657099558967239210949258394887428692050081607692519917050011144233115103"}, - "name": {"raw": "Alex", "encoded": "1139481716457488690172217916278103335"}, + "name": {"raw": ZERO, "encoded": ZERO}, "height": {"raw": "175", "encoded": "175"}, "age": {"raw": "28", "encoded": "28"} }) @@ -217,7 +218,7 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand(pool_nam (rev_reg_id, rev_reg_json, identifier) = await ledger.parse_get_revoc_reg_response(get_revoc_reg_response) # Verifier verify proof - assert 'Alex' == proof['requested_proof']['revealed_attrs']['attr1_referent']['raw'] + assert ZERO == proof['requested_proof']['revealed_attrs']['attr1_referent']['raw'] schemas_json = json.dumps({schema_id: json.loads(schema_json)}) credential_defs_json = json.dumps({cred_def_id: json.loads(cred_def_json)}) ``` to `wrappers/python/tests/test_interation/test_interaction.py` and watch the fireworks.

sklump (Wed, 01 Apr 2020 13:59:52 GMT):
Indy-sdk 1.15.0 still has a problem with zero-valued credential attributes. Apply ``` --- a/wrappers/python/tests/interation/test_interaction.py +++ b/wrappers/python/tests/interation/test_interaction.py @@ -17,6 +17,7 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand(pool_nam issuer_wallet_handle = wallet_handle prover_did, _ = identity_my1 + ZERO = '0' # Prover Creates Wallet and Get Wallet Handle prover_wallet_config = '{"id":"prover_wallet"}' @@ -94,7 +95,7 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand(pool_nam cred_values_json = json.dumps({ "sex": { "raw": "male", "encoded": "5944657099558967239210949258394887428692050081607692519917050011144233115103"}, - "name": {"raw": "Alex", "encoded": "1139481716457488690172217916278103335"}, + "name": {"raw": ZERO, "encoded": ZERO}, "height": {"raw": "175", "encoded": "175"}, "age": {"raw": "28", "encoded": "28"} }) @@ -217,7 +218,7 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand(pool_nam (rev_reg_id, rev_reg_json, identifier) = await ledger.parse_get_revoc_reg_response(get_revoc_reg_response) # Verifier verify proof - assert 'Alex' == proof['requested_proof']['revealed_attrs']['attr1_referent']['raw'] + assert ZERO == proof['requested_proof']['revealed_attrs']['attr1_referent']['raw'] schemas_json = json.dumps({schema_id: json.loads(schema_json)}) credential_defs_json = json.dumps({cred_def_id: json.loads(cred_def_json)}) ``` to `wrappers/python/tests/test_interation/test_interaction.py` and observe. In particular, ``` E indy.error.AnoncredsProofRejected ../../indy/anoncreds.py:1756: AnoncredsProofRejected ``` I've added a comment to https://jira.hyperledger.org/browse/IS-1521 for posterity.

rantoinne (Wed, 01 Apr 2020 14:56:54 GMT):
Has joined the channel.

rantoinne (Wed, 01 Apr 2020 14:56:54 GMT):
@Artemkaaas @PatrikStas @swcurran @leon_dobnik. Hi all I am trying to add `libsodium` in a React Native project. When I build the sdk I get build errors inside my React dependencies. Can anyone help me to understand how to add libsodium inside React native project.

PatrikStas (Wed, 01 Apr 2020 15:01:03 GMT):
@rantoinne my colleague @jakubkoci wrote article describing building libvcx on ios. The process includes libsodium as well, so maybe this will be of some help? https://dev.to/jakubkoci/how-to-build-a-vcx-ios-library-f32

rantoinne (Wed, 01 Apr 2020 15:12:26 GMT):
@PatrikStas thanks for the quick response. I have gone through @jakubkoci article and its very much compatible for native iOS/ macOS projects. Thanks for giving the reference but I would like to know the procedure of doing the same for RN projects as this leads to conflict in React dependencies.

PatrikStas (Wed, 01 Apr 2020 15:15:51 GMT):
I don't have much mobile experience, but do you need to add libsodium as your dependency on react native project level? Isn't it enough to refer to some React Native comptabile IndySDK wrapper and then just make sure compiled libindy and libsodium binaries are bundled in?

rantoinne (Wed, 01 Apr 2020 15:51:25 GMT):
I explored those but none of them builds libsodium within the library

tomislav (Thu, 02 Apr 2020 12:27:57 GMT):
I'm trying to install libindy from stable channel on ubuntu-18.04. Using the following repo ``` RUN apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CE7709D068DB5E88 RUN add-apt-repository "deb https://repo.sovrin.org/sdk/deb xenial stable" ``` However, I get this error ``` The following packages have unmet dependencies: libindy : Depends: libsodium18 but it is not installable E: Unable to correct problems, you have held broken packages. ``` It works if I use `master`, but it only installs libindy 1.14.2. Any ideas how to fix this?

smithbk (Thu, 02 Apr 2020 13:34:57 GMT):
Hi anyone, is it possible for a prover to generate a single proof which can be verified by multiple verifiers?

sklump (Thu, 02 Apr 2020 13:42:04 GMT):
The proof includes elements that arise from the proof request. If two verifiers made proof requests with the same requested attributes, predicates, (and if applicable, non-revocation intervals), I think the same proof would suffice for both?

lsm (Thu, 02 Apr 2020 14:04:03 GMT):
Has joined the channel.

smithbk (Thu, 02 Apr 2020 14:04:27 GMT):
The reason I thought this might not work potentially is because of the nonce at https://github.com/hyperledger/indy-sdk/blob/57dcdae74164d1c7aa06f2cccecaae121cefac25/libindy/src/api/anoncreds.rs#L1419, but I guess as long as the prover also shares the proof request (including the nonce) with the multiple verifiers, this would work.

sklump (Thu, 02 Apr 2020 15:23:34 GMT):
Why would you do this terrible thing? The point of the toolkit is to generate proof. Use it, no?

tomislav (Thu, 02 Apr 2020 21:11:08 GMT):
Nonce is there to prevent replay attacks. They may not care about this protection, in which case, proof request structure can be agreed on upfront.

MALodder (Thu, 02 Apr 2020 23:03:52 GMT):
the nonce also protects the verifier from a malicious prover

domwoe (Fri, 03 Apr 2020 06:24:21 GMT):
I'd really like to understand this point better. What exactly could a malicious prover achieve if she is able to craft the nonce.

domwoe (Fri, 03 Apr 2020 06:26:51 GMT):
I've question concerning restrictions in a proof request. The restrictions of an attribute are an array. If I provide multiple restrictions are these *OR* or *AND* ?

sklump (Mon, 06 Apr 2020 10:21:56 GMT):
OR between dicts within the list, AND between entries per dict. E.g. ``` [ { ] ```

sklump (Mon, 06 Apr 2020 10:21:56 GMT):
OR between dicts within the list, AND between entries per dict. E.g. ``` [ { "schema_name": "transcript", "schema_origin_did": "abcd1234..." # Ontario government }, { "schema_name": "relevé", "schema_origin_did": "efgh5678..." # Quebec government }, ] ``` specifies transcript schema from one origin DID or the other.

sklump (Mon, 06 Apr 2020 10:21:56 GMT):
OR between dicts within the list, AND between entries per dict. E.g. ``` [ { "schema_name": "transcript", "schema_origin_did": "abcd1234..." # Ontario government }, { "schema_name": "relevé", "schema_origin_did": "efgh5678..." # Québec government }, ] ``` specifies transcript schema from one origin DID or the other.

Diiaablo95 (Mon, 06 Apr 2020 13:26:07 GMT):
Hello people! I have tried so hard, but I still did not manage to solve the permission error that I get every time I try to save some tails files in an Android application. I updated to libindy 1.15.0, but still I get the same error (https://postimg.cc/mcyzL50q). I also tried to pre-create the needed folder and set world-wide read/write permissions on it, with no luck. Has anyone had the same problem, and been able to find a solution? The error says: *V/indy::api::anoncreds: prepare_result_3: >>> Err(IndyError { inner: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }*

letsblockchain (Tue, 07 Apr 2020 05:03:30 GMT):
Has joined the channel.

FarhanShafiq (Tue, 07 Apr 2020 11:35:51 GMT):
Hello everyone, I'm trying to install indy-sdk nodejs package on ubuntu 18.04 but getting below errors: gyp ERR! build error gyp ERR! stack Error: `make` failed with exit code: 2 gyp ERR! stack at ChildProcess.onExit (/usr/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:194:23) gyp ERR! stack at ChildProcess.emit (events.js:315:20) gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:275:12) gyp ERR! System Linux 4.15.0-91-generic gyp ERR! command "/usr/bin/node" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild" gyp ERR! cwd /var/www/production/akawe-sdk/source/node_modules/indy-sdk gyp ERR! node -v v13.12.0 gyp ERR! node-gyp -v v5.1.0 gyp ERR! not ok Using latest libindy 1.15.0-bionic Using gcc 8.4.0 also tried with 7.4.0 cmake version 3.17.0

FarhanShafiq (Tue, 07 Apr 2020 11:36:29 GMT):
and installation latest indy-sdk package npm i -S indy-sdk@latest

FarhanShafiq (Tue, 07 Apr 2020 11:39:53 GMT):
btw, I'm not getting any error on my local machine linux mint and using the same above packages. I'm not able to figure out which package I'm missing.

FarhanShafiq (Tue, 07 Apr 2020 11:39:53 GMT):
btw, I'm not getting any error on my local machine linux mint and using the same above packages. I'm unable to figure out which package I'm missing.

FarhanShafiq (Tue, 07 Apr 2020 11:48:53 GMT):
Resolved: I'm getting this error on latest nodejs version

FarhanShafiq (Tue, 07 Apr 2020 12:03:32 GMT):
I'm able to install indy-sdk using node 8.x version. Is there way to install it with latest nodejs?

ankita.p (Wed, 08 Apr 2020 12:34:32 GMT):
sovrin

tomislav (Wed, 08 Apr 2020 12:47:24 GMT):
The state of indy-sdk on Android is very unstable right now. If you grant your app access to external storage (read/write) this problem will go away. Another option is to pass the path to the tails file in the configuration json string and not use the libindy default path. Same issue happens with creating pool configurations.

ultimo2020 (Wed, 08 Apr 2020 14:45:11 GMT):
Has joined the channel.

ultimo2020 (Thu, 09 Apr 2020 09:36:13 GMT):
Greetings everyone. I am going trough the Python samples in this url: https://github.com/hyperledger/indy-sdk/blob/master/docs/how-tos/write-did-and-query-verkey/python/utils.py I have seen that for the DID creation and all other ledger actions, the ledger interraction is bein local with DOCKER containers, the 4 ones. I have now got test tokens for the Sovrin Builder Net. Does anyone knows similar Python samples from Sovrin so that one can play around with the "pool" of Sovrin builder net or staging and to do writes there and not on the local indy Docker nodes? Thanks in advance,

zossimov (Thu, 09 Apr 2020 13:07:49 GMT):
Has joined the channel.

swcurran (Thu, 09 Apr 2020 15:36:52 GMT):
The primary change you make is just to use the genesis files from the network you want to use. We used the same steps as were outlined in that process to write the same object types to the Sovrin MainNet. Of course you have to create the objects you want, and the endorser will be doing their part in their own environment.

lynn.bendixsen (Thu, 09 Apr 2020 15:37:00 GMT):
I helped write some code for Sovrin that has examples of connecting to a pool, using the TAA, transferring tokens, writing an Endorser DID to the ledger, etc. I can paste some excerpts here if you have a more specific question, but here is the raw python code: https://github.com/sovrin-foundation/community-tools/blob/master/selfserve/main_selfserve/nym.py

ultimo2020 (Thu, 09 Apr 2020 16:35:38 GMT):
Thanks. Will check it out and get back to you guys

ultimo2020 (Thu, 09 Apr 2020 18:01:37 GMT):
Hi. What I see in the utils.py it is pointing to local pool of nodes with 127.0.0.1 with the get_pool_genesis_txn_path(pool_name) function. Do I need to point to Sovrin nodes or no need to? I see in the code from Lynn he defined a network as a function parameter

swcurran (Thu, 09 Apr 2020 18:04:19 GMT):
You need to use one of the methods for passing in a genesis file. I'm not certain, but I think the scripts support GENESIS_URL and GENESIS_FILE as environment variables. Scanning the scripts should tell you.

lynn.bendixsen (Thu, 09 Apr 2020 18:23:13 GMT):
Yes, you need to point to the Sovrin BuilderNet genesis file and create a pool using that file to be able to access the BuilderNet. Here is a link to the genesis file for BuilderNet: https://raw.githubusercontent.com/sovrin-foundation/sovrin/master/sovrin/pool_transactions_builder_genesis

lynn.bendixsen (Thu, 09 Apr 2020 18:23:13 GMT):
Yes, you need to download and point to the Sovrin BuilderNet genesis file and create a pool using that file to be able to access the BuilderNet. Here is a link to the genesis file for BuilderNet: https://raw.githubusercontent.com/sovrin-foundation/sovrin/master/sovrin/pool_transactions_builder_genesis

ultimo2020 (Thu, 09 Apr 2020 18:24:28 GMT):
Thanks for the fast help. I have found now in the script from lynn the following:

ultimo2020 (Thu, 09 Apr 2020 18:24:29 GMT):
if bool(errors) == False: logging.debug("No errors found in request...") # Get the steward seed and pool genesis file config = configparser.ConfigParser() try: configFile = os.path.join(lambdaTaskRoot, "nym.ini") config.read_file(open(configFile)) #stewardSeed = config['steward']['Seed'] genesisFile = os.path.join(lambdaTaskRoot, config['pool']['GenesisFile']) except FileNotFoundError as exc: raise Exception("Service configuration error. Configuration file {} not found".format(str(configFile))) except KeyError as exc: raise Exception("Service configuration error. Key {} not found.".format(str(exc))) poolName = genesisFile.split("_")[-2]

ultimo2020 (Thu, 09 Apr 2020 18:25:09 GMT):
I will go more in detail trough the script and try to write my own version and will share of course later.

lynn.bendixsen (Thu, 09 Apr 2020 18:29:37 GMT):
In the code example I sent, a pool has already been created on the local servers wallet with a name of buildernet (or similar) so you will either have to do the same, or write new code that creates the pool before you connect to the pool.

ultimo2020 (Thu, 09 Apr 2020 18:35:44 GMT):
Thanks Lynn. In your nym.py you have created your pool. You have used: pool_name = network for defining it. Will take a deeper look and get back. Nice examples. Thanks

carlojbs (Thu, 09 Apr 2020 19:19:37 GMT):
Hello Everyone. I'm seeking some guidance in regards to what the verification protocol of proof messages actually checks. Let say I have a credential modeled such that is has the ID of a company as an attribute. Will the verification process check if the ID raw value is the same ID that the Issuer added when it created the credential? Or is that something that is handled by the "business" logics from - say - a web application controller and some "off-chain" data? I know the predicates section of the Proof Request has like functionality to verify raw values against a predicate, but as far as I understand, that is intended for use-cases where privacy is desired, hence the use of ZKP. Thanks for any help provided!

sklump (Thu, 09 Apr 2020 20:18:27 GMT):
The proof request shapes the information in the corresponding proof. The proof request can request attribute values from credentials, or it can request numeric (32-bit int) predicates (e.g., score >= 90). Indy-sdk creates proof from credentials in the holder/prover's wallet, and the cryptography in the offer/issue process guarantees the (1) identity of the issuer as anchored to the ledger (blockchain) and (2) that the credential attributes are as the issuer issued them.

sklump (Thu, 09 Apr 2020 20:18:27 GMT):
The proof request shapes the information in the corresponding proof. The proof request can request attribute values from credentials, or it can request numeric (32-bit int) predicates (e.g., score >= 90). Indy-sdk creates proof from credentials in the holder/prover's wallet, and the cryptography in the offer/issue process guarantees the (1) identity* of the issuer as anchored to the ledger (blockchain) and (2) that the credential attributes are as the issuer issued them. \* identity in this case meaning control of private key

sklump (Thu, 09 Apr 2020 20:18:27 GMT):
The proof request shapes the information in the corresponding proof. The proof request can request attribute values from credentials, or it can request numeric (32-bit int) predicates (e.g., score >= 90). Indy-sdk creates proof from credentials in the holder/prover's wallet, and the cryptography in the offer/issue process guarantees the (1) identity* of the issuer as anchored to the ledger (blockchain) and (2) that the credential attributes are as the issuer issued them. * identity in this case meaning control of private key

PatrikStas (Thu, 09 Apr 2020 21:06:01 GMT):
Hello fellow indy devs, I've released and just redeployed new version of Indyscan https://indyscan.io/ Brings some nice UI/UX improvments, most notably live updates on homepage. No need to refresh page anymore. Enjoy.

ShrutiHK (Fri, 10 Apr 2020 01:48:39 GMT):
Has joined the channel.

rakaar (Fri, 10 Apr 2020 16:34:54 GMT):
Has joined the channel.

wizAmit (Sat, 11 Apr 2020 15:25:56 GMT):
Has joined the channel.

aditya520 (Mon, 13 Apr 2020 13:57:01 GMT):
Has joined the channel.

Diiaablo95 (Tue, 14 Apr 2020 06:44:15 GMT):
Hello! Well, I do not have the same problems with the pool configuration file. The app has read/write access to the external storage (also because I can indeed write the pool config file from a hardcoded JSON). I have tried running both on emulator and physical device, in default files folder, cache folder, any other path. Same result, no matter what...

Diiaablo95 (Tue, 14 Apr 2020 06:49:29 GMT):
This is how I initialise the tails writer: `JSONObject tailsWriterConfig = new JSONObject().put("base_dir", IndyUtils.getTailsFilePath()).put("uri_pattern", "");` where `IndyUtils.getTailsFilePath()` = `context.getExternalFilesDir(null).getAbsolutePath() + "/tails"`

Diiaablo95 (Tue, 14 Apr 2020 07:01:34 GMT):
I can even create the file using the `File` class. The exception is thrown when I try to write the revocation registry information via the tails writer. (Tried again just now, same issue).

rakaar (Tue, 14 Apr 2020 14:13:04 GMT):
Hello all, I am trying to run indy-sdk node js sample But it stops every time with an error: `(node:30832) UnhandledPromiseRejectionWarning: IndyError: LedgerNotFound` In the story, it basically stops at this step : `Apply for the job with Acme - Transcript proving` Can anyone tell me why is the issue occurring? EDIT: After putting some console.logs in the code, it seems that it is unable to find the Job Credential schema. Hence exiting with indy error code 309 LedgerNotFound(item not found on ledger) Why is this so?

SethiSaab (Wed, 15 Apr 2020 08:45:29 GMT):
Is there anyone who has done KeyCloak SSo integration with DIDs ?

rileyphughes (Wed, 15 Apr 2020 14:28:43 GMT):
This demo shows KeyCloak OIDC integration with verifiable credentials https://github.com/bcgov/vc-authn-oidc/blob/master/docs/DemoInstructions.md

DibbsZA (Thu, 16 Apr 2020 22:56:54 GMT):
I have managed to get that to work (with much challenges) Very gratefull for the help from @esune

ultimo2020 (Sat, 18 Apr 2020 12:23:47 GMT):
Hi everyone. I was trying to start the indy-sdk python sample and getting some errors on this version: >>> print (sys.version) 3.5.2 (default, Oct 8 2019, 13:06:37) [GCC 5.4.0 20160609] ---- The errors are invalid syntax: /indy-sdk/samples/python# python3.5 -m src.main Traceback (most recent call last): File "/usr/lib/python3.5/runpy.py", line 184, in _run_module_as_main "__main__", mod_spec) File "/usr/lib/python3.5/runpy.py", line 85, in _run_code exec(code, run_globals) File "/root/indy-sdk/samples/python/src/main.py", line 3, in from src import anoncreds, anoncreds_revocation, crypto, ledger, getting_started, txn_author_agreement, endorser File "/root/indy-sdk/samples/python/src/anoncreds.py", line 3, in from indy import anoncreds, wallet File "/usr/local/lib/python3.5/dist-packages/indy/__init__.py", line 1, in from indy.error import IndyError File "/usr/local/lib/python3.5/dist-packages/indy/error.py", line 118 error_code: ErrorCode ^ SyntaxError: invalid syntax

ultimo2020 (Sat, 18 Apr 2020 13:00:08 GMT):
looks better with python3.8

ultimo2020 (Sat, 18 Apr 2020 13:22:55 GMT):
Hi. I can run and see here all of the python scripts: https://github.com/hyperledger/indy-sdk/tree/master/samples/python Is there maybe a wallet or similar demo with with a small http GUI ?

daveek (Sun, 19 Apr 2020 12:35:17 GMT):
Hi, Can anyone please explain or share some docs about Indy/Aries Threat Model? a) What's the Threat Model for Hyperledger Indy/Aries? b) Where is Indy/Aries most vulnerable to attack? c) What are the most relevant threats? d) What do I need to do to safeguard against these threats?

ultimo2020 (Sun, 19 Apr 2020 16:31:40 GMT):
Hi I am researching the code in the https://github.com/hyperledger/indy-sdk/blob/master/docs/how-tos/write-did-and-query-verkey/README.md and understand the actions, I was wondering if there is an mobile or web demo on github of an finished indy-sdk agent, would be also great that interacts with Sovrin builder net

squeege (Mon, 20 Apr 2020 10:16:10 GMT):
Has joined the channel.

squeege (Mon, 20 Apr 2020 10:16:12 GMT):
Hi, would any be able to assist me with the following issue:

squeege (Mon, 20 Apr 2020 10:16:14 GMT):
System.DllNotFoundException: 'Unable to load DLL 'indy' or one of its dependencies: The specified module could not be found.

tomislav (Tue, 21 Apr 2020 14:52:04 GMT):
Are you on a Mac?

lynn.bendixsen (Tue, 21 Apr 2020 16:21:24 GMT):
this might be a good question to ask in the #aries channel...

ultimo2020 (Tue, 21 Apr 2020 19:01:17 GMT):
Thanks

SethiSaab (Wed, 22 Apr 2020 06:36:58 GMT):
Hi Team , I want to integrate Cloud HSM with Indy for key management . Is there anyone who has done that before ?

SethiSaab (Wed, 22 Apr 2020 06:38:15 GMT):
or if anyone can provide some reference

Pe4eHbKa (Thu, 23 Apr 2020 04:59:04 GMT):
Has joined the channel.

Pe4eHbKa (Thu, 23 Apr 2020 04:59:16 GMT):
hi guys

Pe4eHbKa (Thu, 23 Apr 2020 05:01:03 GMT):
I have question regarding getting txnId of NODE transaction - how can I get it? GET_TXN and NODE replies does not contain it

Pe4eHbKa (Thu, 23 Apr 2020 05:02:01 GMT):
usecase: connecting to new nodes (which are not at genesis file) when initial nodes are not available for any reasons

Pe4eHbKa (Thu, 23 Apr 2020 05:03:29 GMT):
main idea is dynamically generate file based on pool genesis for connection to pool, most of parameters are easy to got, except txnId...

PatrikStas (Thu, 23 Apr 2020 06:37:34 GMT):
@Pe4eHbKa `ledger custom {"reqId":1,"identifier":"V4SGRU86Z58d6TV7PBUe6f","operation":{"type":"3","ledgerId":0,"data":1},"protocolVersion":2}` change value of data, to request tx with different seqNo

PatrikStas (Thu, 23 Apr 2020 06:37:34 GMT):
@Pe4eHbKa Using indy-cli you can get pool tx by seqno like this `ledger custom {"reqId":1,"identifier":"V4SGRU86Z58d6TV7PBUe6f","operation":{"type":"3","ledgerId":0,"data":1},"protocolVersion":2}` change value of data, to request tx with different seqNo

Pe4eHbKa (Thu, 23 Apr 2020 06:41:37 GMT):
thanks a lot! can you provide name of function for SDK?

Pe4eHbKa (Thu, 23 Apr 2020 06:45:51 GMT):
am I correct: for reproduce using SDK I should use signAndSubmitRequest using this JSON {"type":"3","ledgerId":0,"data":1} as a parameter?

Pe4eHbKa (Thu, 23 Apr 2020 06:45:51 GMT):
am I correct: for reproduce using SDK I should use signAndSubmitRequest using this JSON {"type":"3","ledgerId":0,"data":1} as a request parameter?

Pe4eHbKa (Thu, 23 Apr 2020 06:47:56 GMT):
or request is whole {"reqId":1,"identifier":"V4SGRU86Z58d6TV7PBUe6f","operation":{"type":"3","ledgerId":0,"data":1},"protocolVersion":2} and reqId should be generate randomly?

Pe4eHbKa (Thu, 23 Apr 2020 07:38:19 GMT):
nwm, I have check both variant and found proper, thanks once again :)

Pe4eHbKa (Thu, 23 Apr 2020 08:42:44 GMT):
so I have try next: create network with 2 nodes, add additional 2 nodes, generate file for connect contains data for 2 new nodes, try to connect using this file

Pe4eHbKa (Thu, 23 Apr 2020 08:43:12 GMT):
receive: Error: Invalid library state. Caused by: Consistency proof verification failed.

Pe4eHbKa (Thu, 23 Apr 2020 08:44:44 GMT):
what should I do to connect to 2 new nodes instead of initial nodes?

Pe4eHbKa (Thu, 23 Apr 2020 09:01:54 GMT):
one more question: when I add to file data for all 4 nodes can't connect also with error: "Error: Invalid library state. Caused by: Ledger merkle tree is not acceptable for current tree."

sergey.minaev (Fri, 24 Apr 2020 13:23:59 GMT):
It's a excellent topic in scope of Aries KMS design. The most solid design is proposed by @MALodder as of now.

adamjlemmon (Mon, 27 Apr 2020 10:42:26 GMT):
Has joined the channel.

PatrikStas (Mon, 27 Apr 2020 15:34:45 GMT):
@Pe4eHbKa not expert on ledger, but maybe the NODE transactions just don't have a txnId? In indy transactions are already uniquely identified by seqNo within a subledger.

lsm (Tue, 28 Apr 2020 14:00:19 GMT):
Hi everyone, I am trying to connect to a public ledger with the sdk. However I get a `indy.error.PoolLedgerTimeout` in the `open_pool_ledger` function of the python wrapper when trying to connect from behind a proxy. On a machine without proxy it is no problem so I guess it is caused by the proxy. Is it possible to work with the sdk when behind a proxy?

ayushmanss (Tue, 28 Apr 2020 14:17:34 GMT):
Is there a way to cross compile the indystrgpostgres for windows

ayushmanss (Tue, 28 Apr 2020 14:17:52 GMT):
i am trying to make it work with dotnet framework

thomas_kim (Wed, 29 Apr 2020 01:08:05 GMT):
I'm interested in this topic too. Our group wants to utilize KeySotre & KeyChain for mobile devices, and HSM for the server side.

ayushmanss (Wed, 29 Apr 2020 21:33:43 GMT):
Hi all, I have run into a blocker and been banging my head since. REQUIREMENT - I want to run postgres with the aries-dotnet framework SOLUTION - I figured it can be the same as it is done with python-cloudagent. Basically load the library before calling any wallet functions and indy-sdk will take care of the rest PROBLEM - I didnt find any dll for indystrgpostgres and decided to build from source. I followed the steps exactly for building libindy for windows and the image build out without any errors but I get "Unhandled exception. System.BadImageFormatException: Bad IL format." when I try to load the library using "AssemblyLoadContext.Default.LoadFromAssemblyPath". REASON - I want to run mediator for large number of users and hence need HA and thus need a better common wallet storage for multiple instances of dotnet mediator containers running Any solution to the problem will be really helpful

tomislav (Thu, 30 Apr 2020 13:59:17 GMT):
If you're running the mediator from aries-dotnet, you don't need to scale to a database wallet storage. Mediator is built to store messages temporarily, until the holder processes them, after which they are deleted. The wallet size will be pretty low most of the time. If you're running the mediator in a container and want to preserve the wallet data, you can mount the container path `/root/.indy_wallet` to a location on your VM (or other cloud storage). This will allow you to restart the container without losing wallet data.

tomislav (Thu, 30 Apr 2020 13:59:17 GMT):
If you're running the mediator from aries-dotnet, you don't need to scale to a database wallet storage. Mediator is built to store messages temporarily, until the holder processes them, after which they are deleted. The wallet size will be pretty low most of the time. If you're running the mediator in a container and want to preserve the wallet data, you can mount the container path `/root/.indy_client` to a location on your VM (or other cloud storage). This will allow you to restart the container without losing wallet data.

SUSHOBHAN (Thu, 30 Apr 2020 14:15:58 GMT):
Has joined the channel.

Moshe7 (Thu, 30 Apr 2020 21:36:41 GMT):
Has joined the channel.

profae (Sat, 02 May 2020 14:38:01 GMT):
Has joined the channel.

rtrive (Sun, 03 May 2020 08:50:30 GMT):
Hi everybody! i’m trying to build an android app with indy sdk (1.13.0). I set up JNA 5.2.0 and i follow the guide on github repo. I develop the app based on huawei AMN-LX9 with android 9 and everything works. I tried the app on a samsung a3 2015 and it works. Then i decide to try it on Huawei p20 lite with android 9 and it return this error: here is an incompatible JNA native library installed on this system Expected: 6.0.0 Found: 5.2.0 /system/lib64:/product/lib64. To resolve this issue you may do one of the following: - remove or uninstall the offending library - set the system property jna.nosys=true - set jna.boot.library.path to include the path to the version of the jnidispatch library included with the JNA jar file you are using Same error on Galaxy note 8. I tried to search if there’s a new version of JNA but the latest is 5.5.0, so the problem still remains. Anyone has encounter this error? Thanks

Diiaablo95 (Mon, 04 May 2020 08:57:48 GMT):
Hello everyone! Assuming a *MitM* between a verifier and a prover, *how can we prevent that the malicious actor creates a DID-based connection with both parties and then simply forwards messages between?* One solution I think would be to tie credentials to DIDs that must then be used in the connection creation process. But I guess this goes against Indy principles. Does Indy support MitM protection for proof requests and proof generation? Thanks!

swcurran (Mon, 04 May 2020 13:53:04 GMT):
This is an attack we have discussed and as we left it, it is theoretically possible with current Indy, if the MITM is present at the initiation of the connection. They can't do it on arbitrary proof request/proof exchanges, but if they are in the middle in establishing the connection and remains so in the life of the connection, they can relay proof requests/proofs. Given the difficulty in managing that, we did not pursue it further at that time. In the plans for Indy is signing self-asserted claims. As I recall (but don't have the details), that could be used to make evident such a MITM.

Diiaablo95 (Mon, 04 May 2020 14:06:36 GMT):
Thanks a lot! I thought that the master secret could somehow be used to link self-asserted credentials to other credentials, making it harder for MitM to impersonate either party. So is using "certified" DIDs in the connection creation an optimal way to work around this issue?

swcurran (Mon, 04 May 2020 14:14:04 GMT):
I confess I don't recall where we ended on this, and how we would use self-asserted claims. Good that you have raised the issue in GitHub - others can weigh in.

sklump (Mon, 04 May 2020 15:55:31 GMT):
*Item:* A proof on a revoked credential verifies *true* for a proof request that does not specify a non-revocation interval pertaining to it. Is this a bug, an oversight, or a feature? Typically, the verifier will be creating the proof request but it is not a guarantee. The verifier could be verifying a proof that some other agent concocted, conspiring in fraud. The counter argument is that a revoked credential can still have data of use (e.g., my licence can vouch for my age even though the ministry revoked it). But specifying a non-revocation period ending before the revocation event could cover such a case. Opinions?

SethiSaab (Mon, 04 May 2020 19:37:32 GMT):
Hi team , I have a requirement where i want some optional attributes in schema .... indy.issuerCreateSchema(governmentDid, 'Job-Certificate', '0.2', ['first_name', 'last_name', 'salary', 'employee_status', 'experience']); Here i want 'first_name', 'last_name' as null I mean issuer can leave this values as blank at the time of issuance of VC

sklump (Tue, 05 May 2020 10:07:40 GMT):
All attributes are mandatory. In aca-py, null values come out as `"None"`. An empty string `""` is another possibility. Raw values must encode to some integer, and so attributes must have (string) values to encode.

profae (Fri, 08 May 2020 04:57:13 GMT):
Hi all, I can't configure webhooks notifications on the dummy-cloud-agent. i launched the demo in "vcx/wrappers/python3/demo" and it works in polling I have seen that the nodejs demo uses webhook notifications I modified the demo in python by passing the same "webhook_url" parameter in the config, but notifications are not sent and from the logs it seems that the config parameter has not been passed to the dummy-cloud-agen I also tried to invoke vcx_agent_update_info but from error "Unsupported message" can someone help me? Thanks

thomas_kim (Fri, 08 May 2020 09:34:17 GMT):
You would like to merge this PR: https://github.com/hyperledger/indy-sdk/pull/2112

carlojbs (Tue, 12 May 2020 17:51:09 GMT):
Hello Everyone, I need some help understanding an error I'm seeing on the log for one of the nodes. Not sure if this is the proper channel for this inquiry; Essentially one of the node is throwing the following error: CURVE I: cannot open client HELLO -- wrong server key? ... has anyone seen this before? Unfortunately i lost the ability to get the logs from the other nodes.

profae (Thu, 14 May 2020 19:17:45 GMT):
Hi all,

profae (Thu, 14 May 2020 19:18:04 GMT):
From the VCX JAVA APIs it seems that the only way to access credentials is to have a credentialHandle to invoke the getCredential It's correct? This implies that you must always save the credentialHandle to access a wallet's credentials. In the import API, only the wallet is imported, without the credentialHandle. this does not allow to list and access the wallet credentials Isn't there a list credential method that doesn't require any parameters? In the API wallet, do the records that can be searched also include credentials? thanks

thomas_kim (Fri, 15 May 2020 06:12:55 GMT):
Basically, you need to serialize/deserialize vcx objects (ex. connectionSerialize), and store them to wallet non-secret storage or even the database. Regarding get_credentials API (https://github.com/hyperledger/indy-sdk/blob/6ecf3dded79fde74206ec0939d2dda179784768c/libindy/src/api/anoncreds.rs#L1322), it is not implemented in LibVCX yet.

profae (Fri, 15 May 2020 12:32:24 GMT):
Hi all, the vcx_wallet_search_next_records is not implemented, return always the response of test: https://github.com/hyperledger/indy-sdk/blob/704f2f4aa92cc584d5e5738c6078b181f3667bbb/vcx/libvcx/src/api/wallet.rs#L712 Isn't there another method to search for records? thanks

shantsum (Sat, 16 May 2020 13:47:40 GMT):
Has joined the channel.

Moshe7 (Sat, 16 May 2020 17:04:34 GMT):
Hi all, I read that Indy-SDK going to be replaced by Aries Sdk - agent library that can be rooted to any DLT by the resolver, and Indy-SDK becomes indy-resolver. my question, it's already happened? where I can see the resolved code? there is a guide on how I can implement my own resolver? Thanks.

shantsum (Sun, 17 May 2020 02:08:57 GMT):
I've faced the same issue and I'm using mac os Catalina.

smithbk (Sun, 17 May 2020 03:31:10 GMT):
Hi, I'm trying to debug a hang when I try to create a schema on sovrin staging using the python SDK. It is hanging on the ledger.sign_and_submit_request call. I set RUST_LOG=indy=trace but not seeing any additional trace. Here is a small program to reproduce the problem. Any help is appreciated. ```import json, aiohttp, time, sys, asyncio from indy import anoncreds, wallet, ledger, pool, crypto, did, ledger, wallet from indy.error import IndyError, ErrorCode class IndyProvider: """ The indy provider isolates all indy-specific code required by the test suite. """ async def setup(self, config): print("Begin setup") if not 'genesis_url' in config: raise Exception( "The Indy provider requires a 'genesis_url' value in config.toml") self.genesis_url = config['genesis_url'] self.pool_name = config.get('pool_name', 'apts') id = config.get('name', 'test') key = config.get('pass', 'testpw') seed = config.get('seed', '0000000000000000000000000000APTS') self.cfg = json.dumps({'id': id}) self.creds = json.dumps({'key': key}) self.seed = json.dumps({'seed': seed}) try: await wallet.delete_wallet(self.cfg, self.creds) except Exception as e: pass await wallet.create_wallet(self.cfg, self.creds) self.wallet = await wallet.open_wallet(self.cfg, self.creds) self.master_secret_id = await anoncreds.prover_create_master_secret(self.wallet, None) (self.did, self.verkey) = await did.create_and_store_my_did(self.wallet, self.seed) print("DID: {}, verkey: {}".format(self.did, self.verkey)) # Download the genesis file resp = await aiohttp.ClientSession().get(self.genesis_url) genesis = await resp.read() genesisFileName = "genesis.apts" with open(genesisFileName, 'wb') as output: output.write(genesis) # Open the pool await self.open_pool({'genesis_txn': genesisFileName}) print("End setup") async def create_schema(self, name: str, version: str, attrs: [str]) -> str: (schema_id, schema) = await anoncreds.issuer_create_schema( self.did, name, version, json.dumps(attrs)) schema_request = await ledger.build_schema_request(self.did, schema) schema_request = await self.append_taa(schema_request) print("Submitting schema request to ledger ...") await ledger.sign_and_submit_request(self.pool, self.wallet, self.did, schema_request) print("Created schema {}".format(schema_id)) return schema_id async def open_pool(self, cfg): # Create the pool, but ignore the error if it already exists await pool.set_protocol_version(2) try: await pool.create_pool_ledger_config(self.pool_name, json.dumps(cfg)) except IndyError as e: if e.error_code != ErrorCode.PoolLedgerConfigAlreadyExistsError: raise e self.pool = await pool.open_pool_ledger(self.pool_name, "{}") async def append_taa(self, req): getTaaReq = await ledger.build_get_txn_author_agreement_request(self.did, None) response = await ledger.submit_request(self.pool, getTaaReq) taa = (json.loads(response))["result"]["data"] if not taa: print("Warning: no TAA found") return req text = taa["text"] if not text: print("Warning: no TAA text found") return req curTime = int(round(time.time() * 1000)) req = await ledger.append_txn_author_agreement_acceptance_to_request(req,taa["text"],taa["version"],taa["digest"],"wallet",curTime) print("Appended TAA") return req async def main(): ip = IndyProvider() await ip.setup({"genesis_url":"https://raw.githubusercontent.com/sovrin-foundation/sovrin/master/sovrin/pool_transactions_sandbox_genesis"}) await ip.create_schema("testing", "0.1", ["name","age"]) sys.exit(0) loop = asyncio.get_event_loop() asyncio.ensure_future(main()) loop.run_forever() loop.close() ```

tomislav (Sun, 17 May 2020 12:22:51 GMT):
This answer helped me get past this issue.

tomislav (Sun, 17 May 2020 12:22:53 GMT):
https://chat.hyperledger.org/channel/aries?msg=nLyZeaMc8G4aozJY5

tomislav (Sun, 17 May 2020 12:23:28 GMT):
@shantsum @squeege

shantsum (Sun, 17 May 2020 12:33:28 GMT):
Great! Thanks, @tomislav! Will give it a try!

Moshe7 (Sun, 17 May 2020 19:46:37 GMT):
Hi, anyone can help?

swcurran (Sun, 17 May 2020 23:28:43 GMT):
So your description is not quite correct. The indy ledger related capabilities of the indy sdk remain - being able to perform read/write operations to an Indy ledger, and being able to exchange Indy-format verifiable credentials. The Indy SDK Wallet will be removed and a logically equivalent storage mechanism moved to Aries. Aries will provide a pluggable interface to various ledgers, including Indy, and likewise for different verifiable credential formats. The Python and .NET frameworks currently only support Indy ledgers and VC formats, while the Go framework does not support Indy, but does support some other DID methods and credential formats. As for how to build a resolver, you can look at the Universal Resolver, and at the DID Spec on what a DID method is and how you would build your own. Part of building a DID ledger is building the resolver part of that.

swcurran (Sun, 17 May 2020 23:29:29 GMT):
https://uniresolver.io/

Moshe7 (Mon, 18 May 2020 10:42:12 GMT):
Thanks for the reply and correctness, I get my information from https://www.slideshare.net/mobile/SSIMeetup/hyperledger-aries-open-source-interoperable-identity-solution-nathan-george I think we are in the same page, Aries gets the wallet (agent) part of Indy SDK, and support Indy by the resolver, while Indy SDK tight to Indy ledger. When I write resolver I meant, Implementation of Aries-SDK interfaces for using Aries as an agent. (Not related URL resolver) Sorry, maybe I wasn't clear, English is not my native language. I hope now I'm more clear 😊.

Moshe7 (Mon, 18 May 2020 11:38:04 GMT):
So the Aries interface pluggable still in progress? If I want support my own leadger (after registrar method) which Aries implementation you recommended? (In terms of progress/maturity)

smithbk (Mon, 18 May 2020 12:58:34 GMT):
Hi, any responses to my question from May 16 is appreciated. I'm blocked on this currently.

andrew.whitehead (Mon, 18 May 2020 16:56:38 GMT):
@smithbk I don't see any obvious issues. We were running into some problems fetching data with aiohttp in the same event loop, you could try just swapping in requests instead

smithbk (Mon, 18 May 2020 17:37:05 GMT):
Thanks Andrew but since that is just used to download the genesis file and I know that it is working correctly, I wouldn't think it is related. This actually works when running using the same code to download a genesis file from a locally running ledger which doesn't have any TAA stuff enabled. Anyway, I'll give it a try anyway just to be sure.

profae (Tue, 19 May 2020 17:35:56 GMT):
Hi all, I'm trying libvcx. i tried the demo python faber and alice and it works. In the config I set protocol_type = 3 to have aries messages. But the offer that alice receives is proprietary and not aries as described here https://github.com/hyperledger/indy-sdk/blob/66f2ca498633b275ea93c4f820e2131c7051e757/vcx/libvcx/src/api/credential.rs#L142 is it right or am I wrong something in the configuration? Thanks

shantsum (Wed, 20 May 2020 10:10:38 GMT):
Hi all,

sergey.minaev (Wed, 20 May 2020 15:16:19 GMT):
To enable logs in the wrapper you have to enable native logging instead of usage of RUST_LOG env variable. For python it may be smth like `logging.basicConfig(level=0)`

sergey.minaev (Wed, 20 May 2020 17:23:20 GMT):
Hi @profae > the offer that alice receives is proprietary are you referring to actual A2A msgs which is hidden by libvcx actually or you are worried about the msg, returned from libvcxAPI to the app?

profae (Wed, 20 May 2020 17:49:42 GMT):
Hi, I am referring to Credential.get_offers, but I realized that it was not as I thought. I connected a LibVCX holder to an ACA-py endpoint and it worked, getting to issue the credentials, so the messages were of the aries type I connected the LibVCX holder to a Streetcred endpoint but it gave a json malformed error on the getOffer.

profae (Wed, 20 May 2020 17:49:42 GMT):
Hi, thank of reply. I am referring to Credential.get_offers, but I realized that it was not as I thought. I connected a LibVCX holder to an ACA-py endpoint and it worked, getting to issue the credentials, so the messages were of the aries type I connected the LibVCX holder to a Streetcred endpoint but it gave a json malformed error on the getOffer.

sergey.minaev (Wed, 20 May 2020 17:52:48 GMT):
yep the output of any API is not equivalent to actual A2A messages. It was an intentional decision to allow old apps based on libvcx to communicate with Aries world.

sergey.minaev (Wed, 20 May 2020 17:53:10 GMT):
... without significant changes in the logic

sergey.minaev (Wed, 20 May 2020 17:58:15 GMT):
it's a good sign that you are able to communicate with ACA-py. So it seems like local problem between streetcred and libvcx. Could you share more details and some logs in #aries-interop channel?

profae (Wed, 20 May 2020 18:07:15 GMT):
ok

mccown (Wed, 20 May 2020 18:16:41 GMT):
Just a reminder about the Identity Implementer's WG Call tomorrow morning (May 22st @ 9am MT). This is a chance to get updates on the WG calls you may have missed this week. Our guest will be Mike Lodder who is a crypto expert and co-leader of Hyperledger Ursa. Mike will be presenting on the new ZKP Linked Data Signature work. Here are links to the Wiki and the Zoom meeting. Wiki: https://wiki.hyperledger.org/display/IWG/2020-05-21+Identity+WG+Implementers+Call Zoom: https://zoom.us/j/244779296

mccown (Wed, 20 May 2020 18:16:41 GMT):
Just a reminder about the Identity Implementer's WG Call tomorrow morning (May 21st @ 9am MT). This is a chance to get updates on the WG calls you may have missed this week. Our guest will be Mike Lodder who is a crypto expert and co-leader of Hyperledger Ursa. Mike will be presenting on the new ZKP Linked Data Signature work. Here are links to the Wiki and the Zoom meeting. Wiki: https://wiki.hyperledger.org/display/IWG/2020-05-21+Identity+WG+Implementers+Call Zoom: https://zoom.us/j/244779296

mdoan (Wed, 20 May 2020 22:57:29 GMT):
Has joined the channel.

mdoan (Wed, 20 May 2020 22:57:29 GMT):
Hi all, I'm trying to figure out if `verifierVerifyProof` can be used to demonstrate range proof: for example, i want to prove a score within a given range [4,5]. 1/ I'm asking that because i see in ursa project supported such use case 2/ how can do do it with indy-sdk, maybe in nodejs?

sklump (Thu, 21 May 2020 10:20:46 GMT):
indy-sdk: the verifier can create a proof request with two predicates regarding the same attribute, e.g.., ``` { "nonce": "123432421212", "name": "proof_req_1", "version": "0.1", "requested_attributes": { "attr1_referent": { "name": "score" } }, "requested_predicates": { "predicate1_referent": { "name": "score", "p_type": ">=", "p_value": 4 }, "predicate2_referent": { "name": "score", "p_type": "<=", "p_value": 5 } }, "non_revoked": { "to": 1590056298 } } ```

sklump (Thu, 21 May 2020 11:58:04 GMT):
*Basic Question*: is the ledger as indy implements it documented anywhere as a specification? Surely it must be. Thanks!

RavindranParthasarathi (Thu, 21 May 2020 12:26:44 GMT):
Has joined the channel.

RavindranParthasarathi (Thu, 21 May 2020 12:26:45 GMT):
node-gyp

shenmue000 (Fri, 22 May 2020 00:53:19 GMT):
Has joined the channel.

shenmue000 (Fri, 22 May 2020 00:53:20 GMT):
Hi, I am trying to find out the implementation of crypto function call. The header files are in indy-sdk/libindy/include. But where is the actual implementation. I suppose they are in indy.dll. Is it open-sourced?

jakubkoci (Fri, 22 May 2020 07:34:45 GMT):
Hi. The implementation is in the indy-sdk repo in the libindy/src folder, so in the same folder where libindy/include folder is. It's written in Rust. For example, if I take first method from indy_crypto.h `indy_create_key`, you can find the implementation in the `src/api/crypto.rs` file.

jakubkoci (Fri, 22 May 2020 07:38:07 GMT):
If you look for underlying low-level crypto algorithms, I guess libindy relies on libsodium and Ursa project (aslo part of Hyperledger https://www.hyperledger.org/use/ursa)

profae (Fri, 22 May 2020 08:03:03 GMT):
Hi, Aries messages contain more information about the data, for example in the credential offer there is the mime-type for each attribute, a very important information. In the proprietary format this info is not there and it is a strong limitation. It would be very useful to have Aries messages as API output. thanks

sklump (Fri, 22 May 2020 14:11:08 GMT):
*Question from aca-py forum:* Is it possible to rotate an indy wallet key? I see `wallet.generate_wallet_key()` but nothing to rotate the wallet key once the wallet is already created. I may be looking in the wrong places?

shenmue000 (Fri, 22 May 2020 18:58:27 GMT):
Yes, I am looking for the low level implementation. the crypto.rs doesn't include the actual logic.

shenmue000 (Fri, 22 May 2020 18:58:27 GMT):
Yes, I am looking for the low level implementation. the crypto.rs seems not include the actual logic.

shenmue000 (Fri, 22 May 2020 18:58:27 GMT):
Thanks, I found the actual logic in the indy-sdk: src/services/anoncreds/

sklump (Mon, 25 May 2020 20:05:11 GMT):
*Help?* How do I go about rolling over the wallet encryption key? With a wallet I've created, I pass in credentials like ``` { ```

sklump (Mon, 25 May 2020 20:05:11 GMT):
*Help?* How do I go about rolling over the wallet encryption key? With a wallet I've created, I pass in credentials like ``` { "key": "...", "key_derivation_method": "RAW", "rekey": "...", "rekey_derivation_method": "RAW" } where the `rekey` value comes from `wallet.generate_wallet_key()`. After I close the wallet, I can neither open it with the old key nor the new one. Is there a sample or a test somewhere of this operation working? Thanks. ```

sklump (Mon, 25 May 2020 20:05:11 GMT):
*Help?* How do I go about rolling over the wallet encryption key? With a wallet I've created, I pass in credentials like ``` { "key": "...", "key_derivation_method": "RAW", "rekey": "...", "rekey_derivation_method": "RAW" } ``` where the `rekey` value comes from `wallet.generate_wallet_key()`. After I close the wallet, I can neither open it with the old key nor the new one. Is there a sample or a test somewhere of this operation working? Thanks.

sklump (Mon, 25 May 2020 20:05:11 GMT):
*Help?* How do I go about rolling over the wallet encryption key? With a wallet I've created, I pass in credentials like ``` { "key": "...", "key_derivation_method": "RAW", "rekey": "...", "rekey_derivation_method": "RAW" } ``` where the `rekey` value comes from `wallet.generate_wallet_key()`. After I close the wallet, I can neither open it with the old key nor the new one. The wallet has become garbage. Is there a sample or a test somewhere of this operation working? Thanks.

sklump (Mon, 25 May 2020 20:05:11 GMT):
*Help?* How do I go about rolling over the wallet encryption key? With a wallet I've created, I pass in credentials like ``` { "key": "...", "key_derivation_method": "RAW", "rekey": "...", "rekey_derivation_method": "RAW" } ``` where the `rekey` value comes from `wallet.generate_wallet_key()`. After I close the wallet, I can neither open it with the old key nor the new one. The wallet -- and hence everything in it -- has become _garbage_. Is there a sample or a test somewhere of this operation working? Thanks.

MartenMeijboom (Tue, 26 May 2020 11:34:27 GMT):
Has joined the channel.

MartenMeijboom (Tue, 26 May 2020 11:34:28 GMT):
This might be a dumb question, I'm doing a project for uni using hyperledger indy. We are using the NodeJs wrapper. While trying to get things up and running, we're following along with the to-do documents. First we create a pool ledger using createPoolLedgerConfig(poolName, poolConfig). Then we try to open the pool ledger using openPoolLedger(poolName, undefined). This results in a PoolLedgerTimeout (307) error. Anyone know why this happens? I've already checked, and the pool does exists.

ianco (Tue, 26 May 2020 18:21:37 GMT):
What Indy ledger are you connecting to?

MartenMeijboom (Tue, 26 May 2020 18:32:56 GMT):
Where do I see / configure this? :cold_sweat: And what do you recommend?

MartenMeijboom (Tue, 26 May 2020 18:35:35 GMT):

Clipboard - May 26, 2020 8:35 PM

ianco (Tue, 26 May 2020 18:35:43 GMT):
When you create a pool you have to provide it with the pool transactions so it knows how to connect to the Indy ledger. If you are getting a PoolLedgerTimeout then you likely have the wrong transactions

ianco (Tue, 26 May 2020 18:36:01 GMT):
You can run a local indy ledger like this: https://github.com/hyperledger/indy-sdk#1-starting-the-test-pool-on-localhost

ianco (Tue, 26 May 2020 18:36:29 GMT):
(This is just one option, or you can connect to a ledger running somewhere else, the trick is to get the right set of genesis transactions)

ianco (Tue, 26 May 2020 18:37:08 GMT):
In your code, `genesisFilePath` should point to a file containing the pool transactions

MartenMeijboom (Tue, 26 May 2020 18:38:59 GMT):
Okay, thanks. I'll try to get that running?

ianco (Tue, 26 May 2020 18:39:05 GMT):
Pool transactions for connecting to sovrin ledgers are in github here: https://github.com/sovrin-foundation/sovrin/tree/master/sovrin

ianco (Tue, 26 May 2020 18:39:30 GMT):
The file `pool_transactions_local_genesis` is what you want for a local Indy ledger

ianco (Tue, 26 May 2020 18:39:50 GMT):
If you look at the contents of the file, you can see that it contains the IP and port #'s of the nodes runnign the ledger

MartenMeijboom (Tue, 26 May 2020 18:40:14 GMT):
So new nodes joining later on should be added to this?

ianco (Tue, 26 May 2020 18:40:32 GMT):
So: - run the local Indy ledger - copy the `pool_transactions_local_genesis` to your local - update your program's `genesisFilePath` to point to the location of this file

ianco (Tue, 26 May 2020 18:41:15 GMT):
There's a process for adding new nodes to a running ledger, I'm not sure offhand, you can ask that question in the #indy-node channel

MartenMeijboom (Tue, 26 May 2020 18:41:43 GMT):
I'll give this a shot. Thanks a lot!

ianco (Tue, 26 May 2020 18:43:01 GMT):
:+1:

ianco (Tue, 26 May 2020 18:45:51 GMT):
It's worth looking at these tutorials if you haven't already: https://github.com/hyperledger/indy-sdk/tree/master/docs/how-tos

ianco (Tue, 26 May 2020 18:45:51 GMT):
It's worth looking at these tutorials if you haven't already: https://github.com/hyperledger/indy-sdk/tree/master/docs/how-tos @MartenMeijboom

brentzundel (Thu, 28 May 2020 13:41:17 GMT):
Has joined the channel.

Diiaablo95 (Mon, 01 Jun 2020 11:10:10 GMT):
Hey people! Is it possible in a credential to have multiple claims with the same name? How can I use the credentials to include a set of "certified" DIDs and disclose only one of them when needed? On the verifier side, the proof request would ask for a claim with name `did` from a credential issued by entity X. Instead of issuing a credential to each DID, I was wondering if it would be possible to issue a credential to a set of DID, and use selective disclosure to each time prove the claim about a DID.

sklump (Mon, 01 Jun 2020 18:37:52 GMT):
A credential includes claims on attributes defined in a schema. No two attributes in a schema can have the same name. Using `did` as an attribute name is going to be a misery factory for everyone who touches your software and their loved ones. Credentials are not certificates, nor are they attribute certificates. You will notice in the documentation, if you look carefully, how reluctant authors are to use "certify" and related terms because that has a connotation associated with another whole set of plans (X.509 via ITU-T, etc). Holders do not need to present credentials, only proofs of possession of claims that they contain. The analogue to certification of a DID is to write it to the ledger, registering it against a NYM (which makes it a public DID). Control of private keys associated with a public DID underpins an identity. An issuer could issue claims to several holders of public DIDs; if one actor controls their public keys then that actor could use the NYM of his choice in interactions. HOWEVER the actor need not use public DID; typically the holder uses pairwise DIDs where the holder side is not a public DID at all (thus preventing collusion by third-parties to make inferences other that what the holder prove with any one of them).

sklump (Mon, 01 Jun 2020 18:37:52 GMT):
A credential includes claims on attributes defined in a schema. No two attributes in a schema can have the same name. Using `did` as an attribute name is going to be a misery factory for everyone who touches your software and their loved ones. Credentials are not certificates, nor are they attribute certificates. You will notice in the documentation, if you look carefully, how reluctant authors are to use "certify" and related terms because that has a connotation associated with another whole set of plans (X.509 via ITU-T, etc). Holders do not need to present credentials, only proofs of possession of claims that they contain. The analogue to certification of a DID is to write it to the ledger, registering it against a cryptonym ("NYM") (which makes it a public DID). Control of private keys associated with a public DID underpins a cryptonym. An issuer could issue claims to several holders of public DIDs; if one actor controls their public keys then that actor could use the NYM of his choice in interactions. HOWEVER the actor need not use public DID; typically the holder uses pairwise DIDs where the holder side is not a public DID at all (thus preventing collusion by third-parties to make inferences other that what the holder prove with any one of them).

StevenTCramer (Tue, 02 Jun 2020 14:58:08 GMT):
Has joined the channel.

mccown (Wed, 03 Jun 2020 19:35:09 GMT):
Just a reminder about the Identity Implementer's WG Call tomorrow morning (June 4th @ 9am MT). This is a chance to get updates on the WG calls you may have missed this week. Our guest presenter will be Matt Norton from Streetcred. Matt will be presenting on some of their new health-related credential work. Here are links to the Wiki and the Zoom meeting. Wiki: https://wiki.hyperledger.org/display/IWG/2020-06-04+Identity+WG+Implementers+Call Zoom: https://zoom.us/j/244779296

rtorres (Thu, 04 Jun 2020 23:21:53 GMT):
Has joined the channel.

rtorres (Thu, 04 Jun 2020 23:21:53 GMT):
Hello all! Is it possible to extend the transactions supported by Indy-SDK in a -more or less- simple way? If not, is there a way to send a transaction with "custom" data (i.e {"hello": "world"}) Sorry if this is an old/repeated or misplaced question and thanks in advance :)

swcurran (Thu, 04 Jun 2020 23:27:17 GMT):
There is not a way to send custom data as a new transaction. Attributes can be added to a Nym (a DID) that can be arbitrary. That is as close as it comes. Of course, new transactions could be added to the Indy code base, but there would need to be a very good use case and agreement in the community. The more likely direction is to tighten up on the sending of attributes.

rtorres (Thu, 04 Jun 2020 23:30:12 GMT):
That's interesting. So, suppose I have an Anchor with its associated DID (NYM). The closest way to somehow "register" an event that the Anchor "generates" would be by associating an attribute to that NYM? Am I right?

rtorres (Thu, 04 Jun 2020 23:30:12 GMT):
Not exactly. I'm working in some kind of decentralized credentials and I'm now playing with ledger support

swcurran (Thu, 04 Jun 2020 23:31:06 GMT):
That's true today. What is the use case? Proof of time?

rtorres (Thu, 04 Jun 2020 23:32:25 GMT):
Not exactly. I'm working in some kind of decentralized credentials and I'm now playing with ledger support

rtorres (Thu, 04 Jun 2020 23:32:25 GMT):
That's interesting. So, suppose I have an Anchor with its associated DID (NYM). The closest way to somehow "register" an event that that Anchor "generates" would be by associating an attribute to that NYM? Am I right? Not exactly. I'm working in some kind of decentralized credentials and I'm now playing with ledger support

swcurran (Thu, 04 Jun 2020 23:33:23 GMT):
OK. You definitely don't want to put credential data/PII on the ledger.

rtorres (Thu, 04 Jun 2020 23:34:33 GMT):
No. I just need/want to record some more "event" that occurs on the anchor.

rtorres (Thu, 04 Jun 2020 23:36:26 GMT):
In fact, I tried Fabric too... however Indy's approach may be more interesting. :)

spacemandev (Fri, 05 Jun 2020 17:35:22 GMT):
I was discussing this in aries channel, but I think this might be an indy topic. When building a presentation for a VC, in the VC standard there is a very useful field (issuance date) that is not encoded as part of the information of the VC. i am curious as to what would be the best way to modify the presentation protocol to add that piece from the VC?

spacemandev (Fri, 05 Jun 2020 17:39:48 GMT):
specifically here: https://github.com/hyperledger/indy-sdk/blob/57dcdae74164d1c7aa06f2cccecaae121cefac25/libindy/src/api/anoncreds.rs#L1508 instead of just schema_id, cred_def_id, rev_reg_id, and timestamp, there should be a fifth value, "issuance date"

tomislav (Fri, 05 Jun 2020 18:41:54 GMT):
Where would this value come from?

spacemandev (Fri, 05 Jun 2020 20:06:46 GMT):
in teh w3c spec for verifiable credentials, it makes issuance date a part of the credential, see here: https://www.w3.org/TR/vc-data-model/#concrete-lifecycle-example*

ap (Sun, 07 Jun 2020 08:37:26 GMT):
I am building the react-native arise SDK and facing one issue.The issue is, In java whenever we perform any wallet related transaction it's taking too much time to execute that transaction while in iOS it's very less time to execute the same transaction. Is anyone facing same issue? Or may I am doing something wrong while integrating indy SDK in android

dfgh (Sun, 07 Jun 2020 18:26:57 GMT):
Has joined the channel.

dfgh (Sun, 07 Jun 2020 18:26:57 GMT):
Hi all, I hope this is the right place to ask this question: We're doing a project right now using the NodeJS wrapper. We've got a backend that we want to connect to the indy-pool, using this dockerfile (https://github.com/hyperledger/indy-sdk/blob/master/ci/indy-pool.dockerfile). Now everything is working fine when the NodeJS backend is running locally, however when I run the backend in another Docker container I get the "CommonInvalidStructure" error on the "indy.openPoolLedger(poolName);" line. The code is practically the same as line 27 in the NodeJS sample "gettingStarted.js"(https://github.com/hyperledger/indy-sdk/blob/master/samples/nodejs/src/gettingStarted.js)

dfgh (Sun, 07 Jun 2020 18:27:38 GMT):

Clipboard - June 7, 2020 8:27 PM

andrew.whitehead (Sun, 07 Jun 2020 18:47:57 GMT):
I would try printing out the genesis file to make sure it's readable

dfgh (Sun, 07 Jun 2020 19:15:31 GMT):

Clipboard - June 7, 2020 9:14 PM

dfgh (Sun, 07 Jun 2020 19:15:52 GMT):
It says '"client_ip": "indy_pool",'. That is supposed to be the ip of the docker container, right?

dfgh (Sun, 07 Jun 2020 19:16:58 GMT):
I am passing "let poolIp = process.env.TEST_POOL_IP;" to util.js and also passing this in the docker-compose.yml

dfgh (Sun, 07 Jun 2020 19:27:14 GMT):
Ok thank you very much! That did help me a lot. There is actually something wrong with the IP I'm passing in my docker-compose. Because if I run it on my local machine and hardcode my local IP it works. Thanks again!

andrew.whitehead (Sun, 07 Jun 2020 19:30:03 GMT):
Docker networking can be a bit complicated, and it can't normally resolve your local IP from inside the container. I would expect a pool timeout and not an invalid structure error in that case though

dfgh (Sun, 07 Jun 2020 19:31:13 GMT):
Well the thing is, if I change: environment: TEST_POOL_IP: indy_pool into my local ip: environment: TEST_POOL_IP: "192.168.1.3" It suddenly works and I don't get the error anymore

andrew.whitehead (Sun, 07 Jun 2020 19:32:43 GMT):
Well, I guess that's good enough :)

andrew.whitehead (Sun, 07 Jun 2020 19:33:09 GMT):
Yes looks like that was an invalid IP, I thought it just had the wrong IP

dfgh (Sun, 07 Jun 2020 19:33:45 GMT):
This works for now, when I'm finished I'll try figuring out how to do it all in 1 docker compose file

dfgh (Sun, 07 Jun 2020 19:33:48 GMT):
Thanks :)

Diiaablo95 (Mon, 08 Jun 2020 06:02:42 GMT):
Hi. Thanks for your answer. The point here is that, as also pointed out in a couple of GitHub issues (eg. https://github.com/decentralized-identity/didcomm-messaging/issues/41), DIDComm has, at the moment, a trust issue where even if you can prove ownership of a DID, you need to prove that *THAT* DID can provide proofs that you need, otherwise you would have a potential MitM able to relay proof requests and proof. That is why, as a temporary solution, I was thinking to use "certification" credentials containing a set of certified DIDs. They would still be pairwise DIDs, not written on the ledger, but which allow the owner to prove its authorisation to whatever verifier it is interacting with. Hence my question about having multiple claims in the same credential definition (and therefore in the same credential schema). The schema declares only one claim, i.e. DID, but the definition instantiates multiple occurrences of that claim within the same credential.

Diiaablo95 (Mon, 08 Jun 2020 06:22:29 GMT):
Ok so apparently is not possible to do it anyway, since indy takes only the last value of the claim, loosing information about all the previous ones upon credential issuance. Problem solved :)

chaeso (Wed, 10 Jun 2020 09:53:49 GMT):
Has joined the channel.

chaeso (Wed, 10 Jun 2020 09:53:49 GMT):
Hi all. I'm trying to use indy library (libindy.so) in Android which I built using the script located in "indy-sdk/vcx/libvcx/build_scripts/android/indy/build.sh". In android, however, error occurs as follows. Is there anybody got this error? => java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "_ZNSt6__ndk15ctypeIcE2idE" referenced by "/data/app/com.hello.ledger-dfg1EC70n_WTHq3qMrT2rA==/lib/x86/libindy.so"...

sheru (Thu, 11 Jun 2020 13:43:30 GMT):
Good Morning, Hope everyone doing well. I am trying to play around with aries-mobileagent-xamarin I have setup the mediator and successfully make a connection with cloud agent by scan the qr code. the cloud agent offer a credential to the mobile agent. When I am trying to request for accept the credential from the mobile agent I am getting the following error... ```**Hyperledger.Indy.PoolApi.PoolConfigNotCreatedException:** 'The requested pool cannot be opened because it does not have an existing configuration.'``` Can anyone please help me what I am missing , Thank you...

profae (Fri, 12 Jun 2020 19:14:47 GMT):
Hi everyone I have a problem with libvcx on Android. I correctly build the AAR wrapper using libvcx.so downloaded from https://repo.sovrin.org/android/libvcx/stable/ When I run the app I get the error on loading the library dlopen failed: unable to find the "__subtf3" symbol referenced by "... = / lib / arm64 / libvcx.so" What am I doing wrong? thanks

andrew.whitehead (Fri, 12 Jun 2020 19:20:40 GMT):
Maybe related to this: https://github.com/rust-lang/rust/issues/46651

andrew.whitehead (Fri, 12 Jun 2020 19:21:48 GMT):
Or you need to install libgcc

profae (Fri, 12 Jun 2020 20:00:49 GMT):
thanks, yes i had read it already, but having used the library downloaded from repo I thought there is some mistake of mine has anyone else had this problem?

mccown (Wed, 17 Jun 2020 18:40:14 GMT):
Just a reminder about the Identity Implementer's WG Call tomorrow morning (June 18th @ 9am MT). This is a chance to get updates on the WG calls you may have missed this week. Our guest presenter will be Oliver Terbu from uPort & ConsenSys. Oliver will be presenting on the Self-Issued OpenID Connect technologies. Here are links to the Wiki and the Zoom meeting. Wiki: https://wiki.hyperledger.org/display/IWG/2020-06-18+Identity+WG+Implementers+Call Zoom: https://zoom.us/j/244779296

lynn.bendixsen (Fri, 19 Jun 2020 22:51:45 GMT):
Does anyone know if libsodium version<1.0.15 is still required to build and install the indy-cli on MacOS? It seems to work with the latest version of libsodium (18?) when I watched someone do it earlier this week... Here is the reference to the requirement: https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/build-guides/mac-build.html

tomislav (Sun, 21 Jun 2020 14:31:50 GMT):
No, you can run latest libsodium. The build script for local build also got updated recently to include correct OpenSSL location. This has caused some issues before, but it should work fine now - https://github.com/hyperledger/indy-sdk/blob/0eeb2ae76733950c2eebadd188e0fc41dac234b6/libindy/mac.build.sh#L44

lynn.bendixsen (Mon, 22 Jun 2020 14:25:05 GMT):
Thanks Tomislav! thats excellent information.

RicardoPeixoto (Thu, 25 Jun 2020 10:03:36 GMT):
Has joined the channel.

RicardoPeixoto (Thu, 25 Jun 2020 10:03:36 GMT):
Hi all, is it possible to remove a credential stored in the wallet anoncreds?

tomislav (Thu, 25 Jun 2020 13:24:11 GMT):
Yes, there's an indy api to delete a credential in the anoncreds service

RicardoPeixoto (Thu, 25 Jun 2020 13:37:56 GMT):
@tomislav do you know how is it called? I can't find it in node package wrapper.

sklump (Thu, 25 Jun 2020 13:46:17 GMT):
in python wrapper, it is `anoncreds.prover_delete_credential()`. It appears to be absent in nodejs to date?

ianco (Thu, 25 Jun 2020 16:45:44 GMT):
Hi folks, just wondering what are the options for a mediator for a mobile agent? I know MAX includes a mediator based on the .NET framework (https://github.com/hyperledger/aries-mobileagent-xamarin), what other mediators are available as open soruce?

thomas_kim (Fri, 26 Jun 2020 09:57:14 GMT):
Here is the PR that implements search related APIs. https://github.com/hyperledger/indy-sdk/pull/2209

aaronr (Fri, 26 Jun 2020 14:16:50 GMT):
Hi, I'm trying to use the openWalletSearch function in the nodejs wrapper to find a record that has a specific property set to false. It never finds it. However if I change the record's value to true and search for that it does find it. Similar when searching for a property with a numeric value...I can't successfully search for a value of 0, but I can for 1, 2, etc. Am I missing something? I don't see anything in the documentation that leads me to believe that this shouldn't work.

aaronr (Fri, 26 Jun 2020 14:16:50 GMT):
Hi, I'm trying to use the openWalletSearch function in the nodejs wrapper to find a record that has a specific property set to false (query is `{ 'manual_accept': 'false' }`). It never finds it. However if I change the record's value to true and search for that it does find it. Similar when searching for a property with a numeric value...I can't successfully search for a value of 0, but I can for 1, 2, etc. Am I missing something? I don't see anything in the documentation that leads me to believe that this shouldn't work.

aaronr (Fri, 26 Jun 2020 14:16:50 GMT):
Hi, I'm trying to use the openWalletSearch function in the nodejs wrapper to find a record that has a specific property set to false (query is `{ 'manual_accept': 'false' }`). It never finds it. However if I change the record's value to true and search for that (query is `{ 'manual_accept': 'true' }`) it does find it. Similar when searching for a property with a numeric value...I can't successfully search for a value of 0, but I can for 1, 2, etc. Am I missing something? I don't see anything in the documentation that leads me to believe that this shouldn't work.

andrew.whitehead (Fri, 26 Jun 2020 15:25:42 GMT):
It should be treating all record tags as strings but maybe some conversion is happening in the wrapper

aaronr (Fri, 26 Jun 2020 20:54:44 GMT):
@andrew.whitehead: bless you, you said just the right words. Looks like there is a difference in the tags that are getting passed when I'm adding the record.

rantoinne (Sun, 28 Jun 2020 18:42:21 GMT):
@RileyHughes @mboyd @drew-streetcred @amitpadmani Hi all, I am Ravi from Ayanworks, I am facing an issue with Indy-objc ( https://repo.sovrin.org/ios/libindy/stable/indy-objc/ ). I am trying to deploy an iOS app on App Store after archiving but when I do so I am facing following error: `SDK version issue. This app was built with iOS sdk 12.1` I am using following configurations: 1. Xcode - 10.1 2. Indy-objc - 1.8.2 I am using a downgraded version of Xcode as the Indy dependency requires a swift compiler of lower version i.e, 4.2 to. build the project with the library(Indy-objc). Any version of xcode above that throws an error and doesn't allow me to build the project. Can any one here in the group help me with the deployment or can suggest me a procedure which I should take to find a solution to this issue. Thanks in advance.

RileyHughes (Sun, 28 Jun 2020 18:42:21 GMT):
Has joined the channel.

amitpadmani (Sun, 28 Jun 2020 18:42:21 GMT):
Has joined the channel.

swcurran (Sun, 28 Jun 2020 19:58:04 GMT):
@mccown ^^^

Diiaablo95 (Mon, 29 Jun 2020 06:20:21 GMT):
Hello! I see there is no built-in functionality to support retrieving the verkeys of a DID in the past, let's say at time T. It might be useful if we want to audit presentation exchange afterwards, so that the validation of a presentation can be done retroactively. I mean, if party C1, customer of A, interacts with party C2, customer of B, by showing a proof that it is authorised to perform an operation, C2 (probably its service provider B), will want to prove to A that C1 has used the service. In that case, B must be able to prove to A that, at time T, the presentation that C1 presented was valid, because it was signed by one of the keys that A owned at the time, even if it has been replaced afterwards. Is there a way to achieve this in Indy?

Diiaablo95 (Mon, 29 Jun 2020 06:20:21 GMT):
Hello! I see there is no built-in functionality to support retrieving the verkeys of a DID in the past, let's say at time T. It might be useful if we want to audit presentation exchange afterwards, so that the validation of a presentation can be done retroactively. I mean, if party C1, customer of A, interacts with party C2, customer of B, by showing a proof that it is authorised to perform an operation, C2 ( probably its service provider B ), will want to prove to A that C1 has used the service. In that case, B must be able to prove to A that, at time T, the presentation that C1 presented was valid, because it was signed by one of the keys that A owned at the time, even if it has been replaced afterwards. Is there a way to achieve this in Indy?

Diiaablo95 (Mon, 29 Jun 2020 06:24:14 GMT):
Nevertheless, I see there's a `indy_build_get_txn_request` method, which might perhaps be used to show that the transaction TX happened at time T, after the presentation was... presented. The TX rotated the verkey of the DID from the one used to sign the credential, to something else.

swcurran (Mon, 29 Jun 2020 13:32:27 GMT):
This is technically possible, but I don't know the steps and whether it has been made easy. Since the verkeys are on the ledger, they can be found and retrieved. However, Indy ledger does not support searching for transactions. I'm not sure if it does support this specific type of searching - given a DID, find previous updates to it.

mccown (Mon, 29 Jun 2020 16:24:30 GMT):
@swcurran thanks for tagging me. @rantoinne, your observation is correct. In xcode, developers are required to match the language / compiler versions with the libraries they link. This is why you're seeing this error with the newer xcode, but downgrading xcode worked. At the moment, there are 2 options: 1) you can keep using the older xcode, or 2) you can recompile the indy-sdk using the newer compiler. I have not used the updated compiler to recompile the indy-sdk, so there may be some additional changes that need to be made. Here's an article from Apple that explains in more detail about their new "library evolution" and "module stability" features, which are intended to allow developers to mix compiler versions between libraries and apps. I think this is something that we should look at implementing for the indy-sdk. https://swift.org/blog/library-evolution/

sairanjit (Wed, 01 Jul 2020 09:10:19 GMT):
Has joined the channel.

kulkarnikk (Wed, 01 Jul 2020 11:38:48 GMT):
Has joined the channel.

mccown (Wed, 01 Jul 2020 18:47:47 GMT):
Just a reminder about the Identity Implementer's WG Call tomorrow morning (July 2nd @ 9am MT). This is a chance to get updates on the WG calls you may have missed this week. Our guest presenter will be Oliver Terbu from uPort & ConsenSys. Oliver will be presenting on the Self-Issued OpenID Connect Provider (SIOP) DID Profile. Here are links to the Wiki and the Zoom meeting. Wiki: https://wiki.hyperledger.org/display/IWG/2020-07-02+Identity+WG+Implementers+Call Zoom: https://zoom.us/j/244779296

AnneGoellnitz (Thu, 02 Jul 2020 08:33:19 GMT):
Has joined the channel.

sklump (Tue, 07 Jul 2020 12:27:37 GMT):
Is there a way to get the indy client directory via the python wrapper on the current OS? ($HOME/.indy_client, $HOME/Documents/.indy_client, $EXTERNAL_STORAGE/.indy_client, maybe others) ?

sklump (Tue, 07 Jul 2020 12:27:37 GMT):
Is there a way to get the indy client directory via the python wrapper on the current OS (`$HOME/.indy_client`, `$HOME/Documents/.indy_client`, `$EXTERNAL_STORAGE/.indy_client`, maybe others) ?

Alexi (Tue, 07 Jul 2020 14:20:29 GMT):
Hello, I was wondering when you call delete_record does this automatically delete the tags as well or do they have to independently be deleted?

bizsecure (Wed, 08 Jul 2020 00:41:48 GMT):
Has joined the channel.

tomislav (Wed, 08 Jul 2020 02:05:55 GMT):
Curious to know the answer to this as well.

andrew.whitehead (Wed, 08 Jul 2020 02:33:22 GMT):
Yes the tags tables are set up with a cascading delete relationship

tomislav (Wed, 08 Jul 2020 02:37:51 GMT):
nice!

tomislav (Wed, 08 Jul 2020 02:38:18 GMT):
Does this also apply to custom storage providers?

andrew.whitehead (Wed, 08 Jul 2020 02:38:38 GMT):
Depends on the provider, but it applies to the postgres backend

andrew.whitehead (Wed, 08 Jul 2020 02:38:38 GMT):
Depends on the provider, but it applies to the postgres backend. It should be implemented by any provider by convention

tomislav (Wed, 08 Jul 2020 02:40:10 GMT):
Interesting. So indy runtime won't actually call delete tags before calling delete value, but it relies on the storage provider to handle it.

andrew.whitehead (Wed, 08 Jul 2020 02:41:12 GMT):
Yes, as far as I know

lynn.bendixsen (Wed, 08 Jul 2020 16:23:17 GMT):
I am having trouble building latest SDK on my MAC. Has anyone seen the following and can help? I think its a rust issue, but I don't know how to fix it. I have rust version 38. ```Compiling indy-utils v0.1.0 (/Users/ken/Projects/indy-sdk/libindy/indy-utils) error[E0008]: cannot bind by-move into a pattern guard --> indy-utils/src/wql.rs:76:24 | 76 | Query::And(suboperators) if suboperators.len() == 0 => { | ^^^^^^^^^^^^ moves value into pattern guard error[E0008]: cannot bind by-move into a pattern guard --> indy-utils/src/wql.rs:79:24 | 79 | Query::And(mut suboperators) if suboperators.len() == 1 => { | ^^^^^^^^^^^^^^^^ moves value into pattern guard ```

andrew.whitehead (Wed, 08 Jul 2020 16:33:27 GMT):
Looks like that was stabilized in 1.39

lynn.bendixsen (Wed, 08 Jul 2020 17:56:56 GMT):
Thanks Andrew, upgrading Rust fixed the issue.

lynn.bendixsen (Wed, 08 Jul 2020 17:56:56 GMT):
Thanks Andrew, upgrading Rust fixed the issue. (I used 1.42.0)

bizsecure (Wed, 08 Jul 2020 23:43:37 GMT):
Good afternoon, I was wondering what happened to the native IOS wrappers? Are they being maintained somewhere? https://jenkins.hyperledger.org/ is not available anymore and the last build on https://repo.sovrin.org/ios/libindy/master/indy-objc/ is two years old. Testflight won't let up upload our app because the iOS wrappers are compiled for an unsupported iOS version. Apple now requires everything to compiled for iOS 12.1 or greater. I am trying to compile the Indy SDK in Xcode 13, however most scripts have issues and I require many external libraries / sources. Its a rather large development environment to setup. Thank you for your assistance.

bizsecure (Wed, 08 Jul 2020 23:43:37 GMT):
Good afternoon, I was wondering what happened to the native IOS wrappers? Are they being maintained somewhere? https://jenkins.hyperledger.org/ is not available anymore and the last build on https://repo.sovrin.org/ios/libindy/master/indy-objc/ is two years old. Testflight won't let us upload our app because the iOS wrappers are compiled for an unsupported iOS version. Apple now requires everything to compiled for iOS 12.1 or greater. I am trying to compile the Indy SDK in Xcode 13, however most scripts have issues and require many external libraries / sources. We are working to find or build all the other components, but do not want to breaking anything in the process as its a rather large development environment to setup. Thank you for your assistance. -ara

tangelo1 (Fri, 10 Jul 2020 00:01:24 GMT):
Has joined the channel.

discoverer (Fri, 10 Jul 2020 00:43:20 GMT):
Has joined the channel.

ap (Fri, 10 Jul 2020 06:35:08 GMT):

Screenshot from 2020-07-10 12-04-39.png

RicardoPeixoto (Fri, 10 Jul 2020 10:44:20 GMT):
Hi, I have a doubt about the function "proverFetchCredentialsForProofReq" in JS sdk. This function expects a 'itemReferent' (referent of attribute/predicate in the proof request). Does this imply that we cannot use the same referent name for a attribute referent and a predicate referent?

SuperSeiyan (Mon, 13 Jul 2020 03:29:43 GMT):
Hello, I would like to reduce the size of the libindy base image. Would it be possible to build as an alpine image? It would be great if any documentation or example can be share. Thank you.

ap (Mon, 13 Jul 2020 08:56:30 GMT):
Yes @RicardoPeixoto, It's must be unique for the attribute referent and a predicate referent

RicardoPeixoto (Mon, 13 Jul 2020 09:48:53 GMT):
@ap Thank you :)

swcurran (Mon, 13 Jul 2020 13:45:31 GMT):
Have you looked at this images? https://hub.docker.com/r/bcgovimages/von-image BC Gov maintains them with each release.

swcurran (Mon, 13 Jul 2020 13:45:50 GMT):
A chunk of work went into optimizing the images.

berserkr (Tue, 14 Jul 2020 01:44:12 GMT):
Has joined the channel.

berserkr (Tue, 14 Jul 2020 01:44:12 GMT):
Hi team, I have a pool running local with 4 nodes, and have one client, all using the 10.0.0.* network.. When I try running the sdk examples `write_did_and_query_verkey.py` I get segfaults with no debug info... has anyone encountered such issue?

seriousmountain (Wed, 15 Jul 2020 13:19:04 GMT):
Has joined the channel.

Madhava 16 (Fri, 17 Jul 2020 04:31:26 GMT):
Has joined the channel.

Madhava 16 (Fri, 17 Jul 2020 04:31:26 GMT):
Hi All, just trying to understand how I can best integrate secure DIDComm messaging into our rust code base. I see https://github.com/hyperledger/aries-cloudagent-python uses indy's python wrapper. Does that mean that if we just use indy-sdk directly we can achieve the same thing without the python layer?

swcurran (Fri, 17 Jul 2020 14:05:21 GMT):
@andrew.whitehead @TelegramSam -- how would you guys answer this question?

andrew.whitehead (Fri, 17 Jul 2020 16:30:35 GMT):
@Madhava 16 You can use the SDK directly (or the indy crate which wraps the FFI interface), which gives you a wallet for holding the keys and makes the pack and unpack process used in didcomm more automatic. I've also been working on an indy-utils crate (https://crates.io/crates/indy-utils) which contains various Indy utilities including pack and unpack, but at a lower level and without the automatic key handling. Still working on a storage component which would provide that capability

berserkr (Tue, 21 Jul 2020 00:11:48 GMT):
Team, when we create credential values, what is the encoding done in? For example: ```prover['cred_values'] = json.dumps({ "sex": {"raw": "male", "encoded": "5944657099558967239210949258394887428692050081607692519917050011144233"}, "name": {"raw": "Alex", "encoded": "1139481716457488690172217916278103335"}, "height": {"raw": "175", "encoded": "175"}, "age": {"raw": "28", "encoded": "28"} })```

berserkr (Tue, 21 Jul 2020 00:45:31 GMT):
I do see the following `# note that encoding is not standardized by Indy except that 32-bit integers are encoded as themselves. IS-786` in https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/getting-started/indy-walkthrough.html#a-developer-guide-for-building-indy-clients-using-libindy ... This means that there is no check within libindy that checks if the encoding is right or wrong?

swcurran (Tue, 21 Jul 2020 17:33:20 GMT):
In aries, the issue credential protocol defines the encoding used for Indy credentials: https://github.com/hyperledger/aries-rfcs/tree/master/features/0036-issue-credential#encoding-claims-for-indy-based-verifiable-credentials

FarhanShafiq (Wed, 22 Jul 2020 08:32:09 GMT):
Has left the channel.

kangme (Thu, 23 Jul 2020 06:03:25 GMT):
Has joined the channel.

JakeZ2020 (Wed, 29 Jul 2020 19:10:38 GMT):
Has joined the channel.

tomislav (Thu, 30 Jul 2020 12:54:10 GMT):
Is indy-sdk single threaded access per wallet or for the entire process?

tomislav (Thu, 30 Jul 2020 12:54:10 GMT):
Is indy-sdk single threaded wallet access per wallet or for the entire process?

swcurran (Thu, 30 Jul 2020 20:49:42 GMT):
I believe it's single-threaded for the process, but @andrew.whitehead would know better. It's why we've been so keen on getting indy-sdk broken up and replaced.

andrew.whitehead (Thu, 30 Jul 2020 22:50:09 GMT):
I believe it runs on the same worker thread for all wallets but I haven’t looked at it in a while

thomas_kim (Fri, 31 Jul 2020 05:18:57 GMT):
You would like to take a look this issue https://github.com/hyperledger/indy-sdk/issues/2164

thomas_kim (Fri, 31 Jul 2020 05:18:57 GMT):
You would like to take a look at this issue https://github.com/hyperledger/indy-sdk/issues/2164

SuperSeiyan (Fri, 31 Jul 2020 18:46:37 GMT):
Hi, Did someone try to implement the libvcx android using react native? I would like to know how many libs (`.so`) required on `main/jniLibs` and what are they?

SuperSeiyan (Fri, 31 Jul 2020 19:17:02 GMT):
Hi, Did someone try to implement Libvcx on android using react-native? I have got an error `Attempt to invoke interface method'int com.evernym.sdk.LibVcx$API.vcx_agent_provision_async(int, java.lang.String, com.sun.jna.Callback)' on a null object reference` on my simulator. on adb it shows `08-03 23:18:37.252 9271 9336 W System.err: java.lang.UnsatisfiedLinkError: Native library (com/sun/jna/android-x86/libjnidispatch.so) not found in resource path (.)` Please help

SuperSeiyan (Sun, 02 Aug 2020 15:51:33 GMT):
Hello All, I would like to develop react-native using Libvcx but, I stuck by `permission denied` thrown from an android emulator After, I grant permission to the application the problem does not solve yet Here is more log from adb ``` 08-02 22:30:27.923 11167 11247 W System.err: [Thread-4] WARN com.evernym.sdk.vcx.LibVcx.native.vcx.utils.libindy.wallet - src/utils/libindy/wallet.rs:79 | could not create wallet alice_wallet: "Error: IO error\n Caused by: Permission denied (os error 13)\n" 08-02 22:30:27.924 11167 11247 W System.err: [Thread-4] ERROR com.evernym.sdk.vcx.LibVcx.native.vcx.api.utils - src/api/utils.rs:85 | vcx_agent_provision_async_cb(command_handle: 1, rc: Error: Error Creating a wallet 08-02 22:30:27.924 11167 11247 W System.err: Caused by: could not create wallet alice_wallet: "Error: IO error\n Caused by: Permission denied (os error 13)\n" 08-02 22:30:27.924 11167 11247 W System.err: , config: NULL 08-02 22:30:27.929 11167 11247 E RNIndy::: createOneTimeInfo: 08-02 22:30:27.929 11167 11247 E RNIndy::: com.evernym.sdk.vcx.wallet.WalletCreationException: Error Creating a wallet 08-02 22:30:27.929 11167 11247 E RNIndy::: at com.evernym.sdk.vcx.VcxJava$API.checkCallback(VcxJava.java:105) 08-02 22:30:27.929 11167 11247 E RNIndy::: at com.evernym.sdk.vcx.utils.UtilsApi.access$200(UtilsApi.java:19) 08-02 22:30:27.929 11167 11247 E RNIndy::: at com.evernym.sdk.vcx.utils.UtilsApi$1.callback(UtilsApi.java:26) 08-02 22:30:27.929 11167 11247 E RNIndy::: at java.lang.reflect.Method.invoke(Native Method) 08-02 22:30:27.929 11167 11247 E RNIndy::: at com.sun.jna.CallbackReference$DefaultCallbackProxy.invokeCallback(CallbackReference.java:520) 08-02 22:30:27.929 11167 11247 E RNIndy::: at com.sun.jna.CallbackReference$DefaultCallbackProxy.callback(CallbackReference.java:551) 08-02 22:30:27.930 11167 11247 D RNIndy::: vcx::APP::async result Prov: null 08-02 22:30:27.934 11167 11218 D ReactNativeJS: [Error: Error Creating a wallet] 08-02 22:30:27.944 11167 11218 E ReactNativeJS: Error: Error Creating a wallet ``` Thank you

thomas_kim (Mon, 03 Aug 2020 01:00:38 GMT):
For Android, you need to set the EXTERNAL_STORAGE env variable https://github.com/hyperledger/indy-sdk/blob/master/docs/build-guides/android-build.md#usage

thomas_kim (Mon, 03 Aug 2020 01:03:28 GMT):
Something like this https://github.com/sktston/vcx-demo-android/blob/3c50b3cc4db54323eded4c7b655e94ceb4d0b8a5/app/src/main/java/com/sktelecom/ston/demo/MainActivity.java#L50

SuperSeiyan (Mon, 03 Aug 2020 03:11:01 GMT):
@thomas_kim Thank you for your suggestion it is very helpful and I found more information about crossplatform to fix issue on android Q https://github.com/miguelpruivo/flutter_file_picker/issues/169#issuecomment-549129122

SuperSeiyan (Mon, 03 Aug 2020 03:11:01 GMT):
@thomas_kim Thank you for your suggestion it is very helpful and I found more information about cross-platform to fix issue on android Q https://github.com/miguelpruivo/flutter_file_picker/issues/169#issuecomment-549129122

SuperSeiyan (Tue, 04 Aug 2020 17:28:58 GMT):
Hello All, I tried to build Libvcx for IOS using `xcodebuild` and got the error like ``` Undefined symbols for architecture arm64: "_rbt_backtracesyminfo", referenced from: backtrace::symbolize::libbacktrace::resolve::h85568b2991d20d5f in libvcx.a(backtrace-765dffd11cca7464.backtrace.e4pyy854-cgu.3.rcgu.o) "rbt_backtrace_create_state", referenced from: backtrace::symbolize::libbacktrace::syminfo_cb::hc35450c66131a767 in libvcx.a(backtrace-765dffd11cca7464.backtrace.e4pyy854-cgu.3.rcgu.o) backtrace::symbolize::libbacktrace::resolve::h85568b2991d20d5f in libvcx.a(backtrace-765dffd11cca7464.backtrace.e4pyy854-cgu.3.rcgu.o) "___rbt_backtrace_pcinfo", referenced from: backtrace::symbolize::libbacktrace::syminfo_cb::hc35450c66131a767 in libvcx.a(backtrace-765dffd11cca7464.backtrace.e4pyy854-cgu.3.rcgu.o) ld: symbol(s) not found for architecture arm64 clang: error: linker command failed with exit code 1 (use -v to see invocation) ``` The error occurs when trying to build on master at the latest commit but, work fine at tag v1.15.0 on repo `indy-sdk` Thank you in advance.

athulramesh (Wed, 05 Aug 2020 07:20:27 GMT):
Has joined the channel.

thomas_kim (Mon, 10 Aug 2020 01:55:56 GMT):
I have realized the same issue few days ago with the same script you used...

SuperSeiyan (Mon, 10 Aug 2020 04:51:12 GMT):
The last commit of indy-sdk which able to build is `b6a168443f60cfc55afc118927b766f3706ae3a3`. But I am not sure what the problem is

lauravuo-techlab (Tue, 11 Aug 2020 06:06:59 GMT):
Has joined the channel.

anchit (Tue, 11 Aug 2020 08:00:02 GMT):
Has joined the channel.

blaz (Tue, 11 Aug 2020 13:53:29 GMT):
Has joined the channel.

AmanAgrawal (Fri, 14 Aug 2020 06:26:59 GMT):
Has left the channel.

swcurran (Mon, 17 Aug 2020 13:40:20 GMT):
The indy-sdk anoncreds implementation gives essentially no information on why a verification fails -- which of the items being proven failed (not from the holder, not tampered with, not revoked). Is there a JIRA ticket or guidance on how this could be rectified?

sklump (Mon, 17 Aug 2020 13:41:56 GMT):
I had always thought this was by design, but I could be wrong?

swcurran (Mon, 17 Aug 2020 13:43:16 GMT):
Is there a proposal (perhaps in a JIRA ticket) for a way for a holder to detect that a credential they hold has been revoked? The only way I'm aware would be to create a proof and then verify it. Is that the best way to do it? Of course, the issuer could notify the holder if they have any a connection. In that case, there is a proposed RFC for that.

swcurran (Mon, 17 Aug 2020 13:44:23 GMT):
I don't think so. The verifier has the proof, so even if the Indy-SDK didn't expose that, the verifier could add their own code to do that. Might as well be exposed from the Indy SDK.

esplinr (Mon, 17 Aug 2020 22:20:24 GMT):
I'm not aware of a ticket to add additional error reporting there.

esplinr (Mon, 17 Aug 2020 22:20:24 GMT):
I'm not aware of a ticket to add additional error reporting when a proof verification fails.

swcurran (Mon, 17 Aug 2020 22:25:03 GMT):
OK - so this is a new idea? Any idea why it was not done previously?

esplinr (Mon, 17 Aug 2020 22:33:36 GMT):
I don't remember it coming up before. @Artemkaaas do you have any insight?

esplinr (Mon, 17 Aug 2020 22:34:54 GMT):
We discussed both ways that you mentioned: issuer notifying the holder over the DID connection, and the holder generating and validating a test proof. I'm not aware of any other proposals.

swcurran (Mon, 17 Aug 2020 22:47:17 GMT):
OK, thanks. So I'm assuming no docs on the latter,

esplinr (Mon, 17 Aug 2020 22:47:45 GMT):
Correct.

swcurran (Mon, 17 Aug 2020 22:50:10 GMT):
I think I will recommend that holder frameworks: 1. Test the proof before sending it. If it passes, send it. 2. If it fails (and we don't know why), test each revocable credential in the proof. E.g. construct a simple proof for each individual credential to check for failure. 3. Report back as detailed info back to the user as possible. Ideally pinned to the problem credential.

Artemkaaas (Tue, 18 Aug 2020 15:16:02 GMT):
There is no ticket. And I think it's not possible to do. Libindy returns errors in case of messages validation but the main part is math which finally leads to comparing just two numbers. And if they are different Indy returns false.

sklump (Tue, 18 Aug 2020 15:30:14 GMT):
Each indexed proof has a `"primary_proof"` and a `"non_revoc_proof"` component: surely any proof can be verified independently? Or is this a limitation of the toolkit rather than the mathematics?

sklump (Tue, 18 Aug 2020 15:30:14 GMT):
Each indexed proof has a `"primary_proof"` and a `"non_revoc_proof"` component: surely any proof can be verified independently, or it is not a proof*? Or is this a limitation of the toolkit rather than the mathematics? * we had a Prime Minister with an accidentally beautiful quote: https://www.daniellemagazine.ca/wp-content/uploads/2018/05/quote-a-proof-is-a-proof-what-kind-of-a-proof-it-s-a-proof-a-proof-is-a-proof-and-when-you-jean-chretien-5-55-61.jpg

esplinr (Tue, 18 Aug 2020 15:58:58 GMT):
lol

esplinr (Tue, 18 Aug 2020 16:00:02 GMT):
I think the proof or non-revocation separate from the primary proof is a limitation of the tool. Trying to figure out which attribute causes a primary proof failure is a limitation of the mathematics.

TimoGlastra (Wed, 19 Aug 2020 20:20:03 GMT):
Has joined the channel.

berserkr (Thu, 27 Aug 2020 01:17:32 GMT):
Hi team, what is the standard storage used to save indy wallet credentials? Is it postgres?

swcurran (Thu, 27 Aug 2020 02:04:29 GMT):
It's pluggable, with the options in the indy sdk SQLite and Postgres.

berserkr (Thu, 27 Aug 2020 03:05:30 GMT):
right, what is default? sqlite? The reason i ask is becasue I am looking at IndiWallet and only see an option for postgres, not sqlite

berserkr (Thu, 27 Aug 2020 03:06:05 GMT):
I am building things locally, already past the testing phase, now trying to build a service using a combination of aries and indy-sdk

swcurran (Thu, 27 Aug 2020 03:27:58 GMT):
SQLite is the default. Postgres takes some extra work with Indy to use. In Aries (e.g. ACA-Py), it's a start up option to use one or the other.

berserkr (Thu, 27 Aug 2020 04:21:48 GMT):
got it, thank you

ashlinSajan (Thu, 27 Aug 2020 05:20:50 GMT):
Hi team,Can any one give me an explanation on the use of BL and CL Signatures in indy-sdk?

SuperSeiyan (Thu, 27 Aug 2020 07:04:14 GMT):
This link could help https://forum.sovrin.org/t/how-are-verifiable-claims-signed/767

SuperSeiyan (Thu, 27 Aug 2020 07:04:14 GMT):
This link would help https://forum.sovrin.org/t/how-are-verifiable-claims-signed/767

sklump (Thu, 27 Aug 2020 10:34:46 GMT):
Indy-sdk `anoncreds.verifier_verify_proof()` gives back CommonInvalidStructure given a proof request with a non-revocation interval and a proof on all non-revocable credentials. The SDK should just ignore it. A holder may have satisfactory credentials for a proof request, some revocable and some not, and happen to find only non-revocable credentials to present.

sklump (Thu, 27 Aug 2020 10:34:46 GMT):
*ITEM:* Indy-sdk `anoncreds.verifier_verify_proof()` gives back CommonInvalidStructure given a proof request with a non-revocation interval and a proof on all non-revocable credentials. The SDK should just ignore it. A holder may have satisfactory credentials for a proof request, some revocable and some not, and happen to find only non-revocable credentials to present.

andrewtan (Mon, 31 Aug 2020 22:06:40 GMT):
Do we know if selective disclosure is now technically possible in Indy? Understand it was a concept not implemented back then. Thanks.

swcurran (Tue, 01 Sep 2020 03:11:58 GMT):
No -- it's always been supported - works exactly as expected.

swcurran (Tue, 01 Sep 2020 03:12:41 GMT):
Hmmm....as expected is probably too clear, since many people can have many ideas of what it might mean. It works the way I expect it to :-)

mccown (Tue, 01 Sep 2020 03:44:02 GMT):
Is anyone using the current indy-sdk version of the iOS wrapper? I found that I needed to make a change to the Podspec file to get the pods to install and build the .xcworkspace. When I try to build, I'm getting a few compiler errors in IndyLedger.mm. Has anyone else observed this?

mccown (Tue, 01 Sep 2020 03:44:02 GMT):
Is anyone using the current indy-sdk version of the iOS wrapper? To build the wrapper, I found that I needed to make a change to the Podspec file to get the pods to install and create the .xcworkspace. When I try to build, I'm getting a few compiler errors in IndyLedger.mm. These look minor (version differences?), but before I debug, has anyone else run into this?

zickau (Tue, 01 Sep 2020 12:36:39 GMT):
Could you please point me to a source how the several DIDs of I, H, and V are being included (mathematically) in the VC, proofs, and presentations on a low crypto level?

Xand (Tue, 01 Sep 2020 18:04:23 GMT):
Has joined the channel.

VictorSyntez (Tue, 01 Sep 2020 18:30:49 GMT):
Has joined the channel.

VictorSyntez (Tue, 01 Sep 2020 21:21:30 GMT):
Hello, I'm interested in volunteering for Hyperledger Indy projects as a developer-beginner. If there are some tasks that don't require extensive coding knowledge or this knowledge might be gained using free available and known resources then I am willing to help. You can contact me using private message. Cheers, Victor.

pikvik (Wed, 02 Sep 2020 04:56:16 GMT):
Has joined the channel.

larabisch (Wed, 02 Sep 2020 16:24:22 GMT):
Has joined the channel.

lynn.bendixsen (Wed, 02 Sep 2020 17:25:01 GMT):
Welcome @VictorSyntez !

VictorSyntez (Wed, 02 Sep 2020 17:25:52 GMT):
Thank you!

ianco (Wed, 02 Sep 2020 20:53:15 GMT):
FYI a recent change to the postgres plug-in has broken compatibility with postgres version 10 and earlier, see https://github.com/hyperledger/indy-sdk/issues/2231

profae (Thu, 03 Sep 2020 05:58:47 GMT):
Hi all, is there a way to delete the messages from the dummy-cloud-agent? I noticed that there is a slowdown as the number of messages increases Thanks

phuctu1901 (Thu, 03 Sep 2020 07:27:51 GMT):
Has joined the channel.

phuctu1901 (Thu, 03 Sep 2020 07:27:51 GMT):
Hey all, I have problem with indy-sdk. Can I verify that the 2 proof presentations come from 1 credentials? Are both proof presentations sharing the same fields and the same verifier?

PatrikStas (Thu, 03 Sep 2020 08:52:55 GMT):
dummy cloud agent doesn't scale well. We've alternative implementation https://github.com/AbsaOSS/vcxagencynode

PatrikStas (Thu, 03 Sep 2020 08:52:55 GMT):
dummy cloud agent doesn't scale well. We've created alternative implementation https://github.com/AbsaOSS/vcxagencynode

PatrikStas (Thu, 03 Sep 2020 08:54:43 GMT):
Should be still compatible with aries libvcx in Hyperledger Indy repo, but keep in mind going into future this will be kept in sync with Absa's LibVCX fork https://github.com/AbsaOSS/libvcx/

profae (Thu, 03 Sep 2020 09:14:39 GMT):
I also tried vcxagencynode but there is the same problem, perhaps even more, that is, a slowdown in responses when the messages are large, for example in the issuing of a credential of several kb this effect gets worse when there are many messages I thought that by deleting old messages maybe it would improve

PatrikStas (Thu, 03 Sep 2020 14:42:12 GMT):
As far as I know there is currently no api to delete message. I find it surprising that you found nodevcxagency to perform worse as all messages are stored in pgsql. On the other hand, dummy agency is doing some heavy lifting trying to keep all state in memory. Anyway, possibly easy experimental solution would be to delete messages in agency whenever status is updated to value `MS-106`, which signals that the message has been processed. Not sure if there scenarios when this would be problematic approach. Probably better solution would be to indeed add api for deleting messages to libvcx

profae (Thu, 03 Sep 2020 14:44:52 GMT):
probably the bottleneck is the encryption and decryption of messages

PatrikStas (Thu, 03 Sep 2020 14:46:17 GMT):
The main bottleneck for vcxnodeagency, and in fact every indy-sdk based application, I believe is this https://github.com/hyperledger/indy-sdk/issues/2164

profae (Thu, 03 Sep 2020 14:47:29 GMT):
I think that deleting messages with status MS-106 is a good solution

PatrikStas (Thu, 03 Sep 2020 14:48:11 GMT):
Are you open to contributing that to vcxagencynode? Or are you planning to stick with dummy agency?

profae (Thu, 03 Sep 2020 14:50:26 GMT):
we are evaluating both to understand the most reliable

profae (Thu, 03 Sep 2020 14:51:50 GMT):
have you tried to issue a 500kb credential and see the download times of the message and updatesatuts?

PatrikStas (Thu, 03 Sep 2020 14:53:46 GMT):
We haven't tried that

profae (Thu, 03 Sep 2020 14:54:36 GMT):
I noticed that the times for download and for the update status increase if there are more large messages, also of MS-106 status

PatrikStas (Thu, 03 Sep 2020 14:56:05 GMT):
The main proposition of node agency vs dummy is that node agency is quite stateless and hence scales horizontally, even though single instance performance is not great (mostly due to forementioned indysdk issue). Dummy agency loads up everything into memory, so startup times are never-ending as number of agents and messages grow and so you can't stale horizontally.

PatrikStas (Thu, 03 Sep 2020 14:57:47 GMT):
That's interesting. We recently artillery load tests contributed to node agency, it would be interesting to measure also these big messages.

PatrikStas (Thu, 03 Sep 2020 14:57:47 GMT):
That's interesting. We recently got artillery load tests contribution to node agency, it would be interesting to measure also these big messages.

profae (Thu, 03 Sep 2020 15:07:00 GMT):
is the communication between the vcx client and the mediator, dummyagent or node agency, defined custom by vcx or is it a public protocol? is this communication always encrypted?

PatrikStas (Thu, 03 Sep 2020 15:09:48 GMT):
That protocol is not according to any existing standard, it's protocol originally developed by Evernym. The best available documentation for that protocol is code - If you are interested, I'd advise to look here https://github.com/AbsaOSS/vcxagencynode/tree/master/vcxagency-client

PatrikStas (Thu, 03 Sep 2020 15:10:41 GMT):
And yes, the communication is always encrypted using indy-sdk/ursa based encryption

paul.bastian (Tue, 08 Sep 2020 11:46:49 GMT):
Has joined the channel.

berserkr (Wed, 09 Sep 2020 04:16:53 GMT):
Hi Team, has anyone seen the following error: ```b'{"identifier":"XYJAkVzsrqsDQgu5wN5wJE","reqId":1599615437529934931,"reason":"client request invalid: could not authenticate, verkey for XYJAkVzsrqsDQgu5wN5wJE cannot be found","op":"REQNACK"}',)``` I am following the steps in the `getting_started.py` script

berserkr (Wed, 09 Sep 2020 04:20:00 GMT):
This same question has been asked several times over the past two years or so, but unfortunately I am unable to see the answers... if there are any...

berserkr (Wed, 09 Sep 2020 04:44:37 GMT):
One more question, I am getting the above when I try to add a STEWARD, are there specific steps I need to follow in order to add a new STEWARD? Starting with a clean indy image?

WadeBarnes (Wed, 09 Sep 2020 13:39:56 GMT):
This error indicates the DID (`XYJAkVzsrqsDQgu5wN5wJE`) was not found on the ledger.

berserkr (Wed, 09 Sep 2020 20:05:59 GMT):
Thank you, yes, that is what I figured. When I start with the default Steward it works fine, if I want to define my own, it fails. So I am looking to see how to get it working with my own Steward/trustees

berserkr (Wed, 09 Sep 2020 23:23:07 GMT):
Team, one more question. The tails file, how is that managed? Most examples use a local tails file... is there support within the sdk to manage a distribuited tails file?

VictorSyntez (Wed, 09 Sep 2020 23:23:10 GMT):
Hello. I wonder if anybody can point me on any existing lists of API commands for the Indy Node

lynn.bendixsen (Thu, 10 Sep 2020 19:15:11 GMT):
A new Trustee or Steward can be added to the ledger using a signature from an existing Trustee. This can be accomplished using code, or the indy-cli. Sometimes the error you saw happens when you have a different verkey in your wallet than the one that exists on the ledger (e.g. you added the Trustee to your wallet with the wrong seed?)

karimStekelenburg1 (Thu, 10 Sep 2020 20:07:20 GMT):
Has joined the channel.

karimStekelenburg1 (Thu, 10 Sep 2020 20:25:32 GMT):
Hi all! I have a question regarding the Android wrapper around IndySdk. I’m working on a react-native app that uses aries-framework-javascript together with rn-indy-sdk (https://github.com/AbsaOSS/rn-indy-sdk) and I’m struggling to get it to work. I have followed the instructions over at https://github.com/hyperledger/indy-sdk/blob/ebdf1b62b4b744b94155cb6f032367540b33556c/docs/build-guides/android-build.md#notes and the build seems to recognise the libindy shared objects. However, the build docs also mention the following: `Make sure you have libc++_shared.so file in the corresponsind subfolder in jniLibs`, but it doesn’t say where to get/find `libc++_shared.so`. After some searching online I found that it’s part of NDK and this should be handled by Gradle. However, by build can’t fails because of it and since the docs mention the manual placement of this file I’m wondering if I’m missing something. I’m by no means an experienced Android developer and it could very well be that this question is not suited for this channel. If this is the case, feel free to correct me :) Thanks in advance!

SuperSeiyan (Fri, 11 Sep 2020 03:43:01 GMT):
You can get`libc++_shared.so` from NDK and you can try to download follow this script, hope this will help https://github.com/sktston/vcx-demo-android/blob/master/populate_libraries.sh#L41

SuperSeiyan (Fri, 11 Sep 2020 03:54:07 GMT):
Hello, I found this script . You can try to comment out for libs you need. When you build an android app with new libraries do not forget to `./gradlew clean` before building a new one. Hope this will help.

SuperSeiyan (Fri, 11 Sep 2020 03:54:07 GMT):
Hello, I found this script https://github.com/sktston/vcx-demo-android/blob/master/populate_libraries.sh. You can try to comment out for libs you need. When you build an android app with new libraries do not forget to `./gradlew clean` before building a new one. Hope this will help.

SuperSeiyan (Fri, 11 Sep 2020 03:54:07 GMT):
Hello, I found this script https://github.com/sktston/vcx-demo-android/blob/master/populate_libraries.sh. You can try to comment out for libs you need. Make sure that you put the library match to android architecture. When you build an android app with new libraries do not forget to `./gradlew clean` before building a new one. Hope this will help.

SuperSeiyan (Fri, 11 Sep 2020 04:31:53 GMT):
Hi All, I would like to know that LibVCX now supports public tails file or only local file? The scenario would be I have an issuer who binds to the public tails server, a verifier, a holder in a separate instance. The issuer able to create a document for the holder but, The verifier cannot verify proof because it cannot find any tails file on the public tails file server. (I also add `tails_file` as a public URL which downloads able) Note: issuer and verifier as ACA-py, holder as LibVCX client.

karimStekelenburg1 (Fri, 11 Sep 2020 08:08:21 GMT):
Hi there! Thank you so much! This looks very promising. I'll test it out later today. Thanks again!

karimStekelenburg1 (Fri, 11 Sep 2020 20:06:57 GMT):
It worked!!! Thanks a lot, now I finally have a fresh new error to worry about :)

berserkr (Tue, 15 Sep 2020 00:35:06 GMT):
Hi All, has anyone seen an issue where we are tyring to create a proof, and am seeing issues where the schema id is not found...

berserkr (Tue, 15 Sep 2020 00:35:17 GMT):
```2020-09-14 17:07:30,945 - indy.libindy - DEBUG - _get_error_details: <<< error_details: {'backtrace': '', 'message': 'Error: Invalid structure\n Caused by: Schema not found by id: SchemaId("59QJZodWdY6dQX3boJiYMF:2:VIDBC:1.0")\n'} 2020-09-14 17:07:30,946 - indy.libindy - DEBUG - _indy_callback: >>> command_handle: 48, err , args: (b'',) 2020-09-14 17:07:30,946 - indy.libindy - DEBUG - _indy_callback: <<< 2020-09-14 17:07:30,946 - indy.libindy - DEBUG - _indy_loop_callback: >>> command_handle: 48, err , args: (b'',) 2020-09-14 17:07:30,946 - indy.libindy - WARNING - _indy_loop_callback: Function returned error 2020-09-14 17:07:30,946 - indy.libindy - DEBUG - _indy_loop_callback <<< Traceback (most recent call last): File "wallet_if.py", line 1037, in schemas_json, cred_defs_json, revoc_states_json) File "wallet_if.py", line 753, in create_proof schemas_json, cred_defs_json, revoc_states_json)) File "/home/lbathen/anaconda3/envs/vid/lib/python3.7/asyncio/runners.py", line 43, in run return loop.run_until_complete(main) File "/home/lbathen/anaconda3/envs/vid/lib/python3.7/asyncio/base_events.py", line 587, in run_until_complete return future.result() File "/home/lbathen/anaconda3/envs/vid/lib/python3.7/site-packages/indy/anoncreds.py", line 1617, in prover_create_proof prover_create_proof.cb)```

berserkr (Tue, 15 Sep 2020 00:37:09 GMT):
However, that does not match my main schema ID, the schema ID it seems comes from the Credentials definition where a totally different schemaid is defined for whatever reason... For example: ```credential_defs_json: '{"UTbxNGNobY3ftF5mZed68N:3:CL:UTbxNGNobY3ftF5mZed68N:2:VIDBC:1.0:cred_def_tag": {"ver": "1.0", "id": "UTbxNGNobY3ftF5mZed68N:3:CL:UTbxNGNobY3ftF5mZed68N:2:VIDBC:1.0:cred_def_tag", "schemaId": "UTbxNGNobY3ftF5mZed68N:2:VIDBC:1.0", "type": "CL", "tag": "cred_def_tag", "value"```

jchierro (Tue, 15 Sep 2020 13:50:44 GMT):
Has joined the channel.

jchierro (Tue, 15 Sep 2020 13:50:44 GMT):
Hi friends, I'm having trouble verifying multiple credentials associated with a single revocation record. I can only validate the first credential. Can you help me? Thank you!

tomislav (Tue, 15 Sep 2020 23:25:35 GMT):
@jchierro Curious, which codebase are you using?

jchierro (Wed, 16 Sep 2020 09:12:23 GMT):
Hi, I use libindy 1.15 the problem arises when validating (from the first one) a credential from the same revocation record. The result is always FALSE when I know that the credential is correct and has not been revoked. Investigating I have found this: https://jira.hyperledger.org/browse/URSA-9?attachmentViewMode=list

profae (Wed, 16 Sep 2020 14:51:38 GMT):
Hi all, I have a problem in the libindy build for iOS i used these scripts https://github.com/jakubkoci/indy-vcx-build but the libindy build fails because it tries to link the libzmq and libsodium libraries in desktop version, taken from the dir /usr/local/Cellar/ ... , and not the arm64 version where am i wrong? thank you

swcurran (Wed, 16 Sep 2020 15:04:00 GMT):
@mccown was talking about this issue on the Indy Contributors call yesterday. It seems to be an issue with XCode 11 perhaps?

profae (Wed, 16 Sep 2020 15:05:24 GMT):
I have XCode 11.6

mindy (Fri, 18 Sep 2020 09:14:40 GMT):
Has joined the channel.

mindy (Fri, 18 Sep 2020 09:14:40 GMT):
Can I get some questions?

mindy (Fri, 18 Sep 2020 09:15:56 GMT):
I tried to execute the sample(https://github.com/hyperledger/indy-sdk/tree/master/samples/java) with java

mindy (Fri, 18 Sep 2020 09:17:32 GMT):
But, I was faced with a NullPointerException in org.hyperledger.indy.sdk.pool.Pool.setProtocolVersion (Pool.java:252)

mindy (Fri, 18 Sep 2020 09:19:17 GMT):
The OS is macos.

mindy (Fri, 18 Sep 2020 09:20:46 GMT):
I downloaded latest libindy.dylib (https://repo.sovrin.org/macos/) and set the DYLD_LIBRARY_PATH.

mindy (Fri, 18 Sep 2020 09:21:52 GMT):
How do I run the sample on Macos?

mindy (Fri, 18 Sep 2020 09:26:05 GMT):
The result is below capture.

mindy (Fri, 18 Sep 2020 09:29:21 GMT):

Screen Shot 2020-09-18 at 6.25.36 PM.png

mindy (Fri, 18 Sep 2020 09:31:41 GMT):

NullPointerException.png

SuperSeiyan (Mon, 21 Sep 2020 03:01:31 GMT):
Hello All, I would like to know, Is there the best practice to use DID connection is a connection per a credential offer or it could be a connection per multiple credential offers?

PatrikStas (Mon, 21 Sep 2020 09:45:54 GMT):
@SuperSeiyan one connection can facilitate many conversations of many protocols (credential exchage, proof requests, ... ). The way you distinguish different conversations of same protocol over the same connection would be by what Aries calls "thread id", see this RFC https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0008-message-id-and-threading/README.md

SuperSeiyan (Wed, 23 Sep 2020 05:33:11 GMT):
@PatrikStas Thank you for your answer :blush:

GianlucaPinto (Thu, 24 Sep 2020 13:55:16 GMT):
Has joined the channel.

GianlucaPinto (Thu, 24 Sep 2020 13:55:17 GMT):
hi all, how can i do for get the timestamp of a credentials ? thanks

GianlucaPinto (Thu, 24 Sep 2020 13:55:33 GMT):
of the issue of that credential

krgko (Tue, 29 Sep 2020 09:51:24 GMT):
Has joined the channel.

biligunb (Wed, 30 Sep 2020 10:36:17 GMT):
generatekey

alexsiqueira (Wed, 30 Sep 2020 22:51:29 GMT):
Has joined the channel.

sklump (Fri, 02 Oct 2020 11:02:13 GMT):
Include it as an attribute in the schema

profae (Sun, 04 Oct 2020 18:51:14 GMT):
Hi all, the call vcxInitWithConfig takes several seconds and the wait occurs when it gives the log message: "com.evernym.sdk.vcx.LibVcx.native.indy.services.pool.merkle_tree_factory - src / services / pool / merkle_tree_factory.rs: 46 | Cache is invalid - dropping it!" is it possible to avoid this waiting? thank you

andrew.whitehead (Sun, 04 Oct 2020 20:23:18 GMT):
That seems to indicate it's trying to perform a catch-up with the ledger validator pool (which is normal), but the invalid cache likely indicates that the ledger has been reset since the last connection. It would probably take a little longer to catch up in that case

PatrikStas (Mon, 05 Oct 2020 10:14:02 GMT):
We have been running into this recently, it tries to catch up pool transactions and the nodes indy-sdk is tried to connect are timing out. Sometimes it takes 20, sometimes even 60 seconds to establish connection

PatrikStas (Mon, 05 Oct 2020 10:15:19 GMT):
We were trying to play with parameters one can pass to open pool function (preferred nodes, different time outs) but we didn't find the right configuration which would significantly improve the issue

PatrikStas (Mon, 05 Oct 2020 10:17:35 GMT):
In particularly for libvcx case @profae , we have a bit of a workaround in place - we don't use `vcxInitWithConfig` but in Absa libvcx fork we've splitted the function into 3 - vcx init core (initialize memory state), open pool, open wallet. So we init memory and open wallet first, as those have predictable durations, and we init pool on the background

sergey.minaev (Mon, 05 Oct 2020 20:29:47 GMT):
There are similar split for `init` in Evernym's fork as well. It's quite new and so it hasn't been ported back to upstream. "Cache is invalid" makes me nervous as it either mean real changes in ledger pool or some bug in libindy sync... @profae @PatrikStas have you seen this behavior connecting to one of Sovrin nets or your local one?

DucaDellaForcoletta (Tue, 06 Oct 2020 08:59:12 GMT):
Hi all,

DucaDellaForcoletta (Tue, 06 Oct 2020 09:11:14 GMT):
Hi all, I've a verify proof with FALSE result using a wallet with credentials inside generated on libindy 1.12 and then exported and used under libindy 1.15 through libvcx 0.8. The verifier is using acapy v.0.5.4 with libindy 1.15. The proof asks for one attribute with a restriction on the credential def id. The ledger used is sovrin staging. I've also enabled the libindy log but I'm not able to find the reason of proof verification failure. The issue feature using the environment described above work well and the credential are stored in the wallet correctly I can provide also the proofrequest and proof if needed for investigation. Help is greatly appreciated. thanks

sabir.aboobaker (Thu, 08 Oct 2020 09:59:25 GMT):
Has joined the channel.

vasantkk (Thu, 08 Oct 2020 10:35:15 GMT):
Has joined the channel.

sergey.minaev (Thu, 08 Oct 2020 10:44:33 GMT):
Hi @DucaDellaForcoletta , is it 100% reproducible? Could you try to create a couple of scripts to show the problem (e.g. based on python or nodejs libVCX demo)? It will speed up the response from IndySDK maintainers a lot. As far as I remember release history there should not be breaking changes between 1.12 and 1.15, but there was some bugfixes (including fixes for false-postives checks)

sergey.minaev (Thu, 08 Oct 2020 10:44:33 GMT):
Hi @DucaDellaForcoletta , is it 100% reproducible? Could you try to create a couple of scripts to show the problem (e.g. based on python or nodejs libVCX demo)? It will speed up the response from IndySDK maintainers a lot. As far as I remember release history there should be no breaking changes between 1.12 and 1.15, but there was some bugfixes (including fixes for false-postives checks)

sergey.minaev (Thu, 08 Oct 2020 10:44:33 GMT):
Hi @DucaDellaForcoletta , is it 100% reproducible? Could you try to create a couple of scripts to show the problem (e.g. based on python or nodejs libVCX demo)? It will speed up the response from IndySDK maintainers a lot. As far as I remember release history there should be no breaking changes between 1.12 and 1.15, but there was some bugfixes around verification process (including fixes for false-postives checks)

sergey.minaev (Thu, 08 Oct 2020 10:44:33 GMT):
Hi @DucaDellaForcoletta , is it 100% reproducible? Could you try to create a couple of scripts to show the problem (e.g. based on python or nodejs libVCX demo)? It will speed up the response from IndySDK maintainers a lot. As far as I remember release history there should be no breaking changes between 1.12 and 1.15, but there were some bugfixes around verification process (including fixes for false-postives checks)

DucaDellaForcoletta (Thu, 08 Oct 2020 10:50:24 GMT):
Hi Sergey, I finally found the problem and it's due to the master_secret present in the wallet that was created using a libindy wrapper. Actually, both aca-py than vcx, generate a new master secret on open and seems it's not possible to provide from external a key already present in wallet. In our scenario this will cause the proof validation failure.

DucaDellaForcoletta (Thu, 08 Oct 2020 10:50:24 GMT):
Hi Sergey, I finally found the problem and it's due to the master_secret present in the wallet that was created using a libindy wrapper. Actually, both aca-py and vcx, generate a new master secret on open and seems it's not possible to provide from external a key already present in wallet. In our scenario this will cause the proof validation failure.

DucaDellaForcoletta (Thu, 08 Oct 2020 10:50:24 GMT):
Hi Sergey, I finally found the problem and it's due to the master_secret present in the wallet that was created using a libindy wrapper. Actually, both aca-py and vcx, generate a new master secret on open and seems it's not possible to provide from external a key already present in wallet. In our scenario this will cause the proof validation failure for old credential present in the wallet.

DucaDellaForcoletta (Thu, 08 Oct 2020 10:50:24 GMT):
Hi @sergey.minaev , I finally found the problem and it's due to the master_secret present in the wallet that was created using a libindy wrapper. Actually, both aca-py and vcx, generate a new master secret on open and seems it's not possible to provide from external a key already present in wallet. In our scenario this will cause the proof validation failure for old credential present in the wallet.

sergey.minaev (Thu, 08 Oct 2020 11:23:27 GMT):
sounds reasonable, thanks for sharing the details!

akshay.sood (Fri, 09 Oct 2020 16:05:17 GMT):
Hi guys I was looking for query language support in indy sdk. I saw the wallet query language, but it is mentioned there that it is for tags. I am not sure if I can use it for attribute complex queries (for example: WHERE degree LIKE Bachelor% ) Ref: https://github.com/hyperledger/indy-sdk/tree/master/docs/design/011-wallet-query-language I have the following credentials in my wallet: ```[{"referent":"00ee06c7-1bd0-4832-acf6-82d3bbc01a59","attrs":{"gpa":"8.9","university":"KUK","firstName":"Akshay","certUUID":"adsdd","studentCode":"ddw","awardedDegree":"Bachelor","awardedYear":"2016","lastName":"Sood"},"schema_id":"CzyJqvfbWBDq3aVFxUCyc3:2:UNIVERSITY_SCHEMA:1.0","cred_def_id":"CzyJqvfbWBDq3aVFxUCyc3:3:CL:24:Tag1","rev_reg_id":"CzyJqvfbWBDq3aVFxUCyc3:4:CzyJqvfbWBDq3aVFxUCyc3:3:CL:24:Tag1:CL_ACCUM:Tag1","cred_rev_id":"2"},{"referent":"f41347a1-75ce-485c-85d7-b32b7e6e7587","attrs":{"awardedDegree":"Bachelor","awardedYear":"2016","lastName":"Sood","firstName":"Akshay","certUUID":"adsdd","university":"KUK","gpa":"8.9","studentCode":"ddw"},"schema_id":"CzyJqvfbWBDq3aVFxUCyc3:2:UNIVERSITY_SCHEMA:1.0","cred_def_id":"CzyJqvfbWBDq3aVFxUCyc3:3:CL:24:Tag1","rev_reg_id":"CzyJqvfbWBDq3aVFxUCyc3:4:CzyJqvfbWBDq3aVFxUCyc3:3:CL:24:Tag1:CL_ACCUM:Tag1","cred_rev_id":"3"},{"referent":"70b43d40-8e08-4a5b-b4f2-19ea3fb36578","attrs":{"gpa":"8.9","lastName":"Sood","firstName":"Akshay","certUUID":"adsdd","studentCode":"ddw","awardedYear":"2016","university":"KUK","awardedDegree":"Master"},"schema_id":"CzyJqvfbWBDq3aVFxUCyc3:2:UNIVERSITY_SCHEMA:1.0","cred_def_id":"CzyJqvfbWBDq3aVFxUCyc3:3:CL:24:Tag1","rev_reg_id":"CzyJqvfbWBDq3aVFxUCyc3:4:CzyJqvfbWBDq3aVFxUCyc3:3:CL:24:Tag1:CL_ACCUM:Tag1","cred_rev_id":"1"}]``` I am trying to search for creds using ```const [sh, count] = await sdk.proverSearchCredentials(proverWallet, {'~attr::awardedDegree::value': {$like: 'Bachelor%'}});``` but it returns count:0 I am using attr::::value pattern because it is mentioned in the document ```proverStoreCredential ( wh, credId, credReqMetadata, cred, credDef, revRegDef ) -> outCredId Check credential provided by Issuer for the given credential request, updates the credential by a master secret and stores in a secure wallet. To support efficient and flexible search the following tags will be created for stored credential: { "schema_id": , "schema_issuer_did": , "schema_name": , "schema_version": , "issuer_did": , "cred_def_id": , "rev_reg_id": , // "None" as string if not present // for every attribute in "attr::::marker": "1", "attr::::value": , }```

akshay.sood (Fri, 09 Oct 2020 16:05:17 GMT):
Hi guys I was looking for query language support in indy sdk. I saw the wallet query language, but it is mentioned there that it is for tags. I am not sure if I can use it for attribute complex queries (for example: WHERE degree LIKE Bachelor% ) Ref: https://github.com/hyperledger/indy-sdk/tree/master/docs/design/011-wallet-query-language I have the following credentials in my wallet: ``` [{"referent":"00ee06c7-1bd0-4832-acf6-82d3bbc01a59","attrs":{"gpa":"8.9","university":"KUK","firstName":"Akshay","certUUID":"adsdd","studentCode":"ddw","awardedDegree":"Bachelor","awardedYear":"2016","lastName":"Sood"},"schema_id":"CzyJqvfbWBDq3aVFxUCyc3:2:UNIVERSITY_SCHEMA:1.0","cred_def_id":"CzyJqvfbWBDq3aVFxUCyc3:3:CL:24:Tag1","rev_reg_id":"CzyJqvfbWBDq3aVFxUCyc3:4:CzyJqvfbWBDq3aVFxUCyc3:3:CL:24:Tag1:CL_ACCUM:Tag1","cred_rev_id":"2"},{"referent":"f41347a1-75ce-485c-85d7-b32b7e6e7587","attrs":{"awardedDegree":"Bachelor","awardedYear":"2016","lastName":"Sood","firstName":"Akshay","certUUID":"adsdd","university":"KUK","gpa":"8.9","studentCode":"ddw"},"schema_id":"CzyJqvfbWBDq3aVFxUCyc3:2:UNIVERSITY_SCHEMA:1.0","cred_def_id":"CzyJqvfbWBDq3aVFxUCyc3:3:CL:24:Tag1","rev_reg_id":"CzyJqvfbWBDq3aVFxUCyc3:4:CzyJqvfbWBDq3aVFxUCyc3:3:CL:24:Tag1:CL_ACCUM:Tag1","cred_rev_id":"3"},{"referent":"70b43d40-8e08-4a5b-b4f2-19ea3fb36578","attrs":{"gpa":"8.9","lastName":"Sood","firstName":"Akshay","certUUID":"adsdd","studentCode":"ddw","awardedYear":"2016","university":"KUK","awardedDegree":"Master"},"schema_id":"CzyJqvfbWBDq3aVFxUCyc3:2:UNIVERSITY_SCHEMA:1.0","cred_def_id":"CzyJqvfbWBDq3aVFxUCyc3:3:CL:24:Tag1","rev_reg_id":"CzyJqvfbWBDq3aVFxUCyc3:4:CzyJqvfbWBDq3aVFxUCyc3:3:CL:24:Tag1:CL_ACCUM:Tag1","cred_rev_id":"1"}] ``` I am trying to search for creds using ```const [sh, count] = await sdk.proverSearchCredentials(proverWallet, {'~attr::awardedDegree::value': {$like: 'Bachelor%'}});``` but it returns count:0 I am using attr::::value pattern because it is mentioned in the document ```proverStoreCredential ( wh, credId, credReqMetadata, cred, credDef, revRegDef ) -> outCredId Check credential provided by Issuer for the given credential request, updates the credential by a master secret and stores in a secure wallet. To support efficient and flexible search the following tags will be created for stored credential: { "schema_id": , "schema_issuer_did": , "schema_name": , "schema_version": , "issuer_did": , "cred_def_id": , "rev_reg_id": , // "None" as string if not present // for every attribute in "attr::::marker": "1", "attr::::value": , }```

akshay.sood (Fri, 09 Oct 2020 16:05:17 GMT):
Hi guys I was looking for query language support in indy sdk. I saw the wallet query language, but it is mentioned there that it is for tags. I am not sure if I can use it for attribute complex queries (for example: WHERE degree LIKE Bachelor% ) Ref: https://github.com/hyperledger/indy-sdk/tree/master/docs/design/011-wallet-query-language I have the following credentials in my wallet: ``` [{"referent":"00ee06c7-1bd0-4832-acf6-82d3bbc01a59","attrs":{"gpa":"8.9","university":"KUK","firstName":"Akshay","certUUID":"adsdd","studentCode":"ddw","awardedDegree":"Bachelor","awardedYear":"2016","lastName":"Sood"},"schema_id":"CzyJqvfbWBDq3aVFxUCyc3:2:UNIVERSITY_SCHEMA:1.0","cred_def_id":"CzyJqvfbWBDq3aVFxUCyc3:3:CL:24:Tag1","rev_reg_id":"CzyJqvfbWBDq3aVFxUCyc3:4:CzyJqvfbWBDq3aVFxUCyc3:3:CL:24:Tag1:CL_ACCUM:Tag1","cred_rev_id":"2"},{"referent":"f41347a1-75ce-485c-85d7-b32b7e6e7587","attrs":{"awardedDegree":"Bachelor","awardedYear":"2016","lastName":"Sood","firstName":"Akshay","certUUID":"adsdd","university":"KUK","gpa":"8.9","studentCode":"ddw"},"schema_id":"CzyJqvfbWBDq3aVFxUCyc3:2:UNIVERSITY_SCHEMA:1.0","cred_def_id":"CzyJqvfbWBDq3aVFxUCyc3:3:CL:24:Tag1","rev_reg_id":"CzyJqvfbWBDq3aVFxUCyc3:4:CzyJqvfbWBDq3aVFxUCyc3:3:CL:24:Tag1:CL_ACCUM:Tag1","cred_rev_id":"3"},{"referent":"70b43d40-8e08-4a5b-b4f2-19ea3fb36578","attrs":{"gpa":"8.9","lastName":"Sood","firstName":"Akshay","certUUID":"adsdd","studentCode":"ddw","awardedYear":"2016","university":"KUK","awardedDegree":"Master"},"schema_id":"CzyJqvfbWBDq3aVFxUCyc3:2:UNIVERSITY_SCHEMA:1.0","cred_def_id":"CzyJqvfbWBDq3aVFxUCyc3:3:CL:24:Tag1","rev_reg_id":"CzyJqvfbWBDq3aVFxUCyc3:4:CzyJqvfbWBDq3aVFxUCyc3:3:CL:24:Tag1:CL_ACCUM:Tag1","cred_rev_id":"1"}] ``` I am trying to search for creds using ``` const [sh, count] = await sdk.proverSearchCredentials(proverWallet, {'~attr::awardedDegree::value': {$like: 'Bachelor%'}}); ``` but it returns count:0 I am using attr::::value pattern because it is mentioned in the document ``` proverStoreCredential ( wh, credId, credReqMetadata, cred, credDef, revRegDef ) -> outCredId Check credential provided by Issuer for the given credential request, updates the credential by a master secret and stores in a secure wallet. To support efficient and flexible search the following tags will be created for stored credential: { "schema_id": , "schema_issuer_did": , "schema_name": , "schema_version": , "issuer_did": , "cred_def_id": , "rev_reg_id": , // "None" as string if not present // for every attribute in "attr::::marker": "1", "attr::::value": , } ```

akshay.sood (Fri, 09 Oct 2020 16:07:13 GMT):
q1ERTYUIOP[]

ankita.p17 (Mon, 12 Oct 2020 08:36:19 GMT):
Has joined the channel.

RinkalBhojani (Wed, 14 Oct 2020 08:16:07 GMT):
Has joined the channel.

RinkalBhojani (Wed, 14 Oct 2020 08:23:04 GMT):
Hi Iynn, Is it possible for you to include libindystrgpostgres.dll on https://repo.sovrin.org/windows/? I am facing an issue while building postgres storage plugin in Indy-sdk on Windows 10. https://github.com/hyperledger/indy-sdk/issues/2248 Thanks

lynn.bendixsen (Wed, 14 Oct 2020 14:46:42 GMT):
Sorry, I am not in charge of builds for Sovrin. @WadeBarnes ? It looks like it is needing zmq.lib, is that in your path?

WadeBarnes (Wed, 14 Oct 2020 15:03:54 GMT):
I agree with @lynn.bendixsen, looks like you're missing a dependency.

akshay.sood (Thu, 15 Oct 2020 06:54:50 GMT):
Can anyone help here?

RinkalBhojani (Thu, 15 Oct 2020 07:35:06 GMT):

Clipboard - October 15, 2020 1:04 PM

RinkalBhojani (Thu, 15 Oct 2020 07:36:01 GMT):
I have downloaded these files from https://zeromq.org/download/

swcurran (Thu, 15 Oct 2020 18:21:08 GMT):
@ianco -- any advice to give here?

ianco (Fri, 16 Oct 2020 18:15:14 GMT):
I'm not sure about the use of the tilde `~` character in the attribute search, I assume this is using a plaintext tag but I haven't tried it

ianco (Fri, 16 Oct 2020 18:15:41 GMT):
... Also I haven't tried with `$like` (assume this will work against plaintext tags but not encrypted tags)

ianco (Fri, 16 Oct 2020 18:16:26 GMT):
If you're able to log the executed sql on the database side you can see exactly what sql is getting generated, and then you can try running the sql directly and see what happens

ianco (Fri, 16 Oct 2020 18:17:04 GMT):
If you haven't seen it the wql docs are here: https://github.com/hyperledger/indy-sdk/tree/master/docs/design/011-wallet-query-language

akshay.sood (Sun, 18 Oct 2020 06:24:35 GMT):
@ianco Thanks for responding. Can you write the simple query for an attribute search here? I just want to know the format that works for you. I am not able to find sample working. Take `awardedDegree` as an attribute example. This will help me a lot

akshay.sood (Sun, 18 Oct 2020 06:24:35 GMT):
@ianco Thanks for responding. Can you write the simple query for an attribute search here? For example: ``` ``` I just want to know the format that works for you. I am not able to find sample working. Take `awardedDegree` as an attribute example. This will help me a lot

akshay.sood (Sun, 18 Oct 2020 06:24:35 GMT):
@ianco Thanks for responding. Can you write the simple query for an attribute search here? For example: ``` const [sh, count] = await sdk.proverSearchCredentials(proverWallet, {'~attr::awardedDegree::value': {$like: 'Bachelor%'}}); ``` I just want to know the format that works for you. I am not able to find sample working. Take `awardedDegree` as an attribute example. This will help me a lot

akshay.sood (Sun, 18 Oct 2020 06:24:35 GMT):
@ianco Thanks for responding. Can you write the simple query for an attribute search here? For example: ``` const [sh, count] = await sdk.proverSearchCredentials(proverWallet, {'~attr::awardedDegree::value': {$like: 'Bachelor%'}}); ``` I just want to know the format that works for you. I am not able to find a working sample. Take `awardedDegree` as an attribute example. This will help me a lot

ianco (Mon, 19 Oct 2020 13:37:59 GMT):
Hi @akshay.sood you can check the indy-sdk unit tests, there are some working examples, for example check in: https://github.com/hyperledger/indy-sdk/blob/master/libindy/tests/anoncreds_demos.rs

ianco (Mon, 19 Oct 2020 13:38:47 GMT):
One good approach to testing your own wql's is to modify an existing unit test to use your syntax and then run `cargo test`

ianco (Mon, 19 Oct 2020 13:38:57 GMT):
Are you able to run indy-sdk unit tests locally?

akshay.sood (Mon, 19 Oct 2020 13:41:09 GMT):
@ianco I havent tried yet. I am using node sdk

ianco (Mon, 19 Oct 2020 13:46:12 GMT):
I'm not familiar with the node sdk :-( Try browsing through the rust code for the unit tests and see if you can get those same examples working in node

akshay.sood (Mon, 19 Oct 2020 13:47:07 GMT):
@ianco That is ok. I am not familiar with rust actually. Can you navigate me to the code where WQL is used?

ianco (Mon, 19 Oct 2020 13:48:12 GMT):
Sure here's an example: https://github.com/hyperledger/indy-sdk/blob/master/libindy/tests/anoncreds_demos.rs#L3207

ianco (Mon, 19 Oct 2020 13:48:35 GMT):
If you just search for `$` you'll be able to recognize where wql operators are being used

ianco (Mon, 19 Oct 2020 13:49:00 GMT):
You can search through the python code an other unit tests as well, it's the same wql in every language

akshay.sood (Mon, 19 Oct 2020 13:49:13 GMT):
Does it work if I add a custom attribute for example: `awardedDegree`

ianco (Mon, 19 Oct 2020 13:49:33 GMT):
Hi folks wondering if there is interest in an updated indy-sdk release? My project has a dependency on some code in msater ut not yet in a release. Understand that no one is supporting indy-sdk releases now, I'd be willing to help with coordinating/supporting the release id there is other interest in the community?

ianco (Mon, 19 Oct 2020 13:49:56 GMT):
Yes it should work with any attribute you have in a credential

akshay.sood (Mon, 19 Oct 2020 13:50:15 GMT):
That is great. Do I need to prefix `attr::`

ianco (Mon, 19 Oct 2020 13:51:56 GMT):
yes you need to use `attr::::value`

akshay.sood (Mon, 19 Oct 2020 13:52:23 GMT):
Thanks @ianco. I will give it a try

ianco (Mon, 19 Oct 2020 14:22:26 GMT):
Hi folks wondering if there is interest in an updated indy-sdk release? My project has a dependency on some code in msater ut not yet in a release. Understand that no one is supporting indy-sdk releases now, I'd be willing to help with coordinating/supporting the release id there is other interest in the community?

ianco (Mon, 19 Oct 2020 15:22:31 GMT):
Hi folks wondering if there is interest in an updated indy-sdk release? My project has a dependency on some code in msater ut not yet in a release. Understand that no one is supporting indy-sdk releases now, I'd be willing to help with coordinating/supporting the release id there is other interest in the community?

sklump (Tue, 20 Oct 2020 11:10:59 GMT):
@domwoe has found that indy-sdk's `crypto.pack_message()` https://github.com/hyperledger/indy-sdk/blob/f9eb2cf17b51584f875c4707094256a96656e7b8/wrappers/python/indy/crypto.py#L442 fails on recipient verification keys in short form: ``` Error: Invalid structure Caused by: The base58 input contained a character not part of the base58 alphabet ``` Isolating to purely indy, consider `test_x.py`: ``` import json from indy import did, crypto import pytest @pytest.mark.asyncio async def test_abbreviate_verkey_for_abbbr_key(wallet_handle): (_did, full_verkey) = await did.create_and_store_my_did(wallet_handle, "{}") verkey = await did.abbreviate_verkey(_did, full_verkey) assert not full_verkey == verkey print(f'\n== abbreviated {full_verkey} -> {verkey}') packed = await crypto.pack_message(wallet_handle, "Hello", [full_verkey], None) print(f'.. Packed long: {packed}') packed = await crypto.pack_message(wallet_handle, "Hello", [verkey], None) print(f'.. Packed short: {packed}') ``` Output follows: ``` test_x.py == abbreviated 2YoRUwBtQZkMBiV8UgJXZSLDVHTbfFaz2azTnoxN5skg -> ~94YEUsZ1f3huu5mWtMz6rg .. Packed long: b'{"protected":"eyJlbmMiOiJ4Y2hhY2hhMjBwb2x5MTMwNV9pZXRmIiwidHlwIjoiSldNLzEuMCIsImFsZyI6IkFub25jcnlwdCIsInJlY2lwaWVudHMiOlt7ImVuY3J5cHRlZF9rZXkiOiJPaDNJc2hNVFpKOHREMkEzM3VfMFJpUzdLOGh6SW9zOWpZQ3lMRHNqQVQ3ejBSWTczU2tzNHluNXdqRHBIR3ljbnRtU1pvR1pVZHZFWFJDVVlzVG5OT1QxcVg5cE55SzYtdERVUUc3NG1QWT0iLCJoZWFkZXIiOnsia2lkIjoiMllvUlV3QnRRWmtNQmlWOFVnSlhaU0xEVkhUYmZGYXoyYXpUbm94TjVza2cifX1dfQ==","iv":"duk4voVcXbasFktC","ciphertext":"oxerJ2w=","tag":"uUge6ednm2dxRCZGjiF4dg=="}' ... test_x.py:18: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ wallet_handle = 3, message = 'Hello', recipient_verkeys = ['~94YEUsZ1f3huu5mWtMz6rg'] sender_verkey = None async def pack_message(wallet_handle: int, message: str, recipient_verkeys: list, sender_verkey: Optional[str]) -> bytes: """ Packs a message by encrypting the message and serializes it in a JWE-like format (Experimental) Note to use DID keys with this function you can call did.key_for_did to get key id (verkey) for specific DID. #Params command_handle: command handle to map callback to user context. wallet_handle: wallet handler (created by open_wallet) message: the message being sent as a string. If it's JSON formatted it should be converted to a string recipient_verkeys: a list of Strings which are recipient verkeys sender_verkey: the sender's verkey as a string. -> When None is passed in this parameter, anoncrypt mode is used returns an Agent Wire Message format as a byte array. See HIPE 0028 for detailed formats """ logger = logging.getLogger(__name__) logger.debug("pack_message: >>> wallet_handle: %r, message: %r, recipient_verkeys: %r, sender_verkey: %r", wallet_handle, message, recipient_verkeys, sender_verkey) def transform_cb(arr_ptr: POINTER(c_uint8), arr_len: c_uint32): return bytes(arr_ptr[:arr_len]), if not hasattr(pack_message, "cb"): logger.debug("pack_message: Creating callback") pack_message.cb = create_cb(CFUNCTYPE(None, c_int32, c_int32, POINTER(c_uint8), c_uint32), transform_cb) c_wallet_handle = c_int32(wallet_handle) msg_bytes = message.encode("utf-8") c_msg_len = c_uint32(len(msg_bytes)) c_recipient_verkeys = c_char_p(json.dumps(recipient_verkeys).encode('utf-8')) c_sender_vk = c_char_p(sender_verkey.encode('utf-8')) if sender_verkey is not None else None res = await do_call('indy_pack_message', c_wallet_handle, msg_bytes, c_msg_len, c_recipient_verkeys, c_sender_vk, > pack_message.cb) E indy.error.CommonInvalidStructure ../../indy/crypto.py:448: CommonInvalidStructure ``` Is there any way to convert a short-form verification key (from a NYM on the ledger) into a form acceptable to `crypto.pack_message()`?

lynn.bendixsen (Tue, 20 Oct 2020 13:39:33 GMT):
There's probably a function for it, but I couldn't find it. I am not 100% sure this will work, but its worth a try if you haven't found another solution yet. The manual way to get the long form of the verkey is to base58 decode both the DID and verkey(without the tilde), prepend the decoded DID to the decoded verkey and then re-encode them as base58.

sklump (Tue, 20 Oct 2020 14:25:51 GMT):
Excellent, thanks, will try it

andrew.whitehead (Tue, 20 Oct 2020 14:33:42 GMT):
Looks like the python wrapper has `did.abbreviate_verkey` but no equivalent to lengthen one

domwoe (Tue, 20 Oct 2020 14:46:20 GMT):
Thanks @sklump for forwarding this to the right place. As a workaround we updated the verkeys on the ledger with the full ones

sklump (Tue, 20 Oct 2020 14:48:02 GMT):
Once I prove the concept I will also adapt the wallet code to check for this case and do the right thing.

sklump (Tue, 20 Oct 2020 14:48:02 GMT):
Once I prove the concept I will also adapt the (aca-py) wallet code to check for this case and do the right thing.

sklump (Tue, 20 Oct 2020 14:48:02 GMT):
Once I prove the concept I will also adapt the (aca-py) wallet _(... actually, elsewhere?)_ code to check for this case and do the right thing.

sklump (Tue, 20 Oct 2020 14:48:02 GMT):
Once I prove the concept I will also adapt the (aca-py) wallet _(... actually, elsewhere? Needs DID?)_ code to check for this case and do the right thing.

kh_touati (Wed, 21 Oct 2020 13:19:46 GMT):
Has joined the channel.

kh_touati (Wed, 21 Oct 2020 13:19:52 GMT):
Hi, I am looking for the newest roadmap of the indy project (mainly Indy network and ledger). I did not find an updated one. Could you please share it here. Thanks in advance

Jonathancj (Wed, 21 Oct 2020 23:55:51 GMT):
Has joined the channel.

wenjing (Fri, 23 Oct 2020 17:58:13 GMT):
Has joined the channel.

akshay.sood (Sat, 24 Oct 2020 06:48:04 GMT):
@ianco If I add the `attr::::value`, it throws `IndyError: CommonInvalidStructure`. The following is the proof request I created: ```{"nonce":"916255320304414322850220","name":"proof_req_1","version":"0.1","requested_attributes":{"attr1_referent":{"name":"awardedYear","restrictions":{"$and":[{"cred_def_id":"Nag332fyHHpbRLptourecB:3:CL:21:Tag1"},{"schema_id":"Nag332fyHHpbRLptourecB:2:UNIVERSITY_SCHEMA:1.0"},{"attr::awardedYear::value":{"$gt":2010}}]}}},"requested_predicates":{"predicate1_referent":{"name":"awardedYear","p_type":">","p_value":2010}},"non_revoked":{"to":1603521824}}```

akshay.sood (Sat, 24 Oct 2020 06:51:50 GMT):
if I remove `attr::attribute::value`, it works fine then

ianco (Sat, 24 Oct 2020 16:27:21 GMT):
I think you can only use equality when checking encrypted tags (i.e. without the `~attr` prefix)

ianco (Sat, 24 Oct 2020 16:43:24 GMT):
For example I've used this format:

ianco (Sat, 24 Oct 2020 16:43:26 GMT):
```"requested_attributes":{ "biomarker_attrs":{"names":["name","concentration"], "restrictions":[{"schema_name":"Biomarker","schema_version":"0.2.0","attr::name::value":"Iron"}] } } ```

akshay.sood (Sat, 24 Oct 2020 18:00:22 GMT):
@ianco I tried to use `~attr::attr-name::value` but this also throw error ```{"nonce":"251341163257006328076752","name":"proof_req_1","version":"0.1","requested_attributes":{"attr1_referent":{"name":"awardedDegree","restrictions":{"$and":[{"cred_def_id":"Nag332fyHHpbRLptourecB:3:CL:21:Tag1"},{"schema_id":"Nag332fyHHpbRLptourecB:2:UNIVERSITY_SCHEMA:1.0"}]}},"attr2_referent":{"name":"awardedYear","restrictions":{"cred_def_id":"Nag332fyHHpbRLptourecB:3:CL:21:Tag1","schema_id":"Nag332fyHHpbRLptourecB:2:UNIVERSITY_SCHEMA:1.0","~attr::awardedYear::value":{"$gt":2017}}},"attr3_referent":{"name":"gpa","restrictions":{"$and":[{"cred_def_id":"Nag332fyHHpbRLptourecB:3:CL:21:Tag1"},{"schema_id":"Nag332fyHHpbRLptourecB:2:UNIVERSITY_SCHEMA:1.0"}]}}},"requested_predicates":{"predicate1_referent":{"name":"gpa","p_type":">","p_value":56,"restrictions":{"$and":[{"cred_def_id":"Nag332fyHHpbRLptourecB:3:CL:21:Tag1"},{"schema_id":"Nag332fyHHpbRLptourecB:2:UNIVERSITY_SCHEMA:1.0"}]}},"predicate2_referent":{"name":"awardedYear","p_type":">","p_value":2017}},"non_revoked":{"to":1603562345}}``` Error: `IndyError: CommonInvalidStructure`

akshay.sood (Sat, 24 Oct 2020 18:09:57 GMT):

tags_plaintext database

akshay.sood (Sat, 24 Oct 2020 18:09:58 GMT):
I tried to check the table `tags_plaintext` in my wallet db. It is empty. Attaching screenshot

esplinr (Mon, 26 Oct 2020 16:36:39 GMT):
We can help you with the release process.

esplinr (Mon, 26 Oct 2020 16:38:26 GMT):
The roadmap is a collaborative endeavor. The best way to follow what is currently in progress is to join the Indy Contributors call. https://wiki.hyperledger.org/display/indy/Indy+Contributors+Meeting Currently in flight: * Releasing Rich Schemas transaction types disabled with a feature flag. * Revocation 2 * Support for BBS+ signatures * Migrating LibIndy to Aries Shared libraries.

geonnave (Mon, 26 Oct 2020 20:47:34 GMT):
Has joined the channel.

geonnave (Mon, 26 Oct 2020 20:51:32 GMT):
Hi, I am having trouble using the function `ledger.build_get_ddo_request`. - I followed the write did and query verkey tutorial¹ using the python wrapper, all working - modified the code to create a ddo request `get_ddo_request = await ledger.build_get_ddo_request(submitter_did=client_did, target_did=steward_did)` - I submit the request with `get_ddo_response_json = await ledger.submit_request(pool_handle=pool_handle, request_json=get_ddo_request)` - then I get an error with reason: `client request invalid: InvalidClientRequest('validation error [ClientAuthRuleOperation]: missed fields - field, new_value, auth_type, constraint, auth_action. ',)` Any ideas? Thanks. ¹ https://github.com/hyperledger/indy-sdk/tree/master/docs/how-tos/write-did-and-query-verkey

mattatkiva (Tue, 27 Oct 2020 11:18:13 GMT):
hopefully an easy question: why does libindy docker images include node and java? is that because of the indy sdk wappers? (https://github.com/hyperledger/indy-sdk/blob/master/libindy/ci/ubuntu18.dockerfile)

mattatkiva (Tue, 27 Oct 2020 11:18:13 GMT):
hopefully an easy question: why does libindy docker images include ruby, node and java? is that because of the indy sdk wappers? (https://github.com/hyperledger/indy-sdk/blob/master/libindy/ci/ubuntu18.dockerfile)

ianco (Tue, 27 Oct 2020 13:24:39 GMT):
You can to configure a "tags policy" to tell indy what to tag. By default it tags all attributes as encrypted tags. I don't recall offhand how to configure a tags policy, but you can check the api (something to do with registering a credential I think)

troyronda (Wed, 28 Oct 2020 17:45:21 GMT):
Has left the channel.

moises_ej (Wed, 28 Oct 2020 20:25:51 GMT):
Has joined the channel.

ItsOmerShafiq (Thu, 29 Oct 2020 17:26:08 GMT):
Is there some work done with indy-sdk in area of offline verifiable credentials? I facing a use-case in which internet is available during issuance of VC but not available when verifying it.

ianco (Thu, 29 Oct 2020 17:33:17 GMT):
The verifier can (theoretically) cache all the information it needs to use to do the verification - cred defs, revocation registries etc

ianco (Thu, 29 Oct 2020 17:33:38 GMT):
It runs the risk that there are updates on the ledger that are not in cache though

sklump (Thu, 29 Oct 2020 18:18:32 GMT):
revocation accumulators need to come from the ledger though if the timestamp is beyond the cached value

ItsOmerShafiq (Thu, 29 Oct 2020 18:30:07 GMT):
what if we work with non-revocable creds?

sklump (Thu, 29 Oct 2020 18:39:57 GMT):
aca-py still checks the ledger for tamper evidence. If you're using indy-sdk proper, and you're confident you're truly dealing with irrevocable credentials only, the verifier won't need to check the ledger.

ItsOmerShafiq (Thu, 29 Oct 2020 19:54:08 GMT):
Thanks @sklump

ianco (Thu, 29 Oct 2020 22:53:15 GMT):
Hi folks We're having a call tomorrow (Fri Oct 30) at 6AM Pacific time to talk about the next Indy SDK release. On the agenda is discussion about the tasks, artifacts and deliverables (basically a KT from the Evernym team). If you're interested in attending the call details are: Join Zoom Meeting https://us02web.zoom.us/j/88652458257?pwd=Z2xmdFpQbVBFTThWTVlOYm9ieitwUT09 Meeting ID: 886 5245 8257 Passcode: 534767

jakubkoci (Fri, 30 Oct 2020 09:10:44 GMT):
Does the holder also communicate with the ledger or only the verifier?

ItsOmerShafiq (Fri, 30 Oct 2020 10:46:54 GMT):
It can but i am trying to avoid internet as much as i can and having a wallet locally provisioned can actually handle a lot.

WadeBarnes (Fri, 30 Oct 2020 14:47:03 GMT):
Reaching out to the MAC/iOS developer community for some assistance resolving a build error: - https://github.com/hyperledger/indy-sdk/issues/2270

tomislav (Fri, 30 Oct 2020 15:03:53 GMT):
I responded to the issue. Looks like there are two options - Use nightly toolchain - Remove 32bit targets from build pipeline

tomislav (Fri, 30 Oct 2020 15:03:53 GMT):
I responded to the issue. Looks like there are two options - Use nightly toolchain - Remove 32bit iOS targets from build pipeline

WadeBarnes (Fri, 30 Oct 2020 15:12:41 GMT):
Thanks

ianco (Fri, 30 Oct 2020 15:14:06 GMT):
Notes from this morning's Indy SDK discussion can be viewed here: https://docs.google.com/document/d/1QmSIfAqfYokHCOyLe65X7yAkLtGyUvPoyWK787L4r9E/edit?usp=sharing (Including a link to the recording of the meeting) Important dates are: Nov 10 - discuss the release at the Indy Contributors call Nov 17 - produce the 1.16.0 release candidate Nov 23 - promote 1.16.0 release candidate to "official" release What community members need to do: - Prior to Nov 10, ensure PR's are approved and merged (if required for the official release) - Nov 17-23, test the 1.16.0 release candidate and report issues Community support will be requested to support the iOS and Android wrappers, and potentially other release artifacts (to be discussed a the Nov 10 meeting)

swcurran (Sat, 31 Oct 2020 16:23:26 GMT):
@mccown @Alexi --- see note above about community support needed for the iOS and Android wrappers.

techragesh (Mon, 02 Nov 2020 10:28:18 GMT):
Has joined the channel.

smithbk (Wed, 04 Nov 2020 13:16:01 GMT):
Could someone review https://github.com/hyperledger/indy-sdk/pull/2273? I'd like to get this in for 1.16.0 release

geonnave (Wed, 04 Nov 2020 16:30:28 GMT):
Hi, I am trying to validate a very simple use case: I would like to register a DDo in the indy pool, and then get the DDo back from it, using the indy-sdk. I tried using the python wrapper and, although it works for DDo registration, it does not work for DDo request. Any help with that? As a side note, I am also expecting to be able to CRUD DDos as specified by the Sovrin DID Method: https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html#crud-operation-definitions.

geonnave (Wed, 04 Nov 2020 16:30:28 GMT):
Hi, I am trying to validate a very simple use case: I would like to register a DDo in the indy pool, and then get the DDo back from it, using the indy-sdk. I tried using the python wrapper and, although it works for DDo registration, it does not work for DDo request. Any help with that? As a side note, I am also expecting to be able to CRUD DDos as specified by the Sovrin DID Method¹, but I cannot find an endpoint to which I could send such CRUD operations. ¹ https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html#crud-operation-definitions

geonnave (Wed, 04 Nov 2020 16:30:28 GMT):
Hi, I am trying to execute a very simple use case: I would like to register a DDo in the indy pool, and then get the DDo back from it, using the indy-sdk. I tried using the python wrapper and, although it works for DDo registration, it does not work for DDo request. Any help with that? As a side note, I am also expecting to be able to CRUD DDos as specified by the Sovrin DID Method¹, but I cannot find an endpoint to which I could send such CRUD operations. ¹ https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html#crud-operation-definitions

geonnave (Wed, 04 Nov 2020 16:30:28 GMT):
Hi, I am trying to execute a very simple use case: I would like to register a DDo in the indy pool, and then get the DDo back from it, using the indy-sdk. I tried using the python wrapper and, although it works for DDo registration, it does not work for DDo request. Any help with that? As a side note, I was also expecting to be able to CRUD DDos as specified by the Sovrin DID Method¹, but I cannot find an endpoint to which I could send such CRUD operations. ¹ https://sovrin-foundation.github.io/sovrin/spec/did-method-spec-template.html#crud-operation-definitions

dgt1nsty (Thu, 05 Nov 2020 09:01:38 GMT):
Has joined the channel.

sj1 4 (Fri, 06 Nov 2020 02:48:34 GMT):
Has joined the channel.

askolesov (Mon, 09 Nov 2020 10:42:37 GMT):
Has joined the channel.

shasnain (Mon, 09 Nov 2020 19:19:31 GMT):
Has joined the channel.

shasnain (Mon, 09 Nov 2020 19:27:07 GMT):
Hey guys ! I have a quick question. Is indy-sdk supported for .Net Core 3.1 ? Also, are there any plans to update the indy-sdk Nuget packages from 1.11.1 to the latest version 1.15.0 ?

dgt1nsty (Tue, 10 Nov 2020 09:33:15 GMT):
Hi, I'm having problem on building Libindy binaries for Android. When I run build-android.sh script I get this error saying "python3: can't open file '/build/tools/make_standalone_toolchain.py': [Errno 2] No such file or directory" I couldn't find a way to get around it. Do you know how to solve it or can you direct me to resources that might be soution of problem cause I couldn't find one.

cmendoza (Thu, 12 Nov 2020 17:49:17 GMT):
Has joined the channel.

tomappleyard (Fri, 13 Nov 2020 10:57:23 GMT):
Has joined the channel.

tomappleyard (Fri, 13 Nov 2020 14:26:17 GMT):
Hey all, I'm having difficulty with compiling the nodejs samples, I keep getting the following upon running `npm i`: ``` indy.obj : error LNK2001: unresolved external symbol indy_append_request_endorser [C:\Users\Tom\workspace\indy-sdk\samples\nodejs\node_modules\indy-sdk\build\indynodejs.vcxproj] indy.obj : error LNK2001: unresolved external symbol indy_build_get_payment_sources_with_from_request [C:\Users\Tom\workspace\indy-sdk\samples\nodejs\node_modules\indy-sdk\build\indynodejs.vcxproj] indy.obj : error LNK2001: unresolved external symbol indy_parse_get_payment_sources_with_from_response [C:\Users\Tom\workspace\indy-sdk\samples\nodejs\node_modules\indy-sdk\build\indynodejs.vcxproj] indy.obj : error LNK2001: unresolved external symbol indy_build_auth_rules_request [C:\Users\Tom\workspace\indy-sdk\samples\nodejs\node_modules\indy-sdk\build\indynodejs.vcxproj] indy.obj : error LNK2001: unresolved external symbol indy_sign_with_address [C:\Users\Tom\workspace\indy-sdk\samples\nodejs\node_modules\indy-sdk\build\indynodejs.vcxproj] indy.obj : error LNK2001: unresolved external symbol indy_verify_with_address [C:\Users\Tom\workspace\indy-sdk\samples\nodejs\node_modules\indy-sdk\build\indynodejs.vcxproj] indy.obj : error LNK2001: unresolved external symbol indy_generate_nonce [C:\Users\Tom\workspace\indy-sdk\samples\nodejs\node_modules\indy-sdk\build\indynodejs.vcxproj] indy.obj : error LNK2001: unresolved external symbol indy_get_request_info [C:\Users\Tom\workspace\indy-sdk\samples\nodejs\node_modules\indy-sdk\build\indynodejs.vcxproj] C:\Users\Tom\workspace\indy-sdk\samples\nodejs\node_modules\indy-sdk\build\Release\indynodejs.node : fatal error LNK1120: 8 unresolved externals [C:\Users\Tom\workspace\indy-sdk\samples\nodejs\node_modules\indy-sdk\build\indynodejs.vcxproj] ``` Has anyone encountered this?

tomappleyard (Fri, 13 Nov 2020 14:26:54 GMT):
For reference, I've set all the env vars I've been asked to, including `LD_LIBRARY_PATH` which appears to be the one pertinent

tomappleyard (Fri, 13 Nov 2020 16:58:22 GMT):
Just so the answer is out here, I was using the wrong library version - if you issue ` git describe --tags` you'll see the tag of what you downloaded. Assuming you're on the master branch get the latest from here: https://repo.sovrin.org/windows/libindy/master/

ianco (Fri, 13 Nov 2020 19:05:46 GMT):
Reminder we are going to be creating a new indy sdk release next week, if there are any outstanding PR's please try to get them merged before Monday

rewaj7 (Sun, 15 Nov 2020 09:29:47 GMT):
Has joined the channel.

rewaj7 (Sun, 15 Nov 2020 09:34:21 GMT):
Hi all, I wanted to ask a quick question. Any ideas why my simple java code can call most functions perfectly, however causes a timeout error when trying to call the sign and submit request for a nym request to add trust anchor to a ledger?

tomappleyard (Mon, 16 Nov 2020 18:08:16 GMT):
Is anyone able to explain to me what the relationship is between a DID, signing key and a verification key? I see in the docs for the node API there's a `createAndStoreMyKey` method which takes a "seed" as proporty of it's `did` argument (https://github.com/hyperledger/indy-sdk/blob/master/wrappers/nodejs/README.md#did) It says "Seed that allows deterministic did creation (if not set random one will be created)." - am I therefore to assume that the seed is used to create the verkey, signkey and DID?

tomappleyard (Mon, 16 Nov 2020 18:14:29 GMT):
Also I assume that the Java and Python wrappers are _not_ in an experimental state? (by virtue of them not having anything in their repos indicating this?)

tomislav (Mon, 16 Nov 2020 19:25:28 GMT):
@tomappleyard Indy DID's are represented as Ed25519 keys. Each key has a public and private part, or verkey and signkey (just different names). The verkey returned by the result of that method is represented in base58. The DID is actually the first 21 bytes of the key, also in base58.

tomislav (Mon, 16 Nov 2020 19:25:28 GMT):
@tomappleyard DIDs in Indy are represented and derived from Ed25519 keys. Each key has a public and private part, or verkey and signkey (just different names). The verkey returned by the result of that method is represented in base58. The DID is actually the first 21 bytes of the key, also in base58.

lauravuo-techlab (Tue, 17 Nov 2020 05:38:04 GMT):
try updating indy?

lauravuo-techlab (Tue, 17 Nov 2020 05:38:04 GMT):
try updating indy lib?

tomappleyard (Tue, 17 Nov 2020 09:42:52 GMT):
I had the wrong version downloaded in the end - was downloading form stable instead of master (described more in the comment below)

tomappleyard (Tue, 17 Nov 2020 14:23:03 GMT):
So the verkey = public and signkey = private, they're just different terms for them?

tomappleyard (Tue, 17 Nov 2020 14:23:17 GMT):
And the DID is just the first 21 bytes of the verkey?

tomappleyard (Tue, 17 Nov 2020 14:26:09 GMT):
Has anyone else had issues running the python samples? I'm trying to get them working but it keeps saying it can't find indy.dll - I've set `LD_LIBRARY_PATH` to point to the lib directory of the unzipped contents of https://repo.sovrin.org/windows/libindy/master/1.15.0-1568/ but it's not picking it up

tomappleyard (Tue, 17 Nov 2020 15:53:32 GMT):
So there's an answer attached to this, you need to write the following in `main.py` before the function def: ``` import os os.add_dll_directory( r"") ```

tomappleyard (Tue, 17 Nov 2020 15:55:13 GMT):
Is anyone else getting this error: ``` File "C:\Users\Tom\workspace\indy-python-samples\src\getting_started.py", line 919, in lambda response: response['result']['data'] is not None) KeyError: 'result' ``` When they runt he python samples?

kdenhartog (Tue, 17 Nov 2020 21:54:07 GMT):
Yup that's correct.

kdenhartog (Tue, 17 Nov 2020 21:57:54 GMT):
> am I therefore to assume that the seed is used to create the verkey, signkey and DID? yes the seed is used to derive the private key (aka signing key) and the associate public key (aka verkey or verification key). >Do the signkey and verkey have a relationship - do you check one with the other? Yes, just like other forms of asymmetric cryptography these pairs are linked via a mathematical function such that if someone signs with the private key the public key can be used to verify the signature when using a signature algorithm that works with the appropriate key pair. In Indy's case we use Ed25519 Key pairs (pairs are the combination of a private/public key linked to each other) and the EdDSA signing algorithm.

tomappleyard (Wed, 18 Nov 2020 10:03:46 GMT):
ah brilliant - thank you!

tomappleyard (Wed, 18 Nov 2020 11:58:49 GMT):
Is there an API definition for the pytohn library as there is for the nodejs one here: https://github.com/hyperledger/indy-sdk/tree/master/wrappers/nodejs ?

tomappleyard (Wed, 18 Nov 2020 11:58:49 GMT):
Is there an API definition for the python library as there is for the nodejs one here: https://github.com/hyperledger/indy-sdk/tree/master/wrappers/nodejs ?

alokrajiv (Sat, 21 Nov 2020 07:30:58 GMT):
Has joined the channel.

ianco (Sat, 21 Nov 2020 15:55:18 GMT):
We're getting some errors with the 64 bit iOS build, is anyone able to help with this PR? https://github.com/hyperledger/indy-sdk/pull/2254

esplinr (Sat, 21 Nov 2020 19:35:47 GMT):
@mccown If we can't fix the build, we might have to drop iOS from the next Indy SDK release.

WadeBarnes (Tue, 24 Nov 2020 16:58:26 GMT):
@rjones, Is there a way to turn off the ability to manual set a DCO check to pass? We ran into an issue lately where a DCO check was manually set to pass without the actual sign-off which, as you know, caused issues down the road.

rjones (Tue, 24 Nov 2020 16:58:26 GMT):
Has joined the channel.

ianco (Tue, 24 Nov 2020 17:11:13 GMT):
https://github.com/hyperledger/indy-sdk/commit/f84e91f6ef618398f7a593499ea30e83b246ddb6

ianco (Tue, 24 Nov 2020 17:11:27 GMT):
^^^ the commit Wade is referring to

rjones (Tue, 24 Nov 2020 19:16:06 GMT):
I've changed the admin group to only have maintain access. I don't see another switch to disallow that specific thing.

rjones (Tue, 24 Nov 2020 19:18:34 GMT):
Another option would be to remove ianco from the admin group

WadeBarnes (Tue, 24 Nov 2020 21:43:46 GMT):
@rjones Ian wasn't the issue. Another user had the ability to mark the DCO check to pass manually without amending the commit to include the actual sign-off. That caused issues down the road when Ian was trying to create an RC, since the commit had not been truly signed-off.

rjones (Wed, 25 Nov 2020 00:38:01 GMT):
OK, sorry for misunderstanding. I looked in the logs, and I can't tell who approved the commit. AFAIK, the only people with that ability are admins. The audit logs tell me nothing.

sklump (Wed, 25 Nov 2020 12:08:09 GMT):
--- a/wrappers/python/tests/interation/test_interaction_several_credentials.py +++ b/wrappers/python/tests/interation/test_interaction_several_credentials.py @@ -507,6 +507,7 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand_4_creds( # Prover Gets RevocationRegistryDelta from Ledger # from: when last prover revocation state were created # to: to + ''' get_revoc_reg_delta_request = await ledger.build_get_revoc_reg_delta_request( prover_did, rev_reg_def_id, @@ -532,6 +533,7 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand_4_creds( timestamp, cred_rev_id[0 if proof_name == 'Alex' else 3] # Alex, then Olga ) + ''' # Prover creates revocation state from scratch # from: 0 or time of credential issuance @@ -564,7 +566,8 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand_4_creds( rev_states[proof_name] = { 'timestamp': timestamp, - 'value': rev_state_from_timestamp_to_now_json # rev_state_from_0_to_now_json must also work + 'value': rev_state_from_0_to_now_json + # 'value': rev_state_from_timestamp_to_now_json # rev_state_from_0_to_now_json must also work } revoc_states_json = json.dumps({rev_reg_id: {timestamp: json.loads(rev_states[proof_name]['value'])}}) I've come across something I can't explain but can reproduce. Can anyone investigate and tell me what goes wrong in `indy-sdk/wrappers/python/test/interation/tests_interaction_several_credentials.py` here? Step 1: apply the following delta: ``` --- a/wrappers/python/tests/interation/test_interaction_several_credentials.py +++ b/wrappers/python/tests/interation/test_interaction_several_credentials.py @@ -507,6 +507,7 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand_4_creds( # Prover Gets RevocationRegistryDelta from Ledger # from: when last prover revocation state were created # to: to + ''' get_revoc_reg_delta_request = await ledger.build_get_revoc_reg_delta_request( prover_did, rev_reg_def_id, @@ -532,6 +533,7 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand_4_creds( timestamp, cred_rev_id[0 if proof_name == 'Alex' else 3] # Alex, then Olga ) + ''' # Prover creates revocation state from scratch # from: 0 or time of credential issuance @@ -564,7 +566,8 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand_4_creds( rev_states[proof_name] = { 'timestamp': timestamp, - 'value': rev_state_from_timestamp_to_now_json # rev_state_from_0_to_now_json must also work + 'value': rev_state_from_0_to_now_json + # 'value': rev_state_from_timestamp_to_now_json # rev_state_from_0_to_now_json must also work } revoc_states_json = json.dumps({rev_reg_id: {timestamp: json.loads(rev_states[proof_name]['value'])}}) ``` and run the test. 1 - WEIRD: It fails to prove Olga's presentation after Alex is revoked. I.e., prover creates revocation state from scratch: no proof can verify from a credential in a revocation registry with any revocations. 2 - WEIRDER: Uncomment the triple-quotes at lines 510 and 536 and run it again: it passes! Updating the revocation state from prior states, then _creating revocation state from scratch and throwing the revocation updated state away_, fixes the problem. I'm totally at a loss here. Can anyone shed some light?

sklump (Wed, 25 Nov 2020 12:08:09 GMT):
I've come across something I can't explain but can reproduce. Can anyone investigate and tell me what goes wrong in `indy-sdk/wrappers/python/test/interation/tests_interaction_several_credentials.py` here? *PROCEDURE* - apply the following delta: ``` --- a/wrappers/python/tests/interation/test_interaction_several_credentials.py +++ b/wrappers/python/tests/interation/test_interaction_several_credentials.py @@ -507,6 +507,7 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand_4_creds( # Prover Gets RevocationRegistryDelta from Ledger # from: when last prover revocation state were created # to: to + ''' get_revoc_reg_delta_request = await ledger.build_get_revoc_reg_delta_request( prover_did, rev_reg_def_id, @@ -532,6 +533,7 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand_4_creds( timestamp, cred_rev_id[0 if proof_name == 'Alex' else 3] # Alex, then Olga ) + ''' # Prover creates revocation state from scratch # from: 0 or time of credential issuance @@ -564,7 +566,8 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand_4_creds( rev_states[proof_name] = { 'timestamp': timestamp, - 'value': rev_state_from_timestamp_to_now_json # rev_state_from_0_to_now_json must also work + 'value': rev_state_from_0_to_now_json + # 'value': rev_state_from_timestamp_to_now_json # rev_state_from_0_to_now_json must also work } revoc_states_json = json.dumps({rev_reg_id: {timestamp: json.loads(rev_states[proof_name]['value'])}}) ``` and run the test. *1 - WEIRD:* It fails to prove Olga's presentation after Alex is revoked. I.e., prover creates revocation state from scratch: no proof can verify from a credential in a revocation registry with any revocations. *2 - WEIRDER:* Uncomment the triple-quotes at lines 510 and 536 and run it again: it passes! Updating the revocation state from prior states, then _creating revocation state from scratch and throwing the revocation updated state away_, fixes the problem. I'm totally at a loss here. Can anyone shed some light?

sklump (Wed, 25 Nov 2020 12:08:09 GMT):
I've come across something I can't explain but can reproduce. Can anyone investigate and tell me what goes wrong in `indy-sdk/wrappers/python/test/interation/tests_interaction_several_credentials.py` here? *PROCEDURE* - apply the following delta: ``` --- a/wrappers/python/tests/interation/test_interaction_several_credentials.py +++ b/wrappers/python/tests/interation/test_interaction_several_credentials.py @@ -507,6 +507,7 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand_4_creds( # Prover Gets RevocationRegistryDelta from Ledger # from: when last prover revocation state were created # to: to + ''' get_revoc_reg_delta_request = await ledger.build_get_revoc_reg_delta_request( prover_did, rev_reg_def_id, @@ -532,6 +533,7 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand_4_creds( timestamp, cred_rev_id[0 if proof_name == 'Alex' else 3] # Alex, then Olga ) + ''' # Prover creates revocation state from scratch # from: 0 or time of credential issuance @@ -564,7 +566,8 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand_4_creds( rev_states[proof_name] = { 'timestamp': timestamp, - 'value': rev_state_from_timestamp_to_now_json # rev_state_from_0_to_now_json must also work + 'value': rev_state_from_0_to_now_json + # 'value': rev_state_from_timestamp_to_now_json # rev_state_from_0_to_now_json must also work } revoc_states_json = json.dumps({rev_reg_id: {timestamp: json.loads(rev_states[proof_name]['value'])}}) ``` and run the test. *1 - WEIRD:* It fails to prove Olga's presentation after Alex is revoked. I.e., prover creates revocation state from scratch: no proof can verify from a credential in a revocation registry with any revocations. *2 - WEIRDER:* Uncomment the triple-quotes at lines 510 and 536 and run it again: it passes! Updating the revocation state *r* from prior states, then _creating revocation state *s* from scratch and throwing the updated revocation state *r* away_, fixes the problem. I'm totally at a loss here. Can anyone shed some light?

sklump (Wed, 25 Nov 2020 12:08:09 GMT):
I've come across something I can't explain but can reproduce. Can anyone investigate and tell me what goes wrong in `indy-sdk/wrappers/python/test/interation/tests_interaction_several_credentials.py` here? *PROCEDURE* - apply the following delta: ``` --- a/wrappers/python/tests/interation/test_interaction_several_credentials.py +++ b/wrappers/python/tests/interation/test_interaction_several_credentials.py @@ -507,6 +507,7 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand_4_creds( # Prover Gets RevocationRegistryDelta from Ledger # from: when last prover revocation state were created # to: to + ''' get_revoc_reg_delta_request = await ledger.build_get_revoc_reg_delta_request( prover_did, rev_reg_def_id, @@ -532,6 +533,7 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand_4_creds( timestamp, cred_rev_id[0 if proof_name == 'Alex' else 3] # Alex, then Olga ) + ''' # Prover creates revocation state from scratch # from: 0 or time of credential issuance @@ -564,7 +566,8 @@ async def test_anoncreds_revocation_interaction_test_issuance_by_demand_4_creds( rev_states[proof_name] = { 'timestamp': timestamp, - 'value': rev_state_from_timestamp_to_now_json # rev_state_from_0_to_now_json must also work + 'value': rev_state_from_0_to_now_json + # 'value': rev_state_from_timestamp_to_now_json # rev_state_from_0_to_now_json must also work } revoc_states_json = json.dumps({rev_reg_id: {timestamp: json.loads(rev_states[proof_name]['value'])}}) ``` and run the test. *1 - WEIRD:* It fails to prove Olga's presentation after Alex is revoked. I.e., prover creates revocation state from scratch: no proof can verify from a credential in a revocation registry having revoked (distinct) credentials. *2 - WEIRDER:* Uncomment the triple-quotes at lines 510 and 536 and run it again: it passes! Updating the revocation state *r* from prior states, then _creating revocation state *s* from scratch and throwing the updated revocation state *r* away and using *s*_, fixes the problem. I'm totally at a loss here. Can anyone shed some light?

WadeBarnes (Wed, 25 Nov 2020 16:16:51 GMT):
Yeah, I did a little more digging. It does not look like you can turn this off other than to remove write access;

WadeBarnes (Wed, 25 Nov 2020 16:16:53 GMT):

Clipboard - November 25, 2020 8:16 AM

WadeBarnes (Wed, 25 Nov 2020 16:17:12 GMT):
We'll just have to be on the lookout.

rjones (Wed, 25 Nov 2020 17:29:30 GMT):
OK. Do you want me to switch `admin` access back to where it was?

WadeBarnes (Wed, 25 Nov 2020 17:29:58 GMT):
PLease

WadeBarnes (Wed, 25 Nov 2020 17:29:58 GMT):
Please

rjones (Wed, 25 Nov 2020 17:31:23 GMT):
done

WadeBarnes (Wed, 25 Nov 2020 17:35:32 GMT):
Thanks

regy14 (Fri, 27 Nov 2020 13:02:44 GMT):
Has joined the channel.

blidd (Fri, 27 Nov 2020 18:13:00 GMT):
Has joined the channel.

blidd (Fri, 27 Nov 2020 18:13:00 GMT):
hi all, I'm having some trouble using python indy-sdk "key_for_did" function call. After storing a DID and verkey pair on the von-network indy ledger with ledger.sign_and_submit_request, I am able to retrieve the verkey once using key_for_did. However on subsequent calls of key_for_did, I encounter a WalletItemAlreadyExists error. Not quite sure what I am missing here

blidd (Fri, 27 Nov 2020 18:13:56 GMT):
`nym_request = await indy.ledger.build_nym_request( did, signing_did, signing_vk, None, None ) await indy.ledger.sign_and_submit_request( pool_handle, wallet.handle, did, nym_request )`

blidd (Fri, 27 Nov 2020 18:15:06 GMT):
`signing_vk = await indy.did.key_for_did( pool_handle, wallet.handle, signing_did, )`

TimoGlastra (Sun, 29 Nov 2020 13:32:06 GMT):
Can I get access to the indy-sdk jenkins? The CI for my PR failed (https://github.com/hyperledger/indy-sdk/pull/2307) but I don't have access to see the logs

WadeBarnes (Sun, 29 Nov 2020 13:58:01 GMT):
DMed info

sergey.minaev (Mon, 30 Nov 2020 10:47:38 GMT):
There was a decision to force push to master branch to fix broken DCO there. Please see details in the 2308 PR The PR with the fix is https://github.com/hyperledger/indy-sdk/pull/2313 and it has been "merged" to master. The old history is available in the temporary branch old_master https://github.com/hyperledger/indy-sdk/tree/old_master If you have in-progress PR merged with master recently you probably will have to force-push your branch. I would suggest you do an interactive rebase of your branch at the top of the new master and drop all commits which are not related to your work

smithbk (Mon, 30 Nov 2020 13:49:19 GMT):
I'm seeing the following break in our CI but still fails. Is this what you're referring to above? ```Step 14/22 : RUN apt-get update -y && apt-get install -y python3-pyzmq=${python3_pyzmq_ver} indy-plenum=${indy_plenum_ver} indy-node=${indy_node_ver} python3-indy-crypto=${python3_indy_crypto_ver} libindy-crypto=${indy_crypto_ver} vim ---> Running in 3de94dc65e52 Hit:1 http://security.ubuntu.com/ubuntu xenial-security InRelease Hit:2 http://archive.ubuntu.com/ubuntu xenial InRelease Hit:3 http://archive.ubuntu.com/ubuntu xenial-updates InRelease Hit:4 http://archive.ubuntu.com/ubuntu xenial-backports InRelease Get:5 https://repo.sovrin.org/deb xenial InRelease [28.4 kB] Get:6 https://repo.sovrin.org/deb xenial/master amd64 Packages [345 kB] Fetched 373 kB in 0s (390 kB/s) Reading package lists... Reading package lists... Building dependency tree... Reading state information... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: indy-plenum : Depends: python3-orderedset (= 2.0) but 2.0.3 is to be installed Depends: python3-psutil (= 5.4.3) but 5.6.6 is to be installed Depends: python3-psutil (= 5.4.3) but 5.6.6 is to be installed Depends: python3-pympler (= 0.5) but 0.8 is to be installed```

kaijuneer (Mon, 30 Nov 2020 17:46:48 GMT):
Has joined the channel.

kaijuneer (Mon, 30 Nov 2020 18:06:41 GMT):
I'm having similar issues as above when running `docker-compose up` in the getting-started folder. Also, what does indy_pool actually mean? Sorry if it's a dumb question as I am a newbie to Hyperledger

lynn.bendixsen (Mon, 30 Nov 2020 20:31:44 GMT):
indy_pool refers to all of the servers in a network, or in other words, the "pool" of servers available to contribute to consensus. Sometimes in documentation there is a pool handle that is referred to as a "pool" or the "indy_pool" so the pool itself is the group of servers or "nodes" and the "pool handle" is the link to be able to communicate with the pool from the application you are running.

kaijuneer (Tue, 01 Dec 2020 10:26:12 GMT):
Thanks for the explanation!

rocky_2020 (Tue, 01 Dec 2020 13:35:03 GMT):
Has joined the channel.

rocky_2020 (Tue, 01 Dec 2020 14:03:44 GMT):
Hi, Can anyone give me the latest link to setup Indy Network on Linux machine? I found one link given below in this channel but it is very old 2018 year https://medium.com/@smaldeniya/setup-hyperledger-indy-pool-in-local-linux-environment-using-docker-304d13eb86dc

swcurran (Tue, 01 Dec 2020 14:52:29 GMT):
Suggest you take a look at https://github.com/bcgov/von-network -- it's a pretty easy way to get a network running quickly.

cmendoza (Tue, 01 Dec 2020 23:49:11 GMT):
hello, does anyone know if the maven repo that sovrin was hosting got moved or if it's removed permanently? `https://repo.sovrin.org/repository/maven-public`

dishan (Wed, 02 Dec 2020 01:16:29 GMT):
Has joined the channel.

omzweikabo (Wed, 02 Dec 2020 08:59:14 GMT):
Has joined the channel.

morticianmili (Wed, 02 Dec 2020 08:59:55 GMT):
Has joined the channel.

omzweikabo (Wed, 02 Dec 2020 09:16:31 GMT):
I have the same issue, it is somehow related to ci/indy-pool.dockerfile. I guess that the versions requested in line 28 result in this error. I have spend many hours trying to fix this, but i couldn't. If you comment the specific versions out, you will get pass this error. But later there will come up another one, as you loaded the wrong versions.

sergey.minaev (Wed, 02 Dec 2020 11:04:26 GMT):
I think, you can try to pin all versions mentioned in the error while the installation command and it may help something like ```apt-get install -y python3-pyzmq=${python3_pyzmq_ver} indy-plenum=${indy_plenum_ver} indy-node=${indy_node_ver} python3-indy-crypto=${python3_indy_crypto_ver} libindy-crypto=${indy_crypto_ver} vim python3-orderedset=2.0 python3-psutil=5.4.3 python3-pympler=0.5 ```

sergey.minaev (Wed, 02 Dec 2020 11:04:26 GMT):
I think, you can try to pin all versions mentioned in the error while the installation command and it may help. something like ```apt-get install -y python3-pyzmq=${python3_pyzmq_ver} indy-plenum=${indy_plenum_ver} indy-node=${indy_node_ver} python3-indy-crypto=${python3_indy_crypto_ver} libindy-crypto=${indy_crypto_ver} vim python3-orderedset=2.0 python3-psutil=5.4.3 python3-pympler=0.5 ```

omzweikabo (Wed, 02 Dec 2020 13:25:53 GMT):
@sergey.minaev , thanks a lot it worked perfectly, exactly like you recommended! So, I changed line 34 and following to this: `RUN apt-get update -y && apt-get install -y \ python3-pyzmq=${python3_pyzmq_ver} \ indy-plenum=${indy_plenum_ver} \ indy-node=${indy_node_ver} \ python3-indy-crypto=${python3_indy_crypto_ver} \ libindy-crypto=${indy_crypto_ver} \ vim \ python3-orderedset=2.0 \ python3-psutil=5.4.3 \ python3-pympler=0.5` After that i still needed to change the getting-started dockerfile as addressed in this issue (last comment): https://github.com/hyperledger/indy-sdk/issues/2237

smithbk (Wed, 02 Dec 2020 13:33:26 GMT):
Thanks ... @omzweikabo Did you or were you going to check in a fix to indy-sdk?

WadeBarnes (Wed, 02 Dec 2020 14:31:38 GMT):
This was fixed. Please try again.

mccown (Thu, 03 Dec 2020 04:38:45 GMT):
The Identity Implementer's WG is meeting tomorrow morning (Dec 3rd @ 9am MT / 4pm UTC). In this call, we will review updates from several industry WGs, which you may have missed this week. For our presentation, Nicole Khor (Anonyome Labs; University of Queensland) will present a part of her research, which includes integrating SSI technologies with existing browser-based authentication protocols (e.g., WebAuthn). She will talk about browser integration, protocol requirements, etc. Here are links to the Wiki and Zoom meeting: Wiki: https://wiki.hyperledger.org/display/IWG/2020-12-3+Identity+Implementers+WG+Call Zoom: https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

mccown (Thu, 03 Dec 2020 16:04:39 GMT):
The Identity Implementer's call is starting https://wiki.hyperledger.org/display/IWG/2020-12-3+Identity+Implementers+WG+Call

cmendoza (Mon, 07 Dec 2020 02:46:00 GMT):
That worked. Thanks, @WadeBarnes.

rocky_2020 (Mon, 07 Dec 2020 16:49:09 GMT):

Clipboard - December 7, 2020 10:19 PM

rocky_2020 (Mon, 07 Dec 2020 16:49:09 GMT):
Pool "testpool" has not been connected. Where I am missing. Is it the issue with genesis file. I changed the IP address to my localhost in genesis file, but no luck.
Clipboard - December 7, 2020 10:19 PM

rocky_2020 (Mon, 07 Dec 2020 16:49:13 GMT):
Pool "testpool" has not been connected. Where I am missing. Is it the issue with genesis file. I changed the IP address to my localhost in genesis file, but no luck.

chakshujain (Tue, 08 Dec 2020 05:30:42 GMT):
Has joined the channel.

lynn.bendixsen (Tue, 08 Dec 2020 16:17:11 GMT):
That error is regularly due to a networking issue. Either all IP's or all ports are unreachable for testpool. Try `nc -vz ` to see if they are open on the machine from which you are running the indy-cli.

RicardoPeixoto (Tue, 08 Dec 2020 22:11:49 GMT):
Hi, is there a way to see the credential object in its integrity with the "signature" and the "signature_correctness_proof" after it has been stored?

PascalHeitz (Wed, 09 Dec 2020 10:15:28 GMT):
Has joined the channel.

rocky_2020 (Thu, 10 Dec 2020 15:22:42 GMT):

Clipboard - December 10, 2020 8:52 PM

rocky_2020 (Thu, 10 Dec 2020 15:22:42 GMT):
indy-pool.docker files in this location is not working now. https://github.com/hyperledger/indy-sdk/blob/master/ci/indy-pool.dockerfile Below are few errors.
Clipboard - December 10, 2020 8:52 PM

rocky_2020 (Thu, 10 Dec 2020 15:22:49 GMT):
indy-pool.docker files in this location is not working now. Below are few errors.

rocky_2020 (Thu, 10 Dec 2020 15:23:19 GMT):

Clipboard - December 10, 2020 8:53 PM

rocky_2020 (Thu, 10 Dec 2020 15:23:19 GMT):
indy-pool.docker files in this location is not working now. Below are few errors.
Clipboard - December 10, 2020 8:53 PM

rocky_2020 (Thu, 10 Dec 2020 15:23:19 GMT):
indy-pool.docker files in this location is not working now. https://github.com/hyperledger/indy-sdk/blob/master/ci/indy-pool.dockerfile Below are few errors.
Clipboard - December 10, 2020 8:53 PM

rocky_2020 (Thu, 10 Dec 2020 15:23:19 GMT):

Message Attachments

rocky_2020 (Thu, 10 Dec 2020 15:24:09 GMT):
indy-pool.docker files in this location is not working now. Below are few errors.

rocky_2020 (Thu, 10 Dec 2020 15:26:21 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/ci/indy-pool.dockerfile

sklump (Thu, 10 Dec 2020 15:31:21 GMT):
Has left the channel.

wykim (Wed, 16 Dec 2020 07:27:13 GMT):
Has joined the channel.

wykim (Wed, 16 Dec 2020 07:27:13 GMT):
In the sample code, there is a issuer and a prover together. I separated the prover(mobile App) from the issuer(server). verifier valid result is false. (Anoncreds.verifierVerifyProof) Please help me.

mattatkiva (Wed, 16 Dec 2020 17:17:54 GMT):
Im getting some compile errors around libc when including indy and indy-sys crate packages in my rust project (happy to paste them here if needed). I currently imported 1.15.0 for indy and indy-sys. I see there is a 1.16.0RC....my question is when will this become offical?

mattatkiva (Thu, 17 Dec 2020 19:49:28 GMT):
More info -> Are there any plans to update the indy stack (rust wrapper specifically but maybe indy-sdk as well) with the latest libc version? The current version indy uses a libc crate that is over a year old. I am working on a rust-aries agent. once I pulled in indy and indy-sys crates I got errors about libc. I really do not want to revert other work to make indy compile with mattraffel@kiva-mattr:~/src/mine/aries-agent/shared$ cargo build Updating crates.io index error: failed to select a version for `libc`. ... required by package `chrono v0.4.19` ... which is depended on by `aries-shared v0.1.0 (/Users/mattraffel/src/mine/aries-agent/shared)` versions that meet the requirements `^0.2.69` are: 0.2.79, 0.2.81, 0.2.80, 0.2.78, 0.2.77, 0.2.76, 0.2.75, 0.2.74, 0.2.73, 0.2.72, 0.2.71, 0.2.70, 0.2.69 all possible versions conflict with previously selected packages. previously selected package `libc v0.2.66` ... which is depended on by `indy v1.15.0` ... which is depended on by `aries-shared v0.1.0 (/Users/mattraffel/src/mine/aries-agent/shared)` failed to select a version for `libc` which could resolve this conflict

esplinr (Thu, 17 Dec 2020 21:58:13 GMT):
We won't be able to update libc before the release that we have been working on, and I'm not aware of someone currently working on that problem.

esplinr (Thu, 17 Dec 2020 21:58:13 GMT):
@WadeBarnes, @ianco, and @sergey.minaev are in the middle of producing a release. I don't think we will be able to update libc before that release unless you have a PR in for it very quickly.

mattatkiva (Thu, 17 Dec 2020 22:16:33 GMT):
when will the next release be made?

mattatkiva (Thu, 17 Dec 2020 22:54:17 GMT):
btw, I bumped the version up to 0.2.29 (for indy wrapper and indy-sys wrapper projects only) and everything compiles. If I made a PR how quickly do you need it to get into this next release?

ianco (Thu, 17 Dec 2020 22:59:46 GMT):
@mattatkiva we have a release ready to go in the `RC` branch right now we're just having some build issues with Jenkins. If you want to open a PR into the RC branch we can take a look at it

mattatkiva (Thu, 17 Dec 2020 23:10:34 GMT):
done. https://github.com/hyperledger/indy-sdk/pull/2331. I am having a problems running cargo test. For sake of time, does someone have a moment to test?

ianco (Fri, 18 Dec 2020 16:43:46 GMT):
The build is failing on your PR: https://github.com/hyperledger/indy-sdk/pull/2331

mattatkiva (Fri, 18 Dec 2020 16:57:07 GMT):
I dont have access to the build server. I cannot see what is the problem

ianco (Fri, 18 Dec 2020 16:57:54 GMT):
```+ cargo clippy --manifest-path vcx/libvcx/Cargo.toml -- -W clippy::style -W clippy::correctness -W clippy::complexity -W clippy::perf Updating crates.io index error: failed to select a version for `libc`. ... required by package `indy v1.16.0 (/home/jenkins/workspace/indy-sdk_indy-sdk-ci_PR-2331/wrappers/rust)` ... which is depended on by `libvcx v0.9.0 (/home/jenkins/workspace/indy-sdk_indy-sdk-ci_PR-2331/vcx/libvcx)` versions that meet the requirements `=0.2.69` are: 0.2.69 all possible versions conflict with previously selected packages. previously selected package `libc v0.2.66` ... which is depended on by `libvcx v0.9.0 (/home/jenkins/workspace/indy-sdk_indy-sdk-ci_PR-2331/vcx/libvcx)` failed to select a version for `libc` which could resolve this conflict script returned exit code 101 ```

mattatkiva (Fri, 18 Dec 2020 16:58:36 GMT):
ok thx. I guess its not as simple as I would like. I will delete the PR and go from there

steuyve (Mon, 21 Dec 2020 09:31:33 GMT):
Has joined the channel.

steuyve (Mon, 21 Dec 2020 09:31:34 GMT):
Hi, I've run into the same issue with the fixes given above resolving the issue for me. Just wanted to ask, will these fixes be merged or checked into indy-sdk?

WadeBarnes (Mon, 21 Dec 2020 13:49:35 GMT):
There are 2 resolutions to this issue being proposed. One in [PR-2328](https://github.com/hyperledger/indy-sdk/pull/2328) and the other in [PR-2330](https://github.com/hyperledger/indy-sdk/pull/2330).

newdev42 (Sat, 26 Dec 2020 15:06:24 GMT):
Has joined the channel.

newdev42 (Sat, 26 Dec 2020 15:18:43 GMT):
hi there! I'm trying to run the controllers/agents demo here: https://github.com/hyperledger/aries-cloudagent-python/tree/master/demo#run-the-alice-and-faber-controllersagents -- and when I run the `runners.faber`, I receive the following error: `ERROR:indy.libindy:_load_cdll: Can't load libindy: dlopen(libindy.dylib, 6): image not found` -- I followed the instructions that I found here to install indy-sdk lib: https://usermanual.wiki/Document/indyinstructionsroughdraft.934871540.pdf -- but I still receive the same error...

newdev42 (Sat, 26 Dec 2020 15:19:34 GMT):
I suspect the final step `cargo build` does not add the libindy.dylib into macos include folders... it only exists at the git cloned `indy-sdk/libindy/target/debug`...

newdev42 (Sat, 26 Dec 2020 15:28:53 GMT):
(yeah, actually doing `sudo ln -s /Users/dev01/Workspace/dev01/ssi/indy-sdk/libindy/target/debug/libindy.dylib /usr/local/lib/libindy.dylib` fixed the issue -- Idk how fragile my sdk installation is though)

EtricKombat (Mon, 28 Dec 2020 11:01:45 GMT):
Has joined the channel.

steuyve (Tue, 29 Dec 2020 01:37:30 GMT):
Great, thanks

pankajn (Sat, 02 Jan 2021 18:32:13 GMT):
Has joined the channel.

pankajn (Sat, 02 Jan 2021 18:32:13 GMT):
Hello and a wish everyone very happy new year :) I am trying to query a saved schema from the ledger via the Java wrapper. I am using 1.15.0 version. The buildGetSchemaRequest method succeeds and when I call the parseGetSchemaResponse I get the following error [Thread-0] DEBUG org.hyperledger.indy.sdk.LibIndy.native.ledger_command_executor - src/commands/ledger.rs:384 | ParseGetSchemaResponse command received [Thread-0] DEBUG org.hyperledger.indy.sdk.LibIndy.native.indy.commands.ledger - src/commands/ledger.rs:808 | parse_get_schema_response >>> get_schema_response: "{\"reqId\":1609608508230043543,\"identifier\":\"HFDD8BsSkNAPV16tNvcAnS\",\"operation\":{\"type\":\"107\",\"dest\":\"HFDD8BsSkNAPV16tNvcAnS\",\"data\":{\"name\":\"aadharTest\",\"version\":\"1.0\"}},\"protocolVersion\":2}" [Thread-0] INFO org.hyperledger.indy.sdk.LibIndy.native.indy.services.ledger - src/services/ledger/mod.rs:458 | parse_response() => Err(IndyError { inner: Error("missing field `op`", line: 0, column: 0) Structure doesn't correspond to type. Most probably not found Item not found on ledger })

pankajn (Sat, 02 Jan 2021 18:32:13 GMT):
Hello and a wish everyone very happy new year :) I am trying to query a saved schema from the ledger via the Java wrapper. I am using 1.15.0 version. The buildGetSchemaRequest method succeeds and when I call the parseGetSchemaResponse I get the following error Err(IndyError { inner: Error("missing field `op`", line: 0, column: 0) Structure doesn't correspond to type. Most probably not found Item not found on ledger })[Thread-0] DEBUG org.hyperledger.indy.sdk.LibIndy.native.ledger_command_executor - src/commands/ledger.rs:384 | ParseGetSchemaResponse command received [Thread-0] DEBUG org.hyperledger.indy.sdk.LibIndy.native.indy.commands.ledger - src/commands/ledger.rs:808 | parse_get_schema_response >>> get_schema_response: "{\"reqId\":1609608508230043543,\"identifier\":\"HFDD8BsSkNAPV16tNvcAnS\",\"operation\":{\"type\":\"107\",\"dest\":\"HFDD8BsSkNAPV16tNvcAnS\",\"data\":{\"name\":\"aadharTest\",\"version\":\"1.0\"}},\"protocolVersion\":2}" [Thread-0] INFO org.hyperledger.indy.sdk.LibIndy.native.indy.services.ledger - src/services/ledger/mod.rs:458 | parse_response() => Err(IndyError { inner: Error("missing field `op`", line: 0, column: 0) Structure doesn't correspond to type. Most probably not found Item not found on ledger })

pankajn (Sat, 02 Jan 2021 18:32:13 GMT):
Hello and a wish everyone very happy new year :) I am trying to query a saved schema from the ledger via the Java wrapper. I am using 1.15.0 version. The buildGetSchemaRequest method succeeds and when I call the parseGetSchemaResponse I get the following error Err(IndyError { inner: Error("missing field `op`", line: 0, column: 0) Structure doesn't correspond to type. Most probably not found Item not found on ledger })-------[Thread-0] DEBUG org.hyperledger.indy.sdk.LibIndy.native.ledger_command_executor - src/commands/ledger.rs:384 | ParseGetSchemaResponse command received [Thread-0] DEBUG org.hyperledger.indy.sdk.LibIndy.native.indy.commands.ledger - src/commands/ledger.rs:808 | parse_get_schema_response >>> get_schema_response: "{\"reqId\":1609608508230043543,\"identifier\":\"HFDD8BsSkNAPV16tNvcAnS\",\"operation\":{\"type\":\"107\",\"dest\":\"HFDD8BsSkNAPV16tNvcAnS\",\"data\":{\"name\":\"Test\",\"version\":\"1.0\"}},\"protocolVersion\":2}" [Thread-0] INFO org.hyperledger.indy.sdk.LibIndy.native.indy.services.ledger - src/services/ledger/mod.rs:458 | parse_response() => Err(IndyError { inner: Error("missing field `op`", line: 0, column: 0) Structure doesn't correspond to type. Most probably not found Item not found on ledger })

pankajn (Sat, 02 Jan 2021 18:32:13 GMT):
Hello and a wish everyone very happy new year :) I am trying to query a saved schema from the ledger via the Java wrapper. I am using 1.15.0 version. The buildGetSchemaRequest method succeeds and when I call the parseGetSchemaResponse I get the following error, looking for some pointers on where to continue my investigation as when I look at the rust code it seems to be looking for the "op" as you can see below it is not in the JSON, is this a version mismatch between the sdk and the indy-node... or something else? Err(IndyError { inner: Error("missing field `op`", line: 0, column: 0) Structure doesn't correspond to type. Most probably not found Item not found on ledger })-------[Thread-0] DEBUG org.hyperledger.indy.sdk.LibIndy.native.ledger_command_executor - src/commands/ledger.rs:384 | ParseGetSchemaResponse command received [Thread-0] DEBUG org.hyperledger.indy.sdk.LibIndy.native.indy.commands.ledger - src/commands/ledger.rs:808 | parse_get_schema_response >>> get_schema_response: "{\"reqId\":1609608508230043543,\"identifier\":\"HFDD8BsSkNAPV16tNvcAnS\",\"operation\":{\"type\":\"107\",\"dest\":\"HFDD8BsSkNAPV16tNvcAnS\",\"data\":{\"name\":\"Test\",\"version\":\"1.0\"}},\"protocolVersion\":2}" [Thread-0] INFO org.hyperledger.indy.sdk.LibIndy.native.indy.services.ledger - src/services/ledger/mod.rs:458 | parse_response() => Err(IndyError { inner: Error("missing field `op`", line: 0, column: 0) Structure doesn't correspond to type. Most probably not found Item not found on ledger })

pankajn (Sat, 02 Jan 2021 18:32:13 GMT):
Hello and a wish everyone a very happy new year :) I am trying to query a saved schema from the ledger via the Java wrapper. I am using 1.15.0 version. The buildGetSchemaRequest method succeeds and when I call the parseGetSchemaResponse I get the following error, looking for some pointers on where to continue my investigation as when I look at the rust code it seems to be looking for the "op" as you can see below it is not in the JSON, is this a version mismatch between the sdk and the indy-node... or something else? Err(IndyError { inner: Error("missing field `op`", line: 0, column: 0) Structure doesn't correspond to type. Most probably not found Item not found on ledger })-------[Thread-0] DEBUG org.hyperledger.indy.sdk.LibIndy.native.ledger_command_executor - src/commands/ledger.rs:384 | ParseGetSchemaResponse command received [Thread-0] DEBUG org.hyperledger.indy.sdk.LibIndy.native.indy.commands.ledger - src/commands/ledger.rs:808 | parse_get_schema_response >>> get_schema_response: "{\"reqId\":1609608508230043543,\"identifier\":\"HFDD8BsSkNAPV16tNvcAnS\",\"operation\":{\"type\":\"107\",\"dest\":\"HFDD8BsSkNAPV16tNvcAnS\",\"data\":{\"name\":\"Test\",\"version\":\"1.0\"}},\"protocolVersion\":2}" [Thread-0] INFO org.hyperledger.indy.sdk.LibIndy.native.indy.services.ledger - src/services/ledger/mod.rs:458 | parse_response() => Err(IndyError { inner: Error("missing field `op`", line: 0, column: 0) Structure doesn't correspond to type. Most probably not found Item not found on ledger })

gagepoulson (Wed, 06 Jan 2021 15:35:44 GMT):
Has joined the channel.

ianco (Mon, 11 Jan 2021 18:49:39 GMT):
Hi Indy folks, just want to remind everyone we have a release candidate for indy sdk (version is `1.16-rc-170`) available for testing. Release artifacts are all on https://repo.sovrin.org/ Please try to test by Tuesday Jan 19 so we can make a decision on promoting to an official `1.16` release

mccown (Wed, 13 Jan 2021 21:36:35 GMT):
The Identity Implementer's WG is meeting tomorrow morning (Jan 14th @ 9am MT / 4pm UTC). In this call, we will review updates from several industry WGs, which you may have missed this week. For our presentation, Patrik Stas (@PatrikStas) will provide an introduction to the Indyscan project and how it helps monitor the health and security of Indy-based ledgers. Here are links to the Wiki and Zoom meeting: Wiki: https://wiki.hyperledger.org/display/IWG/2021-01-14+Identity+Implementers+WG+Call Zoom: https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

stpm01 (Thu, 14 Jan 2021 15:45:33 GMT):
Has joined the channel.

stpm01 (Thu, 14 Jan 2021 15:45:34 GMT):
InvalidStructureException : A value being processed is not valid error 113 When i call indy_prover_create_proof via ARIES framework .net that call indy SDK .net that call libindy.dll (Windows 10), i get InvalidStructureException : A value being processed is not valid. The SDK internal code is 113. Then, i discovered that I could activate the logging of the libindy. Here are the last traces just before the crash: ... TRACE|indy::services::anoncreds::prover| src\services\anoncreds\prover.rs:212 | _prepare_credentials_for_proving >>> requested_credentials: RequestedCredentials { self_attested_attributes: {}, requested_attributes: {"email": RequestedAttribute { cred_id: "d3ca7e99-0ff8-4d72-967a-821dd0e14d7e", timestamp: None, revealed: true } , "first_name": RequestedAttribute { cred_id: "d3ca7e99-0ff8-4d72-967a-821dd0e14d7e", timestamp: None, revealed: true }, "username": RequestedAttribute { cred_id: "d3ca7e99-0ff8-4d72-967a-821dd0e14d7e", timestamp: None, revealed: true }, "last_name": RequestedAttribute { cred_id: "d3ca7e99-0ff8-4d72-967a-821dd0e14d7e", timestamp: None, revealed: true }}, requested_predicates: {} }, proof_req: ProofRequestPayload { nonce: BigNumber { openssl_bn: 960840690959336350186628 } , name: "Basic Proof", version: "1.0", requested_attributes: {"a7ef4839-04f7-4525-92e0-79354cb30eee": AttributeInfo { name: Some("last_name"), names: None, restrictions: Some(Or([Eq("cred_def_id", "XpHQgyg7Dd4WerGtGCL3KN:3:CL:1614:vc-authn-oidc")])), non_revoked: None } , "a67d9ec5-c421-414e-8129-fdf09befb61d": AttributeInfo { name: Some("first_name"), names: None, restrictions: Some(Or([Eq("cred_def_id", "XpHQgyg7Dd4WerGtGCL3KN:3:CL:1614:vc-authn-oidc")])), non_revoked: None }, "f1c2c233-1785-410e-96b3-6c826df1ce94": AttributeInfo { name: Some("email"), names: None, restrictions: Some(Or([Eq("cred_def_id", "XpHQgyg7Dd4WerGtGCL3KN:3:CL:1614:vc-authn-oidc")])), non_revoked: None }, "aed1e027-67dd-466a-85ef-d8fdf1b2fa93": AttributeInfo { name: Some("username"), names: None, restrictions: Some(Or([Eq("cred_def_id", "XpHQgyg7Dd4WerGtGCL3KN:3:CL:1614:vc-authn-oidc")])), non_revoked: None }}, requested_predicates: {}, non_revoked: None } TRACE|indy::api::anoncreds | src\api\anoncreds.rs:2056| prepare_result_1: >>> Err(IndyError { inner:AttributeInfo not found in ProofRequest for referent "email" Invalid structure }) TRACE|indy::api::anoncreds | src\api\anoncreds.rs:2056| indy_prover_create_proof: result: "" In the libindy source code, prover.rs: pub fn _prepare_credentials_for_proving(requested_credentials: &RequestedCredentials, proof_req: &ProofRequestPayload) -> IndyResult, Vec)>> { trace!("_prepare_credentials_for_proving >>> requested_credentials: \{:?} , proof_req: {:?}", requested_credentials, proof_req); let mut credentials_for_proving: HashMap, Vec)> = HashMap::new(); for (attr_referent, requested_attr) in requested_credentials.requested_attributes.iter() { let attr_info = proof_req.requested_attributes .get(attr_referent.as_str()) .ok_or_else(|| err_msg(IndyErrorKind::InvalidStructure, format!("AttributeInfo not found in ProofRequest for referent \"{}\"", attr_referent.as_str())))?;

mccown (Thu, 14 Jan 2021 16:00:17 GMT):
The Identity Implementer's WG is starting (9am MT / 4pm UTC). Today, Patrik Stas will be giving an intro to the Indyscan project and how it helps monitor the health and security of Indy-based ledgers. Zoom: https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

PatrikStas (Thu, 14 Jan 2021 20:19:08 GMT):
Thanks for having me, also 1 thing I forgot to show on the call is this really cool visualisation on top of indyscan made by @wip-abramson https://sovrin-network-vis.netlify.app/

DiAnh (Fri, 22 Jan 2021 08:39:32 GMT):
Has joined the channel.

acuderman (Sat, 23 Jan 2021 09:50:24 GMT):
Has joined the channel.

rewaj7 (Mon, 25 Jan 2021 11:03:23 GMT):
Hi all, wanted to ask a general configuration question. If you are aiming to make a mobile application for verifying user identity, would the following structure be appropriate?

rewaj7 (Tue, 26 Jan 2021 11:41:19 GMT):
Hi all, could anyone point me to a tutorial or a more in depth article on how to register custom wallet storage? An example usage would be great. Thank you!

abhaypsoni (Wed, 27 Jan 2021 05:45:35 GMT):
Has joined the channel.

Integrion (Wed, 27 Jan 2021 18:41:03 GMT):
Has joined the channel.

Integrion (Wed, 27 Jan 2021 18:41:03 GMT):
Hi all, where can we find the latest info on setting up our linux-based local dev environments to work with the latest Aries JavaScript Framework? As suggestions are deeply appreciated!

Integrion (Wed, 27 Jan 2021 18:42:11 GMT):
The links @ https://www.npmjs.com/package/indy-sdk for prerequisites to install are returning 404! It says, make sure you have the latest libindy for your platform. Also make sure you have any other libraries it depends on. See indy-sdk/doc <<<< this is returning 404... any assistance appreciated!

Integrion (Wed, 27 Jan 2021 18:58:34 GMT):
We're also tried without success to follow these instructions to build the indy-sdk on Ubuntu 18.04 without any luck... the build fails complaining something about libsodium 1.16 not being found...

Integrion (Wed, 27 Jan 2021 18:58:37 GMT):
https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/build-guides/ubuntu-build.html

Integrion (Thu, 28 Jan 2021 23:01:16 GMT):
Hi @TimoGlastra, @swcurran suggested we connect regarding setting up our dev environment with the Aries JavaScript Framework. We've managed to build indy-sdk@1.15.0-dev-1618. Is this the latest we can build to, or is this deprecated and not longer the current framework? Thanks!

Integrion (Thu, 28 Jan 2021 23:04:25 GMT):
I see references to using libindy v1.6+ are unable to locate this...

Integrion (Thu, 28 Jan 2021 23:04:25 GMT):
I see references to using libindy v1.6+ but are unable to locate this...

Takuro2 (Sun, 07 Feb 2021 07:31:19 GMT):
Has joined the channel.

Takuro2 (Sun, 07 Feb 2021 07:31:20 GMT):
Hello all, I am trying to run indy-sdk node js sample But it stops every time with an error: `============================== == Getting Trust Anchor credentials - Thrift getting Verinym == ------------------------------ "Thrift" > Create and store in Wallet "Thrift" new DID" "Thrift" > Authcrypt "Thrift DID info" for "Sovrin Steward" "Thrift" > Send authcrypted "Thrift DID info" to Sovrin Steward "Sovrin Steward" > Authdecrypted "Thrift DID info" from Thrift "Sovrin Steward" > Authenticate Thrift by comparision of Verkeys (node:16078) UnhandledPromiseRejectionWarning: IndyError: 212 at Object.callback (/home/ubuntu/indy-sdk/samples/nodejs/node_modules/indy-sdk/src/wrapIndyCallback.js:15:10) (node:16078) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1) (node:16078) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code. ` Can anyone tell me why is the issue occurring?

TimoGlastra (Mon, 08 Feb 2021 10:38:19 GMT):
The indy-sdk example for NodeJS is broken (at least last time I tried). I tried fixing it but wasn't able to do so in a reasonable amount of time so I abandoned it. So can't help you with why it errors, but can say that it is (probably) not a problem on your side.

mccown (Wed, 10 Feb 2021 22:09:00 GMT):
The Identity Implementer's WG is meeting tomorrow (Feb 11th @ 9am MT / 4pm UTC). In this call, we will review updates from several industry WGs, which you may have missed this week. For our presentation, Riley Hughes from Trinsic is presenting some of their new developments (https://trinsic.id). Here are links to the Wiki and Zoom meeting: Wiki: https://wiki.hyperledger.org/display/IWG/2021-02-11+%3A+Identity+Implementers+WG+Call Zoom: https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

rjones (Thu, 11 Feb 2021 01:49:57 GMT):
If I could get one more +1 here that would be awesome: https://github.com/hyperledger/indy-node/pull/1649

PabloRomeu (Wed, 17 Feb 2021 08:34:42 GMT):
Has joined the channel.

huytn.it (Thu, 18 Feb 2021 03:59:38 GMT):
Has joined the channel.

WadeBarnes (Sat, 20 Feb 2021 17:43:41 GMT):
It appears we've resolved the issues with the service accounts needed to publish the `indy-sdk` release. The most recent nightly build was able to publish it's artifacts successfully. Given that, I've initiated to publishing process on the much anticipated `1.16.0` release. - https://build.sovrin.org/job/indy-sdk/job/indy-sdk-cd/job/rc/170/ - https://build.sovrin.org/blue/organizations/jenkins/indy-sdk%2Findy-sdk-cd/detail/rc/170/pipeline

WadeBarnes (Sat, 20 Feb 2021 17:43:41 GMT):
It appears we've resolved the issues with the service accounts needed to publish the `indy-sdk` release. The most recent nightly build was able to publish it's artifacts successfully. Given that, I've initiated the publishing process on the much anticipated `1.16.0` release. - https://build.sovrin.org/job/indy-sdk/job/indy-sdk-cd/job/rc/170/ - https://build.sovrin.org/blue/organizations/jenkins/indy-sdk%2Findy-sdk-cd/detail/rc/170/pipeline

WadeBarnes (Sat, 20 Feb 2021 17:44:09 GMT):
@ianco ^

ianco (Sat, 20 Feb 2021 17:48:08 GMT):
Woo hoo awesome work @WadeBarnes !!!

WadeBarnes (Sat, 20 Feb 2021 17:51:48 GMT):
Team effort; @rjones, @askolesov

WadeBarnes (Sat, 20 Feb 2021 18:01:41 GMT):
The build completed successfully. Over to you @ianco for next steps.

ianco (Sun, 21 Feb 2021 20:35:08 GMT):
Based on the release process documented here: https://github.com/hyperledger/indy-sdk/blob/master/docs/contributors/release-workflow.md The last steps are: - If there is no problems found team approves the release. CD pipeline resumes, moves artifacts to stable release channel and creates Git release tag on corresponded commit. - If some problems were found team declines the release and starts creation of hot-fix PR to rc branch. After PR is created release process resumes from rc PR stage. - After release performed the team back merges the rc branch to the master branch.

ianco (Sun, 21 Feb 2021 20:36:14 GMT):
So, since there were no issues identified in any testing of the release, the outstanding steps are: - create Git release tag on corresponding commit - back merge the rc branch to the master branch

ianco (Sun, 21 Feb 2021 20:37:10 GMT):
The link to create a release is here (thanks to @WadeBarnes for providing): https://github.com/hyperledger/indy-sdk/releases

ianco (Sun, 21 Feb 2021 20:41:14 GMT):
I assume the next steps are (can someone please confirm): - on the above `releases` link click on "Draft a New Release" - version # `v1.16.0` and select the `rc` branch - fill in release title and details - not sure if it's required to attach binaries to this release? - click on "Publish Release"

ianco (Sun, 21 Feb 2021 20:42:09 GMT):
@esplinr @WadeBarnes @sergey.minaev ?

ianco (Sun, 21 Feb 2021 20:42:26 GMT):
(And then once the release is tagged merge `rc` back into the `master` branch)

WadeBarnes (Sun, 21 Feb 2021 21:12:57 GMT):
Those look like the correct steps to me. No need to **attach binaries to this release**. The ones in the other releases are the default ones that GitHub will create for you.

WadeBarnes (Sun, 21 Feb 2021 21:12:57 GMT):
Those look like the correct steps to me. **No need to "attach binaries to this release"**. The ones in the other releases are the default ones that GitHub will create for you.

WadeBarnes (Sun, 21 Feb 2021 21:14:28 GMT):
Also update [CHANGELOG.md](https://github.com/hyperledger/indy-sdk/blob/master/CHANGELOG.md) with the release notes.

WadeBarnes (Sun, 21 Feb 2021 21:18:31 GMT):
Looks like the update to the change log goes into RC before the back merge; https://github.com/hyperledger/indy-sdk/pull/2141

WadeBarnes (Sun, 21 Feb 2021 21:20:00 GMT):
And the tag and release is done on master after the back merge.

WadeBarnes (Sun, 21 Feb 2021 21:20:00 GMT):
~And the tag and release is done on master after the back merge.~

WadeBarnes (Sun, 21 Feb 2021 21:20:27 GMT):
https://github.com/hyperledger/indy-sdk/commit/f85afd2f94959eb59522e5dda160d2c7fdd1a4ba

WadeBarnes (Sun, 21 Feb 2021 21:26:17 GMT):
Although that does not seem correct in this case since `master` would contain change not in the release. I'd tag the release in RC since that contains the code on which the release is based.

WadeBarnes (Sun, 21 Feb 2021 21:26:17 GMT):
~Although that does not seem correct in this case since `master` would contain change not in the release. I'd tag the release in RC since that contains the code on which the release is based.~

WadeBarnes (Sun, 21 Feb 2021 21:32:01 GMT):
Proposal: - Update [CHANGELOG.md](https://github.com/hyperledger/indy-sdk/blob/master/CHANGELOG.md) on RC. - Draft the new release off the latest commit in RC (the one including the update to the change log). Tag `v1.16.0`, name `1.16.0`. - Fill in the release details. - Publish the release. - Back merge into `master`.

WadeBarnes (Sun, 21 Feb 2021 21:32:01 GMT):
Steps: - Update [CHANGELOG.md](https://github.com/hyperledger/indy-sdk/blob/master/CHANGELOG.md) on RC. - Draft the new release off the latest commit in RC (the one including the update to the change log). Tag `v1.16.0`, name `1.16.0`. - Fill in the release details. - Publish the release. - Back merge into `master`.

WadeBarnes (Sun, 21 Feb 2021 21:36:10 GMT):
Here is an example of the back merge; https://github.com/hyperledger/indy-sdk/pull/2144

WadeBarnes (Sun, 21 Feb 2021 21:38:14 GMT):
Example release update: https://github.com/hyperledger/indy-sdk/pull/2141

WadeBarnes (Sun, 21 Feb 2021 21:38:31 GMT):
Example of the back merge; https://github.com/hyperledger/indy-sdk/pull/2144

Kshitij 7 (Tue, 23 Feb 2021 09:05:22 GMT):
Has joined the channel.

Kshitij 7 (Tue, 23 Feb 2021 09:05:23 GMT):
Getting CommonInvalidState error on step# 8 at the stage of prover storing credentials while running negotiateProof.js script in indy-sdk/docs/how-tos/negotiate-proof/nodejs. It's a freshly cloned repo. Any help is much appreciated. { IndyError: CommonInvalidState at Object.callback (/home/ubuntu/indy-sdk/wrappers/nodejs/src/wrapIndyCallback.js:15:10) name: 'IndyError', message: 'CommonInvalidState', indyCode: 112, indyName: 'CommonInvalidState', indyCurrentErrorJson: null }

kukgini (Wed, 24 Feb 2021 05:30:45 GMT):
I can not be sure that this is where it is appropriate. I am asking about `indy_vdr go wrapper`. The following code failed with following error: ``` 1 package main 2 3 import ( 4 "fmt" 5 "log" 6 "net/http" ... 13 "github.com/hyperledger/indy-vdr/wrappers/golang/vdr" 14 ) 15 16 func main() { 17 log.Println("load genesis tx from internet") 18 genesisFile, err := http.Get("https://raw.githubusercontent.com/sovrin-foundation/sovrin/master/sovrin/pool_transactions_builder_genesis") 19 if err != nil { 20 log.Fatalln(err) 21 } 22 defer genesisFile.Body.Close() 23 24 fmt.Println("create indy vdr client") 25 client, err := vdr.New(genesisFile.Body) 26 if err != nil { 27 log.Fatalln(err) 28 } 29 log.Fatalln(client) 30 } ``` error message was: ``` vendor/github.com/hyperledger/indy-vdr/wrappers/golang/vdr/indy_vdr.go:86:34: could not determine kind of name for C.u_long ```

kukgini (Wed, 24 Feb 2021 05:30:45 GMT):
I can not be sure that this is where it is appropriate. I am asking about `indy_vdr go wrapper`. The following code failed with following error: ``` 1 package main 2 3 import ( 5 "log" 6 "net/http" ... 13 "github.com/hyperledger/indy-vdr/wrappers/golang/vdr" 14 ) 15 16 func main() { 17 log.Println("load genesis tx from internet") 18 genesisFile, err := http.Get("https://raw.githubusercontent.com/sovrin-foundation/sovrin/master/sovrin/pool_transactions_builder_genesis") 19 if err != nil { 20 log.Fatalln(err) 21 } 22 defer genesisFile.Body.Close() 23 24 log.Println("create indy vdr client") 25 client, err := vdr.New(genesisFile.Body) 26 if err != nil { 27 log.Fatalln(err) 28 } 29 log.Fatalln(client) 30 } ``` error message was: ``` vendor/github.com/hyperledger/indy-vdr/wrappers/golang/vdr/indy_vdr.go:86:34: could not determine kind of name for C.u_long ``` it seems related with `cgo`. But, i don't know muck about golang and cgo well. can you help me?

kukgini (Wed, 24 Feb 2021 05:30:45 GMT):
I can not be sure that this is where it is appropriate. I am asking about `indy_vdr go wrapper`. The following code failed with following error: ``` 1 package main 2 3 import ( 5 "log" 6 "net/http" ... 13 "github.com/hyperledger/indy-vdr/wrappers/golang/vdr" 14 ) 15 16 func main() { 17 log.Println("load genesis tx from internet") 18 genesisFile, err := http.Get("https://raw.githubusercontent.com/sovrin-foundation/sovrin/master/sovrin/pool_transactions_builder_genesis") 19 if err != nil { 20 log.Fatalln(err) 21 } 22 defer genesisFile.Body.Close() 23 24 log.Println("create indy vdr client") 25 client, err := vdr.New(genesisFile.Body) 26 if err != nil { 27 log.Fatalln(err) 28 } 29 log.Fatalln(client) 30 } ``` error message was: ``` vendor/github.com/hyperledger/indy-vdr/wrappers/golang/vdr/indy_vdr.go:86:34: could not determine kind of name for C.u_long ``` it seems related with `cgo`. But, i don't know much about golang and cgo well. can you help me?

kukgini (Wed, 24 Feb 2021 05:30:45 GMT):
Here's another `indy_vdr` question. `go run demo.go` in `wrappers/golang/cmd/demo` returns following error: ``` 2021/02/25 08:10:45 refresh pool error result: (Indy error code: [824635260280]) exit status 1 ``` I don't know what error code is this. anyone help me?

andrew.whitehead (Wed, 24 Feb 2021 05:56:03 GMT):
I'm not sure what the error is either, but it's possible something broke when a large PR was merged recently as there's no automated testing for that yet (I'm working on the CI right now)

kukgini (Wed, 24 Feb 2021 07:29:46 GMT):
Thanks @andrew.whitehead I'll try later when another commit arrived.

kukgini (Wed, 24 Feb 2021 10:28:45 GMT):
I made a pull request for it. maybe it can help.

aaronr (Wed, 24 Feb 2021 18:41:05 GMT):
Not sure if this is the right place to ask this or not. Would appreciate a pointer in the right direction if it is not. I'm looking to see where negative security-type tests are being run, etc. For example, a test that demonstrates that a modified/tampered with credential used in a proof response fails verification.

kukgini (Wed, 24 Feb 2021 23:16:38 GMT):
Here's another indy_vdr question. go run demo.go in wrappers/golang/cmd/demo returns following error: 2021/02/25 08:10:45 refresh pool error result: (Indy error code: [824635260280]) exit status 1 I don't know what error code is this. anyone help me?

andrew.whitehead (Wed, 24 Feb 2021 23:17:31 GMT):
it looks like the wrapper is probably misinterpreting the bytes of the error code

andrew.whitehead (Wed, 24 Feb 2021 23:30:59 GMT):
hm, the method signature in libindy_vdr.h doesn't look right, the callback gets (id: usize, error: usize)

andrew.whitehead (Wed, 24 Feb 2021 23:33:23 GMT):
that was changed so that the same callbacks can be used for multiple calls. it looks like the wrapper needs updating in a few places to pass an ID (probably 0) and adjust the callback signature

kukgini (Thu, 25 Feb 2021 00:00:45 GMT):
thank you for the look @andrew.whitehead

mccown (Thu, 25 Feb 2021 05:37:02 GMT):
The Identity Implementer's WG is meeting on Thursday (Feb 25th @ 9am MT / 4pm UTC). In this call, we will review updates from several industry WGs, which you may have missed this week. Lohan Spies (CEO, did:x) will provide a presentation of tools & methods for monitoring the health and security of Indy-based ledgers. Here are links to the Wiki and Zoom meeting: Wiki: https://wiki.hyperledger.org/display/IWG/2021-02-25+:+Identity+Implementers+WG+Call Zoom: https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

ianco (Thu, 25 Feb 2021 14:35:43 GMT):
FYI I created the 1.16.0 release tag and the PR to merge `rc` into `main`: https://github.com/hyperledger/indy-sdk/pull/2361

ianco (Thu, 25 Feb 2021 15:24:32 GMT):
PR to fix conflict in the PR: https://github.com/hyperledger/indy-sdk/pull/2362

andrew.whitehead (Thu, 25 Feb 2021 23:59:12 GMT):
@kukgini The go wrapper should be fixed now

daidoji (Fri, 26 Feb 2021 21:34:24 GMT):
So today I was troubleshooting with another team on acapy and we ran into an error strikingly similar to https://jira.hyperledger.org/browse/IS-1309

daidoji (Fri, 26 Feb 2021 21:35:10 GMT):
why was the issue to just update the docs (none of which really made it to acapy or the indy python wrapper that I could find easily) and not to prevent the library from entering into an invalid state?

daidoji (Fri, 26 Feb 2021 21:35:49 GMT):
We were getting a similar error (and acapy was crashing with an Indy wrapper error) when using this nonce in a present-proof `a519371c3e32b0a82cbbf08986a8e35626dc180f188d6f80244113b4b852da6e`

fabienpe (Thu, 04 Mar 2021 10:42:16 GMT):
Hello, I noticed that the JIRA of indy-sdk has turned read-only. Does this mean that that the indy-sdk is being slowly abandoned?

sebastian (Thu, 04 Mar 2021 10:42:25 GMT):
Hello everyone, I try to connect an indy-sdk based wallet with a PostgreSQL hosted on Azure using the postgres plugin. Unfortunately, I am unable to connect with the database. My current guess is that it might be related to missing Tls support of the plugin, which seems to be enforced by Azure. I found this ticket https://jira.hyperledger.org/browse/IS-1461 and have seen uncommented code in the source regarding Tls. But since i have no experience in rust its hard for me to see where the missing parts are. Someone who can point me in the right direction or show me an alternative?

ianco (Thu, 04 Mar 2021 14:26:08 GMT):
The work was started here but never completed/merged: https://github.com/hyperledger/indy-sdk/pull/2157

rjones (Thu, 04 Mar 2021 14:32:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=2DAm2mBLY2TFJ6unT) those issues are tracked on GitHub issues

sebastian (Thu, 04 Mar 2021 16:54:51 GMT):
@ianco Thanks for pointing me to the PR. So the solution you suggested in the end was not tested?

ianco (Thu, 04 Mar 2021 16:55:42 GMT):
No, the newest postgres library had breaking changes and no one has had time to do the updates

lmtriet (Mon, 08 Mar 2021 20:52:16 GMT):
Has joined the channel.

ascatox (Thu, 11 Mar 2021 11:07:26 GMT):
Has joined the channel.

ascatox (Thu, 11 Mar 2021 11:09:32 GMT):
Hi All Someone can help to istall the indy-sdk on Windows Pc???

ascatox (Thu, 11 Mar 2021 11:10:05 GMT):
The documentation on GH has a missing part for the Windows OS. Thanks in advance.

breno.medeiros (Fri, 12 Mar 2021 17:08:48 GMT):
Has joined the channel.

breno.medeiros (Fri, 12 Mar 2021 17:08:49 GMT):
Hello everyone!

breno.medeiros (Fri, 12 Mar 2021 17:34:42 GMT):
I'm an iOS Developer, and im trying to install the wrapper for iOS in this README.md [ https://github.com/hyperledger/indy-sdk/tree/master/wrappers/ios ], but the 6º step that says to edit script "ci/ios-build.sh" I can't do, because that isn't suck a file in my entire project/computer when I search for it in Finder/Spotlight.

breno.medeiros (Fri, 12 Mar 2021 17:35:07 GMT):
Do you know where can I find it so i can edit it?

TimoGlastra (Mon, 15 Mar 2021 09:33:40 GMT):
It's in the root of the repository. So `indy-sdk/ci/ios-build.sh` -> https://github.com/hyperledger/indy-sdk/blob/8c669cff434f5d87e7a2e2e192423c67a9df0b33/ci/ios-build.sh

breno.medeiros (Mon, 15 Mar 2021 11:57:21 GMT):
Tnks!

breno.medeiros (Mon, 15 Mar 2021 12:35:33 GMT):
Thank you for your help, i foud the file 👍🏼 And now i did the next step(7º Step) on Terminal, and it printed this:

breno.medeiros (Mon, 15 Mar 2021 12:36:19 GMT):

Podfile Terminal iOSProjectFolder OpenSSLFolder ios-build.sh .png

ParminderParmar (Mon, 15 Mar 2021 23:54:28 GMT):
Has joined the channel.

ParminderParmar (Tue, 16 Mar 2021 00:00:19 GMT):
Hi Guys, I have a few questions around indy. if some one can help would be great.How can you connect your indy node to sovrin network ? if yes, will sovrin charge for connectivity ? If I will issue a credential using evernym, will I be able to load that credential in any wallet like Trinsic ? What would you recommend in terms of builsing applications - indy connected to sovrin, trinsic or evernym ? If i will spin my own network of indy, are there any wallets which will work automatically with it ?

ParminderParmar (Tue, 16 Mar 2021 00:00:19 GMT):
Hi Guys, I have a few questions about indy. if someone can help would be great. How can you connect your indy node to sovrin network? if yes, will sovrin charge for connectivity? If I will issue a credential using evernym, will I be able to load that credential in any wallet like Trinsic ? What would you recommend in terms of building applications - indy connected to sovrin, trinsic or evernym ? If i will spin my own network of indy, are there any wallets that will work automatically with it?

swcurran (Tue, 16 Mar 2021 03:38:07 GMT):
1. No, you can't on your own connect your Indy node to Sovrin. You have to apply to be a Sovrin Steward, be approved by the Board, and then your node will be added to the network. 2. Issuing from an Evernym issuer to a Trinisic wallet should work fine. I don't know who has done it, but @rileyphughes and @esplinr can probably provide details. That is the point of the Aries Interop Profile. Check out http://aries-interop.info to see frameworks that have continuous interop tests running against the latest code bases. Trinsic and Evernym don't operate networks -- they build software to issuer, hold/prove and verify Indy AnonCred VCs. If you spin your own network, the existing wallets will not work unless they agree to configure their wallet allow users to load your genesis file. I believe one wallet lets you load an arbitrary genesis file, but it's not likely to be added. We are working on a new `did:indy` DID method that will make it easier for new networks to be discovered and used with wallets, but that is not yet available, so it is up to the wallet makers what networks they will support.

swcurran (Tue, 16 Mar 2021 03:38:07 GMT):
1. No, you can't on your own connect your Indy node to Sovrin. You have to apply to be a Sovrin Steward, be approved by the Board, and then your node will be added to the network. 2. Issuing from an Evernym issuer to a Trinisic wallet should work fine. I don't know who has done it, but @rileyphughes and @esplinr can probably provide details. That is the point of the Aries Interop Profile. Check out http://aries-interop.info to see frameworks that have continuous interop tests running against the latest code bases. 3. Trinsic and Evernym don't operate networks -- they build software to issuer, hold/prove and verify Indy AnonCred VCs. 4. If you spin your own network, the existing wallets will not work unless they agree to configure their wallet allow users to load your genesis file. I believe one wallet lets you load an arbitrary genesis file, but it's not likely to be added. We are working on a new `did:indy` DID method that will make it easier for new networks to be discovered and used with wallets, but that is not yet available, so it is up to the wallet makers what networks they will support.

ParminderParmar (Tue, 16 Mar 2021 04:31:38 GMT):
Thank you @swcurran for answering my queries.

HighBrow (Tue, 16 Mar 2021 06:14:26 GMT):
Has joined the channel.

deas (Tue, 16 Mar 2021 13:45:14 GMT):
Has joined the channel.

deas (Tue, 16 Mar 2021 13:48:31 GMT):
I know that the Trinsic app allows you to add genesis files on a one-off basis. I've tried it myself successfully. But in terms of out-of-the-box support without requiring an app user to perform configuration, @rileyphughes might be able to speak to the perspective there.

BrianK7978 (Tue, 16 Mar 2021 18:09:54 GMT):
Has joined the channel.

antonden (Wed, 17 Mar 2021 09:11:20 GMT):
Has joined the channel.

antonden (Wed, 17 Mar 2021 09:15:06 GMT):
@breno.medeiros Looks like you didn't specify script parameters (11 line of the script). @sergey.minaev can help.

sergey.minaev (Wed, 17 Mar 2021 10:05:17 GMT):
@breno.medeiros yep, It's not clear from the README, but the first parameter is mandatory. So to run the script you have to specify the package. E.g. `./ci/ios-build.sh libindy`

rome-sandra (Wed, 17 Mar 2021 10:10:59 GMT):
Has joined the channel.

breno.medeiros (Wed, 17 Mar 2021 14:43:13 GMT):
Thanks for the answer, it seams to go better, the now shows this different error:

breno.medeiros (Wed, 17 Mar 2021 14:43:13 GMT):
Thanks for the answer, it seams to go better, but now shows this different error:

breno.medeiros (Wed, 17 Mar 2021 14:44:15 GMT):

Changed line 11 on ios-build.sh and Terminal showing diferent error.png

tkdp (Thu, 18 Mar 2021 08:42:51 GMT):
hello everybody, has someone experience connecting the postgres-plugin (running in OpenShift) via pgBouncer (running in OpenShift) against an Azure PostgreSQL SingleServer instance? we are using this architecture to circumvent the '@' and tls/ssl problem, which is in the development queue for the postgres-plugin...

WadeBarnes (Thu, 18 Mar 2021 12:39:54 GMT):
The BC Digital Trust Services team has a great deal of OpenShift experience. We're not using that particular pattern, but here are our build and deployment configurations in case any of it is helpful: - https://github.com/bcgov/orgbook-configurations/tree/feature/ocp4 - https://github.com/bcgov/von-bc-registries-agent-configurations/tree/feature/ocp4

WadeBarnes (Thu, 18 Mar 2021 12:39:54 GMT):
The BC Digital Trust Services team has a great deal of OpenShift experience. We're not using that particular pattern, but here are some of our build and deployment configurations in case any of it is helpful: - https://github.com/bcgov/orgbook-configurations/tree/feature/ocp4 - https://github.com/bcgov/von-bc-registries-agent-configurations/tree/feature/ocp4

breno.medeiros (Thu, 18 Mar 2021 13:12:24 GMT):
Good morning @sergey.minaev

tkdp (Thu, 18 Mar 2021 13:30:36 GMT):
Hi, thanks a lot for your reply; but we have to run our postgres-instance not in open shift itself; we should use azure; there Azure generates postgres-user-names containing an additional '@'; also SSL is required; with both (additional '@' and SSL) the postgres-plugin does not cope; therefore we have to put pgBouncer in-between; this is generally no problem (we have a running example with an Azure Kubernetes); but with our openshift we are facing problems

WadeBarnes (Thu, 18 Mar 2021 13:34:41 GMT):
Understood. @ianco, Could you have a quick look to see if the postgres-plugin is quoting usernames and passwords properly. That's typically the issue with special characters and even capital letters when it comes to Postgres.

WadeBarnes (Thu, 18 Mar 2021 13:35:44 GMT):
@tkdp, What sort of issues/errors are you getting while trying to run pgBouncer in OCP?

ianco (Thu, 18 Mar 2021 13:39:42 GMT):
@WadeBarnes looks like @tkdp just put in a PR to fix this

WadeBarnes (Thu, 18 Mar 2021 13:40:07 GMT):
:thumbsup:

tkdp (Thu, 18 Mar 2021 15:22:44 GMT):
no i have not done a pr; would be cool than this would mean that I would have Rust knowledge...

tkdp (Thu, 18 Mar 2021 15:23:17 GMT):
outgoing from the https://github.com/hyperledger/indy-sdk/pull/2157 we searched a way to circumvent the Azure-'@' problem and the TLS-problem and found pgBouncer; The construction is fully runnable in an Azure environment with and Azure Kubernetes Cluster; the scenario is also runnable against an Azure PostgeSQL with a Docker-pgBouncer and an Indy-client starting from my laptop; in our company (behind firewalls, etc.) the world is different; here we have Azure PostegreSQL SingleServer with a PrivateLink and Openshift running the client processes; we are using the same configuration as for the outside world; we are using the plugin default DatabasePerWallet; the plugin connects to the database as admin, notes that it should create a new database and creates the database; after that it disconnects and tries to create the missing tables; which fails; pgBouncer wants now to connect to addresses/ports which we have currently not in focus and nothing to do with the database;

tkdp (Thu, 18 Mar 2021 15:23:41 GMT):
i know my problem is now pgBouncer and not the postgres-plugin itself;

WadeBarnes (Thu, 18 Mar 2021 15:35:29 GMT):
So is this a corporate firewall issue?

tkdp (Thu, 18 Mar 2021 15:55:30 GMT):
i'm currently thinking in this direction; but I would like to understand why pgBouncer "invents" connection strings / ports which I do not have directly under control

tkdp (Thu, 18 Mar 2021 15:56:31 GMT):
but either way: would be cool if the above mentioned PR would be introduced and the '@' problem additionally solved...

tkdp (Thu, 18 Mar 2021 15:57:00 GMT):
I see: I must start learning Rust ...:slight_smile:

breno.medeiros (Fri, 19 Mar 2021 11:56:52 GMT):
@sergey.minaev , can you help me?

breno.medeiros (Fri, 19 Mar 2021 12:52:51 GMT):
@antonden , can you help me run the Readme?

Yunxi 3 (Mon, 22 Mar 2021 09:17:53 GMT):
Has joined the channel.

Yunxi 3 (Mon, 22 Mar 2021 09:17:54 GMT):
Hello all, when running acapy, i always see info "Function returned error" in the acapy logs, what does it mean?

breno.medeiros (Mon, 22 Mar 2021 11:03:06 GMT):
Good morning @sergey.minaev

Yunxi 3 (Mon, 22 Mar 2021 12:22:27 GMT):

Clipboard - March 22, 2021 12:22 PM

andrew.whitehead (Mon, 22 Mar 2021 18:57:57 GMT):
It's not a problem. Sometimes an error is expected, for example when trying to retrieve a record by ID to see if it exists.

vineeta (Wed, 24 Mar 2021 13:54:43 GMT):
Has joined the channel.

vineeta (Thu, 25 Mar 2021 05:02:34 GMT):
Hi, I was checking wallets & tags here https://hyperledger-indy.readthedocs.io/projects/hipe/en/latest/text/0013-wallets/README.html#tags-and-queries for adding custom tags to credentials stored in wallets. Tried with indy-sdk function addWalletRecordTags ( wh, type, id, tags ) -> void to add tag as given in README here for drivers license. Where id is outCredentialID (id returned after storing credentials), tags is json . But call to this function returns wallet item not found. How can we add custom tags to credential after storing it using proverStoreCredential ( wh, credId, credReqMetadata, cred, credDef, revRegDef ) -> outCredId

vineeta (Thu, 25 Mar 2021 05:02:34 GMT):
Hi, I was checking wallets & tags here https://hyperledger-indy.readthedocs.io/projects/hipe/en/latest/text/0013-wallets/README.html#tags-and-queries for adding custom tags to credentials stored in wallets. Tried with indy-sdk function addWalletRecordTags ( wh, type, id, tags ) -> void to add tag as given in README here for drivers license. Where id is outCredId (id returned after storing credentials), tags is json . But call to this function returns wallet item not found. How can we add custom tags to credential after storing it using proverStoreCredential ( wh, credId, credReqMetadata, cred, credDef, revRegDef ) -> outCredId ?

vineeta (Thu, 25 Mar 2021 05:02:34 GMT):
Hi, I was checking wallets & tags here https://hyperledger-indy.readthedocs.io/projects/hipe/en/latest/text/0013-wallets/README.html#tags-and-queries for adding custom tags to credentials stored in wallets. Tried with indy-sdk function addWalletRecordTags ( wh, type, id, tags ) -> void to add tag as given in README here for drivers license. Where id is outCredId (id returned after storing credentials), tags is json . But call to this function returns wallet item not found. How can we add custom tags to credential after storing it using proverStoreCredential ( wh, credId, credReqMetadata, cred, credDef, revRegDef ) -> outCredId ? https://jira.hyperledger.org/browse/IS-790 According to this jira task support for tags is provided for storing credentials. Is adding custom tags supported for credentials ``` ```

vineeta (Thu, 25 Mar 2021 05:02:34 GMT):
Hi, I was checking wallets & tags here https://hyperledger-indy.readthedocs.io/projects/hipe/en/latest/text/0013-wallets/README.html#tags-and-queries for adding custom tags to credentials stored in wallets. Tried with indy-sdk function addWalletRecordTags ( wh, type, id, tags ) -> void to add tag as given in README here for drivers license. Where id is outCredId (id returned after storing credentials), tags is json . But call to this function returns wallet item not found. How can we add custom tags to credential after storing it using proverStoreCredential ( wh, credId, credReqMetadata, cred, credDef, revRegDef ) -> outCredId ? https://jira.hyperledger.org/browse/IS-790 According to this jira task support for tags is provided for storing credentials. Is adding custom tags supported for credentials

vineeta (Thu, 25 Mar 2021 05:02:34 GMT):
Hi, I was checking wallets & tags here https://hyperledger-indy.readthedocs.io/projects/hipe/en/latest/text/0013-wallets/README.html#tags-and-queries for adding custom tags to credentials stored in wallets. Tried with indy-sdk function addWalletRecordTags ( wh, type, id, tags ) -> void to add tag as given in README here for drivers license. Where id is outCredId (id returned after storing credentials), tags is json . But call to this function returns wallet item not found. How can we add custom tags to credential after storing it using proverStoreCredential ( wh, credId, credReqMetadata, cred, credDef, revRegDef ) -> outCredId ? https://jira.hyperledger.org/browse/IS-790 According to this jira task support for tags is provided for storing credentials. Is adding user defined tags supported for credentials

breno.medeiros (Fri, 26 Mar 2021 01:01:11 GMT):
@sergey.minaev , can you help me?

breno.medeiros (Mon, 29 Mar 2021 17:10:39 GMT):
@sergey.minaev ? @antonden ?

sergey.minaev (Tue, 30 Mar 2021 14:00:31 GMT):
Hi Breno, sorry I didn't have enough time to answer last couple of weeks. As I said above, just run the script and specify the package. You shouldn't modify the script. Just pass the package name as a parameter. `./ci/ios-build.sh libindy` is the command to execute from the root of IndySDK repo.

jasoncys (Thu, 01 Apr 2021 09:48:40 GMT):
Has joined the channel.

jasoncys (Thu, 01 Apr 2021 09:48:41 GMT):
Hi, I tried to install the indy repo locally. I received the following 3 failure messages: ``` ``` `failures: high_cases::revoc_reg_def_requests::indy_revoc_reg_def_requests_works high_cases::schema_requests::indy_schema_requests_works medium_cases::schemas_requests::indy_get_schema_requests_works_for_default_submitter_did ``` ` ``` ``` I followed the steps for "How to build Indy SDK from source". And somehow got to run the test using the following: `RUST_TEST_THREADS=1 cargo test` ```

jasoncys (Thu, 01 Apr 2021 09:48:41 GMT):
Hi, I tried to install the indy repo locally. I received the following 3 failure messages: `failures: high_cases::revoc_reg_def_requests::indy_revoc_reg_def_requests_works high_cases::schema_requests::indy_schema_requests_works medium_cases::schemas_requests::indy_get_schema_requests_works_for_default_submitter_did ` I followed the steps for "How to build Indy SDK from source". And somehow got to run the test using the following: `RUST_TEST_THREADS=1 cargo test`

jasoncys (Thu, 01 Apr 2021 09:48:41 GMT):
Hi, I tried to install the indy repo locally. I received the following 3 failure messages: `failures: high_cases::revoc_reg_def_requests::indy_revoc_reg_def_requests_works high_cases::schema_requests::indy_schema_requests_works medium_cases::schemas_requests::indy_get_schema_requests_works_for_default_submitter_did` I followed the steps for "How to build Indy SDK from source". And somehow got to run the test using the following: `RUST_TEST_THREADS=1 cargo test`

jasoncys (Thu, 01 Apr 2021 09:48:41 GMT):
Hi, I tried to install the indy repo locally. I received the following 3 failure messages: `failures: high_cases::revoc_reg_def_requests::indy_revoc_reg_def_requests_works high_cases::schema_requests::indy_schema_requests_works medium_cases::schemas_requests::indy_get_schema_requests_works_for_default_submitter_did` I followed the steps for `How to build Indy SDK from source`. And somehow got to run the test using the following: `RUST_TEST_THREADS=1 cargo test`

jasoncys (Thu, 01 Apr 2021 09:48:41 GMT):
Hi, I tried to install the indy repo locally. I received the following 3 failure messages: ``failures: high_cases::revoc_reg_def_requests::indy_revoc_reg_def_requests_works high_cases::schema_requests::indy_schema_requests_works medium_cases::schemas_requests::indy_get_schema_requests_works_for_default_submitter_did` I followed the steps for `How to build Indy SDK from source`. And somehow got to run the test using the following: `RUST_TEST_THREADS=1 cargo test`

jasoncys (Thu, 01 Apr 2021 09:48:41 GMT):
Hi, I tried to install the indy repo locally. I received the following 3 failure messages: `failures: high_cases::revoc_reg_def_requests::indy_revoc_reg_def_requests_works high_cases::schema_requests::indy_schema_requests_works medium_cases::schemas_requests::indy_get_schema_requests_works_for_default_submitter_did` I followed the steps for `How to build Indy SDK from source`. And somehow got to run the test using the following: `RUST_TEST_THREADS=1 cargo test`

jasoncys (Thu, 01 Apr 2021 09:48:41 GMT):
Hi, I tried to install the indy repo locally. I received the following 3 failure messages:``` ``` `failures: high_cases::revoc_reg_def_requests::indy_revoc_reg_def_requests_works high_cases::schema_requests::indy_schema_requests_works medium_cases::schemas_requests::indy_get_schema_requests_works_for_default_submitter_did` I followed the steps for `How to build Indy SDK from source`. And somehow got to run the test using the following: `RUST_TEST_THREADS=1 cargo test`

jasoncys (Thu, 01 Apr 2021 09:48:41 GMT):
Hi, I tried to install the indy repo locally. I received the following 3 failure messages:``` failures: high_cases::revoc_reg_def_requests::indy_revoc_reg_def_requests_works high_cases::schema_requests::indy_schema_requests_works medium_cases::schemas_requests::indy_get_schema_requests_works_for_default_submitter_did ``` I followed the steps for `How to build Indy SDK from source`. And somehow got to run the test using the following: `RUST_TEST_THREADS=1 cargo test`

jasoncys (Thu, 01 Apr 2021 10:18:49 GMT):
I managed to pass the test using ``` RUST_TEST_THREADS=1 cargo test --test ledger``` Can anyone please explain how it works?

chrisconway (Thu, 01 Apr 2021 18:00:35 GMT):
Has joined the channel.

chrisconway (Thu, 01 Apr 2021 18:00:35 GMT):
Hi, I attempted to import a did into a wallet using the indy-cli. I used a properly formatted import file, resembling json. When I execute the import, the verkey and did end up having the same value. Subsequently, I am incapable of writing to the ledger with that DID. I am attempting to use the did of a trustee in an indy network to do some admin work. Please help me resolve the issue and find the work around so I can continue. Thank you :)

swcurran (Fri, 02 Apr 2021 20:20:03 GMT):
Any ideas @WadeBarnes ?

jasoncys (Mon, 05 Apr 2021 07:07:44 GMT):
I managed to run the test "RUST_TEST_THREADS=1 cargo test" according to "https://github.com/hyperledger/indy-sdk/blob/master/docs/build-guides/ubuntu-build.md" successfully after installing Ubuntu 16.04 LTS. The only material difference is that I've installed python 3.6.13 prior to building everything from scratch.

WadeBarnes (Tue, 06 Apr 2021 11:51:46 GMT):
@chrisconway, Can you describe the process you are using for the import/export?

WadeBarnes (Tue, 06 Apr 2021 11:54:45 GMT):
The export process from the command line should follow this pattern: https://github.com/bcgov/von-network/blob/master/cli-scripts/export-wallet#L46-L53 and the import process should follow this pattern: https://github.com/bcgov/von-network/blob/master/cli-scripts/import-wallet#L45-L52

breno.medeiros (Tue, 06 Apr 2021 17:10:04 GMT):
Hi Sergey! I did just that, and it didn't work as i showed on the PrintScreen i posted in this thread on March 17. In case this PrintScreen has been auto deleted by RocketChat, i'm going to send this error(that happened after i did your instructions) again:

breno.medeiros (Tue, 06 Apr 2021 17:29:13 GMT):

ios-build.sh libindy

breno.medeiros (Tue, 06 Apr 2021 17:30:42 GMT):
Could you make a Call with me on GoogleMeet(or something) just so we can make this work? I guess it won't take that long for you to help me

antonden (Wed, 07 Apr 2021 18:05:07 GMT):
@breno.medeiros could you return `package="$1"` in code?

antonden (Wed, 07 Apr 2021 18:06:55 GMT):
and then run` ./ci/ios-build.sh libindy`

antonden (Wed, 07 Apr 2021 18:06:55 GMT):
and then run ` ./ci/ios-build.sh libindy`

droconnel22 (Tue, 13 Apr 2021 23:39:33 GMT):
Has joined the channel.

droconnel22 (Tue, 13 Apr 2021 23:39:33 GMT):
Hi All, my Java wrapper stopped working suddenly. I ran the .mac.build.sh for libindy successfully but I am stilil getting a LIbindy.api = null error. Does anyone know where I can find the latest version of the maven distributable for org.hyperledger.indy

droconnel22 (Tue, 13 Apr 2021 23:40:05 GMT):
I was using version: 1.10.1-dev-1219

droconnel22 (Tue, 13 Apr 2021 23:40:19 GMT):
I am not on the latest release of the indy-sdk

droconnel22 (Tue, 13 Apr 2021 23:40:57 GMT):

Clipboard - April 13, 2021 7:40 PM

droconnel22 (Tue, 13 Apr 2021 23:41:46 GMT):

Clipboard - April 13, 2021 7:41 PM

droconnel22 (Tue, 13 Apr 2021 23:41:56 GMT):
Thank you all : )

droconnel22 (Wed, 14 Apr 2021 00:49:36 GMT):
If I posted in the wrong channel, please accept my apologies.

andrew.whitehead (Wed, 14 Apr 2021 01:34:20 GMT):
I think this is the right channel, but I'm not sure who is using the java wrapper at the moment

ascatox (Wed, 14 Apr 2021 09:31:25 GMT):
Hi All, Is it possible to configure the ADDRESS to access Indy, in my setup Indy is on a VPS with public address. I'm developing a project using the .NET framework on my laptop, but I can't find any config file for Indy. Thanks in advance!!!

pranav_kirtani (Wed, 14 Apr 2021 11:41:16 GMT):
Can i change the key management system of indy to use HSM?

droconnel22 (Wed, 14 Apr 2021 13:08:19 GMT):
Thank you @andrew.whitehead

ianco (Thu, 15 Apr 2021 14:35:51 GMT):
FYI VCX tests are failing on all the PR's in the `indy-sdk` repo, is someone still supporting the VCX code in this repo?

LukaszSM88 (Thu, 15 Apr 2021 20:27:07 GMT):
Has joined the channel.

LukaszSM88 (Thu, 15 Apr 2021 21:36:47 GMT):
hi, how can I easiest start with indy-sdk ?? I need create 3 agents communicates via Aries channel in Java. What library should I use? Sorry for that questions, but I'm a novice in this topic

swcurran (Thu, 15 Apr 2021 22:21:10 GMT):
Depends a bit on your use case, but here are probably your two best options. For deploy on your infrastructure (on-prem or cloud), suggest you use Aries Cloud Agent Python -- https://github.com/hyperledger/aries-cloudagent-python. It provides all the Aries and Indy bits, and you can write your "controller" in Java -- talks to ACA-Py via HTTP. If you are good with your agents being provided by a service, one option is https://trinsic.id, that offer an "aries-agent-as-a-service". As with ACA-Py, you write your controller to an API. If you want to learn about being an Aries developer there is a Linux Foundation edX course, "Becoming an Aries Developer" that provides lots of info, built around (mostly) ACA-Py. https://www.edx.org/course/becoming-a-hyperledger-aries-developer

LukaszSM88 (Fri, 16 Apr 2021 06:15:14 GMT):
ok, I will check it. Thank you for reply

ascatox (Wed, 21 Apr 2021 07:57:17 GMT):
Hi All! I'm using a Mac M1, I tried to rebuild from source the libindy library to use with the mediator project. The build using the script mac.build.sh contained in the GH repo of the sdk works correctly but in the mediator framework, I encounter always the error _*Unhandled exception. System.DllNotFoundException: Unable to load shared library 'indy' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(libindy, 1): image not found at Hyperledger.Indy.WalletApi.NativeMethods.indy_create_wallet(Int32 command_handle, String config, String credentials, IndyMethodCompletedDelegate cb)*_

ascatox (Wed, 21 Apr 2021 07:57:17 GMT):
Hi All! I'm using a Mac M1, I tried to rebuild from source the libindy library to use with the mediator project. The build using the script mac.build.sh contained in the GH repo of the sdk works correctly but in the mediator framework, I encounter always the error _*`Unhandled exception. System.DllNotFoundException: Unable to load shared library 'indy' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(libindy, 1): image not found at Hyperledger.Indy.WalletApi.NativeMethods.indy_create_wallet(Int32 command_handle, String config, String credentials, IndyMethodCompletedDelegate cb)`*_

ascatox (Wed, 21 Apr 2021 07:57:49 GMT):
It may be a problem caused from the M1 arm64 architecture not fully supported????

egidio.casati (Mon, 26 Apr 2021 13:12:09 GMT):
Has joined the channel.

yeonsoochoi (Tue, 04 May 2021 14:09:56 GMT):
Has joined the channel.

yeonsoochoi (Tue, 04 May 2021 14:09:56 GMT):
Hello everyone, I am having trouble with *installing Indy-SDK*. I'd like to use Indy-SDK for Node.js. I've followed this(https://www.npmjs.com/package/indy-sdk#installing) step but there are several errors like `library not loaded: /usr/local/opt/lobsodium/lib/libsodium.18.dylib` the latest version of libsodium is libsodium.23.dylib but why indy-sdk try to load libsodium.18.dylib? I'm using mac OS (big sur) Thank you 🙂

dcspinho (Wed, 05 May 2021 23:32:49 GMT):
Has joined the channel.

dcspinho (Wed, 05 May 2021 23:33:23 GMT):
Hello. How can I connect to a remote pool using indy-cli?

brentzundel (Thu, 06 May 2021 17:23:54 GMT):
which pool are you wanting to connect to?

brentzundel (Thu, 06 May 2021 17:24:55 GMT):
also, in general indy-cli has pretty good guidance with the help command, which can also be used within specific commands

dcspinho (Mon, 10 May 2021 15:32:16 GMT):
Hello. I want to run 2 VMs and connect both to the pool.

dcspinho (Mon, 10 May 2021 15:34:49 GMT):
Hello. Can anyone help me how to generate primary key to create cred-def with Indy-cli. ledger cred-def schema_id= signature_type= [tag=] primary= [revocation=] [source_payment_address=] [fee=] [fees_inputs=] [fees_outputs=(,),..,(,)] [extra=] [sign=] [send=] [endorser=]

Takuro-Mine (Tue, 11 May 2021 05:42:35 GMT):
Has joined the channel.

Takuro-Mine (Tue, 11 May 2021 05:42:36 GMT):
Hello all . in get_started.py, anoncreds.py and crypto.py under indy-sdk/sample/python/, are you running libursa functions via libindy? If so, what is the location of the referenced libursa?

Takuro-Mine (Tue, 11 May 2021 05:42:36 GMT):
Hello all. In get_started.py, anoncreds.py and crypto.py under indy-sdk/sample/python/, are you running libursa functions via libindy? If so, what is the location of the referenced libursa?

Takuro-Mine (Tue, 11 May 2021 05:42:36 GMT):
Hello all. In getting_started.py, anoncreds.py and crypto.py under indy-sdk/sample/python/, are you running libursa functions via libindy? If so, what is the location of the referenced libursa?

brentzundel (Tue, 11 May 2021 17:08:39 GMT):
you want to create a local pool of multiple VMs?

dcspinho (Mon, 17 May 2021 09:03:39 GMT):
yes

brentzundel (Mon, 17 May 2021 16:56:40 GMT):
ah, with that you have reached the limit of my ability to help. I would recommend looking for indy-node documentation. If you are setting up a pool for testing indy-sdk, I recommend using one of the docker images floating around that spins up a pool of nodes.

lauravuo-techlab (Tue, 18 May 2021 07:12:17 GMT):
Hi all! When working with indy-sdk, we had some trouble when installing it to OSX. Fortunately one of our developers crafted a handy script for the installation to Mac. In case you are struggling with the same issues, I recommend you to check it out: https://github.com/findy-network/findy-wrapper-go#macos The same repository also contains an indy-sdk wrapper for golang, so it may interest fellow Gophers :slight_smile:

TimoGlastra (Tue, 18 May 2021 07:45:10 GMT):
Nice thanks for this. We've also been having some trouble and have reduced it to the following steps: https://github.com/animo/aries-framework-javascript/blob/docs/docs/libindy/macos.md But an automatic script is better of course :)

lauravuo-techlab (Tue, 18 May 2021 08:19:43 GMT):
Ok, thanks for the info! The part that was tricky was especially setting the deps path for the libindy.dylib - setting the DYLD_LIBRARY_PATH was not working for us (at least with GO build process).

kukgini (Tue, 18 May 2021 08:45:30 GMT):
Has left the channel.

yankeemaharjan (Tue, 18 May 2021 13:49:44 GMT):
Has joined the channel.

yankeemaharjan (Tue, 18 May 2021 13:49:45 GMT):
Hey guys, I am getting `LedgerRejectException` whenever I am trying to create a new schema on the ledger. It says `UnauthorizedClientRequest`

swcurran (Tue, 18 May 2021 15:12:53 GMT):
Depends what ledger you are writing to, and what DID you are using to sign the transaction, but chances are you are signing it with a DID that either not on the ledger, or one that is not on the ledger but does not have authority to write. On a Sovrin or VON Network ledger, the DID is not an endorser, so cannot write transactions.

yankeemaharjan (Wed, 19 May 2021 09:56:23 GMT):
Seems like it was due to trying to create the same Schema again

swcurran (Wed, 19 May 2021 14:33:55 GMT):
Interesting. Not the most obvious error message.

TimoGlastra (Thu, 20 May 2021 13:35:54 GMT):
How does the versioning in indy-sdk work at the moment? 1.16.0 was released a while ago, but master is still referencing 1.15.0. It seems like new CD releases are also releasing under version 1.15.0

TimoGlastra (Thu, 20 May 2021 13:35:59 GMT):

Clipboard - May 20, 2021 3:35 PM

WadeBarnes (Thu, 20 May 2021 13:37:19 GMT):
That issue will be resolved when this PR is merged; https://github.com/hyperledger/indy-sdk/pull/2361

WadeBarnes (Thu, 20 May 2021 13:38:00 GMT):
@ianco, could you look at updating the PR please. It's out of sync with the main branch.

WadeBarnes (Thu, 20 May 2021 13:39:03 GMT):
There are also updates on the main branch to remove the lib-vcx build/tests.

TimoGlastra (Thu, 20 May 2021 13:41:13 GMT):
Ah okay. Thanks!

ianco (Thu, 20 May 2021 13:43:47 GMT):
@WadeBarnes I'd prefer to not touch the `rc` branch in the hyperledger repo, since this is supposed to match the release

ianco (Thu, 20 May 2021 13:44:22 GMT):
I suggest that we close the existing PR, I'll update `rc` in my fork and then open a PR from my `rc` to `hyperledger/master`

WadeBarnes (Thu, 20 May 2021 13:44:39 GMT):
Works for me.

ianco (Thu, 20 May 2021 13:45:10 GMT):
ok I'm just doing some testing on my local now, I'll open a new PR shortly

WadeBarnes (Thu, 20 May 2021 13:45:26 GMT):
I agree with not touching the RC branch directly.

ianco (Thu, 20 May 2021 14:04:46 GMT):
https://github.com/hyperledger/indy-sdk/pull/2390

smithbk (Thu, 20 May 2021 20:56:49 GMT):
Hi, can anyone help. I'm running a test locally using the indy-sdk with the default sqlite wallet storage. This has worked in the past but has now started hanging during startup for some reason. The hang appears to happen the first time that I try to write via the wallet APIs. No other processes are running which have the sqlite.db file open and it appears to be an empty DB since I tried from scratch. That is, it created the sqlite.db file but that appears to be all. I've tried with v1.15.0 and v1.16.0 of the indy-sdk. All works fine when using postgres wallet storage. Does this hang sound familiar to anyone? Any help is appreciated. Thanks, Keith

WadeBarnes (Fri, 21 May 2021 14:48:32 GMT):
@TimoGlastra, @ianco's PR has been merged now. Let us know if there are any additional issues.

TimoGlastra (Fri, 21 May 2021 14:49:45 GMT):
Thanks for resolving so quickly!

WadeBarnes (Fri, 21 May 2021 14:50:46 GMT):
@ianco, Do we need to bump the version in `master` to an incremented `dev` version?

WadeBarnes (Fri, 21 May 2021 14:50:46 GMT):
@ianco, Do we need to bump the version in `master` to an incremented `dev` version now?

ianco (Fri, 21 May 2021 14:51:56 GMT):
Yes probably makes sense, I'm not sure what has been done in the past ... but changing the version in `master` to `1.17.0-pre` or something like that makes sense

WadeBarnes (Fri, 21 May 2021 14:53:46 GMT):
I know in `indy-node` it gets bumped to the next minor `dev` version; https://github.com/hyperledger/indy-node/blob/master/indy_node/__version__.json

WadeBarnes (Fri, 21 May 2021 14:56:23 GMT):
I'm not as familiar with the process for indy-sdk; https://github.com/hyperledger/indy-sdk/blob/master/docs/contributors/release-workflow.md

pmccabensds (Sat, 22 May 2021 17:33:21 GMT):
Has joined the channel.

pmccabensds (Sat, 22 May 2021 17:33:21 GMT):
Hello.. I'm trying to follow the process for creating a pull request found here: https://docs.google.com/presentation/d/1zbb1-4TjH1-iYN7LnFZyPWvB1w-YcoUwKYCfByugSE0/edit#slide=id.g23d83a3667_0_55 However, I am unable to create a Jira ticket for the indy-sdk project. The only projects to select from are several Fabric projects, Blockchain Explorer, Iroha and Sawtooth. Am I missing something ?

pmccabensds (Sat, 22 May 2021 17:38:55 GMT):
I opened an issue in Github and submitted a PR against it here: https://github.com/hyperledger/indy-sdk/pull/2392

pmccabensds (Sat, 22 May 2021 17:39:08 GMT):
however, not sure how to create a ticket in Jira to reference

rjones (Mon, 24 May 2021 13:46:42 GMT):
@pmccabensds there is no JIRA for Indy, that documentation is old. GitHub issues is the way to go - thank you!

TimoGlastra (Mon, 24 May 2021 14:47:59 GMT):
Hi all, could someone with write permissions take a look at this PR? https://github.com/hyperledger/indy-sdk/pull/2389

WadeBarnes (Tue, 25 May 2021 11:53:26 GMT):
Done

ianco (Tue, 25 May 2021 14:01:05 GMT):
I'm not sure Jira is used any more?

TimoGlastra (Tue, 25 May 2021 14:12:35 GMT):
Thanks!

rjones (Tue, 25 May 2021 14:55:06 GMT):
outside of Fabric, not really

PaulWen (Wed, 26 May 2021 18:52:37 GMT):
Has joined the channel.

sergio.anguita (Fri, 04 Jun 2021 08:07:42 GMT):
Has joined the channel.

sergio.anguita (Fri, 04 Jun 2021 08:08:40 GMT):
Hi, I've been working with indy for a while and I notice kind of inconsistency in pool genesis format. I mean that, some versions have the pool_genesis content in where services port numbering is defined as string and others as integer. The problem arises when you try to load one of those files to connect to the pool, because you will get a common invalid state error message. For example: the sandox pool genesis (https://raw.githubusercontent.com/sovrin-foundation/sovrin/stable/sovrin/pool_transactions_sandbox_genesis) has ports encoded as string, while built-in development pool included in indy-sdk repo, has them defined as integers (https://github.com/hyperledger/indy-sdk/blob/master/samples/nodejs/src/util.js). So, what is the correct data type for this field?

Yunxi 3 (Fri, 04 Jun 2021 12:44:40 GMT):
Hello all, which files in the indy-sdk deals with the wrapper for PostgreSQL db?

Yunxi 3 (Fri, 04 Jun 2021 12:44:40 GMT):
Hello all, which files in the indy-sdk deal with the wrapper for PostgreSQL db?

Yunxi 3 (Fri, 04 Jun 2021 12:44:40 GMT):
Hello all, which files in the indy-sdk deal with the wrapper for PostgreSQL db + details of how different data are stored to db?

Yunxi 3 (Fri, 04 Jun 2021 12:44:40 GMT):
Hello all, which files in the indy-sdk deal with the wrapper for PostgreSQL db + details of how different data are stored to db? Are there any technical/conceptual docs available explaining how different data are stored to db (e.g. using any encryption/decryption methods) ?

WadeBarnes (Fri, 04 Jun 2021 12:58:19 GMT):
@ianco ^

ianco (Fri, 04 Jun 2021 13:17:49 GMT):
The postgres plug-in is in https://github.com/hyperledger/indy-sdk/tree/master/experimental/plugins/postgres_storage

ianco (Fri, 04 Jun 2021 13:19:06 GMT):
The code that manages how data is stored, encrypted etc is in https://github.com/hyperledger/indy-sdk/tree/master/libindy/indy-wallet

ianco (Fri, 04 Jun 2021 13:19:40 GMT):
The docs are here: https://github.com/hyperledger/indy-sdk/tree/master/docs

ianco (Fri, 04 Jun 2021 13:20:49 GMT):
I'm not sure if there are any docs specific to your questions, but if you're new to indy-sdk it's probably a good idea to do a review of the docs first to get a general understanding. Wallets are handled using plug-ins, so most of the code is in libindy itself, and then the database-specific code si in the plug-in

Yunxi 3 (Fri, 04 Jun 2021 14:11:57 GMT):
thanks for the info @ianco , i'll take a look at these links :-)

Yunxi 3 (Fri, 04 Jun 2021 14:21:44 GMT):
@ianco , for the two modes mentioned in the doc: "MultiWalletSingleTable - all wallets are stored in single table in single database. Each wallet has its own connection pool. MultiWalletSingleTableSharedPool - all wallets are stored in single table in single database. The plugin will create only 1 connection pool reused by all wallets. This can be useful if intend to open many different wallets. Postgres has by default limitation of ~100 simultaneous connections and using this strategy you can limit number of DB connections significantly.", I wonder whether ACA-Py can provide better performance when using *MultiWalletSingleTableSharedPool* mode with 1 connection compared to *MultiWalletSingleTable* mode with each connection per wallet? Let's say we have 50 users simultaneously using their own wallet?

ianco (Fri, 04 Jun 2021 14:34:37 GMT):
You can specify the wallet mode in the configuration settings, aca-py just passes this straight through to indy-sdk which creates/manages the wallet

ianco (Fri, 04 Jun 2021 14:35:24 GMT):
In this example: https://github.com/hyperledger/aries-cloudagent-python/blob/main/demo/local-indy-args.yaml

ianco (Fri, 04 Jun 2021 14:36:18 GMT):
... just set `wallet-storage-config: '{"url":"localhost:5432","max_connections":5, "wallet_scheme": "MultiWalletSingleTableSharedPool"}'`

ianco (Fri, 04 Jun 2021 14:36:25 GMT):
(for example)

Yunxi 3 (Fri, 04 Jun 2021 15:00:39 GMT):
Hello @ianco , I might not express my question well. I know how to use a particular mode in practice, but trying to understand in theory or from you practical experience if any, can "MultiWalletSingleTable" provide *same or more performance* compared to "MultiWalletSingleTableSharedPool", as the "MultiWalletSingleTable" will only have *1 connection* for users to simultaneously use the system, but MultiWalletSingleTableSharedPool can support *at most 100 connections* for users?

Yunxi 3 (Fri, 04 Jun 2021 15:00:39 GMT):
Hello @ianco , I may not express my question well. I know how to use a particular mode in practice, but trying to understand in theory or from you practical experience if any, can "MultiWalletSingleTable" provide *same or more performance* compared to "MultiWalletSingleTableSharedPool", as the "MultiWalletSingleTable" will only have *1 connection* for users to simultaneously use the system, but MultiWalletSingleTableSharedPool can support *at most 100 connections* for users?

Yunxi 3 (Fri, 04 Jun 2021 16:21:52 GMT):

Clipboard - June 4, 2021 5:21 PM

Yunxi 3 (Fri, 04 Jun 2021 16:22:33 GMT):
Hello @ianco , i see the "wallet encryption" section is available on this page: https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/design/003-wallet-storage/README.html#, i wonder if there are any detailed descriptions on this topic available anywhere?

Yunxi 3 (Fri, 04 Jun 2021 16:22:33 GMT):
Hello @ianco , i see the "wallet encryption" section is available on this page: https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/design/003-wallet-storage/README.html#, i wonder I have questions below:if there are any detailed descriptions on this topic available anywhere?

Yunxi 3 (Fri, 04 Jun 2021 16:22:33 GMT):
Hello @ianco , i see the "wallet encryption" section is available on this page: https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/design/003-wallet-storage/README.html#, i wonder I have questions below: Q1. if there are any detailed descriptions on this topic available anywhere?

Yunxi 3 (Fri, 04 Jun 2021 16:24:39 GMT):
e.g. what are the plaintext values for "name", "value" and "type"? how the secret keys are designed in indy-sdk? I guess SHA256 is the encryption approach used, but does it used in indy-sdk or is it used by using Ursa?

Yunxi 3 (Fri, 04 Jun 2021 16:24:39 GMT):
e.g. what are the plaintext values for "name", "value" and "type"? how are secret keys designed in indy-sdk? I guess SHA256 is the encryption approach used, but does it used in indy-sdk or is it used by using Ursa?

Yunxi 3 (Fri, 04 Jun 2021 16:24:39 GMT):
Q2. what are the plaintext values for "name", "value" and "type"? Q3. how are secret keys designed in indy-sdk? Q4. I guess SHA256 is the encryption approach used, but does it used in indy-sdk or is it used by using Ursa?

Yunxi 3 (Fri, 04 Jun 2021 16:26:12 GMT):
the items table has a column called "key", is it used to store the encryption key for each row? why do other tables not have this column?

Yunxi 3 (Fri, 04 Jun 2021 16:26:12 GMT):
the *items* table has a column called "key", is it used to store the encryption key for each row? why do other tables not have this column?

Yunxi 3 (Fri, 04 Jun 2021 16:26:12 GMT):
the *items* table has a column called "key", is it used to store the encryption key for each row? why do other tables (i.e. metadata, tags_encrypted) not have this column?

Yunxi 3 (Fri, 04 Jun 2021 16:26:12 GMT):
Q5. the *items* table has a column called "key", is it used to store the encryption key for each row? Q6. why do other tables (i.e. metadata, tags_encrypted) not have this column?

Yunxi 3 (Fri, 04 Jun 2021 16:28:04 GMT):
what are the general purpose for the four tables (i.e. items, metadata, tag_encrypted and tags_plaintext)?

Yunxi 3 (Fri, 04 Jun 2021 16:28:04 GMT):
Q7. what are the general purpose for the four tables (i.e. items, metadata, tag_encrypted and tags_plaintext)?

conanoc (Mon, 07 Jun 2021 05:16:30 GMT):
Applications connect to indy-pool (https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/indy-walkthrough.md#step-2-connecting-to-the-indy-nodes-pool). Is it possible to connect to a specific indy-node not a pool?

Yunxi 3 (Mon, 07 Jun 2021 08:59:55 GMT):
Hello @swcurran , do you know the answers for my questions above. This might be related to a ticket: https://github.com/hyperledger/aries-cloudagent-python/issues/1054 raised by me months ago, but I don't see any updates on it.

Yunxi 3 (Mon, 07 Jun 2021 08:59:55 GMT):
Hello @swcurran , do you know the answers for my questions above. They are related to a ticket: https://github.com/hyperledger/aries-cloudagent-python/issues/1054 raised by me months ago, but I don't see any updates on it.

WadeBarnes (Mon, 07 Jun 2021 12:39:57 GMT):
Short answer is, No.

WadeBarnes (Mon, 07 Jun 2021 12:41:14 GMT):
The nodes work together to form consensus.

sergio.anguita (Mon, 07 Jun 2021 14:26:35 GMT):
whats the point of connecting to specific node?

sergio.anguita (Mon, 07 Jun 2021 14:26:35 GMT):
@conanoc whats the point of connecting to specific node?

swcurran (Mon, 07 Jun 2021 20:46:04 GMT):
Sorry for the lack of response. Your question is a good one, and issue request for documentation is something that needs to be done. Generally, we've just read the code in the Indy SDK to try to understand it -- but haven't spent enough time to get it into a better form. I'm going to attach your questions to the issue and see if we can get some answers.

conanoc (Tue, 08 Jun 2021 03:11:34 GMT):
Actually, There are many reasons node selection is preferred. First, we need to consider the region. Apps in Asia would better to connect to the nodes in Asia. Second, All nodes do not run on the machines with the same CPU power, network bandwidth. I would need a node with high performance if I have heave traffic. Third, companies in the consortium would want to run their own nodes and use their own nodes.

conanoc (Tue, 08 Jun 2021 03:11:34 GMT):
Actually, There are many reasons node selection is preferred. First, we need to consider the region. Apps in Asia would better connect to the nodes in Asia. Second, All nodes do not run on the machines with the same CPU power, network bandwidth. I would need a node with high performance if I have heave traffic. Third, companies in the consortium would want to run their own nodes and use their own nodes.

sergio.anguita (Tue, 08 Jun 2021 09:11:50 GMT):
right now, the only customization is to choose how many nodes you want to interact when opening a ledger connection. In order to support your requirements, libindy needs to be modified. Did you open a new ticket in JIRA explaining your issue? If properly proposed, it might be implemented in next releases, because it might make sense for read operations.

sergio.anguita (Tue, 08 Jun 2021 09:11:50 GMT):
@conanoc right now, the only customization is to choose how many nodes you want to interact when opening a ledger connection. In order to support your requirements, libindy needs to be modified. Did you open a new ticket in JIRA explaining your issue? If properly proposed, it might be implemented in next releases, because it might make sense for read operations.

sergio.anguita (Tue, 08 Jun 2021 09:16:15 GMT):
is there any plans on the roadmap to release a Go SDK for libindy? Or is aries-framework-go capable enough to support all indy operations?

conanoc (Wed, 09 Jun 2021 05:05:09 GMT):
@sergio.anguita "preordered_nodes" mentioned here(https://github.com/hyperledger/indy-sdk/blob/master/docs/configuration.md#pool) seems to be what I'm looking for. Could I use this option?

conanoc (Wed, 09 Jun 2021 05:09:19 GMT):
Defining credentials using indy-cli has this form: ledger cred-def schema_id=1 signature_type=CL tag=1 primary={"n":"1","s":"2","rms":"3","r":{"age":"4","name":"5"},"rctxt":"6","z":"7"} What is primary and how can I get this?

swcurran (Wed, 09 Jun 2021 13:51:41 GMT):
What level are you interested in? AFAIK -- that is what is returned from creating a Claim Def in the indy-sdk, and then passed to indy-node in the CLAIM_DEF write transaction. For most devs, that's a cryptographic black box, including the signing keys for the claims and some other parameters.

WadeBarnes (Wed, 09 Jun 2021 14:11:10 GMT):
You can't create a `CRED_DEF` directly in the `indy-cli`, that is why we added some tooling in `von-network`'s `indy-cli` wrapper; https://github.com/bcgov/von-network

WadeBarnes (Wed, 09 Jun 2021 14:11:42 GMT):
Have a look at https://github.com/bcgov/von-network/blob/master/docs/Writing%20Transactions%20to%20a%20Ledger%20for%20an%20Un-privileged%20Author.md

WadeBarnes (Wed, 09 Jun 2021 14:12:59 GMT):
It will give you an idea of the process, and where/when the `primary` gets generated.

WadeBarnes (Wed, 09 Jun 2021 14:14:27 GMT):
https://github.com/bcgov/von-network/blob/master/cli-scripts/cred_def.py#L125-L133

WadeBarnes (Wed, 09 Jun 2021 14:14:27 GMT):
https://github.com/bcgov/von-network/blob/master/cli-scripts/cred_def.py#L118-L133

WadeBarnes (Wed, 09 Jun 2021 14:22:03 GMT):
To answer the question before it's asked; Yes, it would make sense for `CRED_DEF` creation functionality to be implemented in the `indy-cli` and/or it's successor.

conanoc (Thu, 10 Jun 2021 06:43:54 GMT):
@WadeBarnes Thank you. You answered one of my future questions. I have another. What will happen if I use arbitrary primary? I don't know what's the use of the primary.

sergio.anguita (Thu, 10 Jun 2021 10:46:49 GMT):
those nodes will get priority upon others, so i think it fits your needs

sergio.anguita (Thu, 10 Jun 2021 10:49:07 GMT):
but be aware that indy read and write tx does not behave same way

WadeBarnes (Thu, 10 Jun 2021 11:31:59 GMT):
Your schema txn will likely fail. The primary is cryptographically tied to the cred def.

tusharbansal (Sun, 13 Jun 2021 18:36:21 GMT):
Has joined the channel.

MichelGiroldo (Mon, 21 Jun 2021 12:28:29 GMT):
Has joined the channel.

MichelGiroldo (Mon, 21 Jun 2021 12:28:30 GMT):
Hey there, how is it going? I'm trying to embed an aca-py hyperledger aries into a raspberry Pi 4 but I'm having issues with libindy. I tried with and without docker, used builx for build to arm architecture and tried too follow the tutorial on https://wiki.hyperledger.org/pages/viewpage.action?pageId=16319019, but didn't worked Now I'm using a docker image and the log returned are these: ....... 2021-06-18 14:10:53,387 indy.libindy ERROR loadcdll: Can't load libindy: libindy.so: cannot open shared object file: No such file or directory 2021-06-18 14:10:53,396 aries_cloudagent.commands.start ERROR Exception during startup: Traceback (most recent call last): File "/usr/local/lib/python3.6/dist-packages/aries_cloudagent/commands/start.py", line 72, in init await startup File "/usr/local/lib/python3.6/dist-packages/aries_cloudagent/commands/start.py", line 28, in start_app await conductor.setup() File "/usr/local/lib/python3.6/dist-packages/aries_cloudagent/core/conductor.py", line 91, in setup self.root_profile, self.setup_public_did = await wallet_config(context) File "/usr/local/lib/python3.6/dist-packages/aries_cloudagent/config/wallet.py", line 40, in wallet_config profile = await mgr.open(context, profile_cfg) File "/usr/local/lib/python3.6/dist-packages/aries_cloudagent/indy/sdk/profile.py", line 161, in open opened = await indy_config.open_wallet() File "/usr/local/lib/python3.6/dist-packages/aries_cloudagent/indy/sdk/wallet_setup.py", line 169, in open_wallet credentials=json.dumps(self.wallet_access), File "/usr/local/lib/python3.6/dist-packages/indy/wallet.py", line 127, in open_wallet open_wallet.cb) File "/usr/local/lib/python3.6/dist-packages/indy/libindy.py", line 29, in do_call err = getattr(_cdll(), name)(command_handle, File "/usr/local/lib/python3.6/dist-packages/indy/libindy.py", line 128, in _cdll cdll.cdll = load_cdll() File "/usr/local/lib/python3.6/dist-packages/indy/libindy.py", line 160, in loadcdll raise e File "/usr/local/lib/python3.6/dist-packages/indy/libindy.py", line 155, in loadcdll res = CDLL(libindy_name) File "/usr/lib/python3.6/ctypes/__init__.py", line 348, in init self._handle = dlopen(self.name, mode) OSError: libindy.so: cannot open shared object file: No such file or directory Shutting down 2021-06-18 14:10:53,418 asyncio ERROR Task exception was never retrieved future: .done() done, defined at /usr/local/lib/python3.6/dist-packages/aries_cloudagent/commands/start.py:77> exception=AttributeError("'NoneType' object has no attribute 'context'",)> Traceback (most recent call last): File "/usr/local/lib/python3.6/dist-packages/aries_cloudagent/commands/start.py", line 79, in done await shutdown File "/usr/local/lib/python3.6/dist-packages/aries_cloudagent/commands/start.py", line 35, in shutdown_app await conductor.stop() File "/usr/local/lib/python3.6/dist-packages/aries_cloudagent/core/conductor.py", line 354, in stop multitenant_mgr = self.context.inject(MultitenantManager, required=False) File "/usr/local/lib/python3.6/dist-packages/aries_cloudagent/core/conductor.py", line 80, in context return self.root_profile.context AttributeError: 'NoneType' object has no attribute 'context' ....... Has anyone done something like that and had this kind of problem?

WadeBarnes (Mon, 21 Jun 2021 13:18:41 GMT):
@MichelGiroldo, have a look over on the #aries-embedded channel.

WadeBarnes (Mon, 21 Jun 2021 13:20:50 GMT):
The process in the tutorial you were following has not worked in a while.

sergio.anguita (Tue, 22 Jun 2021 11:15:12 GMT):
I got a tx rejected error using indy-sdk multi sign methods, anyone tried them before and can point me how to solve the issue? https://github.com/hyperledger/indy-sdk/issues/2401

WadeBarnes (Tue, 22 Jun 2021 12:12:21 GMT):
@sergio.anguita, I asked seom questions on the issue.

WadeBarnes (Tue, 22 Jun 2021 12:12:21 GMT):
@sergio.anguita, I asked some questions on the issue.

sergio.anguita (Tue, 22 Jun 2021 12:20:10 GMT):
@WadeBarnes ill follow on the issue with more details. thanks

lynn.bendixsen (Thu, 24 Jun 2021 18:36:52 GMT):
I checked out the issue also and responded with what I think the root cause of the issue is. (Cannot use STEWARD as ENDORSER)

WadeBarnes (Thu, 24 Jun 2021 18:40:45 GMT):
Thanks Lynn

pranavkirtani88 (Wed, 30 Jun 2021 12:19:13 GMT):
Has joined the channel.

pranavkirtani88 (Wed, 30 Jun 2021 12:19:14 GMT):
I want to create a REST service using indy-sdk, what is a good way to scale indy.openwallet?

WadeBarnes (Wed, 30 Jun 2021 12:37:12 GMT):
You might want to have a look at; https://github.com/hyperledger/aries-cloudagent-python

WadeBarnes (Wed, 30 Jun 2021 12:39:58 GMT):
That project has already done a lot of the heavy lifting to create a higher level interface around Indy operations, and has already solved some (not all just yet) of the scaling issues you'll encounter working with the indy-sdk directly.

WadeBarnes (Wed, 30 Jun 2021 12:44:36 GMT):
Under the covers it's using the indy-sdk, but there are efforts to migrate to a newer set of shared libraries that separate out functionality from the indy-sdk into discrete libraries (for better maintainability) and are being developed to further address scalability issues found in the indy-sdk.

WadeBarnes (Wed, 30 Jun 2021 23:28:37 GMT):
For anyone receiving an error like the following. We are aware of the issue and are working toward a resolution. I'll update the community when the issue has been resolved. Thank you for your patience. ``` The following signatures were invalid: EXPKEYSIG E8BDBE36C8C97811 Sovrin-Repo-Master (Master key for repo.sovring.org) Reading package lists... GPG error: https://repo.sovrin.org/sdk/deb bionic InRelease: The following signatures were invalid: EXPKEYSIG E8BDBE36C8C97811 Sovrin-Repo-Master (Master key for repo.sovring.org) E: The repository 'https://repo.sovrin.org/sdk/deb bionic InRelease' is not signed. ------ executor failed running [/bin/sh -c apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CE7709D068DB5E88 && apt-get update && apt-get install -y software-properties-common && apt-get update && add-apt-repository 'deb https://repo.sovrin.org/sdk/deb bionic stable' && apt-get update && apt-get install -y libindy && apt-get install -y libnullpay]: exit code: 100 ```

lynn.bendixsen (Wed, 30 Jun 2021 23:31:08 GMT):
Thanks for working on getting this fixed Wade!

MikeSmith (Thu, 01 Jul 2021 05:19:21 GMT):
Has joined the channel.

TimoGlastra (Thu, 01 Jul 2021 14:54:50 GMT):
That explains why our CI is failing. Thanks!

wenjing (Thu, 01 Jul 2021 22:46:13 GMT):
If you haven't figured this out yet, I'd guess it's the same problem below that @WadeBarnes is working on. You probably didn't install libindy successfully because of the expired key.

wenjing (Thu, 01 Jul 2021 22:47:38 GMT):
We got this too.

WadeBarnes (Fri, 02 Jul 2021 00:30:57 GMT):
Quick update. The signing key for the repo was updated earlier today. We’re still tracking down an issue with the new key not being recognized even though it looks like things were updated in the repo.

WadeBarnes (Fri, 02 Jul 2021 00:38:40 GMT):
It might not be related. You need to build Indy-SDK from source due to some necessary updates. There is more info on that in #aries-embedded

WadeBarnes (Fri, 02 Jul 2021 00:38:40 GMT):
It might not be related. You need to build Indy-SDK from source on the RPi due to some necessary updates. There is more info on that in #aries-embedded

WadeBarnes (Fri, 02 Jul 2021 12:16:28 GMT):
The issues with the expired GPG signatures on `repo.sovrin.org` have been resolved.

WadeBarnes (Fri, 02 Jul 2021 12:16:34 GMT):
The issues with the expired GPG signatures on `repo.sovrin.org` have been resolved.

echsecutor (Fri, 02 Jul 2021 12:24:44 GMT):
Has joined the channel.

sergey.khoroshavin (Mon, 05 Jul 2021 08:19:30 GMT):
Has joined the channel.

sergey.khoroshavin (Mon, 05 Jul 2021 08:23:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=BDvAJAAqhZ9aDMg54) I wonder - is any action is required on client side (like importing another public key), or it should work automatically? Reason why I'm asking is that this still seems to be broken on my and my colleagues machines...

sergey.khoroshavin (Mon, 05 Jul 2021 08:34:39 GMT):
Okay, it started working for me after running ```sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 97080EBDA5D46DAF```

WadeBarnes (Mon, 05 Jul 2021 16:38:25 GMT):
@sergey.khoroshavin, You should be able to reference the root key like this `apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CE7709D068DB5E88` rather than referencing the new `subkey` directly as above. That way you'll get any new signing keys automatically as they are added.

rafaelandradegs (Mon, 05 Jul 2021 16:42:26 GMT):
Has joined the channel.

deulu (Thu, 08 Jul 2021 10:00:45 GMT):
Has joined the channel.

AniketDhar (Wed, 14 Jul 2021 19:15:54 GMT):
Has joined the channel.

AniketDhar (Thu, 15 Jul 2021 14:49:08 GMT):
the apt dependencies to libsodium are not solvable. Any help on the dependencies used for apt install indy-cli and indy-node wouild be appreciated.

mccown (Thu, 15 Jul 2021 14:49:41 GMT):
The Identity Implementer's WG is starting at the top of the hour (9am MT / 3pm UTC). Today, Timo Glastra (Co-Founder, Animo Solutions) is presenting on their OSS & SSI work and how they are using that in a national collaboration to help citizen volunteers during emergencies. Zoom: https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09 Wiki: https://wiki.hyperledger.org/display/IWG/2021-07-15+%3A+Identity+Implementers+WG+Call

lynn.bendixsen (Thu, 15 Jul 2021 18:42:01 GMT):
Here is a document that describes the installation of both the cli and Node. If you have specific issues after reading this, then post details here and we'll see if we can help some more. https://docs.google.com/document/d/1y0rW78_I-bRkH3qFN5kcP58jJH23Zahc363h18SmJ48/edit

lynn.bendixsen (Thu, 15 Jul 2021 18:42:01 GMT):
Here is a document that describes the installation of both the cli and Node on Ubuntu. If you have specific issues after reading this, then post details here and we'll see if we can help some more. https://docs.google.com/document/d/1y0rW78_I-bRkH3qFN5kcP58jJH23Zahc363h18SmJ48/edit

lynn.bendixsen (Thu, 15 Jul 2021 18:43:54 GMT):
This document is my notes for installing the CLI on other platforms: https://docs.google.com/document/d/1mJ3r3uH9jIWkA59X6bV7eWUlWmQ0NerSuPSFv4Lh7vQ/edit#heading=h.hdfj5odxmp7o

Prerana72 (Tue, 20 Jul 2021 11:53:33 GMT):
Has joined the channel.

Prerana72 (Tue, 20 Jul 2021 11:53:34 GMT):
Hello Team, We are developing edge agent for android. We are using libindy library for android taken from " https://repo.sovrin.org/android/libindy/stable/1.16.0/". When we try to store the credentials using indy_prover_store_credential, we see the following error- "indyorg.hyperledger.indy.sdk.InvalidStructureException: A value being processed is not valid." Please note that we have ensured the following: 1. we are passing valid JSON string values for all the input params. For "rev_reg_def_json" we passed null. 2. ensured the JSON strings carry the value null instead of "null", whereever applicable. Any pointers to how we can find out which param may be causing the issue? The library does not specify that in the error. We tried to build the libindy for android by adding few logs. But we could not successfully compile it. The 'cargo build' is successful but the 'build-libindy-android.sh' is failing with error - "can't open file 'build/tools/make_standalone_toolchain.py' :[Errno 2] No such file or directory?" We are building on ubuntu 20.0.4. Did anyone face this issue or knows what could be the issue?

AmarSrivastava1 (Mon, 26 Jul 2021 10:41:29 GMT):
Has joined the channel.

AmarSrivastava1 (Mon, 26 Jul 2021 10:41:29 GMT):
How aries connects to indy node and where the schema definition is present??

WadeBarnes (Tue, 27 Jul 2021 13:07:41 GMT):
That question is better asked on the #aries channel. That said, if you go through the tutorials in https://github.com/hyperledger/aries-cloudagent-python, you'll get a better idea.

sergio.anguita (Wed, 28 Jul 2021 11:21:49 GMT):
who knows what are the restrictions to build an edge agent in Android using libindy shared libraries? I mean, im trying to create an application to be compatible from Android 4.4 Kitkat onwards and Im getting a runtime library load error identified as "java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "signal" referenced by "libindy.so"..". Note that, same code works on latest android devices. Thats why Im asking for further restrictions apart from compatible arm architecture: x86_64, arm64-v8a, armeabi-v7a. Is it compatible with Android 4.4? Advice appreciated. thanks

mccown (Thu, 29 Jul 2021 03:54:00 GMT):
The Identity Implementer's WG is meeting today / tomorrow (July 28th @ 9am MT / 3pm UTC). In this call, we will review updates from several industry WGs, which you may have missed. This week, Horacio Nunez (Kiva) will present an overview of Kiva’s SSI work and how it drives their innovative products. Wiki: https://wiki.hyperledger.org/display/IWG/2021-07-29+%3A+Identity+Implementers+WG+Call Zoom: https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

TimoGlastra (Thu, 29 Jul 2021 15:49:37 GMT):

Clipboard - July 29, 2021 5:49 PM

TimoGlastra (Thu, 29 Jul 2021 15:51:44 GMT):

Clipboard - July 29, 2021 5:51 PM

bizsecure (Thu, 29 Jul 2021 15:59:53 GMT):
Ditto

bizsecure (Thu, 29 Jul 2021 15:59:53 GMT):
Ditto, we are experiencing the same.

swcurran (Thu, 29 Jul 2021 16:15:39 GMT):
It will get addressed, but unfortunately, @WadeBarnes is offline right now. More to come.

swcurran (Thu, 29 Jul 2021 16:24:13 GMT):
Odd that the server and repo itself is online. It's the path to the maven repository that is missing. Sounds like the publishing is not working. https://repo.sovrin.org/

rjones (Thu, 29 Jul 2021 17:21:33 GMT):
I see that Indy has images on Artifactory, but not maven. https://hyperledger.jfrog.io/ui/repos/tree/General/indy

rjones (Thu, 29 Jul 2021 17:21:59 GMT):
fabric and besu, for example, do use maven: https://hyperledger.jfrog.io/ui/repos/tree/General/fabric-maven

WadeBarnes (Fri, 30 Jul 2021 11:44:05 GMT):
Looking into this.

WadeBarnes (Fri, 30 Jul 2021 18:14:03 GMT):
The repository is back on-line. Please test.

WadeBarnes (Fri, 30 Jul 2021 18:14:45 GMT):
The repository is back on-line. Please test.

TimoGlastra (Fri, 30 Jul 2021 21:57:13 GMT):
Confirmed to be working again! Thanks @WadeBarnes :)

swcurran (Fri, 30 Jul 2021 22:01:55 GMT):
Stellar job by @WadeBarnes on this. A previously undocumented server was restarted and a dependency referenced in the startup script no longer existed. He adjusted the script and all is well. And of course, the server is now documented.... Took a little longer than planned because he was out of the office yesterday.

conanoc (Tue, 03 Aug 2021 09:56:17 GMT):
`Wallet.openWallet().get()` takes about 10sec on my android phone. Is it normal? Is there any reason why it takes so much time?

conanoc (Tue, 03 Aug 2021 09:56:17 GMT):
`Wallet.openWallet().get()` takes about 10sec on my android phone. Is it normal? Any idea why it takes so much time?

shaanjot.gill (Tue, 03 Aug 2021 18:48:40 GMT):
Has joined the channel.

shaanjot.gill (Wed, 04 Aug 2021 14:59:18 GMT):
I am working on implementing a mechanism in ACA-Py to verify `state_proof` for read requests as part of multiple Indy ledger support. I am able to create the `trie` as a `dict` but I am not able to find the key in there. *Indy SDK response* https://gist.github.com/shaangill025/2425a0ef3fd36c48814b05edfd353826 *Trie dict* https://gist.github.com/shaangill025/40a7362cb5d5cfd1eae3c5919290dada

shaanjot.gill (Wed, 04 Aug 2021 15:40:56 GMT):
I am working on implementing a mechanism in ACA-Py to verify `state_proof` for read requests as part of multiple Indy ledger support. I am able to create the `trie` as a `dict` but I am not able to find the key in there. *Indy SDK response* https://gist.github.com/shaangill025/2425a0ef3fd36c48814b05edfd353826 *Trie dict* https://gist.github.com/shaangill025/40a7362cb5d5cfd1eae3c5919290dada I tried with keys `b'2hoqvcwupRTUNkXn6ArYzs:2:test-licence:4.4.4'` and `b'2471'`. The `expected_value` of `{"lsn":2471,"lut":1526055830,"val":{"attr_names":["age","height","name","sex"]}}`. I can see `[b' .4.4', b'\xf8R\xb8P{"lsn":2471,"lut":1526055830,"val":{"attr_names":["age","height","name","sex"]}}']` node.

andrew.whitehead (Wed, 04 Aug 2021 16:20:04 GMT):
`b'\xf8R\xb8P{"lsn":2471,"lut":1526055830,"val":{"attr_names":["age","height","name","sex"]}}'` appears to be a double-msgpack-encoded `'{"lsn":2471,"lut":1526055830,"val":{"attr_names":["age","height","name","sex"]}}'`

andrew.whitehead (Wed, 04 Aug 2021 16:21:45 GMT):
Well, not quite, but something like that

shaanjot.gill (Thu, 05 Aug 2021 00:54:05 GMT):
@andrew.whitehead Yes, I noticed that too, the issue I have is with coming up with a valid key and using it to get a value from `subtrie` dict and then matching that with the `expected_value` I have just implemented a bit different approach which I have tested with `GET_SCHEMA_RESPONSE` and `GET_CRED_DEF_RESPONSE` reply and believe it is working. - create the `subtrie` from `proof_nodes` same as above - iterate through `dict_keys` - for each key, apply `rlp_decode(subtrie.get(key)`. If `length` of `list` is 2 and `unpack_to_nibbles(list[0])[-1] == 16` [meaning it is a `leaf node`], then check if `rlp_decode(list[1])==expected_value` to verify `spv` [to handle double encoding].

andrew.whitehead (Thu, 05 Aug 2021 00:56:10 GMT):
Yeah I was just looking at the trie stuff a bit, the encoding is confusing. I saw this library but it doesn't seem to handle deserialization https://github.com/lovesh/Merkle-Patricia-Trie Sounds like you've mostly got that figured out though

shaanjot.gill (Thu, 05 Aug 2021 00:58:13 GMT):
Yes, I did use this as a reference for my implementation.

swcurran (Thu, 05 Aug 2021 15:04:33 GMT):
Lovesh was one of the implementers, I think -- he was with Evernym at the time. Perhaps an issue on that repo might get a response?

manfredmeyer (Thu, 12 Aug 2021 09:28:23 GMT):
Has joined the channel.

manfredmeyer (Thu, 12 Aug 2021 09:28:23 GMT):
Hi all. Are there any java classes available that model the json structure of the transactions described here: https://hyperledger-indy.readthedocs.io/projects/node/en/latest/transactions.html Or is there an OpenAPI spec of these json structures so I could generate a java model from it?

mccown (Thu, 12 Aug 2021 13:47:15 GMT):
Just a reminder that the Identity Implementer’s WG call is cancelled for today (Aug 12th). Please join us for our next meeting on Aug 26th. Thanks!

fdiarra (Tue, 24 Aug 2021 11:08:27 GMT):
Has joined the channel.

pranavkirtani88 (Wed, 25 Aug 2021 06:14:05 GMT):
I am performance testing indy, but when I test issuerCreateCredential it seems to be very slow, is there anyway to speed up the performance?

pSchlarb (Wed, 25 Aug 2021 10:31:19 GMT):
Has joined the channel.

mccown (Wed, 25 Aug 2021 19:48:10 GMT):
The Identity Implementer's WG is meeting today / tomorrow (Aug 26th @ 9am MT / 3pm UTC). In this call, we will review updates from several industry WGs, which you may have missed. This week, Horacio Nunez (Kiva) will present a new open source desktop tool that will connect secure biometrics with SSI-powered backend services. Wiki: https://wiki.hyperledger.org/display/IWG/2021-08-26+%3A+Identity+Implementers+WG+Call Zoom: https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

mccown (Wed, 25 Aug 2021 19:48:10 GMT):
The Identity Implementer's WG is meeting tomorrow (Aug 26th @ 9am MT / 3pm UTC). In this call, we will review updates from several industry WGs, which you may have missed. This week, Horacio Nunez (Kiva) will present a new open source desktop tool that will connect secure biometrics with SSI-powered backend services. Wiki: https://wiki.hyperledger.org/display/IWG/2021-08-26+%3A+Identity+Implementers+WG+Call Zoom: https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

kangme (Fri, 03 Sep 2021 22:11:34 GMT):
Hi! I am Meng Kang, a Master’s student in Electrical Engineering supervised by Dr.Victria Lemieux. We are looking for people with a background in blockchain, cryptography, or software engineering to volunteer for an anonymous survey. You will first watch a presentation video of our software design research project ‘A Decentralized Identity-Based Blockchain Solution for Privacy-Preserving Licensing of Individual-Owned Data to Prevent Unauthorized Secondary Data Usage’, and then provide your feedback by filling out an online questionnaire. Here is the link for the presentation video: https://drive.google.com/file/d/1X7epdOwUB0SvDOlKrDeGU8l8eKwWSiLd/view?usp=sharing Here is the link to the survey: https://ubc.ca1.qualtrics.com/jfe/form/SV_3C4Yp2FPiHufmM6 Here is the PDF version of the video: https://docs.google.com/presentation/d/1pbjmTVxWe6HQ4Jge-qR0-xS3nn2rIRAW/edit?usp=sharing&ouid=105944806570308548495&rtpof=true&sd=true The video will take you 20 minutes to watch, and the survey will take you another 20 minutes to complete. Thank you for your time and feedback on our research. Please contact me via meng.kang@ubc.ca if you have further interest in this study.

bh4rtp (Sun, 05 Sep 2021 15:09:11 GMT):
Has joined the channel.

mccown (Wed, 08 Sep 2021 17:53:23 GMT):
The Identity Implementer's WG is meeting tomorrow (Sep 9th @ 9am MT / 3pm UTC). In this call, we will review updates from several industry WGs, which you may have missed. This week, Jim StClair (Lumedic.io) will present an overview of how SSI technologies are progressing through ISO/TC 307 to become a part of ISO standards. Wiki: https://wiki.hyperledger.org/display/IWG/2021-09-9+%3A+Identity+Implementers+WG+Call Zoom: https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

IgorSim (Wed, 22 Sep 2021 09:45:00 GMT):
Has joined the channel.

mccown (Wed, 22 Sep 2021 20:07:27 GMT):
The Identity Implementer's WG is meeting tomorrow (Sep 23rd @ 9am MT / 3pm UTC). In this call, we will review updates from several SSI industry WGs. This week, Xavier Vila (SICPA) will present an overview of SICPA and their efforts to create and launch new identity solutions. Wiki: https://wiki.hyperledger.org/display/IWG/2021-09-23+%3A+Identity+Implementers+WG+Call Zoom: https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Prerana72 (Thu, 23 Sep 2021 13:57:13 GMT):
Hi team, We are using stable libindy.so for android and see some issue with storing credentials on wallet. For debugging, We are trying to build the libindy for android following the steps mentioned here (https://github.com/hyperledger/indy-sdk/blob/master/docs/build-guides/android-build.md), with additional logs. We used v1.15 of source code from github for this. We were able to build it, but are seeing a different error while in the call to indy_add_wallet_record. This error was not seen when we used the stable libindy from here(https://repo.sovrin.org/android/libindy/stable/1.15.0/) So, the question is, how are the stable build libraries built? Are there different scripts to generate them? We followed the steps mentioned in the github link above.

MiryangJung (Thu, 23 Sep 2021 14:12:57 GMT):
Has joined the channel.

MiryangJung (Thu, 23 Sep 2021 14:12:57 GMT):
how can i get schema list and definition list? I try `getDidMetadata[schemas]` but not exist function in indy-sdk. > https://github.com/hyperledger/indy-sdk/blob/113b79cd64a238130d20e19b972326f72047c550/wrappers/nodejs/README.md#getdidmetadata--wh-did----metadata

morticianmili (Fri, 24 Sep 2021 09:55:18 GMT):
Hello everyone, I hope this is the right place to ask. Right now, I'm going through the Indy Walkthrough and getting_started.py (https://github.com/hyperledger/indy-sdk/blob/master/samples/python/src/getting_started.py). Before Alice requests the transcript from Faber, she gets the credential definition from the ledger (line 287). Then, before storing the credential in her wallet, she again calls get_cred_def() with the same input parameters (line 317). Why is this necessary?

vsadriano (Wed, 29 Sep 2021 10:29:55 GMT):
Has left the channel.

conanoc (Thu, 30 Sep 2021 08:31:55 GMT):
It is not necessary. Nodejs example use the credential definition for both places.

conanoc (Thu, 30 Sep 2021 08:31:55 GMT):
It is not necessary. Nodejs example use the same credential definition for both places.

baxihemant (Mon, 11 Oct 2021 01:44:36 GMT):
Has joined the channel.

moisesjaramillo (Tue, 12 Oct 2021 01:54:41 GMT):
Has joined the channel.

lauravuo-techlab (Tue, 12 Oct 2021 08:18:02 GMT):
We needed to tune our Docker image building a bit to get the indy-sdk working also on M1 Macs. Read more from the blog: https://findy-network.github.io/blog/2021/09/20/the-arm-adventure-on-docker/

rjones (Tue, 12 Oct 2021 20:00:00 GMT):
@lauravuo-techlab We (Hyperledger) have an M1 Mac we can plug into your repo for CI/CD if needed

lauravuo-techlab (Wed, 13 Oct 2021 05:59:23 GMT):
thanks, I think we resolved all our issues by adding support for arm64-platform in our image building pipeline

conanoc (Mon, 18 Oct 2021 10:02:21 GMT):
I tried to build iOS wrapper manually, `pod install` from `indy-sdk/wrappers/ios/libindy-pod` failed with error: ``` $ pod install Analyzing dependencies Fetching podspec for `CoreBitcoin` from `https://raw.github.com/oleganza/CoreBitcoin/master/CoreBitcoin.podspec` Downloading dependencies Installing CoreBitcoin (0.6.8.1) Installing ISO8601DateFormatter (0.8) Installing OpenSSL (1.0.210) [!] /bin/bash -c set -e VERSION="1.0.2j" SDKVERSION=`xcrun --sdk iphoneos --show-sdk-version 2> /dev/null` MIN_SDK_VERSION_FLAG="-miphoneos-version-min=7.0" BASEPATH="${PWD}" CURRENTPATH="/tmp/openssl" ARCHS="i386 x86_64 armv7 armv7s arm64" DEVELOPER=`xcode-select -print-path` mkdir -p "${CURRENTPATH}" mkdir -p "${CURRENTPATH}/bin" cp "file.tgz" "${CURRENTPATH}/file.tgz" cd "${CURRENTPATH}" tar -xzf file.tgz cd "openssl-${VERSION}" for ARCH in ${ARCHS} do CONFIGURE_FOR="iphoneos-cross" if [ "${ARCH}" == "i386" ] || [ "${ARCH}" == "x86_64" ] ; then PLATFORM="iPhoneSimulator" if [ "${ARCH}" == "x86_64" ] ; then CONFIGURE_FOR="darwin64-x86_64-cc" fi else sed -ie "s!static volatile sig_atomic_t intr_signal;!static volatile intr_signal;!" "crypto/ui/ui_openssl.c" PLATFORM="iPhoneOS" fi export CROSS_TOP="${DEVELOPER}/Platforms/${PLATFORM}.platform/Developer" export CROSS_SDK="${PLATFORM}${SDKVERSION}.sdk" echo "Building openssl-${VERSION} for ${PLATFORM} ${SDKVERSION} ${ARCH}" echo "Please stand by..." export CC="${DEVELOPER}/usr/bin/gcc -arch ${ARCH} ${MIN_SDK_VERSION_FLAG}" mkdir -p "${CURRENTPATH}/bin/${PLATFORM}${SDKVERSION}-${ARCH}.sdk" LOG="${CURRENTPATH}/bin/${PLATFORM}${SDKVERSION}-${ARCH}.sdk/build-openssl-${VERSION}.log" LIPO_LIBSSL="${LIPO_LIBSSL} ${CURRENTPATH}/bin/${PLATFORM}${SDKVERSION}-${ARCH}.sdk/lib/libssl.a" LIPO_LIBCRYPTO="${LIPO_LIBCRYPTO} ${CURRENTPATH}/bin/${PLATFORM}${SDKVERSION}-${ARCH}.sdk/lib/libcrypto.a" ./Configure ${CONFIGURE_FOR} --openssldir="${CURRENTPATH}/bin/${PLATFORM}${SDKVERSION}-${ARCH}.sdk" > "${LOG}" 2>&1 sed -ie "s!^CFLAG=!CFLAG=-isysroot ${CROSS_TOP}/SDKs/${CROSS_SDK} !" "Makefile" make >> "${LOG}" 2>&1 make all install_sw >> "${LOG}" 2>&1 make clean >> "${LOG}" 2>&1 done echo "Build library..." rm -rf "${BASEPATH}/lib/" mkdir -p "${BASEPATH}/lib/" lipo -create ${LIPO_LIBSSL} -output "${BASEPATH}/lib/libssl.a" lipo -create ${LIPO_LIBCRYPTO} -output "${BASEPATH}/lib/libcrypto.a" echo "Copying headers..." rm -rf "${BASEPATH}/opensslIncludes/" mkdir -p "${BASEPATH}/opensslIncludes/" cp -RL "${CURRENTPATH}/openssl-${VERSION}/include/openssl" "${BASEPATH}/opensslIncludes/" cd "${BASEPATH}" echo "Building done." echo "Cleaning up..." rm -rf "${CURRENTPATH}" echo "Done." cp: file.tgz: No such file or directory ```

conanoc (Wed, 20 Oct 2021 05:15:25 GMT):
libzmq cocoapod also seems to be broken. I'm using Xcode13. Any idea? ``` $ pod spec lint https://raw.githubusercontent.com/hyperledger/indy-sdk/master/Specs/libzmq/4.2.3/libzmq.podspec.json -> libzmq (4.2.3) - WARN | github_sources: Github repositories should end in `.git`. - ERROR | xcodebuild: Returned an unsuccessful exit code. You can use `--verbose` for more information. - NOTE | xcodebuild: note: Using new build system - NOTE | xcodebuild: note: Using codesigning identity override: - - NOTE | xcodebuild: note: Build preparation complete - NOTE | xcodebuild: note: Planning - NOTE | xcodebuild: note: Building targets in parallel - NOTE | [iOS] xcodebuild: /var/folders/kt/6nhgy2ss2pl96m8vypm8xtlr0000gn/T/CocoaPods-Lint-20211020-2136-q4esna-libzmq/App.xcodeproj: warning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 15.0.99. (in target 'App' from project 'App') - NOTE | [iOS] xcodebuild: Pods.xcodeproj: warning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 15.0.99. (in target 'libzmq' from project 'Pods') - NOTE | xcodebuild: libzmq/src/precompiled.hpp:33:10: fatal error: 'platform.hpp' file not found - NOTE | [iOS] xcodebuild: Pods.xcodeproj: warning: The iOS Simulator deployment target 'IPHONEOS_DEPLOYMENT_TARGET' is set to 8.0, but the range of supported deployment target versions is 9.0 to 15.0.99. (in target 'Pods-App' from project 'Pods') - NOTE | xcodebuild: note: Using codesigning identity override: - NOTE | [OSX] xcodebuild: Pods.xcodeproj: warning: The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.7, but the range of supported deployment target versions is 10.9 to 11.3.99. (in target 'libzmq' from project 'Pods') - NOTE | [OSX] xcodebuild: Pods.xcodeproj: warning: The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.7, but the range of supported deployment target versions is 10.9 to 11.3.99. (in target 'Pods-App' from project 'Pods') - NOTE | [OSX] xcodebuild: /var/folders/kt/6nhgy2ss2pl96m8vypm8xtlr0000gn/T/CocoaPods-Lint-20211020-2136-q4esna-libzmq/App.xcodeproj: warning: The macOS deployment target 'MACOSX_DEPLOYMENT_TARGET' is set to 10.7, but the range of supported deployment target versions is 10.9 to 11.3.99. (in target 'App' from project 'App') Analyzed 1 podspec. [!] The spec did not pass validation, due to 1 error and 1 warning. ```

Prerana72 (Thu, 21 Oct 2021 05:29:27 GMT):
@gudkov we are observing errors while storing the credentials in wallet in the indy_prover_store_credential api. We had tried both 1.15.0 and 1.16.0 indy-sdk libraries. We even tried to build the libIndy following the instructions in the above link. However that caused different set of errors. We have raised git hub issues as well regarding this and the git hub issue numbers are 2429 and 2430. Can you help us with this issue.

conanoc (Thu, 21 Oct 2021 06:23:34 GMT):
It was because of the pod cache. It succeeded after the removal of the cache. The reason for the wrong cache was that cmake was not installed on my mac when I ran install for the first time.

conanoc (Thu, 21 Oct 2021 06:48:55 GMT):
It is because of that OpenSSL pod is not compatible with the new version of cocoapods. The maintainer of the pod seems to out of touch. https://github.com/FredericJacobs/OpenSSL-Pod/issues/49

conanoc (Thu, 21 Oct 2021 06:48:55 GMT):
It is because the OpenSSL pod is not compatible with the new version of cocoapods. The maintainer of the pod seems to be out of touch. https://github.com/FredericJacobs/OpenSSL-Pod/issues/49

mccown (Thu, 21 Oct 2021 14:34:11 GMT):
Quick Reminder (due to time changes): The Identity Implementer's WG is meeting at the top of the hour. Wiki: https://wiki.hyperledger.org/display/IWG/2021-10-21+%3A+Identity+Implementers+WG+Call Zoom: https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

veerendrab (Wed, 03 Nov 2021 11:46:17 GMT):
Has joined the channel.

mccown (Wed, 03 Nov 2021 19:50:32 GMT):
The Identity Implementer's WG is meeting tomorrow (Nov 4th @ 9am MT / 3pm UTC). We will review a number of updates and milestones from several SSI industry WGs. I will also be giving a presentation on how to auto-generate language wrappers from Rust libraries (e.g., DIDComm_rs, indy-sdk, etc.). Wiki: https://wiki.hyperledger.org/display/IWG/2021-11-04+%3A+Identity+Implementers+WG+Call Zoom: https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

conanoc (Thu, 11 Nov 2021 05:30:00 GMT):
Is the indy-sdk github repo still maintained? I created a PR a week ago, but didn't get any response.

rjones (Thu, 11 Nov 2021 14:33:48 GMT):
@conanoc I just added a reviewer, but I see there are a lot of pending PRs with no review

kukgini (Fri, 12 Nov 2021 02:53:54 GMT):
Has joined the channel.

kukgini (Fri, 12 Nov 2021 05:29:31 GMT):
@conanoc I think they still maintain indy-sdk because a lot of things happening here. see: https://wiki.hyperledger.org/display/indy/Indy+Contributors+Meeting

kukgini (Fri, 12 Nov 2021 06:04:54 GMT):
conanoc I think they still maintain indy-sdk because a lot of things happening here. see: https://wiki.hyperledger.org/display/indy/Indy+Contributors+Meeting

kukgini (Fri, 12 Nov 2021 06:04:54 GMT):
@conanoc I think they still maintain indy-sdk because a lot of things happening here. see: https://wiki.hyperledger.org/display/indy/Indy+Contributors+Meeting

kukgini (Wed, 17 Nov 2021 23:40:42 GMT):
Hi @conanoc I found this https://github.com/hyperledger/indy-sdk/pull/2329/files from comtribution calls (https://wiki.hyperledger.org/display/indy/2021-10-26+Indy+Contributors+Call). Maybe they probably won't put much effort into it. Check out the new projects that aligned with it

mccown (Thu, 18 Nov 2021 12:49:12 GMT):
The Identity Implementer’s WG meeting for today (11/18) has been cancelled. Please join us in our next meeting on Dec 2nd (9am MT / 4pm UTC).

ffendt (Tue, 23 Nov 2021 07:52:37 GMT):
Has joined the channel.

ffendt (Tue, 23 Nov 2021 07:52:38 GMT):
Hi there, are there already any plans for a new release of `indy-sdk` in the near future? I'm currently using aries cloudagent python in Docker behind a company proxy and need to use a socks proxy (see [resolved issue 2399](https://github.com/hyperledger/indy-sdk/issues/2399) ) to be able to connect to the ledger.

WadeBarnes (Tue, 23 Nov 2021 14:44:23 GMT):
@swcurran, @ianco, Any thoughts on a new `indy-sdk` release?

ianco (Tue, 23 Nov 2021 16:16:39 GMT):
I think it would need a bit of testing, indy-sdk hasn't had a lot of attention recently. (Also there are a lot of PR's in the backlog)

mccown (Thu, 02 Dec 2021 05:34:57 GMT):
The Identity Implementer’s WG meeting for today (12/2) has been cancelled. Please join us in our next meeting on Dec 16th (9am MT / 4pm UTC).

mccown (Thu, 16 Dec 2021 00:24:34 GMT):
The final Identity Implementer's WG of 2021 is (tomorrow) Thurs Dec 16th @ 9am MT / 3pm UTC. In addition to reviewing several updates from some key SSI industry WGs, Daniel Hardman (SICPA) will be presenting on the new Gossyp Protocol. Wiki: https://wiki.hyperledger.org/display/IWG/2021-12-16+%3A+Identity+Implementers+WG+Call Zoom: https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

Anasalamin (Mon, 27 Dec 2021 11:51:02 GMT):
Has joined the channel.

ffendt (Fri, 14 Jan 2022 09:58:31 GMT):
Hi there, I created a PR with a tiny bugfix (https://github.com/hyperledger/indy-sdk/pull/2461) and the jenkins build for the PR failed. Is there any way I can find out why the build failed?

WadeBarnes (Fri, 14 Jan 2022 13:52:42 GMT):
Builds are failing due to this issue; https://github.com/hyperledger/indy-sdk/issues/2460

ffendt (Mon, 17 Jan 2022 07:35:37 GMT):
Oh, thanks for the hint. Then I'll probably wait until that is solved first

WadeBarnes (Thu, 20 Jan 2022 00:13:43 GMT):
The PR to fix the `indy-sdk` Jenkins builds is ready; https://github.com/hyperledger/indy-sdk/pull/2470 cc @ianco There are a couple of the GitHub actions builds that are failing, I have not looked into those yet.

rjones (Thu, 20 Jan 2022 15:36:34 GMT):
@WadeBarnes any thoughts on this? https://chat.hyperledger.org/channel/guides?msg=uAJ3jKEqm3dakrgWi

WadeBarnes (Thu, 20 Jan 2022 15:42:41 GMT):
It looks like the links are malformed. The examples exist here; https://github.com/hyperledger/indy-sdk/tree/master/docs/how-tos/write-did-and-query-verkey

rjones (Thu, 20 Jan 2022 15:44:58 GMT):
OK. Looks like the documentation needs updated

WadeBarnes (Thu, 20 Jan 2022 17:03:51 GMT):
Anyone that has submitted a PR to the https://github.com/hyperledger/indy-sdk repo in the past and has seen this build failure message on their PR:

WadeBarnes (Thu, 20 Jan 2022 17:03:53 GMT):

Clipboard - January 20, 2022 9:03 AM

WadeBarnes (Thu, 20 Jan 2022 17:06:18 GMT):
You will need to rebase your commits on the latest version of `indy-sdk` (`2d2140f06369ecdb037f0f275df2862a917d64a3`). It contains the fixes for the issues with the breaking builds, and your PRs will not build properly until they reference that revision as their base.

weiiv (Mon, 24 Jan 2022 17:05:30 GMT):
Has joined the channel.

conanoc (Thu, 27 Jan 2022 07:45:51 GMT):
I have a few questions about `indy_register_wallet_storage` API. 1. Most wrappers(ex, nodejs, java wrappers) do not provide an API for `indy_register_wallet_storage`. Is there any reason? 2. Is there any samples using `indy_register_wallet_storage` except postgres_storage plugin? 3. I'm considering running three web server instances as a credential issuer. Each web server could use default storage for its wallet, each has the same issuer DID stored in its local wallet, each issue credentials with the same credential-definition. I think it will not work properly because the three wallets are separated, so the separated issuers will not be able to generate proper `credential revocation id`s. Am I right? Is the revocation the only issue with these same-did-separate-wallet-issuers?

swcurran (Thu, 27 Jan 2022 14:13:42 GMT):
That would not work. In Indy code, you can create a DID using a seed, so you could have all three instances use the same DID. However, you cannot do that with a ClaimDef -- the keys generated are from a random seed. So each ClaimDef would be different in the separate storage instances, and the one on the ledger would match only one. You have to have all three instances sharing the same storage. I don't know about the first questions....we do have multiple instances of ACA-Py that share the same storage all the time. But we always use Postgres.

c2bo (Thu, 27 Jan 2022 17:12:15 GMT):
Has joined the channel.

conanoc (Fri, 28 Jan 2022 01:48:33 GMT):
I agree with you for the ClaimDef issue. But, I could copy the wallet file which has the ClaimDef keys to other instances as a work around to handle this.

swcurran (Fri, 28 Jan 2022 14:59:06 GMT):
Agreed, but not sure why go to the trouble/risk. Risk if you have to later merge them because you create another CredDef and have to get it into alll three wallets. Doable, but...

Rizary (Sat, 05 Feb 2022 03:25:23 GMT):
Has joined the channel.

rjones (Fri, 11 Feb 2022 23:22:04 GMT):
this chat has moved to discord https://discord.gg/hyperledger

rjones (Sat, 12 Feb 2022 22:03:28 GMT):
[Please move to Discord](https://discord.com/channels/905194001349627914/905205711850594336)

rjones (Sat, 12 Feb 2022 22:03:28 GMT):
[Please get an account on the Hyperledger discord](https://discord.gg), then [join Indy](https://discord.com/channels/905194001349627914/905205711850594336)