rjones (Wed, 16 May 2018 17:48:15 GMT):
@esplinr we aren't creating more channels with the irc idioms of `+m`. Feel free to mute or remove disruptive users

rjones (Wed, 16 May 2018 17:48:23 GMT):
esplinr

rjones (Wed, 16 May 2018 17:48:48 GMT):
nage

esplinr (Wed, 16 May 2018 17:48:56 GMT):
Thank you @rjones

rjones (Wed, 16 May 2018 17:49:21 GMT):
sure thing. please let me know if you have troubles with disruptive users, also

esplinr (Wed, 16 May 2018 17:49:34 GMT):
Will do.

rjones (Wed, 16 May 2018 17:49:43 GMT):
Has left the channel.

esplinr (Wed, 16 May 2018 17:51:41 GMT):
Coordinating the activities of active maintainers of Hyperledger Indy

esplinr (Wed, 16 May 2018 17:51:41 GMT):
This is a public channel, but is intended for active maintainers with a long term commitment to the project.

esplinr (Wed, 16 May 2018 17:53:22 GMT):
Coordinating active maintainers of Hyperledger Indy.

esplinr (Wed, 16 May 2018 17:53:22 GMT):
This is a public channel, but is intended for active maintainers with a long term commitment to the project. See scrum "Pigs vs Chickens".

esplinr (Wed, 16 May 2018 17:58:50 GMT):
User User_1 added by esplinr.

esplinr (Wed, 16 May 2018 17:58:50 GMT):
User User_2 added by esplinr.

esplinr (Wed, 16 May 2018 17:58:50 GMT):
User User_3 added by esplinr.

esplinr (Wed, 16 May 2018 17:58:50 GMT):
User User_4 added by esplinr.

esplinr (Wed, 16 May 2018 17:58:50 GMT):
User User_5 added by esplinr.

esplinr (Wed, 16 May 2018 17:58:50 GMT):
User User_6 added by esplinr.

esplinr (Wed, 16 May 2018 18:01:14 GMT):
User User_7 added by esplinr.

esplinr (Wed, 16 May 2018 18:01:14 GMT):
User User_8 added by esplinr.

esplinr (Wed, 16 May 2018 18:01:14 GMT):
User User_9 added by esplinr.

esplinr (Wed, 16 May 2018 18:01:14 GMT):
User User_10 added by esplinr.

esplinr (Wed, 16 May 2018 18:02:23 GMT):
This channel is intended for active maintainers with a long term commitment to the project (see scrum "Pigs vs Chickens"). We are happy to answer questions about Indy in the other channels.

esplinr (Wed, 16 May 2018 18:03:10 GMT):
This channel is intended for active maintainers with a long term commitment to the project (see scrum Pigs vs Chickens). We are happy to answer questions about Indy in the other channels.

esplinr (Wed, 16 May 2018 18:04:32 GMT):
@all Welcome to the channel! During the Monday maintainers meeting I took the action item of setting up this space for us to discuss the project in between our meetings. Thank you @rjones and the Hyperledger project for hosting us!

rjones (Wed, 16 May 2018 18:04:32 GMT):
Has joined the channel.

esplinr (Wed, 16 May 2018 18:05:01 GMT):
I didn't remember everyone that was on the call, so @nage will need to invite the missing people.

nage (Wed, 16 May 2018 22:03:27 GMT):
Thanks @esplinr! I’ll look at who might be missing when I get back from EIC (@peacekeeper has been everywhere speaking on everything Sovrin, Indy and DIF).

rjones (Thu, 17 May 2018 01:05:03 GMT):
This channel is intended for active maintainers with a long term commitment to the project (see scrum Pigs vs Chickens). We are happy to answer questions about Indy in the other channels

rjones (Thu, 17 May 2018 01:05:46 GMT):
This channel is intended for active maintainers with a long term commitment to the project (see scrum Pigs vs Chickens).

danielhardman (Thu, 17 May 2018 15:07:29 GMT):
@nage , can we assign RFC numbers to my two RFCs (revocation, ssi notation)?

tkuhrt (Mon, 21 May 2018 16:19:25 GMT):
Has joined the channel.

nage (Tue, 22 May 2018 15:59:05 GMT):
_is finally digging out on Rocket.Chat, hopes to start digging out on Github next_

danielhardman (Tue, 22 May 2018 16:58:17 GMT):
Dear indy maintainers: I have raised a PR against indy-rfc in which I propose to remove the term "RFC" from Indy's improvement proposal process, and replace it with "HIIP" (Hyperledger Indy Improvement Proposal, pronounced "hip" for short). The proposal includes the suggestion that we rename the repo from indy-rfc to indy-hiip. The rationale for this change comes from @drummondreed, a veteran of open source and standards efforts who pushed back against the use of the term "RFC" based on two observations: 1. "RFC" says IETF, and presupposes a certain format and process that we are not slavishly following. For example, as @swcurran pointed out, we write docs that include diagrams and so forth. 2. We need to reinforce our own community in the same way that Bitcoin has BIP and Python has PEP and Ethereum has ERC.

drummondreed (Tue, 22 May 2018 16:58:17 GMT):
Has joined the channel.

swcurran (Tue, 22 May 2018 17:58:15 GMT):
Hyperledger Indy Proposal to Standardize Technology Enhancement/Refactoring

danielhardman (Tue, 22 May 2018 17:58:42 GMT):
Gotta love HIPSTERs

danielhardman (Tue, 22 May 2018 17:58:44 GMT):
:-)

danielhardman (Tue, 22 May 2018 17:59:26 GMT):
I'd like to propose something similar to @swcurran's idea bout numbering our improvement proposals. Stephen proposed using github issue numbers, and I felt concerned that people could raise those issues for other stuff. What about a slight variation, which is that we just use the PR number that github gives us?

danielhardman (Tue, 22 May 2018 17:59:26 GMT):
I'd like to propose something similar to @swcurran's idea about numbering our improvement proposals. Stephen proposed using github issue numbers, and I felt concerned that people could raise those issues for other stuff. What about a slight variation, which is that we just use the PR number that github gives us?

swcurran (Tue, 22 May 2018 18:02:55 GMT):
@danielhardman - the problem with that is you have to do the PR with the HIIP before you get a number, and then update document/folder to use the number. If you use Issue number, it's auto-generated before the PR. I also like that you can have a pre-PR discussion on the Issue which - I think is friendlier to new contributors.

danielhardman (Tue, 22 May 2018 18:03:10 GMT):
That's a good point.

swcurran (Tue, 22 May 2018 18:03:33 GMT):
But agree on the HIIP proposal and let's get the HIIPs you have already submitted in play.

danielhardman (Tue, 22 May 2018 18:04:32 GMT):
I think you've mostly convinced me. What does everybody else here think?

danielhardman (Tue, 22 May 2018 19:13:54 GMT):
@mhailstone ? @nage ? @ashcherbakov ? @gudkov ? @esplinr ? Do any of you have objections to: 1. The proposal to start calling these things HIIPs instead of RFCs 2. The notion of numbering them by raising github issues?

mhailstone (Tue, 22 May 2018 19:23:13 GMT):
I like the new process as well. But what about calling it "hype"? (just kidding, only sort of not)

nage (Tue, 22 May 2018 20:05:15 GMT):
Hyperedger Indy Project Enhancements (HIPE)

nage (Tue, 22 May 2018 20:05:17 GMT):
?

nage (Tue, 22 May 2018 20:05:41 GMT):
I like asking people to HIPE their idea 😇

swcurran (Tue, 22 May 2018 20:24:28 GMT):
HIPE is my preference. Better than HIIP.

swcurran (Tue, 22 May 2018 20:24:28 GMT):
HIPE is my preference. Better than HIIP (and HIPSTER).

devin-fisher (Tue, 22 May 2018 20:34:48 GMT):
Has joined the channel.

devin-fisher (Tue, 22 May 2018 20:55:37 GMT):
So the main issue I see with using an auto generated number is (both PR or issue) you chew through namespace for ideas that don't become real RFCs. Also, there is a possibility someone maliciously consumes numbers. rust-lang/rfcs, which is what we based our the rfc format on and they use PR numbers, and the latest rfc is numbered 2420. They have used up a quarter of their name space in 4 years. But they only have 393 actual rfcs. So only 16% of their PR result in an actual rfc but all potential rfc consume a name-space number. Who know what our usage will be but it could be similar. I think giving the RFC a number when merge is the cleanest way.

gudkov (Wed, 23 May 2018 06:27:06 GMT):
> I think giving the RFC the next sequential number when merge is the cleanest way. I don't see what the benefits of knowing the number before its merges are. I share this vision too. According to names all look ok for me.

esplinr (Wed, 23 May 2018 14:28:47 GMT):
Sorry for my delay in responding.

esplinr (Wed, 23 May 2018 14:30:02 GMT):
Thank you @danielhardman for the suggestion to improve the naming. I think they are all improvements to "RFC", and I prefer HIPE.

esplinr (Wed, 23 May 2018 14:30:09 GMT):
I do not have an opinion on the numbering.

danielhardman (Wed, 23 May 2018 14:49:13 GMT):
Okay, I will change the naming to be HIPE.

rjones (Wed, 23 May 2018 15:32:41 GMT):
https://github.com/hyperledger/indy-hipe

esplinr (Wed, 23 May 2018 15:33:56 GMT):
Wow, that was fast. Thank you @rjones and @danielhardman

danielhardman (Wed, 23 May 2018 15:34:21 GMT):
Yes, thank you @rjones .

rjones (Wed, 23 May 2018 22:27:12 GMT):
Has left the channel.

grice_32 (Tue, 29 May 2018 16:45:30 GMT):
Has joined the channel.

burdettadam (Tue, 29 May 2018 19:14:50 GMT):
Has joined the channel.

jwaup (Wed, 30 May 2018 14:00:54 GMT):
Has joined the channel.

danielhardman (Fri, 08 Jun 2018 23:20:59 GMT):
Guys, I propose that we place the credential revocation HIPE into the 2-week Final Comment Period. If we don't hear any objections, then after 2 weeks I want to merge it to master. My reasoning is: 1. This documents something that's already been built, so I don't think it's necessary to debate the merits much. It did receive quite a lot of analysis from several crypto minds other than its implementers. 2. I want at least one HIPE to be visible to the public, asap. What do you think?

danielhardman (Fri, 08 Jun 2018 23:20:59 GMT):
I propose that we place the credential revocation HIPE into the 2-week Final Comment Period. If we don't hear any objections, then after 2 weeks I want to merge it to master. My reasoning is: 1. This documents something that's already been built, so I don't think it's necessary to debate the merits much. It did receive quite a lot of analysis from several crypto minds other than its implementers. 2. I want at least one HIPE to be visible to the public, asap. What do you think?

esplinr (Fri, 08 Jun 2018 23:48:21 GMT):
I'm in favor.

esplinr (Fri, 08 Jun 2018 23:48:52 GMT):
Does anyone have feedback on the HIPE for multi-threaded architecture of LibIndy? We would like to proceed with putting together an implementation plan.

danielhardman (Sun, 10 Jun 2018 15:08:59 GMT):
I have read it. I am yet comfortable with the approach (short-term or long-term). I think further discussion is needed. When could we do that?

danielhardman (Sun, 10 Jun 2018 15:08:59 GMT):
I have read it. I am not yet comfortable with the approach (short-term or long-term). I think further discussion is needed. When could we do that?

esplinr (Mon, 11 Jun 2018 15:11:37 GMT):
Link to the maintainers meeting agenda: https://docs.google.com/document/d/1d_SnxinX54Sx-0TwRTnSJK6p_ZN27ZvoI3ytha1QS28/edit#

swcurran (Mon, 11 Jun 2018 17:31:41 GMT):
FYI - Matthew and I have been working on an Agent's Collected Wisdom document in google to collect and organize our thoughts on all things Agents. https://docs.google.com/document/d/1mRLPOK4VmU9YYdxHJSxgqBp19gNh3fT7Qk4Q069VPY8/edit?usp=sharing

swcurran (Mon, 11 Jun 2018 17:31:41 GMT):
FYI - @mhailstone and I have been working on an Agent's Collected Wisdom document in google to collect and organize our thoughts on all things Agents. https://docs.google.com/document/d/1mRLPOK4VmU9YYdxHJSxgqBp19gNh3fT7Qk4Q069VPY8/edit?usp=sharing

esplinr (Mon, 11 Jun 2018 17:32:58 GMT):
That looks useful! That's a good example of something that we don't want to lose in a Google Drive. Long term, I think it would be a good document in markdown in the Git repository alongside other architecture information.

swcurran (Mon, 11 Jun 2018 17:34:35 GMT):
Agree - switching to md will be easy at some point. But for now, the cost of collaborating in this type of document in github is pretty high.

esplinr (Mon, 11 Jun 2018 17:35:05 GMT):
I agree.

esplinr (Mon, 11 Jun 2018 17:35:43 GMT):
I see the value of having everything be a pull request, but documentation in GitHub is much easier with direct commits where you can use the WebUI like a Wiki.

esplinr (Mon, 11 Jun 2018 17:36:25 GMT):
I'm trying to schedule the follow up discussion about concurrency and performance in LibIndy. The only time it appears that North America Pacific overlaps with Eastern Russia is 8AM Pacific / 6PM Moscow. That's a busy hour in people's calendars.

esplinr (Mon, 11 Jun 2018 17:37:15 GMT):
It looks like Nathan, Daniel, and I are all available on Friday, June 22. Does that work for you @swcurran ? It's late for Slava on a Friday, but he's normally available.

swcurran (Mon, 11 Jun 2018 17:42:07 GMT):
That time is good for me, although it is the time we are trying to use for the Agent Weekly call. If that's it, that's fine. I could do it earlier - e.g. 7AM Mountain. if that would help. That's 6AM Pacific which I determined last Friday was challenging but doable :-).

esplinr (Mon, 11 Jun 2018 17:46:28 GMT):
I'll tell @jljordan_bcgov that the 6AM meeting was your idea. grin

esplinr (Mon, 11 Jun 2018 17:53:12 GMT):
Looking at people's calendars, I don't think an early call is going to work. Most of the attendees on the Agent call will probably be interested in this topic. Do you mind us hijacking your call one time?

swcurran (Mon, 11 Jun 2018 17:54:14 GMT):
Sure - go for it.

esplinr (Mon, 11 Jun 2018 17:58:28 GMT):
Thanks.

swcurran (Mon, 11 Jun 2018 18:29:50 GMT):
@mhailstone FYI for the 22nd ^^^^ I assume we'll keep the agent call and I'll either go on this other call or have someone on that call. Not sure I'm the right person anyway.

mhailstone (Mon, 11 Jun 2018 18:32:15 GMT):
@swcurran @esplinr I am capturing a lot of the details in the Google document in a README.md in the indy-agent repository. After this week, I'll clean it up and create a PR.

swcurran (Mon, 11 Jun 2018 18:33:16 GMT):
At the nodejs or the root level? I think we want a lot of it at the root level.

mhailstone (Mon, 11 Jun 2018 18:34:18 GMT):
It's at the root level in a `docs` directory currently.

mhailstone (Mon, 11 Jun 2018 18:34:55 GMT):
Welcome to use the 22nd time slot for the call mentioned earlier.

danielhardman (Tue, 12 Jun 2018 01:02:13 GMT):
@swcurran I updated the revocation HIPE to address two of your points of feedback: https://github.com/hyperledger/indy-hipe/pull/8/commits/02b174e836ea7fbd9cce58ebf86064cfdeaa93c4

swcurran (Wed, 13 Jun 2018 03:16:23 GMT):
I had asked this question on indy-sdk but I think it got lost. Time to go more directly: 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/ If not - is there a timeframe? Thanks!

stevetolman (Wed, 13 Jun 2018 14:03:22 GMT):
Has left the channel.

esplinr (Thu, 14 Jun 2018 20:15:30 GMT):
@swcurran Did you get an answer to your question? cc @ashcherbakov

ashcherbakov (Fri, 15 Jun 2018 07:06:33 GMT):
@swcurran The current implementation doesn't fully support the DID spec, but this is one of the features in our Roadmap. I think @esplinr could provide more details about the timeframe. BTW there is a Design for DID support: https://github.com/sovrin-foundation/sovrin/blob/master/spec/did-method-spec-template.html. This is currently in Sovrin repo, but I think it will be implemented in Indy.

esplinr (Fri, 15 Jun 2018 12:26:21 GMT):
Ah, that's the project we have listed under "standards compliance" for the second half of this year.

swcurran (Fri, 15 Jun 2018 14:21:42 GMT):
Thanks - I'll check out the design spec.

esplinr (Mon, 25 Jun 2018 22:51:51 GMT):
There was a brief discussion on our call this morning about the Getting Started Guides being out of date. I forgot to mention that we have #indy-outreach where people interested in improving that developer on-ramp experience can coordinate their efforts. I encourage people to join. I just posted some thoughts there.

danielhardman (Tue, 10 Jul 2018 05:57:58 GMT):
On Monday's maintainers call, we decided to advance two HIPEs to the next phase. For the revocation HIPE, we formally announced a final comment period about 4 weeks ago, so I believe it's ready to merge. For Slava's concurrency HIPE, it's not clear to me whether the next step is to announce a 2-week Final Comment Period, or to merge. Can someone clarify?

danielhardman (Tue, 10 Jul 2018 05:58:41 GMT):
I believe I have permissions to merge stuff. Should I go ahead with one or both of these HIPEs? Or should somebody else?

danielhardman (Wed, 11 Jul 2018 07:28:59 GMT):
I raised a HIPE about the design of wallets. There is nothing new in it; it's just a write-up of the presentation that was previously given. https://github.com/hyperledger/indy-hipe/pull/20

n3m (Wed, 11 Jul 2018 07:32:55 GMT):
Has joined the channel.

salmanbaset (Wed, 11 Jul 2018 18:27:14 GMT):
Has joined the channel.

wightman (Wed, 11 Jul 2018 21:04:26 GMT):
Has joined the channel.

swcurran (Thu, 12 Jul 2018 04:28:31 GMT):
@danielhardman @nage and others - took a shot at the Transport HIPE. The following is copied from the indy-agent channel. Thought I should post it here as well. https://github.com/hyperledger/indy-hipe/pull/21 Hey folks, attached is a HIPE about Transport Layer Messaging that I promised to take a shot at. This is likely far too simple to be complete and I offer it mainly to get the conversation going. As noted in the pull request - pictures are desperately needed and I hope to get to that soon, but I have some other work to do. The assumptions are "interesting". I think they are reasonable, but they still leave much up to an implementation. I did not look at what @kdenhartog posted a short time ago in the SSI Protocol repo and so don't know if that affects this.

kdenhartog (Thu, 12 Jul 2018 04:28:31 GMT):
Has joined the channel.

danielhardman (Thu, 12 Jul 2018 08:37:27 GMT):
Thanks, @swcurran . I've got several HIPEs that need review, but I'm finding that my travels in India are not leaving me the evening time that I expected, so I haven't gotten through them yet, like I had hoped. Perhaps this weekend... or maybe late tonight...

danielhardman (Thu, 12 Jul 2018 09:29:41 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=avChAKgoKYdkabk2g) Okay, all, I am going to take matters into my own hands because it's been a few days since I asked about merging two approved HIPEs, and nobody has responded. Here is what I'm going to do: 1. I'm going to update my revocation HIPE to use a number. We never did get around to assigning numbers, but I'm going to start with 11 in case the first 10 need to be reserved for more fundamental matters. 2. Once my revocation HIPE has been updated with a number, I'm going to merge it. 3. I'm going to announce on the mailing list a shortened FCP for Slava's HIPE about concurrency. I will also ask him to update it to use a number, perhaps 12.

danielhardman (Thu, 12 Jul 2018 09:30:08 GMT):
@gudkov , will you update your concurrency HIPE to use number 0012?

danielhardman (Thu, 12 Jul 2018 09:34:09 GMT):
Okay, hipe 0011-cred-revocation has been merged.

gudkov (Thu, 12 Jul 2018 11:57:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=cZajZbHpg5RexF42w) @danielhardman shure

gudkov (Thu, 12 Jul 2018 11:57:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=cZajZbHpg5RexF42w) @danielhardman sure

ryanwest6 (Thu, 12 Jul 2018 22:12:10 GMT):
Has joined the channel.

dbluhm (Fri, 13 Jul 2018 01:02:23 GMT):
Has joined the channel.

sammitchell (Fri, 13 Jul 2018 07:44:32 GMT):
Has joined the channel.

nage (Fri, 13 Jul 2018 21:14:44 GMT):
Ry posted this in the #sawtooth-core-dev channel, I'm guessing it will be the case for those with maintainer rights for Indy as well: 2FA will soon be required across all GitHub orgs. If you do not have 2FA enabled for your account, you will be automatically removed from the Hyperledger org and will need to be re-added. Please check to ensure you have 2FA enabled. https://help.github.com/articles/securing-your-account-with-two-factor-authentication-2fa/

rjones (Wed, 18 Jul 2018 13:12:52 GMT):
Has joined the channel.

rjones (Wed, 18 Jul 2018 13:13:13 GMT):
@nage correct, I missed this channel. An oversight on my part.

danielhardman (Wed, 18 Jul 2018 13:13:31 GMT):
@rjones : Ry, we are trying to model some dependency issues in git repos, and I am wondering if it's time for me to attempt to solve the problem with git submodules. I know that this mechanism's been around for a while. Most developers haven't used it. A few are very critical of it. Some like it. What is your experience/opinion? Also, do you have any experience with other tools that solve the same problem, such as Google's repo tool?

rjones (Wed, 18 Jul 2018 13:21:33 GMT):
@danielhardman interesting question with a lot to unpack. We use git submodules for a lot of LFIT projects, and it works fine. You'll see goofy commits like this: https://github.com/hyperledger/ci-management/commit/e8aafd1be445e1fe0a2f23d3e946fc96abd47f9d

rjones (Wed, 18 Jul 2018 13:22:20 GMT):
if you look at the diff, it's actually this: https://gerrit.hyperledger.org/r/#/c/23299/2/jjb/global-jjb

danielhardman (Wed, 18 Jul 2018 13:23:59 GMT):
Hmm. I'm uncertain that I'm interpreting correctly. Is your first link a summary of the commit in the parent module, and it's actually a commit to a submodule (that is, nothing in the parent changed, but a bunch of stuff in the submodule did)?

rjones (Wed, 18 Jul 2018 13:24:43 GMT):
yes, exactly. Github is helpfully showing you changes in the submodule when the only change in the parent project is a hash.

rjones (Wed, 18 Jul 2018 13:25:25 GMT):
Setting that aside, it works! You're right that git submodules generate a lot of passion. It is another little thing to trip over - people need to make sure they keep submodules up-to-date when they're building, etc.

danielhardman (Wed, 18 Jul 2018 13:25:28 GMT):
Wow, I wasn't expecting Github to be so helpful. That's better than I expected.

rjones (Wed, 18 Jul 2018 13:28:48 GMT):
The `repo` tool: We used this extensively on my previous project, AllJoyn. Since it adds another external dependency: not a fan. However, once it's up and running, it's also fine.

rjones (Wed, 18 Jul 2018 13:29:32 GMT):
What is the problem within indy you're trying to solve with submodules?

rjones (Wed, 18 Jul 2018 13:29:32 GMT):
What is the problem you're trying to solve with submodules?

danielhardman (Wed, 18 Jul 2018 13:32:48 GMT):
The current indy-sdk repo contains wrappers around libindy, which generates a C-callable library. Each wrapper requires a separate compiler (e.g., the golang compiler for the go wrapper, the jdk for the java wrapper, msbuild for the dotnet wrapper...). We want to move wrappers into separate repos, but still present a coherent view of an sdk. And we want people who only care about one wrapper (e.g., dotnet) to not have to do a full build and full test cycle against the stuff they're not using. There are more complexities that I can't describe in a short paragraph, but that's the essence of it.

rjones (Wed, 18 Jul 2018 13:44:16 GMT):
very similar to the problem we tried to solve for AllJoyn. If you're only dealing with one level of abstraction, submodules are probably the way to go. It is a little thing people will trip over - not keeping the submodule up-to-date will cause problems, but this is solvable with muscle memory.

danielhardman (Wed, 18 Jul 2018 13:47:23 GMT):
Yes, only one level of abstraction. I can see how it could get out of hand if we did it at multiple levels. Ugh.

rjones (Wed, 18 Jul 2018 13:48:27 GMT):
I know this is only one project, and I'm trying not to ask a bunch of questions, but the evolution on AllJoyn was monorepo-> `repo` command -> some submodules -> monorepo with conditional compilation

rjones (Wed, 18 Jul 2018 13:49:27 GMT):
if you can get away with a monorepo and conditional compilation, it's easier, because you always have the whole thing and you don't need to remember to update your submodules

danielhardman (Wed, 18 Jul 2018 13:49:57 GMT):
The repos (submodules) need different maintainers and need to release on different schedules...

danielhardman (Wed, 18 Jul 2018 13:50:25 GMT):
There are some real virtues with a monorepo, though. That's what I was favoring yesterday. I'm trying to investigate all options.

rjones (Wed, 18 Jul 2018 13:52:19 GMT):
I feel a lot of times we're looking for a technical answer to a social question. I feel having a large set of maintainers that only iterate in specific areas by social convention is the way to go.

danielhardman (Wed, 18 Jul 2018 13:53:06 GMT):
No matter what we do, we need some social conventions and human behavioral adaptation. That seems unarguable to me.

rjones (Wed, 18 Jul 2018 13:53:09 GMT):
that is, in a monorepo. You can use complex branching strategies if you like.

danielhardman (Wed, 18 Jul 2018 13:53:52 GMT):
We want the simplest thing that can work. There are many dimensions of "simple", and tradeoffs with every approach.

rjones (Wed, 18 Jul 2018 13:54:33 GMT):
yup.

rjones (Wed, 18 Jul 2018 13:55:59 GMT):
I used to be against submodules, as recently as the inception of the Hyperledger project :) I've learned my bias came from poorly maintained submodules.

danielhardman (Wed, 18 Jul 2018 13:57:34 GMT):
We want: - relative autonomy/independence for different subsets of code or different artifacts that are part of the SDK - a semi-unified view of the SDK so developers landing in the Indy world and finding the SDK don't have to hunt up all the pieces separately - some methodology that makes dependency management predictable and as easy as possible but not easier - the ability to release some parts of the SDK earlier than others (not have to do a monolithic release) - a standard methodology/directory structure for associating derivative artifacts with their documentation and the documentation of things they depend on - a way to work with 2 or 3 derivative artifacts that all share a common dependency

swcurran (Wed, 18 Jul 2018 15:27:13 GMT):
FWIW - I've always thought that it would make sense to have separate repos with a good Readme that outlines versions and quality of support. I totally agree with Daniel's "We want the simplest thing that can work. ", which after a quick read of github submodules which I think is to just go with separate repos. The improved version management in indy-SDK will make that easier for the wrappers. IMHO - a common use case will be an individual/organization coming to Indy is going to start with the wrapper of their choice. A fraction of those might dig into indy-sdk. A (likely different) fraction will look at a second wrapper. Very few will ever look at more than two or more than two and indy-sdk. Over time - even more will simply go to the package manager of choice and bring in a wrapper without ever dealing with the repos. Having said all that...I'm guessing it will be a bunch of work to break out the wrappers now and get a CI/CD pipeline for each.

danielhardman (Wed, 18 Jul 2018 15:38:34 GMT):
+1 to what @swcurran said.

nage (Wed, 18 Jul 2018 15:54:38 GMT):
I agree that the common case should be that wrappers come from repos and that the repositories become about contribution more than about consumption

nage (Wed, 18 Jul 2018 15:56:41 GMT):
we've seen other project break out repositories only to claw them back into core. I'm thinking that keeping the repository and build pipeline infrastructure smaller is actually the right thing to optimize for, as the core maintainers are better prepared to handle the complexity and "not breaking others" than anyone else. I don't want to create a situation where we have to manage a lot of cross-repository complexity or build tools issues, because I don't think we will have any dedicated resources to those problems.

nage (Wed, 18 Jul 2018 15:57:53 GMT):
a monolithic repository is a more brain-dead approach, that doesn't really solve the problem, but defers the hard bits to places and people who are better prepared to manage them.

nage (Mon, 23 Jul 2018 15:02:33 GMT):
https://docs.google.com/document/d/1d_SnxinX54Sx-0TwRTnSJK6p_ZN27ZvoI3ytha1QS28

burdettadam (Wed, 25 Jul 2018 20:07:27 GMT):
HIPE for Maintainer Procedures, https://github.com/hyperledger/indy-hipe/pull/23

danielhardman (Wed, 01 Aug 2018 22:24:59 GMT):
I read Adam's HIPE and endorse it. It doesn't feel very controversial. Can we put it into a 2-week FCP?

danielhardman (Wed, 01 Aug 2018 22:25:47 GMT):
@nage, do we have an agenda for the maintainer's meeting on which I can formally propose FCP promotion for HIPEs?

danielhardman (Wed, 01 Aug 2018 22:27:56 GMT):
All: the HIPE from @gudkov on concurrency improvements has been at FCP status for about 5 weeks. Can we merge it?

esplinr (Wed, 01 Aug 2018 23:14:25 GMT):
@danielhardman Maintainer meeting agenda: https://docs.google.com/document/d/1d_SnxinX54Sx-0TwRTnSJK6p_ZN27ZvoI3ytha1QS28/edit

esplinr (Wed, 01 Aug 2018 23:14:53 GMT):
I vote that we merge both HIPEs.

nage (Thu, 02 Aug 2018 15:19:06 GMT):
I have merged 16 and 20

nage (Thu, 02 Aug 2018 15:19:54 GMT):
I also vote we move to merge the maintainers guidelines more quickly, as they should only contain the existing rules we had already approved in google doc and slide deck form

nage (Thu, 02 Aug 2018 15:22:19 GMT):
@gudkov @danielhardman @mhailstone or @dbluhm any specific comments on PR 23?

nage (Thu, 02 Aug 2018 15:22:30 GMT):
and whether we can fast-track it?

dbluhm (Thu, 02 Aug 2018 15:23:34 GMT):
Nothing in particular from me.

dbluhm (Thu, 02 Aug 2018 15:23:53 GMT):
Looks good

nage (Thu, 02 Aug 2018 15:25:01 GMT):
I'm hoping we can ratify it on the next maintainer call, provided the primary PR reviewers for each repo have had a chance to see it.

devin-fisher (Fri, 03 Aug 2018 14:35:16 GMT):
HIPE for Indy Project Repos -- https://github.com/hyperledger/indy-hipe/pull/26

RyanWest (Fri, 03 Aug 2018 18:45:57 GMT):
Has joined the channel.

esplinr (Fri, 03 Aug 2018 18:48:18 GMT):
HIPE for libvcx into Indy SDK: https://github.com/hyperledger/indy-hipe/pull/29

esplinr (Fri, 03 Aug 2018 18:50:48 GMT):
Thank you @jankokrstic and @dkulic

dkulic (Fri, 03 Aug 2018 18:50:48 GMT):
Has joined the channel.

jankokrstic (Fri, 03 Aug 2018 18:50:48 GMT):
Has joined the channel.

swcurran (Fri, 03 Aug 2018 18:57:42 GMT):
@esplinr - we would like to get together (online or zoom) with you and some of your team next week to talk about BC Gov writing to the Provisional Network - adding two Trust Anchor TA DIDs, so that we can add the schema and CredDefs we need for our launch. In doing that, we can talk about code versions and what versions are needed to write to the ledger, create credentials and perform TheOrgBook proofs. I suspect this is too in the weeds for the Maintainers call, but perhaps later in the week? There is a bunch of logistics to work out and likely some verification exercises to make sure the plan we come up with will actually work. A very key question - is there a legal process for becoming a TA?

esplinr (Fri, 03 Aug 2018 19:03:18 GMT):
Yes, we should schedule a call for this discussion.

esplinr (Fri, 03 Aug 2018 19:03:53 GMT):
There is no process for becoming a Trust Anchor. Drummond is proposing removing the permissions associated with Trust Anchor in the next update of the framework.

esplinr (Fri, 03 Aug 2018 19:04:13 GMT):
Today we also discussed as a team how we can get the ledger onto the version you need to go live. I'll have more information about that next week.

esplinr (Fri, 03 Aug 2018 19:27:05 GMT):
@swcurran How about Tuesday at 8AM Pacific?

esplinr (Fri, 03 Aug 2018 19:28:20 GMT):
Hmm, Nathan is busy Tuesday.

esplinr (Fri, 03 Aug 2018 19:28:36 GMT):
I'm not sure whether it is better to have Alex with us Tuesday morning, or Nathan with us Wednesday afternoon.

swcurran (Fri, 03 Aug 2018 19:29:20 GMT):
Maybe both? Early on Tuesday and Wednesday. There is the on the ground technical issues, and then Sovrin Network issuers.

swcurran (Fri, 03 Aug 2018 19:29:20 GMT):
Maybe both? Early on Tuesday and Wednesday. There is the on the ground technical issues, and then Sovrin Network issues.

swcurran (Fri, 03 Aug 2018 19:29:44 GMT):
Latter being more business/political

swcurran (Fri, 03 Aug 2018 19:29:44 GMT):
Latter being more business/legal

esplinr (Fri, 03 Aug 2018 19:29:48 GMT):
Not many times when I can get Nathan and Alex together.

esplinr (Fri, 03 Aug 2018 19:30:24 GMT):
6AM Pacific on Friday.

swcurran (Fri, 03 Aug 2018 19:31:40 GMT):
That's actually tricky for me. I'll have to drive in the middle of that.

esplinr (Fri, 03 Aug 2018 19:31:54 GMT):
So proceed without Alex?

esplinr (Fri, 03 Aug 2018 19:32:19 GMT):
1PM Pacific on Wednesday.

swcurran (Fri, 03 Aug 2018 19:32:26 GMT):
Sounds good.

esplinr (Fri, 03 Aug 2018 19:32:54 GMT):
I'll update @ashcherbakov after the meeting. I can also invite our QA lead.

esplinr (Fri, 03 Aug 2018 19:34:45 GMT):
Invitation sent.

dbluhm (Mon, 06 Aug 2018 18:18:26 GMT):
I've made the promised changes to the "Agent Message Structure" (formerly "core message structure") HIPE. Let me know if you feel that further changes should be made

devin-fisher (Mon, 06 Aug 2018 19:36:17 GMT):
@nage Do you know about plans for a repo named 'indy-doc'? Adam added it to the repo hipe. I'm just double checking.

dbluhm (Mon, 06 Aug 2018 19:43:47 GMT):
@devin-fisher We talked about it briefly in the maintainers call this morning; the consensus was that including it now was premature since the indy-docs repo hasn't been approved quite yet.

dbluhm (Mon, 06 Aug 2018 19:44:56 GMT):
@burdettadam should be updating his PR to your HIPE soon

burdettadam (Mon, 06 Aug 2018 19:46:53 GMT):
@devin-fisher I just removed indy-doc from my PR. I left all other changes I had.

devin-fisher (Mon, 06 Aug 2018 19:47:24 GMT):
I've already merged it. I'll remove it.

nage (Mon, 06 Aug 2018 20:00:26 GMT):
@devin-fisher we are shooting down an indy-doc repo for now

nage (Mon, 06 Aug 2018 20:00:54 GMT):
so lets get that repo taken back out (we talked about it in the maintainer meeting this morning).

devin-fisher (Mon, 06 Aug 2018 20:09:23 GMT):
Done :arrow_heading_up:

danielhardman (Mon, 06 Aug 2018 22:07:27 GMT):
I have updated my HIPE to SSI Notation, to react to @swcurran 's feeback about DID Docs. I think it is good enough to merge now. Unless Stephen votes against, I think we can merge at Nathan's discretion. @nage , do you want me to update the PR with a HIPE number (#14, maybe)?

burdettadam (Mon, 06 Aug 2018 22:49:44 GMT):
I just updated Maintainer Procedures HIPE #23 with suggestions from maintainers meeting.

swcurran (Tue, 07 Aug 2018 00:34:07 GMT):
Thanks - holiday here today, but I'll be HIPE-reading tomorrow.

burdettadam (Tue, 07 Aug 2018 17:01:07 GMT):
Indy-docs HIPE has been updated, https://github.com/hyperledger/indy-hipe/pull/24 .

danielhardman (Tue, 07 Aug 2018 18:01:41 GMT):
I have been working on some ideas about how to report errors in A2A comms. They are coherent enough to share; if people like them, I will put them in HIPE form: https://docs.google.com/document/d/1PJJoPGOFkgsGWfJwmLhjVgH1CyjDgDskZTzxN3D35Oo/edit?usp=sharing

nage (Wed, 08 Aug 2018 14:09:53 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=SNZx77S5N8F6pqypB) @danielhardman yes please

swcurran (Thu, 09 Aug 2018 17:27:55 GMT):
I'm looking at the VCX code and seeing the payment methods sprinkled throughout and that has me thinking. How soon will we have to include payment handling in our code? Should we be updating VON_Anchor to include payments and if so - are there guidelines as to what we have to do. I guess the main question is what will we have to use payments for on Sovrin and what is optional?

ianco (Fri, 10 Aug 2018 17:19:10 GMT):
Has joined the channel.

esplinr (Tue, 14 Aug 2018 04:06:39 GMT):
@swcurran libvcx will work with either Sovrin payments or libnullpay.

devin-fisher (Tue, 14 Aug 2018 20:10:31 GMT):
Looking at the current state of master of `indy-hipe` I see that wallet was merged without HIPE number. I'm sure this was a mistake. Is someone fixing this? If not I can. @danielhardman :arrow_heading_up:

swcurran (Tue, 14 Aug 2018 20:14:02 GMT):
@devin-fisher - it is supposed to be fixed. I'd say you should go ahead.

swcurran (Tue, 14 Aug 2018 20:14:26 GMT):
Per above - it's supposed to be #14

swcurran (Tue, 14 Aug 2018 20:14:26 GMT):
Per above - it's supposed to be something else. Looks like it's SSI Notation that is supposed to be merged with 14.

devin-fisher (Tue, 14 Aug 2018 20:21:14 GMT):
I'll give wallets 14, SSI Notation can get the next number when its merged.

devin-fisher (Tue, 14 Aug 2018 20:25:43 GMT):
Accidentally, looks like 13 is the next available number. I'll give it that number.

devin-fisher (Tue, 14 Aug 2018 20:26:27 GMT):
PR for indy-hipe: https://github.com/hyperledger/indy-hipe/pull/33 Not a HIPE, just a fix for wallet to give it a number.

danielhardman (Tue, 14 Aug 2018 21:03:21 GMT):
@devin-fisher : I merged the PR, so the wallets HIPE is officially 13 now. (Unlucky? :-)

devin-fisher (Tue, 14 Aug 2018 21:06:25 GMT):
Oh, were we skipping 13? Woops. Some place consider 13 to be lucky (for example Italy).

jljordan_bcgov (Thu, 16 Aug 2018 04:28:57 GMT):
I was married on Friday the 13th so far that’s lucky for me :)

rjones (Thu, 16 Aug 2018 06:17:28 GMT):
I got married on the Ides of March. 🍻

nage (Mon, 20 Aug 2018 14:40:34 GMT):
https://zoom.us/j/615818107

nage (Mon, 20 Aug 2018 14:40:45 GMT):
Maintainers call starts in 20 minutes

esplinr (Mon, 20 Aug 2018 15:01:51 GMT):
pinging Nathan . . . . pinging Nathan

esplinr (Mon, 20 Aug 2018 15:01:55 GMT):
@nage

mhailstone (Mon, 20 Aug 2018 15:03:58 GMT):
Waiting for host

esplinr (Mon, 20 Aug 2018 15:05:01 GMT):
I think @nage got abducted by aliens in the last 25 minutes.

esplinr (Mon, 20 Aug 2018 15:05:39 GMT):
Yay! They returned him.

esplinr (Tue, 21 Aug 2018 10:31:01 GMT):
Our next Indy Maintainers meeting is on the US Labor Day holiday. Are we planning to cancel it and just meet again in a month?

nage (Tue, 21 Aug 2018 14:43:06 GMT):
We should cancel it, any objections?

swcurran (Tue, 21 Aug 2018 15:14:11 GMT):
Good with me.

danielhardman (Wed, 22 Aug 2018 23:13:35 GMT):
Do we need any convention about certain constructs in a HIPE's text? I noticed just now that one I read used the words "must" and "should" with double emphasis (**must** in markdown), and introduced terms with capital letters, then consistently capitalized them thereafter. I had been using double emphasis to introduce terms, but not calling them out thereafter, and had been assuming that the usage of "must" and "should" would follow RFC conventions (MUST, SHOULD, MAY). I seem to remember @nage making a recommendation that we should be saying SHOULD NOT more than SHOULD? (Maybe I'm remembering wrong.) Anyway, do we care? If yes, should we write a HIPE about HIPE conventions, or just update the main repo README and the template files that describe how HIPEs should be written?

jljordan_bcgov (Thu, 23 Aug 2018 00:25:16 GMT):
I certainly care about key words and consistency ... and following RFC conventions seems like a very good idea. These documents are meant to reduce uncertainty so consistent language is critical IMO

jljordan_bcgov (Thu, 23 Aug 2018 00:26:42 GMT):
in fact there MUST be a HIPE that specifies this :)

mhailstone (Thu, 23 Aug 2018 03:31:01 GMT):
@danielhardman @jljordan_bcgov I agree with following RFC conventions (https://www.ietf.org/rfc/rfc2119.txt). I do like @danielhardman 's suggestion of changing the template HIPE to ensure knowledge and following of conventions might be sufficient. Either way, an official HIPE or changing the template, is a good idea.

nage (Thu, 23 Aug 2018 05:05:15 GMT):
I vote we add the RFC statement to HIPE-0001

sureshtedla (Fri, 31 Aug 2018 17:29:32 GMT):
Has joined the channel.

SRibeiro (Wed, 05 Sep 2018 12:57:19 GMT):
Has joined the channel.

MALodder (Wed, 05 Sep 2018 17:00:32 GMT):
Has joined the channel.

MALodder (Wed, 05 Sep 2018 17:01:36 GMT):
New HIPE concerns [agent-to-agent communication and forward secrecy](https://github.com/hyperledger/indy-hipe/pull/38)

MALodder (Wed, 05 Sep 2018 17:01:36 GMT):
New HIPE concerning [agent-to-agent communication and forward secrecy](https://github.com/hyperledger/indy-hipe/pull/38)

rjones (Mon, 10 Sep 2018 19:19:42 GMT):
@tijohnson

tijohnson (Mon, 10 Sep 2018 19:19:42 GMT):
Has joined the channel.

rjones (Mon, 10 Sep 2018 19:20:19 GMT):
@andkononykhin

andkononykhin (Mon, 10 Sep 2018 19:20:19 GMT):
Has joined the channel.

rjones (Mon, 10 Sep 2018 19:20:55 GMT):
is this an OK forum to discuss, or should we do it in tickets? this is the github admin issue

andkononykhin (Tue, 11 Sep 2018 16:04:59 GMT):
@rjones @tijohnson Hello. For me it's ok. If you want I can post to helpdesk as well.

andkononykhin (Wed, 12 Sep 2018 15:56:30 GMT):
@rjones @tijohnson Do you have any questions for me? Or do you expect any requests from me besides ones I posted to helpdesk?

kenebert (Wed, 12 Sep 2018 16:54:33 GMT):
Has joined the channel.

rjones (Fri, 14 Sep 2018 21:24:19 GMT):
@andkononykhin sorry, I went on PTO and didn't communicate with @tijohnson that I expected this to be worked out here

TelegramSam (Mon, 17 Sep 2018 14:58:31 GMT):
Indy Maintainers Call in 2 minutes. https://zoom.us/j/615818107

TelegramSam (Mon, 17 Sep 2018 14:58:36 GMT):
Sorry for the late warning.

TelegramSam (Mon, 17 Sep 2018 14:58:55 GMT):
Nathan has asked me to run the meeting, but it doesn't like me as host...

TelegramSam (Mon, 17 Sep 2018 15:19:09 GMT):
Minutes: https://docs.google.com/document/d/1d_SnxinX54Sx-0TwRTnSJK6p_ZN27ZvoI3ytha1QS28/edit#heading=h.ocl4kdczjoj

swcurran (Mon, 17 Sep 2018 15:19:56 GMT):
Import to JIRA from github: https://confluence.atlassian.com/adminjiraserver071/importing-data-from-github-802592903.html

andkononykhin (Mon, 17 Sep 2018 16:31:07 GMT):
@rjones Hello Ry. I see, no problem

danielhardman (Mon, 17 Sep 2018 16:58:44 GMT):
All of the following PRs have been merged: #9 SSI Notation --> 0014-ssi-notation #12 Agent Test Suite --> 0015-agent-test-suite-interface and 0016-agent-test-suite-v1 #17 Agent Message Structure --> 0017-agent-message-structure

danielhardman (Mon, 17 Sep 2018 16:59:10 GMT):
#26 Indy Git Repos --> 0018-indy-git-repos

danielhardman (Mon, 17 Sep 2018 16:59:31 GMT):
#23 Maintainer Procedures --> 0019-maintainer-procedures

danielhardman (Mon, 17 Sep 2018 17:00:08 GMT):
#22 AuthCrypt and AnonCrypt description --> 0020-encryption-primitives

RBorst (Tue, 18 Sep 2018 15:45:22 GMT):
Has joined the channel.

kelly_ (Thu, 20 Sep 2018 15:35:29 GMT):
Has joined the channel.

kelly_ (Thu, 20 Sep 2018 15:36:30 GMT):
:wave: hey Indy maintainers

kelly_ (Thu, 20 Sep 2018 15:37:06 GMT):
I work on the Sawtooth project and as the community grows we are trying to figure out how to coordinate/communicate so that two people aren't developing the same feature in parallel

kelly_ (Thu, 20 Sep 2018 15:37:38 GMT):
One of the folks on the Sawtooth team mentioned you guys had this happen recently and I'm wondering if you came up with a plan to prevent that in the future

esplinr (Thu, 20 Sep 2018 16:15:52 GMT):
The Evernym Indy teams have posted our sprint demos to YouTube. You can see them here: https://www.youtube.com/playlist?list=PLRp0viTDxBWGLdZk0aamtahB9cpJGV7ZF Everything is there since May, except for one recording from early July that I lost.

esplinr (Thu, 20 Sep 2018 16:17:48 GMT):
@kelly_ We use a shared roadmap in the wiki where each team declares what they plan to work on: https://wiki.hyperledger.org/projects/indy/roadmap We should probably do better at keeping that up to date. We also have a monthly meeting were we discuss priorities together.

kelly_ (Thu, 20 Sep 2018 16:18:04 GMT):
awesome thanks!

tkuhrt (Thu, 20 Sep 2018 21:56:24 GMT):

rjones (Fri, 21 Sep 2018 23:11:35 GMT):
@tijohnson @andkononykhin has this been worked out? I was on PTO

andkononykhin (Mon, 24 Sep 2018 09:00:49 GMT):
@rjones @tijohnson no

rjones (Mon, 24 Sep 2018 14:39:38 GMT):
@andkononykhin are you awake?

andkononykhin (Mon, 24 Sep 2018 14:40:02 GMT):
yes, hello

rjones (Mon, 24 Sep 2018 14:40:29 GMT):
excellent.

rjones (Mon, 24 Sep 2018 14:43:41 GMT):
there was ongoing discussion about reducing github access (administrative access) overall on the TSC mailing list WRT Iroha. Indy's access was reduced at the same time for the same issue.

rjones (Mon, 24 Sep 2018 14:44:11 GMT):
The issue is TBH github ACLs are too broad IMHO

rjones (Mon, 24 Sep 2018 14:51:04 GMT):
How often do you think you are needing to do DCObot over-rides?

andkononykhin (Mon, 24 Sep 2018 14:52:23 GMT):
Do you mean how often we might need to skip DCO check in future?

rjones (Mon, 24 Sep 2018 14:53:14 GMT):
no, I mean how often say over the last two months have you needed to do it. An order of magnitude is fine. Once an hour, once a day, once a week?

rjones (Mon, 24 Sep 2018 14:56:13 GMT):
also, are you using the new-ish over-ride DCO UI or are you squashing it directly?

rjones (Mon, 24 Sep 2018 15:03:57 GMT):
I'm asking the last question out of curiosity. I only recently found that bit of UI.

andkononykhin (Mon, 24 Sep 2018 15:12:32 GMT):
>no, I mean how often say over the last two months have you needed to do it. An order of magnitude is fine. Once an hour, once a day, once a week? For feature PRs: I can't remember such things for last months, I guess it might happen for PRs from non-core Indy developers but I can't predict here anything. For release merges: 18 Jul was the last time we faced with DCO issue when it refused previously passed commits. We haven't encountered such issues after that. Possible reason: we stopped using squash for PRs and started to use merge all the time. >also, are you using the new-ish over-ride DCO UI or are you squashing it directly? I am not aware about the UI you mentioned. In the past indy-core developers mostly did `rebase -i` in feature branches /forks.

andkononykhin (Mon, 24 Sep 2018 15:22:14 GMT):
update. I have received feedback from my teammates: seems we do have DCO issues from time to time in PRs but it is fixed in quite same way that I posted without any troubles or in-team discussions. Thus, no stat is available.

rjones (Mon, 24 Sep 2018 15:33:11 GMT):
If you see a red X on a PR status, click it, it will take you to a page where you can override DCO signoff

andkononykhin (Mon, 24 Sep 2018 15:49:58 GMT):
The UI provide an ability to set DCO as passed but I don't see that it changes anything in commit message. More accurate way is mentioned as usage of git commands similar to those that we use (`rebase`/`amend`/force push) "Resolve" link points just to DCO's main page. What is the sense? So, what is the main reason for new UI? Does "Set DCO to pass" button is considered as enough appropriate?

andkononykhin (Mon, 24 Sep 2018 15:49:58 GMT):
The UI provides an ability to set DCO as passed but I don't see that it changes anything in commit message. More accurate way is mentioned as usage of git commands similar to those that we use (`rebase`/`amend`/force push) "Resolve" link points just to DCO's main page. What is the sense? So, what is the main reason for new UI? Does "Set DCO to pass" button is considered as enough appropriate?

andkononykhin (Mon, 24 Sep 2018 15:49:58 GMT):
The UI provides an ability to set DCO as passed but I don't see that it changes anything in commit message. More accurate way is mentioned as usage of git commands similar to those that we use (`rebase`/`amend`/force push) "Resolve" link points just to DCO's main page. So, what is the main reason for new UI? Does "Set DCO to pass" button is considered as enough appropriate?

andkononykhin (Mon, 24 Sep 2018 15:49:58 GMT):
The UI provides an ability to set DCO as passed but I don't see that it changes anything in commit message. More accurate way is mentioned as usage of git commands similar to those that we use (`rebase`/`amend`/force push) "Resolve" link points just to DCO's main page. So, what is the main reason for new UI? Is "Set DCO to pass" button considered as enough appropriate?

rjones (Mon, 24 Sep 2018 17:22:43 GMT):
I don't feel it is. I feel your way is better, @andkononykhin

esplinr (Fri, 28 Sep 2018 23:56:09 GMT):
@all Here is a link to Evernym's most recent sprint demo: https://www.youtube.com/watch?v=Qv41uOORLsk&list=PLRp0viTDxBWGLdZk0aamtahB9cpJGV7ZF

mhailstone (Mon, 01 Oct 2018 15:00:45 GMT):
Meeting today?

TelegramSam (Mon, 01 Oct 2018 15:03:27 GMT):
I'm waiting too.

dbluhm (Mon, 01 Oct 2018 15:03:45 GMT):
Is @nage the host?

esplinr (Mon, 01 Oct 2018 15:04:15 GMT):
I'm waiting.

mhailstone (Mon, 01 Oct 2018 15:04:36 GMT):
That is who the organizer of the meeting invite is from. I supposed that the zoom meeting is Nathan's as well. Not sure.

esplinr (Mon, 01 Oct 2018 15:07:38 GMT):
Yes, the Zoom meeting is Nathan's.

dbluhm (Mon, 01 Oct 2018 15:07:53 GMT):
There's a good chance he won't be able to make the call, I think. He's travelling for the Hyperledger member summit and backrest.

esplinr (Mon, 01 Oct 2018 15:07:57 GMT):
He should add Sam and Mike as co-hosts, or enable the "join with out host" option.

TelegramSam (Mon, 01 Oct 2018 15:08:07 GMT):
yep.

dbluhm (Mon, 01 Oct 2018 15:08:16 GMT):
Hackfest* lol

jljordan_bcgov (Mon, 01 Oct 2018 15:08:23 GMT):
I can offer a zoom room

TelegramSam (Mon, 01 Oct 2018 15:08:43 GMT):
yeah, lets do that.

jljordan_bcgov (Mon, 01 Oct 2018 15:09:14 GMT):
https://zoom.us/j/387327018

nage (Mon, 01 Oct 2018 17:38:05 GMT):
Thanks for changing to a different zoom

nage (Mon, 01 Oct 2018 17:38:28 GMT):
Those with my text number, please text me if you have this issue and I can fix it quickly.

TelegramSam (Mon, 01 Oct 2018 17:42:27 GMT):
@nage I've been tasked with following up on the stuff we decided.

TelegramSam (Mon, 01 Oct 2018 17:42:27 GMT):
@nage I've been tasked with following up with you on the stuff we decided.

TelegramSam (Mon, 01 Oct 2018 18:20:53 GMT):
Mostly we need to promote the HIPEs that we talked about in the meeting. Notes were taken.

TelegramSam (Mon, 01 Oct 2018 18:20:53 GMT):
There is also a suggestion by John Jordan that a new Indy project be created to contain a genericized OrgBook for those who would like to run their own instance.

kdenhartog (Tue, 02 Oct 2018 05:48:43 GMT):
Was there anything in particular that we wanted me to compare wire message and AMES with?

swcurran (Tue, 02 Oct 2018 12:34:31 GMT):
@kdenhartog - the recommendation was to move to final comment period for the Wire Messages HIPE. My question to you is whether that HIPE should be approved as is or is it impacted by the code you have written or the AMES work you are doing? If the answer is obvious either way - no need to look, just let us know the answer. If you need to review the Wire Messages before the final approval period is up to look for changes, please do that as well. Reasonable?

kdenhartog (Tue, 02 Oct 2018 13:36:03 GMT):
Yeah, I'm good to move to FCP for the 3 early HIPEs of yours. If I encounter something small I'll submit an amendment PR against the HIPE and we can discuss it further.

kdenhartog (Tue, 02 Oct 2018 18:58:36 GMT):
@nage @swcurran @mhailstone can someone get a merge request accepted https://github.com/hyperledger/indy-agent/pull/25

TelegramSam (Tue, 02 Oct 2018 19:55:05 GMT):
@kdenhartog working on that.

kdenhartog (Tue, 02 Oct 2018 20:26:16 GMT):
@TelegramSam thanks

nage (Mon, 15 Oct 2018 14:53:36 GMT):
A reminder that the Maintainers call starts in 7 minutes

nage (Mon, 15 Oct 2018 14:55:09 GMT):
Topics for discussion: * shared crypto progress * 1.6 status * Roadmap uodates * options for next Gen of plenum? * universal wallet project options * HIPE review

nage (Mon, 15 Oct 2018 14:55:09 GMT):
Topics for discussion: * shared crypto progress * 1.6 status * Roadmap updates * options for next Gen of plenum? * universal wallet project options * HIPE review

nage (Mon, 15 Oct 2018 15:02:50 GMT):
https://docs.google.com/document/d/1d_SnxinX54Sx-0TwRTnSJK6p_ZN27ZvoI3ytha1QS28

kdenhartog (Mon, 15 Oct 2018 15:05:22 GMT):
doc is view only for me can you add me @nage?

nage (Mon, 15 Oct 2018 15:06:10 GMT):
Done

jljordan_bcgov (Mon, 15 Oct 2018 15:07:38 GMT):
This is an Ottawa company that has some deep capabilities in crypto .. https://www.crypto4a.com I believe they were working in an "entropy as a service"

jljordan_bcgov (Mon, 15 Oct 2018 15:08:27 GMT):
https://www.cengn.ca/wp-content/uploads/2018/04/CENGN-Crypto4A-universal-cybersecurity-platform.pdf

MALodder (Mon, 15 Oct 2018 15:31:50 GMT):
I can't tell what their doing based on their website and the PDF. that's not usually a good sign

MALodder (Mon, 15 Oct 2018 15:32:11 GMT):
@jljordan_bcgov :up:

jljordan_bcgov (Mon, 15 Oct 2018 15:33:03 GMT):
I know the folks from 2Keys that are working with these folks ... we can arrange a call if there is interest

jljordan_bcgov (Mon, 15 Oct 2018 15:33:15 GMT):
I don't know them .. I know of them

danielhardman (Mon, 15 Oct 2018 17:07:24 GMT):
@kdenhartog I have view-only privs on the doc. Can you add my name as someone who attended?

kdenhartog (Mon, 15 Oct 2018 17:07:42 GMT):
yeah

kdenhartog (Mon, 15 Oct 2018 17:07:59 GMT):
done

esplinr (Mon, 15 Oct 2018 20:04:40 GMT):
You can write to the document now.

esplinr (Mon, 15 Oct 2018 20:04:44 GMT):
@danielhardman

danielhardman (Mon, 15 Oct 2018 20:04:54 GMT):
thanks

sergey.minaev (Mon, 29 Oct 2018 15:58:46 GMT):
Has joined the channel.

danielhardman (Mon, 29 Oct 2018 17:01:13 GMT):
The message types HIPE has been merged: https://github.com/hyperledger/indy-hipe/tree/master/text/0021-message-types

danielhardman (Mon, 29 Oct 2018 17:01:19 GMT):
Now working on PR #35

danielhardman (Mon, 29 Oct 2018 17:12:07 GMT):
The cross-domain-messaging HIPE (PR #35) has now been merged as well: https://github.com/hyperledger/indy-hipe/tree/master/text/0022-cross-domain-messaging

cam-parra (Mon, 29 Oct 2018 17:54:13 GMT):
Has joined the channel.

danielhardman (Fri, 02 Nov 2018 15:40:19 GMT):
@esplinr Do we still believe in the Read-the-Docs strategy in this PR? https://github.com/hyperledger/indy-hipe/pull/24 If so, should we hurry and get this merged? It's been languishing...

MALodder (Fri, 02 Nov 2018 18:35:04 GMT):
For Indy agents do we care what the wire message format is? I’ve been thinking about it and wonder why we are using JWE instead or binary

MALodder (Fri, 02 Nov 2018 18:35:04 GMT):
For Indy agents do we care what the wire message format is? I’ve been thinking about it and wonder why we are using JWE instead of binary

MALodder (Fri, 02 Nov 2018 18:35:04 GMT):
For Indy agents do we care what the wire message format is? I’ve been thinking about it and wonder why we are using JWE instead of binary?

MALodder (Fri, 02 Nov 2018 18:35:58 GMT):
If we only pack and unpack agent messages why should it matter if the output of pack is a binary blob

mhailstone (Fri, 02 Nov 2018 21:02:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=JaHJ6lojdQjIuFuYer) @MALodder I think it may have a bearing on interoperability with other SSI solutions and the SSI protocol stack that was discussed at IIW. @TelegramSam What do you think?

danielhardman (Fri, 02 Nov 2018 21:22:31 GMT):
We picked the Jose format because there seem to be some will within the Microsoft and you port communities to use that format. We don't have to stick with it, after all we had already implemented a binary format that was not Jose compliant before then. If you want to go after a binary format, I won't push back, as long as it doesn't affect our chances for interoperability with other communities.

danielhardman (Fri, 02 Nov 2018 21:22:31 GMT):
We picked the Jose format because there seem to be some will within the Microsoft and uPort communities to use that format. We don't have to stick with it, after all we had already implemented a binary format that was not Jose compliant before then. If you want to go after a binary format, I won't push back, as long as it doesn't affect our chances for interoperability with other communities.u

MALodder (Fri, 02 Nov 2018 21:51:36 GMT):
Okay

MALodder (Fri, 02 Nov 2018 21:52:25 GMT):
Just added a PR to Indy crypto to do all inequalities for predicates. See https://github.com/hyperledger/indy-crypto/pull/132

MALodder (Fri, 02 Nov 2018 21:52:47 GMT):
Once that’s merged I’ll raise a PR for Indy SDK to use it

TelegramSam (Mon, 05 Nov 2018 15:54:08 GMT):
> "our chances for interoperability with other communities"

TelegramSam (Mon, 05 Nov 2018 15:54:26 GMT):
This is the largest issue we should be focusing on. Well said @danielhardman

MALodder (Mon, 05 Nov 2018 16:43:34 GMT):
Does anyone know who the maintainers are for hyperledger/indy-crypto?

esplinr (Tue, 06 Nov 2018 20:03:07 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=rfzh3ptprWb4bqTfG) @danielhardman The team at the Foundation has been taking the lead on the documentation HIPE. The developer who was working on it took a new position, so they are doing a reset. I still like the strategy, but it needs someone to push it forward. I think it is best to let the HIPE sit and discuss it in the next meeting.

esplinr (Tue, 06 Nov 2018 20:04:14 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=N7cGqby2xMEmzJFZy) @MALodder I think the Evernym Indy SDK team have commit rights to that repo: Artem I, Sergey M, and Slava.

tkuhrt (Tue, 06 Nov 2018 21:30:21 GMT):
@esplinr : Can you clarify which Foundation?

tkuhrt (Tue, 06 Nov 2018 21:30:37 GMT):
I want to be sure you are not waiting on me for something

esplinr (Tue, 06 Nov 2018 21:33:04 GMT):
@tkuhrt Sorry, I meant the Sovrin Foundation.

tkuhrt (Tue, 06 Nov 2018 21:33:19 GMT):
Cool

drummondreed (Wed, 07 Nov 2018 04:52:03 GMT):
Has left the channel.

swcurran (Thu, 08 Nov 2018 20:00:59 GMT):
Hey y'all - I just put in a PR for a proposed HIPE to change the HIPE process. Reasons are outlined in the HIPE. PR: https://github.com/hyperledger/indy-hipe/pull/56 Text: https://github.com/hyperledger/indy-hipe/blob/cfe38dbfdfd756ebce3b3d83ca0d8e1fc5753253/text/new-hipe-process/new-hipe-process.md

danielhardman (Fri, 09 Nov 2018 16:59:32 GMT):
@JanL (I think I have the right handle) wanted to socialize a HIPE proposal that was built around the concept of consent receipts, but was having trouble with Rocket Chat--so I said I'd drop a link here. https://github.com/hyperledger/indy-hipe/pull/55

swcurran (Sun, 11 Nov 2018 19:52:05 GMT):
Hey, I think @Sean_Bohan is on a well-deserved vacation. We were going to ask about doing a session on the Indy Call this week about von_anchor - the Credentials Exchange library that the VON team has created. Anyone covering for Sean that can answer? Glad to do it, but need to know so we have time to prep. Thanks!

nage (Mon, 12 Nov 2018 15:00:24 GMT):
The Maintainers calendar appointment has gotten out of sync with the official appointment we have been using. When in doubt the one sent to maintainers emails governs. See you all in one hour (not right now

nage (Mon, 12 Nov 2018 15:26:17 GMT):
)

esplinr (Mon, 12 Nov 2018 16:03:53 GMT):
Has the call started? I'm waiting for the host.

mhailstone (Mon, 12 Nov 2018 16:03:58 GMT):
Sorry, I will not be able to attend in an hour.

TelegramSam (Mon, 12 Nov 2018 16:04:02 GMT):
Me too.

TelegramSam (Mon, 12 Nov 2018 16:04:12 GMT):
no, I think it's now. That was posted an hour ago.

mhailstone (Mon, 12 Nov 2018 16:04:22 GMT):
Just realizing. :)

mhailstone (Mon, 12 Nov 2018 16:04:30 GMT):
Also waiting

swcurran (Mon, 12 Nov 2018 16:09:03 GMT):
We're on another call - will join shortly.

umamaheswarv (Mon, 12 Nov 2018 16:49:37 GMT):
Has joined the channel.

esplinr (Mon, 12 Nov 2018 16:52:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=gXzfinA35eXHHWP5p) @swcurran Is @kdenhartog covering for @Sean_Bohan again?

esplinr (Mon, 12 Nov 2018 17:11:03 GMT):
@swcurran Sean will be hosting this Thursday. It is next week that he is out of town.

esplinr (Mon, 12 Nov 2018 17:11:31 GMT):
It sounds like he has a full agenda this week, but I'll let him work with you directly.

swcurran (Mon, 12 Nov 2018 18:54:56 GMT):
Sounds good. Lots on my plate this week anyway. :-) Another time...

tkuhrt (Mon, 12 Nov 2018 21:39:42 GMT):
@nage : I noticed the Community Calendar and my calendar were out of sync this morning. What time are the maintainer calls? I want to be sure to update the Community Calendar so that it is right.

nage (Mon, 12 Nov 2018 21:53:37 GMT):
we are at 9 Mountain Time (it changes along with daylight savings, which is what I think is missing)

danielhardman (Tue, 13 Nov 2018 05:13:10 GMT):
I have raised a PR with a HIPE proposal about how to request message tracing during A2A communication: https://github.com/hyperledger/indy-hipe/pull/59

danielhardman (Tue, 13 Nov 2018 05:13:10 GMT):
I have proposed a HIPE for conventions around how to enable message tracing, for troubleshooting purposes: https://github.com/hyperledger/indy-hipe/pull/60

esplinr (Tue, 13 Nov 2018 05:21:49 GMT):
Correction from something I said during our meeting this morning: The Hyperledger Identity Working Group is on Wednesday. It does not conflict with our call. I was mis-reading the calendar. Sorry.

danielhardman (Tue, 13 Nov 2018 20:48:37 GMT):
I have raised a PR for defining a file format for agent wire messages and for application plaintext messages. It's quite simple and, I think, not controversial. Would be glad of feedback. https://github.com/hyperledger/indy-hipe/blob/717d8e59c59600969c5ca37dd44fdabf69321dd7/text/agent-file-format/README.md

tkuhrt (Tue, 13 Nov 2018 20:53:27 GMT):
@nage : I have corrected the Maintainers meeting starting with the 26th.

tkuhrt (Tue, 13 Nov 2018 20:54:09 GMT):
Sorry for the confusion yesterday. If only daylight savings time didn't exist like in Arizona. :)

nage (Thu, 15 Nov 2018 13:00:43 GMT):
Thanks!

sergey.minaev (Thu, 15 Nov 2018 15:18:54 GMT):
@nage @esplinr @ashcherbakov regarding topic about history of indy-crypto in new HL crypto library: I've shared fixed indy-crypto history to @MALodder and it can successfully pass DCO check. Actually Mike have done about 98% work. So I just apply few fixes to his variant. @MALodder could you provide any estimation when we will see correct history in https://github.com/hyperledger-labs/crypto-lib ?

MALodder (Thu, 15 Nov 2018 15:19:53 GMT):
probably next week when I get back into the office

swcurran (Thu, 15 Nov 2018 19:37:46 GMT):
How in git do I do a PR for a repo that has an in process PR for indy-hipe? I'd like to do some cleanup on (in this case) Kyle's AMES hipe. - I tried just cloning it, but of course I don't have permission to push to his repo. - I tried to fork it, but I can't because I already have a fork of indy-hipe with in process hipes. - I could comment on all the changes, but they are a number and they relatively minor - typos, missing image, obsolete text. They would gum up the comments with little value, and the process would be a pain for both myself and Kyle. What am I missing?

dbluhm (Thu, 15 Nov 2018 19:55:32 GMT):
The process is basically: - Add their fork as a remote to your local git repository - fetch their changes from that remote - Checkout the branch that they were working on - Make your edits and push the changes to your fork - Make a PR from that branch to their branch through GitHub's interface

swcurran (Thu, 15 Nov 2018 19:59:05 GMT):
Thanks. That's horrible :-) I'll give it a try.

DCSnail (Fri, 16 Nov 2018 10:01:51 GMT):
Has joined the channel.

DCSnail (Fri, 16 Nov 2018 10:02:40 GMT):
Has left the channel.

n3m (Fri, 16 Nov 2018 13:33:43 GMT):
Has left the channel.

TelegramSam (Fri, 16 Nov 2018 14:02:25 GMT):
@swcurran I recommend GitKraken for this level of git foo. It integrates with Github in ways that allow you to easily discover new remotes, see PRs to a repo, and even automatically add remote and checkout the base of a PR.

swcurran (Fri, 16 Nov 2018 14:09:14 GMT):
Thanks. Sorry for the digression on this.

MALodder (Fri, 16 Nov 2018 16:28:34 GMT):
Github works great 98% of the time

MALodder (Fri, 16 Nov 2018 16:29:06 GMT):
I occassionally have issues when it tries to open a git project that it can't find the *.git* folder, but that's it

nage (Mon, 19 Nov 2018 19:10:00 GMT):
If you are working on schemas or overlays please join us in #indy-semantics where we will be continuing conversations on json-ld, updates to anoncreds protocol and other encoding, types and schema related stuff.

sergey.khoroshavin (Tue, 20 Nov 2018 16:38:58 GMT):
Has joined the channel.

sergey.khoroshavin (Tue, 20 Nov 2018 16:42:02 GMT):
Today there was a presentation about metrics in Indy Node project on Performance and Scale WG call, and seems like it went well. There were lots of questions - much more than 10 minutes allocated in agenda, and there was also a follow up conversation in #performance-and-scale-wg channel after call ended. Among things that were brought up besides metrics: 1) there is a Hyperledger Caliper blockchain benchmark framework, it already supports Fabric, Sawtooth and Iroha, and there was interest in adding support for Indy project as well 2) VipinB mentioned that it would be great if Hyperledger projects used chaos testing, and I told him that we already use. This sparked quite a lot of interest and it seems like people here would also like to have presentation on our experience with chaos tests

esplinr (Tue, 20 Nov 2018 16:47:14 GMT):
That's great @sergey.khoroshavin !

esplinr (Tue, 20 Nov 2018 16:48:57 GMT):
@nage We should probably set up a time to present on how we test Indy. If @lynn.bendixsen takes the lead I can ask members of our team to assist.

esplinr (Tue, 20 Nov 2018 16:49:30 GMT):
@sergey.khoroshavin Can you remind me when those calls occur?

sergey.khoroshavin (Tue, 20 Nov 2018 16:52:19 GMT):
@esplinr each Tuesday 17:00 Moscow time (and on Hyperledger Google calendar it's set as 9:00 AM, but I'm not sure which timezone they mean)

esplinr (Tue, 20 Nov 2018 16:55:01 GMT):
Looks like US Eastern.

sergey.khoroshavin (Tue, 20 Nov 2018 16:55:53 GMT):
@esplinr checked some TZ converter, seems like it's 7 AM MDT

sergey.khoroshavin (Tue, 20 Nov 2018 16:56:41 GMT):
Anyways here is link to their calendar: https://calendar.google.com/calendar/embed?mode=AGENDA&src=linuxfoundation.org_nf9u64g9k9rvd9f8vp4vur23b0%40group.calendar.google.com&ctz=EST

rjones (Tue, 20 Nov 2018 20:36:46 GMT):
Has left the channel.

nage (Tue, 20 Nov 2018 21:10:22 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=zf9EftpJkCMsxyvdG) @esplinr @lynn.bendixsen ^^^

lynn.bendixsen (Tue, 20 Nov 2018 21:10:23 GMT):
Has joined the channel.

stanleyc-trustscience (Wed, 21 Nov 2018 21:04:35 GMT):
Has joined the channel.

nage (Mon, 26 Nov 2018 15:33:44 GMT):
Reminder: there is an Indy Maintainer's call in 27 minutes at https://zoom.us/j/615818107

nage (Mon, 26 Nov 2018 17:04:04 GMT):
Coordinating active maintainers of Hyperledger Indy, reviewing indy-hipe documents, and discussing important code maintenance issues.

kdenhartog (Mon, 26 Nov 2018 23:10:39 GMT):
@nage I took a look at the multi-sig that @ashcherbakov mentions on the call today thinking it was crypto related. Turns out it

kdenhartog (Mon, 26 Nov 2018 23:10:39 GMT):
@nage I took a look at the multi-sig that @ashcherbakov mentions on the call today thinking it was crypto related. Turns out it's more consensus related and I don't think we should hold it up until @MALodder get's a chance to look through it. I propose we move it to FCP.

nage (Mon, 26 Nov 2018 23:11:32 GMT):
@MALodder ^^^

MALodder (Mon, 26 Nov 2018 23:12:33 GMT):
Yes I’m planning to look at it tomorrow

kdenhartog (Mon, 26 Nov 2018 23:33:52 GMT):
I propose we move skip FCP for this HIPE https://github.com/hyperledger/indy-hipe/pull/53 and merge. If there's an opposition to that (to adhere to the rules) then lets keep it to a short FCP.

kdenhartog (Mon, 26 Nov 2018 23:33:52 GMT):
I propose we skip FCP for this HIPE https://github.com/hyperledger/indy-hipe/pull/53 and merge directly. If there's an opposition to that (to adhere to the rules) then lets keep it to a short FCP.

kdenhartog (Mon, 26 Nov 2018 23:44:33 GMT):
If someone has an answer to @sergey.minaev question on HIPE #29 https://github.com/hyperledger/indy-hipe/pull/29 then I suggest we merge it. It's currently in FCP and has been for almost 2 months.

kdenhartog (Mon, 26 Nov 2018 23:46:19 GMT):
I propose we close HIPE #18 https://github.com/hyperledger/indy-hipe/pull/18 because the work is moving forward in HIPE #54 https://github.com/hyperledger/indy-hipe/pull/54

ashcherbakov (Tue, 27 Nov 2018 06:11:51 GMT):
@kdenhartog Yes,that's why I was saying that multi-sig PR is not about crypto, so I vote to merge it.

kdenhartog (Tue, 27 Nov 2018 06:13:22 GMT):
Yup, sorry about that. I should have read through it before I commented on it. +1 to merge/FCP it.

MALodder (Tue, 27 Nov 2018 16:19:23 GMT):
@ashcherbakov I approved the HIPE, I vote to merge it

MALodder (Tue, 27 Nov 2018 16:19:32 GMT):
FCP it first

donqui (Fri, 30 Nov 2018 15:33:50 GMT):
Has joined the channel.

danielhardman (Fri, 30 Nov 2018 22:12:05 GMT):
I just merged PR 53, per Kyle's suggestion. My understanding is that simple clarifications to already-merged HIPEs don't need to go through a whole new round of community comment--just need to have maintainer approval. Since I'm not the one who proposed the changes, I figured it was kosher for me to merge them as an independent maintainer.

danielhardman (Fri, 30 Nov 2018 22:17:10 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=AvajDrvWnbmgvagB2) @kdenhartog I left an answer to @sergey.minaev 's question about PR 29, and I propose that we merge this PR. It's been in FCP for a long time. Could I have another maintainer besides me and Kyle confirm that you think that's a good idea, or have any maintainer vote against it proactively? If I hear silence, I will merge on Monday.

danielhardman (Fri, 30 Nov 2018 22:19:04 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=iF9K2n5pu983fYigf) @kdenhartog Based on the +1 from @RyanWest and @dbluhm , I closed PR #18 with a note. We'll carry forward in PR #54.

dbluhm (Fri, 30 Nov 2018 22:23:11 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=nzyjoWaZZSoJxam66) @danielhardman Since libVCX is already merged, I personally don't see much reason not to merge the HIPE. Any future action/changes can come up as a new HIPE or PR against the original.

danielhardman (Fri, 30 Nov 2018 22:24:58 GMT):
@dbluhm Could you very quickly address this comment on your FCP HIPE on message threading? https://github.com/hyperledger/indy-hipe/pull/30/files/613ed302bec4dcc62ed6fab1f3a38ce59a96ca3e#r235490439

danielhardman (Fri, 30 Nov 2018 22:25:19 GMT):
If yes, then I vote that this be merged either today or Monday. Any dissent?

donqui (Fri, 30 Nov 2018 22:27:16 GMT):
quick question, is the PR 29 really something that we consider a HIPE or was it just a consensus driving document. I kind of lost the grasp on what constitutes a HIPE.

kdenhartog (Fri, 30 Nov 2018 22:31:04 GMT):
In my opinion, I find the HIPE process useful for consensus building as well as a way to document things that span across multiple repositories. If it's just documenting something for just one repository, then it's probably better to put it in the repositories doc folder though. In this case, I'd think it'd be easier to just merge it as a HIPE because it was originally for gaining consensus which happened quickly.

dbluhm (Fri, 30 Nov 2018 22:31:28 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=vdmJsmd4wCgnD3gng) @danielhardman Just pushed a commit fixing that. Thanks for bringing that back to my attention

danielhardman (Fri, 30 Nov 2018 22:33:37 GMT):
@donqui I never thought PR 29 was a prototypical use case for HIPEs. However, it did force some good discussion, and it did guarantee a public record--so in that sense, it's been at least somewhat useful. I wouldn't necessarily assume that any future work like that should be managed via HIPE. But maybe. We can debate that if the situation arises again.

danielhardman (Fri, 30 Nov 2018 22:35:00 GMT):
Re. merging PR 29: could I get someone other than me to merge that one? I don't feel like it should be merged by an Evernym employee, even though I haven't had much/anything to do with it. @swcurran @TelegramSam @nage

donqui (Fri, 30 Nov 2018 22:36:06 GMT):
I agree, discussion was valuable and it generated a public trace, but I was unsure if we should just move it to indy in the docs repo and not merge it as a HIPE. Either way I am not opposed to merging it.

donqui (Fri, 30 Nov 2018 22:36:06 GMT):
I agree, discussion was valuable and it generated a public trace, but I was unsure if we should just move it to ind-sdk in the docs repo and not merge it as a HIPE. Either way I am not opposed to merging it.

danielhardman (Fri, 30 Nov 2018 22:36:37 GMT):
Ah. That's an interesting idea--just move the doc somewhere else but not give it a HIPE number. I like that.

danielhardman (Fri, 30 Nov 2018 22:37:16 GMT):
If we do that, then merging should be done by an indy-sdk maintainer.

kdenhartog (Fri, 30 Nov 2018 23:07:26 GMT):
I'd support moving it into the IndySDK repo instead.

kdenhartog (Fri, 30 Nov 2018 23:34:27 GMT):
My intention for the AMES hipe is to replace PR #36 which is the Wire Message HIPE. I've included the relevant information, but if there's more information that I should include can you let me know?

danielhardman (Sat, 01 Dec 2018 05:20:39 GMT):
I have proposed a new HIPE. It's about localized messages. Hopefully it feels straightforward to all: https://github.com/hyperledger/indy-hipe/pull/64

swcurran (Sat, 01 Dec 2018 06:19:13 GMT):
I agree with moving the vcx HIPE (29) to indy-sdk repo.

sergey.minaev (Mon, 03 Dec 2018 09:53:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=nzyjoWaZZSoJxam66) @danielhardman Thank you for providing details in the GH comment thread. But I'm not just asking for technical details (as far as I've known the answer (may be inaccurate one). My main question was (sorry if it was not clear enough): should we include this information in HIPE text explicitly?

sergey.minaev (Mon, 03 Dec 2018 09:53:33 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=nzyjoWaZZSoJxam66) @danielhardman Thank you for providing details in the GH comment thread. But I'm not just asking for technical details (as far as I've known the answer (may be inaccurate one)). My main question was (sorry if it was not clear enough): should we include this information in HIPE text explicitly?

swcurran (Mon, 03 Dec 2018 11:08:27 GMT):
@danielhardman and I have proposed a new HIPE about agent to agent messaging error handling that introduces a new message type - "problem-report" that is useful for some categories of errors. The HIPE also describes some (currently) recommended approaches to many error handling categories. There are also some thoughts about adjustments to other HIPEs (threading, tracing and the "Forward" message type) to improve error handling capabilities. https://github.com/hyperledger/indy-hipe/pull/65

TelegramSam (Mon, 03 Dec 2018 17:00:22 GMT):
I've added comments to both.

MALodder (Mon, 03 Dec 2018 21:49:33 GMT):
I'm happy with (HIPE 43)[https://github.com/hyperledger/indy-hipe/pull/43] and propose it move to FCP

MALodder (Mon, 03 Dec 2018 21:49:33 GMT):
I'm happy with [HIPE 43](https://github.com/hyperledger/indy-hipe/pull/43) and propose it move to FCP

MALodder (Mon, 03 Dec 2018 21:50:29 GMT):
I worked with @kdenhartog on it finish any grips I had with it

TelegramSam (Tue, 04 Dec 2018 13:55:34 GMT):
@MALodder @kdenhartog I still see some function interface inconsistencies in the document. Let's address those quickly and then move to FCP.

MALodder (Tue, 04 Dec 2018 14:05:51 GMT):
@TelegramSam I believe Kyle wants to address those in a separate HIPE

TelegramSam (Tue, 04 Dec 2018 14:10:19 GMT):
If so, we should remove them. There are 3-4 inconsistent mentions currently, one of which I have a comment on.

MALodder (Tue, 04 Dec 2018 14:14:31 GMT):
Let Kyle know. We finished resolving our disagreements yesterday

kdenhartog (Tue, 04 Dec 2018 14:22:50 GMT):
The comments above and below should be describing that they're example interfaces and not set in stone. I assume you're referring to the tmsg stuff that I grabbed directly from the wire message protocol.

TelegramSam (Tue, 04 Dec 2018 14:43:20 GMT):
I can highlight them. I suspect just some simple wording updates will clarify.

TelegramSam (Tue, 04 Dec 2018 14:47:44 GMT):
I added a review with my comments.

kdenhartog (Tue, 04 Dec 2018 14:54:06 GMT):
I read it and will make those changes this morning and message you so we can move to FCP asap.

TelegramSam (Tue, 04 Dec 2018 14:56:53 GMT):
perfect.

mboyd (Tue, 04 Dec 2018 17:05:02 GMT):
Has joined the channel.

kdenhartog (Tue, 04 Dec 2018 20:26:33 GMT):
@TelegramSam updated and changed the title https://github.com/hyperledger/indy-hipe/pull/43

kdenhartog (Tue, 04 Dec 2018 20:58:10 GMT):
I've moved Pack/Unpack to FCP with the blessing of @TelegramSam and @MALodder in alignment with the HIPE now

TelegramSam (Tue, 04 Dec 2018 20:59:22 GMT):
I just submitted an approving review. Now in FCP.

TelegramSam (Tue, 04 Dec 2018 21:09:38 GMT):
Email sent to the indy mailing list.

kdenhartog (Tue, 04 Dec 2018 21:47:18 GMT):
thanks forgot to post it there

mboyd (Tue, 04 Dec 2018 22:05:09 GMT):
I have incorporated the changes proposed thus far to my [Indy Documentation HIPE](https://github.com/hyperledger/indy-hipe/pull/63), and would like to suggest we move this to FCP. The community is unofficially using the prototyped indy.readthedocs.io that is currently being built off of my own forks of the Indy repos. Merging this HIPE will allow us to build the docs through the original repos. Please add any more feedback or improvements that you would like to see.

mboyd (Tue, 04 Dec 2018 22:05:09 GMT):
I have incorporated the changes proposed thus far to my [Indy Documentation HIPE](https://github.com/hyperledger/indy-hipe/pull/63), and would like to suggest we move this to FCP. The community is using the prototyped indy.readthedocs.io that is build off of my own forks of the Indy repos, and merging this HIPE will allow us to build the docs through the original repos. Please add any more feedback or improvements that you would like to see.

kdenhartog (Tue, 04 Dec 2018 22:28:55 GMT):
I second moving Indy Docs HIPE forward to FCP

JonathanGiglio (Wed, 05 Dec 2018 17:53:15 GMT):
Has joined the channel.

nage (Thu, 06 Dec 2018 19:21:32 GMT):
+1

danielhardman (Thu, 06 Dec 2018 20:55:57 GMT):
+1 to FCP for the documentation HIPE. Note, however, that when the HIPE gets merged to the Indy HIPE repo, I want the changes to the existing content of the Indy HIPE repo (e.g., to its template, to the top-level README.md that gives instructions, and so forth) to be in another non-HIPE PR ready to merge. I don't want a merged HIPE saying we're doing documentation one way, and then the Indy HIPE repo doing it a different way.

danielhardman (Thu, 06 Dec 2018 20:55:57 GMT):
+1 to FCP for the documentation HIPE. Note, however, that when the HIPE gets merged to the Indy HIPE repo, I want the changes to the existing content of the Indy HIPE repo (e.g., to its template, to the top-level README.md that gives instructions, and so forth) to be in another non-HIPE PR ready to merge. I don't want a temporary divergence where we have a merged HIPE saying we're doing documentation one way, and then the Indy HIPE repo doing it a different way.

sergey.minaev (Fri, 07 Dec 2018 09:14:33 GMT):
@mboyd please contact with @srottem to cover his use case about .NET documentation

srottem (Fri, 07 Dec 2018 09:14:33 GMT):
Has joined the channel.

mboyd (Mon, 10 Dec 2018 16:06:18 GMT):
Is there a maintainers call today?

MALodder (Mon, 10 Dec 2018 16:06:30 GMT):
yes

mboyd (Mon, 10 Dec 2018 16:26:28 GMT):
Wondering if you guys will discuss the documentation HIPE to see if any maintainers have issue with it? I'm happy to join in the call to go over it if you guys would like.

MALodder (Mon, 10 Dec 2018 16:44:08 GMT):
they accepted it @mboyd

MALodder (Mon, 10 Dec 2018 16:44:13 GMT):
merged

danielhardman (Tue, 11 Dec 2018 00:12:15 GMT):
I propose that we merge PR 61. It's been at FCP for a couple weeks, at least. And I resolved the remaining comment from @swcurran

danielhardman (Tue, 11 Dec 2018 00:12:15 GMT):
I propose that we merge PR 61 (agent file format). It's been at FCP for a couple weeks, at least. And I resolved the remaining comment from @swcurran

danielhardman (Tue, 11 Dec 2018 00:20:32 GMT):
I propose that we move PR 64 (localized messages) to FCP status. It's been maturing for a couple weeks, now, and has had some good comments and tweaks.

kdenhartog (Tue, 11 Dec 2018 20:09:31 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=xcqWfqopgpJ7WZskx) @danielhardman second

TelegramSam (Tue, 11 Dec 2018 20:41:31 GMT):
more comments on localized messages: https://github.com/hyperledger/indy-hipe/pull/64

TelegramSam (Tue, 11 Dec 2018 20:41:40 GMT):
I like the progress we are making.

danielhardman (Wed, 12 Dec 2018 04:32:59 GMT):
I've opened a new HIPE about a protocol for trust pings: https://github.com/hyperledger/indy-hipe/pull/67

danielhardman (Wed, 12 Dec 2018 05:58:25 GMT):
I've opened another new HIPE about timing information in message: https://github.com/hyperledger/indy-hipe/pull/68

danielhardman (Wed, 12 Dec 2018 09:15:54 GMT):
I've opened another new HIPE to provide a reference example of how to document a message family: https://github.com/hyperledger/indy-hipe/pull/69

mboyd (Wed, 12 Dec 2018 20:11:29 GMT):
@MALodder mentioned to me that you guys discussed my Indy Documentation PR in the last maintainers call, and decided to merge it? https://github.com/hyperledger/indy-hipe/pull/63

mboyd (Wed, 12 Dec 2018 20:12:07 GMT):
looks like it hasn't been merged yet. I have a PR waiting for each repo with my changes, but I'd prefer to merge the hipe before I submit the PR

esplinr (Thu, 13 Dec 2018 00:36:25 GMT):
By my count, we have 3 HIPEs that are approved to merge, but no one has actually done it. (cc @TelegramSam ) The documentation HIPE was formally approved in the meeting, and #61 and #64, by virtue of no objections in this channel.

esplinr (Thu, 13 Dec 2018 00:36:25 GMT):
By my count, we have 3 HIPEs that are approved to merge, but no one has actually done it. (cc @TelegramSam ) #63 was formally approved in the meeting, and #61 and #64, by virtue of no objections in this channel.

TelegramSam (Thu, 13 Dec 2018 14:24:23 GMT):
#64 has recent coments (by me) on the HIPE.

TelegramSam (Thu, 13 Dec 2018 14:25:33 GMT):
But #61 and #63 are ready for merging.

TelegramSam (Thu, 13 Dec 2018 14:30:51 GMT):
New HIPEs Merged: 0025 - Indy Docs Framework, and 0026 Agent File Format

esplinr (Thu, 13 Dec 2018 21:42:22 GMT):
Thanks @TelegramSam !

danielhardman (Sat, 15 Dec 2018 09:18:54 GMT):
I would really like to get @dbluhm 's message threading HIPE proposal (https://github.com/hyperledger/indy-hipe/blob/7bd05ee7191d5175dd6606bb5851980076b310aa/text/message-threading/README.md) merged. There is one open comment in it, by me. Could we resolve that and then merge it? It's been at FCP for a long time.

danielhardman (Sat, 15 Dec 2018 11:13:56 GMT):
I have created a HIPE proposal that explains the theory and conventions associated with A2A decorators. Would love public comment: https://github.com/hyperledger/indy-hipe/pull/71

danielhardman (Sun, 16 Dec 2018 00:19:51 GMT):
I created another HIPE. This one discusses how A2A communication could adapt itself to a synchronous protocol (one capable of simple request/response, like HTTP) without losing its essential nature and guarantees. As always, feedback requested: https://github.com/hyperledger/indy-hipe/pull/72

danielhardman (Sun, 16 Dec 2018 00:23:02 GMT):
^^^ @TelegramSam and @nage and @mhailstone and @swcurran , I'm particularly interested in your thoughts on the HIPEs I wrote over the past several days. They've been on my to-do list for a LONG time, and I'm feeling a bit relieved to have the concepts out there. Now I just want to get some discussion on them. :-)

swcurran (Sun, 16 Dec 2018 03:31:53 GMT):
Saving those for the long flights ahead today. Safe travels!

TelegramSam (Mon, 17 Dec 2018 16:40:32 GMT):
@danielhardman comments left, all except for threading, which I'm about to add.

dbluhm (Mon, 17 Dec 2018 20:15:56 GMT):
With the indy documentation framework HIPE merged, I'm not sure #24 (https://github.com/hyperledger/indy-hipe/pull/24) is relevant any longer. Thoughts on closing it?

dbluhm (Mon, 17 Dec 2018 20:17:33 GMT):
And it looks like @mboyd beat me to proposing that idea already: https://github.com/hyperledger/indy-hipe/pull/24#issuecomment-445904556

danielhardman (Tue, 18 Dec 2018 02:01:29 GMT):
I created another HIPE. This one is about feature discovery: how does one agent query another to see what message families it supports? Comments appreciated: https://github.com/hyperledger/indy-hipe/pull/73

esplinr (Tue, 18 Dec 2018 14:14:46 GMT):
@nage I believe you said that you are taking vacation next week. Should we expect next Monday's Indy Maintainer call to be canceled?

esplinr (Tue, 18 Dec 2018 14:15:32 GMT):
I will also be on vacation, but I could find an alternate from my team to attend if anyone expects to be there. @here does anyone think it would be productive to meet next Monday?

jljordan_bcgov (Tue, 18 Dec 2018 14:18:52 GMT):
probably no one will be around .. I'm sure there is stuff to talk about but holidays are important :)

esplinr (Tue, 18 Dec 2018 14:20:14 GMT):
My team has it lucky, since the Eastern Europeans take Christmas a couple of weeks later, we can provide coverage. But I won't ask anyone to come if there won't be a call.

esplinr (Tue, 18 Dec 2018 14:20:14 GMT):
My team has it lucky; since the Eastern Europeans take Christmas a couple of weeks later, we can provide coverage. But I won't ask anyone to come if there won't be a call.

nage (Tue, 18 Dec 2018 14:23:00 GMT):
I think we should skip the next maintainer call. I will remove the calendar appointment, unless someone objects

TelegramSam (Tue, 18 Dec 2018 17:00:12 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=xeyBgE66qBgZhTyrh) @dbluhm done.

allisongs (Thu, 20 Dec 2018 03:56:44 GMT):
Has joined the channel.

danielhardman (Thu, 27 Dec 2018 08:08:25 GMT):
I have proposed a new HIPE about how one party can request, and another party can send, acknowledgment messages (ACKs) to confirm receipt and clarify the status of complex processes. I think it has some good ideas in it, but it also raises several deep issues that I would like to discuss on an upcoming agent call: https://github.com/hyperledger/indy-hipe/pull/77

danielhardman (Thu, 27 Dec 2018 09:09:57 GMT):
I have raised a PR against @dbluhm 's FCP HIPE on message threading. See https://github.com/hyperledger/indy-hipe/pull/30#issuecomment-450109149

danielhardman (Thu, 27 Dec 2018 09:09:57 GMT):
I have raised a PR against @dbluhm 's FCP HIPE on message threading. See https://github.com/hyperledger/indy-hipe/pull/30#issuecomment-450109149. @TelegramSam and @swcurran , you may be particularly interested, since you've been the main commenters on the FCP HIPE up till now.

danielhardman (Sat, 29 Dec 2018 02:04:34 GMT):
Okay, I have significantly improved the HIPE on discovery of features/protocols supported by an agent. New revision here: https://github.com/hyperledger/indy-hipe/blob/ec6f2ac8355b625a987a68cf7a49ef1d3ea22c96/text/feature-discovery/README.md

danielhardman (Sat, 29 Dec 2018 02:06:56 GMT):
I also rewrote the tictactoe HIPE, turning it into a HIPE about how to define protocols, with the Tic Tac Toe protocol as an example: https://github.com/hyperledger/indy-hipe/blob/933d80125b25d02ce796ce71ad7df7173c55d7bc/text/protocols/README.md

TelegramSam (Fri, 04 Jan 2019 14:57:39 GMT):
Interesting PR sorting observation. Using the `sort:updated-desc` query in the PR list shows the newest updated PRs first. An update includes both new code commits (update to the PR) and comments by both author and others.

TelegramSam (Fri, 04 Jan 2019 14:57:46 GMT):
https://github.com/hyperledger/indy-hipe/pulls?page=1&q=is%3Aopen+is%3Apr+sort%3Aupdated-desc

swcurran (Fri, 04 Jan 2019 22:17:38 GMT):
Nice, @TelegramSam!!! Super helpful!

mwherman2000 (Sat, 05 Jan 2019 02:04:52 GMT):
Has joined the channel.

kdenhartog (Mon, 07 Jan 2019 17:18:46 GMT):
https://docs.google.com/document/d/1aniA_cAjNLQWUWDjCOxwlQLDLg_ENbrRMDxTyMUxcOE/edit

kdenhartog (Mon, 07 Jan 2019 17:18:59 GMT):
doc to suggest changes to RFC process through github

kdenhartog (Mon, 07 Jan 2019 17:18:59 GMT):
doc to suggest changes to RFC process using github

jljordan_bcgov (Mon, 07 Jan 2019 17:30:21 GMT):
Thanks for discussion this am folks. I annotated the Google Doc with links to repos for the various components we discussed

danielhardman (Mon, 07 Jan 2019 17:30:39 GMT):
Okay @TelegramSam , PR #30 is ready to merge IMO. I changed `myindex` to `sender_order` and `lrecs` to `received_orders`. I also gave it a HIPE # (0027).

jljordan_bcgov (Mon, 07 Jan 2019 17:32:31 GMT):
I think the most important piece to look at in terms of shared code and reference implementation of a python based enterprise grade library is what is current called "von_anchor" ... repo is here https://github.com/PSPC-SPAC-buyandsell/von_anchor and full documentation is here https://von-anchor.readthedocs.io/en/latest/

jljordan_bcgov (Mon, 07 Jan 2019 17:34:45 GMT):
We can assist in getting a Sovrin Steward Credential Registry up an running ... it is a light lift ... all that is needed is some compute space, a csv of membership data that conforms to the desired schema, and some look and feel polishing ... the rest is off the shelf VON-X and ToB code

jljordan_bcgov (Mon, 07 Jan 2019 17:35:00 GMT):
Similarily with the ledger browser, DID registrar

TelegramSam (Mon, 07 Jan 2019 17:51:59 GMT):
Twho HIPEs moved to FCP: 48 - multiple keys and endpoints for a DID https://github.com/hyperledger/indy-hipe/pull/48, and 50, support multiple key types. https://github.com/hyperledger/indy-hipe/pull/50

TelegramSam (Mon, 07 Jan 2019 17:51:59 GMT):
Two HIPEs moved to FCP: 48 - multiple keys and endpoints for a DID https://github.com/hyperledger/indy-hipe/pull/48, and 50, support multiple key types. https://github.com/hyperledger/indy-hipe/pull/50

TelegramSam (Mon, 07 Jan 2019 18:03:34 GMT):
Accepted HIPE: #27 Message ID and Threading: https://github.com/hyperledger/indy-hipe/tree/master/text/0027-message-id-and-threading

TelegramSam (Mon, 07 Jan 2019 18:03:43 GMT):
(finally, horray!)

swcurran (Mon, 14 Jan 2019 14:40:50 GMT):
Hey Folks, my flights (DC to Victoria) didn't happen yesterday, so I'm travelling today, and will miss the Indy Maintainers call.

richzhao (Mon, 14 Jan 2019 15:32:25 GMT):
Has joined the channel.

TelegramSam (Mon, 14 Jan 2019 16:41:22 GMT):
multi-sig HIPE in FCP: https://github.com/hyperledger/indy-hipe/pull/45

danielhardman (Tue, 15 Jan 2019 20:43:15 GMT):
Can someone merge this PR? It's a PR that's not a HIPE--just a paragraph explaining the concept of "native object" format for messages, so we have an official term for it in discussions. https://github.com/hyperledger/indy-hipe/pull/80

TelegramSam (Wed, 16 Jan 2019 17:53:03 GMT):
@danielhardman I had a question about it on the PR.

TelegramSam (Wed, 16 Jan 2019 17:53:16 GMT):
HIPE moved to FCP: https://github.com/hyperledger/indy-hipe/pull/76/files

TelegramSam (Wed, 16 Jan 2019 17:53:21 GMT):
date and time conventions.

danielhardman (Wed, 16 Jan 2019 17:57:50 GMT):
@TelegramSam I left an answer to your question on PR #80.

danielhardman (Wed, 16 Jan 2019 18:02:27 GMT):
I also tweaked the verbiage slightly to make it clearer and simpler.

TelegramSam (Wed, 16 Jan 2019 18:05:10 GMT):
Thanks for the explanation. I think the term updates help clarify as well.

TelegramSam (Wed, 16 Jan 2019 18:05:42 GMT):
I consider these to be an Update HIPE request, so we'll still need to give it an FCP I think.

kdenhartog (Wed, 16 Jan 2019 18:21:29 GMT):
I think it can move to FCP right away given it's very short? @channel Motion to FCP PR #80

TelegramSam (Wed, 16 Jan 2019 19:13:17 GMT):
FCP for HIPE Update PR 80 https://github.com/hyperledger/indy-hipe/pull/80

kdenhartog (Wed, 16 Jan 2019 20:05:40 GMT):
cool thanks

kdenhartog (Tue, 22 Jan 2019 01:55:21 GMT):
Some minor changes were made to the format to make for a better implementation which is now ready for @sergey.minaev to merge. Could I get one last check of the Wire Message Format HIPE from @TelegramSam @danielhardman @swcurran @MALodder @tplooker or anyone else who's helped to review this work. At this point, I'm declaring the HIPE done, and I'll work with @sergey.minaev to get this PR merged this week.

tplooker (Tue, 22 Jan 2019 01:55:21 GMT):
Has joined the channel.

kdenhartog (Tue, 22 Jan 2019 02:02:23 GMT):
Also, I've added links to reference implementations which are place holders right now. Once, the PR is merged, then I'll be adding a static link to a specific commit.

tomislav (Tue, 22 Jan 2019 03:01:50 GMT):
Has joined the channel.

kdenhartog (Tue, 22 Jan 2019 23:36:05 GMT):
@TelegramSam what's your thoughts on @dbluhm request for receiver_key returned from `unpack_message()`? I think it would be a valuable return value.

TelegramSam (Tue, 22 Jan 2019 23:36:35 GMT):
yep.

kdenhartog (Tue, 22 Jan 2019 23:37:52 GMT):
sounds good, I'll get that in. Currently trying to fiddle around with the python wrapper. If you have some time I could use some help debugging it.

kdenhartog (Tue, 22 Jan 2019 23:37:52 GMT):
@TelegramSam sounds good, I'll get that in. Currently trying to fiddle around with the python wrapper. If you have some time I could use some help debugging it.

TelegramSam (Tue, 22 Jan 2019 23:38:26 GMT):
I'll have time tomorrow morning. Drop me a note to point me in the right direction.

kdenhartog (Tue, 22 Jan 2019 23:39:55 GMT):
sounds good, it has to do with encoding the python data. For some reason, I'm getting a tuple returned rather than bytes even though the wrapper is casting to bytes in the call back.

kdenhartog (Tue, 22 Jan 2019 23:41:19 GMT):
https://github.com/kdenhartog/indy-sdk/blob/a86ce6934c2d66998b4e38d1e6615e962f74827f/wrappers/python/indy/crypto.py#L418

andkononykhin (Wed, 23 Jan 2019 14:03:11 GMT):
@rjones Hello Ry. Could you help with https://rt.linuxfoundation.org/SelfService/Display.html?id=66038? It's about adding webhooks for indy repos to push notification to new Sovrin Foundation build server: I haven't seen any updates for the tasks for a quite long time. Thank you

rjones (Wed, 23 Jan 2019 14:03:11 GMT):
Has joined the channel.

rjones (Wed, 23 Jan 2019 15:41:42 GMT):
@tijohnson @jwagantall ^^^^^

jwagantall (Wed, 23 Jan 2019 15:41:42 GMT):
Has joined the channel.

jwagantall (Wed, 23 Jan 2019 17:05:16 GMT):
thanks Ry.. @tijohnson seems like he is working on it

danielhardman (Wed, 23 Jan 2019 17:16:02 GMT):
I am wanting to know about our process for updating a HIPE. I am reviewing some stuff this morning and realizing that there are minor typos, misspellings, broken URLs, and various things in a number of HIPEs we've already merged. In many cases, we ought to add cross links so people can move from one HIPE to another. It doesn't seem desirable to go through a HIPE approval process or a FCP for these types of changes. So I propose that if we find minutiae like this, we simply mark the PR as "non-HIPE", and merge as soon as one other maintainer approves it. Does this feel reasonable?

swcurran (Wed, 23 Jan 2019 17:32:42 GMT):
Yes - let's make improvements easy. Self-policing if the issue is signficant.

danielhardman (Fri, 25 Jan 2019 18:56:43 GMT):
I've proposed a new HIPE about JSON-LD compatibility: https://github.com/hyperledger/indy-hipe/pull/83

danielhardman (Fri, 25 Jan 2019 23:11:44 GMT):
Now merging AMES HIPE, which had impl merged earlier today.

danielhardman (Sat, 26 Jan 2019 15:46:07 GMT):
I have updated the decorators HIPE to use ~ and to stop calling @id and @type "decorators".

danielhardman (Sat, 26 Jan 2019 15:53:52 GMT):
I have updated the ACK HIPE to use ~ for decorators.

danielhardman (Sat, 26 Jan 2019 16:06:36 GMT):
I have raised a minor HIPE update PR to adjust message threading so it is ~thread instead of @thread. Per our earlier conversations, this doesn't need to go through an FCP; it just needs one other maintainer to review and approve, then merge. https://github.com/hyperledger/indy-hipe/pull/84

danielhardman (Sat, 26 Jan 2019 16:09:23 GMT):
I have updated the attachments HIPE to use ~ for decorators.

danielhardman (Sat, 26 Jan 2019 16:21:47 GMT):
I have updated the message tracing HIPE to use ~ for decorators.

danielhardman (Sat, 26 Jan 2019 16:23:59 GMT):
I have updated the message timing HIPE to use ~ for decorators.

danielhardman (Sat, 26 Jan 2019 16:31:32 GMT):
I have updated the trust ping HIPE to use ~ for decorators.

esplinr (Mon, 28 Jan 2019 13:39:58 GMT):
Thank you Daniel for doing the work and keeping us updated.

esplinr (Mon, 28 Jan 2019 13:43:37 GMT):
It doesn't look like anyone added anything to the agenda for the Indy Maintainers call today, so I expect we'll spend the day doing HIPE work. It should be a good opportunity to dig in.

esplinr (Mon, 28 Jan 2019 13:43:47 GMT):
I have a conflict, so I'll only be able to attend the first few minutes of the call.

esplinr (Mon, 28 Jan 2019 13:44:13 GMT):
But I'm not needed for most of the HIPE discussions.

TelegramSam (Mon, 28 Jan 2019 14:13:45 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=4wiXzSbtTfAJGiW84) @danielhardman Approved and merged.

nage (Mon, 28 Jan 2019 16:00:39 GMT):
https://docs.google.com/document/d/1d_SnxinX54Sx-0TwRTnSJK6p_ZN27ZvoI3ytha1QS28/edit#

nage (Mon, 28 Jan 2019 16:10:07 GMT):
Agent Connect-a-thon https://docs.google.com/document/d/1dfGj5yjpSHzRF6UVPv7Ld1PTFme3fsXEwpLs0_e6NGA/edit#heading=h.ssygez1ks54i

danielhardman (Mon, 28 Jan 2019 16:58:33 GMT):
@esplinr and @TelegramSam and @nage : Is there any reason why we can't merge the libvcx HIPE that's been at FCP forever?

TelegramSam (Mon, 28 Jan 2019 17:02:04 GMT):
@danielhardman We need to have a discussion about how libraries are expected to interact with the SDK. Are they add-ons, or do we allow full overlay of the sdk? This HIPE touches those issues, and relates to current thing we need to resolve as a community surrounding higher level libraries.

nage (Mon, 28 Jan 2019 17:02:05 GMT):
Will it blend? that is the question. I think the only thing holding that HIPE up was that VCX had been broken without an agency. But looking at the comments that isn't in there, so now I'm not sure.

nage (Mon, 28 Jan 2019 17:02:37 GMT):
I defer to @TelegramSam

danielhardman (Mon, 28 Jan 2019 17:37:41 GMT):
@TelegramSam I have some questions/feedback on the connection protocol. Would be faster to discuss interactively. Are you free now or sometime today?

TelegramSam (Mon, 28 Jan 2019 17:37:48 GMT):
free now.

TelegramSam (Mon, 28 Jan 2019 17:38:16 GMT):
https://zoom.us/j/228642016

TelegramSam (Mon, 28 Jan 2019 17:39:28 GMT):
@danielhardman ^

swcurran (Mon, 28 Jan 2019 21:19:58 GMT):
FYI @esplinr - we've been running indy-sdk with Python 3.6 for quite awhile. It's only indy-node that requires python 3.5. I believe we have also been using Python 3.7 for some work and it too was fine, but we didn't want to add any extra features.

swcurran (Mon, 28 Jan 2019 21:21:11 GMT):
It might be an interesting (and quick) experiment to see if the indy-sdk CI/CD pipeline can be just changed to Python 3.6 and see if it works. May take a lot of other tweaks, of course, but I'm guessing it would be fine.

swcurran (Mon, 28 Jan 2019 21:23:39 GMT):
As per developer-friendly, beyond the async-io issues (that are crucial for agent), I got this gem: > Also, breakpoint() is invaluable for non-GUI environments. Before I had to back-date to 3.5 again, I was nailing hard bugs four, five times as fast as I've accepted now without it.

jljordan_bcgov (Tue, 29 Jan 2019 22:57:00 GMT):
So .. I was noodling a bit on the weekend about use cases and I think that I would like to propose an approach for indy "use cases" Basically ... each use case would have standard sections Issuer - describe entities, process Holder - describe entities, process Verifier - describe entities, process Credentials - describe credentials (potentially at schema level) Or something along those lines. Each of these short sections would identity the entities, processes etc

jljordan_bcgov (Tue, 29 Jan 2019 22:57:00 GMT):
So .. I was noodling a bit on the weekend about use cases and I think that I would like to propose an approach for indy "use cases" Basically ... each use case would have standard sections # Issuer - describe entities, process # Holder - describe entities, process # Verifier - describe entities, process # Credentials - describe credentials (potentially at schema level) # Desired Outcome of Interaction Or something along those lines. Each of these short sections would identity the entities, processes etc

jljordan_bcgov (Tue, 29 Jan 2019 22:57:00 GMT):
So .. I was noodling a bit on the weekend about use cases and I think that I would like to propose an approach for indy "use cases" Basically ... each use case would have standard sections 1 Issuer - describe entities, process 2 Holder - describe entities, process 3 Verifier - describe entities, process 4 Credentials - describe credentials (potentially at schema level) 5 Desired Outcome of Interaction Or something along those lines. Each of these short sections would identity the entities, processes etc

jljordan_bcgov (Tue, 29 Jan 2019 22:57:00 GMT):
So .. I was noodling a bit on the weekend about use cases and I think that I would like to propose an approach for indy "use cases" Basically ... each use case would have standard sections 1 Issuer - describe entities, process 2 Holder - describe entities, process 3 Verifier - describe entities, process 4 Credentials - describe credentials (potentially at schema level) 5 Desired Outcome of Interaction Or something along those lines. Each of these short sections would identity the entities, processes etc, followed or perhaps proceeded by the overall context and desired outcome of the interaction the parties are undertaking

jljordan_bcgov (Tue, 29 Jan 2019 23:02:31 GMT):
Short Example Evidence Locker for Mines Inspection Reports 1. Issuers - Mines Service - Mines Inspector 2. Holder - "Evidence Locker" (a private credential registry) 3. Verifier - Court Officer 4. Credentials - Mine Project (Foundational Credential) that identifies the mine subject to inspection - Evidence Tag (Credential issued by Mine Inspector) contains metadata on inspection report, digital fingerprint of digitial evidence gathered 5. Ability to demonstrate integrity of a mine inspection at a future time in the court of law via a proof offered by the "Evidence Locker" to the court verifier

kdenhartog (Tue, 29 Jan 2019 23:26:57 GMT):
I like this format @jljordan_bcgov I think it will clarify how every use case comes back to credential exchange

esplinr (Wed, 30 Jan 2019 05:55:14 GMT):
Thanks @swcurran. Our focus on the SDK through February is Agent to Agent communication standards. Then we'll look at updating python.

esplinr (Wed, 30 Jan 2019 05:55:47 GMT):
While we are at it, we should probably go all the way to 3.7. But then we need to set a standard where people aren't quick to adopt the latest language features and prevent running the wrappers on older releases.

cam-parra (Wed, 30 Jan 2019 11:42:55 GMT):
But @esplinr if BC wants to bring in their own pipeline using 3.7 we could accept their changes. The reason why we haven't merged 3.6 and 3.7 PRs by bc is because of our pipelines not being able to test their changes

rjones (Wed, 30 Jan 2019 16:40:54 GMT):
Has left the channel.

danielhardman (Wed, 30 Jan 2019 20:52:27 GMT):
I would like to merge PR #74 ( @mboyd 's proposal to enable ReadTheDocs support in Indy-HIPE). Anybody opposed? This is not a substantive change, but rather a format change--so I'm imagining it doesn't need to go through the HIPE review process.

kdenhartog (Wed, 30 Jan 2019 21:39:48 GMT):
@esplinr or @sergey.minaev The question for release of 1.8 was brought up in the Agent call today. Is that estimated to be released this sprint?

danielhardman (Wed, 30 Jan 2019 23:22:41 GMT):
All: I have raised a new PR with the mediator and relay stuff: https://github.com/hyperledger/indy-hipe/pull/85

danielhardman (Thu, 31 Jan 2019 00:20:00 GMT):
I'm merging PR #74, as mentioned above and approved by Kyle.

danielhardman (Thu, 31 Jan 2019 00:21:10 GMT):
@mboyd #74 has been merged. Please send us a link so we can all see how cool indy-hipe looks on ReadTheDocs.

esplinr (Thu, 31 Jan 2019 12:23:46 GMT):
@kdenhartog The SDK 1.8 release candidate should enter testing today.

esplinr (Thu, 31 Jan 2019 12:25:08 GMT):
@esplinr Backwards compatible changes are fine, but I worry about bringing in language changes that force all users of the python modules to upgrade their language runtime. We need to be very deliberate about when we choose to adopt language features that require a new version of Python.

esplinr (Thu, 31 Jan 2019 12:25:08 GMT):
@cam-parra Backwards compatible changes are fine, but I worry about bringing in language changes that force all users of the python modules to upgrade their language runtime. We need to be very deliberate about when we choose to adopt language features that require a new version of Python.

danielhardman (Thu, 31 Jan 2019 16:23:02 GMT):
The HIPE on date-time conventions has been at FCP status for 15 days without further comment. It's not very controversial. Could I get another maintainer to merge it? I don't think it's good form for me to do it, sincce it's my PR.

danielhardman (Thu, 31 Jan 2019 16:23:05 GMT):
https://github.com/hyperledger/indy-hipe/pull/76

danielhardman (Thu, 31 Jan 2019 16:25:21 GMT):
The HIPE about multi-sig-actions has been at FCP for a while, with largely positive comments. Last couple were approvals to merge. There were earlier comments in the stream from @swcurran and @devin-fisher. Have they been resolved? Can we merge this?

danielhardman (Thu, 31 Jan 2019 16:25:24 GMT):
https://github.com/hyperledger/indy-hipe/pull/45

danielhardman (Thu, 31 Jan 2019 16:26:39 GMT):
@ashcherbakov , are your concerns with this PR resolved so we can merge it? https://github.com/hyperledger/indy-hipe/pull/50

danielhardman (Thu, 31 Jan 2019 21:17:38 GMT):
I have raised a new PR with an explainer around agents--what they are, how they work, how they can be categorized, how to write one, etc. This might be a useful resource for new community members who want an introduction to the concept. Something like it has been needed for a while. I suspect other community members can improve it in various ways, so please weigh in. https://github.com/hyperledger/indy-hipe/pull/86

ashcherbakov (Fri, 01 Feb 2019 06:47:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=iTCzPQ9Z5SuxfLPYS) @danielhardman I'm fine with the PR

danielhardman (Fri, 01 Feb 2019 17:07:56 GMT):
@esplinr: I can't use the @ here notation because I'm not an owner of the channel, but I'd like to ask a question to everyone here. Can you please mention @ here in connection with the following? I would like to get some guidance about proper hyperlinking in docs. Some questions I have include: - Should we hyperlink to README.md files? How does that fit with recent work by @mboyd to integrate with ReadTheDocs--will we be setting ourselves up for broken links? - Should we use relative links or absolute links? - Under what circumstances should we use permalinks instead of temporary ones? - When we move docs, how are we going to adjust all the inbound links that we've broken? - How can we update links that used to point to PRs for pending HIPEs, so that they come to point to the HIPEs in their merged locations? What is a good forum to discuss such questions? Here on rocketchat? Special meeting? Next community call?

tomislav (Fri, 01 Feb 2019 23:00:12 GMT):
@danielhardman RST supports `ref` syntax for cross-referencing to other files without using absolute links. - http://www.sphinx-doc.org/en/stable/usage/restructuredtext/roles.html#cross-referencing-arbitrary-locations For markdown, there's sphinx dependency `recommonmark` that can be added to the conf.py for readthedocs. - https://github.com/rtfd/readthedocs.org/issues/4412

tomislav (Fri, 01 Feb 2019 23:01:01 GMT):
Both should link correctly browsing using readthedocs or github. Github's RST processor is not most updated, but it's pretty good

danielhardman (Fri, 01 Feb 2019 23:03:54 GMT):
Yes, but if I link to a .md file, and my link is valid in github, is my link translated to a .html in readthedocs, or does it point back to the .md on github? Does the answer change depending on whether I use relative links or absolute ones? Can I use RST `ref` when I'm writing MD?

danielhardman (Fri, 01 Feb 2019 23:05:21 GMT):
(Part of why I am asking is because I am seeing RST-isms in some docs on SDK, and they make the markdown look terrible...)

tomislav (Fri, 01 Feb 2019 23:06:01 GMT):
If you're linking from one .md to another .md, using recommonmark and *relative link* it will get translated properly on readthedocs. Cant use rst and md in same document, but there's a plugin to mix documents in same repo.

tomislav (Fri, 01 Feb 2019 23:07:10 GMT):
Personally, I prefer RST for technical documentation, it's little more complex to write, but it's more flexible

mcemkilinc (Sun, 03 Feb 2019 12:01:40 GMT):
Has joined the channel.

esplinr (Fri, 08 Feb 2019 23:38:25 GMT):
@here please see Daniel's question about links in our HIPEs and documentation

esplinr (Fri, 08 Feb 2019 23:38:36 GMT):
(Sorry Daniel, I got behind while traveling and am only now catching up.)

esplinr (Fri, 08 Feb 2019 23:40:55 GMT):
(It's odd that non-owners can't use the @ here notation.)

kdenhartog (Sat, 09 Feb 2019 00:27:41 GMT):
@esplinr it's how Hyperledger has it setup I believe. I've talked with @tkuhrt about this. only `admin` and `owner` roles have this capability I believe she said. We could give that capability to the people who are making long term commitments to Indy in this channel.

tkuhrt (Sat, 09 Feb 2019 00:59:26 GMT):
Let me know who should have moderator access.

tkuhrt (Sat, 09 Feb 2019 01:01:33 GMT):
Maybe point me at the list of Indy maintainers

esplinr (Sat, 09 Feb 2019 23:45:32 GMT):
Sorry all, but the Evernym team has a conflict for the maintainers meeting next Monday. I'll be available via chat, but can't join the call.

TelegramSam (Mon, 11 Feb 2019 16:29:49 GMT):
Newly Accepted HIPE: https://github.com/hyperledger/indy-hipe/tree/master/text/0029-date-time-conventions

swcurran (Tue, 12 Feb 2019 22:12:05 GMT):
@esplinr, @nage, @danielhardman, @TelegramSam, @jljordan_bcgov and Sovrin team - a question for you. We (BC Gov) have a Ledger Browser that we have used against several indy-node network instances. The Ledger Browser starts up and sequentially reads the ledger transactions from 1 in chunks (e.g. 500 per chunk) until it hits the end, and then queries the ledger every n minutes (2 is usual) to get new transactions as they are added. The transactions are stored in a simple database (SQLFile maybe? - not really crucial) and the ledger browser supports filtering by type, name and page. We add more functionality from time to time. We ran this on the Sovrin Testnet and it worked fine - 50000 transactions in about a day. Example: http://dflow.bcovrin.vonx.io (front page) and http://dflow.bcovrin.vonx.io/browse/domain (ledger browser/filter). We'd like to use this to enable browsing the Sovrin Mainnet by using our own Mainnet DID to do the reading. Any concerns with that?

jljordan_bcgov (Tue, 12 Feb 2019 22:12:36 GMT):
None from me

jljordan_bcgov (Tue, 12 Feb 2019 22:12:51 GMT):
We can add a Sovrin logo to the header if that is desired

jljordan_bcgov (Tue, 12 Feb 2019 22:13:01 GMT):
powered by BC Gov at the bottom :)

jljordan_bcgov (Tue, 12 Feb 2019 22:13:38 GMT):
I assume we would not have the "Write your DID" part enabled :)

danielhardman (Tue, 12 Feb 2019 22:13:49 GMT):
I think it's awesome. A new tool in indy-sdk/util?

jljordan_bcgov (Tue, 12 Feb 2019 22:13:52 GMT):
and I don't think we can do that anywats

jljordan_bcgov (Tue, 12 Feb 2019 22:13:52 GMT):
and I don't think we can do that anyways

jljordan_bcgov (Tue, 12 Feb 2019 22:14:03 GMT):
happy to contribute of course

danielhardman (Tue, 12 Feb 2019 22:19:02 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=aaVeM5MWE9Ld9KwRNJ) @tkuhrt Each Indy repo has (or should have) a MAINTAINERS.md file that tracks that. For example, https://github.com/hyperledger/indy-hipe/blob/master/MAINTAINERS.md or https://github.com/hyperledger/indy-sdk/blob/master/MAINTAINERS.md. I would imagine that each of these maintainers should have the ability to reach out to all the other maintainers in this channel (which is, I gather, the privilege of moderator access). @TelegramSam You should be named in the maintainers file for indy-hipe. Submit a PR and I'll merge it.

TelegramSam (Tue, 12 Feb 2019 23:00:07 GMT):
@danielhardman https://github.com/hyperledger/indy-hipe/pull/91

danielhardman (Tue, 12 Feb 2019 23:52:33 GMT):
merged

esplinr (Wed, 13 Feb 2019 04:49:41 GMT):
@swcurran @jljordan_bcgov I was discussing that tool with Ian earlier. It's a great tool and I'm excited that you built it. I would love to see it in Indy proper, and I would love for there to be a public instance hosted somewhere that is pointed at the Sovrin Main Net. I have no concerns. To the contrary, I think you need an applause.

swcurran (Wed, 13 Feb 2019 05:10:36 GMT):
Sounds good. Not worried about where the code is (bcgov) for now. Just want it on MainNet. We'll push that out.

zoltan.lux (Wed, 13 Feb 2019 12:36:56 GMT):
Has joined the channel.

nage (Wed, 13 Feb 2019 15:05:01 GMT):
Lets also figure out how to get it in an indy or sovrin-foundation repo, @lynn.bendixsen would be interested in setting up an instance of it at sovrin.org (or perhaps pointing to yours)

swcurran (Wed, 13 Feb 2019 15:55:55 GMT):
@nage - we'd be happy to have it in the repo, but right now, we just want to get it deployed. We'll do that now and if Sovrin wants to take over hosting, we're good with that too. If it is to go into a hyperledger repo, let us know where.

nage (Wed, 13 Feb 2019 16:05:54 GMT):
:+1: I will try to hunt down a "maintainer sponsor" to get it into the repo, meanwhile, lets push forward and get it up and running

nage (Wed, 13 Feb 2019 16:13:05 GMT):
(if you want to help make it happen, just say so here)

cam-parra (Thu, 14 Feb 2019 14:18:17 GMT):
@swcurran @nage what repos are you looking to get that sponsor?

cam-parra (Thu, 14 Feb 2019 14:18:17 GMT):
@swcurran @nage what repos are you looking to get that sponsor? I am connected with most of the code maintainers and can help you with this

nage (Thu, 14 Feb 2019 14:23:59 GMT):
@cam-parra and @ashcherbakov are the first two to contact 😇

cam-parra (Thu, 14 Feb 2019 14:24:35 GMT):
Please send the link to the PR and I will take a look

ashcherbakov (Thu, 14 Feb 2019 14:40:06 GMT):
@swcurran It would be great to have it in Indy-Node (I think Indy-Node is the best place, but Indy Plenum is also an option). It would be great to have more information about the design and technical details of this Browser, for example, what Indy Node's API it uses. Do you have any doc about this? Feel free to send a PR with such a design into https://github.com/hyperledger/indy-node/tree/master/design

swcurran (Thu, 14 Feb 2019 16:02:16 GMT):
Sounds good. Our immediate focus is on deploying it. It's a pretty small app, so we'll get a design done.

kdenhartog (Fri, 15 Feb 2019 22:15:31 GMT):
@PatrikStas has also built a simlar ledger explorer at https://indyscan.io

PatrikStas (Fri, 15 Feb 2019 22:15:31 GMT):
Has joined the channel.

swcurran (Fri, 15 Feb 2019 22:30:54 GMT):
Yup - we're going to back off our plan to post another. Happy to see there is one out there.

kdenhartog (Mon, 18 Feb 2019 23:48:35 GMT):
Does anyone know the limitations of labels on PRs? I'm thinking if people making PRs can flag a PR with the labels, it will make it easier for maintainers in the HIPEs repo to process PRs faster.

kdenhartog (Tue, 19 Feb 2019 05:19:49 GMT):
Added a process change HIPE PR. It can be found here. https://github.com/hyperledger/indy-hipe/pull/93

TelegramSam (Mon, 25 Feb 2019 14:15:41 GMT):
@kdenhartog I don't think there is a tight limit on labels. Tagging PRs will make it much easier to accept non-standards changes.

kdenhartog (Mon, 25 Feb 2019 16:41:32 GMT):
That's the property I was looking for. I believe Bryant also pointed out that HIPEs don't allow gh issues right now, so we'd likely need to find a better asynchronous channel for discussion in the discussion section.

ycarmel (Tue, 26 Feb 2019 13:26:41 GMT):
Has joined the channel.

danielhardman (Wed, 27 Feb 2019 19:23:43 GMT):
@TelegramSam I have raised a PR against the indy-agent repo, beginning a list of known implementations with links to find out more about them. https://github.com/hyperledger/indy-agent/pull/88

danielhardman (Wed, 27 Feb 2019 19:23:43 GMT):
@TelegramSam I have raised a PR against the indy-agent repo, beginning a list of known agent implementations with links to find out more about them. https://github.com/hyperledger/indy-agent/pull/88

danielhardman (Wed, 27 Feb 2019 19:24:05 GMT):
Can I have 2 minutes to show people on the indy agent call, so I can encourage them to improve the info that's there?

TelegramSam (Wed, 27 Feb 2019 19:24:42 GMT):
Yes.

danielhardman (Wed, 27 Feb 2019 19:25:45 GMT):
^^ @swcurran This is the "implementers" file you suggested, more or less. See what you think. (And help improve the BCGov data. Should we have a separate line for VON?)

TelegramSam (Wed, 27 Feb 2019 19:26:07 GMT):
approved PR.

danielhardman (Wed, 27 Feb 2019 19:26:18 GMT):
Thanks!

MattRaffel (Thu, 28 Feb 2019 14:27:22 GMT):
Has joined the channel.

TelegramSam (Thu, 28 Feb 2019 15:30:53 GMT):
BasicMessage HIPE moved to FCP: https://github.com/hyperledger/indy-hipe/pull/81

TelegramSam (Thu, 28 Feb 2019 15:31:57 GMT):
Trust Ping protocol moved to FCP: https://github.com/hyperledger/indy-hipe/pull/67

jljordan_bcgov (Mon, 04 Mar 2019 14:52:07 GMT):
Is there a call today? My Hyperledger calendar subscription says there is but I think we had one last week.

MALodder (Mon, 04 Mar 2019 14:57:09 GMT):
I'm not planning on any calls today

lorenz.loesch (Mon, 04 Mar 2019 15:36:19 GMT):
Has joined the channel.

nage (Tue, 05 Mar 2019 08:33:18 GMT):
Looks like the calendar appointments on the HL side got off somehow. With @tkuhrt having moved on from her Community Architect role at Hyperledger, I'm not sure who the right contact will be to get it updated

nage (Tue, 05 Mar 2019 08:34:09 GMT):
As we prep for the Hyperledger Bootcamp, we have a session titled "Good First Bugs", are there any easy first issues folks here would like to see us tackle?

nage (Tue, 05 Mar 2019 08:34:57 GMT):
@here label any issues that are good for newcommers to help with in JIRA with the tag

nage (Tue, 05 Mar 2019 08:34:57 GMT):
@here label any issues that are good for newcommers to help with in JIRA with the "good-first-issue"

kdenhartog (Tue, 05 Mar 2019 10:12:47 GMT):
@Silona or @rjones may be able to help with the calendar update

Silona (Tue, 05 Mar 2019 10:12:48 GMT):
Has joined the channel.

rjones (Tue, 05 Mar 2019 10:12:48 GMT):
Has joined the channel.

rjones (Tue, 05 Mar 2019 10:13:02 GMT):
Please send email to community-architects@hyperledger.org

rjones (Tue, 05 Mar 2019 10:13:24 GMT):
@nage @kdenhartog

kdenhartog (Tue, 05 Mar 2019 10:13:50 GMT):
Thanks! I'll send it out

danielhardman (Tue, 05 Mar 2019 18:19:56 GMT):
"

danielhardman (Tue, 05 Mar 2019 18:20:46 GMT):
I raised a new PR against indy-hipe. This is not for a HIPE; it's for a tweak to something already merged. I want to update the "Agent File Format" HIPE to use the verbiage "DIDComm" instead of "A2A". I am also proposing that we change the file extensions from *.ap and *.aw to *.dp and *.dw, and that we change the MIME type from "application/ssi-agent-wire" to "application/didcomm-wire", etc. https://github.com/hyperledger/indy-hipe/pull/99

esplinr (Tue, 05 Mar 2019 19:54:12 GMT):
@nage We have been labeling them with "help-wanted" or "HelpWanted" (both are being used).

esplinr (Tue, 05 Mar 2019 19:55:31 GMT):
DIDComm has a nice ring to it.

tplooker (Tue, 05 Mar 2019 21:16:29 GMT):
I like the ring that DIDComm has but it feels to qualifying, i.e are we building a messaging protocol or a communication protocol? I also dont want to give the impression that this is the only way did

tplooker (Tue, 05 Mar 2019 21:16:29 GMT):
I like the ring that DIDComm has but it feels too qualifying, i.e are we building a messaging protocol or a communication protocol? I also dont want to give the impression that this is the only way dids can communicate

swcurran (Tue, 05 Mar 2019 21:37:35 GMT):
I like DIDMsg better (or DIDMessaging)

tplooker (Tue, 05 Mar 2019 21:37:57 GMT):
That would be my preference too

danielhardman (Wed, 06 Mar 2019 01:01:51 GMT):
We are building a communication protocol. Messaging is what it does underneath, but business process coordination via protocols (e.g., issuing credentials, negotiating payment, logging someone in) is what it does on top. I don't think it's just about messaging. Why was this concern not brought up over the past 9 months when we've been calling it "agent-to-agent communication"?

danielhardman (Wed, 06 Mar 2019 01:02:34 GMT):
We did discuss this name at the agent connect-a-thon, so I was only updating the HIPE based on what I thought the group consensus had decreed a couple weeks ago.

swcurran (Wed, 06 Mar 2019 02:01:36 GMT):
I was calling it Agent-to-Agent Messaging :-). But it's not a big deal to me...

danielhardman (Wed, 06 Mar 2019 19:18:21 GMT):
I guess if I step back a bit, I don't care that much in the abstract. I'm just not excited about the prospect of updating HIPEs a second time with a different name (I've already updated about 4 or 5 HIPEs), and I don't know what to call a message if we call the general technique "DID Messaging" -- is it a "DID Messaging message"?

mwherman2000 (Wed, 06 Mar 2019 22:09:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=gjiWkTw8rSB62Gd8m) @tplooker DID Orchestration

mwherman2000 (Wed, 06 Mar 2019 22:09:24 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=gjiWkTw8rSB62Gd8m) @tplooker DID Orchestration CC: @danielhardman

mwherman2000 (Wed, 06 Mar 2019 22:23:12 GMT):
...or DID Choreography: "Dancers dance following a global scenario without a single point of control" Reference: https://en.wikipedia.org/wiki/Service_choreography

mwherman2000 (Wed, 06 Mar 2019 22:23:12 GMT):
...or DID Choreography: "Dancers dance following a global scenario without a single point of control" Read the first couple paragraphs of https://en.wikipedia.org/wiki/Service_choreography

mwherman2000 (Wed, 06 Mar 2019 22:23:12 GMT):
@tplooker @danielhardman DID Choreography: "Dancers dance following a global scenario without a single point of control" Read the first couple paragraphs of https://en.wikipedia.org/wiki/Service_choreography

mwherman2000 (Wed, 06 Mar 2019 22:23:12 GMT):
@tplooker @danielhardman DID Choreography: "Dancers dance following a global scenario without a single point of control" Read the first couple (short) paragraphs of https://en.wikipedia.org/wiki/Service_choreography

mwherman2000 (Wed, 06 Mar 2019 22:23:12 GMT):
@tplooker @danielhardman DID Choreography or Agent Choreography: "Dancers dance following a global scenario without a single point of control" Read the first couple (short) paragraphs of https://en.wikipedia.org/wiki/Service_choreography

charliez (Thu, 07 Mar 2019 01:45:51 GMT):
Has joined the channel.

danielhardman (Fri, 08 Mar 2019 18:43:37 GMT):
During our last agent WG call, @tplooker and I were debating the virtues of signing messages versus fields in a message. We got on the subject of repudiation and digital signatures. I got some feedback that some people may have wondered why I thought repudiation was such a big deal. I decided to propose a HIPE that explains this topic carefully, so we can refer to it in many other HIPEs where this issue comes up as a tangent. Here is my PR: https://github.com/hyperledger/indy-hipe/pull/100. This doc doesn't argue the specific question Tobias and I were hung up on (whether signatures belong at the scope of a message or lower down). It explicitly acknowledges that signatures are the right answer for the use case Tobias was describing (see the section entitled "Unknown Recipient").

nage (Mon, 11 Mar 2019 14:53:35 GMT):
Just a note, that there is an indy-maintainers call today according to my calendar (the Hyperledger calendar is off from the appointment we have sent out to the maintainers directly)

nage (Mon, 11 Mar 2019 14:54:04 GMT):
the zoom link is here https://zoom.us/j/615818107 (starts officially in 6 minutes)

nage (Mon, 11 Mar 2019 14:54:41 GMT):
Agenda document here https://docs.google.com/document/d/1d_SnxinX54Sx-0TwRTnSJK6p_ZN27ZvoI3ytha1QS28/edit#

kdenhartog (Mon, 11 Mar 2019 16:08:45 GMT):
Sorry I couldn't make the maintainers call today. I got mixed up on times, but I did get an email sent to the community architect email address to request switching these.

nage (Mon, 11 Mar 2019 17:07:26 GMT):
thanks

TelegramSam (Thu, 14 Mar 2019 03:16:44 GMT):
Working on approving FCP HIPEs. If you have any strong opinions on any FCP HIPEs, now is the time.

TelegramSam (Thu, 14 Mar 2019 03:20:16 GMT):
PRs 48 and 50 (with the google doc) are still under discussion. Not net approving.

TelegramSam (Thu, 14 Mar 2019 03:36:18 GMT):
FCP HIPEs that are ready to merge: 45 multi-sig-actions, 54 Connection Protocol, 67 Trust Ping, 81 BasicMessage, 87 Ursa Migration

TelegramSam (Thu, 14 Mar 2019 03:36:27 GMT):
(Those are PR numbers)

tplooker (Thu, 14 Mar 2019 03:36:59 GMT):
Did we want to discuss the connection protocol further around supplying a secure version of a connection invite via a JWS structure?

tplooker (Thu, 14 Mar 2019 03:37:30 GMT):
Im happy to proceed with the connection protocol as is with a view to revisiting the topic?

TelegramSam (Thu, 14 Mar 2019 03:37:45 GMT):
I think that discussion should happen, but will function as an update to the accepted HIPE.

TelegramSam (Thu, 14 Mar 2019 03:38:12 GMT):
Which is I think what you just said.

TelegramSam (Thu, 14 Mar 2019 04:33:20 GMT):
HIPEs 30-34 have now been merged in the PR order from above.

TelegramSam (Thu, 14 Mar 2019 21:37:04 GMT):
I propose that the following HIPEs be moved to FCP: https://github.com/hyperledger/indy-hipe/pull/100 - Repudiation Explainer https://github.com/hyperledger/indy-hipe/pull/86 - Agents Explainer https://github.com/hyperledger/indy-hipe/pull/85 - Mediators and Relays https://github.com/hyperledger/indy-hipe/pull/83 - JSON-LD compatibility These HIPEs have low comment volume and are generally non-controversial. Any Objections? (I'll wait till at least tomorrow before taking action)

kdenhartog (Fri, 15 Mar 2019 03:17:42 GMT):
@TelegramSam @danielhardman I was just looking into invitation protocol and I think we have a MITM problem. A MITM seems small when setting up a connection, but as the connection becomes trusted it could allow the MITM some powerful capabilities. For example, if Mallory is able to inject a key into the DID Doc into Alice's DID Doc it seems useless because the connection isn't trusted. Lets say Alice presents proof though, and Bob trust's its truly Alice. Then Alice submits a proof request to Bob, Mallory forwards this on and then Bob issues the credential. Bob sends it back to Alice and she stores it in her wallet. Then Mallory decides to submit a proof request for a second credential. Mallory generates a second link secret and submits a proof request. Given Bob "trusts" this connection because he already has received a credential, he offers a proof to Mallory thinking its Alice's second agent. Now Mallory posesses a credential to impersonate Alice, Bob doesn't know he issued to Mallory, and Alice doesn't know there's been a second credential issued.

kdenhartog (Fri, 15 Mar 2019 03:29:45 GMT):
I'm thinking we may be able to avoid this by having an agency sign the invitation data and sending it back to Alice. This would allow Bob to be certain no malicious keys have been injected, but it would also create a centralization around "trusted" agencies

kdenhartog (Fri, 15 Mar 2019 03:36:04 GMT):
Additionally on ledger DIDs can help here, but it creates a correlation problem for private connections.

tplooker (Fri, 15 Mar 2019 03:38:09 GMT):
Can you elaborate how mallory is able to inject a key into the did doc?

tplooker (Fri, 15 Mar 2019 03:40:54 GMT):
If the invitation was signed by the invitee then wouldn't this problem be reduced?

kdenhartog (Fri, 15 Mar 2019 03:42:03 GMT):
Say the DID doc Alice wanted to send contains one key and is signed by that key. Mallory could add a second key, recreate the invitation with the second key added, and then sign the invitation with the second key and send the newly genrated invitation to Bob.

kdenhartog (Fri, 15 Mar 2019 03:50:15 GMT):
The safety numbers in Signal are for solving this problem, but from a UX standpoint they're rarely used.

kdenhartog (Fri, 15 Mar 2019 03:53:24 GMT):
https://signal.org/blog/safety-number-updates/

tplooker (Fri, 15 Mar 2019 03:53:44 GMT):
Right I understand, a good problem to mill over for a while

kdenhartog (Fri, 15 Mar 2019 03:55:43 GMT):
I'm wonder if we can do some sort of acknowledgement of safety numbers built into the protocol. I'd have to dig into how these are generated more and see what may come of it. From what I can tell there's not many good "Automated" ways to verify this.

kdenhartog (Fri, 15 Mar 2019 03:56:25 GMT):
Also worth noting this only happens if the out of band channel is untrusted. If it can be trusted, then this problem goes away.

tplooker (Fri, 15 Mar 2019 03:57:44 GMT):
Yeah this handshake when one party is exchanging their information for the basis of the trusted connection I can see a MITM attack vector

tplooker (Fri, 15 Mar 2019 03:59:20 GMT):
But this MITM attack must also inject a decoy endpoint for the false key otherwise they will never receive subsequent messages?

tplooker (Fri, 15 Mar 2019 04:00:10 GMT):
They could just squat on the endpoint and act as a pass through

kdenhartog (Fri, 15 Mar 2019 04:05:28 GMT):
yeah, good point that would be true

kdenhartog (Fri, 15 Mar 2019 04:05:45 GMT):
In the case of a malicious agency though this would make for an easy MITM

kdenhartog (Fri, 15 Mar 2019 04:06:41 GMT):
This could mean that a govt could require all citizens to use "trusted" agencies which are actually MITM the pairwise connections

swcurran (Fri, 15 Mar 2019 13:21:34 GMT):
Nothing simple to solve this like constrain the DIDDoc to have one key?

swcurran (Fri, 15 Mar 2019 13:21:34 GMT):
Nothing simple to solve this like constrain the initial DIDDoc to have one key?

danielhardman (Fri, 15 Mar 2019 14:01:27 GMT):
What about having each party echo back the hash of the DID Doc that they end up with, so they know whether it's been modified?

swcurran (Fri, 15 Mar 2019 15:03:19 GMT):
This would only be possible on the out-of-band Invitation process, correct? If so could we add the hash of the received invitation to the Connection Request message?

swcurran (Fri, 15 Mar 2019 15:10:19 GMT):
FYI - Linux Foundation announces a CD Foundation for trying to bring sanity to the CI/CD space - https://cd.foundation/. The first projects in the CDF are Jenkins/JenkinsX, Spinnaker and Tekton. GitLab is a founding member, as well as many of the other big players in Cloud Native and big CI/CD players - CircleCI, CloudBees, JFrog.

TelegramSam (Fri, 15 Mar 2019 20:54:04 GMT):
Also, only the Invitation is subject to a MITM attack, correct?

kdenhartog (Sun, 17 Mar 2019 20:20:08 GMT):
from what I can tell yes it seems that way

kdenhartog (Sun, 17 Mar 2019 20:21:02 GMT):
We can constrain it by saying the invitation should be sent over a trusted channel, but we definitely need to figure out a better solution soon.

kdenhartog (Sun, 17 Mar 2019 20:23:03 GMT):
@danielhardman I'm not sure that will work because the MITM could echo the hash as well

tplooker (Sun, 17 Mar 2019 20:28:53 GMT):
I agree, in my view the main issue is when we use a message service to deliver the connection request in response to the invite, if the service doing the delivery decides to repack the message then we have a MITM attack

tplooker (Sun, 17 Mar 2019 20:29:18 GMT):
Likewise with the connection response

tplooker (Sun, 17 Mar 2019 20:29:42 GMT):
Well actually not so much the connection response

kdenhartog (Sun, 17 Mar 2019 22:26:44 GMT):
@MALodder what's your take on this? this looks a lot like the TOFU problem.

MALodder (Mon, 18 Mar 2019 00:13:06 GMT):
Yes it’s a TOFU problem. Which is why you usually need two methods to authenticate on first use—two different transport bands.

kdenhartog (Mon, 18 Mar 2019 02:36:20 GMT):
@TelegramSam is there a way that we can add methods of verification into the invitation protocol to meet the best practices of how this problem is solved today? I imagine one way that this can be done is like showing the fingerprint images and making sure they match on the phone and on a website

kdenhartog (Mon, 18 Mar 2019 02:36:46 GMT):
I'm sure there's other ways that are viable as well so we can describe this in a more abstract way

TelegramSam (Mon, 18 Mar 2019 13:17:51 GMT):
A few thoughts.

TelegramSam (Mon, 18 Mar 2019 13:25:32 GMT):
First: We should update the connection protocol HIPE to highlight the MITM potential with untrusted transmission. Invitation via in-person smartphone QR scanning (phone to phone) is mostly free from this problem. Placing a connection invitation in a public place as a permanent QR code is very subject to this via a 'sticker' attack. :)

TelegramSam (Mon, 18 Mar 2019 13:29:42 GMT):
Second: We should consider the right time to solve the problem. Maybe the solution is within the invitation itself, perhaps the solution is in passing proof over the new connection.

TelegramSam (Mon, 18 Mar 2019 13:37:10 GMT):
Using a visual check 'out of band' to the connection seems like the simplest option. this visual check can be done in person phone to phone, or via phone to website.

TelegramSam (Mon, 18 Mar 2019 13:38:28 GMT):
Question: can Zero Knowledge Proofs be proxied in a MITM attack? If yes, then we can't use it to establish trust. If no, then it will be a useful test.

TelegramSam (Mon, 18 Mar 2019 13:42:14 GMT):
So, if peer DIDs are tied to initial keys, then we should only need to verify the DID, right? this allows the peer DID and public DID solutions to be the same.

MALodder (Mon, 18 Mar 2019 14:05:23 GMT):
ZKPs can't be proxied, The verifier knows the nonce, the prover knows the signature and attributes. Even if a Eve alters the nonce, then the verifier will know because the proof will not validate for him

MALodder (Mon, 18 Mar 2019 14:06:01 GMT):
The prover will not know if there is someone in the middle because prover just receives a nonce

MALodder (Mon, 18 Mar 2019 14:06:25 GMT):
So the verifier can detect

jljordan_bcgov (Mon, 18 Mar 2019 15:13:18 GMT):
feels like there will be a social pattern arise that involved verifiable credentials .. if there is a need for trust then I will establish a connection, mentally (or maybe even on the UI) mark it as "unknown level of assurance", then ask the peer for a proof that I need to establish the level of assurance I need to conduct whatever sorts of interactions I would like to do with that peer

jljordan_bcgov (Mon, 18 Mar 2019 15:15:17 GMT):
so if there was a MITM attack and then I ask for some sort of proof that the peer is holding a verifiable credential(s) from trusted third parties, they should not be able to provide those proof unless of course they have somehow gained control of an agent malicioulsy

MALodder (Mon, 18 Mar 2019 15:18:57 GMT):
right

MALodder (Mon, 18 Mar 2019 15:19:12 GMT):
if mutual proofs are done then MITM can be detected

TelegramSam (Mon, 18 Mar 2019 15:31:51 GMT):
mutual proofs may not be needed. The invitation is one way.

TelegramSam (Mon, 18 Mar 2019 15:33:57 GMT):
@jljordan_bcgov's point is really good one. Perhaps we have a standard set of 'baseline' credentials you could ask anybody for. Businesses could supply a business name. Individuals could supply a reputation credential?

jljordan_bcgov (Mon, 18 Mar 2019 15:36:17 GMT):
remembering that trust is highly contextual .. we need only to establish trust when we have to mitigate a risk In many cases we already have very long established practices for establishing needed levels of trust

TelegramSam (Mon, 18 Mar 2019 15:36:25 GMT):
The following HIPEs have been moved to FCP: https://github.com/hyperledger/indy-hipe/pull/100 - Repudiation Explainer https://github.com/hyperledger/indy-hipe/pull/86 - Agents Explainer https://github.com/hyperledger/indy-hipe/pull/85 - Mediators and Relays https://github.com/hyperledger/indy-hipe/pull/83 - JSON-LD compatibility

TelegramSam (Mon, 18 Mar 2019 15:37:09 GMT):
@jljordan_bcgov I feel like basline trust to detect MITM is pretty foundational.

jljordan_bcgov (Mon, 18 Mar 2019 15:37:39 GMT):
we know how to enter into business contracts, we know how to open accounts and so on .. what we are doing here is making it possible to do those rituals digitally

jljordan_bcgov (Mon, 18 Mar 2019 15:38:15 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=ZjZ9fKRMYKYNT6hxQ) @TelegramSam maybe I am missing something for sure ... I don't venture into protocol design much (for good reason :))

jljordan_bcgov (Mon, 18 Mar 2019 15:38:46 GMT):
but I think I understand that we are talking about MITM at the connection level (agent to agent)

jljordan_bcgov (Mon, 18 Mar 2019 15:38:59 GMT):
and some funny business with the initial invitation

TelegramSam (Mon, 18 Mar 2019 15:41:26 GMT):
It is important to detect a MITM attack as soon as possible. Because the Invitation from Bob to Alice is passed out of band, Eve could replace it with her own invitation. Alice sends a request to Eve (unknowingly), Eve sends a request to Bob. Both are completed. Alice thinks she has a connection (and relationship) with Bob and vice versa, but Eve holds the other end of both relationships. As long as she is subtle about passing information back and forth, Alice and Bob might not realize she's in the middle.

jljordan_bcgov (Mon, 18 Mar 2019 15:42:38 GMT):
but that breaks down for ZKP credentials?

jljordan_bcgov (Mon, 18 Mar 2019 15:42:50 GMT):
you can't proxy them

TelegramSam (Mon, 18 Mar 2019 15:42:56 GMT):
right.

TelegramSam (Mon, 18 Mar 2019 15:43:00 GMT):
but proofs of what?

jljordan_bcgov (Mon, 18 Mar 2019 15:43:11 GMT):
that is up to the verifier to decide

TelegramSam (Mon, 18 Mar 2019 15:43:12 GMT):
the proof has to be something Eve can't provide.

TelegramSam (Mon, 18 Mar 2019 15:43:25 GMT):
generally yes, but for MITM we need to be more specific.

jljordan_bcgov (Mon, 18 Mar 2019 15:43:31 GMT):
connections are "in-context" they are not random

jljordan_bcgov (Mon, 18 Mar 2019 15:44:28 GMT):
there is a purpose for a connections otherwise it doesn't matter ... its a friend, or a services, or a business partner, or a store or something like that

jljordan_bcgov (Mon, 18 Mar 2019 15:44:28 GMT):
there is a purpose for a connection otherwise it doesn't matter ... its a friend, or a services, or a business partner, or a store or something like that

TelegramSam (Mon, 18 Mar 2019 15:48:48 GMT):
yes. for a business, it makes sense to immediately provide proof of business name or business license or something.

TelegramSam (Mon, 18 Mar 2019 15:48:58 GMT):
peer connections are harder.

TelegramSam (Mon, 18 Mar 2019 15:50:26 GMT):
for that a different proof is needed.

TelegramSam (Mon, 18 Mar 2019 15:50:50 GMT):
for both cases, a DID hash of the relationship can be used out of band to verify.

danielhardman (Mon, 18 Mar 2019 16:20:04 GMT):
@TelegramSam and @jljordan_bcgov and @MALodder : According to Jason Law, it is possible to prove that the private key used with a pairwise DID was derived from the link secret. If we had this, then this would be the first proof we'd do after establishing a connection. It wouldn't prove anything about the person other than that a MITM isn't possible.

MALodder (Mon, 18 Mar 2019 16:25:25 GMT):
@danielhardman I fail to see how that helps any more or different than just doing a proof

MALodder (Mon, 18 Mar 2019 16:27:52 GMT):
A verifier can detect if his nonce has been changed

MALodder (Mon, 18 Mar 2019 16:28:08 GMT):
but he doesn't know if its really the prover or someone impersonating the prover

MALodder (Mon, 18 Mar 2019 16:29:31 GMT):
linking the DID key with the link secret doesn't help in proving who I am, just that the same person who sent the DID key is also proving which an attacker can easily do

MALodder (Mon, 18 Mar 2019 16:34:21 GMT):
perhaps I'm misunderstanding

MALodder (Mon, 18 Mar 2019 16:34:39 GMT):
can you explain what this buys you

MALodder (Mon, 18 Mar 2019 16:34:45 GMT):
I'm not seeing how its helpful

danielhardman (Mon, 18 Mar 2019 16:53:42 GMT):
@MALodder Mallory interposes between Alice and Bob. Alice thinks she's talking to Bob, but gets Mallory instead. Bob thinks he's talking to Alice, but gets Mallory instead. Now, Alice asks "Bob" to prove that he has a driver's license. That's it--no deep disclosure, no predicates, even. She just wants to know she's dealing with a real person. Mallory takes out her digital driver's license credential and proves this to Alice. Mallory also relays this request to Bob, and has Bob prove it to Mallory. Alice has now received the proof she expected, and Bob has given the proof he was asked for, and neither party has been able to detect the MITM. This is not avoided by the "ZKPs can't be proxied" claim you have made, because Mallory is making no attempt to proxy Bob's proof to Alice; instead, Mallory is throwing away Bob's proof and substituting her own. What I am recommending doesn't solve this problem, either--yet. But carry the relationship forward a bit. Now Alice needs to know something meaningful about Bob. She asks Bob to prove that he has a bank account and lives in Canada (where Bob is supposed to live). It is in Mallory's interests to look as much like Bob as possible, so Alice will eventually disclose unsafe info or send money that Mallory can siphon off. So Mallory now has 2 choices: 1. Try to proxy Bob's legitimate proof requests, tweaking them per Mallory's convenience. As you have said, this doesn't work. 2. Go out on the dark web and buy a credential from someone who lives in Canada. Approach 2 is where what I'm recommending becomes useful. If Mallory buys a credential from such a source, and uses it to substitute her own proof request, the credential will have a link secret that is different from the one Mallory used to do her initial proof. Alice can detect that funny business with link secrets is happening. (It is possible to prove that the same link secret is used in subsequent proofs, without ever knowing what the actual value of the link secret is.)

jljordan_bcgov (Mon, 18 Mar 2019 18:21:46 GMT):
So a fundamental question is why to MITM attacks work?

jljordan_bcgov (Mon, 18 Mar 2019 18:22:28 GMT):
And I'd argue is because there is no antidote to the risk present in current means of establishing digital relationships that are at a distance

jljordan_bcgov (Mon, 18 Mar 2019 18:24:13 GMT):
Verifiable Credentials issued by authoritative sources are the antidote to digital relationships with elements of risk ... relationships where there is going to be some sort of valued transaction take place

jljordan_bcgov (Mon, 18 Mar 2019 18:24:50 GMT):
I'm never going to believe who you are unless you prove with a digital identity claim from a trusted issuer that you are Bob

swcurran (Mon, 18 Mar 2019 19:48:39 GMT):
I'm finding it hard to follow what is the actual MITM problem, mitigations have been defined that would or would not work. @kdenhartog - could you put the relevant scenario into a Google Doc so that people can propose mitigations and we can have them accepted/rejected as effective/ineffective? That way we can see what protocol and/or best practices need to be adjusted.

kdenhartog (Mon, 18 Mar 2019 20:07:20 GMT):
Yup, I can do this

kdenhartog (Mon, 18 Mar 2019 20:07:21 GMT):
Yup, I can do this

kdenhartog (Mon, 18 Mar 2019 20:09:37 GMT):
The original attack I was thinking of should be solvable with a proof that a key has been derived from a link secret I believe.

kdenhartog (Mon, 18 Mar 2019 20:10:34 GMT):
The other formats that have been proposed should be solvable with proofs, so I think using both proofs will be the common solution.

swcurran (Mon, 18 Mar 2019 20:21:55 GMT):
Those solutions require code and protocol updates, I think - correct? We need to highlight those and where they are needed. The proof of link secret sounds super interesting...

swcurran (Mon, 18 Mar 2019 20:23:34 GMT):
For example, can/should we build into the connection protocol the follow up proof so that it just happens (e.g. no UX requirement).

TelegramSam (Mon, 18 Mar 2019 20:42:12 GMT):
if we can generalize to prove no MITM, then I vote we DO include it in the basic protocol.

MALodder (Mon, 18 Mar 2019 21:25:42 GMT):
@danielhardman you’re proposal still doesn’t work because for Mallory to present a proof she has to know the link secret

MALodder (Mon, 18 Mar 2019 21:26:02 GMT):
MITM is only relevant when establishing new connections

MALodder (Mon, 18 Mar 2019 21:26:30 GMT):
Once a connection is setup then did keys prevent MITM

MALodder (Mon, 18 Mar 2019 21:29:06 GMT):
The fundamental problem is you have to verify that the key you sent is the key they received. This is usually done via a different band than the key was sent

MALodder (Mon, 18 Mar 2019 21:30:40 GMT):
If Mallory purchases a credential from the dark net, she still must know ALL the attributes to do a proof.

MALodder (Mon, 18 Mar 2019 21:32:42 GMT):
You’re correct in that Mallory can just change the proof entirely to Bob but the advantage of proofs is that Mallory MUST do this or Bob can detect it

MALodder (Mon, 18 Mar 2019 21:38:56 GMT):
I really like how secure scuttlebutt works for new connections. Perhaps we should draw inspiration from there

danielhardman (Mon, 18 Mar 2019 22:04:56 GMT):
@MALodder When Mallory buys the credential on the dark web, she buys the link secret that goes with it.

danielhardman (Mon, 18 Mar 2019 22:07:08 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=6XDmwmg6PeKXPKHMY) @jljordan_bcgov Of course. But I'd argue that you have the wrong goal. We should stop trying to "prove who you are" and instead start proving that you are the type of identity owner that's needed. Those are different questions.

jljordan_bcgov (Mon, 18 Mar 2019 22:32:50 GMT):
So "Are you John?" vs "Are you a person"?

kdenhartog (Mon, 18 Mar 2019 22:38:07 GMT):
https://docs.google.com/document/d/1CCu2w9QmWthw91OM1aGpwGZxppr-HeC_hRDgmQx6Ips/edit?usp=sharing

kdenhartog (Mon, 18 Mar 2019 22:38:17 GMT):
That's the document I wrote up on this

kdenhartog (Mon, 18 Mar 2019 22:39:34 GMT):
I tried to cover some of the ideas that I've heard so far around this and what I could find from how others are solving this problem from what I could find

kdenhartog (Mon, 18 Mar 2019 22:40:40 GMT):
@MALodder how does SSB solve this problem? I like relying on what others have done to solve this problem if possible. For example using fingerprinting images for out of band verification at the UX layer seems like a good idea.

MALodder (Mon, 18 Mar 2019 23:53:17 GMT):
Basically to prevent MITM, the discovery mechanism needs to allow both parties to agree on what was sent. If the discovery is two people taking in person and one showing the other a QR code that is scanned and the other doing likewise, that’s one example. I may post my connection info on an orphaned website that I only tell new connections about and they confirm that info via phone, sms, email, snail mail, what have you. Most services today have a semi trusted service that handles this for us by uploading an identity key of some kind and as long as we trust the service not to lie about the identity key and also confirm with the other party that the key belongs to them either by fingerprinting, safety numbers then we’re safe. For self sovereignty, ssb helps with the discovery of new people and we can piggyback on that idea but add the extra confirmation step with new connections. Existing connections are already secured if we use the TOFU approach. Ssb can also help me find existing connections and sync up with them without the internet.

MALodder (Tue, 19 Mar 2019 00:10:40 GMT):
We should consider using the formulas from the noise framework DSL for the exact keys that need to be exchanged

TelegramSam (Tue, 19 Mar 2019 01:25:54 GMT):
Unless I misunderstand something, ONLY an out of band check or a credential proof will solve this.

TelegramSam (Tue, 19 Mar 2019 01:26:31 GMT):
Business or org proof makes sense, but what about people?

MALodder (Tue, 19 Mar 2019 03:00:34 GMT):
@TelegramSam just give them your gov't ID right!?!

MALodder (Tue, 19 Mar 2019 03:00:47 GMT):
:confused:

TelegramSam (Tue, 19 Mar 2019 03:10:35 GMT):
Also a problem is adhoc groups. No business credential.

mspatel (Tue, 19 Mar 2019 13:51:33 GMT):
Has joined the channel.

danielhardman (Thu, 21 Mar 2019 16:56:04 GMT):
@TelegramSam Could you accept this PR? It's a minor change to the SSI-Notation HIPE to change the label on the negotiation diagram we discussed yesterday. https://github.com/hyperledger/indy-hipe/pull/106

TelegramSam (Thu, 21 Mar 2019 18:00:18 GMT):
doneski

rjones (Thu, 21 Mar 2019 18:12:09 GMT):
Has left the channel.

danielhardman (Thu, 21 Mar 2019 21:56:00 GMT):
@TelegramSam I updated the localization HIPE and think it is now clean enough for FCP.

MALodder (Fri, 22 Mar 2019 18:22:43 GMT):
So I found out that Indy-crypto has been releasing from the `rc` branch and not porting the changes back to master. As such the two branches are vastly different. Can someone tell me why that’s been happening? I also see merged to master and some of those have not been applied to `rc`

MALodder (Fri, 22 Mar 2019 18:22:43 GMT):
So I found out that Indy-crypto has been releasing from the `rc` branch and not porting the changes back to master. As such the two branches are vastly different. Can someone tell me why that’s been happening? I also see merges to master and some of those changes have not been applied to `rc`

MALodder (Fri, 22 Mar 2019 18:25:16 GMT):
I thought the point of `rc` was it was supposed to short lived and release were either tagged or branched and this is not the case

Gruszka (Fri, 22 Mar 2019 21:44:09 GMT):
Has joined the channel.

nage (Mon, 25 Mar 2019 14:26:29 GMT):
@here maintainers call starts in about 30 minutes, agenda and notes document is here https://docs.google.com/document/d/1d_SnxinX54Sx-0TwRTnSJK6p_ZN27ZvoI3ytha1QS28/edit#

Ryan2 (Tue, 26 Mar 2019 04:48:37 GMT):
Has joined the channel.

TelegramSam (Wed, 27 Mar 2019 16:35:22 GMT):
I think the DIDComm Explainer is ready for FCP: https://github.com/hyperledger/indy-hipe/pull/98

TelegramSam (Wed, 27 Mar 2019 16:35:25 GMT):
Thoughts?

danielhardman (Fri, 29 Mar 2019 08:52:37 GMT):
I have raised a first draft of a HIPE about introductions: https://github.com/hyperledger/indy-hipe/pull/110

danielhardman (Fri, 29 Mar 2019 08:55:14 GMT):
Folks: We have an anomalous HIPE. It is the one about DKMS. I raised it. This is a request to publish research about DKMS design. It is not really a normal HIPE. However, we need a place to publish it, and right now I think the indy-hipe repo is the best location. I'd like to ask a special exception to our normal process where we merge this HIPE PR by EOD tomorrow, because it needs to be published at a permalink for DHS before the end of March. Although it hasn't gone through a normal HIPE process, it *is* the product of significant thinking from the community, and also has been reviewed by a number of people outside the Indy world as well.

danielhardman (Fri, 29 Mar 2019 08:55:14 GMT):
Folks: We have an anomalous HIPE. It is the one about DKMS. I raised it. This is a request to publish research about DKMS design: https://github.com/hyperledger/indy-hipe/pull/108. It is not really a normal HIPE. However, we need a place to publish it, and right now I think the indy-hipe repo is the best location. I'd like to ask a special exception to our normal process where we merge this HIPE PR by EOD tomorrow, because it needs to be published at a permalink for DHS before the end of March. Although it hasn't gone through a normal HIPE process, it *is* the product of significant thinking from the community, and also has been reviewed by a number of people outside the Indy world as well. At the moment, it has a DCO problem, but if given permission to merge, I will fix that before I do the merge.

danielhardman (Fri, 29 Mar 2019 08:56:44 GMT):
^^ @TelegramSam @swcurran @nage

nage (Fri, 29 Mar 2019 12:00:15 GMT):
Will it have the normal HIPE txt and header? Perhaps we can reflect it's special status there? If so I have no problem merging to get the permalink

swcurran (Fri, 29 Mar 2019 16:55:43 GMT):
Agree that it needs to be flagged as a "different beast", but I'm not against pushing it into the HIPE. A question I have is whether the HIPE will evolve over time, or will it be considered locked to the needs of the permalink? I'm not certain what has changed in this iteration vs. previous versions, but I recall there are things from the original version that have likely changed as the thinking has evolved - e.g. authorization policy for an individual being on ledger if individuals can't have data on the ledger.

swcurran (Fri, 29 Mar 2019 16:56:49 GMT):
I"m fine either way - just wondering. It is too many protocols embedded to be finalized and consumed in one go. It will beget protocols, no doubt.

swcurran (Fri, 29 Mar 2019 16:56:49 GMT):
I"m fine either way - just wondering. It has too many protocols embedded to be finalized and consumed in one go. It will beget protocols, no doubt.

swcurran (Fri, 29 Mar 2019 16:56:49 GMT):
I"m fine either way - just wondering. It has too many protocols embedded to be finalized and consumed in one go. It will beget protocols and HIPEs, no doubt.

esplinr (Fri, 29 Mar 2019 17:08:24 GMT):
Good points.

esplinr (Fri, 29 Mar 2019 17:09:02 GMT):
Maybe in addition to the folder hipe/text we should have a folder hipe/design to capture big picture thinking about the network? Or is that too much overlap?

swcurran (Fri, 29 Mar 2019 17:49:03 GMT):
That would be a good idea. There is at least the Revocation HIPE that is really great stuff, but more of a design than a HIPE for those building on Indy.

swcurran (Fri, 29 Mar 2019 17:50:38 GMT):
Doesn't give us long to make a decision to get this a permalink by March 31st. I vote we add a /design folder and put the accept the DKMS HIPE into that folder.

swcurran (Fri, 29 Mar 2019 18:41:44 GMT):
FWIW - the new `anoncreds` hipe from Mike and Brent is another good candidate for the `design` folder.

danielhardman (Fri, 29 Mar 2019 19:26:14 GMT):
Some answers to questions above: 1. We can certainly give the doc a header that explains its abnormalities. And I'm not opposed to putting it in a different folder. 2. The doc will likely evolve more, albeit slowly. In fact, I hope it does, because that would mean the community has engaged around it even more than they have already. 3. We don't need a permalink to the latest version of it--just to the version we release by the end of the month.

MALodder (Fri, 29 Mar 2019 20:37:04 GMT):
@danielhardman I can give you the fee commands needed to fix the DCO problem if you need it

danielhardman (Fri, 29 Mar 2019 20:37:20 GMT):
I just fixed it

danielhardman (Fri, 29 Mar 2019 20:43:39 GMT):
@TelegramSam and @nage et al: I now have the DKMS docs in a form suitable for merging, and I would like your approval to do so. The material is in two parts -- a README.md that is small, and that I have formatted to match the HIPE format, and a much larger doc that contains the real thinking. The README has a note at the top explaining how/why this HIPE is a bit anomalous, and it links to the larger content. You can see the README here: https://github.com/hyperledger/indy-hipe/blob/b338473a10a655f0e2c915a7c2b029d7eeef1e1a/text/dkms/README.md I suggest that we assign this HIPE a number from the small set of numbers < 10 that are reserved for truly foundational material. How about 0005? May I have a quick go-ahead to update the PR with a HIPE number and then get one of you to merge it? (As it currently stands, I am not creating a separate /design folder that parallels /text. This is because I'm lazy and the idea just barely popped--not because I'm opposed to it in any significant way. I figure we can adjust folder structure any time, after the idea bakes a bit. The permalink I'll use is just to the first merge commit that looks canonical.)

danielhardman (Fri, 29 Mar 2019 20:43:53 GMT):
@swcurran ^^

danielhardman (Fri, 29 Mar 2019 20:46:27 GMT):
Whoops. Drummond just did another commit without DCO. Will fix momentarily.

swcurran (Fri, 29 Mar 2019 20:50:20 GMT):
@danielhardman - doesn't the idea of moving it to a /design folder later eliminate the permalink? The idea of a /design folder has come up before, so I don't think it is a huge risk. My personal preference would be to do the /design in this case and we migrate other things to it. It also eliminates the need for using a "magic" number for the HIPE - no collisions with the /text folder.

danielhardman (Fri, 29 Mar 2019 20:52:21 GMT):
No, the permalink would be to a specific git commit. It never changes. I am not opposed to what you're recommending, but I do want one or two other maintainers to weigh in first.

danielhardman (Fri, 29 Mar 2019 21:31:00 GMT):
ping @TelegramSam, @nage, etc

nage (Fri, 29 Mar 2019 21:34:30 GMT):
I have no issues with the proposal and think it should move forward.

nage (Fri, 29 Mar 2019 21:34:55 GMT):
I like giving it a foundational number

danielhardman (Fri, 29 Mar 2019 21:48:57 GMT):
So now I'm getting contradictory feedback. I wanted a HIPE number, and Nathan did, too. Stephen is saying no HIPE number, just put it in a different folder that we would create. Given the impasse, can we get @TelegramSam to vote?

danielhardman (Fri, 29 Mar 2019 21:49:00 GMT):
:-)

danielhardman (Fri, 29 Mar 2019 21:49:31 GMT):
Or, Nathan, do you want to change your vote? I just want to do something that multiple maintainers approve.

danielhardman (Fri, 29 Mar 2019 21:54:50 GMT):
Okay, to make progress here, how about I commit/merge to /design with no HIPE number. That will give it a permalink and make it feel official to DHS. However, because it's not in the /text folder, we won't have bent the normal HIPE process so much, and we can always number it or move later if we like. Doing so won't change the permalink--just where the community that lacks the permalink will find it. Is that agreeable to everybody?

danielhardman (Fri, 29 Mar 2019 22:05:16 GMT):
I've got all that ^^ ready to go. Can I merge?

danielhardman (Fri, 29 Mar 2019 22:09:51 GMT):
Okay, I've got an approval from SWCurran and Mike on this approach, so I'm going to do it.

danielhardman (Fri, 29 Mar 2019 22:11:12 GMT):
Done.

swcurran (Fri, 29 Mar 2019 22:16:42 GMT):
Good way to end a Friday.

swcurran (Fri, 29 Mar 2019 22:16:42 GMT):
Good way to end a Friday. Something merged...

TelegramSam (Fri, 29 Mar 2019 22:26:20 GMT):
Just showed up. Agree with approach. Do I need to do anything to make it happen?

danielhardman (Fri, 29 Mar 2019 23:00:57 GMT):
Nope. All done. However, you can announce the merge on rocket.chat if you like. Here's what I wrote in the top of the README.md: ```NOTE: This HIPE is somewhat unusual in that it is enormously complex and detailed. It arose out of years-long efforts by community members to wrap their brains around how key management should be solved without a central authority. It represents deep thinking by many industry experts, including important voices outside the Indy community. It is published on a deadline, as part of a research grant from the US Department of Homeland Security. Because of this, the normal community collaboration process is somewhat inverted; maintainers have agreed to publish the doc directly, and then open it up for community contribution and polishing after-the-fact.```

esplinr (Sat, 30 Mar 2019 02:48:12 GMT):
Yay!

esplinr (Sat, 30 Mar 2019 04:29:25 GMT):
Please see my note in #indy about changing the Jira configuration of the Indy projects. I expect they will be a lot more productive for us to use now. As part of this process, I created a detailed wiki page on "How to Contribute". I recommend that we replace the GitHub references to the Google Presentation with links to this page of the wiki: https://wiki.hyperledger.org/display/indy/How+to+Contribute

kdenhartog (Sat, 30 Mar 2019 06:57:53 GMT):
@esplinr or @MALodder do you or anyone else know why iOS isn't building the objective-C wrapper to repo.sovrin.org anymore?

esplinr (Sat, 30 Mar 2019 06:59:42 GMT):
I'm sorry, but i have no information on that. Last week we discussed how it was working.

MALodder (Sat, 30 Mar 2019 12:01:10 GMT):
I’ll ask Steven gubler to take a look

kdenhartog (Mon, 01 Apr 2019 04:18:46 GMT):
Thanks @MALodder I appreciate your help

lukasA (Mon, 01 Apr 2019 12:26:30 GMT):
Has joined the channel.

smithbk (Mon, 01 Apr 2019 19:59:41 GMT):
Has joined the channel.

smithbk (Mon, 01 Apr 2019 20:02:38 GMT):
Can someone tell me where I should be pulling anoncreds from now? I was using version 1.0.32 as is used by indy-sdk at https://github.com/hyperledger/indy-sdk/blob/master/ci/indy-pool.dockerfile#L28 but that version is no longer available

cam-parra (Tue, 02 Apr 2019 13:45:14 GMT):
https://repo.sovrin.org/deb/pool/xenial/stable/i/indy-anoncreds/

cam-parra (Tue, 02 Apr 2019 13:45:14 GMT):
@smithbk https://repo.sovrin.org/deb/pool/xenial/stable/i/indy-anoncreds/

cam-parra (Tue, 02 Apr 2019 13:55:22 GMT):
Looks like not all packages were brought over when the repo migration was done

cam-parra (Tue, 02 Apr 2019 13:55:22 GMT):
*Correction* the packages do exists, I was wrong. You are using the master artifacts for your pipeline. Let me send you an example of my anon cred implementation in docker

cam-parra (Tue, 02 Apr 2019 13:55:22 GMT):
*Correction* the packages do exists, I was wrong.... Not sure what is going on here

MALodder (Tue, 02 Apr 2019 15:00:58 GMT):
@lynn.bendixsen mentioned this to me > Anoncreds was removed from dependencies (for the sovrin package) a few months ago and is no longer required iirc for validator nodes. I can't remember why...

VS09 1 (Wed, 03 Apr 2019 06:35:59 GMT):
Has joined the channel.

TelegramSam (Wed, 03 Apr 2019 12:54:42 GMT):
HIPE PR 64 Localized Messages moved to FCP: https://github.com/hyperledger/indy-hipe/pull/64

TelegramSam (Wed, 03 Apr 2019 13:03:23 GMT):
HIPE PR 73 Protocol Discovery moved to FCP: https://github.com/hyperledger/indy-hipe/pull/73

danielhardman (Wed, 03 Apr 2019 21:28:39 GMT):
@TelegramSam I am thinking this PR is ready to merge. It is just a clarification of an existing HIPE, and in its latest form I think it addresses your request to be explicit about JSON object vs. string: https://github.com/hyperledger/indy-hipe/pull/105

kdenhartog (Thu, 04 Apr 2019 15:27:46 GMT):
I agree this is ready to merge as well.

danielhardman (Sat, 06 Apr 2019 15:32:22 GMT):
All: I made some ambitious updates to the protocols explainer HIPE. They are not semantic changes--all the same concepts we've been talking about all along are still there, more or less as we've described them. However, I have added many examples, plus some new content to explain state machines a bit better. I also broke the big, monolothic doc into subdocs. Some places worth reading, even for people familiar with what came before, include: https://github.com/hyperledger/indy-hipe/blob/ed492ca/text/protocols/README.md#types-of-protocols https://github.com/hyperledger/indy-hipe/blob/ed492ca/text/protocols/README.md#composable https://github.com/hyperledger/indy-hipe/blob/ed492ca/text/protocols/uris.md https://github.com/hyperledger/indy-hipe/blob/ed492ca/text/protocols/parties-roles-participants.md https://github.com/hyperledger/indy-hipe/blob/ed492ca/text/protocols/state-details.md

silviu (Sat, 06 Apr 2019 19:14:02 GMT):
Has joined the channel.

kdenhartog (Mon, 08 Apr 2019 11:45:17 GMT):
https://github.com/katzenpost/docs/blob/master/mixnet_academy/syllabus.rst This is a good reference to look through as we continue building out agent routing and wire message format.

nage (Mon, 08 Apr 2019 14:52:04 GMT):
The maintainer call is starting in 9 minutes (according to my calendar)

nage (Mon, 08 Apr 2019 14:52:53 GMT):
@here https://zoom.us/j/615818107

nage (Mon, 08 Apr 2019 14:53:13 GMT):
https://docs.google.com/document/d/1d_SnxinX54Sx-0TwRTnSJK6p_ZN27ZvoI3ytha1QS28/edit#

swcurran (Mon, 08 Apr 2019 14:53:40 GMT):
Welcome back, @nage

nage (Mon, 08 Apr 2019 14:53:51 GMT):
Thanks, it is good to be back

nage (Mon, 08 Apr 2019 15:25:25 GMT):
pythonic, rusty, javish, ... yeah, it doesn't seem to scale across wrappers

rjones (Mon, 08 Apr 2019 15:49:46 GMT):
Has joined the channel.

rjones (Mon, 08 Apr 2019 15:50:08 GMT):
@nage previous project I was on called those "bindings"

MALodder (Mon, 08 Apr 2019 15:50:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=6tPoARjCzWHnra5Rx) @rjones +1

nage (Mon, 08 Apr 2019 16:37:22 GMT):
https://forms.gle/9y9TovnqsAGwfsys7 the survey promised. I will compile a set of answers and re-release an updated version around my lunchtime tomorrow

nage (Mon, 08 Apr 2019 16:38:08 GMT):
You can come back and edit your responses to add support to new suggestions, so feel free to check back later

nage (Mon, 08 Apr 2019 16:38:08 GMT):
You can come back and edit your responses to add support to new suggestions, so feel free to answer it now and then also check back later

rjones (Mon, 08 Apr 2019 17:11:22 GMT):
I added @danielhardman and @nage as group "maintainers" for all of the subgroups of the Indy Common team, and I moved all the existing groups under Indy Common. The role of group maintainer is distinct from code maintainer, so you two can feel free to promote others in the group to maintainer status if you need more cover

nage (Mon, 08 Apr 2019 17:13:36 GMT):
thanks @rjones

nage (Mon, 08 Apr 2019 17:30:11 GMT):
A warning on google forms, when I edit lines the responses disappear (I had to readd one of my responses because I added a better description someone suggested)

nage (Mon, 08 Apr 2019 17:35:11 GMT):
If you have already voted for Hyperledger Cardinal, you may need to update your submission and vote for it again

nage (Mon, 08 Apr 2019 17:45:17 GMT):
(the not updated responses are also listed, so I can do the math)

nage (Mon, 08 Apr 2019 21:09:56 GMT):
Up to 15 responses now.

nage (Mon, 08 Apr 2019 21:18:48 GMT):
Kava, Unity and Edge are being thrown out for "real good reasons"

nage (Mon, 08 Apr 2019 21:19:04 GMT):
(drug, game engine, and mainstream web browser)

nage (Mon, 08 Apr 2019 21:19:28 GMT):
Other options are being added, so update your vote as you'd like

danielhardman (Mon, 08 Apr 2019 23:05:00 GMT):
Okay, I raised a PR that suggests how we can streamline the process. The main README.md is where the change is concentrated. I moved merging a PR earlier, created a new status called "adopted". I also shortened made the readme way less wordy.

danielhardman (Mon, 08 Apr 2019 23:05:00 GMT):
Okay, I raised a PR against the indy-hipe repo that suggests how we can streamline the HIPE process. The main README.md is where the change is concentrated. I moved merging a PR earlier, created a new status called "adopted". I also made the readme way less wordy.

danielhardman (Mon, 08 Apr 2019 23:05:00 GMT):
Okay, I raised a PR against the indy-hipe repo that suggests how we can streamline the HIPE process. The main readme is where the change is concentrated. I moved merging a PR earlier, created a new status called "adopted". I also made the readme way less wordy. https://github.com/hyperledger/indy-hipe/pull/113

danielhardman (Mon, 08 Apr 2019 23:05:50 GMT):
The PR will have to be updated at least once because it proposes that we have two folders, /features and /concepts. This would replace /text and /design, respectively. So either we have to add a folder rename to the PR, or we have to change the PR to keep /text and /design.

rjones (Mon, 08 Apr 2019 23:36:05 GMT):
I fixed up https://github.com/hyperledger/indy-sdk-python let me know if you see anything... odd

TelegramSam (Tue, 09 Apr 2019 15:43:17 GMT):
Newly Merged HIPEs: 02 - Agents Explainer 35 - Json-ld compat 36 - mediators and relays 37 - repudiation explainer

danielhardman (Wed, 10 Apr 2019 02:18:48 GMT):
I added a section about negotiating protocol version into the protocol explainer HIPE: https://github.com/hyperledger/indy-hipe/blob/a1b4544da66c47a2682f9e92103d1f0c2b04a42a/text/protocols/semver.md#version-negotiation

danielhardman (Wed, 10 Apr 2019 02:18:48 GMT):
I added a section about negotiating protocol version into the protocol explainer HIPE: https://github.com/hyperledger/indy-hipe/blob/c9b0888016d924e5f57abc04a5a08a09773f08f5/text/protocols/semver.md#version-negotiation

pmaruindy (Wed, 10 Apr 2019 02:46:57 GMT):
Has joined the channel.

nage (Wed, 10 Apr 2019 14:35:38 GMT):
Last chance to respond to the naming poll before I close it and start the next round https://forms.gle/cnB9UwrWBQdnGeYG6

MALodder (Wed, 10 Apr 2019 17:08:40 GMT):
https://github.com/jedisct1/wasm-crypto Interesting library for implementer to use. It’s the same authors of libsodium

nage (Thu, 11 Apr 2019 04:31:45 GMT):
There were no clear winners in the name survey, but we did get some very helpful feedback about the names that were on the list and some good new suggestions. The top vote getters were {Fidus, Union, Unity, Connector, Cinch, Cardinal} but none received more than 6/20 votes in favor and Unity was disqualified as it is in common use as the Unity Engine. Connector, Fidus and Cardinal all received some negative feedback, but nothing I saw as disqualifying (they did not have copyright or trademark issues, but some expressed dislike over length, being too generic, or having unfavorable sounds or association to the project being unclear. There were also a couple of great late suggestions like Hyperledger Aries (a constellation represented by a ram, often a golden ram, which could fit nicely with Ursa and doesn't sound unpleasant beside Indy). Someone also suggested coming up with another try at a made up name (Kava had a meaning not intended by its recommender). I will compile a new survey with the leaders and a couple of the new suggestions to share in the Indy call tomorrow which we will circulate more widely.

nage (Thu, 11 Apr 2019 04:47:19 GMT):
The next round poll https://forms.gle/5s879DB2Kp37DZYe7

nage (Thu, 11 Apr 2019 05:00:41 GMT):
If you responded to the previous poll you still need to respond to this one (we want to see which choice emerges as a favorite, if any, now that we have started narrowing the field)

reithmayer (Thu, 11 Apr 2019 06:37:22 GMT):
Has joined the channel.

nage (Thu, 11 Apr 2019 14:33:44 GMT):
Some feedback on the names. Fidus is getting feedback that it is too close to Fido as in Fido alliance, and some sentiment that it sounds funny. Union and Connector are getting multiple reports of "too generic" meaning there is no way to say "I work on the Connector project" and have it feel like you are referring to something specific.

nage (Thu, 11 Apr 2019 14:34:08 GMT):
Many of the suggestions this round are also too vague to be actionable "Hyperledger Safe" or "Hyperledger Friendly"

nage (Thu, 11 Apr 2019 14:34:43 GMT):
but there are a few interesting new suggestions like "Hyperledger Nyasa".

nage (Thu, 11 Apr 2019 14:35:49 GMT):
we are already to more responses than the last poll and a group of winners and losers appears to be emerging.

nage (Thu, 11 Apr 2019 14:55:57 GMT):
Nyasa is also the name of an ethnic group in Africa, probably shouldn't add it unless we had contributors or significant adoption and support from that group.

swcurran (Thu, 11 Apr 2019 14:57:03 GMT):
I agree on that @nage.

danielhardman (Fri, 12 Apr 2019 23:50:04 GMT):
I have begun writing a new HIPE draft about Message Trust Contexts. I'm doing the early draft work on hackmd.io instead of github as an experiment. Let me know what you think: https://hackmd.io/s/HJG3et9KV

rjones (Sat, 13 Apr 2019 00:06:38 GMT):
Could I ask Indy maintainers to please join https://lists.hyperledger.org/g/maintainers ? I'd appreciate it.

mtfk (Mon, 15 Apr 2019 20:14:30 GMT):
Has joined the channel.

helengarneau (Tue, 16 Apr 2019 16:51:41 GMT):
Has joined the channel.

TelegramSam (Wed, 17 Apr 2019 20:32:53 GMT):
New Comment on the HIPE change PR: https://github.com/hyperledger/indy-hipe/pull/113#issuecomment-484249957 @danielhardman @swcurran

danielhardman (Wed, 17 Apr 2019 20:38:51 GMT):
Responded.

SteveGoob (Wed, 17 Apr 2019 23:56:27 GMT):
Has joined the channel.

TelegramSam (Thu, 18 Apr 2019 15:32:58 GMT):
Indy Agent calls update with a Summary using the `{excerpt}` macro. Notice how I can pull the summaries up to the meeting list page https://wiki.hyperledger.org/display/indy/Indy+Agent+Working+Group

TelegramSam (Thu, 18 Apr 2019 15:32:58 GMT):
@nage ^

nage (Thu, 18 Apr 2019 15:33:41 GMT):
Cool. Now to repeat this pattern in our other call notes pages

swcurran (Thu, 18 Apr 2019 15:39:39 GMT):
Bonus points for @TelegramSam!

dbluhm (Thu, 18 Apr 2019 16:27:48 GMT):
Regarding @rjones comment on failed DCO checks in #indy, it looks like the repositories with 1 commit failing are the initial commits

rjones (Thu, 18 Apr 2019 17:26:57 GMT):
@dbluhm good

rjones (Thu, 18 Apr 2019 17:29:16 GMT):
@nage: https://github.com/hyperledger-archives/indy-anoncreds

rjones (Thu, 18 Apr 2019 17:31:06 GMT):
```indy-node commits fail DCO: 2191 indy-plenum commits fail DCO: 24117 indy-sdk commits fail DCO: 12818 ```

rjones (Thu, 18 Apr 2019 17:31:06 GMT):
``` indy-plenum commits fail DCO: 24117 indy-sdk commits fail DCO: 12818 ```

rjones (Thu, 18 Apr 2019 17:31:06 GMT):
in descending order: ``` indy-plenum commits fail DCO: 24117 indy-sdk commits fail DCO: 12818 indy-node commits fail DCO: 2191```

nage (Thu, 18 Apr 2019 20:12:28 GMT):
@rjones thanks for archiving that one

nage (Thu, 18 Apr 2019 20:13:02 GMT):
what action are we after here, do we want to rewrite history to add signed-off-by (in most cases we could probably add it) or just acknowledge that these changes happened prior to dco-bot?

rjones (Thu, 18 Apr 2019 20:14:20 GMT):
@nage this is what iroha tried to do: contact the people with commits that did not have a SoB, and have them sign a commit on master that attested to the authorship and DCO-ness of all commits in the project repo to that point in time

rjones (Thu, 18 Apr 2019 20:15:51 GMT):
they couldn't find everyone, so they had to squash. If indy is going to do a lot of repo-tetris, I implore you to use a tool like `git filter-branch` to add DCO in the right places, and make sure you prune files you don't want to bring over etcetera.

nage (Thu, 18 Apr 2019 20:56:06 GMT):
sounds like time to build a plan

nage (Thu, 18 Apr 2019 20:56:15 GMT):
I will add it to the maintainers call agenda

nage (Thu, 18 Apr 2019 20:57:04 GMT):
@esplinr and @MALodder ^^^

MALodder (Thu, 18 Apr 2019 20:58:29 GMT):
I have a script that fixes this having done it multiple times with ursa and indy-crypto

rjones (Thu, 18 Apr 2019 21:18:59 GMT):
@MALodder https://gist.github.com/ryjones/04f35c7610f2cdd17e517eea2ca072bf line 60 says indy-crypto has a lot of unsigned commits though?

MALodder (Thu, 18 Apr 2019 21:19:16 GMT):
yes, when we merged it into ursa, we fixed those

MALodder (Thu, 18 Apr 2019 21:19:28 GMT):
indy-crypto is going to be archived within a month

MALodder (Thu, 18 Apr 2019 21:19:43 GMT):
I don't think we need to go back and fix it do we?

rjones (Thu, 18 Apr 2019 21:22:08 GMT):
oh OK. no. I misunderstood what you were saying

swcurran (Thu, 18 Apr 2019 21:24:07 GMT):
@MALodder - what is the script? Can you share it?

MALodder (Thu, 18 Apr 2019 21:24:41 GMT):
sure, its more a set of commands ``` ```

MALodder (Thu, 18 Apr 2019 21:24:46 GMT):
``` git unite two separate repos git needed use for project_b git filter-branch -f --msg-filter 'cat | grep -v Signed-off-by: && echo "\nSigned-off-by: $GIT_AUTHOR_NAME <$GIT_AUTHOR_EMAIL>"' master HEAD git clone git@github.com:bcgov/project_a cd project_a git remote add project_b git@github.com:hyperledger/project_b git fetch project_b git checkout -b project_b project_b/master git rebase master ```

rangak (Thu, 18 Apr 2019 23:10:49 GMT):
Has joined the channel.

danielhardman (Fri, 19 Apr 2019 20:31:42 GMT):
new HIPE proposal on message trust contexts: https://github.com/hyperledger/indy-hipe/pull/120

Raja_Sabarish (Mon, 22 Apr 2019 10:19:44 GMT):
Has joined the channel.

nage (Mon, 22 Apr 2019 14:31:44 GMT):
@here a reminder of the Maintainers call that starts in 29 minutes here https://zoom.us/j/615818107

rrishmawi (Tue, 23 Apr 2019 12:52:56 GMT):
Has joined the channel.

swcurran (Tue, 23 Apr 2019 19:59:53 GMT):
Hmmm...the Linux Foundation is giving out credentials -- using another platform (Credly/Acclaim). We need to work on them to use an Indy-based platform for that...

rjones (Tue, 23 Apr 2019 20:01:20 GMT):
@swcurran news to me - link?

rjones (Tue, 23 Apr 2019 20:01:20 GMT):
@swcurran https://training.linuxfoundation.org/badges/ this?

swcurran (Tue, 23 Apr 2019 20:03:30 GMT):
Yup. They just offered me one.

rjones (Tue, 23 Apr 2019 20:16:26 GMT):
Agreed, we need to dogfood

rjones (Tue, 23 Apr 2019 20:16:26 GMT):
Agreed, LF needs to dogfood

nage (Wed, 24 Apr 2019 20:07:49 GMT):
The Hyperledger Aries project proposal is now up on the wiki here https://wiki.hyperledger.org/display/HYP/Hyperledger+Aries+Proposal I am a bit over-eager to get it in front of the TSC so that we can try and recruit contributors from Ethereum and other traditional identity systems at the Internet Identity Workshop and DIF meetings next week in Mountain View, CA, so go take a look!

rjones (Wed, 24 Apr 2019 20:43:18 GMT):
@nage could you give me an example of what you would want to remove from the indy-sdk repo as part of the effort to move to aries?

nage (Wed, 24 Apr 2019 20:43:49 GMT):
The ledger.rs modules will stay in Indy

nage (Wed, 24 Apr 2019 20:44:04 GMT):
along with a couple of the other Indy-specific parts of the SDK

nage (Wed, 24 Apr 2019 20:44:13 GMT):
the rest will move over (it will require some refactoring work)

rjones (Wed, 24 Apr 2019 20:44:31 GMT):
what I want to do is shaped something like this: archive the indy-sdk repo to hyperledger-archives org, then make the new repos

rjones (Wed, 24 Apr 2019 20:44:41 GMT):
unless I misunderstand what you're proposing

nage (Wed, 24 Apr 2019 20:44:47 GMT):
we will not be in a big hurry to do that

nage (Wed, 24 Apr 2019 20:45:07 GMT):
I expect we will do a round of refactoring in place in Indy first, then we would be ready to do something like what you are proposing

rjones (Wed, 24 Apr 2019 20:45:49 GMT):
I see. What you propose is an extraction of code from indy-sdk into the new repo, with a gradual wind down of indy-sdk on some timeline that I'm not concerned about

rjones (Wed, 24 Apr 2019 20:47:15 GMT):
you asked a reasonable question (please give me an example and directions) so I wanted to try it in a concrete way

rjones (Wed, 24 Apr 2019 21:00:36 GMT):
Looking at the indy-sdk repo with 12818 commits without DCO, I propose you squash and start a new repo.

nage (Wed, 24 Apr 2019 21:14:55 GMT):
This confuses me. Are you saying that someone has done commits without following process? Are there historic commits where DCO didn't yet apply?

nage (Wed, 24 Apr 2019 21:15:14 GMT):
Saying it this way makes it sounds like we are somehow compromised.

esplinr (Wed, 24 Apr 2019 21:34:03 GMT):
indy-sdk isn't going to go away. The proposal is just for it to get thinner.

esplinr (Wed, 24 Apr 2019 21:34:03 GMT):
With the creation of Aries, indy-sdk isn't going to go away. The proposal is just for it to get thinner.

esplinr (Wed, 24 Apr 2019 21:34:03 GMT):
indy-sdk isn't going to go away with the creation of Aries. The proposal is just for it to get thinner.

esplinr (Wed, 24 Apr 2019 21:36:47 GMT):
I don't think it's a good idea to discard the Indy SDK repo over the report of DCO errors. The team believes that the DCO bot has been a required part of the Indy SDK pipeline since it was instituted by Hyperledger. All the code before that time was contributed by Evernym who can legally agree to the DCO statement on behalf of the author.

nage (Wed, 24 Apr 2019 21:52:07 GMT):
@swcurran++ thanks for updates/edits on the Aries proposal doc.

danielhardman (Fri, 26 Apr 2019 18:39:59 GMT):
Can we merge @kdenhartog 's indy-hipe PR that's not HIPE-related but that rather updates /README.md to list known protocols? I think it's not controversial, and it would be nice to have the root README updated to make protocols more discoverable...

danielhardman (Fri, 26 Apr 2019 18:41:12 GMT):
Can we merge the localized messages HIPE (https://github.com/hyperledger/indy-hipe/pull/64)? It's been at FCP status for 23 days, and was quite mature even before that.

kdenhartog (Fri, 26 Apr 2019 20:56:37 GMT):
I support merging localized messages. I'll abstain from seconding my own HIPE.

kdenhartog (Fri, 26 Apr 2019 21:01:36 GMT):
I'm working on the Signatures decorator HIPE now, and am having second thoughts about using JWS instead of JWT format particularly because I repeatedly see JWT being used, and not JWS. I think this would make for an easy constraint, but before I move forward with this change, I wanted to poll the opinions of others. @TelegramSam @swcurran @danielhardman @nage @tplooker @tomislav where do you guys fall with regards to this?

danielhardman (Fri, 26 Apr 2019 22:39:18 GMT):
I like JWS instead of JWT. The ubiquity of JWT is only relevant if we are fully willing to live within JWT's constraints. I don't think we are.

raj_shekhar (Mon, 29 Apr 2019 08:05:20 GMT):
Has joined the channel.

nage (Mon, 29 Apr 2019 16:02:45 GMT):
I agree with Daniel, I prefer JWS as the dependency over JWT. If you're at IIW, it would be good to discuss this with the JW* experts there

dbluhm (Mon, 29 Apr 2019 16:20:21 GMT):
I submitted a couple of PRs to indy-hipe with minor updates for the Agent Message Structure and Message Type HIPEs. A quick review from one of the repo maintainers would be appreciated. @danielhardman @TelegramSam

tplooker (Mon, 06 May 2019 03:27:17 GMT):
The Mattr team is pleased to announce the open sourcing of osma - an open source mobile agent built on top of AgentFramework (https://github.com/streetcred-id/agent-framework), this project is still in development but we hope it will be of great community value to accelerate the development of mobile agents. Check it out at https://github.com/mattrglobal/osma and get in touch if you have any queries!

barotashish (Mon, 06 May 2019 09:59:44 GMT):
Has joined the channel.

esplinr (Mon, 06 May 2019 14:09:34 GMT):
Very cool.

esplinr (Mon, 06 May 2019 14:09:44 GMT):
@tplooker How is the Mattr team related to Spark?

nage (Mon, 06 May 2019 14:59:47 GMT):
https://docs.google.com/document/d/1d_SnxinX54Sx-0TwRTnSJK6p_ZN27ZvoI3ytha1QS28/edit#

nage (Mon, 06 May 2019 14:59:52 GMT):
One more week in the google doc

tplooker (Mon, 06 May 2019 19:24:10 GMT):
@esplinr Mattr is a new spin out from Spark

esplinr (Mon, 06 May 2019 21:00:55 GMT):
Interesting. Thank you.

danielhardman (Mon, 06 May 2019 21:19:34 GMT):
FYI: I merged 4 PRs that were getting stale that were not HIPEs and were not particularly controversial. Two were from Daniel Bluhm and fixed broken hyperlinks. One was from Kyle DH and added a list of protocols that are well known within our community. One was from Oskar van Deventer and pointed out some security considerations that should be understood with the connection protocol.

kdenhartog (Mon, 06 May 2019 22:53:45 GMT):
Just got my document sent up to the indy mailing list. Here's a link for convenience. https://docs.google.com/document/d/1nMBfeKkoKojPTg81pqajVaxgPihHXraaJBJpAaO1vxI/edit?usp=sharing

kdenhartog (Tue, 07 May 2019 03:18:44 GMT):
Did anyone actually see this go through the Indy mailing list? I haven't seen it yet.

Raja_Sabarish (Tue, 07 May 2019 12:58:45 GMT):
Has left the channel.

Raja_Sabarish (Tue, 07 May 2019 17:24:51 GMT):
Has left the channel.

twshelton (Tue, 07 May 2019 17:57:34 GMT):
Has joined the channel.

twshelton (Tue, 07 May 2019 17:59:49 GMT):
I just received it

rjones (Tue, 07 May 2019 18:03:13 GMT):
@kdenhartog it was held up for moderation. I think the address you send it from wasn't subscribed

kdenhartog (Tue, 07 May 2019 18:04:55 GMT):
Ahh gotcha, thanks for helping get it through. I registered a *@kyledenhartog.com domain, but I still haven't bothered to figure out how to send from those yet.

twshelton (Tue, 07 May 2019 19:16:03 GMT):
when is the next call? I found them on the calendar but looks like from the notes that the time varies?

kdenhartog (Tue, 07 May 2019 19:26:37 GMT):
The calendar lists the correct times. We're trying a new format where we switch every other meeting so that we can accommodate more timezones.

esplinr (Tue, 07 May 2019 19:58:41 GMT):
I t doesn't look like the Hyperledger calendar has been updated with the new schedule. I believe that the next meeting is May 20th at 6PM US Eastern, then June 3 at 11AM US Eastern.

esplinr (Tue, 07 May 2019 19:59:15 GMT):
And then the rotation continues.

arjanvaneersel (Wed, 08 May 2019 11:10:01 GMT):
Has joined the channel.

twshelton (Wed, 08 May 2019 14:23:24 GMT):
thanks @esplinr @kdenhartog

kdenhartog (Tue, 14 May 2019 00:20:22 GMT):
@esplinr @nage Is there a HIPE available to read for the TAA stuff? I'm concerned that functionality is being added without achieving some level of community consensus around its design first.

swcurran (Tue, 14 May 2019 03:05:44 GMT):
Transaction Author Agreements are in JIRA.

kdenhartog (Tue, 14 May 2019 07:57:56 GMT):
Thanks, I didn't think to look there. Would it be possible to have this work go through the HIPE process since it's a significant "chunk~s~ of technology or process that are important to standardize across the Indy ecosystem". I don't think it would be controversial and could move quickly through there. However, I think it's important that we set good precedents early on that all must follow the process to make significant changes like this.

kdenhartog (Tue, 14 May 2019 07:57:56 GMT):
Thanks, I didn't think to look there. Would it be possible to have this work go through the HIPE process since it's a significant "chunk of technology or process that are important to standardize across the Indy ecosystem". I don't think it would be controversial and could move quickly through there. However, I think it's important that we set good precedents early on that all must follow the process to make significant changes like this.

kdenhartog (Tue, 14 May 2019 07:57:56 GMT):
Thanks, I didn't think to look there. Would it be possible to have this work go through the HIPE process since it's a significant "chunk of technology or process that are important to standardize across the Indy ecosystem". I don't think it would be controversial and could move quickly through there. However, I think it's important that we set good precedents early on that everyone must follow the process to make significant changes like this.

tijohnson (Tue, 14 May 2019 14:38:30 GMT):
@all Emergency shutdown of Jenkins build servers required known security issue in Jenkins that is actively being exploited

tijohnson (Tue, 14 May 2019 14:54:19 GMT):
@all Emergency shutdown complete production & sandbox both back on-line

danielhardman (Tue, 14 May 2019 17:27:21 GMT):
+1 to TAA going through HIPE

esplinr (Tue, 14 May 2019 17:46:00 GMT):
The Transaction Author Agreement is tracked as part of this epic: https://jira.hyperledger.org/browse/INDY-1942

esplinr (Tue, 14 May 2019 17:46:00 GMT):
The Transaction Author Agreement is tracked as part of this epic: https://jira.hyperledger.org/browse/INDY-1942 The design is here: https://github.com/hyperledger/indy-node/blob/master/design/txn_author_agreement.md

esplinr (Tue, 14 May 2019 17:46:40 GMT):
I find the HIPE process to be painful for requirements gathering with lots of stakeholders.

esplinr (Tue, 14 May 2019 17:47:02 GMT):
It's an optional capability.

esplinr (Tue, 14 May 2019 17:47:02 GMT):
It's an optional capability. I don't consider it significant or important for standardization.

esplinr (Tue, 14 May 2019 17:47:02 GMT):
It's an optional capability. I don't consider it significant or important for standardization across the ecosystem. Perhaps I was wrong with that assessment.

esplinr (Tue, 14 May 2019 17:49:07 GMT):
We have a pretty good process in place for gathering requirements in JIRA and then generating a plan of attack in GitHub. I'll have to think about how that should change in the future.

esplinr (Tue, 14 May 2019 17:49:49 GMT):
Would the design document in the Indy Node repository be the HIPE, or would you be expecting something different?

kdenhartog (Tue, 14 May 2019 18:56:15 GMT):
That document looks like a good start, but it doesn't help me to discover why this part is necessary. (I know it because I've been on the calls, but I'm speaking up to help others who lurk)

kdenhartog (Tue, 14 May 2019 19:07:14 GMT):
I understand the process can be arduous, but it's the most effective thing we have for the amount of active contributors we have in the ecosystem. We'll find ways to improve it and make it go faster when necessary as we go along I believe. Again, my only concern is that we're making decisions as a community, and with the Jira/Github design process it doesn't seem the majority of the community looks there to discuss design proposals and improvements.

kdenhartog (Tue, 14 May 2019 19:08:20 GMT):
I think combining this jira ticket https://jira.hyperledger.org/browse/INDY-1942 with the Node doc would be a good direction

nage (Tue, 14 May 2019 19:13:38 GMT):
We discussed moving it into a HIPE multiple times, but since all the requirements are effectively owned by legal requirements that were hashed out in the Governance Framework Working Group and the Global Policy Working Group inside Sovrin, it didn't feel right to pursue it that way. We could certainly have someone summarize it into a HIPE md document, but the ticket seems like the right place to collaborate on it. @Sean_Bohan it might be a good idea to have that group present again at the Indy call to help people keep track of what is going on?

kdenhartog (Tue, 14 May 2019 19:26:28 GMT):
I think that's fine that GFWG and GPWG are defining the requirements and we can clearly state and link to those requirements in the HIPE. However, I don't thin it's good precedent to create a new process for each special circumstance to get certain work done. We have a process that works, where we have more than just the implementation team discussing how it's architected and implemented.

nage (Tue, 14 May 2019 19:28:29 GMT):
No argument about having standard process to help keep people informed. I would suggest that JIRA tickets and release notes will always be the best source of that type of notification, as there will always be disagreements about who/what/where/why on features (not that this justifies any particular case). I would support creation of a HIPE if you or anyone else can volunteer time to create such.

kdenhartog (Tue, 14 May 2019 19:29:37 GMT):
I don't know nearly enough about how the system works nor where I can find that info to write a HIPE. This is the main reason I'm asking for a HIPE in this specific instance.

kdenhartog (Tue, 14 May 2019 19:29:37 GMT):
I don't know nearly enough about how this improvement works nor where I can find that info to write a HIPE. This is the main reason I'm asking for a HIPE in this specific instance.

nage (Tue, 14 May 2019 19:39:37 GMT):
The ticket Richard links to and the design document are both pretty detailed. Probably sufficient to be turned into a HIPE, though they don't follow the same format

kdenhartog (Tue, 14 May 2019 19:44:24 GMT):
The format that's commonly used isn't required I believe. If there's a format that works better for them, I wouldn't be opposed to that.

kdenhartog (Tue, 14 May 2019 19:52:58 GMT):
The end goal I'd like to see is that we're all using one process to audit and discuss feature additions and architectural improvements. I know in the past we've used jira tickets to manage community work, but now that we have a more effective process in place that's working for the majority of the community, I'd like to see us all using it.

kdenhartog (Tue, 14 May 2019 19:52:58 GMT):
The end goal I'd like to see is that we're all using one process to audit and discuss feature additions and architectural improvements. I know in the past we've used jira tickets to manage community work (and effectively do this), but now that we have a more effective process in place that's working for the majority of the community, I'd like to see us all using it.

esplinr (Wed, 15 May 2019 00:00:53 GMT):
I don't think it is realistic for all changes to go through one process.

esplinr (Wed, 15 May 2019 00:01:13 GMT):
And I woludn't call the HIPE process more effective.

esplinr (Wed, 15 May 2019 00:02:39 GMT):
As for presenting again on the Transaction Author Agreement in the Thursday calls, I discussed that with @Sean_Bohan and he likes the idea. We would prefer to do it an a week or two when we have a proposed implementation ready to show the specific API changes.

esplinr (Wed, 15 May 2019 00:04:55 GMT):
I like the HIPE process for achieving consensus on interoperability questions. But I don't think it should be a committee controlling gating every improvement. I'd rather people be empowered to act first so long as they don't break anyone.

kdenhartog (Wed, 15 May 2019 00:05:59 GMT):
That's how you end up with bad community dynamics where maintainers have more control over the direction of the system of the community. This is exactly what I want to avoid.

kdenhartog (Wed, 15 May 2019 00:05:59 GMT):
That's how you end up with bad community dynamics where maintainers have more control over the direction of the system than the community. This is exactly what I want to avoid.

kdenhartog (Wed, 15 May 2019 00:38:15 GMT):
I guess I'm just confused why there's opposition to seeing this work go through an RFC process at this point. Is having work going through an public comment period going to impede you?

esplinr (Wed, 15 May 2019 00:42:24 GMT):
My concern is the time and energy investment, and a culture of having to get permission and design by committee before making changes. We worked with the SDK and Ledger maintainers, and announced the changes in the joint maintainers meeting and Thursday Indy calls. People had the opportunity to participate. This wasn't done in secrete. Other parties could have been more involved if they chose.

esplinr (Wed, 15 May 2019 00:42:24 GMT):
My concern is the time and energy investment, and a culture of having to get permission and design by committee before making changes. We worked with the SDK and Ledger maintainers, and announced the changes in the joint maintainers meeting and Thursday Indy calls. People had the opportunity to participate. This wasn't done in secret. Other parties could have been more involved if they chose.

esplinr (Wed, 15 May 2019 00:43:01 GMT):
I have no objection to someone writing up the HIPE. The stewards of the Sovrin network asked for this to be in the May release, and we are working hard to meet that goal in a way that doesn't break anyone.

kdenhartog (Wed, 15 May 2019 00:43:04 GMT):
Aren't the ledger and sdk maintainers the ones who implemented this?

esplinr (Wed, 15 May 2019 00:43:27 GMT):
A portion of the ledger and SDK maintainers implemented this.

kdenhartog (Wed, 15 May 2019 00:43:44 GMT):
Was there anyone else other than them who worked on it?

esplinr (Wed, 15 May 2019 00:44:42 GMT):
I don't understand your question. The Evernym team did the work. Some of that team are maintainers, but some are not. We got feedback on the proposal from a broader group of people at the Sovrin Foundation, in the Indy Maintainers call (Mondays) and the Indy Working Group call (Thursdays), as well as people watching in Jira and GitHub.

esplinr (Wed, 15 May 2019 00:45:15 GMT):
Considering how much of the Indy Maintainers call we spend discussing HIPEs, I felt like there was consensus that a HIPE wasn't required here.

esplinr (Wed, 15 May 2019 00:46:12 GMT):
Hmm, looking at the Indy Maintainers Agenda, maybe we didn't make it a formal discussion item. It was a formal discussion item at a couple of the Thursday calls.

esplinr (Wed, 15 May 2019 00:46:21 GMT):
I need to go. We can discuss more tomorrow.

kdenhartog (Wed, 15 May 2019 00:49:56 GMT):
No worries, we should probably discuss this more on the next maintainers call anyway. Just to be clear, I don't want to block this work. I would like for us to retroactively write a HIPE describing the work though and in the future plan around writing HIPEs for changes that are added. Maybe we need to add a way to expedite HIPEs like this one which would be non-contentious. At least then we have a common library of references and resources to document the system.

esplinr (Wed, 15 May 2019 00:52:01 GMT):
There are differing opinions (including on my team) about whether HIPEs should be a one stop shop of info, or whether they should just be certain aspects of the system. I am of the opinion that most of the design and documentation should be in the affected projects and should not require HIPEs.

esplinr (Wed, 15 May 2019 00:52:01 GMT):
There are differing opinions (including on my team) about whether HIPEs should be a one stop shop of info, or whether they should just cover aspects of the system important for interoperability. I am of the opinion that most of the design and documentation should be in the affected projects and should not require HIPEs.

kdenhartog (Wed, 15 May 2019 00:52:24 GMT):
In my mind HIPEs are valuable for two reasons: 1. They provide a process for achieving community consensus on contentious work. 2. They provide a common place to document functionality across IndySDK and Indy Node.

esplinr (Wed, 15 May 2019 00:52:47 GMT):
I think the second goal is better served in the Indy SDK and Indy Node projects.

kdenhartog (Wed, 15 May 2019 00:56:09 GMT):
Let's talk more about this on the maintainer call. If that's what we agree upon I can go with it, but the reason I have been so frustrated at this is because I thought HIPEs were the ubiquitous way to document the second part and then I checked the IndySDK PRs and see the TAA work being done, but didn't know where I needed to go to read more about the current design since it was last discussed.

kdenhartog (Wed, 15 May 2019 01:15:24 GMT):
Speaking of maintainers call, is the call on 5-19 at 4pm Mountain time or 9am? It looks like it's 4pm on the agenda, but my calendar shows 9am.

esplinr (Wed, 15 May 2019 13:01:03 GMT):
I don't think Nathan has updated the calendar appointment yet. It is supposed to rotate between 4PM Mountain and 9AM Mountain.

esplinr (Wed, 15 May 2019 14:04:47 GMT):
I agree that we need a common understanding about the role of HIPEs. There have been a few times where the differing expectations have caused consternation.

nage (Wed, 15 May 2019 15:02:26 GMT):
I also want to be very careful here @kdenhartog , we *never* want the HIPE process to be used as a tool to prevent folks from making needed or wanted contributions from a use case perspective (that would be the wrong kind of process), but we *do* want to make sure the process helps us work together and get things done more quickly. Lets see if we can focus on what meets both of those goals as we standardize how and when HIPEs should be used

esplinr (Wed, 15 May 2019 15:03:02 GMT):
I don't think HIPEs can be the ubiquitous source of all things Indy. It's a large project, and I would rather keep the different components as independent as possible and keep decision making within the impacted teams as much as possible.

esplinr (Wed, 15 May 2019 15:03:33 GMT):
Especially since most users will need to follow indy-hipe, sovrin-sip, and aries-rfc. So there won't ever be a one-stop location for information.

nage (Wed, 15 May 2019 15:04:18 GMT):
The bigger challenge is aggregating the news up so that people can follow along as the teams they don't primarily work with make breakthroughs

esplinr (Wed, 15 May 2019 15:04:33 GMT):
Agreed.

nage (Wed, 15 May 2019 15:04:35 GMT):
the idea was to have headline summaries that can help everyone know when and where to dig more deeply

nage (Wed, 15 May 2019 15:04:47 GMT):
Evernym's youtube sprint demos are a good example of how to help with this

esplinr (Mon, 20 May 2019 13:32:02 GMT):
@nage What is the plan for the Indy Maintainers call today?

esplinr (Mon, 20 May 2019 13:32:43 GMT):
The Hyperledger calendar isn't updated to reflect our plan of meeting at 4PM Mountain time (~23UTC).

twshelton (Mon, 20 May 2019 13:36:15 GMT):
The Indy Maintainers call is at 4:00P Mountain TODAY and not 5-19 ... correct?

TelegramSam (Mon, 20 May 2019 14:23:51 GMT):
Maintainers call today, in 37 minutes. (9am mountain). Nage is on a plane, so I'll be running the call.

TelegramSam (Mon, 20 May 2019 14:27:10 GMT):
We didn't get the appointment changed yet. Apologies.

rjones (Mon, 20 May 2019 15:55:35 GMT):
@TelegramSam send mail to c-a to let us know what you want changed

esplinr (Mon, 20 May 2019 16:03:32 GMT):
Wait, we did the call at 9?

esplinr (Mon, 20 May 2019 16:03:39 GMT):
I'm so confused.

jljordan_bcgov (Mon, 20 May 2019 16:59:11 GMT):
FYI .. a holiday today in Canada ... celebrating Queen Victoria's Birthday (was the reigning monarch when Canada was formed in 1867 BTW) :)

kdenhartog (Mon, 20 May 2019 18:13:43 GMT):
[ ](https://chat.hyperledger.org/channel/indy-maintainers?msg=Z3wg6YDPjXkPyGKQc) @esplinr A few of us joined just in case, but we're still planning to host one at 4pm today.

kdenhartog (Mon, 20 May 2019 18:14:54 GMT):
@twshelton that's correct its 4pm mountain time today

tomislav (Mon, 20 May 2019 19:54:53 GMT):
@kdenhartog Same zoom invite?

kdenhartog (Mon, 20 May 2019 19:55:06 GMT):
should be yup!

tomislav (Mon, 20 May 2019 19:55:22 GMT):
Great thanks.

esplinr (Mon, 20 May 2019 22:03:09 GMT):
We are starting the maintainers call @tplooker @kdenhartog

esplinr (Mon, 20 May 2019 22:03:15 GMT):
https://zoom.us/j/615818107

esplinr (Tue, 21 May 2019 14:28:22 GMT):
As a follow up from yesterday's Maintainers call, here is a link to a recorded introduction to Indy Node and Plenum: https://www.youtube.com/watch?v=WZin717AT_A&list=PLRp0viTDxBWGLdZk0aamtahB9cpJGV7ZF&index=12

esplinr (Tue, 21 May 2019 14:28:32 GMT):
@kdenhartog

esplinr (Tue, 21 May 2019 14:28:32 GMT):
cc @kdenhartog

esplinr (Tue, 21 May 2019 14:32:24 GMT):
Also @tplooker , I checked with the Evernym Indy team, and we are supposed to be adding the JIRA issue number in each pull request in GitHub. So if you don't understand why a commit was added, you can click on the commit history to see the pull request message, and from there you can read the JIRA issue. It does appear that we got a bit inconsistent lately, but the team will renew that habit now that we know people care that we do it.

DarionHernandez (Tue, 21 May 2019 23:35:41 GMT):
Has joined the channel.

kdenhartog (Tue, 28 May 2019 06:21:06 GMT):
https://github.com/hyperledger/indy-sdk/security/advisories

kdenhartog (Tue, 28 May 2019 06:21:20 GMT):
Can we bring back issues now? :woo:

swcurran (Tue, 28 May 2019 14:11:07 GMT):
Way cool!

esplinr (Tue, 28 May 2019 14:43:17 GMT):
That's interesting.

nage (Tue, 28 May 2019 21:13:18 GMT):
We should bring that question up with @dhuseby once he has a chance to review the new feature

rjones (Tue, 28 May 2019 23:43:30 GMT):
I enabled it for all repos that were not mirrors

rjones (Tue, 28 May 2019 23:44:21 GMT):
go here: https://github.com/hyperledger/indy-sdk

rjones (Tue, 28 May 2019 23:44:28 GMT):
click the "used by" button at the top

rjones (Tue, 28 May 2019 23:45:49 GMT):

nice.png

kdenhartog (Tue, 28 May 2019 23:46:23 GMT):
Thanks I noticed that too. That's going to become a super useful feature in time.

rjones (Tue, 28 May 2019 23:47:01 GMT):
https://github.com/hyperledger/indy-sdk/network/dependencies https://github.com/hyperledger/indy-sdk/network/dependents as well

rjones (Tue, 28 May 2019 23:48:24 GMT):
https://github.com/hyperledger/indy-sdk/security/advisories/GHSA-qcfw-8vx4-rh2q can you see this?

kdenhartog (Tue, 28 May 2019 23:48:51 GMT):
nope. I'm not listed as a maintainer on Indy though so it seems to be working as expected.

rjones (Tue, 28 May 2019 23:50:33 GMT):
¯\_(ツ)_/¯

esplinr (Thu, 30 May 2019 18:08:18 GMT):
Where is the "Used By" badge? I see the dependency graph, but not the nice badgen from @rjones' screen shot.

esplinr (Thu, 30 May 2019 18:08:18 GMT):
Where is the "Used By" badge? I see the dependency graph, but not the nice badge from @rjones' screen shot.

rjones (Thu, 30 May 2019 18:10:23 GMT):
upper right on the main repo web page

esplinr (Thu, 30 May 2019 18:11:10 GMT):
Interesting. It appears that one has to be logged in to see it.

rjones (Thu, 30 May 2019 18:11:35 GMT):

Screen Shot 2019-05-30 at 11.11.05 AM.png

esplinr (Thu, 30 May 2019 18:11:40 GMT):
That badge and the dependency graph will be really useful.

twshelton (Mon, 03 Jun 2019 13:32:33 GMT):
Maintainers call today at 11:00A EST?

rjones (Mon, 03 Jun 2019 14:55:38 GMT):
@nage you should be able to edit that meeting

nage (Mon, 03 Jun 2019 14:59:02 GMT):
Thanks Ry. I will give it a shot today

nage (Mon, 03 Jun 2019 14:59:11 GMT):
and yes, the call is starting up now

nage (Mon, 03 Jun 2019 14:59:18 GMT):
https://zoom.us/j/615818107

nage (Mon, 03 Jun 2019 14:59:32 GMT):
I'm working on the wiki meetings notes page right now

nage (Mon, 03 Jun 2019 15:02:36 GMT):
https://wiki.hyperledger.org/display/indy/2019-06-03+Indy+Maintainers+Call

nage (Mon, 03 Jun 2019 15:55:06 GMT):
https://github.com/hyperledger/indy-hipe/pull/119

esplinr (Wed, 05 Jun 2019 14:31:21 GMT):
@nage @rjones Are you still planning on creating #aries-sdk?

nage (Wed, 05 Jun 2019 14:50:13 GMT):
@rjones with the creation of the aries-sdk and aries-sdk- respositories, it is time to create #aries-sdk and #aries-pr-review

rjones (Wed, 05 Jun 2019 15:38:51 GMT):
@esplinr @nage created, you're both owners of those two channels.

nage (Wed, 05 Jun 2019 15:42:13 GMT):
Thanks!

danielhardman (Tue, 11 Jun 2019 18:07:51 GMT):
I would like to propose that PR #119 enter FCP. It has received some comment from the community since it was raised, and the suggestions have all been addressed. If we can adopt the streamlined process, I would recommend that it be merged instead of entering FCP.

danielhardman (Tue, 11 Jun 2019 18:09:59 GMT):
What do you think about merging PR #113 so the indy-hipe repo has the same streamlined process as aries-rfc?

kdenhartog (Fri, 14 Jun 2019 17:24:48 GMT):
Second to that!

kdenhartog (Fri, 14 Jun 2019 17:39:57 GMT):
@TelegramSam can you update approve the Indy-HIPE PRs for the suggestions @danielhardman provided above?

esplinr (Mon, 17 Jun 2019 22:03:07 GMT):
We are ready to start the Indy Maintainers call. https://zoom.us/j/615818107

esplinr (Mon, 17 Jun 2019 22:03:29 GMT):
@tplooker @nage @kdenhartog

tplooker (Mon, 17 Jun 2019 22:05:25 GMT):
Sorry I wont be able to make it today, will review the recording

esplinr (Mon, 17 Jun 2019 22:05:26 GMT):
Agenda edit link: https://wiki.hyperledger.org/pages/resumedraft.action?draftId=13863186&draftShareId=2e7190f9-d79b-40ac-a935-9bf87c5db287&

esplinr (Mon, 17 Jun 2019 23:18:24 GMT):
Sorry @tplooker , we haven't usually recorded that call and I don't think anyone pushed the button.

esplinr (Mon, 17 Jun 2019 23:18:31 GMT):
It was a small group today.

esplinr (Mon, 17 Jun 2019 23:18:48 GMT):
I kept pretty good notes of the conversation.

tplooker (Mon, 17 Jun 2019 23:49:43 GMT):
Thanks no worries, will review

swcurran (Mon, 17 Jun 2019 23:56:37 GMT):
Hopefullyou got every line that was stated, @esplinr :joy:

swcurran (Mon, 17 Jun 2019 23:56:37 GMT):
Hopefully you got every line that was stated, @esplinr :joy:

swcurran (Mon, 17 Jun 2019 23:56:37 GMT):
Hopefully you got every line that was said, @esplinr :joy:

esplinr (Tue, 18 Jun 2019 00:36:06 GMT):
The adjective "pretty good" was probably overstated. grin

esplinr (Tue, 18 Jun 2019 00:36:18 GMT):
Good enough?

esplinr (Tue, 18 Jun 2019 00:36:18 GMT):
"Good enough" is probably better.

esplinr (Tue, 18 Jun 2019 00:36:54 GMT):
But I should disclose @tplooker that we teased a bit about you not attending the call, since we moved to this time just for you!

esplinr (Tue, 18 Jun 2019 00:37:17 GMT):
But the context was teasing about my missing the Aries calls on Wednesday after volunteering to lead two discussion topics. So you weren't the only one teased.

tplooker (Tue, 18 Jun 2019 00:37:50 GMT):
:grin: yes sorry, I appreciate you moving the call for me and will be attending in future!

esplinr (Tue, 18 Jun 2019 00:39:19 GMT):
One proposal is to merge the Indy SDK Working Group calls with the Indy Maintainers calls. That will make it easier for you to participate on the Indy SDK topics, give a clear place for the Node topics, and make room in the calendar for an Aries calls that works for Russia and the US.

esplinr (Tue, 18 Jun 2019 00:39:48 GMT):
It wasn't practical before because there was too much business to cover, but now much of that business is in the Aries community so we think it is feasibel.

danielhardman (Wed, 19 Jun 2019 18:11:07 GMT):
A week or so ago, I proposed merging the indy-hipe PR that would streamline Indy HIPE processes to make them parallel those used in aries-rfcs. I haven't heard any dissent, but I also haven't heard any comment one way or another, except for @kdenhartog 's endorsement. I think I'll merge after today's Aries call unless I hear otherwise. @swcurran @TelegramSam @tplooker @esplinr

danielhardman (Wed, 19 Jun 2019 18:12:17 GMT):
If we streamline the process, I will do a flurry of cleanup and maintenance of small PRs to improve various things in indy-HIPE -- create an index like the one in aries-rfcs, turn on similar unit tests, etc. I will also start clearing out the PR backlog.

TelegramSam (Wed, 19 Jun 2019 18:12:54 GMT):
I approve.

TelegramSam (Wed, 19 Jun 2019 18:13:35 GMT):
mostly though, I think we should focus on cleaing out the now-Aries work.

TelegramSam (Wed, 19 Jun 2019 18:13:57 GMT):
honestly, the volume of indy work may do fine with the old process.

danielhardman (Thu, 20 Jun 2019 04:35:51 GMT):
All: I have updated the indy-hipe repo with an /index.md that shows all HIPEs by status. It's patterned off the aries-rfcs /index.md and uses a very slightly modified version of the generate_index.py script. See https://github.com/hyperledger/indy-hipe/blob/master/index.md. I have also updated the status of many of the HIPEs so they are clean/correct. There is still some cleanup to do, but it's much less daunting now. And I have run the check_links.py script from Aries and fixed all the issues it found. The repo now passes continuous integration for me exactly the way aries-rfcs does.

danielhardman (Thu, 20 Jun 2019 04:38:25 GMT):
@rjones Can you now turn in circleci for the indy-hipe repo? It should pass immediately, since it passed in my fork.

rjones (Thu, 20 Jun 2019 04:53:40 GMT):
enabled and set to be required.

danielhardman (Thu, 20 Jun 2019 05:08:42 GMT):
@rjones Thank you. However, it looks to me like circleci is either hanging or delaying its running for a long time; see the status on https://github.com/hyperledger/indy-hipe/pull/138. Do you think it's because HL needs to pay for more runners?

rjones (Thu, 20 Jun 2019 05:10:27 GMT):
I think it's because cci was enabled nine-ish hours after that commit.

rjones (Thu, 20 Jun 2019 05:11:21 GMT):
I was trying to figure out how to re-run it against older PRs, but I haven't cracked that nut yet

rjones (Thu, 20 Jun 2019 05:14:17 GMT):
I see this one only took 18 seconds: https://circleci.com/gh/hyperledger/aries-rfcs/17

rjones (Thu, 20 Jun 2019 05:20:08 GMT):
I poked an old PR and it doesn't look like it fired correctly. I'm not sure why

danielhardman (Thu, 20 Jun 2019 05:24:37 GMT):
Okay, let's go with the theory that the commit is old.

rjones (Thu, 20 Jun 2019 05:25:59 GMT):
If I uncheck "required" it will still run and report status, but not block a merge

danielhardman (Thu, 20 Jun 2019 05:38:33 GMT):
Maybe let's do that for a few days, and see whether we see any cases where it's stalled. If no, we re-check it. If yes, we leave it unchecked.

davology (Wed, 26 Jun 2019 09:30:04 GMT):
Has joined the channel.

rjones (Wed, 26 Jun 2019 15:40:45 GMT):
can you guys see this? https://github.com/hyperledger/indy-sdk/network/alerts

dbluhm (Wed, 26 Jun 2019 16:19:07 GMT):
@rjones I can't, at least

rjones (Wed, 26 Jun 2019 17:40:56 GMT):

Your GitHub security alerts for the week of Jun 18 - Jun 25 _ Fastmail.pdf

danielhardman (Thu, 27 Jun 2019 17:20:57 GMT):
@rjones I have created a ticket to track this: https://jira.hyperledger.org/browse/IS-1303

danielhardman (Thu, 27 Jun 2019 17:21:18 GMT):
Yes, I can see it.

danielhardman (Thu, 27 Jun 2019 17:21:18 GMT):
Yes, I can see the security alerts page you liked, @here

danielhardman (Thu, 27 Jun 2019 17:21:18 GMT):
Yes, I can see the security alerts page you linked, @rjones

andkononykhin (Thu, 27 Jun 2019 22:42:21 GMT):
@rjones Hello Ry. How are you?

andkononykhin (Thu, 27 Jun 2019 22:43:20 GMT):
I have a question regarding indy-node repository setting, in particular branch protections. Have you or other Hyperledger admin changed them recently?

andkononykhin (Thu, 27 Jun 2019 22:43:20 GMT):
I have a question regarding indy-node repository settings, in particular branch protections. Have you or other Hyperledger admin changed them recently?

rjones (Fri, 28 Jun 2019 16:48:11 GMT):
@andkononykhin ask away

rjones (Fri, 28 Jun 2019 16:51:39 GMT):
branch protections apply to * and */*

rjones (Fri, 28 Jun 2019 16:51:39 GMT):
branch protections apply to `*` and `*/*`

andkononykhin (Fri, 28 Jun 2019 16:52:27 GMT):
@sergey.khoroshavin created a ticket in Hyperledger helpdesk: https://jira.linuxfoundation.org/servicedesk/customer/portal/2/IT-16604

andkononykhin (Fri, 28 Jun 2019 16:53:29 GMT):
such protcestions are not that we expect and we don't understand the reason why it has been changed

rjones (Fri, 28 Jun 2019 16:53:45 GMT):
I can't see that ticket

rjones (Fri, 28 Jun 2019 16:54:11 GMT):
it was changed across all of github because the DCO bot was not firing on branches named `*/*`

rjones (Fri, 28 Jun 2019 16:54:19 GMT):
I don't remember when I did that

andkononykhin (Fri, 28 Jun 2019 16:55:26 GMT):
We use the same rules for both indy-plenum and indy-node. indy-plenum has not been changed, bug indy-node has

rjones (Fri, 28 Jun 2019 16:56:00 GMT):
that's an oversight on my part

andkononykhin (Fri, 28 Jun 2019 16:56:37 GMT):
We haven't used `*/*`, we use only exactly specified ones: `master` and `stable`

andkononykhin (Fri, 28 Jun 2019 16:57:05 GMT):
Why we should protect all branches?

rjones (Fri, 28 Jun 2019 16:57:18 GMT):
so that non-DCO commits don't come in again.

rjones (Fri, 28 Jun 2019 16:57:36 GMT):
why would you disable DCO checking?

andkononykhin (Fri, 28 Jun 2019 16:58:49 GMT):
@sergey.khoroshavin will continue the conversation, thanks

rjones (Fri, 28 Jun 2019 16:59:57 GMT):
OK

sergey.khoroshavin (Fri, 28 Jun 2019 17:03:10 GMT):
We don't disable DCO checking, we just need to have branch protection on just master and stable branches. Having it on all branches breaks our current release process since as part of CD our bot pushes to release preparation branch to bump versions before merging to stable branch.

rjones (Fri, 28 Jun 2019 17:09:08 GMT):
OK, I set it for master and stable and today and we'll need to have a larger meeting soon.

sergey.khoroshavin (Fri, 28 Jun 2019 17:09:38 GMT):
Thanks!

sergey.khoroshavin (Fri, 28 Jun 2019 17:13:09 GMT):
We plan to finish our release on Jul 4 (and we're on pretty tight schedule now), after that I'll be glad to discuss how to make our release process complaint with hyperledger policies on github. Does this timeframe looks okay for you?

rjones (Fri, 28 Jun 2019 17:29:35 GMT):
yes

tomislav (Sun, 30 Jun 2019 21:50:06 GMT):
Hi All, we're getting errors in CI when building containers that install libs from Sovrin repo. ``` W: GPG error: https://repo.sovrin.org/deb xenial InRelease: The following signatures were invalid: KEYEXPIRED 1561783578 KEYEXPIRED 1561783578 KEYEXPIRED 1561783578 KEYEXPIRED 1561783578 W: The repository 'https://repo.sovrin.org/deb xenial InRelease' is not signed. ``` Adding `--allow-unauthenticated` apt fixes the issue, but might be worth looking into the expired keys.

lukasA (Mon, 01 Jul 2019 15:57:26 GMT):
i'm having the same issue

dbluhm (Mon, 01 Jul 2019 17:24:52 GMT):
@SteveGoob is working on the issue

SteveGoob (Mon, 01 Jul 2019 17:25:59 GMT):
Can confirm

SteveGoob (Mon, 01 Jul 2019 20:55:28 GMT):
So, we've rotated the keys successfully, but there is an issue with ubuntu's keyserver not resolving the abbreviated key properly. To work around that issue, anyone wishing to install packages needs to run ``` apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CE7709D068DB5E88 ```

SteveGoob (Mon, 01 Jul 2019 20:55:28 GMT):
@here We've rotated the keys successfully, but there is an issue with ubuntu's keyserver not resolving the abbreviated key properly. To work around that issue, anyone wishing to install packages needs to run ``` apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CE7709D068DB5E88 ```

sergey.khoroshavin (Thu, 04 Jul 2019 19:45:43 GMT):
@rjones hi, we were going to finish release process today, but it seems someone reverted indy-node branch protection policy back to *, so we are blocked again. Could you revert it to just master and stable for one more day, please?

rjones (Thu, 04 Jul 2019 19:47:03 GMT):
on it

rjones (Thu, 04 Jul 2019 19:48:02 GMT):
@sergey.khoroshavin there are two - one for dev, one for master

rjones (Thu, 04 Jul 2019 19:48:07 GMT):
nothing for `*`

rjones (Thu, 04 Jul 2019 19:48:16 GMT):
which one needs edited

rjones (Thu, 04 Jul 2019 19:48:36 GMT):
sorry, stable and master

sergey.khoroshavin (Thu, 04 Jul 2019 19:49:50 GMT):
That's strange, I need to check our pipeline again. No edits should be needed then

rjones (Thu, 04 Jul 2019 19:49:52 GMT):
do you have zoom?

rjones (Thu, 04 Jul 2019 19:50:09 GMT):
https://zoom.us/j/2032622322

rjones (Thu, 04 Jul 2019 19:52:12 GMT):
Well take a look at my screen

sergey.khoroshavin (Thu, 04 Jul 2019 19:53:01 GMT):
That's strange, I need to check our pipeline again. No edits should be needed then, sorry for bothering

rjones (Thu, 04 Jul 2019 19:57:13 GMT):
this is what I saw in the past:

rjones (Thu, 04 Jul 2019 19:57:19 GMT):
```@sovbot sovbot – protected_branch.rejected_ref_update Ref update rejected for refs/heads/release-1.9.0 on hyperledger/indy-node: United States 7 days ago @sovbot sovbot – protected_branch.rejected_ref_update Ref update rejected for refs/heads/release-1.9.0 on hyperledger/indy-node: United States 7 days ago```

rjones (Thu, 04 Jul 2019 19:58:00 GMT):
then today:

rjones (Thu, 04 Jul 2019 19:58:03 GMT):
```@sovbot sovbot – protected_branch.rejected_ref_update Ref update rejected for refs/heads/stable on hyperledger/indy-node: United States 38 minutes ago```

sergey.khoroshavin (Thu, 04 Jul 2019 20:18:32 GMT):
Yes, stable is supposed to be protected, this failure was my mistake. Sorry for bothering you and thanks again for quick reaction.

rjones (Mon, 08 Jul 2019 18:08:56 GMT):
Has left the channel.

esplinr (Fri, 12 Jul 2019 23:29:29 GMT):
We had started a rotation of the Monday's Indy Maintainers call between US morning and afternoon. That would make next Monday's meeting an afternoon meeting, but on the calendar it is listed as a morning meeting.

esplinr (Fri, 12 Jul 2019 23:29:41 GMT):
Will we be holding it in the morning or the afternoon?

esplinr (Fri, 12 Jul 2019 23:30:16 GMT):
This round I can attend in the morning, but I now have a conflict in the afternoon.

nage (Mon, 15 Jul 2019 05:14:41 GMT):
@here note that the Maintainers call was at 9:00 am two weeks ago and is scheduled for 4:00 pm Monday (Mountain Time US) and again at 9:00 am on the 29th

tplooker (Mon, 15 Jul 2019 05:17:22 GMT):
@nage is that 4pm tomorrow then?

nage (Mon, 15 Jul 2019 05:18:36 GMT):
Correct (by my clock it is 11:18 pm Sunday)

tplooker (Mon, 15 Jul 2019 05:20:23 GMT):
Cool thanks!

esplinr (Mon, 15 Jul 2019 14:33:13 GMT):
I don't think anyone from the Evernym team will be available. It's the call where the Russia team cannot attend, and the calendar confusion resulted in my having a conflict.

tplooker (Mon, 15 Jul 2019 19:25:15 GMT):
@esplinr we could reschedule?

esplinr (Mon, 15 Jul 2019 19:29:32 GMT):
My backup-backup is out of the office this afternoon, so I'm not going to have an alternate.

esplinr (Mon, 15 Jul 2019 19:30:09 GMT):
@tplooker : Thank you for offering. I spoke with Nathan, and he thinks it is best that we keep the meeting. I'm comfortable with you proceeding without me.

esplinr (Mon, 15 Jul 2019 19:30:33 GMT):
Hopefully you get some sleep between now and then. grin

nage (Mon, 15 Jul 2019 21:59:56 GMT):
The maintainers meeting is starting now

nage (Mon, 15 Jul 2019 22:00:18 GMT):
https://wiki.hyperledger.org/pages/resumedraft.action?draftId=16320106&draftShareId=82a00213-1b62-46ba-b7ef-a245b3a012ee&

nage (Mon, 15 Jul 2019 22:00:38 GMT):
https://zoom.us/j/615818107

rjones (Wed, 17 Jul 2019 16:33:05 GMT):
Has joined the channel.

rjones (Wed, 17 Jul 2019 16:33:21 GMT):
hi - could one of the maintainers please take a look at this? https://github.com/hyperledger/indy-sdk/network/alert/vcx/wrappers/node/package-lock.json/braces/open

esplinr (Wed, 17 Jul 2019 16:52:17 GMT):
:arrow_up: @sergey.minaev (his work day is over, so expect a response tomorrow)

rjones (Wed, 17 Jul 2019 17:11:08 GMT):
I don't care if the response is "dismiss as won't fix" or whatever

sergey.minaev (Thu, 18 Jul 2019 14:55:39 GMT):
Dependabot are not able to fix it, so it will require manual fix.

TelegramSam (Fri, 19 Jul 2019 14:09:15 GMT):
indy-agent has now been updated with a migration notice. (Thanks @dbluhm) https://github.com/hyperledger/indy-agent

dbluhm (Wed, 24 Jul 2019 14:01:36 GMT):
@rjones can you grant me permission to edit the description on Indy Agent (or do it for me)? I think it would be a good idea to add a migration notice in the description like the one in the readme now. (I don't think we're ready to outright archive the repository yet...)

rjones (Thu, 25 Jul 2019 04:02:58 GMT):
@dbluhm try now. I set the permission from "write" to "maintain" on the group you're in and I'm interested if that works

dbluhm (Thu, 25 Jul 2019 14:20:19 GMT):
Yep, that worked.

SteveGoob (Tue, 30 Jul 2019 17:29:37 GMT):
It appears that we are not running tests on MacOS for anything other than libvcx in the Jenkins CI pipeline. Because of that, it looks like we've missed a regression where `medium_cases::open::open_pool_ledger_works_after_error` inside libindy's `pool` test module will hang indefinitely.

SteveGoob (Tue, 30 Jul 2019 17:29:37 GMT):
It appears that we are not running tests on MacOS for anything other than libvcx in the Jenkins pipeline. Because of that, it looks like we've missed a regression where `medium_cases::open::open_pool_ledger_works_after_error` inside libindy's `pool` test module will hang indefinitely.

SteveGoob (Tue, 30 Jul 2019 17:43:02 GMT):
^^ The issue [here.](https://jira.hyperledger.org/browse/IS-1338)

SteveGoob (Tue, 30 Jul 2019 17:43:02 GMT):
^^ The issue is [here (IS-1338).](https://jira.hyperledger.org/browse/IS-1338)

esplinr (Tue, 30 Jul 2019 19:58:21 GMT):
Yesterday during the maintainers call, I suggested that we have a lot going on at the moment and would benefit from more frequent calls to ensure a common vision for collaboration. We agreed to meet in the US morning every other week instead of once a month.

esplinr (Tue, 30 Jul 2019 19:59:25 GMT):
Should we also increase our frequency for the meetings in the US afternoon? @tplooker and @kdenhartog would you attend a meeting every two weeks?

cam-parra (Tue, 30 Jul 2019 21:58:39 GMT):
@esplinr would these be indy calls or aries calls?

esplinr (Wed, 31 Jul 2019 12:51:14 GMT):
Indy Maintainer calls, exactly like we currently have once a month in each timezone.

esplinr (Wed, 31 Jul 2019 12:51:32 GMT):
https://wiki.hyperledger.org/display/indy/Indy+Maintainers+Meeting

dbluhm (Wed, 31 Jul 2019 17:35:55 GMT):
I've been doing my best to direct newcomers to the agent ecosystem to the ACA-Py resources (migration notices everywhere I can) but we seem to be getting a significant number of people stumbling upon old resources like those found here: https://github.com/hyperledger/education/tree/master/LFS171x/indy-material/nodejs

esplinr (Wed, 31 Jul 2019 19:27:00 GMT):
It's going to take a concerted effort to deprecate all the Indy user documentation.

swcurran (Thu, 01 Aug 2019 18:00:37 GMT):
I'll update that document to direct people elsewhere. They get their via the Blockchain for Business course. The new version of that course has removed the Indy Chapter.

simranvc (Fri, 02 Aug 2019 11:40:55 GMT):
Has joined the channel.

simranvc (Fri, 02 Aug 2019 11:40:56 GMT):
on single pool we cant create issuer,proover and verifier if we dont want multiple ledger ???

kdenhartog (Tue, 06 Aug 2019 09:48:08 GMT):
I still have a few people stumbling across my indy-dev stuff as well from the youtube videos probably. I just pointed it to the ACA-py demo section as well.

dbluhm (Tue, 06 Aug 2019 13:46:12 GMT):
If you haven't already, I recommend you take your question to the #indy or #indy-sdk channels.

cam-parra (Tue, 06 Aug 2019 16:23:15 GMT):
@esplinr Can we have someone on the Evernym team review this? Should be a simple PR to merge https://github.com/hyperledger/indy-sdk/pull/1791

esplinr (Wed, 07 Aug 2019 13:22:40 GMT):
Thank you @AxelNennker for reviewing the pull request. It appears to be merged already.

AxelNennker (Wed, 07 Aug 2019 13:22:40 GMT):
Has joined the channel.

esplinr (Thu, 08 Aug 2019 20:37:19 GMT):
Thank you @rjones for helping me to update the calendar appointment for the Monday Indy Maintainers call.

rjones (Thu, 08 Aug 2019 20:37:43 GMT):
Sure thing!

esplinr (Thu, 08 Aug 2019 20:38:09 GMT):
It is now scheduled for every week, rotating between US AM / Europe PM (starting next Monday) and US PM / New Zealand AM (starting a week from Monday).

esplinr (Thu, 08 Aug 2019 20:38:09 GMT):
It is now scheduled for every week, rotating between US AM / Europe PM (starting next Monday) and US PM / New Zealand AM (starting a week from Monday) as two separate reoccurring appointments.

esplinr (Thu, 08 Aug 2019 20:38:59 GMT):
I encourage all Indy Maintainers to recopy the appointments from the Hyperledger community calendar to their personal calendars.

raj_shekhar (Fri, 09 Aug 2019 10:24:35 GMT):
Hi Team, I am looking for recordings of past meetings and discussions, can someone plz share with me the link.

dbluhm (Fri, 09 Aug 2019 13:55:36 GMT):
There are lots of meetings that go in within the Indy community and several others that closely relate to Indy. What subjects are you interested in? That might help direct you to the most relevant content

esplinr (Fri, 09 Aug 2019 16:18:36 GMT):
https://wiki.hyperledger.org/display/indy/Indy+Maintainers+Meeting

esplinr (Fri, 09 Aug 2019 16:19:14 GMT):
https://wiki.hyperledger.org/display/IWG/Identity+WG+Implementers+Call

esplinr (Fri, 09 Aug 2019 16:19:24 GMT):
https://wiki.hyperledger.org/display/ARIES/Aries+Working+Group

raj_shekhar (Sat, 10 Aug 2019 14:55:07 GMT):
@dbluhm I am looking from dev point of view. thanks @esplinr I will explore these links

nage (Mon, 12 Aug 2019 14:30:32 GMT):
I believe today's Indy Maintainers call should be at 16:00 Mountain Time (4 PM), and not at 9:00 MT. Apologies, I messed up my google calendar access to the appointment when trying to change it last week.

nage (Mon, 12 Aug 2019 14:30:32 GMT):
I believe today's Indy Maintainers call should be at 16:00 Mountain Time (4 PM), and not at 9:00 MT. Apologies, I messed up my google calendar access to edit the appointment when trying to change it last week.

rjones (Mon, 12 Aug 2019 14:40:32 GMT):
@nage I think @esplinr and I edited those last week

nage (Mon, 12 Aug 2019 14:42:22 GMT):
Hmm. I'm not seeing it on my HL calendar....

nage (Mon, 12 Aug 2019 14:42:39 GMT):
@esplinr do they look right to you?

rjones (Mon, 12 Aug 2019 15:13:28 GMT):
the community calendar is in such a state that I would prefer to burn it down and start over

nage (Mon, 12 Aug 2019 22:04:01 GMT):
https://wiki.hyperledger.org/display/indy/2019-08-12+Indy+Maintainers+Call

raj_shekhar (Tue, 13 Aug 2019 05:57:26 GMT):
Hi maintainers, Anybody maintaining this tutorial, is it working currently?? https://github.com/hyperledger/education/tree/master/LFS171x/indy-material/nodejs

dbluhm (Tue, 13 Aug 2019 13:24:46 GMT):
https://github.com/hyperledger/education/commit/f4cdceea2483aaa784c983d835e72e2c3a0429c8

dbluhm (Tue, 13 Aug 2019 13:25:12 GMT):
The indy materials in that repository should have links to other more up to date resources now

swcurran (Tue, 13 Aug 2019 17:34:19 GMT):
It is working with the instructions given. It should not be used to do future work.

swcurran (Tue, 13 Aug 2019 17:34:39 GMT):
At least it was working last time I used it. I will recheck,

raj_shekhar (Wed, 14 Aug 2019 04:53:35 GMT):
I was able to set it up and ran it till sending and accepting endpoint request, it was working but the validate proof link was not working,,, I will ran it end to end today and update here

swcurran (Wed, 14 Aug 2019 14:07:14 GMT):
OK - one of the proof requests does not work, I think that's noted, but the Alice Transcripts should work.

esplinr (Wed, 14 Aug 2019 20:01:45 GMT):
While @nage was traveling, we discussed on the Indy Maintainers call whether we should increase our cadence to weekly (rotating between timezones). I then spoke will all attendees to verify who would attend on Monday, and worked with @rjones to update the calendar. I then went on my vacation hoping that Nathan would get the message I left with his team. Sorry Nathan.

raj_shekhar (Mon, 19 Aug 2019 08:32:19 GMT):
Yeah @swcurran , Alice transcript works fine but the validate proof is not working for any.

esplinr (Mon, 19 Aug 2019 22:01:35 GMT):
Starting the Indy Maintainers call: https://wiki.hyperledger.org/display/indy/2019-08-19+Indy+Maintainers+Call

esplinr (Mon, 19 Aug 2019 22:01:58 GMT):
@kdenhartog

esplinr (Mon, 19 Aug 2019 22:01:58 GMT):
@kdenhartog @cam-parra @mattatkiva @swcurran

kdenhartog (Mon, 19 Aug 2019 22:41:38 GMT):
was the call in the morning or afternoon for you this time?

kdenhartog (Mon, 19 Aug 2019 22:43:37 GMT):
Also msg_pack presents problems when dealing with an agent that maintains more than one relationship. For example, if I receive a message, I don't know which key in my agent I should be using to decrypt the message. We can get sender anonymity or receiver anonymity, but I don't believe it's possible to get both and still determine who the message is for.

esplinr (Mon, 19 Aug 2019 23:06:47 GMT):
The call was in the afternoon for us, in order to overlap with you.

esplinr (Mon, 19 Aug 2019 23:06:59 GMT):
Next Monday will be our overlap with Europe.

esplinr (Mon, 19 Aug 2019 23:07:37 GMT):
Nathan will post the recording to the agenda page. I'm available if you want to further discuss any items.

kdenhartog (Mon, 19 Aug 2019 23:08:38 GMT):
Sorry I wasn't able to attend. I got the calendar mixed up again.

esplinr (Mon, 19 Aug 2019 23:09:00 GMT):
Understandable. I think the calendar is correct now and we'll be able to be consistent. So two weeks from today we'll meet.

kdenhartog (Mon, 19 Aug 2019 23:09:02 GMT):
My calendar says it was at 6am

kdenhartog (Mon, 19 Aug 2019 23:09:14 GMT):
Ahh that's my personal one

esplinr (Mon, 19 Aug 2019 23:09:20 GMT):
It should be 9AM for you.

esplinr (Mon, 19 Aug 2019 23:09:43 GMT):
(Or whatever time was one hour ago)

esplinr (Mon, 19 Aug 2019 23:10:10 GMT):
@SteveGoob I expect you will find the discussion about what tests should be run in the CI pipeline will be really useful.

esplinr (Mon, 19 Aug 2019 23:21:14 GMT):
@kdenhartog Sergey recently raised the same concern with msg_pack. I put it on the agenda to discuss next time.

kdenhartog (Mon, 19 Aug 2019 23:25:09 GMT):
Sounds good, I've got things added to my calendar now too

esplinr (Mon, 19 Aug 2019 23:27:15 GMT):
I just realized that our next Indy Maintainers call is Labor Day in the US. I don't want to go too long without coordinating with you, so we could move it to Tuesday September 3.

esplinr (Mon, 19 Aug 2019 23:27:18 GMT):
What do you think?

cam-parra (Mon, 19 Aug 2019 23:37:42 GMT):
Sorry I missed that call. Is there a recording or an agenda I can look at to catch up?

swcurran (Mon, 19 Aug 2019 23:39:18 GMT):
@esplinr - I didn't have the call on my calendar. AFAIK the call was last week at this time (although it was poorly attended), so shouldn't the next one be next week vs. this week? Guess I better go back to the Hyperledger Calendar...

esplinr (Mon, 19 Aug 2019 23:40:17 GMT):
@cam-parra Agenda: https://wiki.hyperledger.org/display/indy/2019-08-19+Indy+Maintainers+Call Nathan will post the recording soon.

esplinr (Mon, 19 Aug 2019 23:41:32 GMT):
@swcurran In the last call, we decided that we should meet more frequently at least while we are working on the Indy Aries split. I updated the Hyperledger Calendar, and announced the changes on the Aries and Identity WG calls.

esplinr (Mon, 19 Aug 2019 23:42:01 GMT):
@all Please check the Hyperledger calendar for the updated schedule of Indy meetings.

swcurran (Mon, 19 Aug 2019 23:42:22 GMT):
Sounds good. Sorry about that.

esplinr (Mon, 19 Aug 2019 23:42:52 GMT):
No apology needed. It's hard to communicate a schedule change with everyone, so I'm trying to do it broadly at each opportunity.

esplinr (Mon, 19 Aug 2019 23:43:57 GMT):
(I'm surprised that reference to all worked. I must have elevated permissions in this channel. I should have done that earlier.)

esplinr (Mon, 26 Aug 2019 14:59:57 GMT):
We are about to start the Indy Maintainers call: https://zoom.us/j/615818107

AxelNennker (Mon, 26 Aug 2019 17:06:35 GMT):
My first PR with `[Skip CI]` https://github.com/hyperledger/indy-sdk/pull/1856 :smiley:

esplinr (Mon, 26 Aug 2019 20:42:06 GMT):
I've posted the recording to the Indy Maintainers call that happened earlier today.

esplinr (Mon, 26 Aug 2019 20:42:29 GMT):
https://wiki.hyperledger.org/display/indy/2019-08-26+Indy+Maintainers+Call

esplinr (Mon, 26 Aug 2019 20:44:05 GMT):
@kdenhartog @tplooker Next Monday (Tuesday morning for you) is a holiday in the US. If you want, I'm willing to join the call in order to ensure you are current on all the discussion topics. Are you planning on attending, or should we cancel that specific call?

tplooker (Mon, 26 Aug 2019 20:44:53 GMT):
@esplinr Im happy to cancel this call as we will be away at RWOT

esplinr (Mon, 26 Aug 2019 20:45:03 GMT):
Oh, that's another important conflict. I forgot about that one.

esplinr (Mon, 26 Aug 2019 20:45:23 GMT):
Prauge should be super fun.

esplinr (Mon, 26 Aug 2019 20:45:23 GMT):
Prague should be super fun.

esplinr (Mon, 26 Aug 2019 20:46:43 GMT):
I think you will find the recording of today's call is very informative. If you have any questions, let me know and we can discuss them on the channel or schedule a call to ensure you are adequately involved.

esplinr (Mon, 26 Aug 2019 20:47:02 GMT):
Any other non-US developers planning on joining next Monday's call? @swcurran ?

esplinr (Mon, 26 Aug 2019 20:54:03 GMT):
During the call this morning, @nage proposed that we rename the meeting "Indy Developers" because "Indy Maintainers" was not inclusive enough. I concur, but I would prefer "Indy Contributors" to indicate that we are focused on helping people contribute to Indy, rather than showing them how develop with Indy. In addition to changing the name of the meeting, I would like to change the name of this channel to match. So it would become #indy-contributors, which shows how it is different from #indy. Thoughts?

cam-parra (Mon, 26 Aug 2019 20:55:04 GMT):
You have my vote

tplooker (Mon, 26 Aug 2019 20:55:04 GMT):
Agreed I think that is a valid point happy to change the name

cam-parra (Mon, 26 Aug 2019 20:55:54 GMT):
although a hour of troubleshooting sounds fun :wink:

cam-parra (Mon, 26 Aug 2019 20:55:54 GMT):
although an hour of troubleshooting sounds fun :wink:

rjones (Mon, 26 Aug 2019 20:57:17 GMT):
I just sprayed PRs across every indy repo to add a CODEOWNERS file.

swcurran (Mon, 26 Aug 2019 21:00:11 GMT):
Change from indy-maintainers (anyone that can accept a PR) to indy-contributors (anyone that has/is likely to submit a PR) seems good.

swcurran (Mon, 26 Aug 2019 21:00:44 GMT):
Canada celebrates Labour Day. Very similar to the US holiday but it has a U in it.

esplinr (Mon, 26 Aug 2019 21:22:46 GMT):
Canada always has to add a special flourish!

esplinr (Mon, 26 Aug 2019 21:23:38 GMT):
Thank you everyone for sharing your opinions. I'll give 24 hours for other feedback, and then I'll email community-architects to make the changes.

esplinr (Wed, 28 Aug 2019 04:33:32 GMT):
Coordinating the activities of those who are contributing to Hyperledger Indy.

esplinr (Wed, 28 Aug 2019 04:33:32 GMT):
This channel is intended for those with a long term commitment to improving the project (see scrum Pigs vs Chickens).

esplinr (Wed, 28 Aug 2019 04:33:32 GMT):
This channel is intended for those contributing to Indy. We are happy to answer questions about Indy in the other channels.

esplinr (Wed, 28 Aug 2019 04:33:32 GMT):
Room name changed to: indy-contributors by esplinr

MALodder (Wed, 28 Aug 2019 19:56:48 GMT):
Has left the channel.

rjones (Wed, 04 Sep 2019 22:29:02 GMT):
:indy:

esplinr (Mon, 09 Sep 2019 15:02:16 GMT):
Starting the Indy Contributors call now: https://zoom.us/j/615818107

rjones (Mon, 16 Sep 2019 15:33:54 GMT):
Has left the channel.

esplinr (Mon, 16 Sep 2019 21:53:31 GMT):
We'll be starting the Indy Contributors call in 5 minutes.

esplinr (Mon, 16 Sep 2019 21:53:53 GMT):
https://zoom.us/j/615818107

esplinr (Mon, 16 Sep 2019 21:59:03 GMT):
@kdenhartog Is your team around today to work together?

esplinr (Mon, 16 Sep 2019 22:02:52 GMT):
@tplooker Should we wait for you?

tplooker (Mon, 16 Sep 2019 22:03:42 GMT):
Hey, sorry I'm at TPAC so will be unable to attend this week

kdenhartog (Mon, 16 Sep 2019 22:03:58 GMT):
I can jump on in about 10 minutes. I'm at stand-up now

swcurran (Mon, 16 Sep 2019 23:03:28 GMT):
Dang...missed the call. Too focused. Sorry about that.

esplinr (Tue, 17 Sep 2019 00:53:20 GMT):
No worries. It was a good opportunity to make sure that Kyle the team at Kiva were aware of things we've talked about over the last six weeks.

esplinr (Tue, 17 Sep 2019 00:54:42 GMT):
@kdenhartog : I remembered something I intended to tell you on the call. One of the enhancements to the CI / CD system for Indy SDK (IS-1345) is the ability to mark a PR as "[Skip CI]". Then the PR won't take any runners.

jadhavajay (Thu, 19 Sep 2019 18:46:14 GMT):
Has joined the channel.

rjones (Fri, 20 Sep 2019 17:40:41 GMT):
Has joined the channel.

rjones (Fri, 20 Sep 2019 17:40:41 GMT):
https://lgtm.com/projects/g/hyperledger/indy-plenum/?mode=list not sure if this is the right channel for this

donqui (Fri, 20 Sep 2019 18:03:39 GMT):
I will share it with the folks working on this, this is indy-node related

VenkateshSYS (Sun, 22 Sep 2019 15:01:03 GMT):
Has joined the channel.

VenkateshSYS (Sun, 22 Sep 2019 15:01:05 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:56 GMT):
"scripts": { "startfile" : "node file.js" } How to write this in dockerfile CMD []

rjones (Sun, 22 Sep 2019 15:56:28 GMT):
@VenkateshSYS stop spamming.

rjones (Sun, 22 Sep 2019 15:57:23 GMT):
VenkateshSYS

VenkateshSYS (Sun, 22 Sep 2019 16:34:07 GMT):
Has left the channel.

VenkateshSYS (Sun, 22 Sep 2019 16:34:30 GMT):
Has joined the channel.

VenkateshSYS (Sun, 22 Sep 2019 16:34:38 GMT):
Has left the channel.

esplinr (Mon, 23 Sep 2019 15:01:09 GMT):
Getting started with the Indy Contributors call: https://zoom.us/j/615818107

esplinr (Mon, 23 Sep 2019 23:15:22 GMT):
@cam-parra @mattatkiva Here is the link to Indy Catalyst: https://github.com/bcgov/indy-catalyst I think the use case sounds very similar to what you are doing.

mattatkiva (Mon, 23 Sep 2019 23:15:22 GMT):
Has joined the channel.

esplinr (Mon, 23 Sep 2019 23:17:04 GMT):
@cam-parra per our discussion, I also added to the Aries WG A call on Wednesday an agenda item for us to discuss moving the wallet from indy-sdk to aries-core-wallet.

swcurran (Tue, 24 Sep 2019 05:34:45 GMT):
Let us know if you want to hear more about Indy Catalyst.

mattatkiva (Tue, 24 Sep 2019 13:45:57 GMT):
I want to contribute our javascript "library" for using the postgres plugin for indy-sdk. I was thinking of putting it here `indy-sdk/samples/postgres-plugin/nodejs`....thoughts?

esplinr (Tue, 24 Sep 2019 16:47:58 GMT):
I think that's a great place for it to live until we have a place in aries-core-wallet-postgres for it.

mattatkiva (Tue, 24 Sep 2019 17:02:37 GMT):
thnx @esplinr

mattatkiva (Wed, 25 Sep 2019 13:42:55 GMT):
@esplinr https://github.com/hyperledger/indy-sdk/pull/1897

mattatkiva (Wed, 25 Sep 2019 13:43:09 GMT):
I cannot approve it since I created it :D

rjones (Wed, 25 Sep 2019 14:42:02 GMT):
Hi - I see `indy-plenum` and `indy-node` still trigger builds in Jenkins, but the results are ignored. May I delete the jobs in Jenkins, as we move broadly elsewhere?

rjones (Wed, 25 Sep 2019 14:42:45 GMT):
I propose to delete these jobs: https://jenkins.hyperledger.org/view/indy/

rjones (Wed, 25 Sep 2019 14:45:50 GMT):
https://gerrit.hyperledger.org/r/#/c/ci-management/+/33720/

esplinr (Wed, 25 Sep 2019 16:28:51 GMT):
^^ @AndrewNikitin

esplinr (Wed, 25 Sep 2019 16:28:51 GMT):
^^ @AndrewNikitin and @SteveGoob

AndrewNikitin (Wed, 25 Sep 2019 16:28:51 GMT):
Has joined the channel.

sergey.khoroshavin (Wed, 25 Sep 2019 16:43:12 GMT):
@rjones despite not being a requirement for merge we still look into results from these jobs when they fail (and in some cases it helped find real problems with code), so we'd prefer to keep them if possible as an additional "safety net". However if keeping these jobs is a real problem for HL then feel free to delete them

rjones (Wed, 25 Sep 2019 17:09:44 GMT):
@sergey.khoroshavin Jenkins is going away. It isn't critical that they go away, but Jenkins goes away at the end of 2019

esplinr (Wed, 25 Sep 2019 18:05:33 GMT):
The Indy and Aries communities don't yet have a development plan to get us off of Jenkins by the end of 2019. We are making progress, but it's going slow.

rjones (Wed, 25 Sep 2019 18:06:19 GMT):
Ah, sorry. I mean "the hyperledger hosted jenkins"

rjones (Wed, 25 Sep 2019 18:06:36 GMT):
I see that you are running another jenkins instance; I didn't mean anything about that one.

esplinr (Thu, 26 Sep 2019 21:27:42 GMT):
Phew!

esplinr (Thu, 26 Sep 2019 21:27:47 GMT):
Thanks for clarifying.

esplinr (Thu, 26 Sep 2019 21:28:20 GMT):
@sergey.khoroshavin Are we using the Hyperledger Jenkins as a "safety net"? When was the last time that safety net came in handy?

DibbsZA (Fri, 27 Sep 2019 10:30:45 GMT):
Has joined the channel.

Abhishekkishor (Mon, 30 Sep 2019 03:46:20 GMT):
Has joined the channel.

tomislav (Sat, 05 Oct 2019 02:01:00 GMT):
Apologies for cross posting this, it may not be related to indy-node only. 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?

esplinr (Mon, 07 Oct 2019 14:16:37 GMT):
If you have a topic for today's contributors call, please add it to the agenda. "Main Business" is a good place to put it. https://wiki.hyperledger.org/display/indy/2019-10-07+Indy+Contributors+Call

esplinr (Mon, 07 Oct 2019 14:51:51 GMT):
To finish out this conversation, the Hyperledger Jenskins instances are being run as a backup to the main CI / CD pipeline for Indy that is hosted by the Sovrin Foundation. At least twice this year it caught bugs that were missed by the main pipeline. In both instances this is because the Hyperledger machines run slower and changed the timing of events.

esplinr (Mon, 07 Oct 2019 14:52:23 GMT):
I don't think this is sufficient reason to keep those machines around. We'll look for alternative approaches to meet the same goal.

esplinr (Mon, 07 Oct 2019 15:03:37 GMT):
Starting Indy Contributors: https://zoom.us/j/615818107

smithsamuelm (Mon, 07 Oct 2019 15:03:42 GMT):
Has joined the channel.

AxelNennker (Tue, 08 Oct 2019 19:18:35 GMT):
installed `cargo install cargo-tree` and ran `cargo tree -d` to find duplicates. I think it is a good idea to remove those duplicates.

AxelNennker (Tue, 08 Oct 2019 19:19:32 GMT):

dependency-tree.txt

AxelNennker (Tue, 08 Oct 2019 19:53:22 GMT):
Duplicates meaning the same crate in different versions

Hangyu (Wed, 09 Oct 2019 00:21:11 GMT):
Has joined the channel.

esplinr (Wed, 09 Oct 2019 12:16:35 GMT):
Agreed. That is a useful analysis. I look forward to seeing what issues result fromit.

esplinr (Wed, 09 Oct 2019 12:16:35 GMT):
Agreed. That is a useful analysis. I look forward to seeing what issues are uncovered by it. Thanks @AxelNennker

sergey.minaev (Wed, 16 Oct 2019 17:56:51 GMT):
+1, thanks @AxelNennker . I think fixing duplicates may speed up our build process

ajayjadhav (Fri, 18 Oct 2019 13:38:05 GMT):
Has joined the channel.

esplinr (Fri, 25 Oct 2019 00:32:01 GMT):
We plan to have another coordination conversation to discuss budgets for work on the Indy ledger. We have a call scheduled: October 28 at 11H US Pacific / 19H Central European Time / 19H Moscow Standard Time / 7H October 29 in New Zealand. https://zoom.us/j/715671233 @tplooker @kdenhartog @AxelNennker @vinomaster Do you expect to join us?

vinomaster (Fri, 25 Oct 2019 00:32:01 GMT):
Has joined the channel.

esplinr (Fri, 25 Oct 2019 00:33:06 GMT):
_is really tempted to list everyone's handle to provide personal invitations . . . _

kdenhartog (Fri, 25 Oct 2019 00:52:01 GMT):
Are we moving the normal meeting forward 4 hours from normal then?

esplinr (Fri, 25 Oct 2019 00:52:27 GMT):
I was wondering if we should replace the normal meeting, or hold both.

esplinr (Fri, 25 Oct 2019 00:52:34 GMT):
We can replace the normal meeting if you want.

kdenhartog (Fri, 25 Oct 2019 00:53:49 GMT):
If it makes it possible for us to have more people on the meeting who couldn't normally attend this meeting, then that works for me. Otherwise, I'd prefer to not need to be up at 7am unnecessarily.

esplinr (Fri, 25 Oct 2019 00:54:51 GMT):
We expect to have Evernym's Russia team on the call.

esplinr (Fri, 25 Oct 2019 00:55:10 GMT):
So it's a good (and rare) opportunity for you, me, and them to all be in a conversation together.

swcurran (Fri, 25 Oct 2019 01:44:45 GMT):
@jljordan_bcgov - FYI about this meeting. We need to plan how to cover this with our other meetings that day.

esplinr (Sun, 27 Oct 2019 04:34:27 GMT):
Per @kdenhartog's excellent suggestion, I'll cancel the afternoon Indy Contributors call and we'll combine it with our discussion of Indy Ledger Next during the overlap slot with US / Europe / New Zealand.

esplinr (Sun, 27 Oct 2019 05:53:26 GMT):
Note that the Zoom link is changed too: https://zoom.us/j/715671233

lynn.bendixsen (Mon, 28 Oct 2019 17:01:32 GMT):
Quick question to avoid having to read up a lot in this channel... The contributors meeting starts in 1 hour?

esplinr (Mon, 28 Oct 2019 17:52:05 GMT):
Correct.

esplinr (Mon, 28 Oct 2019 17:52:09 GMT):
10 minutes.

esplinr (Mon, 28 Oct 2019 18:01:23 GMT):
https://zoom.us/j/715671233

esplinr (Mon, 28 Oct 2019 18:01:23 GMT):
We are getting started with the Indy Contributors call: https://zoom.us/j/715671233

esplinr (Mon, 28 Oct 2019 18:05:23 GMT):
@kdenhartog @tplooker @burdettadam @kenebert

mattatkiva (Wed, 30 Oct 2019 16:30:50 GMT):
what is the URL to indy-sdk jira backlog?

donqui (Wed, 30 Oct 2019 17:05:25 GMT):
https://jira.hyperledger.org/secure/RapidBoard.jspa?rapidView=149&projectKey=IS&view=planning.nodetail

esplinr (Wed, 30 Oct 2019 19:55:57 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.

esplinr (Wed, 30 Oct 2019 19:56:54 GMT):
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.

esplinr (Wed, 30 Oct 2019 19:57:12 GMT):
You can read the rationale here: https://wiki.hyperledger.org/display/HYP/2019+Q4+Hyperledger+Indy

jljordan_bcgov (Thu, 31 Oct 2019 00:01:58 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.```

donqui (Thu, 31 Oct 2019 10:15:01 GMT):
I can try to answer, but @ashcherbakov can provide more info here. Indy-Plenum is a general purpose ledger framework that has a production grade PBFT protocol implementation. Plenum can be extended with custom transactions using pluggable request handlers, and other kinds of plugins (custom token implementations... ). This is Indy-Node. Indy-Node takes Indy-Plenum, and defines Identity related transactions making it a Identity focused Ledger. So: 1. Plenum is a general purpose ledger

donqui (Thu, 31 Oct 2019 10:17:24 GMT):
This boils down to: - Indy Plenum is the ledger - Indy Node is a set of Identity related transactions - Indy SDK provides low level tools to build solutions and communicate with Indy-Node - Indy CLI allows for testing and administration of a Indy-Node deployment

donqui (Thu, 31 Oct 2019 10:17:24 GMT):
This boils down to: - Indy Plenum is the ledger with a production grade consensus protocol - Indy Node is a set of Identity related transactions on top of Indy-Plenum - Indy SDK provides low level tools to build solutions and communicate with Indy-Node - Indy CLI allows for testing and administration of a Indy-Node deployment So if Plenum is out of indy, it becomes a general ledger/consensus project, while Indy is left only with the parts that are directly related to Identity (read identity transactions,and interfacing primitives)

donqui (Thu, 31 Oct 2019 10:17:24 GMT):
This boils down to: - Indy Plenum is the ledger with a production grade consensus protocol - Indy Node is a set of Identity related transactions on top of Indy-Plenum - Indy SDK provides primitives for build identity solutions and interfacing with Indy-Node - Indy CLI allows for testing and administration of a Indy-Node deployment So if Plenum is out of indy, it becomes a general ledger/consensus project, while Indy is left only with the parts that are directly related to Identity (read identity transactions,and interfacing primitives)

donqui (Thu, 31 Oct 2019 10:17:24 GMT):
This boils down to: - Indy Plenum is the ledger with a production grade consensus protocol - Indy Node is a set of Identity related transactions on top of Indy-Plenum - Indy SDK provides primitives for build identity solutions and interfacing with Indy-Node - Indy CLI allows for testing and administration of a Indy-Node deployment So if Plenum is out of indy, it becomes a general ledger/consensus project, while Indy is left only with the parts that are directly related to Identity (read identity transactions, interfacing primitives, deployment admin tools)

ashcherbakov (Thu, 31 Oct 2019 10:17:33 GMT):
yes, that's correct (the only thing is that Plenum implements RBFT consensus protocol currently with a plan to move to Aardvark protocol next moth)

swcurran (Thu, 31 Oct 2019 15:23:31 GMT):
Recordings from yesterday Aries working group call have been posted. A good call with the topics covering: * Review of open tickets; which can be resolved? * Signed attachments, ~sig, etc * Delegatable creds and consent receipts * Cutting over to didcomm.org Page is here: https://wiki.hyperledger.org/pages/viewpage.action?pageId=24772975

swcurran (Thu, 31 Oct 2019 15:23:31 GMT):
Recordings from yesterday Aries working group call have been posted. A good call covering: * Review of open tickets; which can be resolved? * Signed attachments, ~sig, etc * Delegatable creds and consent receipts * Cutting over to didcomm.org Page is here: https://wiki.hyperledger.org/pages/viewpage.action?pageId=24772975

esplinr (Mon, 04 Nov 2019 16:02:52 GMT):
Starting the Indy Maintainers c all: https://zoom.us/j/615818107

esplinr (Mon, 11 Nov 2019 22:52:49 GMT):
Indy Contributors meeting in 10 minutes: https://zoom.us/j/615818107

esplinr (Mon, 11 Nov 2019 23:02:46 GMT):
We're waiting for an employee from the Sovrin Foundation to start the meeting.

esplinr (Mon, 11 Nov 2019 23:03:37 GMT):
Meeting started.

esplinr (Mon, 11 Nov 2019 23:03:48 GMT):
@tplooker @kdenhartog Do you want an update on the last few weeks of progress?

kdenhartog (Mon, 11 Nov 2019 23:04:37 GMT):
give me a second joining now

tplooker (Mon, 11 Nov 2019 23:04:45 GMT):
Yeap joining too

swcurran (Mon, 11 Nov 2019 23:41:41 GMT):
Remembrance Day in Canada, so I won't be on today.

esplinr (Tue, 12 Nov 2019 00:07:37 GMT):
Enjoy your holiday!

esplinr (Mon, 18 Nov 2019 15:54:19 GMT):
Will start the Indy Contributors call in ~5 minutes.

esplinr (Mon, 18 Nov 2019 15:54:36 GMT):
https://wiki.hyperledger.org/display/indy/Indy+Contributors+Meeting

esplinr (Mon, 18 Nov 2019 16:01:57 GMT):
We are starting the Indy Contributors call: https://zoom.us/j/615818107

swcurran (Mon, 18 Nov 2019 16:42:18 GMT):
Dang...this is not on my calendar. I thought I had gone through and picked them all up. Sorry for missing the call.

esplinr (Mon, 18 Nov 2019 19:06:57 GMT):
No worries. I'll be posting the recording soon.

TelegramSam (Tue, 19 Nov 2019 16:47:26 GMT):
@sergey.minaev do you know why the schema and cred def have different canonicalization rules? It seems like consistency there would be a good thing.

esplinr (Wed, 20 Nov 2019 14:48:09 GMT):
We spoke with a team. We think it is just a legacy artifact (technical debt). It should probably be fixed. (PRs are welcome!)

esplinr (Wed, 20 Nov 2019 14:52:07 GMT):
I created INDY-2300 to capture the work. We don't think we will be working on it any time soon.

dbluhm (Wed, 20 Nov 2019 18:17:50 GMT):
@kenebert ^^

kenebert (Wed, 20 Nov 2019 18:26:10 GMT):
@esplinr @sergey.minaev Why are we canonicalizing in the first place? It seems like the canon function is lossy as spaces are removed and all uppercase letters are lower cased. This will be problematic when using rich schemas that have camelcase etc. and produce name space collisions where attributes like "My Name" and "myname" create duplicate attribute keys. It will also prevent anyone trying to use the credential attribute to easily correlate back to the schema attribute name, since the canon function does not easily have an inverse.

sergey.minaev (Thu, 21 Nov 2019 12:22:31 GMT):
@kenebert are you asking about INDY-2300 or about "canonicalizing" in libindy for attribute name? as far as I understand @TelegramSam question and INDY-2300 are about schema and creddef transactions and JSONs: schema contains snake_case but creddef uses camelCase for transaction fields

kenebert (Thu, 21 Nov 2019 17:04:22 GMT):
@sergey.minaev As I understand it, INDY-2300 seeks to make schemas and creddefs match. I believe this is a good idea. My concerns are 1. Schemas in current internet use, such as those defined at schema.org, have both spaces and upper case letters. Rich schema work will need to support these types and more. Some schemas on Sovrin MainNet also have spaces and upper case letters. Please see transactions #35079th domain transaction (schema) '''"attr_names": [ "Date of birth", "Over 18", "First name", "Last name", "ID proof", "Level of assurance", "Timestamp", "Nationality", "Document expiry date" ], "name": "Onfido Schema v223", "version": "1.2" ''' and

kenebert (Thu, 21 Nov 2019 17:06:52 GMT):

Clipboard - November 21, 2019 10:06 AM

kenebert (Thu, 21 Nov 2019 17:10:50 GMT):
2. Hving attribute names in the creddef, credentials, and presentations that do match their base schemas will make it very difficult to process those attributes by systems using schemas with uppercase letters or spaces. 3. Unintended name collisions will occur as the result of the canonization of attribute names. Therefore, I think that Indy should not canonize the schema names and make them lose their original schema names. INDY-2300 should make the creddef, credentials, and presentations match the original schema attribute names, not make the schema require canonization before it can be used in the Indy ecosystem.

kenebert (Thu, 21 Nov 2019 17:36:42 GMT):
The clipboard pasted above shows the canonized names in the corresponding creddef.

kenebert (Thu, 21 Nov 2019 17:36:42 GMT):
The clipboard pasted above shows the canonized names in the corresponding creddef. The 'r' values have been edited to omit most of the digits.

rjones (Thu, 21 Nov 2019 17:45:23 GMT):

no-alpha.jpeg

ashcherbakov (Fri, 22 Nov 2019 07:43:35 GMT):
@kenebert INDY-2300 is not about Schema pyaload (attributes names that came from the author). This just about names in general transaction structure (such as `data`, `metadata`, ``version`, etc.). So, it's not intended to canonize/change/lost original schema names, but just to make the transacation/request format consistent.

esplinr (Fri, 22 Nov 2019 16:10:49 GMT):
@kenebert Is this the real issue you are referring to? https://jira.hyperledger.org/browse/IS-1004 We agree it should be fixed.

kenebert (Sat, 23 Nov 2019 03:32:36 GMT):
@ashcherbakov @esplinr Perhaps I am mistaken. The behavior I have observed is that when a credential definition is created, the attribute values in the schema seem to be lowercased and have the spaces removed as the credential definition is written. I am using aca-py to create the schema and credential definition. Perhaps aca-py is the layer performing the canon function. In looking through the code I thought that it might be that libindy/src/domain/anoncreds/credential_attr_tag_policy CredentialAttrTagPolicy could be responsible. I believe this was implemented as a result of IS-1258.

kenebert (Sat, 23 Nov 2019 03:35:13 GMT):
I believe IS-1004 is closely related to this issue. Thanks for the link to the issue.

athira (Mon, 25 Nov 2019 19:04:35 GMT):
Has joined the channel.

esplinr (Mon, 25 Nov 2019 23:02:22 GMT):
Indy Contributors call is starting: https://zoom.us/j/615818107

sergey.minaev (Mon, 02 Dec 2019 15:58:39 GMT):
Indy Contributors call is about to start: https://zoom.us/j/615818107

kumar89 (Tue, 03 Dec 2019 14:12:46 GMT):
Has joined the channel.

esplinr (Mon, 09 Dec 2019 23:01:59 GMT):
Starting the Indy Contributors call: https://zoom.us/j/615818107

burdettadam (Fri, 13 Dec 2019 21:38:54 GMT):
Any indy-node maintainers, please review my Rich Schema's Schema PR https://github.com/hyperledger/indy-node/pull/1513

esplinr (Mon, 16 Dec 2019 16:01:42 GMT):
Starting the Indy Contributors call: https://zoom.us/j/615818107

esplinr (Mon, 20 Jan 2020 23:00:46 GMT):
We are starting the Indy Contributors call: https://zoom.us/j/615818107

SteveGoob (Wed, 22 Jan 2020 23:06:56 GMT):
@esplinr @sergey.minaev @andrew.nikitin I'm designing a _true_ rpm repository for Sovrin and Indy artifacts, and I came up with a versioning system that I believe effectively balances our needs with convention and allows for proper package sorting, ("convention" mostly coming from the [Fedora Packaging Guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/)). Here's the breakdown: - `stable`: The `Version` field contains the version tagged in the git repository that adheres to semantic version standards, (e.g. `1.14.2`). Because all stable releases will be tracked with a separate version, the `Release` field will always be `1`. - `rc`: The `Version` field will use the version projected to be released from it. To differentiate it from the `stable` versions, `Release` will always be of the form `0.`. The `0.` signifies its state as a prerelease. - `master` and other dev builds: By convention, the `Version` should be set to `0`, and `Release` should be of the form `..`. In this system, each stream is separately installable. e.g., - `stable`: `yum install libindy`. This will always track stable. - `rc`: Assuming `1.14.2` has not released yet, `yum install libindy-1.14.2`. This will grab the prerelease and track stable once stable matches/passes that `1.14.2`. - `master`: `yum install libindy-0-master`. This will track the master branch as far as I can tell. It may try to upgrade to a different branch that sorts sooner than "master" does, like "feature-xx" I've definitely had pushback on the "version master as 0" standard, and I'm willing to change that if anyone has a better solution. Also, this proposal will come with a some changes to the CD pipeline, (not unexpectedly), but in some places will require the CI system to know what the next version of stable will be, (see `rc` standard ^^). I'm not sure how easy/difficult that would be to implement, and/or how much maintainer intervention is needed to handle that. Thoughts? (A preview of the repository is available for viewing [here](https://repo.sovrin.org/nexus/#browse/browse:rpm))

SteveGoob (Wed, 22 Jan 2020 23:06:56 GMT):
I'm designing a _true_ rpm repository for Sovrin and Indy artifacts, and I came up with a versioning system that I believe effectively balances our needs with convention and allows for proper package sorting, ("convention" mostly coming from the [Fedora Packaging Guidelines](https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/)). Here's the breakdown: - `stable`: The `Version` field contains the version tagged in the git repository that adheres to semantic version standards, (e.g. `1.14.2`). Because all stable releases will be tracked with a separate version, the `Release` field will always be `1`. - `rc`: The `Version` field will use the version projected to be released from it. To differentiate it from the `stable` versions, `Release` will always be of the form `0.`. The `0.` signifies its state as a prerelease. - `master` and other dev builds: By convention, the `Version` should be set to `0`, and `Release` should be of the form `..`. In this system, each stream is separately installable. e.g., - `stable`: `yum install libindy`. This will always track stable. - `rc`: Assuming `1.14.2` has not released yet, `yum install libindy-1.14.2`. This will grab the prerelease and track stable once stable matches/passes that `1.14.2`. - `master`: `yum install libindy-0-master`. This will track the master branch as far as I can tell. It may try to upgrade to a different branch that sorts sooner than "master" does, like "feature-xx" I've definitely had pushback on the "version master as 0" standard, and I'm willing to change that if anyone has a better solution. Also, this proposal will come with a some changes to the CD pipeline, (not unexpectedly), but in some places will require the CI system to know what the next version of stable will be, (see `rc` standard ^^). I'm not sure how easy/difficult that would be to implement, and/or how much maintainer intervention is needed to handle that. Thoughts? (A preview of the repository is available for viewing [here](https://repo.sovrin.org/nexus/#browse/browse:rpm))

SteveGoob (Wed, 22 Jan 2020 23:33:15 GMT):
My code changes for this proposal are in PR [#2048](https://github.com/hyperledger/indy-sdk/pull/2048)

sergey.minaev (Mon, 27 Jan 2020 15:53:26 GMT):
We are about to start the Indy Contributors call (in ~5min) https://zoom.us/j/615818107

SteveGoob (Thu, 30 Jan 2020 19:55:51 GMT):
On Sovrin chat, we discussed some of this proposal and came to a better solution regarding packages that are not `rc` or `stable`. Instead of `Version` being always set to `0`, we have chosen to opt for the most recent version (e.g. `1.14.1`) with a `~`. The release does not contain the branch. For example, this would be what the name of a package would look like: `libindy-1.14.1~master-1234.20200115git1234abcd.x86_64.rpm`

SteveGoob (Thu, 30 Jan 2020 19:55:51 GMT):
On Sovrin chat, we discussed some of this proposal and came to a better solution regarding packages that are not `rc` or `stable`. Instead of `Version` being always set to `0`, we have chosen to opt for the most recent version (e.g. `1.14.1`) with a `~`. The `Release` will not contain the branch. For example, this would be what the name of a package would look like: `libindy-1.14.1~master-1234.20200115git1234abcd.x86_64.rpm`

SteveGoob (Thu, 30 Jan 2020 19:57:19 GMT):
This will sort better, allow for simpler installation, and disrupt current development practices less.

esplinr (Mon, 03 Feb 2020 23:03:39 GMT):
Anyone available to collaborate on Indy? @kdenhartog @kenebert @MALodder @andrew.whitehead @smithbk

MALodder (Mon, 03 Feb 2020 23:03:40 GMT):
Has joined the channel.

andrew.whitehead (Mon, 03 Feb 2020 23:03:40 GMT):
Has joined the channel.

esplinr (Mon, 03 Feb 2020 23:03:42 GMT):
https://zoom.us/j/615818107

kdenhartog (Mon, 03 Feb 2020 23:05:05 GMT):
yeah jumping on now

rehuman (Tue, 04 Feb 2020 19:09:41 GMT):
Has joined the channel.

esplinr (Mon, 10 Feb 2020 16:02:56 GMT):
Starting the Indy Contributors call: https://zoom.us/j/615818107 https://wiki.hyperledger.org/display/indy/2020-02-10+Indy+Contributors+Call

esplinr (Mon, 10 Feb 2020 18:28:49 GMT):
As discussed during the call, we want to schedule two additional collaboration sessions. If you are interested in these topics, please let me know whether the proposed time works for you: * Rich Schemas development: Tuesday February 11 at 8AM Mountain (3PM UTC). NOTE THAT THIS WOULD BE TOMORROW * Techniques for supporting an Indy network: Tuesday February 25 at 8AM Mountain (3PM UTC).

esplinr (Mon, 10 Feb 2020 23:36:00 GMT):
Per our discussion in the Indy Contributors call this morning, we will be having two special calls this month: * Tuesday, February 11 @ 15H UTC to collaborate on W3C Verifiable Credentials / Indy Rich Schemas * Tuesday, February 25 @ 15H UTC to discuss how best to support an Indy Network I updated the agendas in the wiki, and the Hyperledger calendar.

NikhilPrakash (Wed, 12 Feb 2020 00:45:02 GMT):
Has joined the channel.

ashcherbakov (Thu, 13 Feb 2020 09:26:36 GMT):
@brentzundel @kenebert A HIPE for common parts of all Rich Schema objects https://github.com/hyperledger/indy-hipe/pull/153 I think that if we agree about this HIPE, HIPEs for individual Rich Schema objects can be much smaller and define the payload content only (general template, metadata and formats how it's stored and requested will be the same).

brentzundel (Thu, 13 Feb 2020 09:26:36 GMT):
Has joined the channel.

nacerix (Sun, 23 Feb 2020 14:36:10 GMT):
Has joined the channel.

esplinr (Mon, 24 Feb 2020 15:56:43 GMT):
Starting the Indy Contributors call in 4 minutes: https://wiki.hyperledger.org/display/indy/2020-02-24+Indy+Contributors+Call https://zoom.us/j/615818107

esplinr (Mon, 24 Feb 2020 16:59:02 GMT):
I don't understand why the call just died.

esplinr (Mon, 24 Feb 2020 16:59:32 GMT):
My Zoom is working fine, and I was the host. I wonder if one of the co-hosts killed the call?

esplinr (Mon, 24 Feb 2020 16:59:55 GMT):
Thanks for the useful collaboration session.

andrew.whitehead (Mon, 24 Feb 2020 17:00:59 GMT):
It said another meeting was started under the same ID

andrew.whitehead (Mon, 24 Feb 2020 17:00:59 GMT):
It said another meeting was started under the same ID/account

AhimbisibweBrian (Mon, 24 Feb 2020 23:09:14 GMT):
Has joined the channel.

AhimbisibweBrian (Mon, 24 Feb 2020 23:09:30 GMT):
hello

AhimbisibweBrian (Mon, 24 Feb 2020 23:09:53 GMT):
am brian from uganda happy to be part of th community

kumar89 (Mon, 02 Mar 2020 15:25:00 GMT):
Do we have the Indy can today please...i could not able to see it in the calendar...

esplinr (Mon, 09 Mar 2020 14:59:37 GMT):
@kumar89 We've been meeting every other Monday.

esplinr (Mon, 09 Mar 2020 15:00:01 GMT):
So we're starting our call now: https://zoom.us/j/615818107

ashcherbakov (Thu, 19 Mar 2020 08:21:24 GMT):
A HIPE for Rich Schema object updates and details: https://github.com/hyperledger/indy-hipe/pull/156 (FYI @danielhardman )

ashcherbakov (Mon, 23 Mar 2020 15:06:24 GMT):
Starting the Indy Contributors call: https://zoom.us/j/244779296

bshambaugh (Sun, 29 Mar 2020 02:33:09 GMT):
Has joined the channel.

jramps9 (Tue, 07 Apr 2020 15:53:29 GMT):
Has joined the channel.

jramps9 (Tue, 07 Apr 2020 15:53:30 GMT):
Hello Indy contributors! Friendly reminder to pls join us for the Marketing Committee-DevRel call tomorrow, 4/8 at 9am PT. This is a great opportunity to learn how you can get involved in many aspects of Hyperledger marketing including overall messaging, events, content, social media, PR etc. Feel free to add items to the agenda: https://wiki.hyperledger.org/x/_QjcAQ Hope to see you there :slight_smile:

rjones (Thu, 30 Apr 2020 14:47:55 GMT):
hi - is this repo used? https://github.com/hyperledger/indy-jenkins-pipeline-lib

rjones (Thu, 30 Apr 2020 14:48:01 GMT):
I'd like to archive it if not

kdenhartog (Sun, 03 May 2020 21:53:54 GMT):
that's a question best answered by @esplinr or @ashcherbakov I think

swcurran (Sun, 03 May 2020 23:03:59 GMT):
FYI: Indy Contributors meeting tomorrow (Monday) morning in the US - 8AM Pacific, 11AM Eastern. Zoom info: https://zoom.us/j/244779296 Agenda for the meeting is here: https://wiki.hyperledger.org/display/indy/2020-05-04+Indy+Contributors+Call

esplinr (Wed, 06 May 2020 13:41:09 GMT):
Much of our team was enjoying a holiday, but should be back now. @sergey.minaev is that Jenkins repo still used?

swcurran (Mon, 11 May 2020 22:19:39 GMT):
Help Wanted request: The BC Gov team had been planning on doing the initial work for converting the Indy CI/CD pipelines from Jenkins to GitHub Actions. However, priorities have shifted in the past few weeks and the resources expected to be available for that work are going to be working on other Trust over IP priorities for the foreseeable future. As such, that work is back to being unassigned. If anyone has the expertise and time to do that work, the community would greatly appreciate it.

rjones (Wed, 13 May 2020 02:49:40 GMT):
@swcurran How does [this look](https://dev.azure.com/Hyperledger/Indy/_build/results?buildId=14082&view=logs&j=12f1170f-54f2-53f3-20dd-22fc7dff55f9)? [Change detailed here](https://github.com/hyperledger-cicd/indy-sdk/commit/a4a0e3ef99b61424dedd58f78413a6b359f8c4b1)

jramps9 (Wed, 13 May 2020 12:12:18 GMT):
Hello Indy contributors! Reminder to please join the DevRel Marketing Committee call at 9am PT TODAY, 5/13! Take a look at the agenda and add items here: https://wiki.hyperledger.org/display/Marketing/2020-05-13+Meeting+notes

swcurran (Fri, 15 May 2020 17:11:45 GMT):
@danielhardman @MALodder @andrew.whitehead - are all of you able to make the Indy Contributors call this Monday morning to discuss revocation 2 data structures and algorithms? 8AM US Pacific, 9AM Mountain.

MALodder (Fri, 15 May 2020 17:13:41 GMT):
Possibly

danielhardman (Fri, 15 May 2020 17:29:44 GMT):
I will come if others do

rjones (Fri, 15 May 2020 17:30:22 GMT):
@here I apologize for the spam, but I think this is the correct forum. [I propose archiving indy-crypto](https://github.com/hyperledger/indy-crypto/pull/168) and seek feedback

esplinr (Fri, 15 May 2020 17:33:16 GMT):
We have been waiting to archive it until Ursa is fully integrated into Indy Node.

esplinr (Fri, 15 May 2020 17:34:05 GMT):
@cam-parra I know that your pull request did most of the work. Is it all done?

esplinr (Fri, 15 May 2020 17:35:43 GMT):
It looks like there is still one PR waiting for merge, that builds on what Cam was doing: https://github.com/hyperledger/indy-plenum/pull/1481

esplinr (Fri, 15 May 2020 17:36:22 GMT):
It has received all the necessary reviews, but is still blocked.

esplinr (Fri, 15 May 2020 17:36:55 GMT):
Ah, I think we need to update permissions for people on the repo as the current maintainers aren't the ones with GitHub permissions.

esplinr (Fri, 15 May 2020 17:37:12 GMT):
Anyway @rjones , I think we can archive indy-crypto as soon as that work is done.

esplinr (Fri, 15 May 2020 17:38:46 GMT):
I nudged @Toktar to look at it on Monday.

Toktar (Fri, 15 May 2020 17:38:46 GMT):
Has joined the channel.

esplinr (Fri, 15 May 2020 17:40:03 GMT):
I think @andrew.whitehead (github: andrewwhitehead) should be a code owner of indy-plenum.

rjones (Fri, 15 May 2020 18:16:54 GMT):
looks like 1481 is merged now.

esplinr (Fri, 15 May 2020 18:17:06 GMT):
Wow, Renata was fast.

esplinr (Fri, 15 May 2020 18:17:43 GMT):
So the question is whether that was all the work, or if indy-crypto is still used by the testing tools or something. @cam-parra thoughts?

rjones (Fri, 15 May 2020 18:18:18 GMT):
it won't be deleted. It hasn't had a meaningful commit in almost a year and a half

rjones (Fri, 15 May 2020 18:18:55 GMT):
also, see [the security alerts](https://github.com/hyperledger/indy-crypto/network/alerts)

swcurran (Fri, 15 May 2020 18:34:28 GMT):
@andrew.whitehead is in, sounds like @danielhardman as well, so that leaves @MALodder. Andrew has a pretty cool idea that could work better than what we are looking at today, and I'd like to get everyone together to go over what Daniel has been finding.

swcurran (Fri, 15 May 2020 18:45:36 GMT):
I'm hoping that @WadeBarnes responded to this.

danielhardman (Mon, 18 May 2020 15:05:52 GMT):
Is there a meeting today?

danielhardman (Mon, 18 May 2020 15:06:15 GMT):
If yes, is it at https://zoom.us/j/615818107?

andrew.whitehead (Mon, 18 May 2020 15:11:11 GMT):
It's at https://zoom.us/j/244779296

andrew.whitehead (Mon, 18 May 2020 15:11:11 GMT):
It's at https://zoom.us/j/244779296 @danielhardman

danielhardman (Mon, 18 May 2020 16:03:28 GMT):
Re. optimal size of rev registry, here is the EFF article I linked. I recommend that we all read this. https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy

sergey.minaev (Tue, 19 May 2020 11:04:47 GMT):
@swcurran @danielhardman @esplinr @kenebert Over last several months @mirgee and his team have made significant contribution to IndySDK repo and especially dummy-cloud-agent. I think we should grant write access at least to 1 person from the team or may be to 2 of them. I was going to raise this topic while contributors call yesterday but we have a lot of discussion about revocation, so I suggest to not wait the next call, but discuss it here. Miroslav, could you suggest the best candidates?

sergey.minaev (Tue, 19 May 2020 11:04:47 GMT):
@swcurran @danielhardman @esplinr @kenebert Over last several months @mirgee and his team have made significant contribution to IndySDK repo and especially dummy-cloud-agent. I think we should grant write access at least to 1 person from the team or may be to 2 of them. I was going to raise this topic while contributors call yesterday but we had a lot of discussion about revocation, so I suggest to not wait the next call, but discuss it here. Miroslav, could you suggest the best candidates?

mirgee (Tue, 19 May 2020 11:04:48 GMT):
Has joined the channel.

mirgee (Tue, 19 May 2020 12:35:00 GMT):
Thank you @sergey.minaev! I would suggest me (mirgee on github) if you give permissions to one person, and also @PatrikStas (Patrik-Stas on github) - we would prefer both of us, but if you decide to give them to only one, than we would prefer me.

swcurran (Tue, 19 May 2020 13:24:36 GMT):
Sounds good to me. Great stuff!

danielhardman (Tue, 19 May 2020 15:16:56 GMT):
That also sounds very reasonable to me. I just checked and it looks like I can add people to the indy-sdk-contributors group, which may give the access that's needed. Let me try it.

danielhardman (Tue, 19 May 2020 15:19:05 GMT):
Nope. In order to add someone to the team, they must first be added to the Hyperledger org on github. Then I can add them to a team. It looks like we need to have Ry add them to the org for us. Should we send him a note?

rjones (Tue, 19 May 2020 17:27:01 GMT):
dunno - what would you tell him?

rjones (Tue, 19 May 2020 17:30:19 GMT):
@danielhardman if you go here: https://github.com/orgs/hyperledger/teams/indy-sdk-contributors/members do you see the two pending invitations?

danielhardman (Tue, 19 May 2020 17:31:31 GMT):
Yes. I can issue those invitations and manage them. I just can't add them to the hyperledger org in the first place, which keeps you on the hook. Sorry not to solve this on our own...

rjones (Tue, 19 May 2020 17:32:08 GMT):
it is a shortcoming of GitHub, there isn't much to do about it. I just wanted to be sure I had added the right people to the right group is all

PatrikStas (Wed, 20 May 2020 13:10:03 GMT):
Thanks for adding us! We'll definitely help out maintaning indy-sdk

danielhardman (Thu, 21 May 2020 23:35:28 GMT):
@andrew.whitehead , @esplinr , @sergey.minaev , and @brentzundel : I just assigned myself https://jira.hyperledger.org/browse/IS-1508. The only indy-credx library that I know of is the one that Andrew started. I forked his repo and built and ran all the tests on my machine as an early step. I'm happy to look into next steps. However, I have a doubt about a couple things. 1. Shouldn't there be a hyperledger repo, not just Andrew's fork? Should I start by making that and getting CI/CD set up? 2. Should I go straight to an aries-credx project instead?

swcurran (Fri, 22 May 2020 00:54:47 GMT):
IHMO, since this is about indy format credentials, it should be an indy-credx library. It would plug into an aries abstraction for handling indy and other style credentials. It's not as clear cut as indy-vdr, but I think it is the right approach. Definitely, indy-credx should be a Hyperledger repo. Andrew was getting it to a certain level of maturity before transferring it, but it could be transferred at any time.

esplinr (Fri, 22 May 2020 13:34:09 GMT):
After reporting issues on Sovrin Staging Net, a few people have asked me how to troubleshoot Indy Node. This blog post from @sergey.khoroshavin was very timely: https://www.evernym.com/blog/troubleshooting-an-indy-network/ And this recording of a call on this topic: https://www.youtube.com/watch?v=8qCzr0Wx-Ig&list=PLRp0viTDxBWGLdZk0aamtahB9cpJGV7ZF&index=4 Also this introduction to Indy published by @ashcherbakov https://ssimeetup.org/hyperledger-indy-public-blockchain-node-alexander-shcherbakov-webinar-43/ And this deep dive: https://www.youtube.com/watch?v=WZin717AT_A&list=PLRp0viTDxBWGLdZk0aamtahB9cpJGV7ZF&index=35

esplinr (Fri, 22 May 2020 13:34:39 GMT):
cc @smithbk and @CHempel

CHempel (Fri, 22 May 2020 13:34:39 GMT):
Has joined the channel.

danielhardman (Fri, 22 May 2020 16:32:31 GMT):
@andrew.whitehead : are you willing to have indy-credx transfer to Hyperledger now?

andrew.whitehead (Fri, 22 May 2020 16:49:31 GMT):
I was hoping to get that and indy-vdr depending on the same indy-shared-rs for the data types and common traits, but that can come later. Happy to move it if that's easier

andrew.whitehead (Fri, 22 May 2020 16:50:04 GMT):
There's no rich schema types there but they do exist in indy-shared-rs (and indy-vdr)

danielhardman (Fri, 22 May 2020 16:54:14 GMT):
I can work off your fork as upstream for a while. That's not hard. It just wasn't clear to me how much I should worry about CI/CD as I did so. As long as it's just your fork, I assume I just need to observe all tests passing before I raise a PR?

andrew.whitehead (Fri, 22 May 2020 16:55:24 GMT):
Yep, looks like I haven't added the github actions yet but I can set those up to check on a PR

redongjun (Sun, 24 May 2020 06:21:03 GMT):
Has joined the channel.

rjones (Tue, 26 May 2020 16:11:53 GMT):
@danielhardman since https://github.com/hyperledger/indy-plenum/pull/1481 is merged, could I merge https://github.com/hyperledger/indy-crypto/pull/168 to archive indy-crypto?

esplinr (Tue, 26 May 2020 22:51:10 GMT):
It looks like Indy Node still has a dependency on Indy Crypto, which is blocking builds.

esplinr (Thu, 28 May 2020 15:45:30 GMT):
@mccown See the resources I posted on May 22 for learning about Indy Node.

mccown (Thu, 28 May 2020 15:45:30 GMT):
Has joined the channel.

CHempel (Fri, 29 May 2020 13:16:18 GMT):
User User_1 added by CHempel.

swcurran (Fri, 29 May 2020 18:41:31 GMT):
This week's Indy Contributors call will mostly be about how we can enable dynamic access to multiple Indy ledgers --- allowing an agent (for example, a Mobile Wallet app) to access multiple Indy ledgers in a single session with minimal effort from the agent owner. An example for those that have used the Streetcred and esatus wallets: using both Sovrin Staging and Sovrin Mainnet without having to switch the settings over and over. We'll also cover the latest progress on Revocation 2.0 work. The call is Monday, June 1 at 8AM US Pacific, dial-in information: https://zoom.us/j/244779296 Agenda can be found here: https://wiki.hyperledger.org/display/indy/2020-06-01+Indy+Contributors+Call Join us!

esplinr (Fri, 29 May 2020 23:06:05 GMT):
Great topic. It will also be good to cover the plan for releasing Indy Node and Indy SDK with the latest improvements.

Jintolus (Mon, 01 Jun 2020 15:22:05 GMT):
Has joined the channel.

swcurran (Mon, 01 Jun 2020 18:40:15 GMT):
The indy contributors call happened this morning and the call recording is available on the Wiki page (above ^^^). An issue was opened against Indy SDK to continue the discussion towards consensus on the best approach. Please add your comments here: https://github.com/hyperledger/indy-sdk/issues/2181

ianco (Tue, 02 Jun 2020 18:24:12 GMT):
Indy gurus, I'd appreciate some feedback on this PR: https://github.com/hyperledger/indy-sdk/pull/2179 ... It adds support to proof validation so that predicates can support restrictions of the form "restrictions": [{ ..., "attr::name::value": "Alex" }] (currently with these kinds of restrictions in predicates the proof process will work up to the validation step and then fail) The issue is logged here: https://jira.hyperledger.org/browse/IS-1557 (The PR is a work in progress, I don't want to put too much work into it if I'm already out in left field)

swcurran (Tue, 02 Jun 2020 19:00:12 GMT):
@esplinr ^^^ Not sure who on your team is looking at the SDK PRs. This is a fairly important one, I think.

esplinr (Tue, 02 Jun 2020 23:56:20 GMT):
Thanks @ianco . This is one that has been requested a lot.

esplinr (Tue, 02 Jun 2020 23:58:36 GMT):
@sergey.minaev is still reviewing PRs, as are the other maintainers ( @mirgee and @PatrikStas ).

ianco (Wed, 03 Jun 2020 15:53:32 GMT):
Thanks @esplinr ... the PR is still in draft, but I would appreciate some feedback before I put more work into it (it includes a couple of unit tests that illustrate the problem and the fix)

rjones (Mon, 08 Jun 2020 15:45:48 GMT):
@esplinr @nage @danielhardman I think the requirements to archive indy-crypto have been met for about a month - [thoughts?](https://github.com/hyperledger/indy-crypto/pull/168)

nage (Mon, 08 Jun 2020 16:37:27 GMT):
I agree. Archive it!

rjones (Mon, 08 Jun 2020 16:38:41 GMT):
You have the power, @nage :)

rjones (Mon, 08 Jun 2020 16:39:26 GMT):
I mean, I also have a merge button, but I'd rather one of you does it

rjones (Mon, 08 Jun 2020 16:40:55 GMT):
thanks!

nage (Mon, 08 Jun 2020 16:41:22 GMT):
@esplinr or @danielhardman any dissent?

rjones (Mon, 08 Jun 2020 16:41:34 GMT):
oh whoops ... I can unarchive it :)

nage (Mon, 08 Jun 2020 16:42:10 GMT):
No the merge stands 😇

nage (Mon, 08 Jun 2020 16:42:30 GMT):
GitHub is cool that way, we can go back if we must but I doubt we will want to

rjones (Mon, 08 Jun 2020 17:35:44 GMT):
https://github.com/hyperledger/indy-jenkins-pipeline-lib/pull/4 (retire jenkins - not sure if this is used)

nage (Mon, 08 Jun 2020 17:48:59 GMT):
@esplinr ^^^

danielhardman (Mon, 08 Jun 2020 23:06:42 GMT):
Sorry, it took me a little while to see this. No descent for me let's do it if it hasn't already been done. I'm happy to press a button for right as well, if that's needed. I'm out doing an errand, but I'll do it when I get home if it hasn't already been done by somebody else.

danielhardman (Mon, 08 Jun 2020 23:14:11 GMT):
Sorry for the bad spelling. I'm using text-to-speech on my phone.

danielhardman (Tue, 09 Jun 2020 02:50:32 GMT):
I merged this.

jramps9 (Tue, 09 Jun 2020 15:52:47 GMT):
Hi Indy contributors! Reminder the Marketing Committee-Dev Relations call is tomorrow, 6/10 at 9am PT. Hope to see you there! https://wiki.hyperledger.org/display/Marketing/2020-06-010+Meeting+notes

rjones (Tue, 09 Jun 2020 21:42:20 GMT):
Hi folks. I'm looking at what a [contribute-a-thon](https://wiki.hyperledger.org/display/events/Hyperledger+Contribute-a-thon+Organizer%27s+Guide) for Indy might look like - who would be interested in driving that?

rjones (Tue, 09 Jun 2020 21:43:21 GMT):
[Here is some stuff from Fabric docs team](https://hyperledger-fabric.readthedocs.io/en/latest/CONTRIBUTING.html#ways-to-contribute) that is recent

swcurran (Tue, 09 Jun 2020 21:45:31 GMT):
I can do some thinking on it. :-) Can't resist

rjones (Tue, 09 Jun 2020 21:46:33 GMT):
I'm not sure what it would look like - Besu wanted a better onramp, for instance. Defining needs and goals is hard

swcurran (Fri, 12 Jun 2020 19:57:18 GMT):
This week's Indy Contributors call will be about the progress in Ursa on revocation 2.0 and BBS+ and what we can do in Indy to prepare. Mike Lodder will be joining us to cover that. I've also been doing lots lately with Sovrin and the Sovrin Mainnet and I'll give a draft overview of the important things I'd like to see happening Indy for Sovrin and other Indy deployments. The call is Monday, June 15 at 8AM US Pacific, dial-in information: https://zoom.us/j/244779296 Agenda can be found here: https://wiki.hyperledger.org/display/indy/2020-06-15+Indy+Contributors+Call Join us!

swcurran (Mon, 15 Jun 2020 22:07:46 GMT):
We'd like to move the Indy Contributors call from it's current time (every 2nd Monday) to a new time not opposite other meetings of interest. I've been looking at options to find a time that does not conflict with existing Hyperledger or Indy-related meetings. Please weigh in on the options: - 8AM Tuesdays the same weeks as the current schedule (next meeting June 30 - conflicts with the Climate Action and Accounting SIG which is prime use case for Indy - 8AM Tuesday off weeks from current schedule (next meeting June 23) <<<<------Best Choice/Least conflict - 8AM Fridays (next meeting July 3) Barring objection, I'm going to go with the next meeting being June 23 and every 2nd Tuesday thereafter. Please speak now!

PatrikStas (Wed, 17 Jun 2020 10:17:34 GMT):
Can someone try to rerun master build pipeline in Jenkins? I think I don't have permissions to do that. I have impression that the last master build failure was due to an issue on crates.io side.

PatrikStas (Wed, 17 Jun 2020 10:26:45 GMT):
Also, I know there used to be discussions about porting Sovrin jenkins to another ci/cd platform. I don't know how it went, what was conclusion but a while ago I've started working on porting jenkins to github actions as bit of an experiment https://github.com/hyperledger/indy-sdk/pulls It's far from mature still, but I was thinking we could experimentally merge it while still primarily relying on Jenkins. Github Actions are free for public repos. What do you think?

brentzundel (Fri, 19 Jun 2020 17:21:50 GMT):
That time on Tuesday conflicts with the W3C DID WG call

swcurran (Tue, 23 Jun 2020 04:35:28 GMT):
This week's Indy Contributors call will be about things needed for operational support of an Indy Network like Sovrin -- monitoring, metrics, etc -- with the goal of getting some collaboration to go in building out those tools. The call is Tuesday, June 23 at 8AM US Pacific. 15:00 UTC, dial-in information: https://zoom.us/j/244779296 Agenda can be found here: https://wiki.hyperledger.org/display/indy/2020-06-23+Indy+Contributors+Call Join us!

esplinr (Tue, 23 Jun 2020 14:17:10 GMT):
@rjones @DavidBoswell I see that @swcurran updated the calendar in Groups.io to show the new date and time for the Indy Contributors call, but it isn't showing up on the Hyperledger Google calendar. Does something need a kick to unblock the synchronization?

DavidBoswell (Tue, 23 Jun 2020 14:17:10 GMT):
Has joined the channel.

WadeBarnes (Tue, 23 Jun 2020 15:52:06 GMT):
Has joined the channel.

rjones (Tue, 23 Jun 2020 16:29:45 GMT):
It takes about 24 hours for google to pick up the change.

rjones (Tue, 23 Jun 2020 16:30:18 GMT):
There is nothing any of us can do to make it faster

swcurran (Tue, 23 Jun 2020 16:32:24 GMT):
I did it last week, so well over 24 hours.

esplinr (Tue, 23 Jun 2020 16:36:25 GMT):
@rjones We are aware. We waited before escalating.

rjones (Tue, 23 Jun 2020 16:58:25 GMT):
@dhuseby ideas?

dhuseby (Tue, 23 Jun 2020 16:58:25 GMT):
Has joined the channel.

dhuseby (Wed, 24 Jun 2020 17:11:24 GMT):
@esplinr I'm catching up

esplinr (Thu, 25 Jun 2020 00:20:18 GMT):
I just removed the Indy Semantics WG meeting, and noticed that the Indy Contributors meeting still isn't showing up in the Google calendar.

PatrikStas (Mon, 29 Jun 2020 11:15:16 GMT):
Who has admin rights on jekinks? Can someone kill this job? https://build.sovrin.org/blue/organizations/jenkins/indy-sdk%2Findy-sdk-ci/detail/PR-2195/2/pipeline It's been hanging for 1 week

lynn.bendixsen (Wed, 01 Jul 2020 20:47:22 GMT):
Hi Patrik, I have admin rights and was able to "stop" the job. I don't have any Jenkins expertise, but I do have rights ;)

assit (Sat, 04 Jul 2020 04:50:44 GMT):
Has joined the channel.

assit (Sat, 04 Jul 2020 17:50:04 GMT):
Has left the channel.

ianco (Sun, 05 Jul 2020 18:38:14 GMT):
Just commenting to remind about this PR @esplinr

brentzundel (Mon, 06 Jul 2020 17:40:23 GMT):
There are a number of Indy PRs that need review, if there are community members looking for ways to contribute, we could use feedback on: https://github.com/hyperledger/indy-node/pull/1604 https://github.com/hyperledger/indy-node/pull/1607 https://github.com/hyperledger/indy-node/pull/1608 https://github.com/hyperledger/indy-plenum/pull/1486

swcurran (Mon, 06 Jul 2020 17:53:59 GMT):
We'll discuss on the indy-contributors call tomorrow morning. We'll also talk about some tools that can be used for monitoring Indy networks and the status of nodes.

swcurran (Mon, 06 Jul 2020 17:53:59 GMT):
We'll discuss these PRs on the indy-contributors call tomorrow morning. We'll also talk about some tools that can be used for monitoring Indy networks and the status of nodes and indy-vdr. Call is Tuesday, July 7th at 8AM US Pacific, dial-in information: https://zoom.us/j/244779296 Agenda will soon be found here: https://wiki.hyperledger.org/display/indy/2020-07-07+Indy+Contributors+Call

swcurran (Mon, 06 Jul 2020 20:32:37 GMT):
@brentzundel can I get you to lead the discussions on those tomorrow? I'll have them linked and can do it if you are not available.

brentzundel (Mon, 06 Jul 2020 20:33:19 GMT):
The DID WG call that normally conflicts is not being held tomorrow, so I can lead the discussion on those PRs.

hcsatish (Tue, 07 Jul 2020 16:42:18 GMT):
Has joined the channel.

andrew.whitehead (Wed, 08 Jul 2020 01:29:03 GMT):
I notice that Cargo.toml for indy-sdk lists the license as MIT/Apache-2.0, but the repo only contains the apache-2 license. Is it supposed to be dual licensed?

andrew.whitehead (Thu, 09 Jul 2020 15:08:30 GMT):
Could use reviews on this PR, it moves some shared indy dependencies into separate crates: https://github.com/hyperledger/indy-vdr/pull/41

andrew.whitehead (Thu, 09 Jul 2020 17:39:45 GMT):
@danielhardman ?

danielhardman (Thu, 09 Jul 2020 17:46:52 GMT):
To my knowledge, only Apache 2 is intended. I suspect that Cargo.tuml contains this because Rust treats them as a common license setting for a project. The only checked in LICENSE file is the Apache 2 one -- and I believe that's always been true.

andrew.whitehead (Thu, 09 Jul 2020 17:48:11 GMT):
Okay. That should probably be updated to just Apache-2.0 in the manifest. According to the docs the slash is a deprecated syntax as well

danielhardman (Thu, 09 Jul 2020 17:48:38 GMT):
Sounds appropriate.

danielhardman (Thu, 09 Jul 2020 17:50:07 GMT):
FWIW, I don't know that it would be hard to convince people to allow an MIT license, if the difference matters a lot. The key things we've cared about are the lack of copy-left, the openness, and the posture relative to patent encumbrances.

andrew.whitehead (Thu, 09 Jul 2020 17:51:30 GMT):
The combined MIT/Apache-2.0 seems very common in rust land so it's nice for compatibility

kdenhartog (Tue, 14 Jul 2020 02:51:44 GMT):
Where's the best place to request time to discuss a topic on the implementers call these days? I want to go over a proposal we're working on to get compliant did documents on Indy without adding additional transactions. The details of this can be found here: https://docs.google.com/document/d/1PE1KQHf41zlHbLm27UbgzJ7t7m2xr09JnjZWFT2ApwE/edit @mccown are you the one leading this call these days?

mccown (Tue, 14 Jul 2020 03:39:34 GMT):
Kyle, yes I lead the implementer's call. That would be a great presentation / discussion topic. I'll send you a PM and we can setup a time.

esplinr (Tue, 14 Jul 2020 04:36:46 GMT):
The Identity Implementers call is different from the Indy Contributors call. It covers more topics than just Indy. @swcurran leads the contributors call, and the agendas are in the wiki: https://wiki.hyperledger.org/display/indy/Indy+Contributors+Meeting

esplinr (Tue, 14 Jul 2020 04:36:54 GMT):
This is a timely topic, as we have been thinking along the same lines as you.

esplinr (Tue, 14 Jul 2020 04:37:14 GMT):
cc @brentzundel @sergey.minaev

kdenhartog (Tue, 14 Jul 2020 04:38:21 GMT):
I'd be happy to discuss it on both. When's the next contributors call? More than anything I'm looking for feedback as to things we may need to change and if everyone agrees to the next steps.

kdenhartog (Tue, 14 Jul 2020 04:38:21 GMT):
I'd be happy to discuss it on both if the people who attend are different. When's the next contributors call? More than anything I'm looking for feedback as to things we may need to change and if everyone agrees to the next steps.

swcurran (Tue, 14 Jul 2020 04:38:41 GMT):
I was kind of thinking the same thing -- the indy contributors call probably makes the most sense for this. Sorry @mccown :-) I'm just trying to steal your content.

swcurran (Tue, 14 Jul 2020 04:39:18 GMT):
Next Tuesday -- 8AM Pacific. Perfect for you... :-(

swcurran (Tue, 14 Jul 2020 04:39:48 GMT):
The conversation and exchange will be on the contributors call.

kdenhartog (Tue, 14 Jul 2020 04:39:49 GMT):
Oh lovely :smile: I'll add it to my calendar so I can make it

swcurran (Tue, 14 Jul 2020 04:40:52 GMT):
I'll talk to you about it. I'd like to help frame the issue as there are several related topics. Just had a long exchange with Tobias about them.

kdenhartog (Tue, 14 Jul 2020 04:42:17 GMT):
Works for me!

mccown (Tue, 14 Jul 2020 05:01:48 GMT):
@kdenhartog it looks like you have 2 great calls ... both with great times. :slight_smile:

esplinr (Wed, 15 Jul 2020 16:32:04 GMT):
I want to introduce @m00sey and @pfeairheller . They have been working on an Indy driver for Aries Framework Go (https://github.com/scoir/canis), and are interested in participating more on the project.

pfeairheller (Wed, 15 Jul 2020 16:32:04 GMT):
Has joined the channel.

m00sey (Wed, 15 Jul 2020 16:32:04 GMT):
Has joined the channel.

pfeairheller (Wed, 15 Jul 2020 17:17:32 GMT):
Hello everyone, nice to meet you. Thanks @esplinr

PatrikStas (Fri, 17 Jul 2020 06:40:27 GMT):
IndySDK master build pipeline ``` Uploading indy-sys v1.15.0-dev-1558 (/home/jenkins/workspace/indy-sdk_indy-sdk-cd_master/wrappers/rust/indy-sys) error: api errors (status 401 Unauthorized): The given API token does not match the format used by crates.io. ``` @lynn.bendixsen seems like the api token for creates.io expired, are you able to update it?

swcurran (Fri, 17 Jul 2020 13:41:11 GMT):
We'll take a look at it and see what can be determined. Lynn received the message about it. @esplinr -- is there anyone at Evernym that can help with this?

lynn.bendixsen (Fri, 17 Jul 2020 13:44:29 GMT):
@PatrikStas I looked at it for a few minutes, but don't have enough experience to see where and how to update the token.

swcurran (Fri, 17 Jul 2020 13:50:37 GMT):
Nevermind @esplinr --- @WadeBarnes is going to run with this one. He is just getting access now.

WadeBarnes (Fri, 17 Jul 2020 14:04:38 GMT):
I may need to be invited to the https://crates.io/ project(s). Current listed owners: - https://crates.io/users/Artemkaaas - https://crates.io/users/sovbot

WadeBarnes (Fri, 17 Jul 2020 14:04:38 GMT):
I may need to be invited to the https://crates.io/ project(s), as well. Current listed owners: - https://crates.io/users/Artemkaaas - https://crates.io/users/sovbot

swcurran (Fri, 17 Jul 2020 14:05:54 GMT):
OK @esplinr ^^^ we need help for that access.

swcurran (Fri, 17 Jul 2020 14:13:02 GMT):
@Artemkaaas --- Richard is out of the office. Could you help with this? @WadeBarnes needs access. He is with BC Gov and helping Sovrin with NetOps and CI/CD issues.

WadeBarnes (Fri, 17 Jul 2020 14:28:31 GMT):
I'm in Jenkins.

WadeBarnes (Fri, 17 Jul 2020 14:28:49 GMT):
Issue: `Tokens generated before 2020-07-14 were generated with an insecure random number generator, and have been revoked.`

WadeBarnes (Fri, 17 Jul 2020 14:28:58 GMT):
Just need to create a new token

WadeBarnes (Fri, 17 Jul 2020 14:30:16 GMT):
`For more information please see https://blog.rust-lang.org/2020/07/14/crates-io-security-advisory.html. We apologize for any inconvenience.`

WadeBarnes (Fri, 17 Jul 2020 14:59:35 GMT):
I've updated the token and started a new build, however I expect this to fail as my `crates.io` account does not have access to the repos yet.

WadeBarnes (Fri, 17 Jul 2020 15:06:10 GMT):
The build process references `https://github.com/sovrin-foundation/jenkins-shared.git` which I'll need access to at some point. @lynn.bendixsen, are you able to assist with that?

WadeBarnes (Fri, 17 Jul 2020 17:35:37 GMT):
@lynn.bendixsen, is updating the token with a new one generated using the `sovbot`'s crates.io account.

swcurran (Fri, 17 Jul 2020 20:35:07 GMT):
Hey folks --- on the Indy Contributors call this coming Tuesday (July 21, 8AM Pacific), we're going to be talking again about the DID Method underlying Indy -- currently "did:sov" and at the interoperability of the DID Method and Aries across multiple ledgers. What changes are needed to the DID Method, Indy, Indy SDK, Aries and/or Aries Storage layers to enable a prover to seamlessly create a proof that involves credentials rooted in different Indy networks, and for a verifier to verify such a proof? My goal is for this to be a first discussion in a near-term, focused effort on getting code written and deployed to accomplish that use case. My thought is that we (I??) need to organize a "Connectathon" like multi-day virtual conference to explore the possible solutions, decide on a sufficient goal endpoint, agree on what code needs to be implemented and define a plan to get the resources to do the coding. Please join us on Tuesday for this discussion -- https://wiki.hyperledger.org/display/indy/2020-07-21+Indy+Contributors+Call

tomislav (Sat, 18 Jul 2020 13:32:12 GMT):
I'm super interested to see this effort forward. It's been a big pain point for everyone.

WadeBarnes (Sat, 18 Jul 2020 14:32:46 GMT):
@PatrikStas, @swcurran, The build is back to normal.

kdenhartog (Tue, 21 Jul 2020 16:18:55 GMT):
Thanks all for letting me walk through my proposal for compliant did document support for Indy Here's the document link if anyone needs it: https://docs.google.com/document/d/1PE1KQHf41zlHbLm27UbgzJ7t7m2xr09JnjZWFT2ApwE/edit# I'll update the document to explain the single ATTRIB model better for everyone to review and In the next few weeks I'll be opening PRs for the various action items I identified in there to get this moving forward. I'll be sure to keep you all updated on this work as well along the way.

pfeairheller (Tue, 21 Jul 2020 19:57:17 GMT):
Since it was my first call I was quiet throughout, but I thought the proposal was spot on.

pfeairheller (Tue, 21 Jul 2020 19:59:37 GMT):
I have a related question... After submitting the PR for the golang wrapper for indy-vdr, I've started work on a VDRI indy implementation for aries-framework-go. Part of that work is materializing a did document from a resolved did on an Indy network. Before today I was planning on using the DID/Verkey from the nym and the endpoint from and Endpoint ATTRIB. Is that still a safe assumption for a "first pass" assuming it will change as soon as this `didDoc` ATTRIB become part of Indy?

swcurran (Tue, 21 Jul 2020 20:01:34 GMT):
Yes - that's the way to go for now.

pfeairheller (Tue, 21 Jul 2020 20:03:05 GMT):
Great, thanks for the quick reply!

swcurran (Tue, 21 Jul 2020 20:06:02 GMT):
We had a good Indy Contributors call today diving into evolving Indy to support full DIDDocs as a first class entity. Thanks to @kdenhartog for leading the discussion. Recording is here: https://wiki.hyperledger.org/display/indy/2020-07-21+Indy+Contributors+Call I'm continuing to work on an IIC "Indy Interop Conference" where we hammer would what we're going to do in Indy and related projects to enable Indy Interop along the lines of this use case: *_Enabling a prover to seamlessly create a proof that involves credentials rooted in different Indy networks, and for a verifier to verify such a proof._* Details to follow, help with organizing welcome.

rjones (Thu, 23 Jul 2020 21:49:11 GMT):
@esplinr @swcurran I have given up trying to fix the community calendar; what I did was create another calendar. The reference calendar is still the lists.hyperledger.org ICS file, but the version rendered in the wiki should be more up-to-date.

rjones (Thu, 23 Jul 2020 21:49:29 GMT):
I have learned way more today than I ever wanted to know about gsuite limitations.

esplinr (Thu, 23 Jul 2020 21:50:06 GMT):
Thank you for following up @rjones . The broken calendar has been concerning me.

esplinr (Thu, 23 Jul 2020 21:50:25 GMT):
So if we subscribe to the calendar currently in the wiki, then our appointment will work? Is it likely to break again in the future?

rjones (Thu, 23 Jul 2020 21:50:45 GMT):
Please subscribe to the ICS on lists directly, if you can.

rjones (Thu, 23 Jul 2020 21:50:58 GMT):
https://lists.hyperledger.org/ics/1902217/3131022486068381536/feed.ics

rjones (Thu, 23 Jul 2020 21:51:31 GMT):
The calendar that's rendering in the wiki is from my personal gmail account, which subscribes to that ICS feed.

esplinr (Thu, 23 Jul 2020 21:51:40 GMT):
Ah, that makes sense.

esplinr (Thu, 23 Jul 2020 21:52:00 GMT):
Do you plan to update the instructions in the wiki to point people to the calendar in lists.hyperledger.org?

rjones (Thu, 23 Jul 2020 21:52:06 GMT):
working on it.

esplinr (Thu, 23 Jul 2020 21:52:16 GMT):
:thumbsup:

rjones (Thu, 23 Jul 2020 21:53:16 GMT):
I wanted to let you know that there is a workaround. The next step, and I think the eventual solution, is to write an ics parser that publishes to gcal directly, so we can see the errors.

esplinr (Thu, 23 Jul 2020 21:53:31 GMT):
That sounds like a lot of work.

esplinr (Thu, 23 Jul 2020 21:54:59 GMT):
It works!

esplinr (Thu, 23 Jul 2020 21:54:59 GMT):
Using that ICS URL works!

esplinr (Thu, 23 Jul 2020 21:55:02 GMT):
Yay!

esplinr (Thu, 23 Jul 2020 21:55:17 GMT):
Thank you again.

rjones (Thu, 23 Jul 2020 21:55:58 GMT):
this is an amazingly widespread issue that has revealed a lot of implementation details of gsuite to me :)

esplinr (Thu, 23 Jul 2020 21:57:35 GMT):
Is that ICS file you shared above the correct one? It appears to still have the old Indy meetings (Indy contributors on Mondays and Indy Semantics on Tuesdays).

esplinr (Thu, 23 Jul 2020 21:57:41 GMT):
Maybe I did something wrong at my end.

esplinr (Thu, 23 Jul 2020 21:57:45 GMT):
_goes to double check._

esplinr (Thu, 23 Jul 2020 21:59:34 GMT):
I see in Groups.io how to subscribe to my calendar, but not how to subscribe to the calendar with all Hyperledger events.

esplinr (Thu, 23 Jul 2020 21:59:34 GMT):
I see in Groups.io how to subscribe to my calendar, but not how to subscribe to the calendar with all Hyperledger events. (i.e. to get the ICS feed you shared)

rjones (Thu, 23 Jul 2020 22:00:33 GMT):
hmm, that's the public ICS feed for the group calendar

rjones (Thu, 23 Jul 2020 22:00:46 GMT):
I added it to my email client and it filled in

rjones (Thu, 23 Jul 2020 22:01:27 GMT):
when I look, I see those meetings end in June (the Semantics calls)

esplinr (Thu, 23 Jul 2020 22:03:16 GMT):
On the Groups.io calendar, it looks right. But when I import that ICS feed into Google, it looks wrong. Maybe this is another place where GSuite fails?

rjones (Thu, 23 Jul 2020 22:03:54 GMT):
No idea. I suspect they're caching it.

rjones (Thu, 23 Jul 2020 22:04:05 GMT):

Annotation 2020-07-23 150335.png

rjones (Thu, 23 Jul 2020 22:04:25 GMT):
green is the old one, purple is one from my home mail server

rjones (Thu, 23 Jul 2020 22:04:40 GMT):
(that's for the Semantics call on the 21st)

rjones (Thu, 23 Jul 2020 22:05:06 GMT):
I found that, for instant, two people in the same org can't add the same ICS feed and share it.

rjones (Thu, 23 Jul 2020 22:05:06 GMT):
I found that, for instance, two people in the same org can't add the same ICS feed and share it.

rjones (Thu, 23 Jul 2020 22:05:54 GMT):
also, once someone shares a calendar, they can't edit it or delete it.

rjones (Thu, 23 Jul 2020 22:06:30 GMT):
honestly, I'm just getting started, so I'll shut up now :)

rjones (Thu, 23 Jul 2020 22:07:26 GMT):
If you subscribe to my home ICS, does it work? https://user.fm/calendar/v1-452f1d58bb5b8afc6a7326f604504c1e/lists.hyperledger.org.ics

esplinr (Thu, 23 Jul 2020 22:09:08 GMT):
When I subscribe to the ICS you shared above, I get the old events (the ones in Green in your screen shot). When I subscribe to Groups.IO's "iCalendar URL to your calendar" I only get one event.

esplinr (Thu, 23 Jul 2020 22:09:12 GMT):
I'll try your home ICS now.

esplinr (Thu, 23 Jul 2020 22:09:58 GMT):
Your home ICS is correct.

esplinr (Thu, 23 Jul 2020 22:11:13 GMT):
I wonder why your home ICS works, but the Groups.IO ICS does not.

rjones (Thu, 23 Jul 2020 22:14:24 GMT):
I got nothing

rjones (Thu, 23 Jul 2020 22:20:04 GMT):
the thing is, I can change the URL for my home ICS feed to defeat any caching google does

esplinr (Thu, 23 Jul 2020 22:20:40 GMT):
How did you get the global feed out of GroupsIO? Do you have to be an admin?

rjones (Thu, 23 Jul 2020 22:20:57 GMT):
there is an account, ca-notices, that is subscribed to all calendars.

esplinr (Thu, 23 Jul 2020 22:21:05 GMT):
Ah.

rjones (Thu, 23 Jul 2020 22:22:22 GMT):
Take a look at our checklist: https://wiki.hyperledger.org/display/CA/Create+a+Mailing+List

rjones (Thu, 23 Jul 2020 22:23:00 GMT):
that ICS file is the ca-notices@hyperledger.org personal calendar

esplinr (Thu, 23 Jul 2020 22:26:44 GMT):
That makes sense.

esplinr (Thu, 23 Jul 2020 22:38:19 GMT):
I wonder if it's like you said, that Google is caching the old appointments on the Groups.io calendar feed somewhere in my organization even though I removed it from my own calendar.

esplinr (Thu, 23 Jul 2020 22:38:27 GMT):
That's probably right.

esplinr (Thu, 23 Jul 2020 22:44:09 GMT):
I can't figure out why my personal calendar from Groups.io doesn't work. It's very strange behavior. sigh

rjones (Thu, 23 Jul 2020 22:44:10 GMT):
I’m totally open to ideas or better solutions

esplinr (Thu, 23 Jul 2020 22:44:22 GMT):
Honestly, I have no ideas. Thank you for your efforts.

rjones (Thu, 23 Jul 2020 22:44:47 GMT):
Sure thing.

rjones (Tue, 28 Jul 2020 06:27:07 GMT):
I think I understand now.

rjones (Tue, 28 Jul 2020 06:27:19 GMT):

IMG_0040.PNG

brentzundel (Tue, 28 Jul 2020 15:03:07 GMT):
My link for the meeting isn't working

brentzundel (Tue, 28 Jul 2020 15:04:43 GMT):
Is there not a meeting right now?

brentzundel (Tue, 28 Jul 2020 15:16:13 GMT):
The community calendar still shows Monday as the meeting time, so I'm really not sure what's going on.

swcurran (Tue, 28 Jul 2020 15:24:53 GMT):
It's next Tuesday for the meeting. I've corrected the calendar before and will try again.

brentzundel (Tue, 28 Jul 2020 15:36:38 GMT):
gotcha, thanks

swcurran (Tue, 28 Jul 2020 21:16:33 GMT):
@rjones --- sorry to be a pain, but how do I get the community calendar updated? The calendar is correct at https://lists.hyperledger.org/calendar, but not on the community calendar. I'

rjones (Tue, 28 Jul 2020 21:21:08 GMT):
it's broken, there is nothing you or I can do.

rjones (Tue, 28 Jul 2020 21:21:35 GMT):
what I did was delete the old one, and create a new one. That one is now broken.

rjones (Tue, 28 Jul 2020 21:22:34 GMT):
if anyone here has any automation ideas where I could run a script to parse the ics file once an hour, or whatever, and then push it into a google calendar, I'm all ears

swcurran (Tue, 28 Jul 2020 21:25:02 GMT):
:-(

swcurran (Tue, 28 Jul 2020 21:25:12 GMT):
Got it... oh well.

rjones (Tue, 28 Jul 2020 21:25:34 GMT):
time for a quick call?

rjones (Tue, 28 Jul 2020 21:25:48 GMT):
https://zoom.us/j/2032622322

esplinr (Wed, 29 Jul 2020 14:04:47 GMT):
My team reviewed Indy Node today and put together a list of easy items that need to be done in the short term. I added them to the agenda for the next Indy Contributors call (Sergey M will be on vacation): https://wiki.hyperledger.org/display/indy/2020-08-04+Indy+Contributors+Call cc @swcurran

swcurran (Fri, 31 Jul 2020 23:09:12 GMT):
Hey folks --- on the Indy Contributors call this coming Tuesday (August 4, 8AM Pacific), we're going to be talking some work to be moved forward on Indy Node and about the upcoming Indy Interop-athon. The Indy Interop-athon (https://bit.ly/indyinterop20) will be held virtually on Sept. 1 and 2nd with the specific goal of making this specific use case possible/easy: ``` As a prover, I want to be able to create a proof that includes claims from credentials rooted in different Indy networks that a verifier can verify so that I can easily interact with issuers using different Indy networks. ``` We'll be talking about the pre-work for the conference -- what we can do to setup for a productive two days so that at the finish of the conference we've defined the work needed in Indy and Aries to make the scenario above possible. Please join us on the Contributors call this Tuesday -- https://wiki.hyperledger.org/display/indy/2020-08-04+Indy+Contributors+Call

esplinr (Mon, 10 Aug 2020 15:09:19 GMT):
For all who are deceived by the inaccurate calendar, and attempted to join the Indy Contributors call, it's actually happening every other Tuesday and this is an off-week. See: https://wiki.hyperledger.org/display/indy/Indy+Contributors+Meeting

esplinr (Mon, 10 Aug 2020 15:13:03 GMT):
There is a Trust over IP Technical Stack Working Group meeting now, for those who are interested.

esplinr (Mon, 10 Aug 2020 15:13:16 GMT):
https://wiki.trustoverip.org/display/HOME/2020-08-10+Weekly+Meeting

esplinr (Mon, 10 Aug 2020 15:38:50 GMT):
Note that @WadeBarnes is leading the effort to release Indy Node 1.12.4. Others who are interested should ask to be added to the discussion, as I can't seem to figure out how to link to it.

swcurran (Mon, 10 Aug 2020 15:43:56 GMT):
Re: 1.12.4 -- if you are interested in helping/following the process, please let us know and we'll invite you to the Rocketchat discussion we have to coordinate the release.

esplinr (Mon, 10 Aug 2020 15:44:35 GMT):
cc @cam-parra @nage

esplinr (Mon, 10 Aug 2020 15:44:35 GMT):
cc @cam-parra @nage @lynn.bendixsen

nage (Mon, 10 Aug 2020 15:49:27 GMT):
I would like to follow along and invite a kiva team member to do so as well, but we will probably just be observers this round

esplinr (Mon, 10 Aug 2020 15:51:23 GMT):
invite sent

esplinr (Mon, 10 Aug 2020 15:57:39 GMT):
Based on Lynn's report of a ledger issue here: https://sovrin.atlassian.net/browse/SN-18 We created some Indy issues to address the problems identified: https://github.com/hyperledger/indy-plenum/issues/1490 https://github.com/hyperledger/indy-plenum/issues/1491 https://github.com/hyperledger/indy-plenum/issues/1492 We don't have a plan to work on these issues in the short term, but we can help others who choose to tackle them.

jramps9 (Tue, 11 Aug 2020 00:08:07 GMT):
Hello Indy contributors! Reminder to please join the DevRel Marketing Committee call at 9am PT this Weds 8/12. Take a look at the agenda and add items here: https://wiki.hyperledger.org/display/Marketing/2020-08-12+Meeting+notes

swcurran (Fri, 14 Aug 2020 23:57:49 GMT):
Hey folks --- on the Indy Contributors call this coming Tuesday (August 18, 8AM Pacific), we're going to be talking about what we will be talking about at the Indy Interop-athon - https://bit.ly/indyinterop20 on Sept. 1st and 2nd. We'll talk about the set of topics we'll be discussing at the Interop-athon. I've put a tentative list of those topics in the meeting agenda. We'll start with a summary and see what else needs to be covered, who wants to talk about those topics and what pre-work we want participants to do in preparation for the online conference. Please join us on the Contributors call this Tuesday -- https://wiki.hyperledger.org/display/indy/2020-08-18+Indy+Contributors+Call -- Zoom: https://zoom.us/j/244779296

swcurran (Mon, 17 Aug 2020 20:41:43 GMT):

Indy Interop-athon

TimoGlastra (Wed, 19 Aug 2020 20:20:46 GMT):
Has joined the channel.

kdenhartog (Tue, 01 Sep 2020 06:51:54 GMT):
Hey all I've published a rough first draft of an Indy (name TBD could just be an update to sov) DID Method which describes how w3c compliant DID Documents would work with Indy. For those of you who've seen my Google Doc from last month there's not much difference. The one notable difference that I want to bring up and discuss at the Indy Interop-athon is how we can decentralize the namespace of multiple networks by hashing the genesis transaction file and anchoring it to multiple networks and then use the first 5 to 10 characters of the hash as the network identifier in the DID syntax. If you'd like to give it a read before the interop-athon take a look here: https://hackmd.io/2IKUPROnRXW57Lmal_SGaQ

swcurran (Tue, 01 Sep 2020 10:34:13 GMT):
The Indy Interop-athon is today and tomorrow online. As such, today's Indy Contributors call is cancelled. See you in two weeks for that call!

sheru (Tue, 01 Sep 2020 15:46:02 GMT):
Has joined the channel.

rjones (Tue, 01 Sep 2020 15:49:13 GMT):
@swcurran are you directing people to this channel, or another channel?

swcurran (Tue, 01 Sep 2020 18:02:05 GMT):
Not sure what you mean by the question? Any more context?

Xand (Tue, 01 Sep 2020 18:04:43 GMT):
Has joined the channel.

VictorSyntez (Tue, 01 Sep 2020 18:32:06 GMT):
Has joined the channel.

rjones (Tue, 01 Sep 2020 20:14:10 GMT):
for the hackathon - a bunch of people showed up in #general looking for pointers

swcurran (Tue, 01 Sep 2020 20:14:47 GMT):
Got it -- so now you know the answer :-)

VictorSyntez (Tue, 01 Sep 2020 21:21:12 GMT):
Hello, I'm interested in volunteering for Hyperledger Indy projects as a developer-beginner. If there are some tasks that don't require extensive coding knowledge or this knowledge might be gained using free available and known resources then I am willing to help. You can contact me using private message. Cheers, Victor.

esplinr (Wed, 02 Sep 2020 12:42:29 GMT):
Welcome to our new friends from the Indy Interop-a-thon. Here are some materials to help you learn more about contributing to Indy. This introduction to Indy published by ashcherbakov https://ssimeetup.org/hyperledger-indy-public-blockchain-node-alexander-shcherbakov-webinar-43/ Shorter version is here https://www.youtube.com/watch?v=ncdvaJrOm_Q&list=PLRp0viTDxBWH2hRisVD6Wij43afXt0FHN&index=3 This blog post from sergey.khoroshavin on troubleshooting Indy helps a lot too: https://www.evernym.com/blog/troubleshooting-an-indy-network/ And the documentation in the /docs and /design folders of both indy-node and indy-plenum.

esplinr (Wed, 02 Sep 2020 12:43:50 GMT):
There is a list of good beginner projects here: https://wiki.hyperledger.org/display/indy/2020-08-04+Indy+Contributors+Call

esplinr (Wed, 02 Sep 2020 12:47:03 GMT):
One good project is converting Indy's CI / CD from Sovrin's Jenkins to GitHub Actions. Things you should know: * Hyperledger is using GitHub Actions for other projects, so you can get help on chat.hyperledger.org in #cicd * Hyperledger has an Azure Pipelines account with budget for complicated jobs. The people in #cicd can set you up to use it if needed. * We need to get you access to Sovrin Jenkins so that you can see what is done today. @lynn.bendixsen can help you to get access. * Another good place to collaborate is http://chat.sovrin.org #devops * @SteveGoob , @WadeBarnes , and @sergey.minaev have all looked at this work in the past, and can provide tips. Previous work: * https://jira.hyperledger.org/browse/IS-1546 * https://github.com/hyperledger/indy-node/pull/1605/ * https://jira.hyperledger.org/browse/INDY-2363

esplinr (Wed, 02 Sep 2020 12:48:09 GMT):
cc @VictorSyntez @skynet @sheru @Xand

skynet (Wed, 02 Sep 2020 12:48:09 GMT):
Has joined the channel.

sheru (Wed, 02 Sep 2020 12:56:11 GMT):
Thanks @esplinr, for the resources this is really helpful for me to start the journey with the open source community. Thanks again.

VictorSyntez (Wed, 02 Sep 2020 13:05:32 GMT):
Thank you @esplinr

m00sey (Fri, 04 Sep 2020 20:07:16 GMT):
@WadeBarnes coming out of the Indy interop-athon the team here at Scoir is planning on helping out with the move to GitHub actions. Your name came up as someone to talk to, to understand the release process. My current plan is to work through the Jenkinsfiles in Indy node and look at translating those to actions, then tackling the broader release process. If you have some time next week perhaps we can get on a call, this is open up anyone else as well obviously, my calendar is here https://calendly.com/m00sey

WadeBarnes (Fri, 04 Sep 2020 20:10:48 GMT):
Sounds good. Monday is a Holiday for us here (Canada), and Tuesday I have some appointments in the morning.

m00sey (Fri, 04 Sep 2020 20:11:37 GMT):
We're US so Holiday Monday too, enjoy the long weekend

WadeBarnes (Fri, 04 Sep 2020 20:16:01 GMT):
The build/test processes should translate fairly well, most of it is done in docker containers, which is natural in GHA but additional overhead in Jenkins. It's broken down fairly well to which helps. There are a couple things such as spinning up pools that I think can be streamlined that I think we should discuss.

WadeBarnes (Fri, 04 Sep 2020 20:16:01 GMT):
The build/test processes should translate fairly well, most of it is done in docker containers, which is natural in GHA but additional overhead in Jenkins. It's broken down fairly well too which helps. There are a couple things such as spinning up pools that I think can be streamlined that I think we should discuss.

WadeBarnes (Fri, 04 Sep 2020 20:16:01 GMT):
The build/test processes should translate fairly well, most of it is done in docker containers, which is natural in GHA but additional overhead in Jenkins. It's broken down fairly well too which helps. There are a couple things such as spinning up pools that I think can be streamlined I think we should discuss.

m00sey (Fri, 04 Sep 2020 20:16:35 GMT):
Awesome, thanks. Look forward to it

WadeBarnes (Fri, 04 Sep 2020 20:17:47 GMT):
Another agenda item should be packaging and publishing.

WadeBarnes (Fri, 04 Sep 2020 20:24:29 GMT):
12, 1, or 2 on Tuesday looks good for me.

m00sey (Fri, 04 Sep 2020 22:56:52 GMT):
2pm (EST) works for me, if you want to set up the call, message me your email I'll set a jitsi up for us

m00sey (Fri, 04 Sep 2020 22:56:52 GMT):
2pm (EST) works for me, if you want to set up the call, or message me your email I'll set a jitsi up for us

ianco (Thu, 10 Sep 2020 15:47:05 GMT):
Any chance on getting a review of this PR? https://github.com/hyperledger/indy-sdk/pull/2179 (I notice it's been assigned ...) Thanks in advance

swcurran (Mon, 14 Sep 2020 13:43:40 GMT):
Hey folks --- on the Indy Contributors call this coming Tuesday (September 15, 8AM Pacific, 5PM CET), we're going to be follow up on the first two actions needed out of the Indy Interop-athon -- CI/CD migration to GitHub Actions and the did:indy DID Method spec. We'll also review the outputs from the Indy Interop-athon as we turn talk into action. Please join us on the Contributors call this Tuesday -- https://wiki.hyperledger.org/display/indy/2020-09-15+Indy+Contributors+Call -- Zoom: https://zoom.us/j/244779296

jramps9 (Mon, 14 Sep 2020 17:35:52 GMT):
Hello Indy contributors! Reminder to please join the DevRel Marketing Committee call at 9am PT on 9/16 this week. Take a look at the agenda and add items here: https://wiki.hyperledger.org/display/Marketing/2020-09-16+Meeting+notes

Xand (Tue, 15 Sep 2020 15:05:15 GMT):
ping

m00sey (Tue, 15 Sep 2020 17:31:03 GMT):
pong

kdenhartog (Thu, 17 Sep 2020 00:50:50 GMT):
@andrew.whitehead @rjones @PatrikStas was there any work done to get the indy-vdr node.js lib onto npmjs? I saw this comment here, but wasn't sure what's going on with getting that done. We're interested in using that lib: https://github.com/hyperledger/indy-vdr/pull/44#issuecomment-689715327

rjones (Thu, 17 Sep 2020 00:52:31 GMT):
Nope.

andrew.whitehead (Thu, 17 Sep 2020 00:52:50 GMT):
I haven't had a chance to get into that yet

rjones (Thu, 17 Sep 2020 00:53:03 GMT):
If you publish to GitHub packages, you don't need my say-so to do it.

rjones (Thu, 17 Sep 2020 00:53:18 GMT):
If you want to publish to NPM, I need an NPM user name to invite

rjones (Thu, 17 Sep 2020 00:53:56 GMT):
I would prefer if you published to GitHub, as NPM is yet another layer of stuff I don't want to manage. If you want to publish to NPM, let's do it to it

rjones (Thu, 17 Sep 2020 00:59:48 GMT):
It looks like this is the only node package we publish: https://github.com/hyperledger/aries-framework-go/packages/123279

esplinr (Thu, 17 Sep 2020 05:15:54 GMT):
We'll be having an extra Indy Contributors call in 8 hours (Thursday, September 17 @ 6AM Pacific) to plan the next release of Indy Node. Join this Zoom link: https://zoom.us/j/244779296

esplinr (Thu, 17 Sep 2020 12:53:29 GMT):
We'll be planning the next Indy Node release in 10 minutes.

esplinr (Thu, 17 Sep 2020 12:53:34 GMT):
Well, 7 minutes.

esplinr (Thu, 17 Sep 2020 12:55:20 GMT):
https://wiki.hyperledger.org/display/indy/2020-09-17+Special%3A+Planning+Next+Indy+Node+Release

esplinr (Thu, 17 Sep 2020 12:55:25 GMT):
https://zoom.us/j/244779296

esplinr (Thu, 17 Sep 2020 14:08:01 GMT):
We'll continue this conversation during the next Indy Contributors call on September 29.

swcurran (Thu, 17 Sep 2020 14:52:17 GMT):
I've added three tickets to indy-node following are meeting today. One is a coding request (flagged - help wanted), another a code review (flagged - help wanted/good first issue) and the last assigned to Wade (although @m00sey might want to take a look too). Complete work on the removal of indy-node's indy-crypto dependency #1621 opened 4 minutes ago by swcurran Backlog @WadeBarnes - https://github.com/hyperledger/indy-node/issues/1621 Review current stable-master comparison to see if there is anything other than Rich Schema changes good first issue help wanted #1620 opened 12 minutes ago by swcurran Backlog - https://github.com/hyperledger/indy-node/issues/1620 Add feature flag control over the Rich Schema transactions to indy-node help wanted #1619 opened 17 minutes ago by swcurran Backlog - https://github.com/hyperledger/indy-node/issues/1619 Getting 1619 done would be REALLY helpful if a dev wants to jump in.

rjones (Thu, 17 Sep 2020 15:27:25 GMT):
Hi, if you have anything you'd like to see added to the /dev/weekly newsletter, please comment in the next two hours: https://wiki.hyperledger.org/pages/viewpage.action?pageId=39618911

swcurran (Thu, 17 Sep 2020 15:41:21 GMT):
Not allowed to edit the file. I have a short addition I could add.

swcurran (Thu, 17 Sep 2020 15:41:36 GMT):
I'l add it as a comment

rjones (Thu, 17 Sep 2020 15:45:06 GMT):
yes please

swcurran (Thu, 17 Sep 2020 15:45:59 GMT):
Done

jramps9 (Thu, 17 Sep 2020 15:55:05 GMT):
Thanks @swcurran !

lynn.bendixsen (Fri, 18 Sep 2020 16:51:24 GMT):
Hello, at least a few different organizations have expressed a desire for the ability to have on-ledger transfer of value, so I wrote the following HIPE regarding the addition of a generic way to provide that for all who desire it: https://github.com/hyperledger/indy-hipe/pull/160

GianlucaPinto (Thu, 24 Sep 2020 13:41:04 GMT):
Has joined the channel.

GianlucaPinto (Thu, 24 Sep 2020 13:41:04 GMT):
hi all, how can i do for get the timestamp of a credentials ? thanks

esplinr (Fri, 25 Sep 2020 13:30:52 GMT):
Please don't cross post in channels that aren't related to your question.

esplinr (Fri, 25 Sep 2020 13:30:52 GMT):
Please don't re-post in channels that aren't related to your question.

swcurran (Mon, 28 Sep 2020 16:08:45 GMT):
Hey folks --- on the Indy Contributors call this coming Tuesday (September 29, 8AM Pacific, 5PM CET), we'll be continuing the special meeting we held on Sept. 17 to plan the next release of indy-node and updating the indy-node CI/CD process. Please join us on the Contributors call this Tuesday -- https://wiki.hyperledger.org/display/indy/2020-09-29+Indy+Contributors+Call -- Zoom: https://zoom.us/j/244779296 Note -- if you have trouble logging into the meeting, please check here. Some Zoom rules are changing and that may affect this meeting.

PatrikStas (Tue, 29 Sep 2020 13:04:33 GMT):
@swcurran do we have some space on the call today to discuss the move of absa's libvcx fork back under Hyperledger?

esplinr (Tue, 29 Sep 2020 13:08:10 GMT):
I'm supportive of us making the space. I added it to the agenda.

esplinr (Tue, 29 Sep 2020 13:08:25 GMT):
But I defer to @swcurran if he disagrees.

skynet (Tue, 29 Sep 2020 14:15:11 GMT):
I have a conflicting call, but will try to connect part way through. there will be two other people form our team on the call (@sheru). We think we can help with the CI/CD updates and perhaps Ubunto 20.04.

sheru (Tue, 29 Sep 2020 14:20:08 GMT):
I will be attend the discussion today. Thanks

rjones (Tue, 29 Sep 2020 14:57:09 GMT):
@swcurran I see that "the host has another meeting in progess"

brentzundel (Tue, 29 Sep 2020 15:04:08 GMT):
I'm running a bit late, but will be on the call soon

Xand (Thu, 01 Oct 2020 15:00:04 GMT):
Is the https://zoom.us/j/232861185 for the weekly working group stale?

Xand (Thu, 01 Oct 2020 15:03:21 GMT):
Never mind, I think it was moved to aries: https://wiki.hyperledger.org/display/ARIES/Aries+Working+Group

esplinr (Thu, 01 Oct 2020 17:41:03 GMT):
A lot of the zoom meetings are going to change this week since Zoom is requiring a password so we have to update the invitations.

Xand (Mon, 05 Oct 2020 14:18:01 GMT):
Anyone wanting the feature flag toggle in a hurry able to review 'proposed actions' at the bottom of this wiki page I made to draft the work? https://wiki.hyperledger.org/display/~Xand/Adding+Feature+Flag+for+Rich+Schemas I think some of the actions aren't necessary but could also be going about it the wrong way. PM if you find that easier!

esplinr (Mon, 05 Oct 2020 14:42:49 GMT):
@sergey.khoroshavin Can you help with this within the next couple of days? I'm specifically interested in your opinion of whether config.py is appropriate, or rather this should be on the config ledger.

swcurran (Mon, 05 Oct 2020 15:24:02 GMT):
I'd like to propose a different approach going forward. Basically, the only difference between what we have released and the main/master branch is Rich Schema. Assuming that is true, I'd like to propose that we drop the Rich Schema work and instead of bringing up the release to what's been merged, we instead bring master/main to match what we've released. I say that with apologizes to Brent. Why? It's a combination of BBS+ and the new DID spec. First, with BBS+ we are removing the need for objects on the ledger to better align with other communities, while still supporting (at least) ZKPs, selective disclosure and revocation. Schemas are replaced with JSON-LD which can be on or off ledger. I cannot see us going to the more complex Rich Schema solution that is very Indy specific vs. just using JSON-LD. Second, if we do want the schema information (the JSON-LD documents) on ledger, that can be done with "normal" DIDs according to the new DID spec. We should be able to put a DID in credentials as URI for the context, and have the JSON-LD (the schema for the credential) resolved on the ledger. This is a much simpler optional solution to have schema on the ledger. Based on this arguments, the new Rich Schema work is not needed in Indy-Node and it will create a problem like we saw with LIBVCX in the indy-sdk, where we acted first, and then discovered the ramifications later. As such, I propose that we DON"T add the Rich Schema support to the ledger at this time, but rather we evolve indy-node from our current release.

swcurran (Mon, 05 Oct 2020 15:25:21 GMT):
Note that if necessary and appropriate, we can cherry-pick non-Rich Schema commits from the current merged, unreleased changes and put those into the release.

swcurran (Mon, 05 Oct 2020 15:30:05 GMT):
Please see my proposal to not do this work at all.

sergey.khoroshavin (Mon, 05 Oct 2020 15:39:43 GMT):
@esplinr my quick vote is to implement it using `config.py` and make off by default

sergey.khoroshavin (Mon, 05 Oct 2020 15:39:43 GMT):
@esplinr my quick vote is to implement it using `config.py` and make it off by default

esplinr (Mon, 05 Oct 2020 16:17:13 GMT):
I disagree for the following reasons: * BBS+ signatures will be useful, but will not completely remove the need for Rich Schemas. Even when we can send the schema information off-ledger, I believe it will be useful for people to be able to find existing schemas on-I believe that there are still use cases where Rich Schemas will be better. * There is some other functionality included in the "Rich Schemas" work, such as the encoding mapping.

esplinr (Mon, 05 Oct 2020 16:17:13 GMT):
It's an interesting proposal, because it could save us a lot of work. But I disagree for the following reasons (which might be wrong): * BBS+ signatures will be useful, but will not completely remove the need for Rich Schemas. For instance, even when we can send the schema information off-ledger, I believe it will be useful for people to be able to find existing common schemas on-Iedger. * There is some other functionality included in the "Rich Schemas" work, such as the encoding mapping.

esplinr (Mon, 05 Oct 2020 16:18:08 GMT):
@brentzundel @danielhardman @sergey.minaev What do you think?

esplinr (Mon, 05 Oct 2020 16:18:08 GMT):
@brentzundel @danielhardman @sergey.minaev @kenebert What do you think?

esplinr (Mon, 05 Oct 2020 16:19:16 GMT):
But my opinion is colored that I also disagree with your assessment of LibVCX in the Indy-SDK. I still think that was the right decision at the time.

sergey.minaev (Mon, 05 Oct 2020 16:36:05 GMT):
Well, I would not "accept" both arguments as well, but I'd like to have a check from crypto experts and node experts: 1) bbs+ is math, so rich schema is not controversial idea. @brentzundel what is the source of truth for public keys in BBS+ signatures? I thought the ledger can be one of the source... While we consider some compatibility with other communities we can have use cases where we would like to have such (additional?) basis for trust 2) I would take this point as argument to bring (not to remove) the RichSchema's codechanges into the main branch. It would be easier to re-use some code from the rich-schema scope to have support JSON-LD for "normal" DID. @sergey.khoroshavin what do you think? as for risk to hit some problems similar to LibVCX support in IndySDK, I can find it as a completely different situation. LibVCX is separate codebase against LibIndy. RichSchema scope is just another module which follows the same best practices, architecture and so on in the rest of Indy Node handlers @sergey.khoroshavin please correct me if I'm wrong

swcurran (Mon, 05 Oct 2020 16:50:27 GMT):
Regards Richard's comments: * I answered the "how to put JSON-LD on-ledger" and it doesn't require the complexity of Rich Schema. The need for Rich Schemas is eliminated by the BBS+ method, which only relies on JSON-LD. * I think that the JSON-LD schemas will make unnecessary the uncoding mappings, but if it is useful, it can be cherry-picked and used. Regarding Sergey M's coments: * The ledger is the truth for the keys -- however, it is in the DID. But that is separate issue vs. Rich Schema. * I disagree for the need for this. The "JSON-LD in a normal DID" does not require any ledger support beyond writing the DIDDoc as the ATTRIB as is being proposed with the "did:indy" method. The proposal is about reducing the required ledger processing at layers higher than 1 of the ToIP stack. Indy should read and write DIDs and should do much less at the higher levels, to enable interoperability. Indy MAY do validity checking, but that should be carefully added based on experience versus added by default. But even then, that will be WAY easier if we support pure JSON-LD on the ledger vs. Rich Schema.

swcurran (Mon, 05 Oct 2020 16:50:54 GMT):
I don't need to rehash this, but I disagree with you.

swcurran (Mon, 05 Oct 2020 17:57:07 GMT):
BTW - kudos to @m00sey for the PRs on the indy-node build process. Really like to see those changes made. Hopefully, I'm not triggering too much rework in proposing this change of direction.

m00sey (Mon, 05 Oct 2020 17:57:43 GMT):
All thought welcome, that was very much my attempt to "get something done"

m00sey (Mon, 05 Oct 2020 17:57:43 GMT):
All thoughts welcome, that was very much my attempt to "get something done"

rjones (Mon, 05 Oct 2020 18:02:04 GMT):
I think it's awesome

rjones (Mon, 05 Oct 2020 18:13:53 GMT):
if you want, I have an org set up for testing CI/CD so you could run github actions and stuff with impunity

rjones (Mon, 05 Oct 2020 18:14:08 GMT):
`hyperledger-cicd`

brentzundel (Mon, 05 Oct 2020 18:24:37 GMT):
@swcurran @sergey.minaev @esplinr BBS+ signatures are great. The way the public key can be extended to sign as many messages as are in a credential is fantastic, which means that the need for a cred def on the ledger can be eliminated (as long as the revocation registry is also sent as part of the credential). Schemas may be anchored anywhere. The need for an immutable record of a schema depends on the trust framework. Rich schemas provides one mechanism for immutable anchoring a schema. Another method that may serve most use cases is to send the schema used as part of the signed credential. To this point, I can see the argument to no longer feel that rich schemas are necessary, however, the signing mechanism of BBS+ still expects the signed assertions to be represented as integers. How should an issuer specify how each asseretion has been converted? The current method used with CL signatures may be adequate for simple use cases, but we run into more and more cases where it would be very valuable for an issuer to be able to specify a more complex encoding scheme than "all strings are hashed." I do not know of an answer for this other than rich schema mappings and encodings. There is also the rich schema notion of anchoring a presentation definition to the ledger. As the ecosystem grows, having a set of common, publicly available, immutable presentation definitions may not only be valuable, it may be vital. Unless satisfactory answers can be found for the full scope of capabilities provided by rich schemas, then it doesn't make sense to me to remove them.

danielhardman (Mon, 05 Oct 2020 18:27:40 GMT):
I think I agree substantially with Stephen's thinking, but I think Brent's caveat about the need for mappings is important. BBS+ signatures are a good thing but they don't provide predicates and they don't eliminate the need for encodings/mappings. However, we can keep encodings/mappings off the ledger just like we do for schemas. So we don't need special storage of such objects on Indy.

swcurran (Mon, 05 Oct 2020 20:24:02 GMT):
@brentzundel -- my argument for both examples you give is essentially the same. First, for the encodings, once we know what is needed for BBS+ regards encodings, we can determine what supplemental information is needed. If we add it, we will likely add it not as is done today with Rich Schema, but rather as a typed-DID on the ledger that resolves to the information needed. Likewise, while I like the idea of a presentation definition being on the ledger, that can be done as JSON-LD or as a DID holding a Presentation Request (e.g. DIF format). In both cases, too much has changed since Rich Schema was planned to think that the solution to these upcoming issues will be the same as Rich Schema. The more we do that makes Indy different from other DID Ledger Utilities, the harder it will be to get any other communities to use the Indy ledgers. We need to remove "Indy-isms" from the ledger layer so that we are only dealing with DIDs, and ideally stick to DIDs types that all DID VC solutions need -- DIDs, revocation registries, JSON/JSON-LD metadata. Getting support for the "version", "timestamp" and proposed "type" are all important to make Indy as interoperable as possible with other ledgers.

swcurran (Mon, 05 Oct 2020 20:24:02 GMT):
@brentzundel -- my argument for both examples you give is essentially the same. First, for the encodings. Once we know what is needed for BBS+ regards encodings, we can determine what supplemental information is needed and where it should be placed (e.g. on/off ledger). If we add it, we will likely add it not as is done today with Rich Schema, but rather as a typed-DID on the ledger that resolves to the information needed. Likewise, while I like the idea of a presentation definition being on the ledger, that can be done as JSON-LD or as a DID holding a Presentation Request (e.g. DIF format). In both cases, too much has changed since Rich Schema was planned to think that the solution to these upcoming issues will be the same as Rich Schema. The more we do that makes Indy different from other DID Ledger Utilities, the harder it will be to get any other communities to use the Indy ledgers. We need to remove "Indy-isms" from the ledger layer so that we are only dealing with DIDs, and ideally stick to DIDs types that all DID VC solutions need -- DIDs, revocation registries, JSON/JSON-LD metadata. Getting support for the "version", "timestamp" and proposed "type" are all important to make Indy as interoperable as possible with other ledgers.

brentzundel (Mon, 05 Oct 2020 20:55:22 GMT):
If folks are agreed that the rich schema transactions as originally envisioned aren't the right way to move forward, I'm not going to stand in the way of that. I have repeatedly asserted that BBS+ signatures are orthogonal to rich schemas. They are a really great signature mechanism that address the problem of needing credential definitions, and of the need to specify in advance the precise number of assertions that need to be signed (which allows us to use variable-length list). Because they are actually BBS+LD-Signatures, they also make use of real-world JSON-LD schemas. They still do not define a mechanism for an issuer to express the relationship between the signature and what has been signed (mappings and encodings), but they do make it clear that our heavy reliance on a common ledger is not necessary in all cases. This is valuable insight. The original goals driving rich schemas were: 1. compliance with the W3C VC spec 2. a way to use existing complex, hierarchical schemas with signatures that allow for blinding and selective disclosure 3. a way for issuers to specify and verifiers to have assurances about the types of the values being asserted, and to share the semantic meaning. 4. support for a broader range of predicates I think that the LD-portion of BBS+LD-Signatures brings us really close to number 2, and part of number 3. I look forward to discussing concrete proposals for how we plan to get all the way on 2 and 3, and for accomplishing 1 and 4.

esplinr (Mon, 05 Oct 2020 21:23:23 GMT):
I recognize that you do, as you mentioned in the thread. It represents how our different perspectives lead to different approaches to various questions, such as this one.

swcurran (Mon, 05 Oct 2020 21:48:17 GMT):
Your statement 1 is interesting. I checked out what @tplooker presented at IIW last time (slides here: https://drive.google.com/file/d/1X1JApxDY48MJYYACNT9NPsgpZWft0wHk/view). Per slide 18: > Completely compatible with the VC data model that is already being widely used today. Is that statement incorrect, if so, what will it take for it to correct?

swcurran (Mon, 05 Oct 2020 21:48:17 GMT):
Your statement 1 is interesting. I checked out what @tplooker presented at IIW last time (slides here: https://drive.google.com/file/d/1X1JApxDY48MJYYACNT9NPsgpZWft0wHk/view). Per slide 18: > > Completely compatible with the VC data model that is already being widely used today. > Is that statement incorrect, if so, what will it take for it to correct?

swcurran (Mon, 05 Oct 2020 21:59:17 GMT):
On @brentzundel 's other observations: I agree that 2 and at least some of 3 is covered by BBS+. I don't get that statement and "orthogonal". We may not get it perfect, but it is a start and one that is aligned with what else is being used in other VC/Ledger communities. Further, by following the DID Spec and not creating "indy-only" documents (just DIDs of different types), we have a better chance of achieving the goals without creating an Indy-only solution. I'm assuming that "DIDs of different" types is a sufficiently different solution from the current Rich Schema Indy Node support that continuing down the Rich Schema path will not help us. Further, we still don't have Rich Schema support in Aries clients (indy-sdk and beyond), and no plan to accomplish that. And Rich Schema are behind what we consider to be higher priorities - notably adding BBS+LD ZKP support, including at the Aries level, and scaled revocation.

swcurran (Mon, 05 Oct 2020 21:59:17 GMT):
On @brentzundel 's other observations: I agree that 2 and at least some of 3 is covered by BBS+. I don't get that statement combined with "orthogonal". We may not get it perfect, but it is a start and one that is aligned with what else is being used in other VC/Ledger communities. Further, by following the DID Spec and not creating "indy-only" documents (just DIDs of different types), we have a better chance of achieving the goals without creating an Indy-only solution. I'm assuming that "DIDs of different" types is a sufficiently different solution from the current Rich Schema Indy Node support that continuing down the Rich Schema path will not help us. Further, we still don't have Rich Schema support in Aries clients (indy-sdk and beyond), and no plan to accomplish that. And Rich Schema are behind what we consider to be higher priorities - notably adding BBS+LD ZKP support, including at the Aries level, and scaled revocation.

brentzundel (Mon, 05 Oct 2020 22:12:31 GMT):
This is true for their implementation. There would still be work to do for this to be true in Aries and Indy.

swcurran (Mon, 05 Oct 2020 22:21:38 GMT):
Definitely. To me, that is the priority work that needs to be done.

brentzundel (Mon, 05 Oct 2020 22:24:27 GMT):
I think it makes sense to not go through the process of adding the rich schema transactions to indy, as long as we can agree that the original goals of rich schemas are still worth pursuing.

tplooker (Mon, 05 Oct 2020 22:26:59 GMT):
@brentzundel agree, if we do remove credential definitions then is really the only thing that you want to be able to put on a ledger just a JSON-LD context definition with potentially some expanded metadata? I don't see the need for mapping objects to deal with normalization the mechanism avaliable to all JSON-LD linked data proofs deals with flattening data hierarchies and nesting

tplooker (Mon, 05 Oct 2020 22:26:59 GMT):
@brentzundel agree, if we do remove credential definitions then is really the only thing that you want to be able to put on a ledger just a JSON-LD context definition with potentially some expanded metadata? I don't see the need for mapping objects to deal with normalization, the mechanism avaliable to all JSON-LD linked data proofs deals with flattening data hierarchies and nesting

tplooker (Mon, 05 Oct 2020 22:28:22 GMT):
Using JSON-LD syntax today a term definition in a context can also contain the required value type information that would give processors enough information to decide how to encode that value correctly to say support predicate proofs?

tplooker (Mon, 05 Oct 2020 22:28:58 GMT):
So my real question is how much new syntax and concepts do we need vs what can we just lean on with existing technology?

tplooker (Mon, 05 Oct 2020 22:29:50 GMT):
I still have alot of questions around predicate proofs and hence why we did not elect to solve this in the first instance I think many are underestimating the complexity a compliant signature suite would have to be

tplooker (Mon, 05 Oct 2020 22:29:50 GMT):
I still have alot of questions around predicate proofs and hence why we did not elect to solve this in the first instance. I think many are underestimating the complexity a compliant signature suite would have to be

tplooker (Mon, 05 Oct 2020 22:31:23 GMT):
For example if I wanted to build a compliant signature suite capable of coping with predicate proofs, what is the enumeration of converters I would need from JSON value types to their integer mapping that I MUST support to ensure I dont recieve a proof that I cannot verify

tplooker (Mon, 05 Oct 2020 22:32:22 GMT):
Predicate proofs create a whole new negotiation layer around what implementations may or may not support and unless this is properly defined it will cause massive issues w.r.t interoperability

tplooker (Mon, 05 Oct 2020 22:35:08 GMT):
Im not arguing they are not a worthy endeavour, just that with out answers to all of these questions the threat they pose to interop marginalizes any value they bring to usecases

tplooker (Mon, 05 Oct 2020 22:35:08 GMT):
Im not arguing they are not a worthy endeavour, just that without answers to all of these questions the threat they pose to interop marginalizes any value they bring to usecases

brentzundel (Tue, 06 Oct 2020 12:54:58 GMT):
mapping isn't just for normalization, it also is the means for expressing the encodings used for each property value. If we have a deterministic mechanism for normalization, that does save an issuer from needing to specify signing order, but the need to specify the encoding remains. I think it is possible to describe a set of encodings such that, after normalization, they will map to the normalized property values, but this notion will need to be described, and then tested.

brentzundel (Tue, 06 Oct 2020 12:59:58 GMT):
I think that the verifier would specify (as part of a presentation definition), precisely which signature suites and data formats it can receive, along with the predicate operations it can support, for an example, check out the presentation exchange spec we're working on at DIF: https://identity.foundation/presentation-exchange/#input-descriptor-objects

swcurran (Tue, 06 Oct 2020 13:44:29 GMT):
It sounds like the leaning is to not continuing with the Rich Schema work. How about a discussion on the next Indy Contributors call to have a discussion about it and try to achieve consensus on moving forward?

brentzundel (Tue, 06 Oct 2020 14:15:24 GMT):
I agree. Further discussion would be good. The Indy contributors call regularly conflicts with the DID WG call, so I can only rarely attend.

swcurran (Tue, 06 Oct 2020 14:16:14 GMT):
Can you make next Tuesday's call? 7AM Pacific - Oct. 13?

brentzundel (Tue, 06 Oct 2020 14:19:43 GMT):
I can make it at 7AM PT. I thought they were usually at 8AM.

swcurran (Tue, 06 Oct 2020 15:07:50 GMT):
Shoot -- you are right. Sorry about that. 8AM.

swcurran (Tue, 06 Oct 2020 16:30:54 GMT):
If you can't make it, can you have someone represent you/Evernym on this?

brentzundel (Tue, 06 Oct 2020 16:39:30 GMT):
I will try to make sure someone can be there.

tplooker (Tue, 06 Oct 2020 19:49:09 GMT):
Agreed however JSON-LD allows you to establish the value type of a term, so my question is why not rely on this mechanism to determine the value type of a field and therefore how to encode it?

tplooker (Tue, 06 Oct 2020 19:49:46 GMT):
Because any new syntax has to be fully defined and recognized as a standard to promote interoperability

andrew.whitehead (Tue, 06 Oct 2020 19:54:04 GMT):
I think there would need to be a standard vocabulary of xml schema types that have mappings to normalized forms, otherwise treat them all as strings and hash them

tplooker (Tue, 06 Oct 2020 19:54:43 GMT):
Exactly, 100% agree

tplooker (Tue, 06 Oct 2020 19:55:48 GMT):
The problem is what is the authoritative list on these terms and what happens if an issuer issues one a verifier does not support the encoding and decoding process, thats the threat to interop I'm worried about

tplooker (Tue, 06 Oct 2020 19:55:48 GMT):
The problem is what/who is the authoritative list on these terms and what happens if an issuer issues one a verifier does not support the encoding and decoding process, thats the threat to interop I'm worried about

tplooker (Tue, 06 Oct 2020 19:55:48 GMT):
The problem is what/who is the authoritative list on these terms and what happens if an issuer issues one containing an attribute a verifier does not support the encoding and decoding process of, thats the threat to interop I'm worried about

tplooker (Tue, 06 Oct 2020 19:56:22 GMT):
It would mean the verifier is unable to reproduce the data in the form required to validate the signature or proof

andrew.whitehead (Tue, 06 Oct 2020 19:59:27 GMT):
Explicitly defining the mapping on a credential basis works too, maybe there could be 'standard' mappings available which define the common field types

tplooker (Tue, 06 Oct 2020 20:00:53 GMT):
Potentially, its the 'standard' mappings bit that concerns me and doing something that is entirely verifiable credential specific, BBS+ is a generalized digital signature scheme that has usecases outside of verifiable credentials

andrew.whitehead (Tue, 06 Oct 2020 20:01:47 GMT):
By standard I mainly mean generally available, they could be published as an immutable or versioned DID Doc of some format

tplooker (Tue, 06 Oct 2020 20:02:32 GMT):
Yeap agreed, I'd like to see us leverage as much of the existing syntax defined by something like JSON-LD rather than inventing our own way

brentzundel (Tue, 06 Oct 2020 20:14:33 GMT):
Something like an aries-encodings version 1, that describes the possible inputs and how they should be encoded would allow both issuers and verifiers to have a point of interoperability. I think this is fine for a first attempt, but expect that it will be necessary at some point to define multiple possible encodings for a single input type. Which means that we will still need to define a mechanism that allows an issuer to specify which particular encoding they are using for a particular claim value at the time of signing.

tplooker (Tue, 06 Oct 2020 20:20:00 GMT):
Can you point me at what you mean by aries-encodings version 1?

tplooker (Tue, 06 Oct 2020 20:20:56 GMT):
Statements like "Which means that we will still need to define a mechanism that allows an issuer to specify which particular encoding they are using for a particular claim value at the time of signing" feels quite dangerous to me, there should be no optionality for an issuer beyond a standard set otherwise you will not obtain interop

tplooker (Tue, 06 Oct 2020 20:24:04 GMT):
Creating that type of optionality is a foot gun, there is no point an issuer encoding a special field in there credential in a special way if no verifiers can interpret it?

tplooker (Tue, 06 Oct 2020 20:24:04 GMT):
Creating that type of optionality is a foot gun, there is no point in an issuer encoding a special field in there credential in a special way if no verifiers can interpret it?

tplooker (Tue, 06 Oct 2020 20:24:04 GMT):
Creating that type of optionality is a foot gun, there is no point in an issuer encoding an attribute in a special way if no verifiers can interpret it?

brentzundel (Tue, 06 Oct 2020 20:25:02 GMT):
We could write an rfc that says (just as an example): rfc3339 date strings must be encoding as the number of days since 1700; floating point numbers must be encoded as integers using the following algorithm, ... I totally agree that we need a standard set of possible encodings to draw from, I'm just not convinced that a single encoding per input type will be sufficient.

tplooker (Tue, 06 Oct 2020 20:25:37 GMT):
Ok but can we agree this set has to be bound?

tplooker (Tue, 06 Oct 2020 20:25:53 GMT):
Otherwise you have to design a protocol that negotiates what parties support?

tplooker (Tue, 06 Oct 2020 20:26:27 GMT):
Issuers cannot just decide they want to support new encodings as it will literally lead to verifiers not being able to verify?

brentzundel (Tue, 06 Oct 2020 20:26:31 GMT):
Totally agree, that's what I mean by versioning it. Kind of like Aries interop profiles.

tplooker (Tue, 06 Oct 2020 20:26:53 GMT):
Ok if it is version then its a surface of negotiation

tplooker (Tue, 06 Oct 2020 20:26:53 GMT):
Ok if it is versioned then its a surface of negotiation

brentzundel (Tue, 06 Oct 2020 20:27:28 GMT):
Right

tplooker (Tue, 06 Oct 2020 20:28:22 GMT):
Im not sure aries interop profiles is the correct categorisation this is a low level cryptographic suite definition

tplooker (Tue, 06 Oct 2020 20:28:46 GMT):
IMO it should go in the linked data proof definition

tplooker (Tue, 06 Oct 2020 20:28:55 GMT):
E.g https://github.com/w3c-ccg/ldp-bbs2020

tplooker (Tue, 06 Oct 2020 20:29:41 GMT):
So `BbsBlsSignature2021` would define the fixed set of encoding types for different values

tplooker (Tue, 06 Oct 2020 20:29:57 GMT):
If you wanted to revise you create a new suite like `BbsBlsSignature2022`

tplooker (Tue, 06 Oct 2020 20:29:57 GMT):
If you wanted to revise the encoding types you support you create a new suite like `BbsBlsSignature2022`

tplooker (Tue, 06 Oct 2020 20:29:57 GMT):
If you wanted to revise the encoding type supported you create a new suite like `BbsBlsSignature2022`

tplooker (Tue, 06 Oct 2020 20:30:56 GMT):
Then there is a crisp way to detect as a ecosystem participant if you support the cryptographic suite

brentzundel (Tue, 06 Oct 2020 20:33:39 GMT):
I'm not convinced that interop profiles are the right level, but working the encodings into the LD proof definition feels wrong to me. Verifying the signature happens at a different level of validation than verifying the data encoding.

tplooker (Tue, 06 Oct 2020 20:35:53 GMT):
Fair enough, I disagree though, it is fundamental to the definition of a digital signature scheme to define how you get the data you are signing and verifying into the form required to sign and verify, without that being in lockstep with the crypto it creates a serious interop problem

tplooker (Tue, 06 Oct 2020 20:37:53 GMT):
If we are leveraging JSON-LD semantics as the source of determing how to encode or decode a value then it makes sense, if you want to do something that adds a layer divorced from JSON-LD then I understand and agree that is possible but would posit that is heap of work

tplooker (Tue, 06 Oct 2020 20:37:53 GMT):
If we are leveraging JSON-LD semantics as the source of determing how to encode or decode a value then it makes sense to define in the linked data proof, if you want to do something that adds a layer divorced from JSON-LD then I understand and agree that it is possible, but would posit that is a heap of work

tplooker (Tue, 06 Oct 2020 20:43:24 GMT):
Perhaps a relevant analogy here is imagine if an issuer creating EdDSA signatures had the autonomy to decide the digest algorithm they want to use e.g not SHA-256 instead Blake2B, a verifier would receive a digital signature and be unable to verify this

tplooker (Tue, 06 Oct 2020 20:43:24 GMT):
Perhaps a relevant analogy here is imagine if an issuer creating EdDSA signatures had the autonomy to decide the digest algorithm they want to use e.g not SHA-512 instead Blake2B, a verifier would receive a digital signature and be unable to verify this

tplooker (Tue, 06 Oct 2020 20:43:40 GMT):
Hence why the digest algorithm forms part of the digital signature definition

tplooker (Tue, 06 Oct 2020 20:43:54 GMT):
You cannot seperate them without creating problems around interop

tplooker (Tue, 06 Oct 2020 20:47:54 GMT):
Unless the accompanying metadata to a signature includes enough explicit information so that all parties know how to do the verification process, there is a problem and the more optionality we provide the more brittle this gets

brentzundel (Tue, 06 Oct 2020 20:59:01 GMT):
From the LD proofs perspective that makes a lot of sense. Would it work to define versioned interoperable encodings separately, such that they could be used by any number of signature schemes, then link to the required encoding version from the LD proof description?

tplooker (Tue, 06 Oct 2020 21:02:26 GMT):
Yeap its a bit of work but I can see the value there

tplooker (Tue, 06 Oct 2020 21:02:54 GMT):
As long as the linked data proof suite definition can say concretely for this suite you have to support the following where it cannot change

tplooker (Tue, 06 Oct 2020 21:03:05 GMT):
If you want to change you must rev and create another cryptographic suite

tplooker (Tue, 06 Oct 2020 21:03:20 GMT):
E.g expand to a new set of supported encoding types

brentzundel (Tue, 06 Oct 2020 21:03:36 GMT):
Right.

esplinr (Thu, 08 Oct 2020 03:40:19 GMT):
I would argue that lowest-common-denominator interoperability is not our highest goal.

tplooker (Thu, 08 Oct 2020 03:49:22 GMT):
Interesting what would you argue is?

esplinr (Thu, 08 Oct 2020 03:49:32 GMT):
The problem with this discussion is that "interop" is not the highest goal for many use cases. In many use cases the issuer is the verifier. In others, interop is only required in a defined ecosystem where they can dictate the solutions used. All things being equal, interop is good, but not if it requires sacrificing functionality that is required for the business case.

esplinr (Thu, 08 Oct 2020 03:50:33 GMT):
The problem with this discussion is that "interop" is not the highest goal for many use cases. In many use cases the issuer is the verifier. In others, interop is only required in a defined ecosystem where they can dictate the solutions used. All things being equal, interop is good, but not if it requires sacrificing functionality that is required for the business case.

esplinr (Thu, 08 Oct 2020 03:53:27 GMT):
Or in other words, I'm more worried about short term adoption then short term interop. I believe that we can solve interop problems over the long term.

tplooker (Thu, 08 Oct 2020 04:24:43 GMT):
Fair enough, however I disagree and believe that many successful standards technology teach us that starting simpler gaining interop and laying in complexity is the way to achieve the best results

tplooker (Thu, 08 Oct 2020 04:24:43 GMT):
Fair enough, however I disagree and believe that many successful standards based technologies teach us that starting simpler gaining interop and laying in complexity is the way to achieve the best results

esplinr (Thu, 08 Oct 2020 04:26:46 GMT):
I recognize that different ecosystem participants will have different definitions of "best". That's what makes this a useful conversation.

tplooker (Thu, 08 Oct 2020 04:32:20 GMT):
Yeap it would be great to see a single solution here rather than two, what part of the conversation above had you concerned that your usecase's would not be meet

tplooker (Thu, 08 Oct 2020 04:34:14 GMT):
I only raised concerns around predicate proofs as I think some decisions can be deferred if we believe we have good answers but some cannot, and if they are they can either make a system vulnerable or be difficult to ever become a standards based technology where interoperable implementations can be built

tplooker (Thu, 08 Oct 2020 04:34:14 GMT):
I only raised concerns around predicate proofs as I think some decisions can be deferred if we believe we have good answers, but some cannot, and if they are they can either make a system vulnerable or be difficult to ever become a standards based technology where interoperable implementations can be built

tplooker (Thu, 08 Oct 2020 04:34:14 GMT):
I only raised concerns around predicate proofs as I think some decisions can be deferred if we believe we have good answers, but some cannot, and if they are, they can either make a system vulnerable or be difficult to ever become a standards based technology

esplinr (Thu, 08 Oct 2020 04:39:09 GMT):
I'm glad you are raising the concerns. It's a useful discussion.

esplinr (Fri, 09 Oct 2020 00:04:10 GMT):
This thread got really long and fragmented, so I wrote up my concerns in an email and sent them to the mailing list. https://lists.hyperledger.org/g/indy/topic/addressing_concerns_with/77395321?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,77395321

domwoe (Fri, 09 Oct 2020 11:41:38 GMT):
Has joined the channel.

swcurran (Tue, 13 Oct 2020 04:03:33 GMT):
Hey folks --- on the Indy Contributors call this coming Tuesday (October 13, 8AM Pacific, 5PM CET), we'll be talking about whether or not to release the Indy Node parts of Rich Schema, a new Indy HIPE about a generic token and continuing on with the discussions about the next release of Indy Node. Please join us on the call -- https://wiki.hyperledger.org/display/indy/2020-10-13+Indy+Contributors+Call -- Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 *NOTE THE NEW ZOOM LINK!!!!*

m00sey (Tue, 13 Oct 2020 16:05:00 GMT):
The one thing I wanted to try get consensus on was the `@pytest.mark` approach, if folks are happy with that, I'll add a check list item to the PR to get a "lint" step into verify that each `test_` method has an appropriate annotation, that way I can remove it from draft, and we can move forward.

esplinr (Tue, 13 Oct 2020 16:15:28 GMT):
I'm not familiar with `pytest.mark`. Can you link to an example?

m00sey (Tue, 13 Oct 2020 16:28:27 GMT):
In order to parallelize the build, I opted to create a build matrix for each of the "test" packages. Each test is annotated with `@pytest.mark` as this seemed the lowest barrier to entry in order to use pytest - m ``` @pytest.mark.anon_creds def test_send_get_revoc_reg_def(looper, txnPoolNodeSet, sdk_wallet_steward, sdk_pool_handle, send_revoc_reg_def_by_default): ``` This takes the build time from >45 minutes to ~12 minutes.

swcurran (Tue, 13 Oct 2020 16:51:18 GMT):
Sounds like a good approach @andrew.whitehead @WadeBarnes ^^^

WadeBarnes (Tue, 13 Oct 2020 16:53:34 GMT):
It has my vote.

jramps9 (Wed, 14 Oct 2020 14:07:41 GMT):
Hello Indy contributors! Reminder to please join the DevRel Marketing Committee call at 9am PT TODAY. Take a look at the agenda and add items if you'd like here: https://wiki.hyperledger.org/display/Marketing/2020-10-14+Meeting+notes

ianco (Mon, 19 Oct 2020 13:49:20 GMT):
Hi folks wondering if there is interest in an updated indy-sdk release? My project has a dependency on some code in msater ut not yet in a release. Understand that no one is supporting indy-sdk releases now, I'd be willing to help with coordinating/supporting the release id there is other interest in the community?

WadeBarnes (Mon, 19 Oct 2020 14:05:48 GMT):
I can assist with that @ianco

Jonathancj (Wed, 21 Oct 2020 23:55:58 GMT):
Has joined the channel.

nage (Thu, 22 Oct 2020 14:08:14 GMT):
The next Indy quarterly project report is due on the 29th. Any volunteers to help put it together?

swcurran (Thu, 22 Oct 2020 21:32:37 GMT):
I can do that.

swcurran (Mon, 26 Oct 2020 18:27:47 GMT):
Hey folks --- on the Indy Contributors call this coming Tuesday (October 26, 8AM Pacific, 4PM CET), we'll be talking about the status of the upcoming Indy Node release, requesting participation in a group to draft the `did:indy` DID Method spec, and talking about a request for a new indy-sdk release. Please join us on the call -- https://wiki.hyperledger.org/display/indy/2020-10-27+Indy+Contributors+Call -- Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09

swcurran (Mon, 26 Oct 2020 18:27:47 GMT):
Hey folks --- on the Indy Contributors call this coming Tuesday (October 27, 8AM Pacific, 4PM CET), we'll be talking about the status of the upcoming Indy Node release, requesting participation in a group to draft the `did:indy` DID Method spec, and talking about a request for a new indy-sdk release. Please join us on the call -- https://wiki.hyperledger.org/display/indy/2020-10-27+Indy+Contributors+Call -- Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09

swcurran (Mon, 26 Oct 2020 18:56:21 GMT):
Corrected the date in the notice above ^^^ the meeting is Tuesday, October 27th at the times listed above.

esplinr (Mon, 26 Oct 2020 22:32:15 GMT):
Might also be good to discuss this issue: https://github.com/hyperledger/indy-sdk/issues/2249

esplinr (Tue, 27 Oct 2020 14:21:23 GMT):
Remember that the Indy Contributors call is in 40 minutes. North America doesn't start winter time until this weekend, so it's at a different time for the European attendees. Join here: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09

mgbailey (Tue, 27 Oct 2020 15:28:18 GMT):
Has joined the channel.

swcurran (Tue, 27 Oct 2020 17:37:51 GMT):
FYI - We plan on having weekly `did:indy` Method Specification Drafting meetings on a weekly basis. I propose that the meetings be held at 7AM Pacific Time on Tuesdays, which is the hour before the bi-weekly Indy Contributors call. Request: Please let me know in replies if you plan on participating, and if so, if the time is OK with you, or what times would you prefer? Thanks!

jramps9 (Thu, 29 Oct 2020 13:53:22 GMT):
Hello! we're low on project news and updates for the dev/weekly newsletter going out tomorrow 10/30. If there's anything you'd like to suggest, please do so in the comments here: https://wiki.hyperledger.org/pages/viewpage.action?pageId=41584474

ianco (Thu, 29 Oct 2020 22:53:02 GMT):
Hi folks We're having a call tomorrow (Fri Oct 30) at 6AM Pacific time to talk about the next Indy SDK release. On the agenda is discussion about the tasks, artifacts and deliverables (basically a KT from the Evernym team). If you're interested in attending the call details are: Join Zoom Meeting https://us02web.zoom.us/j/88652458257?pwd=Z2xmdFpQbVBFTThWTVlOYm9ieitwUT09 Meeting ID: 886 5245 8257 Passcode: 534767

esplinr (Fri, 30 Oct 2020 13:04:09 GMT):
Starting the discussion about the Indy SDK release now: https://us02web.zoom.us/j/88652458257?pwd=Z2xmdFpQbVBFTThWTVlOYm9ieitwUT09

ianco (Fri, 30 Oct 2020 15:13:53 GMT):
Notes from this morning's Indy SDK discussion can be viewed here: https://docs.google.com/document/d/1QmSIfAqfYokHCOyLe65X7yAkLtGyUvPoyWK787L4r9E/edit?usp=sharing (Including a link to the recording of the meeting) Important dates are: Nov 10 - discuss the release at the Indy Contributors call Nov 17 - produce the 1.16.0 release candidate Nov 23 - promote 1.16.0 release candidate to "official" release What community members need to do: - Prior to Nov 10, ensure PR's are approved and merged (if required for the official release) - Nov 17-23, test the 1.16.0 release candidate and report issues Community support will be requested to support the iOS and Android wrappers, and potentially other release artifacts (to be discussed a the Nov 10 meeting)

smithbk (Wed, 04 Nov 2020 15:12:37 GMT):
Could someone review https://github.com/hyperledger/indy-sdk/pull/2273? I'd like to get this in for 1.16.0 release

crypto_beep (Wed, 04 Nov 2020 17:11:34 GMT):
Has joined the channel.

esplinr (Thu, 05 Nov 2020 15:17:15 GMT):
We'll try and get that reviewed before Tuesday's contributors call.

askolesov (Mon, 09 Nov 2020 10:42:57 GMT):
Has joined the channel.

jramps9 (Mon, 09 Nov 2020 18:12:30 GMT):
Hello Indy contributors! Reminder to please join the DevRel Marketing Committee call at 9am PT on 11/11 this week. Take a look at the agenda and add items if you'd like here: https://wiki.hyperledger.org/display/Marketing/2020-11-11+Meeting+notes

swcurran (Mon, 09 Nov 2020 18:51:48 GMT):
Hey folks --- on the Indy Contributors call is coming up - Tuesday (October 27, 8AM Pacific, 5PM CET), we'll be talking about the status of the upcoming Indy Node and Indy-SDK releases, and talking about Indy Plenum PRs. Please join us on the call -- https://wiki.hyperledger.org/display/indy/2020-11-10+Indy+Contributors+Call -- Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 Remember that the `did:indy` spec call will be one hour before this meeting.

evertonzn (Tue, 10 Nov 2020 12:13:05 GMT):
Has joined the channel.

evertonzn (Tue, 10 Nov 2020 12:13:06 GMT):
Hi Everyone, I'm Everton Zanotelli and I want to contribute to Hyperledger-Indy, I don't have practical experience with block-chain technology and i have never contributed to an open project before but I'm a very good learner and I want to help in anyway I can.

evertonzn (Tue, 10 Nov 2020 12:18:15 GMT):
This is my Linkedin profile: https://www.linkedin.com/in/everton-zanotelli-4953a12b/

swcurran (Tue, 10 Nov 2020 14:26:58 GMT):
Join us for the Indy Contributors call coming up in 1.5 hours.

m00sey (Tue, 10 Nov 2020 17:40:32 GMT):
latest push fixes the issue I raised regarding `indy_node/test/auth_rule/auth_framework/test_auth_rule_using.py` (successful build here https://github.com/m00sey/indy-node/actions/runs/356291178) I rebased so the change is buried, but if you look at the new file, it should look very familiar. I am available anytime this week for the indy-plenum call @Toktar @WadeBarnes

m00sey (Tue, 10 Nov 2020 17:40:32 GMT):
latest push fixes the issue I raised regarding `indy_node/test/auth_rule/auth_framework/test_auth_rule_using.py` (successful build here https://github.com/m00sey/indy-node/actions/runs/356291178) I rebased so the change is buried, but if you look at the file, it should look very familiar. I am available anytime this week for the indy-plenum call @Toktar @WadeBarnes

WadeBarnes (Tue, 10 Nov 2020 17:42:29 GMT):
I'm available Friday any time before 9am Pacific.

m00sey (Tue, 10 Nov 2020 17:52:20 GMT):
https://www.timeanddate.com/worldclock/meetingtime.html?iso=20201113&p1=256&p2=166&p3=198

m00sey (Tue, 10 Nov 2020 17:53:01 GMT):
I know you have a reputation for being up early Wade, but don't want to take advantage of it :)

m00sey (Tue, 10 Nov 2020 17:53:25 GMT):
6am your time? would be 5pm for @Toktar

m00sey (Tue, 10 Nov 2020 17:53:36 GMT):
obviously any time works for me :grimacing:

m00sey (Tue, 10 Nov 2020 17:54:04 GMT):
I can also see 5pm on a Friday not being ideal :/

WadeBarnes (Tue, 10 Nov 2020 17:55:26 GMT):
Yes 6am works for me.

WadeBarnes (Tue, 10 Nov 2020 17:56:02 GMT):
Agreed 5pm on a Friday is not ideal for @Toktar

ianco (Wed, 11 Nov 2020 15:20:28 GMT):
Jenkins tests are failing on a couple of indy-sdk PR's: https://github.com/hyperledger/indy-sdk/pull/2281 https://github.com/hyperledger/indy-sdk/pull/2273 The failures don't seem to have anything to do with the committed code, and in fact the first PR is just a documentation update. However this PR (a change to the node.js wrapper, just like 2273) seems to have no issues: https://github.com/hyperledger/indy-sdk/pull/2283 Help?

m00sey (Wed, 11 Nov 2020 19:18:57 GMT):
@Toktar any chance that time works for you?

WadeBarnes (Thu, 12 Nov 2020 14:25:38 GMT):
You and I can review today.

WadeBarnes (Thu, 12 Nov 2020 17:20:36 GMT):
@Toktar, Regarding the planned Indy SDK release for next week. Are there any dependencies we need to release/version like we do with indy-node?

WadeBarnes (Thu, 12 Nov 2020 17:20:36 GMT):
@Toktar, Regarding the planned Indy SDK release for next week. Are there any dependencies we need to release/version like we do with indy-node? Just want to make sure the docs we are following are complete; https://github.com/hyperledger/indy-sdk/blob/master/docs/contributors/release-workflow.md

esplinr (Thu, 12 Nov 2020 20:59:05 GMT):
There are no updates to the token plugin, but I believe that it needs to be included in the release.

WadeBarnes (Thu, 12 Nov 2020 21:09:09 GMT):
For indy-node yes, but that's not required for indy-sdk, is it?

esplinr (Thu, 12 Nov 2020 21:17:46 GMT):
Sorry, I read too fast.

esplinr (Thu, 12 Nov 2020 21:18:01 GMT):
I'm not aware of any dependencies for Indy SDK.

ianco (Fri, 13 Nov 2020 19:05:51 GMT):
Reminder we are going to be creating a new indy sdk release next week, if there are any outstanding PR's please try to get them merged before Monday

esplinr (Fri, 13 Nov 2020 20:17:56 GMT):
There are a lot of PRs that would benefit from review by someone in a different organization than the submitter.

ianco (Fri, 13 Nov 2020 22:23:30 GMT):
If you have any specific #'s I can take a look

ianco (Fri, 13 Nov 2020 22:24:04 GMT):
I can merge about 1 per day due to the amount of time required to run the tests

Toktar (Mon, 16 Nov 2020 22:17:10 GMT):
@WadeBarnes @ianco At the moment, the Indy-sdk master has problems with building on CD, because Apple stopped supporting 32-bit systems, as a result, RUST did the same. So the IOS build doesn't work. We are working on it, maybe working together we can unblock the release faster. I will clarify the status of the work by tomorrow. As for the indy-node dependencies for indy-sdk, it is only for integration tests and does not require any special releases or actions. The release process document from the link should be correct, but our experts said that the diagram may have changed. In case of problems, @sergey.minaev is now available. I think he is more experienced in this.

Toktar (Mon, 16 Nov 2020 22:30:35 GMT):
@m00sey I'm really sorry I wasn't available last week. GitHub actions on your link look impressive! I see that auth_rules passed and there are no skipped tests but a lot of deselected tests. If the problem is still actual, could you please write me details (what error messages do you have)? I'll do my best.

ianco (Mon, 16 Nov 2020 23:47:23 GMT):
Status on the preparation for the Indy SDK release @Toktar @esplinr @WadeBarnes: - I have opened a draft PR from `master` branch to `rc` branch with the changes since the previous release (I just took the contents of `master`, I didn't try to cherry-pick) - I merged a couple of PR's over the weekend, there are still a lot outstanding and even some PR's that are "approved" are getting build errors on the automated tests, so if there is anything required for the release please let me know

ianco (Mon, 16 Nov 2020 23:47:23 GMT):
Status on the preparation for the Indy SDK release @Toktar @esplinr @WadeBarnes @rjones : - I have opened a draft PR from `master` branch to `rc` branch with the changes since the previous release (I just took the contents of `master`, I didn't try to cherry-pick) - I merged a couple of PR's over the weekend, there are still a lot outstanding and even some PR's that are "approved" are getting build errors on the automated tests, so if there is anything required for the release please let me know

ianco (Mon, 16 Nov 2020 23:49:06 GMT):
A note on some `DCO` issues - an un-signed commit snuck into the `master` branch (the PR was manually DCO-approved, who even know you could do that) - so the PR to the `rc` branch was failing. I manually added the DCO signature - it is in my fork of the repo, in the `master` branch as well as in the PR to `rc`, I assume we need to fix the `hyperledger/indy-sdk` repo as well

ianco (Mon, 16 Nov 2020 23:49:28 GMT):
Draft PR (for now) is here: https://github.com/hyperledger/indy-sdk/pull/2289

ianco (Mon, 16 Nov 2020 23:49:42 GMT):
... I still need to update version numbers and add the release notes/change log

m00sey (Wed, 18 Nov 2020 00:54:06 GMT):
I resolved the issue regarding auth_rules, however on the PR you mentioned plenum might be a better place to do a conversion to github actions first - There is a PR for plenum too. The github action branch for that is failing running the plenum tests: https://github.com/m00sey/indy-plenum/runs/1388550912?check_suite_focus=true It's 67 thousand lines of log output so any ideas on why the tests might be failing would be helpgul

ianco (Wed, 18 Nov 2020 15:08:20 GMT):
Can someone please review/approve this PR? https://github.com/hyperledger/indy-sdk/pull/2289

Toktar (Wed, 18 Nov 2020 16:41:52 GMT):
I think the main problem is ``` def genesis_dir(self): > return self.chroot_if_needed(self.config.GENESIS_DIR) E AttributeError: module 'plenum.config' has no attribute 'GENESIS_DIR' ``` We had the same problem a long time ago. I'll try to find how to fix it.

ianco (Wed, 18 Nov 2020 22:34:09 GMT):
Thanks @WadeBarnes for approving the above PR!

ianco (Wed, 18 Nov 2020 22:34:29 GMT):
I have a separate PR with the version number bumps for libindy et al: https://github.com/hyperledger/indy-sdk/pull/2291

ianco (Wed, 18 Nov 2020 22:35:30 GMT):
Release notes are still w.i.p. however @esplinr can you/your team look after the VCX release notes (and please also verify the new version numbers)?

m00sey (Wed, 18 Nov 2020 23:45:45 GMT):
Excellent, thanks for taking a look

rrishmawi (Thu, 19 Nov 2020 10:33:33 GMT):
Hello experts, I have a generic question, I am not sure if this is the right place to ask about it. In Verifiable Credentials, how a VC is correlated with an entity like a user? I read about Blinded Linked Secrets? but I could not find a lot of information about it anywhere? I am really surprised that such proving ownership is not talked about a lot in the documentation s and the W3C standards? Am I missing something? Does Hyperledger Indy have a different method for VC ownership? is there a documentation i am missing that explain those concepts?

ianco (Thu, 19 Nov 2020 15:30:23 GMT):
One of the VCX node.js tests is failing in the indy-sdk automated tests, I'm not sure if this is randomness or solar flares or ???

ianco (Thu, 19 Nov 2020 15:30:24 GMT):
``` Using the vcx ffi directly ✓ a call to vcx_connection_create should return 0 1) a call to vcx_connection_create should return 0 3 passing (928ms) 1 failing 1) Using the vcx ffi directly a call to vcx_connection_create should return 0: Uncaught Error: ffi fatal: callback has been garbage collected! at /home/jenkins/workspace/indy-sdk_indy-sdk-ci_PR-2244/vcx/wrappers/node/node_modules/ffi/lib/callback.js:18:15 at process._tickCallback (internal/process/next_tick.js:61:11) ```

ianco (Thu, 19 Nov 2020 15:31:06 GMT):
In this PR: https://github.com/hyperledger/indy-sdk/pull/2291 ... however I've seen this same error occurring in other PR's, but not *all* PR's ...

esplinr (Thu, 19 Nov 2020 18:51:50 GMT):
@sergey.minaev Can you help here?

esplinr (Thu, 19 Nov 2020 18:52:16 GMT):
Questions like this belong in #indy

esplinr (Thu, 19 Nov 2020 18:52:54 GMT):
This channel is for coordinating the development of Indy.

ianco (Thu, 19 Nov 2020 22:44:36 GMT):
:+1:

ianco (Fri, 20 Nov 2020 15:30:00 GMT):
Is it possible to get this done by next Tuesday (Nov 24)? In which case we can kick off the indy-sdk release after the contributors call

ianco (Fri, 20 Nov 2020 15:30:30 GMT):
I've added release notes to the PR: https://github.com/hyperledger/indy-sdk/pull/2291 ... and it's ready to merge

esplinr (Fri, 20 Nov 2020 23:01:59 GMT):
We'll work to have that ready by Tuesday.

ianco (Fri, 20 Nov 2020 23:21:16 GMT):
Note that the iOS arm64 build is failing, I'm following up ...

ianco (Fri, 20 Nov 2020 23:21:50 GMT):
Could be related to https://github.com/hyperledger/indy-sdk/pull/2254 which isn't merged yet, however when I run locally with this PR it still fails

esplinr (Sat, 21 Nov 2020 01:54:32 GMT):
I think we should drop it from the build.

esplinr (Sat, 21 Nov 2020 01:54:55 GMT):
Our team can't fix it, and no one else is working on it.

ianco (Sat, 21 Nov 2020 14:47:13 GMT):
I agree, there is a PR to address this but it doesn't work (CI fails and it fails on my local)

sergey.minaev (Mon, 23 Nov 2020 11:51:47 GMT):
seems like PR 2254 has some problem fixed (like dropped 32-bit in scripts) but it's not about dependency problem for arm

sergey.minaev (Mon, 23 Nov 2020 15:37:22 GMT):
btw, there is a workaround for the pipeline, I hope to raise small PR with a hack to fix it temporary.

sergey.minaev (Mon, 23 Nov 2020 15:42:19 GMT):
@ianco we are going to update VCX change-log tomorrow morning Europe time, so I hope we will have release unblocked from our side

sergey.minaev (Mon, 23 Nov 2020 15:42:25 GMT):
@esplinr FYI

esplinr (Mon, 23 Nov 2020 15:43:06 GMT):
Thank you Sergey.

ianco (Mon, 23 Nov 2020 16:21:42 GMT):
Thanks Sergey!

swcurran (Tue, 24 Nov 2020 00:50:58 GMT):
Hey folks --- on the Indy Contributors call is coming up - Tuesday (November 24, 8AM Pacific, 5PM CET), we'll be talking about the status of Ubuntu 20.04 and the upcoming releases for indy-node and indy-sdk. We may cover as the topics covered in the DID Method Spec meetings. Please join us on the call -- https://wiki.hyperledger.org/display/indy/2020-11-24+Indy+Contributors+Call -- Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 Remember that the did:indy spec call will be one hour before this meeting on the same Zoom line. Meetings Page: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification

ianco (Tue, 24 Nov 2020 17:13:10 GMT):
Good news! I'm able to build the indy-sdk iOS targets locally with the latest updates from the `master` branch:

ianco (Tue, 24 Nov 2020 17:13:12 GMT):
`./ci/ios-build.sh libindy`

ianco (Tue, 24 Nov 2020 17:13:30 GMT):
- fetched latest updates form `master` and set rust version to `1.45.0`

ianco (Tue, 24 Nov 2020 17:13:30 GMT):
- fetched latest updates from `master` and set rust version to `1.45.0`

sergey.minaev (Wed, 25 Nov 2020 01:20:01 GMT):
master 1604 is succesfull as well. I suggest to merge the rest of master to rc branch as well

sergey.minaev (Wed, 25 Nov 2020 01:20:01 GMT):
master 1604 is succesfull as well. I suggest to merge the rest of master to rc branch to have it fixed

esplinr (Wed, 25 Nov 2020 06:29:54 GMT):
@mccown @m00sey After today's Indy Contributors call, I added links to some resources to help you understand the current CI / CD pipeline for Indy Node and Indy Plenum. Hopefully they help you to be able to complete updating to Ubuntu 20.04 and moving to GitHub Actions. This document is the best place to start: https://github.com/hyperledger/indy-node/blob/master/docs/source/ci-cd.md But I also link to some video explanations of the work we did on the pipeline in 2019. @Toktar and @sergey.minaev please share any additional resources that you think would be helpful.

swcurran (Wed, 25 Nov 2020 14:15:44 GMT):
Thanks, Richard -- those links were added to this document: https://wiki.hyperledger.org/display/indy/2020-11-24+Indy+Contributors+Call

SubhadeepBanerjee (Thu, 26 Nov 2020 14:47:09 GMT):
Has joined the channel.

sergey.minaev (Thu, 26 Nov 2020 22:50:53 GMT):
@ianco @WadeBarnes please find my thoughts on broken DCO in IndySDK in the PR https://github.com/hyperledger/indy-sdk/pull/2308#issuecomment-734499970

WadeBarnes (Fri, 27 Nov 2020 15:01:47 GMT):
Thanks @sergey.minaev, I responded on the ticket.

m00sey (Fri, 27 Nov 2020 20:45:20 GMT):
This is great thanks for pointing it out!

rjones (Sat, 28 Nov 2020 07:39:31 GMT):
When

rjones (Sat, 28 Nov 2020 07:39:31 GMT):
When Besu has this issue, they resolve with force push.

swcurran (Sun, 29 Nov 2020 00:58:48 GMT):
I think we should do that -- the sooner the better.

WadeBarnes (Sun, 29 Nov 2020 13:59:39 GMT):
I think @sergey.minaev is already working on it.

sergey.minaev (Mon, 30 Nov 2020 10:38:48 GMT):
yes, thanks all for the discussion and Ry for final approval.

sergey.minaev (Mon, 30 Nov 2020 10:47:02 GMT):
There was a decision to force push to master branch to fix broken DCO there. Please see details above and in the 2308 PR The PR with the fix is https://github.com/hyperledger/indy-sdk/pull/2313 and it has been "merged" to master. The old history is available in the temporary branch old_master https://github.com/hyperledger/indy-sdk/tree/old_master If you have in-progress PR merged with master recently you probably will have to force-push your branch. I would suggest you do an interactive rebase of your branch at the top of the new master and drop all commits which are not related to your work

SubhadeepBanerjee (Mon, 30 Nov 2020 14:29:42 GMT):
HI can anyone tell me some good sites where I can learn more about hyperledger Aries, apart from edx? Thank you

sergey.minaev (Tue, 01 Dec 2020 08:12:01 GMT):
@WadeBarnes could you check what is wrong with Jenkins runners? the latest RC of IndySDK is failed due to error related to docker: https://build.sovrin.org/job/indy-sdk/job/indy-sdk-cd/job/rc/162/execution/node/5645/log/

sergey.minaev (Tue, 01 Dec 2020 08:12:18 GMT):
FYI: @esplinr @ianco

WadeBarnes (Tue, 01 Dec 2020 15:44:18 GMT):
Rebooted the runners and Jenkins, started a new build; https://build.sovrin.org/job/indy-sdk/job/indy-sdk-cd/job/rc/163/

WadeBarnes (Tue, 01 Dec 2020 16:11:43 GMT):
@sergey.minaev, Now the Windows tests are failing because `jenkinsindy01` (192.168.202.91) is not responding. I'm not familiar with the role that `jenkinsindy01` plays here. Could you provide some insight?

sergey.minaev (Tue, 01 Dec 2020 17:45:20 GMT):
there should be an ubuntu machine which runs Node Pool for Windows pipeline. Most probably it's jenkinsindy01

sergey.minaev (Tue, 01 Dec 2020 17:45:20 GMT):
there should be an ubuntu machine which runs Node Pool for the Windows pipeline. Most probably it's jenkinsindy01

WadeBarnes (Tue, 01 Dec 2020 17:58:15 GMT):
It appears whatever services are running there did not survive a reboot. Does it require some special care and feeding?

WadeBarnes (Tue, 01 Dec 2020 17:59:11 GMT):
jenkinsindy01 be registered as a node in Jenkins, I noticed it is not.

WadeBarnes (Tue, 01 Dec 2020 17:59:11 GMT):
jenkinsindy01 be registered as a node in Jenkins? I noticed it is not.

sergey.minaev (Tue, 01 Dec 2020 18:18:56 GMT):
The pool should be started there, I don't know is it automated or not. And the IP should be unchanged or updated in the Jenkins variables AFAIK there is no need to register it as a worker, but it should be accessable from windows worker

WadeBarnes (Tue, 01 Dec 2020 18:26:07 GMT):
I can confirm the IP has not changed.

WadeBarnes (Tue, 01 Dec 2020 18:43:19 GMT):
As a test I completely shutdown and restarted jenkinsindy01. I'm working gaining login access to the server so I can troubleshoot the issue better if we continue to have issues.

dishan (Wed, 02 Dec 2020 01:18:42 GMT):
Has joined the channel.

sergey.minaev (Wed, 02 Dec 2020 10:59:40 GMT):
checked in the codebase: pool start is performed by the pipeline, so jenkinsindy01 is used as a remote docker engine

sergey.minaev (Wed, 02 Dec 2020 11:00:44 GMT):
https://github.com/hyperledger/indy-sdk/blob/master/Jenkinsfile.ci#L70-L72

WadeBarnes (Wed, 02 Dec 2020 14:30:17 GMT):
Thanks

SubhadeepBanerjee (Wed, 02 Dec 2020 14:59:25 GMT):
how can I install indy-cli in ubuntu 20.04?

jramps9 (Mon, 07 Dec 2020 18:00:19 GMT):
Hello Indy contributors! Reminder to please join the DevRel Marketing Committee call at 9am PT on 12/9 this week. Take a look at the agenda and add items if you'd like here: https://wiki.hyperledger.org/display/Marketing/2020-12-09+Meeting+notes

swcurran (Mon, 07 Dec 2020 19:44:17 GMT):
Hey folks --- on the Indy Contributors call is coming up - Tuesday (December 8, 8AM Pacific, 5PM CET) Please join us on the call -- https://wiki.hyperledger.org/display/indy/2020-12-08+Indy+Contributors+Call -- Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 Remember that the did:indy spec call will be one hour before this meeting on the same Zoom line. Meetings Page: https://wiki.hyperledger.org/display/indy/Indy+DID+Method+Specification We'll be talking about: * Status of Ubuntu ~20.04~ 18.04 work * Status of upcoming indy-node release, Rich Schema Feature Flag, and CI/CD Progress * Status of upcoming indy-sdk release

m00sey (Tue, 08 Dec 2020 16:35:02 GMT):
A quick thought on the term "deprecated" as lynn just mentioned in chat We could create a PR that says "this library is feature complete new features are not actively being developed" ?

m00sey (Tue, 08 Dec 2020 16:35:12 GMT):
I have seen that on other libraries I've used

m00sey (Tue, 08 Dec 2020 16:35:44 GMT):
That way it's still open if folks do want to add anything, but conveys the message it is not under active development?

swcurran (Tue, 08 Dec 2020 16:54:31 GMT):
I like that much better.

m00sey (Tue, 08 Dec 2020 17:27:24 GMT):
Summary of where the CI/CD stands. There is a PR in Indy Node (https://github.com/hyperledger/indy-node/pull/1622) for the CI aspect. No work has been done on the CD aspect, @Toktar, suggested it might be easier to complete indy-plenum first, given that release is coupled with an indy-node release. There is a draft PR in Indy plenum (https://github.com/hyperledger/indy-plenum/pull/1497) for the CI aspect, however the 'plenum suite' tests do not complete successfully. This is where help is required @Toktar left a comment previously: ```I think the main problem is def genesis_dir(self): > return self.chroot_if_needed(self.config.GENESIS_DIR) E AttributeError: module 'plenum.config' has no attribute 'GENESIS_DIR' We had the same problem a long time ago. I'll try to find how to fix it.``` I haven't looked into this any further, but that is the starting point, and the first place we need help.

esplinr (Wed, 09 Dec 2020 01:42:14 GMT):
Here is my proposal: > Future releases of the Indy SDK are not planned, as the previous maintainers are focused on replacement libraries. If you want to continue development in this repository, contact us at http://chat.hyperledger.org and we can arrange your access.

m00sey (Wed, 09 Dec 2020 01:44:09 GMT):
I don't think `as the previous maintainers are focused on replacement libraries. ` is necessary but yes. I'd approve.

m00sey (Wed, 09 Dec 2020 01:44:39 GMT):
actually I retract that, and we should point them to the shared libs?

esplinr (Wed, 09 Dec 2020 01:45:08 GMT):
I wanted to point them to the shared libs, but they aren't all in the Hyperledger org yet.

esplinr (Wed, 09 Dec 2020 01:45:13 GMT):
Once Andrew gets them moved, then we should do that.

m00sey (Wed, 09 Dec 2020 01:45:14 GMT):
aaah

m00sey (Wed, 09 Dec 2020 01:45:27 GMT):
then yeah, :thumbsup:

esplinr (Wed, 09 Dec 2020 01:45:42 GMT):
cc @andrew.whitehead

ArturPhilipp (Thu, 10 Dec 2020 12:16:00 GMT):
Has joined the channel.

swcurran (Fri, 11 Dec 2020 15:07:50 GMT):
@Toktar -- any luck in finding this

swcurran (Fri, 11 Dec 2020 15:07:50 GMT):
@Toktar -- any luck in finding this one? I don't see anything on the PR.

swcurran (Fri, 11 Dec 2020 15:08:05 GMT):
Thanks!

swcurran (Fri, 11 Dec 2020 15:16:10 GMT):
One of the things that we would like to see in the CI/CD work that is happening in indy-node and indy-plenum is a simplification of the branching model being used. We would like to see a simpler model where there is Main (aka Master) branch, and short lived PR branches for features. Releases are tagged commits on Main, and if an urgent patch is needed, a special branch is made from the release tag and handled appropriately. That would eliminate the use of the Stable branch and the RC branches. CI would trigger automatically on merges into Main, ideally, also on PR creation/update and we'll decide on the CD trigger/Tag creation strategy. We welcome input on this approach and how best to accomplish it. Since we are currently "stuck" on our ability to release, this seems like a good time to do this.

swcurran (Fri, 11 Dec 2020 15:50:18 GMT):
FYI -- created a page in the Indy space on the Hyperledger Wiki that can be used for the CI/CD project, and eventually as the hub for information about the Indy CI/CD process. Not to duplicate data, just as the place to start for CI/CD info. https://wiki.hyperledger.org/pages/viewpage.action?pageId=41588524 Hope that will be useful -- not much there yet, but we'll get there...

swcurran (Fri, 11 Dec 2020 22:18:47 GMT):
I'm very much against posting anything like what has been proposed. The sentiment is factually incorrect, let alone a terrible signal to the community. For example, when The project Ian C is on needed a feature and a release, they stepped up and are making that happen. The only thing I would be comfortable adding is a pointer to the chat (nm - already there) and a suggestion that they look at the Aries Frameworks rather than using "consuming" indy-sdk.

swcurran (Fri, 11 Dec 2020 22:18:47 GMT):
I'm very much against posting anything like what has been proposed. The sentiment is factually incorrect, let alone a terrible signal to the community. For example, when the project Ian C is on needed a feature and a release, they stepped up and are making that happen. The only thing I would be comfortable adding is a pointer to the chat (nm - already there) and a suggestion that they look at the Aries Frameworks rather than using "consuming" indy-sdk.

swcurran (Fri, 11 Dec 2020 22:18:47 GMT):
I'm very much against posting anything like what has been proposed. The sentiment is factually incorrect, let alone a terrible signal to the community. For example, when the project Ian C is on needed a feature and a release, they stepped up and are making that happen. The only thing I would be comfortable adding is a pointer to the chat (nm - already there) and a suggestion that they look at the Aries Frameworks rather than "consuming" indy-sdk.

esplinr (Mon, 14 Dec 2020 16:12:14 GMT):
How is the sentiment factually incorrect? Is the BC.gov team planning future releases?

esplinr (Mon, 14 Dec 2020 16:15:38 GMT):
I think that is a good model. We previously evaluated it, but we needed the Stable branch to give us a place to work on the concurrent token development. Now that Indy Node is more mature and the token plugin is deprecated, that approach should work.

esplinr (Mon, 14 Dec 2020 16:21:32 GMT):
@WadeBarnes @swcurran You asked for more information about acceptance testing of Indy Node releases for the Sovrin networks, so @vladimir.shishkin created this document: https://github.com/sovrin-foundation/sovrin/blob/master/docs/acceptance.md To go along with this document: https://github.com/sovrin-foundation/sovrin/blob/master/docs/release.md Do those documents answer your questions? Do you want to schedule a meeting to discuss in more detail?

vladimir.shishkin (Mon, 14 Dec 2020 16:21:32 GMT):
Has joined the channel.

esplinr (Mon, 14 Dec 2020 16:24:27 GMT):
Also, we talked about scheduling a meeting this week to discuss Indy Node questions with @Toktar . I think the interested people were @WadeBarnes, @mccown, and @m00sey. Would Thursday at 9AM Pacific work?

swcurran (Mon, 14 Dec 2020 16:31:32 GMT):
Can more information be provided about the 25 node upgrade test? Are we going to be able to continue to run that test?

sergey.minaev (Mon, 14 Dec 2020 16:31:52 GMT):
@WadeBarnes do you have any news about `jenkinsindy01` ? As far as I can see it's the last blocker for IndySDK release? FYI @ianco @esplinr

WadeBarnes (Mon, 14 Dec 2020 16:32:17 GMT):
I am working on that as we speak.

swcurran (Mon, 14 Dec 2020 16:35:14 GMT):
Others -- such as the MyPDX team have added fixes/features and organized a release. It's more than Evernym and BC Gov. Others are still doing work on wrappers -- such as Global ID.

sergey.minaev (Mon, 14 Dec 2020 16:36:25 GMT):
that was my understanding as well, thanks. I hope I shared enough context about this part of IndySDK CI/CD, but let me know if I can help from this point of view. Unfortunately, I don't have deep DevOps knowledge but I'm open to discussing any IndySDK specific requirement for the pipeline/infrastructure

swcurran (Mon, 14 Dec 2020 17:02:53 GMT):
I think we have a new requirement for the next release. In order to enable upgrading the nodes of an existing network, we need to be able to upgrade a single node at a time to use the 18.04 version while the other nodes on the network remain at Ubuntu 16.04. I think that means the next version needs to be EXACTLY the same as the previous version other than the changes to enable 18.04. Obviously, some exceptions are possible, but the more changes, the higher the risk.

esplinr (Mon, 14 Dec 2020 17:18:58 GMT):
The process for rolling updates already allows different versions of Indy Node to be deployed simultaneously across the pool. We just need to test on a pool containing nodes that run both versions of Ubuntu.

swcurran (Mon, 14 Dec 2020 17:20:22 GMT):
Right, but it can't be a rolling update as what we need is an individual node to change their OS, get all of their data over, perhaps change their IPs and then launch. So it won't be rolling at all AFAIK. Individual nodes updating one at a time.

esplinr (Mon, 14 Dec 2020 18:16:49 GMT):
Upgrading the network to a new release of Indy Node is independent from upgrading a single node from Ubuntu 16.04 to 18.04. Nodes currently update their software, rotate IPs, and do other maintenance on a regular basis. Which Ubuntu OS they run on shouldn't impact their ability to engage in consensus.

esplinr (Mon, 14 Dec 2020 18:18:41 GMT):
Indy Node is designed to work on a heterogeneous network (even though we haven't done that in the past).

esplinr (Mon, 14 Dec 2020 18:18:42 GMT):
So the process would be: 1. Upgrade Indy Node across the pool. 2. Then upgrade individual nodes (less than 8 at a time) from Ubuntu 16.04 to Ubuntu 18.04. 3. Each node can upgrade their existing data, or they can install fresh and perform catch-up. 4. When a node establishes consensus, a new node can upgrade.

esplinr (Mon, 14 Dec 2020 18:20:36 GMT):
@swcurran @WadeBarnes I saw a note that you still have questions about the difference between the Master branch and the Stable branch in Indy Plenum. We discussed it in the 20201110 Indy Contributors call, starting at minute 44. Do you have additional questions?

esplinr (Mon, 14 Dec 2020 18:22:59 GMT):
We discussed the difference between Indy Node Master and Stable in the 2020-09-17 special meeting, which I failed to record.

esplinr (Mon, 14 Dec 2020 18:24:52 GMT):
But we continued the conversation on 20200929 starting at minute 41.

esplinr (Mon, 14 Dec 2020 18:24:52 GMT):
But we continued the conversation regarding Plenum and Node on 20200929.

esplinr (Mon, 14 Dec 2020 18:24:52 GMT):
But we continued the conversation regarding Plenum and Node on 20200929. It seems like the conversation got relevant at minute 42.

esplinr (Mon, 14 Dec 2020 18:27:54 GMT):
Evernym maintained a pool for that test through March of 2020. @vladimir.shishkin is that pool still provisioned?

esplinr (Mon, 14 Dec 2020 18:29:42 GMT):
I'm not familiar with the MyPDX team or their long term plans.

esplinr (Mon, 14 Dec 2020 18:31:47 GMT):
I am nervous about leaving an expectation in place of future updates without a plan to do so. Because Evernym has provided this service in the past, people look for us to continue doing so. There are currently a lot of PRs and issues that will not be looked at. We should let people know, so that expectations are aligned with the future of the project.

esplinr (Mon, 14 Dec 2020 18:31:47 GMT):
I am nervous about leaving an expectation in place of future updates without a plan to meet those expectations. Because Evernym has provided this service in the past, people look for us to continue. There are currently a lot of PRs and issues that will not be looked at. We should let people know, so that expectations are aligned with the future of the project.

esplinr (Mon, 14 Dec 2020 18:32:02 GMT):
Do you have a suggestion for how to address that concern @swcurran ?

swcurran (Mon, 14 Dec 2020 19:57:22 GMT):
We discuss this at the next Indy Contributors call, but I would like to swap steps 1 and 2 -- is that possible? Upgrade a single Node to 18.04 and the new release one at a time. It would seem the safer thing to do, given the new release process we are doing.

swcurran (Mon, 14 Dec 2020 20:00:53 GMT):
I had previously checked the Indy Contributors call mentioned about Plenum Stable, but will try again. We're just going to have to move forward from the current release (what is running today) to a new release. Ideally that will happen entirely on the Main branch and we'll eliminate the use of Stable and RC branches. My hope is that will be part of the Project to upgrade the CI/CD, the branching model and delivering an 18.04 equivalent to what we are running today.

swcurran (Mon, 14 Dec 2020 20:01:37 GMT):
And just as important -- can it be put somewhere that the others can execute the test?

swcurran (Mon, 14 Dec 2020 20:06:10 GMT):
One thing we can do is to get a new set of people promoted to maintainers to direct the efforts of people as appropriate (ideally before they start). We need to remove the expectations on Evernym. But doing that with a notice as has been proposed is going to lead to an understanding that indy (not just the SDK) is impacted. I've seen this several times with well-meaning, but damaging statements on repos that make sense to the writer, but do not to a reader landing at the repo.

esplinr (Mon, 14 Dec 2020 20:45:13 GMT):
I don't understand how the new release process makes it safer to tie together the upgrade of Indy node and upgrade of OS. And I'm not clear on how you trigger that from the transaction signed by the trustees that gets added to the pool ledger.

esplinr (Mon, 14 Dec 2020 20:46:58 GMT):
Merging everything in Stable to Main, and then eliminating the Stable branch, should be fine. Releasing off of Main should also be fine for Indy. But it might complicate producing the Sovrin package until the token plugins are removed.

esplinr (Mon, 14 Dec 2020 20:50:54 GMT):
As the note states, we're happy to promote others to be maintainers. But I don't see any volunteers.

esplinr (Mon, 14 Dec 2020 20:52:26 GMT):
I agree that we should add a statement about Indy development continuing, with a link to those repos.

swcurran (Mon, 14 Dec 2020 21:10:30 GMT):
"Safer" -- If we prepare a new release using a new CI/CD process and then do an update of all nodes, then we are hoping that the release is sound. If we upgrade a single node and see if it plays well with others, then we can better trust the new release process.

swcurran (Mon, 14 Dec 2020 21:11:30 GMT):
And if someone wants to upgrade the SDK for something they need, they can do that.

m00sey (Tue, 15 Dec 2020 01:49:43 GMT):
That does work for me

WadeBarnes (Tue, 15 Dec 2020 15:23:47 GMT):
Me too

WadeBarnes (Tue, 15 Dec 2020 19:47:30 GMT):
@ianco @sergey.minaev @esplinr @swcurran The issue with `jenkinsindy01` affecting the Windows tests in the `indk-sdk` builds as been resolved. I ended up having to provision a replacement server (`jenkinsindy03` [`192.168.202.154`]) and have it minimally configured. The Jenkins `env` references to the server have been updated. The Windows Tests are still failing when trying the spin up an indy-node pool on `jenkinsindy03` due to the recent `indy-plenum` dependency issues. https://build.sovrin.org/blue/organizations/jenkins/indy-sdk%2Findy-sdk-cd/detail/rc/166/pipeline/100 ``` jenkins@JENKINSWINDOWS0 c:\Users\jenkins\workspace\indy-sdk\indy-sdk-cd\rc>docker -H 192.168.202.154 build --build-arg pool_ip=192.168.202.154 -f ci/indy-pool.dockerfile -t indy_pool ci Sending build context to Docker daemon 18.43kB Step 1/22 : FROM ubuntu:16.04 ---> 9499db781771 Step 2/22 : ARG uid=1000 ---> Using cache ---> a64768521817 Step 3/22 : RUN apt-get update -y && apt-get install -y git wget python3.5 python3-pip python-setuptools python3-nacl apt-transport-https ca-certificates supervisor ---> Using cache ---> 4f4d357d9296 Step 4/22 : RUN pip3 install -U pip==9.0.3 setuptools ---> Using cache ---> b268928c78dc Step 5/22 : RUN apt-key adv --keyserver keyserver.ubuntu.com --recv-keys CE7709D068DB5E88 || apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys CE7709D068DB5E88 ---> Using cache ---> 489655bd3914 Step 6/22 : ARG indy_stream=master ---> Using cache ---> 00ec6cc43a42 Step 7/22 : RUN echo "deb https://repo.sovrin.org/deb xenial $indy_stream" >> /etc/apt/sources.list ---> Using cache ---> 39d1f34a096f Step 8/22 : RUN useradd -ms /bin/bash -u $uid indy ---> Using cache ---> f9d887a39faf Step 9/22 : ARG indy_plenum_ver=1.12.1~dev989 ---> Using cache ---> 0bf9b2a2cc27 Step 10/22 : ARG indy_node_ver=1.12.1~dev1172 ---> Using cache ---> 10bb298f4a9d Step 11/22 : ARG python3_indy_crypto_ver=0.4.5 ---> Using cache ---> 55e7e380e3f4 Step 12/22 : ARG indy_crypto_ver=0.4.5 ---> Using cache ---> 3753363c3f67 Step 13/22 : ARG python3_pyzmq_ver=18.1.0 ---> Using cache ---> d272e72c469c 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 43c2e4e9b76d Hit:1 http://security.ubuntu.com/ubuntu xenial-security InRelease Get:2 https://repo.sovrin.org/deb xenial InRelease [28.4 kB] Get:3 https://repo.sovrin.org/deb xenial/master amd64 Packages [345 kB] Hit:4 http://archive.ubuntu.com/ubuntu xenial InRelease Get:5 http://archive.ubuntu.com/ubuntu xenial-updates InRelease [109 kB] Get:6 http://archive.ubuntu.com/ubuntu xenial-backports InRelease [107 kB] Get:7 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages [2386 kB] Get:8 http://archive.ubuntu.com/ubuntu xenial-updates/universe amd64 Packages [1530 kB] Fetched 4506 kB in 2s (1592 kB/s) Reading package lists... Reading package lists... Building dependency tree... Reading state information... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: indy-plenum : Depends: python3-orderedset (= 2.0) but 2.0.3 is to be installed Depends: python3-psutil (= 5.4.3) but 5.6.6 is to be installed Depends: python3-psutil (= 5.4.3) but 5.6.6 is to be installed Depends: python3-pympler (= 0.5) but 0.8 is to be installed E: Unable to correct problems, you have held broken packages. The command '/bin/sh -c 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' returned a non-zero code: 100 ``` Could someone familiar with the fix for this issue have a look at the associated `ci/indy-pool.dockerfile` docker file?

andrew.whitehead (Tue, 15 Dec 2020 20:44:34 GMT):
@WadeBarnes I'm not sure what the fix would be for that one, but I have an alternative version here that uses the pypi versions of the plenum/node packages: https://github.com/andrewwhitehead/indy-vdr/blob/feat/indy-utils/ci/indy-pool.dockerfile

WadeBarnes (Tue, 15 Dec 2020 22:48:51 GMT):
Thanks @andrew.whitehead

sergey.minaev (Wed, 16 Dec 2020 11:26:35 GMT):
Thanks @WadeBarnes and @andrew.whitehead . I will take a look on the dockerfile issue and proposed fix in the Ian's PR (I'm assuming it's copied from Andrew's repo).

esplinr (Wed, 16 Dec 2020 14:29:21 GMT):
I sent a calendar invitation. If others are interested, let me know and I'll add them.

WadeBarnes (Wed, 16 Dec 2020 14:36:15 GMT):
@sergey.minaev, @ianco already put in a PR; https://github.com/hyperledger/indy-sdk/pull/2328. I see you're already having a look.

ianco (Wed, 16 Dec 2020 14:36:44 GMT):
Yes it's a copy of the dockerfile from Andrew's repo

esplinr (Wed, 16 Dec 2020 14:59:56 GMT):
We discussed this as a team. Migrating the pool somewhere else is complicated because the current IP addresses are in the genesis file. We would need to checkpoint the ledger, but that would make the tests less representative of the real ledger.

esplinr (Wed, 16 Dec 2020 15:00:08 GMT):
We can discuss more on tomorrow's call.

m00sey (Wed, 16 Dec 2020 15:46:49 GMT):
Thanks, appreciate it

WadeBarnes (Wed, 16 Dec 2020 21:10:57 GMT):
The `indy-sdk` build is getting further now. The windows-tests are still failing, but they are failing on tests now. I've confirmed the failure is repeatable and not a build anomaly. Logs can be found here; https://build.sovrin.org/blue/organizations/jenkins/indy-sdk%2Findy-sdk-ci/detail/PR-2328/2/pipeline/141

WadeBarnes (Wed, 16 Dec 2020 21:12:01 GMT):
The following cargo tests are failing: ``` failures: high_cases::cred_def_cache::indy_get_cred_def_cache_works high_cases::cred_def_cache::indy_get_cred_def_empty_options high_cases::cred_def_cache::indy_get_cred_def_fully_qualified_ids high_cases::cred_def_cache::indy_get_cred_def_min_fresh_works high_cases::cred_def_cache::indy_get_cred_def_no_cache_works high_cases::cred_def_cache::indy_get_cred_def_no_store_works high_cases::cred_def_cache::indy_get_cred_def_only_cache_no_cached_data high_cases::schema_cache::indy_get_schema_cache_works high_cases::schema_cache::indy_get_schema_empty_options high_cases::schema_cache::indy_get_schema_fully_qualified_ids high_cases::schema_cache::indy_get_schema_min_fresh_works high_cases::schema_cache::indy_get_schema_no_cache_works high_cases::schema_cache::indy_get_schema_no_store_works high_cases::schema_cache::indy_get_schema_only_cache_no_cached_data ```

WadeBarnes (Wed, 16 Dec 2020 21:15:25 GMT):
Could this have something to do with the version of `indy-plenum` and `indy-node` used in the updated `ci/indy-pool.dockerfile`?

WadeBarnes (Wed, 16 Dec 2020 21:15:41 GMT):
Or do the tests actually need to be fixed?

WadeBarnes (Wed, 16 Dec 2020 21:15:41 GMT):
Or do the code/tests actually need to be fixed?

ianco (Wed, 16 Dec 2020 21:31:41 GMT):
The first error that occurs is this one: ```Structure doesn't correspond to type. Most probably not found Item not found on ledger }) INFO|indy::services::ledger | src\services\ledger\mod.rs:260 | parse_get_schema_response() => Err(IndyError { inner: Error("data did not match any variant of untagged enum Reply", line: 0, column: 0) ```

ianco (Wed, 16 Dec 2020 21:32:55 GMT):
The rest are just `message: "Error: Invalid pool handle\n Caused by: Pool with the same name is already opened\n"`, probably because the first error didn't clean up properly

ianco (Wed, 16 Dec 2020 21:33:29 GMT):
Looks like all the mac tests are passing

ianco (Wed, 16 Dec 2020 21:34:10 GMT):
I'll run the tests on my windoze box and see if I can duplicate the error

ianco (Wed, 16 Dec 2020 23:25:19 GMT):
I get this error running the tests on Windows, and then it seems to hang up: ```test high_cases::issuer_create_and_store_credential_def::issuer_create_and_store_credential_def_works ... thread '' panicked at 'attempted to leave type `linked_hash_map::Node` uninitialized, which is invalid', /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\library\core\src\mem\mod.rs:658:9 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ```

ianco (Wed, 16 Dec 2020 23:25:57 GMT):
I got the same error with the indy dockerfile as checked into the rc branch, as well as the "patched" version of the dockerfile with the older node/plenum versions

ianco (Wed, 16 Dec 2020 23:26:08 GMT):
All the tests ran fine on my mac

ianco (Wed, 16 Dec 2020 23:29:37 GMT):
```test high_cases::issuer_create_and_store_credential_def::issuer_create_and_store_credential_def_works ... thread '' panicked at 'attempted to leave type `linked_hash_map::Node` uninitialized, which is invalid', /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\library\core\src\mem\mod.rs:658:9 stack backtrace: 0: std::panicking::begin_panic_handler at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\std\src\panicking.rs:483 1: core::panicking::panic_fmt at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\core\src\panicking.rs:85 2: core::panicking::panic at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\/library\core\src\panicking.rs:50 3: core::mem::uninitialized at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\library\core\src\mem\mod.rs:658 4: linked_hash_map::LinkedHashMap::ensure_guard_node at C:\Users\iancostanzo\.cargo\registry\src\github.com-1ecc6299db9ec823\linked-hash-map-0.5.2\src\lib.rs:174 5: linked_hash_map::LinkedHashMap::insert at C:\Users\iancostanzo\.cargo\registry\src\github.com-1ecc6299db9ec823\linked-hash-map-0.5.2\src\lib.rs:304 6: lru_cache::LruCache::insert at C:\Users\iancostanzo\.cargo\registry\src\github.com-1ecc6299db9ec823\lru-cache-0.1.2\src\lib.rs:119 7: rusqlite::cache::StatementCache::cache_stmt at C:\Users\iancostanzo\.cargo\registry\src\github.com-1ecc6299db9ec823\rusqlite-0.20.0\src\cache.rs:143 8: rusqlite::cache::{{impl}}::drop at C:\Users\iancostanzo\.cargo\registry\src\github.com-1ecc6299db9ec823\rusqlite-0.20.0\src\cache.rs:86 9: core::ptr::drop_in_place at /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4\library\core\src\ptr\mod.rs:175 10: indy_wallet::storage::default::{{impl}}::add at .\indy-wallet\src\storage\default\mod.rs:353 11: indy_wallet::wallet::Wallet::add at .\indy-wallet\src\wallet.rs:131 12: indy_wallet::WalletService::add_record at .\indy-wallet\src\lib.rs:269 13: indy_wallet::WalletService::add_indy_record at .\indy-wallet\src\lib.rs:277 14: indy_wallet::WalletService::add_indy_object at .\indy-wallet\src\lib.rs:285 15: indy::commands::anoncreds::issuer::IssuerCommandExecutor::_complete_create_and_store_credential_definition at .\src\commands\anoncreds\issuer.rs:399 16: indy::commands::anoncreds::issuer::{{impl}}::_create_and_store_credential_definition_continue::{{closure}} at .\src\commands\anoncreds\issuer.rs:330 17: core::result::Result, indy_api_types::errors::IndyError>::and_then

ianco (Wed, 16 Dec 2020 23:31:56 GMT):
Looks like the error is raising in the sqlite libraries

ianco (Wed, 16 Dec 2020 23:32:58 GMT):
I used the prebuilt binaries from here: https://repo.sovrin.org/windows/libindy/deps/

ianco (Wed, 16 Dec 2020 23:33:32 GMT):
@WadeBarnes @sergey.minaev

WadeBarnes (Wed, 16 Dec 2020 23:37:24 GMT):
So we need something newer?

WadeBarnes (Wed, 16 Dec 2020 23:37:56 GMT):
Those look really old.

m00sey (Wed, 16 Dec 2020 23:56:25 GMT):
taking another shot at trying to come to some agreement here. I believe we have to do something to set expectations, as we have 57 PRs open, and the entire first page of them failing to build. I want to acknowledge Stephen's desire not to send a negative message to the community and I fully support that. I also appreciate Richard's desire for his team to be able to move on from Indy SDK. So here is what I have: add a section to the readme ```Project Status: We are actively seeking new (or existing) contributors to take ownership of providing new releases. Currently, no new releases are planned. If you would like to implement a feature, bug fix or provide a release, please contact the indy-contributors on Rocket Chat (chat.hyperledger.org) and the appropriate controls can be granted. A alternate approach is also being developed using Aries shared libraries, which offer an alternative to Indy SDK: * indy-vdr (https://github.com/hyperledger/indy-vdr) * indy-shared-rs (https://github.com/bcgov/indy-shared-rs) (currently being proposed to hyperledger) * aries-askar (https://github.com/bcgov/aries-askar) (currently being proposed to hyperledger) For any additional clarity please join us in Rocket Chat. ```

m00sey (Wed, 16 Dec 2020 23:56:25 GMT):
taking another shot at trying to come to some agreement here. I believe we have to do something to set expectations, as we have 57 PRs open, and the entire first page of them failing to build. I want to acknowledge Stephen's desire not to send a negative message to the community and I fully support that. I also appreciate Richard's desire for his team to be able to move on from Indy SDK. So here is what I have: add a section to the readme ```Project Status: We are actively seeking new (or existing) contributors to take ownership of create new releases. Currently, no new releases are planned. If you would like to implement a feature, bug fix or provide a release, please contact the indy-contributors on Rocket Chat (chat.hyperledger.org) and the appropriate controls can be granted. A alternate approach is also being developed using Aries shared libraries, which offer an alternative to Indy SDK: * indy-vdr (https://github.com/hyperledger/indy-vdr) * indy-shared-rs (https://github.com/bcgov/indy-shared-rs) (currently being proposed to hyperledger) * aries-askar (https://github.com/bcgov/aries-askar) (currently being proposed to hyperledger) For any additional clarity please join us in Rocket Chat. ```

m00sey (Wed, 16 Dec 2020 23:56:25 GMT):
taking another shot at trying to come to some agreement here. I believe we have to do something to set expectations, as we have 57 PRs open, and the entire first page of them failing to build. I want to acknowledge Stephen's desire not to send a negative message to the community and I fully support that. I also appreciate Richard's desire for his team to be able to move on from Indy SDK. So here is what I have: add a section to the readme ```Project Status: We are actively seeking new (or existing) contributors to take ownership of creating new releases. Currently, no new releases are planned. If you would like to implement a feature, bug fix or provide a release, please contact the indy-contributors on Rocket Chat (chat.hyperledger.org) and the appropriate controls can be granted. A alternate approach is also being developed using Aries shared libraries, which offer an alternative to Indy SDK: * indy-vdr (https://github.com/hyperledger/indy-vdr) * indy-shared-rs (https://github.com/bcgov/indy-shared-rs) (currently being proposed to hyperledger) * aries-askar (https://github.com/bcgov/aries-askar) (currently being proposed to hyperledger) For any additional clarity please join us in Rocket Chat. ```

m00sey (Wed, 16 Dec 2020 23:56:25 GMT):
taking another shot at trying to come to some agreement here. I believe we have to do something to set expectations, as we have 57 PRs open, and the entire first page of them failing to build. I want to acknowledge Stephen's desire not to send a negative message to the community and I fully support that. I also appreciate Richard's desire for his team to be able to move on from Indy SDK. So here is what I have: add a section to the readme ```Project Status: We are actively seeking new (or existing) contributors to take ownership of creating new releases. Currently, no new releases are planned. If you would like to implement a feature, bug fix or publish a release, please contact the indy-contributors on Rocket Chat (chat.hyperledger.org) and the appropriate controls can be granted. A alternate approach is also being developed using Aries shared libraries, which offer an alternative to Indy SDK: * indy-vdr (https://github.com/hyperledger/indy-vdr) * indy-shared-rs (https://github.com/bcgov/indy-shared-rs) (currently being proposed to hyperledger) * aries-askar (https://github.com/bcgov/aries-askar) (currently being proposed to hyperledger) For any additional clarity please join us in Rocket Chat. ```

ianco (Wed, 16 Dec 2020 23:58:33 GMT):
I tried substituting newer binaries from here (https://www.sqlite.org/download.html) (interestingly dll's not lib's) with no difference in results

andrew.whitehead (Wed, 16 Dec 2020 23:58:44 GMT):
lru_cache is old and busted. hashlink is the new version

ianco (Wed, 16 Dec 2020 23:58:50 GMT):
Looking at the stack trace it looks like it's getting raised in rust code

andrew.whitehead (Thu, 17 Dec 2020 00:02:47 GMT):
Looks like rusqlite updated that on Oct 6/7

andrew.whitehead (Thu, 17 Dec 2020 00:03:13 GMT):
So version 0.24.1 maybe

ianco (Thu, 17 Dec 2020 00:41:39 GMT):
Doesn't compile with 0.24.1

ianco (Thu, 17 Dec 2020 00:42:10 GMT):
Taking a break now I'll follow up on this in a bit

WadeBarnes (Thu, 17 Dec 2020 14:31:28 GMT):
Summary of latest development on the Windows build failures in the indy-sdk: We now have 2 PRs taking different apraoches to resolving the `indy-plenum` and `indy-node` dependancy issues in `ci/indy-pool.dockerfile`. Both are failing in the same way. Personally I'd perfer to move forward with the one that upgrades the `indy-plenum` and `indy-node` version in order to resolve the issue over one that uses verisons of `indy-plenum` and `indy-node` that have dependancy issues and require those dependancies to be included and pined explicitly. - https://github.com/hyperledger/indy-sdk/pull/2328 - https://github.com/hyperledger/indy-sdk/pull/2330

WadeBarnes (Thu, 17 Dec 2020 14:31:28 GMT):
Summary of latest development on the Windows build failures in the indy-sdk: We now have 2 PRs taking different apraoches to resolving the `indy-plenum` and `indy-node` dependancy issues in `ci/indy-pool.dockerfile`. Both are failing in the same way. Personally I'd perfer to move forward with the one that upgrades the `indy-plenum` and `indy-node` version in order to resolve the issue over one that uses verisons of `indy-plenum` and `indy-node` that have known dependancy issues and require those dependancies to be included and pined explicitly. - https://github.com/hyperledger/indy-sdk/pull/2328 - https://github.com/hyperledger/indy-sdk/pull/2330

WadeBarnes (Thu, 17 Dec 2020 14:31:28 GMT):
Summary of latest development on the Windows build failures in the indy-sdk: We now have 2 PRs taking different apraoches to resolving the `indy-plenum` and `indy-node` dependancy issues in `ci/indy-pool.dockerfile`. Both are failing in the same way. Personally I'd perfer to move forward with the one that upgrades the `indy-plenum` and `indy-node` version in order to resolve the issue over one that uses verisons of `indy-plenum` and `indy-node` that have known dependancy issues and require those dependancies to be included and pined explicitly. - https://github.com/hyperledger/indy-sdk/pull/2328 - Upgrade - https://github.com/hyperledger/indy-sdk/pull/2330 - Patch

ianco (Thu, 17 Dec 2020 14:59:07 GMT):
FYI the error we are getting is in the rusqlite library. The version we are using (0.20.0) fails, the latest version (0.24.1) doesn't compile

ianco (Thu, 17 Dec 2020 14:59:31 GMT):
(the error occurs on windows, everything runs fine on mac)

swcurran (Thu, 17 Dec 2020 16:04:29 GMT):
Some slight tweaks, but overall, I'm good with it: ``` Project Status: We are actively seeking contributors to take ownership of creating new releases. Currently, releases are occurring only on an as needed basis. If you would like to implement a feature, bug fix or publish a release, please contact the indy-contributors on Rocket Chat (chat.hyperledger.org) and the appropriate guidance and controls can be provided. A alternate approach to the indy-sdk is also being developed using new Indy and Aries shared libraries, which offer an alternative to Indy SDK: * [indy-vdr](https://github.com/hyperledger/indy-vdr) - a client interface to Indy Node ledgers. * [indy-shared-rs](https://github.com/bcgov/indy-shared-rs) - common Indy capabilities for Hyperledger Aries agents, including Credential Exchange. Currently being proposed as a Contribution to Hyperledger. * [aries-askar](https://github.com/bcgov/aries-askar) - a secure, encrypted storage service for Hyperledger Aries agents. Currently being proposed as a Contribution to Hyperledger. ```

ianco (Thu, 17 Dec 2020 16:38:49 GMT):
FY again I managed to get it working on Windows with an update to rusqlite and a small code patch (PR is updated), I'm just building/testing on Mac now

ianco (Thu, 17 Dec 2020 16:38:49 GMT):
FYI again I managed to get it working on Windows with an update to rusqlite and a small code patch (PR is updated), I'm just building/testing on Mac now

m00sey (Thu, 17 Dec 2020 17:01:46 GMT):
upon reading "which offer an alternative to Indy SDK:" seems superfluous.

m00sey (Thu, 17 Dec 2020 17:01:57 GMT):
minor detail

m00sey (Thu, 17 Dec 2020 17:02:13 GMT):
@esplinr is this satisfactory for you?

swcurran (Thu, 17 Dec 2020 17:05:40 GMT):
Yup -- superflous. :-)

swcurran (Thu, 17 Dec 2020 17:05:40 GMT):
Yup -- superfluous. :-)

ianco (Thu, 17 Dec 2020 17:12:36 GMT):
https://github.com/hyperledger/indy-sdk/pull/2328

ianco (Thu, 17 Dec 2020 17:12:53 GMT):
... tests all pass on Windows and Mac

WadeBarnes (Thu, 17 Dec 2020 19:29:29 GMT):
That seemingly did not translate across to the Jenkins build, or it the current build does not include those changes.

WadeBarnes (Thu, 17 Dec 2020 19:29:40 GMT):
Windows tests still failed.

WadeBarnes (Thu, 17 Dec 2020 19:31:43 GMT):
Nope, the build is using commit `8fee545`, which contains the changes.

ianco (Thu, 17 Dec 2020 20:36:01 GMT):
It's a different error this time: ```thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: IndyError { error_code: PoolLedgerTimeout, message: "Error: Pool timeout\n Caused by: Consensus is impossible\n" ```

ianco (Thu, 17 Dec 2020 20:37:06 GMT):
(This is on the first failure, the rest get `thread 'main' panicked at 'Once instance has previously been poisoned'` caused by `Caused by: Pool with the same name is already opened\n`

ianco (Thu, 17 Dec 2020 20:37:37 GMT):
... but it;'s the same set of tests that's failing

ianco (Thu, 17 Dec 2020 20:37:37 GMT):
... but it's the same set of tests that's failing

andrew.whitehead (Thu, 17 Dec 2020 20:39:19 GMT):
Consensus is impossible seems to indicate that one of the nodes was unreachable

ianco (Thu, 17 Dec 2020 20:41:57 GMT):
Anyways this is what we were getting before, on the first failure (same test though): ```Structure doesn't correspond to type. Most probably not found Item not found on ledger }) INFO|indy::services::ledger | src\services\ledger\mod.rs:260 | parse_get_schema_response() => Err(IndyError { inner: Error("data did not match any variant of untagged enum Reply", line: 0, column: 0) ```

ianco (Thu, 17 Dec 2020 20:42:14 GMT):
... now we get `Consensus is impossible`

andrew.whitehead (Thu, 17 Dec 2020 20:49:40 GMT):
Are they different plenum/node versions?

ianco (Thu, 17 Dec 2020 21:15:54 GMT):
Yes that's one of the changes in the PR, it has your updated dockerfile

andrew.whitehead (Thu, 17 Dec 2020 21:20:10 GMT):
I mean between the runs that got the not-found-on-ledger error and the consensus error. In either case it could be a plenum stability issue that might not be there in earlier versions. Or it's sporadic and running the tests again might work

andrew.whitehead (Thu, 17 Dec 2020 21:21:21 GMT):
Or the test is broken, I dunno

esplinr (Thu, 17 Dec 2020 21:32:11 GMT):
How soon can the "alternative libraries" be brought into Hyperledger?

andrew.whitehead (Thu, 17 Dec 2020 21:35:48 GMT):
I'm just looking at adapting some indy anoncreds tests before moving indy-shared-rs over, because there's very little coverage on indy-credx at the moment. There's a branch of aca-py now that works using all the new libraries though

esplinr (Thu, 17 Dec 2020 21:36:41 GMT):
I'm nervous about linking to the repos in their temporary location, so I'll continue to mention that the Indy Contributors call is the best place to learn about the alternatives.

esplinr (Thu, 17 Dec 2020 21:36:55 GMT):
Thank you for the suggested improvements. All add them to the PR.

WadeBarnes (Thu, 17 Dec 2020 21:51:36 GMT):
Restarted the build to test the theory.

esplinr (Thu, 17 Dec 2020 21:54:18 GMT):
With your improvements, I think we have a decent message put together. Thank you! https://github.com/hyperledger/indy-sdk/pull/2329/files

ianco (Thu, 17 Dec 2020 23:23:48 GMT):
Failed again with the same error

andrew.whitehead (Thu, 17 Dec 2020 23:24:34 GMT):
Which test and error

ianco (Thu, 17 Dec 2020 23:27:37 GMT):
`Consensus is impossible`, however tracing back further in the log (the secret "view full log" command) shows this error: ```DEBUG|indy::commands | src\commands\mod.rs:180 | LedgerCommand command received INFO|indy::services::ledger | src\services\ledger\mod.rs:458 | parse_response() => Err(IndyError { inner: Error("data did not match any variant of untagged enum Reply", line: 0, column: 0) ```

ianco (Thu, 17 Dec 2020 23:27:47 GMT):
... so I guess the answer is, BOTH

ianco (Thu, 17 Dec 2020 23:29:42 GMT):

ianco - Thu Dec 17 2020 15:29:39 GMT-0800 (Pacific Standard Time).txt

ianco (Thu, 17 Dec 2020 23:30:29 GMT):
It's not recognizing a reply fro the Ledger

ianco (Thu, 17 Dec 2020 23:30:29 GMT):
It's not recognizing a reply from the Ledger

andrew.whitehead (Thu, 17 Dec 2020 23:59:09 GMT):
From what I can tell it's just logging the fact that it got a not-found error when looking up a schema. Maybe it's supposed to. Does it not say what test is being run

andrew.whitehead (Fri, 18 Dec 2020 00:05:11 GMT):
It's likely this test in fact: https://github.com/hyperledger/indy-sdk/blob/f9eb2cf17b51584f875c4707094256a96656e7b8/libindy/tests/ledger.rs#L3546

andrew.whitehead (Fri, 18 Dec 2020 00:07:27 GMT):
Similarly, the other error is probably intentional and raised by this: https://github.com/hyperledger/indy-sdk/blob/f9eb2cf17b51584f875c4707094256a96656e7b8/libindy/tests/pool.rs#L354

andrew.whitehead (Fri, 18 Dec 2020 00:10:09 GMT):
Although I would expect there to be a lot more logged errors

ianco (Fri, 18 Dec 2020 18:41:24 GMT):
I'm just running `cargo test --features only_high_tests`, which it looks like is what Jenkins is running, unless I'm missing something ...

ianco (Fri, 18 Dec 2020 18:41:30 GMT):
@andrew.whitehead

andrew.whitehead (Fri, 18 Dec 2020 19:10:19 GMT):
With that command I get five failures, 3 in `services::pool::merkle_tree_factory::tests` and two in `services::pool::pool::tests`, but that's without running a local node pool at all

andrew.whitehead (Fri, 18 Dec 2020 19:16:13 GMT):
Yikes. I got different test failures running it again

andrew.whitehead (Fri, 18 Dec 2020 19:24:07 GMT):
Okay all those pass when running with `-- --test-threads 1`, which makes sense. At least some of the failing tests were testing the protocol version which is a library-global setting, so running other tests in parallel would trample on it. I guess the jenkins environment might have an environment variable to do the same

andrew.whitehead (Fri, 18 Dec 2020 19:24:24 GMT):
Tests start failing once it gets to `high_cases` which probably does need the local pool

andrew.whitehead (Fri, 18 Dec 2020 19:39:57 GMT):
@ianco How are you running that? I think I need to specify the IP, or run the tests in docker too

ianco (Fri, 18 Dec 2020 20:54:40 GMT):
you can run a local pool using the indy dockerfile in the sdk: https://github.com/hyperledger/indy-sdk#1-starting-the-test-pool-on-localhost

ianco (Fri, 18 Dec 2020 20:55:51 GMT):
Yes I can get different errors depending on how I run the tests but I've never managed to duplicate the error that are showing up in Jenkins (and yes I usually run `--test-threads=1` also)

WadeBarnes (Sun, 20 Dec 2020 18:14:50 GMT):
To resolve the various `No space left on device` errors we were seeing in the builds, I cleared off disk space on all of the Jenkins nodes. The Jenkins nodes were basically full with dangling docker images. Pruning the images reduced disk use to around 30%. The build of [PR-2328](https://github.com/hyperledger/indy-sdk/pull/2328) started following the cleanup way successful. I also started a new build of [PR-2330](https://github.com/hyperledger/indy-sdk/pull/2330) for comparison.

WadeBarnes (Sun, 20 Dec 2020 18:14:50 GMT):
To resolve the various `No space left on device` errors we were seeing in the builds, I cleared off disk space on all of the Jenkins nodes. The Jenkins nodes were basically full with dangling docker images. Pruning the images reduced disk use to around 30%. The build of [PR-2328](https://github.com/hyperledger/indy-sdk/pull/2328) started following the cleanup was successful. I also started a new build of [PR-2330](https://github.com/hyperledger/indy-sdk/pull/2330) for comparison.

WadeBarnes (Mon, 21 Dec 2020 13:45:52 GMT):
The build for [PR-2330](https://github.com/hyperledger/indy-sdk/pull/2330) was successful too.

ianco (Mon, 21 Dec 2020 14:17:47 GMT):
Awesome, thanks @WadeBarnes !!! Sounds like we need to pick an approach and to move forward (i.e. merge the PR, produce and test the release). I vote for PR-2328 (upgrade indy-node version) vs PS-2330 (pin dependency versions for older indy-node version), but would be willing to go with either in order to move forward with the release. @WadeBarnes @sergey.minaev @esplinr @swcurran @andrew.whitehead ?

WadeBarnes (Mon, 21 Dec 2020 14:18:59 GMT):
My vote is for PR-2328 (upgrade indy-node version) as I've already indicated on the PRs themselves.

swcurran (Mon, 21 Dec 2020 16:31:27 GMT):
We need to catch up tomorrow on the Indy Contributors call. Our goal right now is to produce the exact Indy Node artifact (with dependencies - indy-crypto, indy-plenum and token-plugin) using the new indy-node- and indy-plenum CI/CD processes. Anything other than that isn't moving us forward.

WadeBarnes (Mon, 21 Dec 2020 16:33:55 GMT):
The point to all of this was to establish a working baseline on which we can verify the new processes.

ianco (Mon, 21 Dec 2020 16:37:18 GMT):
Just to clarify the above 2 PR's are for the indy-sdk release, I don't think having a *specific* indy node/plenum version is a hard requirements, we just need to be able to ru the build

swcurran (Mon, 21 Dec 2020 16:54:26 GMT):
Ah..OK -- I saw the reference to indy-node in the comments.

ianco (Mon, 21 Dec 2020 16:56:29 GMT):
PS is there an indy contributors call tomorrow?

swcurran (Mon, 21 Dec 2020 16:56:48 GMT):
Yes -- I'm still planning to do that one.

ianco (Mon, 21 Dec 2020 16:57:01 GMT):
ok I'll be there!

swcurran (Tue, 22 Dec 2020 05:24:20 GMT):
Hey folks --- on the Indy Contributors call is coming up - Tuesday (December 22, 8AM Pacific, 5PM CET) Please join us on the call -- https://wiki.hyperledger.org/display/indy/2020-12-22+Indy+Contributors+Call -- Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 We'll be talking about: * Status of Ubuntu 18.04 work * Status of upcoming indy-node CI/CD progress * Status of upcoming indy-sdk release

m00sey (Tue, 22 Dec 2020 13:36:51 GMT):
@Toktar trying to replicate the genesis_dir error you pointed out before, if I run the entire suite, I get the error, but if I tag `@pytest.mark.something` just a subset of tests (that fail in the full run) they pass... does that make _any_ sense to you? The genesis dir is getting set in `ubuntu_platform_config.py` and is pulled into conftest as `import plenum.server.general_config.ubuntu_platform_config as platform_config` - as of the moment I have still been unable to get plenum to run and complete the tests successfully locally

m00sey (Tue, 22 Dec 2020 16:12:19 GMT):
https://github.com/m00sey/indy-node/actions https://github.com/m00sey/indy-plenum/actions

m00sey (Tue, 22 Dec 2020 16:12:24 GMT):
@WadeBarnes

esplinr (Tue, 22 Dec 2020 16:53:30 GMT):
A correction from what I said in the Indy Contributors call. I said there was already a HIPE about payments in Indy, but I was thinking about this design document: https://github.com/hyperledger/indy-sdk/tree/master/docs/design/004-payment-interface

esplinr (Tue, 22 Dec 2020 16:53:42 GMT):
@m00sey is correct that we should make it a HIPE.

esplinr (Tue, 22 Dec 2020 17:10:42 GMT):
And an item I forgot to share: We want to add to core Indy the concept of "stubbing a ledger". If a plugin creates a custom ledger, but the ledger is not used, and then the plugin is removed and the custom ledger dropped, the stub would return a constant merkle tree hash so that the audit ledger stays consistent. This would simplify maintaining the Sovrin MainNet because we could remove the unused Token plugin. Any thoughts about that approach?

esplinr (Tue, 22 Dec 2020 17:17:22 GMT):
@askolesov did I describe that correctly?

askolesov (Tue, 22 Dec 2020 17:50:58 GMT):
[ ](https://chat.hyperledger.org/channel/indy-contributors?msg=WNJaNkF3orDM23FmQ) Yes, great explanation

askolesov (Tue, 22 Dec 2020 17:50:58 GMT):
Yes, great explanation

askolesov (Wed, 23 Dec 2020 21:16:10 GMT):
@m00sey Hi! Sorry, Renata is really busy on the other project. I will help you with pipelines until she returns. I'm looking into the issue with GENESIS_DIR, will notify you about progress.

WadeBarnes (Wed, 23 Dec 2020 21:18:00 GMT):
@sergey.minaev, @ianco, Indy-SDK RC build update. Build 167 failed with the following error; https://build.sovrin.org/job/indy-sdk/job/indy-sdk-cd/job/rc/167/execution/node/6174/log/ The actual error appears to be `gpg: signing failed: Inappropriate ioctl for device`, which indicates an `export GPG_TTY=$(tty)` is missing from somewhere so the code signing fails. The flow can be found here; https://build.sovrin.org/blue/organizations/jenkins/indy-sdk%2Findy-sdk-cd/detail/rc/167/pipeline/5483 The publishing gets to this point, https://github.com/hyperledger/indy-sdk/blob/master/Jenkinsfile.cd#L1355, in the Jenkins pipeline and then calls into the https://github.com/sovrin-foundation/sovrin-packaging tools where it fails with the above error. It does not look like much has changes that would affect that pipeline. @sergey.minaev, Any thoughts? I've started a new build to see if this is repeatable. Only other theory I have at the moment is that one of the installed tool chains along the way used to configure the environment for the gpg code signing and now it does not.

WadeBarnes (Wed, 23 Dec 2020 21:18:00 GMT):
@sergey.minaev, @ianco, Indy-SDK RC build update. Build 167 failed with the following error; https://build.sovrin.org/job/indy-sdk/job/indy-sdk-cd/job/rc/167/execution/node/6174/log/ The actual error appears to be `gpg: signing failed: Inappropriate ioctl for device`, which indicates an `export GPG_TTY=$(tty)` is missing from somewhere so the code signing fails. The flow can be found here; https://build.sovrin.org/blue/organizations/jenkins/indy-sdk%2Findy-sdk-cd/detail/rc/167/pipeline/5483 The publishing gets to this point, https://github.com/hyperledger/indy-sdk/blob/master/Jenkinsfile.cd#L1355, in the Jenkins pipeline and then calls into the https://github.com/sovrin-foundation/sovrin-packaging tools where it fails with the above error. It does not look like much has changed that would affect that pipeline. @sergey.minaev, Any thoughts? I've started a new build to see if this is repeatable. Only other theory I have at the moment is that one of the installed tool chains along the way used to configure the environment for the gpg code signing and now it does not.

askolesov (Thu, 24 Dec 2020 17:18:08 GMT):
@m00sey Can you share dockerfile for m00sey/indy-node-build?

WadeBarnes (Thu, 24 Dec 2020 17:24:46 GMT):
Potential fix; https://github.com/hyperledger/indy-sdk/pull/2337

WadeBarnes (Thu, 24 Dec 2020 17:52:56 GMT):
Is this it? https://github.com/m00sey/indy-node/blob/ci-update/.github/workflows/build/Dockerfile

WadeBarnes (Thu, 24 Dec 2020 17:59:23 GMT):
@sergey.khoroshavin, I'm not sure I understand your comment; https://github.com/hyperledger/indy-sdk/pull/2337#pullrequestreview-558693129

WadeBarnes (Thu, 24 Dec 2020 18:00:02 GMT):
That script and the code doing the signing will all be running in the same context in the same container.

WadeBarnes (Thu, 24 Dec 2020 21:07:16 GMT):
I've updated the `repo` user configuration on `repo.sovrinops.com` (aka `repo.sovrin.org`) in an attempt to make sure the environment for the GPG signing is loaded, and started a new build on `rc`.

sergey.minaev (Fri, 25 Dec 2020 09:49:31 GMT):
@WadeBarnes I can remember the following problem in the past: after reboot of the repo machine, there was a need to "activate" gpg key to do signing - add it to active and enter a password I've never done it for gpg but assume something similar to ssh-agent and ssh-add procedure

sergey.minaev (Fri, 25 Dec 2020 09:50:12 GMT):
probably @lynn.bendixsen can remember more details

askolesov (Fri, 25 Dec 2020 11:58:34 GMT):
Probably yes, thanks

WadeBarnes (Mon, 28 Dec 2020 15:45:18 GMT):
Loaded the `gpg-agent` and signed a dummy file which requested the passphrase on the initial signing. Following that I was able to ssh in and sign files without having to enter the passphrase. Started a new build. If this works I'll have to document the "initialization" process better.

askolesov (Mon, 28 Dec 2020 20:03:19 GMT):
Still researching. The issue is really hard to debug. I tried to run failing tests separately on GitHub and they worked. I'll be on vacations for the next two days. Renata will continue research during this period.

WadeBarnes (Mon, 28 Dec 2020 20:57:32 GMT):
That seems to have done the trick. The build is now awaiting input: ``` Publish Indy to Cargo [Pipeline] input Approve if indy-sys is available on crates.io Proceed or Abort ```

WadeBarnes (Mon, 28 Dec 2020 20:57:46 GMT):
https://build.sovrin.org/job/indy-sdk/job/indy-sdk-cd/job/rc/170/console

WadeBarnes (Mon, 28 Dec 2020 21:01:46 GMT):
The release workflow documentation does not indicate what we should be doing at this point; https://github.com/hyperledger/indy-sdk/blob/master/docs/contributors/release-workflow.md

m00sey (Mon, 28 Dec 2020 21:40:45 GMT):
Thanks for taking a look guys, not getting rocket chat notifications but I’ll keep checking back

m00sey (Mon, 28 Dec 2020 21:41:12 GMT):
Yup that’s it, thanks Wade

sergey.minaev (Wed, 30 Dec 2020 14:53:43 GMT):
I've added it recently as a temporary solution. For some reason `indy` failing to be published on crates due to missed `indy-sys`. There is an active issue about it https://github.com/hyperledger/indy-sdk/issues/2309

sergey.minaev (Wed, 30 Dec 2020 14:56:30 GMT):
For the 170 build I've checked crates.io and indy-sys is there. So I've approved this check. If everything else will be succesfull we will have RC builds and the pipeline would be paused for manual approving of RC to became stable. This approval should be given only after enough acceptance testing

sergey.minaev (Wed, 30 Dec 2020 18:54:45 GMT):
Indy SDK 1.16.0 RC 170 is ready for testing. Please do not push "proceed" key in manual step until the manual testing done and we have enough approvals from our community

swcurran (Mon, 04 Jan 2021 16:22:54 GMT):
Hey folks --- the Indy Contributors call is coming up tomorrow - Tuesday January 5, 8AM Pacific, 5PM CET) Please join us on the call -- https://wiki.hyperledger.org/display/indy/2021-01-05+Indy+Contributors+Call -- Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 We'll be talking about: * Status of CI/CD updates for Indy Plenum and Indy Node * Status of upcoming indy-sdk release * More on release sequences

ianco (Mon, 04 Jan 2021 19:06:54 GMT):
FYI I've finished the Ubuntu tests as per: https://github.com/hyperledger/indy-sdk/blob/master/docs/acceptance.md

ianco (Mon, 04 Jan 2021 19:07:40 GMT):
Everything passed, I had a couple issues running the tests but I'll update the doc with my experiences

ianco (Mon, 04 Jan 2021 19:07:50 GMT):
Working on the Windows tests now ..

ianco (Mon, 04 Jan 2021 22:24:50 GMT):
Windows tests also all pass

swcurran (Tue, 05 Jan 2021 01:27:53 GMT):
Folks: BC Gov want to contribute the indy-shared-rs (https://github.com/bcgov/indy-shared-rs) repo to Hyperledger. The repo contains Rust code that works with the already contributed indy-vdr (https://github.com/hyperledger/indy-vdr) and the also to be contributed aries-askar (https://github.com/bcgov/aries-askar) to enable the creation of Aries Agents without using the indy-sdk. Our expectation is that the combination of libraries will be more flexible, capable and performant, and will eliminate the need to use the indy-sdk at all. Per the readme for indy-shared-rs: > > Shared Rust libraries for Hyperledger Indy, the library includes: > > * indy-credx: Indy verifiable credential issuance and presentation (aka Anoncreds) > * indy-data-types: Data type definitions for Schemas, Credential Definitions and other types related to credential issuance and processing > * indy-test-utils: Utilities for use in integration tests. > * indy-utils: Standard wrappers around binary data encodings and Ursa-provided cryptography functions. > We'll talk about this briefly on the Indy Contributors call tomorrow (https://wiki.hyperledger.org/display/indy/2021-01-05+Indy+Contributors+Call) Please let us know if you support or object to this contribution.

swcurran (Tue, 05 Jan 2021 01:27:53 GMT):
Folks: BC Gov wants to contribute the indy-shared-rs (https://github.com/bcgov/indy-shared-rs) repo to Hyperledger. The repo contains Rust code that works with the already contributed indy-vdr (https://github.com/hyperledger/indy-vdr) and the also to be contributed aries-askar (https://github.com/bcgov/aries-askar) to enable the creation of Aries Agents without using the indy-sdk. Our expectation is that the combination of libraries will be more flexible, capable and performant, and will eliminate the need to use the indy-sdk at all. Per the readme for indy-shared-rs: > > Shared Rust libraries for Hyperledger Indy, the library includes: > > * indy-credx: Indy verifiable credential issuance and presentation (aka Anoncreds) > * indy-data-types: Data type definitions for Schemas, Credential Definitions and other types related to credential issuance and processing > * indy-test-utils: Utilities for use in integration tests. > * indy-utils: Standard wrappers around binary data encodings and Ursa-provided cryptography functions. > We'll talk about this briefly on the Indy Contributors call tomorrow (https://wiki.hyperledger.org/display/indy/2021-01-05+Indy+Contributors+Call) Please let us know if you support or object to this contribution.

PatrikStas (Tue, 05 Jan 2021 13:36:22 GMT):
Hi @swcurran @esplinr Can add to today's meeting agenda talking about replacement of Jenkins CI by Github Actions? We as Absa would like to contribute that. I am happy about the initiatives creating separate components as per Stephen's post above, but we would like to help sustain libindy for some longer time - hence we are offering to implement GA CI for IndySDK. I would like to know your opinions about replacement and the scope of the new pipeline.

esplinr (Tue, 05 Jan 2021 13:36:44 GMT):
I think that would be a great addition.

esplinr (Tue, 05 Jan 2021 13:39:29 GMT):
I'm supportive. Thanks for the great contribution!

swcurran (Tue, 05 Jan 2021 14:35:56 GMT):
We'll be talking about CI/CD on the call already -- mostly in the context of Indy Node, but we'll also be talking about the Indy SDK release and happy to include that on the agenda.

rjones (Tue, 05 Jan 2021 15:07:49 GMT):
Let me know how I can help

esplinr (Tue, 05 Jan 2021 16:41:48 GMT):
Thank you for the offer @rjones . It sounds like the team is comfortable at this point with GitHub Actions and how to move forward. We just need to work together more to make progress. We'll let you know if we need additional assistance.

swcurran (Thu, 07 Jan 2021 19:08:14 GMT):
Following the feedback here (no objections) and the discussion on the Indy Contributors call, I think BC Gov can go forward with the contribution of the indy-shared-rs (https://github.com/bcgov/indy-shared-rs) repo to Hyperledger. andrew.whitehead WadeBarnes and rjones --- please go ahead with that as appropriate.

swcurran (Thu, 07 Jan 2021 19:09:47 GMT):
FYI -- @ianco is going to be helping out with the effort to get the indy-node and indy-plenum converted to GitHub Actions and on the first release or two of Indy Node after that.

WadeBarnes (Thu, 07 Jan 2021 19:19:47 GMT):
I've started to bring @ianco up to speed, and @m00sey and I where able to make some progress yesterday and this morning on the indy-node flows.

m00sey (Thu, 07 Jan 2021 19:21:01 GMT):
looks like we might have the first successful build in a while - https://github.com/m00sey/indy-node/actions/runs/469760274 thanks @WadeBarnes for tracking down the issue

rjones (Thu, 07 Jan 2021 19:24:14 GMT):
@WadeBarnes you know how to do the transfer thing for the two repos, when you want to make it happen, LMK

WadeBarnes (Thu, 07 Jan 2021 19:25:58 GMT):
Will do @rjones. I'll start having a look at that first thing in the morning, including making sure the DTO history is complete.

WadeBarnes (Thu, 07 Jan 2021 19:25:58 GMT):
Will do @rjones . I'll start having a look at that first thing in the morning, including making sure the DTO history is complete.

WadeBarnes (Thu, 07 Jan 2021 19:25:58 GMT):
Will do @rjones . I'll start having a look at that first thing in the morning, including making sure the DCO history is complete.

m00sey (Fri, 08 Jan 2021 01:22:35 GMT):
The PR for GHA CI is building again (thanks Wade) https://github.com/hyperledger/indy-node/pull/1622 - The main change from October is that now the test dependency for python3-indy is using the latest version. I think this can be reviewed, approved and merged without the CD aspect.

m00sey (Fri, 08 Jan 2021 01:23:01 GMT):
While we continue to work on CD.

m00sey (Fri, 08 Jan 2021 01:25:23 GMT):
thanks for the additional support

WadeBarnes (Fri, 08 Jan 2021 15:36:47 GMT):
The `bcgov/indy-shared-rs` repository has been transferred to Hyperledger and is now [hyperledger/indy-shared-rs](https://github.com/hyperledger/indy-shared-rs).

jramps9 (Mon, 11 Jan 2021 15:27:14 GMT):
Hello Indy contributors! Reminder to please join the DevRel Marketing Committee call at 9am PT on 1/13 this week. Take a look at the agenda and add items if you'd like here: https://wiki.hyperledger.org/display/Marketing/2021-01-13+Meeting+notes

ianco (Mon, 11 Jan 2021 18:49:26 GMT):
Hi Indy folks, just want to remind everyone we have a release candidate for indy sdk (version is `1.16-rc-170`) available for testing. Release artifacts are all on https://repo.sovrin.org/ Please try to test by Tuesday Jan 19 so we can make a decision on promoting to an official `1.16` release

Toktar (Mon, 11 Jan 2021 21:23:17 GMT):
Happy to join back to you in the new year, I believe it will be productive for us and Indy. I returned to the support of some Indy issues and now available for questions and calls if you need an Indy expertise. @m00sey I'm sorry that I could not quickly find the problem reason of the lost plenum config for GitHub Actions. Did I understand correctly that you have already found the solution? (GitHub Actions look very cute and green) @WadeBarnes Thanks for the victory over the GPG keys, today I built the master for the Libindy. Fantastic, everything works. So if you have any questions about the specifics of an `indy-node` or `indy-plenum` (and a little `indy-sdk`), fill free to ask. I will be really glad to answer for all questions that I can.

Toktar (Mon, 11 Jan 2021 21:23:17 GMT):
Happy to join back to you in the new year, I believe it will be productive for us and Indy. I returned to the support of some Indy issues and now available for questions and calls if you need an Indy expertise. @m00sey I'm sorry that I could not quickly find the problem reason of the lost plenum config for GitHub Actions. Did I understand correctly that you have already found the solution? (GitHub Actions look very cute and green) @WadeBarnes Thanks for the victory over the GPG keys, today I built the master for the Libindy. Fantastic, everything works. So if you have any questions about the specifics of `indy-node` or `indy-plenum` (and a little `indy-sdk`), fill free to ask. I will be really glad to answer for all questions that I can.

mirgee (Wed, 13 Jan 2021 11:37:51 GMT):
Hi everyone! Can somebody with access to 'evernym' or 'sovrin_packaging' accounts on PyPi give me the account credentials / API token, or add me (`mirgee`) as a maintainer of `python3-indy` package, so that we can publish the package as part of the new Github Actions workflow, please?

esplinr (Wed, 13 Jan 2021 15:47:31 GMT):
@Toktar Do you have access for this?

esplinr (Wed, 13 Jan 2021 15:47:31 GMT):
@Toktar Do you have access for this? ^

esplinr (Wed, 13 Jan 2021 15:47:31 GMT):
@Toktar Do you have access for this? :arrow_up:

Toktar (Wed, 13 Jan 2021 15:49:32 GMT):
I don't think that I have this access, but I'll ask @sergey.minaev

sergey.minaev (Wed, 13 Jan 2021 15:53:52 GMT):
I don't have credentials for PyPi. @lynn.bendixsen @MALodder probably have some. Not sure is it the same to Ursa

swcurran (Wed, 13 Jan 2021 16:11:00 GMT):
Sorry to ask, but @mirgee -- who are you? :-) Adding people as maintainers is not something we want to do lightly.

mirgee (Wed, 13 Jan 2021 16:13:41 GMT):
@swcurran I am @PatrikStas's colleague from Absa, we are building the indy workflow which was discussed on the last indy contributors call :)

swcurran (Wed, 13 Jan 2021 16:17:09 GMT):
Got it -- thanks.

esplinr (Wed, 13 Jan 2021 16:21:00 GMT):
Can we get the credentials out of the existing Jenkins pipeline?

lynn.bendixsen (Wed, 13 Jan 2021 17:55:23 GMT):
Sorry, but I don't remember ever getting PyPi credentials. I tried a few things to log in and it looks like I do not have a personal account.

rjones (Wed, 13 Jan 2021 18:58:35 GMT):
Hyperledger owns: ```Your projects (3) python-ursa aries-cloudagent aries-staticagent ``` on pypi

esplinr (Wed, 13 Jan 2021 18:59:02 GMT):
We found the Evernym credentials. I believe that we can use them to grant a different account "Maintainer" access to python3-indy.

rjones (Wed, 13 Jan 2021 18:59:27 GMT):
`https://pypi.org/user/hyperledger/` ?

esplinr (Wed, 13 Jan 2021 18:59:58 GMT):
@rjones That is what I'm thinking. Can @mirgee use that account in the GitHub Actions pipeline?

rjones (Wed, 13 Jan 2021 19:00:36 GMT):
I can generate a token and place it as a secret in a GitHub secret, if you like?

rjones (Wed, 13 Jan 2021 19:01:46 GMT):
which repo needs the secret?

esplinr (Wed, 13 Jan 2021 19:02:49 GMT):
Indy-SDK. @mirgee can confirm details during European business hours tomorrow.

rjones (Wed, 13 Jan 2021 19:03:23 GMT):
OK. If you're able to add `Hyperledger` as a maintainer, please do

esplinr (Wed, 13 Jan 2021 19:03:53 GMT):
Will do.

esplinr (Wed, 13 Jan 2021 19:04:49 GMT):
I assume we should also remove sovrin-packaging as a maintainer. Do you agree @swcurran ?

rjones (Wed, 13 Jan 2021 19:05:40 GMT):
We have a similar situation with `https://pypi.org/project/aries-staticagent/` - @dbluhm owns it, I think, and I have maintainer access

rjones (Wed, 13 Jan 2021 19:06:32 GMT):
actually, looking now, a lot of PyPi seems tied to personal accounts

rjones (Wed, 13 Jan 2021 19:08:17 GMT):
`https://pypi.org/user/cywolf/` `https://pypi.org/user/nbrempel/` and I don't know how many of these will be published by Hyperledger: `https://pypi.org/user/sovrin_packaging/`

esplinr (Wed, 13 Jan 2021 19:46:28 GMT):
"Hyperledger" has a pending invite to take ownership of python3-indy in PyPi. We also removed sovrin-packaging.

esplinr (Wed, 13 Jan 2021 19:47:39 GMT):
Also to indy-node

rjones (Wed, 13 Jan 2021 19:47:57 GMT):
got both

esplinr (Wed, 13 Jan 2021 19:49:48 GMT):
Doing indy-plenum now. There are dev packages for each as well.

esplinr (Wed, 13 Jan 2021 19:49:58 GMT):
Also we'll give you the old indy-crypto and indy-anoncreds packages.

rjones (Wed, 13 Jan 2021 19:50:23 GMT):
OK. fire away.

rjones (Wed, 13 Jan 2021 22:11:03 GMT):
Could I mark this as read-only? https://jira.hyperledger.org/projects/IS/issues I see you use GitHub issues, and I worry people are using JIRA and it's a black hole

andrew.whitehead (Wed, 13 Jan 2021 22:34:31 GMT):
cywolf is me, which packages are you looking at

rjones (Wed, 13 Jan 2021 22:40:49 GMT):
aries-askar and indy-credx: should they be published by/under Hyperledger?

andrew.whitehead (Wed, 13 Jan 2021 22:41:47 GMT):
Yes, probably, but the github pipeline isn't fully set up to produce them yet

andrew.whitehead (Wed, 13 Jan 2021 22:42:14 GMT):
It needs to compile binaries for a few platforms

mirgee (Thu, 14 Jan 2021 07:57:14 GMT):
I am currently testing on my personal fork of `indy-sdk` repo, but will ultimately make a PR to the main repo, so please add the secret there (https://github.com/hyperledger/indy-sdk), and share the secret's name. Thanks :)

sergey.minaev (Thu, 14 Jan 2021 10:30:46 GMT):
I like this idea. What do you think @esplinr @swcurran ?

rjones (Thu, 14 Jan 2021 10:59:03 GMT):
@mirgee what pypi packages will it publish?

rjones (Thu, 14 Jan 2021 11:03:18 GMT):
PYPI_PYTHON3_INDY

esplinr (Thu, 14 Jan 2021 14:28:00 GMT):
Yes. Please do.

esplinr (Thu, 14 Jan 2021 14:28:49 GMT):
Same with https://jira.hyperledger.org/projects/INDY/issues

rjones (Thu, 14 Jan 2021 14:33:41 GMT):
done and done

swcurran (Thu, 14 Jan 2021 16:04:03 GMT):
Agreed and thanks

swcurran (Tue, 19 Jan 2021 03:25:56 GMT):
Hey folks --- the Indy Contributors call is coming up tomorrow - Tuesday January 19, 8AM Pacific, 5PM CET Please join us on the call -- https://wiki.hyperledger.org/display/indy/2021-01-19+Indy+Contributors+Call Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 We'll be talking about: * Status of CI/CD updates for Indy Plenum and Indy Node * Status of upcoming indy-sdk release * Status of CI/CD updates for indy-sdk

esplinr (Tue, 19 Jan 2021 17:08:18 GMT):
@m00sey @Xand Historically, we have released Indy and Sovrin simultaneously, so the documentation on the current branching model is here: https://github.com/sovrin-foundation/sovrin/blob/master/docs/release.md and here: https://github.com/sovrin-foundation/sovrin/blob/master/docs/acceptance.md

esplinr (Tue, 19 Jan 2021 17:08:45 GMT):
It would be good to move the Indy specific stuff into the Indy repos describing the new branching model (releases from tags in Master).

esplinr (Tue, 19 Jan 2021 17:09:11 GMT):
Traditionally, the stable branch was needed to coordinate builds of Indy and the Sovrin Token. But we expect that to go away quickly.

esplinr (Tue, 19 Jan 2021 17:09:11 GMT):
Traditionally, the stable branch was needed to coordinate builds of Indy and the Sovrin Token. But we expect that to go away quickly. And Indy development has slowed, so Master should be more stable.

esplinr (Tue, 19 Jan 2021 17:17:05 GMT):
This is my understanding of the current plan: 1. Create a branch with everything in Master 2. Revert Master back to the last release from Stable 3. Merge everything from Stable into Master 4. Then merge from the branch that used to be Master back into Master This will probably happen over multiple releases. Then going forward, each release will come from Master with a release Tag that could be used to create a branch if needed. Does that match your understanding @WadeBarnes @swcurran ? cc @sergey.minaev

WadeBarnes (Tue, 19 Jan 2021 17:29:16 GMT):
Yes, something like that. To oversimplify, start with a know state and incrementally migrate work into a new `main` branch until all currently accepted features are included.

WadeBarnes (Tue, 19 Jan 2021 17:29:54 GMT):
Then moving forward we only release off the new `main` branch.

swcurran (Tue, 19 Jan 2021 17:31:09 GMT):
I think we still have to a debate about the process. My preference is: 1. Rename Master to Main. 2. Set Main to be the contents of Stable -- identical to the last release of Indy Node (same for plenum). 3. Evolve from there, starting with the Ubuntu upgrade. 4. Only add things from the "old Main" as needed -- e.g. indy-crypto to ursa-crypto. Anything that was not in Stable as of Aug. 30 would have to be re-added as PR.

esplinr (Tue, 19 Jan 2021 17:33:55 GMT):
My biggest concern with this process is that we would mess up the work we have already done in Master. That work is important to us, and we would really struggle contributing if our investments get thrown away.

WadeBarnes (Tue, 19 Jan 2021 17:36:46 GMT):
Agree with both. I think we need to evaluate the differences between stable and master to better understand where are new starting point should be, and at the same time identify all of the work we don't want to loose. In any case we'll make sure to take snapshots (new archive branches) of each existing branch so nothing is lost.

WadeBarnes (Tue, 19 Jan 2021 17:36:46 GMT):
Agree with both. I think we need to further evaluate the differences between stable and master to better understand where are new starting point should be, and at the same time identify all of the work we don't want to loose. In any case we'll make sure to take snapshots (new archive branches) of each existing branch so nothing is lost.

esplinr (Tue, 19 Jan 2021 17:37:20 GMT):
Sounds good.

WadeBarnes (Tue, 19 Jan 2021 17:38:45 GMT):
The desire to start with `stable` as the new base comes from the fact that it is the active release branch. `master` is currently being treated as more of a `develop` branch.

WadeBarnes (Tue, 19 Jan 2021 17:38:45 GMT):
The desire to start with `stable` as the new base comes from the fact that it is the active release branch (known good released code). `master` is currently being treated as more of a `develop` branch.

esplinr (Tue, 19 Jan 2021 17:41:59 GMT):
Thank you for tracking the concern.

WadeBarnes (Tue, 19 Jan 2021 18:31:46 GMT):
[ ](https://chat.hyperledger.org/channel/indy-contributors?msg=R596T2dgCzQe9wjrD) I believe this has caused an issue with the Indy-SDK CD pipleine. @Artemkaaas has the details. Let me know if help is needed to update any credential references in Jenkins.

Artemkaaas (Tue, 19 Jan 2021 18:31:46 GMT):
Has joined the channel.

rjones (Tue, 19 Jan 2021 18:48:41 GMT):
If you look on the page, hyperledger is an owner: https://pypi.org/project/python3-indy/

m00sey (Wed, 20 Jan 2021 01:23:31 GMT):
As per our discussion this morning I reached out to Ry and there are two options for moving the build images from Wade and my's accounts. Create a new namespace under hyperledger github packages and push the images, or push the images to the existing docker hub repo under hyperledger

m00sey (Wed, 20 Jan 2021 01:24:00 GMT):
I prefer the former of the two, it puts the artifacts alongside the repo, instead of indirection to docker hub

m00sey (Wed, 20 Jan 2021 01:24:45 GMT):
I think we'd initially have two artifacts there indy-node-lint and indy-node-build as docker images

m00sey (Wed, 20 Jan 2021 01:24:51 GMT):
(naming is hard)

m00sey (Wed, 20 Jan 2021 01:25:13 GMT):
Asking here if there are objections to pursuing moving these images to github packages

m00sey (Wed, 20 Jan 2021 01:26:11 GMT):
Once CD is complete, we could also package the deb artifacts as well

m00sey (Wed, 20 Jan 2021 01:59:37 GMT):
Regarding stable/master - it sounds like stable should become main, as that represents the last shipped release. master should become "develop" (for want of a better name). We then need a dedicated effort to get the work completed on "master/develop" into stable, especially since it's committed and passing CI. As much as it will annoy @pfeairheller I am raising my hand to work on that effort once CI/CD is complete. I think the only thing that should go into stable before we finish getting "master/develop" merged back in is the 20.04 update and any critical fixes that arise. Once that effort is complete, we remove the "master/develop" branch Happy to partake in any debate.

esplinr (Wed, 20 Jan 2021 18:35:12 GMT):
Thank you for your willingness to do this work!

esplinr (Wed, 20 Jan 2021 18:35:40 GMT):
There might also be some changes needed for deprecating plugins (like the Sovrin token).

andrew.whitehead (Wed, 20 Jan 2021 18:37:46 GMT):
No new releases that still reference `indy-crypto` please

RobinKlemens (Wed, 20 Jan 2021 20:49:59 GMT):
Has joined the channel.

swcurran (Wed, 20 Jan 2021 21:34:13 GMT):
There will be more releases that reference indy-crytpo. We have to go in steps to be safe in what we are doing.

esplinr (Wed, 20 Jan 2021 23:42:47 GMT):
Putting releases using untested and insecure indy-crypto into production is probably more dangerous that upgrading the library and doing adequate testing.

swcurran (Wed, 20 Jan 2021 23:50:13 GMT):
If we had a reliable CI/CD system, and a team of testers, that would be wonderful. We have a piece of working software, and we need to incrementally move from our current state to the desired state. Haven't we talked through this often enough?

esplinr (Wed, 20 Jan 2021 23:51:06 GMT):
> If we had a reliable CI/CD system, and a team of testers, that would be wonderful. The lack of reliable CI/CD system is exactly why I don't have confidence to run mismatched dependencies.

esplinr (Wed, 20 Jan 2021 23:51:57 GMT):
My team has been releasing Indy and deploying to Sovrin for as long as Sovrin has existed. Our uptime is exceptional. I trust their analysis of risk.

swcurran (Wed, 20 Jan 2021 23:52:47 GMT):
But they are no longer working on the project. They are on other projects, so we are trying to move forward.

esplinr (Wed, 20 Jan 2021 23:54:28 GMT):
Renata is on the project. Sergey K has recently joined calls, answered questions, and reviewed the work. Alex and Anton have been on the project since last October. They are all working closely with Vladimir, who has tested the previous releases. We share your goal of a reliable release.

swcurran (Wed, 20 Jan 2021 23:55:31 GMT):
That's great -- are they working on the new CI/CD process? I think that would be the biggest help they could be.

esplinr (Wed, 20 Jan 2021 23:56:58 GMT):
As I have explained, we are answering questions and assisting. We do not have experience with GitHub CI. We are working on the other parts of the project (Indy Crypto to Ursa, Ubuntu upgrade, token removal). Our goal is to remove as much risk in the CI as possible.

swcurran (Wed, 20 Jan 2021 23:57:57 GMT):
So your goals are different from what we are working on. That makes it a challenge.

esplinr (Wed, 20 Jan 2021 23:58:25 GMT):
We share the same goal: a safe and maintainable release.

esplinr (Wed, 20 Jan 2021 23:58:51 GMT):
Our approaches differ, in that we are trying to help in the areas where we can contribute the most.

m00sey (Thu, 21 Jan 2021 00:24:21 GMT):
Your and your teams help has been appreciated @esplinr - Would it help to add @WadeBarnes and myself as maintainers to review and progress the CI/CD stuff? That way the onus is not on your team? I wouldn't say we are experts at GHA but we're trying to make progress and I think between the current maintainers and Wade and myself we can drag this over the finish line. At that point we can debate what happens next, but to be frank it's all moot until we prove we can produce new releases.

esplinr (Thu, 21 Jan 2021 16:37:31 GMT):
I thought that you were already maintainers.

esplinr (Thu, 21 Jan 2021 16:37:48 GMT):
I am completely in favor of you and Wade being maintainers of the repos you have been contributing to.

rjones (Thu, 21 Jan 2021 16:41:58 GMT):
Hi - I think you might be overthinking the branch renaming thing. If you rename `master` to `main` and update your remotes, nothing else changes.

esplinr (Thu, 21 Jan 2021 16:42:05 GMT):
The key reason I bring up what happens next is that I have a team available today to help, and we have been pushing forward. If we can get the 20.04 work done quickly, then you can build a 20.04 environment instead of an 18.04 environment. If we can remove other dependencies (such as the Sovrin token) then we don't have to worry about dependency mismatches.

esplinr (Thu, 21 Jan 2021 16:42:41 GMT):
Changing the name is a minor thing. The main goal is to get Stable and Master / Main synchronized again.

rjones (Thu, 21 Jan 2021 16:42:59 GMT):
gotcha

m00sey (Fri, 22 Jan 2021 01:41:38 GMT):
I have updated PR 1622 to address @WadeBarnes concerns over the images being non-hyperledger repos. The build now includes two additional steps of `build-test-image` and `build-lint-image` which create a hash based of the contents of the appropriate Dockerfile. It then stores that has in the GHA cache, if there is a cache miss, it rebuilds the image and publishes it to GitHub packages otherwise it just pulls the appropriate image from packages. There is no "repo specific" code any more. Full run is here (https://github.com/m00sey/indy-node/actions/runs/502575331) I'd like to get this merged before doing much more on CD as this PR continues to grow in size (and age). Hat tip to @PatrikStas @mirgee for the work on Indy SDK CI, it was very useful. @WadeBarnes we can sync up with regard to porting the changes to plenum. I plan on making one more update (which can be done after 1622 is merged) to remove the dependency on hyperledger base images. The reason to do this is the hash only reflects changes to the top level Dockerfile (in our repo) so any changes to the base images (I'm looking at you 18/20.04 update) wouldn't be picked up, so it seems cleaner to reduce them to one Docker file which contains everything indy-node needs and not impacting anyone else who may be using the base images. As always open to discussion but that's my current plan

m00sey (Fri, 22 Jan 2021 01:41:38 GMT):
I have updated PR 1622 to address @WadeBarnes concerns over the images being non-hyperledger repos. The build now includes two additional steps of `build-test-image` and `build-lint-image` which create a hash based of the contents of the appropriate Dockerfile. It then stores that hash in the GHA cache, if there is a cache miss, it rebuilds the image and publishes it to GitHub packages otherwise it just pulls the appropriate image from packages. There is no "repo specific" code any more. Full run is here (https://github.com/m00sey/indy-node/actions/runs/502575331) I'd like to get this merged before doing much more on CD as this PR continues to grow in size (and age). Hat tip to @PatrikStas @mirgee for the work on Indy SDK CI, it was very useful. @WadeBarnes we can sync up with regard to porting the changes to plenum. I plan on making one more update (which can be done after 1622 is merged) to remove the dependency on hyperledger base images. The reason to do this is the hash only reflects changes to the top level Dockerfile (in our repo) so any changes to the base images (I'm looking at you 18/20.04 update) wouldn't be picked up, so it seems cleaner to reduce them to one Docker file which contains everything indy-node needs and not impacting anyone else who may be using the base images. As always open to discussion but that's my current plan

m00sey (Fri, 22 Jan 2021 21:17:00 GMT):
Just so I don’t interpret this in the wrong way, you mean you have a team working on the 20.04 stuff? Or on the master stable stuff? Either is fantastic

esplinr (Sat, 23 Jan 2021 01:22:28 GMT):
I should have an additional person working on the 20.04 stuff. He will finish his current tasks on Monday and then will start.

esplinr (Sat, 23 Jan 2021 01:28:12 GMT):
Evernym team currently working on Indy / Sovrin: * @Toktar : onboarding the rest of the team, keeping Jenkins running, answering community questions, and working on token removal * @askolesov : writing the HIPE and SIP for token removal, and working on changes to Indy * Anton Denishchenko (who still needs to sign up for this chat) was experimenting with removing tokens from BuilderNet and StagingNet by rewriting history. Now he's helping with the testing of token removal. * Ryan Marsh (who still needs to sign up for this chat): working on upgrade to Ubuntu 20.04 * @vladimir.shishkin will be helping with release testing

esplinr (Sat, 23 Jan 2021 01:29:06 GMT):
All will be able to help for the next few weeks, and then they will move back to other projects.

m00sey (Sat, 23 Jan 2021 01:47:41 GMT):
Would it be fair to ask putting a review of 1622 on toktar and askolesov's plate as well, I think both have looked at it, I'm just trying to determine what it needs to get it merged given it's just the CI portion. Also if there is anyway I could tag along to the onboarding I would be grateful, I appreciate it's an internal team thing but I feel like I am merely skimming the surface of node, and if toktar is taking the time, I can make UTC3 times work :) - if not no worries

esplinr (Mon, 25 Jan 2021 16:50:33 GMT):
I'm in favor of merging. It clearly won't make anything worse!

esplinr (Mon, 25 Jan 2021 16:51:17 GMT):
I'm in favor of both of these proposals.

esplinr (Mon, 25 Jan 2021 16:51:39 GMT):
cc @Toktar

esplinr (Mon, 25 Jan 2021 16:56:13 GMT):
@rmarsh This is the right place to collaborate on your work on Indy Node.

rmarsh (Mon, 25 Jan 2021 16:56:13 GMT):
Has joined the channel.

m00sey (Mon, 25 Jan 2021 16:59:59 GMT):
There is an `acceptance` set of tests in the indy node repo, they are not being executed by the new GHA flow. At first glance I have not seen the docs on how to run them, does anyone know?

esplinr (Mon, 25 Jan 2021 17:06:00 GMT):
I know that there are various tests: unit tests, integration tests, and system tests. Most are in the node and plenum repos, but the system tests are in the indy-test-automation repo.

esplinr (Mon, 25 Jan 2021 17:06:32 GMT):
@vladimir.shishkin provided some documentation here: https://github.com/sovrin-foundation/sovrin/blob/master/docs/acceptance.md

esplinr (Mon, 25 Jan 2021 17:06:52 GMT):
And here: https://github.com/sovrin-foundation/sovrin/blob/master/docs/acceptance.md

esplinr (Mon, 25 Jan 2021 17:09:30 GMT):
@m00sey changing topics to answer your question from deep in another thread: Have you reviewed the following resources for learning Indy Node? An introduction to Indy https://ssimeetup.org/hyperledger-indy-public-blockchain-node-alexander-shcherbakov-webinar-43/ Shorter version https://www.youtube.com/watch?v=ncdvaJrOm_Q&list=PLRp0viTDxBWH2hRisVD6Wij43afXt0FHN&index=3 Blog post on troubleshooting Indy https://www.evernym.com/blog/troubleshooting-an-indy-network/

vladimir.shishkin (Mon, 25 Jan 2021 17:13:43 GMT):
indy-node acceptance folder contains outdated cli batches and one test copied from indy-test-automation, so if you need acceptance tests you should go here: https://github.com/hyperledger/indy-test-automation/tree/master/system

m00sey (Mon, 25 Jan 2021 17:14:15 GMT):
ok excellent, thank you

m00sey (Mon, 25 Jan 2021 17:14:29 GMT):
Would you be opposed to be putting in a PR to remove them?

m00sey (Mon, 25 Jan 2021 17:14:29 GMT):
Would you be opposed to me putting in a PR to remove them, given your reasoning

vladimir.shishkin (Mon, 25 Jan 2021 17:15:44 GMT):
i'm ok with this

m00sey (Mon, 25 Jan 2021 17:18:26 GMT):
I'm not sure that one looks familiar so thanks

rjones (Mon, 25 Jan 2021 18:35:34 GMT):
Hi, the following repos still use `master` as the default branch: `indy-docs, indy-hipe, indy-node, indy-node-monitor, indy-plenum, indy-sdk, indy-shared-rs, indy-test-automation, indy-vdr`. `main` [is the current guidance for naming](https://github.com/github/renaming).

andrew.whitehead (Mon, 25 Jan 2021 19:44:55 GMT):
indy-shared-rs is updated

RobinKlemens (Tue, 26 Jan 2021 16:20:04 GMT):
Hi, I started with the build of Hyperledger Indy and Plenum for Ubuntu 20.04. Regarding Indy, I adjusted `build-scripts/ubuntu-2004` in my repo and it seems to work. However, the installation of Plenum fails because of some dependencies. Can somebody who is more familiar with Plenum than I check if Plenum still relies on all the dependencies below, please? ```The following packages have unmet dependencies: indy-plenum : Depends: python3-ujson (= 1.33-1build1) but it is not going to be installed Depends: python3-prompt-toolkit (= 0.57-1) but 0.57 is to be installed Depends: python3-leveldb but it is not installable Depends: python3-pip (< 10.0.0) but it is not going to be installed Depends: python3-msgpack (= 0.4.6-1build1) but it is not going to be installed``` https://github.com/udosson/indy-plenum/tree/master/build-scripts/ubuntu-2004 https://github.com/udosson/indy-node/tree/master/build-scripts/ubuntu-2004

RobinKlemens (Tue, 26 Jan 2021 16:20:04 GMT):
Hi, I started with the build of Hyperledger Indy and Plenum for Ubuntu 20.04. Regarding Indy, I adjusted `build-scripts/ubuntu-2004` in my repo and it seems to work. However, the installation of Plenum fails because of some dependencies. Can somebody check if Plenum stills relies on all the dependencies below? ```The following packages have unmet dependencies: indy-plenum : Depends: python3-ujson (= 1.33-1build1) but it is not going to be installed Depends: python3-prompt-toolkit (= 0.57-1) but 0.57 is to be installed Depends: python3-leveldb but it is not installable Depends: python3-pip (< 10.0.0) but it is not going to be installed Depends: python3-msgpack (= 0.4.6-1build1) but it is not going to be installed``` https://github.com/udosson/indy-plenum/tree/master/build-scripts/ubuntu-2004 https://github.com/udosson/indy-node/tree/master/build-scripts/ubuntu-2004

RobinKlemens (Tue, 26 Jan 2021 16:20:04 GMT):
Hi, I started with the build of Hyperledger Indy and Plenum for Ubuntu 20.04. Regarding Indy, I adjusted `build-scripts/ubuntu-2004` in my repo and it seems to work. However, the installation of Plenum fails because of some dependencies. Can somebody check if Plenum still relies on all the dependencies below? ```The following packages have unmet dependencies: indy-plenum : Depends: python3-ujson (= 1.33-1build1) but it is not going to be installed Depends: python3-prompt-toolkit (= 0.57-1) but 0.57 is to be installed Depends: python3-leveldb but it is not installable Depends: python3-pip (< 10.0.0) but it is not going to be installed Depends: python3-msgpack (= 0.4.6-1build1) but it is not going to be installed``` https://github.com/udosson/indy-plenum/tree/master/build-scripts/ubuntu-2004 https://github.com/udosson/indy-node/tree/master/build-scripts/ubuntu-2004

swcurran (Tue, 26 Jan 2021 16:30:25 GMT):
This is a bit of hot topic within the community -- we'd love to have help if you are available. We are trying to move to a CI/CD system (GHA) that is not dependent on tribal knowledge that no longer exists in the community. The goal is to do that first on the currently 16.04 and then when we have that, use the newly "trusted" CI/CD to upgrade to either Ubuntu 18.04 or 20.04.

swcurran (Tue, 26 Jan 2021 16:30:49 GMT):
At this point, neither are supported, and the work to upgrade them has not been completed.

rjones (Tue, 26 Jan 2021 17:13:07 GMT):
Hi - does anyone know if this [travel passport](https://www.explica.co/airlines-to-resume-flights-in-march-with-blockchain-based-passport/) is using Indy, or is it just that Sovrin worked on Indy, so it was mentioned in passing?

rjones (Tue, 26 Jan 2021 17:13:07 GMT):
Hi - does anyone know if this [travel passport](https://www.explica.co/airlines-to-resume-flights-in-march-with-blockchain-based-passport/) is using Indy, or is it just that Evernym worked on Indy, so it was mentioned in passing?

ianco (Tue, 26 Jan 2021 17:21:00 GMT):
It mentions Evernym specifically

rjones (Tue, 26 Jan 2021 17:29:04 GMT):
Thanks, fixed.

m00sey (Tue, 26 Jan 2021 20:04:36 GMT):
@esplinr mentioned that @rmarsh was loooking into 20.04 as well, he might have come across this or have insight?

m00sey (Tue, 26 Jan 2021 20:30:32 GMT):
Looking at the pending CI/CD PRs for node/plenum, should the destination be `stable` as opposed to `master`?

m00sey (Tue, 26 Jan 2021 20:30:49 GMT):
Given master is the home of things like the ursa update?

rjones (Tue, 26 Jan 2021 20:43:47 GMT):
@m00sey given this: maybe main? https://chat.hyperledger.org/channel/indy-contributors?msg=rsieZpMM5NLdYbARC

m00sey (Tue, 26 Jan 2021 21:38:40 GMT):
@rjones we currently have both stable and master in indy-node, but no `main` yet - master has diverged and is ahead of stable, we're looking to resolve this in the near future, then we can make a switch to `main` naming

esplinr (Tue, 26 Jan 2021 23:02:58 GMT):
@swcurran and @m00sey : @RobinKlemens had volunteered to help with the Ubuntu upgrade.

esplinr (Tue, 26 Jan 2021 23:02:58 GMT):
@swcurran and @m00sey , you can see in the channel history that @RobinKlemens had volunteered to help with the Ubuntu upgrade.

esplinr (Tue, 26 Jan 2021 23:02:58 GMT):
@swcurran and @m00sey , @RobinKlemens had volunteered to help with the Ubuntu upgrade.

esplinr (Tue, 26 Jan 2021 23:03:30 GMT):
@RobinKlemens Figuring out which of those dependencies is required in Ubuntu 20.04 is the work that needs to happen. @rmarsh will also be helping.

esplinr (Tue, 26 Jan 2021 23:03:55 GMT):
@RobinKlemens What timezone are you in? Are you available for a conversation tomorrow where I can give you more guidance?

esplinr (Tue, 26 Jan 2021 23:07:22 GMT):
That is the project that has been keeping us so busy!

esplinr (Tue, 26 Jan 2021 23:08:25 GMT):
I think either way would work.

esplinr (Tue, 26 Jan 2021 23:12:30 GMT):
Based on your GitHub profile, I'm guessing Berlin. I'm available at the following times in Berlin: 3:30PM or after 4:30PM.

esplinr (Tue, 26 Jan 2021 23:15:54 GMT):
Also, see this comment for next steps: https://github.com/hyperledger/indy-node/pull/1443#issuecomment-529800628

esplinr (Tue, 26 Jan 2021 23:15:54 GMT):
Also, see this comment for a brief explanation: https://github.com/hyperledger/indy-node/pull/1443#issuecomment-529800628

esplinr (Tue, 26 Jan 2021 23:17:24 GMT):
Here is an Indy HIPE that describes the changes we discussed in the last few Indy Contributors calls: https://github.com/hyperledger/indy-hipe/pull/162 For context, the motivation is in this Sovrin SIP: https://github.com/sovrin-foundation/sovrin-sip/pull/28

esplinr (Tue, 26 Jan 2021 23:17:36 GMT):
We would appreciate any feedback people have.

rjones (Tue, 26 Jan 2021 23:58:23 GMT):
Nice!

RobinKlemens (Wed, 27 Jan 2021 08:26:34 GMT):
@esplinr thank you very much for your response. I'm also available at 04:30 PM CET.

esplinr (Wed, 27 Jan 2021 14:09:11 GMT):
Perfect.

esplinr (Wed, 27 Jan 2021 14:09:55 GMT):
If anyone is interested in discussing the upgrade of Indy Node to Ubuntu 20.04, we will be meeting at 4:30 CET / 7:30 US Pacific. Let me know and I'll add you to the meeting invite so you get the Zoom link.

esplinr (Wed, 27 Jan 2021 14:09:55 GMT):
If anyone is interested in discussing the upgrade of Indy Node to Ubuntu 20.04, we will be meeting at 17 CET / 8 US Pacific. Let me know and I'll add you to the meeting invite so you get the Zoom link.

m00sey (Wed, 27 Jan 2021 15:26:24 GMT):
Yes please

esplinr (Wed, 27 Jan 2021 16:22:42 GMT):
Useful information: * https://github.com/sovrin-foundation/sovrin/blob/master/docs/acceptance.md * https://github.com/sovrin-foundation/sovrin/blob/master/docs/release.md

m00sey (Wed, 27 Jan 2021 18:05:59 GMT):
@RobinKlemens am I correct in thinking you got everything you needed to run the tests from our call?

RobinKlemens (Wed, 27 Jan 2021 18:12:45 GMT):
At the moment I'm good with getting `init_indy_node` working on Ubuntu 20.04 and don't need further testing. I run into an error with rocksdb. @esplinr is there a reason why the repo of evernym is referenced as the source of rocksdb instead of the original repo in the build-scripts of plenum for Ubuntu 16.04? I switched to the repo of facebook and updated the version of rocksdb.

RobinKlemens (Wed, 27 Jan 2021 18:12:45 GMT):
At the moment I'm good with getting `init_indy_node` working on Ubuntu 20.04 and don't need further testing. I run into an error with rocksdb. @esplinr is there a reason why the Ubuntu 16.04 of plenum uses the repo of evernym instead of the original repo? I switch to the repo of facebook and updated the version of rocksdb.

RobinKlemens (Wed, 27 Jan 2021 18:12:45 GMT):
At the moment I'm good with getting `init_indy_node` working on Ubuntu 20.04 and don't need further testing. I run into an error with rocksdb. @esplinr is there a reason why the repo of evernym is referenced as the source of rocksdb instead of the original repo in the build-scripts of plenum for Ubuntu 16.04? I switch to the repo of facebook and updated the version of rocksdb.

esplinr (Wed, 27 Jan 2021 19:46:21 GMT):
When we switched to RocksDB, we needed a version newer than was available in Ubuntu. See: https://jira.hyperledger.org/browse/INDY-1205?focusedCommentId=42197&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-42197

rmarsh (Thu, 28 Jan 2021 22:09:50 GMT):
@RobinKlemens what is your status on ubuntu 20.04 upgrade of indy-node? I've looked at your branch and see a lot of progress. What dependencies are you currently tracking down?

RobinKlemens (Fri, 29 Jan 2021 14:40:41 GMT):
I started with building the deb packages on Ubuntu 20.04 and installing them as well. Then I run `init_indy_node` which worked. However, when I start a pool of nodes with `start_indy_node` all nodes but one crash because of an error message which I think is caused by pyzmq. ```File "/usr/local/lib/python3.8/dist-packages/stp_zmq/zstack.py", line 866, in serializeMsg msg = json.dumps(msg) TypeError: LEDGER_STATUS{'ledgerId': 3, 'txnSeqNo': 0, 'viewNo': None, 'ppSeqNo': None, 'merkleRoot': 'GKot5hBsd81kMupNCXHaqbhv3huEbxAFMLnpcX2hniwn', 'protocolVersion': 2} is not JSON serializable``` But this was more of getting familiar with the build process as I'm not a python developer in haven't worked with fpm before. What I want to do now is to test Plenum on Ubuntu 20.04. But I don't know yet what is the best way to do this. I built a Docker image based on Ubuntu 20.04, added some packages, and run the tests inside the container. The tests of common, state, and ledger work but plenum tests have many errors. Would this be the way to go to test the code on Ubuntu 20.04? I'm asking because the tests of the plenum dir depend on indy which I imported via `pip install python3-indy`. Could this cause the errors because python3-indy isn't tested on Ubuntu 20.04? I appreciate any recommendation and guidance. Thx /robin

rmarsh (Fri, 29 Jan 2021 15:02:03 GMT):
This sounds like great progress. I am also becoming familiar with this environment so I will find more answers and get back to you. I setup an environment on 16.04 to become more familiar with the process. My experience with plenum is that the `plenum` directory of tests fail when run all together. I went through individually and tested the failing tests and saw them pass. @Toktar may be able to explain this in better detail than me. She mentioned to me that "there are so many tests and they require so many resources that when you run all of them at once, problems may arise due to the overload of the OS".

rmarsh (Fri, 29 Jan 2021 15:02:03 GMT):
This sounds like great progress. I am also becoming familiar with this environment so I will find more answers and get back to you. I setup an environment on 16.04 to become more familiar with the process. My experience with plenum is that the `plenum` directory of tests has some failures when run all together. I went through individually and tested the failing tests and saw them pass. @Toktar may be able to explain this in better detail than me. She mentioned to me that "there are so many tests and they require so many resources that when you run all of them at once, problems may arise due to the overload of the OS".

rmarsh (Fri, 29 Jan 2021 15:02:03 GMT):
This sounds like great progress. I am also becoming familiar with this environment so I will find more answers and get back to you. I setup an environment on 16.04 to become more familiar with the process. My experience with plenum is that the `plenum` directory of tests has some failures when run all together. I went through individually and tested the failing tests and saw them pass. @Toktar may be able to explain this in better detail than me. She mentioned to me that "there are so many tests and they require so many resources that when you run all of them at once, problems may arise due to the overload of the OS". I will look at your docker environment and see if the failing tests look consistent with what I saw on my 16.04 environment. I will update you with my stauts.

Toktar (Fri, 29 Jan 2021 15:15:48 GMT):
@RobinKlemens `python3-indy` it's a Libindy (from indy-sdk) python wrapper. /usr/lib/libindy.so - the main library. It was tested with ubuntu 18, but never with ubuntu 20. I guess there are needs some manipulation with libsodium18 for the correct Libindy work. @rmarsh Libindy definitely works with Ubuntu 18, so there shouldn't be any difficulties

rmarsh (Fri, 29 Jan 2021 15:32:35 GMT):
@Toktar I may need some clarification. Let me repeat to make sure I understand. 1. We have an expectation that the libindy that worked on 18.04 should work fine on 20.04 if libsodium18 has some changes to it? 2. This fix is to fix the failing node problem not the plenum tests? Is this correct?

Toktar (Sun, 31 Jan 2021 16:17:30 GMT):
@rmarsh 1. Absolutely correct. 2. Technically, the plenum integration tests use the libindy to connect to the pool. But if there are any problems with Libsodium18 or python-indy, I suggest solving them first by looking at the wrapper packages and libindy library.

rmarsh (Mon, 01 Feb 2021 01:57:45 GMT):
@RobinKlemens I spent time trying to build on a 20.04 VM following the docker file you have on your branch. I am running into some python build errors and will look more into it tomorrow. My goal is to get all python tests passing on 20.04. @Toktar thank you for the info. I will take that into consideration when dealing with the integration tests.

swcurran (Mon, 01 Feb 2021 17:57:55 GMT):
Hey folks --- the Indy Contributors call is coming up tomorrow - Tuesday February 2, 8AM Pacific, 5PM CET Please join us on the call -- https://wiki.hyperledger.org/display/indy/2021-02-02+Indy+Contributors+Call Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 We'll be talking about: - Status of indy-node CI/CD and Ubuntu upgrade - Status of upcoming indy-sdk release and follow up issues - Hyperledger help toward adding contributors - HIPEs for plugin helpers

esplinr (Mon, 01 Feb 2021 18:17:13 GMT):
I'm looking forward to the call!

RobinKlemens (Mon, 01 Feb 2021 18:24:37 GMT):
Hi everybody. I adjusted the GitHub Actions of Wade's pull request to Plenum to run on Ubuntu 18.04. The tests of the following directories fail: - plenum - crypto Link to GitHub Action Pipeline: https://github.com/udosson/indy-plenum/actions/runs/528497772 Link to the Docker file I use: https://github.com/udosson/indy-plenum/blob/ubuntu18.04/ci/ubuntu-1804/Dockerfile It'd be great if someone who is familiar with Plenum could check the failed tests. Thanks a lot! See you tomorrow Robin

WadeBarnes (Mon, 01 Feb 2021 18:53:12 GMT):
@RobinKlemens, There are addition inbound changes to that PR.

WadeBarnes (Mon, 01 Feb 2021 18:54:08 GMT):
I'll let you know when they get merged.

WadeBarnes (Mon, 01 Feb 2021 18:55:27 GMT):
Currently here; https://github.com/WadeBarnes/indy-plenum/pull/1

esplinr (Mon, 01 Feb 2021 19:37:52 GMT):
indy-crypto fails because it has been replaced with Ursa in a PR in Master.

esplinr (Mon, 01 Feb 2021 19:37:52 GMT):
It might be unrelated to the crypto tests, but there is a PR in Master that replaces indy-crypto with Ursa. That might address some of the failed tests.

RobinKlemens (Tue, 02 Feb 2021 13:56:29 GMT):
I could found what caused the error. The error message was `OSError: libursa.so: cannot open shared object file: No such file or directory` Plenum looks for libursa.so in /usr/lib. After installing Ursa from `deb https://repo.sovrin.org/deb bionic master`, /usr/lib looks as follows ```ls /usr/lib apt dbus-1.0 gcc gnupg2 librocksdb.a librocksdb.so.5.8 libsqlite.so.0.8.6 openssh python3.6 sasl2 sysusers.d ursa bfd-plugins dpkg git-core gold-ld librocksdb.so librocksdb.so.5.8.8 locale os-release python3.7 ssl tar valgrind compat-ld file gnupg libindy.so librocksdb.so.5 libsqlite.so.0 mime python3 python3.8 systemd tmpfiles.d x86_64-linux-gnu``` libursa.so is, as the error message states, missing. However, libursa.so is there but not where Plenum is looking for it. ```ls /usr/lib/ursa libursa.a libursa.so``` Moving libursa.so and libursa.a to their parent dir (/usr/lib) fixed the error. Should we reach out to the Ursa community so they can fix the output path of the deb package?

RobinKlemens (Tue, 02 Feb 2021 13:56:36 GMT):
thx :)

esplinr (Tue, 02 Feb 2021 17:10:41 GMT):
@lynn.bendixsen Thank you for the feedback on the HIPE. The first section was not clear about dropping ledgers being optional. I believe it's better now. Thank you again. @swcurran I added a comment with links to the PRs that implement the functionality discussed

esplinr (Tue, 02 Feb 2021 17:11:32 GMT):
We need someone with write access to Indy Node and Indy Plenum to create the branches where @rmarsh , @RobinKlemens , and others can work on the Ubuntu upgrade. @WadeBarnes can you do that?

WadeBarnes (Tue, 02 Feb 2021 17:58:16 GMT):
I'll have a look at that between meetings.

WadeBarnes (Tue, 02 Feb 2021 18:36:45 GMT):
@rmarsh, @RobinKlemens https://github.com/hyperledger/indy-node/tree/ubuntu-20.04-upgrade https://github.com/hyperledger/indy-plenum/tree/ubuntu-20.04-upgrade

esplinr (Wed, 03 Feb 2021 05:02:36 GMT):
During today's Indy Contributors call, @WadeBarnes suggested we have a separate meeting to continue collaborating on the next Indy release and the upgrade to Ubunut 20. After asking a number of the interested parties, I scheduled the meeting for Thursday, February 4, at 6AM Pacific / 3PM CET. This is the Zoom link: https://zoom.us/j/8018550866 I can add you to the calendar appointment if you want to be included.

rjones (Wed, 03 Feb 2021 12:13:16 GMT):
yes please

WadeBarnes (Wed, 03 Feb 2021 16:51:31 GMT):
The PR has been updated; https://github.com/hyperledger/indy-plenum/pull/1505

esplinr (Thu, 04 Feb 2021 05:07:58 GMT):
A place to keep notes for tomorrow's meeting: https://wiki.hyperledger.org/display/indy/2021-02-04+Special%3A+Upgrade+Indy

esplinr (Thu, 04 Feb 2021 16:59:59 GMT):
@WadeBarnes This is the issue with catchup that we were tracking: https://github.com/hyperledger/indy-plenum/issues/1490 @Toktar @sergey.khoroshavin Wade says that he recently did a catch up from an empty ledger and it worked (though it went really slowly).

rjones (Thu, 04 Feb 2021 19:58:14 GMT):
@mirgee - I rebased https://github.com/hyperledger/indy-sdk/pull/2354 and the build failed due to disk space

rjones (Thu, 04 Feb 2021 19:59:32 GMT):
Also, https://github.com/hyperledger/indy-sdk/actions/runs/538146398 is _super cool_

esplinr (Thu, 04 Feb 2021 23:30:41 GMT):
:arrow_up: @PatrikStas

swcurran (Fri, 05 Feb 2021 00:52:53 GMT):
The Indy TSC Quarterly report was due and I created this -- https://wiki.hyperledger.org/display/TSC/2021+Q1+Hyperledger+Indy. Please review and correct/add to asap, as the TSC members will be reviewing it in the next few days.

m00sey (Fri, 05 Feb 2021 01:19:45 GMT):
Yeah that's a really nice piece of work

m00sey (Fri, 05 Feb 2021 01:44:30 GMT):
I think it is a fair evaluation

m00sey (Fri, 05 Feb 2021 01:45:29 GMT):
would love to see on the report "we finished the CI/CD" conversion :)

m00sey (Fri, 05 Feb 2021 01:45:29 GMT):
would love to see on the next report "we finished the CI/CD" conversion :)

rmarsh (Fri, 05 Feb 2021 03:44:15 GMT):
@RobinKlemens I have an environment setup on Ubuntu 20.04 with what seems like all of the necessary dependencies. I am running into different python3.8 test failures which I'm working through now. I should have an idea of the work needed to get all tests passing and a basic list of all the dependencies by tomorrow. @esplinr FYI.

RobinKlemens (Fri, 05 Feb 2021 14:29:32 GMT):
@rmarsh great news! Can you share the link to your GitHub repository, please? I build a Docker image which has all the necessary packages installed to run the test. https://github.com/udosson/indy-plenum/blob/ubuntu18.04/ci/ubuntu-2004/Dockerfile I saw in the notes of yesterday's call that you and Brent have already started with the Python3.8 upgrade. What is the current state of this? Did you start with Indy and Plenum?

RobinKlemens (Fri, 05 Feb 2021 14:43:39 GMT):
Hi @WadeBarnes , would you suggest creating a second workflow in GitHub Actions for the Ubuntu 20.04 upgrade that is similar to your pr? I suggest having one GHA pipeline for ci testing on Ubuntu 16.04 which gets triggered by any push and pr to master/main branch and a second pipeline that gets only triggered by push and pr to ubuntu 20.04 branch. The ubuntu 20.04 pipeline would checkout the ubuntu 20.04 branch and use a Docker container that is based on Ubuntu 20.04.

WadeBarnes (Fri, 05 Feb 2021 15:04:38 GMT):
Since many of the steps are going to be basically the same, it would be nice if we could have just the one workflow that changes it's behavior based on the branch. That way we don't have to maintain two completely different files that are basically identical, and the one file would evolve into the final 20.04 version at one stage. Thoughts?

WadeBarnes (Fri, 05 Feb 2021 15:36:33 GMT):
Agreed

rmarsh (Fri, 05 Feb 2021 15:52:45 GMT):
@RobinKlemens I just created a WIP PR against indy-plenum: https://github.com/hyperledger/indy-plenum/pull/1508

rmarsh (Fri, 05 Feb 2021 15:54:19 GMT):
I am making my way through the unit tests right now. I am finding a few failures. The document I attached is meant mostly to track my progress. Most of my work is exploratory. I will add some other details I've collected by this afternoon. My main two tasks right now are: 1. Find all failing tests and hopefully fix. 2. Start upgrading the dependencies. I initially installed the minimum versions to get tests to run. My next step is to look at the dependencies in your Dockerfile and start upgrading my 20.04 machine.

swcurran (Fri, 05 Feb 2021 16:38:10 GMT):
Amen!

m00sey (Fri, 05 Feb 2021 16:41:28 GMT):
This is very exciting

m00sey (Fri, 05 Feb 2021 21:29:31 GMT):
Hello, I reviewed @Toktar 's comments and will be creating a new PR for Indy Node CI. I did not fully understand the work that had gone in to parallizing the build with `runner.py`. For some reason I convinced myself that was the windows runner, I have no idea why. The new PR is much more concise and removes all the `@pytest.mark` annotations. It also removes the rewrites of some tests that were of concern in my original PR. The main change is in build.yaml which now includes slices in the matrix. Successful builds can be seen here - https://github.com/m00sey/indy-node/actions/runs/541634133 I picked 11 slices after some trial and error for times.

m00sey (Fri, 05 Feb 2021 21:42:13 GMT):
The new PR is here https://github.com/hyperledger/indy-node/pull/1645

m00sey (Fri, 05 Feb 2021 21:43:07 GMT):
Given it's limited changes I consider the work "done" and reviewing shouldn't take long

m00sey (Fri, 05 Feb 2021 22:03:29 GMT):
I moved the original PR to draft, but in my opinion it should be closed, and 1645 reviewed

WadeBarnes (Fri, 05 Feb 2021 23:14:43 GMT):
@rmarsh, I missed the WIP part and was trying to be helpful by merging your PR.

WadeBarnes (Fri, 05 Feb 2021 23:15:48 GMT):
I'd recommend opening a Draft PR for Works in Progress, it makes it crystal clear the PR is a WIP.

WadeBarnes (Fri, 05 Feb 2021 23:17:22 GMT):
Example; https://github.com/hyperledger/indy-plenum/pull/1505

WadeBarnes (Fri, 05 Feb 2021 23:20:30 GMT):
The option is available when creating a PR though GitHub:

WadeBarnes (Fri, 05 Feb 2021 23:20:32 GMT):

Clipboard - February 5, 2021 3:19 PM

WadeBarnes (Fri, 05 Feb 2021 23:22:40 GMT):
Or afterward on the PR itself, you have the option of converting it to a draft.

WadeBarnes (Sun, 07 Feb 2021 19:51:24 GMT):
Additional updates; https://github.com/hyperledger/indy-plenum/pull/1505

jramps9 (Mon, 08 Feb 2021 15:14:50 GMT):
Hello Indy contributors! Reminder to please join the DevRel Marketing Committee call at 9am PT on 2/10 this week. Take a look at the agenda and add items if you'd like here: https://wiki.hyperledger.org/display/Marketing/2021-02-10+Meeting+notes

rmarsh (Mon, 08 Feb 2021 17:38:59 GMT):
@WadeBarnes Thank you for your help! I appreciate you being so active with it. I will do a draft PR from now on.

RobinKlemens (Tue, 09 Feb 2021 09:29:14 GMT):
True, many of the steps are going to be identically the same.

RobinKlemens (Tue, 09 Feb 2021 09:29:14 GMT):
True, many of the steps are going to be identically the same. For me, it is the separation of concern and simplicity of the pipelines vs. maintaining one pipeline (to rule them all). If going with your proposed solution, I suggest the following: - create build second build dir (build-u1604 and build-u2004) or name dockerfiles in one build dir accordingly - same goes for lint - in build.yaml: -- Extend the event section at the beginning with the ubuntu-20.04-upgrade branch -- Add a Docker image tag variable as output to workflow-setup and set the variable depending on the event that triggered the workflow -- Use image tag variable correspondingly in following steps to reference the correct setup Example of image tag in workflow setup: ```- name: Set image tag id: image_tag run: | if [[ "${{github.base_ref}}" == "master" || "${{github.ref}}" == "refs/heads/master" ]]; then echo "::set-output name=docker_image_tag::u1604" fi if [[ "${{github.base_ref}}" == "ubuntu-20.04-upgrade" || "${{github.ref}}" == "refs/heads/ubuntu-20.04-upgrade" ]]; then echo "::set-output name=docker_image_tag::u2004" fi```

RobinKlemens (Tue, 09 Feb 2021 09:29:14 GMT):
True, many of the steps are going to be identically the same. For me, it is the separation of concern and simplicity of the pipelines vs. maintaining one pipeline (to rule them all). If going with your proposed solution, I suggest the following: * create build second build dir (build-u1604 and build-u2004) or name dockerfiles in one build dir accordingly * same goes for lint * in build.yaml * Extend the event section at the beginning with the ubuntu-20.04-upgrade branch * Add a Docker image tag variable as output to workflow-setup and set the variable depending on the event that triggered the workflow * Use image tag variable correspondingly in following steps to reference the correct setup Example of image tag in workflow setup: ```- name: Set image tag id: image_tag run: | if [[ "${{github.base_ref}}" == "master" || "${{github.ref}}" == "refs/heads/master" ]]; then echo "::set-output name=docker_image_tag::u1604" fi if [[ "${{github.base_ref}}" == "ubuntu-20.04-upgrade" || "${{github.ref}}" == "refs/heads/ubuntu-20.04-upgrade" ]]; then echo "::set-output name=docker_image_tag::u2004" fi```

RobinKlemens (Tue, 09 Feb 2021 09:29:14 GMT):
True, many of the steps are going to be identically the same. For me, it is the separation of concern and simplicity of the pipelines vs. maintaining one pipeline (to rule them all). If going with your proposed solution, I suggest the following: - create build second build dir (build-u1604 and build-u2004) or name dockerfiles in one build dir accordingly - same goes for lint - in build.yaml - Extend the event section at the beginning with the ubuntu-20.04-upgrade branch - Add a Docker image tag variable as output to workflow-setup and set the variable depending on the event that triggered the workflow - Use image tag variable correspondingly in following steps to reference the correct setup Example of image tag in workflow setup: ```- name: Set image tag id: image_tag run: | if [[ "${{github.base_ref}}" == "master" || "${{github.ref}}" == "refs/heads/master" ]]; then echo "::set-output name=docker_image_tag::u1604" fi if [[ "${{github.base_ref}}" == "ubuntu-20.04-upgrade" || "${{github.ref}}" == "refs/heads/ubuntu-20.04-upgrade" ]]; then echo "::set-output name=docker_image_tag::u2004" fi```

WadeBarnes (Tue, 09 Feb 2021 14:54:50 GMT):
I'd actual consider a matrix approach to separate the concerns in a single workflow. You could define an `os` matrix containing an id for `ubuntu-16.04` and `ubuntu-20.04`. Those IDs could then be used in the jobs/steps to reference the specific `ubuntu-16.04` and `ubuntu-20.04` resources/scripts/images automagically.

WadeBarnes (Tue, 09 Feb 2021 14:56:38 GMT):
Then once we're done with `ubuntu-16.04` we simply remove the matrix entry and any `ubuntu-16.04` resources/scripts/images. This also sets up the pattern for supporting the next upgrade.

WadeBarnes (Tue, 09 Feb 2021 14:56:38 GMT):
Then once we're done with `ubuntu-16.04` we simply remove the matrix entry and any `ubuntu-16.04` specific resources/scripts/images. This also sets up the pattern for supporting the next upgrade.

WadeBarnes (Tue, 09 Feb 2021 15:03:12 GMT):
Images could use the matrix id for their tag. OS specific resources/scripts are perhaps best organized into folders using the matrix IDs as names. All common resources/scripts would be either at the same level as the OS specific folders or in their own common flder.

WadeBarnes (Tue, 09 Feb 2021 15:08:29 GMT):
Or, since we're currently performing this work on a separate branch, we do the `${{github.base_ref}}` detection like you have above, once, in a workflow setup step and set a os id variable that could be used similar to how I described the use of the matrix ids.

WadeBarnes (Tue, 09 Feb 2021 15:08:29 GMT):
Or, since we're currently performing this work on a separate branch, we do the `${{github.base_ref}}` detection like you have above, once, in a workflow setup step and set an os id variable that could be used similar to how I described the use of the matrix ids.

WadeBarnes (Tue, 09 Feb 2021 15:11:52 GMT):
I think we may be talking about the same thing.

RobinKlemens (Tue, 09 Feb 2021 17:20:42 GMT):
Thanks for sharing your thoughts. Yes, I think we are on the same boat. In short: - 1 workflow - event triggers based on master and ubuntu 20.04 branch - based on event we set on variable (e.g., OS=u1604 or OS=2004) - we use a naming conventing with the variable that either sets up and executes everything for Ubuntu 16.04 or 20.04

WadeBarnes (Tue, 09 Feb 2021 17:24:39 GMT):
For the values used with the variables, I'd use `ubuntu-16.04` and `ubuntu-20.04` rather than abbreviations if possible.

RobinKlemens (Tue, 09 Feb 2021 17:25:05 GMT):
sure, we can do

RobinKlemens (Tue, 09 Feb 2021 17:25:29 GMT):
I'd kind of follow this approach https://stackoverflow.com/questions/63117454/how-to-set-workflow-env-variables-depending-on-branch

WadeBarnes (Tue, 09 Feb 2021 17:30:11 GMT):
Using the same approach in `workflow-setup` in the plenum workflow.

WadeBarnes (Tue, 09 Feb 2021 17:30:11 GMT):
Using the same approach in `workflow-setup` in the plenum workflow to set variables used in later jobs.

RobinKlemens (Tue, 09 Feb 2021 18:13:58 GMT):
Yes. I would just extend that `workflow-setup` section accordingly

rmarsh (Wed, 10 Feb 2021 00:31:54 GMT):
@RobinKlemens I am still working through these tests that broke when I upgraded the dependencies. I'm getting much closer to having all tests pass. The current work I've done is to upgrade `rlp` and fix the code references to deprecated methods.

rmarsh (Wed, 10 Feb 2021 00:45:47 GMT):
Here is my current `Draft PR` https://github.com/hyperledger/indy-plenum/pull/1509

RobinKlemens (Wed, 10 Feb 2021 12:39:40 GMT):
@rmarsh I see you're doing great progress!! Could you successfully run the tests in Ubuntu 20.04 without upgrading the dependencies? I'm still looking for a way how we could best work together. Do you have any suggestions?

rmarsh (Wed, 10 Feb 2021 16:13:33 GMT):
@RobinKlemens I did get all the tests passing without upgrading the dependencies. I had to make a few small code changes because of python3.8. I will be better at giving specific dependencies I'm having trouble with to see if you could look into it in your day. I will have an update by 5pm MST. There are two main things that come to mind now. 1. Where to we stand with CI / CD? Did @m00sey finish it completely? I've been heads down so I haven't kept up on the status like I should have. 2. Why is the project pinned to a `pip` version less that 10? I have seen the pin and heard people mention it but haven't looked into it myself. @RobinKlemens Could you look into this?

m00sey (Wed, 10 Feb 2021 17:17:07 GMT):
@rmarsh So Indy node CI merged, Indy plenum CI is pending

m00sey (Wed, 10 Feb 2021 17:17:17 GMT):
@ianco was doing some work on plenum CD

m00sey (Wed, 10 Feb 2021 17:17:48 GMT):
I have a branch for node CD (somewhere) that was looking at running the system tests from `indy-test-automation`

m00sey (Wed, 10 Feb 2021 17:18:16 GMT):
I have been pulled off onto other things, but I will try get that branch pushed this week, if only for a reference point

ianco (Wed, 10 Feb 2021 17:45:24 GMT):
plenum CD stuff is done (I posted a link yesterday), waiting for wade's CI PR to be merged before I PR the CD (it's in the same build script)

WadeBarnes (Wed, 10 Feb 2021 17:47:11 GMT):
I just finished working through some configuration with Ry on the indy-node workflows.

rmarsh (Wed, 10 Feb 2021 22:12:17 GMT):
@Toktar I'm working on the 20.04 upgrade of indy-node. I am having an issue with the `pool_restart` tests. Can you look at this error?

rmarsh (Wed, 10 Feb 2021 22:12:17 GMT):
@Toktar @askolesov I'm working on the 20.04 upgrade of indy-node. I am having an issue with the `pool_restart` tests. Can you look at this error?

rmarsh (Wed, 10 Feb 2021 22:12:47 GMT):

rmarsh - Wed Feb 10 2021 15:12:31 GMT-0700 (Mountain Standard Time).txt

rmarsh (Wed, 10 Feb 2021 22:13:37 GMT):
@askolesov

rjones (Thu, 11 Feb 2021 01:50:27 GMT):
If I could get one more +1 here that would be awesome: https://github.com/hyperledger/indy-node/pull/1649

PatrikStas (Thu, 11 Feb 2021 11:14:14 GMT):
Kudos to @mirgee he did all the hard work there :-)

Toktar (Thu, 11 Feb 2021 14:26:14 GMT):
Looks like a problem with different states after nodes' restart. Did you run only this tests or a few? If a few, could you please launch it alone? I have InvalidStateError for the test too, but with a message about restart and not retrieved exceptions. I guess it's ok because the test passes for my Ubuntu 16

rmarsh (Thu, 11 Feb 2021 14:35:58 GMT):
@Toktar Just to clarify, tests do or do NOT pass on your machine for 16.04?

Toktar (Thu, 11 Feb 2021 14:37:09 GMT):
Tests do pass on my machine for 16.04

rmarsh (Thu, 11 Feb 2021 14:38:45 GMT):
Ok. I will re-run the pool_tests individually just to ensure its the same failure. I will update you.

rmarsh (Thu, 11 Feb 2021 15:04:15 GMT):
I am seeing the same five failures. 1. test_pool_restart_in_view_change 2. test_pool_restart_now_with_empty_datetime 3. test_pool_restarts_one_by_one 4. test_pool_restarts_one_by_one_with_restart_now 5. test_restart_on_inconsistency

rmarsh (Thu, 11 Feb 2021 15:04:15 GMT):
I am seeing the same five failures. 1. test_pool_restart_in_view_change 2.test_pool_restart_now_with_empty_datetime 3. test_pool_restarts_one_by_one 4.test_pool_restarts_one_by_one_with_restart_now 5. test_restart_on_inconsistency

rmarsh (Thu, 11 Feb 2021 15:04:15 GMT):
I am seeing the same five failures. 1. `test_pool_restart_in_view_change` 2. `test_pool_restart_now_with_empty_datetime` 3. `test_pool_restarts_one_by_one` 4. `test_pool_restarts_one_by_one_with_restart_now` 5. `test_restart_on_inconsistency`

rmarsh (Thu, 11 Feb 2021 15:04:15 GMT):
I am seeing the same five failures. 1. `test_pool_restart_in_view_change` 2. `test_pool_restart_now_with_empty_datetime` 3. `test_pool_restarts_one_by_one` 4. test_pool_restarts_one_by_one_with_restart_now` 5. `test_restart_on_inconsistency`

rmarsh (Thu, 11 Feb 2021 15:04:15 GMT):
I am seeing the same five failures. 1.`test_pool_restart_in_view_change` 2.`test_pool_restart_now_with_empty_datetime` 3.`test_pool_restarts_one_by_one` 4.`test_pool_restarts_one_by_one_with_restart_now` 5. `test_restart_on_inconsistency`

esplinr (Thu, 11 Feb 2021 15:16:18 GMT):
We're blocked in our work on implementing frozen ledgers and the default fee handler, because the Sovrin pipelines are still broken and we don't have permission to fix them.

esplinr (Thu, 11 Feb 2021 15:16:36 GMT):
This is due to a legacy dependency between Indy and Sovrin in the indy-test-automation repo.

esplinr (Thu, 11 Feb 2021 15:17:35 GMT):
Our plan is to remove the Sovrin tests from indy-test-automation . We can put them into a separate repo in the sovrin-foundation org if we can get one created. Is this something you can help with @WadeBarnes ?

esplinr (Thu, 11 Feb 2021 15:17:57 GMT):
This will break the Sovrin Jenkins pipelines even further. But the right solution is for someone to migrate them to GitHub Actions.

swcurran (Thu, 11 Feb 2021 15:26:11 GMT):
@esplinr -- looks like you are able and wanting to take back running the Indy Contributors call, which I'm fine with. Let me know if you need to know the host code now used on the call.

esplinr (Thu, 11 Feb 2021 15:27:00 GMT):
I'm not intending to take over the call. I'm just trying to help.

esplinr (Thu, 11 Feb 2021 15:27:22 GMT):
I had a lot of notes that I didn't want to lose. So I created an agenda and put them there. Feel free to do with them what you want.

swcurran (Thu, 11 Feb 2021 15:34:57 GMT):
I'm happy to have you take it -- all good.

esplinr (Thu, 11 Feb 2021 15:45:23 GMT):
I'll be there next Tuesday, but I don't know if I will be able to regularly attend after mid-March. I don't have the host code, but I won't need it if you are planning on attending.

WadeBarnes (Thu, 11 Feb 2021 16:01:27 GMT):
@esplinr , Yes I can help with that process. What would your team like to see, and how do you propose separating the tests in such a way that they can easily be sucked in and run as part of a test run? With Jenkins, is there something I can help with in the short term to help get the pipelines into a working state? If I have details on the the specific pain points with Jenkins I can investigate.

WadeBarnes (Thu, 11 Feb 2021 16:01:27 GMT):
@esplinr , Yes I can help with that process. What would your team like to see, and how do you propose separating the tests in such a way that they can easily be sucked in and run as part of a test run when/if desired? With Jenkins, is there something I can help with in the short term to help get the pipelines into a working state? If I have details on the the specific pain points with Jenkins I can investigate.

esplinr (Thu, 11 Feb 2021 22:43:01 GMT):
@Toktar Can you provide details about the failures we are seeing in Jenkins? Is it worth fixing them if we are changing the organization of the tests?

esplinr (Thu, 11 Feb 2021 22:44:39 GMT):
@WadeBarnes I believe we want a repo with a name similar to github.com/sovrin-foundation/sovrin-test-automation We can then take the sovrin components of indy-test-automation, and move them there. Indy Test Automation should be able to run independent, but Sovrin Test Automation should require Indy Test Automation. Is that correct @askolesov ?

esplinr (Thu, 11 Feb 2021 22:45:44 GMT):
The team said that this might be a big enough change that it's better to just re-implement the pipelines in Github Actions rather than fixing Jenkins. @Toktar Can you provide details about the failures we are seeing in Jenkins? Is it worth fixing them if we are changing the organization of the tests?

rmarsh (Thu, 11 Feb 2021 23:52:06 GMT):
@RobinKlemens I am still working through failing unit tests. I was able to fix about half today. My goal is to have all tests passing by end of day tomorrow. My PR against indy-plenum has FIXME comments around the failing tests. The two things from my perspective that would be helpful that you picked up is: 1. Become familiar with the CI / CD that @m00sey has done so that we can move that along. 2. Look into why pip is pinned to versions before 10.0.0

Helen_Garneau (Fri, 12 Feb 2021 13:56:36 GMT):
Has joined the channel.

WadeBarnes (Fri, 12 Feb 2021 14:20:37 GMT):
@rmarsh, It was pinned do to the additional requirement of pinning another dependency that is not supported in a newer version of pip. @Toktar or @m00sey , may recall the details.

Toktar (Fri, 12 Feb 2021 14:47:33 GMT):
System scripts for starting nodes and their environment use old pip API and if we bump pip version, we need to update the scripts.

Toktar (Fri, 12 Feb 2021 14:52:14 GMT):
I think it depends on changing packages' location in repo.sovrin https://build.sovrin.org/job/sovrin/job/sovrin-nightly/580/ ``` Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: indy-plenum : Depends: python3-orderedset (= 2.0) but 2.0.3 is to be installed Depends: python3-psutil (= 5.4.3) but 5.6.6 is to be installed Depends: python3-psutil (= 5.4.3) but 5.6.6 is to be installed Depends: python3-pympler (= 0.5) but 0.8 is to be installed E: Unable to correct problems, you have held broken packages. ```

Toktar (Fri, 12 Feb 2021 14:57:23 GMT):
GitHub IndyNode CI has a failed step of publishing tests report. And someone made GA check is required. This blocks all PRs to the master brunch and our work. @WadeBarnes Do you know something about this. May we make GA not required?

rjones (Fri, 12 Feb 2021 15:08:19 GMT):
@Toktar could I get a +1 here: https://github.com/hyperledger/indy-node/pull/1649

rjones (Fri, 12 Feb 2021 15:10:21 GMT):
@Toktar which PR is failing? I don't see GHA as required anywhere

Toktar (Fri, 12 Feb 2021 15:30:03 GMT):
I'm sorry I understood GitHub's messages incorrectly. GHA tests were failing in this PR: https://github.com/hyperledger/indy-node/pull/1641 But you are right, this check was optional. I saw the research from BrettLogan. Thanks, I'll read it

rmarsh (Fri, 12 Feb 2021 15:39:33 GMT):
Ok. I will look into the scripts. Are they just the ones defined in setup.py?

esplinr (Fri, 12 Feb 2021 23:25:03 GMT):
In a meeting today, @Toktar gave a great explanation and demo of the freeze ledgers transaction. It took about 15 minutes. Would you be interested in her sharing during the Indy call on Tuesday? @swcurran @WadeBarnes @lynn.bendixsen

WadeBarnes (Sat, 13 Feb 2021 12:52:53 GMT):
@esplinr, Absolutely!

WadeBarnes (Sat, 13 Feb 2021 12:53:26 GMT):
Thanks for hte info

WadeBarnes (Sat, 13 Feb 2021 12:53:26 GMT):
Thanks for the info

m00sey (Sat, 13 Feb 2021 15:57:59 GMT):
@esplinr yup

askolesov (Mon, 15 Feb 2021 10:32:52 GMT):
[ ](https://chat.hyperledger.org/channel/indy-contributors?msg=TdqFfmJWxzEN4X39K) That's right

WadeBarnes (Mon, 15 Feb 2021 14:11:26 GMT):
That repository already exists; https://github.com/sovrin-foundation/sovrin-test-automation

askolesov (Mon, 15 Feb 2021 17:17:55 GMT):
@WadeBarnes Sovrin pipelines use @Library('SovrinHelpers@v1.2.1'). Where can I find it? I don't see any repositories with similar name...

WadeBarnes (Mon, 15 Feb 2021 17:24:40 GMT):
https://github.com/sovrin-foundation/jenkins-shared

WadeBarnes (Mon, 15 Feb 2021 17:24:53 GMT):
Sent you an invite.

askolesov (Mon, 15 Feb 2021 17:33:38 GMT):
Thanks! I believe the invite will be there soon

askolesov (Mon, 15 Feb 2021 17:42:09 GMT):
Can't see it :(

WadeBarnes (Mon, 15 Feb 2021 17:49:07 GMT):
Did you accept the invite to the Sovrin group that would have come through to the email associated to your GitHub account?

WadeBarnes (Mon, 15 Feb 2021 17:50:37 GMT):
Never mind I found the issue.

WadeBarnes (Mon, 15 Feb 2021 17:56:22 GMT):
Ok, now you should get an invite.

askolesov (Mon, 15 Feb 2021 18:10:44 GMT):
It worked, thanks!

esplinr (Tue, 16 Feb 2021 13:49:34 GMT):
Thank you @WadeBarnes !

RobinKlemens (Tue, 16 Feb 2021 14:24:34 GMT):
@WadeBarnes Can you take a look at my draft of integrating both ubuntu versions in one workflow, please? If that's okay with you I create a PR to Plenum. https://github.com/udosson/indy-plenum/tree/gha-ubuntu-20.04/.github/workflows

RobinKlemens (Tue, 16 Feb 2021 14:36:40 GMT):
@rmarsh 1. I started with the CI part of Ubuntu 20.04. https://github.com/udosson/indy-plenum/tree/gha-ubuntu-20.04/.github/workflows 2. At least one reason is the import of pip in __init__.py in ./plenum. The following line causes an error with pip > 20 https://github.com/hyperledger/indy-plenum/blob/c369885b670184dc7cefd803ddcb459a8f34f84a/plenum/__init__.py#L60

RobinKlemens (Tue, 16 Feb 2021 14:36:40 GMT):
@rmarsh @Toktar 1. I started with the CI part of Ubuntu 20.04. https://github.com/udosson/indy-plenum/tree/gha-ubuntu-20.04/.github/workflows 2. At least one reason is the import of pip in __init__.py in ./plenum. The following line causes an error with pip >= 10 https://github.com/hyperledger/indy-plenum/blob/c369885b670184dc7cefd803ddcb459a8f34f84a/plenum/__init__.py#L60

RobinKlemens (Tue, 16 Feb 2021 14:36:40 GMT):
@rmarsh @Toktar 1. I started with the CI part of Ubuntu 20.04. https://github.com/udosson/indy-plenum/tree/gha-ubuntu-20.04/.github/workflows 2. At least one reason is the import of pip in __init__.py in ./plenum. The following line causes an error with pip > 20 https://github.com/hyperledger/indy-plenum/blob/c369885b670184dc7cefd803ddcb459a8f34f84a/plenum/__init__.py#L60

rmarsh (Tue, 16 Feb 2021 15:10:04 GMT):
@RobinKlemens I'll glance at your workflow today. @Toktar may know more about the pip issue.

esplinr (Tue, 16 Feb 2021 16:02:15 GMT):
I need to deal with a family car problem, and will join the Indy Contrubitors call as soon as I can @swcurran @askolesov

esplinr (Tue, 16 Feb 2021 16:39:22 GMT):
Did the call end early? I don't see anyone in the Zoom meeting, and I'm nervous that I have the wrong ID.

swcurran (Tue, 16 Feb 2021 16:40:42 GMT):
Yes

esplinr (Tue, 16 Feb 2021 16:41:22 GMT):
Thanks for confirming. I'll watch the recording. I'm keen to hear about the release progress.

esplinr (Tue, 16 Feb 2021 16:43:17 GMT):
Was there a discussion about Indy HIPE PR 162? I haven't had any feedback in 2 weeks, and I believe it is ready to merge. @WadeBarnes @lynn.bendixsen @swcurran @m00sey

rmarsh (Wed, 17 Feb 2021 04:52:24 GMT):
@RobinKlemens I didn't get a chance to look at the pip error you posted above. I will look more into this tomorrow. Today I made a lot of progress on fixing the broken tests and upgrading some of the packages.

WadeBarnes (Wed, 17 Feb 2021 12:54:43 GMT):
Nice work.

WadeBarnes (Wed, 17 Feb 2021 12:55:13 GMT):
@RobinKlemens, Looks good to me.

RobinKlemens (Wed, 17 Feb 2021 16:21:57 GMT):
alright. What would you suggest as the next step? Waiting till you PR got merged and then create a second PR with the Ubuntu 20.04 updates?

askolesov (Wed, 17 Feb 2021 16:43:39 GMT):
@WadeBarnes Hi, could you please advise me on how to test artifacts uploading to repo.sovrin.org and PyPI? I understand that sharing credentials with me is a security concern. Maybe you can create another credential with minimal rights to a dedicated location? At least for deb repository. What do you think?

WadeBarnes (Wed, 17 Feb 2021 17:15:33 GMT):
Wait for mine. Then Ian has some CD changes that build on that. Then integrate your changes on top. That way you get the CD stuff too.

lynn.bendixsen (Wed, 17 Feb 2021 21:14:41 GMT):
Sorry Richard, but I joined the call too late also.

esplinr (Thu, 18 Feb 2021 00:27:08 GMT):
Are you comfortable with us merging that PR?

esplinr (Thu, 18 Feb 2021 00:28:11 GMT):
I should have made it easier by including a link: https://github.com/hyperledger/indy-hipe/pull/162

esplinr (Thu, 18 Feb 2021 00:29:20 GMT):
Based on the feedback in the PR, I think this is ready to merge. But I don't want to do anything unilaterally.

RobinKlemens (Thu, 18 Feb 2021 06:31:21 GMT):
What is needed to get your PR merged? Is there anything I can help with?

askolesov (Thu, 18 Feb 2021 11:54:01 GMT):
@WadeBarnes Also, I see that pipelines publish builds before running integration tests. Isn't it better to publish after tests pass?

askolesov (Thu, 18 Feb 2021 14:23:47 GMT):
And is there any progress on the SDK CD pipeline issue investigation? Can we help with something? This build will allow us to finish tests for frozen ledgers feature.

WadeBarnes (Thu, 18 Feb 2021 14:36:00 GMT):
@askolesov, Would you be available tomorrow morning for a zoom meeting? We could walk though some of these issues together.

WadeBarnes (Thu, 18 Feb 2021 14:36:00 GMT):
@askolesov, Would you be available tomorrow morning (well morning my time) for a zoom meeting? We could walk though some of these issues together.

WadeBarnes (Thu, 18 Feb 2021 14:36:00 GMT):
@askolesov, Would you be available tomorrow morning (well morning my time) for a zoom meeting? We could walk though some of these issues together. If we can't get things sorted and proceeding via RC.

WadeBarnes (Thu, 18 Feb 2021 14:39:45 GMT):
Are you specifically referring to the investigation that needs to be done to insure the pending indy-sdk release will be published successfully when we push the button to allow it to continue?

WadeBarnes (Thu, 18 Feb 2021 14:41:45 GMT):
If so, yes. A while back @esplinr and @rjones, removed some service accounts from one or more package repositories. I have a feeling those are used during the indy-sdk CD process.

WadeBarnes (Thu, 18 Feb 2021 14:44:58 GMT):
The existing CD process needs to be reviewed to identify which accounts are used to publish the indy-sdk packages to the various package repositories and ensure those accounts still have access to those repositories. Otherwise the indy-sdk release will fail and we'll have to start again and update/troubleshoot the publishing portions of the pipeline.

WadeBarnes (Thu, 18 Feb 2021 14:45:19 GMT):
If you are able to help with this, GREAT!

WadeBarnes (Thu, 18 Feb 2021 14:47:45 GMT):
Sorry, I'm not 100% familiar with all of the processes. Is this a case where the packages are published before the tests because the packages are used during the integration tests? If not then it's likely better for the packages to be published after the tests have passed.

WadeBarnes (Thu, 18 Feb 2021 14:51:12 GMT):
We just need an approval from a code owner to enable merge; https://github.com/hyperledger/indy-plenum/pull/1505

WadeBarnes (Thu, 18 Feb 2021 14:51:53 GMT):
Anyone marked with the shield:

WadeBarnes (Thu, 18 Feb 2021 14:51:55 GMT):

Clipboard - February 18, 2021 6:51 AM

WadeBarnes (Thu, 18 Feb 2021 14:53:11 GMT):
@Toktar, @sergey.khoroshavin ^

WadeBarnes (Thu, 18 Feb 2021 14:56:54 GMT):
@sergey.khoroshavin has some experience and access to repo.sovrin.org. @sergey.khoroshavin, do you have any recommendations or suggestions for the best way to accomplish this?

WadeBarnes (Thu, 18 Feb 2021 15:38:03 GMT):
It looks like all of the access to publish to repo.sovrin.org is done from internally.

esplinr (Thu, 18 Feb 2021 15:42:53 GMT):
I thought that @rjones added the pypi credentials to the relevant repos at GitHub secrets.

rjones (Thu, 18 Feb 2021 15:43:26 GMT):
I did - if it's missing, I will add it to more places

esplinr (Thu, 18 Feb 2021 15:43:32 GMT):
@askolesov you should ask @rjones to add you to the Hyperledger org in GitHub. Then I believe you can see the secrets.

rjones (Thu, 18 Feb 2021 15:43:51 GMT):
Secrets aren't available for pull requests, if that is the issue

WadeBarnes (Thu, 18 Feb 2021 15:43:59 GMT):
We're not talking about the GHA flow. We're talking about hte accounts and credentials used for the existing, in flight, Jenkins pipeline.

WadeBarnes (Thu, 18 Feb 2021 15:43:59 GMT):
We're not talking about the GHA flow. We're talking about theaccounts and credentials used for the existing, in flight, Jenkins pipeline.

WadeBarnes (Thu, 18 Feb 2021 15:43:59 GMT):
We're not talking about the GHA flow. We're talking about the accounts and credentials used for the existing, in flight, Jenkins pipeline.

esplinr (Thu, 18 Feb 2021 15:44:09 GMT):
@WadeBarnes @swcurran Can we accept this HIPE?

esplinr (Thu, 18 Feb 2021 15:44:09 GMT):
@WadeBarnes @swcurran Can we accept this PR?

rjones (Thu, 18 Feb 2021 15:44:11 GMT):
ah, OK, sorry for my confusion.

WadeBarnes (Thu, 18 Feb 2021 15:44:38 GMT):
No, problem. It's been a while.

esplinr (Thu, 18 Feb 2021 15:45:27 GMT):
I'm lost too. I thought we were talking about the new GitHub Actions pipeline for the Indy SDK repo.

esplinr (Thu, 18 Feb 2021 15:45:49 GMT):
I'm not sure we can or should update the old Jenkins pipeline to use the new publishing credentials.

WadeBarnes (Thu, 18 Feb 2021 15:46:46 GMT):
No. We have an in-flight indy-sdk release build. We need to make sure it's able to run through to completion when we press the "proceed" button.

WadeBarnes (Thu, 18 Feb 2021 15:47:13 GMT):
For it to do that it is relying on particular accounts to publish the packages.

WadeBarnes (Thu, 18 Feb 2021 15:47:36 GMT):
We need to ensure those accounts still have access to the package repos.

WadeBarnes (Thu, 18 Feb 2021 15:49:37 GMT):
I'd like to confirm whether or not any of the accounts its using are the ones affected by the account shuffle.

WadeBarnes (Thu, 18 Feb 2021 15:49:37 GMT):
I'd like to confirm whether or not any of the accounts its using are the ones affected by the account shuffle in the move to use GHA.

askolesov (Thu, 18 Feb 2021 15:59:25 GMT):
Yes, I'm about system tests. Firstly packages are released and then used for testing. I think it's better to migrate CD process as is for now. We can change it in future.

askolesov (Thu, 18 Feb 2021 15:59:45 GMT):
Ok, thanks, will contact Sergey

WadeBarnes (Thu, 18 Feb 2021 16:02:29 GMT):
AGreed.

WadeBarnes (Thu, 18 Feb 2021 16:02:29 GMT):
Afreed

WadeBarnes (Thu, 18 Feb 2021 16:02:29 GMT):
Agreed

WadeBarnes (Thu, 18 Feb 2021 16:03:36 GMT):
Perfect. I'd like to understand the process better once you figure it out.

rjones (Thu, 18 Feb 2021 16:04:42 GMT):

Screen Shot 2021-02-18 at 8.03.51 AM.png

rjones (Thu, 18 Feb 2021 16:05:34 GMT):
https://pypi.org/project/python3-indy/ shows the evernym user as maintainer

askolesov (Thu, 18 Feb 2021 16:08:54 GMT):
Sorry for confusion, I was talking about Indy SDK master CD pipeline. There is no alternatives in GHA for it. I'm about this fail: https://build.sovrin.org/job/indy-sdk/job/indy-sdk-cd/job/master/

askolesov (Thu, 18 Feb 2021 16:09:23 GMT):

Clipboard - February 18, 2021 7:09 PM

WadeBarnes (Thu, 18 Feb 2021 16:10:44 GMT):
Yes, that error is likely do to the account shuffle that @rjones and @esplinr had done.

WadeBarnes (Thu, 18 Feb 2021 16:11:46 GMT):
That also confirms the in-flight release build will also fail with the same error is we let it proceed.

WadeBarnes (Thu, 18 Feb 2021 16:11:46 GMT):
That also confirms the in-flight release build will also fail with the same error if we let it proceed.

WadeBarnes (Thu, 18 Feb 2021 16:12:33 GMT):
@rjones Are you able to assist with restoring that account's access please. Let me know if you need anything from me.

rjones (Thu, 18 Feb 2021 16:18:04 GMT):
I sent an invite, so that needs accepted

askolesov (Thu, 18 Feb 2021 16:19:17 GMT):
Let me try to ask Sergey K. first. I've implemented a workaround and publish packages to GitHub releases now so it doesn't bock me. I want to investigate what exactly I need before the meeting. Thanks!

rjones (Thu, 18 Feb 2021 16:19:47 GMT):
@WadeBarnes I don't know who controls that account, but once the invite is accepted, it should work?

rjones (Thu, 18 Feb 2021 16:19:56 GMT):
they might need to get a new API key, possibly?

WadeBarnes (Thu, 18 Feb 2021 16:22:33 GMT):
Apparently I do, lol. I accepted the invite.

WadeBarnes (Thu, 18 Feb 2021 16:23:34 GMT):
@askolesov Can you re-run that build and see if there is anything else we need to do (see if there are any other errors).

askolesov (Thu, 18 Feb 2021 16:23:58 GMT):
Yep

lynn.bendixsen (Thu, 18 Feb 2021 17:00:57 GMT):
@esplinr I have re-reviewed and approved the HIPE. thanks!

esplinr (Fri, 19 Feb 2021 05:06:19 GMT):
Thank you!

esplinr (Fri, 19 Feb 2021 05:06:26 GMT):
@WadeBarnes Can you merge the HIPE?

esplinr (Fri, 19 Feb 2021 05:06:26 GMT):
@WadeBarnes Can you merge the PR?

WadeBarnes (Fri, 19 Feb 2021 15:05:56 GMT):
@askolesov, Did re-instating the service account permissions fix the issue?

esplinr (Fri, 19 Feb 2021 15:59:46 GMT):
Maintainers.md for Indy Node and CODEOWNERS for Node and Plenum are out of date. These files should list people that expect to be involved with the project over the long term, as they will be asked to review and merge PRs. I think there are also some repository maintenance abilities. I think it should be: @WadeBarnes @Toktar @brentzundel @esplinr @sergey.khoroshavin Should we also include @RobinKlemens, @m00sey, @ianco, and @askolesov ? Who is missing? Any concerns with my creating a PR with these names?

swcurran (Fri, 19 Feb 2021 16:12:10 GMT):
I think that sounds right. I would recommend that the Hyperledger standard Maintainers document be used and the repolint process be run to see if any other changes are needed.

askolesov (Sat, 20 Feb 2021 07:46:13 GMT):

Clipboard - February 20, 2021 10:45 AM

askolesov (Sat, 20 Feb 2021 07:46:55 GMT):
The strange thing is there are no failures.

WadeBarnes (Sat, 20 Feb 2021 16:56:50 GMT):
It's waiting for user input; https://build.sovrin.org/job/indy-sdk/job/indy-sdk-cd/job/master/1625/console

WadeBarnes (Sat, 20 Feb 2021 16:57:07 GMT):

Clipboard - February 20, 2021 8:57 AM

WadeBarnes (Sat, 20 Feb 2021 16:58:03 GMT):
That wait step was added recently due to an issue with publishing to creates.io.

WadeBarnes (Sat, 20 Feb 2021 17:01:45 GMT):
https://github.com/hyperledger/indy-sdk/commit/188c18ace78a0bd2e8debbd951fac2ae1c3047ed#diff-6364d631af1178a8331f7eeeceb15f7c4c73f0ea285675b4541b5ea9e4d35cdd

WadeBarnes (Sat, 20 Feb 2021 17:19:43 GMT):
I clicked **Proceed**.

WadeBarnes (Sat, 20 Feb 2021 17:34:51 GMT):
The build completed successfully.

WadeBarnes (Sat, 20 Feb 2021 20:26:26 GMT):
@Toktar, @askolesov, @m00sey @ianco, @rmarsh, @RobinKlemens `indy-node` Jenkins build failure summary: [indy-node-cd - master](https://build.sovrin.org/blue/organizations/jenkins/indy-node%2Findy-node-cd/detail/master/1230/pipeline); failing on `./system/docker/prepare.sh indy-test-automation-network` due to `Version '1.15.0~1618' for 'libindy' was not found` [indy-node-nightly](https://build.sovrin.org/blue/organizations/jenkins/indy-node%2Findy-node-nightly/detail/indy-node-nightly/632/pipeline) failing on `pip install .[tests] >pip.intsall.log` due to `Requested python3-indy==1.15.0-dev-1618 from ... (from indy-node==1.13.0.dev0) has different version in metadata: '1.15.0'`

WadeBarnes (Sat, 20 Feb 2021 20:26:26 GMT):
@Toktar, @askolesov, @m00sey @ianco, @rmarsh, @RobinKlemens `indy-node` Jenkins build failure summary: [indy-node-cd - master](https://build.sovrin.org/blue/organizations/jenkins/indy-node%2Findy-node-cd/detail/master/1230/pipeline); failing on `./system/docker/prepare.sh indy-test-automation-network ` due to `Version '1.15.0~1618' for 'libindy' was not found` [indy-node-nightly](https://build.sovrin.org/blue/organizations/jenkins/indy-node%2Findy-node-nightly/detail/indy-node-nightly/632/pipeline) failing on `pip install .[tests] >pip.intsall.log` due to `Requested python3-indy==1.15.0-dev-1618 from ... (from indy-node==1.13.0.dev0) has different version in metadata: '1.15.0'

WadeBarnes (Sat, 20 Feb 2021 20:28:41 GMT):
Jenkins build issues with `indy-sdk` have been resolved. Not seeing any issues with the Jenkins builds for `indy-plenum`.

WadeBarnes (Sat, 20 Feb 2021 20:31:42 GMT):
Seeing as we just built the `indy-sdk 1.16.0` release, would our best course of action be to fix the `indy-node` builds by updating them to this new release?

WadeBarnes (Sat, 20 Feb 2021 21:35:05 GMT):
@Toktar, @askolesov, The issue with the [token-plugin-ci - PR-405](https://build.sovrin.org/blue/organizations/jenkins/token-plugin%2Ftoken-plugin-ci/detail/PR-405/1/pipeline/113) build appears to be related to a `ruby` dependency. ``` [AWS CodeBuild Plugin] ERROR: Error installing fpm: [AWS CodeBuild Plugin] childprocess requires Ruby version >= 2.4.0. [AWS CodeBuild Plugin] Successfully installed ffi-1.14.2 [AWS CodeBuild Plugin] 1 gem installed [AWS CodeBuild Plugin] Service 'base' failed to build: The command '/bin/sh -c apt-get update && apt-get install -y --no-install-recommends ruby ruby-dev rubygems && gem install --no-ri --no-rdoc rake fpm:$FPM_VERSION && rm -rf /var/lib/apt/lists/*' returned a non-zero code: 1 ``` It looks like one of the dependencies requires `Ruby version >= 2.4.0` and the build container is installing `Ruby version 2.3.0`. There are a number of places that `ENV RUBY_VERSION=2.3.0` is defined to pick the version of ruby to install for the build. However, if I'm reading things correctly it looks like that only affects the centos based images, while the build is using `/token-plugin/devops/ext/docker/base/xenial/Dockerfile.0.2.0` by setting `OSNAME=xenial` and `BASE_DOCKER_VERSION=0.2.0`. This version of the dockerfile is installing `ruby 2.3` by default. Options seem to be; 1) Setup the build to use one of the centos build containers and set the `RUBY_VERSION=2.4.0` or higher. 2) Add support for defining the ruby version in the xenial build containers. 3) Pin `fpm` to a version that supports `ruby 2.3` With any of these options there is the chance of knock-on dependency issues that need to be addressed. Thoughts?

WadeBarnes (Sat, 20 Feb 2021 22:00:18 GMT):
@esplinr, @Toktar, @askolesov, [sovrin-cd - master](https://build.sovrin.org/job/sovrin/job/sovrin-cd/job/master/) builds are fixed.

WadeBarnes (Sat, 20 Feb 2021 22:07:02 GMT):
The last [sovrin-cd - stable](https://build.sovrin.org/job/sovrin/job/sovrin-cd/job/stable/) @Toktar and I built indicated an overall failure, but produced the expected release artifacts. Since this build produces release artifacts I'm going to defer attempting any fixes or re-runs until the next release cycle.

WadeBarnes (Sat, 20 Feb 2021 22:18:56 GMT):
The [sovrin-nightly](https://build.sovrin.org/blue/organizations/jenkins/sovrin%2Fsovrin-nightly/detail/sovrin-nightly/589/pipeline) build is failing due to a dependency issue. ``` 2s + apt-get install -y sovrin=1.1.212 sovtoken=1.0.8~dev151 sovtokenfees=1.0.8~dev151 indy-node=1.13.0~dev1210 indy-plenum=1.13.0~dev1021 python3-indy-crypto=0.4.5 Reading package lists... Building dependency tree... Reading state information... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: indy-plenum : Depends: python3-orderedset (= 2.0) but 2.0.3 is to be installed Depends: python3-psutil (= 5.4.3) but 5.6.6 is to be installed Depends: python3-psutil (= 5.4.3) but 5.6.6 is to be installed Depends: python3-pympler (= 0.5) but 0.8 is to be installed E: Unable to correct problems, you have held broken packages. script returned exit code 100 ``` It looks like we need to update `indy-plenum` and remove `indy-crypto`. Does that sound correct?

WadeBarnes (Sat, 20 Feb 2021 22:18:56 GMT):
The [sovrin-nightly](https://build.sovrin.org/blue/organizations/jenkins/sovrin%2Fsovrin-nightly/detail/sovrin-nightly/589/pipeline) build is failing due to a dependency issue. ``` + apt-get install -y sovrin=1.1.212 sovtoken=1.0.8~dev151 sovtokenfees=1.0.8~dev151 indy-node=1.13.0~dev1210 indy-plenum=1.13.0~dev1021 python3-indy-crypto=0.4.5 Reading package lists... Building dependency tree... Reading state information... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: indy-plenum : Depends: python3-orderedset (= 2.0) but 2.0.3 is to be installed Depends: python3-psutil (= 5.4.3) but 5.6.6 is to be installed Depends: python3-psutil (= 5.4.3) but 5.6.6 is to be installed Depends: python3-pympler (= 0.5) but 0.8 is to be installed E: Unable to correct problems, you have held broken packages. script returned exit code 100 ``` It looks like we need to update `indy-plenum` and remove `indy-crypto`. Does that sound correct?

WadeBarnes (Sat, 20 Feb 2021 22:43:32 GMT):
Actually it looks like the `indy-node` dependency needs to be updated. The `indy-plenum` dependency is dynamically determined based on the version of `indy-node`. Still need to remove the `indy-crypto` dependency to be consistent with the corresponding changes here; https://github.com/hyperledger/indy-node/pull/1607

WadeBarnes (Sun, 21 Feb 2021 19:39:34 GMT):
I've wired up a `sovrin-ci` job to [sovrin-foundation/sovrin](https://github.com/sovrin-foundation/sovrin) so it will build PRs and you can use `(ci) test this please` to also trigger builds. It's wired up to use `Jenkinsfile.nightly`. It's the `ci/sovrin-foundation-jenkins/pr-merge` results you want to look at on the PRs. [WIP Removed token dependencies](https://github.com/sovrin-foundation/sovrin/pull/289) also has a `continuous-integration/jenkins/pr-merge` result on it, but that's an artifact of another build I tried that did not work out. Examples: - https://github.com/sovrin-foundation/sovrin/pull/289 - https://build.sovrin.org/job/sovrin/job/sovrin-ci/

WadeBarnes (Sun, 21 Feb 2021 19:39:34 GMT):
I've wired up a `sovrin-ci` job to [sovrin-foundation/sovrin](https://github.com/sovrin-foundation/sovrin) so it will build PRs and you can use `(ci) test this please` to also trigger builds. It's wired up to use `Jenkinsfile.nightly` currently. It's the `ci/sovrin-foundation-jenkins/pr-merge` results you want to look at on the PRs. [WIP Removed token dependencies](https://github.com/sovrin-foundation/sovrin/pull/289) also has a `continuous-integration/jenkins/pr-merge` result on it, but that's an artifact of another build I tried that did not work out. Examples: - https://github.com/sovrin-foundation/sovrin/pull/289 - https://build.sovrin.org/job/sovrin/job/sovrin-ci/

WadeBarnes (Sun, 21 Feb 2021 19:40:04 GMT):
@esplinr, @askolesov, @Toktar ^

askolesov (Wed, 24 Feb 2021 13:43:02 GMT):
Pinning `fpm` sounds like the less risky option for me.

WadeBarnes (Wed, 24 Feb 2021 14:14:48 GMT):
My concerns with pinning `fpm` are: - We'd be reverting back to a previous version of `fpm` when we've been using the current version if `fpm` explicitly since early 2019. - Would reverting break something else, i.e. are we relying on features of `fpm` version `1.9.3`? - At some point `fpm` has clearly dropped support for Ruby 2.3.0, at least for `fpm` version `1.9.3`. Why?

WadeBarnes (Wed, 24 Feb 2021 14:15:56 GMT):
Here is the answer; https://www.ruby-lang.org/en/news/2019/03/31/support-of-ruby-2-3-has-ended/

WadeBarnes (Wed, 24 Feb 2021 14:17:53 GMT):
The Ruby recommendation is to 2.5 or 2.6. Current stable ruby version 3.0.

WadeBarnes (Wed, 24 Feb 2021 14:19:56 GMT):
It looks like our best choice would be to use a newer version of Ruby.

WadeBarnes (Wed, 24 Feb 2021 14:22:02 GMT):
Ruby 3.0 being the best option, 2.7.x and 2.6.x as backup options. Ruby 2.4 is EOL already, 2.5 is soon to be EOL.

askolesov (Wed, 24 Feb 2021 17:47:44 GMT):
Maybe then we can just update Ruby to the latest version?

WadeBarnes (Wed, 24 Feb 2021 18:44:07 GMT):
That would be the first step, and see if anything breaks.

ianco (Thu, 25 Feb 2021 14:36:21 GMT):
FYI I created the 1.16.0 release tag and the PR to merge `rc` into `main`: https://github.com/hyperledger/indy-sdk/pull/2361

WadeBarnes (Thu, 25 Feb 2021 18:17:18 GMT):
@ianco, @RobinKlemens, The `indy-plenum` [GitHub actions CI workflow](https://github.com/hyperledger/indy-plenum/pull/1513) PR has been merged. @ianco, Please submit the PR to add the CD portion and let @RobinKlemens know when that is submitted and later merged so he can add the Ubuntu 20.04 support. THANKS Guys!

swcurran (Thu, 25 Feb 2021 18:28:54 GMT):
With the merges going on, are we still going to be able to produce a "same as today but from GHAs" release?

WadeBarnes (Thu, 25 Feb 2021 18:38:59 GMT):
Yes, "Same as today" is safe on the `stable` branch.

WadeBarnes (Thu, 25 Feb 2021 18:40:07 GMT):
It's also tagged.

askolesov (Fri, 26 Feb 2021 12:49:04 GMT):
I've updated codeowners for node and plenum as proposed by @esplinr . Please review PRs and approve them if everything is ok: https://github.com/hyperledger/indy-plenum/pull/1518 https://github.com/hyperledger/indy-node/pull/1664

WadeBarnes (Fri, 26 Feb 2021 14:37:48 GMT):
Looks good to me. Thanks @askolesov

rmarsh (Fri, 26 Feb 2021 15:55:15 GMT):
Ubuntu 20.04 upgrade pass off:

rmarsh (Fri, 26 Feb 2021 16:03:48 GMT):
I will be leaving on paternity leave today. Here is my current status. *Plenum:* - branch: https://github.com/ryMarsh44/indy-plenum/tree/ubuntu-20.04-upgrade - PR: https://github.com/hyperledger/indy-plenum/pull/1509 *Node: * - branch: https://github.com/ryMarsh44/indy-node/tree/ubuntu-20.04-upgrade - PR: https://github.com/hyperledger/indy-node/pull/1652 *Known failing test:* 1. `testWorksWithComplexTypes`: Possibly dumb test. @Toktar will look to see if we can remove. 2. `test_send_using_not_dealer_socket` 3. `stp_zmq/test/test_stashed_client_messages.py` -> All of these probably fail for the same reason - `test_stash_msg_to_unknown` - `test_resending_only_for_known_clients` - `test_invalid_msgs_are_not_stashed` - `test_resending_for_old_stash_msgs` *Reference Guide/Dependencies:* - https://github.com/ryMarsh44/indy-node/blob/ubuntu-20.04-upgrade/dev-setup/ubuntu/ubuntu-2004/SetupVMTest.txt - This should include the exact instructions to setup 1. Pip Packages, Debian Packages, and source lists - Almost all the pip packages have been upgraded *Pip packages that have not been updated:* - `rlp` - `pyzmq` - `pip` should only be necessary for build scripts, not unit tests - There may be some more pinned versions that I'm not aware of. I suggest double checking this. FYI: @RobinKlemens @esplinr

rmarsh (Fri, 26 Feb 2021 16:03:48 GMT):
I will be leaving on paternity leave today. Here is my current status. *Plenum*: - branch: https://github.com/ryMarsh44/indy-plenum/tree/ubuntu-20.04-upgrade - PR: https://github.com/hyperledger/indy-plenum/pull/1509 *Node: *- branch: https://github.com/ryMarsh44/indy-node/tree/ubuntu-20.04-upgrade - PR: https://github.com/hyperledger/indy-node/pull/1652 *Known failing test: *1. `testWorksWithComplexTypes`: Possibly dumb test. @Toktar will look to see if we can remove. 2. `test_send_using_not_dealer_socket` 3. `stp_zmq/test/test_stashed_client_messages.py` -> All of these probably fail for the same reason - `test_stash_msg_to_unknown` - `test_resending_only_for_known_clients` - `test_invalid_msgs_are_not_stashed` - `test_resending_for_old_stash_msgs` *Reference Guide/Dependencies: * - https://github.com/ryMarsh44/indy-node/blob/ubuntu-20.04-upgrade/dev-setup/ubuntu/ubuntu-2004/SetupVMTest.txt - This should include the exact instructions to setup 1. Pip Packages, Debian Packages, and source lists - Almost all the pip packages have been upgraded *Pip packages that have not been updated:* - `rlp` - `pyzmq` - `pip` should only be necessary for build scripts, not unit tests - There may be some more pinned versions that I'm not aware of. I suggest double checking this. FYI: @RobinKlemens @esplinr

esplinr (Fri, 26 Feb 2021 18:38:32 GMT):
Hopefully that will prevent people from being blocked by us in the future.

esplinr (Fri, 26 Feb 2021 18:38:55 GMT):
Enjoy your family time!

rjones (Fri, 26 Feb 2021 18:49:57 GMT):
Hi, @WadeBarnes @esplinr I left a request to use GitHub groups instead of naming every person in the CODEOWNERS file. I think the best place to name people is the MAINTAINERS file.

rjones (Fri, 26 Feb 2021 18:50:25 GMT):
If the existing groups are too broad, I'm willing to make new, smaller groups. I see that `indy-common` has about 30 people.

rjones (Fri, 26 Feb 2021 18:50:25 GMT):
If the existing groups are too broad, I'm willing to make new, smaller groups. I see that `indy-common` has about 15 people.

rjones (Fri, 26 Feb 2021 18:51:18 GMT):
If you want to merge those changes, then cycle back once they're in there, totally fine by me... since the changes should go faster :)

Toktar (Fri, 26 Feb 2021 23:19:16 GMT):
@rjones Hello. We created PRs for merging `Stable` branch to `Master` branch and fix conflicts. But both PRs have a problem with DCO check. (I added a manual approval for indy-node PR, but I think it was a mistake. I'll remove it) https://github.com/hyperledger/indy-plenum/pull/1515 https://github.com/hyperledger/indy-node/pull/1663 So, I see the follow ways to solve it: - Manual DCO pass. We already have a painful experience with fixing after this. - Squash old unsigned commits to a new one with adding a new signature. Obviously, the second option looks better, but it means rewriting a few base repo commits from 2017. With force pushing them to `stable`. And I have concern about it. I wonder what is your opinion about it. Thanks in advance.

rjones (Sat, 27 Feb 2021 10:40:14 GMT):
@Toktar check this out: https://github.com/jmertic/contrib_check it makes one makeup commit

rjones (Sat, 27 Feb 2021 18:31:54 GMT):
Howdy. I updated the two CODEOWNERS pull requests: [indy-node](https://github.com/hyperledger/indy-node/pull/1664/files) [indy-plenum](https://github.com/hyperledger/indy-plenum/pull/1518). Please note: I made explicit the hidden permissions for [indy-plenum-maintainers](https://github.com/hyperledger/indy-plenum/pull/1518/files#diff-fcf14c4b7b34fe7a11916195871ae66a59be87a395f28db73e345ebdc828085bR8-R10) @WadeBarnes @Toktar

WadeBarnes (Mon, 01 Mar 2021 12:51:12 GMT):
It looks like some of the DCO issues are due to Merge requests (which are typically unsigned and ignored). I've had issue in the past with the same thing. You need to basically cherry pick around them.

WadeBarnes (Mon, 01 Mar 2021 12:51:58 GMT):
Agreed manually passing the DCO checks will just get us cause us more trouble later.

WadeBarnes (Mon, 01 Mar 2021 12:51:58 GMT):
Agreed, manually passing the DCO checks will just get us cause us more trouble later.

rjones (Mon, 01 Mar 2021 19:24:12 GMT):
if you want to fix them manually and force push, you can do that, too.

rjones (Mon, 01 Mar 2021 19:24:54 GMT):
I could fork the repo and mark it read-only in `hyperledger-archive`, then you force-push

swcurran (Tue, 02 Mar 2021 02:09:19 GMT):
Hey folks --- the Indy Contributors call is coming up tomorrow - Tuesday Match 2, 8AM Pacific, 5PM CET Please join us on the call -- https://wiki.hyperledger.org/display/indy/2021-03-02+Indy+Contributors+Call Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 We'll be talking about: - Status of indy-node CI/CD - Status of Ubuntu upgrade - Status of completed indy-sdk release and follow up issues

esplinr (Tue, 02 Mar 2021 06:27:13 GMT):
I like this approach. cc @askolesov

esplinr (Tue, 02 Mar 2021 06:27:13 GMT):
Using GitHub groups sounds more flexible than maintaining the CODEOWNERS files. Thanks for the suggestion. cc @askolesov

antonden (Tue, 02 Mar 2021 12:23:35 GMT):
Has joined the channel.

Toktar (Tue, 02 Mar 2021 12:39:24 GMT):
@WadeBarnes As far as I understand, the dco check doesn't take into account the merge commits. Unfortunately, there were not enough signatures on many important commits. And many were signed incorrectly. @rjones The tool for adding signatures is very convenient, but with bugs. But now I have experience in fixing ruby scripts in the console. All checks for dso passed, so now you can merge commits if someone revises them.

Toktar (Tue, 02 Mar 2021 12:39:24 GMT):
@WadeBarnes As far as I understand, the dco check doesn't take into account the merge commits. Unfortunately, there were not enough signatures on many important commits. And many were signed incorrectly. @rjones The tool for adding signatures is very convenient, but with some small bugs. Now I have experience in fixing ruby scripts in the console. :) All checks for dco passed, so now you can merge commits if someone revises them.

Toktar (Tue, 02 Mar 2021 12:39:24 GMT):
@WadeBarnes As far as I understand, the dco check doesn't take into account the merge commits. Unfortunately, there were not enough signatures on many important commits. And many were signed incorrectly. @rjones The tool for adding signatures is very convenient, but with some small bugs. Now I have experience in fixing ruby scripts in the console. :) All checks for dco passed, so now you can merge commits if someone review them.

WadeBarnes (Tue, 02 Mar 2021 12:40:29 GMT):
@Toktar, Correct, under normal conditions.

WadeBarnes (Tue, 02 Mar 2021 12:40:59 GMT):
However when/if you cherry pick merge commits DCO has issues with them.

Toktar (Tue, 02 Mar 2021 12:44:23 GMT):
@WadeBarnes I just merged branches without cherry-picks and used https://github.com/coderanger/dco for signing. I guess it uses rebase.

WadeBarnes (Tue, 02 Mar 2021 12:45:54 GMT):
@rjones, did you turn rebase commit on recently?

rjones (Tue, 02 Mar 2021 15:23:58 GMT):
I am not sure.

rjones (Tue, 02 Mar 2021 15:24:21 GMT):
I don't remember making changes to that setting

rjones (Tue, 02 Mar 2021 15:24:51 GMT):
Usually, if a merge commit is content free, it does not need signed.

lynn.bendixsen (Tue, 02 Mar 2021 19:47:48 GMT):
@TelegramSam and I left some comments in the Indy DID Method document shared during the contributors meeting today. Let me know if you or others need any further information/discussion about those comments. @swcurran

swcurran (Tue, 02 Mar 2021 19:50:27 GMT):
Will do.

swcurran (Wed, 03 Mar 2021 01:07:54 GMT):
@lynn.bendixsen -- since many of your comments were editorial (typos, clarifications), would you mind just going into the doc and fixing the text? That would be a lot easier on everyone.

rjones (Wed, 03 Mar 2021 14:55:10 GMT):
Could someone trigger CI on https://github.com/hyperledger/indy-plenum/pull/1521 and https://github.com/hyperledger/indy-node/pull/1666 ? These reflect the current settings of the repos and I'd like to merge them before the `master` - `main` switch. thanks.

antonden (Wed, 03 Mar 2021 14:55:43 GMT):
@RobinKlemens Hello! Now I'm continuing @rmarsh 's work on supporting Ububntu 20.04 for indy-node and indy-plenum. As far as I know you have the same activity. May we sync our progress? I've already fixed several tests for plenum. You can see my progress - https://github.com/hyperledger/indy-plenum/pull/1522 Do you know anyone is doing CD/CI indy-plenum for Ububntu 20.04 yet?

RobinKlemens (Wed, 03 Mar 2021 20:35:57 GMT):
@antonden great to hear that you continue the work of @rmarsh . He was mainly fixing the tests and updating dependencies and I was working on the CI/CD part of Indy-Plenum for Ubuntu 20.04. I'll submit a PR as soon as https://github.com/hyperledger/indy-plenum/pull/1519/files of @ianco get merged.

RobinKlemens (Wed, 03 Mar 2021 20:35:57 GMT):
@antonden great to hear that you continue the work of @rmarsh. He was mainly fixing the tests and updating dependencies and I was working on the CI/CD part of Indy-Plenum for Ubuntu 20.04. I'll submit a PR as soon as https://github.com/hyperledger/indy-plenum/pull/1519/files of @ianco get merged.

lynn.bendixsen (Thu, 04 Mar 2021 18:30:57 GMT):
oops, sorry for slow response. I am happy to go do that :)

lynn.bendixsen (Thu, 04 Mar 2021 18:50:47 GMT):
Done with grammatical fixes and hid the related comments. Left a few comments that are questions and a suggestion for missing content that I was unclear on how to write. Thanks @swcurran and all the others that put so much time into this! Looking great!

askolesov (Fri, 05 Mar 2021 14:08:52 GMT):
@rjones We see failing tasks in most of our PRs. Seems like something related to permissions. Do you have any ideas about what can it be caused by?

askolesov (Fri, 05 Mar 2021 14:08:58 GMT):

Clipboard - March 5, 2021 5:08 PM

askolesov (Fri, 05 Mar 2021 14:09:21 GMT):
For example: https://github.com/hyperledger/indy-node/pull/1665/checks?check_run_id=2012833813

rjones (Fri, 05 Mar 2021 15:51:33 GMT):
yes this was discussed in some other thread - I can't find it right now - basically, there is no easy way to publish the test results. I think that failure should be ignored

rjones (Fri, 05 Mar 2021 15:51:55 GMT):
@BrettLogan said it would be a long time before that feature exists

askolesov (Mon, 08 Mar 2021 09:54:31 GMT):
It's confusing (at least me). I would suggest disabling failing steps. It will not affect the testing process since test results can be found in row output anyway. What do you think?

WadeBarnes (Mon, 08 Mar 2021 14:10:28 GMT):
@askolesov, Short term, the two `Publish Test Report` steps need to be changed to not mark the build as failed when they fail. https://github.com/hyperledger/indy-plenum/blob/master/.github/workflows/build.yaml#L116 https://github.com/hyperledger/indy-plenum/blob/master/.github/workflows/build.yaml#L154

WadeBarnes (Mon, 08 Mar 2021 14:12:04 GMT):
Longer term we need to find a better way to publish test results to the PRs. Seems the way to do that would be using an action that posts the results as a message to the PR.

WadeBarnes (Mon, 08 Mar 2021 14:13:18 GMT):
I've been meaning to do the first, but keep getting distracted.

WadeBarnes (Mon, 08 Mar 2021 14:15:59 GMT):
@ianco, Since your PR (https://github.com/hyperledger/indy-plenum/pull/1519) is up next, is that something you could add to your PR? Then we could do the same for `indy-node`.

askolesov (Mon, 08 Mar 2021 14:19:05 GMT):
@WadeBarnes Great suggestion! I've found the required property: https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idcontinue-on-error

WadeBarnes (Mon, 08 Mar 2021 14:20:08 GMT):
@askolesov, Yes the sort term solution is rather simple.

WadeBarnes (Mon, 08 Mar 2021 14:20:08 GMT):
@askolesov, Yes the shortterm solution is rather simple.

WadeBarnes (Mon, 08 Mar 2021 14:20:08 GMT):
@askolesov, Yes the short term solution is rather simple.

askolesov (Mon, 08 Mar 2021 14:31:48 GMT):
Here it is: https://github.com/hyperledger/indy-plenum/pull/1523

WadeBarnes (Mon, 08 Mar 2021 14:33:05 GMT):
Thanks

WadeBarnes (Mon, 08 Mar 2021 14:36:00 GMT):
@ianco, @askolesov, You'll need to co-ordinate on the order in which these are merged: https://github.com/hyperledger/indy-plenum/pull/1523 and https://github.com/hyperledger/indy-plenum/pull/1519

ianco (Mon, 08 Mar 2021 14:51:26 GMT):
I can back-merge the changes if you want to merge `1523` first

askolesov (Mon, 08 Mar 2021 14:54:14 GMT):
Thanks, @ianco! I will ask @Toktar to merge 1523 then.

Helen_Garneau (Wed, 10 Mar 2021 13:00:06 GMT):
Hello Indy Contributors: Reminder to please join the DevRel Marketing Committee call at 9am PT today. Take a look at the agenda and add items if you'd like here: https://wiki.hyperledger.org/x/Nqx6Ag

Helen_Garneau (Wed, 10 Mar 2021 14:44:35 GMT):
(Please note new zoom info!)

WadeBarnes (Thu, 11 Mar 2021 12:54:44 GMT):
@RobinKlemens, @ianco's GHA PR has been merged; https://github.com/hyperledger/indy-plenum/pull/1519

RobinKlemens (Thu, 11 Mar 2021 13:02:40 GMT):
That's great news!! I have two questions regarding the CD part of GHA: 1. Why don't we use a build container like we do for the CI part? 2. We run the CD part on an Ubuntu20.04 machine and build the deb files for Ubuntu16.04. Could this lead to any troubles because of OS specific dependencies?

WadeBarnes (Thu, 11 Mar 2021 13:04:19 GMT):
Good point. It could. @ianco, Thoughts?

WadeBarnes (Thu, 11 Mar 2021 13:15:31 GMT):
For consistency the builds should be done in a container which is the same version as the target of the build.

RobinKlemens (Thu, 11 Mar 2021 13:45:46 GMT):
I agree. Thus, we need to create a PR that updates the current CD part of GHA

RobinKlemens (Thu, 11 Mar 2021 13:45:46 GMT):
I agree. Thus we need to create a PR that updates the current CD part of GHA

WadeBarnes (Thu, 11 Mar 2021 13:46:44 GMT):
Agreed. The GHAs are a work in progress.

WadeBarnes (Thu, 11 Mar 2021 13:47:10 GMT):
Is that something you could do or do we want @ianco to address?

RobinKlemens (Thu, 11 Mar 2021 13:57:19 GMT):
I can work on this on Monday

WadeBarnes (Fri, 12 Mar 2021 14:04:41 GMT):
@askolesov, @Toktar, As you may already be aware, the indy-node CD and Nightly builds are failing. If I recall correctly you or someone on your team is already working in this area. - https://build.sovrin.org/blue/organizations/jenkins/indy-node%2Findy-node-cd/detail/master/1237/pipeline - https://build.sovrin.org/blue/organizations/jenkins/indy-node%2Findy-node-nightly/detail/indy-node-nightly/652/pipeline In the `./system/docker/prepare.sh indy-test-automation-network` step: ``` The following packages have unmet dependencies: sovrin : Depends: indy-node (= 1.5.590) but 1.13.0~dev1237 is to be installed sovtoken : Depends: indy-node (= 1.13.0~dev1210) but 1.13.0~dev1237 is to be installed E: Unable to correct problems, you have held broken packages. ERROR: Service 'node' failed to build: The command '/bin/sh -c set -ex; apt-get update && apt-get install -y sovrin=${SOVRIN_VERSION} sovtoken=${SOVTOKEN_VERSION} sovtokenfees=${SOVTOKENFEES_VERSION}; rm -rf /var/lib/apt/lists/*; fi' returned a non-zero code: 100 ```

askolesov (Fri, 12 Mar 2021 16:08:34 GMT):
That happens because of outdated Sovrin, Sovtokens, and libsovtoken packages. In short Node system tests depend not only on Indy packages but also on Sovrin packages. Sequence: 1. Tests are triggered by a push to Indy Node 2. Indy Node version is taken from the merge commit 3. Scripts try to install Sovrin, it's version is hardcoded 4. Scripts fail because Sovrin version is old, it requires old Node version but new Node is installed How to fix: 1. Build Sovrin and bump its version in Node CD scripts 2. Get rid of Sovrin dependency in Node CD. <- that's what I was working on but the work was paused. It will be resumed later.

HighBrow (Sun, 14 Mar 2021 08:17:34 GMT):
Has joined the channel.

swcurran (Sun, 14 Mar 2021 23:19:49 GMT):
Hey folks --- the Indy Contributors call is - Tuesday Match 2, 8AM Pacific, 4PM CET *(note the different time for the meeting outside of North America).* Please join us on the call -- https://wiki.hyperledger.org/display/indy/2021-03-16+Indy+Contributors+Call Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 We'll be talking about: - Status of indy-node CI/CD - Status of Ubuntu upgrade - Work to get started to support `did:indy` - extending the NYM and GET_NYM transactions and the NYM ledger object

coderatwork7 (Mon, 15 Mar 2021 08:52:22 GMT):
Has joined the channel.

Toktar (Mon, 15 Mar 2021 21:32:30 GMT):
@RobinKlemens Hello. Could you share your progress with CI for Ubuntu 20.04? If there are any pipelines for running tests, we could try them before the community call tomorrow and prepare the test results for the meeting. And we can test the GA pipelines in one go.

Toktar (Mon, 15 Mar 2021 21:41:39 GMT):
PRs for merging `stable` to `master` @WadeBarnes I analyzed your comment in PR to indy-node and suggested different options. Could you please put your opinion there, and I'll make last changes tomorrow before the community call. https://github.com/hyperledger/indy-node/pull/1665 And if there are not any concerns could you approve PR to plenum? https://github.com/hyperledger/indy-plenum/pull/1515 It's not urgent. Thanks in advance.

WadeBarnes (Mon, 15 Mar 2021 21:47:53 GMT):
I thought https://github.com/hyperledger/indy-plenum/pull/1515 it a bit more. I'm thinking the change that was introduced as part of the PR should be moved out into it's own discrete PR, leaving https://github.com/hyperledger/indy-plenum/pull/1515 as a pure merge from stable to master.

WadeBarnes (Mon, 15 Mar 2021 21:56:41 GMT):
https://github.com/hyperledger/indy-node/pull/1665 - With `pool_automation`, the files were deleted from master a long ago. I don't think they should be reintroduced. Was there a reason they were deleted from master, and left in stable? - `data/migrations/deb` - Agreed, I don't think we should be making those changes to the files in master. Of the 2 options I prefer `remove unnecessary commits from this PR`. I understand there are going to be some differences between stable and master. But we don't want to be reintroducing files that were intentionally removed, nor reverting files back to some previous state.

WadeBarnes (Mon, 15 Mar 2021 21:56:41 GMT):
https://github.com/hyperledger/indy-node/pull/1665 - With `pool_automation`, the files were deleted from master a long time ago. I don't think they should be reintroduced. Was there a reason they were deleted from master, and left in stable? - `data/migrations/deb` - Agreed, I don't think we should be making those changes to the files in master. Of the 2 options I prefer `remove unnecessary commits from this PR`. I understand there are going to be some differences between stable and master. But we don't want to be reintroducing files that were intentionally removed, nor reverting files back to some previous state.

WadeBarnes (Mon, 15 Mar 2021 21:56:41 GMT):
https://github.com/hyperledger/indy-node/pull/1665 - With `pool_automation`, the files were deleted from master a long time ago. I don't think they should be reintroduced. Was there a reason they were deleted from master, and left in stable? - `data/migrations/deb` - Agreed, I don't think we should be making those changes to the files in master. I think the changes would be reverting the files back to some previous state. Of the 2 options I prefer `remove unnecessary commits from this PR`. I understand there are going to be some differences between stable and master. But we don't want to be reintroducing files that were intentionally removed, nor reverting files back to some previous state.

Toktar (Mon, 15 Mar 2021 22:39:19 GMT):
Got it. Created a new PR https://github.com/hyperledger/indy-plenum/pull/1525 Removed this commit from PR #1515. But I used rebase, and I'm afraid that something went wrong. Check it please. The diff looks strange but ok.

Toktar (Mon, 15 Mar 2021 22:42:25 GMT):
Thank you. I'm removing unnecessary commits tomorrow.

Toktar (Mon, 15 Mar 2021 22:42:52 GMT):
Thank you. I'm removing unnecessary commits tomorrow.

RobinKlemens (Tue, 16 Mar 2021 11:11:04 GMT):
@Toktar the current the of the CI pipeline is at https://github.com/udosson/indy-plenum/tree/gha-ubuntu-20.04/.github/workflows Please, reach out to me if you have any questions

Toktar (Tue, 16 Mar 2021 11:21:25 GMT):
@RobinKlemens Wow, that's really great! I will launch on your pipelines and report the results. Perhaps I will find ideas for improving the environment.

Toktar (Tue, 16 Mar 2021 13:44:36 GMT):
@RobinKlemens Could you sign your commits for DCO passing?

WadeBarnes (Tue, 16 Mar 2021 14:13:46 GMT):
Will do.

WadeBarnes (Tue, 16 Mar 2021 14:13:59 GMT):
Thanks!

RobinKlemens (Tue, 16 Mar 2021 15:07:19 GMT):
@WadeBarnes could you take a look at my PR, please? https://github.com/hyperledger/indy-plenum/pull/1526

RobinKlemens (Tue, 16 Mar 2021 15:09:00 GMT):
Yes, sure.

RobinKlemens (Tue, 16 Mar 2021 15:11:58 GMT):
Are you able to run the tests with the CI part for Ubuntu20.04

RobinKlemens (Tue, 16 Mar 2021 15:11:58 GMT):
@Toktar Are you able to run the tests with the CI part for Ubuntu20.04?

Toktar (Tue, 16 Mar 2021 15:39:06 GMT):
@RobinKlemens Trying to run them in PR https://github.com/hyperledger/indy-plenum/pull/1522 And in my fork I have some problems too (I'm looking how to configure the repo) https://github.com/Toktar/indy-plenum/runs/2122006029?check_suite_focus=true

Toktar (Tue, 16 Mar 2021 15:43:42 GMT):
@WadeBarnes The first option turned out to be too expensive and difficult(impossible) to implement (that was mentioned no indy contributors call). So this PR is also ready for review.

RobinKlemens (Tue, 16 Mar 2021 15:49:18 GMT):
unfortunately, I won't make it to the call today. I'll reach out to you tomorrow and then we can discuss the next steps

RobinKlemens (Tue, 16 Mar 2021 15:49:18 GMT):
unfortunately, I couldn't make it to the call today. I'll reach out to you tomorrow and then we can discuss the next steps

askolesov (Wed, 17 Mar 2021 15:26:00 GMT):
Indy Plenum, Node CD thread

askolesov (Wed, 17 Mar 2021 15:37:08 GMT):
@WadeBarnes @RobinKlemens @ianco What are the plans for artifacts publishing in Node and Plenum? Have we done anything or is anyone assigned to it?

askolesov (Wed, 17 Mar 2021 15:40:50 GMT):
I think access to the following resources is necessary to complete this work: https://github.com/sovrin-foundation/jenkins-shared https://github.com/sovrin-foundation/sovrin-packaging @RobinKlemens If you want to contribute I think @WadeBarnes can give it to you.

WadeBarnes (Wed, 17 Mar 2021 15:59:21 GMT):
The plan is to follow the same process as Jenkins where possible.

WadeBarnes (Wed, 17 Mar 2021 15:59:57 GMT):
No one has been officially assigned or volunteered for the task.

WadeBarnes (Wed, 17 Mar 2021 16:00:42 GMT):
Yes, I can provide access to that repository.

WadeBarnes (Wed, 17 Mar 2021 16:01:15 GMT):
@RobinKlemens, let me know.

WadeBarnes (Wed, 17 Mar 2021 16:01:52 GMT):
Thanks

WadeBarnes (Wed, 17 Mar 2021 16:04:09 GMT):
Although it may be easier to publish the artifacts to more accessible locations.

askolesov (Wed, 17 Mar 2021 16:05:23 GMT):
Do you know any appropriate?

WadeBarnes (Wed, 17 Mar 2021 16:28:53 GMT):
@rjones, There seems to be something wrong with either the `CR_PAT` or `CR_USER` secrets for `indy-plenum`. The builds are failing when trying the login to the docker repo https://github.com/hyperledger/indy-plenum/runs/2132448665?check_suite_focus=true

WadeBarnes (Wed, 17 Mar 2021 16:29:39 GMT):
Things are working over in my repo with the same code; https://github.com/WadeBarnes/indy-plenum/runs/2132524563?check_suite_focus=true

RobinKlemens (Wed, 17 Mar 2021 17:49:42 GMT):
@WadeBarnes I can start working on this. Can you already estimate the amount of work?

WadeBarnes (Wed, 17 Mar 2021 18:16:24 GMT):
No, I don't have an estimate.

WadeBarnes (Wed, 17 Mar 2021 18:29:30 GMT):
@RobinKlemens, I ran into this error while testing the updates in my repo; https://github.com/WadeBarnes/indy-plenum/runs/2132871197?check_suite_focus=true

rjones (Wed, 17 Mar 2021 22:13:00 GMT):
@WadeBarnes PRs don't have access to secrets

rjones (Wed, 17 Mar 2021 22:13:49 GMT):
If you want to publish new images, go here: https://github.com/hyperledger/indy-plenum/actions/workflows/build.yaml and click "run workflow" on master

rjones (Wed, 17 Mar 2021 22:14:08 GMT):
(which I just did)

WadeBarnes (Wed, 17 Mar 2021 22:14:26 GMT):
So I don't have to.

WadeBarnes (Wed, 17 Mar 2021 22:14:44 GMT):
Right. Wasn't thinking.

rjones (Wed, 17 Mar 2021 22:15:09 GMT):
should probably have a distinct job to build on merge to master just for publication

WadeBarnes (Wed, 17 Mar 2021 22:16:17 GMT):
Only wrinkle there is when the PR changes the dockerfile and invalidates the cache in the process.

WadeBarnes (Wed, 17 Mar 2021 22:16:33 GMT):
Something to think about.

rjones (Wed, 17 Mar 2021 22:16:47 GMT):
Basically: ```on: # Triggers the workflow on push or pull request events but only for the master branch push: branches: [ master ]```

WadeBarnes (Wed, 17 Mar 2021 22:16:52 GMT):
Shouldn't happen very often.

rjones (Wed, 17 Mar 2021 22:19:06 GMT):
I'm speculating: what about a ci-update branch with a trigger for those cases?

rjones (Wed, 17 Mar 2021 22:19:20 GMT):
you can merge to it to publish, then cherry-pick the change to `master`

rjones (Wed, 17 Mar 2021 22:19:28 GMT):
I've put all of 2 seconds thinking into this

RobinKlemens (Thu, 18 Mar 2021 11:34:39 GMT):
@WadeBarnes thanks for letting my know. I updated my PR with a fix for the error `'./cache/3rd-party-dependencies/': Not a directory`

WadeBarnes (Thu, 18 Mar 2021 12:42:04 GMT):
Pushed for testing; https://github.com/WadeBarnes/indy-plenum/actions/runs/664540395

RobinKlemens (Thu, 18 Mar 2021 13:23:33 GMT):
@WadeBarnes Test slice no. 8 failed. Do this frequently happen?

WadeBarnes (Thu, 18 Mar 2021 13:25:19 GMT):
There are a few tests that are timing dependent which fail occasionally. There is some work being done to address the issue.

WadeBarnes (Thu, 18 Mar 2021 13:25:45 GMT):
Rerunning the build.

RobinKlemens (Thu, 18 Mar 2021 13:31:09 GMT):
Can you create secrets for the ssh and gpg key that is used in sovrin packaging? Then we can use the following to github actions use them in the publishing steps: ssh agent: https://github.com/marketplace/actions/webfactory-ssh-agent import gpg: https://github.com/marketplace/actions/import-gpg

WadeBarnes (Thu, 18 Mar 2021 13:42:07 GMT):
I'll have a look.

rjones (Thu, 18 Mar 2021 13:56:54 GMT):
I've had slice 8 fail a few times.

RobinKlemens (Thu, 18 Mar 2021 15:32:45 GMT):
Now it's slice 2 that failed

WadeBarnes (Thu, 18 Mar 2021 15:33:42 GMT):
Timing related failure again. Re-running.

rjones (Thu, 18 Mar 2021 15:35:20 GMT):
I wonder if these could be distinct jobs, instead of parts of one job, so we could re-run specific slices

WadeBarnes (Thu, 18 Mar 2021 15:37:35 GMT):
There is work being/been done on another branch/PR to help make the tests more stable.

WadeBarnes (Thu, 18 Mar 2021 15:39:18 GMT):
Because many of the tests are based on the consensus between nodes, there is always a fine line of how long you wait for consensus before failing the test.

WadeBarnes (Thu, 18 Mar 2021 15:40:12 GMT):
There is/should be room for improvement though.

esplinr (Thu, 18 Mar 2021 20:46:04 GMT):
Should we be publishing the Indy Debian artifacts to a PPA on Launchpad? https://askubuntu.com/questions/71510/how-do-i-create-a-ppa

askolesov (Fri, 19 Mar 2021 06:49:15 GMT):
If I got it right Launchpad is a GPG key registry, content should be hosted somewhere else. Here is a fun example of hosting PPA in github: https://assafmo.github.io/2019/05/02/ppa-repo-hosted-on-github.html

WadeBarnes (Fri, 19 Mar 2021 17:03:48 GMT):
@RobinKlemens, PR has been merged.

mbanerjee (Fri, 19 Mar 2021 19:06:40 GMT):
Has joined the channel.

mbanerjee (Fri, 19 Mar 2021 19:06:40 GMT):
Trying to bring up indy (docker) instance and it fails - Any suggestions @WadeBarnes @andrew.whitehead 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

andrew.whitehead (Fri, 19 Mar 2021 19:31:12 GMT):
I don’t know what jupyter has to do with it, that’s not an Indy dependency

WadeBarnes (Fri, 19 Mar 2021 19:34:00 GMT):
@mbanerjee, Where is the Dockerfile you're using?

mbanerjee (Fri, 19 Mar 2021 19:52:51 GMT):
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 I get that error.

mbanerjee (Fri, 19 Mar 2021 19:53:22 GMT):
git clone https://github.com/hyperledger/indy-sdk.git

esplinr (Fri, 19 Mar 2021 20:24:21 GMT):
The person who half setup readthedocs added jupyter as a dependency. That should probably be removed.

WadeBarnes (Fri, 19 Mar 2021 20:26:17 GMT):
Thanks @esplinr, I was just tracking the issue: https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/docker-compose.yml#L29 https://github.com/hyperledger/indy-sdk/blob/master/docs/getting-started/getting-started.dockerfile#L19

esplinr (Fri, 19 Mar 2021 20:26:47 GMT):
I'm pretty sure that Launchpad hosts PPA binaries, but that GitHub hosting approach also looks like a good option.

WadeBarnes (Fri, 19 Mar 2021 20:26:50 GMT):
Looks more like it can't find the `ipython-notebook` package.

esplinr (Fri, 19 Mar 2021 20:27:17 GMT):
Yeah, that's all related to Michael's work on ReadTheDocs. It should probably all be reversed.

esplinr (Fri, 19 Mar 2021 20:27:17 GMT):
Yeah, I believe that's all related to the work on ReadTheDocs. It should probably all be reversed.

WadeBarnes (Fri, 19 Mar 2021 20:31:34 GMT):
@mbanerjee, This getting started guide should provide a path of less resistance; https://github.com/hyperledger/aries-cloudagent-python/blob/main/docs/GettingStartedAriesDev/README.md

mbanerjee (Fri, 19 Mar 2021 21:09:07 GMT):
Thanks

RobinKlemens (Sat, 20 Mar 2021 08:52:57 GMT):
Either way could work. However, I think moving away from the sovrin repo to a more "independent" place like GitHub or Launchpad is the way to go. And yes, Launchpad hosts PPA binaries. Each PPA gets 2 GiB of disk space but we could ask for more.

WadeBarnes (Sat, 20 Mar 2021 11:32:54 GMT):
I completely agree. We want to publish the artifacts in a more independent and accessible location.

rjones (Mon, 22 Mar 2021 17:47:17 GMT):
Hey @WadeBarnes check [this out](https://github.com/ryjones/besu/blob/265c9ffa2e901cdb493713c3bf03abd6e0300dde/.github/workflows/repolinter.yml#L25-L29) - maybe this would work for report publishing?

rjones (Mon, 22 Mar 2021 18:04:19 GMT):
Hey, @Toktar , I was looking at your PR so I could rebase it for merging, and there is a conflict. https://github.com/Toktar/indy-node/tree/up-41-set-fees there was a conflict - I think the correct action is to take both lines?

rjones (Mon, 22 Mar 2021 18:04:22 GMT):
```<<<<<<< HEAD from indy_node.server.request_handlers.config_req_handlers.ledgers_freeze_handler import LedgersFreezeHandler ======= from indy_node.server.request_handlers.config_req_handlers.fees.set_fees_handler import SetFeesHandler >>>>>>> 8bf5df5c... UP-41: add set and get fees handlers ```

rjones (Mon, 22 Mar 2021 18:04:44 GMT):
this is the PR I was rebasing: https://github.com/hyperledger/indy-node/pull/1653

Toktar (Mon, 22 Mar 2021 21:13:49 GMT):
@rjones Yes, using both imports is the right decision. But I believe before this PR we need to merge https://github.com/hyperledger/indy-node/pull/1665 After merging, I'll make the PR with set fees actual.

esplinr (Mon, 22 Mar 2021 22:15:19 GMT):
And cheaply maintained location! grin

esplinr (Mon, 22 Mar 2021 22:15:52 GMT):
@rjones What do other Hyperledger projects do for hosting Debian packages?

rjones (Mon, 22 Mar 2021 22:27:08 GMT):
OK. I have rebased it

rjones (Mon, 22 Mar 2021 22:27:55 GMT):
we're paying for artifactory, but I don't know of anyone else publishing `.deb` files

rjones (Mon, 22 Mar 2021 22:29:44 GMT):
@esplinr https://hyperledger.jfrog.io/ui/repos/tree/General/artifactory-build-info

rjones (Mon, 22 Mar 2021 22:31:58 GMT):
https://www.jfrog.com/confluence/display/JFROG/Debian+Repositories

WadeBarnes (Mon, 22 Mar 2021 22:46:54 GMT):
Seems like that would be good place to publish artifacts for a hyperledger project.

rjones (Mon, 22 Mar 2021 23:04:03 GMT):
the disadvantage of using Artifactory is it is yet _one more place_ to manage ACLs. GitHub packages, if it supports `.deb` files, can be managed entirely within GitHub

WadeBarnes (Tue, 23 Mar 2021 00:36:16 GMT):
Like that idea too.

esplinr (Tue, 23 Mar 2021 05:14:36 GMT):
I knew @rjones would already have a solution set up for us!

esplinr (Tue, 23 Mar 2021 05:15:04 GMT):
:rocket:

RobinKlemens (Tue, 23 Mar 2021 13:03:42 GMT):
Have we already decided which way to go? At the moment we have the following options to publish the artifacts (deb files): - Launchpad - GitHub Repository - GitHub Packages - Artifactory (Hyperledger)

WadeBarnes (Tue, 23 Mar 2021 13:05:15 GMT):
I think the best 2 choices in order are: - GitHub Packages - Artifactory (Hyperledger)

askolesov (Tue, 23 Mar 2021 13:05:50 GMT):
GitHub packages don't support .deb

askolesov (Tue, 23 Mar 2021 13:07:26 GMT):
Only docker, npm, maven, nuget and ruby gems are supported: https://github.com/features/packages

WadeBarnes (Tue, 23 Mar 2021 13:11:05 GMT):
So Artifactory (Hyperledger) it is.

rjones (Tue, 23 Mar 2021 13:11:55 GMT):
Ok

WadeBarnes (Tue, 23 Mar 2021 13:12:29 GMT):
@rjones, are you able to facilitate?

rjones (Tue, 23 Mar 2021 13:13:10 GMT):
Yes

rjones (Tue, 23 Mar 2021 13:13:20 GMT):
Artifactory

rjones (Tue, 23 Mar 2021 13:13:44 GMT):
@WadeBarnes who will admin this on your side?

rjones (Tue, 23 Mar 2021 13:14:49 GMT):
I need an email address

WadeBarnes (Tue, 23 Mar 2021 13:15:52 GMT):
That's a great question. Me for sure. I'd also like to see two other admins; members of the existing contributors.

rjones (Tue, 23 Mar 2021 13:16:16 GMT):
To get the ball rolling, please give me one. :)

WadeBarnes (Tue, 23 Mar 2021 13:16:51 GMT):
Does that email need to be tied to a GitHub account?

rjones (Tue, 23 Mar 2021 13:18:29 GMT):
No, this is yet another random ACL to manage, so the email could be from anywhere

WadeBarnes (Tue, 23 Mar 2021 13:20:43 GMT):
DMed

WadeBarnes (Tue, 23 Mar 2021 13:42:49 GMT):
@RobinKlemens, @askolesov, I'm in.

WadeBarnes (Tue, 23 Mar 2021 13:43:19 GMT):
From @rjones; It's pretty easy to get publishing rolling, you can look at how Besu is publishing from CCI for instance

WadeBarnes (Tue, 23 Mar 2021 13:43:53 GMT):
What repositories do we need and what do we want to call them?

askolesov (Tue, 23 Mar 2021 13:47:10 GMT):
Maybe Indy stable, Indy ... (not stable) and the same for Sovrin?

rjones (Tue, 23 Mar 2021 13:48:02 GMT):
https://github.com/hyperledger/besu/blob/a58c472480a46a4020383e264fed61e20a05bee4/.circleci/config.yml#L224-L248

rjones (Tue, 23 Mar 2021 13:48:34 GMT):
please don't publish Sovrin specific packages on Hyperledger's accounts

askolesov (Tue, 23 Mar 2021 13:49:17 GMT):
Oh, my bad, forgot about it

WadeBarnes (Tue, 23 Mar 2021 14:07:14 GMT):
Let's discuss the configuration here; https://github.com/hyperledger/indy-node/issues/1675

WadeBarnes (Tue, 23 Mar 2021 14:07:40 GMT):
I added the reference Ry provided.

mccown (Thu, 25 Mar 2021 14:44:52 GMT):
The Identity Implementer's WG is starting at the top of the hour (9am MT / 3pm UTC). In the call, I'll be going over a way to simplify creating language wrappers for Rust libraries. Some of you have asked about this, so I thought I'd mention it here. Zoom: https://zoom.us/my/hyperledger.community.3?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09 Wiki: https://wiki.hyperledger.org/display/IWG/2021-03-25+%3A+Identity+Implementers+WG+Call

devinleighsmith (Fri, 26 Mar 2021 01:47:00 GMT):
Has joined the channel.

devinleighsmith (Fri, 26 Mar 2021 01:47:00 GMT):
Does anyone know if there are plans to release focal (ubuntu 20.04) packages for libindy and libindy-crypto?

WadeBarnes (Fri, 26 Mar 2021 15:36:44 GMT):
@Toktar, @RobinKlemens, @devinleighsmith, is working on the Ubuntu 20.04 upgrade of the `token-plugin`, any guidance, advice, or answers you can provide would be greatly appreciated. cc @esplinr

devinleighsmith (Fri, 26 Mar 2021 15:39:17 GMT):
for reference, this is what I'm running into: libindy : Depends: libssl1.0.0 but it is not installable libindy-crypto : Depends: libssl1.0.0 but it is not installable 20.04 ships with libssl 1.1.0, not sure if I need to work around this or just grab newer versions of these lib* packages.

esplinr (Fri, 26 Mar 2021 15:43:10 GMT):
indy-crypto has been replaced with Ursa. No one is currently working on upgrading LibIndy to Ubuntu 20.04.

devinleighsmith (Fri, 26 Mar 2021 15:43:57 GMT):
alright, that helps.

WadeBarnes (Fri, 26 Mar 2021 15:48:40 GMT):
@devinleighsmith, you should be able to find reference PRs for indy-plenum regarding the move from `indy-crypto` to `Ursa`.

RobinKlemens (Fri, 26 Mar 2021 15:53:44 GMT):
@devinleighsmith in case you're looking for a Docker file for testing purposes with `indy-crypto` and `libindy` you can use the following https://github.com/adenishchenko/indy-plenum/blob/ubuntu-20.04/.github/workflows/build/Dockerfile.ubuntu-20-04

WadeBarnes (Fri, 26 Mar 2021 16:00:05 GMT):
Ursa related PRs: https://github.com/hyperledger/indy-plenum/pulls?q=is%3Apr+is%3Aclosed+ursa https://github.com/hyperledger/indy-node/pulls?q=is%3Apr+ursa+is%3Aclosed and specifically this one; https://github.com/hyperledger/indy-node/pull/1607

swcurran (Tue, 30 Mar 2021 02:48:49 GMT):
Hey folks --- the Indy Contributors call is - Tuesday March 30, 8AM Pacific, 5PM CET Please join us on the call -- https://wiki.hyperledger.org/display/indy/2021-03-30+Indy+Contributors+Call Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 We'll be talking about: Status of indy-node CI/CD Status of Ubuntu upgrade Indy DID Method Spec – actions

esplinr (Tue, 30 Mar 2021 04:14:35 GMT):
Unfortunately I am unable to attend the call tomorrow, but members of the Evernym team should be there. I believe our work on the next Indy release is done, so we've moved our focus to our next project. Let us know if anyone sees that differently.

antonden (Wed, 31 Mar 2021 13:49:26 GMT):
Hello, @RobinKlemens! How is CI/CD pipeline progressing for Indy-Node? could I help somehow?

RobinKlemens (Wed, 31 Mar 2021 16:39:27 GMT):
Hi @antonden. I haven't started on Indy-Node yet and unfortunately I won't have time to work on this before April 20. However, I would take a look at https://github.com/adenishchenko/indy-plenum/tree/ubuntu-20.04/.github/workflows and follow the same logic

RobinKlemens (Wed, 31 Mar 2021 16:39:41 GMT):
I very much appreciate your help!!

WadeBarnes (Wed, 31 Mar 2021 20:38:24 GMT):
Here is a summary of what would be needed; https://github.com/hyperledger/indy-plenum/pull/1522#issuecomment-810531932

WadeBarnes (Wed, 31 Mar 2021 20:38:24 GMT):
Here is a summary of what would be needed to pull the CI and CD portions together more.; https://github.com/hyperledger/indy-plenum/pull/1522#issuecomment-810531932

WadeBarnes (Wed, 31 Mar 2021 20:38:24 GMT):
Here is a summary of what would be needed to pull the CI and CD portions together more; https://github.com/hyperledger/indy-plenum/pull/1522#issuecomment-810531932

WadeBarnes (Wed, 31 Mar 2021 20:39:38 GMT):
@antonden, Excited to have the additional help.

WadeBarnes (Wed, 31 Mar 2021 20:39:38 GMT):
@antonden, Excited to have the additional help. Thank-you

echsecutor (Mon, 05 Apr 2021 20:22:13 GMT):
Has joined the channel.

devinleighsmith (Wed, 07 Apr 2021 17:07:28 GMT):
Bit of a long shot, but hoping someone more familiar with the indy* code may have seen something like this before. During test setup in the token-plugin, the nodes fail to connect to each other. More specifically, there are four nodes, alpha, beta, gamma, delta. All of the nodes seem to be able to connect to alpha, but the setup will timeout before the other nodes connect. Increasing the timeout of the test doesn't seem to help. Here is a snippet of the error, in hopes that @Toktar or @antonden has seen something similar before: agent_1 | NOTIFICATION stp_core.common.log:keep_in_touch.py:66 Delta’s connections changed from {‘Alpha’} to {‘Gamma’, ‘Alpha’, ‘Beta’} agent_1 | NOTIFICATION stp_core.common.log:keep_in_touch.py:91 CONNECTION: Delta now connected to Beta agent_1 | NOTIFICATION stp_core.common.log:keep_in_touch.py:91 CONNECTION: Delta now connected to Gamma agent_1 | INFO stp_core.common.log:motor.py:33 Delta changing status from starting to started agent_1 | TRACE stp_core.common.log:remote.py:164 Event: {‘event’: 4096, ‘value’: 0, ‘endpoint’: b’tcp://127.0.0.1:0;127.0.0.1:6001’} agent_1 | TRACE stp_core.common.log:remote.py:119 Remote Alpha:HA(host=’127.0.0.1’, port=6001) has monitor events: [4096] agent_1 | DEBUG stp_core.common.log:node.py:1257 Delta choosing to start election on the basis of count 4 and nodes {‘Gamma’, ‘Alpha’, ‘Beta’} agent_1 | DEBUG stp_core.common.log:node.py:2983 Delta sending message LEDGER_STATUS{‘ledgerId’: 0, ‘txnSeqNo’: 4, ‘viewNo’: None, ‘ppSeqNo’: None, ‘merkleRoot’: ‘38dJSTuhPsur1VbV3LuMmESRXxsdkg8n8MPSG32cVP1C’, ‘protocolVersion’: 2} to 1 recipients: [‘Beta’] agent_1 | DEBUG stp_core.common.log:node.py:2983 Delta sending message LEDGER_STATUS{‘ledgerId’: 0, ‘txnSeqNo’: 4, ‘viewNo’: None, ‘ppSeqNo’: None, ‘merkleRoot’: ‘38dJSTuhPsur1VbV3LuMmESRXxsdkg8n8MPSG32cVP1C’, ‘protocolVersion’: 2} to 1 recipients: [‘Gamma’] agent_1 | TRACE stp_core.common.log:zstack.py:549 Alpha got 9 messages through listener agent_1 | TRACE stp_core.common.log:zstack.py:777 Alpha got ping from Beta agent_1 | TRACE stp_core.common.log:zstack.py:852 Alpha transmitting message b’po’ to Beta by socket 510 39930560 agent_1 | DEBUG stp_core.common.log:zstack.py:758 Alpha ponged Beta agent_1 | TRACE stp_core.common.log:zstack.py:777 Alpha got ping from Gamma agent_1 | TRACE stp_core.common.log:zstack.py:852 Alpha transmitting message b’po’ to Gamma by socket 516 40946032 agent_1 | DEBUG stp_core.common.log:zstack.py:758 Alpha ponged Gamma agent_1 | TRACE stp_core.common.log:zstack.py:777 Alpha got ping from Delta agent_1 | TRACE stp_core.common.log:zstack.py:852 Alpha transmitting message b’po’ to Delta by socket 514 40907632 agent_1 | DEBUG stp_core.common.log:zstack.py:758 Alpha ponged Delta agent_1 | TRACE stp_core.common.log:zstack.py:791 Alpha got pong from Beta agent_1 | TRACE stp_core.common.log:zstack.py:791 Alpha got pong from Gamma agent_1 | TRACE stp_core.common.log:zstack.py:791 Alpha got pong from Delta agent_1 | DEBUG stp_core.common.log:eventually.py:174 partial(check_node_connected) succeeded with 19.50 seconds to spare agent_1 | DEBUG stp_core.common.log:eventually.py:174 partial(check_node_connected) succeeded with 19.50 seconds to spare agent_1 | DEBUG stp_core.common.log:eventually.py:174 partial(check_node_connected) succeeded with 19.50 seconds to spare … agent_1 | DEBUG stp_core.common.log:eventually.py:161 partial(check_node_connected) last try… *agent_1 | ERROR stp_core.common.log:eventually.py:188 partial(check_node_connected) failed; not trying any more because 19.49565719999373 seconds have passed; args were () agent_1 | DEBUG stp_core.common.log:eventually.py:96 a coro partial(check_node_connected) with args (Delta, {Beta, Gamma, Alpha}) timed out without succeeding; fail count: 1, acceptable: 0* agent_1 | ERROR stp_core.common.log:looper.py:253 Error while running coroutine checkNodesConnected: AssertionError(‘assert False\n + where False = all([False, False, True])’) agent_1 | INFO stp_core.common.log:motor.py:33 Delta changing status from started to stopping agent_1 | INFO stp_core.common.log:node.py:3063 node Delta current stats

devinleighsmith (Wed, 07 Apr 2021 17:07:28 GMT):
Bit of a long shot, but hoping someone more familiar with the indy* code may have seen something like this before. During test setup in the token-plugin, the nodes fail to connect to each other. More specifically, there are four nodes, alpha, beta, gamma, delta. All of the nodes seem to be able to connect to alpha, but the setup will timeout before the other nodes connect. Increasing the timeout of the test doesn't seem to help. Here is a snippet of the error, in hopes that @Toktar or @antonden has seen something similar before: agent_1 | NOTIFICATION stp_core.common.log:keep_in_touch.py:66 Delta’s connections changed from {‘Alpha’} to {‘Gamma’, ‘Alpha’, ‘Beta’} agent_1 | NOTIFICATION stp_core.common.log:keep_in_touch.py:91 CONNECTION: Delta now connected to Beta agent_1 | NOTIFICATION stp_core.common.log:keep_in_touch.py:91 CONNECTION: Delta now connected to Gamma agent_1 | INFO stp_core.common.log:motor.py:33 Delta changing status from starting to started agent_1 | TRACE stp_core.common.log:remote.py:164 Event: {‘event’: 4096, ‘value’: 0, ‘endpoint’: b’tcp://127.0.0.1:0;127.0.0.1:6001’} agent_1 | TRACE stp_core.common.log:remote.py:119 Remote Alpha:HA(host=’127.0.0.1’, port=6001) has monitor events: [4096] agent_1 | DEBUG stp_core.common.log:node.py:1257 Delta choosing to start election on the basis of count 4 and nodes {‘Gamma’, ‘Alpha’, ‘Beta’} agent_1 | DEBUG stp_core.common.log:node.py:2983 Delta sending message LEDGER_STATUS{‘ledgerId’: 0, ‘txnSeqNo’: 4, ‘viewNo’: None, ‘ppSeqNo’: None, ‘merkleRoot’: ‘38dJSTuhPsur1VbV3LuMmESRXxsdkg8n8MPSG32cVP1C’, ‘protocolVersion’: 2} to 1 recipients: [‘Beta’] agent_1 | DEBUG stp_core.common.log:node.py:2983 Delta sending message LEDGER_STATUS{‘ledgerId’: 0, ‘txnSeqNo’: 4, ‘viewNo’: None, ‘ppSeqNo’: None, ‘merkleRoot’: ‘38dJSTuhPsur1VbV3LuMmESRXxsdkg8n8MPSG32cVP1C’, ‘protocolVersion’: 2} to 1 recipients: [‘Gamma’] agent_1 | TRACE stp_core.common.log:zstack.py:549 Alpha got 9 messages through listener agent_1 | TRACE stp_core.common.log:zstack.py:777 Alpha got ping from Beta agent_1 | TRACE stp_core.common.log:zstack.py:852 Alpha transmitting message b’po’ to Beta by socket 510 39930560 agent_1 | DEBUG stp_core.common.log:zstack.py:758 Alpha ponged Beta agent_1 | TRACE stp_core.common.log:zstack.py:777 Alpha got ping from Gamma agent_1 | TRACE stp_core.common.log:zstack.py:852 Alpha transmitting message b’po’ to Gamma by socket 516 40946032 agent_1 | DEBUG stp_core.common.log:zstack.py:758 Alpha ponged Gamma agent_1 | TRACE stp_core.common.log:zstack.py:777 Alpha got ping from Delta agent_1 | TRACE stp_core.common.log:zstack.py:852 Alpha transmitting message b’po’ to Delta by socket 514 40907632 agent_1 | DEBUG stp_core.common.log:zstack.py:758 Alpha ponged Delta agent_1 | TRACE stp_core.common.log:zstack.py:791 Alpha got pong from Beta agent_1 | TRACE stp_core.common.log:zstack.py:791 Alpha got pong from Gamma agent_1 | TRACE stp_core.common.log:zstack.py:791 Alpha got pong from Delta agent_1 | DEBUG stp_core.common.log:eventually.py:174 partial(check_node_connected) succeeded with 19.50 seconds to spare agent_1 | DEBUG stp_core.common.log:eventually.py:174 partial(check_node_connected) succeeded with 19.50 seconds to spare agent_1 | DEBUG stp_core.common.log:eventually.py:174 partial(check_node_connected) succeeded with 19.50 seconds to spare … agent_1 | DEBUG stp_core.common.log:eventually.py:161 partial(check_node_connected) last try… *agent_1 | ERROR stp_core.common.log:eventually.py:188 partial(check_node_connected) failed; not trying any more because 19.49565719999373 seconds have passed; args were ()* *agent_1 | DEBUG stp_core.common.log:eventually.py:96 a coro partial(check_node_connected) with args (Delta, {Beta, Gamma, Alpha}) timed out without succeeding; fail count: 1, acceptable: 0* agent_1 | ERROR stp_core.common.log:looper.py:253 Error while running coroutine checkNodesConnected: AssertionError(‘assert False\n + where False = all([False, False, True])’) agent_1 | INFO stp_core.common.log:motor.py:33 Delta changing status from started to stopping agent_1 | INFO stp_core.common.log:node.py:3063 node Delta current stats

WadeBarnes (Fri, 09 Apr 2021 14:11:21 GMT):
@Toktar, @askolesov, @antonden, cc @RobinKlemens, @esplinr: @devinleighsmith uncovered some false positives in the output of these test results; https://github.com/hyperledger/indy-plenum/actions/runs/726586406, which are based off the merge of the [Upgrade Ubuntu 20.04](https://github.com/hyperledger/indy-plenum/pull/1522) work. The plenum test slices are falsely passing because `runner.py` was not updated for the newer python version and was not detecting any tests; so the jobs are passing because no tests are run at all. @devinleighsmith has updated `runner.py`, [Update runner to be compatible with python 3.8, pytest 6.2.2](https://github.com/hyperledger/indy-plenum/pull/1530), which has surfaced a number of failing `plenum` tests; https://github.com/hyperledger/indy-plenum/actions/runs/731671722. The results on Devin's fork may be easier to navigate since they don't contain the report upload failures seen in the `indy-plenum` fork's run; https://github.com/devinleighsmith/indy-plenum/actions/runs/731553669 Would someone be able to have a look and provide an assessment of what could be causing the test failures. From what I understood the tests should be working.

WadeBarnes (Fri, 09 Apr 2021 14:18:15 GMT):
@Toktar, @askolesov, @antonden, Would you be able to provide the steps you were using to run the tests locally?

Toktar (Fri, 09 Apr 2021 14:23:55 GMT):
Hello. These instructions should work for Ubuntu 20.04 https://github.com/hyperledger/indy-plenum/blob/ubuntu-20.04-upgrade/dev-setup/ubuntu/ubuntu-2004/SetupVMTest.txt

WadeBarnes (Fri, 09 Apr 2021 15:03:32 GMT):
Thanks

WadeBarnes (Fri, 09 Apr 2021 15:03:38 GMT):
@devinleighsmith ^

WadeBarnes (Fri, 09 Apr 2021 16:48:05 GMT):
@Toktar , @askolesov, Any thoughts on what could be causing these errors in the `indy-sdk` tests? https://build.sovrin.org/blue/organizations/jenkins/indy-sdk%2Findy-sdk-ci/detail/PR-2354/27/pipeline

rjones (Fri, 09 Apr 2021 16:57:19 GMT):
what would it take to migrate `indy-sdk` to GitHub actions completely?

WadeBarnes (Fri, 09 Apr 2021 17:23:12 GMT):
The PR I'm trying the merge is a major step in that direction. Although right now the rule (until the GHA workflows are complete and verified) is that the existing pipelines need to pass.

WadeBarnes (Fri, 09 Apr 2021 17:24:19 GMT):
The goal is to move all of the projects over to GHA, so I can decommission the Sovrin Jenkins infrastructure.

WadeBarnes (Fri, 09 Apr 2021 17:26:46 GMT):
The shorter answer is we need contributors who are willing and able to put in the work to migrate the rest of the bits of the pipelines.

rjones (Fri, 09 Apr 2021 17:34:23 GMT):
I'm willing to do a rough-and-ready move. It won't be high fidelity - that, I assert, can come later.

rjones (Fri, 09 Apr 2021 17:34:33 GMT):
But I assert a lot of things that turn out not to be true :)

WadeBarnes (Fri, 09 Apr 2021 17:38:53 GMT):
lol. For `indy-sdk` Miroslav Kovar's PR, https://github.com/hyperledger/indy-sdk/pull/2354, would be the starting place for such an effort.

WadeBarnes (Fri, 09 Apr 2021 21:43:27 GMT):
@Toktar, @askolesov, @antonden, cc @RobinKlemens, @esplinr: Further to the test automation failures, we've updated the test so they report the individual test failures and upload the detailed logs for the failed runs; https://github.com/WadeBarnes/indy-plenum/actions/runs/734275668 The detailed reports for the test failures can be found here; https://github.com/WadeBarnes/indy-plenum/actions/runs/734275668#artifacts Many of the failed tests are due to pool startup issues. It looks like the nodes are failing to start because they can't serialize transactions. We're also seeing a lot of `failed on setup with "NotImplementedError: use ``sl.add(value)`` instead"` failures, details can be found in the **Raw output** of these test results; https://github.com/WadeBarnes/indy-plenum/runs/2309370032?check_suite_focus=true

WadeBarnes (Fri, 09 Apr 2021 21:43:27 GMT):
@Toktar, @askolesov, @antonden, cc @RobinKlemens, @esplinr: Further to the test automation failures, we've updated the test runner so it reports the individual test failures and upload the detailed logs for the failed runs; https://github.com/WadeBarnes/indy-plenum/actions/runs/734275668 The detailed reports for the test failures can be found here; https://github.com/WadeBarnes/indy-plenum/actions/runs/734275668#artifacts Many of the failed tests are due to pool startup issues. It looks like the nodes are failing to start because they can't serialize transactions. We're also seeing a lot of `failed on setup with "NotImplementedError: use ``sl.add(value)`` instead"` failures, details can be found in the **Raw output** of these test results; https://github.com/WadeBarnes/indy-plenum/runs/2309370032?check_suite_focus=true

WadeBarnes (Fri, 09 Apr 2021 21:43:27 GMT):
@Toktar, @askolesov, @antonden, cc @RobinKlemens, @esplinr: Further to the test automation failures, we've updated the test runner so it reports the individual test failures and uploads the detailed logs for the failed runs; https://github.com/WadeBarnes/indy-plenum/actions/runs/734275668 The detailed reports for the test failures can be found here; https://github.com/WadeBarnes/indy-plenum/actions/runs/734275668#artifacts Many of the failed tests are due to pool startup issues. It looks like the nodes are failing to start because they can't serialize transactions. We're also seeing a lot of `failed on setup with "NotImplementedError: use ``sl.add(value)`` instead"` failures, details can be found in the **Raw output** of these test results; https://github.com/WadeBarnes/indy-plenum/runs/2309370032?check_suite_focus=true

WadeBarnes (Fri, 09 Apr 2021 21:54:39 GMT):
If some could have a look and see if there is anything obvious that stands out, it would be appreciated.

andrew.whitehead (Fri, 09 Apr 2021 22:02:05 GMT):
It looks like NotImplementedErrors are coming from sortedcontainers.SortedList, as used in plenum/server/replica.py and other places. The `__setitem__`, `append`, `extend`, and `insert` methods are deprecated

andrew.whitehead (Fri, 09 Apr 2021 22:04:02 GMT):
https://github.com/grantjenks/python-sortedcontainers/blob/9887989b21fc21fe572e0b4c30a3f3aa1eabbdca/HISTORY.rst#200-2018-05-18

WadeBarnes (Mon, 12 Apr 2021 11:55:02 GMT):
@devinleighsmith, did these errors mostly go away after you pinned the dependencies to the list provided here: https://chat.hyperledger.org/channel/indy-contributors?msg=XgLC7eBNGq46XBMvK?

WadeBarnes (Mon, 12 Apr 2021 12:12:32 GMT):
Thanks, @andrew.whitehead

devinleighsmith (Mon, 12 Apr 2021 16:14:25 GMT):
Yes, using the pinned dependency versions based on those instructions resolved the majority of the errors.

WadeBarnes (Mon, 12 Apr 2021 16:29:45 GMT):
@Toktar, @askolesov, @antonden cc @esplinr Was there a plan to make a second pass at upgrading the dependencies once the tests were working so we're using recent and supported versions rather than obsolete versions? The plan all along has been to upgrade things to recent supported versions so we don't have to pin dependencies to older (obsolete) versions which then makes it easier to maintain and upgrade the code incrementally moving forwarded.

WadeBarnes (Mon, 12 Apr 2021 16:31:49 GMT):
We can help with this.

WadeBarnes (Mon, 12 Apr 2021 16:33:23 GMT):
Do you have any insight into where it was absolutely necessary to pin dependencies to old versions in order for things to work?

WadeBarnes (Mon, 12 Apr 2021 16:34:16 GMT):
So we're not exploring issues you've already uncovered.

askolesov (Mon, 12 Apr 2021 18:08:17 GMT):
As far as I remember we wanted to update them. @Toktar @esplinr Am I right?

askolesov (Mon, 12 Apr 2021 18:09:11 GMT):
Here is a notice explaining why I closed the PR in test-automation: https://github.com/hyperledger/indy-test-automation/issues/102

esplinr (Mon, 12 Apr 2021 22:08:35 GMT):
I thought that Robin had updated them.

esplinr (Mon, 12 Apr 2021 22:09:00 GMT):
We intended to do it, but I thought Kevin or Robin did it as part of their work on the pipeline.

esplinr (Mon, 12 Apr 2021 22:09:10 GMT):
I agree that it needs to be done.

esplinr (Mon, 12 Apr 2021 22:10:41 GMT):
Note that I enabled the issues feature in GitHub for the indy-test-automation repo so that we have a place to keep concerns like the one Alex documented.

swcurran (Tue, 13 Apr 2021 02:31:45 GMT):
Hey folks --- the Indy Contributors call is - Tuesday April 13, 8AM Pacific, 5PM CET Please join us on the call -- https://wiki.hyperledger.org/display/indy/2021-04-13+Indy+Contributors+Call Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 We'll be talking about: Status of indy-node CI/CD Status of Ubuntu upgrade

devinleighsmith (Tue, 13 Apr 2021 06:02:03 GMT):
Getting a timeout from indy_open_pool_ledger in the *unit tests* for token-plugin: `/usr/local/lib/python3.8/dist-packages/indy/pool.py:85: PoolLedgerTimeout` Tried adding RUST_LOG=trace to get additional logging from the rust code (https://github.com/hyperledger/indy-sdk/blob/master/libindy/src/api/pool.rs) but I'm not seeing anything extra. Any suggestions?

devinleighsmith (Tue, 13 Apr 2021 06:02:54 GMT):
guessing I have some kind of dependency issue but hard to track down with the limited logging.

Toktar (Tue, 13 Apr 2021 12:28:11 GMT):
@WadeBarnes We upgraded almost all dependencies and leave old versions which changing doesn't need a lot of updates in a code base. Because all changes in the code base without additional testing are risky. Thanks @andrew.whitehead for figuring out the deprecated methods issue. I asked @antonden for upgrading Sortedcontainers version and check which dependencies we can use without pinning. FYI @esplinr

WadeBarnes (Tue, 13 Apr 2021 13:51:14 GMT):
Latest GHA test run for the Ubuntu 20.04 upgrade branch can be found here; https://github.com/hyperledger/indy-plenum/actions/runs/742714538

WadeBarnes (Tue, 13 Apr 2021 14:03:05 GMT):
https://github.com/hyperledger/indy-plenum/commit/a03e065072d2af3976a9334ba3bb66b229d08714#diff-b4e94244b3aee1acdd73a4aed9bd9d1ffd34fbbbbb5cd26efdb83d5527894991 Contains all of the pinned discrepancies from https://github.com/hyperledger/indy-plenum/blob/ubuntu-20.04-upgrade/dev-setup/ubuntu/ubuntu-2004/SetupVMTest.txt in order to get the automated tests to this state https://github.com/hyperledger/indy-plenum/actions/runs/742714538 Without the dependencies being pinned, the plenum tests all fail.

WadeBarnes (Tue, 13 Apr 2021 14:11:35 GMT):
Example: https://github.com/WadeBarnes/indy-plenum/actions/runs/735975469

Toktar (Tue, 13 Apr 2021 14:47:46 GMT):
Looked at the list of dependencies in the setup.py. You are right, Ryan not only updated dependencies, but also pinned them. It is upset that we did not check this earlier in the code review before the merge. Now Anton is working on removing the fixed version from the dependency list. If we ready to leave a few dependencies pinned then it can be finished fast. Will try to remove all pinned versions.

rmarsh (Tue, 13 Apr 2021 15:18:19 GMT):
I kept pins in my WIP MR to show what versions were upgraded and working for me. In my environment, I didn't need most of the pins.

Toktar (Tue, 13 Apr 2021 15:21:48 GMT):
Thanks, got it. We will remove unnecessary pins and send PR.

WadeBarnes (Tue, 13 Apr 2021 15:58:38 GMT):
Thanks

WadeBarnes (Thu, 15 Apr 2021 16:17:23 GMT):
@lohan.spies

lohan.spies (Thu, 15 Apr 2021 16:17:23 GMT):
Has joined the channel.

lohan.spies (Thu, 15 Apr 2021 17:04:21 GMT):
@WadeBarnes @esplinr if you can guide me I can see how I can contribute to the workload

esplinr (Thu, 15 Apr 2021 17:16:38 GMT):
This meeting recording will help you understand the current state of affairs: https://wiki.hyperledger.org/display/indy/2021-04-13+Indy+Contributors+Call

devinleighsmith (Tue, 20 Apr 2021 16:56:20 GMT):
.deb packages of version *1.13.0.dev.0* of *indy-plenum* and *indy-node* are now available via the new hyperledger artifactory repository. This dockerfile provides an example of how to consume .debs from the new repository: https://github.com/sovrin-foundation/token-plugin/pull/409/files#r616869073 The primary motivation for this release is to provide compatibility with Ubuntu 20.04 focal. This release contains just the indy-plenum and indy-node packages, without packaged 3rd party .deb dependencies. The work to update those dependencies as part of 20.04 support is ongoing.

devinleighsmith (Tue, 20 Apr 2021 16:56:20 GMT):
.deb packages of version 1.13.0.dev.0 of *indy-plenum* and *indy-node* are now available via the new hyperledger artifactory repository. This dockerfile provides an example of how to consume .debs from the new repository: https://github.com/sovrin-foundation/token-plugin/pull/409/files#r616869073 The primary motivation for this release is to provide compatibility with Ubuntu 20.04 focal. This release contains just the indy-plenum and indy-node packages, without packaged 3rd party .deb dependencies. The work to update those dependencies as part of 20.04 support is ongoing.

devinleighsmith (Tue, 20 Apr 2021 16:56:20 GMT):
.deb packages of version `1.13.0.dev.0` of *indy-plenum* and *indy-node* are now available via the new hyperledger artifactory repository. This dockerfile provides an example of how to consume .debs from the new repository: https://github.com/sovrin-foundation/token-plugin/pull/409/files#r616869073 The primary motivation for this release is to provide compatibility with Ubuntu 20.04 focal. This release contains just the indy-plenum and indy-node packages, without packaged 3rd party .deb dependencies. The work to update those dependencies as part of 20.04 support is ongoing.

swcurran (Tue, 27 Apr 2021 13:50:53 GMT):
I'm not able to make the meeting today. Someone (perhaps @WadeBarnes or @esplinr ?) will be hosting.

swcurran (Tue, 27 Apr 2021 13:51:30 GMT):
Hey folks --- the Indy Contributors call is - Tuesday April 127 8AM Pacific, 5PM CET Please join us on the call -- https://wiki.hyperledger.org/display/indy/2021-04-27+Indy+Contributors+Call Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 We'll be talking about: Status of indy-node CI/CD Status of Ubuntu upgrade

esplinr (Tue, 27 Apr 2021 13:51:36 GMT):
I'm happy to host.

swcurran (Tue, 27 Apr 2021 13:52:58 GMT):
Thanks!

esplinr (Tue, 27 Apr 2021 15:01:41 GMT):
I'm coming! Sorry that I'm late.

devinleighsmith (Thu, 29 Apr 2021 23:26:45 GMT):
The stable branch for libsovtoken is failing due to the error that I've included below. ``` Error: Can't create update lock in /usr/local/var/homebrew/locks! Fix permissions by running: sudo chown -R $(whoami) /usr/local/var/homebrew Error: The following directories are not writable by your user: /usr/local/etc/bash_completion.d /usr/local/share/aclocal /usr/local/share/doc /usr/local/share/info /usr/local/share/locale /usr/local/share/man /usr/local/share/man/man1 /usr/local/share/zsh /usr/local/share/zsh/site-functions /usr/local/var/homebrew/locks You should change the ownership of these directories to your user. sudo chown -R $(whoami) /usr/local/etc/bash_completion.d /usr/local/share/aclocal /usr/local/share/doc /usr/local/share/info /usr/local/share/locale /usr/local/share/man /usr/local/share/man/man1 /usr/local/share/zsh /usr/local/share/zsh/site-functions /usr/local/var/homebrew/locks And make sure that your user has write permission. chmod u+w /usr/local/etc/bash_completion.d /usr/local/share/aclocal /usr/local/share/doc /usr/local/share/info /usr/local/share/locale /usr/local/share/man /usr/local/share/man/man1 /usr/local/share/zsh /usr/local/share/zsh/site-functions /usr/local/var/homebrew/locks ``` This is the failing script: https://github.com/sovrin-foundation/libsovtoken/blob/stable/libsovtoken/build_scripts/ios/mac/mac.01.env.setup.sh indy-sdk runs some similar logic but presumably isn't failing: https://github.com/hyperledger/indy-sdk/blob/master/vcx/libvcx/build_scripts/ios/mac/mac.01.libindy.setup.sh Hoping that @antonden or someone else familiar with the macos scripts has seen this error before.

devinleighsmith (Thu, 29 Apr 2021 23:27:52 GMT):
running the chown/chmod could be an option, bet the indy-sdk scripts aren't doing that, so I wonder what is causing the difference in behaviour.

devinleighsmith (Thu, 29 Apr 2021 23:27:52 GMT):
running the chown/chmod could be an option, but the indy-sdk scripts aren't doing that, so I wonder what is causing the difference in behaviour.

swcurran (Fri, 30 Apr 2021 16:16:52 GMT):
I've created the Quarterly Indy report to the TSC for Q2 -- https://wiki.hyperledger.org/display/TSC/2021+Q2+Hyperledger+Indy Let me know if you have any questions/comments/concerns. It's a Wiki page, so you can also update it if you want.

swcurran (Tue, 11 May 2021 03:10:06 GMT):
Hey folks --- the Indy Contributors call is - Tuesday May 11 8AM Pacific, 5PM CET Please join us on the call -- https://wiki.hyperledger.org/display/indy/2021-05-11+Indy+Contributors+Call Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 We'll be talking about: Status of indy-node CI/CD Status of Ubuntu upgrade

echsecutor (Tue, 11 May 2021 15:38:05 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. (Sorry, I was unsure about which would be the right channel)

WadeBarnes (Tue, 11 May 2021 16:02:39 GMT):
I'll DM some info

esplinr (Mon, 24 May 2021 13:03:14 GMT):
I have a family event tomorrow that will prevent me from attending the Indy Contributors call tomorrow. But I will be watching the recording.

esplinr (Mon, 24 May 2021 13:03:14 GMT):
I have a family event that will prevent me from attending the Indy Contributors call tomorrow. But I will be watching the recording.

rjones (Mon, 24 May 2021 15:30:43 GMT):
Howdy: could someone take a look at this? https://chat.hyperledger.org/channel/indy-sdk?msg=ArqR9jZhGpfyyNbvy

echsecutor (Tue, 25 May 2021 14:55:20 GMT):
unfortunately, I wont make it today. Regarding the containers ( https://github.com/IDunion/indy-node-container ): we are producing more issues than progress at the moment ;)

esplinr (Mon, 07 Jun 2021 13:59:30 GMT):
Are we going to keep this week's Indy Contributors call, even with Hyperledger Global Forum? Or should we just do an update via chat?

swcurran (Mon, 07 Jun 2021 16:42:41 GMT):
I'll cancel the meeting -- I'm going to be at HGF. @WadeBarnes -- can you post a quick update?

ianco (Mon, 07 Jun 2021 17:07:59 GMT):
Can I ask someone to review (hopefully approve) this PR (relaxes the "existing wallet" check in the postgres plug-in): https://github.com/hyperledger/indy-sdk/pull/2397

ianco (Mon, 07 Jun 2021 17:08:03 GMT):
Thanks in advance

WadeBarnes (Mon, 07 Jun 2021 18:11:12 GMT):
done

ianco (Mon, 07 Jun 2021 18:25:39 GMT):
Thanks @WadeBarnes !

swcurran (Mon, 07 Jun 2021 19:43:04 GMT):
Tomorrow's Indy Contributors Meeting has been cancelled for HGF.

tusharbansal (Sun, 13 Jun 2021 18:37:13 GMT):
Has joined the channel.

swcurran (Mon, 21 Jun 2021 14:33:16 GMT):
Hey folks --- the Indy Contributors call is - Tuesday June 22 8AM Pacific, 5PM CET Please join us on the call -- https://wiki.hyperledger.org/display/indy/2021-06-22+Indy+Contributors+Call Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 We'll be talking about: Status of indy-node CI/CD Status of Ubuntu upgrade @WadeBarnes has put together this [document](https://docs.google.com/document/d/1oBZSm-Ot8cu0Qcod3nhAzI3veEHIy4kJLBVnpO_nbiM/edit?usp=sharing) about the status of the upgrade and work to be done. Please review this before the meeting. Can you help with the work? Know someone that can?

WadeBarnes (Mon, 21 Jun 2021 14:39:40 GMT):
Questions, comments, and updates to the document are welcome.

swcurran (Tue, 06 Jul 2021 06:39:33 GMT):
Hey folks --- the Indy Contributors call is - Tuesday July 6 8AM Pacific, 5PM CET Please join us on the call -- https://wiki.hyperledger.org/display/indy/2021-06-22+Indy+Contributors+Call Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 We'll be talking about: Status of indy-node CI/CD Status of Ubuntu upgrade WadeBarnes has put together this document about the status of the upgrade and work to be done. Please review this before the meeting. Can you help with the work? Know someone that can?

swcurran (Tue, 06 Jul 2021 06:39:33 GMT):
Hey folks --- the Indy Contributors call is - Tuesday July 6 8AM Pacific, 5PM CET Please join us on the call -- https://wiki.hyperledger.org/display/indy/2021-06-22+Indy+Contributors+Call Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 We'll be talking about: - Status of indy-node CI/CD - Status of Ubuntu upgrade - Indy Contributors Campaign WadeBarnes has put together this document about the status of the upgrade and work to be done. Please review this before the meeting.

RobinKlemens (Tue, 06 Jul 2021 10:12:14 GMT):
Hi everybody, I just started working on the CD part of Plenum for the ubuntu 20.04 upgrade. Why did we extend the docker file ./build/Dockerfile.ubuntu-20-04 (https://github.com/hyperledger/indy-plenum/blob/10d7cd891390c92cfe32a641821a424badbf78e9/.github/workflows/build/Dockerfile.ubuntu-20-04#L31) with all the python packages that get installed during the Github Actions pipeline? Clearly, this approach could save time while running the tests but now we have an additional place where we need to track all the PyPI dependencies. @WadeBarnes @Toktar @devinleighsmith

WadeBarnes (Tue, 06 Jul 2021 12:04:50 GMT):
@RobinKlemens, I recall we were having issues with the tests failing (in some cases silently). This was done as part of an alignment between what was working for local developers running the tests manually and running the tests in GHA. If the dependencies don't need to be installed at that level then I'd say remove them from there. The tests need to work, but maintainability and clarity are key.

RobinKlemens (Tue, 06 Jul 2021 12:47:49 GMT):
Alright. Got it. If we are able to run the tests without installing all the packages during docker build we should remove them and just track them in one place. However, the tests still don't seem to run in a reliable manner. https://github.com/udosson/indy-plenum/actions/runs/1004161667

WadeBarnes (Tue, 06 Jul 2021 13:04:40 GMT):
That's something we need to figure out at some point. It's, unfortunately, normal for the tests to fail every once in a while due to timing issues.

WadeBarnes (Tue, 06 Jul 2021 13:05:44 GMT):
We don't really want to increase the timeout on those tests otherwise they'll take even longer than they do now.

WadeBarnes (Tue, 06 Jul 2021 13:06:19 GMT):
and if I recall correctly, once the tests get into that state, no amount of waiting helps anyway.

WadeBarnes (Tue, 06 Jul 2021 21:30:21 GMT):
Our first official GHA build artifact from the main branch of indy-plenum: https://github.com/hyperledger/indy-plenum/actions/runs/1005754452 https://hyperledger.jfrog.io/ui/repos/tree/General/indy%2Fpool%2Fmain%2Fi%2Findy-plenum%2Findy-plenum_1.13.0~dev82_amd64.deb

WadeBarnes (Tue, 06 Jul 2021 21:30:23 GMT):

Clipboard - July 6, 2021 2:30 PM

swcurran (Wed, 07 Jul 2021 08:25:50 GMT):
Fantastic!!!! Congratulations and thanks for all the hard work!

RobinKlemens (Wed, 07 Jul 2021 09:16:06 GMT):
Following our discussion about the dependency management for the Ubuntu 20.04 upgrade of Indy Plenum I created the following issue: https://github.com/hyperledger/indy-plenum/issues/1544 Also, I provided an overview of all currently installed and required PyPI packages. Please, take a look at the following document and help us achieve more clarity about the packages we really need and which we can remove as a dependency. https://docs.google.com/document/d/1445VZL3qHBmuVbzm-K9O7te_63zKKlyv6mrEwiJcL3Y/edit?usp=sharing @esplinr, it'd be great if one of the evernym team could support. Many thanks :) @WadeBarnes @Toktar @devinleighsmith @askolesov @antonden

WadeBarnes (Wed, 07 Jul 2021 12:43:51 GMT):
Thanks @RobinKlemens

askolesov (Wed, 07 Jul 2021 15:17:28 GMT):
Hi! Looking into this...

askolesov (Wed, 07 Jul 2021 16:53:23 GMT):
I'm not familiar with the entire code base. Moreover, I think nobody is familiar. I would start with tasks described in the ticket and then would remove dependencies one by one and see if it would break build or not.

RobinKlemens (Thu, 08 Jul 2021 13:16:54 GMT):
@askolesov do you have resources to work on the tasks described in the ticket?

esplinr (Thu, 08 Jul 2021 23:50:45 GMT):
Not this week, but hopefully before the end of the month.

RobinKlemens (Fri, 09 Jul 2021 08:32:20 GMT):
How are the PyPI packages currently uploaded? Is this still being done in the Jenkin instance provided by Sovrin? IMO we should integrate the publishing of the python distributions into the CD part of the GHA pipeline. This will be required as soon as we start working on the Ubuntu 20.04 upgrade of Indy Node that needs the PyPI packages from the feature branch `ubuntu-20.04-upgrade` of Indy Plenum. What do you think? Any advice?

WadeBarnes (Fri, 09 Jul 2021 12:36:36 GMT):
Agreed, we need to migrate all of the publishing over to the GHA workflows.

WadeBarnes (Fri, 09 Jul 2021 12:41:11 GMT):
You have access to the two repos that are involved with the Jenkins build/publish processes.

l-wegner (Mon, 12 Jul 2021 12:37:40 GMT):
Has joined the channel.

surajsingla333 (Tue, 13 Jul 2021 07:03:57 GMT):
Has joined the channel.

RobinKlemens (Tue, 13 Jul 2021 12:30:26 GMT):
@rjones I'm currently working on the publishing the packages of Plenum to PyPI . I've talked with @WadeBarnes and we think that testing the GHA workflow with https://test.pypi.org/ would be the best way. Could you set up `TEST_PYPI_API_TOKEN` for me, please? I'd create a new secret called `TEST_PYPI_API_TOKEN` in my repository and send the token to you as a personal message (https://packaging.python.org/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/#saving-credentials-on-github). Thanks for your help!

Helen_Garneau (Tue, 13 Jul 2021 13:27:19 GMT):
Hello Indy Contributors! Reminder to please join the DevRel Marketing Committee call at 9am PT tomorrow- 7/14. Take a look at the agenda and add items if you'd like here: https://wiki.hyperledger.org/x/sANCAw

rjones (Tue, 13 Jul 2021 16:30:39 GMT):
@RobinKlemens shoot me the API key

swcurran (Mon, 19 Jul 2021 18:00:56 GMT):
Indy Contrbutors meeting is tomorrow, but I can't make it. @WadeBarnes will be hosting -- great if you could help, @esplinr . Topic is CI/CD progress with Indy Node (spoiler -- it's happening!).

swcurran (Mon, 19 Jul 2021 18:02:02 GMT):
Call details are here: https://wiki.hyperledger.org/display/indy/Indy+Contributors+Meeting meeting is Tuesday @ 8AM Pacific. 5PM CET.

swcurran (Mon, 19 Jul 2021 18:04:40 GMT):
Page posted -- https://wiki.hyperledger.org/display/indy/2021-07-20+Indy+Contributors+Call

esplinr (Mon, 19 Jul 2021 18:12:19 GMT):
I'll be there. Thank you.

esplinr (Mon, 19 Jul 2021 18:12:45 GMT):
I'll be there, and I'm happy to help. Thank you.

WadeBarnes (Thu, 22 Jul 2021 15:40:25 GMT):
A short time ago the first "official" `indy-plenum` (Ubuntu 16.04 version) python packages were published to PyPi (https://pypi.org/project/indy-plenum/1.13.0.dev99/) via the new GHA CI/CD workflows; https://github.com/hyperledger/indy-plenum/actions/runs/1056338601 - Thanks to @RobinKlemens, @rjones, and @andrew.whitehead for their contributions to this achievement. Work is already underway to integrate this publishing workflows into the `ubuntu-20.04-upgrade` branch.

WadeBarnes (Thu, 05 Aug 2021 14:14:22 GMT):
Our first official Ubuntu 20.04 build artifact generated by the GHA workflows on the `ubuntu-20.04-upgrade` branch of indy-plenum: https://github.com/hyperledger/indy-plenum/actions/runs/1101381573 https://hyperledger.jfrog.io/ui/repos/tree/Properties/indy%2Fpool%2Fdev%2Fi%2Findy-plenum%2Findy-plenum_1.13.0~dev129_amd64.deb

WadeBarnes (Thu, 05 Aug 2021 14:14:22 GMT):
Our first official Ubuntu 20.04 Debian build artifact generated by the GHA workflows on the `ubuntu-20.04-upgrade` branch of indy-plenum: https://github.com/hyperledger/indy-plenum/actions/runs/1101381573 https://hyperledger.jfrog.io/ui/repos/tree/Properties/indy%2Fpool%2Fdev%2Fi%2Findy-plenum%2Findy-plenum_1.13.0~dev129_amd64.deb

WadeBarnes (Thu, 05 Aug 2021 14:14:25 GMT):

Clipboard - August 5, 2021 7:14 AM

WadeBarnes (Thu, 05 Aug 2021 14:16:34 GMT):
We have a few minor issues with the publishing of the associated 3rd party dependencies that needs to be addressed, but we're making progress.

swcurran (Thu, 05 Aug 2021 15:03:30 GMT):
That's awesome -- great work!

WadeBarnes (Tue, 10 Aug 2021 20:42:18 GMT):
Quick update: Progress on `indy-plenum` since the last update includes publishing of Ubuntu 20.04 code based python packages to PyPi. Progress on `indy-node` has also started with the first Ubuntu 16.04 based Debian build artifacts being published to the Hyperleger repository via GitHub Actions; https://github.com/hyperledger/indy-node/actions/runs/1117117778

WadeBarnes (Tue, 10 Aug 2021 20:42:20 GMT):

Clipboard - August 10, 2021 1:42 PM

swcurran (Tue, 10 Aug 2021 21:02:18 GMT):
The following Aries repos need to have their default branch changed to "main", per Hyperledger policy. Can those in charge please make the change? I'm not a maintainer, so can't make the change. The change in GitHub is trivial -- https://github.com/github/renaming which says Go to Settings -> Branches and edit the name of the Default Branch. Impacts on CI/CD must be considered - GHA and Jenkins scripts. https://github.com/hyperledger/indy-docs https://github.com/hyperledger/indy-hipe https://github.com/hyperledger/indy-node https://github.com/hyperledger/indy-plenum https://github.com/hyperledger/indy-sdk https://github.com/hyperledger/indy-test-automation

rjones (Tue, 10 Aug 2021 21:18:52 GMT):
@swcurran I can make the changes. if you want.

rjones (Tue, 10 Aug 2021 21:18:52 GMT):
@swcurran I can make the changes, if you want.

swcurran (Tue, 10 Aug 2021 21:22:35 GMT):
I'm worried about the contributors knowing and the CI/CD scripts being updated. The docs and hipe ones could be done, but the other four should be done with more thought. Or am I being too hesitant about this?

rjones (Tue, 10 Aug 2021 21:26:10 GMT):
docs and hipe are done. looking at GitHub actions, I don't see a lot of branch-specific things (yet).

swcurran (Tue, 10 Aug 2021 21:27:08 GMT):
@WadeBarnes if there are other secret places where this might be referenced...

swcurran (Tue, 10 Aug 2021 21:27:08 GMT):
@WadeBarnes will know if there are other secret places where this might be referenced...

rjones (Tue, 10 Aug 2021 21:27:31 GMT):
I would end up doing something like a `grep -Rl master *`

rjones (Tue, 10 Aug 2021 21:29:03 GMT):
here's one specific `master` [reference](https://github.com/hyperledger/indy-sdk/blob/master/.github/workflows/main.yml)

rjones (Tue, 10 Aug 2021 21:29:08 GMT):
so, there are ones in there

WadeBarnes (Wed, 11 Aug 2021 12:58:03 GMT):
The Jenkins builds for `indy-node`, `indy-plenum`, and `indy-sdk` will be affected and need to be updated. I've been putting that off. The changes to the docs repos will likely effect the ReadTheDocs publishing, but @rjones and I have already talked about that a bit.

WadeBarnes (Wed, 11 Aug 2021 12:59:17 GMT):
Just tried renaming https://github.com/hyperledger/indy-test-automation, and apparently the process failed, so I don't know the ramifications of that:

WadeBarnes (Wed, 11 Aug 2021 12:59:19 GMT):

Clipboard - August 11, 2021 5:59 AM

WadeBarnes (Wed, 11 Aug 2021 13:05:18 GMT):
Re-instated `master` as the main branch.

WadeBarnes (Wed, 11 Aug 2021 13:05:32 GMT):
Will look at this again when there is more time.

WadeBarnes (Wed, 11 Aug 2021 13:06:38 GMT):
I'd really like to get through the node and plenum upgrades before we start messing with renaming branches if that's ok.

WadeBarnes (Wed, 11 Aug 2021 13:08:33 GMT):
If there is objection I can switch focus and work though the renaming and any consequences that causes with the builds.

WadeBarnes (Wed, 11 Aug 2021 13:16:57 GMT):
A second attempt at renaming the main branch on https://github.com/hyperledger/indy-test-automation succeeded.

swcurran (Wed, 11 Aug 2021 15:45:42 GMT):
Definitely wait!

swcurran (Wed, 11 Aug 2021 15:46:02 GMT):
Glad the indy-test-automation, but don't worry about the others.

swcurran (Tue, 17 Aug 2021 04:12:43 GMT):
The Indy Contributors meeting is tomorrow (Tuesday) at 8AM Pacific / 5PM CET. We'll be discussing the continued progress being made on the CI/CD process. Call details are here: https://wiki.hyperledger.org/display/indy/Indy+Contributors+Meeting

esplinr (Tue, 17 Aug 2021 15:15:04 GMT):
Great resources for getting started working on Indy Node and Plenum: How to Troubleshoot an Indy Network https://www.evernym.com/blog/troubleshooting-an-indy-network/ Hyperledger An introduction to Indy https://ssimeetup.org/hyperledger-indy-public-blockchain-node-alexander-shcherbakov-webinar-43/ Shorter version https://www.youtube.com/watch?v=ncdvaJrOm_Q&list=PLRp0viTDxBWH2hRisVD6Wij43afXt0FHN&index=3 You will also find lots of good documentation in the the /docs and /design folders of indy-node, indy-plenum, and indy-sdk.

esplinr (Tue, 17 Aug 2021 15:15:39 GMT):
cc @pSchlarb

pSchlarb (Tue, 17 Aug 2021 15:15:39 GMT):
Has joined the channel.

RobinKlemens (Tue, 31 Aug 2021 14:49:34 GMT):
Hi all, I got the CI part of Indy-Node for the ubuntu 20.04 upgrade up and running in GHA. All tests but one pass. https://github.com/udosson/indy-node/actions/runs/1186479141 Could someone who is more familiar with the codebase take a look at https://github.com/udosson/indy-node/runs/3474220737?check_suite_focus=true, please? Thanks, Robin

echsecutor (Tue, 31 Aug 2021 15:19:08 GMT):
looks like an error in the implementation or test for https://github.com/hyperledger/indy-node/blob/78bb325121be212f4dc729998d713dbbcde78bee/indy_common/authorize/auth_constraints.py#L118 to me the master version looks fine. Which version are you building?

RobinKlemens (Tue, 31 Aug 2021 15:23:29 GMT):
Found and fixed the error. I had to do some adjusted because of flake8 to make lint pass in Python version 3.8. https://github.com/udosson/indy-node/commit/84b127612a5415a6565e34c7500ea114f81f3c7e This line changed the expected error message: https://github.com/udosson/indy-node/blob/84b127612a5415a6565e34c7500ea114f81f3c7e/indy_common/authorize/auth_constraints.py#L139

RobinKlemens (Tue, 31 Aug 2021 15:25:01 GMT):
The new GHA run is at: https://github.com/udosson/indy-node/actions/runs/1186716329

swcurran (Tue, 31 Aug 2021 20:43:27 GMT):
w00t!!!

swcurran (Tue, 31 Aug 2021 20:43:31 GMT):
Nice work.

esplinr (Thu, 02 Sep 2021 04:30:36 GMT):
Yay!

WadeBarnes (Mon, 13 Sep 2021 13:18:31 GMT):
The first `indy-node` python package published via GHA (https://github.com/hyperledger/indy-node/actions/runs/1226653983); https://pypi.org/project/indy-node/1.13.0.dev123/ Great job @RobinKlemens, and thanks for the support setting up the token @rjones.

WadeBarnes (Wed, 15 Sep 2021 18:14:18 GMT):
The first `indy-node` Ubuntu 20.04 `deb` package published via GHA (https://github.com/hyperledger/indy-node/actions/runs/1238525525); https://hyperledger.jfrog.io/ui/repos/tree/General/indy%2Fpool%2Ffocal%2Fdev%2Fi%2Findy-node%2Findy-node_1.13.0~dev144_amd64.deb Associated python package; https://pypi.org/project/indy-node/1.13.0.dev144/ Another great accomplishment @RobinKlemens, and all of the other contributors that made the code updates needed to make the Ubuntu 20.04 build possible, @Toktar, @askolesov, @antonden We're another step closer to a new release! Thanks all!

RobinKlemens (Thu, 16 Sep 2021 06:10:17 GMT):
Thanks to @WadeBarnes for you all support!

esplinr (Sat, 18 Sep 2021 13:13:31 GMT):
In early 2021, the Evernym team offered to test the release and upgrade process once the packages are ready. Since that time, people have moved to other projects. Our internal Q4 planning shows that we are unlikely to have someone available to test over the next two months. I've also picked up new projects and so won't be participating in Indy Contributors as often. cc @WadeBarnes

WadeBarnes (Sat, 18 Sep 2021 13:24:34 GMT):
@esplinr, Any information you can pass along regarding the test processes and procedures your team had planned to perform would be greatly appreciated.

rjones (Mon, 20 Sep 2021 15:31:17 GMT):
Hi folks. The last two repos still on `master` branch are `indy-node` and `indy-plenum`. May I change them to `main`?

WadeBarnes (Mon, 20 Sep 2021 15:35:23 GMT):
That will break all of the Jenkins piplines I believe. The GHA workflows should survive. I was hoping to do the switch after we completed the GHA migration and had the first release out. Otherwise I've got to get the Jenkins pipelines working against `main`.

WadeBarnes (Mon, 20 Sep 2021 15:35:52 GMT):
Just noticed `indy-sdk`'s main branch was renamed to `main`. When did that happen?

rjones (Mon, 20 Sep 2021 15:35:58 GMT):
I'll undo it.

rjones (Mon, 20 Sep 2021 15:36:42 GMT):
Undone. I did it this morning b/c there hadn't been a commit in a few months

swcurran (Fri, 24 Sep 2021 17:38:43 GMT):
Hey folks --- the Indy Contributors call is - Tuesday Sept. 28 at 8AM Pacific, 5PM CET Please join us on the call -- https://wiki.hyperledger.org/display/indy/2021-08-28+Indy+Contributors+Call Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 We'll be talking about: - Status of indy-node CI/CD and the Ubuntu upgrade - Indy DID Method – An overview of the spec, why it is important, and getting started on the work We're seeing more interest in the Indy DID method, which will make it much easier to access multiple Indy networks from an Aries Agent, and enable support for things like BBS+ Verifiable Credentials. Join us to see what's happening with this new DID Method.

esplinr (Tue, 28 Sep 2021 22:37:01 GMT):
We planned two types of testing: * Running the integration test scripts in the test automation repo * A manual upgrade test on an environment designed to look like Sovrin Main Net

lynn.bendixsen (Wed, 29 Sep 2021 20:41:10 GMT):
Added a new github issue for a recurring Indy Node discrepancy. https://github.com/hyperledger/indy-node/issues/1700 Attempts to replicate it manually have failed. I have gotten close, but not quite there yet. Some logs are attached to the issue.

swcurran (Fri, 08 Oct 2021 16:09:55 GMT):
Cancelling next week's Indy Contributors call due to IIW. Please post any updates or topics of interest here. See you at the next meeting.

RobinKlemens (Tue, 12 Oct 2021 16:41:56 GMT):
*Indy-Test-Automation* The tests are running in a GHA workflow now. The most recent run is at https://github.com/udosson/indy-test-automation/actions/runs/1333954704 As the next step, I'll filter all the tests and create a separate directory with `indy-node` tests only without the sovrin dependencies. Once we have that, we can add the indy-test-automation workflow to the indy-node repository for ubuntu 16.04. After that, let's tackle ubuntu 20.04 It'd be great if anyone could support filtering the tests in this directory https://github.com/udosson/indy-test-automation/tree/local-test-env/system/indy-node-tests-only At the moment I temporarily skipped all tests with any sovrin dependencies. However, with some refactoring, we could use parts of the tests. But it's hard for me to decide which tests should be refactored and which tests could just be removed. Thanks for your help.

RobinKlemens (Tue, 12 Oct 2021 17:59:35 GMT):
Who can rebuild `hyperledger/indy-core-baseci:0.0.3-master`? The `ubuntu` base image needs to be updated to fix the following error: `#6 5.033 server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none` (https://github.com/hyperledger/indy-plenum/runs/3873707861?check_suite_focus=true#step:7:262) I faced the same issue with an older version of the `teracy/ubuntu:16.04-dind-latest` image. I had to rebuild the image to fix the error.

pSchlarb (Wed, 13 Oct 2021 09:21:39 GMT):
Well i have done it for the removal of the pip dependencies. But was only able to push to my personal Dockerhub-Repository.

pSchlarb (Wed, 13 Oct 2021 09:22:49 GMT):
And also had to rebuild my version, because of the key errors with apt.

pSchlarb (Wed, 13 Oct 2021 10:06:07 GMT):
Well i have done it for the removal of the pip dependencies(https://github.com/hyperledger/indy-node/pull/1684). But was only able to push to my personal Dockerhub-Repository (https://hub.docker.com/repository/docker/pschlarb/indy-core-baseci). And also had to rebuild my version, because of the key errors with apt.

RobinKlemens (Wed, 13 Oct 2021 12:47:02 GMT):
Alright. So we need someone with access to the Docker Account of Hyperledger. I don't know if there a pipeline that publishes the `hyperledger/indy-*` images. However, this could also be done manually. @rjones @WadeBarnes could you support?

WadeBarnes (Wed, 13 Oct 2021 12:50:18 GMT):
Looks like the `make` file does the work, but there isn't any pipeline that I know of. We should create a GHA for this at some point.

pSchlarb (Wed, 13 Oct 2021 12:50:55 GMT):
I can look into that.

WadeBarnes (Wed, 13 Oct 2021 12:54:23 GMT):
@rjones, would you be able to help @RobinKlemens with token access to the Docker account? The token credentials will need to be setup on the `indy-node` repo too for the GHA workflow to use.

WadeBarnes (Wed, 13 Oct 2021 12:55:22 GMT):
@pSchlarb, examples of workflow publishing to DockerHub; https://github.com/BCDevOps/backup-container/tree/master/.github/workflows

pSchlarb (Wed, 13 Oct 2021 12:57:20 GMT):
Or do we explicitly need the base images ? Wit

RobinKlemens (Wed, 13 Oct 2021 12:58:08 GMT):
We could also think of removing the image from Docker Hub in the near future and build the image in the GHA workflow as we do already for the ubuntu 20.04 build image. Ubuntu 16.04: https://github.com/hyperledger/indy-node/blob/master/.github/workflows/build/Dockerfile Ubuntu 20.04: https://github.com/hyperledger/indy-node/blob/ubuntu-20.04-upgrade/.github/workflows/build/Dockerfile.ubuntu-2004

WadeBarnes (Wed, 13 Oct 2021 12:58:41 GMT):
That works too.

pSchlarb (Wed, 13 Oct 2021 12:58:55 GMT):
Do we really need the base images? When already perfoming cleanup on the GHA Docker build, with enabled Layercaching, would it make sense to get rid off the too?

RobinKlemens (Wed, 13 Oct 2021 12:59:35 GMT):
IMMO we don't need the base images. @pSchlarb see my comment above

rjones (Wed, 13 Oct 2021 16:01:31 GMT):
OK let me know if I need to do anything :)

RobinKlemens (Wed, 13 Oct 2021 18:38:52 GMT):
@rjones it would be great if you could help me with the access to the Docker account so I can publish a new version of the `indy-base-images`. Thanks

rjones (Wed, 13 Oct 2021 18:52:56 GMT):
awesome, I guess I missed that

rjones (Wed, 13 Oct 2021 18:55:44 GMT):
@RobinKlemens what is your docker hub account name?

rjones (Wed, 13 Oct 2021 19:00:51 GMT):
Found it. You are now an admin on that repo

RobinKlemens (Wed, 13 Oct 2021 19:02:32 GMT):
Awesome. Thanks Rj!

RobinKlemens (Wed, 13 Oct 2021 19:02:32 GMT):
Awesome. Thanks Ry :)

RobinKlemens (Wed, 13 Oct 2021 19:05:53 GMT):
I'll just rebuild and push the image with the same tag since nothing has changed. We just update the ubuntu packages. This would require less effort in adjusting all the pipelines etc. What do you think @WadeBarnes?

WadeBarnes (Wed, 13 Oct 2021 19:47:19 GMT):
Let see what happens.

rjones (Wed, 13 Oct 2021 22:05:49 GMT):
I would like to nudge you to use https://chat.lfx.linuxfoundation.org/#/room/#hyperledger-indy:chat.lfx.linuxfoundation.org :)

RobinKlemens (Thu, 14 Oct 2021 07:41:47 GMT):
Will this replace rocket chat in the near future?

RobinKlemens (Thu, 14 Oct 2021 08:05:58 GMT):
I updated the image `hyperledger/indy-core-baseci:0.0.3-master`. Now, we are able to install the packages from repo.sovrin.org again. e.g., https://github.com/hyperledger/indy-plenum/actions/runs/1334210901

rjones (Thu, 14 Oct 2021 13:44:48 GMT):
yes, this CY

pSchlarb (Thu, 14 Oct 2021 14:22:24 GMT):
How should the https://github.com/hyperledger/indy-node/pull/1684#issuecomment-943312892

pSchlarb (Thu, 14 Oct 2021 14:26:22 GMT):
https://github.com/hyperledger/indy-node/pull/1684#issuecomment-943312892 It seems that the linting process in GHA is checking more style conventions than running locally. How should they be treated?

WadeBarnes (Thu, 14 Oct 2021 14:46:39 GMT):
@RobinKlemens, Didn't we have a similar issue with linting before?

WadeBarnes (Thu, 14 Oct 2021 14:46:39 GMT):
@RobinKlemens, Didn't we have a similar issue with linting before? To do with the version of the linter in the image.

pSchlarb (Thu, 14 Oct 2021 14:59:22 GMT):
Strange is locally those conventions are ignored

pSchlarb (Thu, 14 Oct 2021 14:59:22 GMT):
Strange is locally those conventions are ignored. Even if run in the container pulled from ghcr.

RobinKlemens (Thu, 14 Oct 2021 15:15:59 GMT):
I think I found the issue: This is the image we pull in GHA https://github.com/hyperledger/indy-node/runs/3894323762?check_suite_focus=true#step:2:16 `ghcr.io/hyperledger/indy-node/node-lint:latest` However, `latest` is currently `ubuntu-2004` https://github.com/hyperledger/indy-node/pkgs/container/indy-node%2Fnode-lint/versions This line would have to be `image: ghcr.io/${{ needs.workflow-setup.outputs.GITHUB_REPOSITORY_NAME }}/node-lint:ubuntu-18-04` https://github.com/hyperledger/indy-node/blob/master/.github/workflows/build.yaml#L262

RobinKlemens (Thu, 14 Oct 2021 15:16:12 GMT):
I'll create a PR that should fix this

pSchlarb (Thu, 14 Oct 2021 15:23:12 GMT):
So should i wait on your pr and rebase the remove pip imports or also change to `:ubuntu-18-04` linter image?

RobinKlemens (Thu, 14 Oct 2021 15:27:36 GMT):
PR is at https://github.com/hyperledger/indy-node/pull/1701

RobinKlemens (Thu, 14 Oct 2021 15:34:36 GMT):
Lint passed ;) https://github.com/hyperledger/indy-node/runs/3896555491?check_suite_focus=true

RobinKlemens (Thu, 14 Oct 2021 15:35:35 GMT):
@WadeBarnes could you review and merge the PR please, once the GHA run is completed? thanks

RobinKlemens (Thu, 14 Oct 2021 15:36:58 GMT):
Will there be an official announcement soon? Or did I just missed it? :D

WadeBarnes (Thu, 14 Oct 2021 15:38:13 GMT):
@RobinKlemens, To confirm, that PR was meant to target `master`?

RobinKlemens (Thu, 14 Oct 2021 15:38:41 GMT):
yes

WadeBarnes (Thu, 14 Oct 2021 15:39:17 GMT):
Ok, just need to wait for the Jenkins pipeline to do it's thing.

WadeBarnes (Thu, 14 Oct 2021 15:41:15 GMT):
I've approved the PR, so you should be able to merge it once Jenkins is finished (I think).

RobinKlemens (Thu, 14 Oct 2021 15:57:45 GMT):
We'll see :)

rjones (Thu, 14 Oct 2021 16:24:09 GMT):
it's been discussed on the TSC for a while. All graduated projects have a room there; the move of everything is on hold while other issues are worked out

rjones (Thu, 14 Oct 2021 16:24:17 GMT):
so no, you didn't miss anything,

rjones (Thu, 14 Oct 2021 16:24:44 GMT):
One _huge_ advantage is it's easy for people that aren't admins to add stuff like github integrations to a channel

RobinKlemens (Tue, 02 Nov 2021 12:30:16 GMT):
@pSchlarb thanks for your PRs. I'll review them on Thursday.

RobinKlemens (Tue, 09 Nov 2021 21:30:38 GMT):
https://github.com/udosson/indy-node/actions/runs/1440938975 Indy test automations with debian files from artifactory (ubuntu 16.04)

RobinKlemens (Thu, 11 Nov 2021 14:53:58 GMT):
Is anyone aware of a `systemd` docker image for Ubuntu20.04 except `jrei/systemd-ubuntu`?

rjones (Thu, 11 Nov 2021 14:58:21 GMT):
@RobinKlemens did you see the questions in #indy-sdk ? there are a lot of old PRs needing love

RobinKlemens (Thu, 11 Nov 2021 15:07:22 GMT):
Thanks for flagging this. However, I'm not very familiar with the code base of `indy-sdk` and I'm not sure about the current state of its CI/CD pipeline

rjones (Thu, 11 Nov 2021 15:08:05 GMT):
maybe the repo needs archived?

RobinKlemens (Thu, 11 Nov 2021 15:09:53 GMT):
I think `indy-sdk` is still used widely. What do you think @WadeBarnes @ianco @swcurran ?

swcurran (Thu, 11 Nov 2021 21:10:10 GMT):
No -- not archived, it is in active use. However, there is not a lot happening. to change it -- just a lot of use of it.

swcurran (Thu, 11 Nov 2021 21:10:46 GMT):
I can take a quick look at the PRs and we might be able to provide some guidance.

swcurran (Thu, 11 Nov 2021 21:11:15 GMT):
@PatrikStas -- did ABSA complete the work on the GHA pipeline for the Indy SDK?

echsecutor (Tue, 23 Nov 2021 15:29:55 GMT):
Hi all! In todays contributors call https://wiki.hyperledger.org/display/indy/2021-11-23+Indy+Contributors+Call , we would like to talk about some work that was done in ID Union in order to containerize the Indy Node Server + Node Controller https://github.com/IDunion/indy-node-container

swcurran (Tue, 23 Nov 2021 15:31:55 GMT):
@WadeBarnes ^^^ Great stuff. I have to miss the call, so please make sure a recording is made!!

pSchlarb (Wed, 24 Nov 2021 13:51:09 GMT):
@RobinKlemens I updated the PRs for the baseimage and the removal of pip imports. Removed the cython in the baseimage, updated to python3-indy 1.16. and tested the resulting image. Should be ready to review / merge.

RobinKlemens (Wed, 24 Nov 2021 14:19:04 GMT):
Thanks @pSchlarb. Please, talk a look at my feedback on GitHub. Thanks

RobinKlemens (Wed, 24 Nov 2021 14:19:04 GMT):
Thanks @pSchlarb . Please, talk a look at my feedback on GitHub. Thanks

pSchlarb (Wed, 24 Nov 2021 14:19:50 GMT):
will do

pSchlarb (Wed, 24 Nov 2021 14:29:29 GMT):
Should i also sqash the commits for the removal of pip?

RobinKlemens (Wed, 24 Nov 2021 14:36:27 GMT):
Yes, that we be great!

HakanTUB (Mon, 29 Nov 2021 10:23:06 GMT):
Has joined the channel.

HakanTUB (Mon, 29 Nov 2021 10:26:12 GMT):
Hello, As IDunion, we are mobilizing right now to work on the did:indy method and would like to find out if there is already other workstreams happening. Is there any updates or work happening around did:indy method?

pSchlarb (Mon, 29 Nov 2021 15:31:32 GMT):
One question regarding the idea for development containers (VSCode) and Gitpod: Gitpods baseimage is based off of ubuntu20.04. I would therefore create devcontainers for ubuntu 16, 20 in the according branch and for the ubuntu upgrade branch a gitpod configuration. Is that fine or don't we need the devcontainer for 16?

swcurran (Mon, 29 Nov 2021 15:36:30 GMT):
The team here in BC is very interested in that work. Would love to talk over your ideas and help with the plans. Do you have some time for a meeting about this?

WadeBarnes (Mon, 29 Nov 2021 15:45:01 GMT):
I think it's safe to only support 20.04 and forward for this. Efforts for 16.04b should be kept to a minimum.

WadeBarnes (Mon, 29 Nov 2021 15:45:01 GMT):
I think it's safe to only support 20.04 and forward for this. Efforts for 16.04 should be kept to a minimum.

HakanTUB (Tue, 30 Nov 2021 15:49:19 GMT):
That's great to hear Stephen. Can we make this the main topic of the Indy Controbutors' Call on 07.12.2021?

swcurran (Wed, 01 Dec 2021 13:58:24 GMT):
Yes -- that works. I'll update the meeting plan and have a discussion framework ready.

swcurran (Thu, 02 Dec 2021 00:26:47 GMT):
Folks, on the Indy Contributors call this coming Tuesday, Dec. 7 (8AM Pacific, 5PM CET) we're going to be talking about the "did:indy" DID Method Specification and how to get it implemented. We have several organizations at least that are planning to start on that Real Soon Now and we're looking to see who else is interested in tracking or participating in this effort. Please join us! Meeting Details and Zoom Link: https://wiki.hyperledger.org/display/indy/Indy+Contributors+Meeting The DID Indy Specification: https://hyperledger.github.io/indy-did-method/

HakanTUB (Fri, 03 Dec 2021 10:21:19 GMT):
Perfect, thank you and see you on Tuesday

esplinr (Tue, 07 Dec 2021 17:14:04 GMT):
Reposting for those new to Indy Development. Great resources for getting started working on Indy Node and Plenum: How to Troubleshoot an Indy Network https://www.evernym.com/blog/troubleshooting-an-indy-network/ Hyperledger An introduction to Indy https://ssimeetup.org/hyperledger-indy-public-blockchain-node-alexander-shcherbakov-webinar-43/ Shorter version https://www.youtube.com/watch?v=ncdvaJrOm_Q&list=PLRp0viTDxBWH2hRisVD6Wij43afXt0FHN&index=3 You will also find lots of good documentation in the the /docs and /design folders of indy-node, indy-plenum, and indy-sdk.

ianco (Tue, 07 Dec 2021 18:34:41 GMT):
Hi folks, the tests in the https://github.com/hyperledger/indy-sdk repository are failing right now on all PR's, with the following error: ``` error: failed to parse manifest at `/home/indy/.cargo/registry/src/github.com-1ecc6299db9ec823/const-oid-0.6.2/Cargo.toml` Caused by: feature `resolver` is required this Cargo does not support nightly features, but if you switch to nightly channel you can add `cargo-features = ["resolver"]` to enable this feature ``` This is happening on a couple of dependencies (`const-oid` above, also `pkcs8`). Looks like they are including `resolver = "2"` in their `Cargo.toml` files, and then the builds are failing because the Rust version we are using doesn't support this feature. Seems to relate to this: https://doc.rust-lang.org/cargo/reference/resolver.html#feature-resolver-version-2 I tried locally with the latest rust version (`1.57.0`) and get the same error. If I install rust nightly (`1.59.0-nightly`) then the build seems to work :-S

ianco (Tue, 07 Dec 2021 18:36:13 GMT):
(Also if I build everything using the `nightly` rust, and then switch back to `stable` everything seems to work, so it's an issue downloading the dependencies but not building them)

pSchlarb (Thu, 09 Dec 2021 15:21:07 GMT):
Hi all, Just created a PR#1719 for the Github Actions optimization of indy-node. To finalize it a secret needs to be added to the repo with package read/write/delete access. Who is responsible for that and can help me with that ?

swcurran (Thu, 09 Dec 2021 16:17:03 GMT):
@rjones I'm guessing that is you? ^^

rjones (Thu, 09 Dec 2021 17:31:41 GMT):
huh? what? who?

rjones (Thu, 09 Dec 2021 17:41:35 GMT):
@pSchlarb I'm trying to figure out where that setting is, and I'm not seeing it

rjones (Thu, 09 Dec 2021 17:42:52 GMT):
Ah, the issue is that PRs don't have access to secrets.

rjones (Thu, 09 Dec 2021 17:48:33 GMT):
@pSchlarb I suggested a couple changes in review, as well

pSchlarb (Thu, 16 Dec 2021 16:22:44 GMT):
So i conducted some test and measurements on the GHA-Optimizations. Tested 3 runs, because of the different execution times in Github. All measurements are rounded. For the "old" Way(Docker image in GHCR only built when the Dockerfile changes and each test slice installing pip dependencies) when the images were built we get an average execution time for the test of 814 seconds and an overall average pipeline runtime of 20m 17s; when the image was cached we got an average execution time of the tests of 891 seconds and an average overall time of 15m31s With the new way (creation of a docker layer cached container specially for the commit with integrated pip installs and removal after the tests has been run, removal of the linting container) the tests needed an average of 816 seconds ( kind of the same time compared to the old way) but with the increase in time for the commit specific container images the overall runtime is around 20 minutes average. Considered that the GithubActions Dockerfile with the apt dependencies rarely changes the pipeline runtime would increase by about 5 minutes. Should I continue with the effort on commitspecific containers and their removal (as @WadeBarnes suggested the idea of a "base" image with the apt dependencies and from that commitspecific containers for testing) for the GHA or leave it as is and just remove the linting image and fix the test slices?

rjones (Thu, 16 Dec 2021 18:30:54 GMT):
@pSchlarb check out [this run](https://github.com/hyperledger/indy-node/actions/runs/1588856475)

WadeBarnes (Fri, 17 Dec 2021 15:52:43 GMT):
Sorry for the slow reply. I'm thinking you should try the cached build image and then use that as the base to generate commit specific test image(s).

WadeBarnes (Fri, 17 Dec 2021 15:55:07 GMT):
If that does not improve things, then the clean-up as you suggested would be the way to go, as there is no point in having more complicated processes with there is no benefit.

pSchlarb (Fri, 17 Dec 2021 15:58:54 GMT):
Will do. Still the issue i have is that there is a PAT needed for the removal. As @rjones said:"The problem is I can't scope a PAT to one repo. It would be for every org and every repo I have access to." Would it be a security risk to still generate one and set is a secret for the indy-node and indy-plenum repos?

WadeBarnes (Fri, 17 Dec 2021 16:00:34 GMT):
@rjones, What's your opinion?

rjones (Fri, 17 Dec 2021 16:57:40 GMT):
the only way I can think to make it work would be to create a new account that only had access to those two repos

SeanBohan (Fri, 17 Dec 2021 20:04:12 GMT):
Has joined the channel.

WadeBarnes (Fri, 17 Dec 2021 20:12:42 GMT):
Then I think we need to scrap the idea of creating and deleting commit specific images.

rjones (Fri, 17 Dec 2021 20:20:13 GMT):
agreed. GitHub's API is terrible

HakanTUB (Tue, 21 Dec 2021 16:37:47 GMT):
As spoken during the contributors' call: https://github.com/w3c/did-spec-registries/pull/393/commits/4a00fbeca50f6a5f2eb72cec12b09107ee8522ac

esplinr (Tue, 21 Dec 2021 16:46:54 GMT):
Thank you!

pSchlarb (Tue, 21 Dec 2021 18:25:20 GMT):
https://github.com/hyperledger/indy-node/pull/1722 Gitpod is also ready

RobinKlemens (Tue, 04 Jan 2022 14:42:18 GMT):
@rjones could you please create a PAT in `Indy-Node` with the following name 'WORKFLOW_DISPATCH_TOKEN'. The token is required to trigger the `indy-test-automation` workflow from the main CI/CD workflow in Indy-Node. Thanks! See https://github.com/hyperledger/indy-node/blob/cdbf8465a112bc41360da48d907a18f0c93d2561/.github/workflows/build.yaml#L440

rjones (Tue, 04 Jan 2022 18:15:27 GMT):
@RobinKlemens done, but secrets aren't available to PRs, which that commit looks like it is within

RobinKlemens (Tue, 04 Jan 2022 20:54:00 GMT):
Thanks @rjones I'll test everything in my fork and will get the first basic PR ready for merging

RobinKlemens (Thu, 13 Jan 2022 14:30:08 GMT):
What is the process of getting a new version of `python-ursa` pushed to pypi?

RobinKlemens (Thu, 13 Jan 2022 14:30:08 GMT):
What is the process of getting a new version of `python-ursa` pushed to pypi? The version of `python-ursa` is at version 0.1.1. and the `ursa` is at version `0.3.7`

RobinKlemens (Thu, 13 Jan 2022 14:30:08 GMT):
What is the process of getting a new version of `python-ursa` pushed to pypi? The version of `python-ursa` is at version `0.1.1` and the `ursa` is at version `0.3.7`

WadeBarnes (Thu, 13 Jan 2022 14:52:15 GMT):
It might be a good idea to ask over on the #ursa channel.

RobinKlemens (Thu, 13 Jan 2022 15:28:24 GMT):
done https://chat.hyperledger.org/channel/ursa?msg=4L8k8AiDfGcP5AgDa

RobinKlemens (Thu, 13 Jan 2022 15:47:13 GMT):
`indy-test-automation` is running in `hyperledger/indy-node` for the indy artifacts based on ubuntu 16.04

RobinKlemens (Thu, 13 Jan 2022 15:47:13 GMT):
`indy-test-automation` is running in `hyperledger/indy-node` for the indy artifacts based on ubuntu 16.04. The workflow is at https://github.com/hyperledger/indy-node/actions/runs/1693492760

WadeBarnes (Thu, 13 Jan 2022 15:48:25 GMT):
Great work @RobinKlemens

swcurran (Tue, 18 Jan 2022 15:48:11 GMT):
Hey folks --- the Indy Contributors call is - starts in 15 minutes. Please join us on the call -- https://wiki.hyperledger.org/display/indy/2021-08-28+Indy+Contributors+Call Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 We'll be talking about: - Status of indy-node CI/CD and the Ubuntu upgrade - Indy DID Method – reviewing PRs for merging into the spec in anticipation of code development starting - https://hyperledger.github.io/indy-did-method/

esplinr (Wed, 19 Jan 2022 16:43:36 GMT):
Can we move our conversations to the new Hyperledger Matrix service? Rocket Chat is really broken lately.

swcurran (Sat, 22 Jan 2022 17:52:48 GMT):
Per @rjones -- Hyperledger is not going to Matrix. Looks like Discord is a possibility, although it is still early.

lynn.bendixsen (Mon, 24 Jan 2022 15:21:28 GMT):
In our last Indy Contributors call there was a question about "hashing the first 16 bytes of the DID" for comparison and a follow up suggestion/question "why don't we just hash and compare the whole thing". We can maybe hash the whole thing, it appears, but comparing the whole thing will likely not work as a solution due to key rotation (the last part of the full DID changes when rotating keys, but the first part remains constant) Maybe everyone else already realized this, but just in case there was someone who didn't, like me, I thought I would post here. :)

WadeBarnes (Mon, 24 Jan 2022 17:54:40 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:16 GMT):
Has joined the channel.

swcurran (Sun, 30 Jan 2022 19:20:22 GMT):
Hey folks --- the Indy Contributors call is this Tuesday 0800 Pacific / 1700 CET Please join us on the call -- https://wiki.hyperledger.org/display/indy/2022-02-01+Indy+Contributors+Call Zoom: https://zoom.us/my/hyperledger.community?pwd=STZQd0xMZU9xRVVOVnpQM3JNQ2dqZz09 We'll be talking about: * Status of indy-node CI/CD and the Ubuntu upgrade * did:indy PRs * Discussion Topic: did:indy resolution of non-DIDs – schema, etc. Would love to have those with knowledge of DID Resolution and some other DID Methods join for that last topic. Special invitation to you and/or members of your team @peacekeeper :slight_smile: !!

swcurran (Tue, 01 Feb 2022 20:26:02 GMT):
We need more maintainers of the Indy DID Method. I'd like to propose @paul.bastian @domwoe @dbluhm @TelegramSam. We'd welcome nominations of others. Please: * Add an emoji if you agree or disagree to the full list * Reply if you partially agree to the list * Reply to propose others to be added. Thanks!

swcurran (Tue, 01 Feb 2022 20:26:02 GMT):
We need more maintainers of the Indy DID Method repo/spec. I'd like to propose @paul.bastian @domwoe @dbluhm @TelegramSam. We'd welcome nominations of others. Please: * Add an emoji if you agree or disagree to the full list * Reply if you partially agree to the list * Reply to propose others to be added. Thanks!

paul.bastian (Tue, 01 Feb 2022 20:26:02 GMT):
Has joined the channel.

echsecutor (Fri, 11 Feb 2022 09:15:05 GMT):
@rjones As discusssed (with @RobinKlemens ), we have initiated the transfer of our indy-node-container repository (originally https://github.com/IDunion/indy-node-container ) to you (github makes this a multi hop process ) in order to contribute it to Hyperledger. (We have managed to add all missing sign-off messages to the commits. ;) ) A couple of organisatorial points: - We are currently using the github repo wiki for minutes purpouses, but it would probably make sense to move those to Confluence in order to align with the other HL projects, right? How can we do that? - Could you add me ( https://github.com/Echsecutor ) , @RobinKlemens ( https://github.com/udosson ) and Guido https://github.com/mgmgwi to the appropriate team so that we can keep maintaining the repo at HL?

echsecutor (Fri, 11 Feb 2022 09:15:05 GMT):
@rjones As discusssed (with @RobinKlemens ), we have initiated the transfer of our indy-node-container repository (originally https://github.com/IDunion/indy-node-container ) to you (github makes this a multi hop process ) in order to contribute it to Hyperledger. (We have managed to add all missing sign-off messages to the commits. ;) ) A couple of organisatorial points: - We are currently using the github repo wiki for minutes purpouses, but it would probably make sense to move those to Confluence in order to align with the other HL projects, right? How can we do that? - Could you add me ( https://github.com/Echsecutor ) , @RobinKlemens ( https://github.com/udosson ) and @mgmgwi https://github.com/mgmgwi to the appropriate team so that we can keep maintaining the repo at HL?

mgmgwi (Fri, 11 Feb 2022 09:22:38 GMT):
Has joined the channel.

swcurran (Fri, 11 Feb 2022 14:44:29 GMT):
Awesome to hear about this! Thanks!

rjones (Fri, 11 Feb 2022 16:50:39 GMT):
invites extended!

rjones (Fri, 11 Feb 2022 16:51:12 GMT):
as for the wiki - it's up to you. The wiki is really a special git repo, so you could export it if you wanted, or you could copy-paste things

rjones (Sat, 12 Feb 2022 21:59:50 GMT):
[Please move to Discord](https://discord.com/channels/905194001349627914/905205711850594336)

rjones (Sat, 12 Feb 2022 21:59:50 GMT):
[Please get an account on the Hyperledger discord](https://discord.gg), then [join Indy](https://discord.com/channels/905194001349627914/905205711850594336)

rjones (Tue, 15 Feb 2022 01:14:50 GMT):
Has left the channel.

tdiesler (Wed, 23 Feb 2022 10:36:27 GMT):
Has joined the channel.

rjones (Wed, 23 Mar 2022 17:25:37 GMT):