rjones (Thu, 13 Apr 2017 18:35:43 GMT):
nage

peacekeeper (Thu, 13 Apr 2017 19:18:47 GMT):
Has joined the channel.

anttikettunen (Thu, 13 Apr 2017 19:50:41 GMT):
Has joined the channel.

stevetolman (Thu, 13 Apr 2017 20:00:37 GMT):
Has joined the channel.

devin-fisher (Thu, 13 Apr 2017 20:25:24 GMT):
Has joined the channel.

danielhardman (Fri, 14 Apr 2017 02:01:56 GMT):
Has joined the channel.

luca.boldrin (Fri, 14 Apr 2017 05:35:37 GMT):
Has joined the channel.

farooq_m_khan (Fri, 14 Apr 2017 05:37:05 GMT):
Has joined the channel.

Sean_Bohan (Mon, 17 Apr 2017 17:02:44 GMT):
Has joined the channel.

VipinB (Tue, 18 Apr 2017 14:34:19 GMT):
Has joined the channel.

cbruguera (Sun, 23 Apr 2017 21:29:11 GMT):
Has joined the channel.

tkuhrt (Tue, 25 Apr 2017 15:23:59 GMT):
Has joined the channel.

nage (Thu, 27 Apr 2017 14:38:39 GMT):
Just a reminder that there is a Ledger WG call today in 22 minutes here https://zoom.us/j/730665163

nage (Thu, 27 Apr 2017 14:38:39 GMT):
Just a reminder that there is a Sovrin Ledger WG call today in 22 minutes here https://zoom.us/j/730665163

denofernandes (Thu, 27 Apr 2017 15:13:55 GMT):
Has joined the channel.

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

rjones (Mon, 01 May 2017 18:31:46 GMT):
Has left the channel.

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

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

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

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

prashiyn (Thu, 11 May 2017 05:46:40 GMT):
Has joined the channel.

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

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

danielhardman (Thu, 11 May 2017 15:13:07 GMT):
Ledger WG call notes: we are currently merging recent changes with a "3-phase commit" feature in sovrin-node, and also a "state trie" feature.

danielhardman (Thu, 11 May 2017 15:15:42 GMT):
These features introduce batching into Indy, which provides important performance benefits. State trie also makes it possible for us to receive a single response to the query, instead of the F+1 responses required by consensus. The single response is trustworthy because it contains at least F+1 digital signatures. Also, state trie makes it possible to prove that the answer to a query is the latest correct answer (has not been superseded at any time since the point when it was correct).

danielhardman (Thu, 11 May 2017 15:16:13 GMT):
The merge is complex, and we spent some time on the call discussing implications for testing, risks of disruption in the master branch, etc.

nage (Thu, 11 May 2017 15:16:24 GMT):
_notes that the call is in the same Zoom room as two weeks ago https://zoom.us/j/730665163_

danielhardman (Thu, 11 May 2017 15:25:48 GMT):
We have discovered an additional change that is part of the same sequence of commits as the stuff we're trying to merge. This additional change may need to be separated from the rest of the logic by reordering commits or something.

danielhardman (Thu, 11 May 2017 15:26:54 GMT):
Discussion about sovrin network roles and permissions. Used this doc: https://docs.google.com/spreadsheets/d/1uSxqZ5tzAiervgrLQn4FGlUhD-5YbxAbZkG4GdzjPtM/edit?usp=sharing

danielhardman (Thu, 11 May 2017 15:32:51 GMT):
Q: should "TGB member" have any role in the system at all?

danielhardman (Thu, 11 May 2017 15:53:03 GMT):
We discussed and concluded that at most, a TGB member should have the privilege to propose an upgrade. Also discussed signing .deb files with a PGP key using an ED25519 curve, where key is stored on our ledger.

danielhardman (Thu, 11 May 2017 16:03:29 GMT):
Also discussed whether any of the governance rules baked into code today need to become configurable (in the config ledger rather than config files, to make the rules public and uniform across all participants)

Skorpion7777 (Thu, 11 May 2017 20:35:00 GMT):
Has joined the channel.

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

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

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

nage (Thu, 25 May 2017 01:56:58 GMT):
We have an Indy Node WG meeting tomorrow (Thursday May 25th at 9:00 Mountain Time (UTC-6). We are going to be discussing input validation, alpha/provisional network status, the shakedowns and hardening efforts we are doing (and how you could help), along with other topics proposed in this channel. See you at https://zoom.us/j/730665163 when it is time :)

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

nage (Thu, 25 May 2017 14:51:15 GMT):
WG meeting starts in 10 minutes https://zoom.us/j/730665163

nage (Thu, 25 May 2017 15:00:35 GMT):
and it is time! :)

nage (Thu, 25 May 2017 15:33:47 GMT):
https://github.com/hyperledger/indy-sdk

nage (Thu, 25 May 2017 15:38:21 GMT):
https://jira.hyperledger.org/secure/RapidBoard.jspa?rapidView=133&projectKey=INDY

nage (Thu, 25 May 2017 15:43:24 GMT):
Going through the introduction to shakedowns now

nage (Thu, 25 May 2017 15:46:51 GMT):
The shakedowns span all the indy code, so the communication is happening in the #indy channel

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

nage (Thu, 25 May 2017 15:57:08 GMT):
@here Please feel free to ask questions, we don't expect Jason to talk the whole time :P

apoikola (Sat, 27 May 2017 15:31:45 GMT):
Has joined the channel.

srottem (Mon, 29 May 2017 20:59:50 GMT):
Has joined the channel.

mhailstone (Wed, 31 May 2017 22:55:46 GMT):
Has joined the channel.

nage (Thu, 08 Jun 2017 14:53:48 GMT):
The WG meeting starts in 7 minutes here: https://zoom.us/j/730665163

nage (Thu, 08 Jun 2017 15:00:26 GMT):
and it is time!

nage (Thu, 08 Jun 2017 15:00:49 GMT):
@here The Indy-Node WG meeting starts now

nage (Thu, 08 Jun 2017 15:03:10 GMT):
Last week's slides https://docs.google.com/presentation/d/1nSycZWusg3BwyRXesq711s2-xnyrpjJIUaoNLMvZt9w/edit?usp=sharing

nage (Thu, 08 Jun 2017 15:17:57 GMT):
We discussed the difference between Sovrin and Hyperledger Indy (the instance of Indy as a global public utility and the code base respectively)

nage (Thu, 08 Jun 2017 15:18:16 GMT):
Drummond discussed the trust framework and how the Alpha and provisional networks relate to that trust framework

nage (Thu, 08 Jun 2017 15:18:38 GMT):
the Alpha network is a deployment that is intended for stress testing and will be public (please come help test and harden the system)

nage (Thu, 08 Jun 2017 15:20:37 GMT):
Expect that the Alpha network will be reset at least once before the deployment of the provisional network The provisional network is the network that can be used for real identities. At this point the network should be immutable (will not be reset).

nage (Thu, 08 Jun 2017 15:21:08 GMT):
Looking to move from Alpha to the Provisional network in July

nage (Thu, 08 Jun 2017 15:21:31 GMT):
(standard open source "it is ready when it is ready" applies here)

nage (Thu, 08 Jun 2017 15:21:47 GMT):
(the more folks that can help, the faster it can happen)

nage (Thu, 08 Jun 2017 15:25:14 GMT):
@danielhardman will be posting links here to how to help get started

danielhardman (Thu, 08 Jun 2017 15:26:40 GMT):
Here are instructions about how to set up a pool of your own, in which you can conduct destructive tests: https://github.com/evernym/sovrin-environments/blob/master/vagrant/training/vb-multi-vm/TestSovrinClusterSetup.md

danielhardman (Thu, 08 Jun 2017 15:27:20 GMT):
Here is a doc that lists some input validation experiments we'd love to have people try: https://docs.google.com/document/d/1ae6Ud64gUjl-YC3ADDU5KuW_A-kPS9l9g6FGJCylFCs/edit

danielhardman (Thu, 08 Jun 2017 15:28:13 GMT):
Info about what stewards will be doing to start up the Alpha network: https://docs.google.com/document/d/1Da6adGCoRhCntQwPQPzz1H1dJRHAmgyyDi0k01ncvuw/edit

nage (Thu, 08 Jun 2017 15:29:45 GMT):
@danielhardman the input validation requirements document does not appear to be public

danielhardman (Thu, 08 Jun 2017 15:32:13 GMT):
Here's a revised link for the Steward setup on the Alpha network doc: https://docs.google.com/document/d/1cWVSNaoLRqX1TY-5ZsOViPB4-Jg_J8Ri0_3npjTMFYY/edit?usp=sharing

nage (Thu, 08 Jun 2017 15:39:26 GMT):
Discussion about how to start into testing and log tickets associated with issues found (links posted above are related)

nage (Thu, 08 Jun 2017 15:39:39 GMT):
Drummond addressed the question about how to find a trust anchor and get an identity

danielhardman (Thu, 08 Jun 2017 15:41:24 GMT):
Here is the other doc I mentioned, that has about a hundred experiments we'd like to do: https://docs.google.com/spreadsheets/d/1Y1GOOuuzpDWMovUB4ogTgumoliR0uqwUXphV65461aU/edit?usp=sharing

nage (Thu, 08 Jun 2017 15:43:01 GMT):
If you need to get ids (or NYMs) or need to have a trust anchor, speak up on #indy and we'll figure out how to get you what you need

nage (Thu, 08 Jun 2017 15:43:31 GMT):
There are plans for a voting ledger to make getting onboarded more automatic

nage (Thu, 22 Jun 2017 03:20:42 GMT):
We have an Indy Node WG meeting tomorrow (Thursday at 9:00 Mountain Time). We are going to continue the discussion on alpha/provisional network status and hardening efforts we are doing (and how you could help), along with other topics proposed in this channel. See you at https://zoom.us/j/730665163 when it is time!

nage (Thu, 22 Jun 2017 03:20:51 GMT):
@here ^^^

harrihoo (Thu, 22 Jun 2017 10:53:22 GMT):
Has joined the channel.

himansri (Thu, 22 Jun 2017 11:16:38 GMT):
Has joined the channel.

ashcherbakov (Thu, 22 Jun 2017 14:41:27 GMT):
Has joined the channel.

nage (Thu, 22 Jun 2017 14:46:39 GMT):
The WG call starts in 14 minutes https://zoom.us/j/730665163

wightman (Thu, 22 Jun 2017 14:48:34 GMT):
Has joined the channel.

nage (Thu, 22 Jun 2017 14:57:01 GMT):
@here T-4 minutes

nage (Thu, 22 Jun 2017 15:04:28 GMT):
@LoveshHarchandani go ahead

LoveshHarchandani (Thu, 22 Jun 2017 15:04:29 GMT):
Has joined the channel.

nage (Thu, 22 Jun 2017 15:05:14 GMT):
Lovesh: for the last two weeks we have been working on the election process and the view change

nage (Thu, 22 Jun 2017 15:05:34 GMT):
...: this protocol had a few problems so we have moved to a simpler version of round-robin leader selection

nage (Thu, 22 Jun 2017 15:06:18 GMT):
...: a bunch of view change problems were also uncovered under load, where the protocol could get stuck (state wasn't being communicated properly during the view change)

nage (Thu, 22 Jun 2017 15:06:35 GMT):
...: we discussed 4 different approaches from PBFT, and settled on the simplest one

nage (Thu, 22 Jun 2017 15:06:52 GMT):
...: we are almost done with that change and are hoping to raise those changes into master next week

nage (Thu, 22 Jun 2017 15:07:23 GMT):
...: one more thing that we've been wondering about is our quorum sizes, we've been doing 2f+1 and f+1, but if the n value isn't exactly 3f+1 this creates some problems

nage (Thu, 22 Jun 2017 15:07:57 GMT):
...: the 2f+1 number is fine, but the f+1 doesn't create an intersecting quorum with the writes and reads

nage (Thu, 22 Jun 2017 15:08:47 GMT):
...: so we're looking at (f+n+2)/2 as an alternative for prepare and commit quorums and then n-f for the view change quorums

nage (Thu, 22 Jun 2017 15:09:00 GMT):
...: thanks to the Fabric guys for pointing us to the code where they are using these numbers

nage (Thu, 22 Jun 2017 15:09:46 GMT):
...: this brings us to the discussion of pre-prepare and how preprepare right now can prevent us from moving to the prepare stage

nage (Thu, 22 Jun 2017 15:10:03 GMT):
...: so far we've been trying to move speculatively, but looking at other implementations it looks like we actually can do this

nage (Thu, 22 Jun 2017 15:10:24 GMT):
...: these are the protocol change that we are looking at making in the next few weeks

nage (Thu, 22 Jun 2017 15:11:52 GMT):
jlaw : asked some questions to clarify why the changes help. Lovesh expounded on why the read/write and preprepare/prepare quorums need to be sized to provide the needed protocol guarantees.

nage (Thu, 22 Jun 2017 15:13:04 GMT):
@LoveshHarchandani will send out an email to the hyperledger-indy mailing list for further questions and discussion

nage (Thu, 22 Jun 2017 15:14:59 GMT):
alex: added information on how some of these changes are going to proceed

nage (Thu, 22 Jun 2017 15:15:48 GMT):
...: on improving the view change, our current approach is based on the catch-up process of asking about missing transactions which was only started on node startup. Now during view change we trigger catch up.

nage (Thu, 22 Jun 2017 15:16:12 GMT):
...: it looks like the improvements to view change also leads to some good enhancements to the catch up code process

nage (Thu, 22 Jun 2017 15:19:45 GMT):
jlaw: mentioned an optimization about how catch up can take care of any issues that could arise due to having what would currently be considered to be an insufficient number of pre-prepares

nage (Thu, 22 Jun 2017 15:20:50 GMT):
lovesh: For the view change, we had a comprehensive document about the 4 approaches with discussion about the different options. Can we make this public?

nage (Thu, 22 Jun 2017 15:21:05 GMT):
nage: so long as the reviewers know it is public, that sounds like a great idea

nage (Thu, 22 Jun 2017 15:23:42 GMT):
luca: Is the provisional nodes network run by the provisional nodes hard enough to run a real load?

nage (Thu, 22 Jun 2017 15:24:11 GMT):
lovesh: it depends on what a resonable load is, but it general the answer is yes.

nage (Thu, 22 Jun 2017 15:24:43 GMT):
...: mostly we're looking to find the edge cases, like what happens with view changes under high load. We've found some unexpected issues around those, and expect there might be more.

nage (Thu, 22 Jun 2017 15:25:04 GMT):
...: we have performance testing to help prove we can handle load, so please try things and report issues.

nage (Thu, 22 Jun 2017 15:26:00 GMT):
jlaw: the big reasons for these view change fixes were caused by this hardening process. We found issues that needed these changes. The current alpha network doesn't have all these fixes yet. Those fixes should go out during this coming week.

nage (Thu, 22 Jun 2017 15:26:26 GMT):
alex: yes, the next release that is in a week should have these view change fixes

nage (Thu, 22 Jun 2017 15:27:17 GMT):
...: there is a development flag that allows you to disable view changes, and when you do this you can do 10,000s of transactions. Hopefully with the view change fixes we can get to that load without turning the view changes off.

nage (Thu, 22 Jun 2017 15:28:19 GMT):
jlaw: there are configurations called "unsafe" that disable characteristics and requirements of the protocol to help with testing. These are labeled this because they are *very* unsafe and shouldn't ever be used in production, but allows us to test things faster (and identify if things proceed correctly when nodes don't behave).

nage (Thu, 22 Jun 2017 15:30:27 GMT):
jlaw: there are known issues under certain conditions and loads where the alpha network won't survive, so don't throw tons of work at it without coordinating with other folks (#indy is a good place to coordinate those efforts)

nage (Thu, 22 Jun 2017 15:31:37 GMT):
jlaw: there are some specialized scripts for testing, I wonder if all of those scripts are in the repo or if they are on someone's local machine. If anyone has test or load scripts that can be shared, we should make sure they are in the repo.

nage (Thu, 22 Jun 2017 15:31:54 GMT):
alex: there are some good scripts in the sovrin-node repo (eventually to migrate to indy-node)

nage (Thu, 22 Jun 2017 15:32:13 GMT):
alex: there are a bunch more of these scripts that will be added as part of merging in these view change fixes

nage (Thu, 22 Jun 2017 15:33:26 GMT):
jlaw: I've talked with several folks who have some methods for this testing (like @krw910) that would be good to share more widely

nage (Thu, 22 Jun 2017 15:35:05 GMT):
stevetolman: an update on the alpha network: the setup we are using right now has issues with a lot of load, but we now have 9 stewards on that network.

nage (Thu, 22 Jun 2017 15:36:38 GMT):
jlaw: has anyone gotten things setup to do write transactions?

nage (Thu, 22 Jun 2017 15:36:52 GMT):
sebastian: I've setup things, and hope to do some transactions (busy with college)

nage (Thu, 22 Jun 2017 15:37:22 GMT):
markus: working with a team at Helsinki University using a private network for now, and are looking to move to the provisional network as soon as we can

nage (Thu, 22 Jun 2017 15:37:39 GMT):
...: we are very excited about writing DIDs to the network as part of that project

nage (Thu, 22 Jun 2017 15:38:14 GMT):
...: DiMe short for Digital Me is the name of that project

nage (Thu, 22 Jun 2017 15:38:27 GMT):
jlaw: we are eager to hear how things go and help wherever there are issues

nage (Thu, 22 Jun 2017 15:38:52 GMT):
stevetolman: if Mike is able to join the call we'll get more status about the alpha network from him

nage (Thu, 22 Jun 2017 15:39:28 GMT):
markus: a trust anchor which a steward creates for themselves has a concept for creating identities for other folks, what is that called

nage (Thu, 22 Jun 2017 15:39:29 GMT):
?

nage (Thu, 22 Jun 2017 15:39:57 GMT):
jlaw: in Sovrin, because identifiers are pairwise, it feels a bit funny with stewards who have identifiers who are public (all the nodes should be publicly known)

nage (Thu, 22 Jun 2017 15:40:30 GMT):
...: it is pairwise in your role, where your steward key has one id, but then when you create ids for other roles you use different IDs, so in this case you get a trust anchor ID that is different than the steward id

nage (Thu, 22 Jun 2017 15:41:58 GMT):
mike: we now have 9 validator nodes on the network, and we're debugging an issue on one of them where it disconnects periodically

nage (Thu, 22 Jun 2017 15:42:20 GMT):
...: we are able to do transactions on the ledger, and there are several others who are qualified to be founding stewards. We need to be encouraging them to get their nodes online.

nage (Thu, 22 Jun 2017 15:42:37 GMT):
...: we have them in Europe, South America, Africa and North America (so we are geographically diverse)

nage (Thu, 22 Jun 2017 15:42:47 GMT):
...: we would love to get nodes in Asia and Australia

nage (Thu, 22 Jun 2017 15:43:10 GMT):
jlaw: do we have any status on the node in Singapore?

nage (Thu, 22 Jun 2017 15:43:27 GMT):
mike: we expect to ping the stewards who haven't brought their nodes online today (the Singapore node is in that list)

nage (Thu, 22 Jun 2017 15:43:49 GMT):
jlaw: we'd like to share the location of those stewards and start some discussions about the diversity of the stewards

nage (Thu, 22 Jun 2017 15:44:27 GMT):
...: to make sure there aren't too many that share the same security attributes (too many with one host like AWS, in any one country, etc)

nage (Thu, 22 Jun 2017 15:44:46 GMT):
mike: we don't currently have a lot of visibility into some of those attributes, so we might also want to gather more of that type of data.

nage (Thu, 22 Jun 2017 15:45:31 GMT):
markus: how many nodes will we have, what is the plan?

nage (Thu, 22 Jun 2017 15:45:43 GMT):
mike: we have 16 approved, and are hoping to go up to somewhere around 19 for now

nage (Thu, 22 Jun 2017 15:46:54 GMT):
jlaw: there are competing interests on the size of the pools. As you add nodes you increase your security (greater number of discrete administrative domains that must be compromised to stop network progress), so larger is better, but the more nodes you have without the scaling architecture that we've modeled out implemented yet, the network will slow down the more nodes we add.

nage (Thu, 22 Jun 2017 15:47:29 GMT):
...: there are identity based subpool ideas and other things we've thought about to help with that, but the testing we're doing is also to help us find out where the "sweet spot" is for the number of validator nodes

nage (Thu, 22 Jun 2017 15:47:42 GMT):
...: we suspect that the ideal might be 19 or so

nage (Thu, 22 Jun 2017 15:48:13 GMT):
...: there are more and more requests for becoming a steward, so the numbers there will certainly grow. Becoming a founding steward right now requires a vote.

nage (Thu, 22 Jun 2017 15:49:15 GMT):
jlaw: when we're talking about 16 or 19 nodes, we are talking about validator nodes, not about the concept of observer nodes (which isn't fully implemented yet)

nage (Thu, 22 Jun 2017 15:49:46 GMT):
...: observer nodes function much like an edge cache and can answer read requests and we expect that there should be more of these distributed more widely.

nage (Thu, 22 Jun 2017 15:50:24 GMT):
...: observers also have reputation in terms of performance (also tied to who their stewards are), and can be used to help select new validator nodes going forward.

nage (Thu, 22 Jun 2017 15:51:23 GMT):
lovesh: we have been using a 32 byte cryptonym which allows you to treat your cryptonym as your DID, the functionality here is being cleaned up, so you will need to use the 16 byte id more correctly going forward

nage (Thu, 22 Jun 2017 15:51:54 GMT):
jlaw: we are in the process of deprecating this before provisional go-live so we don't have to support both long term

nage (Thu, 22 Jun 2017 15:53:25 GMT):
nage: is there any documentation around DIDs, Cryptonyms, verkeys and abbreviated keys?

nage (Thu, 22 Jun 2017 15:53:35 GMT):
alex: the getting started guide has some info about this

nage (Thu, 22 Jun 2017 15:53:53 GMT):
sebastian: is the go-live happening next month?

nage (Thu, 22 Jun 2017 15:53:57 GMT):
alex: yes

nage (Thu, 22 Jun 2017 15:54:03 GMT):
sebastian: what plans are there for having a GUI?

nage (Thu, 22 Jun 2017 15:54:11 GMT):
jlaw: I know several folks are working on GUIs

nage (Thu, 22 Jun 2017 15:54:37 GMT):
...: there isn't really a reference GUI in the public repos right now, I don't know the answer to that, but it would be a great contribution

nage (Thu, 22 Jun 2017 15:54:50 GMT):
...: adding one makes a lot of sense, it is a good question

nage (Thu, 22 Jun 2017 15:55:44 GMT):
jlaw: I know Markus is doing some work, and Evernym has some proofs-of-concepts that involve GUI

nage (Thu, 22 Jun 2017 15:56:14 GMT):
...: but we've heard bits and pieces about different folks in the community doing different things with existing GUIs that hope to integrate Sovrin as well

nage (Thu, 22 Jun 2017 15:56:47 GMT):
...: we're not sure if any of those are public yet. We would like it if there were some public open source reference GUIs

nage (Thu, 22 Jun 2017 15:56:51 GMT):
...: adding those would be welcome

nage (Thu, 22 Jun 2017 15:57:18 GMT):
...: libsovrin is designed to be a good basis for this

nage (Thu, 22 Jun 2017 15:58:03 GMT):
...: there are java and iOS wrappers for this library already

nage (Thu, 22 Jun 2017 16:00:06 GMT):
jlaw: open invitation, please come help write code. We would love to have your contributions

nage (Thu, 22 Jun 2017 16:00:53 GMT):
#endmeeting

ThePleasurable (Sat, 24 Jun 2017 12:19:45 GMT):
Has joined the channel.

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

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

nage (Wed, 05 Jul 2017 20:52:35 GMT):
@here We have an Indy Node WG meeting tomorrow (Thursday at 9:00 Mountain Time) here https://zoom.us/j/730665163. We will be discussing consensus in Hyperledger Indy, the algorithms used and what makes Indy's consensus approach different. We will also be discussing Go-Live status, and any other topics proposed by those who plan on being part of the call.

nage (Wed, 05 Jul 2017 20:52:56 GMT):
Please post your questions or discussion topics here and I'll make sure they are added to the agenda.

Skorpion7777 (Thu, 06 Jul 2017 12:25:41 GMT):
Hi guys, I have some questions concerning the alpha network and the installation guide. During my set up I ran into two problems (following those steps: https://github.com/evernym/sovrin-environments/blob/master/vagrant/training/vb-multi-vm/TestSovrinClusterSetup.md) First install I did was on my notebook. Everything went well and I managed to run 4 agents and 4 validators inside of virtual box (setup with vagrant). At this time my pc was pretty slowed down by all these VMs so I decided to pause them and only leave 1 validator and 1 agent activly running. This is the problem: when I log in to the agent with the `vagrant ssh agent01` command beeing in the _sovrin-environments-masters/vagrant/traning/vb-multi-vm_ I the login works fine. But when I want o continue the guide and use the `sovrin` command I get that it isn't installed.

Skorpion7777 (Thu, 06 Jul 2017 12:32:37 GMT):
So I decided to give it another try. I rented a aws EC2 instance (with windows server). With more power than my notebook to run all agents and validators. Installation wasn't as smooth as on the notebook since i needed to use vagrant up agent/validator for every VM seperatly. The EC2 instance couldn't handle something like `vagrant up agent01 agent02` only one at a time. Anyways after having all units running I'm now running into the problem that I can't connect via ssh. I always get `ssh_exchange_identification: read: Connection reset by peer` I'm not quite shure where the problems are comming from, but I wanted to inform you. I'll be in the WG meeting later, so maybe we can discusse some issues. I'll also see if I have the time to try running the docker version before the meeting starts.

nage (Thu, 06 Jul 2017 15:02:02 GMT):
The Indy Node WG call is underway here https://zoom.us/j/730665163

farooq_m_khan (Thu, 06 Jul 2017 15:05:06 GMT):
Introduction about what we do in WG from Nathan

farooq_m_khan (Thu, 06 Jul 2017 15:05:26 GMT):
Introductions from new folks joining the call today

nage (Thu, 06 Jul 2017 15:05:34 GMT):
https://docs.google.com/document/d/1hsgbQzZaFmi5aZF6GCA6se8CEQmVvOo0NvE7cAmX-bw/edit#heading=h.atidclfxt9iy

nage (Thu, 06 Jul 2017 15:05:48 GMT):
The paper Sally is helping with ^^^ :)

farooq_m_khan (Thu, 06 Jul 2017 15:07:41 GMT):
General Status of the Project by Steve Tolman (manager at Evernym):

farooq_m_khan (Thu, 06 Jul 2017 15:08:05 GMT):
We are working through some hardening sprints. This means we are working on some issues identified in the code.

nage (Thu, 06 Jul 2017 15:08:09 GMT):
https://jira.hyperledger.org/projects/INDY/issues/INDY-185?filter=allopenissues

farooq_m_khan (Thu, 06 Jul 2017 15:08:24 GMT):
We are running at the moment what we call Alpha pool

nage (Thu, 06 Jul 2017 15:08:31 GMT):
and https://jira.hyperledger.org/projects/IS/issues/IS-157?filter=allopenissues

farooq_m_khan (Thu, 06 Jul 2017 15:08:46 GMT):
There are some issues but we are working on resolving them

farooq_m_khan (Thu, 06 Jul 2017 15:09:10 GMT):
Significant code changes done recently:

farooq_m_khan (Thu, 06 Jul 2017 15:09:45 GMT):
We had a major issue in "View Change" which is now fixed, just a few corner cases are snagging us but this is a huge advance in platform

farooq_m_khan (Thu, 06 Jul 2017 15:10:12 GMT):
This change will probably be available by in a stable build mid of next week

farooq_m_khan (Thu, 06 Jul 2017 15:10:40 GMT):
Folks: want to see the issues that we are working on please go to hyperledger jira (link above) to check all the open issues

farooq_m_khan (Thu, 06 Jul 2017 15:11:06 GMT):
Luca from Infocert: (InfoCert is running a Alpha Node)

farooq_m_khan (Thu, 06 Jul 2017 15:11:34 GMT):
Question from Luca: Will Alpa nodes be asked to update, or is there a auto matic update avalable of some kind

farooq_m_khan (Thu, 06 Jul 2017 15:11:51 GMT):
Answer from Steve: There is a auto-update system in place

farooq_m_khan (Thu, 06 Jul 2017 15:12:31 GMT):
For the update transaction to succeed however Stewards need to ensure the OS on there nodes is updated with OS patches

farooq_m_khan (Thu, 06 Jul 2017 15:13:17 GMT):
Lovesh: Mentions the bug about View Change.

farooq_m_khan (Thu, 06 Jul 2017 15:14:10 GMT):
There were 4 approaches to solve the defect and the approaches were discussed in a google doc that shared on hyperledger-indy mailing list. We used one of the approaches to solve the issue

nage (Thu, 06 Jul 2017 15:14:38 GMT):
https://lists.hyperledger.org/mailman/listinfo/hyperledger-indy

farooq_m_khan (Thu, 06 Jul 2017 15:15:17 GMT):
Link to doc: https://docs.google.com/document/d/1oftK70I00wPGXFvFqiA2tmpwU7-kIjgNNieYkZcFkic/edit#heading=h.7ih81m96h5v6

farooq_m_khan (Thu, 06 Jul 2017 15:15:41 GMT):
Steve Tolman: There was another issue causing some node disconnections, this was also fixed recently

farooq_m_khan (Thu, 06 Jul 2017 15:16:09 GMT):
this will also be present in the build next week.

farooq_m_khan (Thu, 06 Jul 2017 15:17:16 GMT):
Lovesh: We have added the ability for a Node to request arbitrary messages that it might have missed, instead of waiting for a full catchup

farooq_m_khan (Thu, 06 Jul 2017 15:17:41 GMT):
Lovesh: We are going to deprecate crypto-nyms

farooq_m_khan (Thu, 06 Jul 2017 15:18:49 GMT):
Devin: We have added some code so that CLI will generated identifiers as a DID

paulmersky (Thu, 06 Jul 2017 15:19:39 GMT):
Has joined the channel.

farooq_m_khan (Thu, 06 Jul 2017 15:20:33 GMT):
A lot more code has moved to the Hyperledger project under GitHub

farooq_m_khan (Thu, 06 Jul 2017 15:20:33 GMT):
Nathan: A lot more code has moved to the Hyperledger project under GitHub

nage (Thu, 06 Jul 2017 15:20:41 GMT):
More code has moved! https://github.com/hyperledger/

farooq_m_khan (Thu, 06 Jul 2017 15:21:26 GMT):
a few repositories that havent moved are those that are used for packaging and sovrin-environments has not moved

farooq_m_khan (Thu, 06 Jul 2017 15:21:52 GMT):
When raising a pull request you will be asked to sign the Contributors License

farooq_m_khan (Thu, 06 Jul 2017 15:24:34 GMT):
Question from @Skorpion7777 about difficulties running the vagrant system for testing

farooq_m_khan (Thu, 06 Jul 2017 15:24:54 GMT):
Nathan: When running this system you need a minimum for 4 nodes

farooq_m_khan (Thu, 06 Jul 2017 15:26:17 GMT):
since we use the BFT which creates consensus and hence you need 4 nodes

farooq_m_khan (Thu, 06 Jul 2017 15:27:42 GMT):
https://github.com/evernym/sovrin-environments#cloudformation

farooq_m_khan (Thu, 06 Jul 2017 15:28:44 GMT):
https://github.com/evernym/sovrin-environments/tree/master/cloudformation

farooq_m_khan (Thu, 06 Jul 2017 15:31:09 GMT):
Discussion about Hyperledger Architecture Positioning Paper

farooq_m_khan (Thu, 06 Jul 2017 15:31:52 GMT):
Lovesh: Plenum is base on which Indy runs. Which is a variation of PBFT

farooq_m_khan (Thu, 06 Jul 2017 15:32:52 GMT):
Lovesh is giving a short description of RBFT (or plenum) which is variation of PBFT

farooq_m_khan (Thu, 06 Jul 2017 15:38:09 GMT):
Document also details about what details the ledger file has, also we will be adding to the document more about "State" which is maintained in a Patricia Trie

farooq_m_khan (Thu, 06 Jul 2017 15:38:09 GMT):
Document also details about what details the ledger file has, also we will be adding to the document more about "State" which is maintained in a Patricia Trie and how it will help in future about State Proofs

farooq_m_khan (Thu, 06 Jul 2017 15:41:27 GMT):
Thank you everyone for joining our WG call today.

mgbailey (Thu, 06 Jul 2017 16:03:46 GMT):
Has joined the channel.

KevinBai (Fri, 07 Jul 2017 05:15:50 GMT):
Has joined the channel.

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

mark.hadley (Wed, 12 Jul 2017 19:29:55 GMT):
Has joined the channel.

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

swcurran (Tue, 18 Jul 2017 20:13:04 GMT):
Has joined the channel.

nage (Wed, 19 Jul 2017 14:56:08 GMT):
The Indy Node WG will have its regularly scheduled call in a little over 24 hours. If you have a topic you'd like to see on the Agenda, please propose it here.

nage (Wed, 19 Jul 2017 14:57:04 GMT):
* What ledger changes have been merged in the last two weeks * What work is planned for the next two weeks * Go-live status and updates

LoveshHarchandani (Wed, 19 Jul 2017 16:22:51 GMT):
Addition of timestamps to transactions in ledger. Change in the serialisation format, we are transitioning to msgpack from the home grown CompactSerialiser.

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

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

nage (Thu, 20 Jul 2017 14:51:13 GMT):
The WG call starts in 10 minutes

nage (Thu, 20 Jul 2017 14:59:26 GMT):
https://zoom.us/j/730665163

Skorpion7777 (Thu, 20 Jul 2017 15:06:37 GMT):
Updates on Go Live Status: Sprints on Bug fixes and stability

Skorpion7777 (Thu, 20 Jul 2017 15:07:25 GMT):
end of monday goal is to release a stable build and hand it out to customers That build will be the go live release candidate v.1

Skorpion7777 (Thu, 20 Jul 2017 15:07:41 GMT):
21.07 is the roll out

Skorpion7777 (Thu, 20 Jul 2017 15:08:30 GMT):
*31.07

Skorpion7777 (Thu, 20 Jul 2017 15:10:18 GMT):
[Lovesh] new features is timstamp

Skorpion7777 (Thu, 20 Jul 2017 15:10:43 GMT):
every transaction has a timestamp

Skorpion7777 (Thu, 20 Jul 2017 15:11:07 GMT):
same protocol as state proof

Skorpion7777 (Thu, 20 Jul 2017 15:11:54 GMT):
Part of the m1 release

Skorpion7777 (Thu, 20 Jul 2017 15:12:46 GMT):
recently a problem with increasing memory consumtion. fix was delaying checkpoints with saves memory

Skorpion7777 (Thu, 20 Jul 2017 15:12:58 GMT):
pool membership resolved

Skorpion7777 (Thu, 20 Jul 2017 15:15:38 GMT):
Timestamp: is part of the transaction is in utc around 2 sec. delay protocol is quite similar to bitcoin timestamps have rules released in the master guideline

Skorpion7777 (Thu, 20 Jul 2017 15:16:47 GMT):
changes how files and transactions are stored on the ledger

Skorpion7777 (Thu, 20 Jul 2017 15:17:30 GMT):
[Nathan] Are there plans for a blockchain explorer?

Skorpion7777 (Thu, 20 Jul 2017 15:17:56 GMT):
[Lovesh] yes. a simple transaction viewer is planned. But not a complex explorer

Skorpion7777 (Thu, 20 Jul 2017 15:18:41 GMT):
[Nathan] Hyperledger is planning improvments on their blockchain explorer. Maybe we could adapt some features

Skorpion7777 (Thu, 20 Jul 2017 15:19:02 GMT):
[Steve] planning on versioning this release at 1.0

Skorpion7777 (Thu, 20 Jul 2017 15:19:50 GMT):
Planning on putting together a 1.0 inventory (for hyperledger)

Skorpion7777 (Thu, 20 Jul 2017 15:20:07 GMT):
maybe calling it 0.9 release

ryanmarsh (Thu, 20 Jul 2017 15:21:10 GMT):
Has joined the channel.

Skorpion7777 (Thu, 20 Jul 2017 15:22:06 GMT):
[Sebastian] How is it possible to set up a Steward for the go live release?

Skorpion7777 (Thu, 20 Jul 2017 15:22:41 GMT):
[Nathan] reach out to Drummond Reed. Theyll help you to sign into the network and help you go through the setting up.

Skorpion7777 (Thu, 20 Jul 2017 15:23:04 GMT):
at this point the set up shouldnt be hard so just reach out

Skorpion7777 (Thu, 20 Jul 2017 15:23:39 GMT):
a good point is joining the sovrin slack channel. Lot of people are involved and theyll help you

nage (Thu, 20 Jul 2017 15:24:07 GMT):
https://sovrin.slack.com see the #stewards channel

Skorpion7777 (Thu, 20 Jul 2017 15:25:27 GMT):
Outside of th sovrin network there arent really projects using the hyperledger indy codebase

Skorpion7777 (Thu, 20 Jul 2017 15:25:49 GMT):
everyone is invited to join, contribute and to propose new ideas

Skorpion7777 (Thu, 20 Jul 2017 15:28:55 GMT):
[Nathan] A lot of dicussions around consensus protocols

Skorpion7777 (Thu, 20 Jul 2017 15:29:18 GMT):
Architecture working group in hyperledger is the right place

Skorpion7777 (Thu, 20 Jul 2017 15:31:40 GMT):
Generalized summary for consensus mechanisms in hyperledger:

nage (Thu, 20 Jul 2017 15:32:26 GMT):
The consensus positioning paper being developed by the Hyperledger Arch WG https://docs.google.com/document/d/16YgZXJeHICZQLjlLuyRUccjH3tyCwkMQtp5iY5uKA5g/edit

Skorpion7777 (Thu, 20 Jul 2017 15:33:14 GMT):
Scalability in the sovrin Network:

Skorpion7777 (Thu, 20 Jul 2017 15:33:53 GMT):
around 4 or 5 a minute. But 100k + thats a problem right now

nage (Thu, 20 Jul 2017 15:34:16 GMT):
A few other papers currently being discussed by others outside of the Indy project http://www.shoup.net/papers/ckps.pdf https://arxiv.org/abs/1707.01873 http://www.navigators.di.fc.ul.pt/w2/img_auth.php/d/d1/Document_for_Publication-joaosousa2011.pdf and https://www.zurich.ibm.com/~cca/papers/pax.pdf

nage (Thu, 20 Jul 2017 15:34:34 GMT):
obviously this is just a taste of what is going on in the literature for consensus

Skorpion7777 (Thu, 20 Jul 2017 15:34:38 GMT):
that will be a journey together. The ledger is stable. We can upgrade the pool.

Skorpion7777 (Thu, 20 Jul 2017 15:35:32 GMT):
but at the moment right now its definitly an issue

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

rock_martin (Tue, 25 Jul 2017 10:14:39 GMT):
Has joined the channel.

Skorpion7777 (Tue, 25 Jul 2017 12:59:01 GMT):
Hi folks. One aws related question/comment. I used the CloudFormation Script (https://github.com/evernym/sovrin-environments/blob/master/cloudformation/training/SovrinCluster.json) but ran in to the problem that no mater which region I selected the ami's have been wrong. I've searched all public ami's and couldn't find any used in the cloudFormation script. Then I just edited the script and used a random ubuntu 16.04 ami (in my case ami-62498b0d ) that worked and the EC2 instances spinned up. Am I the only one who had this problem?

tharmon (Tue, 25 Jul 2017 18:09:29 GMT):
The AMIs used in the CloudFormation script are produced by Ubuntu. They occasionally release new versions, which causes the old ones to be deprecated. Those who have previously used the deprecated AMIs are still allowed to continue. However, new users cannot see them. It appears that this has occurred, and I'll need to update the AMI list in the template.

tharmon (Tue, 25 Jul 2017 19:28:52 GMT):
Just updated the AMI list, as well as a few other items that I saw. There have been a number of changes recently in the code, and they may not yet be fully reflected in the templates. If you run into any issues with them, please DM me. Thanks.

szlaci1983 (Wed, 26 Jul 2017 08:44:25 GMT):
Has joined the channel.

smithsamuelm (Fri, 28 Jul 2017 19:10:10 GMT):
I fixed the python_listener.py script so it works in Python3 Mike Bailey asked me to submit a pull request but not sure which repot its in.

ksachdeva (Tue, 01 Aug 2017 16:26:00 GMT):
Has joined the channel.

nage (Tue, 01 Aug 2017 20:48:41 GMT):
@LoveshHarchandani and/or Kelly, on the Sovrin Trust Framework WG call someone asked what the service level objectives of the fully live (no longer provisional) network are/should be. Do we have any current performance numbers or any objectives that we could talk about at the next Ledger WG call this Thursday?

nage (Tue, 01 Aug 2017 20:48:41 GMT):
@LoveshHarchandani and/or @krw910 , on the Sovrin Trust Framework WG call someone asked what the service level objectives of the fully live (no longer provisional) network are/should be. Do we have any current performance numbers or any objectives that we could talk about at the next Ledger WG call this Thursday?

krw910 (Tue, 01 Aug 2017 20:58:02 GMT):
@nage I am working through getting some get numbers now. Our focus was on stability and not performance for the initial release. I have several metrics I am working on gathering to see where we are now and then we can make goals on where we want to be. I also see different performance numbers than @LoveshHarchandani partially due to the difference in our setup and partially due to how the information is gathered. Most of my numbers have been from the clients view point which includes round trip latency with the client. With the transaction timestamp I can now start to measure how quickly those transactions are being recorded in the ledger. For example when sending 3500 transactions at once (10 Client at 350 each) the client view shows a throughput of 16 per second, but the timestamp in the ledger shows those were all written at 25 per second. I have seen as much as 69 per second, but it all depends on the load.

nage (Tue, 01 Aug 2017 20:58:44 GMT):
would you be willing to go over some of this info on the Ledger WG call?

krw910 (Tue, 01 Aug 2017 20:59:17 GMT):
@nage when is the next call?

nage (Tue, 01 Aug 2017 20:59:32 GMT):
This Thursday at 9:00

nage (Tue, 01 Aug 2017 20:59:40 GMT):
(am Mountain Time)

krw910 (Tue, 01 Aug 2017 21:00:08 GMT):
@nage sure I am open at that time. I can at least tell what I have seen so far and what our plans are.

nage (Tue, 01 Aug 2017 21:00:30 GMT):
That would be great

nage (Tue, 01 Aug 2017 21:04:01 GMT):
@here anyone have other topics for the Indy Node WG call this Thursday?

krw910 (Tue, 01 Aug 2017 21:17:43 GMT):
@nage can you send me an invite?

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

Sean_Bohan (Wed, 02 Aug 2017 13:52:04 GMT):
Folks: Agenda for the Ledger call (tomorrow Aug 3): Quick note to share the agenda of the next Ledger Working Group and get the community thinking about new topics and discussions. Details: When: The next Ledge WG meeting will be held Thursday, August 03, 2017 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_0dP7WPfp Agenda: We would love to have a focused discussion on the following topics: 1. The Sovrin Provisional Network is LIVE! 2. Product roadmap for Hyperledger Indy We want to share the current needs for Ledger We want your input and thoughts on what is there, what you think is needed “Trailhead” for Hyperledger Indy participation 3. Growing the Ledger community (invite a friend to take a look at our GitHub or join a WG call!) See you all then/there

nage (Wed, 02 Aug 2017 17:28:32 GMT):
[Done ](https://chat.hyperledger.org/channel/indy-node?msg=xkFScMTvshnxm5gRk) @krw910

nage (Wed, 02 Aug 2017 17:31:29 GMT):
@Sean_Bohan Also note that @krw910 will have an agenda item to cover ledger performance (where we are now, and discussion about where we want to get to)

Sean_Bohan (Thu, 03 Aug 2017 12:38:25 GMT):
outstanding

gudkov (Thu, 03 Aug 2017 13:44:29 GMT):
Has joined the channel.

ashcherbakov (Thu, 03 Aug 2017 15:02:55 GMT):
Hey, we were dropped from the meeting. What is the correct meeting URL?

Sean_Bohan (Thu, 03 Aug 2017 15:08:14 GMT):
Hey - Ledger Working group is happening here: https://zoom.us/j/730665163 apologies for the confustion

nage (Thu, 03 Aug 2017 15:54:02 GMT):
Thanks @Sean_Bohan for running the meeting today

ashcherbakov (Fri, 04 Aug 2017 07:03:07 GMT):
Please find the yesterday's status of Community Team: - Supporting new ledger serialization (msgpack): - Speeding up the tests; enhancing the tests - limitting the size of requests - fixing a bug with Claim Def - explarotary testing - improving update procedure

spivachuk (Fri, 04 Aug 2017 12:56:27 GMT):
Has joined the channel.

spivachuk (Fri, 04 Aug 2017 16:43:53 GMT):
Please find the today's status of Community Team: - Supporting new ledger serialization (msgpack): completed the changes in indy-plenum, providing support for the new ledger serialization in indy-node. - Simplifying class hierarchy: made a list of classes and started refactoring. - Enhancing tests: speeding up slow places, trying to execute tests in parallel. - Fixing an issue with a continuous upgrade loop. - Limiting transaction size: fixed the crash, added the error message to client. - Seq no verification for send CLAIM_DEF command: finished fixing the issue, corrected the tests correspondingly to the made changes, writing tests for the fix. - Testing pool upgrade with tweaked system clock. - Tickets verification. - Discussing system testing against a pool in Docker.

spivachuk (Fri, 04 Aug 2017 16:43:53 GMT):
Please find today's status of Community Team: - Supporting new ledger serialization (msgpack): completed the changes in indy-plenum, providing support for the new ledger serialization in indy-node. - Simplifying class hierarchy: made a list of classes and started refactoring. - Enhancing tests: speeding up slow places, trying to execute tests in parallel. - Fixing an issue with a continuous upgrade loop. - Limiting transaction size: fixed the crash, added the error message to client. - Seq no verification for send CLAIM_DEF command: finished fixing the issue, corrected the tests correspondingly to the made changes, writing tests for the fix. - Testing pool upgrade with tweaked system clock. - Tickets verification. - Discussing system testing against a pool in Docker.

spivachuk (Fri, 04 Aug 2017 16:43:53 GMT):
Please find today's status of Community Team: - Supporting new ledger serialization (msgpack): completed the changes in indy-plenum, providing support for the new ledger serialization in indy-node. - Simplifying class hierarchy: made a list of classes and started refactoring. - Enhancing tests: speeding up slow places, trying to execute tests in parallel. - Fixing an issue with a continuous upgrade loop. - Limiting transaction size: fixed the crash, added the error message to client. - Seq no verification for send CLAIM_DEF command: finished fixing the issue, corrected the tests correspondingly to the made changes, writing tests for the fix. - Testing pool upgrade with tweaked system clock. - Tickets verification. - Discussing system testing against a pool in Docker.

spivachuk (Mon, 07 Aug 2017 17:42:06 GMT):
Please find the today's status of Community Team: - Supporting new ledger serialization (msgpack): providing support for the new ledger serialization in indy-node. - Simplifying class hierarchy: made changes in plenum node that simplify work with replicas; reorganized hierarchy. - Enhancing tests: found and fixed some slow places, running tests in parallel. Some Jenkins agents are short of AWS credits - this may be a blocker. - Fixing an issue with a continuous upgrade loop: found and fixed the catchup bug in upgrade procedure, refactoring is in progress. - Hooking up Sovrin AWS SNS notifier to Jenkins. - Limiting transaction size: correcting tests correspondingly to the made changes. - Simplifying user's own key rotation: reviewing key generation commands and related tests. - Seq no verification for send CLAIM_DEF command: wrote tests for the made fix. - Cleaning up log messages and levels in the code: decreasing level of minor log messages. - Issue with accidental test fails on Jenkins: investigating the issue, put on hold for now. - System testing against a pool in Docker: test design is in progress. - Tickets verification. - Logging newly found bugs. - Sovrin Tokens related discussions and meetings.

spivachuk (Mon, 07 Aug 2017 17:42:06 GMT):
Please find today's status of Community Team: - Supporting new ledger serialization (msgpack): providing support for the new ledger serialization in indy-node. - Simplifying class hierarchy: made changes in plenum node that simplify work with replicas; reorganized hierarchy. - Enhancing tests: found and fixed some slow places, running tests in parallel. Some Jenkins agents are short of AWS credits - this may be a blocker. - Fixing an issue with a continuous upgrade loop: found and fixed the catchup bug in upgrade procedure, refactoring is in progress. - Hooking up Sovrin AWS SNS notifier to Jenkins. - Limiting transaction size: correcting tests correspondingly to the made changes. - Simplifying user's own key rotation: reviewing key generation commands and related tests. - Seq no verification for send CLAIM_DEF command: wrote tests for the made fix. - Cleaning up log messages and levels in the code: decreasing level of minor log messages. - Issue with accidental test fails on Jenkins: investigating the issue, put on hold for now. - System testing against a pool in Docker: test design is in progress. - Tickets verification. - Logging newly found bugs. - Sovrin Tokens related discussions and meetings.

spivachuk (Tue, 08 Aug 2017 16:26:08 GMT):
Please find today's status of Community Team: - Fixed the issue with low performance of a number of Jenkins agents caused by lack of AWS credits. However, some time is needed for the agents to accumulate enough credits to provide acceptable performance. - Issue with accidental test fails on Jenkins: found the probable cause - the issue with lack of AWS credits on Jenkins agents. Waiting for the agents to accumulate enough credits to provide acceptable performance for verifying CI health. - Enhancing tests: splitting the tests into 3 parts, running the tests as modules. Further work on this task is blocked by lack of AWS credits on some Jenkins agents. Waiting for the agents to accumulate enough credits to provide acceptable performance. - Supporting new ledger serialization (msgpack): working on new serialization support in indy-node, refactoring genesis txn file due to the migration to leveldb. - Simplifying class hierarchy: fixed broken tests, continued refactoring. - Complying with PEP 8: started work. - Finished fixing the issue with a continuous upgrade loop. - Making sure that indy and sovrin packages are never updated automatically: started work. - Finished hooking up Sovrin AWS SNS notifier to Jenkins. - Providing quick system status on validators: started work. - Limiting transaction size: added an additional test. - Simplifying user's own key rotation: checked the workaround for key rotation. - Cleaning up log messages and levels in the code: continued work on decreasing level of minor log messages. - Exploratory testing: testing a pool with a huge ledger. - System testing against a pool in Docker: test design is in progress, experimenting with interaction with Sovrin CLI process. - Tickets verification.

Suedonym (Tue, 08 Aug 2017 17:13:23 GMT):
Has joined the channel.

spivachuk (Wed, 09 Aug 2017 18:43:43 GMT):
Please find today's status of Community Team team: - Supporting new ledger serialization (msgpack): finished implementation, debug is in progress, writing the migration script. - Fixed the issue with performing re-election on master protocol instance only. - Enhancing tests: sped up the tests at least twice, fixed/skipped some intermittently failing tests. - Making sure that indy and sovrin packages are never updated automatically: finished. - Configuring Jenkins agent on MacOS node: prepared MacOS instance for using as Jenkins agent, connected to Jenkins. - Configuring Jenkins agent on Windows node: updated Amazon AWS AMI for Win2016 to be used with current Jenkins server. - Limiting transaction size: finished. - Simplifying user's own key rotation: implementing the client command for key rotation. - Cleaning up log messages and levels in the code: finished decreasing level of minor log messages. - Testing a pool with a huge ledger: finished. - Tickets verification. - Working on test design.

spivachuk (Wed, 09 Aug 2017 18:43:43 GMT):
Please find today's status of Community Team: - Supporting new ledger serialization (msgpack): finished implementation, debug is in progress, writing the migration script. - Fixed the issue with performing re-election on master protocol instance only. - Enhancing tests: sped up the tests at least twice, fixed/skipped some intermittently failing tests. - Making sure that indy and sovrin packages are never updated automatically: finished. - Configuring Jenkins agent on MacOS node: prepared MacOS instance for using as Jenkins agent, connected to Jenkins. - Configuring Jenkins agent on Windows node: updated Amazon AWS AMI for Win2016 to be used with current Jenkins server. - Limiting transaction size: finished. - Simplifying user's own key rotation: implementing the client command for key rotation. - Cleaning up log messages and levels in the code: finished decreasing level of minor log messages. - Testing a pool with a huge ledger: finished. - Tickets verification. - Working on test design.

mtgran (Thu, 10 Aug 2017 13:53:08 GMT):
Has joined the channel.

spivachuk (Thu, 10 Aug 2017 19:04:13 GMT):
Please find today's status of Indy-Node team: - Supporting new ledger serialization (msgpack): debug is in progress, writing a script reading the ledger (since LevelDB is used now). - Pool failure after some node demotion and pool restart: investigating the issue. - Complying with PEP 8: fixed some PEP 8 violations in anoncreds. - Issue with a continuous upgrade loop: fixed bugs found during verification. - Added static code validation to Jenkins. - CI pipeline for Windows: helped to set up environment and worked on related tasks. - Investigated Jenkins server high CPU usage, configured alarm notifications from AWS about high CPU usage. - Providing quick system status on validators: tested how current monitor stats are published over TCP channel, worked on test. - Simplifying user's own key rotation: implemented the client command for key rotation, writing a test for it. - Cleaning up log messages and levels in the code: merged the changes with master branches, fixing tests regression. - Tickets verification. - Working on test design.

spivachuk (Fri, 11 Aug 2017 19:35:16 GMT):
Please find today's status of Indy-Node team: - Supporting new ledger serialization (msgpack): merged the changes, finished writing a script reading the ledger. - Pool failure after some node demotion and pool restart: found the cause of the issue. - Issue with a continuous upgrade loop: fixed findings. - Logging of an explanation in case the pool is unable to post a transaction to a ledger: started work. - Package publishing: corrected the destination. - Providing quick system status on validators: working on a server tool for collecting validator stats. - Simplifying user's own key rotation: completed the test for the implemented command. - Cleaning up log messages and levels in the code: processed code review findings, prettifying log messages. - Request logs privacy: reviewing the current request logs. - Tickets verification. - Working on test design.

DibbsZA (Sun, 13 Aug 2017 06:26:01 GMT):
Has joined the channel.

marek.dapps (Mon, 14 Aug 2017 12:34:16 GMT):
Has joined the channel.

jljordan_bcgov (Mon, 14 Aug 2017 16:31:31 GMT):
Has joined the channel.

spivachuk (Tue, 15 Aug 2017 17:20:06 GMT):
Please find today's status of Indy-Node team: - Supporting new ledger serialization (msgpack): made some fixes of migration and serialization. - Continue work on complying with PEP 8. - Trustee key usage monitoring: improved the design. - Stalled ledger recovery mechanism: reviewing the code to detect if there are issues with committed transactions. - Cleaning up log messages and levels in the code: writing a guide on how to read the log. - DevOps tasks: fixed Jenkins configuration after recent plugins update, configured access to a newly created AWS EC2 instance. - Tickets verification. - Acceptance testing.

Suedonym (Tue, 15 Aug 2017 21:30:26 GMT):
For those new to Hyperledger Indy and Sovrin, and as a reminder to all, we have developer calls every Thursday at 9:00 am US Mountain Time (the international time can fluctuate based on daylight savings time both in Utah and your local time). We alternate between our Agent Working Group which concerns itself with the off-ledger interactions using Sovrin Identities, and the Ledger or Indy-Node Working Group which talks about the ledger itself. Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/730665163 Or iPhone one-tap (US Toll): +16465588656,730665163# or +14086380968,730665163# Or Telephone: Dial: +1 646 558 8656 (US Toll) or +1 408 638 0968 (US Toll)

Suedonym (Tue, 15 Aug 2017 21:31:46 GMT):
If you have topics you would like to discuss, please note them here.

spivachuk (Wed, 16 Aug 2017 16:13:34 GMT):
Please find today's status of Indy-Node team: - Supporting new ledger serialization (msgpack): made fixes in the migration script. - Stalled ledger recovery mechanism: continued reviewing the code to detect possible issues with committed transactions. - Cleaning up log messages and levels in the code: wrote a script extracting messages of a specific category from a log. - DevOps tasks: investigating the issue with high CPU usage on Jenkins server. - Tickets verification. - Acceptance testing. - Regression testing. - Preparing a stable build.

nage (Thu, 17 Aug 2017 15:02:29 GMT):
@here The Indy Node WG call has started

farooq_m_khan (Thu, 17 Aug 2017 15:05:49 GMT):
First Agenda Item: Whats been just completed in Indy-Node

ashcherbakov (Thu, 17 Aug 2017 15:06:03 GMT):
https://docs.google.com/spreadsheets/d/1zOwXr4ZZBmaYj9Ea4fesc9O9SZShQhlCsGzp8hHX1uM/edit#gid=1948085800

alexander.shekhovcov (Thu, 17 Aug 2017 15:06:36 GMT):
Has joined the channel.

nage (Thu, 17 Aug 2017 15:07:04 GMT):
ascherbakov: This spreadsheet contains information about status and links to demos

nage (Thu, 17 Aug 2017 15:07:19 GMT):
... The first achievement is we split up the tests of plenum

nage (Thu, 17 Aug 2017 15:07:39 GMT):
... now this is improved by almost 3 times, and the test run in less than 20-30 minutes

nage (Thu, 17 Aug 2017 15:07:52 GMT):
... there are also some code improvements and cleanups to meet pep8

nage (Thu, 17 Aug 2017 15:08:15 GMT):
... also we added some static code validation into CI, shown as warnings in continuous integration

nage (Thu, 17 Aug 2017 15:08:27 GMT):
... going forward the number of these warnings should decrease

nage (Thu, 17 Aug 2017 15:08:39 GMT):
... The next set of achievements were to enhance log readability

nage (Thu, 17 Aug 2017 15:08:48 GMT):
... to find out what is going on and have a clean history of events

nage (Thu, 17 Aug 2017 15:08:59 GMT):
... in particular some log levels were refactored

nage (Thu, 17 Aug 2017 15:10:11 GMT):
... We added a script that can grep the logs according to some rules that can be used by QA or developers or others to improve how we can get required information

nage (Thu, 17 Aug 2017 15:10:25 GMT):
... The next set of things that were done, was that ledger serialization was refactored to use msgpack

nage (Thu, 17 Aug 2017 15:10:45 GMT):
... LevelDB is now used as the storage for all ledgers (Domain, Config and Pool) for both transaction log and tries

nage (Thu, 17 Aug 2017 15:11:06 GMT):
...

nage (Thu, 17 Aug 2017 15:11:20 GMT):
... There is now one place in the code where serialization can be configured

nage (Thu, 17 Aug 2017 15:11:36 GMT):
... it is not possible to read the ledger how it was read before, it is now a binary format

nage (Thu, 17 Aug 2017 15:11:55 GMT):
... there is a new "read ledger" script that allows you to get transactions and see them

nage (Thu, 17 Aug 2017 15:12:26 GMT):
... Some bug fixes for preventing the logging of private data were addeed

nage (Thu, 17 Aug 2017 15:12:26 GMT):
... Some bug fixes for preventing the logging of private data were added

nage (Thu, 17 Aug 2017 15:12:49 GMT):
... Also some features for changing an owner's key

nage (Thu, 17 Aug 2017 15:13:00 GMT):
... to allow rotating the key with a single command

nage (Thu, 17 Aug 2017 15:13:23 GMT):
... there were also some sets of tickets related to the upgrade proceedure (including supporting a downgrade option)

nage (Thu, 17 Aug 2017 15:13:49 GMT):
... Finally during the sprint some quality improvements were done to refactor classes and improve tests

nage (Thu, 17 Aug 2017 15:14:31 GMT):
LoveshHarchandani: it used to be that the trie nodes were not hashed, and you could imbalance the trie to increase lookup times, this fix is now in and shouldn't be an issue

nage (Thu, 17 Aug 2017 15:15:13 GMT):
gudkov: The Indy SDK continuous integration structure and pipelines are now setup and there are pipelines to test the SDK on Windows (which creates binaries)

nage (Thu, 17 Aug 2017 15:15:45 GMT):
@gudkov could you provide links to the pipeline builds that people can try out?

nage (Thu, 17 Aug 2017 15:16:13 GMT):
... You can now sign an arbitrary byte array instead of just ledger transactions, so you can use this function to sign any data

nage (Thu, 17 Aug 2017 15:16:31 GMT):
... to sign transactions there is a dedicated call in the Signus module

nage (Thu, 17 Aug 2017 15:16:46 GMT):
... Indy SDK is now compatible with the changes to Indy Node for serialization cases

nage (Thu, 17 Aug 2017 15:17:10 GMT):
... There are also some documentation enhancements to UML and specifications for the Python wrapper

nage (Thu, 17 Aug 2017 15:17:27 GMT):
... Also some stability fixes to help with the pipeline failures

nage (Thu, 17 Aug 2017 15:17:39 GMT):
... libindy also pegs versions of dependencies

gudkov (Thu, 17 Aug 2017 15:19:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=x67rT5HWPdn5kATPt) 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

nage (Thu, 17 Aug 2017 15:20:33 GMT):
gudkov: we have binaries for Ubuntu, RHEL and Windows, along with some other wrapper builds

nage (Thu, 17 Aug 2017 15:20:39 GMT):
... more links to come

nage (Thu, 17 Aug 2017 15:20:45 GMT):
... along with reference to the README

nage (Thu, 17 Aug 2017 15:23:31 GMT):
Welcome to @swcurran and @jljordan_bcgov

nage (Thu, 17 Aug 2017 15:23:47 GMT):
and @Suedonym

nage (Thu, 17 Aug 2017 15:28:02 GMT):
alex.nagelberg voted for the logging demo and we started playing it

nage (Thu, 17 Aug 2017 15:32:40 GMT):
spivachuk shared the video over Zoom (it is available through the previously shared spreadsheetfor those who would like to view it directly)

sergey.minaev (Thu, 17 Aug 2017 15:32:53 GMT):
Has joined the channel.

nage (Thu, 17 Aug 2017 15:33:49 GMT):
@here any other votes for demos before we move to general discussion and questions?

sergey.minaev (Thu, 17 Aug 2017 15:44:22 GMT):
more links for indy-sdk are published in #indy-sdk

peacekeeper (Thu, 17 Aug 2017 15:44:40 GMT):
One question was about the current status and content of the Provisional Network. @peacekeeper reported that apparently since the launch 2 nyms and 1 attribute have been added

Suedonym (Thu, 17 Aug 2017 15:45:29 GMT):
Where can we find a test network? Reach out on Sovrin's slack channel and reach out to @trev.harmon or @mike.bailey for information on this.

farooq_m_khan (Thu, 17 Aug 2017 15:48:56 GMT):
https://github.com/hyperledger-archives/indy-client/blob/master/getting-started.md

nage (Thu, 17 Aug 2017 15:51:28 GMT):
Thanks for those who volunteered to post pointers to how to get a private test network working on the Faber example

ashcherbakov (Thu, 17 Aug 2017 15:52:20 GMT):
https://drive.google.com/drive/u/1/folders/0B4efUY1IocYwUERNNW5sekNTMUU

ashcherbakov (Thu, 17 Aug 2017 15:52:45 GMT):
^ a link to some docs about starting agents

swcurran (Thu, 17 Aug 2017 15:53:08 GMT):
Awesome...thanks @ashcherbakov

srottem (Thu, 17 Aug 2017 15:53:26 GMT):
This is the getting started doc: https://github.com/hyperledger-archives/indy-client/blob/stable/getting-started.md. In particular, to get the various scripts up and running take a look at the 'Create virtual machines' link in that document (https://github.com/evernym/sovrin-environments/blob/master/vagrant/training/vb-multi-vm/TestSovrinClusterSetup.md) which has information on how to bootstrap and get the scripts up and running.

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

spivachuk (Thu, 17 Aug 2017 19:01:39 GMT):
Please find today's status of Indy-Node team: - Supporting new ledger serialization (msgpack): fixing bugs found during testing. - Complying with PEP 8: fixing PEP 8 violations in plenum. - Pool failure after 1st node demotion and pool restart: writing a test for the case when the demoted node includes the primary of the master instance. - Issue with performing re-election on master protocol instance only: the issue is reported again, trying to reproduce it. - Cleaning up log messages and levels in the code: adjusting levels for debug/trace log messages. - Tickets verification. - Confirmation testing. - Logging newly found bugs.

swcurran (Thu, 17 Aug 2017 20:44:53 GMT):
Hey - trying to run the test script end to end using docker scripts. Currently setting up agents as per - https://drive.google.com/drive/u/1/folders/0B4efUY1IocYwUERNNW5sekNTMUU. On the step right before "Acme" in the script: send ATTRIB dest=ULtgFQJe6bjiFbs7ke3NJD raw={"endpoint": {"ha": "10.0.0.6:5555", "pubkey": "5hmMA64DDQz5NzGJNVtRzNwpkZxktNQds21q3Wxxa62z"}} Getting error: Error: client request invalid: InvalidClientRequest('dest should be added before adding attribute for it',) I think the dest has been added in the previous steps. I'm not sure I have the right IP:port, but I don't think that has come into play yet. Any ideas?

mgbailey (Thu, 17 Aug 2017 21:07:11 GMT):
@swcurran The link given does not take me to the doc, so this will be a little general. The steps needed are something like this: 1. As a STEWARD add Acme's TRUST_ANCHOR: sovrin> new key with seed 000000000000000000000000Steward1 sovrin> send NYM dest=ULtgFQJe6bjiFbs7ke3NJD role=TRUST_ANCHOR verkey=~5kh3FB4H3NKq7tUDqeqHc1 2. As the TRUST_ANCHOR, add the ATTRIBs: sovrin> new key with seed Faber000000000000000000000000000 sovrin> send ATTRIB dest=ULtgFQJe6bjiFbs7ke3NJD raw={"endpoint": {"ha": ":5555", "pubkey": "5hmMA64DDQz5NzGJNVtRzNwpkZxktNQds21q3Wxxa62z"}} From the error message, I think you missed step 1.

mgbailey (Thu, 17 Aug 2017 21:07:57 GMT):
That should be Faber's agent, not Acme's

swcurran (Thu, 17 Aug 2017 21:09:06 GMT):
Sorry - proper link is https://drive.google.com/open?id=0By6MAzl2wv6VRjhpeDZwQjVLOWs I definitely did the steps you outline as 1 - all 4 of those steps.

swcurran (Thu, 17 Aug 2017 21:09:06 GMT):
Sorry - proper link is https://drive.google.com/open?id=0By6MAzl2wv6VRjhpeDZwQjVLOWs I definitely did the steps you outline as 1 - all 4 of those steps.commands

swcurran (Thu, 17 Aug 2017 21:10:19 GMT):
Looking at the test code that run the tutorial, it looks like the the endpoint is just the ip:port?

mgbailey (Thu, 17 Aug 2017 21:13:22 GMT):
on one of the validators, what does "grep ULtgFQJe6bjiFbs7ke3NJD /home/sovrin/.sovrin/data/nodes//transactions_sandbox/1 give you?

mgbailey (Thu, 17 Aug 2017 21:13:57 GMT):
You should see the ledger entry for the TRUST_ANCHOR

mgbailey (Thu, 17 Aug 2017 21:14:53 GMT):
if not, the steps in step 1 did not work

mgbailey (Thu, 17 Aug 2017 21:17:12 GMT):
Another thing to check. When you typed the "send NYM" instruction in the CLI, you should have seen "Nym ULtgFQJe6bjiFbs7ke3NJD added" as a response.

swcurran (Thu, 17 Aug 2017 21:17:36 GMT):
Yup....that's what I see.

swcurran (Thu, 17 Aug 2017 21:17:37 GMT):
sovrin@test> new key with seed 000000000000000000000000Steward1 Key created in keyring Default Identifier for key is Th7MpTaRZVRYnPiabds81Y Verification key is ~7TYfekw4GUagBnBVCqPjiC Current identifier set to Th7MpTaRZVRYnPiabds81Y sovrin@test> send NYM dest=ULtgFQJe6bjiFbs7ke3NJD role=TRUST_ANCHOR verkey=~5kh3FB4H3NKq7tUDqeqHc1 Adding nym ULtgFQJe6bjiFbs7ke3NJD sovrin@test>

mgbailey (Thu, 17 Aug 2017 21:18:01 GMT):
Its not there.

mgbailey (Thu, 17 Aug 2017 21:18:58 GMT):
When you typed connect test, did you see "Connected to test" in the output?

swcurran (Thu, 17 Aug 2017 21:19:03 GMT):
Right...doh

swcurran (Thu, 17 Aug 2017 21:19:26 GMT):
sovrin> connect test New keyring Default created Active keyring set to "Default" Active keyring set to "Default" Client sovrin3de746 initialized with the following node registry: Node1C listens at 10.0.0.2 on port 9702 Node2C listens at 10.0.0.3 on port 9704 Node3C listens at 10.0.0.4 on port 9706 Node4C listens at 10.0.0.5 on port 9708 Active client set to sovrin3de746 3tTWCs5wJQQrfLB2ADrQfMViMgshy7JpNvYeYMUWXWwi listening for other nodes at 0.0.0.0:6001 3tTWCs5wJQQrfLB2ADrQfMViMgshy7JpNvYeYMUWXWwi looking for Node1C at 10.0.0.2:9702 3tTWCs5wJQQrfLB2ADrQfMViMgshy7JpNvYeYMUWXWwi looking for Node2C at 10.0.0.3:9704 3tTWCs5wJQQrfLB2ADrQfMViMgshy7JpNvYeYMUWXWwi looking for Node3C at 10.0.0.4:9706 3tTWCs5wJQQrfLB2ADrQfMViMgshy7JpNvYeYMUWXWwi looking for Node4C at 10.0.0.5:9708 Connecting to test... 3tTWCs5wJQQrfLB2ADrQfMViMgshy7JpNvYeYMUWXWwi now connected to Node2C 3tTWCs5wJQQrfLB2ADrQfMViMgshy7JpNvYeYMUWXWwi now connected to Node3C 3tTWCs5wJQQrfLB2ADrQfMViMgshy7JpNvYeYMUWXWwi now connected to Node4C 3tTWCs5wJQQrfLB2ADrQfMViMgshy7JpNvYeYMUWXWwi completed catching up ledger 0, caught up 0 in total 3tTWCs5wJQQrfLB2ADrQfMViMgshy7JpNvYeYMUWXWwi now connected to Node1C Connected to test.

mgbailey (Thu, 17 Aug 2017 21:19:58 GMT):
so that looks ok

swcurran (Thu, 17 Aug 2017 21:26:15 GMT):
Where would I run that grep log command - I assume I exec into one of the docker containers - any of the nodes? I'm on the client and not seeing the log file.

mgbailey (Thu, 17 Aug 2017 21:26:17 GMT):
Hm. Your client is finding the validators and connecting to them. But you are unable to successfully post a transaction to the ledger. It is probably time to go splunking in the logs. On the CLI node they will be in cli.log in the directory from which you ran sovrin. Look for errors there first. Then maybe you will need to look in a validator's logs. They are at /home/sovrin/.sovrin/.log

swcurran (Thu, 17 Aug 2017 21:27:15 GMT):
OK - so exec into the client container and look around there.

mgbailey (Thu, 17 Aug 2017 21:27:15 GMT):
Any validator will do

swcurran (Thu, 17 Aug 2017 21:27:42 GMT):
Sorry - just to confirm - that's one of the nodes, right?

swcurran (Thu, 17 Aug 2017 21:27:42 GMT):
Sorry - just to confirm - that's one of the nodes, right? #newbie

mgbailey (Thu, 17 Aug 2017 21:28:09 GMT):
for the cli.log, go into the client. For the other, go into a validator node

swcurran (Thu, 17 Aug 2017 21:28:26 GMT):
Got it...thanks! I'll see what I find.

swcurran (Thu, 17 Aug 2017 21:29:29 GMT):
And thanks for noting that the previous command didn't complete. I saw the "Adding nym ULtgFQJe6bjiFbs7ke3NJD" and didn't twig that there is no "Added" line. Definitely helps.

mgbailey (Thu, 17 Aug 2017 21:29:40 GMT):
yw

swcurran (Thu, 17 Aug 2017 22:09:48 GMT):
Solved - self-inflicted. I had some issues getting the docker started, and had tweaked one of the scripts - node_build.sh. Saw that in the node logs that (for example) Node 1 thought the other nodes were at 127.0.0.0, vs. the proper IPs. Undid the hack and redeployed. All is well. @mgbailey - thanks for the help. To all - sorry for the noise. #learning.

mgbailey (Thu, 17 Aug 2017 22:12:31 GMT):
yw. You may want to join sovrin slack. There is a channel there, "validator-support", that might be better for questions like this. https://sovrin-slack-signup.herokuapp.com/

nage (Thu, 17 Aug 2017 22:19:15 GMT):
learning++ (for one person asking the question there are likely many others wondering the same thing)

stevetolman (Thu, 17 Aug 2017 22:19:41 GMT):
@swcurran Thanks for asking questions! This community will only grow as we grow!

swcurran (Thu, 17 Aug 2017 22:20:10 GMT):
Best thing to take from that - how to find the logs on the client and node containers.

swcurran (Thu, 17 Aug 2017 23:28:42 GMT):
Whoohoo! Run through of full script complete. Some (minor) tweaks needed to the Google doc. Should that move from Google doc to git? MD would probably be a better format.

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

nage (Fri, 18 Aug 2017 14:16:24 GMT):
I like the idea of having documentation in the git repository so that it can be revisioned along with the code

spivachuk (Fri, 18 Aug 2017 19:38:07 GMT):
Please find today's status of Indy-Node team: - Supporting new ledger serialization (msgpack): investigating the problem with migration. - Complying with PEP 8: made flake8 passed for indy-plenum and indy-node. - Pool failure after 1st node demotion and pool restart: figured out the issues with the primary demotion, finished writing the tests, started to make the fixes. - Node promotion failure in case primary is not started: reproduced the issue, creating a test to check the fix. - Cleaning up log messages and levels in the code: added a filter by a log level to the script for filtering logs, adjusting levels for debug/trace log messages. - Confirmation testing. - Analysis of the existing acceptance tests, discussing necessary acceptance tests.

spivachuk (Mon, 21 Aug 2017 18:09:14 GMT):
Please find today's status of Indy-Node team: - Supporting new ledger serialization (msgpack): fixed problems with migration. - Node promotion failure in case primary is not started: continue work on the issue. - Pool failure after 1st node demotion and pool restart: analyzed the code containing primary selection logic, designed fixes. - Cleaning up log messages and levels in the code: wrote a script gathering statistics on different log messages occurrences in a log; analyzing rates of different log messages in node logs. - Lack of wallet migration mechanism: reproducing the issue. - Confirmation testing.

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

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

spivachuk (Tue, 22 Aug 2017 18:20:32 GMT):
Please find today's status of Indy-Node team: - Multi-signature mechanism in consensus protocol: investigating signed states papers, writing Plan of Attack, discussing the feature with the team. - Node promotion failure in case primary is not started: investigating tests failures. - Pool failure after 1st node demotion and pool restart: learned how primary propagation works for late or lagged nodes, started to implement fixes for algorithm of next primary selection. - Lack of wallet migration mechanism: reproduced the issue, wrote a draft test reproducing it, designed a wallet migration mechanism. - Confirmation testing. - Regression testing. - Enhancing acceptance tests.

downTheFallLine (Wed, 23 Aug 2017 02:15:02 GMT):
Has joined the channel.

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

spivachuk (Wed, 23 Aug 2017 19:08:33 GMT):
Please find today's status of Indy-Node team: - Multi-signature mechanism in consensus protocol: writing plan of attack, learning signed state docs, investigating Milagro Crypto option for signed state, start writing the code. - Logging of explanation in case pool is unable to post transaction to ledger: wrote plan of attack. - Pool failure after 1st node demotion and pool restart: made fixes for nodes rank routine, working on tests passing. - Lack of wallet migration mechanism: implementing wallet migration mechanism. - Confirmation testing. - Regression testing. - Logging newly found bugs. - Enhancing acceptance tests.

spivachuk (Wed, 23 Aug 2017 19:08:33 GMT):
Please find today's status of Indy-Node team: - Multi-signature mechanism in consensus protocol: writing plan of attack, learning signed state docs, investigating Milagro Crypto option for signed state, start writing the code. - Logging of explanation in case pool is unable to post transaction to ledger: wrote plan of attack. - Pool failure after 1st node demotion and pool restart: made fixes for nodes rank routine, working on tests passing. - Lack of wallet migration mechanism: implementing the mechanism. - Confirmation testing. - Regression testing. - Logging newly found bugs. - Enhancing acceptance tests.

lovesh (Thu, 24 Aug 2017 15:31:41 GMT):
Has joined the channel.

spivachuk (Thu, 24 Aug 2017 16:49:47 GMT):
Please find today's status of Indy-Node team: - Multi-signature mechanism in consensus protocol: implemented BLS signatures using Charm, providing abstractions for BLS in plenum, generating and saving BLS keys by nodes. - Command line tool to provide validator status: implemented two options of stats requiring (from json stats file and from socket), writing tests. - Lack of wallet migration mechanism: completed implementation of the mechanism. - Performance and load testing. - Confirmation testing. - Logging newly found bugs. - Enhancing acceptance tests.

spivachuk (Fri, 25 Aug 2017 17:39:37 GMT):
Please find today's status of Indy-Node team: - Multi-signature mechanism in consensus protocol: implementing BLS Signed State in Plenum. - Issue with validator lagging behind the rest of nodes in pool: investigating the issue. - Command line tool providing validator status: finished base implementation of node-side part, implemented formatted output, started to improve it for cases of incorrect/missed data. - Lack of wallet migration mechanism: faced issues with incompatibility between different versions of jsonpickle, supported wallet migration from the intermediate state of renaming Link to Connection; added updating wallets directory name at cli/agent startup. - Performance and load testing. - Confirmation testing. - Logging newly found bugs.

spivachuk (Mon, 28 Aug 2017 19:36:43 GMT):
Please find today's status of Indy-Node team: - Issue with validator lagging behind the rest of nodes in pool: continue investigating the issue. - Multi-signature mechanism in consensus protocol: continue the work. - Issue with receiving a reply with outdated information: investigated the issue, created a test reproducing the issue. - Command line tool providing validator status: finished implementation and testing. - Issue with lack of pool ledger migration on client: implementing the fix. - Confirmation testing. - Load and performance testing. - Acceptance testing. - Regression testing. - Writing release notes.

lohan.spies (Mon, 28 Aug 2017 20:31:23 GMT):
Has joined the channel.

spivachuk (Tue, 29 Aug 2017 16:44:16 GMT):
Please find today's status of Indy-Node team: - Sprint planning activities. - Multi-signature mechanism in consensus protocol: working on implementation of Signed State. - Issue with validator lagging behind the rest of nodes in pool: investigating the issue. - Command line tool providing validator status: added software detection routine, support for processing missed stats parameters in input stream, fixing found bugs. - Issue with message length limitation in case of parallel sending of a lot of transactions: started investigation of the issue. - Issue with lack of wallet migration: fixed a bug in decoding of non-string dictionary keys on wallet deserialization. - Issue with lack of pool ledger migration on client: added migration of genesis pool transactions to the client. - Confirmation testing. - Performance and acceptance testing of the release candidate.

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

spivachuk (Wed, 30 Aug 2017 17:54:37 GMT):
Please find today's status of Indy-Node team: - Multi-signature mechanism in consensus protocol: continue implementing BLS Signed State. - Issue with validator lagging behind the rest of nodes in pool: continue investigating the issue. - Command line tool providing validator status: added logic to explore bindings using OS utils, improved results output, fixing found bugs. - Issue with message length limitation in case of parallel sending of a lot of transactions: fixing the issue. - Issue with lack of wallet migration: writing tests. - Confirmation testing. - Regression testing. - Enhancing acceptance tests.​

nage (Thu, 31 Aug 2017 15:05:44 GMT):
https://docs.google.com/presentation/d/1XO9aAQc_ccVjDwCftS-qNhTfcpMDet3cyVAk5YNBMTI/edit?usp=sharing

ashcherbakov (Thu, 31 Aug 2017 15:07:18 GMT):
Sprint 11: https://docs.google.com/spreadsheets/d/1IUuoEAD0MuFF6SqPVfc9WPV-TcYhSa6XrjDdW4pDIs0/edit#gid=0

Sean_Bohan (Thu, 31 Aug 2017 15:07:25 GMT):
Notes from today's Ledger/NODE WG Call

Sean_Bohan (Thu, 31 Aug 2017 15:07:36 GMT):
Alex posted link to rocketchat above

nage (Thu, 31 Aug 2017 15:07:40 GMT):
Agenda: * What has been checked in the last two weeks, what is happening in the next two weeks * RPM packaging (what do we have now, and who is hoping for more)

Sean_Bohan (Thu, 31 Aug 2017 15:07:55 GMT):
IndyNode - created new stable build (1.1.33) from Indy Node

nage (Thu, 31 Aug 2017 15:08:13 GMT):
* Any demos of sprint tasks that people on the call would like to see * State Proofs work (what is it, how will it change things, and what can be done to help)

Sean_Bohan (Thu, 31 Aug 2017 15:08:17 GMT):
Fixes, changes, changes with ledger serialization, uses messagepack migration scripts in build

Sean_Bohan (Thu, 31 Aug 2017 15:08:25 GMT):
main result, use stable build of Indy Node

nage (Thu, 31 Aug 2017 15:08:43 GMT):
_looks around the room wondering if anyone else has a topic to add to the agenda_

Sean_Bohan (Thu, 31 Aug 2017 15:09:04 GMT):
other features - see in spreadsheet created monitoring tool for Stewards (CLI, installed w Node) stats, info about node, current status link in spreadsheet for video demo

Sean_Bohan (Thu, 31 Aug 2017 15:11:14 GMT):
Fixed some stability problems, motion of nodes, primary nodes, improved some login, working on portability and maintainability tasks clear exlplicit logs when something happens Client Wallets and transaction files from before this release Continue working on improving code, made changes, has code support, code validation if code is not formatted for these rules, PR code will fail - check in CI system Working on states and state proofs feature which will allow, to send request to one node, validator or observer, and get response to request

Sean_Bohan (Thu, 31 Aug 2017 15:11:31 GMT):
possible due to state tree and signing of root, via BLS algorithm

Sean_Bohan (Thu, 31 Aug 2017 15:11:43 GMT):
Hoping to advance more and have working code in the next sprint

Sean_Bohan (Thu, 31 Aug 2017 15:12:47 GMT):
Questions? Vyacheslav: Indy SDK releasing first version - announced in rocketchat

Sean_Bohan (Thu, 31 Aug 2017 15:13:06 GMT):
redefined and automated release process, CI (continuous integration and release pipelines)

Sean_Bohan (Thu, 31 Aug 2017 15:14:30 GMT):
sample projects for Python and Java that uses projects to perform against artifacts can be found in samples folder release contains following artifacts lib files for distros - LibIndy apps, LibIndy w/o contains runtime dependencies contains compile-time dependencies python wrapper package java wrapper package

Sean_Bohan (Thu, 31 Aug 2017 15:15:21 GMT):
Implementation of claims revocation for anoncreds revocation requires integration with ledger, use and test auto functions bug fixes and stability fixes

Sean_Bohan (Thu, 31 Aug 2017 15:16:00 GMT):
changes in .Net wrapper compatible w/ ? approach changed to tasks, more clear and easy to use Questions:

Sean_Bohan (Thu, 31 Aug 2017 15:16:13 GMT):
Lovesh: New crypto library?

Sean_Bohan (Thu, 31 Aug 2017 15:16:50 GMT):
Alex: good comment, thanks all BLS related stuff will provide sep crypto library sep project, IndyCrypto contain BLS algo written in Rust indySDK and IndyNode will work with BLS sigs

Sean_Bohan (Thu, 31 Aug 2017 15:17:14 GMT):
adding more stuff, crypto and protocol related, this project good one for contribs from community related to crypto stuff

Sean_Bohan (Thu, 31 Aug 2017 15:17:38 GMT):
Stephen: meant to replace CL algo or add to it?

Sean_Bohan (Thu, 31 Aug 2017 15:18:40 GMT):
Nathan - CL (comenisch) is for building credentials (claims and proofs) BLS for group signatures, w/o having to ask for S+1 nodes, for consensus and communicating consensus outside ledger

Sean_Bohan (Thu, 31 Aug 2017 15:19:58 GMT):
Demo videos for some of the features - if you like to watch them - offline or online - links in spreadsheet linked to above

Sean_Bohan (Thu, 31 Aug 2017 15:20:44 GMT):
Nathan: new health monitoriing tool for Stewards, Statistics, see whats going on in the ledger tool should help others, if you are a steward running a node, watch the demo, happy to hear about issues or needs, make fixes, etc.

Sean_Bohan (Thu, 31 Aug 2017 15:21:08 GMT):
Alex Tool is not present in latest stable build, finished one day after build, will be present in the next release candidate

Sean_Bohan (Thu, 31 Aug 2017 15:21:33 GMT):
Tool present in Master, guys adding minor fixes there too

Sean_Bohan (Thu, 31 Aug 2017 15:22:28 GMT):
Nathan: Daniel asked if we could talk about RPM packaging more and more support for Red Hat based distros (and oracle and centOS)

Sean_Bohan (Thu, 31 Aug 2017 15:22:47 GMT):
Alex or Slava - anyone want to comment on RPM packaging, what work someone could help with?

Sean_Bohan (Thu, 31 Aug 2017 15:23:43 GMT):
Vyacheslav included in integration pipeline during this sprint some changes in packages for this release, have a bug to be fixed for this, can prioritize, fix as soon as possible link to ticket coming

Sean_Bohan (Thu, 31 Aug 2017 15:24:07 GMT):
Alex:

Sean_Bohan (Thu, 31 Aug 2017 15:24:54 GMT):
Indy node, not big progress in RPMs CI supports it, placeholders for mult packages for diff systems right now just Debian packages can be integrated smoothly need to provide environment for these builds and running integration tests on Ubuntu but also CentOS

Sean_Bohan (Thu, 31 Aug 2017 15:25:18 GMT):
JohnJ Running on Openshift environment Docker Not sure what to use Debian as container OS?

Sean_Bohan (Thu, 31 Aug 2017 15:25:31 GMT):
hitting in the next week or so, running Indy on OpenShip platform

gudkov (Thu, 31 Aug 2017 15:26:11 GMT):
https://jira.hyperledger.org/browse/IS-307 CI: RHEL pipeline broken (can't install "Development Tools" on amazonlinux:2017.03)

Sean_Bohan (Thu, 31 Aug 2017 15:26:11 GMT):
From Vyacheslav Gudkov to Everyone: (11:24 AM) https://jira.hyperledger.org/browse/IS-307 CI: RHEL pipeline broken (can't install "Development Tools" on amazonlinux:2017.03)

Sean_Bohan (Thu, 31 Aug 2017 15:26:17 GMT):
!

Sean_Bohan (Thu, 31 Aug 2017 15:27:11 GMT):
some CI is still running on internal servers at Evernym Where are blockers, things made public but not public yet see what enhancements need to be made area someone could pick up and get involved in

Sean_Bohan (Thu, 31 Aug 2017 15:30:06 GMT):
Nathan - discuss State Proofs

Sean_Bohan (Thu, 31 Aug 2017 15:31:28 GMT):
Lovesh: State proofs and why important Overview as of now, if any clients want to trust a value on the ledger, asks a number of nodes (F+1) confirms from greater than F nodes that something on the ledger has a specific value

Sean_Bohan (Thu, 31 Aug 2017 15:32:09 GMT):
basically - let client create explicit proof client requests one node, to provide a proof, that a particular key on the ledger has a particular value ask a node "tell me the value of this DID, present proof that what you are saying is correct"

Sean_Bohan (Thu, 31 Aug 2017 15:33:10 GMT):
from client and node perspective proof that a particular state is valid node holds merkle trie that stores key value pairs, and because network is signing merkle root periodically, once a proof is valid, and the state is signed by validators, the proof is correct for a particular value pair

Sean_Bohan (Thu, 31 Aug 2017 15:33:35 GMT):
code present to verify proof, integration to do it between node and client, yet to be done

Sean_Bohan (Thu, 31 Aug 2017 15:34:43 GMT):
change, receiving YES reply, and code needs to be aware of API level change in the SDK

Sean_Bohan (Thu, 31 Aug 2017 15:34:58 GMT):
Vyacheslav Not in SDK API, in NODE API

Sean_Bohan (Thu, 31 Aug 2017 15:36:32 GMT):
signing of transaction dont expect changes in SDK Lovesh - you would have a proof coming right? Alex - high level API, get "nym" transaction, would not change, hidden from user how we process replies from node and correct, USER only concerned with it result internals of API may be changed, how check reply is correct, probably from high level POV what NODES ask for in reply, as of now always sent to whole pool of validators, in future, config and send request from some of the nodes

Sean_Bohan (Thu, 31 Aug 2017 15:36:54 GMT):
just integration of States and State Proofs, how send replies, from validator pool, APIs should not change much for the end user

Sean_Bohan (Thu, 31 Aug 2017 15:38:32 GMT):
Nathan - state proofs important from performance perspective, allows observer nodes, allow them to answer questions on behalf of ledger READS spread out over larger set of computers, larger network important piece of progress, and scale/drive adoption network handles higher load, support identities anchored on the ledger

Sean_Bohan (Thu, 31 Aug 2017 15:38:54 GMT):
Alex - how these changes will be integrated is important optional or mandatory first version optional

Sean_Bohan (Thu, 31 Aug 2017 15:39:10 GMT):
after some time may make features mandatory

Sean_Bohan (Thu, 31 Aug 2017 15:39:34 GMT):
require every batch of transactions signed by all nodes, sufficient number of sigs from nodes support feature iteratively to not break pool

jljordan_bcgov (Thu, 31 Aug 2017 15:39:46 GMT):
So ... will is it part of the network vision to allow organizations/people to run observer nodes with very low friction to join the network?

Sean_Bohan (Thu, 31 Aug 2017 15:41:03 GMT):
Nathan - YES - tier of validator nodes, trust framework approved, publicly validate transactions observer nodes, signed to the trust framework, hot spares, full copy of ledger, promoted to the validator pool when needed

Sean_Bohan (Thu, 31 Aug 2017 15:41:28 GMT):
achieve diffuse trust no too many reps from any one geography, industry, political jurisdiction, hosting platform, etc.

Sean_Bohan (Thu, 31 Aug 2017 15:41:49 GMT):
not effect consensus overall, or if so it wouldnt impact fast enough to prevent sovrin from reacting

jljordan_bcgov (Thu, 31 Aug 2017 15:42:35 GMT):
:thumbsup:

Sean_Bohan (Thu, 31 Aug 2017 15:43:38 GMT):
easy to obtain copy of ledger as ledger is updated, closer to doing large #s of queries run an observer node, get a complete copy copies of ledger is healthy as a whole, easier to audit, prove people are validating, following TF with high volume of queries, obfuscation, preserving privacy of all on network closer to center, faster updates at edges, can still build rep to be reliable node, move to center over time, increase participation indy that is not Sovrin, arch differently - only showing sovrin as global public utility for identiy as an example

Sean_Bohan (Thu, 31 Aug 2017 15:45:06 GMT):
Nathan Sig schemes, code changes, node side, SDK impacts Open discussion - questions welcome

Sean_Bohan (Thu, 31 Aug 2017 15:45:45 GMT):
John(BC) - curious about peer to peer comms once two peers discover each other, est secure connection, where crypto TLS and DID TLS happening?

Sean_Bohan (Thu, 31 Aug 2017 15:45:59 GMT):
Nathan Agent to agent comms in the Agent WG

Sean_Bohan (Thu, 31 Aug 2017 15:47:22 GMT):
LEdger serves as distributed PKI everyone has ID, pairwise ID (pub key you can check on ledger, see if still who they say they are), consensus means you have confidence that the consent of the owner to change key instead of cert authority chains and rely on root source of trust, use DLT as root of trust handshake with any party, without disclosing more info enables diff parties to do secure comms, IOT, individuals exposing facets of ID

Sean_Bohan (Thu, 31 Aug 2017 15:47:41 GMT):
nutshell - 2 kinds 1. Agent to Agent comms 2. Talk to the ledger

Sean_Bohan (Thu, 31 Aug 2017 15:49:13 GMT):
2. is simpler Node side - genesis trasactions, validating BLS in state proofs, and make sure party is auth in 1. Agent to Agent - take CurveZMQ, common protocol for dist system connect or talk to agent, this is my ID and this is the ID I want to talk to dont disclose details to malicious eavesdropper no correlations of point to point comms John has his DID for Nathan and Nathan has his own for John

Sean_Bohan (Thu, 31 Aug 2017 15:51:48 GMT):
no one else knows about them protect user to make sure info isnt leaked 2 ways curveZMQ - pairwise feature johns agent in cloud server - it is this ID I am trying to talk to (server sends right to John, no one else knows) TLS handshake key material on ledger - present certs, complete handshake, iETF compliant both techniques work due to oracle of ledger encrypted ? hints, but because we have an oracle of a DLT, can create key or look up key to encrypt SNI data, full end ot end encrypted handshake Source ID address, talked to this ID Address if an agency can forward traffic to another entity on Sovrin, flow of traffic is not sufficient to build correlation models censorship resistance use cases

Sean_Bohan (Thu, 31 Aug 2017 15:51:55 GMT):
discover who is talking to whom

Sean_Bohan (Thu, 31 Aug 2017 15:53:09 GMT):
John(BC) - layer 2, 3 monitoring Nathan - challenge pairwise pub keys, priv keys, why not endpoints IP addresses are mapped to phys world either go down path of building onion network, or funct to build deniability that you need

Sean_Bohan (Thu, 31 Aug 2017 15:53:37 GMT):
couple of routing features, excrypted SNI part is sufficient, see where people want to go from there

Sean_Bohan (Thu, 31 Aug 2017 15:54:09 GMT):
Nathan - reach outto Sam Curren, Farouk Khan, or Mike Lodder - love to discuss it

Sean_Bohan (Thu, 31 Aug 2017 15:55:11 GMT):
Eric Welton looking at SDK

Sean_Bohan (Thu, 31 Aug 2017 15:55:32 GMT):
touch real quick on relationship b/w genesis transactions and runtime when connecting to ledger

Sean_Bohan (Thu, 31 Aug 2017 15:55:43 GMT):
is idea Genesis is dynamic or fixed for say the Sovrin network?

Sean_Bohan (Thu, 31 Aug 2017 16:00:34 GMT):
Lovesh: seed file, getting with codebase is a seed file to connect other nodes EricW: would be varying that a lot under testing but outside of testing, that's a fixed set of transactions constantly growing, not fixed, wouldn't have to use the one that comes with codebase test genesis files ErickW - going thru SDK - first hurdle, confirm und the seed file defines a network, one particular seed file, but if running a priv or nested would have diff seed file, that whole ledger defined by one set of genesis transactions - quite correct might contain ten nodes discovery - client, connects to 10 nodes, client Nathan - from client perspective, genesis block might get updated over time: some leave, others take place, need to grab block and ask for updates, to whatever the current state is simple - get initial state, connect to network, rooted in the blockchain all the way back to initial, should be able to proceed first block on the ledger, was a long signing ceremony, to verify root of trust was correct, audit way to package manager or source of SDK EricW - great, matches understanding, wanted to mention, particular use case in Feb was running a sep ind network, example given something like the hong kong monetary authority, having 100-110 validators corresponding to each group w/in HKMA, sep genesis transactions cloistered from rest of Sovrin

Sean_Bohan (Thu, 31 Aug 2017 16:05:09 GMT):
diff set of genesis transaction, only case where a client would want 2 independent instances get comfortable with talkin to a protected network, brokering DID and DDO exchange between both appropriate facade from regulated environment to public environ Nathan - when you shard, allow all transactions to flow from priv to pub, maintain subset of data locally for jurisdictional control just like OS trust more than 1 root CA, maybe have SDK trust more than one Genesis Block, check sig on whatever is appropriate community resolver tool from DIF EricW the SDK would only ever need to have one genesis block, spin up two instances in close proximity added complexity of SDK not worth it Exporting data to public ledger, specifically the request to avoid contrary to spirit of sovrin, but real concern from reg agencies - this is hong kong data - doesn't leave the island Nathan - self sovereign, control over priv key side in current model, most wont get it, more experienced the hope is they will be shown reality over time EricW - going back to Dec Jan if remember, more of a "I can't sell this upstream when there is data crossing national boundaries, like idea of parity like idea of internet of identity same infrastructure on both sides lightweight NATing

Sean_Bohan (Thu, 31 Aug 2017 16:06:48 GMT):
doesnt technically matter, golf course level understanding, some sensitive bits no matter how entrypted some bits will end up in someone else's data center

Sean_Bohan (Thu, 31 Aug 2017 16:07:26 GMT):
PLEASE NOTE _ our next NODE/LEDGER call is 9/14. If you have topics, ideas, questions you want to discuss, please put them here in this room and we will put together an agenda doc for that call

Sean_Bohan (Thu, 31 Aug 2017 16:07:29 GMT):
THANK YOU ALL!

nage (Thu, 31 Aug 2017 16:58:03 GMT):
Thanks to @tkuhrt we now have a shared folder for meeting recordings and other shared artifacts here https://drive.google.com/drive/folders/0B_NJV6eJXAA1UWtBSmRNLTR3UjQ?usp=sharing

nage (Thu, 31 Aug 2017 16:58:18 GMT):
If anyone has issues with the recording, please let us know

spivachuk (Thu, 31 Aug 2017 20:01:33 GMT):
Please find today's status of Indy-Node team: - Multi-signature mechanism in consensus protocol: extending RBFT with BLS signatures. - Issue with validator lagging behind the rest of nodes in pool: finished investigation, wrote the test, implementing the fix. - Issue with message length limitation in case of parallel sending of a lot of transactions: completed the fix. - Command line tool providing validator status: added stats collection for read txns defined in indy-node. - Issue with lack of wallet migration: debugging the tests for wallet migration. - Confirmation testing. - Acceptance testing of stable build. - Logging newly found bugs. - Enhancing acceptance tests.​

spivachuk (Thu, 31 Aug 2017 20:01:33 GMT):
Please find today's status of Indy-Node team: - Multi-signature mechanism in consensus protocol: extending RBFT with BLS signatures. - Issue with validator lagging behind the rest of nodes in pool: finished investigation, wrote the test, implementing the fix. - Issue with message length limitation in case of parallel sending of a lot of transactions: completed the fix. - Command line tool providing validator status: added stats collection for read txns defined in indy-node. - Issue with lack of wallet migration: debugging the tests. - Confirmation testing. - Acceptance testing of stable build. - Logging newly found bugs. - Enhancing acceptance tests.​

spivachuk (Fri, 01 Sep 2017 18:22:59 GMT):
Please find today's status of Indy-Node team: - Multi-signature mechanism in consensus protocol: implementing BLS signatures in BFT. - Providing quick system status on validators: working on tests for validator-info tool. - Issue with lack of wallet migration: finished debugging the tests. - Issue with different root hashes on client catch-up: tried to reproduce the bug, found out that the bug was invalid. - Issue with using debug mode for node's looper in production: started fixing the issue. - DevOps tasks: set up access to GitHub for CI (since two-factor authentication must be used now). - Confirmation testing. - Exploratory testing.

spivachuk (Mon, 04 Sep 2017 17:52:12 GMT):
Please find today's status of Indy-Node team: - Extending BFT protocol with multi-signature: working on usage of signatures in consensus protocol. - Issue with lack of consensus recovery when stopped nodes are started again: reproducing and investigating the issue. - Process for notification of upgrade error and resolution: started refactoring in plenum, added a child class of notifier to node. - Providing quick system status on validators: wrote set of unit tests for validator-info tool. - Issue with writing transactions when more than F nodes are off: trying to reproduce the issue. - Issue with message length limitation in case of parallel sending of a lot of transactions: wrote several tests. - Issue with loss of consensus under load: investigating the issue, trying to reproduce it. - Logging newly found bugs.

spivachuk (Tue, 05 Sep 2017 19:02:37 GMT):
Please find today's status of Indy-Node team: - Extending BFT protocol with multi-signature: continue integrating BLS signatures to BFT. - Issue with lack of consensus recovery when stopped nodes are started again: trying out several theories which may be the reason of the bug. - Providing quick system status on validators: learned the current pool upgrade routine, reported about found issues, implemented publishing for upgrade schedule and tests for that. - Limiting transaction size on the basis of its type: implementing an individual transaction length validator. - Issue with loss of consensus under load: could not reproduce the issue, found a bug with node launch failed under load. - Issue with using debug mode for node's looper in production: fixing the issue. - Writing system tests: writing a test for removing / adding a role. - Confirmation testing. - Acceptance testing. - Logging newly found bugs.

sklump (Wed, 06 Sep 2017 12:46:27 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.

spivachuk (Wed, 06 Sep 2017 18:43:51 GMT):
Please find today's status of Indy-Node team: - Extending BFT protocol with multi-signature: completing integrating BLS signatures to BFT. - Presenting Signed State Proof for client request: started work. - Issue with lack of consensus recovery when stopped nodes are started again: found the underlying issue, fixing it. - Issue with manual node upgrade with migration script: investigated and fixed the issue. - Limiting transaction size on the basis of its type: implementing check of transaction field size in plenum. - Issue with using debug mode for node's looper in production: made debug / release mode configurable for Looper. - Release preparation: prepared pull requests to stable branches of indy-plenum and indy-node. - Test automation: made libindy python wrapper compatible with Python 3.5 which is the target platform for indy-node. - Updated several acceptance test scenarios. - Confirmation testing. - Regression testing.

spivachuk (Thu, 07 Sep 2017 19:00:04 GMT):
Please find today's status of Indy-Node team: - Presenting Signed State Proof for client request: checked development on state proof, discussed data and format required on client side for verification. - Issue with lack of consensus recovery when stopped nodes are started again: fixed the found cause of the issue but faced several new issues, fixing them. - Lack of log messages about submitted transactions at INFO level: started to work on tests cases and adjusting logging. - Making full build workflow possible for branches: posted short description how to start integration of RPM build logic into our CD. - Limiting transaction size on the basis of its type: finished implementing check of transaction field size in plenum. - Test automation: wrote guides on setup of indy-sdk/samples/python project and installation of libindy and its python wrapper into developer environment. - Acceptance testing of the release candidate.

jljordan_bcgov (Fri, 08 Sep 2017 16:43:42 GMT):
Possible Issue: When trying to follow the Alice/Faber story, first step is to ./pool_start.sh. This seems to work from that scripts output point of view. However, if one enters the node1 docker container and does an 'ls -la .sovrin' there is no Node1.log file indicating node1 did not start up. Here is the node2.log file output ... 2017-09-08 16:36:15,891 | INFO | node.py (2326) | initStateFromLedger | Node2 found state to be empty, re creating from ledger 2017-09-08 16:36:16,922 | INFO | node.py (2326) | initStateFromLedger | Node2 found state to be empty, re creating from ledger 2017-09-08 16:36:17,213 | INFO | plugin_loader.py ( 116) | _load | plugin FirebaseStatsConsumer successfully loade d from module plugin_firebase_stats_consumer 2017-09-08 16:36:17,215 | DISPLAY | replicas.py ( 36) | grow | Node2 added replica Node2:0 to instance 0 (maste r) 2017-09-08 16:36:17,215 | DISPLAY | replicas.py ( 36) | grow | Node2 added replica Node2:1 to instance 1 (backu p) 2017-09-08 16:36:18,481 | INFO | node.py (2326) | initStateFromLedger | Node2 found state to be empty, re creating from ledger 2017-09-08 16:36:18,504 | INFO | stacks.py ( 77) | start | CONNECTION: Node2 listening for other nodes at 0.0.0.0:9703 2017-09-08 16:36:18,543 | INFO | node.py ( 587) | start | Node2 first time running... 2017-09-08 16:36:18,548 | INFO | zstack.py ( 588) | connect | CONNECTION: Node2 looking for Node3 at 10.0.0 .4:9705 2017-09-08 16:36:18,549 | INFO | zstack.py ( 588) | connect | CONNECTION: Node2 looking for Node4 at 10.0.0 .5:9707 2017-09-08 16:36:18,550 | INFO | zstack.py ( 588) | connect | CONNECTION: Node2 looking for Node1 at 10.0.0 .2:9701 2017-09-08 16:36:20,061 | INFO | keep_in_touch.py ( 96) | _connsChanged | Node2 now connected to Node3 2017-09-08 16:36:20,600 | INFO | ledger_manager.py ( 835) | catchupCompleted | CATCH-UP: Node2 completed catching u p ledger 0, caught up 0 in total 2017-09-08 16:36:20,602 | INFO | keep_in_touch.py ( 96) | _connsChanged | Node2 now connected to Node4 2017-09-08 16:36:20,622 | INFO | ledger_manager.py ( 835) | catchupCompleted | CATCH-UP: Node2 completed catching u p ledger 2, caught up 0 in total 2017-09-08 16:36:20,644 | INFO | ledger_manager.py ( 835) | catchupCompleted | CATCH-UP: Node2 completed catching u p ledger 1, caught up 0 in total 2017-09-08 16:36:20,645 | INFO | node.py (1489) | allLedgersCaughtUp | CATCH-UP: Node2 does not need any more catchups 2017-09-08 16:37:55,071 | INFO | base_events.py (1274) | _run_once | poll 9.829 ms took 1001.038 ms: timeout Normally, I can stop the pool, restart it and node1 starts up fine. Not sure if this is important or not.

spivachuk (Fri, 08 Sep 2017 18:27:55 GMT):
Please find today's status of Indy-Node team: - Presenting Signed State Proof for client request: implementing sending of state proof to client. - Issue with lack of consensus recovery when stopped nodes are started again: fixing the new issues found recently. - Lack of log messages about submitted transactions at INFO level: finished implementation of tests and necessary code changes. - Limiting transaction size on the basis of its type: completed the task. - Storing of multi-signatures: started work. - Tests Automation: working on the framework for system tests. - Confirmation testing. - Acceptance testing of the release candidate. - Prepared release notes for the release candidate.

spivachuk (Mon, 11 Sep 2017 17:46:17 GMT):
Please find today's status of Indy-Node team: - Presenting Signed State Proof for client request: continue implementing sending of state proof to client. - Issue with lack of consensus recovery when stopped nodes are started again: finished fixing the bug, working on the code cleanup. - Lack of log messages about submitted transactions at INFO level: processed code review findings. - Providing quick system status on validators: continue work on upgrade scheduling stats and information about ledgers states. - Storing of multi-signatures: continue implementation. - Issue with using debug mode for node's looper in production: debugging tests failed on Jenkins. - Added TGB role to Indy-SDK. - Tests automation: continue working on the framework for system tests, refactoring of the test of removing / adding roles.

spivachuk (Wed, 13 Sep 2017 09:55:51 GMT):
Please find today's status of Indy-Node team: - Presenting Signed State Proof for client request: completing sending of state proofs, debugging and testing. - Issue with lack of consensus recovery when stopped nodes are started again: wrote a test for the made fix, propagated the fix from plenum to node. - Providing quick system status on validators: implemented logic of ledgers states publishing into info file and added tests, debugging tests. - Storing of multi-signatures: completed implementation. - Integrating BLS crypto math: started to integrate indy-crypto library. - Issue with using debug mode for node's looper in production: completed the fix. - Test Automation: continue working on the framework for system tests. - Confirmation testing.

spivachuk (Wed, 13 Sep 2017 18:45:38 GMT):
Please find today's status of Indy-Node team: - Presenting Signed State Proof for client request: debugging and testing. - Support for multiple pool networks: working on design for directories layout refactoring tasks. - Integrating BLS crypto math: debugging indy-crypto library wrapper. - Issue with pool upgrade from master 1.1.130 to master 1.1.136: explored the issue. - Test Automation: completed an initial version of the framework for system tests, refactoring of the acceptance test of removing / adding roles. - Confirmation testing. - Acceptance testing. - Logging newly found bugs.​ - Finished RC preparation.

Audrius (Wed, 13 Sep 2017 19:34:18 GMT):
Has joined the channel.

Sean_Bohan (Thu, 14 Sep 2017 15:08:22 GMT):
Ledger WG Call for the week of 9/11 Slava: lots of progress with code, signed state proof (big part of the task, still under dev but prepared demo to watch as well as try unit tests and see how it works

Sean_Bohan (Thu, 14 Sep 2017 15:08:37 GMT):
also work on test automation, closed tickets, work on documentation

Sean_Bohan (Thu, 14 Sep 2017 15:08:43 GMT):
guides for Indy SDK have been written

Sean_Bohan (Thu, 14 Sep 2017 15:09:20 GMT):
Question from Lovesh - describe the notable bugs fixed in this sprint and their impact?

nage (Thu, 14 Sep 2017 15:09:33 GMT):
Slava: List of the latest sprint achivments: https://docs.google.com/spreadsheets/d/1UnMnCaaOl27Lfx-L3s0wxPeQ6jl4mQa_f7q544IU57o/edit#gid=0

nage (Thu, 14 Sep 2017 15:09:33 GMT):
Slava: List of the latest sprint achievements: https://docs.google.com/spreadsheets/d/1UnMnCaaOl27Lfx-L3s0wxPeQ6jl4mQa_f7q544IU57o/edit#gid=0

Sean_Bohan (Thu, 14 Sep 2017 15:09:47 GMT):
Slava: most important bug , found by Andrew

Sean_Bohan (Thu, 14 Sep 2017 15:10:39 GMT):
Slava - also important, limitation of message length depending on transaction type, now not only generic msg length limitation but also smart limitation

Sean_Bohan (Thu, 14 Sep 2017 15:11:51 GMT):
Victor: - can't create large transaction because it is not supposed to be large can inc amount of size for overall batch of transactions while limiting volume to prevent mechanism 1 limits size of message, another limits by type, provides control over msg lengths, limits are configurable

Sean_Bohan (Thu, 14 Sep 2017 15:13:13 GMT):
Nathan - questions about limits or configurations No questions Nathan to Kelly - lets discuss outstanding issues or blockers, anything impacted by change

Sean_Bohan (Thu, 14 Sep 2017 15:15:48 GMT):
Indy SDK achievements 1. creation of dedicated Indy lib and repo on HL github purpose to provide crypto for hyperledger indy project for this lib, 3 diff interfaces: native C interface to create diff wrappers for languages provides RUST interface provides Python wrapper implemented DLS signatures, create multisig and verify multisignatures library for state proofs working together with Indy Node team, release funct together in Indy Node and Indy SDK

Sean_Bohan (Thu, 14 Sep 2017 15:16:27 GMT):
some changes in Python wrapper of LibIndy for now possible to use Python wrapper, most common version installation will be simplified, dont need additional repos

Sean_Bohan (Thu, 14 Sep 2017 15:17:01 GMT):
enhancement of ? wrapper possible to do custom wallet types code is finished but in review and avail in next version of Indy SDK

Sean_Bohan (Thu, 14 Sep 2017 15:19:04 GMT):
Nathan - all this work is avail and follow along with Jira.hyperledger.org login opens access to active sprint and backlog views, see both views, current sprint and work slava mentioned Indy SDK process, inside project is LibIndy (sprint 8 wrapping now) getting ready to kick off Sprint 9 Indy project, sprint 12, getting ready for sprint 13 active sprint view - tickets havent started, lot in code review, not all tickets Questions about getting involved with this work?

Sean_Bohan (Thu, 14 Sep 2017 15:21:16 GMT):
Who is working on what over the next few weeks, help coord who is working on what, merge conflicts, changes, help account for testing that should be happening in parallel Simon and Marcus document this wonderfully helps with requirements and work, pushing forward

Sean_Bohan (Thu, 14 Sep 2017 15:21:27 GMT):
Agent Call next Thursday

Sean_Bohan (Thu, 14 Sep 2017 15:22:04 GMT):
One thing to mention, in upcoming sprint, whole series of tasks to do to graduate from incubation in Hyperledger branding of folders and files, codebase works against Indy (not Sovrin), tasks for security and general cleanup

Sean_Bohan (Thu, 14 Sep 2017 15:22:45 GMT):
Node codebase - folders and files with Sovrin in path name, need to refactor for Indy instead files structure needs work data files need work, placed on system in a a way to make it difficult

Sean_Bohan (Thu, 14 Sep 2017 15:24:07 GMT):
working on effort to enumerate where all files are on disc, config files, org in such a way that is clean and logical, clear which files belogn to whcih network create test network? move that to production without loss make cleaner and more logical, on SDK side makes more sense to have more than one indy network, might move from instance-test -network to production

Sean_Bohan (Thu, 14 Sep 2017 15:25:48 GMT):
think we can make the process smoother and avoid mistakes, state files or directories that have data that we dont need to get rid of but not use for a period of time slava and team working on organization, posting links on Rocketchat CHANGES HAVE SOME AMOUNT OF RISK ASSOCIATED hoping to get feedback on final destination of files and folders, have migration scripts as part of the upgrade, no disruption to the core of the system bring it up here - you may have written tools or monitoring or logic that depends on certain files in cert locations, we want to avoid disruptions along the way

nage (Thu, 14 Sep 2017 15:29:34 GMT):
IMPORTANT: the Ledger WG Zoom number will change two weeks from now (we plan on making it the same as the current Agent WG call number)

nage (Thu, 14 Sep 2017 15:29:47 GMT):
Chicago hackfest next week (filling up fast)

nage (Thu, 14 Sep 2017 15:30:09 GMT):
nage will be there to hack on things related to indy-crypto, did specs, and other indy stuff

nage (Thu, 14 Sep 2017 15:30:42 GMT):
hackathon-for-good event in Dublin following after that (end of September)

Sean_Bohan (Thu, 14 Sep 2017 15:30:54 GMT):
Comments? Questions? Links to all this good stuff coming

nage (Thu, 14 Sep 2017 15:31:06 GMT):
where they want to cover various topics related to Identity and would love to see projects involving Indy (prizes are available)

nage (Thu, 14 Sep 2017 15:31:47 GMT):
Time is now open for general discussion and questions

nage (Thu, 14 Sep 2017 15:34:58 GMT):
Without any more questions we'll end the call (thanks everyone for coming!)

nage (Thu, 14 Sep 2017 15:35:18 GMT):
_will post the recordings in the usual place once the are finished converting_

nage (Thu, 14 Sep 2017 15:47:15 GMT):
https://drive.google.com/open?id=0B0ChWSmqhJemUzZyTnJaVnJZMjA

spivachuk (Thu, 14 Sep 2017 16:59:00 GMT):
Please find today's status of Indy-Node team: - Presenting Signed State Proof for client request: continue debugging and testing. - Support for multiple pool networks: working on directories layout reorganization in indy-plenum and indy-node. - Providing quick system status on validators: implemented tests for ledgers states, implemented tests in indy-node for config ledger, debugging. - Limiting transaction size on the basis of its type: debugging CLAIM_DEF transaction validation. - Issue with absence of nym's role in "send GET_NYM" command output: investigating the issue. - Test Automation: completed refactoring of the acceptance test of removing / adding roles, isolating sovrin and acceptance projects from each other in indy-node repository. - Acceptance testing of the release candidate.

srottem (Fri, 15 Sep 2017 08:09:26 GMT):
Are the SDK guides mentioned on yesterday's call availably anywhere for review?

spivachuk (Fri, 15 Sep 2017 08:14:34 GMT):
@srottem, are you about the guides on setup of indy-sdk/samples/python project and installation of libindy and its python wrapper into developer environment?

srottem (Fri, 15 Sep 2017 08:29:46 GMT):
I guess so...I'm just going from the notes Sean logged about yesterday's call.

spivachuk (Fri, 15 Sep 2017 08:42:04 GMT):
They are here: https://docs.google.com/document/d/1lMoUihUPWBUqsb_FNUjtOplwm20_nqKbsNEwRoWCpbU https://docs.google.com/document/d/1nbsYvipES3uxTWoyGJnrp_SmCrBmt5tX0ffYRE-ApYU (Both are located in the following folder on google drive: https://drive.google.com/drive/folders/0B4efUY1IocYwX3k1QkpzeTdMWjg)

spivachuk (Fri, 15 Sep 2017 08:42:04 GMT):
They are here: https://docs.google.com/document/d/1lMoUihUPWBUqsb_FNUjtOplwm20_nqKbsNEwRoWCpbU https://docs.google.com/document/d/1nbsYvipES3uxTWoyGJnrp_SmCrBmt5tX0ffYRE-ApYU (Both are located in the following folder on google drive: https://drive.google.com/drive/folders/0B4efUY1IocYwX3k1QkpzeTdMWjg)

spivachuk (Fri, 15 Sep 2017 08:42:04 GMT):
They are here: https://docs.google.com/document/d/1lMoUihUPWBUqsb_FNUjtOplwm20_nqKbsNEwRoWCpbU https://docs.google.com/document/d/1nbsYvipES3uxTWoyGJnrp_SmCrBmt5tX0ffYRE-ApYU (Both are located in the following folder on google drive: https://drive.google.com/drive/folders/0B4efUY1IocYwX3k1QkpzeTdMWjg)

srottem (Fri, 15 Sep 2017 08:51:11 GMT):
Perfect - thanks!

spivachuk (Fri, 15 Sep 2017 13:30:03 GMT):
@nage Could you please clarify, how must we change authority labels like the following one in scope of rebranding? `Evernym, Inc. March 2016`

nage (Fri, 15 Sep 2017 13:31:43 GMT):
No, things like copyright statements and comments about code origins should remain unchanged

spivachuk (Fri, 15 Sep 2017 13:43:08 GMT):
Ok, thank you

spivachuk (Fri, 15 Sep 2017 17:49:45 GMT):
Please find today's status of Indy-Node team: - Sprint planning activities. - Issue with validator lagging behind the rest of nodes in pool: investigating and fixing the failing test. - Presenting Signed State Proof for client request: fixing seq_no in GET_NYM transaction, debugging and testing. - Support for multiple pool networks: continue work on directories layout reorganization. - Removing all non-Indy branding from Indy repositories: removing non-Indy brands from code, docs and paths, updated dockerfiles with testing env, testing Jenkins pipelines. - Integrating BLS crypto math: completed integration of indy-crypto library; writing tests. - Confirmation testing. - Logging newly found bugs.​

andkononykhin (Mon, 18 Sep 2017 09:49:01 GMT):
Has joined the channel.

spivachuk (Mon, 18 Sep 2017 18:24:52 GMT):
Please find today's status of Indy-Node team: - Anchoring of the pool ledger state: providing information about the pool state to be used for multi-signature verification. - Presenting Signed State Proof for client request: writing tests and debugging. - Integrating BLS crypto math: moving to the new indy-crypto API (installing indy-crypto library and its python wrapper). - Issue with validator lagging behind the rest of nodes in pool: completed the fix. - Support for multiple pool networks: continue work on directories layout reorganization. - Removing all non-Indy branding from Indy repositories: completed removal of non-Indy brands from indy-plenum and indy-anoncreds, removing non-Indy brands from indy-node. - Inability of pool to recover after loss of consensus in case view change was happened: reproducing the issue. - Exploratory testing. - Performance testing.

spivachuk (Tue, 19 Sep 2017 17:53:35 GMT):
Please find today's status of Indy-Node team: - Anchoring of the pool ledger state: implementing multi-signature, fixing root hash in Pre-Prepare messages, adding pool root hash to multi-signature, refactoring, debugging. - Presenting Signed State Proof for client request: discussing signed state proofs and multi-signatures, fixing tests for state proofs. - Integrating BLS crypto math: testing indy-crypto integration; integrating into build. - Support for multiple pool networks: continue work on directories layout reorganization. - Removing all non-Indy branding from Indy repositories: completed removal of non-Indy branding from indy-node repo, designing node control tool modification to support re-branding migration. - Inability of pool to recover after loss of consensus in case view change was happened: fixed the issue. - Issue with absence of nym's role in "send GET_NYM" command output: fixed the issue. - Confirmation testing. - Exploratory testing.

spivachuk (Tue, 19 Sep 2017 17:53:35 GMT):
Please find today's status of Indy-Node team: - Anchoring of the pool ledger state: implementing multi-signature, fixing root hash in Pre-Prepare messages, adding pool root hash to multi-signature, refactoring, debugging. - Presenting Signed State Proof for client request: discussing signed state proofs and multi-signatures, fixing tests for state proofs. - Integrating BLS crypto math: testing indy-crypto integration; integrating into build. - Support for multiple pool networks: continue work on directories layout reorganization. - Removing all non-Indy branding from Indy repositories: completed removal of non-Indy branding from indy-node, designing node control tool modification to support re-branding migration. - Inability of pool to recover after loss of consensus in case view change was happened: fixed the issue. - Issue with absence of nym's role in "send GET_NYM" command output: fixed the issue. - Confirmation testing. - Exploratory testing.

sklump (Tue, 19 Sep 2017 18:06:42 GMT):
Has left the channel.

swcurran (Tue, 19 Sep 2017 22:25:07 GMT):
We've been struggling with trying to get Indy-Node instances running in an OpenShift (Kubernetes) environment. The main challenge has been because of Indy-Node's use of systemd and running as root. In thinking about solutions, the use of systemd becomes unnecessary if an assumption is made that Indy-Node will run in a container-ized environment. If you assume containers, the container is "the service", the container manager (eg. Kubernetes, etc) manages robustness, scaling, etc. and so having Indy-Node running without systemd becomes viable. We think it would be a lot easier to test, more supportable and deployment becomes a lot easier (e.g. all the arguments for containers). It does require that Stewards run a container environment, but these days, that is becoming the norm for most organizations, let alone those forward thinking enough to be running Sovrin. Thoughts on that?

ashcherbakov (Wed, 20 Sep 2017 09:41:40 GMT):
I think there are some security reasons why it's assumed that Stewards doesn't use containers now. The Node itself doesn't require root, it's run from 'sovrin' user. It's the node-control-tool-service that requires root. This service is responsible for auto updates (POOL_UPGRADE txn), so it stops node service, performs update (apt-get), and restarts the node service.

gudkov (Wed, 20 Sep 2017 11:02:27 GMT):
From my point of view, indy node must support deployment on different platforms and different nodes must be deployed different ways. Otherwise one security issue in Kubernetes or OS that is used as base for docker image can affect the whole pool. Also hypervisor based environments (actually the most of SaaS based container and virtual environments) can have problems with crypto random numbers generation.

swcurran (Wed, 20 Sep 2017 14:32:31 GMT):
Sounds good. Not the end of the world - just something we're grappling with. We're adjusting the deployment to work with openshift and it looks like (fingers crossed!) it will work without systemd. We'll see what we have to change and see if that is worth contributing back or if it will lead to useful suggestions for adjustment. Our current purpose is to just run a test network, but it will give us some experience if we do go the Steward path.

darrell.odonnell (Wed, 20 Sep 2017 16:04:01 GMT):
I'm a bit too high-level to know definitely. We've had a few projects shift between systemd and other daemon running tools so I can't see what they would have done to block that.

tharmon (Wed, 20 Sep 2017 17:21:46 GMT):
There are a couple of different things going on here, from my perspective. 1) There is a big difference between running a validator in a testing environment and running on in a production environment. The current thought is that for a number of reasons a production validator should run either on bare metal or on a fairly beefy VM. So, there's a bias towards that in the coding. For those running on the Sovrin Network, the Sovrin Provisional Trust Framework (https://sovrin.org/wp-content/uploads/2017/06/SovrinProvisionalTrustFramework2017-03-22.pdf) Technical Requirements basically mandate this (Section 7.1). That said, we would certainly like your participation in the working groups to discuss how containers may become a possibility in the future (ping @nage). That's also one of the best places to get the deep technical reasoning behind why certain decisions have been made. 2) The environments provided in evernym/sovrin-environments aren't part of the official release, but instead are part of a community effort to help each other build up testing environments. They certainly lag behind what is produced, and also occasionally diverge in other ways (though we try to get them back in sync as quickly as possible). I suspect that's where the running as `root` is coming from. That's not how it's suppose to be done. With this, we invite as many contributions as possible to help make the environments provided here better and easier to use. The goal of this particular repository is to provide methods to quickly set up working pools for testing--which is right in line with @swcurran's purpose. Big point, @swcurran, I love your interaction and pushing the community to make things better for everyone.

swcurran (Wed, 20 Sep 2017 17:43:10 GMT):
Thanks for the response - especially pointing out the details in section 7.1 - interesting stuff. The High Availability needs are indeed different than a "typical" app we deal with, so the non-container world does make sense - at least for now. FYI - the good news is that our approach for our test network is working and we're miles ahead of where we were yesterday :-). We're consolidating what's been done and we'll see if we have things to contribute back to the evernym/sovrin-environments codebase.

spivachuk (Wed, 20 Sep 2017 18:02:16 GMT):
Please find today's status of Indy-Node team: - INDY-791: re-factoring BLS-BFT class for better separation, supporting pool_root_hash in multi-signature. - INDY-790: adding timestamp to state and returning it in reply to get_* requests, fixing tests, supporting state proofs in CLI. - INDY-834: continued to work on copying and adaptation of CI logic from Evernym private repos to indy-plenum's Jenkinsfile. - INDY-580: discussed a simplest option of integrating RPM packaging into Indy CD. - INDY-748: adding indy-crypto into installation scripts. - INDY-831: reviewing and preparing procedure of building from branch to test new folder structure. - INDY-830: designing node control tool modification to support re-branding migration. - INDY-333: found and fixed incorrect formatting in CLI. - INDY-848: started investigation of logs from nodes when primary node becomes broken after view change during load testing. - INDY-266: summarizing of research on view change with lagged nodes. - INDY-744: preparing scenario and cron task for performance testing. - INDY-615: exploratory testing of pool read performance. - INDY-849: confirmation testing, regression testing of pool consensus cases. - INDY-862: exploratory testing of peak pool performance on writes.

spivachuk (Wed, 20 Sep 2017 18:02:16 GMT):
Please find today's status of Indy-Node team: - INDY-791: re-factoring BLS-BFT class for better separation, supporting pool_root_hash in multi-signature. - INDY-790: adding timestamp to state and returning it in reply to get_* requests, fixing tests, supporting state proofs in CLI. - INDY-834: continued to work on copying and adaptation of CI logic from Evernym private repos to indy-plenum's Jenkinsfile. - INDY-580: discussed a simplest option of integrating RPM packaging into Indy CD. - INDY-748: adding indy-crypto into installation scripts. - INDY-831: reviewing and preparing procedure of building from branch to test new folder structure. - INDY-830: designing node control tool modification to support re-branding migration. - INDY-333: found and fixed incorrect formatting in CLI. - INDY-848: started investigation of logs from nodes when primary node becomes broken after view change during load testing. - INDY-266: summarizing of research on view change with lagged nodes. - INDY-744: preparing scenario and cron task for performance testing. - INDY-615: exploratory testing of pool read performance. - INDY-849: confirmation testing, regression testing of pool consensus cases. - INDY-862: exploratory testing of peak pool performance on writes.

spivachuk (Thu, 21 Sep 2017 19:21:54 GMT):
Please find today's status of Indy-Node team: - INDY-670: fixing generation of BLS keys for new nodes, supporting state proofs in CLI. - INDY-791: supporting anchoring of pool ledger state, making all the tests pass. - INDY-834: finished debugging CI pipeline for indy-plenum, waiting for PR merge after all tests pass. - INDY-834, INDY-835, INDY-856: reorganized pipelines on Jenkins. - INDY-580: described how Indy CI and CD pipelines will work separately. - INDY-837 [BLOCKED]: information is needed how CI should be moved to Hyperledger Jenkins. - INDY-831: debugging node running with new file structure. - INDY-830: finished designing re-branding migration of node, implementing re-branding migration of node. - INDY-848: continued investigation of issue related to broken primary node after view change during load testing. - INDY-831, INDY-832, INDY-833: testing of incubation changes. - INDY-744: completing cron task for performance testing and load_test output parser. - INDY-865: exploring current behavior of pool when nodes have different genesis files. - INDY-862: performance pool re-installation, running tests. - INDY-868: performed exploratory testing of how long transaction is held waiting for consensus.

spivachuk (Fri, 22 Sep 2017 18:59:31 GMT):
Please find today's status of Indy-Node team: - INDY-670: finished implementation of multi-signatures, all the tests pass in plenum. - INDY-790: fixing generation of BLS keys for new nodes, supporting state proofs in CLI. - INDY-835, INDY-856: made necessary changes in indy-anoncreds and indy-node repositories to support separate pipelines for CI and CD, reconfigured pipelines. - INDY-830: finished implementing re-branding migration of node, testing it. - INDY-831: debugging plenum running with new file structure. - INDY-831, INDY-832, INDY-833: continued testing of incubation changes, started to work on migration script. - INDY-744: finished writing cron task. - INDY-865: completed exploratory testing of node catch-up in case of invalid genesis pool txn file. - INDY-867: working on exploratory testing of client catch-up in case of updated node keys. - INDY-862: completed exploratory testing of max transactions throughput. - INDY-864: working on exploratory testing of manual catch-up on a new node.

spivachuk (Fri, 22 Sep 2017 18:59:31 GMT):
Please find today's status of Indy-Node team: - INDY-670: finished implementation of multi-signatures, all the tests pass in plenum. - INDY-790: fixing generation of BLS keys for new nodes, supporting state proofs in CLI. - INDY-835, INDY-856: made necessary changes in indy-anoncreds and indy-node repositories to support separate pipelines for CI and CD, reconfigured pipelines. - INDY-830: finished implementing re-branding migration of node, testing it. - INDY-831: debugging plenum running with new file structure. - INDY-831, INDY-832, INDY-833: continued testing of incubation changes, started to work on migration script. - INDY-744: finished writing cron task. - INDY-865: completed exploratory testing of node catch-up in case of invalid genesis pool txn file. - INDY-867: working on exploratory testing of client catch-up in case of updated node keys. - INDY-862: completed exploratory testing of max transactions throughput. - INDY-864: working on exploratory testing of manual catch-up on a new node. - INDY-837 [BLOCKED]: information is needed how CI should be moved to Hyperledger Jenkins.

darkcrux (Fri, 22 Sep 2017 19:53:25 GMT):
Has joined the channel.

darkcrux (Fri, 22 Sep 2017 19:53:48 GMT):
Has left the channel.

spivachuk (Mon, 25 Sep 2017 18:55:41 GMT):
Please find today's status of Indy-Node team: - INDY-670: pushing multi-signature changes to indy-node repository. - INDY-790: supporting state proofs in CLI, debugging. - INDY-832: working on CLI refactoring in scope of providing support for multiple pool networks. - TE-63: completed Puppet learning quest, posted summary as a report to the task. - INDY-831: debugging plenum running with new file structure. - INDY-830: set up environment for installation and upgrade of pool in Docker from local deb files, testing re-branding upgrade of node. - INDY-833: continue working on migration script. - INDY-834, INDY-835, INDY-856: verifying changes in CD for indy-node, indy-plenum and indy-anoncreds. - INDY-837 [BLOCKED]: information is needed how CI should be moved to Hyperledger Jenkins.

spivachuk (Tue, 26 Sep 2017 18:17:12 GMT):
Please find today's status of Indy-Node team: - INDY-790: supporting state proofs in CLI, debugging. - INDY-832: working on CLI refactoring in scope of providing support for multiple pool networks. - IS-353: helped Indy-SDK team to move artifacts from repo.evernym.com to repo.sovrin.org. - INDY-869: started to explore logs on the issue with automatic rollback of successful upgrade. - INDY-831: debugging plenum running with new file structure. - INDY-830: tested and debugged rebranding upgrade of node. - INDY-833: working on migration script for directories layout reorganization.

WadeBarnes (Tue, 26 Sep 2017 18:28:32 GMT):
Has joined the channel.

spivachuk (Wed, 27 Sep 2017 18:37:43 GMT):
Please find today's status of Indy-Node team: - INDY-876: Supporting new indy-crypto in plenum. - INDY-790: testing and debugging support for state proofs in client requests. - INDY-832: working on CLI refactoring in scope of providing support for multiple pool networks. - INDY-831: debugging plenum running with new file structure. - INDY-830: implementing rebranding migration of wallet. - INDY-833: finished migration script for directories layout reorganization, designing new structure of configuration files. - INDY-580: shared a plan on CentOS RPMs logic integration into the pipelines. - INDY-837: started moving CI to Hyperledger infrastructure. - Fixed minor issues on Jenkins agents caused by non-accurate cleanup procedure in one of the pipelines. - Fixed next-build-counter for indy-node/stable pipeline which had been broken after recent push to Git in scope of the hotfix for broken pool upgrade.

sklump (Thu, 28 Sep 2017 14:05:27 GMT):
Has joined the channel.

Sean_Bohan (Thu, 28 Sep 2017 15:03:23 GMT):
Notes for the Indy-Node (Ledger) WG Call - 9/28/2017

Sean_Bohan (Thu, 28 Sep 2017 15:03:44 GMT):
Antitrust Policy Notice shared

Sean_Bohan (Thu, 28 Sep 2017 15:04:12 GMT):
Code Changes and Tickets in Progress Jira.hyperledger.org sign in with Linux Foundation account, see active sprints, participate in development work

Sean_Bohan (Thu, 28 Sep 2017 15:05:06 GMT):
Alex: Sprint Update https://docs.google.com/spreadsheets/d/1zFsTXaYDIu4p2bHTEdVYUk771KIpi8QdUUjkjr7OepY/edit#gid=0 SPrint 13 List of tasks Link to demos

Sean_Bohan (Thu, 28 Sep 2017 15:07:45 GMT):
results for indyNode core team finished implementation of signed states and state proof find demos at link above support state proofs in Python CLI consensus extended with BLS signatures applies to clients Next task get rid of non-Indy branding in Source Code Plenum, etc. 3 stories, part of incubation next tasks splitting CI and CD pipelines have CI jenkins file which is public in repo and source code and CI jenkins file integrated into public Jenkins owned by Hyperledger - accessible executed for each of the PRs to run the tests before we merger PR any dev can look at HL Jenkins and see status of the tests Continuous Delivery pipeline concurrent provide builds and apply packages in corresponding repos done on code level next - integrate w/ Hyperledger's Jenkins

Sean_Bohan (Thu, 28 Sep 2017 15:07:53 GMT):
Bug Fixes and Exploratory testing by QA

Sean_Bohan (Thu, 28 Sep 2017 15:09:16 GMT):
in progress, file folder refactoring paths for services, log files, data folders Nathan - big deal, files and folders moving around could disrupt tools built on nodes doing to make things work better and make more clear what files work in what parts of the system (esp if you work on sandbox vs provisional network) working on migration scripts want everyone doing dev and tools to be aware of no one caught off guard

ashcherbakov (Thu, 28 Sep 2017 15:09:21 GMT):
Next Sprint: https://docs.google.com/spreadsheets/d/1NCQCuV5cgSUyN8Pu3ZuCOKXCDVQpreaba0_upuTUzHI/edit#gid=1981889941

Sean_Bohan (Thu, 28 Sep 2017 15:10:17 GMT):
Alex - Next sprint SPRINT 14 Goal - provide stable release candidate for upgrade of pool should contain signed state proof support - completed and tested and verified by QA

Sean_Bohan (Thu, 28 Sep 2017 15:11:19 GMT):
incubation tasks (file folder refactoring and renaming) Bug fixes Code refactoring continuous improvement of code base, better documentation for developers

Sean_Bohan (Thu, 28 Sep 2017 15:11:43 GMT):
spreadhseet contains status of team for each day look there or indy node rocket chat w/ status of tests we are working on

Sean_Bohan (Thu, 28 Sep 2017 15:15:47 GMT):
Slava Indy SDK State proofs and BLS multi sig code implemented displayed in pull request, merging soon into Indy Node and Plenum packages Also - incubation tasks similar tasks for SDK (renaming, CI and CD efforts - similar to Indy Node repos) remove binary artifacts to community repos only exception is making compatible repos for java wrapper plan in the future - move to maintenance perform bug fixes use different cure for BLS Multisig and BLS Nathan Indy crypto lib has been changed to use more secure type 3 pairing curve move SDK over official supported curve for anoncreds going forward open to community - if people have claims they have made that require compatibility - please speak up most claims in ecosystem on PoC projects, reissue in future if you know it will be disruptive please let us know (here, mailing list, direct, rocketchat, etc.)

Sean_Bohan (Thu, 28 Sep 2017 15:15:59 GMT):
Slava Python version of Anoncreds?

Sean_Bohan (Thu, 28 Sep 2017 15:16:29 GMT):
Alex - py version not yet fixed w/ new curve one of next plans in future sprint to fully get rid of Py anoncreds and client, switch to INDY SDK

Sean_Bohan (Thu, 28 Sep 2017 15:16:39 GMT):
implement CLI in Indy SDK

Sean_Bohan (Thu, 28 Sep 2017 15:17:52 GMT):
of course, important thing - take into account current wallets people may have, provide some kind of migration from old wallets ot new one by Indy SDK use Indy SDK for Indy Node test time dependency use Indy SDK to test how pool works, after items done deprecate Python code in anoncreds as well can fix current python anoncreds to use new curve as well

Sean_Bohan (Thu, 28 Sep 2017 15:18:47 GMT):
ALEX next print main goals - finish current tasks and provide builds bug fixing update - very critical for stable pool further plans, next thing, agent-agent communication more for SDK not ledger

Sean_Bohan (Thu, 28 Sep 2017 15:19:35 GMT):
other plans, important features - DDO support for DID, revocation support (supported in anoncreds code and protocol) but not supported in ledger in terms of transactions (we have schema and claim definition to store for primary claims but not revocation keys yet)

jljordan_bcgov (Thu, 28 Sep 2017 15:20:10 GMT):
+1 for revocation

Sean_Bohan (Thu, 28 Sep 2017 15:20:11 GMT):
next possible thing in roadmap is related to stats on the ledger, to have tools and ways to see whats going on in the ledger, some kind of UI basic things for near future

Sean_Bohan (Thu, 28 Sep 2017 15:20:43 GMT):
NATHAN indy crypto library as basis for shared crypto library for Hyperledger

jljordan_bcgov (Thu, 28 Sep 2017 15:21:40 GMT):
going forward does it make sense that there could be more that one crypto function supported within the ecosystem and therefore verifiable claims may need to be associated with specific crypto algorithm as time passes?

Sean_Bohan (Thu, 28 Sep 2017 15:22:29 GMT):
across Indy and could be shared across other projects at Hyperledger as well interest from Sawtooth folks, validate creds with claims and proofs, threshold sig implmeentaiton for BLS, other ZK crypto primitives, ED 25519 curve, more useful way, better for ledger to consume than Apache-Milagro crypto lib breaking up the org of the library, where crypto primitives in lib might decide to break into file system and network comms and one for serialization/data formats

Sean_Bohan (Thu, 28 Sep 2017 15:22:43 GMT):
if someone is trying to consume anoncreds protocol in a secure enclave, easier to do so

Sean_Bohan (Thu, 28 Sep 2017 15:23:12 GMT):
roadmap plans, longer term

Sean_Bohan (Thu, 28 Sep 2017 15:24:41 GMT):
Jljordan42's question Answer - yes, possibly (quantum computing use case, something to harden further), still need to validate and exchange proofs from before - business ceases to exist and still use claim issued, but right now no significant use no need to carry forward rather drop from being supported and not carry old version do want to support multple versions of protocol, look to add

Sean_Bohan (Thu, 28 Sep 2017 15:25:11 GMT):
NATHAN Quantum case

Sean_Bohan (Thu, 28 Sep 2017 15:25:35 GMT):
if it happenss, crypto community will have more problems than just claims and proofs in Indy - hopefully more time to react

Sean_Bohan (Thu, 28 Sep 2017 15:26:23 GMT):
OTHER DISCUSSIONS?

Sean_Bohan (Thu, 28 Sep 2017 15:28:02 GMT):
Nathan Hackfest Chicago update Lot of interest in INDY and work the community is doing using Vagrant setup script VMs over conference wifi maybe "too much" Docker images preferred we do have a Docker environment, Nathan looking to switch over folks started with GSG, CLI based agents with claims and proofs feedback on PoCs, VerClaiims up and running medical use cases, other exciting prototypes

Sean_Bohan (Thu, 28 Sep 2017 15:28:26 GMT):
what sorts of things that worked well, needed more help with related to that - hackathon in Dublin this weekend

Sean_Bohan (Thu, 28 Sep 2017 15:28:27 GMT):
http://events.linuxfoundation.org/events/blockchain-for-good-hackathon/program/agenda

jljordan_bcgov (Thu, 28 Sep 2017 15:28:41 GMT):
@WadeBarnes submitted a pull request to sovrin-environments with an OpenShift deployment implementation that also includes improvements to docker files

Sean_Bohan (Thu, 28 Sep 2017 15:29:04 GMT):
PLEASE HELP OVER THE WEEKEND _ monitoring Indy Agent and Indy Node rocket chat rooms to help hackathon attendees!

Sean_Bohan (Thu, 28 Sep 2017 15:29:22 GMT):
TRACEY Great we are supporting hackathon in dublin

Sean_Bohan (Thu, 28 Sep 2017 15:35:53 GMT):
NATHAN Share crypto lib Hart Montgomery to put out email comms to bootstrap project and propose to TSC anyone who wants to be more involved with crypto reach out to Hart directly or Nathan and he will get you included in the effort cross project efforts Call for participation there notice - lot of basic rebrand efforts to change Sovrin to Indy as you explore the code, and find references to Sovrin in gitHub, good things to log tickets against streamline and simplify hwo to get people started or bad or stale links, duplicated documentation, also would love to see Jira tickets call for participation lurking for a while, get contribs into the project, easy ways to get started

Sean_Bohan (Thu, 28 Sep 2017 15:37:30 GMT):
TRACEY Question for graduating from incubation - when? NATHAN high level tasks trying to get thru, Observer node tier up and running, other things feature complete, not sure how long to take, basic trademark cleanup, get thru it, enforcing some branding guidelines and requirements basic cleanup done, help community decide what point "we have enough here and enough use cases to officially graduate" Tracey latest license scans, get a ticket for updating, making sure they get resolved to

Sean_Bohan (Thu, 28 Sep 2017 15:37:51 GMT):
as we get closer to knowing where/when - include HL PR folks, messaging to the press

Sean_Bohan (Thu, 28 Sep 2017 15:39:43 GMT):
NATHAN CHanges to how agent-agent comms can occur found pairwise curve zmq proto for agent-agent has difficulty integrating into app environments (android, iOS) and mechanics of handshake - going to libsodium based encryption, HTTP or HTTPS and sign over that channel to allow agent comms between environments with less work and avoid hurdles in the past Indy SDK milestone

Sean_Bohan (Thu, 28 Sep 2017 15:40:09 GMT):
Slava and Devin coord some of that effort expect talk more about it in the agent WG call next week open to general questions

Sean_Bohan (Thu, 28 Sep 2017 15:40:22 GMT):
QUESTIONS?

Sean_Bohan (Thu, 28 Sep 2017 15:42:24 GMT):
KELLY - Upgrade issues

Sean_Bohan (Thu, 28 Sep 2017 15:44:30 GMT):
did an upgrade of provisional network, main issue found, when setting up live pool, defaults are set to a sandbox pool need to override in Sov config settings upgrade runs migration script, as root, conffig files as sov user, failing on the upgrade there was a bug fixed after provisional where system was in upgrade loop, pool bouncing, got it fixed and pushed into package, up and running now, gone through and addressed issue, dress up things for upgrade basic issue

Sean_Bohan (Thu, 28 Sep 2017 15:44:49 GMT):
NATHAN In JIRA there are a whole set of tickets named "upgrade" and bug fixes to address issues

Sean_Bohan (Thu, 28 Sep 2017 15:45:50 GMT):
more difficult to have confusion on how update settings worked rearranging config files 3 sep config files - user, system daemon and global think some will help reduce risk of this happening again, easier for scripts to find settings in question, other fixes related to make it easier to handle and manage that part of the code

Sean_Bohan (Thu, 28 Sep 2017 15:46:08 GMT):
more to discuss in 2 weeks as those tickets come into scope of work that people are actively persuing

Sean_Bohan (Thu, 28 Sep 2017 15:46:24 GMT):
JAMES WAUGH quick question

Sean_Bohan (Thu, 28 Sep 2017 15:48:55 GMT):
interested in the crypto lib, collab between Indy and Sawtooth NATHAN collab in early stages really like working with Mic, interesting ideas of integration points that make sense, see which bear fruit try things in particular, secure execution environments are super relevant to key management lot of integration team specifically related to how key management can function, make sure keys cant be stolen or phished Sawtooth generally - data streams that can use external validation Verifiable Claim to allow you to see or interact with data that is on a different ledger Data Stream of supply chain data, on an enterprise ledger, grant access to others based on their sovereign ID, give claims, have proof of ability to see data

Sean_Bohan (Thu, 28 Sep 2017 15:49:46 GMT):
Ledger able to grant access to info, allow transact to occur based on approval distributed instead of Fabric CA and you can depend on external root of trust w/o haveing to contact CAs or have centralized infrastructure

Sean_Bohan (Thu, 28 Sep 2017 15:50:08 GMT):
remains to be seen how much work would be put there interested in those who want to do PRs

spivachuk (Thu, 28 Sep 2017 17:28:38 GMT):
Please find today's status of Indy-Node team: - INDY-790: debugging state proofs on client. - INDY-832: support for multiple pool networks: working on CLI refactoring. - INDY-831: support for multiple pool networks: finished debugging tests in plenum, continue with deb package generation scripts and test network. - INDY-830: debugging rebranding migration of wallet. - INDY-878: started clean-up of baseDir configuration parameter usage. - INDY-837: read documentation on Jenkins job builder and Gerrit. - Explored and fixed indy-node master build failure. - Fixing dependency of indy-plenum on indy-crypto. - Prepared demos of the sprint achievements.

Suedonym (Thu, 28 Sep 2017 19:46:16 GMT):
Recording of today's meeting is here: https://drive.google.com/drive/folders/0B0boW7wc5MQ9b0lIZFBkUzdmdTA?usp=sharing

spivachuk (Fri, 29 Sep 2017 18:27:50 GMT):
Please find today's status of Indy-Node team: - INDY-790: debugging state proofs on client. - INDY-832: finished refactoring of CLI in scope of providing support for multiple pool networks. - INDY-882: checked that multiple APT repositories could coexist on the same host, designed how to adjust current publishing logic to satisfy Indy Core and Indy SDK requirements, started to improve sovrin-packaging. - INDY-831: debugging node and client run on generated test pool, debugging installation from DEB packages. - INDY-830: finished debugging re-branding migration of wallet. - INDY-878: working on reorganizing configs, created platform and user configs, started modification of building and installation processes.

Artemkaaas (Sat, 30 Sep 2017 09:05:01 GMT):
Has joined the channel.

mzk-vct (Sun, 01 Oct 2017 12:15:52 GMT):
Has joined the channel.

spivachuk (Mon, 02 Oct 2017 18:29:48 GMT):
Please find today's status of Indy-Node team: - INDY-754: improving public documentation available on GitHub. - INDY-790: debugging of state proofs on client, state proofs for missing data. - INDY-882: indy-crypto support in CI/CD: finished refactoring of debs upload logic, adjusted debs copying logic. - INDY-831: support for multiple pool networks: debugging client run on generated test pool, debugging installation from deb packages. - INDY-830: rebranding in indy-node: merging the changes with master branch. - INDY-880: updating sovrin package correspondingly to performed rebranding. - INDY-878: modified build scripts to create / merge user configs. - INDY-744: load acceptance test: reviewing test results and updating schedule.

spivachuk (Tue, 03 Oct 2017 17:28:29 GMT):
Please find today's status of Indy-Node team: - INDY-790: debugging of state proofs on client, state proofs for missing data. - INDY-882: indy-crypto support in CI/CD: started testing on Jenkins. - INDY-831: support for multiple pool networks: merged with rebranding changes, debugging client run on generated test pool, debugging installation from deb packages. - INDY-830: finished merging the changes with master branch, performed smoke testing of the merged code. - INDY-880: finished updating sovrin package correspondingly to performed rebranding. - INDY-891: updating sovrin-environments correspondingly to performed rebranding. - INDY-878: configs reorganization: continued working on indy-node installation scripts, started working on installation scripts of sovrin package. - Devops tasks: cleaned Jenkins agent, there were a lot of unused docker images that caused lack of space.

bryanhuang (Wed, 04 Oct 2017 02:40:29 GMT):
Has joined the channel.

cre8bidio (Wed, 04 Oct 2017 14:18:02 GMT):
Has joined the channel.

spivachuk (Wed, 04 Oct 2017 18:31:11 GMT):
Please find today's status of Indy-Node team: - INDY-877: supporting protocol version to be used in each request from clients (this is needed for backward compatibility of old clients with state proofs feature: state proofs will not be sent to old clients). - INDY-790: implementing state proofs for missing data, writing additional tests. - INDY-882: finished debs copying logic refactoring, testing. - INDY-831: debugging installation from deb packages. - INDY-891: completed supporting rebranding in Docker env of sovrin-environments, supporting rebranding in Vagrant env. - INDY-878: started refactoring of plenum code according to new config structure. - INDY-830, INDY-880: regression testing after rebranding. - INDY-670: testing of signed state, regression testing.

spivachuk (Thu, 05 Oct 2017 18:20:49 GMT):
Please find today's status of Indy-Node team: - INDY-877: providing backward compatibility for clients with state proof support. - INDY-790: Completed state proofs for missing data and tests for this feature. - INDY-699: designing how to make all transactions, requests and replies consistent. - INDY-882: optimized logic of looking for missed package, debugged, tested on remote repository. - INDY-831: debugging installation from deb packages. - INDY-891: completed supporting rebranding in Vagrant env of sovrin-environments, faced issues with deploying OpenShift env using the instructions. - INDY-878: refactoring plenum code according to new config structure. - INDY-670: testing of state proofs.

spivachuk (Thu, 05 Oct 2017 18:20:49 GMT):
Please find today's status of Indy-Node team: - INDY-877: providing backward compatibility for clients with state proof support. - INDY-790: Completed state proofs for missing data and tests for this feature. - INDY-699: designing how to make all transactions, requests and replies consistent. - INDY-882: optimized logic of looking for missed package, debugged, tested on remote repository. - INDY-831: debugging installation from deb packages. - INDY-891: completed supporting rebranding in Vagrant env of sovrin-environments, faced issues with deploying OpenShift env using the instructions on sovrin-environments. - INDY-878: refactoring plenum code according to new config structure. - INDY-670: testing of state proofs.

Sean_Bohan (Fri, 06 Oct 2017 13:10:59 GMT):
indy-node friends: We are planning next week's Ledger WG call and want your input. Current Agenda: 1. Housekeeping (Sean) 2. Status (Slava and Alex) 3. Indy Roadmap (draft) Discussion (all) If you have ideas, things you want to bring up, projects you want to share, etc. - feel free to comment here in #indy-node or send me a DM

spivachuk (Fri, 06 Oct 2017 17:23:26 GMT):
Please find today's status of Indy-Node team: - INDY-877: supported protocol version. - INDY-895: provided a hot fix for migration. - INDY-790: fixed conflicts with master, let client send read-only requests to one node, wrote migration script. - INDY-849: investigating why pool can't reach consensus after view change. - INDY-882: indy-crypto support in CI/CD: finished Jenkins testing. - INDY-831: debugging installation from deb packages. - INDY-874: changed the user performing the migration that uses getConfig(). - INDY-157: investigating the issue with failed node restart after canceled pool upgrade. - INDY-231: investigating the issue with performing node upgrade on the current date instead of the scheduled date. - INDY-878: refactoring plenum code according to new config structure. - INDY-670: testing of state proofs.

spivachuk (Mon, 09 Oct 2017 18:40:24 GMT):
Please find today's status of Indy-Node team: - INDY-877: fixed protocol version support. - INDY-895: fixed migration for a problem with adding new nodes into a live pool. - INDY-849: investigating why pool can't reach consensus after view change, writing a test for this case. - INDY-882: verified that new API works for stable branches publishing logic, implemented option to skip copying files to backup directory if file already exists, adjusted indy-node and sovrin CD pipelines logic. - INDY-837 [BLOCKED]: read Jenkins job builder docs, started to write YAMLs for our pipelines, found that Jenkins job builder version 1.5.0 from PyPI doesn't support pipeline job type - raised this issue to administrators. - INDY-831: debugging installation from deb packages; debugging CLI connection to network. - INDY-231: writing a test for the fix of the issue with performing node upgrade on the current date instead of the scheduled date. - INDY-878: refactored server part of plenum, started client refactoring. - INDY-670: testing of state proofs. - INDY-877: testing backward compatibility of nodes with state proof support with old clients.

Raffael 5 (Tue, 10 Oct 2017 15:07:25 GMT):
Has joined the channel.

spivachuk (Tue, 10 Oct 2017 18:25:40 GMT):
Please find today's status of Indy-Node team: - INDY-849: fixing the reason why pool can't reach consensus after view change, writing a test for this case. - INDY-837: got a response about JJB version, discussed a possible option to use JJB with Indy pipelines. - INDY-831: debugging CLI connection to network, fixing review notes. - INDY-231: finished writing a test for the bug with a wrong upgrade time, fixed the bug. - INDY-157: fixing the issue with failed node restart after canceled pool upgrade. - INDY-878: refactoring of plenum CLI and client. - INDY-895: testing and debugging the migration for domain ledger with None values. - INDY-670: testing of state proofs.

FranciscoReyes (Wed, 11 Oct 2017 12:38:43 GMT):
Has joined the channel.

spivachuk (Wed, 11 Oct 2017 17:24:46 GMT):
Please find today's status of Indy-Node team: - INDY-849: fixing the reason why pool cannot reach consensus after view change. - INDY-837: implemented YAML for indy-anoncreds and successfully created pipeline project remotely from the command line using JJB, debugging and testing. - INDY-831: adding tests for config tools, fixing review nodes, testing the migration. - INDY-157: finished fixing the issue with failed node restart after canceled pool upgrade. - INDY-878: finished refactoring of node, working on refactoring of CLI and client in plenum and indy. - INDY-895: migration for domain ledger with None values: testing different upgrade and nodes addition scenarios. - INDY-670: testing of state proofs. - INDY-231: confirmation testing of the upgrade time fix.

Paratus (Thu, 12 Oct 2017 05:43:42 GMT):
Has joined the channel.

sergey.minaev (Thu, 12 Oct 2017 08:44:17 GMT):
[ ](https://chat.hyperledger.org/channel/indy-sdk?msg=kzm96n228fetbo2mi)

anttikettunen (Thu, 12 Oct 2017 11:45:11 GMT):
Where are the current Vagrant files & scripts? Getting started guid (here: https://github.com/hyperledger/indy-node/blob/master/getting-started.md#install-indy) has a broken link to evernym's repo.

nage (Thu, 12 Oct 2017 13:09:42 GMT):
The should be here https://github.com/evernym/sovrin-environments

nage (Thu, 12 Oct 2017 13:09:42 GMT):
They should be here https://github.com/evernym/sovrin-environments

nage (Thu, 12 Oct 2017 13:10:55 GMT):
@here If anyone has topics to discuss in today’s developer call, please propose them here, and we will get them on the agenda.

anttikettunen (Thu, 12 Oct 2017 13:14:27 GMT):
Thanks @nage

Sean_Bohan (Thu, 12 Oct 2017 14:14:28 GMT):
Hyperledger Indy Ledger WG Call TODAY 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 Agenda: 1. Housekeeping (Sean) 2. Status (Slava and Alex) 3. Indy Roadmap (draft) Discussion (all)

nage (Thu, 12 Oct 2017 14:49:18 GMT):
We should have an intro to the token work for value transfer today (like what was discussed in the agent discussion last week, perhaps with some info on the config ledger moving down into plenum).

nage (Thu, 12 Oct 2017 14:49:54 GMT):
We should also have some more discussion about the ledger upgrade txn and the downgrade problem

gudkov (Thu, 12 Oct 2017 15:04:40 GMT):
The list of Spring 14 achivments for Indy Core and Indy SDK teams https://docs.google.com/spreadsheets/d/1JSSezTZ6Fon_cWN0XYju9ASjfSSOkzLXsc4v6MPli6Y/edit?usp=sharing

Sean_Bohan (Thu, 12 Oct 2017 15:04:54 GMT):
Notes for Indy Node WG Call 10/12/17 Intros: TracyK from Hyperledger Hyperledger joining DIF (standards, ID, compatibility, interoperability) compat w/ UPort, Blockstack, ID systems on other blockchains

Sean_Bohan (Thu, 12 Oct 2017 15:05:19 GMT):
Linux Foundation Anti Trust policy

Suedonym (Thu, 12 Oct 2017 15:07:39 GMT):
Linux Foundation meetings involve participation by industry competitors, and it is the intention of the Linux Foundation to conduct all of its activities in accordance with applicable antitrust and competition laws. It is therefore extremely important that attendees adhere to meeting agendas, and be aware of, and not participate in, any activities that are prohibited under applicable US state, federal or foreign antitrust and competition laws. Examples of types of actions that are prohibited at Linux Foundation meetings and in connection with Linux Foundation activities are described in the Linux Foundation Antitrust Policy available at http://www.linuxfoundation.org/antitrust-policy. If you have questions about these matters, please contact your company counsel, or if you are a member of the Linux Foundation, feel free to contact Andrew Updegrove of the firm of Gesmer Updegrove LLP, which provides legal counsel to the Linux Foundation.

bhurley (Thu, 12 Oct 2017 15:10:47 GMT):
Has joined the channel.

Sean_Bohan (Thu, 12 Oct 2017 15:11:37 GMT):
Slava Dev Status: Link with sprint info in rocketchat https://docs.google.com/spreadsheets/d/1JSSezTZ6Fon_cWN0XYju9ASjfSSOkzLXsc4v6MPli6Y/edit?usp=sharing Core and SDK team Core team working on continue on State Proofs in CLI too CLI can work with nodes with sep state proofs backward compatibility for state proofs with all clients state proof changes backwards compatible continue work on multiple directories and layout fresh install looks fine, prepping integration script for new nodes

Sean_Bohan (Thu, 12 Oct 2017 15:13:22 GMT):
integration work in progress continue work on rebranding of code to indy wallet now can use diff keys implemented Libindy in Sovrin packages new nodes added to pools SDK team - state proofs changes in state proofs provided by core team also additional calls to wallet sep key rotation in wallet supported new calls

Sean_Bohan (Thu, 12 Oct 2017 15:14:30 GMT):
auth and anon encryption from keys from ledger implemented new methods to host info on pairwise connections between wallets multiple bug fixes, indy SDK team working on design of new agent-agent approach allow more simple way to communicate between agents, plan to get results in next sprint and implementation any questions ?

Sean_Bohan (Thu, 12 Oct 2017 15:14:52 GMT):
Nathan - versioning?

Sean_Bohan (Thu, 12 Oct 2017 15:16:00 GMT):
Slava - State Proofs finished, only problem to create production version w/ sep state proofs is providing way to update current pool plan to implement migration during this sprint, hope soon there will be new release with sep state proofs support in Node, SDK and CLI Daniel - explaiing what State Proofs do and why important

Sean_Bohan (Thu, 12 Oct 2017 15:17:07 GMT):
Nathan - State Proofs - read req off ledger, will come with group sig from all nodes and that is the signed state from all parties in the network, when you get that back from one node you asked question of, verify that is the state of the ledger from F+1 nodes to assure answer is not malicious and ascertain state of the ledger of all trust answer you get back 2 things: ID is read-heavy use case (more reads than writes)

Sean_Bohan (Thu, 12 Oct 2017 15:17:44 GMT):
2. allow building observer node pool - allow smaller # of validators and lager pool of observer nodes high query node can run it against a observer,

Sean_Bohan (Thu, 12 Oct 2017 15:18:51 GMT):
Daniel - clarify adding support for state proofs are returned but also adding verification of state proofs so when indy sdk is called to get question answered, the signature is tested

Sean_Bohan (Thu, 12 Oct 2017 15:19:30 GMT):
Nathan - yes, thats the understanding Slava - good explanation State proof is signed multi-sig, from each nodes and client of pool, verifies all nodes signed this proof

Sean_Bohan (Thu, 12 Oct 2017 15:21:39 GMT):
Daniel timing for state proofs? protocol versioning? Nathan - versioning for protocol and numbering of transactions imp change to evolve an installed ledger Slava - current vision, comms with node, will introduce version of comms protocol, 1 version and also need to intro version of transaction means that transaction, semantically response to some general x related to version how nodes comm w/ each other and with IndySDK for moment we have implemented audit-only version to comm protocol, only reason for change - current responses with state proofs arent compatible with old clients for now the clients that want to use state proof func.t should put version of comm protocol (#1 for now)

Sean_Bohan (Thu, 12 Oct 2017 15:21:54 GMT):
if version isnt provided, regular results w/o state proofs (consensus approach)

Sean_Bohan (Thu, 12 Oct 2017 15:22:03 GMT):
so responses are valid

Sean_Bohan (Thu, 12 Oct 2017 15:22:30 GMT):
plans to have backwards compatible, changes to protocol, use new version

Sean_Bohan (Thu, 12 Oct 2017 15:23:09 GMT):
Nathan - add here, in very long term essentially allows to revise comms protocol, can show/test if they are compatible important to diffuse trust because you dont want a point of failure in any point of system, trust it as much as possible

jljordan_bcgov (Thu, 12 Oct 2017 15:25:59 GMT):
@Sean_Bohan the new sprint labeling scheme will save me a lot of pencils ... thanks :)

Suedonym (Thu, 12 Oct 2017 15:27:13 GMT):
Naming: First number is the year worked on, second number is the week. We are working on removing the name Sovrin from documentation. Working on bugs (continued effort)

Sean_Bohan (Thu, 12 Oct 2017 15:31:40 GMT):
Sean Roadmap will add notes Marta - wondering - inc idea there are upcoming hackfest and meetups into the sprint planning, so as we know there is Lisbon a good way to close out some of the sprints around hackfests Nathan - like it folks from Evernym team and crypto communities adding those callouts in roadmap

Sean_Bohan (Thu, 12 Oct 2017 15:32:07 GMT):
Nathan - trying to call out - if you are working oor need something intent is to say community in general is working on have the open invitiation to jump in and make it happen get those things on the roadmap as well

jljordan_bcgov (Thu, 12 Oct 2017 15:33:14 GMT):
Revocation ....

Sean_Bohan (Thu, 12 Oct 2017 15:34:36 GMT):
Daniel - validator nodes running windows/red hat/cent os distros what is the plan for introducing obs

Sean_Bohan (Thu, 12 Oct 2017 15:38:11 GMT):
Tracy - right place to ask examples people can use to get started with Indy Node

Suedonym (Thu, 12 Oct 2017 15:38:12 GMT):
We need a solid set of getting started snippets; next steps. Code samples, logic trees, etc

Sean_Bohan (Thu, 12 Oct 2017 15:39:41 GMT):
Revocation in Januar - ver claims and ddo support slide 6 as well Slide 6 - dev enviroments bullet - need the docker env to be more useful, so someone doing a test network (Chi hackfest and Dublin hackathon)

Sean_Bohan (Thu, 12 Oct 2017 15:40:17 GMT):
Daniel - GSG using Vagrant Nathan - Vagrant env does 8-9 machines w/ 1 GB ram each, trouble making it run all at once

jljordan_bcgov (Thu, 12 Oct 2017 15:41:08 GMT):
@Sean_Bohan Sounds great thanks

Sean_Bohan (Thu, 12 Oct 2017 15:44:18 GMT):
Daniel - anyone volunteering to be docker maven have an image dont have a higher level construct/team of images all together with a single command lacking/not rocket science if we tackle - someone will fig out how to make it work, check in, announce success, 1-2 months later, some need to tweak, will have forgotten, not centerail to thinking and interest wouldn't naturally realize maintenance to do there someone who cares about docker enough to own it (supervise, build, maintain) Daniel - never done - pick up a new environment and framework and ecosys for Indy to behave as first class constructs - ongoing maintenance not one time task upgrading GSG as a onetime task and not ongoing, neglected, and got stale Nathan - imp point about open source in general - if you want a funct, please come help get the support community is willing to maintain

Sean_Bohan (Thu, 12 Oct 2017 15:44:37 GMT):
daniels point - someone in community who wants docker images to be maintained, it wont happen

Sean_Bohan (Thu, 12 Oct 2017 15:58:31 GMT):
Make a call out to the mailing list on features people might want to see [11:49] letting people know the direction heading, somethign s people want to participate in, can get started sooner rather than later has seen some callouts on the mailing list of diff projects for roadmaps [11:49] document it in a way that makes it available to people [11:49] pointers to where tey can look for add’l info, involved in particular piece [11:49] anything to help und where to go will help [11:52] Stephen Curran BC - Verified Claims Nathan - have it with anoncreds, very much ledger specific to what we are doing, working on standard w/ W3C, more a JSON format, changes to anoncreds to asjust things, need to suggest things back to W3C (schemas and proofs v claims) - point where it makes sense, supporting W3C ver claims and work with them to move to priv preserving arch Lot like DID/DDO thing Indy supports, do today, do future, adjusting agent code and sdk level [11:56] Tony Rose - blockchain enthusiast, studying space started role with Juvo.com (spelling?) financial inclusion and digital identity using televoms as channel to the consumers doing study on identity help guide them when they think about digital id and credit profile to unbanked, more than collecting data into a database and move them upstream, more than connecting to bank for larger loan, opportunity to give them an identity that has more utility brrings him to INDY at HL Hackfest in January (where first considered) first opp to help develop a product to take advantage of these capabilities looking forward to participating no questions yet spent all week reading SOv whitepapers, techs launched, how do we put together a prototype 6 month engagement, do protos

Sean_Bohan (Thu, 12 Oct 2017 15:59:06 GMT):
Nathan one item - agent WG

Sean_Bohan (Thu, 12 Oct 2017 16:00:11 GMT):
Sovrin foundation started work on token support method to help reduce spam method to create incentives to give issuers data to id owners within ecosystem to be paid for sharing more broadly some refactoring work in Node and Plenum to make sure the config ledgers are in the right places to extend Indy ledger in interesting ways Lovesh and Brent and others putting on agenda for Node in next few weeks to help make it possible

Sean_Bohan (Thu, 12 Oct 2017 16:04:43 GMT):
and that ends the Indy-NODE call for 10/12/17

spivachuk (Thu, 12 Oct 2017 18:48:58 GMT):
Please find today's status of Indy-Node team: - INDY-895: migration for domain ledger with None values: investigating why migration leads to problem with adding new nodes, testing different upgrade and nodes addition scenarios. - INDY-837: finished debugging pipeline for indy-anoncreds managed using JJB and YAML config file. - INDY-831: support for multiple pool networks: fixing the migration and failed tests. - INDY-878: configs reorganization: finished refactoring of plenum client, working on refactoring of plenum CLI. - INDY-670: testing of state proofs. - INDY-231: confirmation testing of the upgrade time fix. - INDY-874: confirmation testing of the fix of user performing migration.

Sean_Bohan (Thu, 12 Oct 2017 21:34:00 GMT):
Links from today's call: https://wiki.hyperledger.org/projects/indy - Indy on the Hyperledger Wiki https://drive.google.com/open?id=0ByaxIFopqmUVR0FFaVVGdTNKcWc - Drummond Reed discussing Verifiable Claims and DIDs https://calendar.google.com/calendar/embed?src=linuxfoundation.org_nf9u64g9k9rvd9f8vp4vur23b0%40group.calendar.google.com&ctz=US/Arizona - Hyperledger Meeting Calendar

brycecurtis (Fri, 13 Oct 2017 17:40:26 GMT):
Has joined the channel.

spivachuk (Fri, 13 Oct 2017 18:04:49 GMT):
Please find today's status of Indy-Node team: - INDY-895: migration for domain ledger with None values: fixed problem with migration from 1.0.28 to 1.1.40, testing different upgrade and nodes addition scenarios. - INDY-904: investigated why new node cannot sync ledger with the pool, found workaround, created ticket INDY-907 for designing solution. - INDY-837: created pipelines for all 3 repositories, testing them. - INDY-869: investigating the issue with spontaneous downgrade after manual upgrade. - INDY-878: configs reorganization: refactoring of plenum / node CLI and client.

hidde-jan (Mon, 16 Oct 2017 09:48:02 GMT):
Has joined the channel.

spivachuk (Mon, 16 Oct 2017 18:36:55 GMT):
Please find today's status of Indy-Node team: - INDY-906: fixed problem with missed init_bls_key script. - INDY-905: fixing the problem with changing BLS key. - INDY-849: fixing the reason why pool cannot reach consensus after view change. - INDY-848: trying to reproduce the issue with primary break after view change. - INDY-831: support for multiple pool networks: fixing the migration and failed tests. - INDY-869: fixing the issue with spontaneous downgrade after manual upgrade. - INDY-878: configs reorganization: started testing of plenum node. - INDY-670: testing of state proofs (upgrade from analog of live pool), updating acceptance test scenarios. - INDY-895: testing upgrade cases, reported bugs: INDY-908, INDY-909. - INDY-874: confirmation testing of the fix of user performing migration. - INDY-837 [BLOCKED]: waiting for answers to the questions about possible options of integration with Hyperledger CI. - INDY-888 [BLOCKED]: feedback is needed (please see the comments to the ticket). - INDY-830 [BLOCKED]: feedback is needed (please see the comments to the ticket).

spivachuk (Tue, 17 Oct 2017 18:02:57 GMT):
Please find today's status of Indy-Node team: - INDY-905: finished fixing the problem with rotation of BLS key. - INDY-883: writing a script for stewards to enable BLS. - INDY-849: issue with inability of pool to reach consensus after view change: fixed some failing tests, smoke testing with local plenum build. - INDY-907: investigated why node cannot send catch-up reply for large ledger, designed solution. - INDY-848: explored logs, found issues with primary selection logic, trying to figure out in plenum how it's possible. - INDY-831: support for multiple pool networks: preparing pull requests, testing. - INDY-869: finished fixing the issue with spontaneous downgrade after manual upgrade, correcting the tests according to the fix. - INDY-878: configs reorganization: continue testing and fixing of plenum node. - INDY-670: testing of state proofs (reading with 1 node, upgrade with analog of live pool). - INDY-895: migration for domain ledger with None values: manual upgrade scenario testing. - INDY-837 [BLOCKED]: waiting for answers to the questions about possible options of integration with Hyperledger CI. - INDY-888 [BLOCKED]: feedback is needed (please see the comments to the ticket). - INDY-830 [BLOCKED]: feedback is needed (please see the comments to the ticket).

spivachuk (Wed, 18 Oct 2017 18:24:30 GMT):
Please find today's status of Indy-Node team: - INDY-883: added script to generate BLS keys and send NODE transaction. - INDY-905: testing BLS key rotation, fixing the problems with BLS key rotation. - INDY-906: testing init_bls_key script. - INDY-907: implementing changes that will let nodes to send large catch-up replies. - INDY-848: primary break after view change: found the cause of the issue, created test, fixing and debugging. - INDY-831: support for multiple pool networks: testing automated deb packages install. - INDY-869: spontaneous downgrade after manual upgrade: finished correcting the tests according to the fix, testing the fix. - INDY-874: investigating an issue with executing a migration script on behalf of sovrin user. - INDY-837 [BLOCKED]: waiting for answers to the questions about possible options of integration with Hyperledger CI. - INDY-888 [BLOCKED]: feedback is needed (please see the comments to the ticket). - INDY-830 [BLOCKED]: feedback is needed (please see the comments to the ticket).

alain2sf (Thu, 19 Oct 2017 06:22:52 GMT):
Has joined the channel.

sklump (Thu, 19 Oct 2017 13:36:09 GMT):
Has left the channel.

spivachuk (Thu, 19 Oct 2017 16:42:08 GMT):
Please find today's status of Indy-Node team: - INDY-905: fixing the problems with rotation of BLS keys. - INDY-907: implemented changes that let nodes to send large catch-up replies. - INDY-849: fixed some tests affected by switching off time check for PrePrepare. - INDY-848: primary break after view change: debugging the test failing on Jenkins but passing on a local machine. - INDY-831: support for multiple pool networks: testing automated deb packages install, fixing review notes, fixing scripts. - INDY-895: migration for domain ledger with None values: fixed issues with processing SCHEMA and CLAIM_DEF transactions. - INDY-382: trying to reproduce the issue with wrong upgrade time in case upgrade is scheduled twice. - INDY-878: configs reorganization: continued refactoring of test fixtures in plenum, testing plenum. - INDY-670: testing of state proofs (live pool upgrade, invalid client response). - INDY-869: confirmation testing of pool upgrade fixes. - INDY-837 [BLOCKED]: waiting for answers to the questions about possible options of integration with Hyperledger CI. - INDY-888 [BLOCKED]: feedback is needed (please see the comments to the ticket). - INDY-830 [BLOCKED]: feedback is needed (please see the comments to the ticket).

spivachuk (Fri, 20 Oct 2017 19:32:47 GMT):
Please find today's status of Indy-Node team: - INDY-670: testing of live pool analog upgrade to the version with state proofs, fixing the problem with initializing of BLS keys. - INDY-849: fixing switching off time check for PrePrepare. - INDY-848: primary break after view change: investigated and fixed one more test failed intermittently, improved logging in plenum code. - INDY-831: support for multiple pool networks: testing automated deb packages install, fixing review notes, fixing scripts. - INDY-382: issue with wrong upgrade time in case pool upgrade is scheduled twice: cannot reproduce the issue on the recent version in master, faced that node upgrade is scheduled twice in case pool upgrade is made in force mode, fixed this. - INDY-701: issue with inability to schedule new pool upgrade to earlier time if there is already scheduled one: cannot reproduce the issue on the recent version in master. - INDY-878: configs reorganization: refactoring of test fixtures in plenum, testing plenum. - INDY-231: issue with wrong upgrade time: preparing pool and scheduling for upgrade during the weekend. - INDY-157: confirmation testing of upgrade log parsing fix (INDY-917 is reported). - INDY-907: confirmation testing of catch-up mechanism fix for large ledgers. - Acceptance testing of indy-node 1.1.43 (running GST and scenario 14 in docker pool). - INDY-837 [BLOCKED]: waiting for answers to the questions about possible options of integration with Hyperledger CI. - INDY-888 [BLOCKED]: feedback is needed (please see the comments to the ticket). - INDY-830 [BLOCKED]: feedback is needed (please see the comments to the ticket). - INDY-874 [BLOCKED]: feedback is needed (please see the comments to the ticket).

spivachuk (Mon, 23 Oct 2017 17:00:53 GMT):
Please find today's status of Indy-Node team: - INDY-905: added more tests related to NODE transaction, debugged the issue with state proof, testing BLS key changes with different roles. - INDY-849: fixing switching off time check for PrePrepare. - INDY-831: support for multiple pool networks: fixing scripts, preparing the pull request. - INDY-382: wrote tests for pool upgrade in force mode and for pool upgrade schedule. - INDY-878: configs reorganization: refactoring and fixing plenum tests. - INDY-670: state proofs: testing upgrade and initialization of BLS keys, testing BLS key change fixes. - INDY-907: testing large ledger catch-up fixes. - INDY-888 [BLOCKED]: feedback is needed (please see the comments to the ticket). - INDY-830 [BLOCKED]: feedback is needed (please see the comments to the ticket). - INDY-874 [BLOCKED]: feedback is needed (please see the comments to the ticket).

nbrempel (Mon, 23 Oct 2017 22:46:33 GMT):
Has joined the channel.

codenamedmitri (Tue, 24 Oct 2017 18:02:20 GMT):
Has joined the channel.

ChristianSmith (Tue, 24 Oct 2017 18:05:58 GMT):
Has joined the channel.

spivachuk (Tue, 24 Oct 2017 18:43:04 GMT):
Please find today's status of Indy-Node team: - INDY-883: enhanced enable_bls to meet new requirements. - INDY-915: fixed problem with init_bls_keys script, fixing minor problems with BLS. - INDY-849: fixing tests for switching off time check for PrePrepare. - INDY-837: made a fix related to agents labels initialization routine in CI pipeline scripts in Indy repositories, tested notifications of PRs created by unknown collaborator, tested builds triggers. - INDY-831: support for multiple pool networks: fixing scripts, preparing the pull request. - INDY-852: implementing additional validation logic for non-string fields. - INDY-917: fixed the issue with re-scheduling of a canceled upgrade in case a node is restarted. - INDY-878: configs reorganization: refactoring and fixing plenum tests. - INDY-670: state proofs: testing upgrade, initialization of BLS keys, changing of BLS keys (reported INDY-921 and INDY-922). - INDY-874 [BLOCKED]: feedback is needed (please see the comments to the ticket).

spivachuk (Wed, 25 Oct 2017 17:58:18 GMT):
Please find today's status of Indy-Node team: - INDY-915: made minor fixes regarding BLS, confirmation testing of BLS-related fixes in CLI. - INDY-754: improving documentation on GitHub. - INDY-849: fixing tests for switching off time check for PrePrepare. - INDY-907: fixing duplicates in catch-up. - INDY-837: finished testing triggering builds by comments to PRs, updated CI jobs for Indy repositories, testing a job on Hyperledger Jenkins sandbox server. - INDY-852: fixed an issue with incorrect transaction fields constraints. - INDY-893: issue with duplicating POOL_UPGRADE transactions: reviewing logs, preparing test environment. - INDY-917: added a test verifying that canceled upgrade is not rescheduled after node restart, confirmation testing of upgrade_log fixes. - INDY-925: implementing application data migration for rebranding upgrade of client. - INDY-878: configs reorganization: merged with the changes related to support for multiple pool networks, continue refactoring and fixing plenum tests. - INDY-670: testing of state proofs: verification of adding nodes to the pool and work with invalid signatures on client side, refinement and actualization of State Proofs test plan. - INDY-848: confirmation testing of view change fixes. - INDY-874 [BLOCKED]: feedback is needed (please see the comments to the ticket).

nage (Thu, 26 Oct 2017 15:02:00 GMT):
The Node WG call is starting now at https://zoom.us/j/232861185

ashcherbakov (Thu, 26 Oct 2017 15:04:06 GMT):
https://docs.google.com/spreadsheets/d/1T-9wcD4tcA8iaHkRWpCbO_5yx00PSMcQBrc7NbkaryI/edit#gid=0

nage (Thu, 26 Oct 2017 15:05:33 GMT):
@ashcherbakov is giving an update on the end of the current sprint and the start of the next one

nage (Thu, 26 Oct 2017 15:05:58 GMT):
The next sprint is devoted to merging in state proofs and part of the incubation tasks around file/folder refactoring and rebranding to Indy

nage (Thu, 26 Oct 2017 15:06:18 GMT):
... we should have a new stable release with these things and some bug fixes for upgrade and some code improvements for CI/CD and so on

nage (Thu, 26 Oct 2017 15:06:39 GMT):
... This is the status for the first part of the Indy Node part of the sprint, for the SDK part of the sprint

nage (Thu, 26 Oct 2017 15:06:56 GMT):
... the main tasks for the past sprint were to design and create a new Agent-to-Agent API based on libsodium

nage (Thu, 26 Oct 2017 15:07:10 GMT):
[ the transport agnostic encryption tools we talked about some at IIW [

nage (Thu, 26 Oct 2017 15:07:10 GMT):
[ the transport agnostic encryption tools we talked about some at IIW ]

nage (Thu, 26 Oct 2017 15:07:50 GMT):
... the main point of communication was related to DID, but now we have a generic key management approach for agent to agent and signing and verification with just keys that don't necessarily have DIDs (unanchored keys)

nage (Thu, 26 Oct 2017 15:08:52 GMT):
... this gives us peer to peer or point to point communication when you have keys for each part

codenamedmitri (Thu, 26 Oct 2017 15:09:17 GMT):
question - are you using any sort of tweaks or changes to the DID spec, in Indy?

nage (Thu, 26 Oct 2017 15:09:24 GMT):
... you can prepare a message to be sent using libsodium sealed-boxes and authentication encryption

nage (Thu, 26 Oct 2017 15:09:41 GMT):
ack @codenamedmitri's question

nage (Thu, 26 Oct 2017 15:09:58 GMT):
... the security is done on the prepare message level

nage (Thu, 26 Oct 2017 15:10:18 GMT):
... then you can send the message over any transport

nage (Thu, 26 Oct 2017 15:10:46 GMT):
... there is a link to a demo describing these changes. They are not yet in stable, finishing this new api and getting it merged should happen early in this next sprint

nage (Thu, 26 Oct 2017 15:11:02 GMT):
... along with the state proof and multisignature support

nage (Thu, 26 Oct 2017 15:11:14 GMT):
[ see the spreadsheet link shared earlier for details ]

nage (Thu, 26 Oct 2017 15:11:42 GMT):
... there is also an update in the wallet implementation to use SQLCypher by default

nage (Thu, 26 Oct 2017 15:11:49 GMT):
... that should be merged in this next sprint

nage (Thu, 26 Oct 2017 15:11:53 GMT):
( for the SDK code )

nage (Thu, 26 Oct 2017 15:12:21 GMT):
... the agent to agent API based on ZeroMQ will be deprecated in favor of the libsodium boxing api described

nage (Thu, 26 Oct 2017 15:13:12 GMT):
[ because the pairwise-curveZMQ version of ZeroMQ we were using didn't allow agents to talk to agents using the owners keys without authenticating an agent's authorization to talk on behalf of the identity owner ]

nage (Thu, 26 Oct 2017 15:13:28 GMT):
@Sean_Bohan can we take a look at the demo?

nage (Thu, 26 Oct 2017 15:13:45 GMT):
@ashcherbakov if others want to see it that should be fine

nage (Thu, 26 Oct 2017 15:14:04 GMT):
[ Sean is attempting to bring the demo up now ]

ashcherbakov (Thu, 26 Oct 2017 15:14:30 GMT):
https://docs.google.com/spreadsheets/d/1T-9wcD4tcA8iaHkRWpCbO_5yx00PSMcQBrc7NbkaryI/edit?usp=sharing

nage (Thu, 26 Oct 2017 15:15:33 GMT):
_notes that we aren't hearing the audio_

ashcherbakov (Thu, 26 Oct 2017 15:18:31 GMT):
demo: https://drive.google.com/file/d/0B-bXTGH2ThrAcXFzZTRWMmdkZUk/view

nage (Thu, 26 Oct 2017 15:18:41 GMT):
Question on DID support: @ashcherbakov that is coming in a future sprint [ see JIRA ]

nage (Thu, 26 Oct 2017 15:19:04 GMT):
@nage we support this now through the NYM transaction(s) and ATTRIBs, but we want to move to supporting the full standard

nage (Thu, 26 Oct 2017 15:19:36 GMT):
@Sean_Bohan many of the community were at the Internet Identity Workshop, it was good to talk to everyone there, does anyone in attendance want to give a report?

nage (Thu, 26 Oct 2017 15:20:12 GMT):
@darrell.odonnell A big take away for me was the biggest part of a self-sovereign solution was governance, and that really sets Indy and Sovrin apart

nage (Thu, 26 Oct 2017 15:20:42 GMT):
... I'm pleased that the framework is so solid. Additionally @swcurran and @jljordan_bcgov 's demo was awesome!

nage (Thu, 26 Oct 2017 15:21:23 GMT):
@jljordan_bcgov It was good to be there and meet everyone. We learned a lot and got good feedback on our model. As for the tech, there is some DID/DDO Verifiable Claims stuff is very interesting to us and we're looking for that to achieve consensus.

nage (Thu, 26 Oct 2017 15:21:39 GMT):
... seeing the activities in the DIF was interesting and we're really hopeful for interoperable implementations

nage (Thu, 26 Oct 2017 15:22:09 GMT):
... we really want to improve the simplicity of adopting Indy, so seeing the CLI and SDK come into alignment and become easier to on-board will be important.

nage (Thu, 26 Oct 2017 15:22:23 GMT):
... there are confusing discussions to be had about what you have to do in the CLI vs the SDK

nage (Thu, 26 Oct 2017 15:22:34 GMT):
... we want that ramp-up to get easier and easier

nage (Thu, 26 Oct 2017 15:22:43 GMT):
[ also @swcurran talking ]

nage (Thu, 26 Oct 2017 15:23:00 GMT):
... looking to have agent to agent code up and running soon, which we will share

nage (Thu, 26 Oct 2017 15:23:08 GMT):
@Sean_Bohan we'd love to have you guys demo in these calls

nage (Thu, 26 Oct 2017 15:27:08 GMT):
@nage talked about the OAuth/OpenIDConnect/SSI session and the bridges to build there, as well as the CL Signature Scheme presentation and the availability of the crypto description document

nage (Thu, 26 Oct 2017 15:29:45 GMT):
@Sean_Bohan there were some good introduction sessions on Sovrin, Indy and Hyperledger projects in general

nage (Thu, 26 Oct 2017 15:30:43 GMT):
@tkuhrt I lead a general Hyperledger introduction where we talked about all the projects at HL and their strengths (we had a good group in attendance)

nage (Thu, 26 Oct 2017 15:31:03 GMT):
@Sean_Bohan we had a shortened Identity WG last week where we talked about GDPR

nage (Thu, 26 Oct 2017 15:31:21 GMT):
... jira.hyperledger.org has all the cardwall and ticket-level roadmap plan

nage (Thu, 26 Oct 2017 15:31:51 GMT):
... we've been working on our roadmap (as slides and descriptions) to try to talk about what we're planning on doing and how we can accelerate the things people need

Sean_Bohan (Thu, 26 Oct 2017 15:53:59 GMT):
Lot of thing that have to happen to make things easier to use Finding most stuck on Agent-Agent comms Rethinking it Always thought of useing TLS TLS 1.2 and earlier dont do diffie-helman earlier enough Revelase relationship between one reltationhip and another TLS3 does Pairwise curvezmq has a real hard time doing agent auth Dont want to auth keys to agents themselves, but to identities, make sure agent is auth to act for identity in question Uphill battle with CurveZMQ Backed off and instead building API based off of auth encryption inside of LibSodium Using boxing and unboxing APIs makes sense Dont have to change threading model that works (node.js, PHP, Py, Java) - do what native platform wants and get secure piont to point When we do move to DID TLS Terms of maturity of the ecosystem - bumpy ride, best option moving forward Questions: Dmirti - experience in semantic web world Used classic TLS certs to ID DIDs b/c faced with same problem, needed to ID Agents to do same thing, “auth on behalf of” terminology Introducing slight edit to DID spec - not only auth DID holder, but also other agents on behalf of that holder Nathan - had that discussion Same curran has a goog doc with DID TLS spec Tradeoffs - how to articulate agent If you have to tell the ledger who the agent is, you could correlate mult keys Idea - generic delegation, vs agent delegation Any did looks the same as any agent USE CASE - hospital and bank want to give ID on a sys like Sov Bank = finance APIs, hospita - medical APIS Tie them together Might simply delegate different endpoints to different places Might need endpoiint that stitches together APIs Might say “doctors office, you can be in charge of keys for med API, dont need to be Self-Sov in that case, sign right auths for agent to respond on my behalf Not the business of who you are talking to Like to look at WebID examples Dmitri mentioned Fairly common pattern for any sys using mutual authentication Onramps or shortcuts? Pick up and use to make DID TLS happen faster DMIRTI - No extensions to TLS itself Load semantic web equiv of DIDs Look for claims Nathan Discussed Indy SDK Crypto code in Indy SDK drops down to Shared Crytpo lib Break apart file system from SDK from pieses that do data format and protocol piece Run protocol mech via something like Intel SGX Differential privacy if claims and proofs from Sov could be done w/in that kind of environment When you try to trust someone elses TPM, trust assurances can be spooked or faked, only trust own, lot of blinding steps alrady in anoncreds protocol Pointed to parts of spec that have usable bits of crypto

swcurran (Thu, 26 Oct 2017 15:54:00 GMT):
BC Gov Trello Board - what we are doing: https://trello.com/b/fHox971V/von

Sean_Bohan (Thu, 26 Oct 2017 15:54:03 GMT):
How that helps over time Roadmap - agent WG call Alot of features pretty far out - focused on making onramp and developer impedence issues are improved Few pieces of toolset where new devs getting hung up, technical things we can do to make it easier Prirotizing dev onboarding that dev new features Welcoem to add yourselves into the sprint! Pull into team standups and people working on overlapping bits of code Use asynch comms as we can Resources available Talked a lot about things worked on in var standards orgs Need ot make more clear - lot of things inside of DIF and other ID platforms that we want to see standardized, beyond Sov and Ind we dont know what the right approach is yet Indy - approach for privacy, trust, ver claims Bite sized standards - ZKPs, selective disclosure, pairwise IDs, DID Specs, Agent APIs (extensible), Identity hub for discovering agents Some pieces we arent sure about: linked data, schema info in ledger vs. higher level, REST resources based approaches of ID hubs, some might disagree w/ As an ecosystem we want people trying those things if they believe in them If somoene wants to try out, see how it works, happy to merge if experiments work out When you look at specs, not every codebase will support everything in spec Cpmpatibility problems, new ecosystem, try things, ok if we dont all support entirely, but we need to see if things work Lessons - adopt standards, pls dont go dark, talk about, “hey i want to do restful ID hubs on Sov” - you can talk to people here DMITRI DID Auth? Mentioned a couple of times Is there any sort of doc, or spec or is it implicit “read the code” NATHAN Started on a couple of times Dont believe there is a coherent doc Closest thing in terms of TLS is Sam Currans DID TLS UML diagrams, swimlane pics of how the LibSodium approach works (Farouk - worked a lot making it clear and documenting parts of use case for claims and proofs Share with community next week CHRISTIANS Experience w/ OpenID Connect and OAuth OpenID Connect and libraries and dealt with extremem edge cases in that world How to go abotu getting VerClaims from Sovrin integrated w/ federation Seems like possibly a path that might drive certain kinds of dev adoption or interest Floorboard engineers in big corps to find ways to justify using small pieces of Sov Onboarding path - tooling NATHAN Christian and Dmitri talked a little at IIW Khagesh Sharma - worked on integrating OAuth and OpenID COnnect RWoT Archives (RWoT 4) - what web auth spec might look like Most folks working on infrastructure level stuff before we came that far D & C could probably make a lot of process quickly Open up to the floor

Sean_Bohan (Thu, 26 Oct 2017 15:54:14 GMT):
NOTE - BC Gov Trello Board - what we are doing: https://trello.com/b/fHox971V/von

Sean_Bohan (Thu, 26 Oct 2017 15:54:19 GMT):
StephanC -

nage (Thu, 26 Oct 2017 15:54:29 GMT):
https://docs.google.com/document/d/1-aPY1eeHdR_TnF7_WpEs58RZ_jNdDeptVrNEu3groFc

Sean_Bohan (Thu, 26 Oct 2017 15:55:58 GMT):
use GitHub to post user stories and post dollar value "help us w/ this user story" vendors can manage agile teams and so forth interesting to use OAuth capability of GitHub to bring GitHub ID into Sov as a mechanism way of understanding their contributions Nathan Keybased doing proof of control Notary can issue a ver claim that you can prove you use a particular account or service Super interesting DMITRI interesting mechanism we could take inspiration from

Sean_Bohan (Thu, 26 Oct 2017 15:56:20 GMT):
Registration link for Lisbon Hackfest: https://www.regonline.com/hyperledgerhackfestdecember2017

Sean_Bohan (Thu, 26 Oct 2017 15:56:32 GMT):
DID TLS Spec - https://docs.google.com/document/d/1-aPY1eeHdR_TnF7_WpEs58RZ_jNdDeptVrNEu3groFc

Sean_Bohan (Thu, 26 Oct 2017 15:56:56 GMT):
Status spreadsheet AND demo links (demos are MP4s): https://docs.google.com/spreadsheets/d/1T-9wcD4tcA8iaHkRWpCbO_5yx00PSMcQBrc7NbkaryI/edit?usp=sharing

Sean_Bohan (Thu, 26 Oct 2017 15:57:20 GMT):
Sam Curran is on a super early timezone but responsive on rocketchat and email

nage (Thu, 26 Oct 2017 15:58:10 GMT):
@TelegramSam ^^ we shared the DID TLS spec in the call and @codenamedmitri has some great ideas on how we can move that forward

jljordan_bcgov (Thu, 26 Oct 2017 15:58:14 GMT):
Link to BC DevExchange -> https://bcdevexchange.org

Sean_Bohan (Thu, 26 Oct 2017 15:58:28 GMT):
Linux Foundation Antitrust Policy - https://www.linuxfoundation.org/antitrust-policy/

jljordan_bcgov (Thu, 26 Oct 2017 15:59:38 GMT):
Have a good day/evening all :)

Sean_Bohan (Thu, 26 Oct 2017 16:00:17 GMT):
thanks everyone!

bhurley (Thu, 26 Oct 2017 16:01:59 GMT):
Sorry for my muted status but I had visitors in my office towards the end of the call. Just so I am not a complete lurker I'll introduce myself now. I work for the Government of Canada here in ottawa, and I'm working with @jljordan_bcgov @swcurran etc on The OrgBook/Verifiable Organization Network

nage (Thu, 26 Oct 2017 16:03:27 GMT):
_apologizes for missing the introductions part of the call (you deserved to hear more from @codenamedmitri, @ChristianSmith and the other awesome folks who came to the call)_

nbrempel (Thu, 26 Oct 2017 16:04:22 GMT):
I'll jump in and say hi as well. I'm working with @jljordan_bcgov and @swcurran in BC on the VON project. My name's Nick

nage (Thu, 26 Oct 2017 16:04:34 GMT):
Welcome Nick!

nbrempel (Thu, 26 Oct 2017 16:04:54 GMT):
Thanks :)

Captain63Dragon (Thu, 26 Oct 2017 17:28:08 GMT):
Is there a voice recording of the meeting yet? If so is there a link?

spivachuk (Thu, 26 Oct 2017 19:01:41 GMT):
Please find today's status of Indy-Node team: - INDY-907: fixing duplicates in catch-up. - INDY-927: made client to send read-only requests to one node. - INDY-837: discussed current issues related to running CI jobs with administrators, fixed some of these issues, waiting for the response related to the other issues. - INDY-882: merged to master branch the refactored logic of publishing deb packages to APT repository needed to support separate APT repository for Indy SDK team, verified its operability. - INDY-831: support for multiple pool networks: fixing failed tests on Jenkins. - INDY-541: issue with repeated log messages about suspicious spike: reviewing logs and code, reproducing the issue. - INDY-925: implementing application data migration for rebranding upgrade of client. - INDY-878: configs reorganization: refactoring and fixing plenum tests. - INDY-382: tested pool upgrade fixes. - INDY-849: testing pre-prepares fixes. - INDY-852: testing fixes in transaction fields constraints. - INDY-874 [BLOCKED]: feedback is needed (please see the comments to the ticket).

spivachuk (Fri, 27 Oct 2017 18:43:26 GMT):
Please find today's status of Indy-Node team: - INDY-754: improving Indy Node documentation on GitHub. - INDY-927: made client resend request to all nodes if cannot confirm proof. - INDY-909: falling out of consensus after upgrade: found the issue with view change by newly added node after specific number of view change events, started to fix. - INDY-837: discussing questions related to running CI jobs with administrators. - INDY-541: issue with repeated log messages about suspicious spike: made the check optional and added threshold value. - INDY-925: finished base implementation of application data migration for rebranding upgrade of client, ensuring fault tolerance in the implemented migration. - INDY-878: configs reorganization: started modifying client to get it worked with new config structure. - INDY-831, INDY-832, INDY-833: support for multiple pool networks: merged all the changes to master branches, preparing test plan. - INDY-231, INDY-701: testing upgrade time fixes. - INDY-907: testing large ledger catch-ups. - INDY-511: regression testing of basic node functionality. - INDY-874 [BLOCKED]: feedback is needed (please see the comments to the ticket).

Captain63Dragon (Fri, 27 Oct 2017 20:32:07 GMT):
From above, it sounds like Thursday's meeting was productive. Asking again, is there a recording of this meeting up somewhere? I'd like to review it.

Sean_Bohan (Sun, 29 Oct 2017 20:28:18 GMT):
@Captain63Dragon we record them - let me find out where we have been storing them and I will share here (Friday was incredibly busy and we are getting our overall community flow in order so we still have hiccups like this)

schristie (Mon, 30 Oct 2017 18:16:57 GMT):
Has joined the channel.

spivachuk (Mon, 30 Oct 2017 19:01:46 GMT):
Please find today's status of Indy-Node team: - INDY-928: supported state timestamp (time when BLS multi-signature was created) in state proofs. - INDY-754: updating public documentation on GitHub. - INDY-932: continuous running of instance change: investigating and fixing the issue. - INDY-909: falling out of consensus after upgrade: working on the test and fix. - INDY-925: finished ensuring fault tolerance in the implemented migration, merging with the changes related to support for multiple pool networks. - INDY-878: configs reorganization: modifying plenum client, test Pool class, NodeSet class. - INDY-831, INDY-832, INDY-833: support for multiple pool networks: supported the changes in Docker env of sovrin-environments, preparing test plan. - INDY-231, INDY-701: testing upgrade time fixes. - INDY-907: testing large ledger catch-ups. - INDY-882: testing indy-crypto support in CI/CD. - INDY-874 [BLOCKED]: feedback is needed (please see the comments to the ticket).

spivachuk (Tue, 31 Oct 2017 18:53:32 GMT):
Please find today's status of Indy-Node team: - INDY-754: updating public documentation on GitHub. - INDY-932: continuous running of instance change: investigating and fixing the issue. - INDY-909: learnt view change related algorithms in plenum code, separating processing of view change initiated by handling current-state messages from processing of currently running view change. - INDY-831, INDY-832, INDY-833: support for multiple pool networks: debugging deployment of Vagrant environment, testing the file/folder structure changes. - INDY-925: client migration for multiple pool networks support: reviewed the new app data layout, implementing the migration. - INDY-878: configs reorganization: cleaning up testing fixtures related to test pool and node set. - Libindy acceptance testing: environment setup, running wrappers acceptance tests. - INDY-874 [BLOCKED]: feedback is needed (please see the comments to the ticket).

hidde-jan (Wed, 01 Nov 2017 09:53:46 GMT):
Hi all, is there some documentation on the kind of network traffic (validator) nodes generate?

spivachuk (Wed, 01 Nov 2017 18:09:01 GMT):
Please find today's status of Indy-Node team: - INDY-754: finished updating public documentation on GitHub. - INDY-941: investigating the issue with catch-up for agents. - INDY-932: continuous running of instance change: made a partial fix. - INDY-909: implemented integration tests, started to work on a fix based on primary selection using only a part of the pool ledger. - INDY-831, INDY-832, INDY-833: support for multiple pool networks: debugging deployment of Vagrant environment, testing upgrade to the new indy-node version. - INDY-925: implementing client migration for indy-node version that supports multiple pool networks. - INDY-878: configs reorganization: fixed several client tests, cleaning up fixtures and their dependencies. - Libindy acceptance testing: set up Windows environment, running wrappers acceptance tests. - INDY-837 [BLOCKED]: waiting for answers to the questions from Andrey Kononykhin.

Sean_Bohan (Thu, 02 Nov 2017 17:19:45 GMT):
Indy NODE friends: For next weeks call (THURSDAY) we will be discussing/going over A. Steve Tolman will be sharing the changes to JIRA workflow B. Roadmap Discussion ( see here, already shared on Agent call): https://drive.google.com/open?id=0ByaxIFopqmUVRkhyRWZ1X0RpQ1U ) C. Special Guest talking about what they are working on

spivachuk (Thu, 02 Nov 2017 18:58:05 GMT):
Please find today's status of Indy-Node team: - INDY-754: made changes in plenum documentation. - INDY-941: issue with catch-up for agents: applying hotfix to code. - INDY-932: found the reason why validator runs instance change continually, working on the fix. - INDY-909: falling out of consensus after upgrade: fixing the issue, testing. - INDY-831, INDY-832, INDY-833: support for multiple pool networks: debugging deployment of test environment and migration; testing file/folder structure changes, node network features, upgrade to the new indy-node version, read_ledger tool. - INDY-925: finished base implementation of client migration for indy-node version that supports multiple pool networks. - INDY-878: configs reorganization: fixed client tests, BLS tests, checkpoints tests, fixtures related to stewards and wallets.

spivachuk (Fri, 03 Nov 2017 20:54:05 GMT):
Please find today's status of Indy-Node team: - INDY-941: issue with catch-up for agents: applying the hotfix, improving the code. - INDY-932: continuous running of instance change: completed the fix. - INDY-801: making logs of upgrade more verbose. - INDY-909: falling out of consensus after upgrade: implemented a fix, testing and debugging it. - INDY-831, INDY-832, INDY-833: support for multiple pool networks: debugging deployment of test environment and migration; testing file / folder structure changes, new networks setup, initializing and adding nodes. - INDY-925: completed implementation of client migration for indy-node with multiple pool networks support, testing and debugging the combined client migration. - INDY-878: configs reorganization: working on pool transactions tests.

CabMorris14 (Sun, 05 Nov 2017 21:13:43 GMT):
Has joined the channel.

anikitinDSR (Wed, 08 Nov 2017 09:04:27 GMT):
Has joined the channel.

Sean_Bohan (Thu, 09 Nov 2017 13:02:27 GMT):
Indy Ledger Friends: Hyperledger Indy Ledger (Node) WG Call TODAY 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 Today's Agenda: Housekeeping (Sean) Development Status (Alex) Changes to Jira / workflow (Steve Tolman)

ashcherbakov (Thu, 09 Nov 2017 16:15:01 GMT):
https://docs.google.com/spreadsheets/d/1-8mv5dokDPd5Laqur7EZtrgxmln0sY5CiJuSsL1Rg9Q/edit#gid=0

jljordan_bcgov (Thu, 09 Nov 2017 16:44:35 GMT):
Here is our "DeathOnion" architecture https://www.draw.io/?state=%7B%22ids%22:%5B%220B4DUXk_qFFhvcDVRc1FvaE1zbzg%22%5D,%22action%22:%22open%22,%22userId%22:%22114604029728267909488%22%7D#G0B4DUXk_qFFhvcDVRc1FvaE1zbzg

jljordan_bcgov (Thu, 09 Nov 2017 16:45:14 GMT):

Decentralized ID Onion - VON Architecture v1.png

jljordan_bcgov (Thu, 09 Nov 2017 16:46:08 GMT):

Decentralized ID Onion - VON Architecture v1-2.png

jljordan_bcgov (Thu, 09 Nov 2017 16:46:39 GMT):
This is rough idea of an architecture for a verifiable claims type implementation(s)

ashcherbakov (Thu, 09 Nov 2017 16:50:26 GMT):
https://github.com/hyperledger/indy-node/blob/master/scripts/validator-info

ashcherbakov (Thu, 09 Nov 2017 16:50:47 GMT):
@swcurran ^

jljordan_bcgov (Thu, 09 Nov 2017 16:51:20 GMT):
Have a great day. Thanks for call.

Sean_Bohan (Thu, 09 Nov 2017 21:35:35 GMT):
Thanks for joining the Hyperledger Indy WG Call for November 9, 2017! Due to a mistake on my part, today's WG was not recorded. Below please find links to the Agenda for the call, Achievements doc Alex and Slava shared and the draft Indy roadmaps for Ledger and SDK/Crypto. Note - next week we will start including previous Achievements in the same doc (history) Indy WG 11-09-17 WG Call Agenda - https://drive.google.com/open?id=1H0eaqMnfYJj2jDERlFJsUYsDFXRF8J-mtQudINFbTSc Dev Status / Achievements Spreadsheet (with demo video links) - https://docs.google.com/spreadsheets/d/1-8mv5dokDPd5Laqur7EZtrgxmln0sY5CiJuSsL1Rg9Q/edit#gid=0 DRAFT Indy Roadmap - https://drive.google.com/open?id=0ByaxIFopqmUVRkhyRWZ1X0RpQ1U As Steve Tolman shared on the call, we have adjusted the Jira and development process to hopefully be more functional for the community. Please join us next week, Thurs Nov 16 for our next call. Feel free to add your ideas for the agenda in RocketChat. THANKS! - Hyperledger Indy Community

ianco (Thu, 09 Nov 2017 21:47:41 GMT):
Has joined the channel.

mountbranch (Wed, 15 Nov 2017 17:20:50 GMT):
Has joined the channel.

theruss (Thu, 16 Nov 2017 20:24:15 GMT):
Has joined the channel.

saadmir (Mon, 20 Nov 2017 03:00:30 GMT):
Has joined the channel.

isahilsharma (Mon, 20 Nov 2017 09:29:03 GMT):
Has joined the channel.

prmdmshra (Wed, 22 Nov 2017 05:41:12 GMT):
Has joined the channel.

prmdmshra (Wed, 22 Nov 2017 05:44:16 GMT):
Hi All, I am receiving the following error on running 'pip install indy-node-dev' command in Ubuntu 16.04. Please suggest Command "/home/pwc/py3env/bin/python3 -u -c "import setuptools, tokenize;__file__='/tmp/pip-build-x_zrglo_/sha3/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" install --record /tmp/pip-3hg2mcho-record/install-record.txt --single-version-externally-managed --compile --install-headers /home/pwc/py3env/include/site/python3.5/sha3" failed with error code 1 in /tmp/pip-build-x_zrglo_/sha3/ Failed building wheel for Charm-Crypto Failed building wheel for orderedset Failed building wheel for leveldb Failed building wheel for psutil Failed building wheel for sha3

ashcherbakov (Wed, 22 Nov 2017 12:32:41 GMT):
Hi @prmdmshra. What OS do you use? As of now, it's guaranteed to work on Ubuntu only. Look like you need to install Charm-Crypto (have a look at https://github.com/hyperledger/indy-anoncreds/blob/master/setup-charm.sh) Also for what purpose are you installing indy-node? Installatiomn from pip is not a recommeneded way. Please have a look at the documentation (https://github.com/hyperledger/indy-node/blob/master/README.md) - if you want to contribute to the code and configure development environment, then please have a look at https://github.com/hyperledger/indy-node/blob/master/docs/setup-dev.md - If you want a ready-to-use pool, then please have a look at `How to Install a Test Network` section in README

prmdmshra (Wed, 22 Nov 2017 13:59:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=SgubtTh7turErysd4) @ashcherbakov I am trying to setup the Indy network to demostrate a PoC for Birth certificate registration.

ashcherbakov (Wed, 22 Nov 2017 14:01:28 GMT):
ok, then you probably need to have a look to indy-sdk (the client part containing also anonymous credentials logic). I think it should be sufficient to install a pool from Docker (see docs in indy-sdk or links above)

prmdmshra (Wed, 22 Nov 2017 14:03:55 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=wzRNHgvnEmyjp9rAz) @ashcherbakov I have started installing Indy-sdk. Thanks a lot :-)

nbrempel (Wed, 22 Nov 2017 19:38:15 GMT):
Are there any utilities that exist to explore the state of the ledger?

nbrempel (Wed, 22 Nov 2017 19:38:24 GMT):
I think that would be helpful during development

mgbailey (Wed, 22 Nov 2017 21:57:48 GMT):
@nbrempel on a validator node you can run "sudo -i -u sovrin validator-info -v" for an overview that includes the sizes of the 3 ledgers in Indy. (2 ledgers are metadata.

mgbailey (Wed, 22 Nov 2017 21:58:05 GMT):
the one you want to see is "domain")

mgbailey (Wed, 22 Nov 2017 21:58:46 GMT):
To inspect the actual contents, on the validator run "sudo read_ledger --type domain"

nbrempel (Wed, 22 Nov 2017 22:14:34 GMT):
thanks

ashcherbakov (Thu, 23 Nov 2017 16:04:22 GMT):
https://docs.google.com/spreadsheets/d/1-8mv5dokDPd5Laqur7EZtrgxmln0sY5CiJuSsL1Rg9Q/edit#gid=526493707

pawan176 (Sun, 26 Nov 2017 08:40:25 GMT):
Has joined the channel.

pawan176 (Sun, 26 Nov 2017 10:33:52 GMT):
Hi..I am trying to understand the code. I started with the simple_node.py file in examples. However, it makes a call to the addGenesisTxns and startKeySharing methods of the Node class which are not present in the code

pawan176 (Sun, 26 Nov 2017 10:33:57 GMT):
Is this an issue?

lovesh (Tue, 28 Nov 2017 10:05:15 GMT):
@pawan176 The code under `examples` is obsolete (our fault), have a look at the tests under `tests`

pawan176 (Tue, 28 Nov 2017 16:58:13 GMT):
okay cool..will try it out!

jww (Wed, 29 Nov 2017 15:53:46 GMT):
Has joined the channel.

wittrock (Wed, 29 Nov 2017 18:55:19 GMT):
Has joined the channel.

wittrock (Wed, 29 Nov 2017 19:03:43 GMT):
Hi all, is this the place to ask basic questions about the Alice demo?

wittrock (Wed, 29 Nov 2017 19:05:29 GMT):
If so, I've got a weird situation in which I'm supposedly connected to the sandbox network but not actually: ```ALICE@sandbox> accept request from "Faber College" Request not yet verified. Connection not yet synchronized. Request acceptance aborted. Cannot sync because not connected. Please connect first. ALICE@sandbox> connect sandbox Already connected to sandbox Usage: connect ```

wittrock (Wed, 29 Nov 2017 19:05:55 GMT):
So the `connect` command tells me I'm already connected but other commands tell me that I haven't.

nbrempel (Wed, 29 Nov 2017 19:06:47 GMT):
I think there is a command called `status`, try that

wittrock (Wed, 29 Nov 2017 19:09:53 GMT):
```ALICE@sandbox> status Attempting connection to sandbox Indy network```

wittrock (Wed, 29 Nov 2017 19:10:08 GMT):
Not _quite_ sure what that means.

nbrempel (Wed, 29 Nov 2017 20:00:11 GMT):
I've seen that before, the cli isn't super clear. Basically that means that it attempted to connect, but did not connect successfully

nbrempel (Wed, 29 Nov 2017 20:00:37 GMT):
So the CLI cannot find the nodes on whatever IP you're pointing it at

wittrock (Wed, 29 Nov 2017 20:30:15 GMT):
aha, thank you! I'll double check open ports, etc.

nbrempel (Wed, 29 Nov 2017 20:40:17 GMT):
👍🏻

mgbailey (Wed, 29 Nov 2017 22:25:59 GMT):
@wittrock after you do "connect sandbox" you should you will see many lines displayed showing that the client is communicating with the nodes of your test network. You should also see the following highlighted line: *Connected to test.*

wittrock (Wed, 29 Nov 2017 22:35:45 GMT):
@mgbailey thanks! the problem was something related to my attempted docker setup, I got the connection working. Currently struggling with a similar CLI question around what I think is a failure to sync: ```ALICE@sandbox> sync faber Expanding faber to "Faber College" Synchronizing... Try Next: show connection "Faber College" accept request from "Faber College" ALICE@sandbox> accept request from Faber Expanding Faber to "Faber College" Request not yet verified. Connection not yet synchronized. Attempting to sync... Synchronizing... Remote endpoint (None) not found, can not connect to Faber College```

wittrock (Wed, 29 Nov 2017 22:36:01 GMT):
it seems likely to be another failed network setup on my part

mgbailey (Wed, 29 Nov 2017 22:36:42 GMT):
Is the Faber agent started?

mgbailey (Wed, 29 Nov 2017 22:37:26 GMT):
What do you get when you do "show connection Faber"

wittrock (Wed, 29 Nov 2017 22:37:40 GMT):
```ALICE@sandbox> show connection Faber Expanding Faber to "Faber College" Connection (not yet accepted) Name: Faber College DID: not yet assigned Trust anchor: Faber College (not yet written to Indy) Verification key: Signing key: Remote: ULtgFQJe6bjiFbs7ke3NJD Remote Verification key: Remote endpoint: Request nonce: b1134a647eb818069c089e7694f63e6d Request status: not verified, remote verkey unknown Last synced: Try Next: sync "Faber College" accept request from "Faber College"```

mgbailey (Wed, 29 Nov 2017 22:38:22 GMT):
try sync, then try this command again

wittrock (Wed, 29 Nov 2017 22:38:37 GMT):
```ALICE@sandbox> sync faber Expanding faber to "Faber College" Synchronizing... Try Next: show connection "Faber College" accept request from "Faber College" ALICE@sandbox> show connection Faber Expanding Faber to "Faber College" Connection (not yet accepted) Name: Faber College DID: not yet assigned Trust anchor: Faber College (not yet written to Indy) Verification key: Signing key: Remote: ULtgFQJe6bjiFbs7ke3NJD Remote Verification key: Remote endpoint: Request nonce: b1134a647eb818069c089e7694f63e6d Request status: not verified, remote verkey unknown Last synced: Try Next: sync "Faber College" accept request from "Faber College"```

wittrock (Wed, 29 Nov 2017 22:38:56 GMT):
similar: I think the sync call is succeeding but the callback in the CLI isn't ever getting called. currently tracking down why

mgbailey (Wed, 29 Nov 2017 22:39:16 GMT):
It would appear that the faber agent attributes are not on the ledger

wittrock (Wed, 29 Nov 2017 22:39:51 GMT):
aha, interesting. Do you know enough about the getting started doc to know where that's supposed to happen in the flow?

wittrock (Wed, 29 Nov 2017 22:40:07 GMT):
(I've been using https://github.com/hyperledger/indy-node/blob/master/getting-started.md)

mgbailey (Wed, 29 Nov 2017 22:42:03 GMT):
The steps are in https://github.com/evernym/sovrin-environments/blob/master/vagrant/training/vb-multi-vm/TestIndyClusterSetup.md. Look in "Setting Up a CLI Client and Configuring the Agents in the Indy Cluster"

wittrock (Wed, 29 Nov 2017 22:42:33 GMT):
great, thanks so much!

mgbailey (Wed, 29 Nov 2017 22:42:39 GMT):
yw

arjanvaneersel (Thu, 30 Nov 2017 07:36:49 GMT):
Has joined the channel.

chriswinc (Thu, 30 Nov 2017 14:54:44 GMT):
Has joined the channel.

the_identity_guy (Thu, 30 Nov 2017 17:04:01 GMT):
Has joined the channel.

wittrock (Thu, 30 Nov 2017 21:36:42 GMT):
Hi all, another question about the Alice demo: I've made progress on the initial setup of syncing to Faber (no more issues with verKeys not being found), but am currently dealing with a supposedly successful sync and then a failure to find an endpoint. My first sync looks something like this: ```ALICE@sandbox> accept request from "Faber College" Request not yet verified. Connection not yet synchronized. Attempting to sync... No key present in wallet for making request on Indy, so adding one Key created in wallet Alice DID for key is 7P5uXE7Dk5jE7RPzRb9cxS Verification key is ~VDZdvdb74sEiPoHSPCFwJ Current DID set to 7P5uXE7Dk5jE7RPzRb9cxS Synchronizing... Connection Faber College synced Remote endpoint (None) not found, can not connect to Faber College``` Subsequently the connection looks like this: ```ALICE@sandbox> show connection "Faber College" Connection (not yet accepted) Name: Faber College DID: not yet assigned Trust anchor: Faber College (not yet written to Indy) Verification key: Signing key: Remote: ULtgFQJe6bjiFbs7ke3NJD Remote Verification key: ~5kh3FB4H3NKq7tUDqeqHc1 Remote endpoint: Not Available Request nonce: b1134a647eb818069c089e7694f63e6d Request status: not verified, remote verkey unknown Last synced: just now``` While I'm getting my nodes and agents set up, also see error messages like the following, but I'm not sure they're related to the problem I'm seeing: ```Error: client request invalid: InvalidClientRequest('dest should be added before adding attribute for it',) Error: client request invalid: InvalidClientRequest('dest should be added before adding attribute for it',) Error: client request invalid: InvalidClientRequest('dest should be added before adding attribute for it',) Nym ULtgFQJe6bjiFbs7ke3NJD added Nym CzkavE58zgX7rUMrzSinLr added Nym H2aKRiDeq8aLZSydQMDbtf added``` Can anyone help me figure out why my client can't seem to find an endpoint?

nbrempel (Thu, 30 Nov 2017 21:44:20 GMT):
You went through these steps? https://github.com/evernym/sovrin-environments/blob/master/vagrant/training/vb-multi-vm/TestIndyClusterSetup.md#setting-up-a-cli-client-and-configuring-the-agents-in-the-indy-cluster

nbrempel (Thu, 30 Nov 2017 21:44:53 GMT):
What happened when you ran the commands like this? `send NYM dest=ULtgFQJe6bjiFbs7ke3NJD role=TRUST_ANCHOR verkey=~5kh3FB4H3NKq7tUDqeqHc1`

wittrock (Thu, 30 Nov 2017 21:45:27 GMT):
those are the steps I'm using, yeah. I'd been scripting the first few commands (connect, new key with seed ..., send NYM..., ) and starting just at `prompt ALICE` but I decided that might have been hiding error messages

wittrock (Thu, 30 Nov 2017 21:45:44 GMT):
so I literally just tried to do it by hand, and I got: ```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=~5kh3FB4H3NKq7tUDqeqHc1 Adding nym ULtgFQJe6bjiFbs7ke3NJD Error: client request invalid: InvalidClientRequest('Th7MpTaRZVRYnPiabds81Y is neither Trustee nor owner of ULtgFQJe6bjiFbs7ke3NJD',)```

wittrock (Thu, 30 Nov 2017 21:46:29 GMT):
not totally sure how to fix that

wittrock (Thu, 30 Nov 2017 21:46:35 GMT):
in fact, not sure at all :)

nbrempel (Thu, 30 Nov 2017 21:47:09 GMT):
If you run the command `status` what do you get?

wittrock (Thu, 30 Nov 2017 21:47:24 GMT):
`Connected to sandbox Indy network`

nbrempel (Thu, 30 Nov 2017 21:48:41 GMT):
Hm, that's strange. When you started the Indy nodes, did you use the command `generate_indy_pool_transactions`?

wittrock (Thu, 30 Nov 2017 21:48:52 GMT):
I did

wittrock (Thu, 30 Nov 2017 21:49:06 GMT):
can paste the output if that's helpful

nbrempel (Thu, 30 Nov 2017 21:49:16 GMT):
sure

wittrock (Thu, 30 Nov 2017 21:50:17 GMT):
```docker run --rm --name Indy -it indy-base /bin/bash -c "generate_indy_pool_transactions --nodes 4 --clients 5 --ips 172.17.0.1,172.17.0.1,172.17.0.1,172.17.0.1; /bin/bash" 2017-11-30 21:43:44,846 | DEBUG | text_file_store.py ( 43) | _append_new_line_if_req | new line check for file: /root/.indy-cli/networks/sandbox/pool_transactions_genesis 2017-11-30 21:43:44,846 | DEBUG | ledger.py ( 201) | start | Starting ledger... 2017-11-30 21:43:44,847 | DEBUG | ledger.py ( 67) | recoverTree | Recovering tree from transaction log 2017-11-30 21:43:44,847 | DEBUG | ledger.py ( 82) | recoverTree | Recovered tree in 0.00014920899957360234 seconds 2017-11-30 21:43:44,847 | DEBUG | text_file_store.py ( 43) | _append_new_line_if_req | new line check for file: /root/.indy-cli/networks/sandbox/domain_transactions_genesis 2017-11-30 21:43:44,847 | DEBUG | ledger.py ( 201) | start | Starting ledger... 2017-11-30 21:43:44,847 | DEBUG | ledger.py ( 67) | recoverTree | Recovering tree from transaction log 2017-11-30 21:43:44,847 | DEBUG | ledger.py ( 82) | recoverTree | Recovered tree in 0.00012722400060738437 seconds BLS Public key is 4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba BLS Public key is 37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk BLS Public key is 3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5 BLS Public key is 2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw```

nbrempel (Thu, 30 Nov 2017 21:52:11 GMT):
The command is supposed to bootstrap the test network with dids with various levels of access. But it seems that the did for the seed `000000000000000000000000Steward1` doesn't have "steward" privileges like it should.

nbrempel (Thu, 30 Nov 2017 21:52:15 GMT):
And I'm not sure why that is

nbrempel (Thu, 30 Nov 2017 21:53:36 GMT):
unless something has changed recently

nbrempel (Thu, 30 Nov 2017 21:54:08 GMT):
try using this key instead: `new key with seed 000000000000000000000000Trustee1`

wittrock (Thu, 30 Nov 2017 21:54:45 GMT):
magic.

wittrock (Thu, 30 Nov 2017 21:54:49 GMT):
```indy@sandbox> new key with seed 000000000000000000000000Trustee1 Key created in wallet Default DID for key is V4SGRU86Z58d6TV7PBUe6f Verification key is ~CoRER63DVYnWZtK8uAzNbx Current DID set to V4SGRU86Z58d6TV7PBUe6f indy@sandbox> send NYM dest=ULtgFQJe6bjiFbs7ke3NJD role=TRUST_ANCHOR verkey=~5kh3FB4H3NKq7tUDqeqHc1 Adding nym ULtgFQJe6bjiFbs7ke3NJD Nym ULtgFQJe6bjiFbs7ke3NJD added```

nbrempel (Thu, 30 Nov 2017 21:54:58 GMT):
ok, great :)

wittrock (Thu, 30 Nov 2017 21:55:03 GMT):
okay, will keep going through the flow then

wittrock (Thu, 30 Nov 2017 21:55:14 GMT):
thank you!

nbrempel (Thu, 30 Nov 2017 21:55:19 GMT):
I'm not sure why the Steward seed isn't working anymore. Maybe something has changed and the docs haven't been updated yet

nbrempel (Thu, 30 Nov 2017 21:55:21 GMT):
no problem

wittrock (Thu, 30 Nov 2017 21:59:46 GMT):
@nbrempel: I've been able to get all the way through the demo! Is this worth filing a bug about somewhere?

nbrempel (Thu, 30 Nov 2017 22:03:43 GMT):
They track tickets here: https://jira.hyperledger.org/projects/INDY/issues/INDY-562?filter=allopenissues but I'm not sure if the public has write access. @sergey.minaev might know if it's a known bug.

mgbailey (Fri, 01 Dec 2017 00:13:16 GMT):
@wittrock , your validators should have a domain_transactions_genesis file that contains your trustees and stewards. Steward1 should be in there, with role=2

sergey.minaev (Fri, 01 Dec 2017 10:35:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=5WFJTyCMr9Hmw947Z) @ashcherbakov

nbrempel (Fri, 01 Dec 2017 19:39:31 GMT):
I thought some people here might find this interesting: We have a test indy network running and we've added some extra features: http://138.197.170.136

nbrempel (Fri, 01 Dec 2017 19:40:14 GMT):
^ it has a dashboard with links to some convenience functions and it also includes a rudimentary ledger browser (it just dumps the contents of the ledgers)

nbrempel (Fri, 01 Dec 2017 19:41:59 GMT):
@nage @Sean_Bohan, @jljordan_bcgov mentioned you might find this interesting :)

nage (Fri, 01 Dec 2017 19:42:55 GMT):
_wants pull requests ;)_

nage (Fri, 01 Dec 2017 19:42:55 GMT):
_wants pull requests :)_

nage (Fri, 01 Dec 2017 19:43:49 GMT):
or at least a blog post

nbrempel (Fri, 01 Dec 2017 19:46:00 GMT):
sure! Where should it live? Right now it's https://github.com/nrempel/von-network (docs are a bit behind)

nage (Sat, 02 Dec 2017 05:33:41 GMT):
Good question, the web-ui isn't really just a stand-alone script, or I think scripts would be the obvious place for it. What do you suggest?

NiallC (Sat, 02 Dec 2017 19:50:55 GMT):
Has joined the channel.

the_identity_guy (Sun, 03 Dec 2017 23:42:46 GMT):
Hi Folks, is there a way to see the key/value transactions stored on the Indy ledger using CLI

swcurran (Mon, 04 Dec 2017 03:37:28 GMT):
@the_identity_guy - @nbrempel has created the start of a dashboard - see example - http://138.197.170.136/. The code (I believe) can be found here - https://github.com/nrempel/von-network Our team is working on a fancier UI to the dashboard.

alkopnin (Mon, 04 Dec 2017 07:44:58 GMT):
Has joined the channel.

mgbailey (Mon, 04 Dec 2017 15:01:40 GMT):
@the_identity_guy If you have access to a validator you can see the contents of the ledger on it using "sudo read_ledger --type domain"

the_identity_guy (Mon, 04 Dec 2017 16:01:19 GMT):
thank you @mgbailey and @swcurran

theruss (Tue, 05 Dec 2017 03:00:07 GMT):
@nbrempel and @swcurran thanks for sharing, very, very timely. I'm still putting together our RFP to use Indy with Fabric, and TBH what's missing for us is a simple GUI with "push button" controls to action things on the ledger such as provisioning entity's, writing schemas to the ledger and revoking claims. The trouble is, once you go down this route, you need to be sure that a). the application user is "on the ledger" and has the correct Sovrin style role, and b). that users of the GUI application are authenticated in a way that is consistent with the underlying SSI principles of Indy. For the latter, I'm thinking a wallet app, whose derived pub keys are stored within it, and using a QR code to authenticate.

theruss (Tue, 05 Dec 2017 03:00:13 GMT):
Still in the thinking stage though.

indykish (Tue, 05 Dec 2017 03:56:40 GMT):
Has joined the channel.

JOYELIN (Tue, 05 Dec 2017 07:03:38 GMT):
Has joined the channel.

swcurran (Tue, 05 Dec 2017 16:26:59 GMT):
@theruss - login with SSI is crucial to us as well. We are focused on the organizational use of SSI (vs. purely personal) and we hope (and are pushing) to see both authentication and authorization (aka roles/capabilities) with delegation of authority as a first class element. We have our current project on the go (TheOrgBook), but that will lead quickly to authentication and authorization.

Suedonym (Thu, 07 Dec 2017 21:47:39 GMT):
Recording of today's meeting can be found here: https://drive.google.com/file/d/1UpSp9A2G6fr7R7Wk-7g_hh_kEe17lKgV/view?usp=sharing

slafranca (Fri, 08 Dec 2017 18:37:26 GMT):
Has joined the channel.

Sean_Bohan (Fri, 08 Dec 2017 19:48:14 GMT):
Folks: Thanks for attending yesterday's Indy WG call. As a followup, here are the links: a video recording of most of the session can be found here: https://drive.google.com/file/d/1UpSp9A2G6fr7R7Wk-7g_hh_kEe17lKgV/view?usp=sharing the agenda can be found here: https://docs.google.com/presentation/d/16smtezBO5T90J0nAosh0ezsklMEkQ_o5Gbwt3R5lQ8A/edit?usp=sharing the video I mentioned on the call can be found here (note, it has no sound or narration but it is a walkthrough of the Getting Started Guide - this is all thanks to Mike Bailey!): https://drive.google.com/open?id=19Z3PjSUT4XNPs4n1ofN9nGa9A80o_Uor And you can find the docs, videos, agendas share in this folder: https://drive.google.com/drive/folders/0B_NJV6eJXAA1UWtBSmRNLTR3UjQ?usp=sharing

ashcherbakov (Mon, 11 Dec 2017 12:53:17 GMT):
A Pull Request with proposed Observer Nodes Design: https://github.com/hyperledger/indy-plenum/pull/478

nud3l (Wed, 13 Dec 2017 17:52:06 GMT):
Has joined the channel.

nuxibyte_old (Thu, 14 Dec 2017 09:41:26 GMT):
Has joined the channel.

gvvishwanath (Fri, 15 Dec 2017 05:21:48 GMT):
Has joined the channel.

calvinx (Fri, 15 Dec 2017 06:29:17 GMT):
Has joined the channel.

notOccupanther (Sun, 17 Dec 2017 16:44:06 GMT):
Has joined the channel.

the_identity_guy (Mon, 18 Dec 2017 18:34:40 GMT):
What is the difference between a schema and claim definition in the context of Indy?

swcurran (Mon, 18 Dec 2017 18:51:59 GMT):
A schema is just that - a definition of the fields in a schema - it has a name, version and creator. A claim definition is a specific use of a schema by an identify, and (will eventually) provide a link to a revocation registry. So a schema might be defined by a group of Banks, and each bank would create a claim def that defined their specific use of the schema.

swcurran (Mon, 18 Dec 2017 18:51:59 GMT):
A schema is just that - a definition of the fields in a schema - it has a name, version and creator. A claim definition is a specific use of a schema by an identity, and (will eventually) provide a link to a revocation registry. So a schema might be defined by a group of Banks, and each bank would create a claim def that defined their specific use of the schema.

wittrock (Mon, 18 Dec 2017 22:13:56 GMT):
I just had this _exact question_, and was super glad to find the answer here! Would be a great thing to put in a FAQ somewhere.

Sean_Bohan (Mon, 18 Dec 2017 22:14:14 GMT):
Wittrock - I am working on an FAQ and glossary over the holiday

wittrock (Mon, 18 Dec 2017 22:14:21 GMT):
fantastic, thank you!

Sean_Bohan (Mon, 18 Dec 2017 22:14:22 GMT):
we are working on upping our game

the_identity_guy (Mon, 18 Dec 2017 22:58:59 GMT):
thank you @Sean_Bohan

Harmannz (Tue, 19 Dec 2017 20:39:48 GMT):
Has joined the channel.

PabloBascunana (Wed, 20 Dec 2017 08:51:30 GMT):
Has joined the channel.

ashcherbakov (Thu, 21 Dec 2017 16:00:12 GMT):
https://docs.google.com/spreadsheets/d/1-8mv5dokDPd5Laqur7EZtrgxmln0sY5CiJuSsL1Rg9Q/edit#gid=1918048553

jljordan_bcgov (Thu, 21 Dec 2017 16:24:27 GMT):
Very initial ideas around an Indy Ledger Browser http://138.197.170.136

jljordan_bcgov (Thu, 21 Dec 2017 16:25:31 GMT):

Clipboard - December 21, 2017 8:25 AM

mgbailey (Thu, 21 Dec 2017 19:19:59 GMT):
@jljordan_bcgov , you can do this with access to all the nodes in the pool. It is harder on the live network, where each steward has access to just one node. How do you think stewards would feel about configuring their production nodes to push this data to a central location / aggregator that could display something like this? Some of them are big, security-conscious organizations.

swcurran (Thu, 21 Dec 2017 19:35:02 GMT):
@mgbailey - agreed - that display and our current approach isn't going to scale to the live network. And we aren't really worried about our view of the live network - someone else's problem. We are building these to make it easier to ramp up new devs and even business folks to help them understand what's going on. We have been thinking about pushing that data into a graph database (centralized, as you say) for visualization and querying. Again, primarily for ramping people up, but can be used for status.

jljordan_bcgov (Thu, 21 Dec 2017 19:35:33 GMT):
@swcurran +1 :)

mgbailey (Thu, 21 Dec 2017 19:38:15 GMT):
@swcurran Right, but I want it for the live pool too!

jljordan_bcgov (Thu, 21 Dec 2017 19:41:26 GMT):
the Graph idea could be interesting for schema discovery we are thinking

jljordan_bcgov (Thu, 21 Dec 2017 19:41:53 GMT):
especially if there ends up being well-known DID for services ... govt services, banks, employers etc

mgbailey (Thu, 21 Dec 2017 19:42:42 GMT):
Which there has to be, if we are going to have recognizable, trusted signatures on claims

jljordan_bcgov (Thu, 21 Dec 2017 19:47:39 GMT):
seems to make sense yes ... in fact we were thinking we would have a verifiable claim that is published by the gov that lists all their services DIDs

mgbailey (Thu, 21 Dec 2017 19:48:18 GMT):
I like it!

wolili (Fri, 22 Dec 2017 11:26:58 GMT):
Has joined the channel.

SaiChaitanya (Wed, 27 Dec 2017 16:35:19 GMT):
Has joined the channel.

Sean_Bohan (Thu, 28 Dec 2017 14:52:21 GMT):
No Indy WG Call Today!

ronniemh (Wed, 03 Jan 2018 16:44:46 GMT):
Has joined the channel.

ronniemh (Wed, 03 Jan 2018 16:45:08 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?

Sean_Bohan (Thu, 04 Jan 2018 14:36:41 GMT):
please note there is no Indy call today! We will reconvene next Thursday 1/11/18

wolili (Fri, 05 Jan 2018 10:04:12 GMT):
Hi, for a proof of concept I would like to use the indy-node and the Plenum Byzantine Fault Tolerance (BFT) Protocol for a custom purpose. I would like to send a custom request from an agent to the indy-nodes. There I would like the nodes to process the request (basically execute a custom function) and then come to consent according to BFT. The result should be sent back to the agent. Since the code will run locally I don’t mind adding code. My questions are: How is it possible to send a request to nodes so that the BFT Protocol is triggered? Where should I place a custom function that is executed by each node? Is there some information (demos, samples, testcases) that show how indy is executing the BFT Protocol? Thanks in advance!

the_identity_guy (Sat, 06 Jan 2018 01:36:03 GMT):
Hi, happy new year Quick question about why clients are being added to the ledger by the "generate_indy_pool_transactions" command .. from test_network_setup.py we have: ``` for cd in client_defs: txn = Member.nym_txn(cd.nym, cd.name, verkey=cd.verkey, creator=trustee_def.nym) domainLedger.add(txn) ``` what is the purpose of registering new clients when starting the network? Aren't clients created when the agent code is executed. for example from Faber.py code we create a new client like this: ```if client is None: client = create_client(base_dir_path=base_dir_path, client_class=TestClient)```

marc4gov (Sat, 06 Jan 2018 20:28:22 GMT):
Has joined the channel.

ashcherbakov (Tue, 09 Jan 2018 13:19:15 GMT):
@the_identity_guy In agents code we create an instance of Client that will connect to the pool and send requests. So, client here is a `code`. In `test_network_setup.py` we create some pre-defined genesis transactions. It created genesis pool transactions (NODE txn defining a node in the pool), plus (optionally) a number of NYM transactions in domain ledger defining Trustees, Stewards, etc. These genesis NYM transactions are called 'clients' in the code. So, here client is a `genesis transaction on ledger`

ashcherbakov (Tue, 09 Jan 2018 13:20:05 GMT):
BTW please note that existing agents from indy-node repos (inclkuding Faber one) are going to be deprecated soon. Please use https://github.com/hyperledger/indy-sdk for any client communicaton

ashcherbakov (Tue, 09 Jan 2018 13:26:48 GMT):
@wolili As of now, it's not possible to add custom behaviour without writing custom code. But it will be possible soon using `plugins`. We are working on a better documentation about BFT support in Plenum. As of now you can have a look at https://github.com/hyperledger/indy-plenum/wiki and https://pakupaku.me/plaublin/rbft/5000a297.pdf

ashcherbakov (Tue, 09 Jan 2018 13:27:47 GMT):
@ronniemh Please have a look at https://github.com/hyperledger/indy-sdk It already has Java wrapper support. It also contains docs about how to use SDK

ashcherbakov (Tue, 09 Jan 2018 13:28:06 GMT):
You can also ask questions in indy-sdk channel

ronniemh (Tue, 09 Jan 2018 14:32:07 GMT):
@ashcherbakov thank you, another question: what do you mean by "...projects may collapse into this one, except for indy-sdk." in About Indy Node, why are they different?

ashcherbakov (Tue, 09 Jan 2018 14:39:21 GMT):
indy-anoncreds will be deprecated soon. So, it'more about indy-plenum and indy-node projects. In fact plenum contains general RBFT and pool support, while indy-node adds Indy-related transactions support. That's why they are different

ashcherbakov (Tue, 09 Jan 2018 14:39:56 GMT):
SDK is a separate one providing a read-to-use wrappers in different languages to be used in applications

ashcherbakov (Tue, 09 Jan 2018 14:39:56 GMT):
SDK is a separate one providing a ready-to-use wrappers in different languages to be used in applications

the_identity_guy (Tue, 09 Jan 2018 15:42:27 GMT):
thank you @ashcherbakov I understood the purpose of creating a trustee and 4 stewards (to manage 4 nodes) transactions but wasn't sure about the creation of clients in ''test_network_setup.py'' as part of the genesis transactions.. My understanding was that clients are used to hold keys and interact with ledger (optionally through agents).. are clients that are created during the genesis used by the Alice use case? can you elaborate a bit on what you mean by clients being a 'genesis transaction on ledger'? are the clients used by the stewards to interact with ledger? '''su - vagrant -c "generate_indy_pool_transactions --nodes 4 --clients 4 --ips '10.20.30.201,10.20.30.202,10.20.30.203,10.20.30.204'''

the_identity_guy (Tue, 09 Jan 2018 15:42:27 GMT):
thank you @ashcherbakov I understood the purpose of creating a trustee and 4 stewards (to manage 4 nodes) transactions but wasn't sure about the creation of clients in ''test_network_setup.py'' as part of the genesis transactions.. My understanding was that clients are used to hold keys and interact with ledger (optionally through agents).. are clients that are created during the genesis used by the Alice use case? can you elaborate a bit on what you mean by clients being a 'genesis transaction on ledger'? are the clients used by the stewards to interact with ledger? ```su - vagrant -c "generate_indy_pool_transactions --nodes 4 --clients 4 --ips '10.20.30.201,10.20.30.202,10.20.30.203,10.20.30.204```

ashcherbakov (Tue, 09 Jan 2018 15:44:17 GMT):
This is just some pre-defined clients one can send requests from. It's not related to Alice/Faber/Acme at all.

ashcherbakov (Tue, 09 Jan 2018 15:44:34 GMT):
(so this is some NYM txns with default role)

ashcherbakov (Tue, 09 Jan 2018 15:45:02 GMT):
(while Stewards and Trustee are NYM txns with a specific role set)

the_identity_guy (Tue, 09 Jan 2018 15:46:21 GMT):
Ok so its generated in case one needs to use it

the_identity_guy (Tue, 09 Jan 2018 15:46:55 GMT):
I do see the transaction being made: [6,{"dest":"7JhapNNMLnwkbiC2ZmPZSE","identifier":"V4SGRU86Z58d6TV7PBUe6f","type":"1","verkey":"~LgpYPrzkB6awcHMTPZ9TVn"}]

ashcherbakov (Tue, 09 Jan 2018 15:46:59 GMT):
yes, it's optional, and not so needed for Getting Started

ashcherbakov (Tue, 09 Jan 2018 15:47:51 GMT):
Just may give you an example of how NYM txns for ordinary users may look like

the_identity_guy (Tue, 09 Jan 2018 15:51:41 GMT):
great thank you @ashcherbakov

JeroenDePrest (Wed, 10 Jan 2018 08:51:09 GMT):
Has joined the channel.

Sean_Bohan (Wed, 10 Jan 2018 20:32:59 GMT):
Indy folks. The Indy Glossary (still work in progress) can be found here: https://wiki.hyperledger.org/projects/indy_glossary

wittrock (Wed, 10 Jan 2018 21:00:14 GMT):
This is fantastic. Thanks!

xixuejia (Thu, 11 Jan 2018 01:48:06 GMT):
Has joined the channel.

ashcherbakov (Thu, 11 Jan 2018 16:15:28 GMT):
FYI: Environment (docker, vagrant, etc.) scripts were moved from sovrin-environment to https://github.com/hyperledger/indy-node/tree/master/environment

Derashe (Mon, 15 Jan 2018 16:09:12 GMT):
Has joined the channel.

Rickzan (Tue, 16 Jan 2018 19:23:39 GMT):
Has joined the channel.

smithbk (Wed, 17 Jan 2018 15:31:04 GMT):
Has joined the channel.

hawkmauk (Wed, 17 Jan 2018 16:30:06 GMT):
Has joined the channel.

smontsaroff (Thu, 18 Jan 2018 00:38:51 GMT):
Has joined the channel.

smontsaroff (Thu, 18 Jan 2018 00:40:22 GMT):
Has anyone tried to install indy-node on Mac OS 10.12.3? I manage the install, but on running indy (using brew's gcc) and get self._s = _sha3.sha3() AttributeError: module '_sha3' has no attribute 'sha3'

ashcherbakov (Thu, 18 Jan 2018 08:46:44 GMT):
@smontsaroff The only officially supported platform for indy-node now is Ubuntu 16.04. We produce working and tested deb packages for it. Do you want to develop indy-node (contribute to the code) using Mac OS, or you just want to run the Pool (without changing the code)? In the later case you can use Docker file (see https://github.com/hyperledger/indy-node/tree/master/environment/docker)

nij458 (Fri, 19 Jan 2018 12:39:35 GMT):
Has joined the channel.

Sean_Bohan (Fri, 19 Jan 2018 15:32:06 GMT):
Thanks to all who joined yesterday's Ledger WG call. Here are the links from the call: 1. Agenda: https://docs.google.com/presentation/d/1PCJua6VssoRLkuGCrse9y7E92f0HTvZaqSRd5VDgA8E/edit#slide=id.g2c72e85c7b_0_49 2. Dev Status (note - tabs at bottom for each week's status): https://docs.google.com/spreadsheets/d/1-8mv5dokDPd5Laqur7EZtrgxmln0sY5CiJuSsL1Rg9Q/edit#gid=970515928 3. Indy Wiki: https://wiki.hyperledger.org/projects/indy 4. Hyperledger Hackfest LA in Feb: https://www.hyperledger.org/event/hyperledger-hackfest-february-2018 5. Hyperledger Identity WG Call next week: https://wiki.hyperledger.org/groups/identity/identity-wg 6. Indy Mailing List: https://lists.hyperledger.org/mailman/listinfo/hyperledger-indy 7. WG Call Recording: https://drive.google.com/open?id=1ubhdivWsnXfe-GY5-bxDPizG4HTAvdst PLEASE - if you have an idea for a topic for next week's WG call or want to demo your work, let me know.

smithbk (Fri, 19 Jan 2018 18:29:44 GMT):
Anyone, does indy support PKCS11 so keys can in an HSM?

mastersingh24 (Mon, 22 Jan 2018 16:59:44 GMT):
Has joined the channel.

akhihaki (Mon, 22 Jan 2018 18:12:32 GMT):
Has joined the channel.

nghia47 (Tue, 23 Jan 2018 04:41:47 GMT):
Has joined the channel.

smithbk (Tue, 23 Jan 2018 16:52:27 GMT):
We are trying to build indy-node on a non-x86 platform. I cloned github.com/hyperledger/indy-node. There is no Makefile. How is the build kicked off and where is native code compiled as part of this process? @mgbailey @andkononykhin Thanks

mgbailey (Tue, 23 Jan 2018 17:18:58 GMT):
@smithbk , indy-node is currently python3 code, and does not require building. Basically what is needed to make it work is: 1) python3 2) all the dependent libraries 3) file placement in the correct directories, environment variables, etc. In the future there will also be some custom RUST libraries that will need to be built, but that is not the case today.

mgbailey (Tue, 23 Jan 2018 17:19:29 GMT):
python 3.5 or later, to be more exact

smithbk (Tue, 23 Jan 2018 17:35:35 GMT):
@mgbailey thanks

akhihaki (Tue, 23 Jan 2018 20:07:40 GMT):
Hello, i have started to explore Indy, Step 1: I followed the Detailed Setup instructions listed on https://github.com/hyperledger/indy-node/blob/stable/docs/setup-dev.md to run indy locally. I was successfully able to install the dependencies. Step 2: To start running indy, i was following https://github.com/hyperledger/indy-node/blob/master/docs/indy-running-locally.md and when i try to setup the environment (#Initial Setup), i am getting the following error "OSError: dlopen(libindy_crypto.dylib, 6): image not found" and not able to get this around. Need help in resolving this issue. More Details : 'libindy_crypto.dylib' is generated when building indy-crypto (https://github.com/hyperledger/indy-crypto#building-indy-crypto) and is in /indy-crypto/libindy-crypto/target/debug/deps folder Let me know if i need to provide more details

zhigunenko.dsr (Wed, 24 Jan 2018 09:20:20 GMT):
Has joined the channel.

Sean_Bohan (Wed, 24 Jan 2018 21:41:06 GMT):
welcome @akhihaki ! hey @mgbailey can you help out here?

mgbailey (Wed, 24 Jan 2018 21:42:22 GMT):
@Sean_Bohan , sorry no. I am not too familiar with the dev type setups.

Sean_Bohan (Wed, 24 Jan 2018 21:43:00 GMT):
no worries @mgbailey - @akhihaki - let me follow up

ashcherbakov (Thu, 25 Jan 2018 07:55:49 GMT):
@akhihaki What is the purpose of the exploration? If you need just to run the pool and write your applications against the pool (using https://github.com/hyperledger/indy-sdk), then you can run the pool easily in Docker (https://github.com/hyperledger/indy-node/tree/master/environment/docker/pool). No need to setup dev environment. So, all client-related logic (send requests and transactions to the pool) as well as anoncreds protocol (verifiable claims) is within indy-sdk. If you want to contribute to indy-node code (write code in https://github.com/hyperledger/indy-node repo dealing with RBFT, consensus, etc.) then you need to install dev environment as you started. Please let us know if you really need it, and we will try to help.

wolili (Thu, 25 Jan 2018 11:24:46 GMT):
@ashcherbakov hi, I have two questions regarding your post above, that might seem trival, but I kind of got stuck. 1. does "run the pool" just mean to startup the docker, or do I have to run some code first? 2. Regarding the development of indy-node. In case I change/add code, how can I deploy/run the code on a local node?

ashcherbakov (Thu, 25 Jan 2018 13:03:10 GMT):
@wolili 1. no code is needed. you can just start the docker. 2. during development, you usually write and run intgeration tests (see test folders) which start a test pool (in one process). You can also run nodes locally as described in the guide you followed. Once the PR is merged, and there is a deb package build, you can try it in Docker as well.

hidde-jan (Thu, 25 Jan 2018 14:49:47 GMT):
Hi people

hidde-jan (Thu, 25 Jan 2018 14:50:55 GMT):
Me and a few people are looking at running a test network, however, we'd like to generate our own steward keys and not use the default 00000...00Steward1 seeds used in all test environments

hidde-jan (Thu, 25 Jan 2018 14:51:29 GMT):
is there any guide or some examples of how to start an indy network from scratch?

WadeBarnes (Thu, 25 Jan 2018 14:59:07 GMT):
@hidde-jan, you're in luck. We've already done that. https://github.com/topics/verifiable-organizations-network You'll want to start with von-connector.

WadeBarnes (Thu, 25 Jan 2018 14:59:07 GMT):
@hidde-jan, you're in luck. We've already done that. https://github.com/topics/verifiable-organizations-network You'll want to start with von-network

WadeBarnes (Thu, 25 Jan 2018 15:02:33 GMT):
A running instance of the von-network complete with ledger browser; http://138.197.170.136/ A running instance of TheOrgBook connected to instances of the permitify services; https://devex-von-dev.pathfinder.gov.bc.ca/roadmap All provisional, so have at it. Performs registration, claim def submissions, claim requests, proofs, etc.

hidde-jan (Thu, 25 Jan 2018 15:03:18 GMT):
@WadeBarnes thanks :)

WadeBarnes (Thu, 25 Jan 2018 15:04:10 GMT):
Things are in flux on the provisional sites, so there may be some interruptions.

hidde-jan (Thu, 25 Jan 2018 15:17:27 GMT):
@WadeBarnes I see you're generating your keys in https://github.com/bcgov/von-connector/blob/master/scripts/start_node.sh

hidde-jan (Thu, 25 Jan 2018 15:18:13 GMT):
but aren't these the default keys used in the testnetwork?

hidde-jan (Thu, 25 Jan 2018 15:22:36 GMT):
Is your provisional network set up using the same keys or did you manually bootstrap the nodes and create the genesis file?

WadeBarnes (Thu, 25 Jan 2018 15:30:34 GMT):
Apologies I meant to point you at the von-network as your starting point. The answer to your questions about genesis file are there.

WadeBarnes (Thu, 25 Jan 2018 15:32:57 GMT):
The von-network has an API endpoint where clients can get the genesis file.

WadeBarnes (Thu, 25 Jan 2018 15:34:43 GMT):
This allows for a bit of dynamic configuration of agents connecting to the ledger; https://github.com/bcgov/TheOrgBook/blob/master/tob-api/tob_api/hyperledger_indy.py

WadeBarnes (Thu, 25 Jan 2018 15:34:43 GMT):
This allows for a bit of dynamic configuration of agents connecting to the ledger, for example; https://github.com/bcgov/TheOrgBook/blob/master/tob-api/tob_api/hyperledger_indy.py

hidde-jan (Thu, 25 Jan 2018 15:41:55 GMT):
thanks

hidde-jan (Thu, 25 Jan 2018 15:42:45 GMT):
it seems that you still use the generate_indy_pool_transactions under the hood, which still use hardcoded seeds as far as I can tell

ashcherbakov (Thu, 25 Jan 2018 16:17:53 GMT):
@hidde-jan You can either enhance generate_indy_pool_transactions to support custom seeds, or just replace verkeys in genesis txns by the ones created by desired seeds. BTW any contribution to enhance the scripts is appreciated.

drew 41 (Thu, 25 Jan 2018 16:35:21 GMT):
Has joined the channel.

hidde-jan (Thu, 25 Jan 2018 17:00:02 GMT):
@ashcherbakov ok, thanks. I’ve had a quick look. Enabling custom seeds seems to touch a lot of things all the way into Indy-plenum. I might have a further look :)

ashcherbakov (Thu, 25 Jan 2018 17:02:16 GMT):
yes, unfortunately the code is quite tightly coupled in many places. one of our goals is to re-factor it to avoid this.

wolili (Fri, 26 Jan 2018 12:01:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=omFKApsnyjE7Maq6T) @ashcherbakov thank you very much

tkuhrt (Fri, 26 Jan 2018 12:45:29 GMT):
SeanBohan_Sovrin

akhihaki (Fri, 26 Jan 2018 20:04:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=FNzQmXrzPJfwjXgwh) @ashcherbakov i was trying to create an application, i now figured out to run the pool using docker. Thanks.

Sean_Bohan (Fri, 26 Jan 2018 20:56:48 GMT):
awesome!

hidde-jan (Sun, 28 Jan 2018 16:22:18 GMT):
Got another question about genesis transaction files

hidde-jan (Sun, 28 Jan 2018 16:22:29 GMT):
How is the txnId determined?

hidde-jan (Sun, 28 Jan 2018 16:22:59 GMT):
I noticed the files are generated by starting a node, adding a few NYM's and then writing the domain an pool genesis files

hidde-jan (Sun, 28 Jan 2018 16:24:42 GMT):
does that seem correct?

robinrob (Mon, 29 Jan 2018 14:45:04 GMT):
Has joined the channel.

ajayatgit (Mon, 29 Jan 2018 19:47:35 GMT):
Has joined the channel.

nmellal (Tue, 30 Jan 2018 09:56:34 GMT):
Has joined the channel.

pimotte (Fri, 02 Feb 2018 07:30:24 GMT):
Has joined the channel.

wolili (Fri, 02 Feb 2018 12:34:43 GMT):
Hello, in indy-plenum/docs/plugin.md I came accross the term "Authenticator", but I cannot find the name in the glossary. What is an Authenticator?

ashcherbakov (Fri, 02 Feb 2018 13:08:50 GMT):
@wolili https://github.com/hyperledger/indy-plenum/blob/master/docs/request_handling.md#signature-verification

salmanbaset (Sun, 04 Feb 2018 22:18:47 GMT):
Has joined the channel.

Jasdog (Wed, 07 Feb 2018 06:22:32 GMT):
Has joined the channel.

wangdong (Thu, 08 Feb 2018 08:00:54 GMT):
Has joined the channel.

wangdong (Thu, 08 Feb 2018 08:12:34 GMT):
Hi I wonder can I just install all the stuff manually with python setup.py install ?

wangdong (Thu, 08 Feb 2018 08:13:06 GMT):
Because there are some compatible issues I have to resolve.

wangdong (Thu, 08 Feb 2018 08:13:28 GMT):
I tried, it seems some files are not properly processed

ashcherbakov (Thu, 08 Feb 2018 08:40:37 GMT):
Hi @wangdong What is your use case? As of now, the only supported platform is Ubuntu (x86). And the only supported way to run Indy pool is to install a deb package.

ashcherbakov (Thu, 08 Feb 2018 08:41:06 GMT):
You can install via pypi or setup.py, but rather for dev purposes (development, running tests, etc.)

wangdong (Thu, 08 Feb 2018 08:41:35 GMT):
yes, I know that. I try to port this to s390 platform

ashcherbakov (Thu, 08 Feb 2018 08:41:52 GMT):
What don't you create a deb package and test it?

ashcherbakov (Thu, 08 Feb 2018 08:42:03 GMT):
With a local installation ytou can check that all tests pass

wangdong (Thu, 08 Feb 2018 08:42:35 GMT):
sure

wangdong (Thu, 08 Feb 2018 08:42:56 GMT):
I just resolved all the third party independencies

wangdong (Thu, 08 Feb 2018 08:43:24 GMT):
I will try to have a build environment later on

wangdong (Thu, 08 Feb 2018 08:43:54 GMT):
for now, I just want see if there are any other compatible issues

wangdong (Thu, 08 Feb 2018 09:04:18 GMT):
when I try to start test environment : got error 'indy_config.py' has no attribute 'GENESIS_DIR'

wangdong (Thu, 08 Feb 2018 09:05:19 GMT):
command line is : **generate_indy_pool_transactions --nodes 1 --clients 1 --nodeNum 1 --ips '10.2.2.8' --network=sandbox**

gudkov (Thu, 08 Feb 2018 10:48:47 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.

ashcherbakov (Thu, 08 Feb 2018 13:57:54 GMT):
@wangdong Did you run `create_dirs.sh`? Also we don't guarantee that it will work somewhere besides deb packages, since some special folders need to be created, and config files need to be prepared

wangdong (Thu, 08 Feb 2018 13:58:59 GMT):
yes, I ran it. And as you said, I fount the NETWORK_NAME is not created. I have to do that manually.

ashcherbakov (Thu, 08 Feb 2018 15:19:13 GMT):
Please feel free to send PRs with your fixes regarding running the nodes locally (not from debs). We will aprreciate any contribution. As I said, we don't officially support running the node locally (not from debs) now, but if you find all this issues and send a PR, that it would be great to support it again

wangdong (Fri, 09 Feb 2018 01:10:07 GMT):
sure. Thanks.

AndrewHughes3000 (Fri, 09 Feb 2018 09:26:00 GMT):
Has joined the channel.

wangdong (Sun, 11 Feb 2018 16:21:00 GMT):
I found the script to build the 3rd parties packages. It just fetch the source code and build it. But what if the source code is local?

wangdong (Sun, 11 Feb 2018 16:21:08 GMT):
How can I build it?

wangdong (Sun, 11 Feb 2018 16:29:15 GMT):
ok, I have to modify something

hawkmauk (Mon, 12 Feb 2018 19:42:19 GMT):
@wangdong don't know if it will help but I've been trying to get indy node running on a digitalocean droplet without docker and have been documenting it here: https://docs.google.com/document/d/19EoJyOXokmjG0dM4bweszNeOYOwxMHI8VCyhDzn7I3M/edit?usp=sharing I haven't been through creating the keys and running the demo yet but hope to do that soon

the_identity_guy (Mon, 12 Feb 2018 19:48:07 GMT):
Is the anon-cred implemented on https://github.com/hyperledger/indy-anoncreds/tree/bf013f72b4cc37030f26bc11b63b18f600638eb4/anoncreds/protocol based on https://github.com/hyperledger/indy-anoncreds/blob/master/docs/dev/anoncred.pdf ?

NickThomas (Mon, 12 Feb 2018 23:09:54 GMT):
Has joined the channel.

wangdong (Tue, 13 Feb 2018 00:35:59 GMT):
@hawkmauk Thanks. I have made it. I have to install something manually. Because indy is not supported on s390 which is my platform. But I can run it now.

wangdong (Tue, 13 Feb 2018 00:36:43 GMT):
Thanks for your sharing.

wangdong (Tue, 13 Feb 2018 00:37:39 GMT):
Ok, if you got any problem, just paste it out. maybe I can help

ashcherbakov (Tue, 13 Feb 2018 09:45:18 GMT):
@the_identity_guy Yes, but ` https://github.com/hyperledger/indy-anoncreds` is going to be deprecated (already deprecated in fact). Please have a look at the latest implementation in https://github.com/hyperledger/indy-crypto/tree/master/libindy-crypto/src/cl and https://github.com/hyperledger/indy-sdk

prathyushpv (Wed, 14 Feb 2018 06:43:15 GMT):
Has joined the channel.

mjmckean (Wed, 14 Feb 2018 22:22:25 GMT):
Has joined the channel.

daveryIBM (Thu, 15 Feb 2018 13:44:52 GMT):
Has joined the channel.

Sean_Bohan (Thu, 15 Feb 2018 16:17:08 GMT):
Anoncreds documentation shared by Alex on the call: https://github.com/hyperledger/indy-node/blob/master/design/anoncreds.md

jljordan_bcgov (Thu, 15 Feb 2018 16:27:01 GMT):
Yay anoncreds team .... great work!

Sean_Bohan (Thu, 15 Feb 2018 16:32:15 GMT):
Ian's wallet document from today's call: https://github.com/ianco/indy-sdk/blob/master/doc/enterprise-wallet-design.md

Sean_Bohan (Thu, 15 Feb 2018 16:44:53 GMT):
Daniel's deck from today's call: http://bit.ly/2EKVy4K

twshelton (Thu, 15 Feb 2018 16:56:59 GMT):
Has joined the channel.

jljordan_bcgov (Thu, 15 Feb 2018 16:58:49 GMT):
@Sean_Bohan @danielhardman Maybe an open call to do more on the wallet discussion?

Sean_Bohan (Thu, 15 Feb 2018 17:02:54 GMT):
I like that idea - let me set something up

narendranath (Thu, 15 Feb 2018 18:50:03 GMT):
Has joined the channel.

Drew 42 (Fri, 16 Feb 2018 21:36:15 GMT):
Has joined the channel.

Comuto (Wed, 21 Feb 2018 12:34:11 GMT):
Has joined the channel.

smithbk (Wed, 21 Feb 2018 14:13:03 GMT):
Hi, we are running a node in docker and want to use supervisord rather than systemd so that we can run unprivileged and still want the control-tool to work. Is the correct place to add this support by modifying these files to look for supervisorctl if systemctl doesn't exist? ```$ grep -lr systemctl scripts scripts/upgrade_indy_node_ubuntu1604.sh scripts/restart_sovrin_node_ubuntu1604.sh scripts/upgrade_indy_node_ubuntu1604_test.sh scripts/validator-info scripts/complete_rebranding_upgrade_ubuntu1604.sh scripts/restart_indy_node_ubuntu1604.sh```

smithbk (Wed, 21 Feb 2018 14:13:03 GMT):
@ashcherbakov thanks .. will do

smithbk (Wed, 21 Feb 2018 14:13:56 GMT):
1) Any issues with adding this support? I could do the PR

smithbk (Wed, 21 Feb 2018 14:14:37 GMT):
2) Is this all that needs to be changed? I assume I'd need to add tests also. Where would those go?

benjsmi (Wed, 21 Feb 2018 16:47:16 GMT):
Has joined the channel.

jcnauta (Thu, 22 Feb 2018 15:54:53 GMT):
Has joined the channel.

jankokrstic (Thu, 22 Feb 2018 16:57:28 GMT):
Has joined the channel.

peacekeeper (Mon, 26 Feb 2018 11:50:12 GMT):
Can a pool consisting of only 2 nodes be stable, or what's the minimum number of nodes?

ashcherbakov (Mon, 26 Feb 2018 12:36:31 GMT):
@peacekeeper As the number of nodes in the pool is 3f+1, the minimum number of nodes for a functional pool should be 4 (f=1 in this case). One can consider having a pool of, for example, 3 nodes, but f=0 in this case, so the system will not be able to survive if at least one malicious node appears.

ashcherbakov (Mon, 26 Feb 2018 12:46:15 GMT):
@smithbk 1) I think it would be great and really appreciated if you raise a PR with supervisord support. The only thing is that we should still keep systemctl support as our current builds are based on this. 2) You will also need to extend the build procedure which assumes using of systemd. Have a look at `build-scripts/ubuntu-1604/postinst_node` You can grep by `systemd`. Unfortunately, we don't have automated tests for this yet.

smithbk (Mon, 26 Feb 2018 20:34:01 GMT):
ok, will do ... thanks

sergey.khoroshavin (Tue, 27 Feb 2018 10:22:36 GMT):
Has joined the channel.

seth (Wed, 28 Feb 2018 03:26:34 GMT):
Has joined the channel.

SergeyPalamarchuk (Wed, 28 Feb 2018 08:00:16 GMT):
Has joined the channel.

Vincent (Wed, 28 Feb 2018 09:38:07 GMT):
Has joined the channel.

smithbk (Wed, 28 Feb 2018 14:56:23 GMT):
I have a docker image which does an `init_indy_node` and `start_indy_node` for startup where `/var/lib/indy` is persistent storage. If the docker image is stopped and restarted, as long as I pass in the SEED arg to `init_indy_node`, it appears to work correctly across restarts. But I want to make sure there aren't any caveats or issues with the re-execution of `init_indy_node`. Can someone affirm or correct me here?

smithbk (Wed, 28 Feb 2018 14:56:23 GMT):
I have a docker image which does an `init_indy_node` and `start_indy_node` for startup where `/var/lib/indy` is persistent storage. If the docker image is stopped and restarted, as long as I pass in the same SEED arg to `init_indy_node`, it appears to work correctly across restarts. But I want to make sure there aren't any caveats or issues with the re-execution of `init_indy_node`. Can someone affirm or correct me here?

smithbk (Wed, 28 Feb 2018 14:56:23 GMT):
@nage I have a docker image which does an `init_indy_node` and `start_indy_node` for startup where `/var/lib/indy` is persistent storage. If the docker image is stopped and restarted, as long as I pass in the same SEED arg to `init_indy_node`, it appears to work correctly across restarts. But I want to make sure there aren't any caveats or issues with the re-execution of `init_indy_node`. Can someone affirm or correct me here?

smithbk (Wed, 28 Feb 2018 14:56:23 GMT):
@nage @ashcherbakov I have a docker image which does an `init_indy_node` and `start_indy_node` for startup where `/var/lib/indy` is persistent storage. If the docker image is stopped and restarted, as long as I pass in the same SEED arg to `init_indy_node`, it appears to work correctly across restarts. But I want to make sure there aren't any caveats or issues with the re-execution of `init_indy_node`. Can someone affirm or correct me here?

mboyd (Wed, 28 Feb 2018 17:00:14 GMT):
Has joined the channel.

lcinacio (Thu, 01 Mar 2018 08:18:03 GMT):
Has joined the channel.

smithbk (Fri, 02 Mar 2018 04:25:38 GMT):
@ashcherbakov See https://github.com/hyperledger/indy-node/pull/588 for adding supervisord support

ashcherbakov (Fri, 02 Mar 2018 08:23:15 GMT):
@smithbk Thank you. @andkononykhin is going to review the PR.

wangdong (Sun, 04 Mar 2018 06:11:03 GMT):
I got some errors when I run the test cases of indy-client indy-sdk indy-plenum. I wonder how can I present them to you guys for some help? I got the test log and is it OK?

hidde-jan (Mon, 05 Mar 2018 13:50:16 GMT):
Hi all, I'm just looking at some inspiration for monitoring a indy node's performance. Are there any examples/ideas out there, like how many transactions in the past hour/current transaction number, etc?

hidde-jan (Mon, 05 Mar 2018 13:50:59 GMT):
Maybe some people actually integrated these things in their own logging/monitoring setup?

hidde-jan (Mon, 05 Mar 2018 14:20:28 GMT):
I notices the _info.json in /var/lib/indy, that seems handy, any other metrics that the node spits out?

ashcherbakov (Mon, 05 Mar 2018 14:58:48 GMT):
@hidde-jan You may be interested in `validator-info` tool based on `_info.json ` results. The tool already provides some performance info (from the `monitor.py` module). And we are expecting to extend it with more info provided (see https://github.com/hyperledger/indy-node/blob/master/design/validator_info.md)

hidde-jan (Mon, 05 Mar 2018 15:00:42 GMT):
@ashcherbakov thanks!

mspatel (Mon, 05 Mar 2018 16:02:23 GMT):
Has joined the channel.

benjsmi (Mon, 05 Mar 2018 20:13:15 GMT):
anybody know of a rocket chat channel related to permitify or the org book?

ianco (Mon, 05 Mar 2018 20:34:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=mqncuWzYGNmkW5qyX) @benjsmi not on RocketChat, tagging @jljordan_bcgov @swcurran

olegwb (Wed, 07 Mar 2018 09:02:36 GMT):
Has joined the channel.

wolili (Wed, 07 Mar 2018 17:24:09 GMT):
Hi, I would like to write a custom function foo in indy-node, for example in node.py where I use other functions of indy and process them. I would like to write a testcase which uses this function in different Nodes. Simplified the test should like: `n1 = Node1() n2 = Node2() n3 = Node3() n1.foo() n2.foo() n3.foo()` This might sound trivial, but how do I correctly initialize nodes or how would a constructor look like? Is there some existing test case that is doing this, where I could take a look at?

wolili (Wed, 07 Mar 2018 17:24:09 GMT):
Hi, I would like to write a custom function foo in indy-node, for example in node.py where I use other functions of indy and process them. I would like to write a testcase which uses this function in different Nodes. Simplified the test should like: ``` n1 = Node1() n2 = Node2() n3 = Node3() n1.foo() n2.foo() n3.foo() ``` This might sound trivial, but how do I correctly initialize nodes or how would a constructor look like? Is there some existing test case that is doing this, where I could take a look at?

smithbk (Wed, 07 Mar 2018 20:48:34 GMT):
I have 4 test nodes and want to stop them all at the same time and restart without losing what is on the ledger. Can someone tell me how to do this? Thanks

creatornader (Wed, 07 Mar 2018 23:00:03 GMT):
Has joined the channel.

ArthurManz (Thu, 08 Mar 2018 10:03:05 GMT):
Has joined the channel.

rado0x54 (Thu, 08 Mar 2018 18:58:06 GMT):
Has joined the channel.

ashcherbakov (Mon, 12 Mar 2018 11:02:57 GMT):
@smithbk The data on the ledger is persisted, so it will not be lost. You can just restart the services on all nodes (systemctl restart indy-node), or stop and start them (systemctl stop indy-node; systemctl start indy-node). Unfortunately, there is no automated way to do it at the exact same time on all nodes, but I think a script can be created for this. Also we have plans to support `restart` command that can restart the whole pool at the specified time. If you are talking about tests, then you can see an example of the pool restart in `test_primary_selection_after_primary_demotion_and_pool_restart` test (please note that TestNode instances are used in all tests, and all (test) nodes are started and run at the same process).

ashcherbakov (Mon, 12 Mar 2018 11:09:36 GMT):
@wolili What is your test case? Why do you need to implement a new function in `node.py`? Please note, that plugins are supported, so probably it's better to use plugins for your case. You can have a look at `https://github.com/hyperledger/indy-plenum/blob/master/docs/plugins.md` and `plenum/test/plugin/demo_plugin` As for existing tests, usually an instance of `TestNode` is used there. All nodes in the pool are started and run at the same process in integration tests (see plenum/tests). You can have a look at `txnPoolNodeSet` fixture (and `create_new_test_node` helper method) where a pool of TestNodes is created, and just use this fixture (or a similar one) in your tests.

p6g (Mon, 12 Mar 2018 12:30:30 GMT):
Has joined the channel.

jljordan_bcgov (Wed, 14 Mar 2018 03:31:58 GMT):
@benjsmi we don't have a specific channel for that ... is there something we can help with? sorry for the late reply ...

jljordan_bcgov (Wed, 14 Mar 2018 03:31:58 GMT):
@benjsmi we don't have a specific channel for that ... is there something we can help with?

carter.willetts (Wed, 14 Mar 2018 18:38:54 GMT):
Has joined the channel.

carter.willetts (Wed, 14 Mar 2018 18:40:40 GMT):
Hi All - I am attempting to create an Indy Node test network but I am having trouble connecting the sandbox

carter.willetts (Wed, 14 Mar 2018 18:40:54 GMT):
Can someone offer me some troubleshooting guidance?

ashcherbakov (Thu, 15 Mar 2018 08:25:56 GMT):
Hi @carter.willetts. Did you try to use Docker from https://github.com/hyperledger/indy-node/tree/master/environment/docker/pool?

ashcherbakov (Thu, 15 Mar 2018 08:25:56 GMT):
Hi @carter.willetts . Did you try to use Docker from https://github.com/hyperledger/indy-node/tree/master/environment/docker/pool?

Sean_Bohan (Thu, 15 Mar 2018 14:24:42 GMT):
TODAY we have the Indy Ledger WG Call for Thursday Mar 15, 2018 Agenda: A. Housekeeping (Sean) B. Development Achievements (Alex and Slava) C. Rebooting Web of Trust Recap (Nathan and Kyle) D. Open Discussion E. Wrap Up Please note: This meeting will be recorded Bring a friend. It will be fun. Call details: Hyperledger Indy Ledger (Node) WG Call When: Mar 15, 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 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

Sean_Bohan (Thu, 15 Mar 2018 14:24:42 GMT):
TODAY we have the Indy Ledger WG Call for Thursday Mar 15, 2018 Agenda: A. Housekeeping (Sean) B. Development Achievements (Alex and Slava) C. Rebooting Web of Trust Recap (Nathan and Kyle) D. Open Discussion E. Wrap Up Please note: This meeting will be recorded Bring a friend. It will be fun. Call details: Hyperledger Indy Agent (SDK) WG Call When: Mar 15, 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 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

eramitg (Thu, 15 Mar 2018 15:10:12 GMT):
Has joined the channel.

ashcherbakov (Thu, 15 Mar 2018 15:18:14 GMT):
PR with transactions and requests refactoring: https://github.com/hyperledger/indy-node/pull/536

jljordan_bcgov (Thu, 15 Mar 2018 15:28:40 GMT):
https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018

jljordan_bcgov (Thu, 15 Mar 2018 15:29:01 GMT):
here are the papers @nage is referring to

jljordan_bcgov (Thu, 15 Mar 2018 15:29:21 GMT):
Main website for Rebooting Web of Trust is http://www.weboftrust.info

jljordan_bcgov (Thu, 15 Mar 2018 15:32:46 GMT):
DID Auth Draft https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/draft-documents/did_auth_draft.md ID Hub Flows https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/draft-documents/Identity%20Hub%20Attestation%20Handling.md

jljordan_bcgov (Thu, 15 Mar 2018 15:32:59 GMT):
TLS Flex https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/draft-documents/TLS-Flex.md

nage (Thu, 15 Mar 2018 15:33:37 GMT):
The google doc for the Variable Length Attribute Based Credentials paper where you can comment and collaborate https://docs.google.com/document/d/1njvX4U7Q-2trvqrTZQQynSCgU3JgxDLXESvb34hYhI0/edit?usp=sharing

jljordan_bcgov (Thu, 15 Mar 2018 15:33:40 GMT):
Comments, PRs Welcome!

nage (Thu, 15 Mar 2018 15:34:15 GMT):
Note: some of these papers are intended to be standards track, and you might be asked to join the W3C Credentials CG (or similar) before contributing.

nage (Thu, 15 Mar 2018 15:34:23 GMT):
(for IPR requirements)

nage (Thu, 15 Mar 2018 15:36:11 GMT):
More DIF stuff here https://github.com/decentralized-identity

carter.willetts (Thu, 15 Mar 2018 16:34:23 GMT):
Hi @ashcherbakov, I was using the VirtualBox and Vagrant guide

carter.willetts (Thu, 15 Mar 2018 16:34:51 GMT):
Would using the Docker be better for me?

mboyd (Thu, 15 Mar 2018 16:49:50 GMT):
@carter.willetts Hi, I'm about to start through the VB and vagrant guide this morning. I just successfully went through the getting started guide using the local test network solution. If you already have virtual box installed, I would recommend that you set up a fresh Ubuntu 16.04 instance with virtual box, then get indy running locally in that instance. It went very smoothly for me when I did that. (https://github.com/hyperledger/indy-node/blob/master/docs/indy-running-locally.md)

carter.willetts (Thu, 15 Mar 2018 16:55:15 GMT):
@mboyd Hi there, I will go ahead and attempt this with the local solution too - I will let you know how it goes

mboyd (Thu, 15 Mar 2018 17:27:58 GMT):
I'm looking at how to set up and run a simulation of indy cluster and agents documented here: https://github.com/hyperledger/indy-node/blob/master/docs/cluster-simulation.md. when I try to install indy-client using pip, via the command `pip install -U --no-cache-dir indy-client` I'm told that there is no matching distribution found for indy-client. I have the full dev environment set up on Ubuntu, does anyone know if I'm doing this wrong, or is the page deprecated?

ashcherbakov (Fri, 16 Mar 2018 07:35:50 GMT):
@mboyd @carter.willetts It looks like `cluster-simulation.md` is an outdated document. We don't support indy-client now. The getting started from indy-node repo is also going to be deprecated (since it's based on the old unsupported client). The new Getting started was created based on libindy: https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md

carter.willetts (Fri, 16 Mar 2018 16:01:22 GMT):
@ashcherbakov I am having some problems attaching the agents to the cluster on the local tutorial ( https://github.com/hyperledger/indy-node/blob/master/docs/indy-running-locally.md ) is this file also deprecated?

ashcherbakov (Fri, 16 Mar 2018 16:02:20 GMT):
@carter.willetts It may be not deprecated, but this is no the intended way to have a local pool. Please use either Docker or Vagrant.

ashcherbakov (Fri, 16 Mar 2018 16:11:10 GMT):
We are going to fix our documentation to say it explicitly.

carter.willetts (Fri, 16 Mar 2018 16:41:34 GMT):
@ashcherbakov I ran through the VM and Vagrant setup previously and had problems connecting to the sandbox

ashcherbakov (Fri, 16 Mar 2018 16:41:53 GMT):
Did you use the master version?

carter.willetts (Fri, 16 Mar 2018 16:42:40 GMT):
I followed thi s

carter.willetts (Fri, 16 Mar 2018 16:42:42 GMT):
https://github.com/hyperledger/indy-node/blob/stable/environment/vagrant/training/vb-multi-vm/TestIndyClusterSetup.md

carter.willetts (Fri, 16 Mar 2018 16:43:04 GMT):
when I get down the section entitled 'Setting Up a CLI Client and Configuring the Agents in the Indy Cluster'

carter.willetts (Fri, 16 Mar 2018 16:43:27 GMT):
and attempt to connect to sandbox, it returns no environment called sandbox etc etc

ashcherbakov (Fri, 16 Mar 2018 16:53:37 GMT):
Is it the same for https://github.com/hyperledger/indy-node/blob/master/environment/vagrant/training/vb-multi-vm/TestIndyClusterSetup.md?

ashcherbakov (Fri, 16 Mar 2018 16:56:56 GMT):
Looks like it's the same

ashcherbakov (Fri, 16 Mar 2018 17:21:12 GMT):
ok, so this is a bug, we are going to fix it this sprint. There is a workaround for now: https://forum.sovrin.org/t/error-when-running-vagrant-up/582

ozheregelya (Fri, 16 Mar 2018 18:11:01 GMT):
Has joined the channel.

carter.willetts (Sat, 17 Mar 2018 03:36:20 GMT):
@ashcherbakov great thank you!

trthhrtz (Sun, 18 Mar 2018 06:37:59 GMT):
Has joined the channel.

dinesh.rivankar (Mon, 19 Mar 2018 08:40:11 GMT):
Has joined the channel.

ShikarSharma (Tue, 20 Mar 2018 22:48:37 GMT):
Has joined the channel.

ashcherbakov (Wed, 21 Mar 2018 12:56:07 GMT):
ok, great, thanks!

bafonins (Wed, 21 Mar 2018 13:30:10 GMT):
Has joined the channel.

the_identity_guy (Wed, 21 Mar 2018 16:14:29 GMT):
Is there any research or discussion around whether all DIDs should be registered on the shared ledger and its affect on the performance of the network?

ManMinster (Thu, 22 Mar 2018 09:08:08 GMT):
Has joined the channel.

ydennisy (Thu, 22 Mar 2018 13:32:46 GMT):
Has joined the channel.

matthewehoward (Thu, 22 Mar 2018 22:17:48 GMT):
Has joined the channel.

BryanSparks (Fri, 23 Mar 2018 13:59:10 GMT):
Has joined the channel.

hkrichen (Sat, 24 Mar 2018 08:42:34 GMT):
Has joined the channel.

wangdong (Mon, 26 Mar 2018 03:17:51 GMT):
I saw in the building script the rocksdb is used as a third party dependency. I wonder if the leveldb has been replaced. But the node in plenum is not completed as I found.

wangdong (Mon, 26 Mar 2018 03:18:06 GMT):
So now the leveldb is still in use, right

ashcherbakov (Mon, 26 Mar 2018 12:59:58 GMT):
@wangdong We are planning to migrate to rocksdb. It will be done only after notification, so don't worry. As of now leveld is still going to be used (at least for the next stable release). Rocksdb will be used just for one storage needed for revocation support. We are planning to migrate to rocksdb together with other breaking (non-backward compatible) changes, such as changes of requests and transactions format.

wangdong (Mon, 26 Mar 2018 13:06:43 GMT):
ok, thanks

nage (Wed, 28 Mar 2018 15:49:13 GMT):
Development discussion and questions about the master branch of indy-node, including the indy-node and plenum code bases.

wolili (Thu, 29 Mar 2018 09:17:39 GMT):
I tried to use the plugin structure for plenum. I took a look at "demo_plugin" and ran the tests. When sdk_get_reply() is called the result is the following: `: ({'identifier': 'MSjKTWkPLtYoPEaTF1TUDb', 'signature': '4qhfFzyBtWoQjQ3PkF3QLopvPLLRsVgaNTMqSws5uzFLD2xj7XhvtagCY5YK42yWSCJXJMbWFeCwSftzXxemm1sp', 'protocolVersion': 1, 'reqId': 16175, 'operation': {'data': {'amount': 20, 'id': 'abc'}, 'type': '99992'}}, {'result': {'identifier': 'MSjKTWkPLtYoPEaTF1TUDb', 'signatures': None, 'type': '99992', 'signature': '4qhfFzyBtWoQjQ3PkF3QLopvPLLRsVgaNTMqSws5uzFLD2xj7XhvtagCY5YK42yWSCJXJMbWFeCwSftzXxemm1sp', 'seqNo': 2, 'rootHash': '85ak6icH4YJfpLBJy8KVKofD2gvwfiK1DbvGyBnCLde4', 'txnTime': 1522309945, 'reqId': 16175, 'data': {'amount': 20, 'id': 'abc'}, 'auditPath': ['BvgckVXbuuPzJDmrSnBAFFWPSDD4NHP9EerVfgY5Xkek']}, 'op': 'REPLY'})`

wolili (Thu, 29 Mar 2018 09:17:39 GMT):
I tried to use the plugin structure for plenum. I took a look at "demo_plugin" and ran the tests. When sdk_get_reply() is called the result is the following: `: ({'identifier': 'MSjKTWkPLtYoPEaTF1TUDb', 'signature': '4qhfFzyBtWoQjQ3PkF3QLopvPLLRsVgaNTMqSws5uzFLD2xj7XhvtagCY5YK42yWSCJXJMbWFeCwSftzXxemm1sp', 'protocolVersion': 1, 'reqId': 16175, 'operation': {'data': {'amount': 20, 'id': 'abc'}, 'type': '99992'}}, {'result': {'identifier': 'MSjKTWkPLtYoPEaTF1TUDb', 'signatures': None, 'type': '99992', 'signature': '4qhfFzyBtWoQjQ3PkF3QLopvPLLRsVgaNTMqSws5uzFLD2xj7XhvtagCY5YK42yWSCJXJMbWFeCwSftzXxemm1sp', 'seqNo': 2, 'rootHash': '85ak6icH4YJfpLBJy8KVKofD2gvwfiK1DbvGyBnCLde4', 'txnTime': 1522309945, 'reqId': 16175, 'data': {'amount': 20, 'id': 'abc'}, 'auditPath': ['BvgckVXbuuPzJDmrSnBAFFWPSDD4NHP9EerVfgY5Xkek']}, 'op': 'REPLY'})` Of whom is the "signature" entry (steward, agend, primary, replica?)? Why is the "signatures" entry "null"? Shouldn't a user receiving the reply know who validated the request?

ashcherbakov (Thu, 29 Mar 2018 13:04:49 GMT):
@wolili The current implementation has two fields `signatures` (if we use multi-signature approach) and `signature` if there is just one signature expected. This is quite ugly and will be re-factored soon. Please have a look at the proposal in https://github.com/hyperledger/indy-node/blob/87e363462bb9c93861e413fe02f935e851a1c10a/docs/requests.md#signed-message-structure

ashcherbakov (Thu, 29 Mar 2018 13:05:34 GMT):
So, in the current implementation we may have either `signatures` or `signature`, but not both. In the proposal there will be just one signature field

wolili (Fri, 30 Mar 2018 08:37:43 GMT):
@ashcherbakov thank you for your reply. The proposal looks interesting. Just for clarification: The "signature" is created by the "Submitter" (client) or by the "Processer" (node) of the request?

wolili (Fri, 30 Mar 2018 08:37:43 GMT):
@ashcherbakov thank you for your reply. The proposal looks interesting. Just for clarification: The "signature" is created by the "Submitter" (client) of the request or by the node(s) who have processed the request?

ashcherbakov (Fri, 30 Mar 2018 08:44:34 GMT):
@wolili By the Submitter (Client). BTW A Node may also play the role of a client and be a Submitter (see NODE_UPGRADE txn) There are also BLS multi-signatures set by nodes. They are present in Replies to Requests.

wolili (Fri, 30 Mar 2018 08:56:02 GMT):
@ashcherbakov Ok, how can you see/enable multi-signatures in replies, because the code from above doesn't have them...

ashcherbakov (Fri, 30 Mar 2018 09:07:40 GMT):
What do you mean by multi-signatures in Replies? BLS multi-signature? As of now this is just one signature (one value), but this is multi-signature because this is multiplication of signatures from all nodes.

wolili (Fri, 30 Mar 2018 09:13:54 GMT):
Assume I would like to write on the ledger, I will make a write request to some node. When I receive a reply I would like to know which node(s) have processed my request and created the reply. My reply: `{'result': {'identifier': 'MSjKTWkPLtYoPEaTF1TUDb', 'signatures': None, 'type': '99992', 'signature': '4qhfFzyBtWoQjQ3PkF3QLopvPLLRsVgaNTMqSws5uzFLD2xj7XhvtagCY5YK42yWSCJXJMbWFeCwSftzXxemm1sp', 'seqNo': 2, 'rootHash': '85ak6icH4YJfpLBJy8KVKofD2gvwfiK1DbvGyBnCLde4', 'txnTime': 1522309945, 'reqId': 16175, 'data': {'amount': 20, 'id': 'abc'}, 'auditPath': ['BvgckVXbuuPzJDmrSnBAFFWPSDD4NHP9EerVfgY5Xkek']}, 'op': 'REPLY'}` I took a look at this json: you told me that the signature in there is from me (the submitter of the request), so where is the signature from the node(s)?

wolili (Fri, 30 Mar 2018 09:13:54 GMT):
Assume I would like to write on the ledger, I will make a write request to some node. When I receive a reply I would like to know which node(s) have processed my request and created the reply. My reply: `{'result': {'identifier': 'MSjKTWkPLtYoPEaTF1TUDb', 'signatures': None, 'type': '99992', 'signature': '4qhfFzyBtWoQjQ3PkF3QLopvPLLRsVgaNTMqSws5uzFLD2xj7XhvtagCY5YK42yWSCJXJMbWFeCwSftzXxemm1sp', 'seqNo': 2, 'rootHash': '85ak6icH4YJfpLBJy8KVKofD2gvwfiK1DbvGyBnCLde4', 'txnTime': 1522309945, 'reqId': 16175, 'data': {'amount': 20, 'id': 'abc'}, 'auditPath': ['BvgckVXbuuPzJDmrSnBAFFWPSDD4NHP9EerVfgY5Xkek']}, 'op': 'REPLY'}` I took a look at this json: you told me that the signature in there is from me (the submitter of the request), so where is the signature from the node(s) in this reply?

MikeCohen (Fri, 30 Mar 2018 18:52:55 GMT):
Has joined the channel.

dinesh.rivankar (Mon, 02 Apr 2018 11:31:21 GMT):
Has left the channel.

hcsatish (Wed, 04 Apr 2018 17:17:44 GMT):
Has joined the channel.

nuxibyte_old (Thu, 05 Apr 2018 22:54:34 GMT):
Has left the channel.

stevenmilstein (Fri, 06 Apr 2018 16:53:16 GMT):
Has joined the channel.

Dan (Fri, 06 Apr 2018 18:00:31 GMT):
Has joined the channel.

kosullivan_sita (Mon, 09 Apr 2018 12:05:21 GMT):
Has joined the channel.

esplinr (Mon, 09 Apr 2018 22:35:34 GMT):
Has joined the channel.

SanketPanchamia (Wed, 11 Apr 2018 11:33:39 GMT):
Has joined the channel.

eramitg (Wed, 11 Apr 2018 15:39:19 GMT):
Hi Folks , I am an Phd Candidate in www.nitrr.ac.in my Linkedind Profile is https://www.linkedin.com/in/eramitg/ for sake of earning an Phd Degree i was proposed Blockchain Technology research work area to my guide so oom I request all of you gyus ,please guide me and assign me some research oriented task so that we mutullay benifited research related to Hyperledger Umbrella Project , All of you feel free to catch me on twitter or skype to https://twitter.com/eramitg1 or amitg.iitb skype id also in Zoom to in Zoom ID 3649222703 or whatsapp +917773011100 Regards

eramitg (Wed, 11 Apr 2018 15:39:19 GMT):
Hi Folks , I am an Phd Candidate in www.nitrr.ac.in my Linkedin Profile is https://www.linkedin.com/in/eramitg/ for sake of earning an Phd Degree i was proposed Blockchain Technology research work area to my guide so I request all of you guys ,please guide me and assign me some research oriented task so that we mutually benefited research related to Hyperledger Umbrella Project , All of you feel free to catch me on twitter or skype to https://twitter.com/eramitg1 or amitg.iitb skype id also in Zoom to in Zoom ID 3649222703 or whatsapp +917773011100 Regards Amit

MyMate (Thu, 12 Apr 2018 09:26:59 GMT):
Has joined the channel.

SanketPanchamia (Fri, 13 Apr 2018 11:42:27 GMT):
Hi, I am following the dev tutorial to setup indy on my local system and was on step 2 that says this *set Network name in config file* the location of the config depends on how a Node was installed. It's usually inside /etc/indy for Ubuntu. the following needs to be added: NETWORK_NAME={network_name} where {network_name} matches the one in genesis transaction files above I am no sure how to give this network name because i cannot initialize a node without a network name. Am i missing something?

the_identity_guy (Sun, 15 Apr 2018 17:26:12 GMT):
Is there a reason the getting started guides support 4 nodes by default? is there a mandatory minimum (or maximum) number of running nodes for proper operation?

SanketPanchamia (Mon, 16 Apr 2018 04:12:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=pKLG84QWnhTPKJbhF) Any ideas will be appreciated

SanketPanchamia (Mon, 16 Apr 2018 04:28:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=Ah8bxwwnyPyxAHHWb) I even tried with "sandbox" but i get this error NETWORK_NAME = sandbox NameError: name 'sandbox' is not defined Environment setup complete

ryanwest6 (Tue, 17 Apr 2018 01:40:01 GMT):
Has joined the channel.

Mahmic404 (Tue, 17 Apr 2018 14:35:36 GMT):
Has joined the channel.

lebdron (Tue, 17 Apr 2018 15:43:51 GMT):
Has joined the channel.

swcurran (Tue, 17 Apr 2018 20:44:13 GMT):
@the_identity_guy - the minimum number of nodes is 4. The plenum protocol requires that many nodes to operate. The maximum number of nodes can go up significantly (not sure how high), but will have a configured maximum. As I understand it, the HL-Indy approach is to have configure Sovrin to have a maximum number of writer nodes, have the rest of the Stewards operate as observer nodes and have observer nodes become writer nodes to maintain a sufficient number of nodes. Any of the nodes can be used for reading.

the_identity_guy (Tue, 17 Apr 2018 20:49:54 GMT):
@swcurran thank you!, after reading the Plenum and RBFT consensus docs I realized the consensus supports 3f+1 = n nodes with f faulty nodes .. i.e. if n is anything less than 4, no faulty nodes can be supported. to support 1 faulty node we need 3(1) + 1 = 4 nodes

neewy (Thu, 19 Apr 2018 08:17:58 GMT):
Has joined the channel.

mhomaid (Thu, 19 Apr 2018 16:10:43 GMT):
Has joined the channel.

Steve-Boyd (Thu, 19 Apr 2018 20:16:16 GMT):
Has joined the channel.

troyronda (Fri, 20 Apr 2018 17:58:52 GMT):
Has joined the channel.

kyogesh91 (Sat, 21 Apr 2018 20:12:25 GMT):
Has joined the channel.

kyogesh91 (Sat, 21 Apr 2018 20:14:13 GMT):

Screenshot from 2018-04-21 16-13-26.png

kyogesh91 (Sat, 21 Apr 2018 20:14:51 GMT):
any idea what would be the reason for this error?

jaredhanson (Mon, 23 Apr 2018 02:02:58 GMT):
Has joined the channel.

Kelattar (Mon, 23 Apr 2018 07:38:30 GMT):
Has joined the channel.

KitHat (Mon, 23 Apr 2018 08:52:54 GMT):
Has joined the channel.

musquash (Mon, 23 Apr 2018 11:35:37 GMT):
Has joined the channel.

StevenCotes (Mon, 23 Apr 2018 20:26:51 GMT):
Has joined the channel.

Toktar (Tue, 24 Apr 2018 08:06:12 GMT):
Has joined the channel.

Dan (Wed, 25 Apr 2018 13:25:40 GMT):
@nage (Not sure Lovesh's handle) Adam is going to go over the new consensus API at the sawtooth tech forum tomorrow. I think that meeting normally conflicts with an Indy meeting. If Lavesh or others can make it, though, I think they would find it interesting and I would also love to hear their feedback.

Dan (Wed, 25 Apr 2018 13:25:40 GMT):
@nage (Not sure Lavesh's handle) Adam is going to go over the new consensus API at the sawtooth tech forum tomorrow. I think that meeting normally conflicts with an Indy meeting. If Lavesh or others can make it, though, I think they would find it interesting and I would also love to hear their feedback.

nage (Wed, 25 Apr 2018 13:27:28 GMT):
@lovesh ^^^. What time is the meeting? (If I remember right it is at the same time as the Indy developer call)

Dan (Wed, 25 Apr 2018 13:37:34 GMT):
Lemme know if this link works or not: https://www.google.com/calendar/event?eid=Y3RqdjgwMTltMTVrOGkwZmdmdDZvaG1xN2NfMjAxODA0MjZUMTUwMDAwWiBsaW51eGZvdW5kYXRpb24ub3JnX25mOXU2NGc5azlydmQ5Zjh2cDR2dXIyM2IwQGc&ctz=UTC

jackson18 (Wed, 25 Apr 2018 19:58:32 GMT):
Has joined the channel.

NihadOgresevic (Thu, 26 Apr 2018 15:30:51 GMT):
Has joined the channel.

mbwhite (Mon, 30 Apr 2018 13:25:35 GMT):
Has joined the channel.

nuxibyte (Tue, 01 May 2018 16:50:10 GMT):
Has joined the channel.

AnhDung (Wed, 02 May 2018 13:29:45 GMT):
Has joined the channel.

AnhDung (Wed, 02 May 2018 13:54:09 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!

swcurran (Wed, 02 May 2018 16:32:46 GMT):
@AnhDung - that will be related to a recent upgrade of the base58 library. You can search back in RocketChat for references from real developers (I just pretend :-) ). I'll see if I can find a related commit that might help from our project.

swcurran (Wed, 02 May 2018 16:40:49 GMT):
I think you need to lock down base58 as follows - base58==0.2.5 - until the libindy is update to reflect the change in base58. @WadeBarnes - can you confirm/help?

SteveGoob (Wed, 02 May 2018 19:42:49 GMT):
Has joined the channel.

danielhardman (Wed, 02 May 2018 22:10:55 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

AnhDung (Thu, 03 May 2018 08:10:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=fBegnPzeECsCQdScg) @swcurran hi, it is working, I've locked to base58==0.2.5 and reinstall the indy-dev-node package, works like charm, thanks for the help :D

samadsajanlal (Fri, 04 May 2018 19:34:05 GMT):
Has joined the channel.

vidor (Mon, 07 May 2018 23:56:24 GMT):
Has joined the channel.

guido.santos (Wed, 09 May 2018 14:05:43 GMT):
Has joined the channel.

nhelmy (Thu, 10 May 2018 07:42:12 GMT):
Has joined the channel.

LuisMarado (Thu, 10 May 2018 10:00:49 GMT):
Has joined the channel.

danielhardman (Thu, 10 May 2018 15:29:10 GMT):
@esplinr Do you have any logging tickets in the current indy-node sprint that I could volunteer for?

esplinr (Thu, 10 May 2018 20:18:05 GMT):
@danielhardman The issue in the current sprint is probably under control: We are adding a specific message requested by Evernym Customer Success to flag when transactions are not added: INDY-1274. I think this one is under control. But there are a number of issues not in the current sprint that would be useful for you to provide some direction on how best to proceed: * We need to create an issue with a plan for addressing the underlying performance concern found in Olga's benchmarking * INDY-1311: Review log messages to ensure that they are emitted at the correct log level. Currently too much is at INFO level. * INDY-1300 is a simple task requested by Evernym customer success.

esplinr (Thu, 10 May 2018 20:18:23 GMT):
@ashcherbakov will probably have more ideas when he returns to work in the morning.

ashcherbakov (Fri, 11 May 2018 08:59:09 GMT):
Yes, INDY-1311 is the one that we need to address.

LuisMarado (Fri, 11 May 2018 10:40:36 GMT):
Hi everyone, I'm trying to configure a network on a Ubuntu 16.04 as described at https://github.com/hyperledger/indy-node/blob/master/docs/start-nodes.md. What I'm getting is some dependency issues between indy-plenum and python3-indy-crypto

LuisMarado (Fri, 11 May 2018 10:40:36 GMT):
Hi everyone, I'm trying to configure a network on a Ubuntu 16.04 as described at https://github.com/hyperledger/indy-node/blob/master/docs/start-nodes.md. What I'm getting is some dependency issues between indy-plenum and python3-indy-crypto. I may try to manually solve them, but would basically like to share the experience while doing this instantiation.

LuisMarado (Fri, 11 May 2018 10:43:20 GMT):
The following packages have unmet dependencies: indy-plenum : Depends: python3-indy-crypto (= 0.4.0) but 0.4.1 is to be installed

LuisMarado (Fri, 11 May 2018 10:47:50 GMT):
with the as is to install it without issues would just need to do a manual installation of that package and everything else installs normally (apt-get install python3-indy-crypto=0.4.0)

LuisMarado (Fri, 11 May 2018 10:47:50 GMT):
with the as is, to install it without issues would just need to do a manual installation of that package and everything else installs normally (apt-get install python3-indy-crypto=0.4.0)

jastisriradheshyam (Mon, 14 May 2018 05:24:56 GMT):
Has joined the channel.

ashcherbakov (Mon, 14 May 2018 06:40:21 GMT):
@LuisMarado The problem with the dependency is fixed now, it was a bug.

kevin.chan (Tue, 15 May 2018 00:31:37 GMT):
Has joined the channel.

swcurran (Thu, 17 May 2018 17:14:14 GMT):
@esplinr - per the discussion today on the Indy call - here is the repo for our indy images that we use for running a test network set of nodes and to embed in the agents we are developing for VON based on the indy-sdk python wrapper. https://github.com/PSPC-SPAC-buyandsell/von-image Variations on the images are published to hub.docker.com at: https://hub.docker.com/r/bcgovimages/von-image/

esplinr (Thu, 17 May 2018 17:23:55 GMT):
Thank you!

ryanwest6 (Thu, 17 May 2018 18:52:43 GMT):
cannot import name 'Replica'

ryanwest6 (Thu, 17 May 2018 19:12:01 GMT):
I'd post this in an indy-plenum channel but looks like this is the closest I've got. I'm trying to run the indy-plenum unit tests using PyCharm and I get 3 errors like this: "ImportError: cannot import name 'Replica'", one of these in the file indy-plenum/plenum/server/primary_selector.py (line is "from plenum.server.replica import Replica"). But the python file replica.py is definitely there, as is its class, Replica. There are no other import issues (the previous line, 'from plenum.server.primary_decider import PrimaryDecider', works just fine) and I'm on master. Has anyone else experienced anything like this?

ashcherbakov (Fri, 18 May 2018 07:44:51 GMT):
@ryanwest6 Did you follow https://github.com/hyperledger/indy-node/blob/master/docs/setup-dev.md to start working with plenum from PyCharm?

wolili (Fri, 18 May 2018 08:28:53 GMT):
Hi everyone, I created a plugin in plenum. I created testcases which do read and write requests. Everything works with little code using the TestNodes and pytests - which is pretty cool, respect to you guys. For a Proof of Concept I would like to use my plugin not only with the pytests, but also with a local pool (docker-setup) that I could connect to my Indy-SDK. I have seen in indy-sdk/ci/indy-pool.dockerfile that indy-plenum is installed using a deb package. So my current approach would be to create a deb package from my local plenum and manually install it in the docker instead of the original deb package. Is this possible, are there better options? Any recommendations, thoughts, experiences, ideas are highly appreciated! Thanks

ashcherbakov (Fri, 18 May 2018 12:37:38 GMT):
@wolili I think the idea of a plugin is that you can extend plenum without changing existing builds, so probably you can just copy your plugin into appropriate folders (or create a deb package for the plugin or some installation script that can make the copy)

ryanwest6 (Sun, 20 May 2018 18:10:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=2nzhrJCLpsCW4tkii) @ashcherbakov I did not. I am attempting to run the plenum on its own (not using anything from the indy-node repo) and get all of its tests passing before cloning indy-node and trying to run it on top of indy-plenum. I'm using the installation and dependencies found on https://github.com/hyperledger/indy-plenum/README.md.

ashcherbakov (Mon, 21 May 2018 07:19:05 GMT):
@ryanwest6 The instruction I mentioned is not for indy-node, but from plenum also (actually we probably need to copy it to plenum as well). Some dependencies need to be installed (RocksDB, libsodium, etc.) to be able to run the tests locally. The provided link contains the information.

CabMorris2 (Mon, 21 May 2018 19:28:11 GMT):
Has joined the channel.

jayapalreddy (Tue, 22 May 2018 12:01:38 GMT):
Has joined the channel.

benjsmi (Wed, 23 May 2018 15:07:54 GMT):
```{"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"}```

benjsmi (Wed, 23 May 2018 15:08:10 GMT):
curious why entries like this are in `/var/lib/indy/sandbox/pool_transactions_gensis`

benjsmi (Wed, 23 May 2018 15:08:14 GMT):
are they stewards?

benjsmi (Wed, 23 May 2018 15:08:37 GMT):
or (as i suspect) are they trustee nodes that will tell you where the steward nodes *are*?

benjsmi (Wed, 23 May 2018 15:08:44 GMT):
(i.e. once you connect and so on)

benjsmi (Wed, 23 May 2018 15:12:17 GMT):
a separate unrelated question: is the `validator verkey, the HEX verification key for your server` located somewhere on the steward node's disk? or is it *only* accessible from STDOUT when you run the `init_indy_node` script?

benjsmi (Wed, 23 May 2018 15:37:10 GMT):
also

benjsmi (Wed, 23 May 2018 15:37:20 GMT):
i have seen the terms `public key` and `verification key` used interchangeable

benjsmi (Wed, 23 May 2018 15:37:20 GMT):
i have seen the terms `public key` and `verification key` used interchangeably

benjsmi (Wed, 23 May 2018 15:37:31 GMT):
and sometimes it seems they are used incorrectly.

benjsmi (Wed, 23 May 2018 15:37:44 GMT):
with the output from `init_indy_node` like this

benjsmi (Wed, 23 May 2018 15:37:47 GMT):
```Init local keys for client-stack Public key is d006946a4f7a9a942eb3c5c6ff2812dfb4e22b34a900be6188f484ac18666c5a Verification key is ad1238ce21293c027ce5e802d3f4c525f41da06f45fa3d0094c9ed8be9bd58bc Init local keys for node-stack Public key is d006946a4f7a9a942eb3c5c6ff2812dfb4e22b34a900be6188f484ac18666c5a Verification key is ad1238ce21293c027ce5e802d3f4c525f41da06f45fa3d0094c9ed8be9bd58bc BLS Public key is 2Ec3CT8ogRK2gxjhhPUNW4pczvyVbToCVkKSMWGkA9f68GeNLKMQLdrALu3o3sapC8dXt7tvsfRNbefR5w1W5W9ApFVkkDLnMq32CfEp6UkJvbWUf7Q8XB9LyL3nZuFtec1x98LoSmxibtbWGGSguiSHSqa5C7prDpqWewXWYzcpQ8x```

benjsmi (Wed, 23 May 2018 15:38:00 GMT):
the one you want is `ad1238ce21293c027ce5e802d3f4c525f41da06f45fa3d0094c9ed8be9bd58bc` right?

benjsmi (Wed, 23 May 2018 15:42:59 GMT):
also curious why that one doesn't match the key in `/var/lib/indy/sandbox/myValidatorsAlias_info.json`

tusharg (Thu, 24 May 2018 13:01:13 GMT):
Has joined the channel.

jeremi 24 (Fri, 25 May 2018 07:05:40 GMT):
Has joined the channel.

json (Fri, 25 May 2018 17:44:56 GMT):
Has joined the channel.

akuma921 (Mon, 28 May 2018 05:08:48 GMT):
Has joined the channel.

akuma921 (Mon, 28 May 2018 05:08:55 GMT):
Hi

akuma921 (Mon, 28 May 2018 05:09:14 GMT):
Guys I am using indy CLI and want to build a customize POC

akuma921 (Mon, 28 May 2018 05:09:45 GMT):
but not sure how to get connection file (.indy) to my CLI

akuma921 (Mon, 28 May 2018 05:09:51 GMT):
can anybody help me

AxelNennker (Mon, 28 May 2018 15:13:27 GMT):
Has joined the channel.

AxelNennker (Mon, 28 May 2018 15:13:51 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 15:14:18 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'.

Neumann347 (Mon, 28 May 2018 22:35:46 GMT):
Has joined the channel.

ashcherbakov (Tue, 29 May 2018 07:25:03 GMT):
@AxelNennker The latest version of indy-node (in master) uses RocksDB instead of levelDB, so just an upgrade doesn't work. The intended way to upgrade Indy-Node is to send POOL_UPGRADE command which can take care of all necessary migrations (such as migration from leveldb to rocksdb). As a workaround you can try to run a migration script manually (https://github.com/hyperledger/indy-node/blob/master/data/migrations/deb/1_3_396_to_1_3_397.py)

ashcherbakov (Tue, 29 May 2018 07:25:03 GMT):
@AxelNennker The latest version of indy-node (in master) uses RocksDB instead of levelDB, so just an upgrade doesn't work. The intended way to upgrade Indy-Node is to send POOL_UPGRADE command which can take care of all necessary migrations (such as migration from leveldb to rocksdb). As a workaround you can try to run a migration script manually (https://github.com/hyperledger/indy-node/blob/master/data/migrations/deb/1_3_396_to_1_3_397.py) Actually if this is just a test pool and you don't have any valuable data in the ledger, then it's easier just to re-create the pool on the latest version.

ashcherbakov (Tue, 29 May 2018 07:25:43 GMT):
@akuma921 What CLI do you use? The one in indy-node repo is deprecated, so please use the new one: https://github.com/hyperledger/indy-sdk/tree/master/cli

ashcherbakov (Tue, 29 May 2018 07:31:14 GMT):
@benjsmi > curious why entries like this are in `/var/lib/indy/sandbox/pool_transactions_gensis` > are they stewards? > or (as i suspect) are they trustee nodes that will tell you where the steward nodes *are This is a NODE txn (the txn telling what Nodes the pool consists of). A steward's txn is a NYM txn with a Steward role telling DID/key for a Steward. genesis txn file consists of a NODE txns defining initial set of the nodes in the pool (to be used by clients and new nodes for initial connection). So, genesis txn file is initial subset of the pool ledger transactions.

ashcherbakov (Tue, 29 May 2018 07:32:34 GMT):
> a separate unrelated question: is the `validator verkey, the HEX verification key for your server` located somewhere on the steward node's disk? or is it *only* accessible from STDOUT when you run the `init_indy_node` script? The verkey is stored on the disk (together with a signing key) and (as this is a public part) also stored in NODE txn on the ledger

ashcherbakov (Tue, 29 May 2018 07:34:27 GMT):
> i have seen the terms `public key` and `verification key` used interchangeably No, ZeroMQ (curveCP implementation which is our secure node-to-node transport) requires both verkey-signingKey and public-private key pairs. Actually one can be obtained from the other by some transformation, that's why only the verkey is stored on the ledger.

AxelNennker (Tue, 29 May 2018 11:08:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=nwtnqjudLpMrDv76z) @ashcherbakov I deleted the data directory and now the validator starts without error messages. Keeping my fingers crossed that it still understands the other nodes, operated by other organizations, which have older versions of the packages.

ashcherbakov (Tue, 29 May 2018 11:11:12 GMT):
@AxelNennker What is the pool you are working with? If this is a production-like pool, then all updates *must* be done via POOL_UPGRADE txn, not manually.

AxelNennker (Tue, 29 May 2018 11:19:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=dZZrBuYjWRLaWppnk) @ashcherbakov The project is not in a state that I would call 'production'. Anyway, I expected that when after my node died after an OS update and I reinstalled the Indy packages and I use the same genesis files etc that it will sync with the other nodes, running older packages - thus rebuilding its local data base. Should I do a https://github.com/hyperledger/indy-node/blob/master/docs/pool-upgrade.md

AxelNennker (Tue, 29 May 2018 11:19:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=dZZrBuYjWRLaWppnk) @ashcherbakov The project is not in state that I would call 'production'. Anyway, I expected that after my node died after an OS update and I reinstalled the Indy packages and I use the same genesis files etc that it will sync with the other nodes, running older packages - thus rebuilding its local data base. Should I do a https://github.com/hyperledger/indy-node/blob/master/docs/pool-upgrade.md

AxelNennker (Tue, 29 May 2018 11:19:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=dZZrBuYjWRLaWppnk) @ashcherbakov The project is not in state that I would call 'production'. Anyway, I expected that when after my node died after an OS update and I reinstalled the Indy packages and I use the same genesis files etc that it will sync with the other nodes, running older packages - thus rebuilding its local data base. Should I do a https://github.com/hyperledger/indy-node/blob/master/docs/pool-upgrade.md

shsedghi (Tue, 29 May 2018 14:53:37 GMT):
Has joined the channel.

burdettadam (Tue, 29 May 2018 19:15:45 GMT):
Has joined the channel.

AxelNennker (Wed, 30 May 2018 13:05:42 GMT):
Hi, I created a PR that adds an option to validator-info which produces Nagios compatible output which can be used by monitoring systems like check_mk (and Nagios obviously). https://github.com/hyperledger/indy-node/pull/733 Hope you find this useful. Axel

jwaup (Wed, 30 May 2018 14:37:41 GMT):
Has joined the channel.

adaml (Wed, 30 May 2018 16:39:38 GMT):
Has joined the channel.

AxelNennker (Thu, 31 May 2018 07:13:55 GMT):
Hi, how do I prevent indy-node from binding to 0.0.0.0? Only one interface is the correct one and I don't want the service to be available on the e.g. admin interface of the host. Node_ip is not the right option.

ashcherbakov (Thu, 31 May 2018 08:12:47 GMT):
@AxelNennker We've just fixed it this Sprint. The latest version of master allows to specify IP. https://github.com/hyperledger/indy-node/blob/master/docs/start-nodes.md#generating-keys So, you can replace 0.0.0.0 with the the value you want.

sergey-shilov (Thu, 31 May 2018 08:23:57 GMT):
Has joined the channel.

tusharg (Thu, 31 May 2018 08:25:09 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..

AxelNennker (Thu, 31 May 2018 08:25:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=fPpjcTRDvtW4Cijea) @ashcherbakov Which config file can I change to bind to 10.0.0.5 but keep the public node_ip as is?

ashcherbakov (Thu, 31 May 2018 08:27:56 GMT):
@tusharg You can use `read_ledger`, or `validator_info` script.

ashcherbakov (Thu, 31 May 2018 08:27:56 GMT):
@tusharg You can use `read_ledger`, or `validator_info` scripts.

tusharg (Thu, 31 May 2018 08:29:36 GMT):
@ashcherbakov Thanks for the quick reply! Actually I am quite new at indy.. Can you explain in some detail (or give me a link) as how to do that?

AxelNennker (Thu, 31 May 2018 08:30:38 GMT):
I would remove the optional seed from the examples in https://github.com/hyperledger/indy-node/blob/master/docs/start-nodes.md#generating-keys because people will use the example seed and later move the test network to production. 'init_indy_node Alpha 0.0.0.0 9701 0.0.0.0 9702 [--seed 111111111111111111111111111Alpha]'

sergey-shilov (Thu, 31 May 2018 08:32:36 GMT):
hi @AxelNennker, you can specify IPs for node-to-node and client-to-node communication in /etc/indy/indy.env file. So append something like this: NODE_IP=127.0.0.10 CLIENT_IP=10.0.0.5

ashcherbakov (Thu, 31 May 2018 08:32:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=tmuv2jBawmYXgYyJw) @tusharg Just go to the node machine, and run `read_ledger --type=domain` (try -h for more options), or `validator_info` (try -h for more options). Please run the scripts from the `indy` user. A list of helper scripts: https://github.com/hyperledger/indy-node/blob/master/docs/helper-scripts.md

tusharg (Thu, 31 May 2018 08:33:55 GMT):
@ashcherbakov Thanks :smile:

sergey-shilov (Thu, 31 May 2018 08:39:50 GMT):
@AxelNennker so the node listener will be bound on NODE_IP and the client listener on CLIENT_IP

AxelNennker (Thu, 31 May 2018 08:40:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=kpQp9pAXwfZoFnBSY) @sergey-shilov I think this will stop my node from working because the node _needs_ the public IP address to be reachable but that public IP address is not assigned to any LAN interface because the firewall (DDOS protection etc) has the public IP address. The node has three private addresses. Only one of them gets the traffic that is directed to the node's public IP. How do I tell indy-node that about the public IP address and at the same time bind to only one of the LAN interfaces - identified by its private IP address). I tried once to start the node with the private address which resulted in it not being reachable by the other nodes. I can try that again but ...

AxelNennker (Thu, 31 May 2018 08:45:29 GMT):
More specific: The node should use its public IP address if that is part of any message send out to other parties but only bind its listening sockets to one private IP address.

sergey-shilov (Thu, 31 May 2018 08:49:12 GMT):
indy-node gets IPs for binding from indy.env file, so you can specify your private address for listening. Other nodes get IP for connection from pool ledger, where should be specified node's public IP

AxelNennker (Thu, 31 May 2018 08:56:40 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=Q9LisqdvjYzDbPQ97) @sergey-shilov I added NODE_IP=10.0.0.5 and CLIENT_IP=10.0.0.5 to indy.env, stopped indy.service, started indy.service but it still binds to 0.0.0.0. Wrong variable name?

sergey-shilov (Thu, 31 May 2018 08:58:25 GMT):
@AxelNennker this is currently under testing, it was merged just today, I'm checking now

sergey-shilov (Thu, 31 May 2018 08:58:40 GMT):
@AxelNennker you are the first who run it))

AxelNennker (Thu, 31 May 2018 09:06:28 GMT):
@sergey-shilov No, you are probably assuming I am running indy-node from git but I am using version indy-node 1.3.428 on this node. Sorry for the misunderstanding. It is still unclear to me which IP address to use when and where. I think that an indy.env might need to look like for my infrastructure: NODE_NAME=something NODE_PORT=9700 NODE_CLIENT_PORT=9701 NODE_IP=public-IP CLIENT_IP=another-or-the-same-public-ip NODE_BIND_IP=private-ip CLIENT_BIND_IP=another-or-the-same-private-IP

tusharg (Thu, 31 May 2018 09:15:46 GMT):
@ashcherbakov So I am using the default docker-compose file given in the SDK, and run `docker exec indy_pool read_ledger --type pool` on my terminal, and it shows the genesis transaction (with the node info)... However, I run the write_did_and_query_verkey tutorial till the addition of trust anchor. Now the trust anchor is getting verified by the script, but the `read_ledger` command is still showing the genesis transactions only... Where am I going wrong?

sergey-shilov (Thu, 31 May 2018 09:36:43 GMT):
@AxelNennker of course for version indy-node 1.3.428 these parameters are ignored and it still binds to 0.0.0.0

AxelNennker (Thu, 31 May 2018 09:41:19 GMT):
@sergey-shilov Still not sure whether the new code helps in my setup: Internet - FW with public addresses for node and client - node with several private addresses How do the node or client know their public IP address?

sergey-shilov (Thu, 31 May 2018 09:44:19 GMT):
@AxelNennker regarding NODE_IP and NODE_BIND_IP... lets look at indy-node as at a simple server that listens for incoming connections, and it just need one IP address to listen on. why does it need any knowledge about proxy/NAT/DDoS-protector public IP if that proxy forwards packets from it's public IP to node's local IP?

sergey-shilov (Thu, 31 May 2018 09:45:21 GMT):
public IP is needed just for other nodes to be able to connect

Toktar (Thu, 31 May 2018 09:47:47 GMT):
Еуттфте

AxelNennker (Thu, 31 May 2018 09:49:12 GMT):
It is then a problem if the public IP address is used IN a message between nodes. There only the public IP address MUST be used because the others MUST not know about my private network layout. If the IP address of the node is never taken from NODE_IP or CLIENT_IP but published somewhere else then everything works. Coming back to the first answer regarding key generation, should 0.0.0.0 replaced by the public IP address or the private NIC adddress?

sergey-shilov (Thu, 31 May 2018 09:49:13 GMT):
@AxelNennker FW and node are different machines in your setup?

AxelNennker (Thu, 31 May 2018 09:50:05 GMT):
@sergey-shilov yes, they are different machines operated by different groups.

sergey-shilov (Thu, 31 May 2018 09:53:41 GMT):
@AxelNennker are your nodes located in a local network to be able to contact each other by nodes' local addresses?

sergey-shilov (Thu, 31 May 2018 09:53:41 GMT):
@AxelNennker are your nodes located in a local network to be able to contact each other by node's local addresses?

AxelNennker (Thu, 31 May 2018 10:13:27 GMT):
No. other nodes - Internet - FW with public addresses for node and client - node with several private addresses

sergey-shilov (Thu, 31 May 2018 10:21:20 GMT):
so, to make it worked, your FW should do port forwarding, i.e. forward packets sent to GLOBAL_IP:NODE_PORT to LOCAL_IP:NODE_PORT, right?

AxelNennker (Thu, 31 May 2018 10:28:31 GMT):
Yes, the FW does exactly this. This is all working and it will continue to work after indy-node stops binding to 0.0.0.0. My concern is that the node might use the bind address in a message to others who are then confused or reject the message because the IP address is different to the public IP. If inside of messages the public IP is used then everything is fine. But how does the node know its public IP address if it is not in NODE_IP nor CLIENT_IP?

AxelNennker (Thu, 31 May 2018 10:29:26 GMT):
If the IP address is never inside a message then there is no problem at all.

sergey-shilov (Thu, 31 May 2018 10:38:03 GMT):
as I remember, we don't add IP addresses inside of our business-logic messages, IPs are only presented in TCP/IP headers

sergey-shilov (Thu, 31 May 2018 10:38:41 GMT):
and your FW does NAT, so your setup should work

sergey-shilov (Thu, 31 May 2018 10:42:52 GMT):
bind indy-node to local IPs by setting NODE_IP and CLIENT_IP, setup correct port forwarding on your FW and all should work

sergey-shilov (Thu, 31 May 2018 14:41:38 GMT):
@AxelNennker sorry, use NODE_CLIENT_IP instead of CLIENT_IP in indy.env file

mgbailey (Thu, 31 May 2018 22:57:04 GMT):
@AxelNennker , let me chime in here, and perhaps summarize some of the conversation. The goal is to have 2 externally-reachable NICs. This is to allow isolation between client and node traffic, so that a DOS attack on the client port will not interfere with traffic between validator nodes. We also expect that the node port will be firewalled so that connections are only accepted from other validators, while the client port is open to any IP address. Unfortunately there is currently a bug so that the client port binding is to 0.0.0.0 instead of to its specific IP address. This defect will be fixed in an upcoming release, in about a month. The client and node ports and IP addresses are published on the ledger, which information will be used by the other validators and client to connect to your validator. In the current release, I do not see where the client and node IP addresses are configured in configuration files, but in the release where the client port is properly bound to a particular IP address, I assume that they will be configured, perhaps in /etc/indy/indy.env. @sergey-shilov , can you confirm this?

AxelNennker (Fri, 01 Jun 2018 08:12:20 GMT):
The question is how 'The client and node ports and IP addresses are published on the ledger' is done. NODE_IP and NODE_CLIENT_IP are private addresses (in my case), so the node does not know its public address. In the Steward Preparation Guide is this done by the Sovrin admin after the steward had send the node's info per email to Sovrin?

sergey-shilov (Fri, 01 Jun 2018 08:27:56 GMT):
@mgbailey exactly

sergey-shilov (Fri, 01 Jun 2018 09:16:14 GMT):
@AxelNennker "NODE_IP and NODE_CLIENT_IP are private addresses (in my case)" - this absolutely right setup. Regarding the question how 'The client and node ports and IP addresses are published on the ledger' is done: each new node is added to the pool by special transaction called "node transaction". Each pool node and pool client gets IP/port to connect from this transaction. So that this transaction contains PUBLIC node and client IPs to be able to connect. These IPs may differ from NODE_IP and NODE_CLIENT_IP (your case with separated FW with port forwarding), but may be the same. If FW's public IP is changed then corresponding node transaction should be sent to propagate updated node info

AxelNennker (Fri, 01 Jun 2018 10:07:40 GMT):
Would you advice to add NODE_IP and NODE_CLIENT_IP to indy.env now so that it is there when the next package update is done?

sergey-shilov (Fri, 01 Jun 2018 10:19:07 GMT):
I don't think that it is needed now... this will be done by migration script during upgrade of indy-node package. But note that this migration script gets value for NODE_IP from pool ledger, i.e. your PUBLIC IP, and sets 0.0.0.0 for NODE_CLIENT_IP as the script does not know which iface do you prefer for binding. So you can change these two parameters after upgrade is finished. We plan to provide a doc for stewards about that upgrade and binding configuration.

AxelNennker (Fri, 01 Jun 2018 10:27:29 GMT):
If I add the values now would the migration script respect them? Removing the public IP after the upgrade would result in a second (short) downtime, right?

AxelNennker (Fri, 01 Jun 2018 10:27:29 GMT):
If I add the values now would the update script respect them? Removing the public IP after the upgrade would result in a second (short) downtime, right?

sergey-shilov (Fri, 01 Jun 2018 10:34:27 GMT):
For now the migration script does not respect them. I can implement appending of these parameters just in case of their absence to avoid the second downtime, but I need to check it with our team as these changes take a time to be merged in master due to our CI and CD pipelines

sergey-shilov (Fri, 01 Jun 2018 10:34:44 GMT):
I'll let you know soon

AxelNennker (Fri, 01 Jun 2018 11:01:42 GMT):
Dang. I managed to wreck my PR buy using the web editor to add one blank into the PR. Now the sign-off to that change is missing and blocking the review. https://github.com/hyperledger/indy-node/pull/733

AxelNennker (Fri, 01 Jun 2018 11:01:42 GMT):
Dang. I managed to wreck my PR by using the web editor to add one blank into the PR. Now the sign-off to that change is missing and blocking the review. https://github.com/hyperledger/indy-node/pull/733

sergey-shilov (Fri, 01 Jun 2018 12:47:10 GMT):
every commit should be signed-off, you can sign-off your previous commits using git rebase

sergey-shilov (Fri, 01 Jun 2018 12:47:54 GMT):
yes, it then require forced update

sergey-shilov (Fri, 01 Jun 2018 12:47:54 GMT):
yes, it then requires forced update

sergey-shilov (Fri, 01 Jun 2018 12:49:55 GMT):
it's not good, but is not critical at the same time

sergey-shilov (Fri, 01 Jun 2018 12:49:55 GMT):
it's not good, but is not critical at the same time as you are working in your own fork

AxelNennker (Fri, 01 Jun 2018 14:39:56 GMT):
Started from scratch doing Nagios support https://github.com/hyperledger/indy-node/pull/741

LoveshHarchandani (Fri, 01 Jun 2018 23:22:43 GMT):
https://github.com/hyperledger/indy-plenum/issues/721

LoveshHarchandani (Fri, 01 Jun 2018 23:22:43 GMT):
indy-plenum tests failing, https://github.com/hyperledger/indy-plenum/issues/721

karthikpanicker (Sat, 02 Jun 2018 09:25:25 GMT):
Has joined the channel.

ashcherbakov (Mon, 04 Jun 2018 07:36:41 GMT):
@LoveshHarchandani A newer version of libindy needs to be installed locally, please see my comments in the issue

haggs (Mon, 04 Jun 2018 20:32:25 GMT):
Has joined the channel.

sativ (Tue, 05 Jun 2018 13:49:44 GMT):
Has joined the channel.

sativ (Tue, 05 Jun 2018 13:58:26 GMT):
Hi all, I'm trying to run a demo from IBM-Blockchain-Identity/indy-ssivc-tutorial on Ubuntu 16.04, and webserver in VON network is crashing with indy.error.IndyError: ErrorCode.PoolLedgerTimeout I assume that this error means that Indy ledger is not working. But not sure why or how to fix it I appreciate any ideas and suggestions Thanks

the_identity_guy (Wed, 06 Jun 2018 00:16:19 GMT):
Hi, If the Indy CLI and Indy-lib codes can't connect with Indy-nodes, what could be the reason? From Indylib code the error I receive is ``` open_pool_ledger.cb) indy.error.IndyError: ErrorCode.PoolLedgerTimeout ```

the_identity_guy (Wed, 06 Jun 2018 00:16:19 GMT):
Hi, If the Indy CLI and Indy-lib codes can't connect with Indy-nodes, what could be the reason? From Indylib code the error I receive is ``` File "/Users/RSoltani/Repositories-N2K/2Keys/Indy-Experiment/venv/lib/python3.6/site-packages/indy/pool.py", line 82, in open_pool_ledger open_pool_ledger.cb) indy.error.IndyError: ErrorCode.PoolLedgerTimeout ```

the_identity_guy (Wed, 06 Jun 2018 00:16:19 GMT):
Hi, If the Indy CLI and Indy-lib codes can't connect with Indy-nodes, what could be the reason? From Indylib code the error I receive is ``` File "project/indy/pool.py", line 82, in open_pool_ledger open_pool_ledger.cb) indy.error.IndyError: ErrorCode.PoolLedgerTimeout ```

the_identity_guy (Wed, 06 Jun 2018 00:18:47 GMT):
nodes cant reach other either: ``` Validator Node1 is running Validator DID: Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv Verification Key: 33nHHYKnqmtGAVfZZGoP8hpeExeH45Fo8cKmd5mcnKYk7XgWNBxkkKJ Node Port: 9701 Client Port: 9702 Metrics: Uptime: 1 hour, 33 minutes, 36 seconds Total Ledger Transactions: 9 Total Pool Transactions: 4 Read Transactions/Seconds: 0.00 Write Transactions/Seconds: 0.00 Reachable Hosts: 1/4 Unreachable Hosts: 3/4 ```

sativ (Wed, 06 Jun 2018 07:10:32 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=csAQx3So7nFmhb3fL) @the_identity_guy I have the same problem, would like to figure out how can I "ping" nodes from one another to see if there's network connection (just to be sure that it isn't firewall blocking it)

ashcherbakov (Wed, 06 Jun 2018 08:53:42 GMT):
What version of node and client (SDK) do you use? As was announced on meetings and mailing lists, there are some breaking changes in master node (comparing to previous stable). So, please make sure that you either use stable or latest master for *both* indy-node and indy-sdk.

ashcherbakov (Wed, 06 Jun 2018 08:54:22 GMT):
> would like to figure out how can I "ping" nodes from one another to see if there's network connection (just to be sure that it isn't firewall blocking it) We have a tool `validator_info` which can be run on a node to a lot of statistics (including connections to other nodes)

ashcherbakov (Wed, 06 Jun 2018 08:58:36 GMT):
https://github.com/hyperledger/indy-node/blob/master/docs/helper-scripts.md BTW the tool was improved and extended in the latest master, so it should give more info. Also there is a command (available from the new indy-sdk-based CLI) `ledger get-validator-info` which can be run from a Steward to get info from all the nodes in the pool

sativ (Wed, 06 Jun 2018 11:57:35 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=qh4bBKx3Mqii6f2Tw) @ashcherbakov , thanks for the info! I'm running indy network from https://github.com/IBM-Blockchain-Identity/indy-ssivc-tutorial the version of Indy that composes a network of nodes is Indy 1.2.297 I want to run a demo to showcase Indy in our company, so can't really switch to a different Indy version simply because I don't have enough expertise with Indy to do so. when I run `validator-info` I get back``` Validator Node1 is in unknown state Validator DID: Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv Verification Key: 33nHHYKnqmtGAVfZZGoP8hpeExeH45Fo8cKmd5mcnKYk7XgWNBxkkKJ Node Port: 9701 Client Port: 9702 Metrics: Uptime: 30 minutes, 1 second Total Ledger Transactions: 5 Total Pool Transactions: 4 Read Transactions/Seconds: 0.00 Write Transactions/Seconds: 0.00 Reachable Hosts: 1/4 Unreachable Hosts: 3/4 ``` also from the log of a node I get: ``` node1_1 | 2018-06-06 10:41:00,009 | INFO | zstack.py (584) | connect | CONNECTION: Node1 looking for Node4 at 127.0.0.1:9418 node1_1 | 2018-06-06 10:41:00,014 | INFO | zstack.py (584) | connect | CONNECTION: Node1 looking for Node2 at 127.0.0.1:9418 node1_1 | 2018-06-06 10:41:00,019 | INFO | zstack.py (584) | connect | CONNECTION: Node1 looking for Node3 at 127.0.0.1:9418 ``` I am not sure why is it a different port number that node is listening to (e.g. 9418 vs 970x) Any ideas? Thanks!

ashcherbakov (Wed, 06 Jun 2018 13:39:43 GMT):
I'm not aware of the content of https://github.com/IBM-Blockchain-Identity/indy-ssivc-tutorial You can try an official Docker from https://github.com/hyperledger/indy-node/tree/master/environment/docker/pool In general it should be the same port. You can compare the content of the pool ledger (run `read_ledger`, which contains public data), and `indy.env` file (in /etc/indy/indy.env)

BreizhIndy (Wed, 06 Jun 2018 14:41:18 GMT):
Has joined the channel.

the_identity_guy (Wed, 06 Jun 2018 14:53:51 GMT):
@ashcherbakov I am using the 1.4.0 tag for Indy-SDK and the Stable branch for Indy-Node.. are they compatible? I noticed on the Stable branch of the Indy-Node there is ``` add-apt-repository "deb https://repo.sovrin.org/deb xenial master ``` should it be 'master' or 'stable' in that line?

ashcherbakov (Wed, 06 Jun 2018 15:16:30 GMT):
Please use stable libindy. It may mention master just for CI tests.

brycecurtis (Wed, 06 Jun 2018 19:12:27 GMT):
@sativ It could be that the IP address for DOCKERHOST isn't being set when you run the manage script. If you are running on Windows, this is very likely the problem. Please open an issue with specific details in the git repo (https://github.com/IBM-Blockchain-Identity/indy-ssivc-tutorial/issues) and we will take a look.

swcurran (Wed, 06 Jun 2018 19:38:46 GMT):
FYI - this is a good multiplatform way to get the DOCKERHOST set: ``` export DOCKERHOST=${APPLICATION_URL-$(docker run --rm --net=host codenvy/che-ip)} ``` It uses a docker image from Codenvy. Run that before you start up the various components. @brycecurtis - you or we :-) could add that to the manage script to increase the flexibility. We've been using it for awhile in our scripts.

brycecurtis (Wed, 06 Jun 2018 21:08:53 GMT):
@swcurran Nice. Will take a look at it.

swcurran (Wed, 06 Jun 2018 23:15:12 GMT):
Does the current implementation of Indy-Node support the pending DID Document standard as it currently stands? In particular does Indy allow a DID to have multiple public keys/authentication methods and multiple endpoints? I'm not talking about storing the information on the ledger as a DID Doc, but whether multiple keys and endpoints are supported. https://w3c-ccg.github.io/did-spec/

SherifMuhammed (Thu, 07 Jun 2018 10:00:55 GMT):
Has joined the channel.

skynet (Thu, 07 Jun 2018 10:46:27 GMT):
Has joined the channel.

SherifMuhammed (Thu, 07 Jun 2018 11:50:17 GMT):
Hi , I am trying to run ALICE@sandbox> accept request from "Faber College" Request not yet verified. Connection not yet synchronized. Request acceptance aborted. Cannot sync because not connected. Please connect first. Usage: connect ALICE@sandbox>

SherifMuhammed (Thu, 07 Jun 2018 11:50:57 GMT):
I am always get this error. any help please

RyanWest (Thu, 07 Jun 2018 19:38:19 GMT):
Has joined the channel.

abraham (Fri, 08 Jun 2018 05:20:06 GMT):
Has joined the channel.

PhillipGibb (Fri, 08 Jun 2018 09:28:19 GMT):
Has joined the channel.

PhillipGibb (Fri, 08 Jun 2018 09:50:15 GMT):
Hi, I have setup a couple nodes in docker using the commands in the indy-sdk read me. And a docker for indy-cli What I am unsure of is how indy-cli knows of the nodes in the other docker image. There is a create pool option in cli, but I can't see how this is setup to connect to my nodes, so at the moment nothing can be ledgered until the pool is setup Any suggestions for a pool create gen file and how it is setup? The docker one I found in github does not work thanks Phill

SherifMuhammed (Fri, 08 Jun 2018 10:18:17 GMT):
FYI , I used connect sandbox command it gives me attempting to connect

PhillipGibb (Fri, 08 Jun 2018 10:40:49 GMT):
tks, that lead me to more info: Step 1. Create the pool ledger from genesis txn file A genesis txn file contains the information about the NODE and CLIENT machines. With this information after dumped to JSON format and a name, a pool ledger is created. Step 2. Open pool ledger to get the pool handle via pool name. The returned pool handle is used in methods that require pool connection Step 3. Create the new Wallet. Step 4. Get wallet handle to use in methods that require wallet access. But I believe that I have a ledger pool in a running docker connection. Question is how do i direct indy-cli to it

PhillipGibb (Fri, 08 Jun 2018 11:03:12 GMT):
getting Indy SDK error occurred PoolLedgerNotCreatedError when I use a gen file containing: {"data":{"alias":"pool1","blskey":"4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n694b61aac3af08ba875ce3026a160acbc3a3af35fc","type":"0"}

PhillipGibb (Fri, 08 Jun 2018 11:03:44 GMT):
pool create succeeds Connect fails with an error

PhillipGibb (Fri, 08 Jun 2018 11:03:44 GMT):
pool create succeeds {"data":{"alias":"pool1","client_ip":"192.168.1.252","client_port":"9702","node_ip":"192.168.1.252","node_port":"9701$ Connect fails with an error

PhillipGibb (Fri, 08 Jun 2018 11:24:52 GMT):
actually: {"data":{"alias":"pool1","client_ip":"192.168.1.252","client_port":"9702","node_ip":"192.168.1.252","node_port":"9701$

PhillipGibb (Fri, 08 Jun 2018 11:27:42 GMT):
actually {"data":{"alias":"pool1","client_ip":"192.168.1.252","client_port":"9702","node_ip":"192.168.1.252","node_port":"9701","services":["VALIDATOR"]},"dest":"UZH61eLH3JokEwjMWQoCMwB3PMD6zRBvG6NCv5yVwXz","identifier":"3U8HUen8WcgpbnEz1etnai","txnId":"c585f1decb986f7ff19b8d03deba346ab8a0494cc1e4d69ad9b8acb0dfbeab6f","type":"0"}

saikirantyson7 (Fri, 08 Jun 2018 12:19:50 GMT):
Has joined the channel.

saikirantyson7 (Fri, 08 Jun 2018 12:20:15 GMT):
Hi everyone. ! Can anyone forward me the doc regarding indy?

PhillipGibb (Fri, 08 Jun 2018 13:46:46 GMT):
https://github.com/hyperledger/indy-sdk

saikirantyson7 (Fri, 08 Jun 2018 14:06:27 GMT):
Thanks @PhillipGibb

PhillipGibb (Fri, 08 Jun 2018 17:10:39 GMT):
@saikirantyson7 if you get a docker comtainer running with nodes and are able to cli into it from another container please let me know. Struggling with this.

PhillipGibb (Fri, 08 Jun 2018 19:48:35 GMT):
has anyone actually got an indy test environment up and running in docker containers? I have been trying to follow the steps in https://github.com/hyperledger/indy-sdk and I have to say; there is no way that anyone has succeeded

esplinr (Fri, 08 Jun 2018 22:04:57 GMT):
@PhillipGibb : @kdenhartog has been playing with setting everything up inside of docker.

kdenhartog (Fri, 08 Jun 2018 22:04:57 GMT):
Has joined the channel.

kdenhartog (Sat, 09 Jun 2018 00:53:09 GMT):
@PhillipGibb are you looking to just do the demo? If so, I'd suggest https://github.com/IBM-Blockchain-Identity/indy-tutorial-sandbox

kdenhartog (Sat, 09 Jun 2018 00:53:51 GMT):
I'm building off the stuff they've built to make an all in one solution for running the demo and being able to develop with the sdk

kdenhartog (Sat, 09 Jun 2018 00:54:44 GMT):
the main difference is their's uses the indy-node cli which has been deprecated in favor of the indySDK cli which is one of the things I'll be updating

PhillipGibb (Sat, 09 Jun 2018 03:15:19 GMT):
@esplinr @kdenhartog I have been trying to set everything up inside a docker container, currently trying the install the sdk with https://github.com/hyperledger/indy-sdk/blob/master/doc/ubuntu-build.md

PhillipGibb (Sat, 09 Jun 2018 03:17:53 GMT):
@kdenhartog I have done the demo before with success, what I want to achieve is 1. run the docker nodes in a container - it appears that this is done 2. Setup a wall and a did - and connect to one of the pools to ledger a ddo

PhillipGibb (Sat, 09 Jun 2018 03:20:47 GMT):
@kdenhartog presently I am attempting to build indysdk cli but now this: warning: spurious network error (2 tries remaining): [28] Timeout was reached (Operation timed out after 30002 milliseconds with 0 out of 0 bytes received) warning: spurious network error (1 tries remaining): [6] Couldn't resolve host name (Couldn't resolve host 'static.crates.io') error: unable to get packages from source Caused by: [6] Couldn't resolve host name (Couldn't resolve host 'static.crates.io')

kdenhartog (Sat, 09 Jun 2018 03:24:01 GMT):
let me try running it and seeming what I get. From googling that error it looks like an issue with rust and their dns resolution

kdenhartog (Sat, 09 Jun 2018 03:24:54 GMT):
@PhillipGibb are you on `commit 129b813d6b247a14b869759bdfe56ad15b2fabbc`

PhillipGibb (Sat, 09 Jun 2018 03:26:39 GMT):
yes

kdenhartog (Sat, 09 Jun 2018 03:27:22 GMT):
gotcha, and are you trying to get the cluster pool running in docker or the actual sdk?

PhillipGibb (Sat, 09 Jun 2018 03:30:00 GMT):
the actual sdk

kdenhartog (Sat, 09 Jun 2018 03:37:41 GMT):
It looks like this has an sdk dockerfile setup already. Did you use this guide last time by chance? https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/run-getting-started.md

PhillipGibb (Sat, 09 Jun 2018 03:59:33 GMT):
@kdenhartog going to do that again with docker compose, but I have a docker running with the pools setup, problem is I want to use the indysdk - cli and I am not able to connect to a pool

kdenhartog (Sat, 09 Jun 2018 04:00:41 GMT):
yeah I'm seeing similar issues currently. If you run `docker-compose down` then `docker-compose up --build` that should get you an image setup

kdenhartog (Sat, 09 Jun 2018 04:08:55 GMT):
then you should (this is where I'm stuck at currently) be able to run tests within a terminal by editing files within your local file system and then testing them within the docker container by running `docker run -it --name --rm indy-sdk -v /indy-sdk:/home/indy-dev getting-started bash`

kdenhartog (Sat, 09 Jun 2018 04:11:00 GMT):
from here, the indy-sdk container should be setup and we'll have a common system to work with

kdenhartog (Sat, 09 Jun 2018 04:11:42 GMT):
I'm thinking what is causing this problem is either the genesis txns or the network setup in the dockerfile.yaml so I'm trying to change stuff in that right now

PhillipGibb (Sat, 09 Jun 2018 04:12:46 GMT):
coool, tks. I am going to try that

kdenhartog (Sat, 09 Jun 2018 04:20:11 GMT):
Ok, I've gotten it to work with a few tweaks.

kdenhartog (Sat, 09 Jun 2018 04:20:44 GMT):
do you want to jump on a zoom call? I can probably explain this much faster on there.

PhillipGibb (Sat, 09 Jun 2018 04:28:02 GMT):
can't do a voice call with everyone sleeping :O

PhillipGibb (Sat, 09 Jun 2018 04:28:16 GMT):
how did you get past: error: no matching version `^1.0.16` found for package `sodiumoxide`

kdenhartog (Sat, 09 Jun 2018 04:33:10 GMT):
no worries, I didn't encounter that error, but I've seen it before. give me a second and I'll see if I can remember what causes that

kdenhartog (Sat, 09 Jun 2018 04:35:41 GMT):
is this an issue when you're trying to build the node or the sdk image?

PhillipGibb (Sat, 09 Jun 2018 04:40:10 GMT):
when I try to build the docker image in ci/

kdenhartog (Sat, 09 Jun 2018 04:41:27 GMT):
@PhillipGibb what does lines 27 - 31 say on there? I assume they're the same because we're on the same commit but I want to double check

PhillipGibb (Sat, 09 Jun 2018 04:42:55 GMT):
ARG indy_plenum_ver=1.2.389 ARG indy_anoncreds_ver=1.0.32 ARG indy_node_ver=1.3.446 ARG python3_indy_crypto_ver=0.4.1 ARG indy_crypto_ver=0.4.0

kdenhartog (Sat, 09 Jun 2018 04:45:10 GMT):
ok, we're matching on that

PhillipGibb (Sat, 09 Jun 2018 04:47:02 GMT):
I did manage to get an image to run with the pools. Yesterday, I believe that it used sodiumoxide 1.0.14

kdenhartog (Sat, 09 Jun 2018 04:48:41 GMT):
yeah that's what I was thinking, but I'm not finding any sodiumoxide dependecies in the files

kdenhartog (Sat, 09 Jun 2018 04:49:00 GMT):
I know there is one, I just can't remember which repo it's for

kdenhartog (Sat, 09 Jun 2018 04:53:02 GMT):
it looks like the only place it's used is by indy-sdk for a cargo crate

kdenhartog (Sat, 09 Jun 2018 04:55:38 GMT):
I was already planning to build exactly what you're looking for within my next sprint (2 weeks). Would you be able to wait until that's finished and I'll send you the dockerfiles and documentation to test it?

PhillipGibb (Sat, 09 Jun 2018 04:57:37 GMT):
thanks for the help, I am going to have to continue later because I have to go now

kdenhartog (Sat, 09 Jun 2018 04:59:11 GMT):
same, I'll ping you once I get this new stuff built

PhillipGibb (Sat, 09 Jun 2018 12:08:38 GMT):
@kdenhartog I have managed to get the getting* started *

PhillipGibb (Sat, 09 Jun 2018 12:10:13 GMT):
@kdenhartog I have managed to get the getting started docker image going with docker composer up but the url to 8888 does not work so I don't even know if I can connect to the pool with the cli

PhillipGibb (Sat, 09 Jun 2018 12:11:12 GMT):
even if it is working I am struggling to find documentation on the genesis file needed to make a connection to the pool

PhillipGibb (Sat, 09 Jun 2018 12:11:12 GMT):
even if it is working I am struggling to find documentation on the genesis file needed to make a connection to the pool

PhillipGibb (Sat, 09 Jun 2018 12:31:44 GMT):
actually if I use 127.0.0.1:800 I see stuff - what I can do with it is debatable, but there is a genesis file there

PhillipGibb (Sat, 09 Jun 2018 12:33:08 GMT):
I build libindy for my platform (macos) successfully but I can't build cli so the to liblndy is

PhillipGibb (Sat, 09 Jun 2018 12:33:15 GMT):
is pointless

PhillipGibb (Sat, 09 Jun 2018 12:33:51 GMT):
back to an unbuntu docker image to connect to the pool which does not work, I wonder what works

PhillipGibb (Sat, 09 Jun 2018 13:14:21 GMT):
actually creating a pool with the genesis file and connecting results in "Indy SDK error occurred CommonInvalidState" sigh

kdenhartog (Sat, 09 Jun 2018 19:57:14 GMT):
Yeah that's the exact same error I'm getting. I'm going to talk with Slava to see what that means. Sorry about the frustration with running the setup. This is something I'm particularly interested in fixing to create a more consistent on boarding experience and developer experience.

PhillipGibb (Sat, 09 Jun 2018 20:19:49 GMT):
@kdenhartog what I can get right is running indy cli via docker, register a did on the test net them connect to the ledger and query a few things

PhillipGibb (Sat, 09 Jun 2018 20:26:47 GMT):
unfortunately I can't query an attrib - I think that there is a bug there; the help says I can use a few option none of which work and error says I can't use attrib but the example shows it I thought I could query my email

kdenhartog (Sat, 09 Jun 2018 20:34:48 GMT):
What's the error you're receiving when trying to query attrib?

PhillipGibb (Sat, 09 Jun 2018 20:48:35 GMT):
it says attrib is not a valid argument

PhillipGibb (Sat, 09 Jun 2018 20:53:28 GMT):
@kdenhartog I am going to code a few node.js calls using a wrapper, do you know of a guide that displays a recommended guide to kickstart with? e.g. 1. Create wallet if it does not exist (open wallet) 2. Create DID or use one 3. open connection to pool 4. connect to ledger 5. publish a piece of public information that is signed 6. query and verify that info off the ledger

swcurran (Sun, 10 Jun 2018 00:44:29 GMT):
@PhillipGibb - a couple of things. First, the indy-agent - https://github.com/hyperledger/indy-agent- repo has a starter indy reference agent in node. There is a pending PR from BYU, so their repo is a little ahead - https://github.com/byu-oit/indy-agent Next - your step 5 is not how Indy works. Data does not get published on the ledger. The ledger is for keys/endpoints (DIDs, DID Docs), schema, Credential Definitions and related Revocation data.

swcurran (Sun, 10 Jun 2018 00:52:20 GMT):
@kdenhartog - we definitely want to figure out why this was so hard. We've been using docker for 10 months for Indy, and can spin up networks and agents in seconds.

kdenhartog (Sun, 10 Jun 2018 01:03:51 GMT):
Are you guys using make files? I think that's the main problem is that commands are too specific as well as there's some changes happening for 1.5 that are getting node and SDK out of sync occasionally because they were breaking changes.

PhillipGibb (Sun, 10 Jun 2018 06:48:33 GMT):
@swcurran yes, thanks, I understand that - about the data. Huge thanks for pointing me to the reference agent - this is the kind of thing I want to setup

slr (Mon, 11 Jun 2018 16:52:02 GMT):
Has joined the channel.

slr (Mon, 11 Jun 2018 16:53:01 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!

esplinr (Mon, 11 Jun 2018 17:38:59 GMT):
@slr What do you mean by a connection request? You want to establish a DID relationship?

esplinr (Mon, 11 Jun 2018 17:40:34 GMT):
Oh @slr, I see now that you cross posted in a bunch of channels. That makes it hard to know where to assist you in a collaborative way. I think #indy is probably the best place.

slr (Mon, 11 Jun 2018 17:41:02 GMT):
oops sorry about that! I wasn't sure which one to put it in :/

slr (Mon, 11 Jun 2018 17:41:58 GMT):
i ultimately am trying to create a new agent but for starters I was just trying to establish a new DID relationship and see if I understood how that works

slr (Mon, 11 Jun 2018 17:43:56 GMT):
any help would be appreciated!

esplinr (Mon, 11 Jun 2018 17:44:21 GMT):
If it isn't clear where to post, it is best in #indy. That's the catch-all channel.

esplinr (Mon, 11 Jun 2018 17:45:15 GMT):
@swcurran recently put together a document to guide people who want to implement agents. You might find it helpful. https://docs.google.com/document/d/1mRLPOK4VmU9YYdxHJSxgqBp19gNh3fT7Qk4Q069VPY8/edit#

slr (Mon, 11 Jun 2018 17:45:43 GMT):
thanks! i'll check it out

AvikHazra (Wed, 13 Jun 2018 05:56:28 GMT):
Has joined the channel.

tja 16 (Thu, 14 Jun 2018 17:02:37 GMT):
Has joined the channel.

RyanWest (Thu, 14 Jun 2018 17:58:53 GMT):
Trying to install indy-plenum dependencies on Fedora Linux, rocksdb specifically is giving me issues. Looks like other people have had this problem online but has anyone encountered anything like this when installing rocksdb (not python-rocksdb, the actual rocksdb)? ``` CC shared-objects/util/status.o util/status.cc: In static member function ‘static const char* rocksdb::Status::CopyState(const char*)’: util/status.cc:28:15: error: ‘char* strncpy(char*, const char*, size_t)’ output truncated before terminating nul copying as many bytes from a string as its length [- Werror=stringop-truncation] std::strncpy(result, state, cch - 1); ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~ util/status.cc:19:18: note: length computed here std::strlen(state) + 1; // +1 for the null terminator ~~~~~~~~~~~^~~~~~~ ``` I'm on Fedora Linux using gcc 8.1.1.

RyanWest (Thu, 14 Jun 2018 17:58:53 GMT):
Trying to install indy-plenum dependencies on Fedora Linux, rocksdb specifically is giving me issues. Looks like other people have had this problem online but has anyone encountered anything like this when installing `rocksdb` (not python-rocksdb, the actual rocksdb)? ``` CC shared-objects/util/status.o util/status.cc: In static member function ‘static const char* rocksdb::Status::CopyState(const char*)’: util/status.cc:28:15: error: ‘char* strncpy(char*, const char*, size_t)’ output truncated before terminating nul copying as many bytes from a string as its length [- Werror=stringop-truncation] std::strncpy(result, state, cch - 1); ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~ util/status.cc:19:18: note: length computed here std::strlen(state) + 1; // +1 for the null terminator ~~~~~~~~~~~^~~~~~~ ``` I'm on Fedora Linux using gcc 8.1.1.

kdenhartog (Fri, 15 Jun 2018 00:54:45 GMT):
@RyanWest im not sure anyone has ventured into this territory yet. If you figure it out can you document how to setup Indy-node for Fedora?

ashcherbakov (Fri, 15 Jun 2018 07:01:39 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

RyanWest (Tue, 19 Jun 2018 03:22:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=2SuGLFSSfF4Zkr25r) I've solved this problem; all you need to do is open up util/status.cc:19 and change the line `std::strncpy(result, state, cch - 1)` to `std::strncpy(result, state, cch)` . This allows rocksdb to build succefully and then you can do `pip install python-rocksdb`. This will be fixed on the rocksdb side, but I'll post the solution here in case anyone else runs into it until then.

RyanWest (Tue, 19 Jun 2018 15:31:22 GMT):
As another issue, I believe I've found a circular dependency when trying to run the indy-plenum unit tests using Pycharm. When trying to import plenum/server/replica.py, that file tries to import node.py, which tries to import primary_selector.py, which tries to import replica.py, which fails. Issue on Jira: https://jira.hyperledger.org/browse/INDY-1423

akuma921 (Wed, 20 Jun 2018 04:47:14 GMT):
Hi all, need a quick help

akuma921 (Wed, 20 Jun 2018 04:47:29 GMT):
I am setting up my own trust anchor in sandbox

akuma921 (Wed, 20 Jun 2018 04:47:40 GMT):
and want to know how to get 'pubkey' ?

akuma921 (Wed, 20 Jun 2018 04:48:21 GMT):
to execute this command: send ATTRIB dest=ULtgFQJe6bjiFbs7ke3NJD raw={"endpoint": {"ha": "10.0.0.6:5555", "pubkey": "5hmMA64DDQz5NzGJNVtRzNwpkZxktNQds21q3Wxxa62z"}}

akuma921 (Wed, 20 Jun 2018 04:48:29 GMT):
for my own Trust Anchor

tylerhester (Wed, 20 Jun 2018 14:25:46 GMT):
Has joined the channel.

tylerhester (Wed, 20 Jun 2018 14:31:31 GMT):
Hi all! I am trying get up and running with indy and I'm following the "how-tos" on writing a did and querying a verkey. I seem to be having some trouble here. I'm using python, on MacOSX, and running the python file "write_did.py" results in an error `ErrorCode: Pool Genesis Transactions are not compatible with Protocol version Libindy PROTOCOL_VERSION is 1 but Pool Genesis Transactions are of version 1.4` I try adding the following to the code: `await pool.set_protocol_version(2)` and I get another error `AttributeError: module 'indy.pool' has no attribute 'set_protocol_version'` Does anyone have any advice on how to resolve this issue?

gudkov (Wed, 20 Jun 2018 14:57:59 GMT):
@tylerhester You need to update to latest idny sdk master if you want the latest indy node master

tylerhester (Wed, 20 Jun 2018 15:02:06 GMT):
After having pulled the latest indy-sdk, I ran `cargo build` in the libindy folder, and then symlink'd the `libindy.dylib` found in /target/debug/ to /usr/local/lib. I've also exported the path to the dylib in LD_LIBRARY_PATH and DYLD_LIBRARY_PATH

tylerhester (Wed, 20 Jun 2018 15:03:56 GMT):
I'm still encountering the same issue. I feel like I'm missing something.

gudkov (Wed, 20 Jun 2018 15:14:55 GMT):
you need to update python wrapper also

tylerhester (Wed, 20 Jun 2018 15:26:27 GMT):
Is that with `pip3 install python3-indy`?

gudkov (Wed, 20 Jun 2018 15:52:32 GMT):
> pip3 install python3-indy this command install the latest stable version. To install master you need to provide exact version

gudkov (Wed, 20 Jun 2018 15:53:30 GMT):
1.4.0-dev-591

tylerhester (Wed, 20 Jun 2018 16:03:56 GMT):
Awesome! That got it working again. Thank you :)

Qiu (Sun, 24 Jun 2018 17:02:17 GMT):
Has joined the channel.

Qiu (Sun, 24 Jun 2018 17:03:33 GMT):
Hi all! I need help,How to solve this problem? qiubodeMacBook~Pro: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... /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_2204 (Errno::EACCES)

Qiu (Sun, 24 Jun 2018 17:03:33 GMT):
Hi all! I need help,How to solve this problem? qiubodeMacBook~Pro: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... /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_2204 (Errno::EACCES)

Qiu (Sun, 24 Jun 2018 17:03:33 GMT):
Hi all! I need help,How to solve this problem? qiubodeMacBook~Pro: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... /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_2204 (Errno::EACCES)

ryanwest6 (Sun, 24 Jun 2018 20:32:21 GMT):
Did you try it with `sudo vagrant up`?

Qiu (Mon, 25 Jun 2018 06:11:17 GMT):
@ryanwest6 I then started vagrant SHH cli01 to prompt me to perform under the same level of user

Qiu (Mon, 25 Jun 2018 06:46:38 GMT):
Hi everyone!I would like to ask how to solve this problem? indy@sandbox> send NYM dest=Th7MpTaRZVRYnPiabds81Y role=TRUST_ANCHOR verkey=~7TY fekw4GUagBnBVCqPjiC Adding nym Th7MpTaRZVRYnPiabds81Y Error: client request invalid: UnauthorizedClientRequest('STEWARD cannot update role',)

ashcherbakov (Mon, 25 Jun 2018 08:29:30 GMT):
@Qiu Once a new NYM with verkey is onboarded (by a TRUST_ANCHOR), which means that the person this NYM belongs to owns the corresponding private key (this private key must be unknown for the party doing onboarding, that is the Trust Anchor!), then only the person the NYM belongs to can update the NYM (rotate keys for example). No one else (including the Trust Anchor who onboarded the NYM) can do this. This is one of the principles of self-sovereign identity (SSI).

Qiu (Mon, 25 Jun 2018 16:35:21 GMT):
Hi everyone! My OS is ubuntu! I want to ask how to solve this problem? parallels@parallels-vm:~/indy-node/environment/vagrant/training/vb-multi-vm$ sudo vagrant up [sudo] password for parallels: 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: Importing base box 'bento/ubuntu-16.04'... ==> cli01: Matching MAC address for NAT networking... ==> cli01: Checking if box 'bento/ubuntu-16.04' is up to date... ==> cli01: Setting the name of the VM: cli01 ==> 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.

Qiu (Mon, 25 Jun 2018 16:35:21 GMT):
Hi everyone! My OS is ubuntu! I want to ask how to solve this problem? ```parallels@parallels-vm:~/indy-node/environment/vagrant/training/vb-multi-vm$ sudo vagrant up [sudo] password for parallels: 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: Importing base box 'bento/ubuntu-16.04'... ==> cli01: Matching MAC address for NAT networking... ==> cli01: Checking if box 'bento/ubuntu-16.04' is up to date... ==> cli01: Setting the name of the VM: cli01 ==> 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.

K.Amine (Mon, 25 Jun 2018 23:22:42 GMT):
Has joined the channel.

K.Amine (Mon, 25 Jun 2018 23:22:46 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:43:20 GMT):
lib/vagrant/action/builtin

swcurran (Tue, 26 Jun 2018 02:48:12 GMT):
@K.Amine - wallet export/import is coming in the next release (Indy-SDK 1.5). You can just backup and restore the wallet file today. However, you do have to keep the wallet in-sync with the ledger and that can get tricky. You can use seeds to make the ledger sync up with an existing wallet for DIDs, however when you create a CredDef, it internally creates a public/private keypair without a seed, so if you have to sync a CredDef between the wallet and the ledger you are out of luck. As a result, you are generally stuck with how you are doing it. It would be really good if you could use a Seed with a CredDef. I'm not sure about how you would go about snapshotting the ledger and wallets at the same time to enable a known startpoint for a test.

alvaradojl (Tue, 26 Jun 2018 07:57:06 GMT):
Has joined the channel.

Qiu (Tue, 26 Jun 2018 08:22:53 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:44:36 GMT):
```$ vagrant ssh agent01 vagrant@agent02:~$ sudo python3 /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/acme.py --port 6666 --network 10.20.30.102 Loading module /usr/local/lib/python3.5/dist-packages/config/config-crypto-example1.py Module loaded. Client hasn't finished catch-up with Pool Ledger yet or doesn't have sufficient number of connections```

Qiu (Tue, 26 Jun 2018 08:44:36 GMT):
```$ vagrant ssh agent01 vagrant@agent02:~$ sudo python3 /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/acme.py --port 6666 --network 10.20.30.102 Loading module /usr/local/lib/python3.5/dist-packages/config/config-crypto-example1.py Module loaded. Client hasn't finished catch-up with Pool Ledger yet or doesn't have sufficient number of connections```

Qiu (Tue, 26 Jun 2018 08:44:36 GMT):
Hi Everyone!The service will shut down automatically after a while. How to solve this problem? ```$ vagrant ssh agent01 vagrant@agent02:~$ sudo python3 /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/acme.py --port 6666 --network 10.20.30.102 Loading module /usr/local/lib/python3.5/dist-packages/config/config-crypto-example1.py Module loaded. Client hasn't finished catch-up with Pool Ledger yet or doesn't have sufficient number of connections```

Qiu (Tue, 26 Jun 2018 08:44:36 GMT):
Hi Everyone!The service will shut down automatically after a while. How to solve this problem? ```$ vagrant ssh agent01 vagrant@agent02:~$ sudo python3 /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/acme.py --port 6666 --network 10.20.30.102 Loading module /usr/local/lib/python3.5/dist-packages/config/config-crypto-example1.py Module loaded. ------------------------------------------------------------------ERROR------------------------------------------------------------------ Agent startup failed: [cause : Client hasn't finished catch-up with Pool Ledger yet or doesn't have sufficient number of connections] ------------------------------------------------------------------ERROR------------------------------------------------------------------```

Qiu (Tue, 26 Jun 2018 08:44:36 GMT):
Hi Everyone!The service will shut down automatically after a while. How to solve this problem? ```$ vagrant ssh agent01 vagrant@agent02:~$ sudo python3 /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/acme.py --port 6666 --network 10.20.30.102 Loading module /usr/local/lib/python3.5/dist-packages/config/config-crypto-example1.py Module loaded. ------------------------------------------------------------------ERROR------------------------------------------------------------------ 'Agent startup failed: [cause : Client hasn't finished catch-up with Pool Ledger yet or doesn't have sufficient number of connections]' ------------------------------------------------------------------ERROR------------------------------------------------------------------```

Qiu (Tue, 26 Jun 2018 08:44:36 GMT):
Hi Everyone!The service will shut down automatically after a while. How to solve this problem? ```$ vagrant ssh agent01 vagrant@agent02:~$ sudo python3 /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/acme.py --port 6666 --network 10.20.30.102 Loading module /usr/local/lib/python3.5/dist-packages/config/config-crypto-example1.py Module loaded. ------------------------------------------------------------------ERROR------------------------------------------------------------------ "Agent startup failed: [cause : Client hasn't finished catch-up with Pool Ledger yet or doesn't have sufficient number of connections]" ------------------------------------------------------------------ERROR------------------------------------------------------------------```

Qiu (Tue, 26 Jun 2018 08:44:36 GMT):
Hi Everyone!The service will shut down automatically after a while. How to solve this problem? ```$ vagrant ssh agent01 vagrant@agent01:~$ sudo python3 /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/acme.py --port 6666 --network 10.20.30.102 Loading module /usr/local/lib/python3.5/dist-packages/config/config-crypto-example1.py Module loaded. ------------------------------------------------------------------ERROR------------------------------------------------------------------ "Agent startup failed: [cause : Client hasn't finished catch-up with Pool Ledger yet or doesn't have sufficient number of connections]" ------------------------------------------------------------------ERROR------------------------------------------------------------------```

Qiu (Tue, 26 Jun 2018 08:44:36 GMT):
Hi Everyone!The service will shut down automatically after a while. How to solve this problem? ```$ vagrant ssh agent01 vagrant@agent01:~$ sudo python3 /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/acme.py --port 6666 --network 10.20.30.101 Loading module /usr/local/lib/python3.5/dist-packages/config/config-crypto-example1.py Module loaded. ------------------------------------------------------------------ERROR------------------------------------------------------------------ "Agent startup failed: [cause : Client hasn't finished catch-up with Pool Ledger yet or doesn't have sufficient number of connections]" ------------------------------------------------------------------ERROR------------------------------------------------------------------```

Qiu (Tue, 26 Jun 2018 08:44:36 GMT):
Hi Everyone!The service will shut down automatically after a while. How to solve this problem? ```$ vagrant ssh agent01 vagrant@agent01:~$ sudo python3 /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/acme.py --port 5555 --network 10.20.30.101 Loading module /usr/local/lib/python3.5/dist-packages/config/config-crypto-example1.py Module loaded. ------------------------------------------------------------------ERROR------------------------------------------------------------------ "Agent startup failed: [cause : Client hasn't finished catch-up with Pool Ledger yet or doesn't have sufficient number of connections]" ------------------------------------------------------------------ERROR------------------------------------------------------------------```

Qiu (Tue, 26 Jun 2018 08:44:36 GMT):
Hi Everyone!The service will shut down automatically after a while. How to solve this problem? ```$ vagrant ssh agent01 vagrant@agent01:~$ sudo python3 /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/acme.py --port 5555 --network 10.20.30.101 Loading module /usr/local/lib/python3.5/dist-packages/config/config-crypto-example1.py Module loaded. ------------------------------------------------------------------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```

Qiu (Tue, 26 Jun 2018 08:44:36 GMT):
Hi Everyone!The service will shut down automatically after a while. How to solve this problem? ```$ vagrant ssh agent01 vagrant@agent01:~$ sudo python3 /usr/local/lib/python3.5/dist-packages/indy_client/test/agent/acme.py --port 5555 --network 10.20.30.101 Loading module /usr/local/lib/python3.5/dist-packages/config/config-crypto-example1.py Module loaded. ------------------------------------------------------------------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```

ltzMaxwell (Tue, 26 Jun 2018 14:23:48 GMT):
Has joined the channel.

ltzMaxwell (Tue, 26 Jun 2018 14:25:46 GMT):
Is there a built 'indycore' image that could be used out of box?_

ltzMaxwell (Tue, 26 Jun 2018 14:26:51 GMT):
the building process always failed due to apt repo issues (no pub key available)

ltzMaxwell (Tue, 26 Jun 2018 15:00:15 GMT):

Clipboard - June 26, 2018 10:59 PM

ltzMaxwell (Tue, 26 Jun 2018 15:00:53 GMT):
Hi , guys , indycore always build fail, any clues?

K.Amine (Tue, 26 Jun 2018 15:50:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=RJSSEzrNAHLsWhRR7) @swcurran seems a bit complicated, I will rather try to debug my pipeline a small dataset

RyanWest (Tue, 26 Jun 2018 17:25:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=PTur2eozHJ3p92Zso) @Qiu Hey Qiu, using vagrant to build the sdk is no longer actively supported. We suggest using Docker to run the test pool instead, which is much more likely to work without error. https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker

ltzMaxwell (Wed, 27 Jun 2018 03:42:27 GMT):
@RyanWest Hi ,do we have an already built indy_pool image? cuz it always comes error in building process.

ltzMaxwell (Wed, 27 Jun 2018 06:38:19 GMT):
`Hit:1 http://archive.ubuntu.com/ubuntu xenial InRelease Hit:2 http://security.ubuntu.com/ubuntu xenial-security InRelease Get:3 http://archive.ubuntu.com/ubuntu xenial-updates InRelease [109 kB] Get:4 http://archive.ubuntu.com/ubuntu xenial-backports InRelease [107 kB] Ign:5 https://repo.sovrin.org/deb xenial InRelease Ign:6 https://repo.sovrin.org/deb xenial Release Ign:7 https://repo.sovrin.org/deb xenial/master amd64 Packages Ign:8 https://repo.sovrin.org/deb xenial/master all Packages Ign:7 https://repo.sovrin.org/deb xenial/master amd64 Packages Ign:8 https://repo.sovrin.org/deb xenial/master all Packages Ign:7 https://repo.sovrin.org/deb xenial/master amd64 Packages Ign:8 https://repo.sovrin.org/deb xenial/master all Packages Ign:7 https://repo.sovrin.org/deb xenial/master amd64 Packages Ign:8 https://repo.sovrin.org/deb xenial/master all Packages Ign:7 https://repo.sovrin.org/deb xenial/master amd64 Packages Ign:8 https://repo.sovrin.org/deb xenial/master all Packages Err:7 https://repo.sovrin.org/deb xenial/master amd64 Packages gnutls_handshake() failed: An unexpected TLS packet was received. Ign:8 https://repo.sovrin.org/deb xenial/master all Packages Fetched 216 kB in 2min 22s (1516 B/s) Reading package lists... Done W: The repository 'https://repo.sovrin.org/deb xenial Release' does not have a Release file. N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use. N: See apt-secure(8) manpage for repository creation and user configuration details. E: Failed to fetch https://repo.sovrin.org/deb/dists/xenial/master/binary-amd64/Packages gnutls_handshake() failed: An unexpected TLS packet was received. E: Some index files failed to download. They have been ignored, or old ones used instead.`

swcurran (Wed, 27 Jun 2018 14:04:25 GMT):
@ltzMaxwell - von-image is available from the BC Gov on hub.docker.com. It contains both indy-node and indy-sdk in the image and has been optimized for size. Docker: https://hub.docker.com/r/bcgovimages/von-image/ - github repo for the image is here - https://github.com/PSPC-SPAC-buyandsell/von-image There is also von-network which makes it easy to spin up a new Sovrin network - https://github.com/bcgov/von-network

ryanwest6 (Wed, 27 Jun 2018 14:37:42 GMT):
2'

ryanwest6 (Wed, 27 Jun 2018 14:41:17 GMT):
@ltzMaxwell, in addition to @swcurran's response, there is also a docker setup available for creating your own test network at https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker.

ltzMaxwell (Wed, 27 Jun 2018 14:43:01 GMT):
@swcurran @ryanwest6 Thanks guys.

ltzMaxwell (Wed, 27 Jun 2018 14:44:17 GMT):
The previous problem's been solved, it's a connection issue due to VPN.

swcurran (Wed, 27 Jun 2018 14:59:08 GMT):
Yup...spinning up a network is easy, and problems tend to be in two areas - IP address between the two systems (e.g. on Windows getting the correct DOCKERHOST IP, VPNs, etc.) and mismatched client/node versions.

ltzMaxwell (Wed, 27 Jun 2018 15:01:22 GMT):
Hmm, I'll try this out, thanks for your tip~

swcurran (Wed, 27 Jun 2018 15:02:27 GMT):
Oh...and people trying to build natively. Docker is your friend!!

ltzMaxwell (Wed, 27 Jun 2018 15:03:00 GMT):
:rofl:

arunwij (Fri, 29 Jun 2018 05:52:13 GMT):
Has joined the channel.

LuigiRiva (Fri, 29 Jun 2018 13:27:09 GMT):
Has joined the channel.

LuigiRiva (Fri, 29 Jun 2018 14:29:48 GMT):
Hello everyone, just new to Indy, internally in my company we would like to set up a test env and start playing with it. Could everyone point me out at the right resource in order to do that or, even better, provide me a comprehensive lists of tasks that should be done for having an indy env up & running?

ryanwest6 (Sat, 30 Jun 2018 02:27:28 GMT):
Hi @LuigiRiva, you are looking for the #indy-sdk channel. www.github.com/hyperledger/indy-sdk has information on how to set up a test network with Docker, though it is still deep in development.

KanupriyaPandey (Mon, 02 Jul 2018 05:43:51 GMT):
Has joined the channel.

LuigiRiva (Mon, 02 Jul 2018 08:56:49 GMT):
@ryanwest6 thanks!

ThomasKrech (Tue, 03 Jul 2018 09:45:30 GMT):
Has joined the channel.

VitalijReicherdt (Tue, 03 Jul 2018 09:47:11 GMT):
Has joined the channel.

Qiu (Wed, 04 Jul 2018 03:20:35 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``` ```

Qiu (Wed, 04 Jul 2018 03:20:35 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```

pradeeppadmarajaiah (Wed, 04 Jul 2018 07:06:39 GMT):
Has joined the channel.

pradeeppadmarajaiah (Wed, 04 Jul 2018 07:06:44 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

herveblanc (Thu, 05 Jul 2018 15:49:48 GMT):
Has joined the channel.

ashcherbakov (Mon, 09 Jul 2018 13:58:25 GMT):
@Qiu This getting started is deprecated. Please use the following one: https://github.com/hyperledger/indy-sdk/tree/master/doc/getting-started

ashcherbakov (Mon, 09 Jul 2018 13:58:37 GMT):
@pradeeppadmarajaiah You can start with ttps://github.com/hyperledger/indy-sdk/tree/master/doc/getting-started

ashcherbakov (Mon, 09 Jul 2018 13:58:37 GMT):
@pradeeppadmarajaiah You can start with https://github.com/hyperledger/indy-sdk/tree/master/doc/getting-started

LuigiRiva (Mon, 09 Jul 2018 14:30:59 GMT):
hi @ashcherbakov I just managed to install the getting started correctly but when I start the jupiter notebook, even if everything works fine if I execute the provided code into the jupiter

LuigiRiva (Mon, 09 Jul 2018 14:31:20 GMT):
I got an error while calling create_wallet functionality

LuigiRiva (Mon, 09 Jul 2018 14:31:21 GMT):
and now the error is: "Sovrin Steward" -> Create wallet Function indy_create_wallet returned error 103 NameError: name 'IndyError' is not defined

LuigiRiva (Mon, 09 Jul 2018 14:31:57 GMT):
any idea if it could be related to something I made wrong while installing or perhaps the code is decprecated?

ashcherbakov (Mon, 09 Jul 2018 14:43:33 GMT):
Please ask in #indy-sdk channel

smithbk (Mon, 09 Jul 2018 20:18:20 GMT):
Could someone help with https://jira.hyperledger.org/browse/IS-800 please? I am blocked and even though it is opened against indy-sdk, we need help from the indy-node side to know why the hashes don't match. All version info is included in the comments

gudkov (Tue, 10 Jul 2018 08:17:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=QhhK5ySjfgEnDRQuE) @smithbk I believe in the ticket there is a clear answer. You have changed port in genesis transactions that caused different merkle trees on client and on ledger side. What additional help do you want?

gudkov (Tue, 10 Jul 2018 08:18:56 GMT):
To help you we need the list of steps that you performed from the very beginning. Remove all images. Start from scratch and document all steps you performed.

gudkov (Tue, 10 Jul 2018 08:21:10 GMT):
See comment https://jira.hyperledger.org/browse/IS-800?focusedCommentId=47135&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-47135

pradeeppadmarajaiah (Tue, 10 Jul 2018 08:46:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=K8BPm3vmhZ4Eq4bpu) @ashcherbakov Thank you. I want to try Java based samples. Throwing error while running samples. Is there proper documentation for setting up the environment like Getting started

pradeeppadmarajaiah (Tue, 10 Jul 2018 08:46:24 GMT):
??

ashcherbakov (Tue, 10 Jul 2018 10:53:31 GMT):
@pradeeppadmarajaiah You can try https://github.com/hyperledger/indy-sdk/tree/master/samples/java

pradeeppadmarajaiah (Tue, 10 Jul 2018 11:20:52 GMT):
Raised issue while running this sample 931,932 and 934

pradeeppadmarajaiah (Tue, 10 Jul 2018 11:21:05 GMT):
I like to do a setup on windows

smithbk (Tue, 10 Jul 2018 12:02:22 GMT):
@gudkov I included additional info in https://jira.hyperledger.org/browse/IS-800 ... thanks

ashcherbakov (Tue, 10 Jul 2018 12:40:53 GMT):
@smithbk We left 2 comments in IS-800 that may help

tomislav (Tue, 10 Jul 2018 19:05:29 GMT):
Has joined the channel.

Abhishek_Tyagi (Wed, 11 Jul 2018 06:41:39 GMT):
Has joined the channel.

Abhishek_Tyagi (Wed, 11 Jul 2018 06:42:36 GMT):
Hello,

Abhishek_Tyagi (Wed, 11 Jul 2018 06:51:34 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 but could not understand the architecture. Some of my questions are: - Where the Public keys are stored and how to look for them? - How Acme Corp. know that the Proof Request was fulfilled with the correct previous claim(i.e. Faber transcript)? - How to run the network again and revive all the history after closing the network once (for ex. If I sign out from CLI01 and agents today and then tomorrow I want to continue from where I last left, is it possible?) Moreover, I now want to customize the nodes (My own agents instead of Faber, Acme or Thrift, and my own indy files). Would anyone please care to explain how to proceed further? Thanks,

Abhishek_Tyagi (Wed, 11 Jul 2018 06:51:34 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 but could not understand the architecture. Some of my questions are: - Where the Public keys are stored and how to look for them? - How Acme Corp. know that the Proof Request was fulfilled with the correct previous claim(i.e. Faber transcript)? - How to run the network again and revive all the history after closing the network once (for ex. If I sign out from CLI01 and agents today and then tomorrow I want to continue from where I last left, is it possible?) Moreover, I now want to customize the nodes (My own agents instead of Faber, Acme or Thrift, and my own indy files). Would anyone please care to explain how to proceed further? Thanks, Abhishek Tyagi P.S. I am working on Windows10.

Abhishek_Tyagi (Wed, 11 Jul 2018 06:51:34 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 but could not understand the architecture. Some of my questions are: - Where the Public keys are stored and how to look for them? - How Acme Corp. knows that the Proof Request was fulfilled with the correct previous claim(i.e. Faber transcript)? - How to run the network again and revive all the history after closing the network once (for ex. If I sign out from CLI01 and agents today and then tomorrow I want to continue from where I last left, is it possible?) Moreover, I now want to customize the nodes (My own agents instead of Faber, Acme or Thrift, and my own indy files). Would anyone please care to explain how to proceed further? Thanks, Abhishek Tyagi P.S. I am working on Windows10.

n3m (Wed, 11 Jul 2018 07:32:30 GMT):
Has joined the channel.

wightman (Wed, 11 Jul 2018 21:18:52 GMT):
Has left the channel.

nikhil.kumar (Thu, 12 Jul 2018 05:37:36 GMT):
Has joined the channel.

Khaled.MH (Thu, 12 Jul 2018 13:54:09 GMT):
Has joined the channel.

KevinBai (Fri, 13 Jul 2018 03:11:33 GMT):
Has left the channel.

sammitchell (Fri, 13 Jul 2018 07:44:36 GMT):
Has joined the channel.

kendra.bittner (Fri, 13 Jul 2018 16:40:54 GMT):
Has joined the channel.

baconsandwich (Fri, 13 Jul 2018 21:00:28 GMT):
Has joined the channel.

PeterX (Sun, 15 Jul 2018 07:44:28 GMT):
Has joined the channel.

DoctorX (Sun, 15 Jul 2018 12:33:01 GMT):
Has joined the channel.

DoctorX (Mon, 16 Jul 2018 12:30:26 GMT):

Clipboard - July 16, 2018 8:29 PM

stefanopulzeic (Tue, 17 Jul 2018 07:46:23 GMT):
Has joined the channel.

fabienpe (Tue, 17 Jul 2018 13:36:04 GMT):
Has joined the channel.

Ribas (Wed, 18 Jul 2018 13:05:26 GMT):
Has joined the channel.

dklesev (Wed, 18 Jul 2018 14:58:06 GMT):
Has joined the channel.

thPart (Thu, 19 Jul 2018 07:35:02 GMT):
Has joined the channel.

Sergey.Kupryushin (Thu, 19 Jul 2018 14:01:48 GMT):
Has joined the channel.

devin-fisher (Fri, 20 Jul 2018 15:31:40 GMT):
Does anyone know were we got the python3 packages on 'https://repo.sovrin.org/deb/pool/xenial/stable/p/'. The python3-psutil broke my system. It is not compatible with mint 19. I would expect all distributions to have many if not all of these common python Debian packages. I doubt we want to sign up to make sure that these packages work for all system that could install them. Is there a reason we don't use the package from the distribution?

BlockchainBusiness (Tue, 24 Jul 2018 02:06:25 GMT):
Has joined the channel.

Gokulraja (Tue, 24 Jul 2018 05:29:16 GMT):
Has joined the channel.

PeterX (Tue, 24 Jul 2018 06:28:18 GMT):

Clipboard - July 24, 2018 2:28 PM

PeterX (Tue, 24 Jul 2018 06:28:46 GMT):
hi, all, when I follow this document "https://github.com/hyperledger/indy-node/blob/stable/docs/start-nodes.md" to start the indy node on my local machine. when I execute "init_indy_node Alpha 0.0.0.0 9701 0.0.0.0 9702 [--seed 111111111111111111111111111Alpha]", It throw an error like above.

PeterX (Tue, 24 Jul 2018 06:29:39 GMT):
Many thanks if anyone can help to figure out the reason

PeterX (Tue, 24 Jul 2018 06:35:09 GMT):
@ashcherbakov , could you help to give me some guidance? Many thanks!

ashcherbakov (Tue, 24 Jul 2018 07:13:58 GMT):
@PeterX Please use docker to start the nodes https://github.com/hyperledger/indy-node/tree/master/environment/docker/pool If you (for some reasons) still want to run a node locally, then, as mentioned in https://github.com/hyperledger/indy-node/blob/stable/docs/start-nodes.md, ``` the following needs to be added: NETWORK_NAME={network_name} where {network_name} matches the one in genesis transaction files above ``` So, you need to add `NETWORK_NAME='sandbox'` to ``/etc/indy/indy_config.py`

ashcherbakov (Tue, 24 Jul 2018 07:13:58 GMT):
@PeterX Please use docker to start the nodes https://github.com/hyperledger/indy-node/tree/master/environment/docker/pool If you (for some reasons) still want to run a node locally, then, as mentioned in https://github.com/hyperledger/indy-node/blob/stable/docs/start-nodes.md, ``` the following needs to be added: NETWORK_NAME={network_name} where {network_name} matches the one in genesis transaction files above ``` So, you need to add `NETWORK_NAME='sandbox'` to `/etc/indy/indy_config.py`

PeterX (Tue, 24 Jul 2018 07:24:36 GMT):
@ashcherbakov , Many thanks for your response, I will have a try.

PeterX (Wed, 25 Jul 2018 09:49:07 GMT):
Hi all , I have a question about add a new node to a existed node pool, described as below: I have created a node pool follow the document: https://github.com/hyperledger/indy-node/blob/stable/docs/start-nodes.md Now the pool has four nodes: Node1, Node2, Node3, Node4 1. Use "send NODE" command with indy cli to add "Node5" 2. After add Node5, I found there is errro log on Node1, Node2, Node3, Node4, like below: 2018-07-25 05:47:00,050|ERROR|node.py|Node1 commit failed for batch request, error PublicKeyNotFoundOnDisk("Node1 could not get Node5's public key from disk. Make sure the keys are initialized for this remote or provided explicitly.",) 3. The I use "init_indy_node Node5 0.0.0.0 9709 0.0.0.0 9710" to generate keys. 4. After generate keys for Node5, I found the keys are generated on /var/lib/indy/localpool/keys/Node5 folder, but in /var/lib/indy/localpool/keys/Node1, there is still no key file about Node5, so in Node1 there are still error like: raise PublicKeyNotFoundOnDisk(self.name, name) stp_core.network.exceptions.PublicKeyNotFoundOnDisk: Node1 could not get Node5's public key from disk. Make sure the keys are initialized for this remote or provide d explicitly. Anyone know what's going wrong? or any materials or documents about adding a new node to existed node pool? Many thanks for your help.

PeterX (Wed, 25 Jul 2018 09:49:07 GMT):
Hi all , I have a question about add a new node to a existed node pool, described as below: I have created a node pool follow the document: https://github.com/hyperledger/indy-node/blob/stable/docs/start-nodes.md Now the pool has four nodes: Node1, Node2, Node3, Node4 1. Use "send NODE" command with indy cli to add "Node5" 2. After add Node5, I found there is errro log on Node1, Node2, Node3, Node4, like below: 2018-07-25 05:47:00,050|ERROR|node.py|Node1 commit failed for batch request, error PublicKeyNotFoundOnDisk("Node1 could not get Node5's public key from disk. Make sure the keys are initialized for this remote or provided explicitly.",) 3. The I use "init_indy_node Node5 0.0.0.0 9709 0.0.0.0 9710" to generate keys. 4. After generate keys for Node5, I found the keys are generated on /var/lib/indy/localpool/keys/Node5 folder, but in /var/lib/indy/localpool/keys/Node1, there is still no key file about Node5, so in Node1 there are still error like: raise PublicKeyNotFoundOnDisk(self.name, name) stp_core.network.exceptions.PublicKeyNotFoundOnDisk: Node1 could not get Node5's public key from disk. Make sure the keys are initialized for this remote or provide d explicitly. Anyone know what's going wrong? or any materials or documents about adding a new node to existed node pool? Many thanks for your help.

PeterX (Wed, 25 Jul 2018 09:57:51 GMT):
@ashcherbakov , could you help to have a look? Many thanks!

zhigunenko.dsr (Wed, 25 Jul 2018 10:49:05 GMT):
Hi @PeterX, what did you mean by "add Node5" ? Run command in CLI is not enough. Please check that you didn't miss these steps: 1) copy pool_transactions_genesis file from one of existing node to %node5_host%:/var/lib/indy/%network_name%/ 2) copy domain_transactions_genesis file to %node5_host%:/var/lib/indy/localpool/ 3) NODE5: run "init_indy_node Node5 0.0.0.0 9709 0.0.0.0 9710" 4) CLI: use existing Trustee DID for new Steward DID creation 5) CLI: use new Steward DID for "ledger node" sending 6) NODE5: run "systemctl start indy_node" to start up Node service If you still have problems - please contact me directly

PeterX (Wed, 25 Jul 2018 10:54:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=xhC2Z5sS8dftZHnzB) @zhigunenko.dsr Many thanks for your response, you are right, only cli command "send node" is not enough, I have tried generate keys, create steward and so on. And I will try your steps later. Thanks again!

PeterX (Wed, 25 Jul 2018 12:37:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=3dSsgQ3fZAhYqhNK4) Hi, @zhigunenko.dsr , After I executed step 3, I checked the public keys in the /var/lib/indy/localpool, I found:

PeterX (Wed, 25 Jul 2018 12:37:30 GMT):

Clipboard - July 25, 2018 8:37 PM

PeterX (Wed, 25 Jul 2018 12:38:39 GMT):
@zhigunenko.dsr , Node5 just have Node3.key, but other nodes have Node1.key, Node2.key, Node3.key, Node4.key, Is there any issue here?

zhigunenko.dsr (Wed, 25 Jul 2018 12:46:25 GMT):
no, there is no expected changes on Node5 before you finished step 6

zhigunenko.dsr (Wed, 25 Jul 2018 12:46:25 GMT):
@PeterX no, there is no expected changes on Node5 before you finished step 6

PeterX (Wed, 25 Jul 2018 12:51:08 GMT):
@zhigunenko.dsr , got it, thanks

PeterX (Wed, 25 Jul 2018 12:51:24 GMT):

Clipboard - July 25, 2018 8:51 PM

PeterX (Wed, 25 Jul 2018 12:52:08 GMT):

Clipboard - July 25, 2018 8:52 PM

PeterX (Wed, 25 Jul 2018 12:53:11 GMT):
@zhigunenko.dsr , when I do step 4, I found the error: Error: client request invalid: CouldNotAuthenticate('Can not find verkey for 92PMXtzRGuTAhAK5xPbwqq',), Is there anything wrong about my commands?

zhigunenko.dsr (Wed, 25 Jul 2018 13:00:28 GMT):
@PeterX yes. "new key" command switch your current DID to fresh generated. Execute "did use V4SGRU86Z58d6TV7PBUe6f" before send NYM to ledger

PeterX (Wed, 25 Jul 2018 13:02:04 GMT):
@zhigunenko.dsr , :sweat_smile: many thanks for your remind!

PeterX (Wed, 25 Jul 2018 13:18:26 GMT):
@zhigunenko.dsr , thanks for your help, I have finished the steps, and added the node to the pool successfully.

PeterX (Thu, 26 Jul 2018 01:05:00 GMT):
@zhigunenko.dsr , 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 01:05:14 GMT):

Clipboard - July 26, 2018 9:05 AM

PeterX (Thu, 26 Jul 2018 01:05:55 GMT):

Clipboard - July 26, 2018 9:05 AM

PeterX (Thu, 26 Jul 2018 07:28:51 GMT):
Hi all, I have read a doc about node pool upgrade: https://github.com/hyperledger/indy-node/blob/master/docs/pool-upgrade.md, but there is no operation steps that describe how to upgrade a existed node pool, is anyone can share a doc about the operation steps?

PeterX (Thu, 26 Jul 2018 09:03:53 GMT):
@zhigunenko.dsr , are you online? could you help to have a look my questions?

zhigunenko.dsr (Thu, 26 Jul 2018 10:36:14 GMT):
@PeterX sorry for the delayed response about new CLI - you can't just open another program and continue work. You need create pool again (names no matters) and migrate your wallet if needed (see script here https://github.com/hyperledger/indy-sdk/blob/master/cli/README.md ) about node pool upgrade - you can just type "ledger pool-upgrade help" in your CLI (syntax is for new indy-cli)

PeterX (Thu, 26 Jul 2018 10:45:18 GMT):
@zhigunenko.dsr , thanks for your response, I want to confirm one thing, "You need create pool again " means I need to create another node pool? or I can use the existed node pool, and just need migrate my wallet?

zhigunenko.dsr (Thu, 26 Jul 2018 10:55:35 GMT):
you can use the existed pool, but before connect you need type something like "pool create localpool gen_txn_file=./indy_cli/networks/localpool/pool_transactions_genesis"

zhigunenko.dsr (Thu, 26 Jul 2018 10:55:35 GMT):
@PeterX you can use the existed pool, but before connect you need type something like "pool create localpool gen_txn_file=./indy_cli/networks/localpool/pool_transactions_genesis"

PeterX (Thu, 26 Jul 2018 11:02:30 GMT):
@zhigunenko.dsr , seems I got it, many thanks for your help, I will try it later.

PeterX (Thu, 26 Jul 2018 12:18:16 GMT):
@zhigunenko.dsr , thanks for your help. 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.", do you know how to get the sha256 of a package? BTW, my current indy node version is “indy-node 1.4.66”.

zhigunenko.dsr (Thu, 26 Jul 2018 12:32:07 GMT):
@PeterX at this moment it doesn't matter, you can include any valid sha256 hash

PeterX (Thu, 26 Jul 2018 12:42:46 GMT):
@zhigunenko.dsr , got it, I will have a try.

PeterX (Thu, 26 Jul 2018 12:57:23 GMT):
@zhigunenko.dsr , one more question what to ask you, about the package version, my current indy-node version is 1.4.66, which is the latest stable version, so can I use the master version as the upgrade target version? like "indy-node_1.5.511_amd64.deb "?

zhigunenko.dsr (Thu, 26 Jul 2018 13:01:09 GMT):
@PeterX yes, but you will do it at your own risk. you can switch from stable repo to master, but success is probable, but not guaranteed. Also master is a branch under development, so you can face with some fresh bugs

PeterX (Thu, 26 Jul 2018 13:01:52 GMT):
@zhigunenko.dsr , got it, thanks!

matthewdavie (Thu, 26 Jul 2018 17:21:38 GMT):
Has joined the channel.

mgbailey (Thu, 26 Jul 2018 20:08:16 GMT):
We are now able to designate 2 IP addresses, on 2 NICs, for incoming traffic on a validator, one for client traffic, and one for inter-node traffic. My question is, which of these IP addresses is used for outgoing communications to the other validators?

mgbailey (Thu, 26 Jul 2018 20:18:53 GMT):
Question 2: How do we change a Node that was configured to use 1 IP address to use 2 instead? If we just add lines to /etc/indy/indy.env will that be all that is needed to make the change as far as Indy is concerned? I.e.: NODE_CLIENT_IP=10.20.30.205 NODE_CLIENT_PORT=10.20.30.206 Obviously there will be changes needed in routing tables, etc., in addition.

mgbailey (Thu, 26 Jul 2018 20:18:53 GMT):
Question 2: How do we change a Node that was configured to use 1 IP address to use 2 instead? If we just add lines to /etc/indy/indy.env will that be all that is needed to make the change as far as Indy is concerned? I.e.: NODE_IP=10.20.30.205 CLIENT_IP=10.20.30.206 Obviously there will be changes needed in routing tables, etc., in addition.

mgbailey (Thu, 26 Jul 2018 20:35:01 GMT):
Oh, and we will need to update the NODE entries on the ledger to show the 2 IP addresses as well, of course.

DoctorX (Fri, 27 Jul 2018 07:20:33 GMT):
Hi @danielhardman, have the Indy released for production use?

danielhardman (Fri, 27 Jul 2018 15:34:33 GMT):
The first network that uses Indy became available to the world in a provisional state in July 2017. At that time, the Indy codebase was given a 1.0 version number, because it had been wholly built within Sovrin, and Sovrin believed that it had reached 1.0 quality. The code was good enough to guarantee that permanent identities could be built upon it, and never lost. However, the Sovrin network itself (not its code) was given a "provisional" status because there were some legalities that needed time to mature, and because the deployment of the code wasn't ready for crushing traffic. Now, at that time, the code had just been transferred to Hyperledger as the Indy codebase, and Hyperledger doesn't like to assign 1.0 version numbers while projects are still in incubation. So from a Hyperledger perspective, giving the code a 1.0 version was a bit surprising. We've worked hard to mature the code for an additional year now, and I personally think it's reasonable to build production systems upon it. Evernym (the company I work for) is doing so. The code has been released multiple times (on a semi-regular cadence), and its stability and security posture are moderately well understood. However, it is not officially out of Hyperledger's incubation status (though it's close). Whether it meets the needs of a particular production deployment scenario is something you will have to judge for yourself by reading the jira issues and inspecting the release notes of indy-node and indy-sdk.

DoctorX (Sat, 28 Jul 2018 05:20:22 GMT):
@danielhardman thanks, Daniel. I will keep looking into it.

DoctorX (Sat, 28 Jul 2018 05:27:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=rN2X7767P8HRXNzb7) @danielhardman Thanks, Daniel. The indy design is very good and it's useful. I will keep eyes on it.

sauravverma (Sun, 29 Jul 2018 20:53:36 GMT):
Has joined the channel.

benlongstaff (Mon, 30 Jul 2018 02:59:12 GMT):
Has joined the channel.

RuWander (Tue, 31 Jul 2018 08:32:53 GMT):
Has joined the channel.

fabienpe (Tue, 31 Jul 2018 13:06:00 GMT):
I used to (before move from Sovrin to Indy) be able to run the `getting_started.py` (which is now in `indy-node/indy_client/test/training/`). But now, this just does not work and there are many error popping. I realise that there is a new `getting_started.py` in the `indy-sdk` project but its implementation is completely different. In particular it does not seem to have the concept of agents. Besides the `indy-agent` project has not been updated for months... so what's you recommendation to build a simple demo with a ledger running on docker and and few agents talking to each other running a separate processes?

fabienpe (Tue, 31 Jul 2018 13:06:00 GMT):
I used to (before move from Sovrin to Indy) be able to run the `getting_started.py` (which is now in `indy-node/indy_client/test/training/`). But now, this just does not work and there are many errors popping. I realise that there is a new `getting_started.py` in the `indy-sdk` project but its implementation is completely different. In particular it does not seem to have the concept of agents. Besides the `indy-agent` project has not been updated for months... so what's your recommendation to build a simple demo with a ledger running on docker and and few agents talking to each other running a separate processes?

mboyd (Tue, 31 Jul 2018 17:41:11 GMT):
Hi @fabienpe, we are trying to clean up our repositories to reduce confusion when developers get started. Right now, one of the best ways to bootstrap your knowledge of the indy code is to read through the code and run the demos in our python wrapper folder: https://github.com/hyperledger/indy-sdk/tree/master/wrappers/python

pradeeppadmarajaiah (Thu, 02 Aug 2018 10:05:56 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

ashcherbakov (Thu, 02 Aug 2018 14:49:24 GMT):
Hi @pradeeppadmarajaiah You can have a look at https://github.com/hyperledger/indy-plenum/tree/master/docs and https://github.com/hyperledger/indy-node/tree/master/docs

esplinr (Thu, 02 Aug 2018 20:19:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=ZLwbzLZfQibMkMTYy) @devin-fisher I asked the team about this. We only ship packages that are newer than the ones in the default repositories.

esplinr (Thu, 02 Aug 2018 20:22:26 GMT):
Currently Indy Node is only tested with Ubuntu 16.04. We want to upgrade to 18.04, remove the dependencies on specific versions of specific packages, and support a broader range of systems. But currently we aren't surprised to hear that there are problems with other platforms, especially newer ones.

pradeeppadmarajaiah (Fri, 03 Aug 2018 06:56:55 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=ER5pADexKBZzGXTD4) @ashcherbakov Thanks . Will have a look into

RubenLassau-Strauven (Fri, 03 Aug 2018 07:21:14 GMT):
Has joined the channel.

zickau (Fri, 03 Aug 2018 09:59:36 GMT):
Has joined the channel.

Aschi (Fri, 03 Aug 2018 12:26:16 GMT):
Has joined the channel.

Gokulraja (Mon, 06 Aug 2018 05:19:45 GMT):
Has left the channel.

bsuichies (Mon, 06 Aug 2018 09:54:31 GMT):
Has joined the channel.

rmarsh (Tue, 07 Aug 2018 21:37:51 GMT):
Has joined the channel.

NataliaDracheva (Thu, 09 Aug 2018 12:54:20 GMT):
Has joined the channel.

VuiLenDi (Mon, 13 Aug 2018 08:40:19 GMT):
Has joined the channel.

baconsandwich (Tue, 14 Aug 2018 11:18:52 GMT):
Is this the place to ask question specific to Plenum?

baconsandwich (Tue, 14 Aug 2018 11:18:52 GMT):
Is this the place to ask questions specific to Plenum?

baconsandwich (Tue, 14 Aug 2018 13:11:26 GMT):
OK, I am just gonna ask. I am trying to understand what Plenum is using for communication between the nodes. The README.md says its RAET, the main.md says its CurveZMQ. Afaiu CurveZMQ uses ZeroMQ, or in other words, is a layer on top of ZeroMQ. So is ZeroMQ also an implementation of RAET? I am trying to consolidate all these statements.

baconsandwich (Tue, 14 Aug 2018 13:13:09 GMT):
In the indy-plenum code I only found references to ZeroMQ, which adds to the confusion.

RyanWest (Wed, 15 Aug 2018 02:18:35 GMT):
I believe RAET has been removed from the code, but has not been removed from the wiki yet (correct me if I'm wrong). This should be updated.

ashcherbakov (Wed, 15 Aug 2018 06:37:24 GMT):
@baconsandwich ZeroMQ is the only supported secure transport in plenum. RAET was deprecated and removed from the code. Thanks for finding inconsistency in the docs, that needs to be fixed (feel free to contribute and send a PR with fixes to the docs)

baconsandwich (Wed, 15 Aug 2018 16:39:34 GMT):
And what about CurveZWQ?

smithbk (Wed, 15 Aug 2018 17:16:53 GMT):
Hi, I am noticing what appears to be a slow memory leak on our steward node. What is the normal memory usage pattern? Should I open a jira? If yes, what is needed to debug?

PatrikStas (Thu, 16 Aug 2018 04:40:25 GMT):
Has joined the channel.

FCode (Thu, 16 Aug 2018 10:24:01 GMT):
Has joined the channel.

baconsandwich (Fri, 17 Aug 2018 04:02:38 GMT):
I am trying to find a definitive answer to what identity data (relevant to the users) is stored on the ledger. Can you confirm that 1. Only the domain ledger needs to be considered, because the other two only store data that is relevant to the ledger itself. 2. https://github.com/hyperledger/indy-node/blob/master/docs/transactions.md#domain-ledger shows all the transactions and therefore this is the exhausting listing of all data that will be stored on the ledger. I need to know for sure which data would be public (in the ledger).

swcurran (Fri, 17 Aug 2018 13:37:43 GMT):
@baconsandwich - I would agree that the domain ledger is the only relevant one to your question. What you mean by "identity data (relevant to the user)" is not exactly clear, but the document you reference contains most of the transactions, and hence data, stored on the domain ledger. I don't see on that page information about revocation data, but not none of that data can be tied to a user - because of how revocation is handled. But if you are trying to answer "What's on the ledger", the document you are looking at is pretty accurate.

swcurran (Fri, 17 Aug 2018 13:39:21 GMT):
One more note is that the "nym" related data - the DID - is likely in the future to be mostly stored off ledger - data shared directly by the two identities that exchanged the pairwise DIDs. That reduces the volume of data going on the public ledger. The DID data is the same, just the volume will be lower.

baconsandwich (Fri, 17 Aug 2018 13:44:27 GMT):
basically I am trying to understand what data that is somehow related to a user or his identity is stored on the ledger, so nodes would be irrelevant but did or verkey would be relevant

swcurran (Fri, 17 Aug 2018 13:46:23 GMT):
OK - then it's really the DID data and the Cred Def (with related revocation data). The Schema is just that, a schema so is to user related.

baconsandwich (Fri, 17 Aug 2018 13:46:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=CYibpoQvChfZXyka6) @swcurran I don't understand, the DID is going to be stored off-ledger?

swcurran (Fri, 17 Aug 2018 13:50:51 GMT):
Some DIDs will be on ledger. The idea is that if I create a connection with you and we exchange DIDs and related data (the DIDDoc), no one else is going to use that DID or DIDDoc to contact me, so I don't need to make it public. When I update a DIDDoc (e.g. rotate a key, add a key), I need to replicate that change to whatever copies of the DIDDoc are out there - either on the public ledger or on a microledger that I have with you. Since I am managing my copies of the data locally in my wallet (e.g. a data store), I can use that as the basis of the microledgers I keep with many other identities.

baconsandwich (Fri, 17 Aug 2018 13:53:20 GMT):
@swcurran And at the moment this DID pair between us would be stored on the ledger?

swcurran (Fri, 17 Aug 2018 14:08:01 GMT):
@baconsandwich yes.

baconsandwich (Fri, 17 Aug 2018 14:11:29 GMT):
i see

baconsandwich (Fri, 17 Aug 2018 14:12:23 GMT):
can you point me to information regarding the "microledger"? I have not seen this term yet when reading about indy.

n3m (Fri, 17 Aug 2018 14:13:45 GMT):
Hre are some thoughts about that that: https://github.com/hyperledger/indy-hipe/blob/07d62e74d80e0edeeb00c2e6638d92fc5c5801a2/text/relationship-state-machine/README.md

n3m (Fri, 17 Aug 2018 14:13:45 GMT):
@baconsandwich Here are some thoughts about that that: https://github.com/hyperledger/indy-hipe/blob/07d62e74d80e0edeeb00c2e6638d92fc5c5801a2/text/relationship-state-machine/README.md

n3m (Fri, 17 Aug 2018 14:13:52 GMT):
It is a work in progress at the moment

n3m (Fri, 17 Aug 2018 14:14:08 GMT):
Still brewing

baconsandwich (Fri, 17 Aug 2018 14:33:05 GMT):
thanks, I read about 1/2 of the document. what I don't understand is what kind of "Personal data was put on the immunitble ledger". It mentions agents (endpoints) that could allow correlation but what else is there that is personally identifiable?

baconsandwich (Fri, 17 Aug 2018 14:34:08 GMT):
i mean , i thought that was the whole point to have DIDs that are not correlatable to the real identities (verinyms)

jljordan_bcgov (Fri, 17 Aug 2018 14:50:27 GMT):
There would be no "personal data" such as attributes like names and so forth

jljordan_bcgov (Fri, 17 Aug 2018 14:51:58 GMT):
However, if all of one's peer-to-peer relationships DIDs where on the ledger it increases the probabilities that it along perhaps with network traffic data and so forth could be used to perform coorelation

jljordan_bcgov (Fri, 17 Aug 2018 14:53:27 GMT):
Apparently ... the prevailing GDPR opinion is that DID and DIDDoc type data is considered personal data ... maybe @drummondreed or @nage can provide more details on that

drummondreed (Fri, 17 Aug 2018 14:53:27 GMT):
Has joined the channel.

PatrikStas (Mon, 20 Aug 2018 14:48:09 GMT):
Hi everyone! I've started playing around with indy, but I need your help to clarify a few points. Thanks a lot in advance!!! 1. Looking at genesis files in Sovrin repo here https://github.com/sovrin-foundation/sovrin/tree/master/sovrin what's the difference between `domain_transactions_*` files and `pool_transactions_*`? It seems that those "domain" files have "role" field specifying stewards/trustees, but unlike "pool" files, they don't contain specific IP addresses. What are the use cases for these 2 kinds of genesis files? 2. I wanted to connect to Sovrin live using indy-cli. So I've created pool configuration like this: ``` pool create live gen_txn_file="/Users/patrikstas/dev/hyperledger/sovrin/sovrin/pool_transactions_live_genesis" ``` pointing to the sovrin genesis file https://github.com/sovrin-foundation/sovrin/blob/master/sovrin/pool_transactions_live_genesis however, when I try to connect, I can't: ``` indy> pool connect live Pool "live" has not been connected. ``` Also, can I increase logging level for `indy-cli` so I could get some more info? 3. In the `pool_transactions_*` genesis files, there is concept of "node" and "client". ``` "client_ip":"127.0.0.1","client_port":9702,"node_ip":"127.0.0.1","node_port":9701, ``` I suppose node represents the service running indy-node https://github.com/hyperledger/indy-node/ verifying transactions. What does the *client* service represents and what do I use it for?

josh.hill (Tue, 21 Aug 2018 05:14:57 GMT):
Has joined the channel.

ashcherbakov (Tue, 21 Aug 2018 06:54:47 GMT):
@PatrikStas 1: There are multiple ledgers, Domain Ledger (with txns like NYM, SCHEMA, ATTRIB, etc.), which is the main one for users data. and Pool Ledger, where information about the Nodes is stored (NODE txn). So, there are two genesis txn files (one for Domain ledger containing initial/gensis NYM txns, that is initial Trustees in the system, and one for the Pool ledger containing initial Nodes in the pool, that is NODE txns) 3: Indy Node service has 2 network interfaces: for node-to-node communication (consensus protocol), defined by node_ip and node_port, and for client-to-node communication (defined by client_ip, client_port), which receives requests and transactions from clients

ashcherbakov (Tue, 21 Aug 2018 06:54:47 GMT):
@PatrikStas 1: There are multiple ledgers, Domain Ledger (with txns like NYM, SCHEMA, ATTRIB, etc.), which is the main one for users data. and Pool Ledger, where information about the Nodes is stored (NODE txn). So, there are two genesis txn files (one for Domain ledger containing initial/gensis NYM txns, that is initial Trustees in the system, and one for the Pool ledger containing initial Nodes in the pool, that is NODE txns) 3: Indy Node service has 2 network interfaces: for node-to-node communication (consensus protocol), defined by node_ip and node_port, and for client-to-node communication (defined by client_ip, client_port), which receives requests and transactions from clients

PatrikStas (Tue, 21 Aug 2018 09:25:16 GMT):
@ashcherbakov Thanks a lot, that's very helpful. Is there anything you could add up to the 2nd point? Basically, since there are actually 2 ledgers, pool ledger and domain ledger, how can I connect to Sovrin network? In case of the dockerized pool example (https://github.com/hyperledger/indy-sdk/blob/master/cli/docker_pool_transactions_genesis), there is only single genesis file to work with, which seems to contain the "pool ledger transactions". It seems like something is shaded away from the user for sake of simplicity in the case of the dockerized pool example, as there's only 1 genesis file to work with.

claudiobizzotto (Tue, 21 Aug 2018 20:28:04 GMT):
Has joined the channel.

baconsandwich (Wed, 22 Aug 2018 11:54:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=YDLhKE2rPJwiokdYK) @ashcherbakov Is "client" equivalent to agent (indy-agent) here or are there other type of entities that would use client-to-node communication?

baconsandwich (Wed, 22 Aug 2018 12:03:58 GMT):
Where can I get information for potential real-world deployments of indy regarding the following: Let's say several companies are using it to have a common set of users, claims etc. Should all of them run a node? Should each of them run multiple nodes? Or in what case would I decide to only run an observer node and not a validator node? Since there is not proof-of-work, running a validator node should be cheap. Is it just about trust then and I only allow very trusthworhty companies to be a steward? Would each company have an agent? And could an agent of a company access the (steward) node of another company? Is there documentation or info regarding how this all would make sense?

gudkov (Thu, 23 Aug 2018 11:08:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=ZnbBXwvju3bHvp3Af) @baconsandwich Partial answer is https://sovrin.org

xum7331 (Sat, 25 Aug 2018 02:42:41 GMT):
Has joined the channel.

laurasp (Wed, 29 Aug 2018 11:23:26 GMT):
Has joined the channel.

sklump (Wed, 29 Aug 2018 11:34:22 GMT):
Has joined the channel.

sklump (Wed, 29 Aug 2018 11:34:35 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 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?

sklump (Wed, 29 Aug 2018 11:34:35 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 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? One bet: tweak the indy-pool.dockerfile (which versions marked `?` will work here?) ``` ARG indy_plenum_ver=? ARG indy_anoncreds_ver=? ARG indy_node_ver=1.3.62 ARG python3_indy_crypto_ver=? ARG indy_crypto_ver=? ``` , build docker image, docker run it, then figure out what magic values (name, sha256) to pass the upgrade call? I could really use some guidance here.

sklump (Wed, 29 Aug 2018 11:34:35 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 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? *One bet:* tweak the `indy-pool.dockerfile` (which versions marked `?` will work here?) ``` ARG indy_plenum_ver=? ARG indy_anoncreds_ver=? ARG indy_node_ver=1.3.62 ARG python3_indy_crypto_ver=? ARG indy_crypto_ver=? ``` , build docker image, docker run it, then figure out what magic values (name, sha256) to pass the upgrade call? I could really use some guidance here.

ashcherbakov (Wed, 29 Aug 2018 15:04:10 GMT):
@sklump You can use POOL_UPGRADE txn (https://github.com/hyperledger/indy-node/blob/master/docs/requests.md#pool_upgrade) to update the pool from 1.3.x to the latest 1.6.x (I recommend to do the upgrade to the latest version, not to 1.4.x). *Please note that for this particular upgrade force flag must True and all times in schedule must be the same, so that Upgrade is simultaneous* name can be anything. sha256 can also be anything (not supported yet) Please note that only a Trustee can send the Pool Upgrade txn. The Pool Upgrade txn will upgrade all the nodes to the latest (specified one) version, and will call auto migration scripts that will migrate all ledger data to the new format. An example with the old Indy CLI (distributed with IndyNode): ``` send POOL_UPGRADE name=upgrade-2 version=1.6.71 sha256=f6f2ea8f45d8a057c9566a33f99474da2e5c6a6604d736121650e2730c6fb0a3 action=start force=True schedule={'Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv': '2017-08-11T11:45:00.000000+00:00', '8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb': '2017-08-11T11:45:00.000000+00:00', 'DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya': '2017-08-11T11:45:00.000000+00:00', '4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA': '2017-08-11T11:45:00.000000+00:00'} ```

ashcherbakov (Wed, 29 Aug 2018 15:04:10 GMT):
@sklump You can use POOL_UPGRADE txn (https://github.com/hyperledger/indy-node/blob/master/docs/requests.md#pool_upgrade) to update the pool from 1.3.x to the latest 1.6.x (I recommend to do the upgrade to the latest version, not to 1.4.x). *Please note that for this particular upgrade force flag must True and all times in schedule must be the same, so that Upgrade is simultaneous* name can be anything. sha256 can also be anything (not supported yet) Please note that only a Trustee can send the Pool Upgrade txn. The Pool Upgrade txn will upgrade all the nodes to the latest (specified one) version, and will call auto migration scripts that will migrate all ledger data to the new format. An example with the old Indy CLI (distributed with IndyNode): ``` send POOL_UPGRADE name=upgrade-2 version=1.6.71 sha256=f6f2ea8f45d8a057c9566a33f99474da2e5c6a6604d736121650e2730c6fb0a3 action=start force=True schedule={'Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv': '2017-08-11T11:45:00.000000+00:00', '8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb': '2017-08-11T11:45:00.000000+00:00', 'DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya': '2017-08-11T11:45:00.000000+00:00', '4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA': '2017-08-11T11:45:00.000000+00:00'} ```

ashcherbakov (Wed, 29 Aug 2018 15:04:10 GMT):
@sklump You can use POOL_UPGRADE txn (https://github.com/hyperledger/indy-node/blob/master/docs/requests.md#pool_upgrade) to update the pool from 1.3.x to the latest 1.6.x (I recommend to do the upgrade to the latest version, not to 1.4.x). *Please note that for this particular upgrade force flag must True and all times in schedule must be the same, so that Upgrade is simultaneous* name can be anything. sha256 can also be anything (not supported yet) Please note that only a Trustee can send the Pool Upgrade txn. The Pool Upgrade txn will upgrade all the nodes to the latest (specified one) version, and will call auto migration scripts that will migrate all ledger data to the new format. An example with the old Indy CLI (distributed with IndyNode): ``` send POOL_UPGRADE name=upgrade-2 version=1.6.71 sha256=f6f2ea8f45d8a057c9566a33f99474da2e5c6a6604d736121650e2730c6fb0a3 action=start force=True schedule={'Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv': '2018-08-29T11:45:00.000000+00:00', '8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb': '2018-08-29T11:45:00.000000+00:00', 'DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya': '2018-08-29T11:45:00.000000+00:00', '4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA': '2018-08-29T11:45:00.000000+00:00'} ```

sklump (Wed, 29 Aug 2018 15:06:24 GMT):
If I make the call via indy-sdk ledger API, will it have the same effect?

ashcherbakov (Wed, 29 Aug 2018 15:09:05 GMT):
yes, it should be the same

sklump (Wed, 29 Aug 2018 15:12:33 GMT):
thanks, will try later today

gskerry (Wed, 29 Aug 2018 15:55:08 GMT):
Has joined the channel.

sklump (Thu, 30 Aug 2018 10:43:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=BehZ5PWNRoJuLRq2e) @ashcherbakov How can I find versions for ``` ARG indy_plenum_ver=? ARG indy_anoncreds_ver=? ARG indy_node_ver=1.3.62 ARG python3_indy_crypto_ver=? ARG indy_crypto_ver=? ``` ARG indy_plenum_ver=? ARG indy_anoncreds_ver=? ARG indy_node_ver=1.3.62 ARG python3_indy_crypto_ver=? ARG indy_crypto_ver=? ``` that docker can build from the dockerfile, to match what is currently in the Sovrin Live (or Test) Network? Old `indy-sdk/ci/indy-pool.dockerfile` files do not work anymore - the dependencies are wrong or unavailable. E.g., E: Version '1.2.389' for 'indy-plenum' was not found E: Version '1.0.32' for 'indy-anoncreds' was not found E: Version '1.3.446' for 'indy-node' was not found ``` The command '/bin/sh -c apt-get update -y && apt-get install -y indy-plenum=${indy_plenum_ver} indy-anoncreds=${indy_anoncreds_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 ``` Thanks in advance. ```

sklump (Thu, 30 Aug 2018 10:43:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=BehZ5PWNRoJuLRq2e) @ashcherbakov How can I find versions for ``` ARG indy_plenum_ver=? ARG indy_anoncreds_ver=? ARG indy_node_ver=1.3.62 ARG python3_indy_crypto_ver=? ARG indy_crypto_ver=? ``` ``` that docker can build from the dockerfile, to match what is currently in the Sovrin Live (or Test) Network? Old `indy-sdk/ci/indy-pool.dockerfile` files do not work anymore - the dependencies are wrong or unavailable. E.g., E: Version '1.2.389' for 'indy-plenum' was not found E: Version '1.0.32' for 'indy-anoncreds' was not found E: Version '1.3.446' for 'indy-node' was not found ``` The command '/bin/sh -c apt-get update -y && apt-get install -y indy-plenum=${indy_plenum_ver} indy-anoncreds=${indy_anoncreds_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 ``` Thanks in advance. ```

sklump (Thu, 30 Aug 2018 10:43:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=BehZ5PWNRoJuLRq2e) @ashcherbakov How can I find versions for ``` ARG indy_plenum_ver=? ARG indy_anoncreds_ver=? ARG indy_node_ver=1.3.62 ARG python3_indy_crypto_ver=? ARG indy_crypto_ver=? ``` that docker can build from the dockerfile, to match what is currently in the Sovrin Live (or Test) Network? Old `indy-sdk/ci/indy-pool.dockerfile` files do not work anymore - the dependencies are wrong or unavailable. E.g., E: Version '1.2.389' for 'indy-plenum' was not found E: Version '1.0.32' for 'indy-anoncreds' was not found E: Version '1.3.446' for 'indy-node' was not found ``` The command '/bin/sh -c apt-get update -y && apt-get install -y indy-plenum=${indy_plenum_ver} indy-anoncreds=${indy_anoncreds_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 ``` Thanks in advance. ```

sklump (Thu, 30 Aug 2018 10:43:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=BehZ5PWNRoJuLRq2e) @ashcherbakov How can I find versions for ``` ARG indy_plenum_ver=? ARG indy_anoncreds_ver=? ARG indy_node_ver=1.3.62 ARG python3_indy_crypto_ver=? ARG indy_crypto_ver=? ``` that docker can build from the dockerfile, to match what is currently in the Sovrin Live (or Test) Network? Old `indy-sdk/ci/indy-pool.dockerfile` files do not work anymore - the dependencies are wrong or unavailable. E.g., ``` E: Version '1.2.389' for 'indy-plenum' was not found E: Version '1.0.32' for 'indy-anoncreds' was not found E: Version '1.3.446' for 'indy-node' was not found ``` The command '/bin/sh -c apt-get update -y && apt-get install -y indy-plenum=${indy_plenum_ver} indy-anoncreds=${indy_anoncreds_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 ``` Thanks in advance. ```

sklump (Thu, 30 Aug 2018 10:43:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=BehZ5PWNRoJuLRq2e) @ashcherbakov How can I find versions for ``` ARG indy_plenum_ver=? ARG indy_anoncreds_ver=? ARG indy_node_ver=1.3.62 ARG python3_indy_crypto_ver=? ARG indy_crypto_ver=? ``` that docker can build from the dockerfile, to match what is currently in the Sovrin Live (or Test) Network? Old `indy-sdk/ci/indy-pool.dockerfile` files do not work anymore - the dependencies are wrong or unavailable. E.g., ``` E: Version '1.2.389' for 'indy-plenum' was not found E: Version '1.0.32' for 'indy-anoncreds' was not found E: Version '1.3.446' for 'indy-node' was not found The command '/bin/sh -c apt-get update -y && apt-get install -y indy-plenum=${indy_plenum_ver} indy-anoncreds=${indy_anoncreds_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 ``` Thanks in advance. ```

ashcherbakov (Thu, 30 Aug 2018 10:46:59 GMT):
@sklump https://github.com/hyperledger/indy-node/blob/1.3.62-stable/setup.py#L59 So, this is indy-plenum==1.2.42 indy-anoncreds==1.0.11 https://github.com/hyperledger/indy-plenum/blob/1.2.42-stable/setup.py#L60 indy-crypto==0.4.1 python3_indy_crypto_ver==0.4.1

sklump (Thu, 30 Aug 2018 10:50:39 GMT):
Closer - I still get ``` E: Version '0.4.1' for 'libindy-crypto' was not found ```

sklump (Thu, 30 Aug 2018 10:57:25 GMT):
... so I set `indy_crypto_ver=0.4.0` as per https://github.com/hyperledger/indy-sdk/blob/e5ea63665b2f6dd43ec29903d82edab87593f67c/ci/indy-pool.dockerfile#L31 and advanced the result to: ``` The following packages have unmet dependencies: indy-plenum : Depends: python3-base58 (= 0.2.4) but 1.0.0 is to be installed ```

ashcherbakov (Thu, 30 Aug 2018 11:23:57 GMT):
well, it looks like you have to install python3-base58= 0.2.4 as well... There were some changes in dependencies of base58 version

sklump (Thu, 30 Aug 2018 11:46:41 GMT):
OMG it builds! Thanks!

sklump (Thu, 30 Aug 2018 19:03:21 GMT):
... unfortunately I can't get the upgrade instruction to work on the node pool. As a TRUSTEE, I sign and submit ``` { "result": { "sha256": "f6f2ea8f45d8a057c9566a33f99474da2e5c6a6604d736121650e2730c6fb0a3", "signatures": null, "rootHash": "FHCMJGmjRn7LDRDJSjzw7oxaFUt1RTZqCAkMFnag14Vo", "action": "start", "force": true, "type": "109", "identifier": "V4SGRU86Z58d6TV7PBUe6f", "signature": "JFBhnGQuEsCCDTN2Qsjokcf2tUxAeYRy43JdFzMD7oNg3RfYKAAaZGwwUxFxeWvgwT2hxxPvvqb9KPv4spJKHob", "name": "upgrade-pool", "txnTime": 1535655202, "reqId": 1535655202530013891, "auditPath": [], "reinstall": false, "schedule": { "Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv": "2018-08-30T18:54:22.529649+00:00", "DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya": "2018-08-30T18:54:22.529649+00:00", "4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA": "2018-08-30T18:54:22.529649+00:00", "8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb": "2018-08-30T18:54:22.529649+00:00" }, "version": "1.6.71", "seqNo": 1 }, "op": "REPLY" } ``` and the nodes go into an infinite loop with errors like this: ``` node1_1 | 2018-08-30 19:00:38,943 | INFO | node.py (2529) | executeBatch | Node1 committed batch request, view no 0, ppSeqNo 1322, ledger 2, state root DfNLmH4DAHTKv63YPFJzuRdeEtVwF5RtVnvKYHd8iLEA, txn root H9ehR3QuAPtNC8tTJPAjZdqz26CEAGQeeA3FVMCG6Qmy, requests: [('DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya', 1535655637359290), ('Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv', 1535655637490552), ('8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb', 1535655637724030), ('4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA', 1535655637815431)] node1_1 | 2018-08-30 19:00:38,952 | INFO | node.py (2879) | send | Node1 sending message PREPREPARE{'stateRootHash': 'DfNLmH4DAHTKv63YPFJzuRdeEtVwF5RtVnvKYHd8iLEA', 'ppTime': 1535655638, 'digest': 'd586e9f14db9181cac6918be8e65a98f45e5ff0b0719643d07bd70bdac0d5c37', 'viewNo': 0, 'reqIdr': [('DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya', 1535655638050589), ('Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv', 1535655638191841), ('8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb', 1535655638450598), ('4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA', 1535655638520678)], 'ppSeqNo': 1323, 'instId': 0, 'discarded': 4, 'ledgerId': 2, 'txnRootHash': 'F4RzjBDED5UVmyDUVbYPqL2gDxzVgCgranzogKU7UxS8'} to all recipients: ['Node2', 'Node4', 'Node3'] node1_1 | 2018-08-30 19:00:38,953 | INFO | node.py (2879) | send | Node1 sending message PREPARE{'stateRootHash': None, 'ppTime': 1535655638, 'digest': '608d2dac47319c08234a6721b8e11229033649bb3a5de16aaac901f02bd61505', 'viewNo': 0, 'ppSeqNo': 1395, 'instId': 1, 'txnRootHash': None} to all recipients: ['Node2', 'Node4', 'Node3'] node1_1 | 2018-08-30 19:00:38,953 | INFO | node.py (2879) | send | Node1 sending message COMMIT{'ppSeqNo': 1395, 'instId': 1, 'viewNo': 0} to all recipients: ['Node2', 'Node4', 'Node3'] node1_1 | 2018-08-30 19:00:38,962 | INFO | upgrader.py ( 469) | _sendUpdateRequest | Sending message to control tool: {"version": "1.6.71"} node1_1 | 2018-08-30 19:00:38,963 | WARNING | upgrader.py ( 474) | _sendUpdateRequest | Failed to communicate to control tool: [Errno 111] Connect call failed ('127.0.0.1', 30003) node1_1 | 2018-08-30 19:00:38,964 | INFO | upgrader.py ( 469) | _sendUpdateRequest | Sending message to control tool: {"version": "1.6.71"} node1_1 | 2018-08-30 19:00:38,966 | WARNING | upgrader.py ( 474) | _sendUpdateRequest | Failed to communicate to control tool: [Errno 111] Connect call failed ('127.0.0.1', 30003) node1_1 | 2018-08-30 19:00:38,967 | INFO | upgrader.py ( 469) | _sendUpdateRequest | Sending message to control tool: {"version": "1.6.71"} node1_1 | 2018-08-30 19:00:38,968 | WARNING | upgrader.py ( 474) | _sendUpdateRequest | Failed to communicate to control tool: [Errno 111] Connect call failed ('127.0.0.1', 30003) node1_1 | 2018-08-30 19:00:38,970 | ERROR | upgrader.py ( 536) | _upgrade_failed | Node Node1 failed upgrade 1535655202530013891 to version 1.6.71 scheduled on 2018-08-30 18:54:22.529649+00:00 because of problems in communication with node control service ``` Anyone have a guess what might be going wrong?

sklump (Thu, 30 Aug 2018 19:03:21 GMT):
... unfortunately I can't get the upgrade instruction to work on the node pool. As a TRUSTEE, I sign and submit ``` { "result": { "sha256": "f6f2ea8f45d8a057c9566a33f99474da2e5c6a6604d736121650e2730c6fb0a3", "signatures": null, "rootHash": "FHCMJGmjRn7LDRDJSjzw7oxaFUt1RTZqCAkMFnag14Vo", "action": "start", "force": true, "type": "109", "identifier": "V4SGRU86Z58d6TV7PBUe6f", "signature": "JFBhnGQuEsCCDTN2Qsjokcf2tUxAeYRy43JdFzMD7oNg3RfYKAAaZGwwUxFxeWvgwT2hxxPvvqb9KPv4spJKHob", "name": "upgrade-pool", "txnTime": 1535655202, "reqId": 1535655202530013891, "auditPath": [], "reinstall": false, "schedule": { "Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv": "2018-08-30T18:54:22.529649+00:00", "DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya": "2018-08-30T18:54:22.529649+00:00", "4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA": "2018-08-30T18:54:22.529649+00:00", "8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb": "2018-08-30T18:54:22.529649+00:00" }, "version": "1.6.71", "seqNo": 1 }, "op": "REPLY" } ``` and the nodes go into an infinite loop with errors like this: ``` node1_1 | 2018-08-30 19:00:38,943 | INFO | node.py (2529) | executeBatch | Node1 committed batch request, view no 0, ppSeqNo 1322, ledger 2, state root DfNLmH4DAHTKv63YPFJzuRdeEtVwF5RtVnvKYHd8iLEA, txn root H9ehR3QuAPtNC8tTJPAjZdqz26CEAGQeeA3FVMCG6Qmy, requests: [('DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya', 1535655637359290), ('Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv', 1535655637490552), ('8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb', 1535655637724030), ('4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA', 1535655637815431)] node1_1 | 2018-08-30 19:00:38,952 | INFO | node.py (2879) | send | Node1 sending message PREPREPARE{'stateRootHash': 'DfNLmH4DAHTKv63YPFJzuRdeEtVwF5RtVnvKYHd8iLEA', 'ppTime': 1535655638, 'digest': 'd586e9f14db9181cac6918be8e65a98f45e5ff0b0719643d07bd70bdac0d5c37', 'viewNo': 0, 'reqIdr': [('DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya', 1535655638050589), ('Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv', 1535655638191841), ('8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb', 1535655638450598), ('4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA', 1535655638520678)], 'ppSeqNo': 1323, 'instId': 0, 'discarded': 4, 'ledgerId': 2, 'txnRootHash': 'F4RzjBDED5UVmyDUVbYPqL2gDxzVgCgranzogKU7UxS8'} to all recipients: ['Node2', 'Node4', 'Node3'] node1_1 | 2018-08-30 19:00:38,953 | INFO | node.py (2879) | send | Node1 sending message PREPARE{'stateRootHash': None, 'ppTime': 1535655638, 'digest': '608d2dac47319c08234a6721b8e11229033649bb3a5de16aaac901f02bd61505', 'viewNo': 0, 'ppSeqNo': 1395, 'instId': 1, 'txnRootHash': None} to all recipients: ['Node2', 'Node4', 'Node3'] node1_1 | 2018-08-30 19:00:38,953 | INFO | node.py (2879) | send | Node1 sending message COMMIT{'ppSeqNo': 1395, 'instId': 1, 'viewNo': 0} to all recipients: ['Node2', 'Node4', 'Node3'] node1_1 | 2018-08-30 19:00:38,962 | INFO | upgrader.py ( 469) | _sendUpdateRequest | Sending message to control tool: {"version": "1.6.71"} node1_1 | 2018-08-30 19:00:38,963 | WARNING | upgrader.py ( 474) | _sendUpdateRequest | Failed to communicate to control tool: [Errno 111] Connect call failed ('127.0.0.1', 30003) node1_1 | 2018-08-30 19:00:38,964 | INFO | upgrader.py ( 469) | _sendUpdateRequest | Sending message to control tool: {"version": "1.6.71"} node1_1 | 2018-08-30 19:00:38,966 | WARNING | upgrader.py ( 474) | _sendUpdateRequest | Failed to communicate to control tool: [Errno 111] Connect call failed ('127.0.0.1', 30003) node1_1 | 2018-08-30 19:00:38,967 | INFO | upgrader.py ( 469) | _sendUpdateRequest | Sending message to control tool: {"version": "1.6.71"} node1_1 | 2018-08-30 19:00:38,968 | WARNING | upgrader.py ( 474) | _sendUpdateRequest | Failed to communicate to control tool: [Errno 111] Connect call failed ('127.0.0.1', 30003) node1_1 | 2018-08-30 19:00:38,970 | ERROR | upgrader.py ( 536) | _upgrade_failed | Node Node1 failed upgrade 1535655202530013891 to version 1.6.71 scheduled on 2018-08-30 18:54:22.529649+00:00 because of problems in communication with node control service ``` Anyone have a guess how to fix it? I am guessing that it's bound to the local box?

sklump (Thu, 30 Aug 2018 19:05:35 GMT):
I don't know what 30003 is - maybe a port I have to open up somehow?

ashcherbakov (Fri, 31 Aug 2018 07:35:08 GMT):
Yes, node control tool is a separate process listening to the port 30003 for Upgrade events. So, please make sure that node control tool is up and is listening to that port.

sklump (Fri, 31 Aug 2018 10:23:27 GMT):
Node control tool? Is there a document?

ashcherbakov (Fri, 31 Aug 2018 11:29:17 GMT):
https://github.com/hyperledger/indy-node/blob/master/docs/pool-upgrade.md

ashcherbakov (Fri, 31 Aug 2018 11:30:54 GMT):
in general, there are two services (systemctl-based): `indy-node` and `indy-control-tool`

ashcherbakov (Fri, 31 Aug 2018 11:30:54 GMT):
in general, there are two services (systemctl-based): `indy-node` and `indy-node-control-tool`

sklump (Fri, 31 Aug 2018 11:34:10 GMT):
I have the indy-nodes running on ports 9701 through 9708. My docker file has `EXPOSE 9701 9702 9703 9704 9705 9706 9707 9708 30003`. I have gone onto the container as root and started the node control tool: ``` root@b39f15c82ceb:/home/indy# start_node_control_tool 2018-08-31 11:28:38,768 | DEBUG | __init__.py ( 60) | register | Registered VCS backend: git 2018-08-31 11:28:38,828 | DEBUG | __init__.py ( 60) | register | Registered VCS backend: hg 2018-08-31 11:28:38,894 | DEBUG | __init__.py ( 60) | register | Registered VCS backend: svn 2018-08-31 11:28:38,895 | DEBUG | __init__.py ( 60) | register | Registered VCS backend: bzr 2018-08-31 11:28:39,017 | INFO | node_control_tool.py ( 75) | __init__ | Node control tool is starting up on localhost port 30003 2018-08-31 11:28:40,038 | DEBUG | node_control_tool.py ( 288) | start | Waiting for the next event ```

sklump (Fri, 31 Aug 2018 11:35:46 GMT):
It's running on indy_pool_network as per indy-sdk, but when I `telnet 10.0.0.3 30003`, there is no response. There is a response on 9701, 9702, etc.

sklump (Fri, 31 Aug 2018 11:36:05 GMT):
I don't know if this is normal?

sklump (Fri, 31 Aug 2018 11:36:17 GMT):
I'm about to kick off the test suite and see what happens.

sklump (Fri, 31 Aug 2018 11:40:49 GMT):
Incredibly, it seems to be going out and getting stuff. Progress!

sklump (Fri, 31 Aug 2018 11:44:15 GMT):
Uh-oh: ``` Setting up indy-node (1.6.71) ... + ret=0 + '[' 0 -ne 0 ']' 2018-08-31 11:42:45,772 | DEBUG | node_control_tool.py ( 170) | _create_backup | Creating backup for 1.3.62 2018-08-31 11:42:45,910 | INFO | migration_tool.py ( 52) | migrate | Migrating from 1.3.62 to 1.6.71 on Ubuntu 2018-08-31 11:42:45,911 | DEBUG | migration_tool.py ( 54) | migrate | Found migration scripts: ['1_0_28_to_1_0_29', '1_1_37_to_1_1_38', '1_1_43_to_1_2_44', '1_2_44_to_1_2_45', '1_2_50_to_1_2_51', '1_2_51_to_1_2_52', '1_3_396_to_1_3_397', '1_3_428_to_1_3_429', '1_3_433_to_1_3_434', '1_4_500_to_1_4_501', 'disabled_1_0_29_to_1_0_28', 'helper_1_0_28_to_1_0_29', 'helper_1_1_37_to_1_1_38'] 2018-08-31 11:42:45,912 | INFO | migration_tool.py ( 61) | migrate | Following migrations will be applied: ['1_3_396_to_1_3_397', '1_3_428_to_1_3_429', '1_3_433_to_1_3_434', '1_4_500_to_1_4_501'] 2018-08-31 11:42:45,912 | INFO | migration_tool.py ( 63) | migrate | Applying migration 1_3_396_to_1_3_397 2018-08-31 11:42:45,913 | INFO | migration_tool.py ( 35) | _call_migration_script | script path /usr/local/lib/python3.5/dist-packages/data/migrations/deb/1_3_396_to_1_3_397.py Traceback (most recent call last): File "/usr/local/lib/python3.5/dist-packages/data/migrations/deb/1_3_396_to_1_3_397.py", line 79, in migrate_storage leveldb_storage = KeyValueStorageLeveldbCls(level_db_dir, db_name, read_only=True) File "/usr/local/lib/python3.5/dist-packages/storage/kv_store_leveldb_int_keys.py", line 12, in __init__ super().__init__(db_dir, db_name, open, read_only) File "/usr/local/lib/python3.5/dist-packages/storage/kv_store_leveldb.py", line 22, in __init__ self.open() File "/usr/local/lib/python3.5/dist-packages/storage/kv_store_leveldb_int_keys.py", line 16, in open 'IntegerComparator', integer_comparator)) leveldb.LevelDBError: IO error: lock /var/lib/indy/sandbox/data/Node4/pool_transactions/LOCK: Resource temporarily unavailable None Could not open leveldb storage: /var/lib/indy/sandbox/data/Node4/pool_transactions Could not migrate pool_transactions, DB path: /var/lib/indy/sandbox/data/Node4/pool_transactions Storages migration from LevelDB to RocksDB failed! 2018-08-31 11:42:46,708 | ERROR | migration_tool.py ( 44) | _call_migration_script | Migration failed: script returned 1 2018-08-31 11:42:46,709 | DEBUG | node_control_tool.py ( 175) | _restore_from_backup | Restoring from backup for 1.3.62 2018-08-31 11:42:46,710 | WARNING | node_control_tool.py ( 182) | _restore_from_backup | Copying last_version failed due to [Errno 2] No such file or directory: '/var/lib/indy/sandbox/last_version' 2018-08-31 11:42:46,710 | WARNING | node_control_tool.py ( 182) | _restore_from_backup | Copying next_version failed due to [Errno 2] No such file or directory: '/var/lib/indy/sandbox/next_version' 2018-08-31 11:42:46,711 | WARNING | node_control_tool.py ( 182) | _restore_from_backup | Copying upgrade_log failed due to [Errno 2] No such file or directory: '/var/lib/indy/sandbox/upgrade_log' 2018-08-31 11:42:46,711 | WARNING | node_control_tool.py ( 182) | _restore_from_backup | Copying last_version_file failed due to [Errno 2] No such file or directory: '/var/lib/indy/sandbox/last_version_file' 2018-08-31 11:42:46,844 | WARNING | node_control_tool.py ( 191) | _restore_from_backup | Copying last_version failed due to [Errno 2] No such file or directory: '/tmp/.indy_tmp/last_version' 2018-08-31 11:42:46,844 | WARNING | node_control_tool.py ( 191) | _restore_from_backup | Copying next_version failed due to [Errno 2] No such file or directory: '/tmp/.indy_tmp/next_version' 2018-08-31 11:42:46,850 | WARNING | node_control_tool.py ( 191) | _restore_from_backup | Copying upgrade_log failed due to [Errno 2] No such file or directory: '/tmp/.indy_tmp/upgrade_log' 2018-08-31 11:42:46,852 | WARNING | node_control_tool.py ( 191) | _restore_from_backup | Copying last_version_file failed due to [Errno 2] No such file or directory: '/tmp/.indy_tmp/last_version_file' 2018-08-31 11:42:46,853 | ERROR | node_control_tool.py ( 259) | _declare_upgrade_failed | Upgrade from 1.3.62 to 1.6.71 failed: Migration failed: script returned 1 2018-08-31 11:42:46,853 | ERROR | node_control_tool.py ( 235) | _upgrade | Trying to rollback to the previous version Migration failed: script returned 1 ```

sklump (Fri, 31 Aug 2018 11:45:37 GMT):
... then ... ``` Try to donwload indy version indy-anoncreds=1.0.11 python3-indy-crypto=0.4.1 indy-plenum=1.2.42 indy-node=1.3.62 + apt-get -y update 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 Ign:5 https://repo.sovrin.org/deb xenial InRelease Hit:6 https://repo.sovrin.org/deb xenial Release Reading package lists... Done + apt-get --download-only -y --allow-downgrades --allow-change-held-packages install indy-anoncreds=1.0.11 python3-indy-crypto=0.4.1 indy-plenum=1.2.42 indy-node=1.3.62 Reading package lists... Done Building dependency tree Reading state information... Done indy-anoncreds is already the newest version (1.0.11). python3-indy-crypto is already the newest version (0.4.1). 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-base58 (= 0.2.4) but 1.0.0 is to be installed E: Unable to correct problems, you have held broken packages. + ret=100 + '[' 100 -ne 0 ']' + echo 'Failed to obtain indy-anoncreds=1.0.11 python3-indy-crypto=0.4.1 indy-plenum=1.2.42 indy-node=1.3.62' Failed to obtain indy-anoncreds=1.0.11 python3-indy-crypto=0.4.1 indy-plenum=1.2.42 indy-node=1.3.62 + exit 1 2018-08-31 11:43:03,802 | ERROR | node_control_tool.py ( 259) | _declare_upgrade_failed | Upgrade from 1.3.62 to 1.3.62 failed: upgrade script failed, exit code is 1 ```

sklump (Fri, 31 Aug 2018 11:52:10 GMT):
It looks like the base58 update breaks the upgrade path to 1.6 from 1.3. For the lack of a '>' character the upgrade is lost. Could someone with privilege update the indy-plenum requirement to base58 >= 0.2.4, or else to have it apt-get install base58=0.2.4 explicitly?

sklump (Fri, 31 Aug 2018 11:52:10 GMT):
It looks like the base58 update breaks the upgrade path to 1.6 from 1.3. For the lack of a '>' character the upgrade is lost. Could someone with privilege update the indy-plenum requirement to base58 >= 0.2.4, or else to have it apt-get install base58=0.2.4 explicitly on repo.sovrin.org?

sklump (Fri, 31 Aug 2018 11:52:10 GMT):
It looks like the base58 update breaks the upgrade path from 1.3 to 1.6. For the lack of a '>' character the upgrade is lost. Could someone with privilege update the indy-plenum requirement to base58 >= 0.2.4, or else to have it apt-get install base58=0.2.4 explicitly on repo.sovrin.org?

sklump (Fri, 31 Aug 2018 11:52:10 GMT):
It looks like the base58 update breaks the upgrade path from 1.3 to 1.6. For the lack of a '>' character the upgrade is lost. Could someone with privilege update the indy-plenum requirement to base58>=0.2.4, or else to have it apt-get install base58=0.2.4 explicitly on repo.sovrin.org? Or maybe there is an easier way I don't see?

sklump (Fri, 31 Aug 2018 11:52:10 GMT):
It looks like the base58 update breaks the upgrade path from 1.3 to 1.6. For the lack of a '>' character the upgrade is lost. Could someone with privilege update the indy-plenum requirement to base58>=0.2.4, or else to have it apt-get install base58=0.2.4 explicitly on repo.sovrin.org? Or maybe there is another way I don't see?

sklump (Fri, 31 Aug 2018 11:52:10 GMT):
It looks like the base58 update breaks the upgrade path from 1.3 to 1.6. For the lack of a '>' character the upgrade is lost. Could someone with privilege kindly update the indy-plenum requirement to base58>=0.2.4, or else to have it apt-get install base58=0.2.4 explicitly on repo.sovrin.org? This looks like an ordeal - this will affect pretty much every version of every indy package using base58, so, all of them. Maybe there is another way I don't see?

sklump (Fri, 31 Aug 2018 11:52:10 GMT):
It looks like the base58 update breaks the upgrade path from 1.3 to 1.6. For the lack of a `>` the upgrade is lost. Could someone with privilege kindly update the indy-plenum requirement to base58>=0.2.4, or else to have it apt-get install base58=0.2.4 explicitly on repo.sovrin.org? This looks like an ordeal - this will affect pretty much every version of every indy package using base58, so, all of them. Maybe there is another way I don't see?

sklump (Fri, 31 Aug 2018 11:52:10 GMT):
It looks like the base58 update breaks the upgrade path from 1.3 to 1.6. For the lack of a `>` character the upgrade is lost. Could someone with privilege kindly update the indy-plenum requirement to base58>=0.2.4, or else to have it apt-get install base58=0.2.4 explicitly on repo.sovrin.org? This looks like an ordeal - this will affect pretty much every version of every indy package using base58, so, all of them. Maybe there is another way I don't see?

sklump (Fri, 31 Aug 2018 11:52:10 GMT):
It looks like the base58 update breaks the upgrade path from 1.3 to 1.6. For lack of a `>` character the upgrade is lost. Could someone with privilege kindly update the indy-plenum requirement to base58>=0.2.4, or else to have it apt-get install base58=0.2.4 explicitly on repo.sovrin.org? This looks like an ordeal - this will affect pretty much every version of every indy package using base58, so, all of them. Maybe there is another way I don't see?

sebastian (Fri, 31 Aug 2018 12:59:00 GMT):
Has joined the channel.

ashcherbakov (Fri, 31 Aug 2018 14:34:31 GMT):
The Upgrade from 1.3 to 1.6 was tested many times and it should work. Maybe there is some local misconfiguration? Feel free to cerate an issue in Jira if needed

sklump (Fri, 31 Aug 2018 17:26:50 GMT):
I have to create a ticket for this in Jira. There is definitely a wrong required base58 version. If I hot-swap pip install base58==0.2.4 underneath the node control tool on the docker container to match the dependency in indy-plenum, the migration script 1_3_396_to_1_3_397.py chokes with a stack trase ending in ``` File "/usr/local/lib/python3.5/dist-packages/plenum/common/messages/fields.py", line 350, in Base58Field _alphabet = set(base58.alphabet.decode("utf-8")) AttributeError: 'str' object has no attribute 'decode' ``` and I see that base58.py v0.2.4 had alphabet as a `str` where v1.0.0 has it as a `bytes`.

sklump (Fri, 31 Aug 2018 17:26:50 GMT):
I have to create a ticket for this in Jira. There is definitely a wrong required base58 version. If I hot-swap pip install base58==0.2.4 underneath the node control tool on the docker container to match the dependency in indy-plenum, the migration script 1_3_396_to_1_3_397.py chokes with a stack trace ending in ``` File "/usr/local/lib/python3.5/dist-packages/plenum/common/messages/fields.py", line 350, in Base58Field _alphabet = set(base58.alphabet.decode("utf-8")) AttributeError: 'str' object has no attribute 'decode' ``` and I see that base58.py v0.2.4 had alphabet as a `str` where v1.0.0 has it as a `bytes`.

sklump (Fri, 31 Aug 2018 17:26:50 GMT):
I have to create a ticket for this in Jira. There is definitely a wrong required base58 version. If I hot-swap pip install base58==0.2.4 underneath the node control tool on the docker container to match the dependency in indy-plenum, the migration script 1_3_396_to_1_3_397.py chokes with a stack trace ending in ``` File "/usr/local/lib/python3.5/dist-packages/plenum/common/messages/fields.py", line 350, in Base58Field _alphabet = set(base58.alphabet.decode("utf-8")) AttributeError: 'str' object has no attribute 'decode' ``` and I see that base58.py v0.2.4 had `alphabet` as a `str` where v1.0.0 has it as a `bytes`.

sklump (Fri, 31 Aug 2018 17:26:50 GMT):
I have to create a ticket for this in Jira. There is definitely a wrong required base58 version. If I hot-swap `pip install base58==0.2.4` underneath the node control tool on the docker container to match the dependency in indy-plenum, the migration script 1_3_396_to_1_3_397.py chokes with a stack trace ending in ``` File "/usr/local/lib/python3.5/dist-packages/plenum/common/messages/fields.py", line 350, in Base58Field _alphabet = set(base58.alphabet.decode("utf-8")) AttributeError: 'str' object has no attribute 'decode' ``` and I see that base58.py v0.2.4 had `alphabet` as a `str` where v1.0.0 has it as a `bytes`.

sklump (Fri, 31 Aug 2018 17:26:50 GMT):
I have to create a ticket for this in Jira. There is definitely a wrong required base58 version. If I hot-swap `pip install base58==0.2.4` underneath the node control tool on the docker container to match the dependency in indy-plenum, the migration script `1_3_396_to_1_3_397.py` chokes with a stack trace ending in ``` File "/usr/local/lib/python3.5/dist-packages/plenum/common/messages/fields.py", line 350, in Base58Field _alphabet = set(base58.alphabet.decode("utf-8")) AttributeError: 'str' object has no attribute 'decode' ``` and I see that base58.py v0.2.4 had `alphabet` as a `str` where v1.0.0 has it as a `bytes`.

sklump (Fri, 31 Aug 2018 17:26:50 GMT):
I have to create a ticket for this in Jira. There is definitely incompatibility in required base58 versions. If I hot-swap `pip install base58==0.2.4` underneath the node control tool on the docker container to match the dependency in indy-plenum, the migration script `1_3_396_to_1_3_397.py` chokes with a stack trace ending in ``` File "/usr/local/lib/python3.5/dist-packages/plenum/common/messages/fields.py", line 350, in Base58Field _alphabet = set(base58.alphabet.decode("utf-8")) AttributeError: 'str' object has no attribute 'decode' ``` and I see that base58.py v0.2.4 had `alphabet` as a `str` where v1.0.0 has it as a `bytes`.

sklump (Fri, 31 Aug 2018 17:26:50 GMT):
I have to create a ticket for this in Jira. There is definitely incompatibility in required base58 versions. If I hot-swap `pip install base58==0.2.4` underneath the node control tool on the docker container to match the dependency in indy-plenum, the migration script `1_3_396_to_1_3_397.py` chokes with a stack trace ending in ``` File "/usr/local/lib/python3.5/dist-packages/plenum/common/messages/fields.py", line 350, in Base58Field _alphabet = set(base58.alphabet.decode("utf-8")) AttributeError: 'str' object has no attribute 'decode' ``` and I see that base58.py v0.2.4 had `alphabet` as a `str` where v1.0.0 has it as a `bytes`. It could be as simple as finding these and using `set(base58.alphabet.decode('utf-8') if isinstance(base58.alphabet, bytes) else base58.alphabet` instead, then relaxing the requirements to base58>=0.2.4 throughout?

sklump (Fri, 31 Aug 2018 17:26:50 GMT):
I have to create a ticket for this in Jira. There is definitely incompatibility in required base58 versions. If I hot-swap `pip install base58==0.2.4` underneath the node control tool on the docker container to match the dependency in indy-plenum, the migration script `1_3_396_to_1_3_397.py` chokes with a stack trace ending in ``` File "/usr/local/lib/python3.5/dist-packages/plenum/common/messages/fields.py", line 350, in Base58Field _alphabet = set(base58.alphabet.decode("utf-8")) AttributeError: 'str' object has no attribute 'decode' ``` and I see that base58.py v0.2.4 had `alphabet` as a `str` where v1.0.0 has it as a `bytes`. It could be as simple as finding these and using `set(base58.alphabet.decode('utf-8') if isinstance(base58.alphabet, bytes) else base58.alphabet` instead, then relaxing the requirements to base58>=0.2.4 throughout? I can't imagine base58 semantics have changed appreciably otherwise.

sureshtedla (Fri, 31 Aug 2018 17:29:41 GMT):
Has joined the channel.

sklump (Fri, 31 Aug 2018 18:20:14 GMT):
It could be as simple as finding these and using `set(base58.alphabet.encode('utf-8') if isinstance(base58.alphabet, str) else base58.alphabet` instead, then relaxing the requirements to base58>=0.2.4 throughout?

sklump (Fri, 31 Aug 2018 18:20:14 GMT):
It could be as simple as finding these and using `set(base58.alphabet.decode('utf-8') if isinstance(base58.alphabet, bytes) else base58.alphabet` instead, then relaxing the requirements to base58>=0.2.4 throughout?

RyanWest (Fri, 31 Aug 2018 20:19:33 GMT):
Yes, @sklump, I ran into this base58 problem over three months ago and had requested that the base58 dependency be changed as well. I thought that it was, but perhaps there were more places where it hadn't been updated.

ShivVenkatraman (Sat, 01 Sep 2018 01:11:04 GMT):
Has joined the channel.

ShivVenkatraman (Sat, 01 Sep 2018 01:15:44 GMT):
I am an indy newbie. I followed the instructions in https://github.com/hyperledger/indy-node/blob/master/docs/start-nodes.md; and could run init_indy_node and generate_indy_pool_transactions on Ubuntu using sandbox network. However when I run 'start_indy_node Alpha 0.0.0.0 9701 0.0.0.0 9702' I get the following error: CURVE I: cannot open client HELLO -- wrong server key?

SherifMuhammed (Sun, 02 Sep 2018 15:07:30 GMT):
Hi , Is it possible to use Indy as an Authenticator ?

tkdp (Tue, 04 Sep 2018 09:11:58 GMT):
Has joined the channel.

sklump (Tue, 04 Sep 2018 11:14:10 GMT):
I'm still trying to build a pool running indy node protocol 1.3.x so I can upgrade it. Mr. Vladimir Shishkin pointed out that upgrading the pool (docker simulation) that ships with indy-sdk is futile, so I should use the one in the indy-node environment instead. How do I get the indy-pool in indy-node to run protocol 1.3? I'm running with `git checkout 1.3.62-stable` but `client_for_pool_start.sh` still spins up ``` Indy-CLI (c) 2017 Evernym, Inc. Type 'help' for more information. Running Indy 1.6.593 indy> ``` Please and thanks.

sklump (Tue, 04 Sep 2018 11:14:10 GMT):
I'm still trying to build a pool running indy node protocol 1.3.x so I can upgrade it. Mr. Vladimir Shishkin pointed out that upgrading the pool (docker simulation) that ships with indy-sdk is futile, so I should use the one in the indy-node environment instead. How do I get the indy-pool in indy-node to run protocol 1.3? I'm running with `git checkout 1.3.62-stable` but `client_for_pool_start.sh` still spins up ``` ... Indy-CLI (c) 2017 Evernym, Inc. Type 'help' for more information. Running Indy 1.6.593 indy> ``` How do I instruct this pool to run an old version of indy node?

brycebudd (Tue, 04 Sep 2018 15:54:54 GMT):
Has joined the channel.

ashcherbakov (Wed, 05 Sep 2018 06:23:57 GMT):
@sklump I think you can just get the latest master version, and manually specify the desired versions in https://github.com/hyperledger/indy-node/blob/master/environment/docker/pool/core.ubuntu.dockerfile#L23 like `RUN apt-get update -y && apt-get install -y indy-anoncreds==1.0.11 indy-crypto==0.4.0 python3_indy_crypto_ver==0.4.0 indy-plenum==1.2.42 indy-node==1.3.62`

sklump (Wed, 05 Sep 2018 11:05:54 GMT):
Thanks - after a bit of tweaking that runs Indy 1.3.62 :)

sklump (Wed, 05 Sep 2018 11:06:58 GMT):
(apt-get `python3-base58=0.2.4`, replace indy-stream `master` with `stable`)

sklump (Wed, 05 Sep 2018 11:06:58 GMT):
(`apt-get python3-base58=0.2.4`, replace indy-stream `master` with `stable`)

sklump (Wed, 05 Sep 2018 11:06:58 GMT):
( `apt-get python3-base58=0.2.4`, replace indy-stream `master` with `stable`)

sklump (Wed, 05 Sep 2018 12:44:46 GMT):
Using indy-sdk, I can get this pool to schedule the upgrade, but then it doesn't actually upgrade. Further requests are invalid ( ` InvalidClientRequest(\"Upgrade 'upgrade-pool' is already scheduled\",)" `, but no upgrade proceeds. I'm stripping it down to one node to see if that helps.

SRibeiro (Wed, 05 Sep 2018 12:55:32 GMT):
Has joined the channel.

sklump (Wed, 05 Sep 2018 13:06:02 GMT):
I'm looking all over the docker container for logs, but I can't find any. Would you know the default?

sklump (Wed, 05 Sep 2018 13:38:04 GMT):
One bad thing: running `indy-node/environment/docker/pool/pool_start.sh` starts a docker network, `pool-network`, that knocks out DNS on my guest OS. That probably prevents the docker container from finding any hosts it needs to implement the upgrade. I have no idea how this might come to pass but it's reproducible. I hope you have a better experience upgrading the live network, but this is where I step off.

sklump (Wed, 05 Sep 2018 13:38:04 GMT):
One bad thing: running `indy-node/environment/docker/pool/pool_start.sh` starts a docker network, `pool-network`, that knocks out DNS on my guest OS. That probably prevents the docker container from finding any hosts it needs to implement the upgrade. The pool-network is 10.0.0.0/8, which clobbers my name service at 10.17.<...>. I will replace it with a less greedy 10.0.0.0/24 and see what happens.

sklump (Wed, 05 Sep 2018 15:04:56 GMT):
Another bad thing: A cred def against node protocol 1.3 uses no tag. Now if my issuer wants to find it programmatically on a node pool that has upgraded to 1.4 or higher, it will be in the wallet but under something that is no longer a cred def id. It won't find it on the ledger either. This might be partially my own deficient code that needs a workaround.

sklump (Wed, 05 Sep 2018 15:04:56 GMT):
Another bad thing: A cred def against node protocol 1.3 uses no tag in its cred def id. Now if my issuer wants to find it programmatically on a node pool that has upgraded to 1.4 or higher, it will be in the wallet but under something that is no longer a cred def id. It won't find it on the ledger either. This might be partially my own deficient code that needs some workaround. It is definitely goint to mess up my tails file processing. I see the usefulness of tags for cred def ids, but this is going to be a bug factory for a while.

swcurran (Wed, 05 Sep 2018 15:16:19 GMT):
@sklump - so scenario is * Create a CredDef using a 1.3 Node Pool and Indy-SDK 1.6 client * Upgrade the Node Pool to 1.4 (or 1.6) * The CredDef cannot be found in the wallet (no tag) and cannot be retrieved from the Node Pool. The same scenario entirely on a 1.4 (or 1.6) Node Pool works fine. How do you find the CredDef on the 1.4/1.6 Node Pool?

swcurran (Wed, 05 Sep 2018 15:16:19 GMT):
@sklump - so scenario is - Create a CredDef using a 1.3 Node Pool and Indy-SDK 1.6 client - Upgrade the Node Pool to 1.4 (or 1.6) - The CredDef cannot be found in the wallet (no tag) and cannot be retrieved from the Node Pool. The same scenario entirely on a 1.4 (or 1.6) Node Pool works fine. How do you find the CredDef on the 1.4/1.6 Node Pool?

sklump (Wed, 05 Sep 2018 15:36:43 GMT):
I'm not sure what breaks and what doesn't, since I've only just been able to get the pool to upgrade and then force the new genesis transaction format into the test code.

sklump (Wed, 05 Sep 2018 15:36:43 GMT):
cred def on 1.3 looks like `Q4zqM7aXqm7gDQkUVLng9h:3:CL:18` and on 1.4, `Q4zqM7aXqm7gDQkUVLng9h:3:CL:18:tag`. Note trailing tag. Revocation registry id builds on cred def id. I'm not sure what breaks and what doesn't, since I've only just been able to get the pool to upgrade and then force the new genesis transaction format into the test code.

sklump (Wed, 05 Sep 2018 15:39:44 GMT):
But the issuer at least finds what was a lynchpin of cache indexation, credentials, revocation registry, and tails file processing is no longer a cred def. Could it issue new credentials against a cred def on an id that is not a cred def id anymore? What about the ones it had issued and/or revoked before? There is a galaxy of stuff to trace and troubleshoot. It will take longer to get an OK than it will to push indy node 1.4 or higher everywhere and quietly drop 1.3 support.

sklump (Wed, 05 Sep 2018 15:39:44 GMT):
But the issuer at least finds what was a lynchpin of cache indexation, credentials, revocation registry, and tails file processing is no longer a cred def id. Could it issue new credentials against a cred def on an id that is not a cred def id anymore? What about the ones it had issued and/or revoked before? There is a galaxy of stuff to trace and troubleshoot. It will take longer to get an OK than it will to push indy node 1.4 or higher everywhere and quietly drop 1.3 support.

swcurran (Wed, 05 Sep 2018 15:45:43 GMT):
Agree you shouldn't do coding to deal with this. I'm more interested in what the Indy Team's response is - both for this situation, and what they are testing in the future. They may get by on this release, but I don't think it works from here on out.

swcurran (Wed, 05 Sep 2018 15:46:17 GMT):
I've nudged the manager to ask Slava and/or Alex to work with you on this.

sklump (Wed, 05 Sep 2018 16:16:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=uyiugnW87CHcPcJfj) Follow-up: specifying `SUBNET="${BASE_IP}0/24"` (was `SUBNET="${BASE_IP}0/8"`) preserves DNS in the unfortunate case where the name server resides locally on a 10.* IP address.

sklump (Wed, 05 Sep 2018 16:16:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=uyiugnW87CHcPcJfj) Follow-up: specifying `SUBNET="${BASE_IP}0/24"` in `indy-node/environment/docker/pool/pool_start.sh` (was `SUBNET="${BASE_IP}0/8"`) preserves DNS in the unfortunate case where the name server resides locally on a 10.* IP address.

sklump (Wed, 05 Sep 2018 16:16:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=uyiugnW87CHcPcJfj) Follow-up: specifying `SUBNET="${BASE_IP}0/24"` in `indy-node/environment/docker/pool/pool_start.sh` (was `SUBNET="${BASE_IP}0/8"`) preserves DNS in the unfortunate case where the name server resides locally on a 10.* IP address, allowing the node upgrade to proceed when a trustee schedules it.

Dubh3124 (Thu, 06 Sep 2018 01:06:20 GMT):
Has joined the channel.

ryanwest6 (Thu, 06 Sep 2018 14:36:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=wjgdGE3n4m5Heb7MD) @sklump Thanks for adding your solutions here @sklump—it will likely help others with the same problem later on. As for the issues you've found, they need to be looked at. I'll spend some time looking for solutions

RyanWest (Thu, 06 Sep 2018 20:10:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=Ge5oL9sdP2Ynyd4Ht) @sklump Did you find a solution to this?

RyanWest (Thu, 06 Sep 2018 20:10:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=QGGe7t7BqJ9Dknpre) And apparently I have two usernames on here. I'll fix that.

ashcherbakov (Fri, 07 Sep 2018 06:56:28 GMT):
@sklump @swcurran > cred def on 1.3 looks like `Q4zqM7aXqm7gDQkUVLng9h:3:CL:18` > and on 1.4, `Q4zqM7aXqm7gDQkUVLng9h:3:CL:18:tag`. Note trailing tag. Revocation registry id builds on cred def id. > I'm not sure what breaks and what doesn't, since I've only just been able to get the pool to upgrade and then force the new genesis transaction format into the test code. This is expected, since Indy Node 1.4 contained breaking changes, and one of this changes (see https://github.com/hyperledger/indy-node/blob/master/docs/1.3_to_1.4_migration_guide.md) is adding a new field TAG at the end of Cred Def ID. So, you can fix it on app level just by appending either a valid tag or a default tag ('tag'). Please note, that all CRED_DEF txns that were present in 1.3 will be migrated (when updating to 1.4) to contain the tag field. That's why apps will need to specify it to be able to query. The tag is needed to distinguish CRED_DEFS created by the same DID for the same Schema.

sklump (Fri, 07 Sep 2018 10:29:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=QGGe7t7BqJ9Dknpre) @RyanWest Yes thanks - the problem was the node pool's docker network (10.0.0.0/8) covered my DNS server at 10.17.26.150 or whatever. Once I pared back its subnet to 10.0.0.0/24, the upgrade process's use of DNS (via apt-get) could proceed.

sklump (Fri, 07 Sep 2018 10:38:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=itPWR5kavChEuWfSD) @ashcherbakov When the migration process to 1.4 updates CRED_DEF txns from 1.3, what will it use for the tag? I can't be understanding you correctly - I thought that ledger entries were supposed to be immutable? Will the migration process also fix all txns using a revocation registry identifier (:4::3:CL: *:* :CL_ACCUM:) ? Again, how will it know what to use for the cred def id tag?

ashcherbakov (Fri, 07 Sep 2018 11:25:23 GMT):
@sklump Yes, migration script changes the transaction format (but not data) to support this (the last) breaking change. For CRED_DEF and corresponding REVOC_REG_DEFs, it add a default tag value. The default tag value is `tag`

ashcherbakov (Fri, 07 Sep 2018 11:25:23 GMT):
@sklump Yes, migration script changes the transaction format (but not data) to support this (the last) breaking change. For CRED_DEF and corresponding REVOC_REG_DEFs, it adds a default tag value. The default tag value is `tag`

ashcherbakov (Fri, 07 Sep 2018 11:25:23 GMT):
@sklump Yes, migration script changes the transaction format (but not data) to support this (the last) breaking change (so, this is violation of immutability, but it was approved for Sovrin). For CRED_DEF and corresponding REVOC_REG_DEFs, it adds a default tag value. The default tag value is `tag`

sklump (Fri, 07 Sep 2018 11:39:54 GMT):
@ashcherbakov thanks - credentials already in the wallet since their issue against a cred def circa protocol version 1.3, however, won't have the same cred def id as their cred def on the ledger after a migration to 1.4? I will have to do some investigation. I am still recommending not to issue credentials to a node pool running 1.3 and expect them to persist through a migration. Te von_anchor code base relies heavily on cred def ids to index all kinds of stuff. In hindsight, that was a mistake on my part - I should have realized the impact and run them through some kind of canonicalization process. I think the safest thing to do from our point of view is to wait for 1.4+ everywhere. It won't be long now in any case.

sklump (Fri, 07 Sep 2018 11:39:54 GMT):
@ashcherbakov thanks - credentials already in the wallet since their issue against a cred def circa protocol version 1.3, however, won't have the same cred def id as their cred def on the ledger after a migration to 1.4? I will have to do some investigation. I am still recommending not to issue credentials to a node pool running 1.3 and expect them to persist through a migration. The von_anchor code base relies heavily on cred def ids to index all kinds of stuff. In hindsight, that was a mistake on my part - I should have realized the impact and run them through some kind of canonicalization process. I think the safest thing to do from our point of view is to wait for 1.4+ everywhere. It won't be long now in any case.

sklump (Fri, 07 Sep 2018 11:39:54 GMT):
@ashcherbakov thanks. However, credentials already in the wallet since their issue against a cred def circa protocol version 1.3, won't have the same cred def id as their cred def on the ledger after a migration to 1.4? I will have to do some investigation. I am still recommending not to issue credentials to a node pool running 1.3 and expect them to persist through a migration. The von_anchor code base relies heavily on cred def ids to index all kinds of stuff. In hindsight, that was a mistake on my part - I should have realized the impact and run them through some kind of canonicalization process. I think the safest thing to do from our point of view is to wait for 1.4+ everywhere. It won't be long now in any case.

ashcherbakov (Fri, 07 Sep 2018 12:26:07 GMT):
@sklump @gudkov @esplinr I can see 3 options here: 1) Do not use 1.3 node/client for issuance and use >= 1.4 2) Have a fix on Indy Node side that will check if TAG field is empty in GET_CLAIM_DEF requests and append a default value when querying 3) Have a fix on Indy SDK side that will check if TAG field is empty in GET_CLAIM_DEF requests and append a default value when querying. This fix will not work if revocation is needed (since a ref to claim def in revoc txn still be the same) If we decide to go with 2 or 3, we will need to issue a hot fix release.

sklump (Fri, 07 Sep 2018 12:42:38 GMT):
For what it's worth, I vote #1. It carries the least project risk. #2 and #3 introduce a push for new code to bring a few weeks of functionality at most, which then becomes dead code forever. A bit of patience will provide the best solution.

PhillipGibb (Mon, 10 Sep 2018 06:43:13 GMT):
Docker indy_pool: running the docker file from sdk/ci and using the genesis file there: I am unable to ledger a did if I use the seed : 000000000000000000000000Steward1 because I am not authorized, but if I use 000000000000000000000000Trustee1 it works. 1. I was under the assumption that the Steward had the role and ability to ledger DIDs, or is the case that the steward was not part of the genesis transactions? 2. Would the Trustee alway be part of the genesis transactions and the steward did added after start up? Strange, because I thought that Stewards would run the nodes.

baoyangc (Tue, 11 Sep 2018 17:02:11 GMT):
Has joined the channel.

kenebert (Wed, 12 Sep 2018 16:58:53 GMT):
Has joined the channel.

farskipper (Wed, 12 Sep 2018 21:48:31 GMT):
Has joined the channel.

Rantwijk (Thu, 13 Sep 2018 13:15:26 GMT):
Has joined the channel.

MaheshSharma (Fri, 14 Sep 2018 07:32:37 GMT):
Has joined the channel.

MaheshSharma (Fri, 14 Sep 2018 07:34:16 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.

MaheshSharma (Fri, 14 Sep 2018 07:59:59 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...

gudkov (Mon, 17 Sep 2018 15:05:10 GMT):
@sklump @ashcherbakov Here are some investigation on Node 1.3 to 1.4 migration. I looked to the proposed plan and I have a feeling that we can avoid re-issuing of credentials and cred def keys during Node 1.3 -> 1.4 migration. Some background information: * Indy Node 1.3 (protocol version 1) uses the tuple (ISSUER_DID, SCHEMA_SEQ_NO) as an identifier of CRED_DEF * Indy Node 1.4 (protocol version 2) uses the tuple (ISSUER_DID, SCHEMA_SEQ_NO, TAG) as an identifier of CRED_DEF * The tag was introduced to allow posting multiple credential definitions from the one issuer DID * During upgrade to 1.4 Indy Node performs migration and adds tag field with the value "TAG" to all credential definition txns * Libindy 1.6 returns (ISSUER_DID, SCHEMA_SEQ_NO, TAG) as an ID of credential definition. * When credential is posted to the ledger with protocol version 1 tag field will be removed from the txn * When we looking of credential on the ledger with protocol version 1 tag field will be removed from the request, but as Node 1.3 supports only one cred def per DID it doesn't matter and correct cred def keys will be returned. The only problem is that tag field will be empty in response, but it doesn’t matter if libindy response parsers are used. As a result if issuer uses libindy 1.6 and tag=TAG for issuance of credentials resolving of cred def keys should work fine for Node 1.3 and Node 1.4 after migration. If different from "TAG" tag was used for credential definition creation it is still possible to recovery. Issuer just need to re-post cred def transaction of upgrading Node to 1.4.

gudkov (Mon, 17 Sep 2018 15:05:10 GMT):
@sklump @ashcherbakov Here are some investigation on Node 1.3 to 1.4 migration. I looked to the proposed plan and I have a feeling that we can avoid re-issuing of credentials and cred def keys during Node 1.3 -> 1.4 migration. Some background information: * Indy Node 1.3 (protocol version 1) uses the tuple (ISSUER_DID, SCHEMA_SEQ_NO) as an identifier of CRED_DEF * Indy Node 1.4 (protocol version 2) uses the tuple (ISSUER_DID, SCHEMA_SEQ_NO, TAG) as an identifier of CRED_DEF * The tag was introduced to allow posting multiple credential definitions from the one issuer DID * During upgrade to 1.4 Indy Node performs migration and adds tag field with the value "TAG" to all credential definition txns * Libindy 1.6 returns (ISSUER_DID, SCHEMA_SEQ_NO, TAG) as an ID of credential definition. * When credential is posted to the ledger with protocol version 1 tag field will be removed from the txn * When we looking of credential on the ledger with protocol version 1 tag field will be removed from the request, but as Node 1.3 supports only one cred def per DID it doesn't matter and correct cred def keys will be returned. The only problem is that tag field will be empty in response, but it doesn’t matter if libindy response parsers are used. As a result if issuer uses libindy 1.6 and tag=TAG for issuance of credentials resolving of cred def keys should work fine for Node 1.3 and Node 1.4 after migration. If different from "TAG" tag was used for credential definition creation it is still possible to recovery. Issuer just need to re-post cred def transaction after upgrading Node to 1.4.

swcurran (Mon, 17 Sep 2018 15:21:44 GMT):
Let's discuss in the google doc with Stephen K. His quick answer was not positive.

swcurran (Mon, 17 Sep 2018 15:22:25 GMT):
Too much impact on VON-Anchor for such a short gain.

RBorst (Tue, 18 Sep 2018 15:44:59 GMT):
Has joined the channel.

rgunn (Thu, 20 Sep 2018 03:59:25 GMT):
Has joined the channel.

Shyam_Pratap_Singh (Thu, 20 Sep 2018 06:47:03 GMT):
Has joined the channel.

ClearFoundation (Mon, 24 Sep 2018 06:40:20 GMT):
Has joined the channel.

ShivVenkatraman (Mon, 24 Sep 2018 20:33:58 GMT):
From the white paper, "What goes in Sovrin", the revocation registries are published by the issuer and stored in Sovrin. How fast (and big) does the revocation registration grow? If 1000s of claims are revoked, what are the implications on the run time performance during validation/verification?

ShivVenkatraman (Mon, 24 Sep 2018 20:33:58 GMT):
From the white paper, https://www.evernym.com/wp-content/uploads/2017/07/What-Goes-On-The-Ledger.pdf, the revocation registries are published by the issuer and stored in Sovrin. How fast (and big) does the revocation registration grow? If 1000s of claims are revoked, what are the implications on the run time performance during validation/verification?

MaheshSharma (Thu, 27 Sep 2018 11:05:49 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?

karthick15v (Fri, 28 Sep 2018 06:18:47 GMT):
Has joined the channel.

esplinr (Fri, 28 Sep 2018 23:51:08 GMT):
Everyone: Here is the recording of the sprint demo from the Evernym team: https://www.youtube.com/watch?v=Qv41uOORLsk&list=PLRp0viTDxBWGLdZk0aamtahB9cpJGV7ZF

phaniac (Mon, 01 Oct 2018 18:04:29 GMT):
Has joined the channel.

smithbk (Tue, 02 Oct 2018 17:30:44 GMT):
Hi, I am doing a `ledger.build_cred_def_request` and `ledger.sign_and_submit_request` to write a cred def to the ledger and am seeing 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)\"}"```

smithbk (Tue, 02 Oct 2018 17:31:11 GMT):
My versions are as follows: ```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```

smithbk (Tue, 02 Oct 2018 17:31:57 GMT):
It also fails to look up the cred def later.

smithbk (Tue, 02 Oct 2018 17:32:18 GMT):
Can anyone help tell me what I may be doing wrong ... or is it a bug?

aniv (Wed, 03 Oct 2018 09:12:46 GMT):
Has joined the channel.

arjunkhera (Wed, 03 Oct 2018 13:04:11 GMT):
Has joined the channel.

nage (Thu, 04 Oct 2018 03:14:27 GMT):
@ashcherbakov ^^^

ashcherbakov (Thu, 04 Oct 2018 14:36:13 GMT):
@smithbk What is the version of IndySDK? The version of indy-node looks pretty old (the current one is 1.6)

smithbk (Thu, 04 Oct 2018 15:08:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=tFNjJ7HsBaGrJ9WWK) @ashcherbakov I'm using `libindy=1.5.0`. Yes, I know it has moved to 1.6 but these are the versions that were associated with indy-sdk 1.5. We will be moving up to 1.6 but need to schedule that since there are multiple teams relying on a stable version

jlin (Fri, 05 Oct 2018 15:08:03 GMT):
Has joined the channel.

osesov (Thu, 11 Oct 2018 15:08:04 GMT):
Has joined the channel.

rbole (Sun, 21 Oct 2018 13:54:40 GMT):
Has joined the channel.

Paul-TAB (Mon, 22 Oct 2018 14:31:10 GMT):
Has joined the channel.

tomislav (Tue, 23 Oct 2018 18:00:43 GMT):
I know this has been asked many times before - I can't find an answer. What are the directories I should mount when using the getting started docker image, so I can preserve node data across container restarts?

twshelton (Thu, 25 Oct 2018 13:43:48 GMT):
Has left the channel.

haniavis (Thu, 25 Oct 2018 22:47:28 GMT):
Has joined the channel.

mark.hadley (Mon, 29 Oct 2018 21:33:19 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=9Kq5ujjBKsHejwRZ8) @tomislav probably `/var/lib/indy` and '/var/log/lindy'

MichaelLitchev (Mon, 29 Oct 2018 21:50:30 GMT):
Has joined the channel.

bhagadorn (Wed, 31 Oct 2018 19:00:04 GMT):
Has joined the channel.

NateThelen (Wed, 31 Oct 2018 22:00:40 GMT):
Has joined the channel.

mgbailey (Fri, 02 Nov 2018 22:34:39 GMT):
and maybe /etc/indy [late response]

ShivVenkatraman (Mon, 05 Nov 2018 18:45:48 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.)

faisal00813 (Tue, 06 Nov 2018 05:52:25 GMT):
@ShivVenkatraman This could be a good starting point for mac https://github.com/hyperledger/indy-node/tree/master/dev-setup/osx

lsg1213 (Tue, 06 Nov 2018 07:08:19 GMT):
Has joined the channel.

lsg1213 (Tue, 06 Nov 2018 07:09:15 GMT):
Hello, I don't understand claim. what is the definition? :)

ShivVenkatraman (Tue, 06 Nov 2018 17:46:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=8jek3wvBSBTtRnrps) @faisal00813 Thanks. That script seems to be for sdk; to build libindy.

kh.nguyen (Wed, 07 Nov 2018 01:36:56 GMT):
Has joined the channel.

drummondreed (Wed, 07 Nov 2018 04:51:47 GMT):
Has left the channel.

LucW (Thu, 08 Nov 2018 09:41:36 GMT):
Has joined the channel.

Tvrtko (Thu, 08 Nov 2018 12:41:42 GMT):
Has joined the channel.

Tvrtko (Thu, 08 Nov 2018 12:43:32 GMT):
hi - does anyone know if there is a way to "explore" the chain behind hyperledger indy? For example is there a way to see the individual transactions on the merkle tree ? something like when you do a "get-nym" command on indy-cli and get an output but show a list of entries instead of just one entry ?

sklump (Thu, 08 Nov 2018 14:34:03 GMT):
Has left the channel.

mwherman2000 (Thu, 08 Nov 2018 22:35:09 GMT):
Has joined the channel.

mgbailey (Fri, 09 Nov 2018 15:57:56 GMT):
@Tvrtko if you are a steward and log into your validator node, you can use "sudo read_ledger --type domain" to see transactions. Default is to show the first 100 transactions, but there are flags to control this.

mgbailey (Fri, 09 Nov 2018 15:59:57 GMT):
I know that you can also fetch an arbitrary transaction using the sdk, but I don't think this functionality has been exposed in the cli

MALodder (Fri, 09 Nov 2018 22:51:11 GMT):
Has joined the channel.

MALodder (Fri, 09 Nov 2018 22:51:35 GMT):
Is there a way to start the pool in the getting started guide with log output set to DEBUG?

haggs (Mon, 12 Nov 2018 02:15:49 GMT):
@MALodder I think if you change the log level inside the dockerfile you can do so

umamaheswarv (Mon, 12 Nov 2018 16:49:10 GMT):
Has joined the channel.

baconsandwich (Tue, 13 Nov 2018 04:11:14 GMT):
In what way are the three ledgers (pool, config, domain) separated? I suppose they all run on each node. Are they differente processes? Is consensus calculated independently? Where can I find more info about this?

baconsandwich (Tue, 13 Nov 2018 04:11:14 GMT):
In what way are the three ledgers (pool, config, domain) separated? I suppose they all run on each node. Are they different processes? Is consensus calculated independently? Where can I find more info about this?

ashcherbakov (Tue, 13 Nov 2018 06:21:13 GMT):
@baconsandwich - All ledgers are present on all nodes. - Indy-node is a single-process service, so all ledgers are in the same process. - Each ledger has its own key-value storages (for transaction logs and merkle tree). - RocksDB is used as a key-value storage - you can read more in docs folder, in particular https://github.com/hyperledger/indy-plenum/blob/master/docs/storage.md

mgbailey (Tue, 13 Nov 2018 22:28:37 GMT):
@MALodder add "logLevel = 0" to /etc/indy/indy_config.py

swcurran (Tue, 13 Nov 2018 22:30:46 GMT):
@mgbailey - does this mean that the update that changes the logging mechanism has been released? Previously we were using RUST_LOG env variable.

mgbailey (Tue, 13 Nov 2018 22:34:25 GMT):
This is for the pool, and is how you control the logging going to /var/log/indy/sandbox/.log

mgbailey (Tue, 13 Nov 2018 22:34:34 GMT):
It is not new

swcurran (Tue, 13 Nov 2018 22:34:59 GMT):
Thanks.

gy8409i (Thu, 15 Nov 2018 03:50:31 GMT):
Has joined the channel.

mxs1491 (Thu, 15 Nov 2018 10:30:30 GMT):
Has joined the channel.

baconsandwich (Fri, 16 Nov 2018 05:00:10 GMT):
Are there existing benchmark scripts that I can run to measure the throughput of a indy ledger? For example creating n identities or something like measuring claims per second so as to get a quantitative measuremment for a system?

sergey.khoroshavin (Fri, 16 Nov 2018 10:36:29 GMT):
@baconsandwich yes, they (as well as documentation on how to use them) are located here: https://github.com/hyperledger/indy-node/tree/master/scripts/performance

baconsandwich (Fri, 16 Nov 2018 12:10:35 GMT):
@sergey.khoroshavin Thanks a lot!

baconsandwich (Sun, 18 Nov 2018 09:38:39 GMT):
Do observer nodes need some kind of authentication to read the ledgerl? Afaik validator nodes can only be added by stewards. The [role spreadsheet](https://docs.google.com/spreadsheets/d/1TWXF7NtBjSOaUIBeIH77SyZnawfo91cJ_ns4TR-wsq4/edit#gid=0) says "later". But in general, will someone else have to add an observer or can I just participate like that, as in bitcoin for example. Has this been discussed yet?

baconsandwich (Sun, 18 Nov 2018 09:38:39 GMT):
Do observer nodes need some kind of authentication to read the ledgerl? Afaik validator nodes can only be added by stewards. The [role spreadsheet](https://docs.google.com/spreadsheets/d/1TWXF7NtBjSOaUIBeIH77SyZnawfo91cJ_ns4TR-wsq4/edit#gid=0) says "later" in regards to observers. But in general, will someone else have to add an observer or can I just participate like that, as in bitcoin for example. Has this been discussed yet? I am trying to evaluate how high the entry barrier for observers willl be.

n3m (Sun, 18 Nov 2018 17:15:11 GMT):
Has left the channel.

pradeepjain (Tue, 20 Nov 2018 05:09:55 GMT):
Has joined the channel.

esplinr (Tue, 20 Nov 2018 23:22:35 GMT):
@baconsandwich We haven't implemented observer nodes yet, so answers to your questions don't exist.

baconsandwich (Wed, 21 Nov 2018 08:59:19 GMT):
@esplinr ok, thanks. I didnt not find a clear statement regarding this

baconsandwich (Wed, 21 Nov 2018 08:59:19 GMT):
@esplinr ok, thanks. I did not find a clear statement regarding this

yisheng (Fri, 23 Nov 2018 06:44:02 GMT):
Has joined the channel.

manner (Fri, 23 Nov 2018 09:58:11 GMT):
Has joined the channel.

Derashe (Fri, 23 Nov 2018 10:00:05 GMT):
Hello everybody. We have finally removed old client code, which was merged with our plenum & node codebases. For now the only way to connect to ledger and send transactions is Indy SDK (https://github.com/hyperledger/indy-sdk). Old getting started guide is deprecated too. You can find new one at https://github.com/hyperledger/indy-sdk/blob/master/doc/getting-started/getting-started.md

HiranKumar (Sun, 25 Nov 2018 15:03:07 GMT):
Has joined the channel.

HiranKumar (Sun, 25 Nov 2018 18:31:57 GMT):
I installed a node of network using docker in a linux vm.And the docker container is running like as shown below

HiranKumar (Sun, 25 Nov 2018 18:32:22 GMT):

Clipboard - November 26, 2018 12:01 AM

HiranKumar (Sun, 25 Nov 2018 18:32:43 GMT):
I tried to connect the network from the local machine using indy-cli. But got the below error

HiranKumar (Sun, 25 Nov 2018 18:32:57 GMT):

Clipboard - November 26, 2018 12:01 AM

HiranKumar (Sun, 25 Nov 2018 18:33:08 GMT):
Anyone please help me to solve this issue

mgbailey (Mon, 26 Nov 2018 15:09:19 GMT):
An interesting question from a steward: Samuel Krieg [6:05 AM] When backing up the `/var/lib/indy` folder, do I have to stop the service or do any other related action in order to have consistent data? @ashcherbakov , can we get a dev perspective?

ashcherbakov (Mon, 26 Nov 2018 15:55:08 GMT):
@mgbailey I believe the service needs to be stopped when doing backup

smithbk (Mon, 26 Nov 2018 16:32:53 GMT):
Hi, I have a general question about the relationship between the multiple ledgers. Is the processing of a transaction on the domain ledger dependent upon data from the config ledger? If yes, doesn't that introduce non-determinism when processing a transaction on the domain ledger which could result in a split? For example, suppose config transaction C and domain transaction D are submitted at about the same time, where some nodes perform C and then D while other nodes perform D and then C. Couldn't this cause different results for transaction D on different nodes? Thanks

JamieLi (Tue, 27 Nov 2018 00:57:41 GMT):
Has joined the channel.

JamieLi (Tue, 27 Nov 2018 00:57:56 GMT):
KeyValueStorageRocksdbIntKeys.open ignores the "read_only" flag. Can it be fixed?

JamieLi (Tue, 27 Nov 2018 00:59:27 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)

ashcherbakov (Tue, 27 Nov 2018 06:08:20 GMT):
@smithbk The purpose of consensus algorithm implemented in Plenum is to make sure that all nodes have transactions ordered in the same order for all ledgers. The Primary proposes the next transactions to be ordered. The transactions are ordered by batches, and 1 batch can contain transactions from one ledger only. So, this makes the process deterministic. Moreover, dynamic validation (and comparing of root hashes) is part of consensus algorithm, so during ordering we also make sure that all data is consistent.

ashcherbakov (Tue, 27 Nov 2018 06:11:20 GMT):
@JamieLi https://github.com/ashcherbakov/indy-plenum/blob/master/storage/kv_store_rocksdb_int_keys.py#L26 - it has read_only flag passed there, and as I know it works (that's why, for example, validator_info works from a different process). Do you see any cases when it doesn't work? Is there a test for this?

smithbk (Tue, 27 Nov 2018 21:51:59 GMT):
@ashcherbakov Thanks much. Another related question pls. Is there a way to query values from the ledger at some time (or logical time) in the past? My ultimate goal is for two verifiers to be guaranteed to get the same verification result, but this requires that they get the same info from the ledger when performing verification even though they ask at different times.

mgbailey (Tue, 27 Nov 2018 23:19:11 GMT):
@smithbk there is a timestamp on each transaction, this is generally exposed to client queries. For example, I get this from the CLI when I query for a NYM:

mgbailey (Tue, 27 Nov 2018 23:19:17 GMT):
pool(testnet):wallet(testnet_wallet):did(6fe...zSJ):indy> ledger get-nym did=MbFr18DvT2pSXipr86Ep3z Following NYM has been received. Metadata: +------------------------+-----------------+---------------------+---------------------+ | Identifier | Sequence Number | Request ID | Transaction time | +------------------------+-----------------+---------------------+---------------------+ | 6feBTywcmJUriqqnGc1zSJ | 11737 | 1543359673840331363 | 2018-11-14 16:08:56 | +------------------------+-----------------+---------------------+---------------------+ Data: +------------------------+------------------------+----------------------------------------------+--------------+ | Identifier | Dest | Verkey | Role | +------------------------+------------------------+----------------------------------------------+--------------+ | 6feBTywcmJUriqqnGc1zSJ | MbFr18DvT2pSXipr86Ep3z | CDunX3DH6SAch5GAb4WPw6g1XgPHiUM8Nrs6g1hwEzbd | TRUST_ANCHOR | +------------------------+------------------------+----------------------------------------------+--------------+

smithbk (Wed, 28 Nov 2018 03:46:02 GMT):
@mgbailey Thanks. Yes, I knew there was a time stamp in each transaction and so the raw data is there to determine what the values were at some time in the past, but I'm wondering if there is a ledger or SDK API automatically determines what the values were by walking the blocks/transactions for you.

carsten (Wed, 28 Nov 2018 04:33:53 GMT):
Has joined the channel.

ashcherbakov (Wed, 28 Nov 2018 06:17:46 GMT):
@smithbk Yes, every txn (reply) has a timstamp guaranteed by consensus. In general, this is up to application to check how fresh the result is. But Indy-SDK is going to have more API to help in verifying the freshness of the timestamp soon (the work is started this sprint)

donqui (Fri, 30 Nov 2018 15:34:21 GMT):
Has joined the channel.

DirkT (Mon, 03 Dec 2018 14:52:08 GMT):
Has joined the channel.

bootstrapsp (Mon, 03 Dec 2018 19:24:31 GMT):
Has joined the channel.

bootstrapsp (Mon, 03 Dec 2018 19:25:00 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

ozheregelya (Mon, 03 Dec 2018 19:41:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=gATzvCyYRDFeDWjRK) @bootstrapsp Yes, `/etc/indy/indy_config.py` is right place. You can use any name for network. It will affect only folder names (`/var/log/indy/`, `/var/lib/indy/`) on your machine. Example: ``` # Current network NETWORK_NAME = 'sandbox' ```

ozheregelya (Mon, 03 Dec 2018 19:41:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=gATzvCyYRDFeDWjRK) @bootstrapsp Yes, `/etc/indy/indy_config.py` is right place. You can use any name for network. It will affect only folder names (`/var/log/indy/` , `/var/lib/indy/`) on your machine. Example: ``` # Current network NETWORK_NAME = 'sandbox' ```

ozheregelya (Mon, 03 Dec 2018 19:41:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=gATzvCyYRDFeDWjRK) @bootstrapsp Yes, `/etc/indy/indy_config.py` is right place. You can use any name for network. It will affect only folder names ( `/var/log/indy/` , `/var/lib/indy/` ) on your machine. Example: ``` # Current network NETWORK_NAME = 'sandbox' ```

bootstrapsp (Mon, 03 Dec 2018 19:47:27 GMT):
@ozheregelya thanks! that works

bootstrapsp (Mon, 03 Dec 2018 19:47:47 GMT):
post that step do I need to manually create this pool_transactions_genesis file

bootstrapsp (Mon, 03 Dec 2018 19:52:16 GMT):
I don't see anything other than keys folder in /var/lib/indy/ {NETWORK_NAME}/

ozheregelya (Mon, 03 Dec 2018 19:56:09 GMT):
@bootstrapsp It depends on what you are going to do. If you are going to connect the node to existing pool: https://github.com/hyperledger/indy-node/blob/master/docs/add-node.md If you are going to run own test network: https://github.com/hyperledger/indy-node#how-to-install-a-test-network

bootstrapsp (Mon, 03 Dec 2018 19:57:54 GMT):
@ozheregelya I'm basically following this https://github.com/hyperledger/indy-node/blob/master/docs/start-nodes.md

bootstrapsp (Mon, 03 Dec 2018 19:58:26 GMT):
generically speaking just trying to understand the structure, (instead of just blackboxing it with docker build)

ozheregelya (Mon, 03 Dec 2018 20:03:49 GMT):
@bootstrapsp Here https://github.com/hyperledger/indy-node/blob/master/docs/start-nodes.md#generating-keys-and-test-genesis-transaction-files-for-a-test-network `generate_indy_pool_transactions` will create pool and domain genesis files. In case of `init_indy_node`, proper genesis files should be put to the /var/lib/indy/ manually.

bootstrapsp (Mon, 03 Dec 2018 20:06:31 GMT):
@ozheregelya thank you! gonna try this now

HiranKumar (Tue, 04 Dec 2018 11:13:12 GMT):
How can we store the credentials and do the verification process without using ledger

dnnn (Tue, 04 Dec 2018 11:53:34 GMT):
Has joined the channel.

dnnn (Tue, 04 Dec 2018 11:59:31 GMT):
Hi, I have a question regarding genesis_txn_file. What `reqSignature` stands for in each transaction item? And when and how it is created/used?

MiguelFJimenezSola (Tue, 04 Dec 2018 19:26:02 GMT):
Has joined the channel.

user7429 (Wed, 05 Dec 2018 05:18:12 GMT):
Has joined the channel.

ashcherbakov (Wed, 05 Dec 2018 07:16:09 GMT):
@HiranKumar Indy requires Ledger for getting a Public Key (CRED_DEF) for credentials verification. In principle, omne can use just verifiable credentials crypto (see Hyperledger Ursa or Hyperlddger indy-crypto).

ashcherbakov (Wed, 05 Dec 2018 07:17:30 GMT):
@dnnn Every write request (transaction) to the Ledger must be signed by a sender (using a key associated with a DID stored on the ledger; so every sender needs to have a DID on the ledger). `reqSignature` is the sender's signarture against the request (transaction), We store it in the Ledger together with the content.

dnnn (Wed, 05 Dec 2018 08:38:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=7qgtJZt4J89jajJMh) @ashcherbakov Hi Alexander, and big thanks for the answer! what signature should be specified for genesis transaction file when you initially start the network with the first nodes (for example 4) in it? In `indy-sdk` examples I have seen `genesis_txn` files with empty `reqSignature` field. Is it legit to have it empty for those transactions for genesis nodes?

ashcherbakov (Wed, 05 Dec 2018 08:39:19 GMT):
@dnnn Yes, for genesis txns this is fine to have no (absent) reqSignature

dnnn (Wed, 05 Dec 2018 08:49:54 GMT):
@ashcherbakov thanks! also if you do not mind I have a question regarding provided `init_indy_keys` script. for example, when I run it during debian `indy-node` installation process for node named `node_a` as an output I get every needed public key for `genesis_txn` file (which will contain `node_a` as a genesis node). If my understanding is correct `init_indy_keys` also generate private keys. My question is how private keys are managed and where `init_indy_keys` scripts put them?

ashcherbakov (Wed, 05 Dec 2018 08:51:24 GMT):
yes, private keys are also created. They are stored in `/var/lib/indy` in a file.

dnnn (Wed, 05 Dec 2018 08:54:47 GMT):
@ashcherbakov great, thanks for your help. have a superduper day! :relaxed:

user7429 (Wed, 05 Dec 2018 08:57:04 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? I am using indy-sdk python wrapper for establishing connection.

esplinr (Wed, 05 Dec 2018 21:09:35 GMT):
https://www.youtube.com/watch?v=WZin717AT_A&list=PLRp0viTDxBWGLdZk0aamtahB9cpJGV7ZF

esplinr (Wed, 05 Dec 2018 21:09:35 GMT):
An architecture overview of Indy Plenum, courtesy @ashcherbakov : https://www.youtube.com/watch?v=WZin717AT_A&list=PLRp0viTDxBWGLdZk0aamtahB9cpJGV7ZF

SanjeevKumarn (Thu, 06 Dec 2018 06:06:14 GMT):
Has joined the channel.

dnnn (Thu, 06 Dec 2018 12:35:19 GMT):

Clipboard - December 6, 2018 3:35 PM

dnnn (Thu, 06 Dec 2018 12:35:22 GMT):
Hi everybody, could anyone be so kind and help me with clarification how those fields are derived for initial `pool_transactions_genesis` file entry?

ashcherbakov (Thu, 06 Dec 2018 12:50:30 GMT):
@dnnn There is a script that can help generating gensis txns: `generate_indy_pool_transactions` Please have a look at https://github.com/hyperledger/indy-node/blob/master/docs/start-nodes.md#generating-keys-and-test-genesis-transaction-files-for-a-test-network

dnnn (Fri, 07 Dec 2018 10:07:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=x4Lz8ZLmvXiqqneXK) @ashcherbakov big thanks for answers and your support!

dnnn (Fri, 07 Dec 2018 10:07:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=x4Lz8ZLmvXiqqneXK) @ashcherbakov @ashcherbakov big thanks for answers and your support!

dnnn (Fri, 07 Dec 2018 10:17:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=3v5iNwWYhezXHbYgH) Maybe someone else would need it. From what I found out: - `dest` is did of the node. but it is derived not as first 16 bytes of verkey. here are steps to do it in python: ``` from binascii import unhexlify # VERKEY_STRING is a "Verification key" in output of init_indy_keys script a = "VERKEY_STRING".encode() b = unhexlify(a) node_did = base58.b58encode(b) ``` - `from` in metadata is `did` of the initial client specified in `domain_transactions_genesis` file - `txnID` – transaction id. In examples it is derived as: ``` sha256(node_name.encode()).hexdigest() ``` where `node_name` is node's `alias` in `pool_transactions_genesis` file entry

dnnn (Fri, 07 Dec 2018 10:17:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=3v5iNwWYhezXHbYgH) Maybe someone else would need it. From what I found out: - `dest` is did of the node. but it is derived not as first 16 bytes of verkey. here are steps to do it in python: ``` from binascii import unhexlify # VERKEY_STRING is a "Verification key" in output of init_indy_keys script a = "VERKEY_STRING".encode() b = unhexlify(a) node_did = base58.b58encode(b) ``` - `from` in metadata is did of the initial client specified in `domain_transactions_genesis` file - `txnID` – in examples transaction id is derived as: sha256(node_name.encode()).hexdigest() where node_name is node's alias in pool_transactions_genesis file

jeff_g (Sun, 09 Dec 2018 12:38:34 GMT):
Has joined the channel.

HiranKumar (Mon, 10 Dec 2018 11:38:46 GMT):
While starting node,I got a message like wrong server key.

HiranKumar (Mon, 10 Dec 2018 11:38:58 GMT):
Would you please help me to solve this issue

PatrikStas (Mon, 10 Dec 2018 15:53:55 GMT):
Hi. I am trying to use indy-cli to connect to mainnet. I am using following genesis pool transactions, but I got some issue with danube node. Check out following logs from indy-cli

PatrikStas (Mon, 10 Dec 2018 15:53:55 GMT):
Hi. I am trying to use indy-cli to connect to mainnet. I am using following genesis pool transactions https://github.com/sovrin-foundation/sovrin/blob/stable/sovrin/pool_transactions_live_genesis , but I got some issue with danube node. Check out following logs from indy-cli

PatrikStas (Mon, 10 Dec 2018 15:54:37 GMT):

sovrin-mainnet.log

PatrikStas (Mon, 10 Dec 2018 15:55:25 GMT):
What do I need to do in order to connect to mainnet?

HiranKumar (Tue, 11 Dec 2018 05:46:52 GMT):
Now I got a message like cannot open client HELLO , wrong server key. WHILE EXECUTING start_indy_node Node2 0.0.0.0 9703 0.0.0.0 9704 would you please help me to solve this

HiranKumar (Tue, 11 Dec 2018 06:31:41 GMT):
Now I got an error like AttributeError: module '_sha3' has no attribute 'sha3'

HiranKumar (Tue, 11 Dec 2018 06:31:48 GMT):
while starting the nodes

user7429 (Tue, 11 Dec 2018 09:32:36 GMT):
Hi everyone....Could anyone help me out on this: I am getting this error : indy.error.IndyError: ErrorCode.PoolLedgerTimeout WARNING:indy.libindy:_indy_loop_callback: Function returned error 307 at this step : Send Nym to Ledger for "Sovrin Steward Government" DID whereas in the logs i am getting this `2018-12-10 07:44:38,850|INFO|ledger_manager.py|Node1 received ledger status: LEDGER_STATUS{'txnSeqNo': 1, 'merkleRoot': '6mMyswGcmoXXe1oAU3WLQEELahHU4XFjpmJJYmFyiEc8', 'viewNo': None, 'protocolVersion': 2, 'ledgerId': 0, 'ppSeqNo': None} from b']McJV*(cFe:aKsQ!i(^*?x/pp4:AO>x/8:tI!VKC' 2018-12-10 07:44:38,851|INFO|ledger_manager.py|Node1 comparing its ledger 0 of size 1 with 1 2018-12-10 07:44:38,852|INFO|ledger_manager.py|Node1 comparing its ledger 0 of size 1 with 1 2018-12-10 07:44:54,680|NOTIFICATION|node.py|Node1 primary has been disconnected for too long 2018-12-10 07:44:54,680|INFO|node.py|Node1 The node is not ready yet so view change will not be proposed now, but re-scheduled. 2018-12-10 07:45:54,532|WARNING|replicas.py|Unordered request with reqId: 091e0a4426c9ec22a575c533c212ff7ac08f4273773d9f1f2e6e015dcd431231 was not found in prePrepares. Prepares count: 0, Commits count: 0 `

user7429 (Tue, 11 Dec 2018 09:32:36 GMT):
Hi everyone....Could anyone help me out on this: I am getting this error : indy.error.IndyError: ErrorCode.PoolLedgerTimeout WARNING:indy.libindy:_indy_loop_callback: Function returned error 307 at this step : Send Nym to Ledger for "Sovrin Steward Government" DID whereas in the logs i am getting this `2018-12-10 07:44:38,850|INFO|ledger_manager.py|Node1 received ledger status: LEDGER_STATUS{'txnSeqNo': 1, 'merkleRoot': '6mMyswGcmoXXe1oAU3WLQEELahHU4XFjpmJJYmFyiEc8', 'viewNo': None, 'protocolVersion': 2, 'ledgerId': 0, 'ppSeqNo': None} from b']McJV*(cFe:aKsQ!i(^*?x/pp4:AO>x/8:tI!VKC' 2018-12-10 07:44:38,851|INFO|ledger_manager.py|Node1 comparing its ledger 0 of size 1 with 1 2018-12-10 07:44:38,852|INFO|ledger_manager.py|Node1 comparing its ledger 0 of size 1 with 1 2018-12-10 07:44:54,680|NOTIFICATION|node.py|Node1 primary has been disconnected for too long 2018-12-10 07:44:54,680|INFO|node.py|Node1 The node is not ready yet so view change will not be proposed now, but re-scheduled. 2018-12-10 07:45:54,532|WARNING|replicas.py|Unordered request with reqId: 091e0a4426c9ec22a575c533c212ff7ac08f4273773d9f1f2e6e015dcd431231 was not found in prePrepares. Prepares count: 0, Commits count: 0 ` I am stuck at sending NYM keys... Please help me in resolving this or any leads to look in

donqui (Tue, 11 Dec 2018 09:53:43 GMT):
@user7429 https://github.com/hyperledger/indy-sdk#how-to-start-local-nodes-pool-with-docker

donqui (Tue, 11 Dec 2018 09:54:07 GMT):
there is an explanation what may be causing the error and how to fix it

user7429 (Tue, 11 Dec 2018 10:48:36 GMT):
@donqui I have set up the indy node without docker...with single Node

user7429 (Tue, 11 Dec 2018 10:48:36 GMT):
@donqui I have set up the indy node without docker... single Node on Google cloud

HiranKumar (Tue, 11 Dec 2018 11:56:00 GMT):
Hi

HiranKumar (Tue, 11 Dec 2018 11:56:10 GMT):
I am also facing the same issue

HiranKumar (Tue, 11 Dec 2018 11:56:47 GMT):
while executing sdk.createPoolLedgerConfig,I got PoolLedgerConfigAlreadyExistsError

HiranKumar (Tue, 11 Dec 2018 11:57:53 GMT):
But when I execute sdk.openPoolLedger ,I got PoolLedgerConfigAlreadyExistsError

HiranKumar (Tue, 11 Dec 2018 11:58:13 GMT):
I setup the nodes without docker

HiranKumar (Tue, 11 Dec 2018 11:58:24 GMT):
which is in azure

user7429 (Tue, 11 Dec 2018 12:02:13 GMT):
@HiranKumar you got to delete the files from ~/.indy_client dir

donqui (Tue, 11 Dec 2018 13:24:25 GMT):
@user7429 aha, ok. have you check the addresses that are being used in the genesis files for both sdk and node? Even though you are not using docker the problem that is triggering the error might be the same one.

user7429 (Tue, 11 Dec 2018 13:29:06 GMT):
@donqui yes i have checked. Both the gensis files are same

user7429 (Tue, 11 Dec 2018 13:29:06 GMT):
@donqui yes i have checked. Both the gensis files are same What does indy node mean by the following log? _Unordered request with reqId: XXX was not found in prePrepares_

wombletron (Tue, 11 Dec 2018 20:08:46 GMT):
Has joined the channel.

kdenhartog (Tue, 11 Dec 2018 20:20:23 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=bq2oDBY4PuDzwkaCF) @PatrikStas Mainnet was having issues around the time you were trying to connect. Please try again. Also, for Sovrin specific things like this I'd suggest joining the Sovrin rocketchat at https://chat.sovrin.org

kdenhartog (Tue, 11 Dec 2018 20:23:09 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=CRoiFi4qEqR85swWJ) @donqui yup, you'll need to change the IP address that is in the genesis_pool_transaction_file which is in the cli folder. Alternatively, use https://github.com/kdenhartog/indy-dev

kdenhartog (Tue, 11 Dec 2018 20:23:09 GMT):
@user7429 yup, like @donqui mentioned you'll need to change the IP address that is in the genesis_pool_transaction_file which is in the cli folder. Alternatively, use https://github.com/kdenhartog/indy-dev which has been designed to setup nodes locally and solve this problem. Is it common for people to want to use nodes in a cloud environment? I suppose I could support that later on.

sam-kaw (Tue, 11 Dec 2018 22:05:01 GMT):
Has joined the channel.

richzhao (Wed, 12 Dec 2018 02:12:51 GMT):
Has joined the channel.

ashcherbakov (Wed, 12 Dec 2018 06:29:38 GMT):
@user7429 @HiranKumar Please use Docker to setup a pool of nodes. The minimum number of nodes is 4 (the docker can setup exactly 4 nodes)

ashcherbakov (Wed, 12 Dec 2018 06:29:59 GMT):
@HiranKumar Pleas make sure that you use Ubuntu 16.04 and Python 3,5

HiranKumar (Wed, 12 Dec 2018 08:50:10 GMT):
Thanks @ashcherbakov

HiranKumar (Wed, 12 Dec 2018 08:50:44 GMT):
Now it working @ashcherbakov

user7429 (Thu, 13 Dec 2018 10:29:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=WtvNEpg8t89YdsDwL) @ashcherbakov thanks @ashcherbakov it helped

dnnn (Mon, 17 Dec 2018 14:16:34 GMT):
Hi everyone, I have a question about `plugin`s. In documentation of `indy-plenum` there is a description and also an example of how it is possible to add new transactions and even new ledgers with the help of `plugin`s. If I understand correctly `indy-node` is built using `indy-plenum`. So my question is: does `plugin` mechanism exist in `indy-node` and how it can be used?

dnnn (Mon, 17 Dec 2018 14:16:34 GMT):
Hi everyone, I have a question about `plugin`. I documentation of `indy-plenum` there is a description and also and example of how it is possible to add new transactions and even new ledgers with the help of `plugin`s. If I understand correctly `indy-node` is built using `indy-plenum`. So my question is: does `plugin` mechanism exist in `indy-node` and how it can be used?

dnnn (Mon, 17 Dec 2018 14:16:34 GMT):
Hi everyone, I have a question about `plugin`s. In documentation of `indy-plenum` there is a description and also and example of how it is possible to add new transactions and even new ledgers with the help of `plugin`s. If I understand correctly `indy-node` is built using `indy-plenum`. So my question is: does `plugin` mechanism exist in `indy-node` and how it can be used?

mwherman2000 (Wed, 19 Dec 2018 15:17:08 GMT):
CONTEXT: Early today, @drummondreed clarified that "In the did:sov: method, the DID is written to the Sovrin ledger using a NYM transaction. The properties of the associated DID document are written using ATTRIB transactions.". This makes sense: the Indy/Sovrin Distributed Ledger is sequential ledger of NYM, ATTRIB, and presumably other Tx types.

mwherman2000 (Wed, 19 Dec 2018 15:17:08 GMT):
CONTEXT: Early today, @drummondreed clarified that "In the did:sov: method, the DID is written to the Sovrin ledger using a NYM transaction. The properties of the associated DID document are written using ATTRIB transactions.". This makes sense: the Indy/Sovrin Distributed Ledger is sequential ledger of NYM, ATTRIB, and presumably other Tx types.

mwherman2000 (Wed, 19 Dec 2018 15:17:08 GMT):
CONTEXT: Early today, @drummondreed clarified that "In the did:sov: method, the DID is written to the Sovrin ledger using a NYM transaction. The properties of the associated DID document are written using ATTRIB transactions.". This makes sense: the Indy/Sovrin Distributed Ledger is sequential ledger of NYM, ATTRIB, and presumably other Tx types. @peacekeeper

drummondreed (Wed, 19 Dec 2018 15:17:08 GMT):
Has joined the channel.

mwherman2000 (Wed, 19 Dec 2018 15:21:48 GMT):
QUESTION 1a: Does an Indy/Sovrin Ledger Agent Node at a high level (but not too high a level) operate similar to an Ethereum Node (e.g. geth.exe) in the sense that when a Ledger Node starts up for the first time, it starts reading the Genesis block/Tx and then somehow maintains some sort of local store representing the current of the Ledger?

mwherman2000 (Wed, 19 Dec 2018 15:21:48 GMT):
QUESTION 1a: Does an Indy/Sovrin Ledger Agent Node at a high level (but not too high a level) operate similar to an Ethereum Node (e.g. geth.exe) in the sense that when a Ledger Node starts up for the first time, it starts reading the Genesis block/Tx and then somehow maintains some sort of local store representing the current of the Ledger? @peacekeeper

drummondreed (Wed, 19 Dec 2018 15:22:41 GMT):
Mike, I'm not a deep Sovrin ledger code expert, but yes, what you describe it exactly how I understand it.

mwherman2000 (Wed, 19 Dec 2018 15:25:12 GMT):
QUESTION 1b: If so, what is the representation of the local store? Is it, for example, data structures that look like/virtual the same as a DID Document? ...is it serialized (into JSON-LD format at this point) ...or does the Node use some other representation (that is easily transformed into a JSON-LD DID Document)?

mwherman2000 (Wed, 19 Dec 2018 15:25:12 GMT):
QUESTION 1b: If so, what is the representation of the local store? Is it, for example, data structures that look like/virtual the same as a DID Document? ...is it serialized (into JSON-LD format at this point) ...or does the Node use some other representation (that is easily transformed into a JSON-LD DID Document)? @peacekeeper

drummondreed (Wed, 19 Dec 2018 15:27:06 GMT):
The latter. See this for details: https://github.com/hyperledger/indy-node/blob/master/docs/transactions.md

mwherman2000 (Wed, 19 Dec 2018 15:27:07 GMT):
QUESTION 2: When a DID (id) is passed to a DID Resolver, does the resolver talk to a Ledger Node to retrieve the corresponding DID Document? (see 1b. above) ...or is a DID Resolver expected to run directly against the Indy/Sovrin Ledger?

mwherman2000 (Wed, 19 Dec 2018 15:27:07 GMT):
QUESTION 2: When a DID (id) is passed to a DID Resolver, does the resolver talk to a Ledger Node to retrieve the corresponding DID Document? (see 1b. above) ...or is a DID Resolver expected to access the Indy/Sovrin Ledger directly (instead of talking to a Ledger Agent Node)?

mwherman2000 (Wed, 19 Dec 2018 15:27:07 GMT):
QUESTION 2: When a DID (id) is passed to a DID Resolver, does the resolver talk to a Ledger Node to retrieve the corresponding DID Document? (see 1b. above) ...or is a DID Resolver expected to access the Indy/Sovrin Ledger directly (instead of talking to a Ledger Agent Node)? @peacekeeper

drummondreed (Wed, 19 Dec 2018 15:29:28 GMT):
@peacekeeper is the expert to answer that question in depth, but my high level answer is that the resolver uses the DID to look up the associated transactions on the Sovrin ledger (the NYM transaction to get the public (verification) key and the ATTRIB transactions to get the other DID document properties, and then the resolve dynamically composes the DID document to return.

drummondreed (Wed, 19 Dec 2018 15:30:41 GMT):
To clarify, any client always talks to a Sovrin ledger node to read or write data. So I don't lknow what it would mean for "a DID Resolver to run directly against the Indy/Sovrin Ledger".

mwherman2000 (Wed, 19 Dec 2018 15:34:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=7wzjAncyzTLEfQ56F) @drummondreed I clarified my question. Thank you Drummond. I'm trying to complete this part of the puzzle for the Indy/Sovrin architecture reference model (ARM) as well as provide additional feedback on the draft DID specification #confudsionremoval ;-)

mwherman2000 (Wed, 19 Dec 2018 15:35:50 GMT):
@peacekeeper I'm working to correct/validate the following diagram...

mwherman2000 (Wed, 19 Dec 2018 15:36:02 GMT):

DID Logical Architecture v0.4.png

mwherman2000 (Wed, 19 Dec 2018 15:36:02 GMT):

DID Logical Architecture v0.4.png

mwherman2000 (Wed, 19 Dec 2018 15:36:02 GMT):

DID Logical Architecture v0.4.png

mwherman2000 (Wed, 19 Dec 2018 15:36:02 GMT):

DID Logical Architecture v0.4.png

mwherman2000 (Wed, 19 Dec 2018 15:36:56 GMT):
p.s. Is there a URL for a Ledger Browser for the public Indy/Sovrin distributed ledger?

mwherman2000 (Wed, 19 Dec 2018 16:35:12 GMT):
Found it: http://138.197.138.255/browse/domain?page=1&query=mwherman2002&txn_type=

swcurran (Wed, 19 Dec 2018 16:39:11 GMT):
@mwherman2000 - that is not a browser of the Sovrin Public network - it's a browser for the BCovrin Test Network used by BC and Ontario Gov only. AFAIK, there is no browser for the Sovrin Public Network as yet. We've talked about standing one up using the save code as you are seeing with BCovrin, but have not yet spent the time on that.

mwherman2000 (Wed, 19 Dec 2018 16:43:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=wzGixXSSCXX2LnJ7w) @swcurran Thank you ...I'm going to switch over and use @kdenhartog 's labs. I think I remember seeing BC Gov browser deployed there too.

mwherman2000 (Wed, 19 Dec 2018 16:44:00 GMT):
I want to see the NYM and ATTRIB Txs for an actual DID Document.

jakubkoci (Wed, 19 Dec 2018 19:00:54 GMT):
Has joined the channel.

kdenhartog (Wed, 19 Dec 2018 21:00:08 GMT):
the indy-dev does not, but the education lab (written by @swcurran ) does use it. I'd love to add that functionality to the indy-dev when I can.

swcurran (Wed, 19 Dec 2018 21:55:50 GMT):
I've got to update the education repo to include the latest browser that allows for searching and filter on ledger transactions. Hmm...sounds like a holiday thing...

allisongs (Thu, 20 Dec 2018 03:57:21 GMT):
Has joined the channel.

mwherman2000 (Thu, 20 Dec 2018 20:47:03 GMT):
Updated AIM v0.8...

mwherman2000 (Thu, 20 Dec 2018 20:47:03 GMT):
Updated AIM v0.8... Feedback appreciated ...especially in the technology/infrastructure layer. Thk u

mwherman2000 (Thu, 20 Dec 2018 20:47:03 GMT):
Updated ARM v0.8... Feedback appreciated ...especially in the technology/infrastructure layer. Thk u

mwherman2000 (Thu, 20 Dec 2018 20:47:19 GMT):

DID Logical Architecture v0.8.png

MayukhGhosh (Fri, 21 Dec 2018 09:58:36 GMT):
Has joined the channel.

sanjeevkkn (Wed, 26 Dec 2018 06:20:01 GMT):
Has joined the channel.

aappddeevv (Thu, 27 Dec 2018 21:28:02 GMT):
Has joined the channel.

jleders (Fri, 28 Dec 2018 04:49:13 GMT):
Has joined the channel.

anant706 (Fri, 28 Dec 2018 17:23:32 GMT):
Has joined the channel.

mwherman2000 (Wed, 02 Jan 2019 04:22:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=TMQRZpTpvtwjabpND) The most recent DID ARM can always be found here:

ashokkj (Thu, 03 Jan 2019 02:08:37 GMT):
Has joined the channel.

HiranKumar (Thu, 03 Jan 2019 10:28:39 GMT):
I got an error like "InvalidState("Ledger merkle tree is not acceptable for current tree."))",while trying to connect to the network sandbox.

HiranKumar (Thu, 03 Jan 2019 10:29:00 GMT):
Would you please help me to resolve this issue

HiranKumar (Thu, 03 Jan 2019 10:31:34 GMT):
indy::commands::pool] INFO indy::commands::pool:OpenAck handle 1, pool_id 1, result Err(CommonError(InvalidState("Ledger merkle tree is not acceptable for current tree."))) 2019-01-03T15:52:56.218503800+05:30 [indy::errors::indy] ERROR indy::errors::indy:Casting error to ErrorCode: Invalid library state: Ledger merkle tree is not acceptable for current tree. 2019-01-03T15:52:56.218503800+05:30 [indy::api::pool] TRACE indy::api::pool:indy_open_pool_ledger: pool_handle: 0

smithbk (Thu, 03 Jan 2019 19:47:35 GMT):
Hi, can anyone tell me how to enable trace in indy-node?

smithbk (Thu, 03 Jan 2019 19:58:59 GMT):
I'm using version 1.6.7 of indy-sdk with the following versions of indy-node ```ARG indy_plenum_ver=1.6.520 ARG indy_anoncreds_ver=1.0.32 ARG indy_node_ver=1.6.576 ARG python3_indy_crypto_ver=0.4.3 ARG indy_crypto_ver=0.4.3 ``` I am able to read the ledger but am getting a timeout when doing a send_nym to onboard the first trust anchor. I don't see any output at all in the pool logs and am seeing the following indy-sdk logs in my client app

smithbk (Thu, 03 Jan 2019 20:00:38 GMT):
```TRACE|indy::services::pool::networker| src/services/pool/networker.rs:59 | sending new request TRACE|indy::services::pool::networker| src/services/pool/networker.rs:83 | send request in new conn ... TRACE|indy::services::pool::networker| src/services/pool/networker.rs:319 | _send_msg_to_one_node >> idx 3, req_id 1546537805848403026, req {"identifier":"Th7MpTaRZVRYnPiabds81Y","operation":{"dest":"A1D5wynfUzFTfkwnXnyjm6","role":"101","type":"1","verkey":"5ud35zmjayN65j5t8ipyQpyEydz97uwxU16rvk4ZNHuP"},"protocolVersion":2,"reqId":1546537805848403026,"signature":"NqFps2i5qewhjvz7xqXkhhfUYL4mG82ucp5afQpjLNk3wCgGJaMm4szEYgNJUXo7UZwcyPZf7NNqkzKKzp7SRHc"} 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("{\"identifier\":\"Th7MpTaRZVRYnPiabds81Y\",\"reqId\":1546537805848403026,\"op\":\"REQACK\"}", "Node2")) TRACE|indy::services::pool::pool | src/services/pool/pool.rs:384 | received reply from node "Node2": "{\"identifier\":\"Th7MpTaRZVRYnPiabds81Y\",\"reqId\":1546537805848403026,\"op\":\"REQACK\"}" TRACE|indy::services::pool::pool | src/services/pool/pool.rs:537 | received pool event: Some(NodeReply("{\"reqId\":1546537805848403026,\"identifier\":\"Th7MpTaRZVRYnPiabds81Y\",\"op\":\"REQACK\"}", "Node3")) TRACE|indy::services::pool::pool | src/services/pool/pool.rs:384 | received reply from node "Node3": "{\"reqId\":1546537805848403026,\"identifier\":\"Th7MpTaRZVRYnPiabds81Y\",\"op\":\"REQACK\"}" TRACE|indy::services::pool::pool | src/services/pool/pool.rs:537 | received pool event: Some(NodeReply("{\"reqId\":1546537805848403026,\"identifier\":\"Th7MpTaRZVRYnPiabds81Y\",\"op\":\"REQACK\"}", "Node4")) TRACE|indy::services::pool::pool | src/services/pool/pool.rs:384 | received reply from node "Node4": "{\"reqId\":1546537805848403026,\"identifier\":\"Th7MpTaRZVRYnPiabds81Y\",\"op\":\"REQACK\"}" TRACE|indy::services::pool::pool | src/services/pool/pool.rs:537 | received pool event: Some(NodeReply("{\"op\":\"REQACK\",\"reqId\":1546537805848403026,\"identifier\":\"Th7MpTaRZVRYnPiabds81Y\"}", "Node1")) TRACE|indy::services::pool::pool | src/services/pool/pool.rs:384 | received reply from node "Node1": "{\"op\":\"REQACK\",\"reqId\":1546537805848403026,\"identifier\":\"Th7MpTaRZVRYnPiabds81Y\"}" TRACE|indy::services::pool::pool | src/services/pool/pool.rs:537 | received pool event: Some(Timeout("1546537805848403026", "Node3")) TRACE|indy::services::pool::networker| src/services/pool/networker.rs:248 | is_active >> time worked: Duration { secs: 60, nanos: 112435176 } 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("1546537805848403026", "Node2")) TRACE|indy::services::pool::networker| src/services/pool/networker.rs:248 | is_active >> time worked: Duration { secs: 60, nanos: 113514610 } 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("1546537805848403026", "Node4")) 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 ``` Any ideas on what is causing this or how to debug is appreciated.

PatrikStas (Thu, 03 Jan 2019 22:02:30 GMT):
Why do many transactions have identical value of `txnMetadata.txnId` ? This page https://github.com/hyperledger/indy-node/blob/master/docs/transactions.md says that: ``` txnId (string): Txn ID as State Trie key (address or descriptive data). It must be unique within the ledger. ``` however, for instance at sovrin mainnet, there's literally hunderds of transactions with `txnId` value `UFSFjGNiain5FQ2m88dijd:1:bb485893951ed5093fc370df3671146c7e2380b493206140330f69f4c6af57fe` Am I misunderstanding the description of txnId?

tuckerg (Fri, 04 Jan 2019 06:33:38 GMT):
Has joined the channel.

abdfaye (Mon, 07 Jan 2019 16:12:49 GMT):
Has joined the channel.

abdfaye (Mon, 07 Jan 2019 16:21:35 GMT):
Hello, I have some questions about the Revocation Registry. Is the Indy code using dynamic accumulators or regular ones? When is the accumulator updated after a transaction is issued for a new credential?

swcurran (Mon, 07 Jan 2019 17:57:58 GMT):
@abdfaye - this is the best document on revocation, although your first question likely needs a code review or discussion with the original developers: https://github.com/hyperledger/indy-hipe/tree/master/text/0011-cred-revocation The "nornal" case for Indy for updating the accumulator is only on revocation of one or a set of credentials. That said, I believe that there is an option that can be used where the credentials must be activated on issuance and in that case the accumulator is updated on issuance and revocation. I can't see the purpose for that latter model (lots of overhead), so I'd stick with the former.

HiranKumar (Tue, 08 Jan 2019 10:34:11 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

PatrikStas (Tue, 08 Jan 2019 11:27:50 GMT):
@HiranKumar try to export `RUST_LOG=trace` in the execution environment where you run the application. You should see all indySDK logs and sometimes it helps discovering what exactly is the problem.

HiranKumar (Tue, 08 Jan 2019 11:49:49 GMT):
@PatrikStas ,How can I set this RUST_LOG?

PatrikStas (Tue, 08 Jan 2019 11:55:11 GMT):
I suppose you are executing your application from command line shell, something like bash, right? If so, just run `export RUST_LOG=trace` in command line and then try to run your app

PatrikStas (Tue, 08 Jan 2019 11:55:11 GMT):
@HiranKumar I suppose you are executing your application from command line shell, something like bash, right? If so, just run `export RUST_LOG=trace` in command line and then try to run your app

HiranKumar (Tue, 08 Jan 2019 12:05:48 GMT):
I run the command.and executed the application.But where can I see the indy trace logs?

PatrikStas (Tue, 08 Jan 2019 13:01:49 GMT):
It should be displayed along the logs from your application. If it's not displayed, I am wondering, maybe you need to use debug build of libindy. Not entirely sure though.

PatrikStas (Tue, 08 Jan 2019 13:06:09 GMT):
Do you remember building libidny? Did you run `cargo build --release` ? If so, you can try build its debug version be omitting the `--release` switch. Then you have to make sure your app is using this new build. I think it might help, but beware: `Note: By default cargo build produce debug artifacts with a large amount of run-time checks. It's good for development, but this build can be in 100+ times slower for some math calculation.` (quoting indy-sdk github)

PatrikStas (Tue, 08 Jan 2019 13:08:02 GMT):
I think we should continue in #indy-sdk, this is not the right channel for this

HiranKumar (Tue, 08 Jan 2019 13:55:23 GMT):
Thanks @PatrikStas

PhillipGibb (Tue, 08 Jan 2019 19:43:01 GMT):
token

haniavis (Tue, 08 Jan 2019 20:10:42 GMT):
Hi, I am trying to add a node to an existing pool following this guide https://github.com/hyperledger/indy-node/blob/master/docs/add-node.md. before running the `ledger node` command I need to get the base58 of the new node verification key

haniavis (Tue, 08 Jan 2019 20:11:42 GMT):
but trying this one `python3 -c "from plenum.common.test_network_setup import TestNetworkSetup; print(TestNetworkSetup.getNymFromVerkey(str.encode(‘ab78300b3a3eca0a1679e72dd1656075de9638ae79dc6469a3093ce1cc8b424f’)))"` with my verification key it outputs `binascii.Error: Non-hexadecimal digit found`

haniavis (Tue, 08 Jan 2019 20:11:51 GMT):
any help?

mgbailey (Tue, 08 Jan 2019 22:18:35 GMT):
@haniavis , this worked fine for me: python3 -c "from plenum.common.test_network_setup import TestNetworkSetup; print(TestNetworkSetup.getNymFromVerkey(str.encode('ab78300b3a3eca0a1679e72dd1656075de9638ae79dc6469a3093ce1cc8b424f')))" CYM1dgJMTcrk27xs3fRzwjUDBviMnKapuwYuRnWai7jU

mgbailey (Tue, 08 Jan 2019 22:21:51 GMT):
This was run on a node with indy-node 1.6.80 on it

haniavis (Tue, 08 Jan 2019 22:26:00 GMT):
@mgbailey I am running indy-node 1.6.82, but this doesn't work

haniavis (Tue, 08 Jan 2019 22:27:02 GMT):
I mean with my own verification key not with the one used in the example

mgbailey (Tue, 08 Jan 2019 22:35:47 GMT):
Ah, I think I know the issue. In 1.6.82 I believe that the output of init_indy node has been fixed so that it puts out base58 instead of hex. This step is now unnecessary.

mgbailey (Tue, 08 Jan 2019 22:35:47 GMT):
Ah, I think I know the issue. In 1.6.82 I believe that the output of init_indy_node has been fixed so that it puts out base58 instead of hex. This step is now unnecessary.

haniavis (Tue, 08 Jan 2019 22:36:03 GMT):
I just realized that the output of the init_indy_node in indy-node 1.6.82 is different than previous versions

haniavis (Tue, 08 Jan 2019 22:37:20 GMT):
ok so I am ready to go with the `ledger node ` command in the cli

haniavis (Tue, 08 Jan 2019 22:42:06 GMT):
now working in indy-cli... it says that there is no opened pool so I connect to the pool and execute the command, but it says that "There is no opened wallet now" and when I try to open the wallet I need a key.....which one is this key?

mgbailey (Tue, 08 Jan 2019 22:44:26 GMT):
This is a new cli. There is good online help in it. Just type help. Then drill in and type a command or subcommand, then help.

mgbailey (Tue, 08 Jan 2019 22:44:43 GMT):
First connect to a pool. "pool connect"

mgbailey (Tue, 08 Jan 2019 22:45:05 GMT):
Actually first create it "pool create"

mgbailey (Tue, 08 Jan 2019 22:45:10 GMT):
then connect to it

mgbailey (Tue, 08 Jan 2019 22:45:26 GMT):
Next create a wallet "wallet create"

mgbailey (Tue, 08 Jan 2019 22:45:35 GMT):
then "wallet open"

mgbailey (Tue, 08 Jan 2019 22:45:59 GMT):
Then put your keys into the wallet "did new seed=xxx"

mgbailey (Tue, 08 Jan 2019 22:46:27 GMT):
Then you can add a new steward "ledger nym"

mgbailey (Tue, 08 Jan 2019 22:46:58 GMT):
and then change to the steward did "did use"

mgbailey (Tue, 08 Jan 2019 22:47:16 GMT):
and finally add the node information to the ledger "ledger node"

mgbailey (Tue, 08 Jan 2019 22:48:31 GMT):
the wallet key is something you make up in wallet create.

mgbailey (Tue, 08 Jan 2019 22:50:17 GMT):
Feel free to edit add-node.md as you go through this, to make the path smoother for those who follow :)

haniavis (Tue, 08 Jan 2019 22:50:26 GMT):
ok this was what I thought, but I found an existing pool and an existing wallet which I hadn't created before, I suppose they are made through the generate_indy_pool_transactions script?

mgbailey (Tue, 08 Jan 2019 22:51:09 GMT):
maybe. It has been forever since I have been through those steps myself

haniavis (Tue, 08 Jan 2019 22:51:46 GMT):
ok anyway I will try the proper way you mention. Thanks a lot for your help

mgbailey (Tue, 08 Jan 2019 22:51:54 GMT):
yw

haniavis (Tue, 08 Jan 2019 22:56:00 GMT):
for editing the add-node.md file should I edit it directly or should I use another way like a PR?

haniavis (Tue, 08 Jan 2019 22:56:00 GMT):
@mgbailey for editing the add-node.md file should I edit it directly or should I use another way like a PR?

mgbailey (Tue, 08 Jan 2019 23:12:31 GMT):
A PR

firewater (Wed, 09 Jan 2019 07:04:29 GMT):
Has joined the channel.

firewater (Wed, 09 Jan 2019 09:30:54 GMT):
i have setup the indy-node with `./pool_start.sh' command from https://github.com/hyperledger/indy-node/blob/master/environment/docker/pool/README.md. What should i do next??

firewater (Wed, 09 Jan 2019 09:30:54 GMT):
i have setup the indy-node with `./pool_start.sh` command from https://github.com/hyperledger/indy-node/blob/master/environment/docker/pool/README.md. What should i do next??

firewater (Wed, 09 Jan 2019 09:32:07 GMT):
eg how can i expose the node to public?

firewater (Wed, 09 Jan 2019 09:32:18 GMT):
and how to continue setup agent and client

DmitriPlakhov (Thu, 10 Jan 2019 12:00:53 GMT):
Has joined the channel.

smithbk (Fri, 11 Jan 2019 18:43:30 GMT):
Does indy-node support dynamically changing the log level, without restarting the node process?

ashcherbakov (Mon, 14 Jan 2019 09:54:59 GMT):
@smithbk Unfortunately no, you have to restart the service,

vsadriano (Thu, 17 Jan 2019 11:20:50 GMT):
Has joined the channel.

vsadriano (Thu, 17 Jan 2019 18:22:43 GMT):
Hi! I'm trying to set a new indy nodes pool and I'm getting the error bellow: ```shell OSError: [Errno 22] Invalid argument: '/etc/indy/indy_config.py' -> '/etc/indy/indy_config.py.bak' ``` Hi! I'm trying to set a new node pool and I'm getting the error bellow: ```shell generate_indy_pool_transactions --nodes 4 --clients 0 --nodeNum 1 --ips 173.17.0.101,173.17.0.102,173.17.0.103,173.17.0.104 Traceback (most recent call last): File "/home/indy/.pyenv/versions/3.5.5/bin/generate_indy_pool_transactions", line 19, in getTxnOrderedFields(), ConfigHelper, NodeConfigHelper) File "/home/indy/.pyenv/versions/3.5.5/lib/python3.5/site-packages/plenum/common/test_network_setup.py", line 248, in bootstrapTestNodes for line in fileinput.input(['/etc/indy/indy_config.py'], inplace=True): File "/home/indy/.pyenv/versions/3.5.5/lib/python3.5/fileinput.py", line 248, in __next__ line = self._readline() File "/home/indy/.pyenv/versions/3.5.5/lib/python3.5/fileinput.py", line 335, in _readline os.rename(self._filename, self._backupfilename) OSError: [Errno 22] Invalid argument: '/etc/indy/indy_config.py' -> '/etc/indy/indy_config.py.bak' ``` Any idea what's going on?

vsadriano (Thu, 17 Jan 2019 18:22:43 GMT):
Hi! I'm trying to set a new node pool and I'm getting the error bellow: ```shell generate_indy_pool_transactions --nodes 4 --clients 0 --nodeNum 1 --ips 173.17.0.101,173.17.0.102,173.17.0.103,173.17.0.104 Traceback (most recent call last): File "/home/indy/.pyenv/versions/3.5.5/bin/generate_indy_pool_transactions", line 19, in getTxnOrderedFields(), ConfigHelper, NodeConfigHelper) File "/home/indy/.pyenv/versions/3.5.5/lib/python3.5/site-packages/plenum/common/test_network_setup.py", line 248, in bootstrapTestNodes for line in fileinput.input(['/etc/indy/indy_config.py'], inplace=True): File "/home/indy/.pyenv/versions/3.5.5/lib/python3.5/fileinput.py", line 248, in __next__ line = self._readline() File "/home/indy/.pyenv/versions/3.5.5/lib/python3.5/fileinput.py", line 335, in _readline os.rename(self._filename, self._backupfilename) OSError: [Errno 22] Invalid argument: '/etc/indy/indy_config.py' -> '/etc/indy/indy_config.py.bak' ``` Any idea what's going on?

Yair (Fri, 18 Jan 2019 11:00:51 GMT):
Has joined the channel.

smithbk (Fri, 18 Jan 2019 11:21:21 GMT):
Hi, my test ledger runs 4 nodes in a single container. Nodes 1 - 3 start find and I can see them listening on their ports, but the 4th never starts. It appears to be in an infinite loop with the following trace repeating ```2019-01-18 11:01:14,062|DEBUG|node_runner.py|You can find logs in /var/log/indy/sandbox/Node4.log 2019-01-18 11:01:14,062|DEBUG|node_runner.py|Indy related env vars: [] 2019-01-18 11:01:14,062|DEBUG|selector_events.py|Using selector: EpollSelector 2019-01-18 11:01:14,063|INFO|looper.py|Starting up indy-node 2019-01-18 11:01:14,063|DEBUG|looper.py|Setting handler for SIGINT 2019-01-18 11:01:14,063|DEBUG|looper.py|Setting handler for SIGTERM 2019-01-18 11:01:33,171|INFO|ledger.py|Starting ledger... 2019-01-18 11:01:42,073|INFO|ledger.py|Recovering tree from transaction log 2019-01-18 11:02:11,144|INFO|ledger.py|Recovered tree in 29.070786982774734 seconds 2019-01-18 11:02:29,946|DEBUG|idr_cache.py|Initializing identity cache Node4 2019-01-18 11:02:29,946|INFO|node.py|Node4 found state to be empty, recreating from ledger 2019-01-18 11:02:29,950|INFO|node.py|Node4 initialized pool state: state root 6xUDowdhHe2pMeqwPj3wM6cQfHj2JYzMdztvTDsa4TS1 2019-01-18 11:02:29,950|INFO|pool_manager.py|Node4 sets node Node1 (Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv) order to 5 2019-01-18 11:02:29,950|INFO|pool_manager.py|Node4 sets node Node2 (8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb) order to 5 2019-01-18 11:02:29,950|INFO|pool_manager.py|Node4 sets node Node3 (DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya) order to 5 2019-01-18 11:02:29,951|INFO|pool_manager.py|Node4 sets node Node4 (4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA) order to 5 2019-01-18 11:02:52,174|NOTIFICATION|looper.py|Looper shutting down now... 2019-01-18 11:02:52,184|NOTIFICATION|looper.py|Looper shut down in 0.010 seconds. 2019-01-18 11:02:52,184|DEBUG|looper.py|Unsetting handler for SIGINT 2019-01-18 11:02:52,184|DEBUG|looper.py|Unsetting handler for SIGTERM```

smithbk (Fri, 18 Jan 2019 11:21:21 GMT):
Hi, my test ledger runs 4 nodes in a single container. Nodes 1 - 3 start fine and I can see them listening on their ports, but the 4th never starts. It appears to be in an infinite loop with the following trace repeating ```2019-01-18 11:01:14,062|DEBUG|node_runner.py|You can find logs in /var/log/indy/sandbox/Node4.log 2019-01-18 11:01:14,062|DEBUG|node_runner.py|Indy related env vars: [] 2019-01-18 11:01:14,062|DEBUG|selector_events.py|Using selector: EpollSelector 2019-01-18 11:01:14,063|INFO|looper.py|Starting up indy-node 2019-01-18 11:01:14,063|DEBUG|looper.py|Setting handler for SIGINT 2019-01-18 11:01:14,063|DEBUG|looper.py|Setting handler for SIGTERM 2019-01-18 11:01:33,171|INFO|ledger.py|Starting ledger... 2019-01-18 11:01:42,073|INFO|ledger.py|Recovering tree from transaction log 2019-01-18 11:02:11,144|INFO|ledger.py|Recovered tree in 29.070786982774734 seconds 2019-01-18 11:02:29,946|DEBUG|idr_cache.py|Initializing identity cache Node4 2019-01-18 11:02:29,946|INFO|node.py|Node4 found state to be empty, recreating from ledger 2019-01-18 11:02:29,950|INFO|node.py|Node4 initialized pool state: state root 6xUDowdhHe2pMeqwPj3wM6cQfHj2JYzMdztvTDsa4TS1 2019-01-18 11:02:29,950|INFO|pool_manager.py|Node4 sets node Node1 (Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv) order to 5 2019-01-18 11:02:29,950|INFO|pool_manager.py|Node4 sets node Node2 (8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb) order to 5 2019-01-18 11:02:29,950|INFO|pool_manager.py|Node4 sets node Node3 (DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya) order to 5 2019-01-18 11:02:29,951|INFO|pool_manager.py|Node4 sets node Node4 (4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA) order to 5 2019-01-18 11:02:52,174|NOTIFICATION|looper.py|Looper shutting down now... 2019-01-18 11:02:52,184|NOTIFICATION|looper.py|Looper shut down in 0.010 seconds. 2019-01-18 11:02:52,184|DEBUG|looper.py|Unsetting handler for SIGINT 2019-01-18 11:02:52,184|DEBUG|looper.py|Unsetting handler for SIGTERM```

smithbk (Fri, 18 Jan 2019 11:21:21 GMT):
Hi, my test ledger runs 4 nodes in a single container. Nodes 1 - 3 start fine and I can see them listening on their ports, but the 4th never starts listening on ports. It appears to be in an infinite loop with the following trace repeating ```2019-01-18 11:01:14,062|DEBUG|node_runner.py|You can find logs in /var/log/indy/sandbox/Node4.log 2019-01-18 11:01:14,062|DEBUG|node_runner.py|Indy related env vars: [] 2019-01-18 11:01:14,062|DEBUG|selector_events.py|Using selector: EpollSelector 2019-01-18 11:01:14,063|INFO|looper.py|Starting up indy-node 2019-01-18 11:01:14,063|DEBUG|looper.py|Setting handler for SIGINT 2019-01-18 11:01:14,063|DEBUG|looper.py|Setting handler for SIGTERM 2019-01-18 11:01:33,171|INFO|ledger.py|Starting ledger... 2019-01-18 11:01:42,073|INFO|ledger.py|Recovering tree from transaction log 2019-01-18 11:02:11,144|INFO|ledger.py|Recovered tree in 29.070786982774734 seconds 2019-01-18 11:02:29,946|DEBUG|idr_cache.py|Initializing identity cache Node4 2019-01-18 11:02:29,946|INFO|node.py|Node4 found state to be empty, recreating from ledger 2019-01-18 11:02:29,950|INFO|node.py|Node4 initialized pool state: state root 6xUDowdhHe2pMeqwPj3wM6cQfHj2JYzMdztvTDsa4TS1 2019-01-18 11:02:29,950|INFO|pool_manager.py|Node4 sets node Node1 (Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv) order to 5 2019-01-18 11:02:29,950|INFO|pool_manager.py|Node4 sets node Node2 (8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb) order to 5 2019-01-18 11:02:29,950|INFO|pool_manager.py|Node4 sets node Node3 (DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya) order to 5 2019-01-18 11:02:29,951|INFO|pool_manager.py|Node4 sets node Node4 (4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA) order to 5 2019-01-18 11:02:52,174|NOTIFICATION|looper.py|Looper shutting down now... 2019-01-18 11:02:52,184|NOTIFICATION|looper.py|Looper shut down in 0.010 seconds. 2019-01-18 11:02:52,184|DEBUG|looper.py|Unsetting handler for SIGINT 2019-01-18 11:02:52,184|DEBUG|looper.py|Unsetting handler for SIGTERM```

smithbk (Fri, 18 Jan 2019 11:21:53 GMT):
Any ideas what would cause this?

mgbailey (Mon, 21 Jan 2019 15:01:40 GMT):
@smithbk On a VM i would check "sudo journalctl -u indy-node" to find the problem. You will need to look in your supervisord equivalent.

nemesisinhell (Wed, 23 Jan 2019 12:25:16 GMT):
Has joined the channel.

nemesisinhell (Wed, 23 Jan 2019 12:27:17 GMT):
format

nemesisinhell (Wed, 23 Jan 2019 12:30:21 GMT):
Hi fellas, 1) in hyperledger indy, does the owner of the node role is steward ? 2) in hyperledger indy, in order to establish connection end user with trust anchor, does trust anchor had to host a api server to process the connection request ? 3) in hyperledger indy, what type of format or source can trust anchor provide in order to let end user get it's data such as DID , verkey for establish connection ?

nemesisinhell (Wed, 23 Jan 2019 12:31:56 GMT):
Question: we are thinking of scanning qr code of cloud agent from client app to establish connection with them. What info does the qr code in cloud ageny should provide and is there a standard format of how it should have?

drummondreed (Wed, 23 Jan 2019 13:20:19 GMT):
Since you cross-posted, see the answers I posted in the #indy-agent channel.

nehalshah50 (Wed, 23 Jan 2019 18:10:33 GMT):
Has joined the channel.

misaelssantos (Wed, 23 Jan 2019 21:01:15 GMT):
Has joined the channel.

misaelssantos (Wed, 23 Jan 2019 21:05:20 GMT):
Hello, Where is the magic behind the Steward? Why his DID in the demos is always Th7MpTaRZVRYnPiabds81Y? What prevents any agent turn itself a TRUST_ANCHOR?

misaelssantos (Wed, 23 Jan 2019 21:07:18 GMT):
How Is this set in the node pool?

swcurran (Wed, 23 Jan 2019 21:52:28 GMT):
@misaelssantos - the DID in the demos are always the same so that the demos can proceed - the demo startup can create the necessary Trust Anchors, etc.. That Steward is only on local/toy sandboxes - those all use the same genesis file. On the real Sovrin networks, those are not the DIDs of the Stewards. DIDs with the Trust Anchor role are created (currently) manually by a Sovrin Trustee upon request and only after due diligence of the person/organization asking. That DID is created because the SEED for it is well-known and it matches what is in the genesis file that is used for sandbox networks.

adamgering (Thu, 24 Jan 2019 03:04:14 GMT):
Has joined the channel.

mwherman2000 (Thu, 24 Jan 2019 14:59:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=PCoSYZF3waj98Nu5n) @nemesisinhell @nemesisinhell @drummondreed I've interested in these answers as well but I haven't been able to find them in #indy-agent. Can you repost them here? ...or a link of some sort if that's possible. Thank you

mwherman2000 (Thu, 24 Jan 2019 14:59:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=PCoSYZF3waj98Nu5n) @nemesisinhell @nemesisinhell @drummondreed I've interested in these answers as well but I haven't been able to find them in #indy-agent . Can you repost them here? ...or a link of some sort if that's possible. Thank you [postscript: The answers can be found below as well as in the #indy channel]

mwherman2000 (Thu, 24 Jan 2019 14:59:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=PCoSYZF3waj98Nu5n) @nemesisinhell @nemesisinhell @drummondreed I've interested in these answers as well but I haven't been able to find them in #indy-agent . Can you repost them here? ...or a link of some sort if that's possible. Thank you [postscript: The answers can be found below as well as in the #indy channel]

mgbailey (Thu, 24 Jan 2019 15:06:27 GMT):
@mwherman2000 https://chat.hyperledger.org/channel/indy?msg=xLjK2pk6sdXxaEGZD

mwherman2000 (Fri, 25 Jan 2019 00:26:13 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=7wzjAncyzTLEfQ56F) @drummondreed In the Universal Resolver architecture, there is (was) this concept of a Resolver Lightweight Node/Driver (that talks to a Ledger Node) as well as Resolver Full Node/Driver (that maintains its own Local Ledger State). In the case of the DID Resolver, specifically, it only supports the Lightweight Node/Driver model. Checkout elements (35) through (42) in the INDY ARM: https://hyperonomy.com/2019/01/13/hyperledger-indy-sovrin-comprehensive-architecture-reference-model-arm/

mwherman2000 (Fri, 25 Jan 2019 00:31:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=S9Xr7t8ro2B2eLvc7) @drummondreed You are correct Drummond, checkout @peacekeeper 's webcast here: timecode https://youtu.be/gf2g4O3yqCc?t=400 ...as well as elements (16), (17), (41), and (42) - with a dash of (35) thru (38) - in the current version of the INDY ARM: https://hyperonomy.com/2019/01/13/hyperledger-indy-sovrin-comprehensive-architecture-reference-model-arm/ ...thank you

GEEKTEDDY (Fri, 25 Jan 2019 02:23:54 GMT):
Has joined the channel.

MikeRichardson (Fri, 25 Jan 2019 22:19:01 GMT):
Has joined the channel.

peter.danko (Mon, 28 Jan 2019 11:48:23 GMT):
Has joined the channel.

coderintherye (Mon, 28 Jan 2019 23:11:41 GMT):
Has joined the channel.

coderintherye (Mon, 28 Jan 2019 23:14:01 GMT):
Has anyone else experienced that when following the README at environment/docker/pool/README.md # Start client ./client_for_pool_start.sh [file with pool data] [client's IP address] [number of clients] that this results in OCI runtime exec failed: exec failed: container_linux.go:348: starting container process caused "exec: \"indy\": executable file not found in $PATH": unknown

coderintherye (Mon, 28 Jan 2019 23:14:49 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=enbEfrFtGfQ6nGr3q) the problem itself there being that the command it arrives at: docker exec -it indyclient indy fails because indy isn't found / executable on the environment

coderintherye (Mon, 28 Jan 2019 23:15:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=enbEfrFtGfQ6nGr3q) I searched around for a bug ticket for it in Jira but didn't see one

mwherman2000 (Tue, 29 Jan 2019 04:29:52 GMT):
Is there a script/console app that will loop through each of the transactions in the Ledger and dump each of them to the console? ...link?

swcurran (Tue, 29 Jan 2019 05:14:44 GMT):
The von-network site has that. Puts the transactions in a database to support the ledger browser. https://github.com/bcgov/von-network

swcurran (Tue, 29 Jan 2019 05:16:23 GMT):
Code for it is here: https://github.com/bcgov/von-network/blob/master/server/anchor.py

stefan.vogl (Tue, 29 Jan 2019 10:39:32 GMT):
Has joined the channel.

mwherman2000 (Tue, 29 Jan 2019 15:03:36 GMT):
Thk you @swcurran I think I can adapt this.

swcurran (Tue, 29 Jan 2019 15:53:26 GMT):
Coding/concept is by Andrew Whitehead of BC Gov team. It's pretty cool!

mwherman2000 (Tue, 29 Jan 2019 16:49:06 GMT):
@swcurran The context is: As a learning tool, I'm updating the `getting_started.py` script from the SDK (aka _Alice buys a Big Red Car (aka Lambourgini)_) to be highly correlateable with the other Getting Started documentation ...including display of all of the DIDs, JSON artifacts, etc. I'll extract what I need from `anchor.py` to be able to incrementally dump out what's actually written to the Ledger. - Numbered output example:

mwherman2000 (Tue, 29 Jan 2019 16:49:06 GMT):
@swcurran The context is: As a learning tool, I'm updating the `getting_started.py` script from the SDK (aka _Alice buys a Big Red Car (aka Lambourgini)_) to be highly correlateable with the other Getting Started documentation ...including display of all of the DIDs, JSON artifacts, etc. I'll extract what I need from `anchor.py` to be able to incrementally dump out what's actually written to the Ledger. - Numbered output example: https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-numbered.log - Verbose output example: https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-verbose.log

mwherman2000 (Tue, 29 Jan 2019 16:49:06 GMT):
@swcurran The context is: As a learning tool, I'm updating the `getting_started.py` script from the SDK (aka _Alice buys a Big Red Car (aka Lambourgini)_ scenario) to be highly correlateable with the other Getting Started documentation ...including display of all of the DIDs, JSON artifacts, etc. I'll extract what I need from `anchor.py` to be able to incrementally dump out what's actually written to the Ledger. - Numbered output example: https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-numbered.log - Verbose output example: https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-verbose.log

mwherman2000 (Tue, 29 Jan 2019 16:49:06 GMT):
@swcurran The context is: As a learning tool, I'm updating the `getting_started.py` script from the SDK (aka _Alice buys a Big Red Car (aka Lambourgini)_ scenario) to be highly correlateable with the other Getting Started documentation ...including display of all of the DIDs, JSON artifacts, etc. I'll extract what I need from `anchor.py` to be able to incrementally dump out what's actually written to the Ledger. - Numbered output example: https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-numbered.log - Verbose output example: https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-verbose.log

mwherman2000 (Tue, 29 Jan 2019 16:49:06 GMT):
@swcurran FYI: The context is: As a learning tool, I'm updating the `getting_started.py` script from the SDK (aka _Alice buys a Big Red Car (aka Lambourgini)_ scenario) to be highly correlateable with the other Getting Started documentation ...including display of all of the DIDs, JSON artifacts, etc. I'll extract what I need from `anchor.py` to be able to incrementally dump out what's actually written to the Ledger. - Numbered output example: https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-numbered.log - Verbose output example: https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-verbose.log

haniavis (Tue, 29 Jan 2019 17:56:13 GMT):
Hi, I am working on a private pool installation and I am using the scirpt `generate_indy_pool_transactions` to create the pool_transactions_genesis and domain_transactions_genesis files. After that, I see in the domain ledger a TRUSTEE is created and 2 STEWARDS. How can I manually replicate the `generate_indy_pool_transactions` script functionality and create TRUSTEEs, so that I can add STEWARDS on the ledger?

haniavis (Tue, 29 Jan 2019 20:17:31 GMT):
What I am trying to do is to add another node in the pool, so I need to have another STEWARD did, so I need to have the did of the TRUSTEE of the pool to add another STEWARD, am I thinking right?

firewater (Wed, 30 Jan 2019 05:08:46 GMT):
how could it possible to setup distributed node on different vps? and how can i change the default seed value?

firewater (Wed, 30 Jan 2019 05:10:43 GMT):
i am setting up the node with von network

Sandeep (Wed, 30 Jan 2019 18:04:54 GMT):
Has joined the channel.

alainN (Wed, 30 Jan 2019 18:31:36 GMT):
Has joined the channel.

alainN (Wed, 30 Jan 2019 18:31:43 GMT):
boto3

haniavis (Wed, 30 Jan 2019 19:56:17 GMT):
Hi, I managed to add a new node (Node3) in my initial pool (Node1 + Node2) . I see Node3 in the ledger of Node1 and Node2 but there is this warning in their log: WARNING|kit_zstack.py|CONNECTION: Node1 cannot connect to Node3 due to Node1 could not get Node3's public key from disk. Make sure the keys are initialized for this remote or provided explicitly.

haniavis (Wed, 30 Jan 2019 19:56:22 GMT):
any idea?

xaviervila (Thu, 31 Jan 2019 17:33:38 GMT):
Has joined the channel.

vo2vo (Fri, 01 Feb 2019 04:40:19 GMT):
Has joined the channel.

DavidP (Fri, 01 Feb 2019 14:53:58 GMT):
Has joined the channel.

HLFPOC (Mon, 04 Feb 2019 10:26:45 GMT):
Has joined the channel.

ashcherbakov (Mon, 04 Feb 2019 10:56:48 GMT):
@haniavis The minimum number of nodes in the pool is 4. I suggest not trying to add nodes manually, but use Docker for easy start-up: https://github.com/hyperledger/indy-node/blob/master/environment/docker/pool/README.md If you still want to initialize a pool manually, please have a look at https://github.com/hyperledger/indy-node/blob/master/docs/source/start-nodes.md

mondraymond (Mon, 04 Feb 2019 12:19:10 GMT):
Has joined the channel.

haniavis (Mon, 04 Feb 2019 15:36:40 GMT):
@ashcherbakov Thanks for your reply. I am using a pool with 2 nodes, and I managed to add a 3rd one. The error I mentioned above is because I used in the node request, the DID of the new node instead of the verkey of the new node. Now everything works fine.

haniavis (Mon, 04 Feb 2019 15:36:56 GMT):
What do you mean the minimum number of nodes in the pool is 4? Maybe using Docker?

ashcherbakov (Mon, 04 Feb 2019 16:09:00 GMT):
The number of nodes in the pool should be 3f+1 where f is the maximum number of failure or malicious nodes. So, if we have a pool of 4 nodes, then 1 node can be failure/malicious. If we have a pool of 7 nodes, then 2 nodes can be failure/malicious.

ashcherbakov (Mon, 04 Feb 2019 16:09:18 GMT):
So, it doesn't make sense to have less than 4 nodes, since f=0 in this case

haniavis (Mon, 04 Feb 2019 17:30:46 GMT):
So it is not that with less than 4 nodes the pool will not be able to operate, but with less than 4 nodes the consensus algorithm will not be able to detect a malicious node, right?

harmitfans (Mon, 04 Feb 2019 18:43:23 GMT):
Has joined the channel.

ashcherbakov (Tue, 05 Feb 2019 08:44:01 GMT):
yes

hamidm (Tue, 05 Feb 2019 11:40:48 GMT):
Has joined the channel.

hamidm (Tue, 05 Feb 2019 11:43:08 GMT):
Hello, when I try to create a pool using the genesis file that is in the CLI folder, I'm unable to open a pool. when I use the one provided with the Sandbox in the docker folder, I'am able to open a pool. What is the DID of the steward to use to be able to create Anchors ? Thanks

ElSqueakador (Wed, 06 Feb 2019 01:44:40 GMT):
Has joined the channel.

nanspro (Wed, 06 Feb 2019 15:28:53 GMT):
Has joined the channel.

sklump (Wed, 06 Feb 2019 15:49:30 GMT):
Has joined the channel.

sklump (Wed, 06 Feb 2019 15:51:49 GMT):
I notice that, acting as the Steward, I cannot change the role of a user anymore - I get ``` (1012) Ledger rejected transaction request: client request invalid: UnauthorizedClientRequest('actor must be owner',) ``` As the trustee I should be able to set roles, no? This messes up part of my world.

sklump (Wed, 06 Feb 2019 15:51:49 GMT):
I notice that, acting as the Steward, I cannot change the role in a user's cryptonym on the ledger anymore - I get ``` (1012) Ledger rejected transaction request: client request invalid: UnauthorizedClientRequest('actor must be owner',) ``` As the trustee I should be able to set roles, no? This messes up part of my world.

sklump (Wed, 06 Feb 2019 15:51:49 GMT):
I notice that, acting as the Steward, I cannot change the role in a user's cryptonym on the ledger anymore - I get ``` (1012) Ledger rejected transaction request: client request invalid: UnauthorizedClientRequest('actor must be owner',) ``` As the trustee I should be able to set roles, no? This messes up part of my world. It seems to be new circa indy-sdk 1.8.0

sklump (Wed, 06 Feb 2019 15:51:49 GMT):
I notice that, acting as the Steward, I cannot change the role in a user's cryptonym from `TRUST_ANCHOR` to `` on the ledger anymore - I get ``` (1012) Ledger rejected transaction request: client request invalid: UnauthorizedClientRequest('actor must be owner',) ``` As the trustee I should be able to set roles, no? This messes up part of my world. It seems to be new circa indy-sdk 1.8.0

sklump (Wed, 06 Feb 2019 15:51:49 GMT):
I notice that, acting as the trustee, I cannot change the role in a user's cryptonym from `TRUST_ANCHOR` to `` on the ledger anymore - I get ``` (1012) Ledger rejected transaction request: client request invalid: UnauthorizedClientRequest('actor must be owner',) ``` As the trustee I should be able to set roles, no? This messes up part of my world. It seems to be new circa indy-sdk 1.8.0

sklump (Wed, 06 Feb 2019 16:08:47 GMT):
Judging from https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md, this may be a bug.

sklump (Wed, 06 Feb 2019 16:08:47 GMT):
Judging from https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md, this may be a bug. I'll rebuild from old `indy-sdk/ci/indy-pool.dockerfile` and see if I can get back the old behaviour, or whether something deeper and more confusing is going on.

sklump (Wed, 06 Feb 2019 16:23:27 GMT):
... yep, it's a bug. I'll submit a JIRA.

ArnabChatterjee (Wed, 06 Feb 2019 18:31:09 GMT):
Has joined the channel.

ThiagoFontes (Wed, 06 Feb 2019 23:49:48 GMT):
Has joined the channel.

kdenhartog (Wed, 06 Feb 2019 23:53:22 GMT):
@sklump probably popped up from the changes to error handling that they did

ashcherbakov (Thu, 07 Feb 2019 07:50:40 GMT):
@sklump There was a bug https://jira.hyperledger.org/browse/INDY-1971 that is fixed now. The latest master version should be fine

sklump (Thu, 07 Feb 2019 11:35:31 GMT):
Nope, still broken

ozheregelya (Thu, 07 Feb 2019 12:03:03 GMT):
Could you please check which indy-node version do you use? This case was re-tested on indy-node=1.6.785 (master) and works fine: ``` pool(p):wallet(w):did(V4S...e6f):indy> did new Did "A7mVC7EBAE4LDGWrCYvis4" has been created with "~AZxDvU5FBdgWCfKZKN3W88" verkey pool(p):wallet(w):did(V4S...e6f):indy> ledger nym did=A7mVC7EBAE4LDGWrCYvis4 verkey=~AZxDvU5FBdgWCfKZKN3W88 role=TRUST_ANCHOR Nym request has been sent to Ledger. Metadata: +------------------------+-----------------+---------------------+---------------------+ | From | Sequence Number | Request ID | Transaction time | +------------------------+-----------------+---------------------+---------------------+ | V4SGRU86Z58d6TV7PBUe6f | 22 | 1549397197897530276 | 2019-02-05 20:06:38 | +------------------------+-----------------+---------------------+---------------------+ Data: +------------------------+-------------------------+--------------+ | Did | Verkey | Role | +------------------------+-------------------------+--------------+ | A7mVC7EBAE4LDGWrCYvis4 | ~AZxDvU5FBdgWCfKZKN3W88 | TRUST_ANCHOR | +------------------------+-------------------------+--------------+ pool(p):wallet(w):did(V4S...e6f):indy> ledger nym did=A7mVC7EBAE4LDGWrCYvis4 role= Nym request has been sent to Ledger. Metadata: +------------------------+-----------------+---------------------+---------------------+ | From | Sequence Number | Request ID | Transaction time | +------------------------+-----------------+---------------------+---------------------+ | V4SGRU86Z58d6TV7PBUe6f | 23 | 1549397213744523609 | 2019-02-05 20:06:53 | +------------------------+-----------------+---------------------+---------------------+ Data: +------------------------+------+ | Did | Role | +------------------------+------+ | A7mVC7EBAE4LDGWrCYvis4 | - | +------------------------+------+ pool(p):wallet(w):did(V4S...e6f):indy> did use A7mVC7EBAE4LDGWrCYvis4 Did "A7mVC7EBAE4LDGWrCYvis4" has been set as active pool(p):wallet(w):did(A7m...is4):indy> ledger nym did=17mVC7EBAE4LDGWrCYvi11 Transaction has been rejected: Rule for this action is: 1 TRUSTEE signature is required OR 1 STEWARD signature is required OR 1 TRUST_ANCHOR signature is required ```

sklump (Thu, 07 Feb 2019 13:07:28 GMT):
Oh! The ci/indy-pool.dockerfile in indy-sdk master needs a lift then: ``` ARG indy_plenum_ver=1.6.662 ARG indy_anoncreds_ver=1.0.32 ARG indy_node_ver=1.6.772 ARG python3_indy_crypto_ver=0.4.5 ARG indy_crypto_ver=0.4.5 ``` Do I need to bump plenum to match the node version? If so, what should work?

smithbk (Thu, 07 Feb 2019 13:17:59 GMT):
Hi anyone, are there any performance numbers available for various ledger operations?

ozheregelya (Thu, 07 Feb 2019 13:28:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=ZrQcDNsry6qSBHfft) @sklump Try to change node and plenum versions to: `indy_plenum_ver=1.6.672` and `indy_node_ver=1.6.785`.

sklump (Thu, 07 Feb 2019 14:00:33 GMT):
Interesting - new behaviour about who can touch the verification key. I think it's fine, but I need half an hour or so to work around it.

MALodder (Thu, 07 Feb 2019 18:17:56 GMT):
Has left the channel.

sklump (Fri, 08 Feb 2019 11:31:31 GMT):
Has left the channel.

kulkarnikk (Mon, 11 Feb 2019 16:19:25 GMT):
Has joined the channel.

rekmarks (Mon, 11 Feb 2019 23:21:07 GMT):
Has joined the channel.

zoltan.lux (Wed, 13 Feb 2019 12:36:38 GMT):
Has joined the channel.

jenklogic (Wed, 13 Feb 2019 18:38:11 GMT):
Has joined the channel.

danacr (Thu, 14 Feb 2019 15:48:49 GMT):
Has joined the channel.

danacr (Thu, 14 Feb 2019 15:49:16 GMT):
Is anybody running a k8s deployment with indy nodes?

coderintherye (Thu, 14 Feb 2019 22:36:37 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=pE9FzEbWW9fauXMrw) @danacr we've been exploring it, but the benefits didn't override the complexity of trying to get it going so we gave that up for now, would be interested if anyone is doing it and willing to share their setup / steps

danacr (Fri, 15 Feb 2019 11:51:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=5vfZfoCbTdjdTtBC8) @coderintherye I'd be happy to contribute, my current issue is finding proper dockerfiles which allow for multiple stewards. The demo one is 4 in one container

movee2005 (Sat, 16 Feb 2019 23:58:12 GMT):
Has joined the channel.

movee2005 (Sun, 17 Feb 2019 00:00:16 GMT):
Folks -- can anyone help with why I get an error when running pool_start to setup a local network ./pool_start.sh 4 0.0.0.0 2 9701. I get the error docker: Error response from daemon: Invalid address 192.0.0.1: It does not belong to any of this network's subnets.

danacr (Sun, 17 Feb 2019 14:39:37 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=gG9P4FP8dTPDFLqGQ) @movee2005 are you referring to this? https://github.com/hyperledger/indy-node/tree/master/environment/docker/pool

movee2005 (Sun, 17 Feb 2019 19:39:51 GMT):
Yes

movee2005 (Sun, 17 Feb 2019 19:41:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=daEKBa4yPYu7jKb2E) @danacr Yes.. I cloned the repository and actually, trying to get a local network running to try the Alice tutorial

movee2005 (Sun, 17 Feb 2019 19:43:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=YcCjsYcN528McANM4) There is an error in the cut and paste.. it should read Invalud address 0.0.0.0. I tried various addresses

sudodazza (Sun, 17 Feb 2019 23:14:20 GMT):
Has joined the channel.

sudodazza (Sun, 17 Feb 2019 23:15:47 GMT):
Hi all - does anyone know what utility performs the log rotation function in `/var/log/indy/sandbox` and on what schedule? Thanks in advance

sergey.khoroshavin (Mon, 18 Feb 2019 09:15:25 GMT):
@sudodazza by default logs are rotated once they reach 100 Mb size uncompressed. During rotation they are compressed into xz in a separate process (so that node doesn't stall for several seconds). Maximum number of allowed backups is 150 by default. You can look for actual default values in https://github.com/hyperledger/indy-plenum/blob/master/stp_core/config.py, and you can override them in `/etc/indy/indy_config.py`. If you want to see the actual code that does rotation - here it is: https://github.com/hyperledger/indy-plenum/blob/master/stp_core/common/logging/CompressingFileHandler.py

danacr (Mon, 18 Feb 2019 10:58:18 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=CNtKYX8tfyk5qBMGG) @movee2005 0.0.0.0 does not seem to be the right way to pass the ip addresses, if you do not want the default values, you must enter 4 values, e.g. 10.0.0.2,10.0.0.3,10.0.0.4,10.0.0.5 and not 0.0.0.0 (which I assume in your case is the listening address)

movee2005 (Mon, 18 Feb 2019 15:02:10 GMT):
thanks I will try.. I was trying to find the syntax

ruggero.montalto-tno (Tue, 19 Feb 2019 13:06:18 GMT):
Has joined the channel.

ruggero.montalto-tno (Tue, 19 Feb 2019 14:07:21 GMT):
I use the stable Sovring deb repo (`"deb https://repo.sovrin.org/deb xenial stable"`), but after running the command `sudo apt install -y sovrin` I obtain the following outcome: ``` Reading package lists... Done Building dependency tree Reading state information... Done 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: sovrin : Depends: indy-node (= 1.6.83) but it is not going to be installed Depends: sovtoken (= 0.9.9) but it is not going to be installed Depends: sovtokenfees (= 0.9.9) but it is not going to be installed Depends: libindy-crypto (= 0.4.5) but 0.5.1 is to be installed E: Unable to correct problems, you have held broken packages. ``` Any ideas why that might be?

ruggero.montalto-tno (Tue, 19 Feb 2019 14:07:21 GMT):
I use the stable Sovrin deb repo (`"deb https://repo.sovrin.org/deb xenial stable"`), but after running the command `sudo apt install -y sovrin` I obtain the following outcome: ``` Reading package lists... Done Building dependency tree Reading state information... Done 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: sovrin : Depends: indy-node (= 1.6.83) but it is not going to be installed Depends: sovtoken (= 0.9.9) but it is not going to be installed Depends: sovtokenfees (= 0.9.9) but it is not going to be installed Depends: libindy-crypto (= 0.4.5) but 0.5.1 is to be installed E: Unable to correct problems, you have held broken packages. ``` Any ideas why that might be?

sudodazza (Tue, 19 Feb 2019 22:48:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=WqDWtLXMWjttXDbau) @sergey.khoroshavin Thanks @sergey.khoroshavin

ryanwest6 (Tue, 19 Feb 2019 23:11:37 GMT):
On both mainnet and testnet, the first 16 and 15 transactions (perhaps more) on the ledgers have missing subfields "txnId" and "txnTime" from the top field "txnMetadata". Does anyone know why these are missing fields that are supposedly required and are included in all subsequent transactions?

ryanwest6 (Tue, 19 Feb 2019 23:11:37 GMT):
On both mainnet and testnet, the first 16 and 15 transactions (perhaps more) on the ledgers have missing subfields "txnId" and "txnTime" from the top field "txnMetadata". Does anyone know why these are missing fields that are supposedly required and are included in all subsequent transactions? (I'm building a binary search algorithm to return the first transaction on or after a given POSIX timestamp, but these transactions don't have timestamps)

danacr (Wed, 20 Feb 2019 08:26:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=5vfZfoCbTdjdTtBC8) @coderintherye we got it working in k8s and will share our template once we are certain it is stable

dnnn (Wed, 20 Feb 2019 09:23:18 GMT):
Hi all, I am experiencing troubles with installing indy-node with this command from docs: ``` sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 68DB5E88 sudo bash -c 'echo "deb https://repo.sovrin.org/deb xenial stable" >> /etc/apt/sources.list' sudo apt-get update sudo apt-get install indy-node ``` The problem is in indy-plenum versions mismatch: ``` The following packages have unmet dependencies: indy-node : Depends: indy-plenum (= 1.6.58) but 1.6.644 is to be installed ``` Could anyone share a hint on how could it be fixed?

dnnn (Wed, 20 Feb 2019 09:44:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=s4jsyRCTmWXQsu4y6) Was able to fix it by providing explicit versions for packages ``` sudo echo "deb https://repo.sovrin.org/deb xenial stable" >> /etc/apt/sources.list && \ sudo apt-get update && \ sudo apt-get -y install indy-plenum=1.6.58 && \ sudo apt-get -y install indy-node=1.6.83 ``` But I guess that the `Packages` file (located here: https://repo.sovrin.org/deb/dists/xenial/stable/binary-amd64/) should be updated to resolve this issue anyway.

dnnn (Wed, 20 Feb 2019 09:44:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=s4jsyRCTmWXQsu4y6) Was able to fix it by providing explicit versions for packages ``` ```

dnnn (Wed, 20 Feb 2019 09:44:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=s4jsyRCTmWXQsu4y6) Was able to fix it by providing explicit versions for packages ``` sudo echo "deb https://repo.sovrin.org/deb xenial stable" >> /etc/apt/sources.list && \ sudo apt-get update && \ sudo apt-get -y install indy-plenum=1.6.58 && \ sudo apt-get -y install indy-node=1.6.83 ```

mgbailey (Wed, 20 Feb 2019 15:07:56 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=iGDGnRiRXh8uTi7Pj) @ryanwest6 The first transactions on the pool and domain ledgers are from the genesis file. Since they were not added to the ledger using the consensus protocols, but were instead the initial configuration of the ledger when it spun up, they do not have transaction ids.

ashcherbakov (Thu, 21 Feb 2019 07:26:27 GMT):
@dnnn 1.6.644 is a master version, so it looks like you have both master (`https://repo.sovrin.org/deb xenial master`) and stable (`https://repo.sovrin.org/deb xenial stable`) deb repos installed. If you remove `master`, then I think everything should be fine.

tenfinney (Thu, 21 Feb 2019 18:55:39 GMT):
Has joined the channel.

danacr (Thu, 21 Feb 2019 23:36:54 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=LbidyuA8HNixvBDLi) added k8s support to the bc-gov dev network, seems to work fine https://github.com/Kryha/indy-network

ashlinSajan (Fri, 22 Feb 2019 09:11:47 GMT):
Has joined the channel.

ashlinSajan (Fri, 22 Feb 2019 09:12:47 GMT):
@kdenhartog I am new to indy.Can you tell me what an indy pool is?

kdenhartog (Fri, 22 Feb 2019 09:14:03 GMT):
It's a collection of nodes that operate an Indy network. So for example if 4 nodes (separate servers) are operating an indy network the collection of 4 nodes would be referred to as a pool.

ashlinSajan (Fri, 22 Feb 2019 09:18:17 GMT):
@kdenhartog what is the use of jupyter notebook

kdenhartog (Fri, 22 Feb 2019 11:02:19 GMT):
it's intended to be a way to setup a sandbox to learn new concepts and tools that exist in the Indy ecosystem

ruggero.montalto-tno (Fri, 22 Feb 2019 11:13:25 GMT):
(I'm cross-posting from #indy-sdk ) 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. Do I need someone to accreditate me, or is there a way I can do it myself?

esplinr (Fri, 22 Feb 2019 20:08:57 GMT):
@ruggero.montalto-tno You can run your own indy network, but to join the Sovrin Test Net, your organization needs to go through the process to be a Sovrin steward.

esplinr (Fri, 22 Feb 2019 20:09:35 GMT):
https://sovrin.org/stewards/

esplinr (Fri, 22 Feb 2019 20:09:51 GMT):
You can run applications that create and use Sovrin credentials without being a Sovrin steward.

esplinr (Fri, 22 Feb 2019 20:10:38 GMT):
https://forum.sovrin.org/t/testing-on-the-sovrin-test-network-stn/643

JoshCook (Fri, 22 Feb 2019 20:51:24 GMT):
Has joined the channel.

nanspro (Sat, 23 Feb 2019 02:11:35 GMT):
Has left the channel.

JoshCook (Wed, 27 Feb 2019 22:19:24 GMT):
Hey everyone, just wondering what is the best way / OS to run a node cluster on Raspberri Piis.

DuckLover (Sun, 03 Mar 2019 21:15:14 GMT):
Has joined the channel.

DuckLover (Sun, 03 Mar 2019 21:22:58 GMT):
Hello, can anyone provide a source about the storage in the ledger? I am interested in how the ledger is made immutable without using a blockchain but also who can read entries. Is is possible to scan every entry for the endpoint adress to detect the most popular Sovrin Agent for example?

cam-parra (Mon, 04 Mar 2019 14:03:43 GMT):
Has joined the channel.

cam-parra (Mon, 04 Mar 2019 14:10:39 GMT):
@DuckLover I can answer some of your questions. Anyone is able to read off the ledger in fact it is public so if you wanted to see who was the most popular sovrin agent you would be able to scan the ledgers. When we say the sovrin ledger we mean the domain, config, and the pool ledger. The domain stores information like NYM transactions, while the config holds the configuration of the ledger. And the pool is where the add node, pool status and other transactions are kept.

ashcherbakov (Mon, 04 Mar 2019 14:20:49 GMT):
@DuckLover > Hello, can anyone provide a source about the storage in the ledger? Please have a look at https://github.com/hyperledger/indy-plenum/blob/master/docs/source/storage.md https://github.com/hyperledger/indy-plenum/blob/master/docs/source/diagrams/storages.png > I am interested in how the ledger is made immutable without using a blockchain There is a merkle tree for every ledger, and the consistency of data (equal merkle tree root hashes) is part of Plenum consensus protocol, so that Plenum makes sure that all nodes have the same data. > who can read entries The ledger is public, so everyone can read

cam-parra (Mon, 04 Mar 2019 14:40:07 GMT):
@DuckLover https://indyscan.io/home/SOVRIN_MAINNET

DuckLover (Mon, 04 Mar 2019 15:19:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=9ggT3aTuL8nG9pvo6) @cam-parra Doesnt the identity ledger contains the DiD-Documents and the Agent Endpoints?

DuckLover (Mon, 04 Mar 2019 15:20:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=mEyZ6gcFPHL3sgGCD) @ashcherbakov Thanks for the ressources :-) So it is possible to decide to change a value in the past without computing all the following entries?

ashcherbakov (Mon, 04 Mar 2019 15:22:46 GMT):
@DuckLover > Doesnt the identity ledger contains the DiD-Documents and the Agent Endpoints? There is no full DID-DOC support yet there

ashcherbakov (Mon, 04 Mar 2019 15:23:37 GMT):
> So it is possible to decide to change a value in the past without computing all the following entries? A node may try to change a value in the past, but such change will not be accepted by other nodes and clients

ashcherbakov (Mon, 04 Mar 2019 15:24:11 GMT):
Since the nodes sign root hashes of the merkle tree by BLS multi-signature

cam-parra (Mon, 04 Mar 2019 15:26:09 GMT):
And with merkle trees any child node that is changed will result in a different root hash.

lorenz.loesch (Mon, 04 Mar 2019 15:37:31 GMT):
Has joined the channel.

DuckLover (Mon, 04 Mar 2019 15:45:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=PXGpuNdiAqGpBrQhr) @ashcherbakov Does it support that all nodes decide to change a value? In case of an security incident? With blockchains there are only forks possible what about the indy ledger?

shenoy (Mon, 04 Mar 2019 15:59:58 GMT):
Has joined the channel.

ryanwest6 (Mon, 04 Mar 2019 17:42:42 GMT):
I'm looking at how to get revocation info off the ledger, but the testnet domain ledger doesn't have any REVOC_REG_DEF transactions. Does anyone know from which ledger I can retrieve these transactions and if they are on the testnet?

ashcherbakov (Mon, 04 Mar 2019 18:07:00 GMT):
@DuckLover Plenum is a permissioned ledger (not a permissionless like Bitcoin) which means that not everyone can become a validator Node. Plenum is also based on BFT consensus protocol, which supports up to f nodes being malicious (where the total number of nodes is 3f+1). Changing a value by all nodes means that all the nodes behave maliciously.

ashcherbakov (Mon, 04 Mar 2019 18:08:11 GMT):
@ryanwest6 Revocation txns are in DOMAIN ledger, but I'm not sure that there are any on the testnet yet.

Sreesha (Tue, 05 Mar 2019 09:00:45 GMT):
Has joined the channel.

movee2005 (Tue, 05 Mar 2019 18:17:46 GMT):
Guys I am not sudy Documentation is really useful. There is a struggle to get stuff right between documentation and reality.

movee2005 (Tue, 05 Mar 2019 18:17:51 GMT):
https://github.com/hyperledger/indy-node/blob/master/getting-started.md

movee2005 (Tue, 05 Mar 2019 18:18:26 GMT):
Under Indy-CLI none of the commands work as is in the documentation. Is there some CLI documentation that is updated and works.

movee2005 (Tue, 05 Mar 2019 18:19:36 GMT):
For example, new wallet Alice is not correct - it seems to be wallet create Alice key="Key1"

movee2005 (Tue, 05 Mar 2019 18:20:41 GMT):
indy> how sample/faber-request.indy works but indy>load sample/faber-request.indy fails

Diiaablo95 (Wed, 06 Mar 2019 11:47:24 GMT):
Has joined the channel.

Diiaablo95 (Wed, 06 Mar 2019 11:47:28 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?

cam-parra (Wed, 06 Mar 2019 15:27:26 GMT):
@movee2005 I'd be glad to run through a quick demo with you whenever you'd like . Currently the team is pretty busy working on ledger performance so maybe from my demo you could update the documentation

peteoleary (Wed, 06 Mar 2019 16:20:05 GMT):
Has joined the channel.

ashcherbakov (Wed, 06 Mar 2019 19:29:59 GMT):
@movee2005 https://github.com/hyperledger/indy-node/blob/master/getting-started.md is outdated (and should be removed in general). Please follow https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/indy-walkthrough.md instead

peteoleary (Wed, 06 Mar 2019 20:18:41 GMT):
@cam-parra I'll take you up on that demo offer you gave @movee2005. I have been using the NodeJS agent to follow the walkthrough with good results but I am stuck. Maybe your demo can give me some ideas on how to get unstuck. I'm happy to take notes and update docs as best I can.

charliez (Thu, 07 Mar 2019 01:45:02 GMT):
Has joined the channel.

Diiaablo95 (Thu, 07 Mar 2019 13:33:17 GMT):
Hey guys! Can you help me with setting up a pool across two organizations over the public internet? I have followed the guides, and am able to join the node to the network. But when the client tries to connect to the pool, it gets a null public key from the node.

Diiaablo95 (Thu, 07 Mar 2019 13:34:05 GMT):
Is there anything else that needs to be done on the node side, other than call init_indy_node with the right parameters and then copy the values of public_key, blskey and blskey_pop into the pool genesis transaction?

Diiaablo95 (Thu, 07 Mar 2019 13:34:48 GMT):
If I run the genesis example, and then create a new node and modify the created genesis transaction, everything works. But if I start from scratch, I get this issue.

mgbailey (Thu, 07 Mar 2019 15:19:14 GMT):
@Diiaablo95 , follow the steps in https://docs.google.com/document/d/1AH618bj4q9U8FS1uyoIgbcvwNzaghBCQ1v44tNpZ2OU/edit?usp=sharing. This is what new stewards follow to set up a new validator on the Sovrin TestNet. Of course, you will need to use your own genesis files instead of those for the

mgbailey (Thu, 07 Mar 2019 15:19:14 GMT):
@Diiaablo95 , follow the steps in https://docs.google.com/document/d/1AH618bj4q9U8FS1uyoIgbcvwNzaghBCQ1v44tNpZ2OU/edit?usp=sharing. This is what new stewards follow to set up a new validator on the Sovrin TestNet. Of course, you will need to use your own genesis files instead of those for the TestNet.

mgbailey (Thu, 07 Mar 2019 15:21:04 GMT):
At step 3.4, you will need to use the CLI, using the Trustee keys on your network, to add the steward DID to the network, like this:

mgbailey (Thu, 07 Mar 2019 15:22:23 GMT):
``` ledger nym role=STEWARD did= verkey=```

Diiaablo95 (Thu, 07 Mar 2019 15:45:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=2nHn4zardP6iZWeky) @mgbailey Hey! Thanks for your answer. I actually already came across that document, but it somehow didn't help me in solving the problem. What I am doing is to create a genesis transaction with only one trustee and one steward ("added" by the trustee) in the domain genesis, and one node "added" by the steward in the pool genesis. As a node, I manage to connect to the pool indeed, the problem is client-side (indy-cli) when trying to connect to the pool...

mgbailey (Thu, 07 Mar 2019 15:55:08 GMT):
You need at least 4 nodes in your genesis pool, for consensus

dnnn (Thu, 07 Mar 2019 23:56:08 GMT):
less than 1

mwherman2000 (Fri, 08 Mar 2019 03:44:10 GMT):
@DuckLover @cam-parra Checkout the INDY ARM for answers to some of your questions: https://github.com/mwherman2000/indy-arm/blob/master/README.md#1-all-in-viewpoint-

mwherman2000 (Fri, 08 Mar 2019 03:45:12 GMT):
Each of the bulleted element is described here: https://github.com/mwherman2000/indy-arm/blob/master/README.md#narration

mwherman2000 (Fri, 08 Mar 2019 03:46:19 GMT):
In addition to the "All-in" viewpoint, there's also a series of more detailed/zoomed in viewpoints: https://github.com/mwherman2000/indy-arm/blob/master/README.md#3-did-resolution-viewpoint-

mwherman2000 (Fri, 08 Mar 2019 03:47:01 GMT):
The current list of viewpoints can be found here: https://github.com/mwherman2000/indy-arm/blob/master/README.md#indy-arm-viewpoints-

itbill (Fri, 08 Mar 2019 05:47:04 GMT):
Has joined the channel.

Diiaablo95 (Mon, 11 Mar 2019 13:11:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=6wxAnWetJhr9ZXjJn) @mgbailey But that's not true. If I start a test network with only two validator nodes, everything keeps working seamlessly.

cam-parra (Mon, 11 Mar 2019 13:16:52 GMT):
@ashcherbakov :arrow_up_small:

sergey.khoroshavin (Mon, 11 Mar 2019 13:22:08 GMT):
@Diiaablo95 it is possible to start a network with less than four validator nodes, however in this case if any node goes down network will stop ordering - so there will be no fault tolerance

Diiaablo95 (Mon, 11 Mar 2019 13:25:59 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=uiFLkT2fWrBH4HxP6) @sergey.khoroshavin Yes, I know that. Thanks :) Anyway, my current problem is that I cannot get the pool working if I generate the pool genesis transaction from scratch. The only difference between the one I write and the auto-generated one is the length of the identifiers and verkeys. I always use the full length version, while the auto-generated always uses the truncated one. Does that matter?

sergey.khoroshavin (Mon, 11 Mar 2019 13:29:36 GMT):
@Diiaablo95 oh, I should have mentioned @mgbailey and @cam-parra in my previous reply. Anyways - can you provide some logs for your failing case?

Diiaablo95 (Mon, 11 Mar 2019 13:29:47 GMT):
Or maybe I'm missing something when initializing the Node.. I don't know. What I do is generate keys for 3 trustees, 3 stewards and 3 nodes, and then generate the test genesis transaction but then modify it according to all the keys that I had previously generated.

Diiaablo95 (Mon, 11 Mar 2019 13:30:16 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=kKcLGYG7p42DAxMxD) @sergey.khoroshavin I'm going through the process once more, I should be done in 10-15 mins and I'll write whatever output I'll get

cam-parra (Mon, 11 Mar 2019 13:31:25 GMT):
@sergey.khoroshavin thanks for answering that :) I will let you continue from here

Diiaablo95 (Mon, 11 Mar 2019 13:52:15 GMT):
@sergey.khoroshavin sorry man, I have to rush. I'll keep working on this tomorrow. I will post something here as soon as I have it. Hope you or somebody else could help me out :) Cheers!

ashcherbakov (Mon, 11 Mar 2019 17:21:44 GMT):
@Diiaablo95 Why don't you use Docker for setting up a network: https://github.com/hyperledger/indy-node/blob/master/environment/docker/pool/README.md?

ashcherbakov (Mon, 11 Mar 2019 17:51:39 GMT):
@Diiaablo95 If you want to setup a pool manually, you can use https://github.com/hyperledger/indy-node/blob/master/docs/source/start-nodes.md#scripts-for-initialization

nage (Mon, 11 Mar 2019 21:37:46 GMT):
For those who would like to participate in the "ledger 2.0" effort we have opened up the #indy-ledger-next channel for those discussions

Diiaablo95 (Tue, 12 Mar 2019 07:44:32 GMT):
Hey @ashcherbakov, the Docker solution is limited to a pool running locally, and the needs are to create a pool over three different organizations linked by public IP addresses, as part of a pilot project. I followed also the scripts in the second link you put, but the scripts generate a pool without giving you the keys used for the Trustee and the Stewards. Meaning that you cannot extend the pool with more nodes (as far as I understood). What I am trying to do, is to automate the process of setting up a distributed pool (over the Internet), in which there is an initial set of nodes, but the same initiators are also trustees and stewards, meaning that 1. they have control over their keys and 2. the pool can be extended by adding more validators and nodes at a later stage.

GEEKTEDDY (Tue, 12 Mar 2019 08:23:27 GMT):
Hi, about the structure of transaction "CLAIM_DEF", what's is the attribute 'primary' and 'revocation' used for? I am not understand the usage of primary/revocation claim public key.

Diiaablo95 (Tue, 12 Mar 2019 09:28:57 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=JqLbbDhjpXnTB5Dkd) I am probably just missing something regarding which value of the output of init_indy_keys I should use if I want to add (and later control) a TRUSTEE or VALIDATOR to the genesis transaction :disappointed_relieved:

Diiaablo95 (Tue, 12 Mar 2019 14:53:10 GMT):

Error_screenshot.png

reithmayer (Wed, 13 Mar 2019 07:47:57 GMT):
Has joined the channel.

sergey.khoroshavin (Wed, 13 Mar 2019 09:21:25 GMT):
@Diiaablo95 this looks like a bug in Indy SDK

sergey.khoroshavin (Wed, 13 Mar 2019 09:21:36 GMT):
@sergey.minaev :arrow_up:

Diiaablo95 (Wed, 13 Mar 2019 10:43:27 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=cMDYF2vbd8WE2b2NZ) @sergey.khoroshavin Oh, I honestly hope it's not :joy: I am more likely to think that I am doing something wrong here with node keys, somewhere...

sergey.khoroshavin (Wed, 13 Mar 2019 10:52:52 GMT):
@Diiaablo95 I suspect that there is something bad with your setup, since nodes return zeroed keys, however it shouldn't lead to crashes due to some assertion errors

sergey.khoroshavin (Wed, 13 Mar 2019 10:54:11 GMT):
It would be very useful if you could provide logs from nodes themselves, not client

Diiaablo95 (Wed, 13 Mar 2019 10:55:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=MEMDpj9NwDSFoMyP9) @sergey.khoroshavin Nodes do not show anything. That's the weird thing. I set the log level to the maximum, DEBUG, but still nothing is shown.

Diiaablo95 (Wed, 13 Mar 2019 10:55:48 GMT):
I'm trying once more now, so I'll see if anything changes. But that's what I've gotten in the past 3 days

Diiaablo95 (Wed, 13 Mar 2019 11:00:54 GMT):

Error_screenshot_2.png

Diiaablo95 (Wed, 13 Mar 2019 11:02:29 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=tXwteQ3y4oaMLTa9o) This is one more thing that happens. I generate the keys for a node with `init_indy_keys Node1 10.0.0.5 9701 10.0.0.5 9702 --seed 111111111111111111111111111Node1` and it generates keys folders correctly. I then run `start_indy_node Node1 0.0.0.0 9701 0.0.0.0 9702` and the content of the public keys gets messed up, and the public keys do not match anymore the private counterparts. This leads to impossibility to authenticate nodes among each other.

sergey.khoroshavin (Wed, 13 Mar 2019 11:12:48 GMT):
@Diiaablo95 concerning logs - did you look into /var/log/indy, probably /var/log/indy/sandbox/Node1 ?

Diiaablo95 (Wed, 13 Mar 2019 11:13:33 GMT):
I configured the node to print to stdout as well, so I'm getting everything realtime anyway

Diiaablo95 (Wed, 13 Mar 2019 11:47:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=xfgLR4kPZhSown3XD) Which, by the way, is not the case if the `generate_indy_pool_transactions --nodes 4 --clients 0 --nodeNum 1 --network=test_script` script is launched. In that case, everything works fine.

Diiaablo95 (Wed, 13 Mar 2019 14:19:21 GMT):
*I THINK I FINALLY FOUND THE ISSUE!* In the transactions documents, it's written that for nodes, the _dest_ field should contain the DID of the node. But in the (working) script setup, that field actually contains the *verification key* of the node. If you try to replace that value with value of the public key, you get the assertion failure.

stefanopulzeic (Wed, 13 Mar 2019 16:41:50 GMT):
Has left the channel.

JuanCamilo_0314 (Wed, 13 Mar 2019 19:59:18 GMT):
Has joined the channel.

JuanCamilo_0314 (Wed, 13 Mar 2019 19:59:26 GMT):
cli

jlspector68 (Thu, 14 Mar 2019 06:02:02 GMT):
Has joined the channel.

jlspector68 (Thu, 14 Mar 2019 06:07:12 GMT):
Hi All - quick question about the CLI. I have a test network running in Docker and can connect to the pool within Docker from the CLI. What I am completely missing is how to interact with the pool in the role of Trustee? I can add a new wallet and a DID, but how to I use the role in the domain_transactions_genesis file? Hopefully that even makes sense. Thank you!

jlspector68 (Thu, 14 Mar 2019 06:07:12 GMT):
Hi All - quick question about the CLI. I have a test network running in Docker and can connect to the pool within Docker from the CLI. What I am completely missing is how to interact with the pool in the role of Trustee? I can add a new wallet and a DID, but how do I use the role in the domain_transactions_genesis file? Hopefully that even makes sense. Thank you!

Diiaablo95 (Thu, 14 Mar 2019 08:21:09 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=NkiKP533khALuNrkj) @jlspector68 Hey! You need to generate the keys for the Trustee :) The test example uses the Trustee key generated by using the seed `000000000000000000000000Trustee1`. So generate the keys with `init_indy_keys --name Trustee1 --seed 000000000000000000000000Trustee1` and then import the DID of the trustee into the wallet (if you run `did import help` the cli tells you the structure of the DID).

jlspector68 (Thu, 14 Mar 2019 13:11:39 GMT):
@Diiaablo95 - thanks for the reply! So, I went into the Docker container and ran that command and got this output:

jlspector68 (Thu, 14 Mar 2019 13:11:39 GMT):
@Diiaablo95 - thanks for the reply! So, I went into the Docker container and ran that command and got this output: init_indy_keys --name Trustee1 --seed 000000000000000000000000Trustee1 Node-stack name is Trustee1 Client-stack name is Trustee1C Generating keys for provided seed 000000000000000000000000Trustee1 Init local keys for client-stack Public key is XWSNZUwj7Uc4KzBuTQjNwCZZFwXSMNGVqnfDgbwMiNP Verification key is GJ1SzoWzavQYfNL9XkaJdrQejfztN4XqdsiV4ct3LXKL Init local keys for node-stack Public key is XWSNZUwj7Uc4KzBuTQjNwCZZFwXSMNGVqnfDgbwMiNP Verification key is GJ1SzoWzavQYfNL9XkaJdrQejfztN4XqdsiV4ct3LXKL BLS Public key is 3KKbz86PXZYaCfMTwTCtXLsmxeDgRthXhynnsEciRp3K1rD1JwZWYzC2WDUtXuy4XUnEaa9aP5U745vukV9NRgnie8qf5vPST8mNB2mytC9P4mVuxkDv8eeUuvymiSkUUutSRjuSAcqqjjtQUFTCDKfNKZzoCL2mdpJPYFwgqERmgCu Proof of possession for BLS key is R87RNGQEGLpCDJx9CwmSrYQVNj5XNjguFFUJ2GwX6Cms13j2nWtfzeDLgMz5fC4NSXrnwNpcahWBg39jW1hK54T7RHMJpsmd7SGabUBc4XFKT7xLdmawMDsCj7HmssTkpN3NH1mn3bVpXDbwmxS4bJaSFbNNw17jmFqxoyEHtLswqh

jlspector68 (Thu, 14 Mar 2019 13:12:32 GMT):
@Diiaablo95 - help for import DID is: did import help Command: did import - Import DIDs entities from file to the current wallet. File format: { "version": 1, "dids": [{ "did": "did", "seed": "UTF-8, base64 or hex string" }] } Usage: did import Parameters are: file - Path to file with DIDs

jlspector68 (Thu, 14 Mar 2019 13:12:47 GMT):
@Diiaablo95 Not sure what to import?

jlspector68 (Thu, 14 Mar 2019 13:58:19 GMT):
@Diiaablo95 - What I ended up doing was creating a new DID in a wallet with this: did new seed=000000000000000000000000Trustee1, then did use and that seems to have done the trick

aronvanammers (Mon, 18 Mar 2019 14:13:58 GMT):
Has joined the channel.

aguel (Mon, 18 Mar 2019 18:10:02 GMT):
Has joined the channel.

GEEKTEDDY (Wed, 20 Mar 2019 10:28:55 GMT):
Hi, where can I find the trigger of view change in doc or code?

ashcherbakov (Wed, 20 Mar 2019 14:41:05 GMT):
@GEEKTEDDY Please have a look at https://github.com/hyperledger/indy-plenum/blob/master/plenum/server/view_change/view_changer.py, in particular where `propose_view_change` is called

BernardLin (Fri, 22 Mar 2019 14:29:28 GMT):
Has joined the channel.

Gruszka (Fri, 22 Mar 2019 21:43:52 GMT):
Has joined the channel.

NutecDev (Mon, 25 Mar 2019 10:07:32 GMT):
Has joined the channel.

Ryan2 (Tue, 26 Mar 2019 04:48:44 GMT):
Has joined the channel.

pyraman (Tue, 26 Mar 2019 08:27:49 GMT):
Has joined the channel.

lepar (Tue, 26 Mar 2019 13:55:01 GMT):
Has joined the channel.

janb (Tue, 26 Mar 2019 21:16:06 GMT):
Has joined the channel.

janb (Tue, 26 Mar 2019 21:17:00 GMT):
Hi, I have a question about running indy nody in a docker/pool configuration locally for development purposes - the containers seem to claim 100% CPU

janb (Tue, 26 Mar 2019 21:17:20 GMT):
I have the issue on two different machines

GEEKTEDDY (Wed, 27 Mar 2019 08:45:54 GMT):
Hi, I have several questions about the code of node(node.py)

GEEKTEDDY (Wed, 27 Mar 2019 08:46:51 GMT):
``` Hi, I have several questions about the code of node(node.py) ```

GEEKTEDDY (Wed, 27 Mar 2019 09:03:08 GMT):
``` Hi, I have several questions while digging into the code of node(node.py) 1.how many states a node has? 2.node.py line 3053, there is a function 'sendNodeRequestSpike()’ which is called in node performance check, what’s the function for? 3.node.py line 3583, there is a function ‘reportSuspiciousNode()’, I think if there are some errors when nodes is handling messages, there will have an exception, which will cause this function be called. So what kind of cases will cause the exceptions? ```

GEEKTEDDY (Wed, 27 Mar 2019 09:03:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=gcqoophpQBGfj5k2d) @ashcherbakov

sklump (Wed, 27 Mar 2019 11:15:10 GMT):
Has joined the channel.

sklump (Wed, 27 Mar 2019 11:21:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=qfgLqm8a6bzpZxzmX) A flavour of this is back: now, acting as the Trustee, I cannot change the role in a user's cryptonym from `` to `TRUST_ANCHOR` - I get ``` (1012) Ledger rejected transaction request: client request invalid: UnauthorizedClientRequest('TRUSTEE can not touch role field since only the owner can modify it',) ``` . Contrast https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md row #3 which states that the Trustee should have permission. I am running ``` indy_plenum_ver=1.6.726 indy_node_ver=1.6.862 ```

sklump (Wed, 27 Mar 2019 11:21:39 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=qfgLqm8a6bzpZxzmX) A flavour of this is back: now, acting as the Trustee, I cannot change the role in a user's cryptonym from `` to `TRUST_ANCHOR` - I get ``` (1012) Ledger rejected transaction request: client request invalid: UnauthorizedClientRequest('TRUSTEE can not touch role field since only the owner can modify it',) ``` . Contrast https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md row #3 which states that the Trustee should have permission. I am running ``` indy_plenum_ver=1.6.726 indy_node_ver=1.6.862 ``` . The original error from February follows, for posterity:

mgbailey (Wed, 27 Mar 2019 13:48:08 GMT):
@sklump Please file a JIRA ticket on this and let me know the number of it.

sklump (Wed, 27 Mar 2019 14:05:48 GMT):
Thanks @mgbailey : https://jira.hyperledger.org/browse/INDY-2033 is in.

ashcherbakov (Thu, 28 Mar 2019 06:44:12 GMT):
@sklump Thank for finding. We will have a look.

ashcherbakov (Thu, 28 Mar 2019 06:52:28 GMT):
@GEEKTEDDY > 1.how many states a node has? If you're talking about a State Trie, then we have a State Trie for every ledger (Domain, Pool, Config) except Audit ledger. More details can be found here: https://github.com/hyperledger/indy-plenum/blob/master/docs/source/storage.md https://github.com/hyperledger/indy-plenum/blob/master/docs/source/diagrams/storages.png

ashcherbakov (Thu, 28 Mar 2019 06:54:23 GMT):
> 2.node.py line 3053, there is a function 'sendNodeRequestSpike()’ which is called in node performance check, what’s the function for? This tracks changes in traffic (using moving average), like suspicious spikes, that may indicate beginning of DDoS attacks. The Stewards will be notified in this case (if they set up and enable this notification).

ashcherbakov (Thu, 28 Mar 2019 06:57:00 GMT):
> 3.node.py line 3583, there is a function ‘reportSuspiciousNode()’, I think if there are some errors when nodes is handling messages, there will have an exception, which will cause this function be called. So what kind of cases will cause the exceptions? There can be quite a lot of cases, when Primary (leader) behaves suspiciously or incorrectly, so that we send InstanceChange message to start a view change and elect a new one. Examples of suspicious actions can be found here: https://github.com/hyperledger/indy-plenum/blob/master/plenum/server/suspicion_codes.py

anikitinDSR (Thu, 28 Mar 2019 07:41:29 GMT):
@sklump please, can you describe all of the steps, which follows the error, in detail as much as possible.

sklump (Thu, 28 Mar 2019 11:59:23 GMT):
@anikitinDSR Bear with me, I'm trying to reproduce it on purely indy primitives and failing -- there may be a subtle problem on my side. Investigation continues.

sklump (Thu, 28 Mar 2019 11:59:23 GMT):
@anikitinDSR added comment in https://jira.hyperledger.org/browse/INDY-2033 to satisfy.

lukasA (Fri, 29 Mar 2019 10:19:29 GMT):
Has joined the channel.

AnnaJ (Fri, 29 Mar 2019 20:01:21 GMT):
Has joined the channel.

Henrycoffin (Sun, 31 Mar 2019 09:29:08 GMT):
Has joined the channel.

mbanerjee (Mon, 01 Apr 2019 22:02:00 GMT):
Has joined the channel.

VS09 1 (Wed, 03 Apr 2019 06:36:23 GMT):
Has joined the channel.

bart.cant@gmail.com (Thu, 04 Apr 2019 22:14:24 GMT):
Has joined the channel.

pmaruindy (Wed, 10 Apr 2019 02:47:09 GMT):
Has joined the channel.

vsadriano (Wed, 10 Apr 2019 13:45:43 GMT):
Hi! Where can I get the docs about add a new node on pool? Tks!

andrej-zirko (Wed, 10 Apr 2019 14:59:36 GMT):
Has joined the channel.

andrej-zirko (Wed, 10 Apr 2019 15:00:16 GMT):
Hello, please is the concept of observer node already implemented? Thank you

esplinr (Wed, 10 Apr 2019 23:05:19 GMT):
@andrej-zirko It is not yet implemented.

elbaloo (Fri, 12 Apr 2019 19:59:47 GMT):
Has joined the channel.

vsadriano (Mon, 15 Apr 2019 10:56:09 GMT):
Hi! I'm trying to add a new node on existing pool following [these steps](https://docs.google.com/document/d/1AH618bj4q9U8FS1uyoIgbcvwNzaghBCQ1v44tNpZ2OU/edit). I'm getting ```shell Transaction has been rejected: validation error [ClientNodeOperation]: should not contain the following chars ['0'] (dest=cafdeb0d83c1bf38a8e47e4b8b4cbf625e1bbadbade10d505ae48330992e4c09) ``` when I run `ledger node ...`. Any idea what'a going on

vsadriano (Mon, 15 Apr 2019 10:56:09 GMT):
Hi! I'm trying to add a new node on existing pool following [these steps](https://docs.google.com/document/d/1AH618bj4q9U8FS1uyoIgbcvwNzaghBCQ1v44tNpZ2OU/edit). I'm getting ```shell Transaction has been rejected: validation error [ClientNodeOperation]: should not contain the following chars ['0'] (dest=cafdeb0d83c1bf38a8e47e4b8b4cbf625e1bbadbade10d505ae48330992e4c09) ``` when I run `ledger node ...`. Any idea what'a going on?

vsadriano (Mon, 15 Apr 2019 10:56:09 GMT):
Hi! I'm trying to add a new node on existing pool following [these steps](https://docs.google.com/document/d/1AH618bj4q9U8FS1uyoIgbcvwNzaghBCQ1v44tNpZ2OU/edit). I'm getting ```shell Transaction has been rejected: validation error [ClientNodeOperation]: should not contain the following chars ['0'] (dest=cafdeb0d83c1bf38a8e47e4b8b4cbf625e1bbadbade10d505ae48330992e4c09) ``` when I run `ledger node ...`. Any idea what'a going on?

mgbailey (Mon, 15 Apr 2019 14:07:56 GMT):
@vsadriano my guess is that you are using an old version of indy-node. The current version is 1.8.3. In older versions, init_indy_node returned the node DID in hexadecimal, which the admin then needed to convert to base58 before writing it to the ledger. This step is no longer necessary, and the conversion step has been removed from the validator prep guide.

vsadriano (Mon, 15 Apr 2019 15:08:53 GMT):
Yes @mgbailey! I'm using `1.6.8`. I'll try with `1.8.3`. Tks!

itarunachalam (Tue, 16 Apr 2019 08:49:18 GMT):
Has joined the channel.

ONRising (Wed, 17 Apr 2019 13:52:53 GMT):
Has joined the channel.

esplinr (Wed, 17 Apr 2019 19:58:24 GMT):
@vsadriano and @mgbailey The latest release of Indy Node is 1.6.83 (February). The latest release of Indy SDK is 1.8.2 (March).

mgbailey (Wed, 17 Apr 2019 20:02:28 GMT):
Right. Sorry. That is what I meant

vsadriano (Wed, 17 Apr 2019 20:07:29 GMT):
@esplinr tks!

Switch2Logic (Thu, 18 Apr 2019 10:30:11 GMT):
Has joined the channel.

lucafra (Thu, 18 Apr 2019 12:14:24 GMT):
Has joined the channel.

rangak (Thu, 18 Apr 2019 23:10:18 GMT):
Has joined the channel.

pioneer (Mon, 22 Apr 2019 06:34:03 GMT):
Has joined the channel.

Raja_Sabarish (Mon, 22 Apr 2019 10:35:49 GMT):
Has joined the channel.

Raja_Sabarish (Mon, 22 Apr 2019 10:35:56 GMT):
Hi Everyone, I am trying to use https://github.com/IBM-Blockchain-Identity/indy-ssivc-tutorial while following those installation steps, I need to build the VON Network as part of installation. So while building it by using this command `./manage build` it fails to build as it looks for particular version of indy-plenum[1.2.237] and indy-node[1.2.297] which is not even available in the version history. Kindly shed some light on this.

swcurran (Mon, 22 Apr 2019 14:07:40 GMT):
I suspect the IBM version of the demo is using an old version of the von-network that is out of date. Suggest that you compare the IBM version of the docker-compose file with the one in von-network itself - https://github.com/bcgov/von-network. A warning though - I don't think the IBM tutorial has been updated in awhile, and you might need to update the network and the SDK components in the demo.

Raja_Sabarish (Mon, 22 Apr 2019 14:12:14 GMT):
@swcurran OK sure! let me check

Raja_Sabarish (Mon, 22 Apr 2019 14:12:14 GMT):
@swcurran OK sure! let me check. Thanks a lot.

vsadriano (Mon, 22 Apr 2019 18:05:51 GMT):
Hi guys! I'm following the steps from [docs](https://docs.google.com/document/d/1AH618bj4q9U8FS1uyoIgbcvwNzaghBCQ1v44tNpZ2OU/edit) to add a new node validator on existing pool. I updated my `indy-node` to run and I'm getting this error: ```shell Transaction has been rejected: Can not find verkey for 'XYZ' ``` Any can help me?

mgbailey (Mon, 22 Apr 2019 18:15:45 GMT):
A nym for XYZ must have been previously added to the ledger as a STEWARD

vsadriano (Mon, 22 Apr 2019 18:18:04 GMT):
Hi @mgbailey where's the doc for action? tks!

mgbailey (Mon, 22 Apr 2019 18:20:41 GMT):
@vsadriano The best doc for this sort of thing is the one that stewards use while adding a node to one of the Sovrin networks: https://docs.google.com/document/d/1AH618bj4q9U8FS1uyoIgbcvwNzaghBCQ1v44tNpZ2OU

mgbailey (Mon, 22 Apr 2019 18:21:59 GMT):
The transaction for adding a NYM is: ledger nym role=STEWARD did=<> verkey=<> You must be a TRUSTEE on the validator pool to post this transaction

vsadriano (Mon, 22 Apr 2019 18:23:09 GMT):
Ok! Tks!

vsadriano (Tue, 23 Apr 2019 14:02:07 GMT):
How can I get complete `verkey` value using `indy-cli`?

sklump (Tue, 23 Apr 2019 14:08:04 GMT):
Has left the channel.

mgbailey (Tue, 23 Apr 2019 14:39:11 GMT):
@vsadriano The verkeys for all DIDs that are in your wallet can be seen by "did list". If you want to see the verkey for something that is on the ledger, you can run "ledger get-nym did=<>"

pioneer (Wed, 24 Apr 2019 06:26:47 GMT):
HI guys! ~/workspace/project/indy/indy-sdk/samples/python/src$ python3.6 getting_started.py ModuleNotFoundError: No module named 'indy'

pioneer (Wed, 24 Apr 2019 06:27:58 GMT):
any can help me? Thanks!

ajayjadhav (Wed, 24 Apr 2019 09:18:10 GMT):
Has joined the channel.

vsadriano (Wed, 24 Apr 2019 10:47:33 GMT):
@pioneer did you run `pip install -r $PATH/requirements.txt`?

Raja_Sabarish (Wed, 24 Apr 2019 12:06:47 GMT):
Hello Everyone!! Could someone help me in stopping all docker containers for this `Hyperledger Indy` *Alice* demo project https://github.com/hyperledger/education/blob/master/LFS171x/indy-material/nodejs/README.md I tried following commands: - `sudo ./manage down` - `docker stop $(docker ps -a -q)` - `docker rm $(docker ps -a -q)`

Raja_Sabarish (Wed, 24 Apr 2019 12:06:47 GMT):
Hello Everyone!! Could someone help me in stopping all docker containers for this `Hyperledger Indy` *Alice* demo project https://github.com/hyperledger/education/blob/master/LFS171x/indy-material/nodejs/README.md I tried the following commands: - `sudo ./manage down` - `docker stop $(docker ps -a -q)` - `docker rm $(docker ps -a -q)` It doesn't stop it says [Check Attachment]

Raja_Sabarish (Wed, 24 Apr 2019 12:06:47 GMT):
Hello Everyone!! Could someone help me in stopping all docker containers for this `Hyperledger Indy` *Alice* demo project https://github.com/hyperledger/education/blob/master/LFS171x/indy-material/nodejs/README.md I tried the following commands: - `sudo ./manage down` - `docker stop $(docker ps -a -q)` - `docker rm $(docker ps -a -q)` It doesn't stop it says [Check Below Attachment]

Raja_Sabarish (Wed, 24 Apr 2019 12:06:47 GMT):
Hello Everyone!! Could someone help me in stopping all docker containers for this `Hyperledger Indy` *Alice* demo project https://github.com/hyperledger/education/blob/master/LFS171x/indy-material/nodejs/README.md I tried the following commands: - `sudo ./manage down` - `sudo docker stop $(docker ps -a -q)` - `sudo docker rm $(docker ps -a -q)` It doesn't stop it says [Check Below Attachment]

Raja_Sabarish (Wed, 24 Apr 2019 12:09:32 GMT):

error_log.PNG

vsadriano (Wed, 24 Apr 2019 13:14:14 GMT):
@Raja_Sabarish you can try `docker-compose down -v`. It'll clear all docker-compose service volume.

Raja_Sabarish (Wed, 24 Apr 2019 13:15:47 GMT):
@vsadriano unfortuantely it fails. and it says the same error again.

Raja_Sabarish (Wed, 24 Apr 2019 13:16:52 GMT):
Actually `./manage down` calls `docker-compose down` itself.

vsadriano (Wed, 24 Apr 2019 13:16:58 GMT):
You can run docker without `sudo`: ```shell sudo usermod -aG docker $(whoami) sudo systemctl restart docker ```

Raja_Sabarish (Wed, 24 Apr 2019 13:17:53 GMT):
@vsadriano Wonderful that helped me up. Thanks a ton!!!

pioneer (Wed, 24 Apr 2019 15:35:13 GMT):
@vsadriano Thank you very much

swcurran (Wed, 24 Apr 2019 16:29:25 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=YfKgXsY7Fv7pTXuDL) @Raja_Sabarish That's very strange that *not* using sudo worked. Glad it worked. Did you use `sudo` when you ran the `./manage` command to start the example?

Raja_Sabarish (Thu, 25 Apr 2019 04:51:48 GMT):
@swcurran well, after running the below commands ```sudo usermod -aG docker $(whoami) sudo systemctl restart docker``` i did `docker-compose down` it stopped all the services. But then after running `sudo ./manage up` it started saying port is already in use So, to double check it `sudo netstat -tulpn | grep LISTEN` and killed all the process. Now if i try to start bby using `sudo ./manage up`. Its not starting at all. kindly look at below logs

Raja_Sabarish (Thu, 25 Apr 2019 04:51:48 GMT):
@swcurran well, after running the below commands ```sudo usermod -aG docker $(whoami) sudo systemctl restart docker``` i did `sudo docker-compose down` it stopped all the services. But then after running `sudo ./manage up` it started saying port is already in use So, to double check it `sudo netstat -tulpn | grep LISTEN` and killed all the process. Now if i try to start bby using `sudo ./manage up`. Its not starting at all. kindly look at below logs

Raja_Sabarish (Thu, 25 Apr 2019 04:51:48 GMT):
@swcurran well, after running the below commands ```sudo usermod -aG docker $(whoami) sudo systemctl restart docker``` i did `sudo docker-compose down` it stopped all the services. But then after running `sudo ./manage up` it started saying port is already in use So, to double check it `sudo netstat -tulpn | grep LISTEN` and killed all the process. Now if i try to start by using `sudo ./manage up`. Its not starting at all. kindly look at below logs

Raja_Sabarish (Thu, 25 Apr 2019 04:56:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=kQowBLbqN6ySjvTnz) @swcurran Yes I used `sudo`

Raja_Sabarish (Thu, 25 Apr 2019 04:56:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=kQowBLbqN6ySjvTnz) @swcurran Yes I used `sudo`. BUt i dont know whats going wrong.

Raja_Sabarish (Thu, 25 Apr 2019 04:56:00 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=kQowBLbqN6ySjvTnz) @swcurran Yes I used `sudo`. But i dont know whats going wrong.

AdityaSanthanam (Thu, 25 Apr 2019 05:52:50 GMT):
Has joined the channel.

Raja_Sabarish (Thu, 25 Apr 2019 10:54:04 GMT):

error_log.PNG

swcurran (Thu, 25 Apr 2019 14:00:26 GMT):
@Raja_Sabarish - the command `sudo usermod -aG docker $(whoami)` allows you to use docker without the need to use sudo - it puts your user into the docker group. So if you run that, you should not be using sudo at all.

Raja_Sabarish (Thu, 25 Apr 2019 14:04:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=G99dy4xfrToGNHvKs) @swcurran :thumbsup:

vsadriano (Thu, 25 Apr 2019 16:43:44 GMT):
Hi guys! I applied all settings to add a new node (Node5) on my pool and it's all right. But new node is `Unreachable` now. From logs I'm getting: ```shell # From Node5 - new node 2019-04-25 16:31:30,509|NOTIFICATION|node.py|Node5 primary has been disconnected for too long 2019-04-25 16:31:30,509|INFO|node.py|Node5 The node is not ready yet so view change will not be proposed now, but re-scheduled. 2019-04-25 16:31:30,510|INFO|node.py|Node5 scheduling a view change in 60 sec 2019-04-25 16:31:41,366|WARNING|batched.py|CONNECTION: Node5 has removed rid Fsp2dyt7D2B4GA53hKnEmLym5Y75ExGFz2ZBzcQMNKsB 2019-04-25 16:31:41,411|WARNING|batched.py|CONNECTION: Node5 has removed rid 6KTs7Q9Lng5uX6oWCkVifiJ6hSpkdHiRijAsXtAunnGN 2019-04-25 16:31:41,528|WARNING|batched.py|CONNECTION: Node5 has removed rid ECUd5UfoYa2yUBkmxNkMbkfGKcZ8Voh5Mi3JzBwWEDpm ... ``` ```shell # From others 2019-04-25 16:28:35,011|INFO|replica.py|Ledger 1 is not updated for 301 seconds, so its freshness state is going to be updated now 2019-04-25 16:28:35,044|WARNING|zstack.py|Remote Node5 is not connected - message will not be sent immediately.If this problem does not resolve itself - check your firewall settings 2019-04-25 16:28:35,246|WARNING|zstack.py|Remote Node5 is not connected - message will not be sent immediately.If this problem does not resolve itself - check your firewall settings ``` ```shell # Connection test results $ telnet 173.17.0.105 9709 Trying 173.17.0.105... Connected to 173.17.0.105. $ telnet 173.17.0.105 9710 Trying 173.17.0.105... Connected to 173.17.0.105. ``` Any idea?

vsadriano (Thu, 25 Apr 2019 16:43:44 GMT):
Hi guys! I applied all settings to add a new node (Node5) on my pool and it's all right. But new node is `Unreachable` now. I'm getting: ```shell # From Node5 - new node 2019-04-25 16:31:30,509|NOTIFICATION|node.py|Node5 primary has been disconnected for too long 2019-04-25 16:31:30,509|INFO|node.py|Node5 The node is not ready yet so view change will not be proposed now, but re-scheduled. 2019-04-25 16:31:30,510|INFO|node.py|Node5 scheduling a view change in 60 sec 2019-04-25 16:31:41,366|WARNING|batched.py|CONNECTION: Node5 has removed rid Fsp2dyt7D2B4GA53hKnEmLym5Y75ExGFz2ZBzcQMNKsB 2019-04-25 16:31:41,411|WARNING|batched.py|CONNECTION: Node5 has removed rid 6KTs7Q9Lng5uX6oWCkVifiJ6hSpkdHiRijAsXtAunnGN 2019-04-25 16:31:41,528|WARNING|batched.py|CONNECTION: Node5 has removed rid ECUd5UfoYa2yUBkmxNkMbkfGKcZ8Voh5Mi3JzBwWEDpm ... ``` ```shell # From others 2019-04-25 16:28:35,011|INFO|replica.py|Ledger 1 is not updated for 301 seconds, so its freshness state is going to be updated now 2019-04-25 16:28:35,044|WARNING|zstack.py|Remote Node5 is not connected - message will not be sent immediately.If this problem does not resolve itself - check your firewall settings 2019-04-25 16:28:35,246|WARNING|zstack.py|Remote Node5 is not connected - message will not be sent immediately.If this problem does not resolve itself - check your firewall settings ``` ```shell # Connection test results $ telnet 173.17.0.105 9709 Trying 173.17.0.105... Connected to 173.17.0.105. $ telnet 173.17.0.105 9710 Trying 173.17.0.105... Connected to 173.17.0.105. ``` Any idea?

vsadriano (Thu, 25 Apr 2019 16:50:06 GMT):
Ah! All containers are in same network. There's no firewalls.

mgbailey (Fri, 26 Apr 2019 13:50:01 GMT):
@vsadriano on one of your existing validators, run "sudo read_ledger --type pool" and post the result here.

vsadriano (Fri, 26 Apr 2019 13:59:26 GMT):
@mgbailey ```json [1, { "reqSignature": {}, "txn": { "data": { "data": { "alias": "Node1", "blskey": "4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba", "blskey_pop": "RahHYiCvoNCtPTrVtP7nMC5eTYrsUA8WjXbdhNc8debh1agE9bGiJxWBXYNFbnJXoXhWFMvyqhqhRoq737YQemH5ik9oL7R4NTTCz2LEZhkgLJzB3QRQqJyBNyv7acbdHrAT8nQ9UkLbaVL9NBpnWXBTw4LEMePaSHEw66RzPNdAX1", "client_ip": "173.17.0.101", "client_port": 9702, "node_ip": "173.17.0.101", "node_port": 9701, "services": ["VALIDATOR"] }, "dest": "Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv" }, "metadata": { "from": "Th7MpTaRZVRYnPiabds81Y" }, "type": "0" }, "txnMetadata": { "seqNo": 1, "txnId": "fea82e10e894419fe2bea7d96296a6d46f50f93f9eeda954ec461b2ed2950b62" }, "ver": "1" }] [2, { "reqSignature": {}, "txn": { "data": { "data": { "alias": "Node2", "blskey": "37rAPpXVoxzKhz7d9gkUe52XuXryuLXoM6P6LbWDB7LSbG62Lsb33sfG7zqS8TK1MXwuCHj1FKNzVpsnafmqLG1vXN88rt38mNFs9TENzm4QHdBzsvCuoBnPH7rpYYDo9DZNJePaDvRvqJKByCabubJz3XXKbEeshzpz4Ma5QYpJqjk", "blskey_pop": "Qr658mWZ2YC8JXGXwMDQTzuZCWF7NK9EwxphGmcBvCh6ybUuLxbG65nsX4JvD4SPNtkJ2w9ug1yLTj6fgmuDg41TgECXjLCij3RMsV8CwewBVgVN67wsA45DFWvqvLtu4rjNnE9JbdFTc1Z4WCPA3Xan44K1HoHAq9EVeaRYs8zoF5", "client_ip": "173.17.0.102", "client_port": 9704, "node_ip": "173.17.0.102", "node_port": 9703, "services": ["VALIDATOR"] }, "dest": "8ECVSk179mjsjKRLWiQtssMLgp6EPhWXtaYyStWPSGAb" }, "metadata": { "from": "EbP4aYNeTHL6q385GuVpRV" }, "type": "0" }, "txnMetadata": { "seqNo": 2, "txnId": "1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc" }, "ver": "1" }] [3, { "reqSignature": {}, "txn": { "data": { "data": { "alias": "Node3", "blskey": "3WFpdbg7C5cnLYZwFZevJqhubkFALBfCBBok15GdrKMUhUjGsk3jV6QKj6MZgEubF7oqCafxNdkm7eswgA4sdKTRc82tLGzZBd6vNqU8dupzup6uYUf32KTHTPQbuUM8Yk4QFXjEf2Usu2TJcNkdgpyeUSX42u5LqdDDpNSWUK5deC5", "blskey_pop": "QwDeb2CkNSx6r8QC8vGQK3GRv7Yndn84TGNijX8YXHPiagXajyfTjoR87rXUu4G4QLk2cF8NNyqWiYMus1623dELWwx57rLCFqGh7N4ZRbGDRP4fnVcaKg1BcUxQ866Ven4gw8y4N56S5HzxXNBZtLYmhGHvDtk6PFkFwCvxYrNYjh", "client_ip": "173.17.0.103", "client_port": 9706, "node_ip": "173.17.0.103", "node_port": 9705, "services": ["VALIDATOR"] }, "dest": "DKVxG2fXXTU8yT5N7hGEbXB3dfdAnYv1JczDUHpmDxya" }, "metadata": { "from": "4cU41vWW82ArfxJxHkzXPG" }, "type": "0" }, "txnMetadata": { "seqNo": 3, "txnId": "7e9f355dffa78ed24668f0e0e369fd8c224076571c51e2ea8be5f26479edebe4" }, "ver": "1" }] [4, { "reqSignature": {}, "txn": { "data": { "data": { "alias": "Node4", "blskey": "2zN3bHM1m4rLz54MJHYSwvqzPchYp8jkHswveCLAEJVcX6Mm1wHQD1SkPYMzUDTZvWvhuE6VNAkK3KxVeEmsanSmvjVkReDeBEMxeDaayjcZjFGPydyey1qxBHmTvAnBKoPydvuTAqx5f7YNNRAdeLmUi99gERUU7TD8KfAa6MpQ9bw", "blskey_pop": "RPLagxaR5xdimFzwmzYnz4ZhWtYQEj8iR5ZU53T2gitPCyCHQneUn2Huc4oeLd2B2HzkGnjAff4hWTJT6C7qHYB1Mv2wU5iHHGFWkhnTX9WsEAbunJCV2qcaXScKj4tTfvdDKfLiVuU2av6hbsMztirRze7LvYBkRHV3tGwyCptsrP", "client_ip": "173.17.0.104", "client_port": 9708, "node_ip": "173.17.0.104", "node_port": 9707, "services": ["VALIDATOR"] }, "dest": "4PS3EDQ3dW1tci1Bp6543CfuuebjFrg36kLAUcskGfaA" }, "metadata": { "from": "TWwCRQRZ2ZHMJFn9TzLp7W" }, "type": "0" }, "txnMetadata": { "seqNo": 4, "txnId": "aa5e817d7cc626170eca175822029339a444eb0ee8f0bd20d3b0b76e566fb008" }, "ver": "1" }] [5, { "reqSignature": { "type": "ED25519", "values": [{ "from": "92PMXtzRGuTAhAK5xPbwqq", "value": "6Khnym7NkwttS6dSEzJQ8e8gey58v92bhPBFfKNtamWeU2b8ukLpU1Yoyfs5CPTwDw9WGe29cytEZr9NUkMJxAw" }] }, "txn": { "data": { "data": { "alias": "Node5", "blskey": "2JSLkTGhnG3ZzGoeuZufc7V1kF5wxHqTuSUbaudhwRJzsGZupNHs5igohLnsdcYG7kFj1JGC5aV2JuiJtDtHPKBeGw24ZmBJ44YYaqfCMi5ywNyP42aSjMkvjtHrGS7oVoFbP4aG4aRaKZL3UZbbGcnGTK5kfacmBNKdPSQDyXGCoxB", "blskey_pop": "QkfRaLjoiQRyY5bmsJYRiDSvUrkVTHr671vTodMKTKTfKeVuawPLhGXk2few4bo5ZMC1LFMfHhaiMfJYPTzzJbdnWuZeucWcZjgcjAcBfg5GXSNUp2swExjju359MJLb1zQMoo2yFH3VCCkgtohHA1y5AbxAmzer4Rai2ndVHtyKoV", "client_ip": "173.17.0.105", "client_port": 9710, "node_ip": "173.17.0.105", "node_port": 9709, "services": ["VALIDATOR"] }, "dest": "4SWokCJWJc69Tn74VvLS6t2G2ucvXqM9FDMsWJjmsUxe" }, "metadata": { "digest": "ca1edde87d9cbaf20571fec3b5ceee0b7e221b0eb15964009af8a34c6b9a58b3", "from": "92PMXtzRGuTAhAK5xPbwqq", "payloadDigest": "f05205993f549a111b1e976043ca1a25269e9e7ed896ad4a71d39e6f06b037a7", "reqId": 1556208224229916374 }, "protocolVersion": 2, "type": "0" }, "txnMetadata": { "seqNo": 5, "txnTime": 1556208226 }, "ver": "1" }] ```

mgbailey (Fri, 26 Apr 2019 14:02:02 GMT):
That looks ok, at first glance. @vsadriano try running "sudo validator-info" on node5

mgbailey (Fri, 26 Apr 2019 14:03:25 GMT):
we'll compare the data it returns to what is written to the ledger (above)

vsadriano (Fri, 26 Apr 2019 14:04:11 GMT):
BLS key is unknown. ```shell Validator Node5 is in unknown state Update time: Friday, April 26, 2019 2:01:43 PM +0000 Validator DID: 4SWokCJWJc69Tn74VvLS6t2G2ucvXqM9FDMsWJjmsUxe Verification Key: 68a39yveJUn39PYLSY4fkDMcqKwL9zKoEKodr641qUK7HpyoyWu6Ayt BLS Key: unknown Node HA: 173.17.0.105:9709 Client HA: 173.17.0.105:9710 Metrics: Uptime: 20 hours, 55 minutes, 32 seconds Total ledger Transactions: 0 Total audit Transactions: 0 Total pool Transactions: 0 Total config Transactions: 0 Read Transactions/Seconds: 0.00 Write Transactions/Seconds: 0.00 Reachable Hosts: 1/1 Node5 Unreachable Hosts: 0/1 Software Versions: indy-node: 1.7.0.dev908 sovrin: unknown ```

mgbailey (Fri, 26 Apr 2019 14:05:21 GMT):
yeah, that is a problem. Did you run init_indy_node on this new validator?

mgbailey (Fri, 26 Apr 2019 14:07:09 GMT):
Is this the same version of indy-node as your other nodes? 1.7 is pretty old...

vsadriano (Fri, 26 Apr 2019 14:07:28 GMT):
Yeah! As you can see on: ```json Node-stack name is Node5 Client-stack name is Node5C Generating keys for provided seed 000000000000000000000000000Node5 Init local keys for client-stack Public key is 3ouukk4hSmumojipxgoofs5JPZkASHWTrtJG5wfDPJQ7 Verification key is 4SWokCJWJc69Tn74VvLS6t2G2ucvXqM9FDMsWJjmsUxe Init local keys for node-stack Public key is 3ouukk4hSmumojipxgoofs5JPZkASHWTrtJG5wfDPJQ7 Verification key is 4SWokCJWJc69Tn74VvLS6t2G2ucvXqM9FDMsWJjmsUxe BLS Public key is 2JSLkTGhnG3ZzGoeuZufc7V1kF5wxHqTuSUbaudhwRJzsGZupNHs5igohLnsdcYG7kFj1JGC5aV2JuiJtDtHPKBeGw24ZmBJ44YYaqfCMi5ywNyP42aSjMkvjtHrGS7oVoFbP4aG4aRaKZL3UZbbGcnGTK5kfacmBNKdPSQDyXGCoxB Proof of possession for BLS key is QkfRaLjoiQRyY5bmsJYRiDSvUrkVTHr671vTodMKTKTfKeVuawPLhGXk2few4bo5ZMC1LFMfHhaiMfJYPTzzJbdnWuZeucWcZjgcjAcBfg5GXSNUp2swExjju359MJLb1zQMoo2yFH3VCCkgtohHA1y5AbxAmzer4Rai2ndVHtyKoV Node-stack name is Node5 Client-stack name is Node5C Generating keys for provided seed 000000000000000000000000000Node5 Init local keys for client-stack Public key is 3ouukk4hSmumojipxgoofs5JPZkASHWTrtJG5wfDPJQ7 Verification key is 4SWokCJWJc69Tn74VvLS6t2G2ucvXqM9FDMsWJjmsUxe Init local keys for node-stack Public key is 3ouukk4hSmumojipxgoofs5JPZkASHWTrtJG5wfDPJQ7 Verification key is 4SWokCJWJc69Tn74VvLS6t2G2ucvXqM9FDMsWJjmsUxe BLS Public key is 2JSLkTGhnG3ZzGoeuZufc7V1kF5wxHqTuSUbaudhwRJzsGZupNHs5igohLnsdcYG7kFj1JGC5aV2JuiJtDtHPKBeGw24ZmBJ44YYaqfCMi5ywNyP42aSjMkvjtHrGS7oVoFbP4aG4aRaKZL3UZbbGcnGTK5kfacmBNKdPSQDyXGCoxB Proof of possession for BLS key is QkfRaLjoiQRyY5bmsJYRiDSvUrkVTHr671vTodMKTKTfKeVuawPLhGXk2few4bo5ZMC1LFMfHhaiMfJYPTzzJbdnWuZeucWcZjgcjAcBfg5GXSNUp2swExjju359MJLb1zQMoo2yFH3VCCkgtohHA1y5AbxAmzer4Rai2ndVHtyKoV ```

vsadriano (Fri, 26 Apr 2019 14:07:28 GMT):
Yeah! As you can see on: ```json Node-stack name is Node5 Client-stack name is Node5C Generating keys for provided seed 000000000000000000000000000Node5 Init local keys for client-stack Public key is 3ouukk4hSmumojipxgoofs5JPZkASHWTrtJG5wfDPJQ7 Verification key is 4SWokCJWJc69Tn74VvLS6t2G2ucvXqM9FDMsWJjmsUxe Init local keys for node-stack Public key is 3ouukk4hSmumojipxgoofs5JPZkASHWTrtJG5wfDPJQ7 Verification key is 4SWokCJWJc69Tn74VvLS6t2G2ucvXqM9FDMsWJjmsUxe BLS Public key is 2JSLkTGhnG3ZzGoeuZufc7V1kF5wxHqTuSUbaudhwRJzsGZupNHs5igohLnsdcYG7kFj1JGC5aV2JuiJtDtHPKBeGw24ZmBJ44YYaqfCMi5ywNyP42aSjMkvjtHrGS7oVoFbP4aG4aRaKZL3UZbbGcnGTK5kfacmBNKdPSQDyXGCoxB Proof of possession for BLS key is QkfRaLjoiQRyY5bmsJYRiDSvUrkVTHr671vTodMKTKTfKeVuawPLhGXk2few4bo5ZMC1LFMfHhaiMfJYPTzzJbdnWuZeucWcZjgcjAcBfg5GXSNUp2swExjju359MJLb1zQMoo2yFH3VCCkgtohHA1y5AbxAmzer4Rai2ndVHtyKoV ```

vsadriano (Fri, 26 Apr 2019 14:08:06 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=9H7ewcQ8DuwBKfJdN) @mgbailey Yeah!

mgbailey (Fri, 26 Apr 2019 14:09:48 GMT):
No, I am thinking wrong. This is newer than what is in the stable repo, which is 1.6.83. Are you needing something that is not in stable?

vsadriano (Fri, 26 Apr 2019 14:10:19 GMT):
Pretty old? The latest stable version is `1.6.83-stable` ([here](https://github.com/hyperledger/indy-node/releases))

vsadriano (Fri, 26 Apr 2019 14:10:30 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=YtNjPSMdyaLGZ69CC) @mgbailey Ok.

mgbailey (Fri, 26 Apr 2019 14:13:37 GMT):
init_indy_ node should have written the bls keys to a directory in /var/lib/indy/sandbox/keys. validator-info should have picked them up from there.

vsadriano (Fri, 26 Apr 2019 14:18:12 GMT):
```shell $ ls -lh ledger/sandbox/keys/Node5 total 20K drwxr--r-- 2 indy indy 4.0K Apr 25 16:00 bls_keys drwxr-xr-x 2 indy indy 4.0K Apr 25 17:05 private_keys drwxr-xr-x 2 indy indy 4.0K Apr 25 17:05 public_keys drwxr-xr-x 2 indy indy 4.0K Apr 25 17:05 sig_keys drwxr-xr-x 2 indy indy 4.0K Apr 25 17:05 verif_keys ```

vsadriano (Fri, 26 Apr 2019 14:18:12 GMT):
`BLS Keys` are here: ```shell $ ls -lh ledger/sandbox/keys/Node5 total 20K drwxr--r-- 2 indy indy 4.0K Apr 25 16:00 bls_keys drwxr-xr-x 2 indy indy 4.0K Apr 25 17:05 private_keys drwxr-xr-x 2 indy indy 4.0K Apr 25 17:05 public_keys drwxr-xr-x 2 indy indy 4.0K Apr 25 17:05 sig_keys drwxr-xr-x 2 indy indy 4.0K Apr 25 17:05 verif_keys ```

mgbailey (Fri, 26 Apr 2019 14:19:28 GMT):
Hm. Maybe validator-info has a problem in this version? does validator-info work correctly in your other nodes?

vsadriano (Fri, 26 Apr 2019 14:19:28 GMT):
My setting parameter: ```python NETWORK_NAME = 'sandbox' LEDGER_DIR = '/home/indy/ledger' LOG_DIR = '/home/indy/log' KEYS_DIR = LEDGER_DIR GENESIS_DIR = LEDGER_DIR BACKUP_DIR = '/home/indy/backup' PLUGINS_DIR = '/home/indy/plugins' NODE_INFO_DIR = LEDGER_DIR ```

vsadriano (Fri, 26 Apr 2019 14:20:28 GMT):
Node1: ```shell Validator Node1 is in unknown state Update time: Friday, April 26, 2019 2:19:14 PM +0000 Validator DID: Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv Verification Key: 33nHHYKnqmtGAVfZZGoP8hpeExeH45Fo8cKmd5mcnKYk7XgWNBxkkKJ BLS Key: 4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba Node HA: 0.0.0.0:9701 Client HA: 0.0.0.0:9702 Metrics: Uptime: 59 minutes, 3 seconds Total ledger Transactions: 6 Total config Transactions: 0 Total pool Transactions: 5 Total audit Transactions: 803 Read Transactions/Seconds: 0.00 Write Transactions/Seconds: 0.00 Reachable Hosts: 4/5 Node2 (1) Node1 (0) Node4 Node3 Unreachable Hosts: 1/5 Node5 Software Versions: indy-node: 1.7.0.dev908 sovrin: unknown ```

mgbailey (Fri, 26 Apr 2019 14:20:48 GMT):
ok, so that looks correct

vsadriano (Fri, 26 Apr 2019 14:21:28 GMT):
All containers use the same image...

mgbailey (Fri, 26 Apr 2019 14:22:37 GMT):
on node5, what is the output of ifconfig? I want to make sure that your node is configured for addresses that are internally recognized.

mgbailey (Fri, 26 Apr 2019 14:26:37 GMT):
indy-node on your other nodes is binding to a wild-card: 0.0.0.0. That is why I ask

vsadriano (Fri, 26 Apr 2019 14:28:04 GMT):
```shell $ docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' indynode_node5_1 173.17.0.105 ```

vsadriano (Fri, 26 Apr 2019 14:29:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=2Xq9eLoaqCQ3jJko2) @mgbailey I'll alter generation script and return.

vsadriano (Fri, 26 Apr 2019 16:02:35 GMT):
@mgbailey I updated generation script and network. I don't understand why `bls key` is not in `Node5` validation info: ```shell $ init_indy_node Node5 173.17.0.105 9709 173.17.0.105 9710 000000000000000000000000000Node5 Node-stack name is Node5 Client-stack name is Node5C Generating keys for provided seed 000000000000000000000000000Node5 Init local keys for client-stack Public key is 3ouukk4hSmumojipxgoofs5JPZkASHWTrtJG5wfDPJQ7 Verification key is 4SWokCJWJc69Tn74VvLS6t2G2ucvXqM9FDMsWJjmsUxe Init local keys for node-stack Public key is 3ouukk4hSmumojipxgoofs5JPZkASHWTrtJG5wfDPJQ7 Verification key is 4SWokCJWJc69Tn74VvLS6t2G2ucvXqM9FDMsWJjmsUxe BLS Public key is 2JSLkTGhnG3ZzGoeuZufc7V1kF5wxHqTuSUbaudhwRJzsGZupNHs5igohLnsdcYG7kFj1JGC5aV2JuiJtDtHPKBeGw24ZmBJ44YYaqfCMi5ywNyP42aSjMkvjtHrGS7oVoFbP4aG4aRaKZL3UZbbGcnGTK5kfacmBNKdPSQDyXGCoxB Proof of possession for BLS key is QkfRaLjoiQRyY5bmsJYRiDSvUrkVTHr671vTodMKTKTfKeVuawPLhGXk2few4bo5ZMC1LFMfHhaiMfJYPTzzJbdnWuZeucWcZjgcjAcBfg5GXSNUp2swExjju359MJLb1zQMoo2yFH3VCCkgtohHA1y5AbxAmzer4Rai2ndVHtyKoV $ validator-info Validator Node5 is in unknown state Update time: Friday, April 26, 2019 4:01:21 PM +0000 Validator DID: 4SWokCJWJc69Tn74VvLS6t2G2ucvXqM9FDMsWJjmsUxe Verification Key: 68a39yveJUn39PYLSY4fkDMcqKwL9zKoEKodr641qUK7HpyoyWu6Ayt BLS Key: unknown Node HA: 173.17.0.105:9709 Client HA: 173.17.0.105:9710 Metrics: Uptime: 10 minutes, 1 second Total ledger Transactions: 0 Total pool Transactions: 0 Total audit Transactions: 0 Total config Transactions: 0 Read Transactions/Seconds: 0.00 Write Transactions/Seconds: 0.00 Reachable Hosts: 1/1 Node5 Unreachable Hosts: 0/1 Software Versions: indy-node: 1.7.0.dev912 sovrin: unknown ``` Any idea?

vsadriano (Fri, 26 Apr 2019 16:02:35 GMT):
@mgbailey I updated generation script and network. I don't understand why `bls key` is not in `Node5` (validation info): ```shell $ init_indy_node Node5 173.17.0.105 9709 173.17.0.105 9710 000000000000000000000000000Node5 Node-stack name is Node5 Client-stack name is Node5C Generating keys for provided seed 000000000000000000000000000Node5 Init local keys for client-stack Public key is 3ouukk4hSmumojipxgoofs5JPZkASHWTrtJG5wfDPJQ7 Verification key is 4SWokCJWJc69Tn74VvLS6t2G2ucvXqM9FDMsWJjmsUxe Init local keys for node-stack Public key is 3ouukk4hSmumojipxgoofs5JPZkASHWTrtJG5wfDPJQ7 Verification key is 4SWokCJWJc69Tn74VvLS6t2G2ucvXqM9FDMsWJjmsUxe BLS Public key is 2JSLkTGhnG3ZzGoeuZufc7V1kF5wxHqTuSUbaudhwRJzsGZupNHs5igohLnsdcYG7kFj1JGC5aV2JuiJtDtHPKBeGw24ZmBJ44YYaqfCMi5ywNyP42aSjMkvjtHrGS7oVoFbP4aG4aRaKZL3UZbbGcnGTK5kfacmBNKdPSQDyXGCoxB Proof of possession for BLS key is QkfRaLjoiQRyY5bmsJYRiDSvUrkVTHr671vTodMKTKTfKeVuawPLhGXk2few4bo5ZMC1LFMfHhaiMfJYPTzzJbdnWuZeucWcZjgcjAcBfg5GXSNUp2swExjju359MJLb1zQMoo2yFH3VCCkgtohHA1y5AbxAmzer4Rai2ndVHtyKoV $ validator-info Validator Node5 is in unknown state Update time: Friday, April 26, 2019 4:01:21 PM +0000 Validator DID: 4SWokCJWJc69Tn74VvLS6t2G2ucvXqM9FDMsWJjmsUxe Verification Key: 68a39yveJUn39PYLSY4fkDMcqKwL9zKoEKodr641qUK7HpyoyWu6Ayt BLS Key: unknown Node HA: 173.17.0.105:9709 Client HA: 173.17.0.105:9710 Metrics: Uptime: 10 minutes, 1 second Total ledger Transactions: 0 Total pool Transactions: 0 Total audit Transactions: 0 Total config Transactions: 0 Read Transactions/Seconds: 0.00 Write Transactions/Seconds: 0.00 Reachable Hosts: 1/1 Node5 Unreachable Hosts: 0/1 Software Versions: indy-node: 1.7.0.dev912 sovrin: unknown ``` Any idea?

mgbailey (Fri, 26 Apr 2019 16:53:45 GMT):
@vsadriano It is curious why it in not showing up in validator-info. Take a look in ledger/sandbox/keys/Node5/bls_keys/bls_pk. Does it match what you got from init_indy_node for the bls key? it should. Is the path to this file the same as on the other nodes (with a different node name)? In a VM, another log that I would look in for clues is "sudo journalctl -u indy-node". You might see if there is anything of interest in the docker equivalent.

mgbailey (Fri, 26 Apr 2019 16:56:25 GMT):
You might also try using 0.0.0.0 instead of the actual IP address when launching, since that is a difference between node5 and the other nodes.

vsadriano (Fri, 26 Apr 2019 17:07:15 GMT):
@mgbailey `bls_pk` value in file and `BLS Public key` (`init_indy_node` result) are equals. I set up IP 173.17.0.3.X for all nodes and network communication test is ok.

vsadriano (Fri, 26 Apr 2019 17:07:50 GMT):
```shell $ cat ledger/sandbox/keys/Node5/bls_keys/bls_pk 2JSLkTGhnG3ZzGoeuZufc7V1kF5wxHqTuSUbaudhwRJzsGZupNHs5igohLnsdcYG7kFj1JGC5aV2JuiJtDtHPKBeGw24ZmBJ44YYaqfCMi5ywNyP42aSjMkvjtHrGS7oVoFbP4aG4aRaKZL3UZbbGcnGTK5kfacmBNKdPSQDyXGCoxB ```

mgbailey (Fri, 26 Apr 2019 17:08:55 GMT):
And the path to the bls_pk file is the same on node5 and on the other nodes?

vsadriano (Fri, 26 Apr 2019 17:10:13 GMT):
Yeah! It's the same config file.

mgbailey (Fri, 26 Apr 2019 17:11:26 GMT):
I'm running out of ideas, sorry. It seems like it is not finding the bls_pk file, but I don't know why

vsadriano (Fri, 26 Apr 2019 17:13:19 GMT):
I don't understand why `bls key` is `unknown` on `validator-info` results - only Node5. All containers are build with same image.

vsadriano (Fri, 26 Apr 2019 17:13:19 GMT):
I don't understand why `bls key` is `unknown` on `validator-info` results - only Node5.

ashcherbakov (Mon, 29 Apr 2019 07:29:15 GMT):
@vsadriano BLS key is get from the Pool ledger (` "sudo read_ledger --type pool"`). It looks like Node5 can not connect to other nodes in the Pool, so it can not catch-up its own transaction from other Nodes (in order to prove it, you can run ` "sudo read_ledger --type pool"` on Node5 and see if Node5's txn (with seqNo=5) is there). So, Node5 can not get the BLS key for Node5, since it doesn't have a txn about itself in its Pool Ledger. That means that the original issue is that Node 5 can not connect to other nodes. Maybe a firewall issue?

raj_shekhar (Mon, 29 Apr 2019 08:05:03 GMT):
Has joined the channel.

george.aristy (Tue, 30 Apr 2019 21:16:07 GMT):
Has joined the channel.

vsadriano (Thu, 02 May 2019 12:06:13 GMT):
@ashcherbakov I agree. Node5 isn't connecting to other nodes but I don't firewall and all containers are in same network. See this: ```shell # Telnet Tests # From Node1 To Node5 $ telnet 173.17.0.105 9709 Trying 173.17.0.105... Connected to 173.17.0.105. $ telnet 173.17.0.105 9710 Trying 173.17.0.105... Connected to 173.17.0.105. # From Node5 To Node1 $ telnet 173.17.0.101 9701 Trying 173.17.0.101... Connected to 173.17.0.101. $ telnet 173.17.0.101 9701 Trying 173.17.0.101... Connected to 173.17.0.101. ```

vsadriano (Thu, 02 May 2019 12:06:13 GMT):
@ashcherbakov I agree. Node5 isn't connecting to other nodes but I don't firewall and all containers are in same network. See this: ```shell # A single telnet testes between Node1 and Node5 (i.e) # From Node1 To Node5 $ telnet 173.17.0.105 9709 Trying 173.17.0.105... Connected to 173.17.0.105. $ telnet 173.17.0.105 9710 Trying 173.17.0.105... Connected to 173.17.0.105. # From Node5 To Node1 $ telnet 173.17.0.101 9701 Trying 173.17.0.101... Connected to 173.17.0.101. $ telnet 173.17.0.101 9701 Trying 173.17.0.101... Connected to 173.17.0.101. ```

vsadriano (Thu, 02 May 2019 12:06:13 GMT):
@ashcherbakov I agree. Node5 isn't connecting to other nodes but I don't firewall and all containers are in same network. See this: ```shell # A single telnet test between Node1 and Node5 (i.e) # From Node1 To Node5 $ telnet 173.17.0.105 9709 Trying 173.17.0.105... Connected to 173.17.0.105. $ telnet 173.17.0.105 9710 Trying 173.17.0.105... Connected to 173.17.0.105. # From Node5 To Node1 $ telnet 173.17.0.101 9701 Trying 173.17.0.101... Connected to 173.17.0.101. $ telnet 173.17.0.101 9701 Trying 173.17.0.101... Connected to 173.17.0.101. ```

vsadriano (Thu, 02 May 2019 12:08:28 GMT):
As you can see, there is conectivity between nodes.

vsadriano (Thu, 02 May 2019 12:10:36 GMT):
I thought that `bls keys` were generated when I ran `init_indy_node ...`.

vsadriano (Thu, 02 May 2019 12:26:11 GMT):
And I get this on Node5 init log: ```shell Node-stack name is Node5 Client-stack name is Node5C Generating keys for provided seed 000000000000000000000000000Node5 Init local keys for client-stack Public key is 3ouukk4hSmumojipxgoofs5JPZkASHWTrtJG5wfDPJQ7 Verification key is 4SWokCJWJc69Tn74VvLS6t2G2ucvXqM9FDMsWJjmsUxe Init local keys for node-stack Public key is 3ouukk4hSmumojipxgoofs5JPZkASHWTrtJG5wfDPJQ7 Verification key is 4SWokCJWJc69Tn74VvLS6t2G2ucvXqM9FDMsWJjmsUxe BLS Public key is 2JSLkTGhnG3ZzGoeuZufc7V1kF5wxHqTuSUbaudhwRJzsGZupNHs5igohLnsdcYG7kFj1JGC5aV2JuiJtDtHPKBeGw24ZmBJ44YYaqfCMi5ywNyP42aSjMkvjtHrGS7oVoFbP4aG4aRaKZL3UZbbGcnGTK5kfacmBNKdPSQDyXGCoxB Proof of possession for BLS key is QkfRaLjoiQRyY5bmsJYRiDSvUrkVTHr671vTodMKTKTfKeVuawPLhGXk2few4bo5ZMC1LFMfHhaiMfJYPTzzJbdnWuZeucWcZjgcjAcBfg5GXSNUp2swExjju359MJLb1zQMoo2yFH3VCCkgtohHA1y5AbxAmzer4Rai2ndVHtyKoV ``` I don't have idea what's going on.

vsadriano (Thu, 02 May 2019 14:11:32 GMT):
I saw a small difference between nodes' data on ledger. From Node1 (and others): ```json ... "metadata": { "from": "EbP4aYNeTHL6q385GuVpRV" }, "type": "0" }, "txnMetadata": { "seqNo": 2, "txnId": "1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc" }, ... ``` From Node5: ```json ... "metadata": { "digest": "c77bb6ca1d3c581a00b6b1a008de4c57b8746559bc1bc9660f2c2f3885d0a2a1", "from": "92PMXtzRGuTAhAK5xPbwqq", "reqId": 1556797936211765738 }, "protocolVersion": 2, "type": "0" }, "txnMetadata": { "seqNo": 5, "txnTime": 1556797939 }, ... ```

vsadriano (Thu, 02 May 2019 14:11:32 GMT):
I saw a small difference between nodes on pool data. From Node1 (and others): ```json ... "metadata": { "from": "EbP4aYNeTHL6q385GuVpRV" }, "type": "0" }, "txnMetadata": { "seqNo": 2, "txnId": "1ac8aece2a18ced660fef8694b61aac3af08ba875ce3026a160acbc3a3af35fc" }, ... ``` From Node5: ```json ... "metadata": { "digest": "c77bb6ca1d3c581a00b6b1a008de4c57b8746559bc1bc9660f2c2f3885d0a2a1", "from": "92PMXtzRGuTAhAK5xPbwqq", "reqId": 1556797936211765738 }, "protocolVersion": 2, "type": "0" }, "txnMetadata": { "seqNo": 5, "txnTime": 1556797939 }, ... ```

vsadriano (Thu, 02 May 2019 18:54:28 GMT):
Hi guys! Is there any doc about build a private network?

jljordan_bcgov (Thu, 02 May 2019 20:44:16 GMT):
This might help ... https://github.com/bcgov/von-network @vsadriano [ ](https://chat.hyperledger.org/channel/indy-node?msg=fEXPad8vngvkHfFNY)

jljordan_bcgov (Thu, 02 May 2019 20:44:30 GMT):
If you mean for development work and such

ashlinSajan (Fri, 03 May 2019 08:34:29 GMT):
Hi @mgbailey I am getting poolLedgerTimeout issue while creating the pool.Can any one help me on this

vsadriano (Fri, 03 May 2019 10:18:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=tjXpadwK23KiEnnsE) @ashlinSajan Did you run any connection test between nodes?

ashlinSajan (Fri, 03 May 2019 10:20:05 GMT):
@vsadriano I am trying to run gettingStarted.js

vsadriano (Fri, 03 May 2019 10:35:23 GMT):
@jljordan_bcgov is good for setup a static network but I would like to understand the network build process. What's network build flow? How entities (Trustee and Stewards) are created?

vsadriano (Fri, 03 May 2019 10:35:23 GMT):
@jljordan_bcgov is good for setup a static network but I would like to understand the network build process. What's network build flow? How entities (Trustee and Stewards) are created? I would like to build a private and "complete network. Is it possible?

esplinr (Fri, 03 May 2019 15:10:15 GMT):
@vsadriano https://github.com/hyperledger/indy-node/blob/master/docs/source/start-nodes.md This video is also useful: https://www.youtube.com/watch?v=WZin717AT_A&list=PLRp0viTDxBWGLdZk0aamtahB9cpJGV7ZF&index=11

iamtxena (Fri, 10 May 2019 07:16:20 GMT):
Has joined the channel.

tadeu_andrade (Thu, 16 May 2019 12:23:24 GMT):
Has joined the channel.

circlespainter (Sat, 18 May 2019 07:43:27 GMT):
Has joined the channel.

ashlinSajan (Mon, 20 May 2019 13:38:34 GMT):
Hi @esplinr how does the link secret help to identify the prover?

esplinr (Mon, 20 May 2019 16:06:31 GMT):
The link secret is used by the prover to sign the proof so that it is clear that the various credentials used to compose the proof came from the same wallet.

ashlinSajan (Tue, 21 May 2019 03:50:59 GMT):
@esplinr how will the receiver identify that the link secret belongs to the particular prover

Unni_1994 (Tue, 21 May 2019 09:20:57 GMT):
Has joined the channel.

esplinr (Tue, 21 May 2019 14:29:50 GMT):
The link secret shows that all the credentials in a proof come from the same wallet. The proof is also signed by the pairwise DID of the prover.

vsadriano (Tue, 21 May 2019 16:26:54 GMT):
HI! I'm trying run `ledger nym did=...` and receiving `Transaction response has not been received`. Can any help me?

vsadriano (Tue, 21 May 2019 16:26:54 GMT):
HI! I'm trying run `ledger nym did=...` from `cli` and receiving `Transaction response has not been received`. Can any help me?

vsadriano (Tue, 21 May 2019 16:29:34 GMT):
Log from my node: ```shell $ tail -f /var/log/indy/sandbox/Node1.log 2019-05-21 16:28:03,195|INFO|node_runner.py|Going to integrate plugin: sovtokenfees 2019-05-21 16:28:03,223|INFO|node_runner.py|Integrated plugin: sovtokenfees 2019-05-21 16:28:03,223|INFO|motor.py|Node1 changing status from stopped to starting 2019-05-21 16:28:03,225|INFO|stacks.py|CONNECTION: Node1 listening for other nodes at 192.168.0.22:9701 2019-05-21 16:28:03,250|INFO|node.py|Node1 first time running... 2019-05-21 16:28:03,250|INFO|node.py|Node1 processed 0 Ordered batches for instance 0 before starting catch up 2019-05-21 16:28:03,250|INFO|node.py|Node1 reverted 0 batches before starting catch up 2019-05-21 16:28:03,250|INFO|node_leecher_service.py|Node1:NodeLeecherService starting catchup (is_initial=True) 2019-05-21 16:28:03,251|INFO|node_leecher_service.py|Node1:NodeLeecherService transitioning from Idle to PreSyncingPool 2019-05-21 16:28:03,251|INFO|cons_proof_service.py|Node1:ConsProofService:0 starts 2019-05-21 16:28:27,841|INFO|seeder_service.py|Node1 received ledger status: LEDGER_STATUS{'viewNo': None, 'txnSeqNo': 1, 'protocolVersion': 2, 'ledgerId': 0, 'ppSeqNo': None, 'merkleRoot': '7uNCADcyTkx91hMkFu8JdybuBkgysL9WXYTx8uU4C39J'} from b'QtEhGR4A^poBMt6[$b$IS?Z2]P1JdB?I]+(MuSJr' 2019-05-21 16:29:03,240|NOTIFICATION|node.py|Node1 primary has been disconnected for too long 2019-05-21 16:29:03,241|INFO|node.py|Node1 The node is not ready yet so view change will not be proposed now, but re-scheduled. 2019-05-21 16:29:03,241|INFO|node.py|Node1 scheduling a view change in 60 sec ```

tadeu_andrade (Tue, 21 May 2019 19:34:19 GMT):
Hello, in the document "Sovrin Steward Validator Preparation Guide" (https://docs.google.com/document/d/1AH618bj4q9U8FS1uyoIgbcvwNzaghBCQ1v44tNpZ2OU), it is said in section 3.5 (Add Node to a Pool) that "a Sovrin Trustee will put your steward public key into the ledger". I'm trying to run a private pool (as @vsadriano said he is trying to do too) and would like to know how this data is added to ledger (like scripts, steps and alike). Can anybody help me?

ilya1w (Wed, 22 May 2019 03:51:55 GMT):
Has joined the channel.

vsadriano (Wed, 22 May 2019 16:12:52 GMT):
Hi guys! How can I verify health status of a specific node?

mgbailey (Wed, 22 May 2019 16:35:55 GMT):
@vsadriano There are 2 cases for this question: 1) You are the steward of the node and have access to the command line: ```$ sudo validator-info --json``` 2) You have a cli client and keys in your wallet for a TRUSTEE, STEWARD, or NETWORK_MONITOR: ```indy> ledger get-validator-info nodes=``` In both cases you will get back json which can be easily parsed.Check for Node_info/Freshness_status (indicates that the node is in consensus), and Pool_info/Unreachable_nodes_count (indicates how many peer validators cannot be connected to), among other things.

mgbailey (Wed, 22 May 2019 16:35:55 GMT):
@vsadriano There are 2 cases for this question: 1) You are the steward of the node and have access to the command line: ```$ sudo validator-info --json``` 2) You have a cli client and keys in your wallet for a TRUSTEE, STEWARD, or NETWORK_MONITOR: ```indy> ledger get-validator-info nodes=``` In both cases you will get back json which can be easily parsed.Check for Node_info/Freshness_status (indicates that the node is in consensus), and Pool_info/Unreachable_nodes_count (indicates how many peer validators cannot be connected to), among other things.

mgbailey (Wed, 22 May 2019 16:35:55 GMT):
@vsadriano There are 2 cases for this question: 1) You are the steward of the node and have access to the command line: ```$ sudo validator-info --json``` 2) You have a cli client and keys in your wallet for a TRUSTEE, STEWARD, or NETWORK_MONITOR: ```indy> ledger get-validator-info nodes=``` In both cases you will get back json which can be easily parsed.Check for Node_info/Freshness_status (indicates that the node is in consensus), and Pool_info/Unreachable_nodes_count (indicates how many peer validators cannot be connected to), among other things.

vsadriano (Wed, 22 May 2019 16:36:51 GMT):
Tks @mgbailey !

cam-parra (Wed, 22 May 2019 22:38:16 GMT):
@ashcherbakov could you remind me why it is ideal to have more than 12 nodes? I know you explained this to me before but I can't remember the details. I remember that you mentioned performance but I know we saw a difference in 4 node testing pools

ashcherbakov (Thu, 23 May 2019 14:11:53 GMT):
The more nodes you have in the pool, the more malicious (faulty) nodes you may have. So, theoretically you may want to have as many nodes as possible. However, PBFT (and especially RBFT protocol that we use) is very "chatty", and it becomes non-linearly slower with increasing number of nodes. So, currently we don't recommend to have more than 25 nodes and do our tests on a pool with 25 nodes. The number of nodes on the pool is recommended to be equal to 3f+1 where f is a number of faulty/malicious nodes. So, for a pool of 25 nodes we may have 8 faulty/malicious nodes. It's recommended to have exactly 3f+1 nodes, because if the number of nodes is 3f+2 or 3f+3, then the number of malicious nodes is still the same, while performance is worse and getting consensus may be harder.

cam-parra (Thu, 23 May 2019 16:35:55 GMT):
Thank you for answering that. I really appreciate you guys taking the time to do so! Have you found 25 nodes to be optimal for speed or just for testing?

esplinr (Thu, 23 May 2019 21:17:41 GMT):
In our testing, 25 nodes seemed to be the sweet spot between security (8 potential faulty nodes) and performance.

esplinr (Thu, 23 May 2019 21:18:15 GMT):
28 nodes would allow 9 faulty nodes, but we saw a drop in performance.

cam-parra (Thu, 23 May 2019 21:20:52 GMT):
Thank you. That helps a ton!

vidhi24 (Fri, 24 May 2019 06:42:31 GMT):
Has joined the channel.

vidhi24 (Fri, 24 May 2019 06:42:37 GMT):
Hi i was trying to setup dev of indy node``` while running code ```

vidhi24 (Fri, 24 May 2019 06:42:37 GMT):
Hi i was trying to setup dev of indy node``` while running command pip install -e .[tests]``` getting error failed building wheel for sha3,orderedset and many more.... please help as soon as possible ``` ```

TelegramSam (Mon, 27 May 2019 16:36:05 GMT):
Has left the channel.

RodrigoMedeiros (Wed, 29 May 2019 17:12:37 GMT):
Has joined the channel.

SeanBohan (Wed, 29 May 2019 17:50:01 GMT):
Has joined the channel.

vidhi24 (Thu, 30 May 2019 04:09:56 GMT):
Hi Guys!, Can someone please help me through commands of indy-cli for using zkp crypto?

mgbailey (Thu, 30 May 2019 13:55:10 GMT):
indy-cli is primarily an administrative tool for ledger transactions. There is no capability in it to do credential or proof exchanges. You will need to write agent code in one of the wrapper languages to do zkp

paliwalg (Fri, 31 May 2019 08:23:16 GMT):
Has joined the channel.

cam-parra (Fri, 31 May 2019 15:07:13 GMT):
@ashcherbakov so I have generated a seed using `pwgen 32 1` . and then i call `init_indy_node` using [--seed ] and I receive an error saying it

cam-parra (Fri, 31 May 2019 15:07:13 GMT):
@ashcherbakov so I have generated a seed using `pwgen 32 1` . and then i call `init_indy_node` using [--seed ] and I receive an error saying it's an invalid seed

cam-parra (Fri, 31 May 2019 15:07:34 GMT):
Do you know why this would happen?

kdenhartog (Fri, 31 May 2019 23:14:36 GMT):
Alternatively, you can use the AgentFramework (C# framework) or IndyCatAgent (Python framework) to get an agent setup quickly.

kdenhartog (Fri, 31 May 2019 23:14:38 GMT):
https://github.com/streetcred-id/agent-framework

kdenhartog (Fri, 31 May 2019 23:14:52 GMT):
https://github.com/bcgov/indy-catalyst

cam-parra (Tue, 04 Jun 2019 02:19:09 GMT):
@ashcherbakov are there any other tool besides `generate_indy_pool_transactions` to generate a genesis transaction?

ibrahimel (Tue, 04 Jun 2019 08:51:49 GMT):
Has joined the channel.

glotov (Tue, 04 Jun 2019 08:55:10 GMT):
Has joined the channel.

glotov (Tue, 04 Jun 2019 09:00:13 GMT):
hi, are indy-sdk/samples/nodejs still supported? I am getting these errors trying to `npm install` it: https://chat.hyperledger.org/channel/indy-sdk?msg=hv843XccT653JB7mR

DougKing (Tue, 04 Jun 2019 14:32:07 GMT):
Has joined the channel.

vsadriano (Wed, 05 Jun 2019 14:29:38 GMT):
Hi! I'm trying to add a new STEWARD and getting the error bellow: ``` Transaction has been rejected: Client request is discarded since view change is in progress ``` What is it?

mgbailey (Wed, 05 Jun 2019 15:44:41 GMT):
It would seem your validator pool is unhealthy. You are probably unable to post _any_ transaction to it.

peacekeeper (Fri, 07 Jun 2019 08:59:31 GMT):
I have a pool of 5 nodes and issued a POOL_UPGRADE to upgrade "sovrin" from 1.1.41 to 1.1.45. 2 of the nodes were successful, the 3 others were stuck with status "in_progress".. any idea?

lreinink (Fri, 07 Jun 2019 11:12:10 GMT):
Has joined the channel.

lreinink (Fri, 07 Jun 2019 11:12:11 GMT):
I have a question about Indy Node. In the Bitcoin network, each node is connected to 8 peers. It can also be configured to allow for more connections. How is this done in Indy Node?

esplinr (Fri, 07 Jun 2019 21:53:45 GMT):
@lreinink I recommend that you ask this at StackOverflow and then link to it here. I can then answer it over there so that it gets indexed by Google.

lreinink (Mon, 10 Jun 2019 18:01:07 GMT):
Allright, https://stackoverflow.com/questions/56531345/how-many-peers-does-an-indy-node-connect-to. Thank you in advance.

esplinr (Tue, 11 Jun 2019 01:07:01 GMT):
I responded. Thanks for asking your question in a place that will hopefully help others!

nhelmy (Wed, 12 Jun 2019 20:12:53 GMT):
Given a DID and a full dump of all the transactions on a network (let's say MAINNET), how does one construct the full DID Document? I understand that you use the DID to look up the associated transactions. My understanding is that the NYM transaction will get the public (verification) key and the ATTRIB transactions will get the other DID document properties, which the resolver uses to dynamically compose the DID document. Here's where I'm stuck. The NYM transaction includes actual public keys--great. However the ATTRIB transaction does not include actual DID Doc data. It only includes hashes. How do I use these hashes to retrieve the actual attributes?

nhelmy (Wed, 12 Jun 2019 20:12:53 GMT):
Given a DID and a full dump of all the transactions on a given Indy network (let's say Sovrin MAINNET), how does one construct the full DID Document? I understand that you use the DID to look up the associated transactions. My understanding is that the NYM transaction will get the public (verification) key and the ATTRIB transactions will get the other DID document properties, which the resolver uses to dynamically compose the DID document. Here's where I'm stuck. The NYM transaction includes actual public keys--great. However the ATTRIB transaction does not include actual DID Doc data. It only includes hashes. How do I use these hashes to retrieve the actual attributes?

nhelmy (Wed, 12 Jun 2019 20:14:06 GMT):
According to developer documentation, there is a value in the ATTRIB transaction called `raw` which is described like so: `Hash of the raw attribute data. Raw data is represented as JSON, where the key is the attribute name and the value is the attribute value. The ledger only stores a hash of the raw data; the real (unhashed) raw data is stored in a separate attribute store.` https://hyperledger-indy.readthedocs.io/projects/node/en/latest/transactions.html#domain-ledger

nhelmy (Wed, 12 Jun 2019 20:14:55 GMT):
The unhashed data is stored in a separate attribute store? Where is this?

ashlinSajan (Thu, 13 Jun 2019 06:32:20 GMT):
What is the kind of mechanism to ensure that credentials used in the proof do not belong to another wallet.

AndrewNikitin (Thu, 13 Jun 2019 09:04:58 GMT):
Has joined the channel.

swcurran (Thu, 13 Jun 2019 14:28:10 GMT):
Someone with deeper knowledge should answer, but based on the data on the Sovrin Mainnet, the data is retrievable: https://sovrin-mainnet-browser.vonx.io/browse/domain?page=1&query=&txn_type=100

swcurran (Thu, 13 Jun 2019 14:29:24 GMT):
That shows that the data value of the attrib can be retrieved. My guess is that the data is not stored on the ledger, but is stored on the node, and is available via ledger api calls.

kdenhartog (Thu, 13 Jun 2019 18:50:04 GMT):
Hmm, this is a good question. On the uniresolver site I see the data is available in the "data" field from the method metadata response. I'm not sure if @peacekeeper is putting this information in himself through his own attrib store or this is being done by the IndySDK and actually goes in the transactions.

swcurran (Thu, 13 Jun 2019 18:51:49 GMT):
It has to be being done by the indy-sdk since we are doing it and we don't have a node. We're just querying the ledger via the API calls.

swcurran (Thu, 13 Jun 2019 18:51:49 GMT):
It has to be being done by the indy-sdk calls since we are doing it and we don't have a node. We're just querying the ledger via the API calls.

kdenhartog (Thu, 13 Jun 2019 18:56:03 GMT):
Gotcha, it looks like in the GET_ATTRIB request there's a "raw" field. Try putting "endpoint" as the value in the request and it should return the raw data. https://github.com/hyperledger/indy-node/blob/master/docs/source/requests.md#get_attrib

FarhanShafiq (Fri, 14 Jun 2019 07:45:15 GMT):
Has joined the channel.

FarhanShafiq (Fri, 14 Jun 2019 07:45:26 GMT):
FarhanShafiq 12:35 PM Hey Guys, I'm new to indy and installing indy through docker setup given by https://github.com/hyperledger/indy-node/blob/master/environment/docker/pool/README.md but facing error: generate_indy_pool_transactions: error: argument --clients: invalid int value: '127.0.0.1:2122,127.0.0.1:2123,127.0.0.1:2124,127.0.0.1:2125'

FarhanShafiq (Fri, 14 Jun 2019 07:45:26 GMT):
Hey Guys, I'm new to indy and installing indy through docker setup given by https://github.com/hyperledger/indy-node/blob/master/environment/docker/pool/README.md but facing error: generate_indy_pool_transactions: error: argument --clients: invalid int value: '127.0.0.1:2122,127.0.0.1:2123,127.0.0.1:2124,127.0.0.1:2125'

BreizhIndy (Fri, 14 Jun 2019 10:30:37 GMT):
Hey huys, how can I measure the performance of my implementation, is there somewhere where I cand find results of test performance ?

AndrewNikitin (Fri, 14 Jun 2019 10:31:49 GMT):
As described in https://github.com/hyperledger/indy-node/blob/master/environment/docker/pool/README.md#start-pool please, try to pass a string "127.0.0.1,127.0.0.1,127.0.0.1,127.0.0.1" as [IP addresses of nodes] and 2122 as [port for the first node] Full command string will be looked like: ./pool_start.sh 4 "127.0.0.1,127.0.0.1,127.0.0.1,127.0.0.1" 4 2122

FarhanShafiq (Fri, 14 Jun 2019 10:34:32 GMT):
Thanks, I did as you said but nodes still working on 10.0.0.1-4. Node node4 started on 10.0.0.5

FarhanShafiq (Fri, 14 Jun 2019 10:34:32 GMT):
Thanks, I did as you said but nodes still running on 10.0.0.1-4. Node node4 started on 10.0.0.5

FarhanShafiq (Fri, 14 Jun 2019 10:34:32 GMT):
Thanks, I did as you said but nodes still running on 10.0.0.1-5. Node node4 started on 10.0.0.5

FarhanShafiq (Fri, 14 Jun 2019 10:37:10 GMT):
I want to run these nodes on localhost.

FarhanShafiq (Fri, 14 Jun 2019 10:40:49 GMT):
I run that again by stopping the pool and now facing different problem. docker: Error response from daemon: Invalid address 127.0.0.1: It does not belong to any of this network's subnets.

FarhanShafiq (Fri, 14 Jun 2019 10:42:00 GMT):
localhost ip should be without port removing ":" or with port/

FarhanShafiq (Fri, 14 Jun 2019 10:42:00 GMT):
localhost ip should be without port removing ":" or with port.

FarhanShafiq (Fri, 14 Jun 2019 10:43:08 GMT):
Pool created Reading pool data Pool data is node1 127.0.0.1 9701 9702,node2 127.0.0.1 9703 9704,node3 127.0.0.1 9705 9706,node4 127.0.0.1 9707 9708 Creating pool network pool-network 6e2bb5eb040ab19b59b2714529f97617ee6733dbc4256b6b14f16a10b1dcf8d2 Starting pool Starting node node1 127.0.0.1 WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap. 044cda9791f6877d7b5137fb0e5a3ac9947896a3d5c839337d141ce0666deeb0 docker: Error response from daemon: Invalid address 127.0.0.1: It does not belong to any of this network's subnets.

FarhanShafiq (Fri, 14 Jun 2019 10:43:40 GMT):
Pool created Reading pool data Pool data is node1 127.0.0.1 9701 9702,node2 127.0.0.1 9703 9704,node3 127.0.0.1 9705 9706,node4 127.0.0.1 9707 9708 Creating pool network pool-network 6e2bb5eb040ab19b59b2714529f97617ee6733dbc4256b6b14f16a10b1dcf8d2 Starting pool Starting node node1 127.0.0.1 WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap. 044cda9791f6877d7b5137fb0e5a3ac9947896a3d5c839337d141ce0666deeb0 docker: Error response from daemon: Invalid address 127.0.0.1: It does not belong to any of this network's subnets.

AndrewNikitin (Fri, 14 Jun 2019 10:43:59 GMT):
well, you can try to create a you own docker network with subnet 127.0.0.1/8 and pass it into pool_start.sh script. docker network create --subnet="127.0.0.1/8" "my-indy-network" and ./pool_start.sh 4 "127.0.0.1,127.0.0.1,127.0.0.1,127.0.0.1" 4 2122 "my-indy-network"

FarhanShafiq (Fri, 14 Jun 2019 10:44:45 GMT):
okay let me try.

FarhanShafiq (Fri, 14 Jun 2019 10:48:06 GMT):
I tried this after removing all docker container and network but still facing same issue.

FarhanShafiq (Fri, 14 Jun 2019 10:48:25 GMT):
Creating pool network my-indy-network my-indy-network 52d6fa01686a45696e546632a491336a9deeef5dd679a462e9c02bd81c10640d Starting pool Starting node node1 127.0.0.1 WARNING: Your kernel does not support swap limit capabilities or the cgroup is not mounted. Memory limited without swap. 1d556e8e05ec5a70f846bc60de65a0ffe3c1510160d5a9f3e2732381c068f23c docker: Error response from daemon: Invalid address 127.0.0.1: It does not belong to any of this network's subnets.

AndrewNikitin (Fri, 14 Jun 2019 11:19:21 GMT):
well, it's not a trivial case. I think, for now, pool_start script can create pool only on 10.0.0. subnet

FarhanShafiq (Fri, 14 Jun 2019 11:52:01 GMT):
Yeah i think so too.

FarhanShafiq (Fri, 14 Jun 2019 11:52:33 GMT):
What is the other way to create pool network ?

AndrewNikitin (Fri, 14 Jun 2019 11:53:15 GMT):
you can run ./pool_start.sh without any parameters.

FarhanShafiq (Fri, 14 Jun 2019 11:54:20 GMT):
but it will run on 10.0.0. subnet that will make unable for me to testing on it.

FarhanShafiq (Fri, 14 Jun 2019 11:56:10 GMT):
I also tried to run the pool by using that command: generate_indy_pool_transactions --nodes 4 --clients 5 --nodeNum 1 [--ips '191.177.76.26,22.185.194.102,247.81.153.79,93.125.199.45'] [--network=sandbox] But it generate more error than this on i.e invalid nodenum and ips.

AndrewNikitin (Fri, 14 Jun 2019 11:56:16 GMT):
you can try to change BASE_IP var in pool_start.sh script

FarhanShafiq (Fri, 14 Jun 2019 11:58:05 GMT):
but its uses the 10.0.0.x rather than one static i.e 127.0.0.1

AndrewNikitin (Fri, 14 Jun 2019 11:58:40 GMT):
Did you use generate_indy_pool_transactions brackets (like [ ) for input parameters?

FarhanShafiq (Fri, 14 Jun 2019 12:00:17 GMT):
I removed that but still facing error.

FarhanShafiq (Fri, 14 Jun 2019 12:01:08 GMT):
Also indy-node through apt-get doesn't support linux mint which force me to use docker container.

FarhanShafiq (Fri, 14 Jun 2019 12:41:46 GMT):
I tried again with generate_indy_pool_transactions and now it's working fine or i suppose that. I'm running on docker container and each node expose two ips, one for node and second for client. when i try to ping it through browser, it doesn't work. Is there anyway to access node API

FarhanShafiq (Fri, 14 Jun 2019 12:41:46 GMT):
I tried again with generate_indy_pool_transactions and now it's working fine or i suppose that. I'm running on docker container and each node expose two ips, one for node and second for client. when i try to ping it through browser, it doesn't work. Is there anyway to access node API's ?

FarhanShafiq (Fri, 14 Jun 2019 12:42:32 GMT):
start_indy_node Node2 0.0.0.0 9703 0.0.0.0 9704

FarhanShafiq (Fri, 14 Jun 2019 12:42:32 GMT):
> start_indy_node Node2 0.0.0.0 9703 0.0.0.0 9704

FarhanShafiq (Fri, 14 Jun 2019 12:42:46 GMT):
running this node but it's not showing any status

AndrewNikitin (Fri, 14 Jun 2019 14:05:53 GMT):
node expose one ip with different ports.

FarhanShafiq (Fri, 14 Jun 2019 14:07:46 GMT):
I using this guide: https://hyperledger-indy.readthedocs.io/projects/node/en/latest/start-nodes.html working fine but > systemctl status indy-node stop with exit-code

FarhanShafiq (Fri, 14 Jun 2019 14:08:14 GMT):
systemctl status indy-node � indy-node.service - Indy Node Loaded: loaded (/etc/systemd/system/indy-node.service; enabled; vendor preset : enabled) Active: activating (auto-restart) (Result: exit-code) since Fri 2019-06-14 14 :06:14 UTC; 309ms ago Process: 10192 ExecStart=/usr/bin/env python3 -O /usr/local/bin/start_indy_nod e ${NODE_NAME} ${NODE_IP} ${NODE_PORT} ${NODE_CLIENT_IP} ${NODE_CLIENT_PORT} (code=exited, status=1/FAILURE) Main PID: 10192 (code=exited, status=1/FAILURE) Jun 14 14:06:14 494d2e919c35 systemd[1]: indy-node.service: Unit entered failed state. Jun 14 14:06:14 494d2e919c35 systemd[1]: indy-node.service: Failed with result 'exit-code'.

FarhanShafiq (Mon, 17 Jun 2019 11:42:05 GMT):
Unable to connect indy-node with indy-cli. Is there any configuring for indy-cli to detect indy-node ?

FarhanShafiq (Mon, 17 Jun 2019 11:42:57 GMT):
indy-node is currently working fine by checking systemctl status and node monitor status is also good.

FarhanShafiq (Mon, 17 Jun 2019 11:43:27 GMT):
> indy> pool list There are no pools defined

FarhanShafiq (Mon, 17 Jun 2019 11:44:18 GMT):
> indy> pool connect pool1 Pool "pool1" does not exist.

FarhanShafiq (Tue, 18 Jun 2019 11:28:26 GMT):
I used one of the did from the domain_transaction_genesis for adding new node as a validator but got error: Transaction has been rejected: client request invalid: InsufficientCorrectSignatures(0, 1)

hanubc7743 (Tue, 25 Jun 2019 19:41:11 GMT):
Has joined the channel.

hanubc7743 (Tue, 25 Jun 2019 19:41:16 GMT):
Hi We are looking for the hyperledger indy experienced developers so who has interest they can share the profile to hanubc7743@gmail.com

MarcoPasotti (Wed, 26 Jun 2019 16:30:40 GMT):
Has joined the channel.

Pe4eHbKa (Wed, 03 Jul 2019 08:00:53 GMT):
Has joined the channel.

Pe4eHbKa (Wed, 03 Jul 2019 08:00:53 GMT):
Hi guys

Pe4eHbKa (Wed, 03 Jul 2019 08:01:31 GMT):
Can somebody help me with adding new node to ledger with indy-sdk?

Pe4eHbKa (Wed, 03 Jul 2019 08:05:37 GMT):
My workflow is next: 1) create 4 init nodes, generate genesises - OK 2) start pool - OK, init nodes connects to each other 3) connect to this pool - OK 4) create NYM request, signed and submit it - OK 5) create NODE request, signed and submit it - OK, services: ['VALIDATOR'] 6) start new node - failed, node can't connect to network and try to reconnect every min

Hangyu (Mon, 08 Jul 2019 07:40:26 GMT):
Has joined the channel.

nhrishi (Thu, 11 Jul 2019 06:29:58 GMT):
Has joined the channel.

BreizhIndy (Thu, 11 Jul 2019 15:04:32 GMT):
hello i'm trying to run performance test but I can't find my genesis file

BreizhIndy (Thu, 11 Jul 2019 15:05:18 GMT):
I used this command to create my pool

BreizhIndy (Thu, 11 Jul 2019 15:05:43 GMT):
docker build -f ci/indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9708:9701-9708 indy_pool

BreizhIndy (Thu, 11 Jul 2019 15:05:52 GMT):
and i'm trying to run these scripts

BreizhIndy (Thu, 11 Jul 2019 15:06:00 GMT):
https://github.com/hyperledger/indy-node/tree/master/scripts/performance

BreizhIndy (Thu, 11 Jul 2019 15:09:11 GMT):
looks like similar problem to @FarhanShafiq

BreizhIndy (Thu, 11 Jul 2019 17:42:40 GMT):
I managed to make it almost) work via the docker container but the tx are not going through

BreizhIndy (Thu, 11 Jul 2019 17:42:42 GMT):
python3 perf_processes.py -n 10000000 -k nym -g /home/indy/.indy-cli/networks/sandbox/pool_transactions_genesis Version 1.1.5 Number of client 4 Path to genesis txns file /home/indy/.indy-cli/networks/sandbox/pool_transactions_genesis Seed ['000000000000000000000000Trustee1'] Batch size 10000000 Request kind nym Refresh rate, sec 10 Pregenerated reqs cnt 30 Output directory ./load_test_20190711_174111 Value Separator | Wallet Key key Started At 2019-07-11 17:41:11.460774 Mode processes Sync mode freeflow Pool config None Load rate batches per sec 10.0 Ext settings None Save short statistics False Time 0.02 Clients 0/4 Sent: 0 Succ: 0 Failed: 0 Nacked: 0 Rejected: 0 DONE At 2019-07-11 17:41:15.896309 Time 4.44 Clients 0/4 Sent: 0 Succ: 0 Failed: 0 Nacked: 0 Rejected: 0

lynn.bendixsen (Thu, 11 Jul 2019 19:47:30 GMT):
Has joined the channel.

BrajeshKumar (Fri, 12 Jul 2019 10:57:07 GMT):
Has joined the channel.

BreizhIndy (Fri, 12 Jul 2019 21:36:10 GMT):
finally made it work

BreizhIndy (Fri, 12 Jul 2019 21:37:27 GMT):
one question, should the number of node be an odd number, or is it ok if it's an even number (regarding performance and how the bft consensus algorithm work)

sergey.khoroshavin (Fri, 12 Jul 2019 21:48:44 GMT):
@BreizhIndy for best results number of nodes should look like 3f+1, where f is number of faulty nodes that network can tolerate. So, you'd better aim for 4, 7, 10, 13, etc nodes. Of course you can have for example 5 nodes in your network, however this is a bit counterproductive since it will be able to tolerate only one failure, just like 4-nodes network, but you will pay the price (in terms of performance) of 5 nodes.

BreizhIndy (Fri, 12 Jul 2019 22:42:08 GMT):
@sergey.khoroshavin thanks I was about to do experiment on 4 8 12 16 node but I remembered that there was something like that in my distributed system class ;)

sumodgeorge (Sat, 13 Jul 2019 13:18:04 GMT):
Has joined the channel.

ViaSky (Wed, 17 Jul 2019 17:24:55 GMT):
Has joined the channel.

mero (Tue, 23 Jul 2019 08:05:05 GMT):
Has joined the channel.

rtrive (Tue, 30 Jul 2019 20:31:04 GMT):
Has joined the channel.

rtrive (Tue, 30 Jul 2019 20:31:26 GMT):
hi ! i'm trying to set up an indy node by myself following this guide https://github.com/hyperledger/indy-node/blob/master/docs/source/start-nodes.md#scripts-for-initialization I'm stuck to understand some process. If i use generate_indy_pool_transactions everything goes fine but the initial seed is always the same and i don't want this. If i use init_indy_node i cannot see the files pool_transaction_genesis, domain_transaction_genesis. What part am i missing? Thanks

lynn.bendixsen (Tue, 30 Jul 2019 21:40:22 GMT):
Hi rtrive, Here is another option to avoid making genesis files by hand (which is also possible) You can use the following instructions and the genesis_from_files.py script along with init_indy_node to have unique seeds as you are wanting. Here is the link: https://github.com/sovrin-foundation/steward-tools/tree/master/create_genesis

lynn.bendixsen (Tue, 30 Jul 2019 21:40:22 GMT):
Hi rtrive, Here is another option to avoid making genesis files by hand (which is also possible). You can use the following instructions and the genesis_from_files.py script along with init_indy_node to have unique seeds as you are wanting. Here is the link: https://github.com/sovrin-foundation/steward-tools/tree/master/create_genesis

cam-parra (Tue, 30 Jul 2019 22:30:08 GMT):
Does anyone have documentation on the new roles introduced by 1.9.0?

andrew.whitehead (Wed, 31 Jul 2019 20:22:32 GMT):
Has joined the channel.

andrew.whitehead (Wed, 31 Jul 2019 20:25:22 GMT):
Hm, is this official? Can indy-plenum be updated to use it? It seems like at the moment one has to build both ursa and indy-crypto. https://github.com/lanius-shrike/python-ursa

andrew.whitehead (Wed, 31 Jul 2019 20:25:22 GMT):
Hm, is this official? Can indy-plenum be updated to use it? It seems like at the moment one has to build both ursa (for the sdk) and indy-crypto. https://github.com/lanius-shrike/python-ursa

cam-parra (Wed, 31 Jul 2019 20:39:29 GMT):
Oh that's mine :) yeah that should work with plenum

cam-parra (Wed, 31 Jul 2019 20:40:15 GMT):
@MALodder has this been added to ursa?

MALodder (Wed, 31 Jul 2019 20:40:15 GMT):
Has joined the channel.

andrew.whitehead (Wed, 31 Jul 2019 21:45:28 GMT):
I just renamed that wrapper to indy_crypto 0.5.1 for now.. seems to work :)

cam-parra (Wed, 31 Jul 2019 21:47:15 GMT):
I will work on this for the next week or so to make it say ursa

MALodder (Wed, 31 Jul 2019 21:47:35 GMT):
we haven't added this to ursa yet

andrew.whitehead (Wed, 31 Jul 2019 21:52:44 GMT):
Any idea why trying to fetch the AML or TAA produces this error? ```Faber | 2019-07-31 21:16:07,428 indy.libindy.native.indy.services.pool.state_proof.node ERROR src/services/pool/state_proof/node.rs:131 | Unexpected data while parsing Patricia Merkle Trie: Ok(Data(0)): UntrustedRlp { bytes: [128], offset_cache: Cell { value: OffsetCache { index: 18446744073709551615, offset: 0 } }, count_cache: Cell { value: None } }```

andrew.whitehead (Wed, 31 Jul 2019 21:52:44 GMT):
Any idea why trying to fetch the AML or TAA produces this error? ```indy.libindy.native.indy.services.pool.state_proof.node ERROR src/services/pool/state_proof/node.rs:131 | Unexpected data while parsing Patricia Merkle Trie: Ok(Data(0)): UntrustedRlp { bytes: [128], offset_cache: Cell { value: OffsetCache { index: 18446744073709551615, offset: 0 } }, count_cache: Cell { value: None } }```

andrew.whitehead (Wed, 31 Jul 2019 21:52:44 GMT):
Any idea why trying to fetch the AML or TAA produces this error? On 1.9.0 ```indy.libindy.native.indy.services.pool.state_proof.node ERROR src/services/pool/state_proof/node.rs:131 | Unexpected data while parsing Patricia Merkle Trie: Ok(Data(0)): UntrustedRlp { bytes: [128], offset_cache: Cell { value: OffsetCache { index: 18446744073709551615, offset: 0 } }, count_cache: Cell { value: None } }```

andrew.whitehead (Thu, 01 Aug 2019 01:08:22 GMT):
Seems to be fixed by sdk 1.10.1

PaulA (Thu, 01 Aug 2019 08:48:01 GMT):
Has joined the channel.

cam-parra (Fri, 02 Aug 2019 17:37:52 GMT):
@esplinr Me and Mike L are going to colab to switch plenums bls to the renamed wrapper for URSA. Just to let your team know. It's the same code Slava wrote just with the proper ursa naming.

cam-parra (Fri, 02 Aug 2019 17:38:21 GMT):
We will implement proper testing and pipelines for this as well

rtrive (Mon, 05 Aug 2019 19:02:39 GMT):
hi @lynn.bendixsen ! thanks for you answer! it was very helpful because it works ;)

esplinr (Mon, 05 Aug 2019 21:47:10 GMT):
Which new roles? I'm only aware of the rename from TRUST_ACHOR to ENDORSER, which is as simple as it sounds.

esplinr (Mon, 05 Aug 2019 21:47:24 GMT):
Thank you for the heads-up.

cam-parra (Tue, 06 Aug 2019 14:28:11 GMT):
@sergey.khoroshavin do you know if plenum's ci installs indy-crypto through pip or apt-get?

ashcherbakov (Tue, 06 Aug 2019 14:57:32 GMT):
@cam-parra Both. There is a library `libindy-crypto` (please have a look at ci/ubuntu.dockerfile) installed through apt-get, and a python wrapper `indy-crypto` (have a look at setup.py) installed through pip

alvaradojl (Wed, 07 Aug 2019 07:09:34 GMT):
does anyone have an idea what's the process for a steward to onboard an endorser in Sovrin?

PaulA (Fri, 09 Aug 2019 10:45:01 GMT):
I'm trying to initialize and start indy node as presented (https://github.com/hyperledger/indy-node/blob/master/docs/source/start-nodes.md#scripts-for-initialization) But i encounter problems running the below commands. (init_indy_node Alpha 0.0.0.0 9701 0.0.0.0 9702 [--seed 111111111111111111111111111Alpha]) Error: bad pattern: [--seed

lynn.bendixsen (Fri, 09 Aug 2019 15:42:41 GMT):
It looks like the [] in that example indicate an optional parameter. From my experience with the script, you just need to pass the seed at the end of the script (no suqare brackets, and no --seed) for example, I think this is what you want: ```init_indy_node Alpha 0.0.0.0 9701 0.0.0.0 9702 111111111111111111111111111Alpha```

lynn.bendixsen (Fri, 09 Aug 2019 15:42:41 GMT):
It looks like the [] in that example indicate an optional parameter. From my experience with the script, you just need to pass the seed at the end of the command (no suqare brackets, and no --seed) for example, I think this is what you want: ```init_indy_node Alpha 0.0.0.0 9701 0.0.0.0 9702 111111111111111111111111111Alpha```

lynn.bendixsen (Fri, 09 Aug 2019 15:42:41 GMT):
It looks like the [] in that example indicate an optional parameter. From my experience with the script, you just need to pass the seed at the end of the command (no square brackets, and no --seed) for example, I think this is what you want: ```init_indy_node Alpha 0.0.0.0 9701 0.0.0.0 9702 111111111111111111111111111Alpha```

PaulA (Sun, 11 Aug 2019 03:01:42 GMT):
It works. Thanks

lynn.bendixsen (Mon, 19 Aug 2019 16:04:59 GMT):
I am noticing that the last few nodes added to the Sovrin BuilderNet are having a hard time getting into and staying in consensus. They are currently out of consensus and restarting them does not bring them back in. Does anyone know of any code changes in the last twoish releases that might have caused this issue? I am on indy-node 1.9.1. Yes, it could be that it is just by chance that the recently added ones are the ones with issues, but it seems a pretty strong correlation to me, so I thought I would ask.

lynn.bendixsen (Mon, 19 Aug 2019 16:04:59 GMT):
I am noticing that the last few nodes added to the Sovrin BuilderNet are having a hard time getting into and staying in consensus. They are currently out of consensus and restarting them does not bring them back in. Does anyone know of any code changes in the last twoish releases that might have caused this issue? I am on indy-node 1.9.1. Yes, it could be that it is just by chance that the recently added ones are the ones with issues, but it seems a pretty strong correlation to me, so I thought I would ask. All of the nodes having trouble were added after Aug 5th, which was the last time BuilderNet was upgraded.

esplinr (Tue, 20 Aug 2019 03:58:57 GMT):
I share your suspicions. It's best to create an issue and add logs from the nodes that are struggling.

esplinr (Tue, 20 Aug 2019 04:20:55 GMT):
I see that you raised https://jira.hyperledger.org/browse/INDY-2211 Thank you.

ashcherbakov (Tue, 20 Aug 2019 14:20:20 GMT):
Thanks for raising the issue. We will have a look in the scope of the current Sprint.

Hangyu (Wed, 28 Aug 2019 04:36:57 GMT):
hi, I am new to indy and I don't know if this question sounds reasonable. I am trying to build indy node of version 1.7. I noticed that the according crypto version is 0.5.0, but I couldn't find the source of indy-crypto of version 0.5.0 from git. Could anyone help me with it? really much appreciate it.

ashcherbakov (Thu, 29 Aug 2019 07:23:54 GMT):
Please note that the current indy-node version is 1.9.1. And it depends on indy-crypto 0.4.5: https://github.com/hyperledger/indy-plenum/blob/master/setup.py#L56, https://github.com/hyperledger/indy-plenum/blob/master/ci/ubuntu.dockerfile#L12

Hangyu (Thu, 29 Aug 2019 07:50:44 GMT):
thanks for the the reply, it helps a lot

Hangyu (Thu, 29 Aug 2019 08:07:53 GMT):
Sorry to bother you again, another quick question, where is the source of indy-crypto 0.4.5? I noticed that the recent release is 0.4.2 https://github.com/hyperledger/indy-crypto/releases

MALodder (Thu, 29 Aug 2019 12:44:39 GMT):
I think that version is not on master

MALodder (Thu, 29 Aug 2019 12:45:11 GMT):
I think its on `rc`

Hangyu (Mon, 02 Sep 2019 06:03:52 GMT):
So the 0.4.5 is actually rc. Got it, thanks very much!

jadhavajay (Thu, 19 Sep 2019 18:45:22 GMT):
Has joined the channel.

VenkateshSYS (Sun, 22 Sep 2019 15:02:02 GMT):
Has joined the channel.

VenkateshSYS (Sun, 22 Sep 2019 15:02:04 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:45 GMT):
"scripts": { "startfile" : "node file.js" } How to write this in dockerfile CMD []

volume_zero (Sun, 22 Sep 2019 18:33:03 GMT):
Has joined the channel.

volume_zero (Sun, 22 Sep 2019 18:43:32 GMT):
Hello all, I am trying to run the indy-dev demo (https://github.com/sovrin-foundation/indy-dev.git) by separating the node pool in one VM and the dev client in one VM. The pool is accessible from the dev client as tested via telnet. However on running the getting_started.py demo code on the client, after putting the correct IPs for the client and pool in utils.py, I get errors 306 and 307. Any thoughts, whether this is the correct way of doing things?

volume_zero (Sun, 22 Sep 2019 18:43:44 GMT):

Clipboard - September 22, 2019 12:43 PM

PoojaJagtap (Mon, 23 Sep 2019 09:03:13 GMT):
Has joined the channel.

PoojaJagtap (Mon, 23 Sep 2019 09:10:29 GMT):
To use Node Monitoring Tools I am installing Email Plugin in Ubuntu. But by (with changing email address) entering the command "echo "Subject: sendmail test" | sendmail -v youremail@example.com -f alert@noreply.com" I am not getting any test mail. It means my "sendmial" is not working. Can someone help me to fix this?

PoojaJagtap (Mon, 23 Sep 2019 09:11:17 GMT):

Clipboard - September 23, 2019 2:41 PM

PoojaJagtap (Mon, 23 Sep 2019 09:57:32 GMT):
354 Enter mail, end with "." on a line by itself >>> . 050 ... Connecting to local... 050 ... Sent 250 2.0.0 x8N4J1Ix005690 Message accepted for delivery root... Sent (x8N4J1Ix005690 Message accepted for delivery) Closing connection to [127.0.0.1] >>> QUIT 221 2.0.0 e2e-39-183.NodeName.in closing connection You have new mail in /var/mail/root

acaldas18 (Tue, 01 Oct 2019 22:56:22 GMT):
Has joined the channel.

tomislav (Sat, 05 Oct 2019 01:59:27 GMT):
Our CI build fails with ``` The following packages have unmet dependencies: 1451 indy-plenum : Depends: python3-pyzmq (= 17.0.0) but 18.1.0 is to be installed ``` This used to work until today. Docker image used - https://github.com/hyperledger/aries-framework-dotnet/blob/master/docker/indy-pool.dockerfile Failed build - https://travis-ci.com/hyperledger/aries-framework-dotnet/builds/130500345 Any clues on how to resolve this or what is causing it to fail?

Hangyu (Tue, 08 Oct 2019 06:57:23 GMT):
Hello everyone, I am trying to build indy-node pool with my own customized libindy-crypto.so. I simply replaced the old one in /usr/lib/ and then i got the error as following: ``` Traceback (most recent call last): File "/usr/local/bin/start_indy_node", line 19, in client_ip=sys.argv[4], client_port=int(sys.argv[5])) File "/usr/local/lib/python3.5/dist-packages/indy_node/utils/node_runner.py", line 51, in run_node ha=node_ha, cliha=client_ha) File "/usr/local/lib/python3.5/dist-packages/indy_node/server/node.py", line 101, in __init__ config=config) File "/usr/local/lib/python3.5/dist-packages/plenum/server/node.py", line 216, in __init__ self.bls_bft = self._create_bls_bft() File "/usr/local/lib/python3.5/dist-packages/plenum/server/node.py", line 1131, in _create_bls_bft bls_bft = bls_factory.create_bls_bft() File "/usr/local/lib/python3.5/dist-packages/crypto/bls/bls_factory.py", line 68, in create_bls_bft bls_crypto_signer = self._bls_factory_crypto.create_bls_crypto_signer_from_saved_keys() File "/usr/local/lib/python3.5/dist-packages/crypto/bls/bls_factory.py", line 32, in create_bls_crypto_signer_from_saved_keys return self._create_bls_crypto_signer(sk, pk, group_params) File "/usr/local/lib/python3.5/dist-packages/plenum/bls/bls_crypto_factory.py", line 21, in _create_bls_crypto_signer return BlsCryptoSignerIndyCrypto(sk=sk, pk=pk, params=group_params) File "/usr/local/lib/python3.5/dist-packages/crypto/bls/indy_crypto/bls_crypto_indy_crypto.py", line 114, in __init__ self._sk_bls = IndyCryptoBlsUtils.bls_from_str(sk, SignKey) File "/usr/local/lib/python3.5/dist-packages/crypto/bls/indy_crypto/bls_crypto_indy_crypto.py", line 42, in bls_from_str return cls.from_bytes(bts) File "/usr/local/lib/python3.5/dist-packages/indy_crypto/bls.py", line 34, in from_bytes do_call(cls.from_bytes_handler, xbytes, len(xbytes), byref(c_instance)) File "/usr/local/lib/python3.5/dist-packages/indy_crypto/lib.py", line 12, in do_call err = getattr(_cdll(), name)(*args) File "/usr/local/lib/python3.5/dist-packages/indy_crypto/lib.py", line 22, in _cdll _cdll.cdll = _load_cdll() File "/usr/local/lib/python3.5/dist-packages/indy_crypto/lib.py", line 51, in _load_cdll getattr(res, "indy_crypto_init_logger")() File "/usr/lib/python3.5/ctypes/__init__.py", line 360, in __getattr__ func = self.__getitem__(name) File "/usr/lib/python3.5/ctypes/__init__.py", line 365, in __getitem__ func = self._FuncPtr((name_or_ordinal, self)) AttributeError: /usr/lib/libindy_crypto.so: undefined symbol: indy_crypto_init_logger ``` I am using indy-node 1.8.1 and the indy-crypto version is 0.4.5(based on which I added changes) does anyone know if i missed any important steps?

FarhanShafiq (Thu, 10 Oct 2019 07:48:39 GMT):
Can someone help me understand why pairwise DID are important? What if i only use one DID for all connection?

Fosol (Tue, 15 Oct 2019 16:12:01 GMT):
Has joined the channel.

Fosol (Tue, 15 Oct 2019 16:12:02 GMT):
Where can I read up on how the ledger is distributed and remains in sync between instances?

eduelias (Wed, 16 Oct 2019 08:48:08 GMT):
Has joined the channel.

pranavkirtani88 (Wed, 16 Oct 2019 08:58:00 GMT):
Has joined the channel.

pranavkirtani88 (Wed, 16 Oct 2019 08:58:01 GMT):
Hi, any good source material around credential schemas and schema definitions?

donqui (Wed, 16 Oct 2019 11:58:01 GMT):
Maybe something like this: https://github.com/hyperledger/indy-node/blob/master/design/anoncreds.md

chuda (Tue, 22 Oct 2019 11:59:47 GMT):
Has joined the channel.

Rick (Tue, 22 Oct 2019 13:38:10 GMT):
Has joined the channel.

sanket1211 (Wed, 23 Oct 2019 04:28:09 GMT):
Has joined the channel.

esplinr (Wed, 30 Oct 2019 19:57:42 GMT):
In Monday's Indy Contributors call, we had a discussion about our concerns for the future of Indy based on the small number of contributors to Plenum. As a result, we have a proposal to the TSC as part of our quarterly report (due today): let's spin Plenum out as its own first-class Hyperledger project. You can read the rationale here: https://wiki.hyperledger.org/display/HYP/2019+Q4+Hyperledger+Indy

jljordan_bcgov (Wed, 30 Oct 2019 20:50:20 GMT):
what are "identity primitives" in this sentence from the quarterly reports? Trying to understand what is left in Indy if there is no Plenum ```If Plenum leaves Indy, then Indy is a smaller and more focused project. Indy will consist of the identity primitives and server configuration for Plenum. It will be easier to understand and contribute to.```

akshay.sood (Thu, 31 Oct 2019 08:15:23 GMT):
Has joined the channel.

lynn.bendixsen (Fri, 01 Nov 2019 13:50:03 GMT):
@esplinr ^^

andrew.whitehead (Fri, 01 Nov 2019 16:51:32 GMT):
Might that mean eventually having a rust (?) library for communicating with a plenum/indy ledger, separate from indy-sdk?

esplinr (Fri, 01 Nov 2019 20:37:05 GMT):
Interesting question.

esplinr (Fri, 01 Nov 2019 20:38:11 GMT):
We are already keen to move most of the Indy SDK to Aries as separate Aries components (Indy Wallet crate move to Aries-KMS, each wrapper to its own Aries language library, Indy Pack / Unpack to Aries something else).

esplinr (Fri, 01 Nov 2019 20:39:00 GMT):
I expect after that, what is left in the Indy SDK is the Indy Verifiable Data Interface for Aries (indy-vdri-aries) a.k.a. the Indy resolver for Aries.

esplinr (Fri, 01 Nov 2019 20:40:27 GMT):
If we separate Plenum from Indy, Plenum won't have any of the identity primitives. So I don't think there would be an Aries / Plenum resolver. But there probably would be a Plenum Rust library that would be leveraged by the Indy Aries VDRI.

esplinr (Fri, 01 Nov 2019 20:40:36 GMT):
That's my thinking, spur-of-the-moment.

andrew.whitehead (Fri, 01 Nov 2019 20:46:26 GMT):
Thanks, that sounds reasonable

andrew.whitehead (Fri, 01 Nov 2019 22:36:23 GMT):
Is there documentation somewhere of how transaction signatures work in plenum? I'm not sure but I think they are created over the submitted JSON representation of a transaction before it is converted to msgpack for storage, and eventually back to JSON when queried by a client. Is there any way for a client to verify one? I suppose this would also mean fetching a NYM's verkey as of a particular sequence number in case it's changed since then.

esplinr (Fri, 01 Nov 2019 22:49:14 GMT):
I'm sorry I don't know the answer, and it's a holiday weekend for the team (back on Tuesday). @ashcherbakov or @sergey.khoroshavin can answer when they get back. Or maybe @kenebert or @burdettadam know the answer?

andrew.whitehead (Fri, 01 Nov 2019 22:53:32 GMT):
No rush, it’s mainly for my own edification

huxd (Tue, 05 Nov 2019 04:14:45 GMT):
Has joined the channel.

pranavkirtani88 (Thu, 07 Nov 2019 05:51:20 GMT):
quick question on master secret, if the Holder of the master secret looses the device can this master secret be recovered? also can master secret be rotated

vardan10 (Thu, 07 Nov 2019 05:59:10 GMT):
Has joined the channel.

Huid 1 (Thu, 07 Nov 2019 10:49:38 GMT):
Has joined the channel.

Huid 1 (Thu, 07 Nov 2019 10:49:39 GMT):
Hi there, I've tried to built a sample application with Sovrin and Hyperledger. I'm using the indy-pool docker file from the indy-sdk and deployed the docker pool on a public server. The port 9701 - 9708 are free and available. If I want to connect to the pool, my client will try to connect to the pool but somehow runs in a pool-timeout. I captured the traffic and see a lot of TCP-Retransmissions and TCP-RST coming from the indy pool. Does anyone know what it could be?

Huid 1 (Thu, 07 Nov 2019 10:49:45 GMT):

Clipboard - November 7, 2019 11:49 AM

Huid 1 (Thu, 07 Nov 2019 10:52:45 GMT):

Clipboard - November 7, 2019 11:52 AM

Huid 1 (Thu, 07 Nov 2019 10:52:45 GMT):

Clipboard - November 7, 2019 11:52 AM

andrew.whitehead (Thu, 07 Nov 2019 18:41:28 GMT):
I checked the plenum and indy-node documentation before asking, but I couldn't find anything about the implementation of the signatures (transaction or BLS), like what the inputs are

rtrive (Thu, 07 Nov 2019 21:16:46 GMT):
hi guys! I would like to ask a question: could be a security problem if a potential hacker could stolen the steward's wallet and for example could open it and have access to the network? Is it good to protect the steward's wallets on a secure place o this is not at all a problem? Thanks

donqui (Fri, 08 Nov 2019 09:16:14 GMT):
Wallet was designed so that if it was stolen it won't be of much use as data at rest is encrypted, the only thing attacker could to is to try to break the encryption. What you need to keep secure is the wallet key used to 'unlock' the wallet.

donqui (Fri, 08 Nov 2019 09:17:34 GMT):
but it is always a good idea to limit the attack surface and not let your wallet to be compromised, so I would say try to keep it in a secure place :)

rtrive (Fri, 08 Nov 2019 11:35:55 GMT):
if they will break the encryption and have access to data on wallet, this could be a problem for the blockchain?

donqui (Fri, 08 Nov 2019 11:37:28 GMT):
yes, because they would own your keys and creds and could impersonate you.

donqui (Fri, 08 Nov 2019 11:38:33 GMT):
but if you notice that your wallet has been stolen and that someone is trying to break the encryption, there are ways to revoke your creds and rotate keys

donqui (Fri, 08 Nov 2019 11:39:32 GMT):
this may be of help: https://sovrin.org/wp-content/uploads/2019/03/What-if-someone-steals-my-phone-110319.pdf

rtrive (Sun, 10 Nov 2019 15:18:15 GMT):
thanks donqui ;)

gordon_hkpkiforum (Mon, 11 Nov 2019 10:29:33 GMT):
Has joined the channel.

ashlinSajan (Tue, 12 Nov 2019 10:56:05 GMT):
Hi @ashcherbakov @sergey.khoroshavin @kenebert @burdettadam Is there a provision currently to sign any transaction data using the pairwise did s public keys?

ashcherbakov (Tue, 12 Nov 2019 13:47:01 GMT):
Every transaction (write request) must be signed by a user. The use needs to have a NYM txn with a verkey (public part of of DID's key) on the ledger before sending any transaction. So, the user can sign the transaction by the private part, and the ledger can verify the signature using the public part stored on the ledger.

ashlinSajan (Wed, 13 Nov 2019 09:11:09 GMT):
Is there already some functionality available in Indy for signing?

ashcherbakov (Wed, 13 Nov 2019 10:22:15 GMT):
yes, please have a look at `sign_request` in indy-sdk

pranavkirtani88 (Mon, 18 Nov 2019 04:17:18 GMT):
when sharing a crdential, what happens if a party if recording network traffic, can it re use the data sent to the relying party and use to perform a replay attack?

MALodder (Mon, 18 Nov 2019 15:39:00 GMT):
are you talking about when presenting a credential to a verifier? If so, each party contributes a nonce as required by the protocol which makes replays invalid. However, the proofs generated can be verified whenever because they are classified as non-interactive ZKPs so it depends on what you are trying to protect from replays

MALodder (Mon, 18 Nov 2019 15:39:37 GMT):
Usually there are two cases to protect, 1- malicious holder, 2- malicious verifier

MALodder (Mon, 18 Nov 2019 15:40:16 GMT):
a malicious holder's goal is to fool the verifier into believing she has a valid credential when she does not

MALodder (Mon, 18 Nov 2019 15:41:11 GMT):
a malicious verifier has two goals, impersonate the original credential holder, and divine the true values used in the ZKP

MALodder (Mon, 18 Nov 2019 15:42:25 GMT):
the malicious holder case is extremely difficult because the odds of this happening is 1/2^256 per attribute

MALodder (Mon, 18 Nov 2019 15:44:49 GMT):
for a verifier to impersonate the holder, this is enforced by the nonces generated by another verifier. Think of these a presentation ids or session ids. They change per presentation. In that case the malicious verifier serves the same role as a malicious holder. Since she cannot create a new proof valid for the new session id or break the proof presented to her to extract the actual attribute values, replay to impersonate is very difficult

HLFPOC (Fri, 22 Nov 2019 06:05:42 GMT):
Hi Team, Can anyone please differentiate between Steward and a trust anchor role in Sovrin? As per my understanding, steward is the one who takes responsibility of running a node of Sovrin, and trust anchor issues/verifies credentials. In order to do that, trust anchor will also have to run a node in Sovrin? So indirectly a trust anchor is also a steward ? Can someone please give some inputs on this ?

ashcherbakov (Fri, 22 Nov 2019 07:47:37 GMT):
> steward is the one who takes responsibility of running a node of Sovrin Yes > In order to do that, trust anchor will also have to run a node in Sovrin? Sovrin/Indy ledger is Public Permissioned. That means that 1) Anyone can read from the leger. No special roles are required. *No need to run a node to do reads* 2) Writes to the ledger are permissioned. But they are restircted just by the role only (like some txns can be written by Strewards only, some by Trust Anchors only). And again, *No need to run a node to do writes*. > trust anchor issues/verifies credentials. Issuance of credentials requires writing some transactions to the ledger (SCHEMA, CRED_DEF, Revocation). And usually only Trust Anchors (or it's better to use a new term Endorsers) can do this. Verifiaing of proofs doesn't require any writes to the ledger, only reads. So, anyone can be a verifier.

JeromeK (Wed, 27 Nov 2019 09:12:37 GMT):
Has joined the channel.

JeromeK (Wed, 27 Nov 2019 09:12:38 GMT):
Hey Guys Please check out our disscussen in #indy https://chat.hyperledger.org/channel/indy?msg=hE7iLohXHrhxiabpW about the Sovrin-StagingNet timing out when requesting a credential-definiton with 88 Schema Attributes

JeromeK (Wed, 27 Nov 2019 09:12:38 GMT):
Hey Guys Please check out our discussion in #indy https://chat.hyperledger.org/channel/indy?msg=hE7iLohXHrhxiabpW about the Sovrin-StagingNet timing out when requesting a credential-definition with 88 Schema Attributes

ashcherbakov (Wed, 27 Nov 2019 11:08:04 GMT):
Hi @JeromeK I don't think this is related to server performance since read operation is pretty cheap. Also we're not aware of any issues related to this. Do I understand correctly that everything works with a custom python script but doesn't work with CLI?

JeromeK (Wed, 27 Nov 2019 11:47:50 GMT):
yes, (currently): So we tried to do the same interactions yesterday and today. Yesterday: none of them worked Today: The python-script worked, CLI still getting a timeout

JeromeK (Wed, 27 Nov 2019 11:47:50 GMT):
yes, (currently): So we tried to do the same interactions yesterday and today. *Yesterday*: none of them worked *Today*: The python-script worked, CLI still getting a timeout

JeromeK (Wed, 27 Nov 2019 11:48:38 GMT):
(no modification to the calls)

ashcherbakov (Wed, 27 Nov 2019 11:54:27 GMT):
Is the problem with the specific CredDef txn only? Or you see the same timeout issue with other txns (with not so many attributtes)?

ashcherbakov (Wed, 27 Nov 2019 11:54:38 GMT):
Also what version of CLI are you using?

ashcherbakov (Wed, 27 Nov 2019 11:55:57 GMT):
Please note, that there is a limit for maximum length of a message on Node side (128 KB). So, in theory, if the message is huge, it can be just rejected.

JeromeK (Wed, 27 Nov 2019 12:08:44 GMT):
Ahhh thats the Problem.... Because all of those Attributes are crazy long, it comes over this maximum lenght

JeromeK (Wed, 27 Nov 2019 12:08:52 GMT):
thanks thats what i wanted

JeromeK (Wed, 27 Nov 2019 12:10:07 GMT):
or wait no ? because then i would not get a response back from the python-script

JeromeK (Wed, 27 Nov 2019 12:10:24 GMT):
Hyperledger Indy CLI (https://github.com/hyperledger/indy-sdk) This is the official CLI tool for Hyperledger Indy (https://www.hyperledger.org/projects), which provides a distributed-ledger-based foundation for self-sovereign identity (https://sovrin.org/). Version: 1.12.0 Apache License Version 2.0 Copyright 2017 Sovrin Foundation

JeromeK (Wed, 27 Nov 2019 12:11:02 GMT):
* i only see the timeout if we have X amount of Attributes with in one schema

JeromeK (Wed, 27 Nov 2019 12:11:40 GMT):
i dont now the exact number when this appears but we noticed this at 88 attributes

JeromeK (Wed, 27 Nov 2019 12:13:33 GMT):
Also a question should i get a timeout if its to big

ashcherbakov (Wed, 27 Nov 2019 12:13:34 GMT):
It can be that the payload is near the limit and sometimes it exceeds it, sometimes not... But agree that this is still weird. If txns with less number of attributes work fine, then this is likely that the problem is related to the size of messages

JeromeK (Wed, 27 Nov 2019 12:13:37 GMT):
or a 200 - rejected?

ashcherbakov (Wed, 27 Nov 2019 12:14:11 GMT):
Timeout. A Node will not send huge reply at all

JeromeK (Wed, 27 Nov 2019 12:14:28 GMT):
okay thanks for the infos, I will have a deeper look at it

JeromeK (Wed, 27 Nov 2019 12:14:36 GMT):
:thumbsup:

ashcherbakov (Wed, 27 Nov 2019 12:14:56 GMT):
Welcome! Thanks for raising this.

JeromeK (Wed, 27 Nov 2019 12:45:50 GMT):
Okay even more strange, the response is only 240 bytes big

JeromeK (Wed, 27 Nov 2019 12:45:58 GMT):
so not even close to 128 kb

ashcherbakov (Wed, 27 Nov 2019 12:47:10 GMT):
Is it the full response, or only the "paylaod" part? Any response consists of "payload" and "metdata" (state proofs, etc.)

JeromeK (Wed, 27 Nov 2019 12:47:46 GMT):
` import sys await Pool.set_protocol_version(2) ph = await Pool.open_pool_connection(POOL, {}) b = await Ledger.get_cred_def_request('', 'VmcAeAQ7D5eRyLWLMKD9oq:3:CL:79461:tprm-tag1') res = await Ledger.submit_request(ph, b) await Pool.close_pool_connection(ph) print(res) print(sys.getsizeof(res))`

JeromeK (Wed, 27 Nov 2019 12:47:46 GMT):
`import sys await Pool.set_protocol_version(2) ph = await Pool.open_pool_connection(POOL, {}) b = await Ledger.get_cred_def_request('', 'VmcAeAQ7D5eRyLWLMKD9oq:3:CL:79461:tprm-tag1') res = await Ledger.submit_request(ph, b) await Pool.close_pool_connection(ph) print(res) print(sys.getsizeof(res))`

JeromeK (Wed, 27 Nov 2019 12:47:46 GMT):
```import sys await Pool.set_protocol_version(2) ph = await Pool.open_pool_connection(POOL, {}) b = await Ledger.get_cred_def_request('', 'VmcAeAQ7D5eRyLWLMKD9oq:3:CL:79461:tprm-tag1') res = await Ledger.submit_request(ph, b) await Pool.close_pool_connection(ph) print(res) print(sys.getsizeof(res))```

JeromeK (Wed, 27 Nov 2019 12:47:57 GMT):
{'op': 'REPLY', 'result': {'type': '108', 'tag': 'tprm-tag1', 'state_proof': {'multi_signature': {'value': {'ledger_id': 1, 'state_root_hash': 'DhX9jtvJNvHoXzn5j96adXveto3S5WTVmGRy4B2tk57J', 'txn_root_hash': '3FgMCzwN1B9tf22L2ThM14HFr5MENrm1n6bLegfKcf57', 'timestamp': 1574858510, 'pool_state_root_hash': 'AYedYvLdZPkz5DxrordsR9bu9fStxtFZuzwb7bW5XBfk'}, 'participants': ['Node3', 'Node1', 'Node2'], 'signature': 'QzD1rMuLe3weYRhi3rMKwmmMyPKzH66Thc3cVDHFtQC3wzEk6ebJaq16p2am1y8b3GoAaEqzUZAvxn5ePTGJ8PdQbh32nA7CUAP87KzPbD4mFRbuUvhqpoE7PnrXUJpHQMBhUxuv3XAYJveFCP4BjesYu3G13Pf1n4CDEDmbkc2WPy'}, 'proof_nodes': '+QM1+DmXAFVUp3cDljTEpTNG5vOWtFdVR4Vnk6OgAec7DG79oAgY7dDIGdtXnrocXRLerD8WoPoi7PBvAUL4UYCAgICAgKAaau92wiI+tak3tr4Z+iBAP71TbBCV1ov1M85mKiEafKCr6uFKTSQpK0qLIMoGkpeGCjPtLOVlvga48apAC7J3OoCAgICAgICAgPjRoLNo0qbc78nhobrO2FN5O+Xw4EyOY1HUOjcGJkdSDqa7oIBfKAJnsRWwkl5qQTYifNMawHEVtgIW1PPi9eFMCF8OgICgSXcC9boNX9qonoT+E8s3fVrIMoA5CVB6Rv9JSA22e+GAoMioXmOGKaz5WZZBjD1aW4EiZZaUH437qPUenQWt9ouIgICgcEd215Kye/3H6h1gJMD2NV+CoI4qfxItLBq9T3Kqn0WAgICgXJXYT0D8Gd2H0JPtAS9SRifOqhCR+TMS+uMpk46+XmKAgID5AdGg09I/bgmxWmztC58rrZwebgwutUGli7VUyVOFwmuLFqOgrGwJZcNIVQkGjCdnMzLripOaQJBqgTmgSem2lRhc9SGAoJzp0IKypqilNcXhOc/LuaAa6gSQf2BIKwU+eHY/WRFCoE4mao2Wty0SDX8vu5tHsrOGCXDflxpT+Lm10Gg97eujoDI4M5EO2/+KBvEWSpVKToFBV7AlM6zBx7uTZlX9J9yfoBKC0D4DfpSzjY6UQvB208mTTs/7pzakovQz7FzCVfDzoH3FhUUi6bekHEtvos7CRkF+AKtXCgonHe6GY0S5l00KoFhKl2O5QSbxjLt1mwgqsuTj1Y0NS3a+o3RX7Te6BDIOoL/x/AlZyRgpJVyVPxcF/DdGuwTegeL2PKg+4NGF5d6tgKBSjoV5ASAEFfAcn0hdkKC/NEscoAQCL6RP1L85zb3eT6C6yMOl0565tbj8DHBt5CYJ7HsWrYVcxaXYUxKKLe+456B9JVxOO1bVJRb8Jwgua4GPO/Juk6XhGUySCneElMV7aqAhmsjuDAC/yzijaEw9MjyJ029UWptaaaDtEk6Sn7nv2qC+503Zqovg4SbLaRrvfOuKcrvk5ZH4W4/FF+/TZkbm5IA=', 'root_hash': 'DhX9jtvJNvHoXzn5j96adXveto3S5WTVmGRy4B2tk57J'}, 'signature_type': 'CL', 'identifier': 'LibindyDid111111111111', 'reqId': 1574858800328279000, 'txnTime': None, 'data': None, 'ref': 79461, 'origin': 'VmcAeAQ7D5eRyLWLMKD9oq', 'seqNo': None}} 240

ashcherbakov (Wed, 27 Nov 2019 12:49:23 GMT):
`'data': None` 'seqNo': None It looks like the CredDef hasn't been found on the ledger. Is it expected?

ashcherbakov (Wed, 27 Nov 2019 12:49:23 GMT):
`'data': None` 'seqNo': None` It looks like the CredDef hasn't been found on the ledger. Is it expected?

ashcherbakov (Wed, 27 Nov 2019 12:49:23 GMT):
`'data': None` `'seqNo': None` It looks like the CredDef hasn't been found on the ledger. Is it expected?

JeromeK (Wed, 27 Nov 2019 12:50:58 GMT):
ya true, dafuq?

JeromeK (Wed, 27 Nov 2019 12:51:00 GMT):
https://indyscan.io/tx/sovstaging/domain/79461

JeromeK (Wed, 27 Nov 2019 12:51:07 GMT):
but its right there no?

JeromeK (Wed, 27 Nov 2019 12:51:26 GMT):
oh no wait

JeromeK (Wed, 27 Nov 2019 12:51:35 GMT):
my bad was on the wrong network

ashcherbakov (Wed, 27 Nov 2019 12:51:37 GMT):
This is SCHEMA, not CRED_DEF

JeromeK (Wed, 27 Nov 2019 12:51:44 GMT):
now i get the timeout

JeromeK (Wed, 27 Nov 2019 12:53:07 GMT):
https://indyscan.io/tx/sovstaging/domain/79462

JeromeK (Wed, 27 Nov 2019 12:53:11 GMT):
sorry here the cred-def

ashcherbakov (Wed, 27 Nov 2019 12:55:49 GMT):
Does GET_CRED_DEF work for example for https://indyscan.io/tx/sovstaging/domain/79509?

JeromeK (Wed, 27 Nov 2019 12:56:12 GMT):
it does

ashcherbakov (Wed, 27 Nov 2019 12:56:17 GMT):
If yes, then this is most ptobably size-related thing. If no - then there is some issue on Staging Net

JeromeK (Wed, 27 Nov 2019 12:56:22 GMT):

JeromeK - Wed Nov 27 2019 13:56:17 GMT+0100 (Mitteleuropäische Normalzeit).txt

JeromeK (Wed, 27 Nov 2019 12:56:32 GMT):
it does

JeromeK (Wed, 27 Nov 2019 12:58:42 GMT):
okay, so its really about that response-limit

JeromeK (Wed, 27 Nov 2019 12:59:06 GMT):
could there be an other way to fix this instead of splitting the schemas?

ashcherbakov (Wed, 27 Nov 2019 13:01:16 GMT):
I think without fixes in node code or configs on the pool - no...

JeromeK (Wed, 27 Nov 2019 13:03:58 GMT):
hmmm okay, one last question

JeromeK (Wed, 27 Nov 2019 13:04:09 GMT):
can this limit be lower than 128 KB?

JeromeK (Wed, 27 Nov 2019 13:04:36 GMT):
or higher? if you hosting your own nodes like sovrin is doing - yes righ?

JeromeK (Wed, 27 Nov 2019 13:04:36 GMT):
or higher? if you hosting your own nodes like sovrin is doing - yes right?

ashcherbakov (Wed, 27 Nov 2019 13:05:27 GMT):
this limit is in config file so yes. it can be changed

ashcherbakov (Wed, 27 Nov 2019 13:06:17 GMT):
In any case, I think it's worth creating an issue in Jira to re-consider this limit

JeromeK (Wed, 27 Nov 2019 13:06:51 GMT):
Okay sure, I will create a new one

ashcherbakov (Wed, 27 Nov 2019 13:06:57 GMT):
https://jira.hyperledger.org/secure/RapidBoard.jspa?rapidView=133&projectKey=INDY&view=planning.nodetail Feel free to create a ticket there

JeromeK (Wed, 27 Nov 2019 13:07:14 GMT):
because from my oppinion if you can create up to 125 Attributes you will easly overcome this limit

JeromeK (Wed, 27 Nov 2019 13:07:14 GMT):
because from my opinion if you can create up to 125 Attributes you will easily overcome this limit

ashcherbakov (Wed, 27 Nov 2019 13:07:59 GMT):
yeah... I think the limit for the number of attributes in Schema has been tested against write requests only. Not against read requests which can be more because of additional metadata (like state proofs)

JeromeK (Wed, 27 Nov 2019 13:08:59 GMT):
exactly :sweat_smile:

ashcherbakov (Wed, 27 Nov 2019 13:09:33 GMT):
Thank you again for finding this!

JeromeK (Wed, 27 Nov 2019 13:10:00 GMT):
:thumbsup: Thanks for the Help

JeromeK (Wed, 27 Nov 2019 13:15:14 GMT):
https://jira.hyperledger.org/browse/INDY-2306

ashcherbakov (Wed, 27 Nov 2019 13:17:02 GMT):
:thumbsup:

lsl88 (Wed, 27 Nov 2019 15:37:30 GMT):
Has joined the channel.

SigmaS 1 (Fri, 29 Nov 2019 14:19:18 GMT):
Has joined the channel.

esplinr (Wed, 11 Dec 2019 01:46:11 GMT):
Next Tuesday, December 17, ashcherbakov will be hosting a webinar about Indy Plenum: https://ssimeetup.org/hyperledger-indy-public-blockchain-node-alexander-shcherbakov-webinar-43/ This is a great opportunity to learn about the details of Indy Plenum from the project architect.

steveLiuu (Mon, 16 Dec 2019 06:27:59 GMT):
Has joined the channel.

esplinr (Tue, 17 Dec 2019 17:03:57 GMT):
Alex Shcherbakov is starting a deep dive into Indy's Plenum ledger now: https://ssimeetup.org/hyperledger-indy-public-blockchain-node-alexander-shcherbakov-webinar-43/

biligunb (Fri, 27 Dec 2019 09:56:10 GMT):
Has joined the channel.

biligunb (Mon, 30 Dec 2019 07:45:46 GMT):
Just 1 question guys. Can I use indy-sdk to connect with indy-node (without indy-agent)?

swcurran (Mon, 30 Dec 2019 23:02:06 GMT):
@biligunb - yes.

rjones (Mon, 06 Jan 2020 22:07:34 GMT):
Has joined the channel.

rjones (Mon, 06 Jan 2020 22:07:35 GMT):
Hi - could I get this merged, please?

rjones (Mon, 06 Jan 2020 22:07:35 GMT):
Hi - could I get this merged, please? https://github.com/hyperledger/indy-node/pull/1547

SigmaS 1 (Tue, 07 Jan 2020 11:33:01 GMT):
Hi all, are all Indy nodes automatically stewards or observers?

ashcherbakov (Wed, 08 Jan 2020 09:27:16 GMT):
Stewards. Observer feature is only partially implemented.

ashcherbakov (Wed, 08 Jan 2020 11:28:03 GMT):
merged

smithbk (Thu, 09 Jan 2020 14:12:13 GMT):
Hi, for test purposes, is it possible to run an entire ledger (i.e. 4 validator nodes) and a client in the same python process?

smithbk (Thu, 09 Jan 2020 14:12:13 GMT):
Hi, for test purposes, is it possible to run an entire ledger (i.e. 4 validator nodes) and an indy-sdk client in the same python process?

JeromeK (Thu, 09 Jan 2020 14:58:22 GMT):
Why would you want to run the indy-sdk in the same process?

JeromeK (Thu, 09 Jan 2020 14:58:45 GMT):
Just use the Dockerfile provided to host you node and connect over the genesisfile to the local pool

JeromeK (Thu, 09 Jan 2020 14:58:45 GMT):
Just use the Dockerfile provided to host your node and connect over the genesisfile to the local pool

smithbk (Thu, 09 Jan 2020 18:27:03 GMT):
Same reason someone runs sqlite, an embedded version of a SQL server, cuz it's lighter weight and fewer dependencies. Yes, I have run in docker but curious if it was possible to run embedded

swcurran (Thu, 09 Jan 2020 20:01:24 GMT):
In theory possible. For example, in our ACA-Py demos, we run an ACA-Py agent as a subprocess of a controller. How much work to configure that, I don't know. No one has done it.

smithbk (Thu, 09 Jan 2020 20:02:17 GMT):
ok, thanks

ashcherbakov (Fri, 10 Jan 2020 08:08:59 GMT):
Yes, it's possible and used in indy-plenum's and indy-node's integration tests (indy-sdk as well as a pool of N nodes is run in one process there).

ashcherbakov (Fri, 10 Jan 2020 08:08:59 GMT):
Yes, it's possible and used in indy-plenum's and indy-node's integration tests (pytest). indy-sdk as well as a pool of N nodes is run in one process there. And this is possible there because nodes are instantiated rught from the code for test purposes. For the end users using build artifacts (deb packages, Docker images, etc.) it's not easily possible to run both client and node in one process.

smithbk (Fri, 10 Jan 2020 14:01:02 GMT):
Great. Can you point me to code where that is done? @ashcherbakov

smithbk (Fri, 10 Jan 2020 14:01:02 GMT):
Great. Can you point me to the pytest integration tests? @ashcherbakov

smithbk (Fri, 10 Jan 2020 14:02:31 GMT):
I think I can pull the pieces together, but would be easier to see an entire example

ashcherbakov (Fri, 10 Jan 2020 15:06:06 GMT):
You can have a look at any test in https://github.com/hyperledger/indy-plenum/tree/master/plenum/test. In particular, `txnPoolNodeSet`, `sdk_pool_handle`, `sdk_wallet_steward`, etc. fixtures

smithbk (Fri, 10 Jan 2020 15:24:37 GMT):
@ashcherbakov thanks much

andrew.whitehead (Thu, 16 Jan 2020 07:17:17 GMT):
@esplinr Ledger client repo is public now, still needs work of course: https://github.com/andrewwhitehead/indy-ledger-client (probably to be renamed indy-vdr or similar)

andrew.whitehead (Thu, 16 Jan 2020 07:17:17 GMT):
@esplinr @sergey.khoroshavin Ledger client repo is public now, still needs work of course: https://github.com/andrewwhitehead/indy-ledger-client (probably to be renamed indy-vdr or similar)

andrew.whitehead (Thu, 16 Jan 2020 07:17:17 GMT):
@esplinr Ledger client repo is public now, still needs work of course: https://github.com/andrewwhitehead/indy-ledger-client (probably to be renamed indy-vdr or similar)

ashcherbakov (Thu, 16 Jan 2020 10:32:04 GMT):
@sergey.minaev FYI ^^^^

bariscimen (Sat, 18 Jan 2020 11:08:24 GMT):
Has joined the channel.

EdEykholt (Mon, 20 Jan 2020 03:31:24 GMT):
Has joined the channel.

kdenhartog (Tue, 21 Jan 2020 14:47:05 GMT):
I'd like to sync with you and @peacekeeper on this if possible. I've been looking more at the resolution spec and it would be valuable insight to take some of the implementation learnings and feed it back into the spec.

andrew.whitehead (Tue, 21 Jan 2020 17:08:49 GMT):
@kdenhartog Sure, I'm available to go over that

kdenhartog (Tue, 21 Jan 2020 17:09:40 GMT):
I'll follow up with you to figure out a time. I'm about to head to bed now that it's 6am :upside_down:

andrew.whitehead (Tue, 21 Jan 2020 17:10:14 GMT):
I think you just stay up at that point and reset tomorrow..

akshay.sood (Fri, 24 Jan 2020 16:49:03 GMT):
Hi guys, I am trying to create a `pool_transactions_genesis` file for my own configured nodes. Is there any way to do this? I am trying to create a network which can be deployed on multiple servers without using the `generate_indy_pool_transactions ` script which is for test networks only. Please let me know if anyone knows the procedure. Thanks

lynn.bendixsen (Fri, 24 Jan 2020 22:30:25 GMT):
We have a genesis_from_files.py script that you are welcome to try. https://github.com/sovrin-foundation/steward-tools/tree/master/create_genesis

akshay.sood (Sat, 25 Jan 2020 11:30:10 GMT):
@lynn.bendixsen Thanks for sharing this. Unfortunately, I am not a python dev. Are there any commands or program written in Go, Java, Javascript to do this job?

domwoe (Sat, 25 Jan 2020 18:30:17 GMT):
Has joined the channel.

ashcherbakov (Mon, 27 Jan 2020 07:33:18 GMT):
No, I believe the only script we have is written in Python, but you are welcome to contribute and create a script in oteghr languages.

akshay.sood (Mon, 27 Jan 2020 11:22:45 GMT):
@ashcherbakov ok. I checked the script and got to know that it asks for 2 csv files. It ask for Trustee's DID, Verkey and Steward's DID & Verkey. Do you know how to generate them?

ayushmanss (Mon, 27 Jan 2020 14:43:03 GMT):
Has joined the channel.

lynn.bendixsen (Mon, 27 Jan 2020 14:45:42 GMT):
I think that there is a --help as part of the script that gives the format of the csv files. Hope that helps!

akshay.sood (Mon, 27 Jan 2020 15:27:44 GMT):
Thanks @lynn.bendixsen :)

lynn.bendixsen (Mon, 27 Jan 2020 18:29:22 GMT):
Sorry, I think I didn't answer the question that you asked. Any valid DID/verkey combinations will work in the Genesis files. The new network you make will assign the roles indicated as it is initiating itself. I usually create DID's using the indy-cli interface `indy-cli> did new seed=` If you want to try out the auth_rules feature, you will want to create at least 3 Trustees so that you don't lock yourself out. (They don't all have to be in the genesis file)

akshay.sood (Tue, 28 Jan 2020 04:21:59 GMT):
Thanks @lynn.bendixsen. This is very helpful. I will try it out

lauravuo (Wed, 29 Jan 2020 17:38:44 GMT):
Has joined the channel.

lauravuo-techlab (Thu, 30 Jan 2020 06:42:18 GMT):
Has joined the channel.

lauravuo (Thu, 30 Jan 2020 06:49:39 GMT):
Has left the channel.

andrew.whitehead (Mon, 03 Feb 2020 01:49:04 GMT):
I added some modifications to the request handling in indy-vdr in case somebody with inside knowledge wants to validate/critique the changes: - Combined the 'single' (state proof) and 'consensus' request handlers - When not using state proof, initially send to (`read_nodes + f`) instead of all nodes - Abort requests if `read_nodes` consistent NACK replies are received - Abort requests if `f` reject/NACK/unrecognized replies are received - Fixed state proof verification for `GET_TXN` of `ATTRIB` transaction (must hash raw/enc property) - Fixed comparison of responses for consensus checking (must sort participant names) https://github.com/andrewwhitehead/indy-vdr/blob/0603d879bb26d2398e0913aaee05b8f79463b99b/libindy_vdr/src/pool/handlers/consensus.rs

andrew.whitehead (Mon, 03 Feb 2020 01:49:04 GMT):
I added some modifications to the request handling in indy-vdr in case somebody with inside knowledge wants to validate/critique the changes: - Combined the 'single' (state proof) and 'consensus' request handlers - When not using state proof, initially send to `read_nodes + f` instead of all nodes - Abort requests if `read_nodes` consistent NACK replies are received - Abort requests if `>f` reject/NACK/unrecognized replies are received - Fixed state proof verification for `GET_TXN` of `ATTRIB` transaction (must hash raw/enc property) - Fixed comparison of responses for consensus checking (must sort participant names) https://github.com/andrewwhitehead/indy-vdr/blob/0603d879bb26d2398e0913aaee05b8f79463b99b/libindy_vdr/src/pool/handlers/consensus.rs

biligunb (Tue, 04 Feb 2020 03:42:27 GMT):
Hi guys. I can see documentation for Add Node to existing pool. But how can I remove Node from pool?

ashcherbakov (Tue, 04 Feb 2020 07:47:06 GMT):
Just send a NODE txn with `services=[]`. This is called demotion of a Node.

vladimir.shishkin (Tue, 04 Feb 2020 07:50:40 GMT):
Has joined the channel.

ashcherbakov (Tue, 04 Feb 2020 07:55:03 GMT):
https://github.com/hyperledger/indy-node/blob/master/docs/source/requests.md#node

ashcherbakov (Tue, 04 Feb 2020 08:04:08 GMT):
Thanks for the improvements. I believe @sergey.minaev or @Artemkaaas can add more comments specific to Indy SDK. As from my side: > When not using state proof, initially send to read_nodes + f instead of all nodes Do I understand correctly that this is for read requests only? `initially send` means that if there are no replies by timeout, it will be send to more nodes, doesn't it? Please note, that up to F nodes may be down/malicious/unavailable, but we need at least F+1 equal replies in 'consensus' case. So, if a read request is sent to just `read_nodes + f`, and F nodes are not available, it will not be enough for consensus (as `read_nodes ` is usually less than F+1).

ashcherbakov (Tue, 04 Feb 2020 08:06:13 GMT):
> Abort requests if read_nodes consistent NACK replies are received Up to F nodes can be malicious, so we can not trust anything got from less that F+1 node (unless we use State Proofs and BLS signatures). As `read_nodes ` is usually less than `F+1`, I think we should not abort a request if we got just `read_nodes` NACKs.

biligunb (Tue, 04 Feb 2020 09:59:04 GMT):
tnx. i will try that right away

andrew.whitehead (Tue, 04 Feb 2020 16:48:23 GMT):
Thanks, I'll make some adjustments to that. Yes, 'initially send' means it will send to more nodes if timeouts or failed responses are received. It makes sense that the 'consensus' handler is more aggressive if it's used for write transactions, I wasn't considering that. I might add a flag for read transactions that don't have state proof verification to enable the less aggressive consensus method (not sending to all nodes)

andrew.whitehead (Tue, 04 Feb 2020 16:48:23 GMT):
Thanks, I'll make some adjustments to that. Yes, 'initially send' means it will send to more nodes if timeouts or failed responses are received. It makes sense that the 'consensus' handler is more aggressive if it's used for write transactions, I wasn't considering that. I might add a flag for read transactions that don't have state proof verification to enable the less aggressive consensus method (not sending to all nodes initially)

Artemkaaas (Wed, 05 Feb 2020 06:49:40 GMT):
Thank you, Andrew. I has some additions to Alex commen. - `Combined the 'single' (state proof) and 'consensus' request handlers` - Personally I don't like their mixing. They have similar moments but it still differs in many places. - `Fixed state proof verification for GET_TXN of ATTRIB transaction (must hash raw/enc property)` - good catch. Could you also send PR to Liibndy with this change? - `Fixed comparison of responses for consensus checking (must sort participant names)` - when is it `["data"]["multi_signature"]` possiible? As I remember `multi_signature` is always inside `state_proof` and we remove `state_proof` and `stateProofFrom` fields.

Artemkaaas (Wed, 05 Feb 2020 06:49:40 GMT):
Thank you, Andrew. I have some additions to Alex comment. - `Combined the 'single' (state proof) and 'consensus' request handlers` - Personally, I don't like their mixing. They have similar moments but it still differs in many places. - `Fixed state proof verification for GET_TXN of ATTRIB transaction (must hash raw/enc property)` - good catch. Could you also send PR to Liibndy with this change? - `Fixed comparison of responses for consensus checking (must sort participant names)` - when is it `["data"]["multi_signature"]` possible? As I remember `multi_signature` is always inside `state_proof` and we remove `state_proof` and `stateProofFrom` fields. - `Abort requests if >f reject/NACK/unrecognized replies are received` - I doubt it is the correct condition.

ashcherbakov (Wed, 05 Feb 2020 07:35:21 GMT):
> It makes sense that the 'consensus' handler is more aggressive if it's used for write transactions, Please note, that a write request must be send to all nodes. > Abort requests if >f reject/NACK/unrecognized replies are received Do you abort it when we have > F *equal* Rejects/NACKs? Then the result should be the Reject/NACK returned (having equal F+1 means there is a quorum we can trust)

nath1014 (Wed, 05 Feb 2020 09:15:46 GMT):
Has joined the channel.

andrew.whitehead (Wed, 05 Feb 2020 23:55:47 GMT):
@Artemkaaas `multi_signature` is inside `data` for a GET_TXN, so if state proof verification fails (like it was for attrib transactions) then consensus can also fail and it might request from all nodes. Maybe it should just be removing multi_signature (and other properties?) for comparing the results, I'm not sure

andrew.whitehead (Wed, 05 Feb 2020 23:57:56 GMT):
@ashcherbakov The current version uses a 'failure consensus' to track this

andrew.whitehead (Thu, 06 Feb 2020 00:00:39 GMT):
Btw, I think indy-sdk might avoid 'no consensus' in this case by looping around to the same verifier and getting the same result, which isn't great

swcurran (Thu, 06 Feb 2020 01:52:11 GMT):
Question for Andrew and Nick. Can we self-assert that we support AIP 1.0? Are there any caveats we should add? There is not a test suite to use. AIP references a number of protocols and specific versions of those protocols. What due diligence do we need to do to say "Yeep, we support it" (in a way that Tobias would understand).

swcurran (Thu, 06 Feb 2020 01:53:04 GMT):
The answer might need to be in the form of a task for someone to do...

andrew.whitehead (Thu, 06 Feb 2020 03:27:50 GMT):
Wrong channel?

swcurran (Thu, 06 Feb 2020 03:28:42 GMT):
Yup! :-)

jrallen (Fri, 07 Feb 2020 15:29:29 GMT):
Has joined the channel.

jrallen (Fri, 07 Feb 2020 15:32:27 GMT):
hello guys. I am having trouble taking zmq to indy-node. I'm calling equivalent things as indy-cli is calling at networker.rs:343, but I just see that indy-node immediately drops the connection silently without replying with a WELCOME frame.

jrallen (Fri, 07 Feb 2020 15:32:27 GMT):
hello guys. I am having trouble talking zmq to indy-node. I'm calling equivalent things as indy-cli is calling at networker.rs:343, but I just see that indy-node immediately drops the connection silently without replying with a WELCOME frame.

jrallen (Fri, 07 Feb 2020 15:32:57 GMT):
I'm looking for advice on how to make indy-node (and it's underlying zmq library) log more and tell me what I'm doing wrong.

jrallen (Fri, 07 Feb 2020 16:36:56 GMT):
trustee seed

ashcherbakov (Mon, 10 Feb 2020 07:48:12 GMT):
You can change the log level in config file located in `/etc/indy` to `logLevel = 0`

jrallen (Mon, 10 Feb 2020 11:28:43 GMT):
thanks, but what I need is for libzmq to tell me why it is terminating connections right away. I only get this in the indy-node logs:

jrallen (Mon, 10 Feb 2020 11:28:50 GMT):
2020-02-10 11:09:02,033|TRACE|stacks.py|Node1C listener event: {'endpoint': b'tcp://172.17.0.2:9702', 'event': 32, 'value': 216} 2020-02-10 11:09:02,033|TRACE|stacks.py|Node1C: number of connected clients: 1 2020-02-10 11:09:02,033|TRACE|stacks.py|Node1C listener event: {'endpoint': b'tcp://172.17.0.2:9702', 'event': 512, 'value': 216} 2020-02-10 11:09:02,033|TRACE|stacks.py|Node1C: number of connected clients: 0

jrallen (Mon, 10 Feb 2020 16:10:59 GMT):
verkey

andrew.whitehead (Mon, 10 Feb 2020 16:14:08 GMT):
Is it set up to use the curve encryption?

jrallen (Mon, 10 Feb 2020 16:17:52 GMT):
my client is, yes.

jrallen (Mon, 10 Feb 2020 16:25:18 GMT):
I suspect my call to SetCurveServerkey is maybe wrong. I'm trying to do the same as Libindy, that is find the verkey for the validator from the genesis txn and then convert it to curve25519.

jrallen (Mon, 10 Feb 2020 16:27:26 GMT):
(but that's actually not robust: if all the nodes that I have in my genesis file have changed their verkey via updates in the pool chain, I'd never be able to connect and find out about their self-updates. Hmm.)

NikhilPrakash (Wed, 12 Feb 2020 00:48:14 GMT):
Has joined the channel.

FarhanShafiq (Fri, 14 Feb 2020 13:44:35 GMT):

FarhanShafiq - Fri Feb 14 2020 18:44:31 GMT+0500 (Pakistan Standard Time).txt

FarhanShafiq (Fri, 14 Feb 2020 13:44:59 GMT):
Facing issue, my nodes are shutdowns

FarhanShafiq (Fri, 14 Feb 2020 13:44:59 GMT):
Facing issue, my nodes are shutdown after running 3 months

ashcherbakov (Fri, 14 Feb 2020 14:34:33 GMT):
Please have a look if there are any errors in `journalctl`. Also please note, that the current indy-node versiomn is 1.12.2 which is much newer than the one run on your pool (1.9.2). So upgrade may make sense.

FarhanShafiq (Sat, 15 Feb 2020 18:17:01 GMT):
Thanks @ashcherbakov, sorry I don't know about journalctl so, can you tell where to find it and what it log? Is there any way to check the current pool version?

iamShashvat (Mon, 17 Feb 2020 08:39:47 GMT):
Has joined the channel.

lynn.bendixsen (Mon, 17 Feb 2020 15:25:46 GMT):
you can run `sudo journalctl -u indy-node` and `sudo journalctl -u indy-node-control` to see log info for indy-node itself and the update controller respectively. and you can run `sudo validator-info` to see the version information

futurama92 (Mon, 17 Feb 2020 20:17:34 GMT):
Has joined the channel.

jrallen (Wed, 19 Feb 2020 15:09:26 GMT):
Hello. I am getting "Given signature is not for current root hash, aborting" when trying to verify state proofs from the Sovrin builder net. Anyone interested in knowing more, helping me debug?

jrallen (Wed, 19 Feb 2020 16:13:30 GMT):
(I'm asking on Sovrin's chat instead, excuse the noise here.)

nacerix (Sun, 23 Feb 2020 14:34:44 GMT):
Has joined the channel.

gen_el (Mon, 24 Feb 2020 16:03:09 GMT):
Has joined the channel.

ashcherbakov (Mon, 24 Feb 2020 22:28:10 GMT):
@jrallen Currently this is expected behaviour that state proofs are not supported for the audit ledger. From the client point of view there is no error, reply is obtained via consensus fallback (to have enough equal replies). So, the only problem is that libindy logs may look a bit confusing in this case. More details in https://jira.hyperledger.org/browse/IS-1502

ashlinSajan (Mon, 02 Mar 2020 12:10:27 GMT):
@swcurran @andrew.whitehead Calling same function multiple times concurrently gives me the following error

ashlinSajan (Mon, 02 Mar 2020 12:10:41 GMT):

ERROR.png

ashlinSajan (Mon, 02 Mar 2020 12:11:24 GMT):
Is there any way using which I can solve the concurrency issue?

andrew.whitehead (Mon, 02 Mar 2020 15:59:00 GMT):
The built in IndyLedger class supports being 'opened' multiple times (it just stays open for a keepalive interval)

Vritra (Thu, 05 Mar 2020 04:46:30 GMT):
Has joined the channel.

bigworld12 (Thu, 05 Mar 2020 13:49:03 GMT):
Has joined the channel.

Abhishekkishor (Thu, 12 Mar 2020 19:30:27 GMT):
Has joined the channel.

kumar89 (Wed, 25 Mar 2020 17:24:46 GMT):
Has joined the channel.

mohammadhossein73 (Sun, 29 Mar 2020 05:48:10 GMT):
Has joined the channel.

swcurran (Fri, 03 Apr 2020 22:13:24 GMT):
What is the status of eliminating `indy-crypto` from Indy Node? I heard a rumour that @cam-parra had done a PR for this?

swcurran (Fri, 03 Apr 2020 22:13:24 GMT):
Question 1: What is the status of eliminating `indy-crypto` from Indy Node? I heard a rumour that @cam-parra had done a PR for this?

swcurran (Fri, 03 Apr 2020 22:23:49 GMT):
Question 2: How are people using ATTRIB in production use cases? Should support be included in frameworks to write anything to an ATTRIB, or should writes be constrained to identified use cases? This question relates to the concern of people writing non-DID-related data (e.g. illegal data like plans for making weapons). Should we be worried about that.

swcurran (Fri, 03 Apr 2020 22:23:49 GMT):
Opinions Wanted: How are people using ATTRIB in production use cases? Should support be included in frameworks to write anything to an ATTRIB, or should writes be constrained to identified use cases? This question relates to the concern of people writing non-DID-related data (e.g. illegal data like plans for making weapons). Should we be worried about that.

sergey.khoroshavin (Sun, 05 Apr 2020 07:48:58 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=2ijxker4gDQRzR6Z5) @swcurran Yes, there is a PR for this from @cam_parra, but it is far from being complete. I've done some improvements to it and going to push them to Cam's PR, but there are still unresolved problems, mostly with Ursa python wrapper (like it being unable to find libursa.so in standard locations because it is installed into non-standard location by ursa debian package, or for some reason wrapper itself failing to install from pip for python3, thats weird, but I tripple checked it in several different environments).

swcurran (Sun, 05 Apr 2020 21:52:57 GMT):
Thanks, @sergey.khoroshavin - much appreciated. @cam-parra - any thoughts on how to move this ahead? Do you have the time to do more on it? Can we have someone else work it? Or do we just keep maintaining indy-crypto?

swcurran (Sun, 05 Apr 2020 22:09:54 GMT):
@andrew.whitehead - perhaps you can help determine the state of things with this PR?

cam-parra (Mon, 06 Apr 2020 14:42:32 GMT):
So the problem is that we don't have a working artifact for URSA and to get one on repo.sovrin.org is a bit difficult since the people who can do it are a bit busy. Besides that we have found a way to use URSA on 16.04. If andrew wants to find a way to get URSA to work on pypi that would be great

rjones (Mon, 06 Apr 2020 14:53:23 GMT):
I have the ability to publish to PyPi in the hyperledger org, if that helps

andrew.whitehead (Mon, 06 Apr 2020 15:04:30 GMT):
For the record von-network uses indy-node with ursa (built from source), with a stub wrapper that pretends to be indy-crypto. I don't think I can do anything about debian packaging issues but I can look into the python packaging

rjones (Mon, 06 Apr 2020 15:06:08 GMT):
we're paying for bintray and artifactory, as well. @BrettLogan uses both to publish artifacts for Fabric, and Besu uses them.

BrettLogan (Mon, 06 Apr 2020 15:06:08 GMT):
Has joined the channel.

sergey.khoroshavin (Mon, 06 Apr 2020 19:01:11 GMT):
I've made required changes to cargo-deb config of libursa and successfully built and uploaded deb artifact to repo.sovrin.org, so as of now the only problem is with ursa python wrapper. It still refuses to install from pypi, but when installed manually it correctly works with updated deb package

sergey.khoroshavin (Mon, 06 Apr 2020 19:03:54 GMT):
Changes to libursa can be found in this PR: https://github.com/hyperledger/ursa/pull/108

sergey.khoroshavin (Tue, 07 Apr 2020 18:01:11 GMT):
For the record - I raised an issue in python-ursa wrapper describing problem with installation from PyPi: https://github.com/hyperledger/ursa-python/issues/4

andrew.whitehead (Tue, 07 Apr 2020 18:08:15 GMT):
The only uploaded package is a wheel for python 2 https://pypi.org/project/python-ursa/#files

andrew.whitehead (Tue, 07 Apr 2020 18:43:54 GMT):
@sergey.khoroshavin I'd suggest somebody upload a source package for python 3

rjones (Tue, 07 Apr 2020 19:08:03 GMT):
could [this github action](https://github.com/hyperledger/ursa-python/blob/master/.github/workflows/pythonpublish.yml) be changed to make that happen?

andrew.whitehead (Tue, 07 Apr 2020 19:19:41 GMT):
The repo doesn't have any releases so I don't think that's been run

rjones (Tue, 07 Apr 2020 19:21:34 GMT):
should I create one? like a 0.0.1?

andrew.whitehead (Tue, 07 Apr 2020 19:22:25 GMT):
You could try creating a 0.1.0 release, that's the current version

rjones (Tue, 07 Apr 2020 19:22:58 GMT):
`v0.1.0` - correct?

andrew.whitehead (Tue, 07 Apr 2020 19:23:21 GMT):
Yeah that's the convention github recommends

rjones (Tue, 07 Apr 2020 19:29:51 GMT):
When [this is merged](https://github.com/hyperledger/ursa-python/pull/5), I'll try again. @cam-parra

andrew.whitehead (Tue, 07 Apr 2020 19:31:14 GMT):
Is that necessary? It should just add the missing packages

andrew.whitehead (Tue, 07 Apr 2020 19:32:16 GMT):
Confirmed I can install it with pip now

rjones (Tue, 07 Apr 2020 19:33:17 GMT):
I got an error when it tried to publish to PyPi

rjones (Tue, 07 Apr 2020 19:33:23 GMT):
OK, I'll kill it

rjones (Tue, 07 Apr 2020 19:34:06 GMT):
https://pypi.org/project/python-ursa/#files shows the python 3 file.

andrew.whitehead (Tue, 07 Apr 2020 19:37:08 GMT):
It added the wheel but normally there's a source package as well, so that's probably the error

rjones (Tue, 07 Apr 2020 19:37:46 GMT):
the issue was it couldn't upload the python2 version of the wheel because it already existed.

rjones (Tue, 07 Apr 2020 19:39:10 GMT):
``` Uploading python_ursa-0.1.0-py3-none-any.whl 0%| | 0.00/12.5k [00:00

andrew.whitehead (Tue, 07 Apr 2020 19:39:39 GMT):
Right, it doesn't allow repeated uploads

rjones (Tue, 07 Apr 2020 19:40:06 GMT):
is it important that we're missing the source, or is this what was needed?

andrew.whitehead (Tue, 07 Apr 2020 19:40:21 GMT):
I think this one is sufficient

FarhanShafiq (Fri, 10 Apr 2020 14:23:39 GMT):
Transaction response has not been received I'm trying to execute nym transaction but this error is occuring. Can anybody help me?

FarhanShafiq (Mon, 13 Apr 2020 13:32:24 GMT):
Unable to get the stable version of bionic. Keep getting the same issue of unable to write transaction on ledger.

iamShashvat (Wed, 15 Apr 2020 05:33:55 GMT):
I was also thinking the same that people will misuse this data field, but if you put constrain, you have to take multiple consideration. It's better to define ATTRIB further down into ServiceEndpoints[] and PublicKeys[] because according to W3, these are the information that a DID can put/update their-self.

FarhanShafiq (Wed, 15 Apr 2020 10:07:39 GMT):
Can anybody please help me, I'm stuck with unable to write transaction on ledger. Using indy-node 1.12.2 and indy-plenum 1.12.2 xaniel

FarhanShafiq (Wed, 15 Apr 2020 10:07:39 GMT):
Can anybody please help me? I'm stuck with unable to write transaction on ledger. Using indy-node 1.12.2 and indy-plenum 1.12.2 xaniel

RicardoPeixoto (Mon, 20 Apr 2020 14:40:57 GMT):
Has joined the channel.

swcurran (Thu, 23 Apr 2020 21:11:27 GMT):
Hey folks - interested in contributing to Indy Revocation 2? We have posted a couple of Help Wanted issues for tech spikes into our revocation plans. These are for one or two standalone programs (any language!) to test out the ideas we have for revocation - think of them as assignments you would get in a Computer Science class on algorithms and data structures. If you can spare a 1/2 to 1 day to help out, that would probably do it! Issues are here: https://github.com/hyperledger/indy-node/issues, with the ones I'm talking about tagged with "Help Wanted". Questions welcome, contributions even more so!

akshay.sood (Sat, 25 Apr 2020 07:53:59 GMT):
Hi guys I tried to run indy pool sandbox with volume. I mounted the path sandbox/indy: /var/lib/indy/sanbox but it does not work. The indy pool does not work with volume. However, it works perfectly fine without a volume. I tried both Kubernetes & Docker. Does anyone knows the issue?

akshay.sood (Sat, 25 Apr 2020 07:53:59 GMT):
Hi guys I tried to run indy pool sandbox with volume. I mounted the path ./indy: /var/lib/indy/sandbox but it does not work. The indy pool does not work with volume. However, it works perfectly fine without a volume. I tried both Kubernetes & Docker. Does anyone knows the issue?

akshay.sood (Sat, 25 Apr 2020 07:53:59 GMT):
Hi guys I tried to run indy pool sandbox with volume. I mounted the path ./indy:/var/lib/indy/sandbox on docker but it does not work. The indy pool does not work with volume. However, it works perfectly fine without a volume. I tried both Kubernetes & Docker. Does anyone knows the issue?

akshay.sood (Sat, 25 Apr 2020 07:53:59 GMT):
Hi guys I tried to run indy pool sandbox with volume. I mounted the path ./indy:/var/lib/indy/sandbox on docker, but it does not work. The indy pool does not work with volume. However, it works perfectly fine without a volume. I tried both Kubernetes & Docker. Does anyone know the issue?

akshay.sood (Sat, 25 Apr 2020 07:53:59 GMT):
Hi guys I tried to run indy pool sandbox with volume. I mounted the path ./indy:/var/lib/indy/sandbox on docker, but it does not work. The indy pool does not work with volume. However, it works perfectly fine without a volume. I tried both Kubernetes & Docker. Does anyone know the issue? When I open the directory with volume mounted: /var/lib/indy/sanbox, it is empty. But when I open the same directory without volume, it has data in it

andrew.whitehead (Sat, 25 Apr 2020 19:56:19 GMT):
You might need to create the directory in your dockerfile, before it is mounted

swcurran (Sat, 25 Apr 2020 20:42:00 GMT):
Issues like that are usually docker permission issues. If you don't pre-create the folders and make them rw for others, Docker creates them as the container spins up. If Docker creates them, they are owned by root, and the user inside the container can't access them.

akshay.sood (Sun, 26 Apr 2020 06:35:48 GMT):
@swcurran I can see inside the container, the owner of `/var/lib/indy` is indy

akshay.sood (Sun, 26 Apr 2020 06:35:48 GMT):
@swcurran I can see inside the container, the owner of `/var/lib/indy` is user `indy`

akshay.sood (Sun, 26 Apr 2020 06:35:48 GMT):
@swcurran I saw inside the container, the owner of `/var/lib/indy` is user `indy`

akshay.sood (Sun, 26 Apr 2020 06:35:48 GMT):
@swcurran I saw inside the container, the owner of `/var/lib/indy` is user `indy` not root

akshay.sood (Sun, 26 Apr 2020 06:35:48 GMT):
@swcurran I saw inside the container, the owner of `/var/lib/indy` is user `indy` not `root`

akshay.sood (Sun, 26 Apr 2020 13:49:48 GMT):
I have added this on stackoverflow: https://stackoverflow.com/questions/61437680/hyperledger-indy-data-is-not-being-mounted-in-kubernetes-volume-directory

akshay.sood (Mon, 27 Apr 2020 15:01:09 GMT):
I tried this but it did not work

akshay.sood (Mon, 27 Apr 2020 15:01:09 GMT):
@andrew.whitehead I tried this but it did not work

SUSHOBHAN (Wed, 29 Apr 2020 16:01:13 GMT):
Has joined the channel.

ken5scal (Wed, 06 May 2020 14:53:49 GMT):
Has joined the channel.

carlojbs (Tue, 12 May 2020 17:55:44 GMT):
Has joined the channel.

carlojbs (Tue, 12 May 2020 17:55:45 GMT):
Hello Everyone, I need some help understanding an error I'm seeing on the log for one of the nodes. Essentially one of the nodes 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.

BrettLogan (Wed, 13 May 2020 01:35:02 GMT):
Has left the channel.

anchit (Thu, 21 May 2020 17:15:28 GMT):
Has joined the channel.

aguel (Fri, 29 May 2020 08:55:22 GMT):
Has left the channel.

Primordium (Sat, 11 Jul 2020 22:33:22 GMT):
Has joined the channel.

Primordium (Sat, 11 Jul 2020 22:33:23 GMT):
During installation on a fresh ubuntu 16.04 setup I get the following error `/var/lib/dpkg/info/indy-node.postinst: line 116: /etc/supervisor/indy-node.conf: No such file or directory grep: /etc/indy/node_control.conf: No such file or directory` will this be an issue in the future?

Primordium (Mon, 13 Jul 2020 10:55:07 GMT):
Hi guys, I did a fresh install on ubuntu 16.04, my setup right now is 4 machines, each running one node. I did the following steps : 1. Install using deb packages. 2. Change NETWORK_NAME on all machines from /etc/indy/indy_config.py 3. RUN generate_indy_pool_transactions --nodes 4 --clients 5 --nodeNum 1 --ips 'ip1,ip2,ip3,ip4' --network=mynetwork 4. Start node on all machines 5 . Run Validator-info. Output: ``` ubuntu@vm-blk-node1:~$ sudo validator-info Validator Node1 is stopped Update time: Monday, July 13, 2020 10:40:26 AM +0000 Validator DID: Gw6pDLhcBcoQesN72qfotTgFa7cbuqZpkX3Xo6pLhPhv Verification Key: 33nHHYKnqmtGAVfZZGoP8hpeExeH45Fo8cKmd5mcnKYk7XgWNBxkkKJ BLS Key: 4N8aUNHSgjQVgkpm8nhNEfDf6txHznoYREg9kirmJrkivgL4oSEimFF6nsQ6M41QvhM2Z33nves5vfSn9n1UwNFJBYtWVnHYMATn76vLuL3zU88KyeAYcHfsih3He6UHcXDxcaecHVz6jhCYz1P2UZn2bDVruL5wXpehgBfBaLKm3Ba Node HA: 0.0.0.0:9701 Client HA: 0.0.0.0:9702 Metrics: Uptime: 4 seconds Total ledger Transactions: 10 Total pool Transactions: 4 Total config Transactions: 0 Total audit Transactions: 3 Read Transactions/Seconds: 0.00 Write Transactions/Seconds: 0.00 Reachable Hosts: 4/4 Node2 (1) Node3 Node1 (0) Node4 Unreachable Hosts: 0/4 Software Versions: indy-node: 1.12.3 sovrin: unknown ``` I expected that Validator to be running, but it's stopped. Do I need any extra step to get it running?

Primordium (Mon, 13 Jul 2020 14:32:16 GMT):
Sorry, I was not able so far to connect, maybe vpn is blocking

Primordium (Mon, 13 Jul 2020 14:32:40 GMT):
but maybe you can answer me

Primordium (Mon, 13 Jul 2020 14:32:59 GMT):
in this doc https://docs.google.com/document/d/18MNB7nEKerlcyZKof5AvGMy0GP9T82c4SWaxZkPzya4/edit#heading=h.il4b7xijujxy , in the point 3.2 it says to isntall sovrin to have a validator

Primordium (Mon, 13 Jul 2020 14:33:10 GMT):
i never did that step, maybe it would solve it ?

lynn.bendixsen (Mon, 13 Jul 2020 22:48:53 GMT):
No that is not a problem unless you are running the Node in a docker

lynn.bendixsen (Mon, 13 Jul 2020 22:58:04 GMT):
Its hard to tell for sure without seeing the log file (/var/log/indy//Node1.log) but it looks like you might be missing a domain_transactions_genesis file. When building a multi server pool, you can use the following to create the genesis files and then copy them into the /var/lib/indy/ directory (you might need to create the dir) with ownership as indy:indy. https://github.com/sovrin-foundation/steward-tools/tree/master/create_genesis

SethiSaab (Tue, 14 Jul 2020 09:03:57 GMT):
Has joined the channel.

SethiSaab (Tue, 14 Jul 2020 09:03:58 GMT):
Hi Guys , I want to setup the indy node ... could someone please help me with that .. by providing some references

tomislav (Tue, 14 Jul 2020 17:49:37 GMT):
You can simply build and run the docker image at https://github.com/hyperledger/indy-sdk/tree/master/ci ``` docker build -f indy-pool.dockerfile -t indy_pool . docker run -itd -p 9701-9709:9701-9709 indy_pool ```

WadeBarnes (Tue, 14 Jul 2020 17:55:21 GMT):
If you just want a provisional ledger for test purposes you could use; https://github.com/bcgov/von-network

WadeBarnes (Tue, 14 Jul 2020 17:59:30 GMT):
Hosted example; http://dev.bcovrin.vonx.io/

SethiSaab (Wed, 15 Jul 2020 04:36:21 GMT):
I want to set it up for production level

SethiSaab (Wed, 15 Jul 2020 04:36:43 GMT):
Thanks for you help guys ... Please guide me as i want to setit up for production level

WadeBarnes (Wed, 15 Jul 2020 13:34:04 GMT):
@lynn.bendixsen, Any good resources we can share? ^

lynn.bendixsen (Wed, 15 Jul 2020 14:39:22 GMT):
I created this document a while ago that might help you get started: https://docs.google.com/document/d/1XE2QOiGWuRzWdlxiI9LrG9Am9dCfPXBXnv52wGHorNE

FarhanShafiq (Wed, 22 Jul 2020 08:31:22 GMT):
Has left the channel.

Mahadevan 3 (Thu, 23 Jul 2020 04:35:51 GMT):
Has joined the channel.

JakeZ2020 (Mon, 27 Jul 2020 14:58:02 GMT):
Has joined the channel.

RobinKlemens (Wed, 29 Jul 2020 14:36:02 GMT):
Has joined the channel.

RobinKlemens (Wed, 29 Jul 2020 14:36:03 GMT):
Hi folks, I try to get an Indy node as part of a bigger consortium run on OpenShift. However, I could start the Indy node, and as far as I can say it seems to work properly. However, I'm not able to run the helper scripts, e.g. validator-info, because of some ownership issues. I created the indy group and user but the script fails with the following error: ```$ validator-info Cannot set owner of /var/log/indy/validator-info.log file to indy The owner of /var/log/indy/validator-info.log must be indy:indy $ ls -l /var/log/indy/validator-info.log -rw-r--r--. 1 indy indy 0 Jul 29 14:27 /var/log/indy/validator-info.log``` I'm using this repo: `deb [arch=amd64] https://repo.sovrin.org/deb xenial stable` I'd appreciate any help. Thanks /Robin

RobinKlemens (Wed, 29 Jul 2020 14:36:03 GMT):
Hi folks, I try to get an Indy node as part of a bigger consortium running on OpenShift. However, I could start the Indy node, and as far as I can say it seems to work properly. However, I'm not able to run the helper scripts, e.g. validator-info, because of some ownership issues. I created the indy group and user but the script fails with the following error: ```$ validator-info Cannot set owner of /var/log/indy/validator-info.log file to indy The owner of /var/log/indy/validator-info.log must be indy:indy $ ls -l /var/log/indy/validator-info.log -rw-r--r--. 1 indy indy 0 Jul 29 14:27 /var/log/indy/validator-info.log``` I'm using this repo: `deb [arch=amd64] https://repo.sovrin.org/deb xenial stable` I'd appreciate any help. Thanks /Robin

WadeBarnes (Wed, 29 Jul 2020 15:10:51 GMT):
@RobinKlemens, how are you dealing with (or plan on dealing with) the `IP:PORT` addressing issue? https://github.com/bcgov/von-network/tree/master/openshift#warning

WadeBarnes (Wed, 29 Jul 2020 15:10:51 GMT):
@RobinKlemens, how are you dealing with (or plan on dealing with) the `IP:PORT` addressing issues? https://github.com/bcgov/von-network/tree/master/openshift#warning

WadeBarnes (Wed, 29 Jul 2020 15:10:51 GMT):
@RobinKlemens, how are you dealing with the `IP:PORT` addressing issue? https://github.com/bcgov/von-network/tree/master/openshift#warning

WadeBarnes (Wed, 29 Jul 2020 15:13:00 GMT):
The way the two (OpenShift and Indy-Node) are designed to handle addressing is incompatable.

WadeBarnes (Wed, 29 Jul 2020 15:19:37 GMT):
As far as the permissions go you need to ensure they are setup so things are able to run under the control of a non-previlaged user in OpenShift. Examples of what we do; https://github.com/PSPC-SPAC-buyandsell/von-image/blob/master/node-1.9/Dockerfile.ubuntu#L247 Although we're setting things up in different directories, so you'll have to adjust things for the more standard installation latyout.

RobinKlemens (Wed, 29 Jul 2020 15:32:54 GMT):
@WadeBarnes, our setup goes as follows. 1 Pod with 1 container running indy node & pvc to store data persistently. 1 Service which references the pod. 2 routes with target ports 9701 and 9702. As routes are provided only as DNS in OpenShift we use an ISGW with plain layer 4 nat (reverse proxy). Thus, we get a static IP:PORT addressing. Thanks for providing the link to your docker file. I'll try and adapt the permission section and will come back with feedback tomorrow.

RobinKlemens (Wed, 29 Jul 2020 15:35:23 GMT):
That's how I tried to fix the permission issues: ```# Fix permission for OpenShift RUN chgrp -R 0 /var/lib/indy/ \ && chmod -R g=u /var/lib/indy/ \ && chgrp -R 0 /var/log/indy/ \ && chmod -R g=u /var/log/indy/ \ && chgrp -R 0 /etc/indy/ \ && chmod -R g=u /etc/indy/ \ && chgrp -R 0 /etc/passwd \ && chmod -R g=u /etc/passwd \ && chgrp -R 0 /etc/group \ && chmod -R g=u /etc/group ```

RobinKlemens (Wed, 29 Jul 2020 15:35:49 GMT):
And in the running container I executed ```echo "indy:x:$(id -u):$(id -g):,,,:$HOME:/bin/bash" >> /etc/passwd echo "indy:x:$(id -G | cut -d' ' -f 2)" >> /etc/group```

WadeBarnes (Wed, 29 Jul 2020 15:38:02 GMT):
The indy-node processes want to run as the `indy` user so you need to do this; https://github.com/PSPC-SPAC-buyandsell/von-image/blob/master/node-1.9/Dockerfile.ubuntu#L250

WadeBarnes (Wed, 29 Jul 2020 15:39:34 GMT):
Then update ownership and make some things read/write; https://github.com/PSPC-SPAC-buyandsell/von-image/blob/master/node-1.9/Dockerfile.ubuntu#L265

RobinKlemens (Wed, 29 Jul 2020 15:45:54 GMT):
How are you dealing with IP:PORT? Instead of using two routes you could also use one egress loading balacer.

WadeBarnes (Wed, 29 Jul 2020 15:53:29 GMT):
We don't host any ledgers/nodes in OpenShift do to the complications. The ledger instances are meant to be made up of muliple nodes running as a network.

WadeBarnes (Wed, 29 Jul 2020 15:53:29 GMT):
We don't host any ledgers/nodes in OpenShift do to the complications. The ledger instances are meant to be made up of multiple nodes running as a network.

WadeBarnes (Wed, 29 Jul 2020 15:53:54 GMT):
We host all of our client services in OpenShift.

WadeBarnes (Wed, 29 Jul 2020 15:56:46 GMT):
It's far easier to run a provisional ledger in AWS or Digital Ocean for testing, and then use one of the Sorin ledgers when things need to interoperate with a larger set of agents, and then use Sovrin MainNet for production applications.

WadeBarnes (Wed, 29 Jul 2020 15:59:20 GMT):
We host a few provisional ledgers which are instances of `von-network` running in Digital Ocean. http://dev.bcovrin.vonx.io/ http://test.bcovrin.vonx.io/

RobinKlemens (Wed, 29 Jul 2020 16:05:21 GMT):
So true... We also run one provisional ledger in DigitalOcean. It works like charm. However, due to IT-security guidelines, we're somehow forced to host the indy node in OpenShift. For many use cases, the Sovrin MainNet is a great fit. Nonetheless, in the consortium, I contribute to, we want to an SSI network for Germany/Europe

WadeBarnes (Wed, 29 Jul 2020 16:06:58 GMT):
I don't see OpenShift being a good fit for a hosting platform for a fully functional indy-node network (ledger).

WadeBarnes (Wed, 29 Jul 2020 16:07:49 GMT):
The static vs dynamic IP assignment simple complicates things too much.

RobinKlemens (Wed, 29 Jul 2020 16:08:38 GMT):
It will be just us and maybe a few more participants of the consortium hosting their nodes in OpenShift. Most of them use aws, azure etc., and on premise

RobinKlemens (Wed, 29 Jul 2020 16:10:58 GMT):
I agree with you. The static ip:port stuff requires a lot of overhead... Do you know, why Indy doesn't support DNS in the hell of changing IP addresses due to cloud computing?

WadeBarnes (Wed, 29 Jul 2020 16:11:00 GMT):
If you are only hosting a single node in OpenShift that is connecting to a larger network, as you say, it's doable, but it adds so many additional layers.

RobinKlemens (Wed, 29 Jul 2020 16:12:05 GMT):
jup... At the moment it's the only way for me to participate in the network... Hopefully, things gonna change in the future

RicardoPeixoto (Thu, 06 Aug 2020 14:16:00 GMT):
Hi, could someone point me some documents that explain what strategy is used by hyperledger to help with efficient metadata search in the blockchain?

esplinr (Thu, 06 Aug 2020 17:34:12 GMT):
As an identity focused ledger, there isn't a lot of use cases for metadata search on Indy Node. We have an index where we store keys for specific use cases (searching for a specific transaction author agreement), but I'm not aware of anything else.

saanvijay (Sun, 16 Aug 2020 16:35:59 GMT):
Has joined the channel.

Primordium (Mon, 31 Aug 2020 16:13:34 GMT):
I'm trying to add a new machine to my pool as shown in https://hyperledger-indy.readthedocs.io/projects/node/en/latest/add-node.html But when I start the new node with sudo systemctl start indy-node the status shows it fails after a few seconds. The other nodes are still on version 1.12.3 the newnode 1.12.4, is there a conflict there ? Also does the ports need to be different in everynode ? I reuse use the same ones as other node, but they are running on different machinces.

lynn.bendixsen (Mon, 31 Aug 2020 19:02:49 GMT):
The versions should be the same for all nodes. I am not sure that is your problem though as I think those 2 versions might be compatible... The ports can be the same on every node. Send more logs or info?

Xand (Thu, 03 Sep 2020 13:59:43 GMT):
Has joined the channel.

chakshujain (Mon, 07 Sep 2020 02:34:30 GMT):
Has joined the channel.

paul.bastian (Tue, 08 Sep 2020 11:45:53 GMT):
Has joined the channel.

akshay.sood (Mon, 28 Sep 2020 14:24:02 GMT):
Hi experts Does anyone know the steps to our own indy pool and create nodes? I am having hard time to find steps

WadeBarnes (Mon, 28 Sep 2020 15:00:52 GMT):
The steps differ depending no the intended purpose. What is your intended use of the node pool?

akshay.sood (Mon, 28 Sep 2020 15:01:33 GMT):
It is for using nodes and stewards with different seeds

WadeBarnes (Mon, 28 Sep 2020 15:04:41 GMT):
I'm not sure I fully understand what that means. From a high level what is it that you are trying to accomplish (do)? Please provide details.

akshay.sood (Mon, 28 Sep 2020 15:06:00 GMT):
When we generate indy pool transaction, it creates the configuration with predefined seed which can be used by anyone and connect to the network. I want to define my own seeds not the test network

WadeBarnes (Mon, 28 Sep 2020 15:08:07 GMT):
What instructions are you following currently?

akshay.sood (Mon, 28 Sep 2020 15:08:40 GMT):
https://hyperledger-indy.readthedocs.io/projects/node/en/latest/start-nodes.html

akshay.sood (Mon, 28 Sep 2020 15:09:03 GMT):
I do not know how to generate pool_transactions_genesis & domain_transactions_genesis

lynn.bendixsen (Mon, 28 Sep 2020 15:19:10 GMT):
These instructions have a link to the genesis node creation script https://docs.google.com/document/d/1XE2QOiGWuRzWdlxiI9LrG9Am9dCfPXBXnv52wGHorNE/edit

lynn.bendixsen (Mon, 28 Sep 2020 15:19:10 GMT):
These instructions have a link to the genesis file creation script https://docs.google.com/document/d/1XE2QOiGWuRzWdlxiI9LrG9Am9dCfPXBXnv52wGHorNE/edit

lynn.bendixsen (Mon, 28 Sep 2020 15:19:10 GMT):
These instructions have a link to the genesis file creation script https://docs.google.com/document/d/1XE2QOiGWuRzWdlxiI9LrG9Am9dCfPXBXnv52wGHorNE

WadeBarnes (Mon, 28 Sep 2020 15:20:16 GMT):
What is the intended end use for the ledger once you have it up and running? Is this for testing purposes or more for a production level ledger. The document that @lynn.bendixsen provided is for creating a new production level ledger.

akshay.sood (Mon, 28 Sep 2020 15:20:38 GMT):
It is kind of production usage

WadeBarnes (Mon, 28 Sep 2020 15:21:17 GMT):
Then the instructions above are the ones you want to follow.

WadeBarnes (Mon, 28 Sep 2020 15:21:17 GMT):
Thn the instructions above are the ones you want to follow.

WadeBarnes (Mon, 28 Sep 2020 15:21:17 GMT):
In that case, the instructions above are the ones you want to follow.

WadeBarnes (Mon, 28 Sep 2020 15:23:13 GMT):
Just be aware, currently, nodes and agents connected to a particular ledger are unable to interact with agents connected to another ledger. There is work being done on network interoperability.

WadeBarnes (Mon, 28 Sep 2020 15:23:13 GMT):
Just be aware, currently, nodes and agents connected to a particular ledger are unable to interact with agents connected to another ledger. There is work being done on network interoperability. So eventually this won't be an issue.

akshay.sood (Mon, 28 Sep 2020 15:23:47 GMT):
Sure @WadeBarnes

WadeBarnes (Mon, 28 Sep 2020 15:25:03 GMT):
If you're looking for the most interoperability at the point, you'll want to look at the Sovrin ledgers.

WadeBarnes (Mon, 28 Sep 2020 15:27:05 GMT):
They are secure, full distributed, and fully HA. Each node on each of the networks is hosted and maintained by a dedicated Steward (a company or organization with formal agreements with the Sovrin Foundation). A list of Stewards can be found on the [Sovrin](https://sovrin.org/) website. - For dev environments there is [BuilderNet](https://raw.githubusercontent.com/sovrin-foundation/sovrin/stable/sovrin/pool_transactions_builder_genesis) - For test/staging environments there is [StagingNet](https://raw.githubusercontent.com/sovrin-foundation/sovrin/stable/sovrin/pool_transactions_sandbox_genesis) - For production environments there is [MainNet](https://raw.githubusercontent.com/sovrin-foundation/sovrin/stable/sovrin/pool_transactions_live_genesis) You can register DIDs on BuilderNet and StagingNet here; https://selfserve.sovrin.org/

akshay.sood (Mon, 28 Sep 2020 15:29:18 GMT):
Sure @WadeBarnes. Thanks

Jussihoo (Mon, 05 Oct 2020 13:14:13 GMT):
Has joined the channel.

Jussihoo (Mon, 05 Oct 2020 13:14:13 GMT):
Hello all, I have a questions about changing / rotating keys for Indy nodes. Background shortly: We are running out own Indy pool, where we have currently four nodes. This indy pool and nodes were set-up initially with the sandbox test keys using the "generate_indy_pool_transactions" command. Question: I did some googling and I could not found anything about rotating the node keys so that nodes would not have to restarted, genesis file to be manually updated and deliver the updated genesis file to clients. So it looks like this has to be manually using the "init_indy_keys" command. I used this command and got different keys as an output. In the pool_transactions_genesis file I need to then update the information for each node what comes to the following fields: "blskey" "blskey_pop" "dest" So far I know what keys map into these fields, but what about the "metadata":{"from": field in the pool_transactions_genesis? Should that be changed and where can I find the hash for that? And similarly, what about "txnId" field in the genesis file? Let's say I updated Node4 keys using the "init_indy_keys" and I succesfully updated the pool_transaction_genesis file. Should I also update Node4 keys in all other node's /keys folder? Is it really so that this is basically the only way to rotate keys? Any improvements on the roadmap for this? Thanks in advance!

Jussihoo (Mon, 05 Oct 2020 13:14:13 GMT):
Hello all, I have a questions about changing / rotating keys for Indy nodes. Background shortly: We are running our own Indy pool, where we have currently four nodes. This indy pool and nodes were set-up initially with the sandbox test keys using the "generate_indy_pool_transactions" command. Question: I did some googling and I could not found anything about rotating the node keys so that nodes would not have to restarted, genesis file to be manually updated and deliver the updated genesis file to clients. So it looks like this has to be manually using the "init_indy_keys" command. I used this command and got different keys as an output. In the pool_transactions_genesis file I need to then update the information for each node what comes to the following fields: "blskey" "blskey_pop" "dest" So far I know what keys map into these fields, but what about the "metadata":{"from": field in the pool_transactions_genesis? Should that be changed and where can I find the hash for that? And similarly, what about "txnId" field in the genesis file? Let's say I updated Node4 keys using the "init_indy_keys" and I succesfully updated the pool_transaction_genesis file. Should I also update Node4 keys in all other node's /keys folder? And what about the domain_transactions_genesis file, how should that be modified? Is it really so that this is basically the only way to rotate keys? Any improvements on the roadmap for this? Thanks in advance!

kh_touati (Wed, 07 Oct 2020 08:14:43 GMT):
Has joined the channel.

kh_touati (Wed, 07 Oct 2020 08:14:43 GMT):
Hi all, I am trying to create a customized indy network where I have to specify the number of validator nodes and their Ip-addresses in order to deploy them. I am trying to upgrade the von-network project in order to do this. I am wondering if this will be the best apporach or I have to create it directly based on indy-node. Otherwise, I wanted also to check if there are some tutorials that may help to understand the different steps to add a node to the von_netowrk (ie: add node5_1) Thanks in advance

kh_touati (Wed, 07 Oct 2020 08:14:43 GMT):

kh_touati (Wed, 07 Oct 2020 15:05:53 GMT):
z

kh_touati (Wed, 07 Oct 2020 15:08:34 GMT):

Clipboard - 7 octobre 2020 17:08

kh_touati (Wed, 07 Oct 2020 15:08:54 GMT):
Hi all, I am trying to use the von_network inn order to create an indy network based on 5 nodes. I did some updates and the node are well deployed with the needed keys and the pool genesis transaction. However, I got a problem to run the von_webserver container Have any idea about how to resolve this issue thanks

WadeBarnes (Wed, 07 Oct 2020 15:27:52 GMT):
Please create an issue in the `von-network` repository so we can better track the issue and the resolution. Thanks

kh_touati (Wed, 07 Oct 2020 15:36:17 GMT):
Thanks WadeBarnes, I will do it

lynn.bendixsen (Thu, 08 Oct 2020 17:58:21 GMT):
I am working on writing a GDPR compliant governance framework. A feature called "Tombstoning" has been proposed in the past that helps with part of that, but has not yet been completed. Does anyone know the status of the "Tombstone" feature? In the meantime, it would be nice to be able to document or incorporate a proposed "manual" method to do "Tombstoning" until the feature is available. Is that possible? If so, how? Perhaps a whitepaper or document is already written? @sergey.khoroshavin? @Toktar? or @esplinr?

esplinr (Thu, 08 Oct 2020 20:46:27 GMT):
https://jira.hyperledger.org/browse/INDY-2082

esplinr (Thu, 08 Oct 2020 20:47:37 GMT):
https://docs.google.com/document/d/1gfIz5TT0cNp2kxGMLFXr19x1uoZsruUe_0glHst2fZ8/edit#heading=h.q1jlwma6qomv

lynn.bendixsen (Thu, 08 Oct 2020 23:33:10 GMT):
Thx Richard, now all we need is a workaround to use while it gets implemented... Is there one?

esplinr (Thu, 08 Oct 2020 23:46:04 GMT):
Individual stewards could do a variety of things to block access to specific requests. That will force requestors to try a different validator in the pool. I am uncomfortable with the idea that stewards can refuse to respond to some requests, and I would advocate that the governance framework of an Indy ledger forbids that.

lynn.bendixsen (Fri, 09 Oct 2020 15:55:39 GMT):
How does a Steward comply with GDPR or other local laws if the framework forbids it? Even the sovrin Framework has a clause in it (referring to the unwritten tombstone feature) so that it can be GDPR compliant. I don't see how any framework can "forbid" it, based on the fact that a "mistake" could easily be made on a ledger which might put it in violation. Please explain?

esplinr (Sat, 10 Oct 2020 00:27:46 GMT):
The governance framework should forbid individual stewards tampering with data or selectively responding to requests, which would be required to do something like tombstoning without recording that tombstone on the ledger.

esplinr (Sat, 10 Oct 2020 00:27:57 GMT):
The advantage to an actual tombstone is that there is a record and governance around it.

esplinr (Sat, 10 Oct 2020 00:28:23 GMT):
My concern is with attempts to "workaround it".

esplinr (Sat, 10 Oct 2020 00:29:02 GMT):
Also, even though people regularly ask about tombstones, and say it is important, no one to my knowledge cares enough to implement it.

ZappaBoy (Sun, 11 Oct 2020 12:57:24 GMT):
Has joined the channel.

kh_touati (Tue, 20 Oct 2020 11:09:59 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

mirgee (Thu, 22 Oct 2020 09:36:18 GMT):
Has joined the channel.

RicardoPeixoto (Mon, 26 Oct 2020 00:30:31 GMT):
Hi, can someone help me map the Indy Node roles to real life entities? Who would perform the trustee, steward, endorser and monitor?

lynn.bendixsen (Mon, 26 Oct 2020 15:06:10 GMT):
Trustee- A person who is either a member of the Board of Trustees (the way Sovrin Foundation does it) or another volunteer from a relevant organization interested in making sure the network was well managed. Steward - an organization willing to donate and operate a node. The organization typically pays employees to monitor and manage their node using their organizations Steward DID. Endorser - An organization willing to take on the legal obligation and effort required to assist Transaction Authors to write items to a ledger. They may also write their own txns and this is the reason that some of them want to become an endorser. The organization will assign employees or contractors to act in their behalf with their Endorser DID. Network Monitor - An personwho has been assigned to make sure that a node or the whole network continues operating efficiently. They get access to more information than is generally available to the public users. Summary - some roles are generally considered "organization" roles and others are considered to be owned by an individual as shown above.

RicardoPeixoto (Mon, 26 Oct 2020 20:27:01 GMT):
Thank you very much. Your answer was exactly what i was looking for :)

mickra (Wed, 28 Oct 2020 10:26:04 GMT):
Has joined the channel.

troyronda (Wed, 28 Oct 2020 17:42:42 GMT):
Has left the channel.

askolesov (Mon, 09 Nov 2020 10:37:36 GMT):
Has joined the channel.

rewaj7 (Sun, 15 Nov 2020 11:13:51 GMT):
Has joined the channel.

rewaj7 (Sun, 15 Nov 2020 11:18:49 GMT):
Hi all, I've recently restarted working on a project. I am running my nodes in a docker container on a server but I have found that I cannot communicate with the ledger from the CLI or the SDK, resulting in a timeout error as no response received. I am confident the genesis file is correct as I copied it from the container and through the SDK I can at least open the pool ledger but cannot sign and submit nym requests. Thank you!

dgt1nsty (Tue, 17 Nov 2020 06:26:10 GMT):
Has joined the channel.

Dan (Wed, 18 Nov 2020 19:54:22 GMT):
Has left the channel.

dgt1nsty (Fri, 20 Nov 2020 08:19:08 GMT):
Hi, I am trying to build indy-node dev setup usign Quick Setup on Ubuntu 16.04 guide but at 7th sterp I couldn't create a virtual environment, I'm getting the following error:"AttributeError: module 'os' has no attribute 'PathLike". I wonder if anyone has come across this error before and knows how to fix it?

smithbk (Tue, 01 Dec 2020 15:22:53 GMT):
@WadeBarnes @esplinr Can anyone help? Our CI is broken because of the following change in indy-plenum: ```commit 0c686d082f93f20de3cd84432bc06687adae0c49 Author: Alexandr Kolesov Date: Thu Nov 19 16:39:41 2020 +0300 Synchronized versions of dependencies in Jenkinsfile.cd and .deb build script Signed-off-by: Alexandr Kolesov ``` Using https://github.com/hyperledger/indy-sdk/blob/master/ci/indy-pool.dockerfile to build an image now fails as follows: ```Step 9/22 : ARG indy_plenum_ver=1.12.1~dev989 ---> Running in a844316ffd73 Removing intermediate container a844316ffd73 ---> ddb1767ce868 Step 10/22 : ARG indy_node_ver=1.12.1~dev1172 ---> Running in 6f1c7299c09b Removing intermediate container 6f1c7299c09b ---> 1d72474dd1d6 Step 11/22 : ARG python3_indy_crypto_ver=0.4.5 ---> Running in 4a6ffed7da1a Removing intermediate container 4a6ffed7da1a ---> e569157c4eb7 Step 12/22 : ARG indy_crypto_ver=0.4.5 ---> Running in d0713ff04de4 Removing intermediate container d0713ff04de4 ---> 3e8f46532c85 Step 13/22 : ARG python3_pyzmq_ver=18.1.0 ---> Running in 0565ded127c6 Removing intermediate container 0565ded127c6 ---> 9a2841f87ba8 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 d2f98d733d7c 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 (435 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 E: Unable to correct problems, you have held broken packages.``` Any help on what needs to be updated to fix is appreciated.

WadeBarnes (Tue, 01 Dec 2020 15:50:32 GMT):
Looks like the `indy_plenum_ver` needs to be updated to a version that matches the dependency updates @askolesov made.

smithbk (Tue, 01 Dec 2020 16:11:09 GMT):
Thanks Wade. Two questions then: 1) I thought the indy-pool.dockerfile was bound to a release that would not change. 2) I listed the versions of the indy-plenum package but am not sure what it should be changed to. Just the latest version, which is currently `1.13.0~dev1021` or the latest 1.12.1 version which is `1.12.1~dev993` or another?

WadeBarnes (Tue, 01 Dec 2020 16:13:22 GMT):
I'm not sure of the exact details. @sergey.minaev, @sergey.minaev, @Toktar, are any of you able to way in?

smithbk (Tue, 01 Dec 2020 19:31:20 GMT):
@sergey.minaev @Toktar I've tried with various versions of indy-plenum and still get the same error. To reproduce, simply execute `docker build --no-cache https://github.com/hyperledger/indy-sdk/raw/v1.15.0/ci/indy-pool.dockerfile`

smithbk (Tue, 01 Dec 2020 19:31:53 GMT):
I'm out of ideas to try so I appreciate your help

paul.bastian (Wed, 02 Dec 2020 11:03:47 GMT):
I have had similar problems. It seemed to me that aptitude is way more intelligent than apt on how to resolve problems, maybe give that a try

paul.bastian (Wed, 02 Dec 2020 11:04:36 GMT):
The problem anyway comes down to specifying exact and correct versions to install

smithbk (Wed, 02 Dec 2020 13:35:50 GMT):
Thanks. This was answered on the indy-sdk channel. The fix is to pin those 3 packages to the version in parens as follows: `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`

cam-parra (Wed, 02 Dec 2020 17:33:06 GMT):
@WadeBarnes I've solved merge conflicts on indy-node. The CI is still not running

WadeBarnes (Wed, 02 Dec 2020 18:24:50 GMT):
Thanks @cam-parra !

WadeBarnes (Wed, 02 Dec 2020 18:40:27 GMT):
@cam-parra, I kicked off the build and it's failing.

WadeBarnes (Wed, 02 Dec 2020 18:41:43 GMT):
@sergey.khoroshavin, @Toktar, What's the typical process for test/verification of pipeline updates?

swcurran (Wed, 02 Dec 2020 20:01:13 GMT):
Folks -- we met today on the "Ubuntu 20.04" problem. Based on the information provided from @cam-parra we have redefined the immediate problem to be the "Ubuntu 18.04" which we think (but have to test/verify) is already solved. So we would like to get the existing PRs for Plenum and Node for 18.04, tested and merged so that we can include them in the current release. Next step on the is for @WadeBarnes to work with @Toktar and team to get the CI/CD run completed for the relevant PRs. Ideally, the resulting artifacts will support both 16.04 and 18.04. We need to see how to both verify that and how to publish the artifacts for those. Anyone that can help with that are encouraged to. We would REALLY like to get this wrapped up as soon as possible.

swcurran (Wed, 02 Dec 2020 20:01:43 GMT):
Ubuntu 20.04 support can follow on after we release an 18.04 version.

WadeBarnes (Fri, 04 Dec 2020 13:45:46 GMT):
@sergey.minaev, @sergey.khoroshavin, @Toktar, For https://github.com/hyperledger/indy-node/pull/1443, what's the best way to build the PR using the CI/CD scripts that were modified in the PR, preferably without merging.

WadeBarnes (Fri, 04 Dec 2020 13:45:46 GMT):
@sergey.minaev, @sergey.khoroshavin, @Toktar, For https://github.com/hyperledger/indy-node/pull/1443, what's the best way to build the PR using the CI/CD scripts that were modified in the PR (preferably without merging)?

swcurran (Fri, 04 Dec 2020 15:06:37 GMT):
Do we need a meeting on this @sergey.minaev and @Toktar ? Are you onboard with idea of NOT going to 20.04 now (since the work isn't done), but going to 18.04 because (we think) the work is done.

swcurran (Fri, 04 Dec 2020 15:06:37 GMT):
Do we need a meeting on this @sergey.minaev and @Toktar ? Are you onboard with idea of NOT going to 20.04 now (since the work isn't done), but going to 18.04 because (we think) the work is done?

swcurran (Fri, 04 Dec 2020 15:07:29 GMT):
Perhaps an early morning (Pacific) Monday meeting late afternoon eastern Europe meeting?

EtricKombat (Mon, 28 Dec 2020 11:05:24 GMT):
Has joined the channel.

gagepoulson (Wed, 06 Jan 2021 15:35:30 GMT):
Has joined the channel.

timbu (Thu, 21 Jan 2021 14:04:41 GMT):
Has joined the channel.

Yunxi 3 (Fri, 22 Jan 2021 14:44:44 GMT):
Has joined the channel.

Yunxi 3 (Fri, 22 Jan 2021 14:44:44 GMT):
Hello all, i'm running a test Indy pool network (4 nodes), are there any command lines that i can use to connect to my indy network and check indy network details (e.g. what are role types of indy nodes, Trustee, Stardward etc)?

swcurran (Fri, 22 Jan 2021 15:05:37 GMT):
Your environment already has a super-powered Trustee that you can use to create more DIDs - endorsers and plain authors. This tutorial spins up a network and some agents (you ignore their purpose for what you are doing) and then walks through using the CLI to so some things.

swcurran (Fri, 22 Jan 2021 15:05:40 GMT):
https://github.com/bcgov/von-network/blob/master/docs/Writing%20Transactions%20to%20a%20Ledger%20for%20an%20Un-privileged%20Author.md

Yunxi 3 (Fri, 22 Jan 2021 16:50:27 GMT):
@swcurran , thanks for the reply. I've figured out Indy-SDK cli is the command line i can use, but can't find any relevant commands that can show me node role type info. I would also like to know how i can configure a node to be either Trustee or other types? is this something i need to configure before having an Indy network up and running or after?

swcurran (Fri, 22 Jan 2021 18:18:56 GMT):
You have to connect to the network first (`pool connect `, and then the command `ledger get-nym did=VsKV7grR1BUE29mG2Fm2kX`

swcurran (Fri, 22 Jan 2021 18:19:16 GMT):
That will tell you the role of DID.

swcurran (Fri, 22 Jan 2021 18:19:39 GMT):
Configuring nodes, adding nodes and so on is a lot more complicated.

swcurran (Fri, 22 Jan 2021 18:20:09 GMT):
Others - e.g. @lynn.bendixsen might be able to point you at some resources to help

lynn.bendixsen (Fri, 22 Jan 2021 18:43:34 GMT):
Hi @Yunxi 3 I don't know of a "tell me all of the Steward DIDs on the network" command, but you can look in the /var/lib/indy/sandbox/domain_transaction_genesis file on any node to see the initial DIDs for the Trustees and Stewards in your test network. (where "sandbox" is your test network name). A Node does not take on a role like Trustee or Steward. Those roles are assigned to DIDs on the ledger and can be changed by using a DID with the TRUSTEE role. Adding new DID's with the mentioned roles usually happens after your network is up and running for test networks. The best way to begin is to find the seed used for a TRUSTEE that is already on your network, add that TRUSTEE did to your wallet (using the >did new seed command), then use that TRUSTEE did (>did use ) to get started. Then you can start playing around with adding DIDs with various roles and checking things out on your network. For more ledger commands that you can run, try >ledger help in the indy-cli.

Yunxi 3 (Mon, 25 Jan 2021 10:13:21 GMT):
@lynn.bendixsen, as per your explanation, are roles such as TRUSTEE or Steward applied to agents instead of a node?

Yunxi 3 (Mon, 25 Jan 2021 10:13:21 GMT):
@lynn.bendixsen, as per your explanation, are roles such as TRUSTEE or Steward used in agents instead of nodes?

Yunxi 3 (Mon, 25 Jan 2021 10:13:21 GMT):
@lynn.bendixsen, as per your explanation, are roles such as TRUSTEE or Steward used in agents instead of Indy nodes?

Yunxi 3 (Mon, 25 Jan 2021 10:15:38 GMT):

Clipboard - January 25, 2021 10:15 AM

Yunxi 3 (Mon, 25 Jan 2021 10:17:28 GMT):
@lynn.bendixsen, the above image i've found shows an Indy node can be either a Validator (write/read permission) and an Observer (read permission only), but i can't find any information in Indy guide that shows how i can set up a network with these two types of nodes. Also wondering if they are relevant to concepts such as TRUSTEE and Steward?

Yunxi 3 (Mon, 25 Jan 2021 10:19:25 GMT):

Clipboard - January 25, 2021 10:19 AM

Yunxi 3 (Mon, 25 Jan 2021 10:20:55 GMT):

Clipboard - January 25, 2021 10:20 AM

Yunxi 3 (Mon, 25 Jan 2021 10:21:12 GMT):
@lynn.bendixsen, also a very basic question. If I need to set up a production-level Indy network for an enterprise-level project, which docs show the right tutorial for setting up an Indy network? I see Indy-Node's doc shows an approach for Ubuntu, also Indy-SDK shows a way to start with a docker image

lynn.bendixsen (Mon, 25 Jan 2021 22:29:47 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=XGGYhyBbfk3pGmWKw) Roles such as Trustee, Steward and Endorser are permissioned roles on an Indy Network ledger. Agents might use DIDs that have one of those roles as part of dealing with the network, but do not themselves use those roles. The observer Node concept was discussed and designed, but never implemented. As such, there are no Indy Networks with an Observer Node on them, nor can there be until the implementation has been done. There are no current projects that I know of that are working on implementing observer nodes. The different types of nodes are not at all related to the DiD roles existing on the ledger. Here is a link to my starter document that I use to set up production level networks. It includes links to several other documents: https://docs.google.com/document/d/1Tg4dAEtC78TxG9AsIby_CfpbeOicK_YMKznSQOvtIVU

lynn.bendixsen (Mon, 25 Jan 2021 22:29:47 GMT):
Roles such as Trustee, Steward and Endorser are permissioned roles on an Indy Network ledger. Agents might use DIDs that have one of those roles as part of dealing with the network, but do not themselves use those roles. The observer Node concept was discussed and designed, but never implemented. As such, there are no Indy Networks with an Observer Node on them, nor can there be until the implementation has been done. There are no current projects that I know of that are working on implementing observer nodes. The different types of nodes are not at all related to the DiD roles existing on the ledger. Here is a link to my starter document that I use to set up production level networks. It includes links to several other documents: https://docs.google.com/document/d/1Tg4dAEtC78TxG9AsIby_CfpbeOicK_YMKznSQOvtIVU

timbu (Tue, 26 Jan 2021 19:35:55 GMT):
Hi, regarding https://github.com/hyperledger/indy-node/pull/1443 is there any activity still going on?

swcurran (Tue, 26 Jan 2021 20:43:10 GMT):
We're looking for help on that and a prerequisite work -- getting CI/CD upgraded to be independent of no longer available resources, and static infrastructure. Any chance you would be able to help?

Yunxi 3 (Wed, 27 Jan 2021 17:42:21 GMT):
@lynn.bendixsen , thanks for sharing the doc link, i'll definitely look at it. Just making sure i understand you correctly. Q1. Regarding the Indy node, as per what you explained, my understanding is current indy nodes have only one type that can read and write data from/to indy ledger, right? Q2. following on Q1, this means if an Indy node wants to determine whether data sent from agents can be written to the indy ledger or not, that's the time we should use permissioned roles such as Trustee and Steward related to DIDs representing end users , right?

lynn.bendixsen (Thu, 28 Jan 2021 23:17:05 GMT):
Q1. correct, all indy nodes are currently validator nodes. There are no other types. Q2. Yes, Indy nodes write data to the ledger based on consensus, and to achieve consensus, the nodes must agree that the correct number of signatures from valid users appears on the transaction to write. Different transactions require different levels of signatures and different numbers of signatures of that level (TRUSTEE, ENDORSER, STEWARD etc.) To determine how many and what kind of signatures are required for each transaction on a network, execute a get-auth-rules command.

morticianmili (Mon, 01 Feb 2021 16:51:29 GMT):
Has joined the channel.

Yunxi 3 (Tue, 02 Feb 2021 10:57:13 GMT):
Thanks for your confirmation @lynn.bendixsen. If I need to design DIDs, credential schemas and definitions, what official documentations should I look at? I'v found most tutorials in the Indy github's Readmes are more related to the code level, which doesn't fit for design purpose.

Yunxi 3 (Tue, 02 Feb 2021 10:57:13 GMT):
Thanks for your confirmation @lynn.bendixsen. If I need to design DIDs, credential schemas and definitions (e.g. normal fields for each), what official documentations should I look at? I'v found most tutorials in the Indy github's Readmes are more related to the code level, which doesn't fit for design purpose.

Yunxi 3 (Tue, 02 Feb 2021 12:01:40 GMT):
Hello all, I see "Trust Anchor" is mentioned as a role in this link: https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/indy-walkthrough.md, but I can't see it as defined in this link: https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md. Can anyone explain which role is Trust Anchor is referred to ?

Yunxi 3 (Tue, 02 Feb 2021 12:01:40 GMT):
Hello all, I see "Trust Anchor" is mentioned as a role in this link: https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/indy-walkthrough.md, but I can't see it as defined in this link: https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md. Does Trust Anchor equal to "Steward" only?

Yunxi 3 (Tue, 02 Feb 2021 15:57:55 GMT):
@lynn.bendixsen , i've found this file(https://github.com/hyperledger/indy-sdk/blob/master/vcx/libvcx/src/api/credential_def.rs) and this file (https://github.com/hyperledger/indy-sdk/blob/master/vcx/libvcx/src/api/schema.rs) in the indy github. Are they the up-to-date generic fields in the Indy credential schema and definition i should follow for design?

Yunxi 3 (Tue, 02 Feb 2021 15:59:08 GMT):
Hello all, If I need to design DIDs, credential schemas and definitions (e.g. normal fields for each), what official documentations should I look at? I'v found most tutorials in the Indy github's Readmes are more related to the code level, which doesn't fit for design purpose. However, i've found this file(https://github.com/hyperledger/indy-sdk/blob/master/vcx/libvcx/src/api/credential_def.rs) and this file (https://github.com/hyperledger/indy-sdk/blob/master/vcx/libvcx/src/api/schema.rs) in the indy github. Are they the up-to-date generic fields in the Indy credential schema and definition i should follow for design?

lynn.bendixsen (Tue, 02 Feb 2021 20:09:48 GMT):
The term "Trust Anchor" has been deprecated and is no longer used on the ledgers. It has been replaced by "Endorser" and slightly redefined. The Steward role is only used for managing network nodes and is almost entirely unrelated to "Endorser". (Does not have any of the same privileges).

Yunxi 3 (Wed, 03 Feb 2021 10:10:23 GMT):
Thanks for the response @lynn.bendixsen . How about "Trustee"? I see Trustee has more privilege than Steward (at least Trustee can create new Steward), so does it mean Trustee can also be used for managing network nodes?

Yunxi 3 (Wed, 03 Feb 2021 10:10:23 GMT):
Thanks for the response @lynn.bendixsen . How about "Trustee"? I see a Trustee has more privilege than a Steward (at least a Trustee can create a new Steward), so does it mean a Trustee can also be used for managing network nodes?

Yunxi 3 (Wed, 03 Feb 2021 10:10:23 GMT):
Thanks for the response @lynn.bendixsen . How about "Trustee"? I see a Trustee has more privileges than a Steward (at least a Trustee can create a new Steward), so does it mean a Trustee can also be used for managing network nodes or it is used for other purposes?

Yunxi 3 (Wed, 03 Feb 2021 10:55:52 GMT):

Clipboard - February 3, 2021 10:55 AM

Yunxi 3 (Wed, 03 Feb 2021 10:58:08 GMT):
Hello all, i've looked this credential definition file in the Indy github: https://github.com/hyperledger/indy-sdk/blob/master/vcx/libvcx/src/api/credential_def.rs. This is the only file i can find that explains the credential definition template. Got 2 questions. Q1: is this the right doc i should follow? Q2: if Q1 is correct, can anyone explain a bit more on what the two fields "tag" and "revocation details" do as shown in the figure above? Thanks!

Yunxi 3 (Wed, 03 Feb 2021 10:58:08 GMT):
Hello all, i've looked this credential definition file in the Indy github: https://github.com/hyperledger/indy-sdk/blob/master/vcx/libvcx/src/api/credential_def.rs. This is the only file i can find that explains the credential definition template. Got 2 questions. Q1: is this the right doc i should follow? Q2: if Q1 is correct, can anyone explain a bit more on what the two fields "tag" and "revocation details" do as shown in the figure above (e.g. providing examples would be very helpful)? Thanks!

paul.bastian (Wed, 03 Feb 2021 14:04:01 GMT):
You should start by trying out Software agents like Acapy that enable you to easily create stuff over REST-based swagger API

WadeBarnes (Wed, 03 Feb 2021 14:18:50 GMT):
for example; https://github.com/hyperledger/aries-cloudagent-python

lynn.bendixsen (Wed, 03 Feb 2021 15:44:03 GMT):
Trustees have other purposes, but with three trustee signatures they can add or remove existing nodes and do other network management and administration things (like upgrades). They are also responsible for adding/removing DID's of all roles. Only Stewards can add a new node and only one node for each Steward on a network.

Yunxi 3 (Wed, 03 Feb 2021 17:50:07 GMT):
Hello @lynn.bendixsen , i want to use an example to make sure i understand the limitation of Stewards for adding new nodes. so, if we have 3 stewards (S1, S2 and S3)in the Indy network consisting with 4 nodes (N1 - N4). Do you mean if S1 wants to add a new node N5,

Yunxi 3 (Wed, 03 Feb 2021 17:50:07 GMT):
Hello @lynn.bendixsen , i want to use an example to make sure i understand the limitation of Stewards for adding new nodes. so, if we have 3 stewards (S1, S2 and S3)in the Indy network consisting with 4 nodes (N1 - N4). Do you mean if S1 wants to add new nodes, it can only add a N5 to the network, and then its credit of adding a new node becomes 0(no chance to add any other new nodes like N6 etc.), and this principle applies to S2 and S3?

Yunxi 3 (Wed, 03 Feb 2021 17:50:07 GMT):
Hello @lynn.bendixsen , i want to use an example to make sure i understand the limitation of Stewards for adding new nodes. so, if we have 3 stewards (S1, S2 and S3)in the Indy network consisting of 4 nodes (N1 - N4). Do you mean if S1 wants to add new nodes, it can only add a N5 to the network, and then its credit of adding a new node becomes 0(no chance to add any other new nodes like N6 etc.), and this principle applies to S2 and S3?

Yunxi 3 (Wed, 03 Feb 2021 17:50:07 GMT):
Hello @lynn.bendixsen , i want to use an example to make sure i understand the limitation of Stewards for adding new nodes. so, if we have 3 stewards (S1, S2 and S3)in the Indy network consisting of 4 nodes (N1 - N4). Do you mean if S1 wants to add new nodes, it kind of has a credit with a value of 1 (meaning adding 1 node), it then can add a N5 as a new node to the network, and then its credit of adding a new node becomes 0(no chance to add any other new nodes like N6 etc.), and this principle applies to S2 and S3?

lynn.bendixsen (Wed, 03 Feb 2021 20:53:34 GMT):
Yes, each Steward DID, can only be used to add 1 node to the network. On test networks, the same node operator might create multiple steward DID's so that they can add more Nodes if needed. If there are 4 nodes in a network, there must be 4 steward DID's used, one for each node.

Yunxi 3 (Thu, 04 Feb 2021 09:58:51 GMT):
@paul.bastian and @WadeBarnes , thanks for providing the info and link. I see aries-cloudagent-python should be used to build controllers along with the agent, but i'm still confused with when we should use Indy-SDK? looks like Indy-SDK might have overlapping functions with aries and Indy-Node, is this correct?

Yunxi 3 (Thu, 04 Feb 2021 09:58:51 GMT):
@paul.bastian and @WadeBarnes , thanks for providing the info and link. I see aries-cloudagent-python should be used to build controllers along with the agent, but i'm still confused with when we should use Indy-SDK? looks like Indy-SDK might have overlapping functions with aries and Indy-Node (mainly for Indy DLT Ledger network set up), is this correct?

WadeBarnes (Thu, 04 Feb 2021 13:23:54 GMT):
All of the functionality you need is in aries-cloudagent-python. The components of indy-sdk are being broken out into new shared libraries which in turn are being integarted into the newer aries frameworks such as aries-cloudagent-python. If you are starting from the beginning you don't need to use indy-sdk directly.

Yunxi 3 (Thu, 04 Feb 2021 14:10:39 GMT):
Thanks @WadeBarnes , so my understanding of the mapping between 3 Indy components and their libraries are, (1) agent -> aries-cloudagent-python (2) cryptography -> ursa and (3) Indy DLT network setup -> Indy-node, is this correct?

Yunxi 3 (Thu, 04 Feb 2021 14:55:44 GMT):

Clipboard - February 4, 2021 2:55 PM

Yunxi 3 (Thu, 04 Feb 2021 14:58:02 GMT):

Clipboard - February 4, 2021 2:57 PM

Yunxi 3 (Thu, 04 Feb 2021 14:59:32 GMT):
Hello all, when I go through this doc: https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/indy-walkthrough.md for how a Steward can onboard a new party, the message shown in the picture says a communication channel between each pair exists. I would imagine this agent level communication between a Steward and the new party. At this point, i understand the new party's DID is not committed to the ledger yet. Then when i see this link: https://github.com/hyperledger/aries-rfcs/blob/master/features/0067-didcomm-diddoc-conventions/README.md. explaining how agent-level channel should be established, step 1 shows: sender resolves the did-communication service of the recipients. I'm wondering in the onboarding process, how can the new party resolve the DID of the Steward without completing the onboarding process?

Yunxi 3 (Thu, 04 Feb 2021 14:59:32 GMT):
Hello all, when I go through this doc: https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/indy-walkthrough.md for how a Steward can onboard a new party A, the message shown in the picture says a communication channel between each pair exists. I understand this is agent level communication between a Steward and the new party A, and the new party's DID is not committed to the ledger yet. Then when i see this link: https://github.com/hyperledger/aries-rfcs/blob/master/features/0067-didcomm-diddoc-conventions/README.md. explaining how agent-level channel should be established, step 1 shows: sender resolves the did-communication service of the recipients. I'm wondering in the onboarding process, how can the new party A resolve the DID of the Steward without completing the onboarding process?

WadeBarnes (Thu, 04 Feb 2021 15:17:23 GMT):
I think you could abstract you're thinking to: 1) Agent; one of the Aries Frameworks. 2) Ledger; Indy-Node. The cryptography bit is abstracted and handled completely by the Agent. You're application's business logic interacts with the agent an does not need to be concerned with the underlying cryptography.

WadeBarnes (Thu, 04 Feb 2021 15:17:52 GMT):
@swcurran, @andrew.whitehead may have more to add.

Yunxi 3 (Thu, 04 Feb 2021 17:10:48 GMT):
@WadeBarnes , you mentioned "one of the Aries Frameworks" in your answer, could I ask what other frameworks are available for Agent apart from "aries-cloudagent-python "?

swcurran (Thu, 04 Feb 2021 17:12:44 GMT):
There is also Aries Framework .NET and Aries Framework Go. Aries Framework .NET works with Aries Cloud Agent Python; Aries Framework Go uses forward looking protocols, and so does not work with the other frameworks.

swcurran (Thu, 04 Feb 2021 17:12:58 GMT):
Aries Framework Go does not use Indy.

paul.bastian (Fri, 05 Feb 2021 14:14:52 GMT):
you don't need a DID on the ledger for didcomm to work, also you could send this information via https/webseite to an endorser. this doc is a little outdated, as an endorser would now write party A's DID to the ledger. also for resolving a DID, you don't need a DID either, its free information on the ledger

Yunxi 3 (Mon, 08 Feb 2021 10:26:06 GMT):
Thanks @paul.bastian, i've gone through the doc for setting up the 1st time communication channel for two agents, now i understand it's not relying on the DLT. One more question i've got is regarding the first-time communication channel between any two Aries agents, is there always a manual intervention that is required? In other words, are there any ways to automate the communication channel setup between any two agents for the 1st time?

paul.bastian (Mon, 08 Feb 2021 17:36:36 GMT):
sure all the things are automateable, usually at least one agent is fully automated in a production setup later. in the textbook ssi the other party is most likely a human that has to interact manully and accept transactions in the wallet as user consent is a major trait of SSI. but fully automated SSI transactions between 2 automated agents are also possible, depending on the scenario, e.g. between two companys or if i give explicit permission for my wallet for certain transactions,e.g. physical access via bluetooth/NFC

Yunxi 3 (Tue, 09 Feb 2021 11:12:27 GMT):
Hello @paul.bastian , not sure if your answer corresponds to my question. When i looked at this link: https://github.com/hyperledger/aries-cloudagent-python/blob/main/demo/AriesOpenAPIDemo.md, in the "Establishment a Connection" section, it shows how 1st-time connection is established between two agents. I see a user will have to manually generate an invitation in the Faber agent and then copy and paste this invitation in the Alice agent. I also see this message in the page: "A key observation to make here. The "copy and paste" we are doing here from Faber's agent to Alice's agent is what is called an "out of band" message. Because we don't yet have a DIDComm connection between the two agents, we have to convey the invitation in plaintext (we can't encrypt it - no channel) using some other mechanism than DIDComm. With mobile agents, that's where QR codes often come in. Once we have the invitation in the receivers agent, we can get back to using DIDComm." So I wonder if steps for "out of band message" can't be automated? Hope this clarifies my queestion.

Yunxi 3 (Tue, 09 Feb 2021 11:12:27 GMT):
Hello @paul.bastian , not sure if your answer corresponds to my question. When i looked at this link: https://github.com/hyperledger/aries-cloudagent-python/blob/main/demo/AriesOpenAPIDemo.md, in the "Establishment a Connection" section, it shows how 1st-time connection is established between two agents as an example. I see a user will have to manually generate an invitation in the Faber agent and then copy and paste this invitation in the Alice agent. I also see this message in the page: "A key observation to make here. The "copy and paste" we are doing here from Faber's agent to Alice's agent is what is called an "out of band" message. Because we don't yet have a DIDComm connection between the two agents, we have to convey the invitation in plaintext (we can't encrypt it - no channel) using some other mechanism than DIDComm. With mobile agents, that's where QR codes often come in. Once we have the invitation in the receivers agent, we can get back to using DIDComm." So I wonder if steps for "out of band message" can't be automated? Hope this clarifies my queestion.

Yunxi 3 (Tue, 09 Feb 2021 11:28:43 GMT):
hello all, i'm looking at the multi-tenancy section in ACA-py in this link: https://github.com/hyperledger/aries-cloudagent-python/blob/main/Multitenancy.md. I see this statement -"⚠️ Although support for unmanaged mode is mostly in place, the receiving of messages from other agents in unmanaged mode is not supported yet. This means unmanaged mode can not be used yet.", and I wonder whether the "unmanaged mode" is still not available?

Yunxi 3 (Tue, 09 Feb 2021 11:28:43 GMT):
hello all, i'm looking at the multi-tenancy section in ACA-py in this link: https://github.com/hyperledger/aries-cloudagent-python/blob/main/Multitenancy.md. I see this statement -"⚠️ Although support for unmanaged mode is mostly in place, the receiving of messages from other agents in unmanaged mode is not supported yet. This means unmanaged mode can not be used yet.", and I wonder whether the "unmanaged mode" as a feature is still not available?

WadeBarnes (Tue, 09 Feb 2021 14:48:04 GMT):
@Yunxi 3, Please redirect that question to #aries-cloudagent-python

Yunxi 3 (Mon, 15 Feb 2021 09:32:45 GMT):

Clipboard - February 15, 2021 9:32 AM

Yunxi 3 (Mon, 15 Feb 2021 09:33:55 GMT):
Hello all, this doc: https://trustoverip.org/wp-content/uploads/sites/98/2020/05/Introducing-The-Trust-over-IP-Foundation-V1.pdf shows a concept of "Transaction Author", but I can't find it in the role definition in this link: https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md. I'm wondering if this "Transaction Author" concept is out of date now?

Yunxi 3 (Mon, 15 Feb 2021 09:33:55 GMT):
Hello all, this doc: https://trustoverip.org/wp-content/uploads/sites/98/2020/05/Introducing-The-Trust-over-IP-Foundation-V1.pdf shows a concept of "Transaction Author", but I can't find it in the role definition in this link: https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md. I'm wondering if this "Transaction Author" concept is deprecated now?

Yunxi 3 (Mon, 15 Feb 2021 09:33:55 GMT):
Hello all, this doc: https://trustoverip.org/wp-content/uploads/sites/98/2020/05/Introducing-The-Trust-over-IP-Foundation-V1.pdf shows a concept of "Transaction Author", but I can't find it in the role definition in this link: https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md. I'm wondering if this "Transaction Author" concept is out of datenow?

Yunxi 3 (Mon, 15 Feb 2021 09:33:55 GMT):
Hello all, this doc: https://trustoverip.org/wp-content/uploads/sites/98/2020/05/Introducing-The-Trust-over-IP-Foundation-V1.pdf shows a concept of "Transaction Author", but I can't find it in the role definition in this link: https://github.com/hyperledger/indy-node/blob/master/docs/source/auth_rules.md. I'm wondering if this "Transaction Author" concept is out of date now?

lynn.bendixsen (Mon, 15 Feb 2021 14:46:41 GMT):
Hi @Yunxi 3 , "Transaction Author" is the external descriptive name given to a DID that is on the ledger but has no assigned Role. ( i.e. Role= ). Transaction Authors currently require an Endorser signature to be able to write to the ledger.

Yunxi 3 (Tue, 16 Feb 2021 10:18:01 GMT):
Thanks for the answer @lynn.bendixsen , so basically Transaction Author = DID of a party that has no role assigned. However, in order for a party to write to the ledger, an Endorser role needs to be assigned to the party, is it correct?

Yunxi 3 (Tue, 16 Feb 2021 10:18:01 GMT):
Thanks for the answer @lynn.bendixsen , so basically Transaction Author = DID of a party that has no role assigned. However, in order for the party to write transactions to the ledger, an Endorser role needs to be assigned to the party, is it correct?

Yunxi 3 (Tue, 16 Feb 2021 10:18:01 GMT):
Thanks for the answer @lynn.bendixsen , when you said "Transaction Authors currently require an Endorser signature", does it mean the Transaction Authors' DIDs will have to assigned an Endorsor role?

lynn.bendixsen (Tue, 16 Feb 2021 15:08:26 GMT):
What I meant was that when a Transaction Author builds a transaction, they assign an endorser at that time, then the transaction Endorserr (a different Entity/DID on the ledger) must sign their transaction for them before they can send it to the ledger. The Transaction Author just needs the Endorser's signature before they can write their Schema/cred_def etc. to the ledger.

Yunxi 3 (Tue, 16 Feb 2021 15:58:02 GMT):
this is clear, thanks @lynn.bendixsen

T_aanna (Wed, 17 Feb 2021 10:17:38 GMT):
Has joined the channel.

T_aanna (Wed, 17 Feb 2021 10:32:41 GMT):
Hi guys, please let me know if I'm wrong here with my question. I tried to follow the indy-ssivc-tutorial since I'm new to the hyperledger indy stuff. When trying to run the commands for setting up the VON-network with the 4 nodes I always end up getting errors. I tried to solve them by googling and searching for related errors on stackoverflow etc. I ended up on a github page with several issues handling those errors. Those issues where dated with 2020, does that mean that they are still observing the issue there? Or is the tutorial outdated in general? Does someone have alternatives how I can try out those things? Thanks a lot in advance :)

WadeBarnes (Wed, 17 Feb 2021 12:46:16 GMT):
What errors are you seeing when trying to run `von-network`? What OS are you running and what version/flavor of Docker are you running?

rjones (Wed, 17 Feb 2021 19:28:54 GMT):
Hi. I'm updating the `maintainers` email list, and I don't have a valid address for ```$ grep -R lovesh hyperledger/* hyperledger/indy-node/MAINTAINERS.md: instead of day-to-day scrum. geo=India; github; jira=lovesh; rocket.chat=LoveshHarchandani```

rjones (Wed, 17 Feb 2021 19:32:57 GMT):
```$ grep -Ri wightman hyperledger/* hyperledger/indy-node/MAINTAINERS.md:* Doug - maintainer. geo=Utah, USA; github=glowkey; rocket.chat, jira=DouglasWightman hyperledger/indy-sdk/MAINTAINERS.md:* Doug - vcx maintainer. geo=Utah, USA; github=glowkey; rocket.chat, jira=DouglasWightman ```

esplinr (Fri, 19 Feb 2021 05:08:06 GMT):
Lovesh changed jobs 18 months ago, and is not longer involved in Indy. But he does still work on Ursa. I don't have a valid email address for him.

esplinr (Fri, 19 Feb 2021 05:08:29 GMT):
Doug Wightman changed jobs 20 months ago, and is no longer involved in Indy or Aries.

esplinr (Fri, 19 Feb 2021 05:08:53 GMT):
Lovesh changed jobs 18 months ago, and is not longer involved in Indy. But he does still work on Ursa. I don't have a valid email address for him.

esplinr (Fri, 19 Feb 2021 05:09:04 GMT):
Doug Wightman changed jobs 20 months ago, and is no longer involved in Indy or Aries.

rjones (Fri, 19 Feb 2021 15:20:16 GMT):
OK. Should I file a PR to update the maintainers file?

rjones (Fri, 19 Feb 2021 15:20:36 GMT):
OK, same question here.

esplinr (Fri, 19 Feb 2021 15:48:44 GMT):
That entire document is very out of date.

esplinr (Fri, 19 Feb 2021 15:50:51 GMT):
I know that's not a helpful response. I'm looking at the file to see what needs to happen.

rjones (Fri, 19 Feb 2021 15:57:39 GMT):
OK, no worries. I'll drop it for now.

da3v21 (Tue, 23 Feb 2021 10:24:23 GMT):
Has joined the channel.

mvaibhav (Thu, 25 Feb 2021 03:46:07 GMT):
Has joined the channel.

mvaibhav (Thu, 25 Feb 2021 09:30:53 GMT):
Can anyone tell me a way to run a local indy network and nodes(for test purpose, not for development) without using von-network? I am sorry if this is very trivial question, I am very new to Hyperledger-Indy.

mvaibhav (Thu, 25 Feb 2021 12:12:00 GMT):
I have run pool_start.sh and the nodes are running successfully, can anyone please tell me how can I run the agents given in this tutorial. https://github.com/hyperledger/indy-node/tree/master/environment/docker/pool

mvaibhav (Thu, 25 Feb 2021 12:15:43 GMT):

Screenshot (35).png

WadeBarnes (Thu, 25 Feb 2021 14:33:11 GMT):
Have you looked at the Alice/Faber demos here; https://github.com/hyperledger/aries-cloudagent-python

WadeBarnes (Thu, 25 Feb 2021 14:33:20 GMT):
They are more up to date.

andrew.whitehead (Thu, 25 Feb 2021 20:21:38 GMT):
I just noticed that the indy-plenum package has "pip<10.0.0" as a dependency in setup.py, I don't think it should be installing that. Partly since it's at 21.0 now

andrew.whitehead (Thu, 25 Feb 2021 20:27:09 GMT):
It looks like it does actually import pip in multiple places though

WadeBarnes (Thu, 25 Feb 2021 20:31:24 GMT):
Thanks @andrew.whitehead, pip is being pinned due to another dependency issue that needs to be resolved.

WadeBarnes (Thu, 25 Feb 2021 20:31:55 GMT):
Should be addressed in the Ubuntu 20.04 upgrade.

mvaibhav (Fri, 26 Feb 2021 05:50:54 GMT):
I have tried those demos, but they use von-network. I want to create my own network for test purposes.

Yunxi 3 (Fri, 26 Feb 2021 10:19:04 GMT):
Hello all, i just updated my acapy code to the latest 0.6.0 and when running my agent which worked fine in v0.6.0rc1, now i got error: docker: Invalid ip address 8000:8000: address 8000:8000:: too many colons in address. What is the right syntax for environment variables such as "PORTS=" now?

WadeBarnes (Fri, 26 Feb 2021 14:15:39 GMT):
Do you know about the Sovrin BuildNet and StagingNet ledgers available though https://selfserve.sovrin.org/. They are freely available distributed ledgers for testing.

WadeBarnes (Fri, 26 Feb 2021 14:20:41 GMT):
That would be your best way forward since you's want to end up connecting with something like Sovrin MainNet for production.

WadeBarnes (Fri, 26 Feb 2021 14:21:18 GMT):
If you're really set on standing up your own network this document should point you in the right direction; https://docs.google.com/document/d/1XE2QOiGWuRzWdlxiI9LrG9Am9dCfPXBXnv52wGHorNE

swcurran (Fri, 26 Feb 2021 16:37:01 GMT):
If you want to create your own, you can dissect the von-network dockerfile and docker-compose scripts. They do what you have to do on bare-metal. Not sure what your goal is in doing that. It's kind of like saying I want to understand the compiler before I do some coding. It's great if you want to work on extending Indy, but not needed if you are working on exchanging verifiable credentials.

mvaibhav (Sun, 28 Feb 2021 21:31:20 GMT):
@swcurran Can you please tell me how the von-network generated the genesis file it is using? I mean if they are creating a network from scratch, they shouldn't use a genesis file in the beginning. Or better question, how can I create my own genesis file without using one?

mvaibhav (Sun, 28 Feb 2021 21:34:08 GMT):
@WadeBarnes Thanks for the doc. link. I think it's exactly what we were looking for. We are working on trying it ourselves.

Takuro-Mine (Wed, 03 Mar 2021 02:46:45 GMT):
Has joined the channel.

Takuro-Mine (Wed, 03 Mar 2021 02:46:45 GMT):
Hi ,I have a question about dev-setup (https://github.com/hyperledger/indy-node/blob/master/docs/source/setup-dev.md). Why do I have to fork indy-node and indy-plenum instead of clone them ?

Yunxi 3 (Wed, 03 Mar 2021 15:38:58 GMT):
Hello all, where can i find the right docs explaining what/why/when to use a seed/verkey for a DID?

mvaibhav (Fri, 05 Mar 2021 07:42:52 GMT):
Can one Steward add multiple validator nodes to the network?

mvaibhav (Fri, 05 Mar 2021 11:16:13 GMT):
I want to add a steward into my local ledger, I sent a nym transaction using a trustee on indy-cli, it showed "Nym request has been sent to Ledger.". But when I ran read-ledger script, it didn't show me the new steward. What should I do? Please help me.

WadeBarnes (Mon, 08 Mar 2021 13:49:30 GMT):
Technically, yes. In practice each Steward only hosts a single node per network.

mvaibhav (Tue, 09 Mar 2021 08:07:46 GMT):
Okay. Thanks.

mvaibhav (Tue, 09 Mar 2021 08:09:37 GMT):

Screenshot (39).png

mvaibhav (Tue, 09 Mar 2021 08:10:00 GMT):
[steward_did] already has a node

mvaibhav (Tue, 09 Mar 2021 08:10:17 GMT):
Can you please tel me a way to bypass this

WadeBarnes (Tue, 09 Mar 2021 13:16:47 GMT):
Is this your own network?

WadeBarnes (Tue, 09 Mar 2021 13:16:47 GMT):
Is this your own network? For testing?

mvaibhav (Wed, 10 Mar 2021 09:03:19 GMT):
Yes, I have created a local network for testing.

WadeBarnes (Wed, 10 Mar 2021 13:21:19 GMT):
Then create a new steward did and assign the new validator node to that did.

mvaibhav (Thu, 11 Mar 2021 05:41:44 GMT):
I have done that and that's working

mvaibhav (Thu, 11 Mar 2021 05:42:35 GMT):
But my point is why did the error come when I tried to add another node using a steward?

WadeBarnes (Thu, 11 Mar 2021 13:45:05 GMT):
Looks like there are auth rules preventing the operation.

WadeBarnes (Thu, 11 Mar 2021 13:45:05 GMT):
Looks like there are auth rules preventing the operation, and ensuring best practice.

weiyaous (Thu, 11 Mar 2021 17:18:03 GMT):
Has joined the channel.

weiyaous (Thu, 11 Mar 2021 17:18:03 GMT):
Dear all, can any one explain what is a seed? I would like to start a server and join a von-network, and I saw one parameter is the LEDGER_SEED. I'm wondering if someone can explain the seed or let me know where to find the description about seed? I didn't find too much information. Thank you! :grin:

kdenhartog (Thu, 11 Mar 2021 21:18:10 GMT):
The seed is a cryptographically random pseudorandom number used to generate a key. For more information see here: https://en.wikipedia.org/wiki/Random_seed

timbu (Thu, 11 Mar 2021 21:54:04 GMT):
Hi @ all, I was wondering if there is some workaround to run node_control for upgrades within OpenShift environment as non-root user. Is it possible to trigger indy-node.service via indy-node-control.service just by adding a user in the unit declaration?

weiyaous (Fri, 12 Mar 2021 01:26:57 GMT):
Gotcha, thanks.

mvaibhav (Fri, 12 Mar 2021 06:57:42 GMT):
Okay, yeah I get it. Also, a steward having multiple validator nodes is not good for practice. So, Thanks.

WadeBarnes (Fri, 12 Mar 2021 13:52:21 GMT):
Are you trying to run a node, or node pool in OpenShift? The addressing schemes used by indy-node and OpenShift are incompatible. It's possible to get a node running in OpenShift but there is a significant amount of effort and extra services and infrastructure required. Some information here; https://github.com/bcgov/von-network/tree/master/openshift#warning

weiyaous (Sat, 13 Mar 2021 20:42:46 GMT):
Dear all, I have created a pool by following the instruction https://github.com/bcgov/von-network/blob/master/docs/UsingVONNetwork.md. Is there any instruction regarding add more indy-nodes into this pool? Thank you.

WadeBarnes (Sun, 14 Mar 2021 11:34:32 GMT):
What is your use case? Why do you want to add nodes to the `von-network` pool? `von-network` was originally designed to be an easy to use, fixed size, provisional ledger for test purposes. It's possible to add nodes, but if you want them managed by the scripts you'll need to make some updates to the start-up scripts and docker-compose file.

weiyaous (Sun, 14 Mar 2021 13:16:39 GMT):
Hello, I'm trying to add more nodes to test the consensus and performance.

weiyaous (Sun, 14 Mar 2021 13:22:51 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=ZWEHw3iSHfCu2on4b) Hello, I'm trying to add more nodes to test the consensus and performance. I'm using von-network since I found it's much easier to deploy compares to the original indy project.

WadeBarnes (Sun, 14 Mar 2021 13:31:13 GMT):
Consensus and performance of `von-network` or the performance of your application? How do you plan on using `von-network`? If you're looking for a production grade ledger you should be looking at using something like Sovrin MainNet. Sovrin also provides full scale distributed ledgers for `dev` (BuilderNet) and `test` (StagingNet) applications that would be far more suited for full scale performance testing. https://sovrin.org/overview/ You can sign up for BuilderNet or StagingNet here; https://selfserve.sovrin.org/ Ignore the `Payment-Address` field.

weiyaous (Sun, 14 Mar 2021 13:43:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=MCftx2FSq2Dfqbth3) Thanks, Wade. I actually want to build my own network. I'm starting to learn HL-indy blockchain. Since I have trouble to build network using original Indy project, I start with von-network and found it is much easier to use. I can simply follow the script to deploy a network, so I'm asking whether I can use non-network go further, e.g. adding more nodes.

WadeBarnes (Sun, 14 Mar 2021 13:45:52 GMT):
What are the plans for the network you are building?

weiyaous (Sun, 14 Mar 2021 13:52:21 GMT):
I'm planing to build a network, which allows vehicles to register on the network, and will build agent applications for v-v communication.

weiyaous (Sun, 14 Mar 2021 13:52:36 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=tN9tyWs9WSc4TRCbD) I'm planing to build a network, which allows vehicles to register on the network, and will build agent applications for v-v communication.

WadeBarnes (Sun, 14 Mar 2021 13:53:12 GMT):
So you're trying to build a production grade network?

weiyaous (Sun, 14 Mar 2021 13:54:01 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=ReDs3rcmwoqNZNtkE) Correct.

WadeBarnes (Sun, 14 Mar 2021 13:55:04 GMT):
This should point you in a better direction; https://docs.google.com/document/d/1XE2QOiGWuRzWdlxiI9LrG9Am9dCfPXBXnv52wGHorNE/edit

weiyaous (Sun, 14 Mar 2021 14:01:48 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=cEjmYZuhsQGsFBDA5) I'll check it, thank you very much :blush:

HighBrow (Tue, 16 Mar 2021 06:42:34 GMT):
Has joined the channel.

stranger (Wed, 17 Mar 2021 05:49:55 GMT):
Has joined the channel.

stranger (Wed, 17 Mar 2021 05:50:42 GMT):
https://medium.com/coinmonks/hyperledger-indy-custom-network-with-indy-node-plenum-protocol-ledger-85fd10eb5bf5 You can also check this tutorial

esplinr (Thu, 18 Mar 2021 20:50:01 GMT):
It would be great to add one of those tutorials to the indy-node/docs folder.

weiyaous (Fri, 19 Mar 2021 01:28:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=GRenx9bGxaWdGFAxN) Hi, there, I found this tutorial, but some steps cannot go through.

WadeBarnes (Fri, 19 Mar 2021 12:05:55 GMT):
The document link I provided was written by @lynn.bendixsen, who has been involved with Indy Node network operations for a number of years.

mbanerjee (Fri, 19 Mar 2021 19:04:15 GMT):
Hi, I am following https://hyperledger-indy.readthedocs.io/projects/sdk/en/latest/docs/getting-started/run-getting-started.html When i run docker-compose up in indy-sdk/docs/getting-started - Step 5/8 : RUN pip3 install -U pip ipython-notebook ipython==7.9 setuptools jupyter python3-indy==1.11.0 ---> Running in 939c8e6357d4 Collecting pip Downloading https://files.pythonhosted.org/packages/fe/ef/60d7ba03b5c442309ef42e7d69959f73aacccd0d86008362a681c4698e83/pip-21.0.1-py3-none-any.whl (1.5MB) Collecting ipython-notebook Could not find a version that satisfies the requirement ipython-notebook (from versions: ) No matching distribution found for ipython-notebook You are using pip version 8.1.1, however version 21.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 ipython-notebook ipython==7.9 setuptools jupyter python3-indy==1.11.0' returned a non-zero code: 1

SeriousM 4 (Sat, 20 Mar 2021 11:17:19 GMT):
Has joined the channel.

HighBrow (Sun, 21 Mar 2021 07:05:52 GMT):
Dear all, can anyone explain how is a transaction marked with a Tombstone on the ledger? Reference: Section 1.4, https://sovrin.org/wp-content/uploads/Sovrin-Ledger-Access-Policies-V1.pdf

WadeBarnes (Sun, 21 Mar 2021 15:32:00 GMT):
@weiyaous, @stranger, @esplinr, @lynn.bendixsen; https://github.com/hyperledger/indy-node/issues/1674

WadeBarnes (Sun, 21 Mar 2021 15:33:15 GMT):
@weiyaous, Would you be able to provide details on the ticket as to which steps (in @stranger's tutorial) you were unable to follow and why.

weiyaous (Sun, 21 Mar 2021 15:39:20 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=aDATQj26fZxg499mC) When I run the prerequisites.sh script provided by @stranger, there are some issue caused by missing dependency for some python package. I added some packages, and tested in a fresh Ubuntu 16.04. It works correctly, here is the file I modified. https://github.com/wYaobiz/Hyperledger-Indy-Tutorial/blob/master/prerequisites.sh

WadeBarnes (Sun, 21 Mar 2021 15:40:27 GMT):
Can you add that feedback and information to this ticket please; https://github.com/hyperledger/indy-node/issues/1674

weiyaous (Sun, 21 Mar 2021 15:40:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=BBNyvSrBTTC9gPMJZ) Absolutely!

WadeBarnes (Sun, 21 Mar 2021 15:40:52 GMT):
Perfect! Thanks!

esplinr (Mon, 22 Mar 2021 22:12:56 GMT):
That behavior was never implemented.

esplinr (Mon, 22 Mar 2021 22:13:25 GMT):
https://jira.hyperledger.org/browse/INDY-2082

HighBrow (Tue, 23 Mar 2021 05:17:36 GMT):
@esplinr Any specific reason why this was not implemented? In case it is decided that this will not be implemented, are there any workarounds to achieve the objectives that were supposed to be fulfilled by the implementation of Tombstones. I came to know of the legal arrangements (Transaction Endoreser-Author agreement) that are currently implemented to take care of these issues but not sure of any technical solution currently implemented.

HighBrow (Tue, 23 Mar 2021 05:17:36 GMT):
@esplinr Any specific reason why this was not implemented? In case it is decided that this will not be implemented, are there any workarounds to achieve the objectives that were supposed to be fulfilled by the implementation of Tombstones. I came to know of the legal arrangements (Transaction Endoreser-Author agreement) that are currently implemented to take care of these issues but not sure of any technical solution currently implemented.

timbu (Tue, 23 Mar 2021 14:34:10 GMT):
thank you!

esplinr (Tue, 23 Mar 2021 14:55:57 GMT):
Lots of people thought it was a good idea, but no one volunteered to implement it.

esplinr (Tue, 23 Mar 2021 14:56:52 GMT):
Can you share more information about your use case driving your interest in this feature?

HighBrow (Wed, 24 Mar 2021 04:41:57 GMT):
While studying about Indy I was wondering what could be done if an entity wants to get its data removed from the ledger. That's not usually possible with blockchains but since Indy works on a public permissioned model, I was wondering if something could be done around "Right to be forgotten" if a community plans to use Indy on scale since the community might be interested in addressing that requirement.

esplinr (Wed, 24 Mar 2021 05:09:31 GMT):
Yes, that's exactly the thinking behind Sovrin's proposal for adding a tombstone feature.

esplinr (Wed, 24 Mar 2021 05:09:41 GMT):
Are you launching an Indy network?

timbu (Thu, 25 Mar 2021 12:31:28 GMT):
Dear all, we are running a node in OpenShift in a network and experiencing tcp disconnects in a 30s-1minute timeframe. logs: 2021-03-22 16:20:29,357|NOTIFICATION|keep_in_touch.py|CONNECTION: GS1Germany disconnected from DeutscheBahn 2021-03-22 16:22:19,065|NOTIFICATION|keep_in_touch.py|CONNECTION: GS1Germany now connected to DeutscheBahn 2021-03-22 16:22:48,246|NOTIFICATION|keep_in_touch.py|CONNECTION: GS1Germany disconnected from DeutscheBahn 2021-03-22 16:22:54,064|NOTIFICATION|keep_in_touch.py|CONNECTION: GS1Germany now connected to DeutscheBahn 2021-03-22 16:23:23,855|NOTIFICATION|keep_in_touch.py|CONNECTION: GS1Germany disconnected from DeutscheBahn 2021-03-22 16:25:01,075|NOTIFICATION|keep_in_touch.py|CONNECTION: GS1Germany now connected to DeutscheBahn 2021-03-22 16:25:30,859|NOTIFICATION|keep_in_touch.py|CONNECTION: GS1Germany disconnected from DeutscheBahn 2021-03-22 16:27:20,115|NOTIFICATION|keep_in_touch.py|CONNECTION: GS1Germany now connected to DeutscheBahn 2021-03-22 16:35:32,243|TRACE|remote.py|Remote DeutscheBahn:HA(host='X.X.X.X', port=9701) has monitor events: [512, 4] 2021-03-22 16:35:32,243|DEBUG|remote.py|DeutscheBahn:HA(host='X.X.X.X', port=9701) found disconnected event on monitor 2021-03-22 16:35:32,243|TRACE|remote.py|DeutscheBahn:HA(host='X.X.X.X', port=9701) connection to remote lost, closing monitor socket Do you have any idea how we can solve this?

timbu (Thu, 25 Mar 2021 14:34:49 GMT):
we have reverse proxy which redirects the traffic from public into the pod where the node is up and running

HighBrow (Fri, 26 Mar 2021 07:02:46 GMT):
No, not launching an Indy network as of now. Currently, just doing a preliminary study on what all needs to be done in case a need for launching an Indy network arises. @esplinr Thanks for answering!

weiyaous (Sun, 28 Mar 2021 02:34:09 GMT):

Clipboard - March 27, 2021 10:34 PM

weiyaous (Sun, 28 Mar 2021 02:40:04 GMT):
Dear all, I tried to build indy-node by using script indy-node/build-scripts/ubuntu-1604/build-indy-node.sh. But the script seem like stunk, can anyone explain what's the problem, or how to get more debug information? Thank you.

weiyaous (Sun, 28 Mar 2021 02:40:15 GMT):

Clipboard - March 27, 2021 10:40 PM

weiyaous (Sun, 28 Mar 2021 02:41:05 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=BqrCrdCa9fcDPNnZn)
Clipboard - March 27, 2021 10:41 PM

weiyaous (Sun, 28 Mar 2021 14:16:37 GMT):
Dear all, is there any tutorial or documentation for the indy-test-automation project? https://github.com/hyperledger/indy-test-automation

echsecutor (Thu, 29 Apr 2021 12:26:38 GMT):
Has joined the channel.

ashishtripathi (Fri, 30 Apr 2021 05:37:35 GMT):
Has joined the channel.

ashishtripathi (Fri, 30 Apr 2021 05:37:36 GMT):
Greetings everyone, I have been trying to create local Indy pool. The Indy Node service has been crashing all the time, the restart fails with the below log :`````` ``` ubuntu@ip-172-31-35-22:/var/lib/indy/indy_pool$ sudo systemctl restart indy-node ubuntu@ip-172-31-35-22:/var/lib/indy/indy_pool$ sudo systemctl status indy-node ● indy-node.service - Indy Node Loaded: loaded (/etc/systemd/system/indy-node.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2021-04-30 05:33:01 UTC; 4s ago Main PID: 8764 (python3) Tasks: 1 Memory: 42.1M CPU: 4.859s CGroup: /system.slice/indy-node.service └─8764 python3 -O /usr/local/bin/start_indy_node Node5 127.0.0.1 8707 127.0.0.1 8708 Apr 30 05:33:01 ip-172-31-35-22 systemd[1]: Started Indy Node. ubuntu@ip-172-31-35-22:/var/lib/indy/indy_pool$ sudo systemctl status indy-node ● indy-node.service - Indy Node Loaded: loaded (/etc/systemd/system/indy-node.service; enabled; vendor preset: enabled) Active: activating (auto-restart) (Result: exit-code) since Fri 2021-04-30 05:33:07 UTC; 8s ago Process: 8764 ExecStart=/usr/bin/env python3 -O /usr/local/bin/start_indy_node ${NODE_NAME} ${NODE_IP} ${NODE_PORT} ${NODE_CLIENT_IP} ${NODE_CLIENT_PORT} (code=exited, status=1/FA Main PID: 8764 (code=exited, status=1/FAILURE) Apr 30 05:33:07 ip-172-31-35-22 systemd[1]: indy-node.service: Unit entered failed state. Apr 30 05:33:07 ip-172-31-35-22 systemd[1]: indy-node.service: Failed with result 'exit-code'. lines 1-8/8 (END) ``` ``` Appreciate your help! ```

WadeBarnes (Fri, 30 Apr 2021 11:53:01 GMT):
Easiest way to spin up a local indy node pool fro development; https://github.com/bcgov/von-network

swcurran (Fri, 30 Apr 2021 22:29:37 GMT):
Anyone (such as @sergey.khoroshavin ) know why GET_TXN does not return a state proof? Is there something technical that prevents it? https://hyperledger-indy.readthedocs.io/projects/node/en/latest/requests.html#get-txn

swcurran (Fri, 30 Apr 2021 22:29:37 GMT):
Anyone (such as @sergey.khoroshavin ) know why GET_TXN does not return a state proof? Is there something technical that prevents it? https://hyperledger-indy.readthedocs.io/projects/node/en/latest/requests.html#get-txn Other calls such as GET_NYM etc. do return a state proof.

andrew.whitehead (Sat, 01 May 2021 02:16:11 GMT):
I think it does, it may have been added after that doc was last updated, for example: ```json { "reqId": 1619835242480791000, "type": "3", "data": { "txn": { "metadata": {}, "type": "1", "data": { "alias": "Phil Windley", "verkey": "Ce9jZ2bQcLRCrY3eT5AbjsU5mXFa4jMF6dDSF21tyeFJ", "dest": "NMjQb59rKTJXKNqVYfcZFi", "role": "0" } }, "ledgerSize": 3820, "txnMetadata": { "seqNo": 1 }, "ver": "1", "reqSignature": {}, "auditPath": [ "6rwuBfxhqdByev94TgaXrC3TyDYnPvoChi86in3tj1gc", "WxtLaCqWq36hcqozYp5WFJGmCPtUh1nuSU3tkB5RZmq", "8wDKUacWg4FnQVKtP19FPnoUVCmde9nEAcmAPxALchcY", "4CLGbPXiRtz9ZPTZhqQXT6x9m7oXk2hMKcHapSctNNU9", "A8jffZvHSJRdfTwKdM11DHoVzJRT6CPwUCcsDrZPRC3Y", "Dxqzgs8B7xgWkBoQmj5dh1Nz6xDZo6tGpwzTC7tm3pdq", "E3kipUhFZyj4AwmXyszXy7kAm5pCgahERuG9hBqWC1eP", "2FXfH7rbeJtN1S6PHFttem4kEarJoCQtHkvKLnb8hM4K", "9UgJwPT2MHMENUT4agY7RsfUKDUBP9sTuLpbi69oEzqZ", "EHYdGpgaWwxMZsxTbFXLdqanUX215CBEJTUnf9Ybhh6L", "3DQzm1Lp56gBwxR35mkq4QcXGTq5QsEzbYZCHpjFPjTq", "HZoWrJCRTuqSk92D7v6zKdWYrY76V5vEdcF5BHE2Ka8v" ], "rootHash": "HddFoTMW3eWrj8KrQgBusyDKkbP14TtSH1MqUCw2NzEB" }, "identifier": "LibindyDid111111111111", "state_proof": { "multi_signature": { "participants": [ "Dynenode1", "Axuall", "MainIncubator", "riddleandcode", "DHIWAY", "xsvalidatorec2irl", "danube", "ovvalidator", "validatedid", "mitrecorp", "fetch-ai", "ifis", "makolab01" ], "signature": "RZ5EN7DmyEr42dMfrPoEPdWs5faq2ye6viaJdKboY8ffaGuaHQRq8iA7dnPxBR7xMeaH2Y9esNrwTkKWgQKpxF8Mb3gzqvJ176dxXKZrukkTrosGpsx4pFKaQ8ck1er4BA6oZuwnjcbUAUSPLPoof8Dm4b8cSb6WknwkXb8EBwoayV", "value": { "ledger_id": 1, "state_root_hash": "6Q5jnqiGtnThVq1qPd6NWcgwguc4AkFN7vmFDX1aUXkB", "txn_root_hash": "HddFoTMW3eWrj8KrQgBusyDKkbP14TtSH1MqUCw2NzEB", "timestamp": 1619835187, "pool_state_root_hash": "4UTk1Eh3Fruxnhx6aCnf71ALDfhT9NBEErg3fQxofyQX" } } }, "seqNo": 1 } ```

swcurran (Sat, 01 May 2021 02:49:41 GMT):
Cool -- thanks!

ashishtripathi (Sat, 01 May 2021 17:36:12 GMT):
We want to create our own private Indy pool. Earlier we were using Von for development, but the requirements has changed.

ashishtripathi (Sat, 01 May 2021 17:36:12 GMT):
We want to create our own private Indy pool. Earlier we were using Von for development, but the requirements has changed. @WadeBarnes

ashishtripathi (Mon, 03 May 2021 08:50:00 GMT):
I am trying to add a node to my local Indy pool after adding 5 STEWARD, but getting the below error : pool(local-pool):myWallet:did(V4S...e6f):indy> did new Did "JGagFrXFdGMNyyt4VHNRtS" has been created with "~Ni7NaVXUW9EsSUj4DPKCBs" verkey pool(local-pool):myWallet:did(V4S...e6f):indy> ledger nym did=JGagFrXFdGMNyyt4VHNRtS verkey=~Ni7NaVXUW9EsSUj4DPKCBs role=STEWARD Nym request has been sent to Ledger. Metadata: +------------------------+-----------------+---------------------+---------------------+ | From | Sequence Number | Request ID | Transaction time | +------------------------+-----------------+---------------------+---------------------+ | V4SGRU86Z58d6TV7PBUe6f | 12 | 1620029800503576942 | 2021-05-03 08:16:40 | +------------------------+-----------------+---------------------+---------------------+ Data: +------------------------+-------------------------+---------+ | Did | Verkey | Role | +------------------------+-------------------------+---------+ | JGagFrXFdGMNyyt4VHNRtS | ~Ni7NaVXUW9EsSUj4DPKCBs | STEWARD | +------------------------+-------------------------+---------+ pool(local-pool):myWallet:did(V4S...e6f):indy> ledger node target=FrWkWRL61qJ1MC2cxypDfTzEdJJh6tR5qatrFSshRxcS client_port=7704 client_ip=127.0.0.1 alias=NewNode4 node_ip=127.0.0.1 node_port=7703 services=VALIDATOR blskey=y8JMrDepUVq9o1bSSyPnaQz3Z8U7MRqSdZngfzh75qn4GEV43aoKkNPi557uPR5nii4RRadC1rUxZq5LacYNbfhodLSVGtJAaXwgxSTHzuX5iyswu4J6Y8XgxA1KPfobCH8uY4jDprGq59QwLARhSZg7nzZibEdpF7z2NUHjTyxHAy blskey_pop=RK3dfpnix5reUQrTMRHrNTzn9pCt2HvYwjkYujxrAUY8sd1UCbv9nXhQBqhr2rsdigawzEj8qqCbnWWXfp423GwXi9P2DyFU73EVuH6UscCcpLeJDXofpN34rjbYgmSbpTcyxCFmZMRuDWR8WKr2iBXTGionfS78Z7qXziY481DJvT *Transaction has been rejected: Not enough STEWARD signatures*

WadeBarnes (Mon, 03 May 2021 11:37:11 GMT):
The transaction needs to be created by the DID of the Steward you just wrote to the ledger.

WadeBarnes (Mon, 03 May 2021 11:39:12 GMT):
https://github.com/hyperledger/indy-node/issues/1674

cam-parra (Mon, 03 May 2021 17:57:28 GMT):
@WadeBarnes Do you know how long an upgrade transaction should take? I sent it to my ledger and it's been about 30 minutes and it still shows the same indy-node version

WadeBarnes (Mon, 03 May 2021 18:03:01 GMT):
It typically takes less then 5 minutes for each node to upgrade. What was the form of the upgrade transaction you used?

cam-parra (Mon, 03 May 2021 18:07:37 GMT):
```ledger pool-upgrade name=indynodeupgrade202105 version=1.12.4 action=start sha256=3405e41a0d175d297ea7b1da7024598809c76c0c746481553c68f696a7840cdc schedule={filled out in actual transaction} timeout=15 force=true package=indy-node```

cam-parra (Mon, 03 May 2021 18:08:51 GMT):
I don't use the sovrin package but would that be an issue?

WadeBarnes (Mon, 03 May 2021 18:17:05 GMT):
Only if the network is running a sovrin based install.

WadeBarnes (Mon, 03 May 2021 18:17:27 GMT):
Also you should not need `force=true`.

cam-parra (Mon, 03 May 2021 18:46:44 GMT):
for some reason it doesn't seem to do anything even though the validator info says it started

cam-parra (Mon, 03 May 2021 18:54:40 GMT):
Has anyone been able to do a succesful version upgrade of indy-node without the sovrin package?

WadeBarnes (Mon, 03 May 2021 19:45:27 GMT):
Does the upgrade show as scheduled on the nodes?

WadeBarnes (Mon, 03 May 2021 19:47:32 GMT):
`indy-cli`; `ledger get-validator-info` command or `validator-info -v` on the node. If the upgrade was successfully scheduled. There will be a section indicating when it's scheduled for.

WadeBarnes (Mon, 03 May 2021 19:47:46 GMT):
The nodes use UTC, BTW.

WadeBarnes (Mon, 03 May 2021 19:49:10 GMT):
[hyperledger/indy-node-monitor](https://github.com/hyperledger/indy-node-monitor) is a great tool for getting node info.

WadeBarnes (Mon, 03 May 2021 19:52:19 GMT):
The `--status` flag will help highlight things like scheduled or failed upgrades with the help of the analysis plugin; - https://github.com/hyperledger/indy-node-monitor/blob/main/fetch-validator-status/plugins/analysis.py#L118-L122

ashishtripathi (Tue, 04 May 2021 07:33:17 GMT):
@WadeBarnes Thanks, this worked.

cam-parra (Tue, 04 May 2021 16:18:53 GMT):
```2021-05-04 15:25:52,765|INFO|upgrader.py|FBMeRM31sPVPnD147P6gQzx1jhF5RvXDsnmTbrSye7zX's upgrader processing upgrade for version indy-node=1.12.4 2021-05-04 15:25:52,765|INFO|upgrader.py|FBMeRM31sPVPnD147P6gQzx1jhF5RvXDsnmTbrSye7zX's upgrader calling agent for upgrade 2021-05-04 15:25:52,765|INFO|node.py|KivaWater is about to be upgraded, sending NODE_UPGRADE in_progress to version 1.12.4 2021-05-04 15:25:52,767|INFO|upgrader.py|Sending message to control tool: {"version": "1.12.4", "message_type": "upgrade", "pkg_name": "indy-node"} 2021-05-04 15:25:52,768|INFO|upgrader.py|Waiting 10 minutes for upgrade to be performed 2021-05-04 15:35:52,777|INFO|upgrader.py|Timeout exceeded for 2021-05-03 18:45:49+00:00:1.12.4 2021-05-04 15:35:52,777|ERROR|upgrader.py|Node KivaWater failed upgrade 162006618664141520016 to version 1.12.4 of package indy-node scheduled on 2021-05-03 18:45:49+00:00 because of exceeded upgrade timeout```

cam-parra (Tue, 04 May 2021 16:19:13 GMT):
So these are the logs I am seeing @WadeBarnes

mvaibhav (Wed, 05 May 2021 09:23:02 GMT):
How can a single transaction be signed by multiple stewrads? I mean I want to add a new steward but it needs three steward signatures, how will I proceed?

mvaibhav (Wed, 05 May 2021 09:38:18 GMT):
Has anybody here tried to run Hyperledger-Indy on Blockchain automation framework?

waqaswahid1 (Thu, 06 May 2021 09:10:21 GMT):
Has joined the channel.

waqaswahid1 (Thu, 06 May 2021 09:10:22 GMT):
hi

esplinr (Fri, 07 May 2021 22:07:20 GMT):
Demo using the Indy CLI: https://youtu.be/UsMjiXz18lE?list=PLRp0viTDxBWGLdZk0aamtahB9cpJGV7ZF&t=520 GUI tool: https://github.com/sovrin-foundation/steward-tools/tree/master/token-minter Demo of GUI tool: https://youtu.be/bcBeKilkink?t=292

esplinr (Fri, 07 May 2021 22:07:20 GMT):
Demo using the Indy CLI: https://youtu.be/UsMjiXz18lE?list=PLRp0viTDxBWGLdZk0aamtahB9cpJGV7ZF&t=520 GUI tool: https://github.com/sovrin-foundation/steward-tools/tree/master/token-minter Demo of GUI tool: https://youtu.be/bcBeKilkink?list=PLRp0viTDxBWGLdZk0aamtahB9cpJGV7ZF&t=295t=292

mvaibhav (Sun, 09 May 2021 18:58:20 GMT):
Thanks @esplinr

paul.bastian (Mon, 10 May 2021 14:09:53 GMT):
Hi there, I'm getting "no creating new batch because there are already 4 in flight out of 4 allowed" info. Anyone has insight of what this means and how it evolves?

lmtriet (Tue, 11 May 2021 12:27:44 GMT):
Has joined the channel.

echsecutor (Tue, 11 May 2021 15:36:17 GMT):
At ID Union, we are currently working on non-ubuntu16 based containers for indy node. https://github.com/IDunion/indy-node-container WIP, we just got the firts (ubuntu 18 and debian buster based) containers running. Any hints to similar efforts/existing work on containerizing indy node and of course contributions are most welcome.

jkrstic (Sat, 22 May 2021 18:11:23 GMT):
Has joined the channel.

conanoc (Wed, 26 May 2021 05:17:38 GMT):
Has joined the channel.

conanoc (Wed, 02 Jun 2021 03:11:29 GMT):
Is it possible to use hostname instead of IP in the pool_transactions_genesis file for NODE_IP?

conanoc (Wed, 02 Jun 2021 03:11:29 GMT):
Is it possible to use hostname instead of IP for NODE_IP in the pool_transactions_genesis file?

WadeBarnes (Wed, 02 Jun 2021 12:46:29 GMT):
Short answer is; No.

WadeBarnes (Wed, 02 Jun 2021 12:48:33 GMT):
indy-node does not support DNS resolution of nodes. This helps ensure registered nodes are "well known" via their distinct IP Address.

conanoc (Thu, 03 Jun 2021 02:27:59 GMT):
I see. But, then I could not run indy-node on kubernetes.

conanoc (Thu, 03 Jun 2021 07:37:06 GMT):
I was mistaken. I could use the IP address of the service on kubernetes.

sergio.anguita (Fri, 04 Jun 2021 08:08:05 GMT):
Has joined the channel.

sergio.anguita (Fri, 04 Jun 2021 12:11:27 GMT):
anyone tried to run indy-node on docker with ubuntu version set to 21.10?

swcurran (Fri, 04 Jun 2021 15:05:46 GMT):
No. Indy Node is currently only running officially on Ubuntu 16.04. We're in the midst of upgrading to Ubuntu 20.04, but need some help to get that completed. Most of it is done, but not all...

sergio.anguita (Mon, 07 Jun 2021 08:32:23 GMT):
so what's missing? I might take a look on current status...

echsecutor (Mon, 07 Jun 2021 09:08:53 GMT):
we have a running 20.04 Container. I would recommend targeting LTS versions only. Main problem (as usual) are dependencies/packages

echsecutor (Mon, 07 Jun 2021 09:08:53 GMT):
we have a running 18.04 Container. I would recommend targeting LTS versions only. Main problem (as usual) are dependencies/packages

sergio.anguita (Mon, 07 Jun 2021 09:09:20 GMT):
yes, I notice that with indy-plenum dependency mostly

echsecutor (Mon, 07 Jun 2021 09:17:06 GMT):
dependencies on the archived libindy-crypto and hence libssl 1.0.0 are most problematic, I think. See here for what we have running: https://github.com/IDunion/indy-node-container/tree/main/build

WadeBarnes (Mon, 07 Jun 2021 13:48:35 GMT):
Is someone able to remind me what `Suspecting inconsistent 3PC state` means.

ianco (Mon, 07 Jun 2021 13:58:17 GMT):
https://jira.hyperledger.org/browse/INDY-1199

WadeBarnes (Mon, 07 Jun 2021 14:01:36 GMT):
Thanks, always forget to search the Jira boards.

WadeBarnes (Mon, 07 Jun 2021 14:12:18 GMT):
Having the PRs makes it much easier to follow. Thanks

sergio.anguita (Mon, 07 Jun 2021 14:46:23 GMT):
@echsecutor any guide about how to contribute more specifically?

swcurran (Mon, 07 Jun 2021 16:42:08 GMT):
@WadeBarnes can you give an update on the status and how to contribute. We are into the CD phase of the project -- so very close.

WadeBarnes (Mon, 07 Jun 2021 16:51:37 GMT):
@sergio.anguita, @RobinKlemens, and @devinleighsmith have been driving a lot of the CI/CD updated from two sides, Robin from the Plenum/Node side and Devin backward from the Sovrin/Token Plugin side. Next steps are for this CD work (https://github.com/hyperledger/indy-plenum/pull/1541) to be completed and then integrated with the 20.04 build processes in the https://github.com/hyperledger/indy-plenum/tree/ubuntu-20.04-upgrade branch. The same patterns can then be used and applied to the https://github.com/hyperledger/indy-node CI/CD process in the same branches. Tickets for the Ubuntu 20.04 work can be found here; https://github.com/hyperledger/indy-plenum/issues?q=is%3Aissue+is%3Aopen+label%3A%22Ubuntu+20.04%22 And important summary of the current CD work can be found in this ticket; https://github.com/hyperledger/indy-plenum/issues/1537

WadeBarnes (Mon, 07 Jun 2021 16:54:23 GMT):
Tickets for the Ubuntu 20.04 work on the Node side can be found here; https://github.com/hyperledger/indy-node/issues?q=is%3Aissue+is%3Aopen+label%3A%22Ubuntu+20.04%22

WadeBarnes (Mon, 07 Jun 2021 16:55:05 GMT):
The work on Plenum needs to be completed first, since it's needed for the Node work.

WadeBarnes (Mon, 07 Jun 2021 16:58:38 GMT):
Thanks to @Toktar and team, @askolesov, etc, for creating the tickets and performing the majority of the Ubuntu 20.04 upgrade work to get us to this point.

sergio.anguita (Tue, 08 Jun 2021 14:39:04 GMT):
Okey, I'll take a look to those links. In the meantime, our team has built a indy-node image based on LTS debian. Is there any test suite we can use to check all indy-node features are working properly?

WadeBarnes (Tue, 08 Jun 2021 14:57:21 GMT):
https://github.com/hyperledger/indy-test-automation

WadeBarnes (Tue, 08 Jun 2021 14:59:16 GMT):
Please consider contributing back to the upstream projects so the community and project as a whole can benefit from your efforts.

WadeBarnes (Tue, 08 Jun 2021 15:00:20 GMT):
@devinleighsmith has some of the most recent experience with `https://github.com/hyperledger/indy-test-automation`.

Bechir (Tue, 08 Jun 2021 19:01:11 GMT):
Has joined the channel.

Bechir (Tue, 08 Jun 2021 19:01:13 GMT):
.

conanoc (Fri, 11 Jun 2021 09:17:38 GMT):
I could add node to existing pool (https://github.com/hyperledger/indy-node/blob/master/docs/source/add-node.md). Can I also remove node from the pool?

WadeBarnes (Fri, 11 Jun 2021 11:36:00 GMT):
Setting `services=` removes the node from the list of Validators. Example: ``` ledger node target=6G9QhQa3HWjRKeRmEvEkLbWWf2t7cw6KLtafzi494G4G alias=NewNode services= ```

tusharbansal (Sun, 13 Jun 2021 18:29:59 GMT):
Has joined the channel.

Yunxi 3 (Mon, 14 Jun 2021 10:55:59 GMT):

Clipboard - June 14, 2021 11:55 AM

Yunxi 3 (Mon, 14 Jun 2021 10:56:08 GMT):

Clipboard - June 14, 2021 11:56 AM

Yunxi 3 (Mon, 14 Jun 2021 10:56:54 GMT):
Hello all and @swcurran , I see VON provides services for users to use their dev, staging and von services on this link: https://vonx.io/clickythings/. I've got 2 questions. Q1. Does VON provide the underlying Indy network in the production environment? I can see nodes info for dev env, but can't see nodes info for prod. Q2. To use VON network, does a user need to pay for any transaction fees like how Sovrin does (e.g. it incurs charges for different types of transactions)?

WadeBarnes (Mon, 14 Jun 2021 11:58:45 GMT):
Information on `von-network` can be found here; https://github.com/bcgov/von-network. There is no cost to any of the `von-network` base ledgers, though we appreciate development contributions to the project, and especially to the underlying Hyperledger Indy-Node and Indy-Plenum projects that power all of the Hyperledger Indy Networks. `von-network` It is intended to be used as a provisional Hyperledger Indy Node ledger for testing and development only. We provide a few hosted instances to support the BC Government's `dev` and `test` environments and the community is free to use them. There is no production level `von-network` instance. If you are looking for a production level Hyperledger Indy Node network you'll want to have a look at a network like [Sovrin](https://sovrin.org/overview/). The `Sovrin Main Net` ledger browser you have pictured above is a `von-network` ledge browser connected (read-only) to Sovrin MainNet. You can register a DID on either Sovrin BuilderNet (`dev`) or Sovrin StagingNet (`test`) for free here; [Sovrin Self Serve](https://selfserve.sovrin.org/). More information about how to join the Sovrin MainNet (`prod`) ledger can be found here; [Sovrin](https://sovrin.org/overview/)

WadeBarnes (Mon, 14 Jun 2021 11:58:45 GMT):
Information on `von-network` can be found here; https://github.com/bcgov/von-network. There is no cost to any of the `von-network` base ledgers, though we appreciate development contributions to the project, and especially to the underlying Hyperledger Indy-Node and Indy-Plenum projects that power all of the Hyperledger Indy Networks. `von-network` is intended to be used as a provisional Hyperledger Indy Node ledger for testing and development only. We provide a few hosted instances to support the BC Government's `dev` and `test` environments and the community is free to use them. There is no production level `von-network` instance. If you are looking for a production level Hyperledger Indy Node network you'll want to have a look at a network like [Sovrin](https://sovrin.org/overview/). The `Sovrin Main Net` ledger browser you have pictured above is a `von-network` ledge browser connected (read-only) to Sovrin MainNet. You can register a DID on either Sovrin BuilderNet (`dev`) or Sovrin StagingNet (`test`) for free here; [Sovrin Self Serve](https://selfserve.sovrin.org/). More information about how to join the Sovrin MainNet (`prod`) ledger can be found here; [Sovrin](https://sovrin.org/overview/)

WadeBarnes (Mon, 14 Jun 2021 11:58:45 GMT):
Information on `von-network` can be found here; https://github.com/bcgov/von-network. There is no cost to any of the `von-network` base ledgers, though we appreciate development contributions to the project, and especially to the underlying Hyperledger Indy-Node and Indy-Plenum projects that power all of the Hyperledger Indy Networks. `von-network` is intended to be used as a provisional Hyperledger Indy Node ledger for testing and development only. We provide a few hosted instances to support the BC Government's `dev` and `test` environments and the community is free to use them. There is no production level `von-network` instance. If you are looking for a production level Hyperledger Indy Node network you'll want to have a look at a network like [Sovrin](https://sovrin.org/overview/). The `Sovrin Main Net` ledger browser you have pictured above is a `von-network` ledger browser connected (read-only) to Sovrin MainNet. You can register a DID on either Sovrin BuilderNet (`dev`) or Sovrin StagingNet (`test`) for free here; [Sovrin Self Serve](https://selfserve.sovrin.org/). More information about how to join the Sovrin MainNet (`prod`) ledger can be found here; [Sovrin](https://sovrin.org/overview/)

WadeBarnes (Mon, 14 Jun 2021 11:58:45 GMT):
Information on `von-network` can be found here; https://github.com/bcgov/von-network. There is no cost to any of the `von-network` based ledgers, though we appreciate development contributions to the project, and especially to the underlying Hyperledger Indy-Node and Indy-Plenum projects that power all of the Hyperledger Indy Networks. `von-network` is intended to be used as a provisional Hyperledger Indy Node ledger for testing and development only. We provide a few hosted instances to support the BC Government's `dev` and `test` environments and the community is free to use them. There is no production level `von-network` instance. If you are looking for a production level Hyperledger Indy Node network you'll want to have a look at a network like [Sovrin](https://sovrin.org/overview/). The `Sovrin Main Net` ledger browser you have pictured above is a `von-network` ledger browser connected (read-only) to Sovrin MainNet. You can register a DID on either Sovrin BuilderNet (`dev`) or Sovrin StagingNet (`test`) for free here; [Sovrin Self Serve](https://selfserve.sovrin.org/). More information about how to join the Sovrin MainNet (`prod`) ledger can be found here; [Sovrin](https://sovrin.org/overview/)

Yunxi 3 (Mon, 14 Jun 2021 17:10:28 GMT):
Thanks for your useful answer @WadeBarnes !!!

Yunxi 3 (Mon, 14 Jun 2021 17:17:57 GMT):
@WadeBarnes , do you know when did the first VON network (either dev or test) was setup and launched? how many nodes do they use?

WadeBarnes (Mon, 14 Jun 2021 17:18:45 GMT):
`von-network` is always made up of a fixed set of 4 nodes.

WadeBarnes (Mon, 14 Jun 2021 17:19:22 GMT):
We've been running our `dev` and `test` instances for a few years now.

Yunxi 3 (Mon, 14 Jun 2021 17:19:53 GMT):
do you know which year they were set up and running ?

WadeBarnes (Mon, 14 Jun 2021 17:20:29 GMT):
The largest use-case for `von-network` is spinning up a local instance for development.

Yunxi 3 (Mon, 14 Jun 2021 17:23:34 GMT):
Thanks @WadeBarnes , i know how to set up a local one, just trying to understand when the dev and test instances were set up that are available in the VON website?

WadeBarnes (Mon, 14 Jun 2021 17:23:43 GMT):
March 2018 was the first hosted instance we deployed.

Yunxi 3 (Mon, 14 Jun 2021 17:23:54 GMT):
thanks

echsecutor (Tue, 15 Jun 2021 10:59:24 GMT):
Thanks for the testing link! We are currently just spinning up a 4 node test notwork and checking the explorer ( https://github.com/IDunion/indy-node-container/blob/main/.github/workflows/ledger-test.yml -> https://github.com/IDunion/indy-node-container/tree/main/test ) but we will also look into a more complete test setup.

echsecutor (Tue, 15 Jun 2021 11:00:45 GMT):
@sergio.anguita did you already adress the issue of how to implement node_controller (like) functionality for a containerized setup? (pool restart, pool upgrade, ...)

deulu (Mon, 28 Jun 2021 08:56:50 GMT):
Has joined the channel.

deulu (Mon, 28 Jun 2021 09:40:49 GMT):
Hi everyone, I have a question about indy node performance. When we perform a load test with indy java wrapper, the tps values we get are very low (for example, the tps value for nym request is around 50-60) and when we monitor,we saw that java threads are waiting on submit request step. Does anyone have a similar load test and get different values? Or if you can get much higher tps values, what would you suggest to check? Not only write request but also read request is giving similar tps results. We made our test in our private network ( which 4 nodes on same machine different docker containers and machine resources 40 GB ram,30 CPU, 105 GB storage.)

MikeSmith (Thu, 01 Jul 2021 05:19:08 GMT):
Has joined the channel.

domwoe (Thu, 01 Jul 2021 10:51:13 GMT):
We experience an issue with a huge IC_queue. Our validator_info response has a size of around 7MB. The issue started already in March, when lots of view changes were triggered before the view change could be completed. View_no to be voted for increased from 8044 to 10931. Then a node voted for a view change to 8045 again which was successful. However every node still carries the huge IC_queue. Restarting does not help since the IC_queue is persisted.

domwoe (Thu, 01 Jul 2021 10:53:16 GMT):

extract.txt

domwoe (Thu, 01 Jul 2021 10:56:25 GMT):
Does anyone know what could be the cause of the initial build up of unsuccessful view changes that still increase the view_no to be voted for ? I think there should be a mechanism to prevent the IC_queue to grow out of bounds

domwoe (Thu, 01 Jul 2021 10:56:25 GMT):
Does anyone know what could be the cause of the initial build up of unsuccessful view changes that still increase the view_no to be voted for ? I think there should be a mechanism to prevent the IC_queue to grow out of bounds and is there a way to flush the IC_queue right now?

swcurran (Thu, 01 Jul 2021 14:15:05 GMT):
@Toktar -- do you have any input on this ^^^

gaberasturi (Fri, 02 Jul 2021 07:45:28 GMT):
Has joined the channel.

echsecutor (Fri, 02 Jul 2021 07:49:13 GMT):
Hi all! it seems that the current deb repositories gpg signature has expired? ``` W: 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. ```

sergey.khoroshavin (Fri, 02 Jul 2021 10:26:18 GMT):
I looks like so - I'm having same issues

sergey.khoroshavin (Fri, 02 Jul 2021 10:27:00 GMT):
FYI @WadeBarnes

WadeBarnes (Fri, 02 Jul 2021 11:20:24 GMT):
https://chat.hyperledger.org/channel/indy-sdk?msg=Nx69W84ZokW27swYN

WadeBarnes (Fri, 02 Jul 2021 12:16:22 GMT):
The issues with the expired GPG signatures on `repo.sovrin.org` have been resolved.

WadeBarnes (Fri, 02 Jul 2021 12:16:44 GMT):
The issues with the expired GPG signatures on `repo.sovrin.org` have been resolved.

WadeBarnes (Fri, 02 Jul 2021 12:23:31 GMT):
https://chat.hyperledger.org/channel/indy-node?msg=ahWfxAh2vr88p3Pj2

echsecutor (Fri, 02 Jul 2021 12:23:35 GMT):
confirmed. Awesome! Many thanks for the quick fix! :)

WadeBarnes (Fri, 02 Jul 2021 12:24:46 GMT):
Not as quick as I'd like it to have been. :wink:

mahengct (Sat, 03 Jul 2021 13:08:48 GMT):
Has joined the channel.

PatrikStas (Mon, 09 Aug 2021 09:18:25 GMT):
I am observing that `txnTime` field on transactions tend to be about 30 seconds in the future. Seeing this happening on Sovrin stagingnet net for sure. Seems like a bug. Just open https://indyscan.io/home/SOVRIN_STAGINGNET and wait till new TX comes on the homepage. It will display `Unknown time` as I assume `txnTime` wouldn't be in future.

PatrikStas (Mon, 09 Aug 2021 09:18:25 GMT):
I am observing that `txnTime` field on transactions tend to be about 30 seconds in the future. Seeing this happening on Sovrin stagingnet net for sure. Seems like a bug. Just open https://indyscan.io/home/SOVRIN_STAGINGNET and wait till new TX comes on the homepage. It will display `Unknown time` as I assumed `txnTime` wouldn't be in future.

PatrikStas (Mon, 09 Aug 2021 09:21:13 GMT):
For a record, it was definitely case with this TX https://indyscan.io/tx/SOVRIN_STAGINGNET/domain/246442 I saw the transaction before even 09:16

WadeBarnes (Mon, 09 Aug 2021 11:33:17 GMT):
Having a look.

WadeBarnes (Mon, 09 Aug 2021 12:09:54 GMT):
I think I found the issue. The time stamp for the current primary node is about 45 seconds in the future. All others are 1-3 seconds in the past which is what is expected with the indy-node-monitor queries.

WadeBarnes (Mon, 09 Aug 2021 12:10:19 GMT):
I'm going to bump the node out of the primary position and contact the Steward.

WadeBarnes (Mon, 09 Aug 2021 12:17:42 GMT):
That looks like it fixed the issue.

WadeBarnes (Mon, 09 Aug 2021 12:17:54 GMT):
Thanks @PatrikStas for reporting.

WadeBarnes (Mon, 09 Aug 2021 12:53:02 GMT):
The Steward of the affected node has been contacted and is looking into resolving the issue.

swcurran (Mon, 09 Aug 2021 14:59:44 GMT):
Great catch, and great job at clearing it up @WadeBarnes -- nice work!

ghoshbishakh (Wed, 11 Aug 2021 09:28:39 GMT):
Has joined the channel.

ghoshbishakh (Wed, 11 Aug 2021 09:28:40 GMT):
Hi all, I am trying to add a new kind of transaction or modify NYM transactions to include some additional information. Can anyone point me to the relevant places in the code to do that? I am trying to understand indy-node and indy-plenum codebases for a couple of weeks. Looks like I need to add the new type of transaction to plenum and indy-node. Do I need to make changes to the indy-sdk also?

pSchlarb (Wed, 25 Aug 2021 10:31:53 GMT):
Has joined the channel.

pranjay (Thu, 26 Aug 2021 21:51:33 GMT):
Has joined the channel.

knibals (Wed, 01 Sep 2021 13:50:31 GMT):
Has joined the channel.

bh4rtp (Sun, 05 Sep 2021 14:55:22 GMT):
Has joined the channel.

vsadriano (Wed, 29 Sep 2021 10:29:27 GMT):
Has left the channel.

Yunxi 3 (Thu, 07 Oct 2021 12:52:55 GMT):
Hello all, anyone knows in order to use Soverin's BuilderNet (since 2019), is it free of charge or a user has to fill in a form or any documented guidance available?

WadeBarnes (Thu, 07 Oct 2021 13:02:26 GMT):
`BuilderNet` is free to use; https://selfserve.sovrin.org/

Yunxi 3 (Thu, 07 Oct 2021 14:41:48 GMT):
thanks for the link @WadeBarnes :-)

Yunxi 3 (Fri, 08 Oct 2021 10:15:30 GMT):

Clipboard - October 8, 2021 11:15 AM

Yunxi 3 (Fri, 08 Oct 2021 10:16:12 GMT):
Hello @WadeBarnes , when I followed the self instruction of this doc: https://docs.google.com/document/d/1sXZoN18lpFoAF075QoptofwDV_1otUylPGFKRQnA56E/edit# to set up environments in my Ubuntu VM, after running this command: sudo apt-get install -y indy-cli libsovtoken, I've got error as shown in the screenshot. Are these commands require a specific Ubuntu version? My Ubuntu is 18.04-LTS, btw

Yunxi 3 (Fri, 08 Oct 2021 10:17:01 GMT):

Clipboard - October 8, 2021 11:16 AM

Yunxi 3 (Fri, 08 Oct 2021 10:17:14 GMT):
@WadeBarnes , i also tried the steps for Mac, but I dont understand what to do for the openSSL bit in the screenshot

Yunxi 3 (Fri, 08 Oct 2021 10:17:14 GMT):
@WadeBarnes , i also tried the steps for Mac, but I dont understand what to do for the openSSL bit as step 3 in the screenshot

Yunxi 3 (Fri, 08 Oct 2021 10:17:14 GMT):
@WadeBarnes , i also tried the steps for Mac, but I dont understand what to do for the openSSL bit as step 3 in the screenshot, eventually step 5 doesn't work for me either

Yunxi 3 (Fri, 08 Oct 2021 10:17:59 GMT):

Clipboard - October 8, 2021 11:17 AM

WadeBarnes (Fri, 08 Oct 2021 11:42:45 GMT):
Try using the containerized `indy-cli` built into `von-network`; https://github.com/bcgov/von-network/blob/master/docs/Indy-CLI.md

Yunxi 3 (Fri, 08 Oct 2021 15:00:20 GMT):
@WadeBarnes , when running this code: ./manage cli init-pool builder_net https://raw.githubusercontent.com/sovrin-foundation/sovrin/stable/sovrin/pool_transactions_builder_genesis in my local Mac OS, got error: "Error response from daemon: pull access denied for von-network-base, repository does not exist or may require 'docker login': denied: requested access to the resource is denied". Is this von-network-base image a private one?

Yunxi 3 (Fri, 08 Oct 2021 15:00:20 GMT):
@WadeBarnes , when running this code: ./manage cli init-pool builder_net https://raw.githubusercontent.com/sovrin-foundation/sovrin/stable/sovrin/pool_transactions_builder_genesis in my local Mac OS, got error: "Error response from daemon: pull access denied for von-network-base, repository does not exist or may require 'docker login': denied: requested access to the resource is denied". Is this von-network-base image a private one or not even exist?

WadeBarnes (Fri, 08 Oct 2021 15:02:01 GMT):
Sounds like you missed the `build` step; https://github.com/bcgov/von-network/blob/master/docs/Indy-CLI.md#build-von-network

Yunxi 3 (Fri, 08 Oct 2021 15:02:37 GMT):
that's right, just realised this, my bad

Yunxi 3 (Fri, 08 Oct 2021 15:08:10 GMT):
any restrictions (e.g. x digitals long) on a seed i need to enter?

Yunxi 3 (Fri, 08 Oct 2021 15:10:20 GMT):
figured it out

Yunxi 3 (Fri, 08 Oct 2021 15:18:12 GMT):
qq, once the wallet is closed and detached, no chance to see it by using wallet list command?

Yunxi 3 (Fri, 08 Oct 2021 15:23:23 GMT):
after creating a new wallet named: mywallet with my key value, what's the right command syntax to open it again? I've tried: open mywallet and open mywallet key=, neither works

swcurran (Fri, 08 Oct 2021 15:26:23 GMT):
Should be `wallet open mywallet key=`

Yunxi 3 (Fri, 08 Oct 2021 15:27:49 GMT):

Clipboard - October 8, 2021 4:27 PM

Yunxi 3 (Fri, 08 Oct 2021 15:28:13 GMT):

Clipboard - October 8, 2021 4:28 PM

swcurran (Fri, 08 Oct 2021 15:30:18 GMT):
Odd. THe CLI has autocompletion, so perhaps if you just use `m` it will autocomplete. I'm wondering if it has a weird character in the name? Hmm...maybe it is open already? Seems odd, but I don't see anything else.

Yunxi 3 (Fri, 08 Oct 2021 15:30:55 GMT):

Clipboard - October 8, 2021 4:30 PM

Yunxi 3 (Fri, 08 Oct 2021 15:33:09 GMT):

Clipboard - October 8, 2021 4:32 PM

Yunxi 3 (Fri, 08 Oct 2021 15:33:23 GMT):

Clipboard - October 8, 2021 4:33 PM

WadeBarnes (Fri, 08 Oct 2021 15:38:22 GMT):
How did you create the wallet in the first place? Using the example in the docs I sent?

Yunxi 3 (Fri, 08 Oct 2021 15:38:54 GMT):

Clipboard - October 8, 2021 4:38 PM

Yunxi 3 (Fri, 08 Oct 2021 15:38:55 GMT):
yes, literally following this command

Yunxi 3 (Fri, 08 Oct 2021 15:39:07 GMT):
just change the walletname to my wallet name

WadeBarnes (Fri, 08 Oct 2021 15:39:51 GMT):
And are you sure you are using the same value for the key that was entered when the wallet was created?

Yunxi 3 (Fri, 08 Oct 2021 15:39:52 GMT):

Clipboard - October 8, 2021 4:39 PM

WadeBarnes (Fri, 08 Oct 2021 15:40:19 GMT):
That was able to open the wallet using your key.

Yunxi 3 (Fri, 08 Oct 2021 15:40:30 GMT):
yes, cuz after typing in the key value for the first time to create the wallet, the interactive cli asked me to retype in the key value again to open it

Yunxi 3 (Fri, 08 Oct 2021 15:41:08 GMT):
after typing the seed, it auto showed these info and exit the command

Yunxi 3 (Fri, 08 Oct 2021 15:41:29 GMT):
now i want to use the cli interactive mode to reopen it, but can't

WadeBarnes (Fri, 08 Oct 2021 15:41:29 GMT):
That should be the same key you use to open the wallet manually on the command line. The batch process performs the same commands.

Yunxi 3 (Fri, 08 Oct 2021 15:42:17 GMT):
yes, i did put the same key value to open it, but the command doesn't work

WadeBarnes (Fri, 08 Oct 2021 15:43:43 GMT):
Try `wallet open mywallet key`, and it should prompt you for the key like it did when you first created the wallet.

Yunxi 3 (Fri, 08 Oct 2021 15:44:48 GMT):

Clipboard - October 8, 2021 4:44 PM

WadeBarnes (Fri, 08 Oct 2021 15:47:22 GMT):
Exit the `indy-cli`.

WadeBarnes (Fri, 08 Oct 2021 15:47:26 GMT):
run `./manage cli bash`

WadeBarnes (Fri, 08 Oct 2021 15:47:40 GMT):
That will open a bash command line in the container.

Yunxi 3 (Fri, 08 Oct 2021 15:48:02 GMT):

Clipboard - October 8, 2021 4:47 PM

WadeBarnes (Fri, 08 Oct 2021 15:48:21 GMT):
Run `cd .indy_client/`

WadeBarnes (Fri, 08 Oct 2021 15:48:39 GMT):
`ls wallet`

WadeBarnes (Fri, 08 Oct 2021 15:48:50 GMT):
`ls wallets`

Yunxi 3 (Fri, 08 Oct 2021 15:49:05 GMT):

Clipboard - October 8, 2021 4:49 PM

WadeBarnes (Fri, 08 Oct 2021 15:49:32 GMT):
So the name of the wallet is `my_wallet`

Yunxi 3 (Fri, 08 Oct 2021 15:50:00 GMT):

Clipboard - October 8, 2021 4:49 PM

Yunxi 3 (Fri, 08 Oct 2021 15:50:08 GMT):
okay, but why the name shown in the list is differnet?

WadeBarnes (Fri, 08 Oct 2021 15:50:39 GMT):
because you tried to open a wallet names mywallet that does not exist.

WadeBarnes (Fri, 08 Oct 2021 15:50:39 GMT):
because you tried to open a wallet named mywallet that does not exist.

WadeBarnes (Fri, 08 Oct 2021 15:51:01 GMT):
exit the bash command line

WadeBarnes (Fri, 08 Oct 2021 15:51:26 GMT):
`./manage indy-cli`

WadeBarnes (Fri, 08 Oct 2021 15:51:26 GMT):
`./manage indy-cli``

WadeBarnes (Fri, 08 Oct 2021 15:51:26 GMT):
`./manage indy-cli`

Yunxi 3 (Fri, 08 Oct 2021 15:51:27 GMT):
but the wallet list command shows the wrong wallet name, doesn't it?

Yunxi 3 (Fri, 08 Oct 2021 15:51:46 GMT):
i can now reopen my wallet with the right wallet name, thanks for the help

WadeBarnes (Fri, 08 Oct 2021 15:52:17 GMT):
wallet detach mywallet

WadeBarnes (Fri, 08 Oct 2021 15:52:17 GMT):
`wallet detach mywallet`

WadeBarnes (Fri, 08 Oct 2021 15:52:36 GMT):
`wallet attach my_wallet`

Yunxi 3 (Fri, 08 Oct 2021 15:52:59 GMT):

Clipboard - October 8, 2021 4:52 PM

WadeBarnes (Fri, 08 Oct 2021 15:53:11 GMT):
no `wallet list` should should the correct wallet and you should be able to open it.

WadeBarnes (Fri, 08 Oct 2021 15:53:11 GMT):
now `wallet list` should should the correct wallet and you should be able to open it.

Yunxi 3 (Fri, 08 Oct 2021 15:53:45 GMT):

Clipboard - October 8, 2021 4:53 PM

Yunxi 3 (Fri, 08 Oct 2021 15:54:00 GMT):
but the first one named "mywallet" doesn't exist

WadeBarnes (Fri, 08 Oct 2021 15:54:02 GMT):
You're able to attach a wallet that does not exist, you just can't open it after that.

Yunxi 3 (Fri, 08 Oct 2021 15:54:11 GMT):
ah okay

WadeBarnes (Fri, 08 Oct 2021 15:54:20 GMT):
`wallet detach mywallet`

Yunxi 3 (Fri, 08 Oct 2021 15:55:15 GMT):
once detaching the wallet, any chance to see detached wallets by using any commands?

Yunxi 3 (Fri, 08 Oct 2021 15:55:31 GMT):
think detaching wallet is different from deleting wallet, right?

WadeBarnes (Fri, 08 Oct 2021 15:56:05 GMT):
No. You need to open a bash shell like you did and `ls` the wallet directories.

Yunxi 3 (Fri, 08 Oct 2021 15:56:22 GMT):
okay thanks

WadeBarnes (Fri, 08 Oct 2021 15:56:45 GMT):
Yes `detach` is non-destructive.

WadeBarnes (Fri, 08 Oct 2021 15:57:16 GMT):
`delete` is destructive.

Yunxi 3 (Fri, 08 Oct 2021 15:57:23 GMT):

Clipboard - October 8, 2021 4:56 PM

WadeBarnes (Fri, 08 Oct 2021 15:58:37 GMT):
Yes, you need to create a unique seed, which will then create a unique DID and VerKey.

WadeBarnes (Fri, 08 Oct 2021 16:00:02 GMT):
You can create a random (recommended) seed and wallet key using the `./manage` command; https://github.com/bcgov/von-network/blob/master/docs/Indy-CLI.md#generate-a-set-of-secrets

Yunxi 3 (Fri, 08 Oct 2021 16:01:34 GMT):
a side question, if two persons (let's say 1st guy is the real holder, 2nd one is a malicious guy) can use the same seed to create the same Verkey, does it mean, they can see the same wallet's contents ?

WadeBarnes (Fri, 08 Oct 2021 16:02:48 GMT):
Yes! You need to keep your seed a secret, otherwise someone can impersonate you.

WadeBarnes (Fri, 08 Oct 2021 16:04:22 GMT):
The DID and Verkey are public and safe to distribute if needed. The seed and the wallet key are sensitive and should be kept a secret and stored in a very safe place.

Yunxi 3 (Fri, 08 Oct 2021 16:06:01 GMT):
okay, that's why we should use the randomly seed generation function to generate our seeds to decrease the likelihoods for attackers to guess our seed, right?

Yunxi 3 (Fri, 08 Oct 2021 16:11:20 GMT):
@WadeBarnes , after i successfully register my DID and VerKey to the buildnet, think i can run my ACA-Py agent to connect to the buildnet, what's the buildnet's url?

Yunxi 3 (Fri, 08 Oct 2021 16:11:20 GMT):
@WadeBarnes , after i successfully register my DID and VerKey to the buildnet, think i can run my ACA-Py agent to connect to the buildnet, what's the buildnet's url? Is this url available anywhere?

WadeBarnes (Fri, 08 Oct 2021 16:16:37 GMT):
You would connect your agent to BuilderNet by providing it with the URL to the genesis file for BuilderNet; https://raw.githubusercontent.com/sovrin-foundation/sovrin/stable/sovrin/pool_transactions_builder_genesis

swcurran (Fri, 08 Oct 2021 16:16:47 GMT):
Beat me to it... :-)

Yunxi 3 (Fri, 08 Oct 2021 16:18:03 GMT):
is this the right parameter and value: --genesis-url https://raw.githubusercontent.com/sovrin-foundation/sovrin/stable/sovrin/pool_transactions_builder_genesis?

Yunxi 3 (Fri, 08 Oct 2021 16:23:05 GMT):
also, by using the buildnet, do i need to use this option --tails-server-base-url for running my ACA-Py ?

WadeBarnes (Fri, 08 Oct 2021 16:23:32 GMT):
Or set the `ACAPY_GENESIS_URL` environment variable.

WadeBarnes (Fri, 08 Oct 2021 16:23:51 GMT):
Only if you need to support revocation.

WadeBarnes (Fri, 08 Oct 2021 16:24:21 GMT):
You should direct `aca-py` questions to the #aries-cloudagent-python channel

Yunxi 3 (Mon, 11 Oct 2021 08:22:17 GMT):
thanks for your help @WadeBarnes :-)

Yunxi 3 (Fri, 15 Oct 2021 12:36:35 GMT):
Hello all, does Sovrin networks not provide its default tail server?

swcurran (Fri, 15 Oct 2021 18:12:28 GMT):
No. That's a concept that we came up with at BC Gov and built. BC hosts one for convenience, and we maintain a repo for it for others to deploy.

Yunxi 3 (Fri, 22 Oct 2021 09:49:55 GMT):
Hello @WadeBarnes, once configuring ACA-Py to connect to Sovrin's BuidlerNet, whenever I run the ACA-Py, it will always receive an agreement message from the Sovrin and an interactive response i need to give. Is there a way to auto this process? see screenshot here

Yunxi 3 (Fri, 22 Oct 2021 09:50:16 GMT):

Clipboard - October 22, 2021 10:49 AM

Yunxi 3 (Fri, 22 Oct 2021 09:52:43 GMT):

Clipboard - October 22, 2021 10:52 AM

Yunxi 3 (Fri, 22 Oct 2021 09:56:33 GMT):
thanks for the response @swcurran. Can i check with you on how *revocation registry size * will impact a credential revocation (e.g. in a production env, what aspects we should take into account regarding the revocation registry)? What is the supported size range for this value? This is a value we have to specify when *creating a new credential definition*. I've read this article: https://github.com/hyperledger/indy-hipe/tree/master/text/0011-cred-revocation#proof-of-non-revocation-intervals, but can't find any answer there.

WadeBarnes (Fri, 22 Oct 2021 12:33:06 GMT):
You can use this code as reference; https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L290-L344

WadeBarnes (Fri, 22 Oct 2021 12:34:46 GMT):
`baseURL` is the URL to your `aca-py` instance's admin interface and `apiKey` is the API Key it's expecting.

Yunxi 3 (Mon, 25 Oct 2021 11:58:44 GMT):
Hello @WadeBarnes, don't understand how baseURL and apiKey could help here. Could you help clarify it? When i use: --genesis-url https://raw.githubusercontent.com/sovrin-foundation/sovrin/stable/sovrin/pool_transactions_builder_genesis as the option to connect my ACA-Py to Sovrin's BuilderNet, I wonder how i can skip the agreement message from Sovrin that interrupts my ACA-Py to run?

WadeBarnes (Mon, 25 Oct 2021 14:23:49 GMT):
You can't skip it. You have to agree to and accept it. Once you've done that it won't appear again. The code above provides a reference on how to accept the aggreement.

WadeBarnes (Mon, 25 Oct 2021 14:23:49 GMT):
You can't skip it. You have to agree to and accept it. Once you've done that it won't appear again. The code above provides a reference on how to accept the agreement.

Yunxi 3 (Tue, 26 Oct 2021 12:21:44 GMT):
@swcurran , any updates on the above question?

swcurran (Tue, 26 Oct 2021 19:06:03 GMT):
When the revocation registry is created, a the tails file is created based on the size. The tails file has an entry per credential, so the file size grows linearly with the registry size (number of credentials). The size of that file becomes the limiter, as the holder (such as a mobile wallet) must download and process the file. It is a static file, so they only need to download it once, but then they have to hold it locally -- which takes up space. I don't have the size stats handy, but as I recall, 10k to 20k is about as big as a rev. registry can realistically be.

zickau (Thu, 04 Nov 2021 14:42:34 GMT):
Hi, I Made some tests yesterday: Revoc_Reg_Size=3000, Tailsfile 768KB, ProofGen~4sec Revoc_Reg_Size=10000, Tailsfile 2,6MB, ProofGen~5sec Revoc_Reg_Size=32768, Tailsfile 8,4MB, ProofGen~7sec Used: Lissi-Wallet on a iPhone 12Pro 32768 is the max-size-value set in the ACA-Py

zickau (Thu, 04 Nov 2021 14:43:16 GMT):
Is there a conceptual or technical reason for this particular max-size-value?

swcurran (Fri, 05 Nov 2021 14:59:18 GMT):
I think the size was thought to be the max that the tails file should be, but I'm not sure otherwise. "ProofGen" time -- that is the time it took the holder to produce the proof, including the proof of non-revocation, right?

swcurran (Fri, 05 Nov 2021 14:59:56 GMT):
I'm going to do a PR to add this information to the indy-tails-server docs at least (perhaps ACA-Py?). Unless you beat me to it :-)

deoalade (Sat, 06 Nov 2021 18:43:30 GMT):
Has joined the channel.

deoalade (Sat, 06 Nov 2021 19:09:09 GMT):
HI all, I’ve recently been working with Hyperledger Aries (versions 0.6.0 & 0.7.1) & have generally found it to be a really amazing framework. However I notice there seems to be some inconsistencies resulting in errors when executing some of the API calls for the Acapy agents. For instance I was able to successfully run a full sequence of schema/credential definition, credential request/issuance & credential verification on a new instance with my Issuer, holder & verifier nodes. However, when attempting to run the same sequence again for a brand new set of credentials I get the following error t the send presentation API call: `Error when constructing revocation state: Error: Invalid structure. Caused by: UrsaCryptoError: Invalid len of bytes representation for PoingG2. CommonInvalidStructure.` The API Request was constructed using the following details: Type: `POST` Endpoint: `http://{{Verifier_IP}}:{{AcaPy_Port}}/present-proof/send-request` Body: `{ "comment": "string", "connection_id": "{{Verifier_Holder_Conn}}", "proof_request": { "name": "Proof request", "non_revoked": { "to": 1636122004 }, "nonce": "1234567890", "requested_attributes": { "additionalProp1": { "name": "companyname" } }, "requested_predicates": { "additionalProp2": { "name": "grade", "p_type": ">=", "p_value": 10, "restrictions": [ {} ] } }, "version": "1.0" }, "trace": false }` Could you kindly advise on why this could be happening especially given that the same request has been successful on previous occasions. Thanks P.S. I am running this on the sovrin dev network without a Postgres database

Yunxi 3 (Mon, 08 Nov 2021 09:43:13 GMT):
@WadeBarnes, once accept the agreement, how can an ACA-Py agent determine if this agreement has been accepted before? Does this information stored in the ACA-Py agent's wallet?

Yunxi 3 (Mon, 08 Nov 2021 15:11:27 GMT):
Hello all, in order to enable my ACA-Py to connect to Sovrin's BuilderNet, what IP addresses and port numbers have to be opened in my ACA-Py's local environment? I've raised a question here: https://github.com/hyperledger/aries-cloudagent-python/issues/1458#issuecomment-963139368 for more details. Can anyone help here? Thanks

WadeBarnes (Mon, 08 Nov 2021 16:03:47 GMT):
https://github.com/hyperledger/aries-cloudagent-python/issues/1458#issuecomment-963303855

WadeBarnes (Mon, 08 Nov 2021 16:03:47 GMT):
Response: https://github.com/hyperledger/aries-cloudagent-python/issues/1458#issuecomment-963303855

swcurran (Mon, 08 Nov 2021 22:58:03 GMT):
I'm 99% sure, but I best defer to @ianco for that...

ianco (Tue, 09 Nov 2021 01:47:11 GMT):
I think this info probably *does* get stored in the wallet, but I don't know how you'd access it. I suspect the controller has to remember, and if you get an error writing to the ledger then that's a clue that you may need to accept the TAA

Yunxi 3 (Tue, 09 Nov 2021 16:41:55 GMT):
@ianco, after testing this without having a controller, I only need to accept the TAA in ACA-Py agent for only once, so guess it might be stored in the wallet. My initial worry was how this interactive mode would work if I dont have the interactive access to the container, but after testing, obviously, ACA-Py is intelligent enough to detect if the ACA-py container is running without an interactive mode supported, the TAA doesn't even pop up, which is good :-)

ianco (Tue, 09 Nov 2021 17:15:41 GMT):
:+1:

Yunxi 3 (Wed, 10 Nov 2021 13:25:25 GMT):
@WadeBarnes, my ACA-Py agents run in an AWS ECS containers, by default, when running the ACA-Py, it detects there's no interactive mode with this warning message: *Cannot accept TAA without interactive terminal* but it still runs. However, When I tried to create a definition schema, I've got below error: *400: Ledger rejected transaction request: client request invalid: InvalidClientTaaAcceptanceError('Txn Author Agreement acceptance is required for ledger with id 1',).*. This looks like ACA-Py must accept the TAA first. I see AWS ECS provisions an appraoch to allow us to exec into the container, but I'm not sure if this could resolve this issue. Have you ever met this issue before?

Yunxi 3 (Wed, 10 Nov 2021 13:25:25 GMT):
@WadeBarnes, my ACA-Py agents run in an AWS ECS containers, by default, when running the ACA-Py, it detects there's no interactive mode with this warning message: *Cannot accept TAA without interactive terminal* but it still runs. However, When I tried to create a definition schema, I've got below error: *400: Ledger rejected transaction request: client request invalid: InvalidClientTaaAcceptanceError('Txn Author Agreement acceptance is required for ledger with id 1',).*. This looks like ACA-Py must accept the TAA first. I see AWS ECS provisions an appraoch to allow us to exec into the container, but I'm not sure if this could resolve this issue. Have you ever met this issue before? @daidoji

Yunxi 3 (Wed, 10 Nov 2021 13:25:25 GMT):
@WadeBarnes, my ACA-Py agents run in an AWS ECS containers, by default, when running the ACA-Py, it detects there's no interactive mode with this warning message: *Cannot accept TAA without interactive terminal* but it still runs. However, When I tried to create a definition schema, I've got below error: *400: Ledger rejected transaction request: client request invalid: InvalidClientTaaAcceptanceError('Txn Author Agreement acceptance is required for ledger with id 1',).*. This looks like ACA-Py must accept the TAA first. I see AWS ECS provisions an appraoch to allow us to exec into the container, but I'm not sure if this could resolve this issue. Have you ever met this issue before? @daidoji, you mentioned you've deployed ACA-Py to ECS cluster, are your ACA-Py agents connecting to Sovrin's network and have similar issues?

WadeBarnes (Wed, 10 Nov 2021 13:44:31 GMT):
@Yunxi 3, You can accept the TAA through your agent's admin interface. Here is a reference script (I believe I've pointed out to you before). The script was designed for use in and OpenShift environment, but you could use it as a reference to create one that works for AWS. https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L55-L60 https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L272-L345 https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L563-L572

WadeBarnes (Wed, 10 Nov 2021 13:44:31 GMT):
@Yunxi 3 You can accept the TAA through your agent's admin interface. Here is a reference script (I believe I've pointed out to you before). The script was designed for use in and OpenShift environment, but you could use it as a reference to create one that works for AWS. https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L55-L60 https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L272-L345 https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L563-L572

WadeBarnes (Wed, 10 Nov 2021 13:44:31 GMT):
@'Yunxi 3' You can accept the TAA through your agent's admin interface. Here is a reference script (I believe I've pointed out to you before). The script was designed for use in and OpenShift environment, but you could use it as a reference to create one that works for AWS. https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L55-L60 https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L272-L345 https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L563-L572

WadeBarnes (Wed, 10 Nov 2021 13:44:31 GMT):
@Yunxi 3 You can accept the TAA through your agent's admin interface. Here is a reference script (I believe I've pointed out to you before). The script was designed for use in and OpenShift environment, but you could use it as a reference to create one that works for AWS. https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L55-L60 https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L272-L345 https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L563-L572

WadeBarnes (Wed, 10 Nov 2021 13:44:31 GMT):
@Yunxi 3 You can accept the TAA through your agent's admin interface. Here is a reference script (I believe I've pointed out to you before). The script was designed for use in an OpenShift environment, but you could use it as a reference to create one that works for AWS. https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L55-L60 https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L272-L345 https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L563-L572

WadeBarnes (Wed, 10 Nov 2021 13:50:08 GMT):
Alternatively you could use the agent's admin swagger interface and post the TAA acceptance payload using the `/ledger/taa/accept` endpoint.

WadeBarnes (Wed, 10 Nov 2021 13:50:11 GMT):

Clipboard - November 10, 2021 5:50 AM

Yunxi 3 (Wed, 10 Nov 2021 13:50:37 GMT):
Thanks @WadeBarnes , never used the Openshift before, so not sure how the script would works, but let me recheck these info and may come back to you; cool, will also check this api

Yunxi 3 (Wed, 10 Nov 2021 13:50:37 GMT):
Thanks @WadeBarnes , never used the Openshift before, so not sure how the script would work, but let me recheck these info and may come back to you; cool, will also check this api

WadeBarnes (Wed, 10 Nov 2021 13:51:54 GMT):
The swagger interface is available at /api/doc

WadeBarnes (Wed, 10 Nov 2021 13:52:15 GMT):
You need to click:

WadeBarnes (Wed, 10 Nov 2021 13:52:16 GMT):

Clipboard - November 10, 2021 5:52 AM

WadeBarnes (Wed, 10 Nov 2021 13:52:46 GMT):
and enter the API Key you've defined for your agent's admin interface:

WadeBarnes (Wed, 10 Nov 2021 13:52:47 GMT):

Clipboard - November 10, 2021 5:52 AM

Yunxi 3 (Wed, 10 Nov 2021 13:53:38 GMT):

Clipboard - November 10, 2021 1:53 PM

Yunxi 3 (Wed, 10 Nov 2021 13:53:40 GMT):
where is this "Authorize" button?

Yunxi 3 (Wed, 10 Nov 2021 13:54:44 GMT):
where can i find TAA payload?

Yunxi 3 (Wed, 10 Nov 2021 13:56:36 GMT):
ah i see a get api for the TAA

Yunxi 3 (Wed, 10 Nov 2021 13:57:21 GMT):
can use the payload response in the GET /ledger/taa and copy it to the payload for POST /ledger/taa/accept?

Yunxi 3 (Wed, 10 Nov 2021 13:57:21 GMT):
can I use the payload response in the GET /ledger/taa and copy it to the payload for POST /ledger/taa/accept?

WadeBarnes (Wed, 10 Nov 2021 13:58:27 GMT):
The Authorize button is near the top right corner of the page

Yunxi 3 (Wed, 10 Nov 2021 13:59:25 GMT):

Clipboard - November 10, 2021 1:59 PM

Yunxi 3 (Wed, 10 Nov 2021 13:59:34 GMT):
you mean the swagger page? i'm using 0.6

Yunxi 3 (Wed, 10 Nov 2021 14:00:20 GMT):
is this "authorize" button available in 0.7 only?

WadeBarnes (Wed, 10 Nov 2021 14:01:07 GMT):
I'd recommend looking at the reference script I provided. It will show you how to construct the TAA acceptance payload; https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L327

WadeBarnes (Wed, 10 Nov 2021 14:01:50 GMT):
[ ](https://chat.hyperledger.org/channel/indy-node?msg=MhoSANm73nvzHg2GX) No, it should be there in 0.6.0 as well.

WadeBarnes (Wed, 10 Nov 2021 14:02:13 GMT):
Did you set an API Key for your agent's admin interface?

WadeBarnes (Wed, 10 Nov 2021 14:02:31 GMT):
If not it will be wide open and insecure.

Yunxi 3 (Wed, 10 Nov 2021 14:02:38 GMT):
no, i'm using admin-insecure-mode for testing purpose

WadeBarnes (Wed, 10 Nov 2021 14:03:00 GMT):
That could be why the authorize button is not there.

Yunxi 3 (Wed, 10 Nov 2021 14:03:58 GMT):
ah fair, so without an authorize button, what i need to do is to find out the TAA payload used for Sovrin and call the POST api to accept it, right?

WadeBarnes (Wed, 10 Nov 2021 14:05:06 GMT):
Correct

Yunxi 3 (Wed, 10 Nov 2021 14:06:44 GMT):

Clipboard - November 10, 2021 2:06 PM

Yunxi 3 (Wed, 10 Nov 2021 14:06:51 GMT):
is this the url:https://agent-admin-url-dev.apps.silver.devops.gov.bc.ca that gives the TAA?

WadeBarnes (Wed, 10 Nov 2021 14:08:33 GMT):
That URL is an example URL. It is the URL for one of our OpenShift environments.

Yunxi 3 (Wed, 10 Nov 2021 14:09:27 GMT):
where can I find the url for getting the right TAA for Sovrin?

Yunxi 3 (Wed, 10 Nov 2021 14:09:27 GMT):
where can I find the url for getting the right TAA for Sovrin's BuilderNet?

WadeBarnes (Wed, 10 Nov 2021 14:09:41 GMT):
It is the base URL for the agent's admin interface. You will want to use the URL for your agent's admin interface.

WadeBarnes (Wed, 10 Nov 2021 14:10:31 GMT):
You could alternately use:

WadeBarnes (Wed, 10 Nov 2021 14:10:32 GMT):

Clipboard - November 10, 2021 6:10 AM

Yunxi 3 (Wed, 10 Nov 2021 14:11:18 GMT):

Clipboard - November 10, 2021 2:11 PM

Yunxi 3 (Wed, 10 Nov 2021 14:11:21 GMT):
i've done the GET api and see teh response, just can't tell if this is the right payload, lol

WadeBarnes (Wed, 10 Nov 2021 14:11:39 GMT):
BTW the portion of the example script that is specific to OpenShift is this section; https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L283-L287

Yunxi 3 (Wed, 10 Nov 2021 14:12:06 GMT):

Clipboard - November 10, 2021 2:11 PM

WadeBarnes (Wed, 10 Nov 2021 14:13:31 GMT):
You need to form the payload, for example; https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L327

WadeBarnes (Wed, 10 Nov 2021 14:14:08 GMT):
The TAA from `/ledger/taa` only forms part of that payload.

Yunxi 3 (Wed, 10 Nov 2021 14:14:57 GMT):
how/where can I find out the values for the attributes: mechanism, test and version for Sovrin's builderNet?

WadeBarnes (Wed, 10 Nov 2021 14:15:00 GMT):
The acceptance payload needs to define which option, acceptance `mechanism`, you've selected.

Yunxi 3 (Wed, 10 Nov 2021 14:17:50 GMT):

Clipboard - November 10, 2021 2:17 PM

WadeBarnes (Wed, 10 Nov 2021 14:25:02 GMT):

taa_payload.txt

WadeBarnes (Wed, 10 Nov 2021 14:25:17 GMT):
Here is an example TAA acceptance payload.

WadeBarnes (Wed, 10 Nov 2021 14:25:17 GMT):
Here is an example TAA acceptance payload ^.

WadeBarnes (Wed, 10 Nov 2021 14:26:04 GMT):
With that you should be able to figure out how to construct you're own TAA acceptance payload.

Yunxi 3 (Wed, 10 Nov 2021 14:26:54 GMT):
thanks a lot, does this "on_file" map to option 2?

Yunxi 3 (Wed, 10 Nov 2021 14:27:21 GMT):
do you know the other values for *mechanism* and *version* attributes?

Yunxi 3 (Wed, 10 Nov 2021 14:27:21 GMT):
do you know the other optional values for *mechanism*, *text* and *version* attributes?

WadeBarnes (Wed, 10 Nov 2021 14:29:35 GMT):
In my case `on_file` was option 5.

WadeBarnes (Wed, 10 Nov 2021 14:30:53 GMT):
All of the options and version information are contained in the TAA when you `get` it.

WadeBarnes (Wed, 10 Nov 2021 14:33:40 GMT):
Example:

WadeBarnes (Wed, 10 Nov 2021 14:33:42 GMT):

Clipboard - November 10, 2021 6:33 AM

WadeBarnes (Wed, 10 Nov 2021 14:34:04 GMT):

Clipboard - November 10, 2021 6:34 AM

Yunxi 3 (Wed, 10 Nov 2021 14:34:08 GMT):
ah, i see, they in the "aml" block. I see there are 7 options after calling the GET api, but in the interactive mode, why there are only 4 options?

WadeBarnes (Wed, 10 Nov 2021 14:35:57 GMT):
Likely because they are the only options that make sense for the interactive session.

Yunxi 3 (Wed, 10 Nov 2021 14:36:50 GMT):
ah intelligent.

Yunxi 3 (Wed, 10 Nov 2021 14:37:06 GMT):

Clipboard - November 10, 2021 2:37 PM

Yunxi 3 (Wed, 10 Nov 2021 14:37:25 GMT):

Clipboard - November 10, 2021 2:37 PM

Yunxi 3 (Wed, 10 Nov 2021 14:37:34 GMT):
i also see two versions

Yunxi 3 (Wed, 10 Nov 2021 14:37:47 GMT):
think should use the one in the "taa_record"?

WadeBarnes (Wed, 10 Nov 2021 14:38:06 GMT):
It's the `taa_record.version` you want to use.

WadeBarnes (Wed, 10 Nov 2021 14:38:33 GMT):
As in the example code; v

WadeBarnes (Wed, 10 Nov 2021 14:38:33 GMT):
As in the example code; https://github.com/bcgov/a2a-trust-over-ip-configurations/blob/master/openshift/manage#L297

Yunxi 3 (Wed, 10 Nov 2021 14:40:35 GMT):
thanks for your huge help @WadeBarnes , really appreciate it :grinning:

Yunxi 3 (Wed, 10 Nov 2021 14:42:09 GMT):
another question, what does "on file with the user’s organization" mean?

Yunxi 3 (Wed, 10 Nov 2021 14:43:00 GMT):
any docs explain the difference of these options?

Yunxi 3 (Wed, 10 Nov 2021 14:43:00 GMT):
any docs explain the difference of these options (e.g. what does "on file with the user’s organization" mean?)?

WadeBarnes (Wed, 10 Nov 2021 14:43:35 GMT):
It means there has been paper/electronic agreement signed and it is on file with the user's organization.

Yunxi 3 (Wed, 10 Nov 2021 14:45:09 GMT):
Is the difference amongst these options is more on the legal side but not on the technical side (e.g. ACA-Py's behaviour might be different when using different options)?

swcurran (Wed, 10 Nov 2021 14:46:50 GMT):
ACA-Py's behaviour will remain the same. The list of options might change, but the need to select one and say "That's how we accepted the TAA" will be the same.

Yunxi 3 (Wed, 10 Nov 2021 14:49:56 GMT):
thanks for the answer @swcurran , looks like these options are related to the legal aspect then.

WadeBarnes (Wed, 10 Nov 2021 14:50:30 GMT):
Correct.

zickau (Thu, 11 Nov 2021 16:19:20 GMT):
Sorry for my late reply, yes it included the proof-of-non-revoc (but only counted) As far as I understand, the time might be prolonged if you have a very active accumulator were you have a lot of revocations, so the Holder must get a lot of acc information from the ledger.

zickau (Thu, 11 Nov 2021 16:19:53 GMT):
What exactly do you wanna add as PR?

swcurran (Thu, 11 Nov 2021 21:16:46 GMT):
I agree on the problem with getting the acc information from the ledger -- having deltas is a challenge. No worries about the PR -- I can just add in the info to the tails server readme, so it's preserved somewhere. :-)

shimizut (Thu, 18 Nov 2021 05:03:25 GMT):
Has joined the channel.

shimizut (Thu, 18 Nov 2021 05:03:30 GMT):
Hello, I am setting up an environment for developing indy-node and meeting some problems: `pytest .` outputs errors. When testing indy-plenum, I got the following output. ``` = 7 failed, 11453 passed, 307 skipped, 71 warnings, 1089 error in 2380.80 seconds = ``` indy-node's test showed a similar result, which included fails and errors. I am using master branch in indy-node and indy-plenum. I executed commands according to https://github.com/hyperledger/indy-node/blob/master/docs/source/setup-dev.md on ubuntu 16 https://releases.ubuntu.com/16.04/ , but the test `pytest . ` did not run. According to error messages, I additionally executed `pip install --upgrade 'setuptools<45.0.0`, `pip install pip==9.0.3` and so on. Then, `pytest .` ran but showed errors. For example I got the following. Actually, plenum/config.py does not include `GENESIS_DIR` ``` E AttributeError: module 'plenum.config' has no attribute 'GENESIS_DIR' ``` Does this output show an installation problem? If this question is not suitable here, I would appreciate it if you could tell me where I should write. Thanks in adnvace.

shimizut (Thu, 18 Nov 2021 05:03:30 GMT):
Hello, I am setting up an environment for developing indy-node and meeting some problems: `pytest .` outputs errors. When testing indy-plenum, I got the following output. ``` = 7 failed, 11453 passed, 307 skipped, 71 warnings, 1089 error in 2380.80 seconds = ``` indy-node's test showed a similar result, which included fails and errors. I am using master branch in indy-node and indy-plenum. I executed commands according to https://github.com/hyperledger/indy-node/blob/master/docs/source/setup-dev.md on ubuntu 16 https://releases.ubuntu.com/16.04/ , but the test `pytest . ` did not run. According to error messages, I additionally executed `pip install --upgrade 'setuptools<45.0.0'`, `pip install pip==9.0.3` and so on. Then, `pytest .` ran but showed errors. For example I got the following. Actually, plenum/config.py does not include `GENESIS_DIR` ``` E AttributeError: module 'plenum.config' has no attribute 'GENESIS_DIR' ``` Does this output show an installation problem? If this question is not suitable here, I would appreciate it if you could tell me where I should write. Thanks in adnvace.

shimizut (Thu, 18 Nov 2021 05:03:30 GMT):
Hello, I am setting up an environment for developing indy-node and meeting some problems: `pytest .` outputs errors. When testing indy-plenum, I got the following output. ``` = 7 failed, 11453 passed, 307 skipped, 71 warnings, 1089 error in 2380.80 seconds = ``` indy-node's test showed a similar result, which included fails and errors. I am using master branch in indy-node and indy-plenum. I executed commands according to https://github.com/hyperledger/indy-node/blob/master/docs/source/setup-dev.md on ubuntu 16 https://releases.ubuntu.com/16.04/ , but the test `pytest . ` did not run. According to error messages, I additionally executed `pip install --upgrade 'setuptools<45.0.0'`, `pip install pip==9.0.3` and so on. Then, `pytest .` ran but showed errors. For example I got the following. Actually, plenum/config.py does not include `GENESIS_DIR` ``` E AttributeError: module 'plenum.config' has no attribute 'GENESIS_DIR' ``` Does this output show an installation problem? If this question is not suitable here, I would appreciate it if you could tell me where I should write. Thanks in advance.

WadeBarnes (Thu, 18 Nov 2021 13:09:29 GMT):
I'd recommend having a closer look at the way the tests are setup and executed in the GitHub Actions workflows. You'll notice they are broken down into groups more. The tests don't always succeed when run all at once.

WadeBarnes (Thu, 18 Nov 2021 13:12:51 GMT):
@pSchlarb, Would you be able to share your recent experiences. @RobinKlemens, Any other advice for working locally?

shimizut (Fri, 19 Nov 2021 00:31:18 GMT):
@WadeBarnes Thank you for your quick response. I am sorry that I do no know what 'the GitHub Actions workflows' means. Is that https://github.com/hyperledger/indy-node/actions ? Since I have not seen that page and have not used, I will study.

shimizut (Fri, 19 Nov 2021 00:31:18 GMT):
@WadeBarnes Thank you for your quick response. I am sorry that I do no know what 'the GitHub Actions workflows' means. Is that https://github.com/hyperledger/indy-node/actions ? Since I have not seen that page and have not use actions on github, I will study.

shimizut (Fri, 19 Nov 2021 00:31:18 GMT):
@WadeBarnes Thank you for your quick response. I am sorry that I do no know what 'the GitHub Actions workflows' means. Is that https://github.com/hyperledger/indy-node/actions ? If so, since I have not seen that page and have not used actions in any project, I will study.

shimizut (Fri, 19 Nov 2021 00:31:18 GMT):
@WadeBarnes Thank you for your quick response. I am sorry that I do no know what 'the GitHub Actions workflows' means. Is that https://github.com/hyperledger/indy-node/actions ? If so, since I have not seen that page and have not used actions in any github repository, I will study.

WadeBarnes (Fri, 19 Nov 2021 17:28:38 GMT):
This build script; https://github.com/hyperledger/indy-node/blob/master/.github/workflows/build.yaml

WadeBarnes (Fri, 19 Nov 2021 17:28:38 GMT):
This build script is what drives those results; https://github.com/hyperledger/indy-node/blob/master/.github/workflows/build.yaml

RobinKlemens (Mon, 22 Nov 2021 13:58:43 GMT):
And this is the Dockerfile we use to run the tests: https://github.com/hyperledger/indy-node/blob/master/.github/workflows/build/Dockerfile

shimizut (Tue, 23 Nov 2021 23:50:51 GMT):
@WadeBarnes @RobinKlemens Thank you very much.

shimizut (Thu, 25 Nov 2021 05:25:00 GMT):
According to your advices, I have succeeded to do tests. Thank you again. By the way, it seems that indy-node's github actions workflow does not do all tests. For example, in https://github.com/hyperledger/indy-node/runs/4313751072?check_suite_focus=true , in Sliced Moudule Tests, Only "1/22", "2/22", ..., and "11/22" are passed to `--test-only-slice` when executing `runner.py`. Then, some test modules such as 'indy_node/test/nym_txn', 'indy_node/test/package', did not appear in any slices. Am I misunderstanding?

shimizut (Thu, 25 Nov 2021 05:25:00 GMT):
According to your advices, I have succeeded to run tests. Thank you again. By the way, it seems that indy-node's github actions workflow does not do all tests. For example, in https://github.com/hyperledger/indy-node/runs/4313751072?check_suite_focus=true , in Sliced Moudule Tests, Only "1/22", "2/22", ..., and "11/22" are passed to `--test-only-slice` when executing `runner.py`. Then, some test modules such as 'indy_node/test/nym_txn', 'indy_node/test/package', did not appear in any slices. Am I misunderstanding?

shimizut (Thu, 25 Nov 2021 05:25:00 GMT):
According to your advices, I have succeeded to run tests. Thank you again. By the way, it seems that indy-node's github actions workflow does not do all tests. For example, in https://github.com/hyperledger/indy-node/runs/4313751072?check_suite_focus=true , in Sliced Moudule Tests, Only "1/22", "2/22", ..., and "11/22" are passed to `--test-only-slice` when executing `runner.py` for testing indy-node. Then, some test modules such as 'indy_node/test/nym_txn', 'indy_node/test/package', did not appear in any slices. Am I misunderstanding?

shimizut (Thu, 25 Nov 2021 05:35:58 GMT):
In `runner.py`, the two numbers passed by `--test-only-slice` are used for selecting test modules: the start and the step to extract modules from the test module list.

shimizut (Thu, 25 Nov 2021 05:35:58 GMT):
In `runner.py`, the two numbers passed by `--test-only-slice` are used for selecting test modules: the start and the step to extract modules from the test module list. Then, 13th, 14th, ..., and 21th test modules are not executed.

shimizut (Thu, 25 Nov 2021 05:35:58 GMT):
In `runner.py`, the two numbers passed by `--test-only-slice` are used for selecting test modules: the start and the step to extract modules from the test module list. Then, 12th, 13th, ..., and 22th test modules are not executed.

pSchlarb (Thu, 25 Nov 2021 10:42:54 GMT):
I also get errors and missing dependencies, when i ran pytest in the root directory. Not quite sure if that is intended or not. But i remember that the DevSetup mentions to test the subfolers(indy_common/indy_node). If not run in the root directory the test should be executed.

pSchlarb (Thu, 25 Nov 2021 10:57:23 GMT):
``

pSchlarb (Thu, 25 Nov 2021 10:57:23 GMT):
It seems strange with the test in the actions. But if i run them locally it seems ok for indy_common. ``` root@f7c66d5767a8:/indy-node# RUSTPYTHONASYNCIODEBUG=0 python3 runner.py --pytest "python3 -m pytest -l -vv" --dir "indy_common" --output "test-result-node-1.txt" --test-only-slice "13/22" Preparing test suite with python3 -m pytest -l -vv Reading collected modules file Collecting modules Found 60 tests in 11 modules, sliced 0 test modules Total 1 runs 0 passed, 0 failed, 0 errors, 0 skipped Tests run. Returning 0 root@f7c66d5767a8:/indy-node# RUSTPYTHONASYNCIODEBUG=0 python3 runner.py --pytest "python3 -m pytest -l -vv" --dir "indy_common" --output "test-result-node-1.txt" --test-only-slice "14/22" Preparing test suite with python3 -m pytest -l -vv Reading collected modules file Collecting modules Found 60 tests in 11 modules, sliced 0 test modules Total 1 runs 0 passed, 0 failed, 0 errors, 0 skipped Tests run. Returning 0 ``` But for indy_node @shimizut seems right that some tests aren't run ``` root@f7c66d5767a8:/indy-node# RUSTPYTHONASYNCIODEBUG=0 python3 runner.py --pytest "python3 -m pytest -l -vv" --dir "indy_node" --output "test-result-node-1.txt" --test-only-slice "12/22" Preparing test suite with python3 -m pytest -l -vv Reading collected modules file Collecting modules Found 188 tests in 31 modules, sliced 1 test modules python3 -m pytest -l -vv --junitxml=node_txn-test-results.xml indy_node/test/node_txn > currentTestReport-indy_node-test-result-node-1.txt-1637837846.4724529.txt In indy_node/test/node_txn, 43 passed, 0 failed, 0 errors, 1 skipped, 36.9s time (1/1 progress) Total 1 runs 43 passed, 0 failed, 0 errors, 1 skipped Tests run. Returning 0 ``` @WadeBarnes or @RobinKlemens any ideas?

pSchlarb (Thu, 25 Nov 2021 10:57:23 GMT):
It seems strange with the test in the actions. But if i run them locally it seems ok for indy_common. ``` root@f7c66d5767a8:/indy-node# RUSTPYTHONASYNCIODEBUG=0 python3 runner.py --pytest "python3 -m pytest -l -vv" --dir "indy_common" --output "test-result-node-1.txt" --test-only-slice "13/22" Preparing test suite with python3 -m pytest -l -vv Reading collected modules file Collecting modules Found 60 tests in 11 modules, sliced 0 test modules Total 1 runs 0 passed, 0 failed, 0 errors, 0 skipped Tests run. Returning 0 root@f7c66d5767a8:/indy-node# RUSTPYTHONASYNCIODEBUG=0 python3 runner.py --pytest "python3 -m pytest -l -vv" --dir "indy_common" --output "test-result-node-1.txt" --test-only-slice "14/22" Preparing test suite with python3 -m pytest -l -vv Reading collected modules file Collecting modules Found 60 tests in 11 modules, sliced 0 test modules Total 1 runs 0 passed, 0 failed, 0 errors, 0 skipped Tests run. Returning 0 ``` But for indy_node @shimizut seems right that some tests aren't run ``` root@f7c66d5767a8:/indy-node# RUSTPYTHONASYNCIODEBUG=0 python3 runner.py --pytest "python3 -m pytest -l -vv" --dir "indy_node" --output "test-result-node-1.txt" --test-only-slice "12/22" Preparing test suite with python3 -m pytest -l -vv Reading collected modules file Collecting modules Found 188 tests in 31 modules, sliced 1 test modules python3 -m pytest -l -vv --junitxml=node_txn-test-results.xml indy_node/test/node_txn > currentTestReport-indy_node-test-result-node-1.txt-1637837846.4724529.txt In indy_node/test/node_txn, 43 passed, 0 failed, 0 errors, 1 skipped, 36.9s time (1/1 progress) Total 1 runs 43 passed, 0 failed, 0 errors, 1 skipped Tests run. Returning 0 ``` @WadeBarnes or @RobinKlemens any ideas? Or am i missing something?

WadeBarnes (Thu, 25 Nov 2021 14:02:49 GMT):
We'll have to take a closer look. I recall @devinleighsmith ran into a similar issue and had to update the test runner code.

shimizut (Fri, 26 Nov 2021 05:16:20 GMT):
@pSchlarb Thank you for checking. I think `indy_common` is ok because there are 11 modules, which is less than step 22.

shimizut (Fri, 26 Nov 2021 05:16:20 GMT):
@pSchlarb Thank you for checking. I think `indy_common` is ok because there are 11 modules, which is less than the number of steps: 22.

shimizut (Fri, 26 Nov 2021 05:16:20 GMT):
@pSchlarb Thank you for checking. I think `indy_common` is ok because is has only 11 test modules, which is less than the number of steps: 22.

shimizut (Fri, 26 Nov 2021 05:16:20 GMT):
@pSchlarb Thank you for checking. I think `indy_common` is ok because is has only 11 test modules, which is equal to the number of slices.

shimizut (Fri, 26 Nov 2021 05:16:20 GMT):
@pSchlarb Thank you for checking. I think `indy_common` is ok because is has only 11 test modules, which is equal to the number of slices in `build.yaml`: `indy_node_tests.strategy.slices`.

shimizut (Fri, 26 Nov 2021 05:16:20 GMT):
@pSchlarb Thank you for checking. I think `indy_common` is ok because it has only 11 test modules, which is equal to the number of slices in `build.yaml`: `indy_node_tests.strategy.slices`.

shimizut (Fri, 26 Nov 2021 05:16:20 GMT):
@pSchlarb Thank you for checking. I think `indy_common` is ok because it has only 11 test modules; the number is equal to the number of slices in `build.yaml`: `indy_node_tests.strategy.slices`.

shimizut (Fri, 26 Nov 2021 05:21:15 GMT):
I miss I do not know well github actions and do now know how to rewrite `--test-only-slice "${{ matrix.slice }}/${{ strategy.job-total }}"` in `build.yaml`.

shimizut (Fri, 26 Nov 2021 05:21:15 GMT):
I miss I do not know well github actions and do not know how to rewrite `--test-only-slice "${{ matrix.slice }}/${{ strategy.job-total }}"` in `build.yaml`.

pSchlarb (Fri, 26 Nov 2021 10:26:38 GMT):
These variables are basically the variables comming from the GithubActions(GHA) Slice Strategy for jobs. (further reading on that here: https://docs.github.com/en/actions/learn-github-actions/managing-complex-workflows#using-a-build-matrix) I couldn't really find any documentation on the fly on the `strategy.job-total` context variable. But it seems to me that it is the total sum of slices and therefore wrong in our case. (2*11 since 2 modules with 11slices) Will open a PR for that fix.

mateokurti (Wed, 22 Dec 2021 14:54:59 GMT):
Has joined the channel.

mateokurti (Wed, 22 Dec 2021 14:55:00 GMT):
Hi everyone! I am trying on deploying an instance of Indy Node on my Kubernetes Cluster. I had a look on VON Network at first, but it's almost impossible to make a valid deployment of it to use in production. I'm looking on ways to directly deploy Indy Node, but there is not enough information. I was wondering if someone here has some idea regarding this.

WadeBarnes (Wed, 22 Dec 2021 14:57:16 GMT):
Did you check out all of the links I provided here? https://github.com/bcgov/von-network/issues/190#issuecomment-995918202

WadeBarnes (Wed, 22 Dec 2021 14:58:38 GMT):
The https://github.com/IDunion/indy-node-container repo would be the place to start if your looking to containerize the nodes.

mateokurti (Wed, 22 Dec 2021 14:58:57 GMT):
Yes, I am looking on those resources. Found them helpful actually.

mateokurti (Wed, 22 Dec 2021 14:59:22 GMT):
I also found out about Hyperledger Bevel

mateokurti (Wed, 22 Dec 2021 15:00:00 GMT):
https://hyperledger-bevel.readthedocs.io/en/latest/architectureref/hyperledger-indy.html?highlight=kubernetes#components

WadeBarnes (Wed, 22 Dec 2021 15:00:21 GMT):
The `Create New Indy Network` link in the `Add a detailed tutorial on how to create a New Indy Network` link is another good resource.

WadeBarnes (Wed, 22 Dec 2021 15:00:42 GMT):
Yes Bevel would be something to look into for sure.

WadeBarnes (Wed, 22 Dec 2021 15:03:06 GMT):
I'd be interested in your experiences with Bevel and would be willing to provide what indy-node support I can during your investigation.

mateokurti (Wed, 22 Dec 2021 15:06:05 GMT):
Okay, I'll have a look. I'm still continuing to try and explore. Thanks for the help, resources and suggestions

jcourt (Wed, 22 Dec 2021 20:36:48 GMT):
Has joined the channel.

sairanjit (Thu, 23 Dec 2021 13:18:24 GMT):
Has joined the channel.

fethbita (Wed, 29 Dec 2021 08:46:38 GMT):
Has joined the channel.

c2bo (Mon, 03 Jan 2022 09:56:00 GMT):
Has joined the channel.

tkuhrt (Mon, 03 Jan 2022 17:50:59 GMT):
@mateokurti : Also feel free to ask questions in the #bevel channel

regiseloi (Tue, 11 Jan 2022 20:23:36 GMT):
Has joined the channel.

WadeBarnes (Thu, 13 Jan 2022 14:15:53 GMT):
Documentation for setting up a new `indy-node` network can now be found here; https://github.com/hyperledger/indy-node/blob/master/docs/source/NewNetwork/NewNetwork.md

WadeBarnes (Thu, 13 Jan 2022 14:15:53 GMT):
Documentation for setting up a new `indy-node` network can now be found here; https://github.com/hyperledger/indy-node/blob/master/docs/source/NewNetwork/NewNetwork.md Contributions welcome.

etschelp (Thu, 20 Jan 2022 09:14:28 GMT):
Has joined the channel.

mateokurti (Mon, 24 Jan 2022 13:12:47 GMT):
Great job, thanks a lot. I have a question. Can all the nodes be run by the same organization (steward) for test purposes? So not having 4 different organizations running the 4 nodes?

WadeBarnes (Mon, 24 Jan 2022 17:55:43 GMT):
Virtual development environments have been integrated into the `ubuntu-20.04-upgrade` branches of [hyperledger/indy-node](https://github.com/hyperledger/indy-node/tree/ubuntu-20.04-upgrade) and [hyperledger/indy-plenum](https://github.com/hyperledger/indy-plenum/tree/ubuntu-20.04-upgrade). You can now spin up a fully functional development environment in your choice of a Visual Studio Code Devcontainer or a Gitpod. Thanks to @pSchlarb for his work on getting this done. Happy Coding!

sbohanlf (Tue, 25 Jan 2022 15:22:52 GMT):
Has joined the channel.

JamesSchulte (Tue, 25 Jan 2022 17:14:48 GMT):
Has joined the channel.

mateokurti (Tue, 25 Jan 2022 17:58:11 GMT):
What are the suggested hardware requirements for the machine which will run one Node?

mateokurti (Tue, 25 Jan 2022 17:58:22 GMT):
Hi! What are the suggested hardware requirements for the machine which will run one Node?

WadeBarnes (Tue, 25 Jan 2022 19:16:45 GMT):
That depends on the use case. Sovrin recommendations for a production Node: ``` 32 G RAM 8 CPU cores 1T RAIDed disk space 2 NICs with 2 Public IP addresses (1 per NIC) ```

WadeBarnes (Tue, 25 Jan 2022 19:16:45 GMT):
That depends on the use case. Sovrin recommendations for a production Node: ``` 32 G RAM 8 CPU cores 1T disk space 2 NICs with 2 Public IP addresses (1 per NIC) ```

WadeBarnes (Tue, 25 Jan 2022 19:17:39 GMT):
For a `dev` environment you can get away with less: ``` 8 G RAM 2 CPU cores 20G disk space 2 NICs with 2 Public IP addresses (1 per NIC) ```

WadeBarnes (Tue, 25 Jan 2022 19:17:39 GMT):
For a `dev` environment you can get away with less: ``` 8 G RAM 2 CPU cores 20G disk space 2 NICs with 2 Public IP addresses (1 per NIC) ``` This is an EC2 `t3.large` in AWS terms.

mateokurti (Tue, 25 Jan 2022 22:13:18 GMT):
Thank you :partying_face: That helped a lot

mateokurti (Tue, 25 Jan 2022 22:14:50 GMT):
Is this information at any part of documentation. I wasn't able to find those, except for the two NICs

WadeBarnes (Tue, 25 Jan 2022 22:16:32 GMT):
Sovrin recommendations are from here; https://docs.google.com/document/d/1UfjHdHdpF6lNU2tPXuit0xEgYaFMMyD67fPfOvoL7_A/edit?usp=drive_web&ouid=112451385645753586786

WadeBarnes (Tue, 25 Jan 2022 22:17:19 GMT):
`dev` resource levels are based on experience operating networks.

lynn.bendixsen (Tue, 25 Jan 2022 23:20:25 GMT):
required resource levels are mentioned in the technical portion of a Networks Governance documents. Testing was done a while back to determine what the levels should be for Sovrin as depicted here: https://sovrin.org/wp-content/uploads/Steward-Technical-and-Organizational-Policies-V2.pdf

mateokurti (Fri, 28 Jan 2022 12:40:13 GMT):
So, does it mean that the Validator can now run on Ubuntu 20.04? When will that be merged into master?

mateokurti (Mon, 31 Jan 2022 20:01:32 GMT):
Any update on this? :slight_smile:

WadeBarnes (Mon, 31 Jan 2022 22:37:49 GMT):
Yes, it means a Validator can run on Ubuntu 20.04. We've still got some work to do and testing is still being done. It's a very small group working on this, so it's a little difficult to provide and ETA.

mateokurti (Tue, 01 Feb 2022 16:36:58 GMT):
Okay, thank you for the clarification. I wish I could help :unamused:

mateokurti (Fri, 04 Feb 2022 08:18:15 GMT):
>In the /etc/indy/indy_config.py file, change the Network Name from “sandbox” (Sovrin StagingNet) to “net3” (Sovrin BuilderNet) using one of the following commands: Hi @WadeBarnes , I have a question. Why is it specified `net3`? Should I use the same name even when configuring a new network?

WadeBarnes (Fri, 04 Feb 2022 12:36:21 GMT):
`net3` happens to be the network name decided on for the configuration of nodes connecting to Sovrin BuilderNet. You can use a name that is appropriate for the network you are configuring and you should keep that name consistent across all nodes connected to that network. You want to use unique names for the networks. The name corresponds to the name of the directory that will contain all of the private keys and ledger data associated with the network. That way if your node ever moves to a different network the data for each network is segregated.

mateokurti (Fri, 04 Feb 2022 14:10:27 GMT):
By consistent you mean identical? So for all nodes connected to the Sovrin BuilderNet it should be `net3`? And in my case, we should specify something unique for the network, and configure that name in the same way to each node? Have I understood it correct?

WadeBarnes (Fri, 04 Feb 2022 14:22:03 GMT):
Correct

Rizary (Sat, 05 Feb 2022 03:28:17 GMT):
Has joined the channel.

mateokurti (Sun, 06 Feb 2022 20:11:58 GMT):
Hi again! I'm sorry for the multiple questions I'm having. I'm finding something confusing in the documentation. ``` The Stewards will also need to download the genesis files onto their nodes while completing the setup. All of the following steps are to be completed on the node. ``` and then the genesis files are added to `/var/lib/indy/` However, in order to create those genesis files, on `Installation and configuration of Indy-Node` documentation, it is needed to already have those files in that directory. By that tutorial, it instructs to download the genesis files of Sovrin. So, my question is, how can I generate Verification Key and BLS, which I need for the genesis file, without having a genesis file to begin with? Not sure if I'm being clear.

mateokurti (Sun, 06 Feb 2022 20:13:21 GMT):
The only way that it can happen, is if the `genesis files` are not needed at the beginning, when the Key for the Validator Node is created.

mateokurti (Sun, 06 Feb 2022 20:14:37 GMT):
But this has contradictions with the statement: ``` Please run the following on the Validator before running init_indy_node. ``` Reference: https://github.com/hyperledger/indy-node/blob/master/docs/source/installation-and-configuration.md#323-create-the-key-for-the-validator-node

mateokurti (Sun, 06 Feb 2022 20:17:42 GMT):
So, to sum up. Sorry for the long long question. In the `Installation and configuration of Indy-Node` documentation is says that before running `init_indy_node`, you should have the genesis files in the specified directory. In the other hand, on `NewNetwork` documentation, it says that you should add the genesis files on that directory, while in order to create those genesis files, the keys from `init_indy_node` are needed.

mateokurti (Sun, 06 Feb 2022 20:38:10 GMT):
_In relation to the previous question_ >NOTE: There are a few steps in the guide that they will not be able to complete because the network has not yet been created, and the guide assumes that you are adding a node to an existing network. I guess that this is referring to the part, where the genesis files are added to that directory? So, in the scenario when creating a New Network and when we don't have genesis files to begin with, we should run the `init_indy_node` without having the genesis files added to `/var/lib/indy/{network_name}`? Is this correct @WadeBarnes ?

mateokurti (Sun, 06 Feb 2022 23:27:35 GMT):
``` Uptime: 8 minutes, 0 seconds Total audit Transactions: 0 Total config Transactions: 0 Total ledger Transactions: 8 Total 1001 Transactions: 0 Total pool Transactions: 4 Read Transactions/Seconds: 0.00 Write Transactions/Seconds: 0.00 Reachable Hosts: 1/4 myNode-4 Unreachable Hosts: 3/4 myNode-2 (1) myNode-1 (0) myNode-3 Software Versions: indy-node: 1.12.4 sovrin: 1.1.89 ```

mateokurti (Mon, 07 Feb 2022 10:31:32 GMT):
Solved it. There is a confusion in the documentation. So, the right steps would be: Before `Creating Validator Node keys`, you should `Edit /etc/indy/indy_config.py and change the network name. NETWORK_NAME = "newNetwork"` (if we refer to this quick walkthrough https://github.com/hyperledger/indy-node/blob/master/sample/Network/README.md), not the other way around

WadeBarnes (Mon, 07 Feb 2022 12:52:48 GMT):
@mateokurti, Can you confirm whether you've resolved the issues you were having? I looks like you have. Also can you point out specifically where the confusion is in the documentation so that can be resolved?

mateokurti (Mon, 07 Feb 2022 13:24:02 GMT):
Yes, I did resolve it. I'll write some points in a bit, which I think can be improved

WadeBarnes (Mon, 07 Feb 2022 13:29:10 GMT):
Feel free to submit a PR.

lynn.bendixsen (Mon, 07 Feb 2022 16:30:02 GMT):
To this question: "how can I generate Verification Key and BLS, which I need for the genesis file, without having a genesis file to begin with?" A genesis file is not required to be able to generate Verkey and BLS for a node. When creating a new network, skip all of the steps in the validator prep guide that say anything about the genesis files, as they do not (and cannot) exist for the new network. The geneesis files will be created during a later step in the new network guide after all nodes have submitted their info to the spreadsheet (i.e.the results of running init_indy_node on each genesis node)

mateokurti (Mon, 07 Feb 2022 19:27:00 GMT):
Yes, I realized that, thank you. However, the step where the Network Name was specified in the node, should not be skipped. If the network name is changed after the verkey and BLS is created, the nodes will be unable to reach each others. This is the part which I mostly found confusing in the docs. I think that it is worth mentioning.

lynn.bendixsen (Mon, 07 Feb 2022 19:32:26 GMT):
Yes, that is a good point and should be fixed in the docs to be less confusing. Thanks!

lwyatt (Thu, 10 Feb 2022 05:44:29 GMT):
Has joined the channel.

rjones (Fri, 11 Feb 2022 23:27:25 GMT):
this chat has moved to [discord](https://discord.gg/hyperledger)

rjones (Fri, 11 Feb 2022 23:28:25 GMT):
Has left the channel.

rjones (Sat, 12 Feb 2022 22:00:55 GMT):
Has joined the channel.

rjones (Sat, 12 Feb 2022 22:00:56 GMT):
[Please move to Discord](https://discord.com/channels/905194001349627914/905205711850594336)

rjones (Sat, 12 Feb 2022 22:00:56 GMT):
[Please get an account on the Hyperledger discord](https://discord.gg), then [join Indy](https://discord.com/channels/905194001349627914/905205711850594336)