rjones (Fri, 14 Jun 2019 20:52:46 GMT):
danielhardman

rjones (Fri, 14 Jun 2019 20:53:04 GMT):
Pigs versus chickens

rjones (Fri, 14 Jun 2019 20:56:21 GMT):
User User_1 added by rjones.

rjones (Fri, 14 Jun 2019 20:56:21 GMT):
User User_2 added by rjones.

rjones (Fri, 14 Jun 2019 20:56:21 GMT):
User User_3 added by rjones.

rjones (Fri, 14 Jun 2019 21:02:25 GMT):
@danielhardman I added this, which is the sample circleci yml: https://github.com/hyperledger/aries-rfcs/pull/86

rjones (Fri, 14 Jun 2019 21:03:34 GMT):
It will publish results here (once you edit the yml and merge): https://circleci.com/gh/hyperledger/workflows/aries-rfcs

rjones (Fri, 14 Jun 2019 21:03:58 GMT):
if you don't want to use CircleCI, feel free to close my PR as not needed. I just didn't want to get in your way of moving forward

danielhardman (Fri, 14 Jun 2019 21:06:04 GMT):
I don't have a strong opinion about which CI to use, except that I want it to be dead simple. The "build" step is probably going to be a no-op; I just want some kind of test mechanism that I can use to enforce quality of the docs. Is CircleCI one you like and recommend to other HL projects? I'm happy to use it if HL infrastructure will automatically service the project for us...

rjones (Fri, 14 Jun 2019 21:07:19 GMT):
It's free for open source projects, and it's kind of the market leader, so yes.

rjones (Fri, 14 Jun 2019 21:07:37 GMT):
and it's under your control, as a project maintainer

danielhardman (Fri, 14 Jun 2019 21:07:39 GMT):
Okay, great. CircleCI it is. I would like another couple Aries maintainers to weigh in before I accept the PR, just so I know they're cool with where I'm headed. I don't want them to be unhappy with what I've done.

rjones (Fri, 14 Jun 2019 21:08:03 GMT):
sure. The other thing is - that's the sample config - you'll need to put something interesting in there

danielhardman (Fri, 14 Jun 2019 21:08:18 GMT):
Yup. I'm reading CircleCI docs now.

rjones (Fri, 14 Jun 2019 21:08:42 GMT):
And I selected the "python" project type, which is probably the wrong one.

rjones (Fri, 14 Jun 2019 21:09:27 GMT):
it takes like three clicks for me to enable a new repo, so just tell me when you want a new one to build and I'll go on my PPC adventure

danielhardman (Fri, 14 Jun 2019 21:09:38 GMT):
Okay, excellent.

rjones (Fri, 14 Jun 2019 21:09:58 GMT):
If you need access to features that require money - there is money to spend, just let me know.

danielhardman (Fri, 14 Jun 2019 21:10:20 GMT):
Okay. But probably not needed. This is very simple stuff.

TelegramSam (Fri, 14 Jun 2019 21:18:09 GMT):
:thumbsup: on this channel.

rjones (Fri, 14 Jun 2019 21:18:34 GMT):
TelegramSam

rjones (Fri, 14 Jun 2019 21:18:37 GMT):
swcurran

kdenhartog (Fri, 14 Jun 2019 22:26:32 GMT):
I'm in support of using a CI pipeline.

rjones (Fri, 14 Jun 2019 22:35:12 GMT):
Cool. If/when you went circle ci enabled elsewhere just say so

danielhardman (Fri, 14 Jun 2019 23:01:44 GMT):
Okay, please enable CircleCI on the repo. I have it passing integration with one unit test.

danielhardman (Fri, 14 Jun 2019 23:02:09 GMT):
@rjones

danielhardman (Fri, 14 Jun 2019 23:03:58 GMT):
Thanks. It's working!

danielhardman (Fri, 14 Jun 2019 23:04:54 GMT):
@here There is now an active CI for the aries-rfcs repo. It succeeds if index.md is up-to-date, and fails if it's outdated. We can add more stuff to it later.

danielhardman (Sat, 15 Jun 2019 04:41:52 GMT):
@here Can someone review this trivial tweak to instructions in the README? It makes it easier to figure out what's the next RFC num. https://github.com/hyperledger/aries-rfcs/pull/89

callahan (Sat, 15 Jun 2019 09:16:21 GMT):
Has joined the channel.

rjones (Sat, 15 Jun 2019 13:22:53 GMT):
@danielhardman I meant to ask how many, if any, mandatory reviews you wanted for that repo. I picked 1

george.aristy (Sun, 16 Jun 2019 13:43:48 GMT):
Has joined the channel.

danielhardman (Mon, 17 Jun 2019 15:59:22 GMT):
@kdenhartog ^^

kdenhartog (Mon, 17 Jun 2019 16:00:21 GMT):
Yeah I can merge it now

danielhardman (Mon, 17 Jun 2019 16:04:23 GMT):
@here: @rjones asks an important question. For the aries-rfcs repo, do we want to require a formal review of each PR, separate from the implicit review of whichever maintainer clicks the "Merge" button? We deliberately tried to streamline the process on that repo such that getting something merged had minimal impedance. The only things we are checking for with RFC proposals is minimal conformance to document standards, reasonable terminology, and hyperlinks. We can accomplish this with the 1 mandatory reviewer that Ry picked, or with zero, or with >1. What is our preference? An argument for keeping Ry's choice of 1 is that some PRs aren't simple RFC proposals, but rather suggestions about meaningful updates to RFCs. For those, I would say reviewers should be >= 1, and we should possibly have a more ambitious process...

danielhardman (Mon, 17 Jun 2019 16:04:23 GMT):
@here: @rjones asks an important question. For the aries-rfcs repo, do we want to require a formal review of each PR, separate from the implicit review of whichever maintainer clicks the "Merge" button? We deliberately tried to streamline the process on that repo such that getting something merged had minimal impedance. The only things we are checking for with initial RFC proposals (most common PR type thus far) is minimal conformance to document standards, reasonable terminology, and hyperlinks. We can accomplish this with the 1 mandatory reviewer that Ry picked, or with zero, or with >1. What is our preference? An argument for keeping Ry's choice of 1 is that some PRs aren't simple RFC proposals, but rather suggestions about meaningful updates to RFCs. For those, I would say reviewers should be >= 1, and we should possibly have a more ambitious process...

kdenhartog (Mon, 17 Jun 2019 16:14:55 GMT):
I think 1 is fine because the maintainer who is merging can also be the one approving the PR. Something I've tried to do when merging PRs that aren't moving status is give a short summary as a backlog of why I'm accepting the PR. That way there's a record of my thinking as well as who merged it. I like the idea of using a DCO to keep the quality up while keeping the additional effort minimal on both maintainers and committers.

swcurran (Mon, 17 Jun 2019 16:22:45 GMT):
I think the guidance be that the reviewer should be the "facilitator" of the document, if known. If it is the facilitator submitting the change, it would just be one of the maintainers.

danielhardman (Mon, 17 Jun 2019 16:26:23 GMT):
Separate question thread: folder naming conventions for decorators and protocols

danielhardman (Mon, 17 Jun 2019 16:26:23 GMT):
Thread: folder naming conventions for decorators and protocols

danielhardman (Mon, 17 Jun 2019 16:28:19 GMT):
I noticed when I was doing some cleanup last Friday that we have some RFCs that have the word "protocol" in their folder name, and others that are about protocols that lack that word. Similarly, we have some RFCs that have the word "decorator" in their folder name, and others that don't. For the sake of consistency and clarity, how do you feel about stipulating that protocol RFCs have "protocol" in their names, and decorator RFCs have "decorator" in their names? I'd like to decide this early, since we are creating permalinks as the RFCs get merged...

danielhardman (Mon, 17 Jun 2019 16:31:21 GMT):
Thread: naming of other aries repos

danielhardman (Mon, 17 Jun 2019 16:33:49 GMT):
I'm warming up to the idea of calling the various top-level agent frameworks "aries-xyz", where xyz is a programming language. This would make the project-formerly-known-as-indycat into "aries-python". We would keep names like "aries-sdk", "aries-rfcs", etc. And we would use the top-level aries repo as a documentation/orientation repo for people landing in the aries ecosystem. Are there opposing opinions to this strategy, or was I the only holdout?

swcurran (Mon, 17 Jun 2019 16:43:03 GMT):
I think that sounds right.

danielhardman (Mon, 17 Jun 2019 16:49:47 GMT):
BTW, I suggest that protocol versions NOT appear in a protocol RFC's folder name/permalink. Rather, I suggest that evolutions of the protocol version become subdocuments in that protocol. When a protocol first gets defined it's maybe 0.9, and the folder name might be "foo-protocol". The main README.md says that the current version is 0.9. Then, when version 1.0 is formalized, the main README.md is updated to describe 1.0, and a new doc called "version-0.9.md" is created and hyperlinked, so people needing to find the 0.9 docs can find them. This has the effect that the latest version of the protocol is the most natural permalink, but permalinks to older versions can be created if need be. Thoughts?

danielhardman (Mon, 17 Jun 2019 17:57:34 GMT):
@TelegramSam , could you review this PR? https://github.com/hyperledger/aries-rfcs/pull/90

TelegramSam (Mon, 17 Jun 2019 18:08:30 GMT):
@danielhardman approved. Waiting for circleci approval.

TelegramSam (Mon, 17 Jun 2019 18:09:56 GMT):
I like aries-- when a language is involved.

TelegramSam (Mon, 17 Jun 2019 18:11:20 GMT):
the difference between aries-python and aries-agent-python depends on what aries should be seen as to the initial user.

TelegramSam (Mon, 17 Jun 2019 18:49:29 GMT):
so, @dbluhm and I wrote a thing: https://github.com/TelegramSam/aries-staticagent-python I'm not sure if the proposed repo name is the right answer. Thoughts?

dbluhm (Mon, 17 Jun 2019 18:49:29 GMT):
Has joined the channel.

TelegramSam (Mon, 17 Jun 2019 18:50:01 GMT):
(Of course, we plan to move this to an Aries Repo in Hyperledger)

TelegramSam (Mon, 17 Jun 2019 18:56:58 GMT):
This code should end up as a python package, as well as exist for examples and documentation.

TelegramSam (Mon, 17 Jun 2019 18:57:46 GMT):
Does that mean each shippable artifact needs it's own repo? Thoughts?

TelegramSam (Mon, 17 Jun 2019 19:57:38 GMT):
I've added a migration notice to the main aries repos. This will help guide people while we work out the details: https://github.com/hyperledger/aries

esplinr (Mon, 17 Jun 2019 22:25:10 GMT):
Has joined the channel.

esplinr (Tue, 18 Jun 2019 00:01:53 GMT):
I share Sam's concern that aries- might be too limiting, as we might have eventually have aries-agent-python and aries-wallet-python

esplinr (Tue, 18 Jun 2019 00:02:19 GMT):
But I see some advantage to having a single place where Pythonistas might go to find all things Aries. Maybe we prefer to have them in the same repo.

esplinr (Tue, 18 Jun 2019 00:02:39 GMT):
I don't feel strongly about it, but that's the arguments that I see.

esplinr (Tue, 18 Jun 2019 00:02:39 GMT):
I don't feel strongly about it, but those are the arguments that I see.

danielhardman (Tue, 18 Jun 2019 00:03:24 GMT):
Okay, sounds like @TelegramSam and @esplinr are aligned and thinking differently from @swcurran . I was coming around to Stephen's point of view but could be happy with whatever consensus emerges. So I'll leave it to the 3 of you to hammer out a compromise.

esplinr (Tue, 18 Jun 2019 00:03:54 GMT):
How does Circle CI relate to the GitLab CI that Indy has been doing?

TelegramSam (Tue, 18 Jun 2019 00:04:50 GMT):
I just noticed that one of my messages didn't work because I used angle braces. 🤨

swcurran (Tue, 18 Jun 2019 00:05:34 GMT):
This is too funny. I started with aries-python-agent, Sam convinced me that aries-python was right for what we have, now he is on the other side :-). Maybe I misunderstood him. I think this thing is as close to "aries" as there is going to be, so I would leave off "thing" for this element. I would be OK otherwise.

TelegramSam (Tue, 18 Jun 2019 00:06:22 GMT):
I agree with leaving thing off for the agent.

esplinr (Tue, 18 Jun 2019 00:06:24 GMT):
Based on Stephen's response, I formally declare that I don't care how it gets named. We can always change later.

TelegramSam (Tue, 18 Jun 2019 00:06:30 GMT):
Lol

danielhardman (Tue, 18 Jun 2019 00:06:48 GMT):
Okay, it's down to Stephen and Sam to form a grand compromise. :-)

TelegramSam (Tue, 18 Jun 2019 00:07:43 GMT):
Also, did you see my aries-staticagent-python proposal?

swcurran (Tue, 18 Jun 2019 00:08:08 GMT):
I did...it's my homework.

TelegramSam (Tue, 18 Jun 2019 00:08:24 GMT):
Naming matters there too.

esplinr (Tue, 18 Jun 2019 00:16:20 GMT):
I saw the thread in #aries

danielhardman (Tue, 18 Jun 2019 03:48:35 GMT):
@here: I have a new PR that fixes tons of broken or suboptimal hyperlinks in our RFCs, and that creates a unit test that checks for problems. Please review and merge: https://github.com/hyperledger/aries-rfcs/pull/91

kdenhartog (Tue, 18 Jun 2019 03:57:03 GMT):
I just did a quick review and approval. Given it's a bit larger of a PR than I was expecting and I only quickly reviewed it I'm going to let it sit for a bit until I can get some time to do a more in depth scan tomorrow or someone else gets a chance to review it as well. Does that work for you @danielhardman

kdenhartog (Tue, 18 Jun 2019 03:57:27 GMT):
Mainly just want to test the code and make sure it's running properly on my machine

kdenhartog (Tue, 18 Jun 2019 03:57:53 GMT):
All the editorial changes looked fine and only updated links to properly follow MD format.

kdenhartog (Tue, 18 Jun 2019 03:59:55 GMT):
Also, I was going to merge PR #90 just now but it's still hanging from the CircleCI for me.

kdenhartog (Tue, 18 Jun 2019 04:00:56 GMT):
Do we need to add any workers or anything to the CircleCI for these to actually run? I assumed these would be light and fairly quick to run even on a small machine.

swcurran (Tue, 18 Jun 2019 04:40:02 GMT):
Awesome stuff @danielhardman - that's the lazy (and best) way to check that. Very cool. Ran the script and did a quick scan and it looks good.

kdenhartog (Tue, 18 Jun 2019 04:52:56 GMT):
Cool I'll go ahead and merge it then. Thanks for checking it.

danielhardman (Tue, 18 Jun 2019 16:55:00 GMT):
I'm going to reverse my opinion from yesterday and say that I don't think we want to require a review before a merge. Here's why: We have 2 different kinds of PRs. There are substantive PRs, where the content is being updated in a way that matters to the community, and then there are "tweak" PRs where we're fixing a missing comma or something equally trivial. The enforcement doesn't distinguish between them, which means that even trivial stuff has the impedance of getting a review. I think that's going to make it less likely that we'll fix minor issues. It'll just be too much bother, so we'll let those issues just fester--sort of like a "broken windows" phenomenon for the repo (https://en.wikipedia.org/wiki/Broken_windows_theory). Yesterday I raised trivial PR 90, and Sam obligingly reviewed and approved it. However, today I committed a minor improvement, and found that I had invalidated Sam's approval. So it now needs to be reviewed all over again. This despite the fact that a lot of the things we check for are now enforced by unit test--so we already have an automated review of sorts, on top of anything humans might do. I think I'd rather leave the management of "tweak" PRs up to maintainer judgment plus automation, with the option that any of us could fix a hyperlink or comma whenever we see it, with no approval other than CI. This is trusting us to use good judgment and not unilaterally commit something that deserves community discussion. I think that's a good risk to take.

rjones (Tue, 18 Jun 2019 16:55:39 GMT):
@danielhardman tell me to make the change and I will.

rjones (Tue, 18 Jun 2019 16:55:56 GMT):
I can also uncheck the "dismiss approvals on update" option

danielhardman (Tue, 18 Jun 2019 17:01:30 GMT):
Let's wait and see what the other maintainers think; i don't want to change the policy just on my own say-so.

danielhardman (Tue, 18 Jun 2019 17:03:06 GMT):
BTW, @TelegramSam or @kdenhartog , would you mind re-reviewing PR #90? Since it needed a new review, I added a more substantive change -- a couple paragraphs to the best practices RFC explaining what logic we're enforcing on hyperlinks. https://en.wikipedia.org/wiki/Broken_windows_theory

swcurran (Tue, 18 Jun 2019 17:09:00 GMT):
I agree with what @danielhardman says. Maintainers will do the right thing (right?), and people can always request reviews to indicate that they are needed.

TelegramSam (Tue, 18 Jun 2019 20:44:10 GMT):
approved and merged.

swcurran (Tue, 18 Jun 2019 21:37:54 GMT):
PR for migrating the 0022-cross-domain-messaging HIPE (with updates) submitted. Changes made to reflect new terminology, inbound routing concepts and adding all the misisng links in the doc.

danielhardman (Wed, 19 Jun 2019 00:13:28 GMT):
Okay, @rjones , we've let it sit long enough. No objections from other maintainers. Please change the review requirement to 0 instead of 1.

danielhardman (Wed, 19 Jun 2019 00:14:28 GMT):
BTW, @rjones , the CI builds seem to work like a charm for my pull requests, but everybody else's don't trigger builds; the PR just waits for the build to happen, seemingly forever. Is this because I actually turned on cicircle on my fork, but nobody else did?

rjones (Wed, 19 Jun 2019 00:59:54 GMT):
not sure. let me look

rjones (Wed, 19 Jun 2019 01:03:18 GMT):
I uninstalled circle CI on github for that repo, then re-enabled it.

kdenhartog (Wed, 19 Jun 2019 07:05:31 GMT):
Just getting back to this now. The number won't make much of a difference for me. I plan to still review them and state why I'm merging or why I intend to hold off and wait for another reviewer. If it makes it easier for others that's fine for me.

TelegramSam (Wed, 19 Jun 2019 14:47:03 GMT):
https://github.com/hyperledger/aries-rfcs/pull/95 (BasicMessage RFC)

danielhardman (Wed, 19 Jun 2019 15:44:35 GMT):
I reviewed. Needs one change: folder name should have the RFC number in it and then /index.md updated again. Then I'll merge.

TelegramSam (Wed, 19 Jun 2019 15:54:07 GMT):
argh. forgot that.

TelegramSam (Wed, 19 Jun 2019 15:55:59 GMT):
fixed.

danielhardman (Wed, 19 Jun 2019 17:08:25 GMT):
Now you need to update /index.md. :-) Sorry to be picky; I'm just trying to preserve the high bar that we've set now that we've turned on unit tests and such.

TelegramSam (Wed, 19 Jun 2019 17:10:46 GMT):
I'll catch up. fixed. :)

danielhardman (Wed, 19 Jun 2019 17:12:18 GMT):
Merged.

dbluhm (Wed, 19 Jun 2019 18:02:15 GMT):
I think we ought to update the topic on #indy-agent to point to #aries. A banner like the one on #indy-maintainers may be helpful as well.

dbluhm (Wed, 19 Jun 2019 18:02:15 GMT):
I think we ought to update the topic on #indy-agent to point to #aries. A banner like the one on #indy-maintainers point there may be helpful as well.

dbluhm (Wed, 19 Jun 2019 18:02:15 GMT):
I think we ought to update the topic on #indy-agent to point to #aries. A banner like the one on #indy-maintainers pointing there may be helpful as well.

mbanerjee (Wed, 19 Jun 2019 19:13:41 GMT):
Has joined the channel.

danielhardman (Wed, 19 Jun 2019 19:38:49 GMT):
FYI, I updated the /README.md in the aries repo with a bit more info. In particular, I added a section about the relationship between Aries and Indy, because many people are asking about it. You can use this hyperlink to refer people to it: https://github.com/hyperledger/aries/blob/master/README.md#relationship-to-hyperledger-indy I also added all Aries logos to the aries repo, in the /collateral folder

jakubkoci (Wed, 19 Jun 2019 20:00:14 GMT):
Has joined the channel.

TelegramSam (Wed, 19 Jun 2019 20:49:38 GMT):
so, `aries-cloudagent-python` and `aries-staticagent-python`?

TelegramSam (Wed, 19 Jun 2019 21:26:23 GMT):
@swcurran @danielhardman ^

swcurran (Wed, 19 Jun 2019 21:27:17 GMT):
Just about to type the same thing. Yes. PyPi package will by `aries_cloudagent`

swcurran (Wed, 19 Jun 2019 21:27:17 GMT):
Just about to type the same thing. Yes. PyPi package will be `aries_cloudagent`

danielhardman (Thu, 20 Jun 2019 01:55:14 GMT):
Sounds good

danielhardman (Thu, 20 Jun 2019 04:38:57 GMT):
Cross-posting this from #indy-maintainers, FYI. 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.

TelegramSam (Thu, 20 Jun 2019 17:05:19 GMT):
aries-staticagent-python has been migrated to hyperledger: https://github.com/hyperledger/aries-staticagent-python

rjones (Thu, 20 Jun 2019 17:53:53 GMT):
via force-push?

TelegramSam (Thu, 20 Jun 2019 18:08:31 GMT):
I don't think so.

TelegramSam (Thu, 20 Jun 2019 18:10:01 GMT):
I added a new remote, then did a git pull --allow-unrelated-histories, which created a merge commit between the repo first commit and the existing ones.

TelegramSam (Thu, 20 Jun 2019 18:10:27 GMT):
@rjones ^

TelegramSam (Thu, 20 Jun 2019 18:12:23 GMT):
then just a push, and it took it.

rjones (Thu, 20 Jun 2019 19:02:47 GMT):
Cool

TelegramSam (Thu, 20 Jun 2019 19:42:21 GMT):
@rjones to be honest, I lost the link to the guide that was shared on how to do this. Found this way, and it seemed straightforward.

rjones (Thu, 20 Jun 2019 20:18:42 GMT):
That’s exactly how I did it

TelegramSam (Thu, 20 Jun 2019 20:39:14 GMT):
I'm glad that I was accidentally right.

swcurran (Thu, 20 Jun 2019 21:05:32 GMT):
@rjones @TelegramSam - we're going to be shortly essentially transferring a bcgov repo (currently called bcgov/indycat-agent, to be renamed and populated from the bcgov/indy-catalyst repo, agent folder). I'm thinking that we should be transferring that repo to Hyperledger vs. copying the code/history into an existing repo. E.g. that there should be an identifiable transaction that moves the repo from BC Gov to Hyperledger. Thoughts on that?

TelegramSam (Thu, 20 Jun 2019 21:06:02 GMT):
identifiable transaction?

swcurran (Thu, 20 Jun 2019 21:06:22 GMT):
Technically it doesn't matter, but it seems to be me that it should be done that way so we can point to it and say - "hey, BC Gov contributed that".

TelegramSam (Thu, 20 Jun 2019 21:06:31 GMT):
ah, this one is only part of the source repo, not the whole repo.

swcurran (Thu, 20 Jun 2019 21:06:42 GMT):
identifiable transaction - the transfer of the repo

TelegramSam (Thu, 20 Jun 2019 21:06:45 GMT):
That is harder to do and maintain history.

swcurran (Thu, 20 Jun 2019 21:06:51 GMT):
Yes - the whole repo.

swcurran (Thu, 20 Jun 2019 21:07:18 GMT):
No - you just go to admin and say "Transfer this repo to this other entity". At least I think that's what you do.

TelegramSam (Thu, 20 Jun 2019 21:07:31 GMT):
oh, so this is indy cat as a whole?

TelegramSam (Thu, 20 Jun 2019 21:08:01 GMT):
there is another way to transfer history if needed. I just did it on the staticagent.

swcurran (Thu, 20 Jun 2019 21:08:17 GMT):
No - we are doing - indy-catalyst/agent to new repo indycat-agent in bcgov, and then transfer that repo intact to Hyperledger.

swcurran (Thu, 20 Jun 2019 21:08:40 GMT):
At least i think that is the appropriate logistics to be done.

TelegramSam (Thu, 20 Jun 2019 21:08:45 GMT):
ah.

TelegramSam (Thu, 20 Jun 2019 21:09:22 GMT):
I didn't transfer the repo, but I suppose that could be done instead of the merge trick I did for the other repo.

swcurran (Thu, 20 Jun 2019 21:11:57 GMT):
Yes - that's what I realized. But for this, I don't think that's the way to go.

rjones (Thu, 20 Jun 2019 22:03:51 GMT):
@swcurran the way to send a whole repo is to transfer it to me, ryjones, on github. another alternative is to make me an owner of the donating org, and I'll do the transfer and remove myself.

swcurran (Thu, 20 Jun 2019 22:53:32 GMT):
Hmm...not thinking the BC Gov is going to want to give you control over the organization, :laughing: . We'll look to see what's possible. We want to transfer it directly from BC Gov to Hyperledger if at all possible. We've got a bit of time (but not much) to figure out if that's possible and how. And of course, we can always fall back to the push the commits method.

rjones (Thu, 20 Jun 2019 23:51:43 GMT):
this is literally how all of the repos landed in the hyperledger org at the start. Fabric, Sawtooth, etc.

rjones (Thu, 20 Jun 2019 23:53:03 GMT):
the issue with repo transfer from org to org is the person that does it needs to be an owner of both orgs.

swcurran (Fri, 21 Jun 2019 00:09:33 GMT):
That is so bizarre. OK - thanks. I'll check around here.

bbehlendorf (Fri, 21 Jun 2019 00:14:09 GMT):
Has joined the channel.

bbehlendorf (Fri, 21 Jun 2019 00:14:14 GMT):
If it's the "optics: of having Ry be a part of your GH org or assigning the repo to Ry that is challenging, since it appears to suggest that BCGov is giving it to Ry and not to Hyperledger, what if instead we set up a third GH org, call it "hyperledger-inbound", where both Ry and you guys can be owners, but it's considered "owned" and managed by the LF. Then Ry transfers it from "hyperledger-inbound" to the right place in "hyperledger". Does this make sense, solve anything?

danielhardman (Fri, 21 Jun 2019 01:04:50 GMT):
I worked with @rjones to transfer the former Sovrin Foundation repos that are now HL Indy repos. What I remember is that I simply went into the repo settings and changed the owner. I didn't make Ry an owner inside SF. HL's github account then got a notification that a repo transfer was proposed, and Ry approved it as an HL owner. It was super easy and did not involve all of the complexity we're talking about above.

swcurran (Fri, 21 Jun 2019 04:04:24 GMT):
I'm hoping that is how it will work - that's what the documentation appears to say. But it is ambiguous, and Ry has a lot more experience than I. We'll try to do it that way, and if it doesn't work, we'll go to plan B or C.

kdenhartog (Fri, 21 Jun 2019 04:45:12 GMT):
after BC do we bring the gov? :sunglasses: :drum:

rjones (Fri, 21 Jun 2019 07:55:45 GMT):
I created a test org, hyperledger-transfer. If you want to see how it works, feel free to make either a personal repo or a test repo containing only the Apache 2.0 license file and let's practice repo transfers.

rjones (Fri, 21 Jun 2019 07:56:40 GMT):
Transfer of the repo has nice benefits - issues, followers, stars, etc come with. Also, anyone with the repo cloned or forked will end up in the right place due to GitHub redirects.

rjones (Fri, 21 Jun 2019 10:23:55 GMT):
The case I can think of where I was made owner of an outside org was for composer

dbluhm (Fri, 21 Jun 2019 16:41:02 GMT):
@rjones I noticed that aries-staticagent-python has "generated from rjones/ht" beneath the repo name. Not that I don't like having your name in the repo lol but can we get rid of that?

dbluhm (Fri, 21 Jun 2019 16:41:02 GMT):
@rjones I noticed that aries-staticagent-python has "generated from ryjones/ht" beneath the repo name. Not that I don't like having your name in the repo lol but can we get rid of that?

rjones (Fri, 21 Jun 2019 18:39:46 GMT):
I don't know. I used that as a template to make things easier and I'm never doing that again

rjones (Fri, 21 Jun 2019 18:39:46 GMT):
@dbluhm easier said than done

rjones (Fri, 21 Jun 2019 18:39:46 GMT):
@dbluhm easier done than said

rjones (Fri, 21 Jun 2019 18:41:59 GMT):
(yes)

jadhavajay (Mon, 24 Jun 2019 15:08:46 GMT):
Has joined the channel.

danielhardman (Thu, 27 Jun 2019 23:20:49 GMT):
@rjones We appear to be caught in one of those funny limbo states where CircleCI is not building the aries-rfc repo. See https://github.com/hyperledger/aries-rfcs/pull/102.

danielhardman (Thu, 27 Jun 2019 23:20:54 GMT):
Any thoughts?

danielhardman (Thu, 27 Jun 2019 23:21:23 GMT):
As a non-owner, I am stuck. Can't merge, can't request that the CI be re-run, can't cancel.

danielhardman (Thu, 27 Jun 2019 23:22:03 GMT):

Screen Shot 2019-06-27 at 5.21.52 PM.png

danielhardman (Thu, 27 Jun 2019 23:22:26 GMT):
And when I go into the CircleCI dashboard, I don't see any build in progress, either.

arjanvaneersel (Fri, 28 Jun 2019 10:58:49 GMT):
Has joined the channel.

danielhardman (Fri, 28 Jun 2019 15:08:57 GMT):
Pinging Ry again about the above problem; note that I've now raised another PR that is also stalled. @rjones ^^

danielhardman (Fri, 28 Jun 2019 15:42:34 GMT):
Did you fix this, Ry? It suddenly started working...

danielhardman (Fri, 28 Jun 2019 15:42:59 GMT):
@all, could someone merge this? https://github.com/hyperledger/aries-rfcs/pull/103

rjones (Fri, 28 Jun 2019 15:48:46 GMT):
I didn’t do anything to either

rjones (Fri, 28 Jun 2019 15:49:39 GMT):
I got home from the airport yesterday, passed out, and just woke up.

rjones (Fri, 28 Jun 2019 17:02:02 GMT):
@danielhardman Do you see build status here? https://circleci.com/gh/hyperledger/aries-rfcs

rjones (Fri, 28 Jun 2019 17:04:24 GMT):
I see you follow the project, but I can't figure out how to add you to the project so you can re-trigger builds

danielhardman (Fri, 28 Jun 2019 17:23:07 GMT):
Yes, I can see the build status, but I don't see a way to re-trigger a build. Maybe I'm missing something that's there. Anyway, it seems to be the case that when a PR is stalled like this, another commit to the PR may re-trigger the build and allow me to get unstuck. So I've got a workaround.

rjones (Fri, 28 Jun 2019 17:30:28 GMT):
In the upper right corner here, do you see the rerun button? https://circleci.com/gh/hyperledger/aries-rfcs/21

rjones (Fri, 28 Jun 2019 17:30:48 GMT):

Screen Shot 2019-06-28 at 10.30.39 AM.png

danielhardman (Fri, 28 Jun 2019 17:51:21 GMT):
@rjones Yes, I do see that. However, this won't help if the job isn't running in the first place; it's only useful if the job has been triggered at least once. Also, it reruns the workflow with the snapshot of the code it first ran against, not with latest, so it wouldn't help to trigger a new build with a new version of the code, only a new build against the code as it existed before. With the stall I was experiencing, no build had ever been triggered in response to my PR being raised, so it would not have helped.

rjones (Fri, 28 Jun 2019 17:51:49 GMT):
ah, I misunderstood, sorry.

troyronda (Fri, 28 Jun 2019 17:59:44 GMT):
Has joined the channel.

troyronda (Fri, 28 Jun 2019 18:49:23 GMT):
Hey folks - As you may have seen on #aries-sdk (or DIF channels), we've been working on native Golang DIDComm/Agent framework libraries. We have, so far, split up the functionality by concept (e.g., DIDComm "building blocks" vs Agent Framework [vs Hubs]). See this post: https://chat.hyperledger.org/channel/aries-sdk?msg=r45GyBg4DqnC6AJ6C. I also feel that it is better to build common functionality within a Foundation (be it Hyperledger or DIF). So I'd like to better understand (and/or kick up a conversation): (1) How others view splitting up the library architecture; (2) Which foundation should host each part; and (3) I'd like to propose that we create Go framework repos [in the right place] and start landing/maintaining code :). As mentioned previously, we are working on a native Go implementation of DIDComm/Frameworks (rather than wrapper of libindy/vcx). @kdenhartog @danielhardman @swcurran @TelegramSam

swcurran (Fri, 28 Jun 2019 18:50:43 GMT):
@jljordan_bcgov ^^^

jljordan_bcgov (Fri, 28 Jun 2019 18:50:43 GMT):
Has joined the channel.

kdenhartog (Fri, 28 Jun 2019 18:50:53 GMT):
@tplooker and @tomislav curious what your thoughts are on this as well because you've worked on them as well. ^

tplooker (Fri, 28 Jun 2019 18:50:54 GMT):
Has joined the channel.

tomislav (Fri, 28 Jun 2019 18:50:54 GMT):
Has joined the channel.

troyronda (Fri, 28 Jun 2019 18:50:56 GMT):
p.s., our implementation work is currently here: https://github.com/trustbloc

kdenhartog (Fri, 28 Jun 2019 18:52:48 GMT):
FWIW I just got done speaking with @troyronda about this for a bit and it didn't seem very clearcut. If we aren't able to figure it out in this discussion here, I suggest we discuss it on an upcoming Aries WG call. I'll reach out to Daniel Buchner as well to see if he would join (since MSFT is now a HL member)/has opinions on it.

kdenhartog (Fri, 28 Jun 2019 18:53:34 GMT):
From what I can tell this is a new way of architecting agent frameworks based on building blocks, where some conversations happen in DIF and some in Aries.

danielhardman (Fri, 28 Jun 2019 19:02:40 GMT):
@troyronda and @kdenhartog IMO, the path forward is quite clear: put the code in aries-cloudagent-go (or aries-mobileagent-go if that's more appropriate) under Hyperledger. This doesn't necessarily say where *conversations* ought to happen -- that could be on DIF calls or Aries calls or both -- but from a code management perspective, I think you want all the contextual support that HL offers in terms of process, devops support, integration with LinuxFoundation accounts for issue tracking, etc. Plus, the frameworks that are peers of the one you're building are also Aries repos.

danielhardman (Fri, 28 Jun 2019 19:02:40 GMT):
@troyronda and @kdenhartog IMO, the path forward is quite clear: put the code in aries-cloudagent-go (or aries-mobileagent-go if that's more appropriate) under Hyperledger. This doesn't necessarily say where *conversations* ought to happen -- that could be on DIF calls or Aries calls or both -- but from a code management perspective, I think you want all the contextual support that HL offers in terms of process, IP management, devops, integration with LinuxFoundation accounts for issue tracking, etc. Plus, the frameworks that are peers of the one you're building are also Aries repos.

kdenhartog (Fri, 28 Jun 2019 19:05:24 GMT):
It's not an entire agent which is where it becomes less clear. For example there's a separate Hub-store server component, a separate protocol component, a DID Doc parsing component, a hub routing component, etc. Would you put every component within the same repository then?

danielhardman (Fri, 28 Jun 2019 19:05:55 GMT):
Would they be tested and versioned together?

kdenhartog (Fri, 28 Jun 2019 19:06:49 GMT):
There's also one component that's intended to package them together as an agent framework, however someone could just take 1 or 2 components and not use the entire agent framework. As for your question I'm not sure. @troyronda thoughts?

danielhardman (Fri, 28 Jun 2019 19:07:29 GMT):
If they're tested, versioned, and released as a unit, then they should all be in one repo, even if people only use subsets.

danielhardman (Fri, 28 Jun 2019 19:08:59 GMT):
If not, then putting them in separate repos might make sense. There's still a question about overhead for the team maintaining the separate components, and for people trying to discover what they need.

danielhardman (Fri, 28 Jun 2019 19:12:54 GMT):
Maybe the one component that's intended to package them together as an agent framework should be the only thing in aries-agent-go, and all the other stuff should live under the github.com/trustbloc account as its own repos, upon which aries-agent-go depends.

troyronda (Fri, 28 Jun 2019 19:20:46 GMT):
So when thinking about DIDComm and Agent Frameworks, I had viewed them as separate logical blocks. An Aries Agent Framework uses DIDComm but a Hub could also use DIDComm. In that view DIDComm is a set of building blocks to build features into agents, hubs, and other services. When the projects are separated, there must be a clean API for these building blocks; if they are encompassed together then it might be only the Agent Framework API that is clean. Of course, this goes to a similar point about being tested and versioned together. I would say the DIDComm building block layer needs its own clean API and tests against it.

troyronda (Fri, 28 Jun 2019 19:20:46 GMT):
So when thinking about DIDComm and Agent Frameworks, I had viewed them as separate logical blocks. An Aries Agent Framework uses DIDComm but a router, mediator (or even Hub doing those types of services) could also use DIDComm. In that view DIDComm is a set of building blocks to build features into agents, hubs, mediators/routers, and other services. When the projects are separated, there must be a clean API for these building blocks; if they are encompassed together then it might be only the Agent Framework API that is clean. Of course, this goes to a similar point about being tested and versioned together. I would say the DIDComm building block layer needs its own clean API and tests against it.

troyronda (Fri, 28 Jun 2019 19:20:46 GMT):
So when thinking about DIDComm and Agent Frameworks, I had viewed them as separate logical blocks. An Aries Agent Framework uses DIDComm but a router, mediator (or even a Hub doing those types of services) could also use DIDComm. In that view DIDComm is a set of building blocks to build features into agents, hubs, mediators/routers, and other services. When the projects are separated, there must be a clean API for these building blocks; if they are encompassed together then it might be only the Agent Framework API that is clean. Of course, this goes to a similar point about being tested and versioned together. I would say the DIDComm building block layer needs its own clean API and tests against it.

troyronda (Fri, 28 Jun 2019 19:20:46 GMT):
So when thinking about DIDComm and Agent Frameworks, I had viewed them as separate logical blocks. An Aries Agent Framework uses DIDComm but a router, mediator (or a Hub doing those types of services) could also use DIDComm. In that view DIDComm is a set of building blocks to build features into agents, hubs, mediators/routers, and other services. When the projects are separated, there must be a clean API for these building blocks; if they are encompassed together then it might be only the Agent Framework API that is clean. Of course, this goes to a similar point about being tested and versioned together. I would say the DIDComm building block layer needs its own clean API and tests against it.

troyronda (Fri, 28 Jun 2019 19:21:47 GMT):
(it is also true that the Agent Framework would pin its tests against a specific version of the DIDComm library).

troyronda (Fri, 28 Jun 2019 19:23:51 GMT):
(but the main point is that there should be a clean API for both the DIDComm layer and the Agent Framework layer, regardless of the number of repos and the name of the repo).

troyronda (Fri, 28 Jun 2019 19:23:51 GMT):
(but the main point is that there should be a clean, tested, and independent API for both the DIDComm layer and the Agent Framework layer, regardless of the number of repos and the name of the repo).

troyronda (Fri, 28 Jun 2019 19:23:51 GMT):
The main point is that there should be a clean, tested, and independent API for both the DIDComm layer and the Agent Framework layer, regardless of the number of repos and the name of the repo. If there is a single (mono)repo, then I would suggest a generic name like aries-framework-go with subdirectories for each framework component. If there are multiple repos, then put the component name in the repo. @danielhardman @kdenhartog

kdenhartog (Fri, 28 Jun 2019 19:43:26 GMT):
One of the difficulties @troyronda pointed out about this is that it means that trustbloc now has to handle the contributor agreements. It sounds like they want to avoid this which is why they want it in a foundation.

kdenhartog (Fri, 28 Jun 2019 19:46:00 GMT):
I think the components that make this confusing for me is the hub-store, and side-tree components because the conversations and changes aren't discussed in HL.

troyronda (Fri, 28 Jun 2019 19:47:05 GMT):
Yeh sidetree and hub-store are server implementations based on the protocols discussed in DIF; although I think a hub-store client would be useful in HL.

troyronda (Fri, 28 Jun 2019 19:48:30 GMT):
(and a Sidetree client would be a useful resolver as well).

troyronda (Fri, 28 Jun 2019 19:48:30 GMT):
(and a Sidetree client would be a useful DID resolver as well).

troyronda (Fri, 28 Jun 2019 19:59:48 GMT):
At the end of the day, this is still mainly about "I'd like to propose that we create Go framework repo(s)" ... and start landing/maintaining code. This framework contains DIDComm and Agent layers (along with supporting elements such as DID document processing and resolution, DIDComm, Hub storage client). (If framework isn't the right word, let's substitute a better one). This can be done with a single generic repo and subdirectories for each logical module; or multiple more specific repos.

troyronda (Fri, 28 Jun 2019 20:01:53 GMT):
There are many good reasons to have a common place to contribute and collaborate on code. Sure - avoiding more CLAs is one of them.

danielhardman (Fri, 28 Jun 2019 20:04:27 GMT):
@troyronda The desire to have an abstraction around DIDComm that is separate from the abstraction around agents makes sense to me--but it is a new architectural requirement. Until very recently "agent stuff" and "didcomm" were virtual synonyms in the minds of many of us. As a result, we do not currently have a mental model that separates things out in the way you'd like. I am friendly to creating one. However, I wouldn't hold codebase progress hostage to that conversation. Let's get the code somewhere public and then start working on how to divide it up. This makes the process of organizing take longer, but it breaks the logjam of trying to solve too many architectural problems with a single move.

danielhardman (Fri, 28 Jun 2019 20:05:21 GMT):
I would be happy to endorse the creation of an "aries-framework-go" repo to get the ball rolling.

kdenhartog (Fri, 28 Jun 2019 20:07:29 GMT):
That seems like a reasonable approach to me.

troyronda (Fri, 28 Jun 2019 20:57:59 GMT):
Makes sense, thanks.

troyronda (Fri, 28 Jun 2019 20:57:59 GMT):
Makes sense, thanks @danielhardman @kdenhartog

tomislav (Fri, 28 Jun 2019 21:19:50 GMT):
@troyronda SDK's are generally structured in accordance to the language ecosystem they are designed for, but a rough separation can be drawn in few layers: - storage layer (indy wallets, databases, hubs such as ion) - protocol layer (Aries protocol, data contracts) - agent layer (handler architecture, communication services) - application extensions (language/platform specific support for integration) Up until now, a lot of the frameworks have been designed with indy support in mind, and a lot of contracts and even messages part of the Aries protocol are created to eventually support Indy SDK capabilities. While a good abstraction can be made to support other ledgers and SDKs, it's largely a guess work right now due to lack of completeness of other libraries. Example, not many implementations of verifiable credentials with ledger support out there. We're trying to design frameworks with these separations in mind (https://github.com/streetcred-id/agent-framework), but the implementation is far from perfect or generic.

tomislav (Fri, 28 Jun 2019 21:20:59 GMT):
Note that I use Aries instead DIDComm in my comment, this is unintentional

jljordan_bcgov (Sat, 29 Jun 2019 16:01:43 GMT):
Seems to me that this is the basic architecture we have already implemented in Aries-cloudagent-python

jljordan_bcgov (Sat, 29 Jun 2019 16:02:40 GMT):
Which has clear simple APIs for DIDComm and VC exchange and any other arbitrary protocol an implement wishes to add via a python module which is loadable at runtime.

jljordan_bcgov (Sat, 29 Jun 2019 16:03:46 GMT):
The language of implementation of the cloudagent is more or less irrelevant it seems to me as the web developer for a service that will control the agent simply uses the APIs to send and receive signals from the agent

jljordan_bcgov (Sat, 29 Jun 2019 16:05:37 GMT):
So to be frank ... not sure why one would want to incur the NREs of building something from scratch when they can just use what is already had a millions development effort put into it?

jljordan_bcgov (Sat, 29 Jun 2019 16:08:35 GMT):
We plan to put out at “Code with Us” (https://www.bcdevexchange.org/) sometime soon to sponsor the development of a non-Indy verifiable credential exchange protocol using Aries-cloudagent-python as the base which offers DIDComm and storage services

darrell.odonnell (Sat, 29 Jun 2019 16:48:37 GMT):
Has joined the channel.

circlespainter (Sat, 29 Jun 2019 17:08:16 GMT):
Has joined the channel.

swcurran (Sat, 29 Jun 2019 17:32:14 GMT):
To take John's point a bit further. Those of us building low level components (the plumbing) should be experimenting with integrations to other components based on code we have - e.g. integratiing with Ion and Hubs using the python agent we have. That will expose more on the layering and improving the core. I can totally see re-implementing

swcurran (Sat, 29 Jun 2019 17:42:18 GMT):
To take John's point a bit further. For those of us interested in experimenting with integrations, build DIDcomm protocols (e.g. Ion, uPort) and agent services (e.g. storage) that plug into the python agent we have. That's the easiest fastest way to experiment, learn and contribute the learnings. If you want to build an equivalent to the python agent in another language, go for it, but please don't alter the core concepts without discussion - don't unilaterally make something completely different. For developers that just want to build apps - use the agents we have as configurable black boxes and build applications. Don't worry about the plumbing.

swcurran (Sat, 29 Jun 2019 17:46:34 GMT):
I'll leave it to other folks to decide where the code should go. Our choice is Hyperledger and we'll be transferring the `aries-cloudagent-python` repo to Hyperledger on Monday or Tuesday this week - Monday is a holiday here :-).

swcurran (Sat, 29 Jun 2019 17:52:30 GMT):
The conversation question is harder. I personally think the most advanced conversations on agents and scalable implementations leading to the common use of verifiable credentials are going on in Aries calls/chat. Other communities are having deep conversations on other topics - especially different issues with DIDs and storage replication but those are not core to verifiable credentials. If you want to talk agents, including integrations with other verifiable credential implementations, I think Aries if the place to be.

troyronda (Mon, 01 Jul 2019 13:00:47 GMT):
@swcurran As mentioned above, we are working on building a Golang implementation of DIDComm, along with supporting framework libraries. In our case, we would use those framework libraries directly in our applications rather than a cloud agent API intermediary. We had also planned to have a Web API-driven service (reference agent) built on top of those libraries to enable our BDD integration tests (and demos) of the framework.

troyronda (Mon, 01 Jul 2019 13:01:43 GMT):
The thought was that we are working, as a community, to enable a new messaging standard based on DIDs. This means both SDK/framework/component libraries in various languages to enable native integrations for those applications. It also means that there are reference agents that use those libraries to enable an out-of-the-box experience, for easier integration and experimentation.

troyronda (Mon, 01 Jul 2019 13:15:54 GMT):
In terms of the python agent: I certainly understand the point of view that many "end" applications will simply want to use a Web API. However, for those of us working on applications that actually expose that Web API (aka building various forms of agents as it is called here); we need the flexibility to add these capabilities natively using libraries built for our implementation languages. In our case, we are adding these features to an existing Golang service.

swcurran (Mon, 01 Jul 2019 14:38:56 GMT):
Good note @troyronda and I certainly agree that's what we are trying to accomplish and we'll need multiple implementations in multiple languages. I was a little concerned with the ideas of fundamentally different (and hence, possibly not interoperable) architectures. As long as interop remains a top priority, I'm happy.

danielhardman (Mon, 01 Jul 2019 18:38:32 GMT):
@swcurran and @TelegramSam, what do you think about getting an aries-framework-go repo where @troyronda and crew can begin working in a non-trustbloc place? (@troyronda, do you have DCO hygiene taken care of?)

swcurran (Mon, 01 Jul 2019 18:43:49 GMT):
I'm fine with it, but don't completely understand it. We have the aries-go-sdk repo and we eventually will presumably have an aries-agent-go repo, so I'm not sure what goes in the framework repo. If there is a clear vision for the three repos by @troyronda and team, I'm good with it. If there is still experimenting to be done, I'd suggest going with populating the aries-go-sdk in Hyperledger and experimenting in trustbloc (in the open, of course).

TelegramSam (Mon, 01 Jul 2019 21:20:55 GMT):
aries-sdk-go should be an unopinionated language library.

TelegramSam (Mon, 01 Jul 2019 21:21:25 GMT):
aries-framework-go is a good place for opinions.

kdenhartog (Mon, 01 Jul 2019 21:57:54 GMT):
I think Aries-framework-go is a good place for it. The framework from what I understood is going to be taking a bunch of modular components and combining them together.

esplinr (Tue, 02 Jul 2019 01:04:19 GMT):
@troyronda As you worked on your implementation, did you find anything useful in the Indy Go wrapper?

danielhardman (Tue, 02 Jul 2019 12:53:48 GMT):
@rjones I have yet another stalled PR against the aries-rfcs repo: https://github.com/hyperledger/aries-rfcs/pull/105. Could the lack of response from circleci be due to us needing more docker allocation? I don't see any job even scheduled to run against this PR in the hyperledger org's dashboard on circleci.com.

danielhardman (Tue, 02 Jul 2019 12:54:42 GMT):
@kdenhartog or @TelegramSam or @swcurran : Could one of you please approve/merge my PR #103 which has been idling for several days now? https://github.com/hyperledger/aries-rfcs/pull/103

swcurran (Tue, 02 Jul 2019 12:57:03 GMT):
I lack the power.

TelegramSam (Tue, 02 Jul 2019 13:17:08 GMT):
@danielhardman I merged 103, and then I updated 105 with a merge. After that merge, the circleci checks passed. Anyway, both merged.

swcurran (Tue, 02 Jul 2019 16:43:54 GMT):
We're getting ready to do the repo transfer for `aries-cloudagent-python` from bcgov to hyperledger. I'd like to propose that @andrew.whitehead, @nbrempel and myself be maintainers for now. Any objections? Any additions?

andrew.whitehead (Tue, 02 Jul 2019 16:43:55 GMT):
Has joined the channel.

nbrempel (Tue, 02 Jul 2019 16:43:55 GMT):
Has joined the channel.

esplinr (Tue, 02 Jul 2019 16:45:41 GMT):
I have no objection. It will be great to broaden the list as we have contributors from others orgs, but that shouldn't stand in the way of getting the repo published.

TelegramSam (Tue, 02 Jul 2019 17:38:15 GMT):
agree. let's start there and expand

kdenhartog (Tue, 02 Jul 2019 18:18:10 GMT):
No objections here. I'm excited to see it moving into HL!

swcurran (Tue, 02 Jul 2019 20:57:37 GMT):
@rjones - not the owners for the new repo above ^^^^

swcurran (Tue, 02 Jul 2019 20:57:37 GMT):
@rjones - not the maintainers for the new repo above ^^^^ (my github is swcurran).

swcurran (Tue, 02 Jul 2019 20:57:37 GMT):
@rjones - not the maintainers for the new repo above ^^^^

swcurran (Tue, 02 Jul 2019 20:57:37 GMT):
@rjones - note the maintainers for the new repo `aries-cloudagent-python` above ^^^^

rjones (Tue, 02 Jul 2019 21:01:12 GMT):
@swcurran you are a maintainer of https://github.com/orgs/hyperledger/teams/aries-cloudagent-python-committers/members so you may add and remove people as you please

swcurran (Tue, 02 Jul 2019 21:02:59 GMT):
OK - thanks!

swcurran (Tue, 02 Jul 2019 21:03:11 GMT):
Whoohoo!!! Transfer done!!

swcurran (Tue, 02 Jul 2019 21:03:30 GMT):

Clipboard - July 2, 2019 2:03 PM

nbrempel (Tue, 02 Jul 2019 21:06:21 GMT):
🏆

troyronda (Tue, 02 Jul 2019 21:55:25 GMT):
@danielhardman yes DCO hygiene is taken care of.

troyronda (Tue, 02 Jul 2019 21:56:43 GMT):
@esplinr we decided to use native Go libraries to support the crypto behind the protocols, so we don’t have need for a wrapped libindy.

troyronda (Tue, 02 Jul 2019 21:57:25 GMT):
(I assume a wrapped ursa will be needed for anoncred payloads)

esplinr (Tue, 02 Jul 2019 22:02:50 GMT):
Good to know. Thank you.

nbrempel (Tue, 02 Jul 2019 22:47:59 GMT):
Hi @rjones, what is the recommended approach for publishing python packages to https://pypi.org under Hyperledger?

rjones (Tue, 02 Jul 2019 22:56:30 GMT):
@nbrempel I don't know that we have an approach.

rjones (Tue, 02 Jul 2019 22:57:18 GMT):
Docker Hub and NPM were set up as needed - I think you're the first to ask to publish to pypi, so I guess I should set that up

rjones (Tue, 02 Jul 2019 22:58:59 GMT):
@nbrempel looks like I set it up some time ago - https://pypi.org/user/hyperledger/

nbrempel (Tue, 02 Jul 2019 23:06:11 GMT):
Ok, great! Does it have a permissions system? If you're able to give me publish access to a package called `aries-cloudagent` I can publish the initial release

rjones (Tue, 02 Jul 2019 23:10:22 GMT):
So far, I haven't found how to do that.

rjones (Tue, 02 Jul 2019 23:13:38 GMT):
I'm digging into github actions. if you know more about pypi please let me know directly

rjones (Tue, 02 Jul 2019 23:14:00 GMT):
https://github.com/pypa/gh-action-pypi-publish

nbrempel (Tue, 02 Jul 2019 23:27:23 GMT):
yeah, I saw that as well which would be nice to automate it. I have the manual instructions for cutting a release in a pending PR https://github.com/hyperledger/aries-cloudagent-python/pull/36/files

rjones (Wed, 03 Jul 2019 00:04:04 GMT):
OK. Until we figure something automatic I can give it a whirl later in the week if that's OK?

nbrempel (Wed, 03 Jul 2019 01:52:20 GMT):
yep! No rush on it. Thanks

dbluhm (Wed, 03 Jul 2019 12:22:16 GMT):
For the aries-staticagent-python pypi package, I just published it myself under my account with the intention to add as maintainers whoever/whatever would need permission to change or update the package. That allowed me to quickly get a release up manually with the potential for automation in the future.

rjones (Wed, 03 Jul 2019 13:30:10 GMT):
@dbluhm is there some obvious way for me to give people permissions to publish that I'm missing?

dbluhm (Wed, 03 Jul 2019 13:34:03 GMT):
After logging in, it shows "your projects." From there, clicking "manage" on the project then "collaborators" from the left menu allowed me to add people as maintainers on a project which I assume means they can publish to the project but I haven't actually verified that yet

rjones (Wed, 03 Jul 2019 13:34:31 GMT):
ah ha! Since I haven't published, I don't have that option. thank you

rjones (Wed, 03 Jul 2019 13:35:27 GMT):
@nbrempel it looks like - you publish, then later we figure out automation, which is the reverse of what I said yesterday. Sound OK?

dbluhm (Wed, 03 Jul 2019 13:37:16 GMT):
Another note, you can add maintainers to a project you've uploaded but you can also transfer ownership as well so @nbrempel can upload then transfer to hyperledger and leave himself as a maintainer

rjones (Wed, 03 Jul 2019 13:38:13 GMT):
I guess I was expecting something more like Dockerhub, where we have teams and acls somewhat like github

dbluhm (Wed, 03 Jul 2019 14:10:14 GMT):
lol I guess PyPI is too simple for anything like that

nbrempel (Wed, 03 Jul 2019 15:59:56 GMT):
Sounds good!

danielhardman (Thu, 04 Jul 2019 05:18:19 GMT):
All: a large number of RFCs are about protocols. A smaller but still significant number are about decorators. We do not have consistency in the folder names we use for these two categories. We have "service-decorator" and "payment-decorators", but also "message-timing" and "message-tracing" (both of which are about decorators). Most of our protocol folder names don't have "-protocol" on the end, but I'm wondering if they should; "0028-introduce" sounds weird, but "0028-introduce-protocol" much more natural. Anyway, should we establish some naming pattern that we try to follow consistently, before permalinks get entrenched? Or do we not care?

george.aristy (Thu, 04 Jul 2019 15:29:45 GMT):
@danielhardman +1

lukasA (Fri, 05 Jul 2019 08:58:06 GMT):
Has joined the channel.

ajayjadhav (Mon, 08 Jul 2019 11:06:34 GMT):
Has joined the channel.

TelegramSam (Mon, 08 Jul 2019 13:20:14 GMT):
I'm a fan of a `protocol` and `decorator` suffix.

xfreeman (Mon, 08 Jul 2019 13:59:19 GMT):
Has joined the channel.

rjones (Mon, 08 Jul 2019 18:08:48 GMT):
Has left the channel.

rolsonquadras (Tue, 09 Jul 2019 18:32:34 GMT):
Has joined the channel.

troyronda (Tue, 09 Jul 2019 20:07:48 GMT):
@danielhardman @swcurran @TelegramSam @kdenhartog : It would be good to continue on the next steps for a Go (agent/didcomm) framework repo. (I was out last week). The previous thread primarily left off at: https://chat.hyperledger.org/channel/aries-maintainers?msg=q5hx5W2Tj7n5kFLbQ and https://chat.hyperledger.org/channel/aries-maintainers?msg=mSdyxxWqKvP8SwZyE To answer @swcurran previous question on Aries-agent vs Aries-framework vs Aries-sdk, here are a few thoughts: * It seemed that "SDK" repos are effectively for wrapper libraries (unopinionated). So we didn't go down this path for naming. * The repo will contain both libraries that can be used for building an agent, along with a reference implementation (with a particular goal of testing & demonstration). i.e., we particularly wanted to ensure that the libraries are useable "independently" of the reference implementation. * We also want to ensure that the framework is extendable - e.g., you can plug-in additional handlers using extension libraries. * We don't currently need to use an Aries SDK in this (agent/didcomm) framework, but there is an assumed need for Ursa for AnonCreds. So I believe we know what should be part of this particular repo. In regards to naming the repo (agent vs framework). The repo's primary intent is to provide an extendable Aries/DIDComm agent framework (along with supporting libraries) so you could probably argue either way but I tilted towards "framework" due to this primary intent (even though it is intended to contain a reference agent) and my earlier thoughts in the thread about DIDComm layering.

troyronda (Tue, 09 Jul 2019 20:08:24 GMT):
In terms of an additional repo on top, did you have some thoughts on that?

troyronda (Tue, 09 Jul 2019 20:08:24 GMT):
In terms of an additional repo on top, did you have some thoughts on that @swcurran ?

troyronda (Tue, 09 Jul 2019 20:08:24 GMT):
In terms of a possible additional repo on top, did you have some thoughts on that @swcurran ?

danielhardman (Tue, 09 Jul 2019 20:13:19 GMT):
@troyronda , who besides you ought to have commit rights?

danielhardman (Tue, 09 Jul 2019 20:14:03 GMT):
(I am going to get the aries-framework-go repo created so we can move ahead. If we end up renaming it, that's fine. I just don't want us hung up on procedural stuff.)

troyronda (Tue, 09 Jul 2019 20:41:24 GMT):
@danielhardman awesome - sounds good. I'll collect some IDs.

swcurran (Tue, 09 Jul 2019 20:45:36 GMT):
My guess is what you are calling "framework" we are calling "cloudagent", but we'll have to see from the implementation. Each cloudagent instance is an agent that has a corresponding controller instance (with horizontal scaling available). The cloudagent does all the agent processing, has pluggable services and a configurable set of protocols. The controller provides the business logic for the agent - when to initiate protocols, and how to respond to protocol events. We provide examples of controllers, but no concrete repo to fork, since they could be anything - a UI for a person, an actual person (by having the person operate a Swagger UI), an integration with a legacy service, etc, etc.

swcurran (Tue, 09 Jul 2019 20:45:36 GMT):
My guess is what you are calling "framework" we are calling "cloudagent", but we'll have to see from the implementation. Each cloudagent instance is an agent that has a corresponding controller instance (with horizontal scaling available). The cloudagent does all the agent processing, has pluggable services and a configurable set of protocols. The controller provides the business logic for the agent - when to initiate protocols, and how to respond to protocol events. We provide examples of controllers, but no concrete repo to fork, since a controller could be anything - a UI for a person, an actual person (by having the person operate a Swagger UI), an integration with a legacy service, etc, etc.

swcurran (Tue, 09 Jul 2019 20:47:16 GMT):
Our implementation uses a HTTP/JSON interface between the agent and controller (events from agent to controller, admin requests from controller to agent). My guess is that your structure is that the framework is a library, and an agent embeds the library and calls it internally.

swcurran (Tue, 09 Jul 2019 20:47:56 GMT):
Do you think I'm close?

swcurran (Tue, 09 Jul 2019 20:49:26 GMT):
As I've learned, we'll get the name wrong regardless, so I'm good with the names. I'm a little concerned it will be confusing to those arriving into the community, but we'll cross that bridge when we have that problem.

danielhardman (Tue, 09 Jul 2019 21:53:41 GMT):
@troyronda Have at it: https://github.com/hyperledger/aries-framework-go. Make sure to follow DCO. (I'm not sure whether DCO is turned on; usually that shows up in the first commit... @rjones ^^)

rjones (Tue, 09 Jul 2019 21:53:42 GMT):
Has joined the channel.

troyronda (Tue, 09 Jul 2019 22:32:07 GMT):
@danielhardman Nice thanks. Will do. For other initial committers, I would suggest @george.aristy (llorllale), @rolsonquadras (rolsonquadras), @bstasyszyn (bstasyszyn). BTW, who should I ask about turning on CI and enabling branch protection to require code review?

troyronda (Tue, 09 Jul 2019 22:32:07 GMT):
@danielhardman Nice thanks. Will do.

bstasyszyn (Tue, 09 Jul 2019 22:32:08 GMT):
Has joined the channel.

troyronda (Tue, 09 Jul 2019 22:37:11 GMT):
@swcurran Yes - I think that seems close. (with appropriate difference in description due to the framework as library as you said).

danielhardman (Tue, 09 Jul 2019 22:42:43 GMT):
@swcurran One difference that I wonder about is whether Troy's framework is really about *cloud* agents specifically, or if it's more general. I wonder if we should alter our naming conventions so it's consistently more-general-to-more-specific, as in "aries-agent-cloud-python", "aries-agent-static-python", etc. Then, if we have a repo that includes more than one kind of agent thingy, we could just omit the specifier, giving "aries-agent-go". Just a thought.

swcurran (Tue, 09 Jul 2019 22:45:08 GMT):
Like I said, no matter what we do we'll get it wrong 🤣. We've used two names now. I'd say we wait until it's blindingly obvious what we did wrong.

danielhardman (Tue, 09 Jul 2019 22:47:15 GMT):
okay

troyronda (Tue, 09 Jul 2019 22:47:17 GMT):
@danielhardman @swcurran I wouldn't have used *cloud* agents specifically - yes, would say it's more general.

danielhardman (Tue, 09 Jul 2019 22:48:08 GMT):
@kdenhartog or @TelegramSam : do you mind reviewing/merging this PR? https://github.com/hyperledger/aries-rfcs/pull/115

swcurran (Tue, 09 Jul 2019 22:48:18 GMT):
Yes, with approach and language I would not expect the "not mobile" restriction.

troyronda (Tue, 09 Jul 2019 22:49:46 GMT):
yup.

rjones (Wed, 10 Jul 2019 03:50:45 GMT):
@danielhardman thanks for the catch. DCO was not enabled on that repo

peacekeeper (Wed, 10 Jul 2019 18:46:10 GMT):
Has joined the channel.

firas.qutishat (Thu, 11 Jul 2019 17:02:10 GMT):
Has joined the channel.

alank9 (Mon, 15 Jul 2019 23:17:11 GMT):
Has joined the channel.

dbluhm (Tue, 16 Jul 2019 22:29:41 GMT):
I've prepared a "0.1" release of the Aries Protocol Test Suite that I'd like to propose now moving out of my personal repo, transferring ownership to hyperledger under the name aries-protocol-test-suite.

dbluhm (Tue, 16 Jul 2019 22:31:51 GMT):
I've included the connection tests as they were at the connect-a-thon in February as something to start with and expect that more tests and improvements to the test suite can be introduced as PRs.

dbluhm (Tue, 16 Jul 2019 22:32:59 GMT):
https://github.com/dbluhm/aries-protocol-test-suite If you'd like to see what I have together so far

dbluhm (Tue, 16 Jul 2019 22:33:17 GMT):
Any remaining objections? Things that need to be resolved before we make the transfer?

swcurran (Tue, 16 Jul 2019 23:08:06 GMT):
I'd like to have a discussion about the handling of this PR - https://github.com/hyperledger/aries-rfcs/pull/23 In one step this PR deprecated *and* eliminated a protocol, and created a new protocol that seems to only have a name change. The proper handling of this (IMHO - and our developers) is that the existing protocol (connections) should have been marked as deprecated and the new one (did-exchange) should have been added. As well there should have been a lot more flag raising about the change. This change is (hopefully) somewhat of a special case as it was hidden in the transfer from indy-hipe to aries-rfc, but it is definitely not hidden in the implementations that are running. Our solution is to support both protocols for the forseeable future, until we can safely remove the deprecated protocol. I don't think we need to change anything with this, but do I think we need to be more cognizent of such changes given that there implementations running. The implementations aren't running too many protocols, but the core ones should be handled properly when changed.

esplinr (Wed, 17 Jul 2019 00:13:39 GMT):
No objections, but a suggestion: it would be good to update indy-agent to point to where the work is currently happening.

esplinr (Wed, 17 Jul 2019 00:13:39 GMT):
No objections, but a suggestion: it would be good to update indy-agent repo to point to where the work is currently happening.

esplinr (Wed, 17 Jul 2019 00:14:57 GMT):
I was similarly caught off guard by the change, but I agree that this was a special case due to the migration from indy-hipes to aries-rfcs.

dbluhm (Wed, 17 Jul 2019 14:03:36 GMT):
@rjones looks like we're good for a transfer; what does that process look like?

MITomK (Wed, 17 Jul 2019 14:10:25 GMT):
Has joined the channel.

rjones (Wed, 17 Jul 2019 14:42:27 GMT):
transfer it to my github user - ryjones

rjones (Wed, 17 Jul 2019 14:45:11 GMT):
also - tell me who a committer or two is?

rjones (Wed, 17 Jul 2019 14:45:38 GMT):
and make sure the DCO is compliant please

rjones (Wed, 17 Jul 2019 14:46:08 GMT):
https://gist.github.com/ryjones/07ac650dcc5e83c91e8308ec98bacda4

dbluhm (Wed, 17 Jul 2019 14:53:31 GMT):
We'll start with myself (dbluhm on github as well) and @TelegramSam (also TelegramSam on github)

dbluhm (Wed, 17 Jul 2019 14:53:34 GMT):
DCO should be good

rjones (Wed, 17 Jul 2019 14:54:20 GMT):
if you want to do an experiment - make me an admin on the incoming repo while you still own it

dbluhm (Wed, 17 Jul 2019 14:55:53 GMT):
I'm not seeing an obvious "make admin" option; do I need to make you a collaborator?

rjones (Wed, 17 Jul 2019 14:56:27 GMT):
yes. that's an experiment, though. if you want the easier way just transfer it to me directly

rjones (Wed, 17 Jul 2019 14:56:32 GMT):
```(lftools) rjones@penguin:~/aries-protocol-test-suite$ lftools dco check Checking commits in branch origin/master for commits missing DCO... (lftools) rjones@penguin:~/aries-protocol-test-suite$ ```

dbluhm (Wed, 17 Jul 2019 14:57:06 GMT):
I'm good for an experiment

rjones (Wed, 17 Jul 2019 14:57:12 GMT):
do it to it

dbluhm (Wed, 17 Jul 2019 14:57:55 GMT):
Not sure how to interpret this. Does that mean we're good?

rjones (Wed, 17 Jul 2019 14:58:13 GMT):
yes. no commits showed up so you're fine

rjones (Wed, 17 Jul 2019 14:59:08 GMT):
I kind of suspect that since your github account isn't an org, there won't be an admin role to add me to

dbluhm (Wed, 17 Jul 2019 14:59:17 GMT):
Ah

rjones (Wed, 17 Jul 2019 14:59:34 GMT):
invite accepted

rjones (Wed, 17 Jul 2019 15:00:53 GMT):
when I go here: https://github.com/dbluhm/aries-protocol-test-suite I don't see a settings tab

dbluhm (Wed, 17 Jul 2019 15:01:33 GMT):
Interesting. I can't seem to elevate your privileges anymore than what you already have either

dbluhm (Wed, 17 Jul 2019 15:01:44 GMT):
So transfer?

rjones (Wed, 17 Jul 2019 15:01:49 GMT):
OK. just transfer the repo to my user]

rjones (Wed, 17 Jul 2019 15:01:49 GMT):
OK. just transfer the repo to my user

dbluhm (Wed, 17 Jul 2019 15:01:54 GMT):
:thumbsup:

rjones (Wed, 17 Jul 2019 15:12:05 GMT):
https://github.com/hyperledger/aries-protocol-test-suite gtg

dbluhm (Wed, 17 Jul 2019 15:12:21 GMT):
Thanks!

rjones (Wed, 17 Jul 2019 15:12:33 GMT):
thank you!

kdenhartog (Wed, 17 Jul 2019 17:31:32 GMT):
[ ](https://chat.hyperledger.org/channel/aries-maintainers?msg=dpNJKhaWGspNPjZFg) @swcurran I agree as with the approach you suggested. I accepted because it was being moved and we had consensus about the name change. To rephrase how I'm understanding what you're raising, no accepted status RFCs should have a breaking change?

rjones (Wed, 17 Jul 2019 17:43:23 GMT):
I have a question for maintainers of aries-* on github: would you be willing to try a new tool for permission management for your repos? It would involve creating and editing a YAML file in each repo.

dbluhm (Wed, 17 Jul 2019 17:57:26 GMT):
I wouldn't mind for aries-staticagent-python and aries-protocol-test-suite

nbrempel (Wed, 17 Jul 2019 18:02:26 GMT):
I'm happy to try it out!

swcurran (Wed, 17 Jul 2019 18:14:40 GMT):
@kdenhartog - would say no breaking changes when we know there are multiple implementations. In this case, the right thing to do probably was to migrate the HIPE as is with a "deprecated" flag on it and then copy the HIPE again with the new changes.

troyronda (Wed, 17 Jul 2019 18:34:25 GMT):
@rjones sure, interested for Aries-framework-go. Do you have a link to the tool?

kdenhartog (Wed, 17 Jul 2019 19:05:19 GMT):
[ ](https://chat.hyperledger.org/channel/aries-maintainers?msg=mTWYaifTWndWiTuff) @swcurran Multiple implementations would move it to active status from my understanding. Also, we should be including some way of indicating and potentially linking to implementations if we're using that as a distinctive metric. It's worth noting that while I agree that implementations are important metric to consider there's different types we should consider. For example, code that's in production I would consider a production implementation which should encounter as few of breaking changes as possible. However, we may also have prototype implementations which are used to learn and improve the protocols. These are useful, but can handle as many breaking changes as we see fit in my opinion. So I'd suggest that we also indicate what type of implementation it is in the RFC as well.

kdenhartog (Wed, 17 Jul 2019 19:06:52 GMT):
FWIW @danielhardman raised this point when we were moving to the new process. I'm not able to remember why we didn't start doing that.

danielhardman (Wed, 17 Jul 2019 19:18:14 GMT):
I'd be happy to try it in aries-rfcs.

danielhardman (Wed, 17 Jul 2019 19:20:58 GMT):
@swcurran and @kdenhartog : I generally feel aligned with sentiments that both of you expressed. I think we may want to do a better job of tracking which protocols are implemented, and give them a status other than PROPOSED. That would have helped in the specific case that Stephen pointed out, because the bar for changing an ACCEPTED RFC is higher than for changing one that's merely PROPOSED.

rjones (Wed, 17 Jul 2019 19:27:03 GMT):
This is what the file you would need to add would look like:

rjones (Wed, 17 Jul 2019 19:27:04 GMT):
https://github.com/opnfv/releng/blob/master/INFO.yaml

rjones (Wed, 17 Jul 2019 19:27:55 GMT):
this is the schema:

rjones (Wed, 17 Jul 2019 19:27:56 GMT):
https://github.com/lfit/releng-global-jjb/blob/master/info-schema

rjones (Wed, 17 Jul 2019 19:32:09 GMT):
I'm heading out on vacation today, but the author of the tool (Aric) is writing the github integration right now

agardner (Wed, 17 Jul 2019 19:36:18 GMT):
Has joined the channel.

agardner (Wed, 17 Jul 2019 19:36:18 GMT):
there we go

agardner (Wed, 17 Jul 2019 19:37:49 GMT):
I will update the status of the github integration here when its ready

danielhardman (Wed, 17 Jul 2019 20:00:15 GMT):
@swcurran and @kdenhartog : See this section of the DIDComm Best Practices RFC 0074, which talks about what we should do when a protocol is revised. https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0074-didcomm-best-practices#rfc-naming

TelegramSam (Wed, 17 Jul 2019 21:11:17 GMT):
@swcurran @kdenhartog @danielhardman As the perpertrator of the crime, I have to agree with all this as well. Moving the existing to Deprecated, then working on a replacement would be a much better option. It is still possible to do this. Should I revert this one to the original, and make a new one for didexchange?

kdenhartog (Wed, 17 Jul 2019 21:11:50 GMT):
yeah I'm fine if we still do this just to keep things in proper higene

TelegramSam (Wed, 17 Jul 2019 21:12:15 GMT):
The further we deviate (signed invitations, etc. given call today) the more I think this would be useful.

danielhardman (Wed, 17 Jul 2019 21:51:08 GMT):
There was no "crime" here. What was changed was a PR, not a merged spec. That is always legal. And merging the PR was also legal, because there was no pre-existing PR to deprecate. I think we already have a copy of the old protocol over in the indy-hipe repo, and I think we already say that the Aries RFC supersedes it. If that's the case, then I think nothing further needs to be done. If it's not, maybe that should be the target.

danielhardman (Wed, 17 Jul 2019 21:51:46 GMT):
When should we commit such a file?

rjones (Wed, 17 Jul 2019 21:52:07 GMT):
@agardner is working on the implementation

rjones (Wed, 17 Jul 2019 21:52:26 GMT):
@agardner is working on the implementation

swcurran (Wed, 17 Jul 2019 23:17:42 GMT):
I don't think it's a huge issue but bigger than just saying it was all legal and hence OK. It is causing confusion that should be smoother handled in a smoother way. Renaming a protocol is not something that should be handled lightly, and IMHO definitely shouldn't be done as part of another operation (e.g. the move from Indy-HIPE to Aries-RFC). We'll survive - just need to coordinate between the existing implementations.

kdenhartog (Thu, 18 Jul 2019 18:37:49 GMT):
yup, I made a mental note to start checking for this when I'm merging PRs too. Thanks for raising it.

dbluhm (Fri, 19 Jul 2019 14:50:32 GMT):
@danielhardman https://github.com/hyperledger/aries/pull/6 small PR updating links in the Aries repository

danielhardman (Fri, 19 Jul 2019 15:39:51 GMT):
Merged!

danielhardman (Fri, 19 Jul 2019 15:39:55 GMT):
Thank you

swcurran (Fri, 19 Jul 2019 17:23:16 GMT):
Hey folks - interesting bit of learning about decorators that @andrew.whitehead and @sklump have been working on. Thought I would add a note here to highlight this as a test of where to start a discussion about implementation experience. I'm thinking this type of thing should wind up in the RFC itself? In aries-cloudagent-python, the core message handlers scans the messages and processes decorators. That works nicely for cross-cutting decorators - timing, threads, etc. When Stephen K was implementing Issue Credential (RFC 36), an attachment is a required field of the message and it makes sense that it be processed in the protocol. A first cut of his code had some ugly handling of the decorator - a workaround for what was happening in the core. What they came up with to avoid thw workaround and duplicate code/processing is that the core scans the protocol message format and skips processing decorators that are part of the protocol. I believe thc core processing can also be passed a "skip" parameter to skip other decorators. That experience might be useful for other implementations.

sklump (Fri, 19 Jul 2019 17:23:16 GMT):
Has joined the channel.

sklump (Fri, 19 Jul 2019 17:37:43 GMT):
@andrew.whitehead 's final fix is a clever piece of marshmallow-fu that inspects the schema for named fields. If it's in the spec as a field, the decorator extraction process leaves it as-is. So the decorator spec can vary independently of the message spec as the standards progress. I think it's bulletproof.

dbluhm (Fri, 19 Jul 2019 17:39:38 GMT):
Would `~attachment` ever not be processed by the protocol? I can't think of what meaning it could have outside of that given by the message type

sklump (Fri, 19 Jul 2019 17:42:54 GMT):
At present, `~attach` is not a default decorator, so you are correct. The processing extracts decorators like `~thread`, `~timing`, etc. These are conceptually different because they operate orthogonally to the spec. But if some wag in the future wants to put `bad~timing` as a field in the spec, this approach will do the right thing and leave it alone. The Aries#0036 issue-credential v1.0 (draft) PR includes an attachment decorator implementation, but as yet no others use it, so no design decision is necessary.

sklump (Fri, 19 Jul 2019 17:42:54 GMT):
At present, `~attach` is not a default decorator, so you are correct. The processing extracts decorators like `~thread`, `~timing`, etc. These are conceptually different because they operate orthogonally to any Aries message spec. But if some wag in the future wants to put `bad~timing` as a field in the spec, this approach will do the right thing and leave it alone. The Aries#0036 issue-credential v1.0 (draft) PR includes an attachment decorator implementation, but as yet no others use it, so no design decision is necessary.

troyronda (Wed, 24 Jul 2019 19:16:08 GMT):
@TelegramSam @swcurran @kdenhartog I'm confused about this thread. https://github.com/hyperledger/aries-rfcs/issues/137 . I thought DID Exchange replaced Connection.

kdenhartog (Wed, 24 Jul 2019 19:35:23 GMT):
The python agent had the previous ideas from Indy implemented and properly versioned releases. Then when moved to Aries there were changes made that caused breaking changes. This thread is proposing a common way to track who's building implementations and a way to identify when we create breaking changes of the protocol in an RFC.

troyronda (Wed, 24 Jul 2019 19:37:53 GMT):
Are you thinking of having two different RFCs - the existing RFC for DID Exchange and another one for Connections?

troyronda (Wed, 24 Jul 2019 19:52:23 GMT):
Bringing up some questions for this type of situation: - Do both RFCs have effectively the same text (with a name change)? Or a smaller document about the old name or link to a version? - Does the "new" name RFC state that the "old" name is deprecated? - Do new implementations use the "new" name? How is the "old" name treated? e.g., do we default to sending the "new" name?

danielhardman (Fri, 26 Jul 2019 16:54:35 GMT):
@troyronda Yes, the Aries RFC and the Indy HIPE have effectively the same text and the same concepts/flows. The most substantive difference is that the Aries RFC is still fluid (hence @TelegramSam 's intention to shift its status back to PROPOSED), where the Indy HIPE was more stable. Yes, the new RFC references the old one and says it is superseded. Implementations should be targeting DID Exchange Protocol, IMO--not Indy's Connection Protocol--unless they want to interoperate with code that's frozen to February's Agent Connectathon. It would be easy to write one impl that supports both protocols, given how virtually identical they are--but whether an impl does that or not is up to its authors.

swcurran (Fri, 26 Jul 2019 17:31:33 GMT):
I differ from Daniel's view a little in the details. A number of implementers implemented Connections 0.1 that is documented here - https://hackmd.io/s/HkklVzww4 It was defined for IIW and has had a much longer lifespan than expected. Note that it is significantly different that DID-Exchange in that it does not support preview or the proposal messages. We recommend: - adding "connections" as an RFC with an "Accepted" status and a notice pointing to the DID-Exchange protocol for new implementation and the context described here. - When DID Exchange becomes "Accepted", the connections RFC is marked as "deprecated" (or whatever term we have). - Come up with a way to track implementations so that we know the impact of supporting one, the other or both (which is issue 137) I deliberate chose to mark connections as "Accepted" for now, because it is the de facto accepted protocol, and that pushes the group to agree on DID-Exchange. I also suggest that we don't lightly change protocol names vs. versions. I don't think DID-Exchange is significantly better than connections to be worth all this confusion. From an implementation perspective, we did two implementations in parallel as intertwining the two was found to be difficult. Your results may vary.

talwinder50 (Wed, 31 Jul 2019 00:10:32 GMT):
Has joined the channel.

talwinder50 (Wed, 31 Jul 2019 00:10:33 GMT):
hello there

talwinder50 (Wed, 31 Jul 2019 00:10:51 GMT):
Can someone

talwinder50 (Wed, 31 Jul 2019 00:11:04 GMT):
add me to the committers group

danielhardman (Wed, 31 Jul 2019 16:25:49 GMT):
I defer to Stephen about the substantive differences; I guess they're somewhat more meaningful than I realized. Thank you for the correction. The remaining difference between my view and Stephen's seems to be in how much we think a hackmd doc needs to be accommodated by an RFC management process. I do agree with Stephen's recommendations for content *inside Aries*; I just don't think we should be reasoning about content that's not embodied in either HIPEs or RFCs, and applying the same standard. For example, the pushback about changing protocol names and versions assumes that there should be some sort of continuity between the hackmd doc and an Aries RFC; I don't think that's crazy, but I also don't think it's a foregone conclusion. Anyway, if we never write and implement protocols in hackmd again, this is probably a moot point. I'll happily vote to merge Stephen's PR when it's raised. But can we also agree that, although writing a protocol doc in hackmd is fine, the Aries community doesn't have any obligation to protect it with formal change control management until it shows up as an RFC?

danielhardman (Wed, 31 Jul 2019 20:45:43 GMT):
@swcurran Thanks for pushing us on RFC management a bit. Some things where I'm not clear on who's doing what: 1. Raise a PR that changes the description of our process, introduces FIRST_IMPL as a status, makes our 4-arrow circle into a 5-arrow circle, and changes our index script so it generates a differently sorted and better described list. Have it look up in-between statuses or last-status-update dates to provide better metadata. (Let me know if you're doing this instead.) We can then approve the updated process via the PR. 2. Propose a better status block and a new implementations block for all RFCs, and write a script that adds those blocks to all existing docs. 3. Raise PRs that move a handful of RFCs to ACCEPTED status.

danielhardman (Wed, 31 Jul 2019 20:45:43 GMT):
@swcurran Thanks for pushing us on RFC management a bit. Some things where I'm not clear on who's doing what: 1. Raise a PR that changes the description of our process, introduces FIRST_IMPL as a status, makes our 4-arrow circle into a 5-arrow circle, and changes our index script so it generates a differently sorted and better described list. Have it look up in-between statuses or last-status-update dates to provide better metadata. We can then approve the updated process via the PR. 2. Propose a better status block and a new implementations block for all RFCs, and write a script that adds those blocks to all existing docs. 3. Raise PRs that move a handful of RFCs to ACCEPTED status.

danielhardman (Wed, 31 Jul 2019 20:46:10 GMT):
Which ones of these do you want to do? I'll volunteer to help with others. In particular, I can redo the graphic and the script, since I've worked on both.

danielhardman (Wed, 31 Jul 2019 20:46:10 GMT):
Which ones of these do you want to do? I'll volunteer to help with others. In particular, I can redo the graphic and the indexing script, since I've worked on both.

swcurran (Thu, 01 Aug 2019 18:05:38 GMT):
I would definitely appreciate the help with the graphic and the script. I will do the raising of the PR for the process, and can write/run a script for adding the blocks to the existing docs. I will raise an issue and will write the "update all existing docs" script after we agree on the format.

swcurran (Thu, 01 Aug 2019 18:07:15 GMT):
I'll include in the PR any clarification needed on the author/facilitators role in doing changing the status - including Kyle's proposal on formating the PR.

danielhardman (Thu, 01 Aug 2019 19:49:47 GMT):
Perfect! I'll start working on the new graphic and the updated indexer.

guolidong (Fri, 02 Aug 2019 07:58:39 GMT):
Has joined the channel.

danielhardman (Mon, 05 Aug 2019 16:45:32 GMT):

possible lifecycle

danielhardman (Mon, 05 Aug 2019 16:47:01 GMT):
@swcurran, @kdenhartog, @telegramsam What do you think of this graphic? Note that I named the stage between PROPOSED and ACCEPTED "POC" instead of "IMPLEMENTED". I could also go for "FIRST IMPL" if you like that better. And I changed the final phase to RETIRED instead of SUPERSEDED, because that seems to me to cover both the case where someone withdraws an RFC, and the case where the RFC remains around but is superseded or deprecated for some reason.

danielhardman (Mon, 05 Aug 2019 16:47:01 GMT):
@swcurran, @kdenhartog, @TelegramSam What do you think of this graphic? Note that I named the stage between PROPOSED and ACCEPTED "POC" instead of "IMPLEMENTED". I could also go for "FIRST IMPL" if you like that better. And I changed the final phase to RETIRED instead of SUPERSEDED, because that seems to me to cover both the case where someone withdraws an RFC, and the case where the RFC remains around but is superseded or deprecated for some reason.

danielhardman (Mon, 05 Aug 2019 17:02:02 GMT):
@swcurran and @TelegramSam In the updated indexer, I'm thinking I'd like to be able to report the following metadata about each RFC: when its status last changed (so we can tell if proposals are stale), how many impls it has, and what tags are associated with it. This means I need a section for impls that lists them in a way that they are easily countable. I'm thinking something like: ``` # Implementations - [my impl](https://example.com/myimpl) (whatever note you'd like) ``` How does that sound?

swcurran (Mon, 05 Aug 2019 17:32:55 GMT):
I like the graphic and the name adjustments. Nice!

TelegramSam (Mon, 05 Aug 2019 17:58:40 GMT):
How about DEMONSTRATED instead of POC?

TelegramSam (Mon, 05 Aug 2019 17:58:50 GMT):
Just to fit in the naming theme a little better.

TelegramSam (Mon, 05 Aug 2019 17:59:54 GMT):
I've accepted Nikita's PR to the RFC 0036 - Issue Credential Protocol. I don't think his corrections fully address the concerns we had, but he also included the files and instructions on how to update them. https://github.com/hyperledger/aries-rfcs/blob/master/features/0036-issue-credential/README.md

TelegramSam (Mon, 05 Aug 2019 18:40:26 GMT):
quick tweak PR for BasicMessage: https://github.com/hyperledger/aries-rfcs/pull/148

TelegramSam (Mon, 05 Aug 2019 18:40:35 GMT):
AFter that, I"ll be proposing a status change.

swcurran (Mon, 05 Aug 2019 19:28:33 GMT):
OK - 2 points to Sam for "Demonstrated". I'm going to go with that in updating the README.md for the repo. @danielhardman - if you want to send me the image you can, or you can add it later.

danielhardman (Mon, 05 Aug 2019 19:29:08 GMT):
Okay, I'll update POC to DEMONSTRATED in the graphic and so forth.

swcurran (Mon, 05 Aug 2019 19:29:20 GMT):
FYI - I've just updated all RFCs with an "Implementations" section. PR pending.

swcurran (Mon, 05 Aug 2019 19:29:20 GMT):
FYI - I've just updated all RFCs with an "Implementations" section. PR submitted

swcurran (Mon, 05 Aug 2019 19:29:20 GMT):
FYI - I've just updated all RFCs with an "Implementations" section. PR submitted.

danielhardman (Mon, 05 Aug 2019 19:30:46 GMT):
@TelegramSam Your PR for BM is merged.

danielhardman (Mon, 05 Aug 2019 19:31:03 GMT):
@swcurran Your PR is merged as well.

danielhardman (Tue, 06 Aug 2019 07:45:06 GMT):
@all I did some work to improve the indexing script. It's substantially cleaner and more useful. It counts and reports/hyperlinks implementations for each indexed item in the new impl section that @swcurran added. It also shows the last status date of each RFC, so we can see what's stalled. And it supports tagging. I have defined and used 4 tags so far; you'll see them when you go look at the latest version of /index.md. I went in and added links to implementations for a number of RFCs. They are definitely incomplete/imperfect, but even so, it is very encouraging to see how much real progress we've made that we just weren't giving ourselves credit for. This change caused a number of RFCs to move from PROPOSED to DEMONSTRATED status. I went ahead and merged those changes, because this status change is not controversial; it's just a reflection of us having data about impl code. Many of the things that are now in DEMONSTRATED status should probably be in ACCEPTED status instead, but that's a more controversial move and one that I think others might want to advocate. Please note: I also added a new unit test that is picky about the metadata at the top of each RFC. Your PRs won't pass unless you follow the format. To find out if you're following the format, run `pytest code` from the root of the repo.

kdenhartog (Tue, 06 Aug 2019 09:51:21 GMT):
Wow you've all been busy while I'm on a hiatus trying to get adjusted here. I'm glad to see the new changes and am in support of all of them. Thanks!

dbluhm (Tue, 06 Aug 2019 14:33:33 GMT):
@danielhardman I submitted a PR to aries-rfcs that contains updates for references to Indy Agent updates some of the commentary about Indy Agent in the Agent Explainer: https://github.com/hyperledger/aries-rfcs/pull/161 This is part of an effort to point people in the right direction as the enter the community

dbluhm (Tue, 06 Aug 2019 14:33:33 GMT):
@danielhardman I submitted a PR to aries-rfcs that contains updates for references to Indy Agent and updates some of the commentary about Indy Agent in the Agent Explainer: https://github.com/hyperledger/aries-rfcs/pull/161 This is part of an effort to point people in the right direction as the enter the community

danielhardman (Tue, 06 Aug 2019 14:41:39 GMT):
@dbluhm the PR is great. I will merge it as soon as I'm on a real computer instead of my mobile phone, unless someone beats me to it. Thank you so much for improving the metadata.

danielhardman (Tue, 06 Aug 2019 15:40:23 GMT):
@dbluhm merged

danielhardman (Tue, 06 Aug 2019 15:49:01 GMT):
@swcurran Now that I have a little experience using the `Implementations` section, I want to suggest a couple tweaks: 1. The `Name` column and the `Link` column feel wasteful of screen real estate. If we combined them so `Name` is a phrase that's just hyperlinked, the reading would be streamlined. 2. I think I used the `Implementation Notes` field incorrectly about half the time. I put a description of a codebase there, when what I really ought to do is put a description of the specific implemented feature (e.g., not "Codebase X has the following characteristics" but "The impl of this RFC in codebase X has the following characteristics"). Do you agree? If so, I'll try to circle back and update. 3. I'm not sure that I chose the best name for each impl. Can owners of each impl please comment? @troyronda @TelegramSam

danielhardman (Tue, 06 Aug 2019 15:50:58 GMT):
Also, I am not sure what to do with this section for things that are conceptual. For example, it doesn't seem to make sense on the RFC about repudiation, or JSON-LD compatibility. Should the section be removed as not applicable, or just left empty?

swcurran (Tue, 06 Aug 2019 15:55:41 GMT):
Agree on 1 and agree on 2 - good call. I think we leave the section in for conceptual ones, but less important beyond reference implementations. Nice to have a link to a reference implementation where possible. We can remove later if it's not useful.

danielhardman (Tue, 06 Aug 2019 15:55:59 GMT):
okay

TelegramSam (Tue, 06 Aug 2019 21:01:56 GMT):
PR ready with existing connection protocol: https://github.com/hyperledger/aries-rfcs/pull/160

TelegramSam (Tue, 06 Aug 2019 21:08:18 GMT):
alongside another PR to demote DID Exchange from Accepted to Proposed: https://github.com/hyperledger/aries-rfcs/pull/164

danielhardman (Wed, 07 Aug 2019 00:12:16 GMT):
Both have been merged.

TelegramSam (Wed, 07 Aug 2019 14:18:14 GMT):
does a move to Demonstrated need a waiting period? or just to accepted?

swcurran (Wed, 07 Aug 2019 14:31:28 GMT):
I think it can be merged. It's the moves to Accepted and Adopted that should get commnunity comments.

TelegramSam (Wed, 07 Aug 2019 14:46:33 GMT):
RFC to move return route to demonstrated, with impl links: https://github.com/hyperledger/aries-rfcs/pull/166

troyronda (Wed, 07 Aug 2019 20:04:06 GMT):
@danielhardman @swcurran For aries-framework-go, "Aries Framework - Go" / "Aries Framework Go" would make sense. (suffixing the implementation language in the name, similar to aries-cloudagent-python.)

danielhardman (Wed, 07 Aug 2019 20:05:12 GMT):
Okay. Do you want to raise a PR that does a search and replace? I can merge it immediately. (I could raise the PR myself; it's easy enough. But I want more contributors to have gravitas in the repo history, not just me.)

troyronda (Wed, 07 Aug 2019 20:05:22 GMT):
Will do :).

troyronda (Wed, 07 Aug 2019 20:07:58 GMT):
We have been wondering about the best place to hold chat conversations for discussing aries-framework-go topics. e.g., coordination, implementation, questions. Have you typically created new channels for this, or used an existing channel (I was a bit worried about polluting an existing channel).

troyronda (Wed, 07 Aug 2019 20:07:58 GMT):
We have been wondering about the best place to hold chat conversations for discussing aries-framework-go topics. e.g., coordination, implementation, questions. Have you typically created new channels for this, or used an existing channel? (I was a bit worried about polluting an existing channel.)

dbluhm (Wed, 07 Aug 2019 20:10:22 GMT):
I wouldn't mind seeing some of that coordination in #aries ; maybe it's appropriate to use #aries as much as is needed until it becomes a problem?

esplinr (Thu, 08 Aug 2019 20:41:44 GMT):
@callahan thanks to the help of @rjones , there is no longer a requirement for PR reviews on aries-sdk-ruby. Once you have recruited some other contributors, we should re-add the review requirement.

troyronda (Fri, 09 Aug 2019 11:48:07 GMT):
https://github.com/hyperledger/aries-rfcs/pull/170

swcurran (Fri, 09 Aug 2019 20:47:22 GMT):
@rjones - we'd like to have an artifact of the `aries-cloudagent-python` repo be a docker image with aca-py pre-installed, so that it can be the base image for other projects. We're starting with a BCGov repo to build that, but would eventually like that to be a Hyperledger container image (https://hub.docker.com/u/hyperledger). Is there a process/guidance for doing that?

rjones (Fri, 09 Aug 2019 20:48:27 GMT):
@swcurran I can create the repo, and either have it build from github auto-magically or give you admin access to set it up as you like

swcurran (Fri, 09 Aug 2019 20:49:50 GMT):
Cool - should we get it working first in BCGov and then either move it over or recreate it? The history will be WAY less important vs. aries-cloudagent-python.

rjones (Fri, 09 Aug 2019 20:50:52 GMT):
Give me a dockerhub username and a repo name. I'll make them admin and let them set it up as they like. Please send email to community-architects@hyperledger.org with the request so everyone is aware

swcurran (Fri, 09 Aug 2019 20:54:01 GMT):
OK - will do.

swcurran (Fri, 09 Aug 2019 20:54:49 GMT):
@WadeBarnes @esune - ^^^ - let's talk and work through this.

WadeBarnes (Fri, 09 Aug 2019 20:54:49 GMT):
Has joined the channel.

esune (Fri, 09 Aug 2019 20:54:49 GMT):
Has joined the channel.

WadeBarnes (Fri, 09 Aug 2019 21:06:07 GMT):
@rjones, Docker Hub Ids: `wwjbarnes` and `esune` Repo Name: `aries-cloudagent-container`, we started one here, `https://cloud.docker.com/u/bcgovimages/repository/docker/bcgovimages/aries-cloudagent-container`, but we'll redirect to the official one when it's ready.

rjones (Fri, 09 Aug 2019 21:08:50 GMT):
@WadeBarnes invites sent. You're both admins of the repo; let me know when it's set up to your satisfaction so I can drop your admin access

WadeBarnes (Fri, 09 Aug 2019 21:12:10 GMT):
@rjones, Thank-you Sir. Will do.

esune (Mon, 12 Aug 2019 23:08:12 GMT):
@rjones me and @WadeBarnes were thinking that `aries-cloudagent-container` is a bit redundant for Docker Hub and we should instead name the repo `aries-cloudagent`. Could you delete the old repo and create a new one with the "new" name?

esune (Mon, 12 Aug 2019 23:08:12 GMT):
@rjones @WadeBarnes and I were thinking that `aries-cloudagent-container` is a bit redundant for Docker Hub and we should instead name the repo `aries-cloudagent`. Could you delete the old repo and create a new one with the "new" name?

esune (Mon, 12 Aug 2019 23:08:12 GMT):
@rjones : @WadeBarnes and I were thinking that `aries-cloudagent-container` is a bit redundant for Docker Hub and we should instead name the repo `aries-cloudagent`. Could you delete the old repo and create a new one with the "new" name?

rjones (Mon, 12 Aug 2019 23:08:30 GMT):
If it's good with @WadeBarnes will do

WadeBarnes (Mon, 12 Aug 2019 23:09:10 GMT):
Good with me.

rjones (Mon, 12 Aug 2019 23:09:33 GMT):
https://cloud.docker.com/u/hyperledger/repository/docker/hyperledger/aries-cloudagent

esune (Mon, 12 Aug 2019 23:09:42 GMT):
Thanks!

WadeBarnes (Mon, 12 Aug 2019 23:15:38 GMT):
Thanks @rjones

tomislav (Tue, 13 Aug 2019 02:00:06 GMT):
I missed the meeting again today, I wanted to ask about moving `streetcred-id/agent-framework` to an aries- repo. I'm not sure if `aries-sdk-dotnet` would be the appropriate destination, or a new repo `aries-agentframework-dotnet`. The current codebase has no namespacing or branding related to streetcred.id, so refactoring should be minimal.

tomislav (Tue, 13 Aug 2019 02:01:08 GMT):
We talked about this previously, but I never got around to push this, and we've been sitting at a stable version for a while now, seems like the right time to do it.

swcurran (Tue, 13 Aug 2019 17:33:26 GMT):
I think the name `aries-framework-dotnet` is the right name. Same pattern that `go` framework team is using.

esplinr (Wed, 14 Aug 2019 20:05:58 GMT):
I'm excited to see it move forward @tomislav . Thank you for the contribution!

kdenhartog (Thu, 15 Aug 2019 22:56:26 GMT):
@danielhardman @TelegramSam or @swcurran (I think you can do this as well) If you feel that the RFC #0036 is no longer blocked would you mind removing the label? I'm not sure if I marked the PR as blocked, which I wanted to do so we could manage the deadline properly.

kdenhartog (Thu, 15 Aug 2019 22:56:26 GMT):
@danielhardman @TelegramSam or @swcurran (I think you can do this as well) If you feel that the RFC #0036/#0037 is no longer blocked would you mind removing the label? I'm not sure if I marked the PR as blocked, which I wanted to do so we could manage the deadline properly.

swcurran (Thu, 15 Aug 2019 23:20:09 GMT):
Release 0.3.1 of `aries-cloudagent-python` is now available in github and pypi. This is largely a cleanup release (TAA tweaks - thanks to the community) but with a couple of new features. https://github.com/hyperledger/aries-cloudagent-python/releases/tag/0.3.1 https://pypi.org/project/aries-cloudagent/0.3.1/

swcurran (Thu, 15 Aug 2019 23:20:09 GMT):
Release 0.3.1 of `aries-cloudagent-python` is now available in github and pypi. This is (mostly) a cleanup release (TAA tweaks - thanks to the community) but with a couple of new features. https://github.com/hyperledger/aries-cloudagent-python/releases/tag/0.3.1 https://pypi.org/project/aries-cloudagent/0.3.1/

danielhardman (Fri, 16 Aug 2019 02:01:23 GMT):
@tomislav When you get this into an Aries repo, please submit a PR that updates all the Implementation sections at the bottom of RFCs, so they point to your new project instead of the old home. Also please update github.com/aries/README.md to reference it. Super exciting!

swcurran (Fri, 16 Aug 2019 20:19:41 GMT):
Just got off a call with someone with whom I was talking about Aries. Found out that because of their indoctrination with the historical terms "Edge/Cloud" agent, they didn't understand that `aries-cloudagent-python` could be an edge agent. I don't know what we can do about that other than to rename ACA-Py to `aries-notmobileagent-python` :-) Too bad that those terms have become so well used. Any thoughts on if we should change anything or just explain it to people that get confused by the terms? We should reconsider and just go with `aries-agent-python`. Anyone with the least bit of knowledge about Python would equate that to `aries-notmobileagent-python`

jljordan_bcgov (Sat, 17 Aug 2019 03:20:08 GMT):
+1 to removing the deployment context from the naming convention

esplinr (Sat, 17 Aug 2019 04:37:29 GMT):
AAPy is so much harder to vocalize than ACAPy. It needs a consonant. ANMAPy works alright. grin

kdenhartog (Sun, 18 Aug 2019 22:14:20 GMT):
@swcurran I'm all for changing those names and left the issue on the subject open. https://github.com/hyperledger/aries-rfcs/issues/122 Even if we don't go with the term "Custodial" (I still think it provides a good distinction) we need better language to describe the diversity of agents in the ecosystem.

TelegramSam (Mon, 19 Aug 2019 20:46:03 GMT):
I think any name we choose will have some naming issue... I wonder how far we can get by including naming information near the top of the various repo README files. Will that help enough?

swcurran (Mon, 19 Aug 2019 20:52:21 GMT):
It might and should be done. But since any name is bad, we'd like to change to ACA-Py to `aries-agent-python`. Any objections?

TelegramSam (Mon, 19 Aug 2019 21:09:38 GMT):
I don't think it's a good idea.

swcurran (Mon, 19 Aug 2019 21:49:33 GMT):
Any reason?

jljordan_bcgov (Mon, 19 Aug 2019 22:32:40 GMT):
When there is an option to be succinct it’s usually a good option.

jljordan_bcgov (Mon, 19 Aug 2019 22:33:56 GMT):
Taxonomies work when there are cultural norms ... something we can’t easily achieve with a global scope

jljordan_bcgov (Mon, 19 Aug 2019 22:34:15 GMT):
So simple names ... describe in readme

TelegramSam (Mon, 19 Aug 2019 22:41:12 GMT):
Simple names can also lead to confusion.

TelegramSam (Mon, 19 Aug 2019 22:42:19 GMT):
I think we are young in the process to be changing a name. I don't directly object to the new proposed name, but I worry that we will learn so much in the next 6 months that it might lead us to choose a better name.

TelegramSam (Mon, 19 Aug 2019 22:44:18 GMT):
I'm not saying the current repo name is awesome.

TelegramSam (Mon, 19 Aug 2019 22:45:42 GMT):
I'm worried that given a lack of good names for the landscape of agents in our current ecosystem, we are unlikely to choose one without significant problems of it's own.

TelegramSam (Mon, 19 Aug 2019 22:46:20 GMT):
My preference is to update readmes now, and work to mature the naming of things within the ecosystem. as it settles, perform the repo rename then.

kdenhartog (Mon, 19 Aug 2019 22:55:30 GMT):
I tend to agree that it could lead to confusion. The naming is going to set the mental model, and I'm concerned in not distinguishing between a cloud agent and an edge agent. From a personal user perspective (not a business) it's a generally accepted paradigm that they should preference an edge agent with a cloud agent approach over a cloud agent with a rest controller app. This is because by doing the latter has a strong incentive to not be run on user owned hardware which in turn undermines the users control.

swcurran (Mon, 19 Aug 2019 23:03:12 GMT):
My read of what you are saying is @kdenhartog is exactly why it shouldn't be called "cloudagent". Given the original (circa-2016/17) "cloud" and "edge" agent terms from Sovrin, ACA-Py is either one. In that terminology an edge agent != mobile agent which is what you seem to be implying. The only limitation on ACA-Py's use is that it won't run on as a mobile agent and so would generally not be used by a personal user. It can be an enterprise edge agent, an enterprise cloud agent, an agency endpoint, and a personal cloud agent. It could be a personal edge agent, if a person doesn't want to run their edge agent on a mobile device.

swcurran (Mon, 19 Aug 2019 23:03:12 GMT):
My read of what you are saying is @kdenhartog is exactly why it (ACA-Py) shouldn't be called "cloudagent". Given the original (circa-2016/17) "cloud" and "edge" agent terms from Sovrin, ACA-Py is either one. In that terminology an edge agent != mobile agent which is what you seem to be implying. The only limitation on ACA-Py's use is that it won't run on as a mobile agent and so would generally not be used by a personal user. It can be an enterprise edge agent, an enterprise cloud agent, an agency endpoint, and a personal cloud agent. It could be a personal edge agent, if a person doesn't want to run their edge agent on a mobile device.

swcurran (Mon, 19 Aug 2019 23:04:02 GMT):
We concern right now is those (IMHO) old terms is that are in common use in the community.

swcurran (Mon, 19 Aug 2019 23:04:02 GMT):
My concern right now is those (IMHO) old terms is that are in common use in the community.

swcurran (Mon, 19 Aug 2019 23:04:02 GMT):
My concern right now is those (IMHO) old terms is that are in common use in the community today.

kdenhartog (Mon, 19 Aug 2019 23:08:14 GMT):
It can also become an impersonator agent, which is the paradigm I want to avoid occurring. If we find a way to explicitly prevent developers from selecting that solution than I'm open to anything. So far, I don't feel that we've found a mental model that highlights all the solutions you provided while also excluding the impersonator paradigm.

swcurran (Mon, 19 Aug 2019 23:37:24 GMT):
?? What's an impersonator agent? It don't see how that relates to the discussion.

jljordan_bcgov (Mon, 19 Aug 2019 23:45:01 GMT):
It’s an agent. We all agree on that.

jljordan_bcgov (Mon, 19 Aug 2019 23:45:35 GMT):
Now it’s deployed will be up to the adoptor ... the the case of the python agent ... it won’t be on a phone afaik.

jljordan_bcgov (Mon, 19 Aug 2019 23:45:35 GMT):
How it’s deployed will be up to the adoptor ... the the case of the python agent ... it won’t be on a phone afaik.

jljordan_bcgov (Mon, 19 Aug 2019 23:47:43 GMT):
It will be (we hope) in all kinds of surprising and useful (hopefully) ways we can’t predict.

jljordan_bcgov (Mon, 19 Aug 2019 23:47:43 GMT):
It will be deployed (we hope) in all kinds of surprising and useful (hopefully) ways we can’t predict.

kdenhartog (Tue, 20 Aug 2019 00:03:41 GMT):
an impersonator agent is a paradigm where the agent host has the capability (whether used or not) to impersonate the user. For example, if Google decides to host personal agents for their users and only offers a cloud agent with a REST controller app. Then Google has the capability to impersonate the user (e.g. sending credentials without user consent) or to perform analytics and data tracking on the users habits (similar to what Google already does).

kdenhartog (Tue, 20 Aug 2019 00:03:41 GMT):
an impersonator agent is a paradigm where the agent host has the capability (whether used or not) to impersonate the user. For example, if Google decides to host personal agents for their users and only offers a cloud agent with a REST controller app then Google has the capability to impersonate the user (e.g. sending credentials without user consent) or to perform analytics and data tracking on the users habits (similar to what Google already does).

kdenhartog (Tue, 20 Aug 2019 00:04:03 GMT):
I don't want to encourage that because it violates many of the principles of SSI.

danielhardman (Tue, 20 Aug 2019 01:29:40 GMT):
Although the cloud agent term is too narrow, the plain agent term is too broad. How about server agent?

jljordan_bcgov (Tue, 20 Aug 2019 02:03:18 GMT):
And the name of a repo will prevent that?

kdenhartog (Tue, 20 Aug 2019 02:04:01 GMT):
Implicitly I believe it will if it sets the wrong expectations for the consumer of the repo.

jljordan_bcgov (Tue, 20 Aug 2019 02:06:07 GMT):
We can argue until we are blue i the face to no resolution. I can be confident that stuff we build Will be used in harmful ways.

jljordan_bcgov (Tue, 20 Aug 2019 02:06:58 GMT):
We have roads and cars.

kdenhartog (Tue, 20 Aug 2019 02:09:30 GMT):
Making sure we're telling a good story and setting a right vision is important though. That's what naming is about. If we pick bad names we set ourselves up for encouraging the poor usage. For example SSI albeit controversial it's an excellent name for setting the mental model that differentiates the paradigm from other identity models like federated and centralized identity.

kdenhartog (Tue, 20 Aug 2019 02:09:30 GMT):
Making sure we're telling a good story and setting a right vision is important though. That's what naming is about. If we pick bad names we set ourselves up for encouraging the poor usage. For example Self sovereign identity albeit controversial it's an excellent name for setting the mental model that differentiates the paradigm from other identity models like federated and centralized identity.

kdenhartog (Tue, 20 Aug 2019 02:11:43 GMT):
In the beginning we didn't call centralized identity that. We just called it Identity and Access Management. Then when we learned and differentiate the difference between Federated and Centralized, we brought in new language. What I hear is being suggested is we want to go from a model that sets a paradigm (cloud and edge) and move back to one without paradigms. I think that's a move in the wrong direction.

kdenhartog (Tue, 20 Aug 2019 02:17:01 GMT):
My argument is that we should be picking names that preserve the story that was originally told when we set out on build self sovereign identity. If people want to build impersonator agents than UMA may be a better paradigm for them to look at because it's been designed with those paradigms in mind.

jljordan_bcgov (Tue, 20 Aug 2019 02:20:51 GMT):
In the end implementation and regulation if needed will set the conditions for what arises.

jljordan_bcgov (Tue, 20 Aug 2019 02:21:56 GMT):
Of course we do our best to design and describe this stuff to meet the objectives of protecting citizens etc

kdenhartog (Tue, 20 Aug 2019 02:33:25 GMT):
Certainly, and the story we tell makes a difference in how regulators (who may not understand what they're regulating to the fullest extent) and developers will use the technology. That's why I'm a stickler for preserving the story to it's original intent. I don't want another OIDC situation where OIDC is designed well in theory and then the largest implementation get's used to abuse user rights (Facebook).

jljordan_bcgov (Tue, 20 Aug 2019 02:35:39 GMT):
Well. I guess that is why I do what I do. Because I have those discussions with the regulators.

kdenhartog (Tue, 20 Aug 2019 02:36:35 GMT):
And I appreciate and trust you'll set their expectations properly. I'm not sure that a drive by developer consuming the package will understand this because it's very much tribal knowledge at this point.

kdenhartog (Tue, 20 Aug 2019 02:37:44 GMT):
I've started writing a RFC for concepts so that this would be less of a concern. Then calling it something like a server agent feels like it could be a potential middle ground. Would that feel like a better name than cloud agent for you?

kdenhartog (Tue, 20 Aug 2019 02:37:44 GMT):
I've started writing a RFC to explain this concept so that we can explicitly call it out as an anti pattern. Then calling it something like a server agent feels like it could be a potential middle ground. Would that feel like a better name than cloud agent for you?

jljordan_bcgov (Tue, 20 Aug 2019 02:38:48 GMT):
Lots more to do to tell the story well ... and it will be at a level well above repos and RFC for the decision makers that drive adoption.

kdenhartog (Tue, 20 Aug 2019 02:39:36 GMT):
Yup definitely. Many people including yourself have done a good job telling the story. Let's keep it consistent in the repos as well.

danielhardman (Tue, 20 Aug 2019 14:10:57 GMT):
The terminology of "cloud" vs. "edge" has a long and troubled history. Originally we believed that "cloud" and "edge" were good opposites and that they represented distinctions of trust. We've since realized that there could be untrusted edge agents (rare, but possible), or fully trusted cloud agents (also rare, but possible). So "edge" and "cloud" have more to do with location and less to do with trust. RFC 0004: Agents now has a section that discusses these terms; see https://github.com/hyperledger/aries-rfcs/tree/master/concepts/0004-agents#categorizing-agents. If you read that section of the RFC, I think you inevitably come to the conclusion that @swcurran and @jljordan_bcgov are correct to want the term "cloud" removed from their codebase name; there is nothing about the codebase that has strong alignment with cloud-based hosting. The RFC suggests using the platform of an agent as a form of categorization. If you do that, then "mobile" and "server" are pretty good opposites, and a "server agent" does convey pretty well what the acapy codebase's focus is. It could be used as an edge agent or a cloud agent--but either way, it's definitely running a web server, and it's likely running on a machine that acts as a server. (Although it could be run on desktop hardware, its utility as an agent depends on it listening on a port for incoming communication, which makes it more truly server-like.) So that's why I suggested changing the name to "Aries Server Agent - Python".

danielhardman (Tue, 20 Aug 2019 14:33:09 GMT):
new PR that needs merging (Coin Flip Protocol): https://github.com/hyperledger/aries-rfcs/pull/193

danielhardman (Tue, 20 Aug 2019 14:33:22 GMT):
Could a maintainer please review and merge?

jljordan_bcgov (Tue, 20 Aug 2019 15:01:53 GMT):

jljordan_bcgov (Tue, 20 Aug 2019 15:02:02 GMT):
Thanks Mr @danielhardman ... It think it is better in that it is less subject to interpretation as you describe... we have already had someone get ACA-Py (maybe AServ-Py :) ) running on a Raspberry Pi

jljordan_bcgov (Tue, 20 Aug 2019 15:03:53 GMT):
Which seems server like for sure One of the other interesting dimension is the agent primarily human controlled .. ie a person is interacting usually in real time to respond to connection creations, credential exchanges (they could pre-authorize) or is the agent controlled by software that is responded according to programmed business rules

TelegramSam (Tue, 20 Aug 2019 15:46:35 GMT):
Also Fellow Maintainers: We have two RFC status changes to act on today.

TelegramSam (Tue, 20 Aug 2019 15:47:37 GMT):
95 BasicMessage has no objections.

danielhardman (Tue, 20 Aug 2019 17:54:23 GMT):
I will merge it.

danielhardman (Tue, 20 Aug 2019 17:55:33 GMT):
@TelegramSam Can you resolve the merge conflict in index.md?

danielhardman (Tue, 20 Aug 2019 19:13:38 GMT):
Never mind. Merged.

jonathanreynolds (Tue, 20 Aug 2019 20:52:04 GMT):
Has joined the channel.

kdenhartog (Wed, 21 Aug 2019 00:36:56 GMT):
PRd details about how to DCO commit https://github.com/hyperledger/aries-rfcs/pull/195 Can a maintainer review it and merge?

jadhavajay (Wed, 21 Aug 2019 15:42:19 GMT):
PR to move Indy NodeJS wrapper code https://github.com/hyperledger/aries-sdk-javascript/pull/1

tomislav (Thu, 22 Aug 2019 15:05:49 GMT):
PR up to move agent-framework to aries-framerowk-dotnet - https://github.com/hyperledger/aries-framework-dotnet/pull/2

kengeo (Fri, 23 Aug 2019 03:56:12 GMT):
Has joined the channel.

danielhardman (Fri, 23 Aug 2019 20:56:10 GMT):
@tomislav Can I get you to submit an Aries RFCs PR that updates the references to the Streetcred framework in the impl section at the bottom of many Aries RFCs to be a reference to your new framework repo?

danielhardman (Fri, 23 Aug 2019 20:57:12 GMT):
@kdenhartog or @swcurran or @TelegramSam : Could one of you approve and merge this minor PR? https://github.com/hyperledger/aries-rfcs/pull/200

danielhardman (Fri, 23 Aug 2019 20:58:08 GMT):
@swcurran and @jljordan_bcgov : Did we get to closure on renaming acapy?

danielhardman (Fri, 23 Aug 2019 20:58:35 GMT):
I ask because I'm revising the root README in the aries (not aries-rfcs) repo, and I want to use the canonical, new name.

swcurran (Fri, 23 Aug 2019 21:07:47 GMT):
We're not going to bother now. IMHO the proposed options are at best slightly better. We'll wait on the next round of naming that Sam suggested was coming :-).

swcurran (Fri, 23 Aug 2019 21:18:38 GMT):
Done. And I've added a question to the PR. Why does this RFC exist, or at least exist as a core protocol?

tomislav (Fri, 23 Aug 2019 21:53:57 GMT):
Yes. I'm on it.

kdenhartog (Sat, 24 Aug 2019 01:14:52 GMT):
[ ](https://chat.hyperledger.org/channel/aries-maintainers?msg=GF9xRqwT6Pnj54XWT) @swcurran I'm all for making this happen sooner rather than later. I sympathize with the problem that cloud/edge paradigm needs replaced. I came in a too hot regarding changing the name and wasn't trying to prevent us from moving away from that paradigm. I'll keep thinking about it. From your perspective should the paradigm choose words that are more common to tech minded people or business minded people or both? I wonder if we're trying to address different audiences here which is leading to us not finding a resolution.

kdenhartog (Sat, 24 Aug 2019 01:14:52 GMT):
@swcurran I'm all for making this happen sooner rather than later. I sympathize with the problem that cloud/edge paradigm needs replaced. I came in too hot regarding changing the name and wasn't trying to prevent us from moving away from that paradigm. I'll keep thinking about it. From your perspective should the paradigm choose words that are more common to tech minded people or business minded people or both? I wonder if we're trying to address different audiences here which is leading to us not finding a resolution.

kdenhartog (Sat, 24 Aug 2019 01:14:52 GMT):
@swcurran I'm all for making this happen sooner rather than later. I sympathize with the problem that cloud/edge paradigm needs replaced. I came in too hot regarding changing the name and wasn't trying to prevent us from moving away from that paradigm. Sorry for that. I'll keep thinking about it. From your perspective should the paradigm choose words that are more common to tech minded people or business minded people or both? I wonder if we're trying to address different audiences here which is leading to us not finding a resolution.

kdenhartog (Sat, 24 Aug 2019 01:14:52 GMT):
@swcurran I'm all for making this happen sooner rather than later. I sympathize with the problem that cloud/edge paradigm needs replaced. I came in too hot regarding changing the name and wasn't trying to prevent us from moving away from that paradigm. Sorry for that @jljordan_bcgov . I'll keep thinking about it. From your perspective should the paradigm choose words that are more common to tech minded people or business minded people or both? I wonder if we're trying to address different audiences here which is leading to us not finding a resolution.

tomislav (Sat, 24 Aug 2019 13:34:16 GMT):
https://github.com/hyperledger/aries-rfcs/pull/203

rjones (Fri, 30 Aug 2019 15:39:09 GMT):
Hi - I could use some help finding missing voters from Evernym: https://github.com/ryjones/tsc-missing/blob/master/missing.csv

danielhardman (Fri, 30 Aug 2019 19:56:32 GMT):
Ry: All of the people on that list who show as affiliated with Evernym are working in different places right now. I'm not sure of their involvement with Hyperledger, with one exception. Matt Raffel is now working for Kiva but attends the Hyperledger community calls and is actively maintaining Indy SDK. I believe his rocketchat handle is `@MattRaffel`

danielhardman (Fri, 30 Aug 2019 19:58:06 GMT):
Merged PR #158.

danielhardman (Fri, 30 Aug 2019 19:58:38 GMT):
^ @swcurran @esplinr @kithat @sergey.minaev

sergey.minaev (Fri, 30 Aug 2019 19:58:38 GMT):
Has joined the channel.

rjones (Fri, 30 Aug 2019 20:00:05 GMT):
@danielhardman I appreciate that they've moved on - and I forgot Matt at Kiva has a ballot. Even if the involvement is low, they still have the right to cast a ballot. That's why I'm trying to find them

danielhardman (Fri, 30 Aug 2019 20:01:40 GMT):
I am connected to most of them on linkedin and may have their personal emails that way. I can DM them to you...

danielhardman (Fri, 30 Aug 2019 20:01:51 GMT):
Jumping on a call right now; give me an hour.

rjones (Fri, 30 Aug 2019 20:02:58 GMT):
sure, thank you

danielhardman (Mon, 02 Sep 2019 14:47:15 GMT):
Anybody free (working on US Labor Day, not traveling to RWOT) to merge a new PR in aries-rfcs? https://github.com/hyperledger/aries-rfcs/pull/209 @kdenhartog @swcurran @TelegramSam

danielhardman (Tue, 03 Sep 2019 17:01:50 GMT):
@ry: I accidentally created a branch: indy-hipe/sipmaster. I can't delete it because it became protected once I pushed it. Can you please remove it for me?

TelegramSam (Wed, 04 Sep 2019 18:21:56 GMT):
I have three new RFCs in proposed state in the repo. Thanks in advance.

rjones (Wed, 04 Sep 2019 22:27:37 GMT):
This is super important: you have a new, Aries-specific emoji. `:aries:`

rjones (Wed, 04 Sep 2019 22:27:37 GMT):
This is super important: you have a new, Aries-specific emoji. `:h-aries:`

rjones (Wed, 04 Sep 2019 22:28:41 GMT):
:h-aries:

danielhardman (Tue, 10 Sep 2019 19:25:11 GMT):
new PR proposing an RFC: https://github.com/hyperledger/aries-rfcs/pull/216

danielhardman (Tue, 10 Sep 2019 19:35:22 GMT):
And another one: https://github.com/hyperledger/aries-rfcs/pull/217

danielhardman (Wed, 11 Sep 2019 01:18:43 GMT):
And another: https://github.com/hyperledger/aries-rfcs/pull/218 This last one introduces the concept of delegatable credentials, and covers how they can be built with either ZKP-based or non-ZKP-based creds. I had to make some updates to existing RFC 0103 (indirect identity control), which is why it looks bigger than you might expect.

danielhardman (Wed, 11 Sep 2019 15:57:50 GMT):
@ry, can you turn on issues for the aries-protocol-test-suite repo?

danielhardman (Wed, 11 Sep 2019 15:57:50 GMT):
@rjones , can you turn on issues for the aries-protocol-test-suite repo?

rjones (Wed, 11 Sep 2019 16:32:25 GMT):
done

danielhardman (Wed, 11 Sep 2019 17:06:10 GMT):
@all: I have raised a PR that makes the protocol test suite more important. It updates our docs to say that we can't give an RFC the ACCEPTED status unless we have tests for it in the test suite, and we have at least one impl that passes those tests. It also adds a unit test to enforce this logic. I would like to discuss on today's "B" call with the Aries community.

danielhardman (Wed, 11 Sep 2019 17:06:10 GMT):
@all: I have raised a PR that makes the protocol test suite more important. It updates our docs to say that we can't give a protocol RFC the ACCEPTED status unless we have tests for it in the test suite, and we have at least one impl that passes those tests. It also adds a unit test to enforce this logic. I would like to discuss on today's "B" call with the Aries community.

danielhardman (Wed, 11 Sep 2019 17:06:25 GMT):
https://github.com/hyperledger/aries-rfcs/pull/220

rjones (Wed, 11 Sep 2019 19:52:05 GMT):
@esplinr @smithbk @jadhavajay I did a force-push to master on the repo. I didn't see there was a pull request in flight. Sorry. https://github.com/hyperledger/aries-sdk-javascript/pull/1 was closed by that action, and I can't reopen it directly. If you @jadhavajay rebases on top of the new master, I think it can be re-opened.

smithbk (Wed, 11 Sep 2019 19:52:05 GMT):
Has joined the channel.

swcurran (Wed, 11 Sep 2019 22:37:13 GMT):
As noted in the #aries, there was no recording made of todays call - no one there could push the record button. How do we make sure that we can record Working Group meetings in the future? At minimum, we need to know who is authorized to be a Zoom host on the Aries Working Group calls and push the record button. Ideally, we explicitly hand over both the meeting host and Zoom host roles for all future meetings. I had thought @kenebert had the power and made sure he was on the meeting, but he wasn't the host. Thanks! @nage @TelegramSam

nage (Wed, 11 Sep 2019 22:37:13 GMT):
Has joined the channel.

kenebert (Wed, 11 Sep 2019 22:37:13 GMT):
Has joined the channel.

swcurran (Wed, 11 Sep 2019 22:38:32 GMT):
Ouch...that "Thanks!" sounded sarcastic - it wasn't suppose to!!!!!

swcurran (Wed, 11 Sep 2019 22:38:53 GMT):
I meant - thanks for helping out with coming up with a solution that will work :-).

kenebert (Wed, 11 Sep 2019 22:40:03 GMT):
I thought I had record privileges (since I had been able to record other meetings), but I didn't. Nor could I find anyone who had them. I agree we need to clearly designate who has record privileges and a process for passing control when all hosts are unable to attend.

kdenhartog (Thu, 12 Sep 2019 00:33:23 GMT):
@SeanBohan had a way that he was able to designate shared hosts from the host's account. This allowed me to be able to record the Indy meetings in the past. I believe there's a setting in Zoom web app to toggle this feature.

SeanBohan (Thu, 12 Sep 2019 00:33:23 GMT):
Has joined the channel.

nage (Thu, 12 Sep 2019 14:24:07 GMT):
@swcurran I was disappointed with how the call was setup. We usually set the meeting to auto-record and also add everyone else in the org as alternative hosts. It looks like we haven't done either yet with the Aries appointments

nage (Thu, 12 Sep 2019 14:24:45 GMT):
we will look at all the meeting appointments and fix the defaults going forward

swcurran (Thu, 12 Sep 2019 14:44:31 GMT):
Awesome - thanks, @nage. Sam's away next week again and I'm hosting so we can verify all is well.

esplinr (Thu, 12 Sep 2019 15:28:59 GMT):
The big challenge is that Zoom doesn't allow co-hosts from a different organization.

rjones (Thu, 12 Sep 2019 15:44:15 GMT):
We have community Zoom accounts which you can use.

rjones (Thu, 12 Sep 2019 15:44:27 GMT):
which have other problems - I know! but they exist.

jadhavajay (Thu, 12 Sep 2019 17:13:07 GMT):
Sure, @rjones . I will try to rebase and will re-open the PR

rjones (Thu, 12 Sep 2019 17:54:47 GMT):
I apologize for the turbulence.

jadhavajay (Fri, 13 Sep 2019 09:26:24 GMT):
Raised the PR again - https://github.com/hyperledger/aries-sdk-javascript/pull/4

jadhavajay (Fri, 13 Sep 2019 09:27:03 GMT):
[ ](https://chat.hyperledger.org/channel/aries-maintainers?msg=97HLNeJFyNq4ciPL3) No problem :thumbsup:

rjones (Mon, 16 Sep 2019 15:35:16 GMT):
Has left the channel.

dbluhm (Tue, 24 Sep 2019 14:05:30 GMT):
@george.aristy called to attention the fact that the signature decorator is currently undocumented in aries-rfcs. I had to dig quite a bit to find the original proposed HIPE that introduced it. As the `did-exchange` protocol depends on being able to sign a field, this ought to be resolved quickly -- especially with implementations intending to cut over to did-exchange after IIW. Issue reference: https://github.com/hyperledger/aries-rfcs/issues/228

danielhardman (Tue, 24 Sep 2019 16:17:27 GMT):
@rjones Can I chat with you live (e.g., over zoom) about https://github.com/hyperledger/aries-rfcs/issues/225?

rjones (Tue, 24 Sep 2019 16:17:27 GMT):
Has joined the channel.

rjones (Tue, 24 Sep 2019 16:32:37 GMT):
sure - not sure what I can add, but yes

sklump (Tue, 24 Sep 2019 16:33:25 GMT):
Has left the channel.

danielhardman (Tue, 24 Sep 2019 16:34:19 GMT):
https://zoom.us/j/8013612445

danielhardman (Tue, 24 Sep 2019 16:34:19 GMT):
@rjones https://zoom.us/j/8013612445

george.aristy (Tue, 24 Sep 2019 18:57:31 GMT):
@dbluhm thank you!

george.aristy (Tue, 24 Sep 2019 18:57:53 GMT):
@kdenhartog can you please advise us on that issue?

george.aristy (Tue, 24 Sep 2019 18:58:15 GMT):
@kdenhartog can you please advise us on this issue?

kdenhartog (Tue, 24 Sep 2019 23:44:19 GMT):
In regards to the ~sig work, I think it's fine to keep things as they are in did-exchange protocol but the intent is to be using JWS for signing rather than the object I originally created for the ~sig decorator. If you only want to write one, then JWS would be better because that's what's being used in the crypto layer as well. However, it hasn't been documented because I've been caught up with work on products at Mattr and haven't had time to write the new documents like I originally stated awhile ago.

kdenhartog (Tue, 24 Sep 2019 23:44:19 GMT):
In regards to the `~sig` work, I think it's fine to keep things as they are in did-exchange protocol but the intent is to be using JWS for signing rather than the object I originally created for the `~sig` decorator. If you only want to write one, then JWS would be better because that's what's being used in the crypto layer as well. However, it hasn't been documented because I've been caught up with work on products at Mattr and haven't had time to write the new documents like I originally stated awhile ago.

kdenhartog (Tue, 24 Sep 2019 23:44:19 GMT):
In regards to the `~sig` work, I think it's fine to keep things as they are in did-exchange protocol but the intent is to be using JWS for signing rather than the object I originally created for the `~sig` decorator. If you only want to write one, then JWS would be better because that's what's being used in the crypto layer as well. However, it hasn't been documented because I've been caught up with work at Mattr and haven't had time to write the new documents like I originally stated awhile ago

kdenhartog (Tue, 24 Sep 2019 23:45:21 GMT):
What this means is that the did exchange protocol likely needs to be changed.

dbluhm (Tue, 24 Sep 2019 23:47:01 GMT):
To clarify, we can embed a JWS inside of the connection response, essentially replacing the object that we were originally using?

kdenhartog (Tue, 24 Sep 2019 23:47:17 GMT):
Yes, that's what I think should be done.

dbluhm (Tue, 24 Sep 2019 23:51:28 GMT):
I wonder if it would make sense to first port over the original HIPE into an RFC and then supersede it with an RFC detailing use of JWS. That way we have a cleaner "commit history" so to speak

dbluhm (Tue, 24 Sep 2019 23:52:24 GMT):
Especially since the original HIPE was, unfortunately, never merged into the indy-hipe repository. All we have right now to refer back to is a closed PR

kdenhartog (Wed, 25 Sep 2019 00:01:28 GMT):
Makes sense to the first suggestion of porting and superseding.

kdenhartog (Wed, 25 Sep 2019 00:01:53 GMT):
If you can make a PR on it I can merge it, but I won't have much time to chase that down before IIW.

dbluhm (Wed, 25 Sep 2019 00:03:02 GMT):
I'll work on throwing a port together tomorrow

kdenhartog (Wed, 25 Sep 2019 00:03:08 GMT):
thanks!

rjones (Wed, 25 Sep 2019 00:30:56 GMT):
Has left the channel.

esplinr (Wed, 25 Sep 2019 14:01:49 GMT):
Starting the Aries WG A call: https://zoom.us/j/244779296

esplinr (Wed, 25 Sep 2019 14:01:58 GMT):
https://wiki.hyperledger.org/pages/viewpage.action?pageId=20021893

danielhardman (Wed, 25 Sep 2019 15:17:16 GMT):
@TelegramSam Can I have 10 min in the afternoon call to talk about this PR? https://github.com/hyperledger/aries-rfcs/pull/220

george.aristy (Wed, 25 Sep 2019 18:07:59 GMT):
I'd rather we decide now instead of switching gears later (if we've already made up our minds regarding what the final solution will look like)

george.aristy (Wed, 25 Sep 2019 18:09:29 GMT):
So, if I understand correctly, what you guys are proposing for the final solution with JWS is to have the `response` msg also include a `did` and `did_doc` attribute (just like the `request` msg), and in addition to that include an attribute with a jws signature on the contents of the `did_doc`?

dbluhm (Wed, 25 Sep 2019 18:11:43 GMT):
Multiple implementations are already using the "forgotten" signature semantics and I think we still need more definition on using a JWS instead before we can cleanly switch

george.aristy (Wed, 25 Sep 2019 18:13:10 GMT):
the dot net framework is already using `conection~sig`: https://github.com/hyperledger/aries-framework-dotnet/blob/eb261677f7d13466b232db0ddfb410afd0a4078f/src/AgentFramework.Core/Messages/Connections/ConnectionResponseMessage.cs#L25

dbluhm (Wed, 25 Sep 2019 18:13:44 GMT):
The contents of `connection~sig` is what would change

dbluhm (Wed, 25 Sep 2019 18:14:39 GMT):
Right now, that object is what is defined in the closed PR from Indy HIPE. Or at least that's how things are working in the code bases I'm familiar with. I'd have to look into the .net framework

dbluhm (Wed, 25 Sep 2019 18:16:18 GMT):
My interpretation was that switching to JWS would essentially mean still having that `connection~sig` object but instead of what we originally defined as the contents of that attribute, we would have a JWS but I'm saying that without knowing in detail what @kdenhartog 's thoughts were on this

george.aristy (Wed, 25 Sep 2019 18:21:32 GMT):
Ok

george.aristy (Wed, 25 Sep 2019 18:22:17 GMT):
So, is part of the proposal to simply continue forth with the did-exchange RFC as it exists in Aries?

george.aristy (Wed, 25 Sep 2019 18:22:34 GMT):
And then update `connection~sig` later?

dbluhm (Wed, 25 Sep 2019 18:23:47 GMT):
That's my personal opinion but I certainly don't claim to speak for everyone. Might be a good topic to resolve on the call today. @TelegramSam ?

george.aristy (Wed, 25 Sep 2019 18:29:02 GMT):
Well... the problem I'm seeing with the RFC as-is is that `ed25519Sha512_single` is not defined at all

george.aristy (Wed, 25 Sep 2019 18:29:48 GMT):
And I see a few differences between what's described in the Aries RFC vs the HIPE that's currently sitting in Kyle's forkof indy-hipe

dbluhm (Wed, 25 Sep 2019 18:31:19 GMT):
I agree that that is a problem. We obviously need an RFC that defines it. I haven't been able to examine the original HIPE in detail yet. What differences are you seeing?

george.aristy (Wed, 25 Sep 2019 18:32:28 GMT):
Well, for starters, the Aries RFC doesn't define `ed25519Sha512_single` at all. But if you were to assume that its definition resides in Kyle's HIPE, then I see that the timestamp format is different

dbluhm (Wed, 25 Sep 2019 18:33:46 GMT):
I'm confused; which timestamps are you comparing?

george.aristy (Wed, 25 Sep 2019 18:34:18 GMT):
The one in `sig_data`

george.aristy (Wed, 25 Sep 2019 18:34:43 GMT):
I think that's the only difference I see

dbluhm (Wed, 25 Sep 2019 18:34:47 GMT):
Ah, I see it now

george.aristy (Wed, 25 Sep 2019 18:35:25 GMT):
Also, RFCs shouldn't define standards in terms of specific implementations - see the mention of "indy_crypto_sign" here: https://github.com/kdenhartog/indy-hipe/blob/d421fc77bae87c780aad346d15c0c49939adc281/text/digital-signatures/README.md#signing-implementation

dbluhm (Wed, 25 Sep 2019 18:37:33 GMT):
I agree; that and any other indy-isms and the timestamp format would naturally need to be addressed in porting to an RFC

danielhardman (Wed, 25 Sep 2019 20:04:46 GMT):
All (and especially @dbluhm and @TelegramSam): I really liked our brief discussion about the test suite just now. It made me feel like we need an RFC to explain community expectations about the test suite. I just started a hackmd doc that I filled with questions (but not a lot of answers). When you see the questions, I think you'll see why I don't think it's the same thing as test suite docs. Maybe we could use this to collaborate on the topic? https://hackmd.io/@dhh1128/SyQ0Y4tvS

faisal00813 (Thu, 26 Sep 2019 04:51:44 GMT):
Has joined the channel.

george.aristy (Thu, 26 Sep 2019 19:16:17 GMT):
@dbluhm are you porting the `connection~sig` HIPE?

dbluhm (Thu, 26 Sep 2019 19:22:46 GMT):
I'm planning to but I haven't yet

george.aristy (Thu, 26 Sep 2019 23:32:29 GMT):
So what I see is that aries-framework-dotnet is pretty much following the signing implementation steps of the HIPE: https://github.com/kdenhartog/indy-hipe/blob/d421fc77bae87c780aad346d15c0c49939adc281/text/digital-signatures/README.md#signing-implementation

george.aristy (Thu, 26 Sep 2019 23:33:03 GMT):
Which just means at compute a ed25519 signature.

george.aristy (Thu, 26 Sep 2019 23:33:03 GMT):
Which just means: compute a ed25519 signature.

george.aristy (Thu, 26 Sep 2019 23:33:34 GMT):
Is that all there is to the spec?

george.aristy (Thu, 26 Sep 2019 23:33:47 GMT):
I had lingering questions around the identifier `ed25519Sha512_single`

george.aristy (Thu, 26 Sep 2019 23:34:04 GMT):
She "Sha512" part and the "single" part

george.aristy (Thu, 26 Sep 2019 23:34:04 GMT):
The "Sha512" part and the "single" part

dbluhm (Thu, 26 Sep 2019 23:36:39 GMT):
Essentially; if you'd like to see an implementation that doesn't use Indy, here are a couple: https://github.com/dbluhm/indy-sign-attr-js https://github.com/hyperledger/aries-staticagent-python/blob/master/aries_staticagent/crypto.py#L143-L177 Not sure myself on the identifier

kdenhartog (Thu, 26 Sep 2019 23:37:30 GMT):
@george.aristy if you're able to get around to porting it before @dbluhm let me know and I can merge it.

kdenhartog (Thu, 26 Sep 2019 23:42:39 GMT):
It is supposed to just be a normal ed25519 signature. However, I named it in that way to account for how signatures using weierstrass curves (P-256, Secp256k1, etc) can support multiple hash algorithms. With regards to Single, I was trying to account for the use of multi-signatures which is why the question at the bottom brings this up.

kdenhartog (Thu, 26 Sep 2019 23:43:17 GMT):
E.g. how would a notary and mortgage purchaser sign data together

george.aristy (Fri, 27 Sep 2019 13:58:02 GMT):
FYI: I'm in the middle of porting this

george.aristy (Fri, 27 Sep 2019 13:58:06 GMT):
should be done sometime today

george.aristy (Fri, 27 Sep 2019 16:27:55 GMT):
https://github.com/hyperledger/aries-rfcs/pull/235

KellyCooper (Sun, 29 Sep 2019 18:12:35 GMT):
Has joined the channel.

cam-parra (Wed, 09 Oct 2019 15:46:47 GMT):
Has joined the channel.

george.aristy (Thu, 10 Oct 2019 15:13:22 GMT):
@swcurran @TelegramSam do you guys agree with @danielhardman 's solution for correlating a did-exchange request to an invitation by using `~thread.phid`? https://github.com/hyperledger/aries-rfcs/issues/208#issuecomment-538017606

george.aristy (Thu, 10 Oct 2019 15:14:11 GMT):
Does it need discussion on a call, or can we update the RFC right away if you guys agree?

george.aristy (Thu, 10 Oct 2019 15:16:58 GMT):
I would also ping Ryan West and Matthew Hailstone, but I don't have their handles.

swcurran (Thu, 10 Oct 2019 15:38:00 GMT):
I'm out on vacation so won't get to it until next week. Seems odd, but I've not thought through it, and I suspect Daniel has 😀. Needs to handle cases of a single-use and multi-use invitations.

TelegramSam (Thu, 10 Oct 2019 15:43:18 GMT):
Gave it a read. I agree with both the approach and the need for explanitary text.

TelegramSam (Thu, 10 Oct 2019 15:45:45 GMT):
Matthew Hailstone and Ryan West are less involved at this point, but were the origins of much of this.

TelegramSam (Thu, 10 Oct 2019 15:48:05 GMT):
@george.aristy comment left on issue as well. PR to the RFC is welcome.

swcurran (Thu, 10 Oct 2019 15:55:32 GMT):
Good stuff... Done.

swcurran (Thu, 10 Oct 2019 15:55:32 GMT):
Good stuff... Decision made.

danielhardman (Thu, 10 Oct 2019 16:54:57 GMT):
I would like to get https://github.com/hyperledger/aries-rfcs/pulls merged. Does anybody have concerns about doing so? It's been sitting for a couple weeks waiting for community comment, but only a few thoughts have been shared. We socialized at IIW and got a positive reaction--but that was oral feedback, not written feedback... @jjordan left a question, which I tried to resolve... (If a maintainer is comfortable merging, please do so; I feel like it would be better for someone else to merge this than for me, since it is not a semantically insignificant tweak, and since I raised it.)

danielhardman (Thu, 10 Oct 2019 16:54:57 GMT):
I would like to get https://github.com/hyperledger/aries-rfcs/pulls/220 merged. Does anybody have concerns about doing so? It's been sitting for a couple weeks waiting for community comment, but only a few thoughts have been shared. We socialized at IIW and got a positive reaction--but that was oral feedback, not written feedback... @jjordan left a question, which I tried to resolve... (If a maintainer is comfortable merging, please do so; I feel like it would be better for someone else to merge this than for me, since it is not a semantically insignificant tweak, and since I raised it.)

jjordan (Thu, 10 Oct 2019 16:54:57 GMT):
Has joined the channel.

mwherman2000 (Thu, 10 Oct 2019 18:56:41 GMT):
Has joined the channel.

jljordan_bcgov (Fri, 11 Oct 2019 18:38:07 GMT):
What I don't quite operationally understand is how the test suite is built and maintained ... as I understand this implementation for a test suite .. https://github.com/hyperledger/aries-protocol-test-suite .. there is code that would need to be written and maintained to reflect something defined in an RFC and that this code would be different that the code for an "agent under test" ... is that a correct understanding?

troyronda (Fri, 11 Oct 2019 18:47:40 GMT):
@jljordan_bcgov @danielhardman A possibly related concern to the above point: Let's say that someone writes an RFC and creates an implementation and even writes the code for the test suite. Is there criteria for the test suite maintainers to accept the new code? Will the test suite maintainers have the bandwidth (and also interest) in dealing with (reviewing and merging) a ... wide range ... of test suite submissions?

troyronda (Fri, 11 Oct 2019 18:47:40 GMT):
@jljordan_bcgov @danielhardman A possibly related point to the above: Let's say that someone writes an RFC and creates an implementation and even writes the code for the test suite. Is there criteria for the test suite maintainers to accept the new code? Will the test suite maintainers have the bandwidth (and also interest) in dealing with (reviewing and merging) a ... wide range ... of test suite submissions?

troyronda (Fri, 11 Oct 2019 18:47:40 GMT):
@jljordan_bcgov @danielhardman A possibly related point to the above: Let's say that someone writes an RFC and creates an implementation and even writes the code for the test suite for that RFC. Is there criteria for the test suite maintainers to accept the new code? Will the test suite maintainers have the bandwidth (and also interest) in dealing with (reviewing and merging) a ... wide range ... of test suite submissions?

dbluhm (Fri, 11 Oct 2019 19:26:43 GMT):
@jljordan_bcgov The required code to test an agent is significantly simpler than the code of an actual agent. It is still code that needs to be maintained but I think we can get to a point where the writing of tests is not much more difficult than writing an RFC itself is.

jljordan_bcgov (Fri, 11 Oct 2019 20:46:49 GMT):
@dbluhm thanks ... I like the sound of that. Once we have a few cycles and people return from holidays I am sure we will have more ability to contribute to the discussion

swcurran (Tue, 15 Oct 2019 16:13:33 GMT):
Just back from vacation - wondering what is going on with DID-Exchange and getting rid of the "Connections" protocol in the current implementations. Last I heard that was to happen with everyone the week after IIW - e.g. last week. Any progress? @tomislav @tplooker @andrew.whitehead

andrew.whitehead (Tue, 15 Oct 2019 17:10:43 GMT):
@TelegramSam wanted to hold off on that one for some potential changes, and we discovered another required change related to peer DID support

andrew.whitehead (Tue, 15 Oct 2019 17:12:35 GMT):
https://github.com/hyperledger/aries-rfcs/issues/243 (this one)

swcurran (Tue, 15 Oct 2019 23:08:33 GMT):
Just listened to the call from Sept. 25 about this. Lots of new information that I didn't know. Very confusing... :-). For us, do nothing is a good approach. What does the Go folks and the IBM folks think? We were trying to move to support them.

swcurran (Tue, 15 Oct 2019 23:08:33 GMT):
Just listened to the call from Sept. 25 about this. Lots of new information that I didn't know. Very confusing... :-). For us, do nothing is a good approach. What do the Go folks and the IBM folks think? We were trying to move to support them.

swcurran (Tue, 15 Oct 2019 23:08:33 GMT):
Just listened to the call from Sept. 25 about this. Lots of new information that I didn't know. Very confusing... :-). For us, do nothing is a good approach. What do the Go folks and the IBM folks think? We were trying to move to support/align with them.

swcurran (Tue, 15 Oct 2019 23:09:19 GMT):
@troyronda @smithbk @george.aristy

swcurran (Tue, 15 Oct 2019 23:09:58 GMT):
Hmm...I haven't finished listening to the discussion. Maybe the answer is later in the recording.

TelegramSam (Wed, 16 Oct 2019 14:22:35 GMT):
I have a PR in for a clarification on the status for the DID Exchange RFC. (I was supposed to do it weeks ago, better late than never...)

TelegramSam (Wed, 16 Oct 2019 14:29:13 GMT):
@george.aristy A comment left on your RFC PR: https://github.com/hyperledger/aries-rfcs/pull/254

george.aristy (Wed, 16 Oct 2019 14:54:03 GMT):
@swcurran we're proceeding with the `did-exchange` protocol because of the weaknesses identified in the `connection`, such as that pointed to by Andrew.

swcurran (Wed, 16 Oct 2019 15:59:15 GMT):
OK. I guess we'll remain incompatible until the rest of the issues with DID-Exchange can be clarified.

swcurran (Wed, 16 Oct 2019 15:59:15 GMT):
OK. I guess we'll remain incompatible with the Go framework until the rest of the issues with DID-Exchange can be clarified.

danielhardman (Wed, 16 Oct 2019 20:27:40 GMT):
@TelegramSam and @cam-parra : I was able to rename the wallet repo to Ares - AMS. However, I couldn't change the list of maintainers, and I cannot create the new repo Ares - core. We need to contact Rye for that. I am using rocketchat from my mobile phone because the Mac client broke when I upgraded to Catalina, so it's hard for me to paste hyperlinks into this. I'm using voice to text. Could one of you paste a hyperlink to the Ares 3 ticket for Rye, and ask him to take care of this additional busy work? Tell him I tried to use the Privileges he gave me, and I could have done it in some groups, but it appears that I can't do it across the board.

danielhardman (Wed, 16 Oct 2019 22:40:31 GMT):
@swcurran or @TelegramSam, I have updated the pr about test Suite, number 220, according to what we discussed in our community call. Can you please merge it?

kdenhartog (Thu, 17 Oct 2019 00:56:38 GMT):
@danielhardman the mac client works if you uninstall the client downloaded from the Apple store and download the package directly from the website. The link is the "direct download" button at https://rocket.chat/install

kdenhartog (Thu, 17 Oct 2019 00:56:52 GMT):
I had similar problems with upgrading as well

kdenhartog (Thu, 17 Oct 2019 00:59:04 GMT):
[ ](https://chat.hyperledger.org/channel/aries-maintainers?msg=608af88f-3c07-472a-8311-88ccb20cc3c9) @rjones could you help with this? Here's the link to the ticket https://jira.hyperledger.org/secure/RapidBoard.jspa?rapidView=231&projectKey=ARIES&view=planning&selectedIssue=ARIES-3

rjones (Thu, 17 Oct 2019 00:59:04 GMT):
Has joined the channel.

rjones (Thu, 17 Oct 2019 02:02:04 GMT):
@kdenhartog I want to be sure: you want new, blank repos, right?

rjones (Thu, 17 Oct 2019 02:02:31 GMT):
@kdenhartog I ask because last time I did this, I did a lot of work that I had to discard

rjones (Thu, 17 Oct 2019 02:02:49 GMT):
```Each repo should contain a README.md explaining the purpose of the repo, and other open source scaffolding (license, maintainers, etc).```

rjones (Thu, 17 Oct 2019 02:02:51 GMT):
belay thagt

rjones (Thu, 17 Oct 2019 02:02:51 GMT):
belay that

kdenhartog (Thu, 17 Oct 2019 02:08:33 GMT):
I’m not sure quite honestly. I’m just relaying the message. I’ll let others make that call.

rjones (Thu, 17 Oct 2019 02:10:07 GMT):
I think, reading the bug, I understand the expectationsa

swcurran (Sat, 19 Oct 2019 20:25:04 GMT):
I just added a comment to the Jira 3 about the repo names and would like to propose that some of the repo names change to match W3C naming. https://jira.hyperledger.org/browse/ARIES-3?focusedCommentId=64801&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-64801 ``` Troy Ronda had asked a question on the call about the term "dri" and I incorrectly answered that it is the term used by W3C for the source of verification data ("keys and other relevant data" per the spec) for verifiable credentials – aka the ledger. The correct W3C term is "Verifiable Data Registry". See this section.] of the verifiable credentials spec. I suggest that we change the "dri" acronyms to be "vdri" to align with the W3C verifiable credential data model spec. As a side note, I also suggest that we stick to github issues for everything Aries. ```

swcurran (Sat, 19 Oct 2019 20:25:04 GMT):
I just added a comment to the Jira 3 about the repo names and would like to propose that some of the repo names change to match W3C naming. https://jira.hyperledger.org/browse/ARIES-3?focusedCommentId=64801&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-64801 ``` Troy Ronda had asked a question on the call about the term "dri" and I incorrectly answered that it is the term used by W3C for the source of verification data ("keys and other relevant data" per the spec) for verifiable credentials – aka the ledger. The correct W3C term is "Verifiable Data Registry". See this section of the verifiable credentials spec. I suggest that we change the "dri" acronyms to be "vdri" to align with the W3C verifiable credential data model spec. As a side note, I also suggest that we stick to github issues for everything Aries. ```

kdenhartog (Sun, 20 Oct 2019 03:18:27 GMT):
Hey all, @brentzundel has proposed moving the Rich Schema RFC (0250) from `proposed` status to `accepted` status. If anyone has objections to this change in status please raise them in the next week. Otherwise we'll assume consensus on the RFC has been achieved. Also, I'm taking note that @troyronda has raised a concern already and the RFC has been modified. Can you take a look to see if it addresses your concerns Troy?

brentzundel (Sun, 20 Oct 2019 03:18:27 GMT):
Has joined the channel.

TelegramSam (Tue, 22 Oct 2019 14:29:26 GMT):
aries-rfcs has access to github actions now. I'll see about testing the index build as an action instead of a pre-required step.

danielhardman (Wed, 23 Oct 2019 15:09:53 GMT):
@TelegramSam : aries-ams-sqlite and aries-vdri-peer have been marked as read-only repos for the time being, with a readme clarifying how they fit into the overall mental model, so nobody gets confused about whether to work with them.

danielhardman (Wed, 23 Oct 2019 15:10:10 GMT):
@swcurran : aries-dri has been renamed aries-vdri

TelegramSam (Wed, 23 Oct 2019 15:55:03 GMT):
Thanks for doing that @danielhardman

brian.richter (Thu, 24 Oct 2019 15:47:12 GMT):
Has joined the channel.

josephboyle (Fri, 25 Oct 2019 20:50:14 GMT):
Has joined the channel.

donqui (Sun, 27 Oct 2019 07:25:59 GMT):
Has joined the channel.

kdenhartog (Tue, 29 Oct 2019 03:28:21 GMT):
Hey in regards to status, what's our take on converting things from Accepted to Adopted? I'm realizing that Accepted has become what I originally invisioned Adopted would be and demonstrated is becoming what I originally thought accepted would be. This doesn't align with what's written though, so I'm curious what difference do we expect to convert an accepted status to an adopted status?

kdenhartog (Tue, 29 Oct 2019 03:28:42 GMT):
For example, would the encryption envelope be adopted at this point?

kdenhartog (Tue, 29 Oct 2019 03:28:42 GMT):
For example, would the encryption envelope be adopted at this point? (I'd say no at this point, but it's getting there)

kdenhartog (Tue, 29 Oct 2019 03:28:42 GMT):
For example, would the encryption envelope be adopted at this point? (I'd say no as a gut check at this point, but it's getting there)

swcurran (Tue, 29 Oct 2019 18:57:34 GMT):
@kdenhartog , @danielhardman @troyronda - would one of you drive a discussion on the ~attach change about ~sig and include a discussion on the kid vs. jwk tradeoffs? It seems we are very close on that, right? Perhaps we can nail this down within this community.

swcurran (Tue, 29 Oct 2019 18:57:34 GMT):
@kdenhartog , @danielhardman @troyronda - would one of you drive a discussion on the \~attach change about \~sig and include a discussion on the kid vs. jwk tradeoffs? It seems we are very close on that, right? Perhaps we can nail this down within this community.

swcurran (Tue, 29 Oct 2019 18:57:34 GMT):
@kdenhartog , @danielhardman @troyronda - would one of you drive a discussion on the \~attach change about elimination of \~sig and include a discussion on the kid vs. jwk tradeoffs? It seems we are very close on that, right? Perhaps we can nail this down within this community.

swcurran (Tue, 29 Oct 2019 18:57:34 GMT):
@kdenhartog , @danielhardman @troyronda - would one of you drive a discussion **on the Aries afternoon call tomorrow** on the \~attach change about elimination of \~sig and include a discussion on the kid vs. jwk tradeoffs? It seems we are very close on that, right? Perhaps we can nail this down within this community.

swcurran (Tue, 29 Oct 2019 18:59:19 GMT):
^^^ I meant to say "on the Aries afternoon call tomorrow"

danielhardman (Tue, 29 Oct 2019 19:34:58 GMT):
I'm happy to do it if nobody else volunteers, because I agree we need to get it over the finish line. But I think it'd be more optimal for someone else to be the spokesperson since I talk too much... :-)

danielhardman (Tue, 29 Oct 2019 19:57:14 GMT):
@swcurran : I added the topic as an agenda item in the doc on the wiki. I put Kyle and Troy's name by it, but I'll fill in if neither of them wants to take it. I also added some other agenda items...

danielhardman (Tue, 29 Oct 2019 19:59:27 GMT):
@kdenhartog : To convert to ADOPTED, we'd need to see a really robust testing strategy and broad impl. The old encr envelope stuff might have approached that, but IMO we keep resetting the status by changing our minds about how we're going to do it next. This is one of my sources of frustration; I thought we had something working with reasonable adoption, and now I'm feeling like we're starting over. Certainly we can't claim that something not yet implemented, that's being discussed in PR and issue comment streams, deserves the ADOPTED status.

rjones (Tue, 29 Oct 2019 20:30:17 GMT):
Has left the channel.

kdenhartog (Tue, 29 Oct 2019 20:49:48 GMT):
Yes, I agree that anything new would not even be of a proposed status yet. I was thinking of what’s implemented during that comment. And more than anything I wanted to get a sense of what’s the rough boundary between accepted and adopted status. I’m uncertain of the additional hurdles that adopted places on an RFC when converting from accepted status. For example would the agents RFC qualify for adopted status?

kdenhartog (Tue, 29 Oct 2019 20:57:28 GMT):
Also I can lead that part of the discussion tomorrow

rjones (Tue, 29 Oct 2019 23:10:09 GMT):
Has joined the channel.

rjones (Tue, 29 Oct 2019 23:10:58 GMT):
A discussion of GitHub issues versus Jira

rjones (Tue, 29 Oct 2019 23:11:26 GMT):
In the last week, guidance on Jira versus GitHub has changed.

rjones (Tue, 29 Oct 2019 23:11:53 GMT):
With the exception of security bugs - which must, right now, go in Jira - projects can choose Jira or GitHub issues.

rjones (Tue, 29 Oct 2019 23:13:03 GMT):
My comment here to @danielhardman and @esplinr is no longer true: https://jira.hyperledger.org/browse/ARIES-3?focusedCommentId=64884&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-64884

danielhardman (Tue, 29 Oct 2019 23:13:41 GMT):
Good to know. Thanks.

troyronda (Wed, 30 Oct 2019 00:29:15 GMT):
I ran a simple experiment in aries-framework-go to compile to WebAssembly. So far, I tested starting up the framework and then calling DID Exchange CreateInvitation where I saw the freshly generated invitation (in this case, the wasm file was loaded into Safari v13). Note: I had to comment out the leveldb persistence code to get compilation to work. Thought I would share as it seemed interesting :).

troyronda (Wed, 30 Oct 2019 00:29:15 GMT):
I ran a simple experiment in aries-framework-go to compile to WebAssembly. So far, I tested starting up the framework and then calling DID Exchange CreateInvitation where I saw the freshly generated invitation object (in this case, the wasm file was loaded into Safari v13). Note: I had to comment out the leveldb persistence code to get compilation to work. Thought I would share as it seemed interesting :).

troyronda (Wed, 30 Oct 2019 00:39:23 GMT):
The experiment code is temporarily available here in my forked branch: https://github.com/troyronda/aries-framework-go/tree/wasm

swcurran (Wed, 30 Oct 2019 04:54:48 GMT):
FYI, GitHub issues handling of security bugs is in beta. I'm strongly in favor of sticking to going issues.

kdenhartog (Wed, 30 Oct 2019 06:43:50 GMT):
I far prefer issues. It reduces the complexity of managing what's happening in my opinion.

troyronda (Wed, 30 Oct 2019 11:33:04 GMT):
I also prefer GitHub issues.

swcurran (Wed, 30 Oct 2019 14:56:06 GMT):
And "going" is "github" in my comment above :-)

rjones (Wed, 30 Oct 2019 15:47:44 GMT):
@swcurran are you talking about this tab: https://github.com/hyperledger/aries-framework-go/security/advisories ? or is there another feature for security issues?

rjones (Wed, 30 Oct 2019 15:48:13 GMT):
that tab doesn't let someone external to the project file an issue privately in the same way Jira does

rjones (Wed, 30 Oct 2019 15:49:34 GMT):
```Access and visibility Until it is published, this draft security advisory will only be visible to collaborators with admin permissions on hyperledger/aries-framework-go. Other users and teams may be added once the advisory is created. Once published, security advisories on public repos are visible to everyone. Once reviewed by GitHub, they may be broadcast on the GitHub Advisory Database and they may be used to send security alerts to users that depend on this repository.```

troyronda (Wed, 30 Oct 2019 22:39:58 GMT):
@danielhardman Do you have the RFC with the updated message type posted (you were showing during the call)?

troyronda (Wed, 30 Oct 2019 22:39:58 GMT):
@danielhardman Do you have the RFC with the updated message type posted (you were showing during the call)? EDIT: I see it here: https://github.com/hyperledger/aries-rfcs/pull/277/

troyronda (Wed, 30 Oct 2019 22:41:15 GMT):
Just doule-checking that the message type changes from "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0/request" to "https://didcomm.org/didexchange/1.0/request"?

troyronda (Wed, 30 Oct 2019 22:41:15 GMT):
So the equivalent update for DID Exchange would appear to be "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0/request" to "https://didcomm.org/didexchange/1.0/request". i.e., Replace "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec" with "https://didcomm.org"

troyronda (Wed, 30 Oct 2019 22:41:15 GMT):
So the equivalent update for DID Exchange would be "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/didexchange/1.0/request" to "https://didcomm.org/didexchange/1.0/request". (i.e., Replace "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec" with "https://didcomm.org".)

troyronda (Wed, 30 Oct 2019 22:42:14 GMT):
i.e., Replace "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec" with "https://didcomm.org"

danielhardman (Thu, 31 Oct 2019 00:06:10 GMT):
Yes

troyronda (Thu, 31 Oct 2019 00:21:43 GMT):
I created a PR for DID Exchange RFC to update to https://didcomm.org. I assumed this would be an okay RFC to start with as it contains a new protocol type anyways. Thoughts?

troyronda (Thu, 31 Oct 2019 01:56:40 GMT):
And now also created a PR for the Introduce RFC.

esplinr (Fri, 01 Nov 2019 13:24:22 GMT):
In general, I'm happy with GitHub issues. But I expect we will continue to need the Aries Jira project for the issues that cross repo boundaries and so there isn't a place for them in GitHub.

troyronda (Fri, 01 Nov 2019 14:42:49 GMT):
@swcurran @kdenhartog @danielhardman @TelegramSam ( https://github.com/hyperledger/aries-rfcs/pull/282 / https://github.com/hyperledger/aries-rfcs/pull/283 )

cstoecker (Fri, 01 Nov 2019 15:06:41 GMT):
Has joined the channel.

danielhardman (Tue, 05 Nov 2019 15:46:19 GMT):
@swcurran and @TelegramSam and @kdenhartog and any others who are interested: @jjordan and @drummondreed and @darrell.odonnell and @vinomaster and others have submitted an RFC about the general solution layers required for self-sovereign or decentralized identity. (My name is on it, too, but I am really more of a mechanical contributor than an author; I just helped fix some graphics and get it merged.) Currently it is numbered 0289. However, I believe this RFC should be renumbered to 0001; I think it is the most high-level or foundational piece of content in the entire RFCs repo. It describes the general problem domain and how the various pieces of a software stack contribute and layer on one another; as we describe Aries at lower levels of detail, I think we'll be referring to it constantly. Are you okay with us renumbering this one?

vinomaster (Tue, 05 Nov 2019 15:46:19 GMT):
Has joined the channel.

drummondreed (Tue, 05 Nov 2019 15:46:19 GMT):
Has joined the channel.

danielhardman (Tue, 05 Nov 2019 15:50:23 GMT):
@sergey.minaev : I head that you were interested in working on an RFC about general Aries architecture. The RFC I mentioned above ^^ would be a good reference. It is NOT the RFC you are imagining, but would provide background for it. Perhaps that RFC you want to write ought to be RFC 0002 and could include a bunch of the architecture diagrams that we've been trying to polish in this slide deck: https://docs.google.com/presentation/d/1L5L4QcZOATrn9rj4bEMmlbvij9XWyqgQRoWO-HNiUGw/edit. Such an RFC could then be cited by the root READMEs of various repos we create or have already created for Aries (e.g., an aries-vdri repo could point to the arch diagram checked in with RFC 0002 that situates the VDRI component in inside the larger Aries stack that maps to the general problem domain description of RFC 0001).

danielhardman (Tue, 05 Nov 2019 15:50:23 GMT):
@sergey.minaev : I head that you were interested in working on an RFC about general Aries architecture. The RFC I mentioned above ^^ would be a good reference. It is NOT the RFC you are imagining, but would provide background for it. Perhaps that RFC you want someone to write ought to be RFC 0002 and could include a bunch of the architecture diagrams that we've been trying to polish in this slide deck: https://docs.google.com/presentation/d/1L5L4QcZOATrn9rj4bEMmlbvij9XWyqgQRoWO-HNiUGw/edit. Such an RFC could then be cited by the root READMEs of various repos we create or have already created for Aries (e.g., an aries-vdri repo could point to the arch diagram checked in with RFC 0002 that situates the VDRI component in inside the larger Aries stack that maps to the general problem domain description of RFC 0001).

danielhardman (Tue, 05 Nov 2019 15:50:23 GMT):
@sergey.minaev : I head that you were interested in getting collaborators to work on an RFC about general Aries architecture. The RFC I mentioned above ^^ would be a good reference. It is NOT the RFC you are imagining, but would provide background for it. Perhaps that RFC you want someone to write ought to be RFC 0002 and could include a bunch of the architecture diagrams that we've been trying to polish in this slide deck: https://docs.google.com/presentation/d/1L5L4QcZOATrn9rj4bEMmlbvij9XWyqgQRoWO-HNiUGw/edit. Such an RFC could then be cited by the root READMEs of various repos we create or have already created for Aries (e.g., an aries-vdri repo could point to the arch diagram checked in with RFC 0002 that situates the VDRI component in inside the larger Aries stack that maps to the general problem domain description of RFC 0001).

danielhardman (Tue, 05 Nov 2019 15:50:23 GMT):
@sergey.minaev : I heard that you were interested in getting collaborators to work on an RFC about general Aries architecture. The RFC I mentioned above ^^ would be a good reference. It is NOT the RFC you are imagining, but would provide background for it. Perhaps that RFC you want someone to write ought to be RFC 0002 and could include a bunch of the architecture diagrams that we've been trying to polish in this slide deck: https://docs.google.com/presentation/d/1L5L4QcZOATrn9rj4bEMmlbvij9XWyqgQRoWO-HNiUGw/edit. Such an RFC could then be cited by the root READMEs of various repos we create or have already created for Aries (e.g., an aries-vdri repo could point to the arch diagram checked in with RFC 0002 that situates the VDRI component in inside the larger Aries stack that maps to the general problem domain description of RFC 0001).

esplinr (Tue, 05 Nov 2019 16:15:44 GMT):
I am in favor of claiming the number. That kind of foundational RFC was what I expected in an RFC 001 when we set it aside.

swcurran (Tue, 05 Nov 2019 16:33:11 GMT):
I will likely support this, but definitely think that this should be talked about in the community. Suggest a proposal at the Working Group meeting and then a formal vote, announcement and waiting period.

swcurran (Tue, 05 Nov 2019 16:33:11 GMT):
I will likely support this, but definitely think that this should be talked about in the community first. Suggest a proposal at the Working Group meeting and then a formal vote, announcement and waiting period.

danielhardman (Tue, 05 Nov 2019 17:00:31 GMT):
The problem with that kind of process is that permalinks become entrenched. Content gets indexed by google at old links. John Jordan is on the road right now, and told me last night he wanted to share the doc with people he is meeting. I don't want to perpetuate an RFC number that's going to be changed. There is no document or process that covers this situation, so socializing it and having a waiting period feel to me like things we'd do out of an abundance of caution. Are we expecting there to be lots of pushback? This is NOT a request that we change the status of the RFC doc to ACCEPTED or ADOPTED... We could socialize this idea in #aries right now, rather than waiting for a call and so forth...

swcurran (Tue, 05 Nov 2019 17:07:59 GMT):
I reading the document now. Finding some issues with it, but generally in agreement. We would leave 289 in place as a redirector to the new location. I don't see that as a big deal. Part of my reaction was that this was offered as an approach and immediately followed with "and this should be RFC 0002", which I definitely think is jumping the gun. Lets get content and then consider if it should be a magic RFC.

danielhardman (Tue, 05 Nov 2019 17:11:03 GMT):
Stephen: I think you're conflating 2 different things. RFC 0002 is a number I suggested for a non-existent document, and that is an "approach" document. The document I'm proposing to renumber is 0289, and I'm suggesting it be renamed to 0001. The latter doc is not an approach; it's a survey of the conceptual territory in our space. Of course we can tweak a doc--but we don't normally renumber things after we accept them; we get the permanent number when it is proposed.

swcurran (Tue, 05 Nov 2019 17:11:39 GMT):
No, that's exactly what I understood.

swcurran (Tue, 05 Nov 2019 17:12:22 GMT):
Suggesting a non-existent document be RFC 0002 is IMHO odd. I understand 289 -> 001, and generally agree, but I think the community should decide.

danielhardman (Tue, 05 Nov 2019 17:13:07 GMT):
Leaving a redirect will require us to create some ugly kludges in our unit tests and automation, since the old doc will be degenerate.

swcurran (Tue, 05 Nov 2019 17:14:57 GMT):
I don't know what to tell you. I think its a bad idea.

danielhardman (Tue, 05 Nov 2019 17:15:12 GMT):
What is a bad idea: 0001 or 0002?

danielhardman (Tue, 05 Nov 2019 17:15:28 GMT):
Please keep these two ideas separate.

danielhardman (Tue, 05 Nov 2019 17:15:43 GMT):
0002 is entirely unrelated to what I'm proposing.

swcurran (Tue, 05 Nov 2019 17:15:56 GMT):
I get that. I'm talking 0001 without community agreement.

danielhardman (Tue, 05 Nov 2019 17:17:01 GMT):
So do you have a problem with me proposing it to the community right now, instead of waiting for a call?

swcurran (Tue, 05 Nov 2019 17:17:28 GMT):
Yes

danielhardman (Tue, 05 Nov 2019 17:17:33 GMT):
why?

swcurran (Tue, 05 Nov 2019 17:17:49 GMT):
You can propose it now, and I'm against completing the process until the community responds.

danielhardman (Tue, 05 Nov 2019 17:18:22 GMT):
And you're saying that the way to measure "the community responds" must be to let a 2-week comment period elapse?

troyronda (Tue, 05 Nov 2019 17:18:31 GMT):
Do we think we need to introduce a bit more neutrality into this document?

troyronda (Tue, 05 Nov 2019 17:18:43 GMT):
It has a bit of a sovrin flare to it.

troyronda (Tue, 05 Nov 2019 17:18:43 GMT):
It feels like it has a bit of a sovrin flare to it. (but I only had a quick glance so far.)

swcurran (Tue, 05 Nov 2019 17:19:02 GMT):
I think this is a pretty important issue and the community needs to weigh in. You want to make this a go to document for the entire community. That's not a small issue.

troyronda (Tue, 05 Nov 2019 17:20:41 GMT):
I certainly think there is worthwhile and useful content for a community introduction in it.

troyronda (Tue, 05 Nov 2019 17:21:02 GMT):
but there are bits that could have been ... perhaps moved to a particular flavor.

danielhardman (Tue, 05 Nov 2019 17:22:37 GMT):
I think you are confusing acceptance (a defined status adjudication process) with numbering. Nobody is saying that the content of the document in its current form has to be what the community accepts. What I am saying is that a document with the current scope / topic belongs as RFC 0001. The community gets to debate its content just like any other RFC, until we are happy with it. But there's no question in my mind that this is topic #1 for the community, and it feels silly for me to wonder whether that's the case.

danielhardman (Tue, 05 Nov 2019 17:23:11 GMT):
What alternative topic would you suggest ought to be topic #1?

swcurran (Tue, 05 Nov 2019 17:23:18 GMT):
I'm not confusing that. I'm saying if we are going to suddenly decide to have a flagship RFC, the community should weigh in.

swcurran (Tue, 05 Nov 2019 17:23:38 GMT):
I don't have an alternative to propose.

swcurran (Tue, 05 Nov 2019 17:23:51 GMT):
I don't think waiting is a crisis.

danielhardman (Tue, 05 Nov 2019 17:35:00 GMT):
Okay. I'll follow the alternative process that you're recommending, Stephen. However, I'm gritting my teeth. I don't like polluting the RFC index and namespace with redirects, and I don't agree that numbering a doc is the same as accepting it, and I don't agree that assigning #1 to this topic is controversial. I do agree that it's worth discussing whether we want to have a "highest level survey of the problem space" RFC at all, and I do agree that the content of such an RFC should be vetted by the community very carefully, correcting any concerns like the ones Troy is raising. I think that by following the process you're recommending, we'll perpetuate a misunderstanding about the relative gravitas of an RFC with only the PROPOSED status, and get bogged down in debates about content that don't belong as part of this numbering question.

danielhardman (Tue, 05 Nov 2019 17:35:58 GMT):
Look for my post in #aries proposing the number; I'll also add myself to the agenda on tomorrow's two calls to make the proposal.

danielhardman (Tue, 05 Nov 2019 19:02:47 GMT):
@swcurran : I'm feeling more cheerful now that I've had time to think a bit more about this, and I'm regretting that I pushed back so hard. Thanks for your patience with me. I eventually come around, if you outwait my impatience... :-)

danielhardman (Tue, 05 Nov 2019 19:05:59 GMT):
@troyronda : can you capture some of your feedback where RFC 0289 feels too Sovrin-y, as one or more issues in github? I don't want to lose that important input, and I also don't want the doc to end up feeling too Sovrin-y. That was not its intent. Dan G just added a section about the notion of network-of-networks, where multiple instances of multiple networks, including R3 and EEA and Fabric, fit into the diagram...

troyronda (Tue, 05 Nov 2019 19:10:53 GMT):
I wrote a few comments prior to the latest update. https://github.com/hyperledger/aries-rfcs/issues/292

troyronda (Tue, 05 Nov 2019 19:11:59 GMT):
I would summarize as being careful about the description of ZKP, governance frameworks, and being inclusive of cases beyond physical credential analogues.

danielhardman (Tue, 05 Nov 2019 19:12:25 GMT):
Thank you!

TelegramSam (Tue, 05 Nov 2019 20:35:11 GMT):
I think it's appropriate to leave a 'redirect' RFC in place when another is promoted. I don't mean a literal redirect, just a placeholder RFC as a tombstone of sorts. This would require no changes to the CI and processing pipelines.

TelegramSam (Tue, 05 Nov 2019 20:35:25 GMT):
In any case, I've added time for this on tomorrow's call.

cam-parra (Wed, 06 Nov 2019 00:39:13 GMT):
@danielhardman you mentioned above that some may want to put together an RFC for a general architecture of Aries. This seems like the wrong approach since every piece of the architecture should have an individual RFC. And then maybe there could be something that says "these are the RFCs that make up the foundation of aries"

danielhardman (Wed, 06 Nov 2019 00:49:44 GMT):
Building up an architecture from the constituent pieces and breaking down an architecture from a global picture are both reasonable things to do, and they are not mutually exclusive. One process is called analysis; the other is called synthesis. The drawback of starting from a big picture is that you can't be sure of the details. The drawback of starting from the details is that you can't be sure they add up to a big picture that you like. In my experience, the best architectural output is achieved by iterating and alternating between these two modes, not by insisting that one or the other is correct. So my recommendation would be to do some work in both ways, and see what interesting tensions we uncover as we do it. I have already attempted to start a big picture once (the slides I sent around; https://docs.google.com/presentation/d/1L5L4QcZOATrn9rj4bEMmlbvij9XWyqgQRoWO-HNiUGw/edit). This is just a beginning, not a last word on that side of the work. The work you are doing to clarify the architecture of KMS is starting from the other side, and is also important. I predict that when we compare your doc draft to my diagram draft, we will find a lot that fits together and a few places that don't. Those few places will be worth learning from. So: I'm not advocating anything that should disrupt the efforts you already have underway. AND I'm also suggesting that thinking about the big picture is a good idea. I'm only pushing back on the assumption that the only way to proceed is to build everything from the details toward the general big picture; we should do both.

danielhardman (Wed, 06 Nov 2019 00:49:44 GMT):
Building up an architecture from the constituent pieces and breaking down an architecture from a global picture are both reasonable things to do, and they are not mutually exclusive. One process is called synthesis; the other is called analysis. The drawback of starting from a big picture is that you can't be sure of the details. The drawback of starting from the details is that you can't be sure they add up to a big picture that you like. In my experience, the best architectural output is achieved by iterating and alternating between these two modes, not by insisting that one or the other is correct. So my recommendation would be to do some work in both ways, and see what interesting tensions we uncover as we do it. I have already attempted to start a big picture once (the slides I sent around; https://docs.google.com/presentation/d/1L5L4QcZOATrn9rj4bEMmlbvij9XWyqgQRoWO-HNiUGw/edit). This is just a beginning, not a last word on that side of the work. The work you are doing to clarify the architecture of KMS is starting from the other side, and is also important. I predict that when we compare your doc draft to my diagram draft, we will find a lot that fits together and a few places that don't. Those few places will be worth learning from. So: I'm not advocating anything that should disrupt the efforts you already have underway. AND I'm also suggesting that thinking about the big picture is a good idea. I'm only pushing back on the assumption that the only way to proceed is to build everything from the details toward the general big picture; we should do both.

danielhardman (Wed, 06 Nov 2019 00:54:09 GMT):
BTW, do you have a draft of the KMS stuff that we can start looking at?

cam-parra (Wed, 06 Nov 2019 01:33:52 GMT):
I do apologize I realized that my statement above makes sounds like I am against your work on the slides. I actually really appreciate that work and have used it in my draft for the RFC for the KMS. I am more trying to compile all the good ideas that have been agreed upon so my draft may look familiar because it is compiled and then concepts are explained by me. My fear here is that we have a general RFC that goes against the KMS architecture (or any other piece of the architecture), therefore causing a divide. There are certain concepts that have been sold to the community already would be an anti-pattern to renege on those. here is what I have compiled so far: https://github.com/mac-arrap/aries-rfcs/tree/master/concepts/0276-key-management-service (it's pretty similar to what you've descibed) but I realized today that this is incomplete if we do not give a rough outline of what the APIs will look like. So I have invited the community to participate in that effort and realize that it might take some sitting down and discussing this.

danielhardman (Wed, 06 Nov 2019 01:39:19 GMT):
What you have so far seems like a reasonable start to me, but it is maybe 5% of what that doc needs. The APIs only add another 5%. I don't get why you say in your table that the Indy wallet doesn't have pluggable persistance. That was one of the major features of the Indy wallet--a defining characteristic, even. Maybe you mean something different from it than what I guess?

danielhardman (Wed, 06 Nov 2019 01:42:27 GMT):
Some major sections that I think the doc will eventually need include: 1. What kind of data goes into a KMS? Why? 2. Is a KMS searchable? How? 3. How is a KMS protected at rest? How is it protected when accessed over the wire? 4. What scale and performance contract does a KMS offer? 5. How is data in a KMS replicated? (I suspect the easy answer: "not at all" is a dead end, since DIDs and public keys do need replication) 6. How does backup and recovery work?

cam-parra (Wed, 06 Nov 2019 01:46:27 GMT):
I meant that indy does not offer a pluggable storage for keys themselves. If that is a mistake I can fix that . Thank you I will start working on those questions and update the doc tomorrow. I do think that it will take more than just me to populate this document since there are many details that must be agreed upon and many may have specific needs that need to be fulfilled by the kms.

troyronda (Wed, 06 Nov 2019 13:06:28 GMT):
My suggestion would be to split out a subset of the content of this RFC into a new RFC. This subset of content should be agnostic of use case, governance structure, credential types, and ledgers. There can be other RFCs for more detailed variations.

troyronda (Wed, 06 Nov 2019 13:06:28 GMT):
My suggestion would be to split out a subset of the content of this RFC into a new Overview RFC. This subset of content should be agnostic of use case, governance structure, credential types, and ledgers. There can be other RFCs for more detailed variations.

troyronda (Wed, 06 Nov 2019 13:06:28 GMT):
My suggestion would be to split out a subset of the content of this RFC into a new Overview RFC. (and augment with additional overview content as needed). This subset of content should be agnostic of use case, governance structure, credential types, and ledgers.

esplinr (Wed, 06 Nov 2019 14:58:45 GMT):
Starting the Aries WG A call in 2 minutes: https://zoom.us/j/244779296

troyronda (Mon, 11 Nov 2019 21:13:02 GMT):
@TelegramSam @swcurran @danielhardman I'm confused by the implications of this comment. https://github.com/hyperledger/aries-rfcs/pull/302#issuecomment-552553453 (This process does make a change to what PRs can be accepted by RFC repo maintainers.)

troyronda (Mon, 11 Nov 2019 21:13:02 GMT):
@TelegramSam @swcurran @danielhardman I'm also a bit confused by the implications of this comment. https://github.com/hyperledger/aries-rfcs/pull/302#issuecomment-552553453 (This process does make a change to what PRs can be accepted by RFC repo maintainers.)

troyronda (Mon, 11 Nov 2019 21:20:18 GMT):
This "Aries Stable" proposal leaves out newer members like ourselves. Despite our newness, we have already made substantial contributions, so this proposal (and general process) gives concern. We are very focused on a ledger, credential, and governance framework neutral approach to DID communications.

troyronda (Mon, 11 Nov 2019 21:20:18 GMT):
We should be careful that proposals like "Aries Stable" does not leave out newer members like ourselves. Despite our newness, we have already made substantial contributions, so this proposal (and general process) gives concern. We are very focused on a ledger, credential, and governance framework neutral approach to DID communications.

troyronda (Mon, 11 Nov 2019 21:20:18 GMT):
I would hope that the community remains vigilant that process and labelling proposals do not leave out newer members like ourselves. Despite our newness, we have already made substantial contributions, so this proposal (and general process) gives concern. We are very focused on a ledger, credential, and governance framework neutral approach to DID communications.

troyronda (Mon, 11 Nov 2019 21:20:18 GMT):
I would hope that the community remains vigilant that process and labelling proposals do not leave out newer members like ourselves. Despite our relative newness, we have already made substantial contributions, so this proposal (and general process) gives concern. We are very focused on a ledger, credential, and governance framework neutral approach to DID communications.

troyronda (Mon, 11 Nov 2019 21:20:18 GMT):
I would hope that the community remains vigilant that process and labelling proposals do not leave out newer members like ourselves. Despite our relative newness, we have already made substantial contributions, so some interpretations of this proposal (and the general process) gives concern. We are very focused on a ledger, credential, and governance framework neutral approach to DID communications.

swcurran (Mon, 11 Nov 2019 21:43:11 GMT):
On my phone, but quick answer is that certain PRs for this RFC have to be handled like PRs that change the status of a protocol RFC to "Accepted" - they need community agreement before merging. I think that is what Sam is highlighting.

troyronda (Mon, 11 Nov 2019 21:44:29 GMT):
I don't understand how we work on the next version of these protocols.

troyronda (Mon, 11 Nov 2019 21:44:29 GMT):
I don't understand how we work on the next iteration of these protocols.

troyronda (Mon, 11 Nov 2019 21:44:56 GMT):
Are we creating brand new RFCs for all of those RFCs to change the message type to https://didcomm.org (quick example).

troyronda (Mon, 11 Nov 2019 21:46:36 GMT):
Are we branching the repo?

troyronda (Mon, 11 Nov 2019 21:46:36 GMT):
Are we branching the aries-rfc repo?

troyronda (Mon, 11 Nov 2019 21:47:14 GMT):
Seems like we are missing a critical step of the process for those of us who are working on the iteration beyond what has been proposed.

troyronda (Mon, 11 Nov 2019 21:47:14 GMT):
Seems like we are missing a critical step of the process for those of us who are working on the iteration beyond what has been proposed in RFC 302.

troyronda (Mon, 11 Nov 2019 21:47:14 GMT):
Seems like we need clarification on a critical step of the process for those of us who are working on the iteration beyond what has been proposed in RFC 302.

troyronda (Mon, 11 Nov 2019 21:49:46 GMT):
We (aries-framework-go) are now starting on the credential protocols so we are going to hit this issue rapidly.

troyronda (Mon, 11 Nov 2019 21:49:46 GMT):
We (aries-framework-go contributors) are now starting on the credential protocols so we are going to hit this issue rapidly.

troyronda (Mon, 11 Nov 2019 21:59:32 GMT):
On another topic, we wrote up the aries-framework-go project description in preparation for our 0.1.0 release: https://github.com/hyperledger/aries-framework-go#framework-go

troyronda (Mon, 11 Nov 2019 22:00:33 GMT):
We are wrapping up a few more documentation updates ... so we expect the release shortly.

TelegramSam (Tue, 12 Nov 2019 15:39:56 GMT):
@troyronda I think we handle the message type change different than other protocol changes. Meaning, I don't think we need to 'version' them the same way. Further, I think we can have a conversion period handled in a small way within codebases that allows a transition period.

TelegramSam (Tue, 12 Nov 2019 15:52:11 GMT):
Adding a detect and replace block of code should be possible in a single place within a codebase. This allows for support of both for a period.

TelegramSam (Tue, 12 Nov 2019 15:52:33 GMT):
for the RFCs, This is also a search and replace operation.

TelegramSam (Tue, 12 Nov 2019 15:52:43 GMT):
combined approach means much less operational churn.

TelegramSam (Tue, 12 Nov 2019 15:54:02 GMT):
when we have a plan, we can set a community goal for accepting the new type strings. (as described above).

swcurran (Tue, 12 Nov 2019 15:54:06 GMT):
We (Nick) did a cut at an implementation last week. It does get a bit tricky and invasive to support both when you have to track which version of the @type to use with each outbound message based on the inbound message of the thread. It is not a search and replace, but it is doable.

TelegramSam (Tue, 12 Nov 2019 15:54:37 GMT):
then a goal to transmit the new type, then a goal to remove old support.

swcurran (Tue, 12 Nov 2019 15:54:53 GMT):
We plan to support both for a period of time. See: https://github.com/hyperledger/aries-cloudagent-python/issues/244

swcurran (Tue, 12 Nov 2019 15:57:33 GMT):
We are also making some changes in ACA-Py that will make the transition from Connection to DID Exchange easier. It has the same issue with tracking the inbound message to know what to support, with the added fun of having a generated `invitation` (first message) not knowing what protocol family to use. Our suggestion is that we make `invitation` separate from either Connection or DID Exchange to eliminate that issue.

swcurran (Tue, 12 Nov 2019 15:58:10 GMT):
That would still leave the issue of how to respond to an invitation - which protocol to use.

rjones (Wed, 20 Nov 2019 17:12:21 GMT):
@TelegramSam do these repo renaming and the like use the RFC process or no?

rjones (Wed, 20 Nov 2019 17:12:21 GMT):
@TelegramSam do these repo renaming and the like use the RFC process or no? https://chat.hyperledger.org/channel/community-architects?msg=q9JSWS7pWGf5HH5Cg

TelegramSam (Wed, 20 Nov 2019 17:16:19 GMT):
@rjones No.

TelegramSam (Wed, 20 Nov 2019 17:16:34 GMT):
RFC processes are unique to that one repo.

TelegramSam (Wed, 20 Nov 2019 17:16:39 GMT):
These are all code repos.

rjones (Wed, 20 Nov 2019 17:17:05 GMT):
OK, cool. That isn't the case for Fabric's new RFC process so I wanted to make sure I'm not breaking anything.

TelegramSam (Wed, 20 Nov 2019 17:17:19 GMT):
:thumbsup:

rjones (Wed, 20 Nov 2019 17:20:25 GMT):
`dbluhm` is a maintainer of `aries-sdk-javascript`. Remove?

rjones (Wed, 20 Nov 2019 17:21:00 GMT):
You should be able to see members and pending members here: https://github.com/orgs/hyperledger/teams/aries-sdk-javascript-committers/members

rjones (Wed, 20 Nov 2019 17:30:25 GMT):
@TelegramSam With the exception of the question about @dbluhm everything is set up for https://github.com/hyperledger/aries-framework-javascript and https://github.com/hyperledger/aries-sdk-javascript

rjones (Wed, 20 Nov 2019 17:31:00 GMT):
@ajayjadhav discussion here ^^^

dbluhm (Wed, 20 Nov 2019 17:31:48 GMT):
I haven't been involved in `aries-sdk-javascript` to this point. I mean, I'm happy to contribute lol but not sure I'm a first pick for maintainership :slight_smile:

rjones (Wed, 20 Nov 2019 17:32:02 GMT):
OK, I'll remove you if you like :)

dbluhm (Wed, 20 Nov 2019 17:32:14 GMT):
Probably best

rjones (Wed, 20 Nov 2019 17:35:56 GMT):
@TelegramSam whenever you want to transfer the two new repos, just go for it - transfer them to my GitHub ID, `ryjones`

dbluhm (Wed, 20 Nov 2019 18:07:54 GMT):
"Repository transfer to ryjones requested" for aries-acapy-plugin-toolbox

dbluhm (Wed, 20 Nov 2019 18:07:59 GMT):
@rjones ^

dbluhm (Wed, 20 Nov 2019 18:11:02 GMT):
Same for aries-toolbox now

rjones (Wed, 20 Nov 2019 18:12:50 GMT):
@dbluhm who will the maintainers be?

dbluhm (Wed, 20 Nov 2019 18:15:04 GMT):
The following will do: For toolbox: @TelegramSam, @burdettadam, and myself For aries-acapy-plugin-toolbox: @TelegramSam, and myself

burdettadam (Wed, 20 Nov 2019 18:15:04 GMT):
Has joined the channel.

rjones (Wed, 20 Nov 2019 18:25:55 GMT):
@dbluhm @TelegramSam I think everything is set up now.

dbluhm (Wed, 20 Nov 2019 18:26:12 GMT):
Thanks!

ajayjadhav (Wed, 20 Nov 2019 19:17:07 GMT):
Thanks @rjones

dbluhm (Thu, 21 Nov 2019 00:27:25 GMT):
@rjones I'm interested in using Github Actions to automatically upload packages to PyPI for Aries Static Agent Python on new releases but this requires using secrets which I am unable to manage or create on the repository. Is that something I can be granted access to? It's not too big of a deal but it would be convenient

rjones (Thu, 21 Nov 2019 00:29:20 GMT):
which repo?

dbluhm (Thu, 21 Nov 2019 00:29:37 GMT):
https://github.com/hyperledger/aries-staticagent-python

rjones (Thu, 21 Nov 2019 00:30:45 GMT):
OK. You have as much permission as I can delegate. If you can't get there from here, I can work with you to make this happen.

rjones (Thu, 21 Nov 2019 00:30:59 GMT):
I'm all on the "automate this away" train

dbluhm (Thu, 21 Nov 2019 00:31:12 GMT):
Looks like that worked. Thanks!

rjones (Thu, 21 Nov 2019 00:31:31 GMT):
Let me know when you have it wired up and working.

dbluhm (Thu, 21 Nov 2019 00:32:10 GMT):
Will do

dbluhm (Thu, 21 Nov 2019 00:54:35 GMT):
Got it set up and working. If you're curious, you can see the result of the action here (it failed because I didn't bump the version number and I've already published for this version): https://github.com/hyperledger/aries-staticagent-python/commit/b2a5425d4378b170fea6b00296de26d44513f185/checks?check_suite_id=321353617 Might make this a little more sophisticated with future PRs but that's it basically taken care of.

rjones (Thu, 21 Nov 2019 00:55:12 GMT):
cool. I won't change anything for a while in case you need to jiggle some bits around

SwapnaliDive (Fri, 22 Nov 2019 11:45:06 GMT):
Has joined the channel.

huxd (Tue, 26 Nov 2019 09:00:11 GMT):
Has joined the channel.

SwapnaliDive (Fri, 29 Nov 2019 06:45:08 GMT):
@rjones Hey, Can we have more detailed document of aries aca-py to setup it locally and run it.

rjones (Fri, 29 Nov 2019 08:55:14 GMT):
@SwapnaliDive ask in #aries please. I don't have any connection to the project other than creating the repo.

george.aristy (Sat, 30 Nov 2019 18:04:12 GMT):
The recording for the last call has not been posted yet.

george.aristy (Sat, 30 Nov 2019 18:31:07 GMT):
@swcurran @tplooker I'm trying to understand the use cases you guys have in mind for `did:key` in DIDComm. Can you guys share your thoughts?

swcurran (Sat, 30 Nov 2019 18:34:51 GMT):
Basically, any place in an RFC where there is a naked public key. I'm not 100% sold on did:key, although after the call Wednesday I'm on board. I do think that at minimum, we need to use multicodecs, so that we have both the key and algorithm in a concise form. But Tobias was pretty convincing to me on the benefits of using did:key.

swcurran (Sat, 30 Nov 2019 18:34:51 GMT):
Basically, any place in an RFC where there is a naked public key. I'm not 100% sold on did:key, although after the call Wednesday I'm more on board. I do think that at minimum, we need to use multicodecs, so that we have both the key and algorithm in a concise form. But Tobias was pretty convincing to me on the benefits of using did:key.

swcurran (Sat, 30 Nov 2019 18:35:23 GMT):
I don't think it will be particularly hard to implement.

george.aristy (Sat, 30 Nov 2019 18:37:06 GMT):
Yes, I definitely think naked keys are nowhere close to ideal. Some encoding mechanism like multicodecs or JWKs should be used (the former preferred due to reduced size).

george.aristy (Sat, 30 Nov 2019 18:37:57 GMT):
What I did not understand was your statement about the other fields of did:key being useful. And you specifically pointed out `keyAgreement`. That alone reminded me of that weird quirk that some implementations are doing.

george.aristy (Sat, 30 Nov 2019 18:38:11 GMT):
I don't understand why we need everything else aside from the key.

george.aristy (Sat, 30 Nov 2019 18:38:48 GMT):
There's also this point about documentation on usage of the key being built into did:key - I'd like to see how/where that is done.

swcurran (Sat, 30 Nov 2019 18:44:58 GMT):
I assume you know about this: https://digitalbazaar.github.io/did-method-key/ @tplooker - do you know where those others would be used? Also, what are your thoughts about the practicality of using both derivations of the keys? Presumably you can start with either and derive the other?

swcurran (Sat, 30 Nov 2019 18:44:58 GMT):
I assume you know about this: https://digitalbazaar.github.io/did-method-key/ @tplooker - do you know where it is documented how each entry in the DIDDoc would be used? Also, what are your thoughts about the practicality of using both derivations of the keys? Presumably you can start with either and derive the other?

george.aristy (Sat, 30 Nov 2019 18:47:06 GMT):
Ah, thank you for that link. All I had to go on was their github repo (https://github.com/digitalbazaar/did-method-key).

george.aristy (Sat, 30 Nov 2019 18:47:13 GMT):
I'll go through their method spec now

george.aristy (Sat, 30 Nov 2019 19:01:42 GMT):
It leaves me with the same questions. :/

swcurran (Sat, 30 Nov 2019 21:07:34 GMT):
Yeah, there's not much about how the entries should be used, just the transformation from the input to the DIDDoc.

tplooker (Sat, 30 Nov 2019 23:25:52 GMT):
@george.aristy which elements of the did:key did document did you find confusing? The keyAgreement section makes it explict that the key defined in the section is appropriate for keyAgreement usage e.g doing ECDH KDF

tplooker (Sat, 30 Nov 2019 23:26:03 GMT):
Which we need for both auth and anon crypt

tplooker (Sat, 30 Nov 2019 23:27:22 GMT):
without being explicit we risk someone using a key inappropriately, for instance if you use ed25519 keys for this purpose without doing the conversion there are potential vulnerabilities

tplooker (Sat, 30 Nov 2019 23:28:31 GMT):
If I was going to create a non-repudiable signature in a did comm message I also need the key defined under the authentication section of the did:key did doc as this is an ed25519 key appropriate for signing

tplooker (Sat, 30 Nov 2019 23:33:03 GMT):
did:key would just be a more formal way of achieving the approach than a raw multi-codec public key, the main thing I wanted to point out was that if we do go with just a raw multi-codex public key, we are creating a new type of identifier and as such it should be appropriately defined.

george.aristy (Tue, 03 Dec 2019 14:01:19 GMT):
@tplooker isn't the Linked Data Crypto Suite Registry supposed to fulfil that same purpose? To document the key's crypto suite and usage?

swcurran (Fri, 20 Dec 2019 23:50:21 GMT):
There are a number of aries rfcs that are not status changes. Is there any reason that they are not being merged? I'm going to do a few that I didn't write and can do those as well, if no one objects or no one else merges those.

kdenhartog (Mon, 06 Jan 2020 04:29:20 GMT):
I went through and was wondering the same thing. Most seemed like they were good to merge. I noticed there were a few status changes and other dated items that are lingering as well.

kdenhartog (Mon, 06 Jan 2020 04:29:34 GMT):
At the very least we can merge and if additional changes are made new PRs can be added.

tplooker (Mon, 06 Jan 2020 04:40:50 GMT):
@george.aristy, im unsure what you mean? if you are referring to the proofPurpose field in a Linked Data proof, that tells you what the key should be authorised with in reference to the "verificationMethod". E.g take the following proof ``` { "@context": "https://www.w3.org/2018/credentials/examples/v1", "title": "Hello World!", "proof": { "type": "Ed25519Signature2018", "proofPurpose": "assertionMethod", "created": "2019-08-23T20:21:34Z", "verificationMethod": "did:example:123456#key1", "domain": "example.org", "jws": "eyJ0eXAiOiJK...gFWFOEjXk" } } ``` This proof states the key identified by `did:example:123456#key1` should appear authorized in the did document retrieved by did:example:123456 for the "assertionMethod" proof purpose authorization is conveyed by the keys membership in the "assertionMethod" array element of the DID document

tplooker (Mon, 06 Jan 2020 04:42:19 GMT):
A DID document conveys both keys and the authority those keys have on behalf of the DID subject

george.aristy (Wed, 08 Jan 2020 15:14:27 GMT):
@tplooker I was referring to how each LD Crypto Suite details how it's intended to be used. This is one of the benefits that proponents of did:key tout, yet we already have this in the form of existing crypto suites (if we accept JSON-LD as a representation for DIDs)

swcurran (Wed, 08 Jan 2020 23:57:52 GMT):
Hey - is there someone that has access to the recordings from Aries WG calls? I recorded today's to the cloud and I don't have access to the recording. Can someone send me the link? @esplinr @TelegramSam @kenebert @nage @burdettadam Thanks!

nage (Thu, 09 Jan 2020 17:12:39 GMT):
@dbluhm ^^^ do you have this access? If not, I would like to figure out how to make sure you get it

dbluhm (Thu, 09 Jan 2020 17:17:17 GMT):
The zoom room is hosted by @TelegramSam's zoom account. He's given me the ability to claim host in meetings but I unfortunately do not have access to the recordings sent to the cloud.

esplinr (Thu, 09 Jan 2020 20:17:45 GMT):
Can Kayla find it?=

esplinr (Thu, 09 Jan 2020 20:17:45 GMT):
Can Kayla find it?

TelegramSam (Thu, 09 Jan 2020 20:41:32 GMT):
I'm uploading the meeting recordings.

TelegramSam (Thu, 09 Jan 2020 20:47:55 GMT):
Uploaded: https://wiki.hyperledger.org/pages/viewpage.action?pageId=24779761

swcurran (Thu, 09 Jan 2020 20:56:32 GMT):
Thanks @TelegramSam ! Welcome back and Happy New Year!

esplinr (Fri, 10 Jan 2020 00:55:24 GMT):
I updated the main Aries Read Me. I sure it can be further improved: https://github.com/hyperledger/aries/pull/11

rjones (Fri, 10 Jan 2020 20:25:36 GMT):
Hi - I ran the dotnet SDK ci script (the docker compose test) in a loop for 119 iterations over a couple of days and I found these tests failed the most: https://github.com/ryjones/atr/blob/master/src/COUNTS

rjones (Fri, 10 Jan 2020 20:26:39 GMT):
this was on a 6 core Mac mini of the most recent vintage, dedicated to the task. I suspect some of these flakes could be disabled.

rjones (Fri, 10 Jan 2020 20:27:14 GMT):
I did this experiment because that test almost always failed in AZP, it works almost always on my laptop, but it never worked on my iMac (which is older).

rjones (Fri, 10 Jan 2020 20:28:10 GMT):
this was the test: https://github.com/ryjones/aries-framework-dotnet/blob/master/ci/docker-compose-test.sh

TelegramSam (Mon, 13 Jan 2020 15:42:09 GMT):
I've merged a change (approved by @danielhardman ) that removes the index generation from the CI tests, per generation via the github action.

danielhardman (Mon, 13 Jan 2020 16:45:50 GMT):
@TelegramSam : can you please give us maintainers a 1-paragraph summary of the change in process we should expect as a result of this change? Do we just cross indexing off our list of worries in all contexts, forever? Or will we get error messages about the index not needing a change, that we should know to ignore, in cases where a PR doesn't introduce an index change?

TelegramSam (Mon, 13 Jan 2020 16:57:26 GMT):
Index generation becomes the concern of the maintainers, not the individual contributors. We should update the github action if we desire it to be different. Right now, if a merge doesn't need an index update, the action 'fails' because the index generated is not different as a result of the merge and cannot be committed. For the time being that can be ignored. An update to the action can handle that case more gracefully.

TelegramSam (Mon, 13 Jan 2020 16:58:12 GMT):
@danielhardman Is that what you were looking for?

danielhardman (Mon, 13 Jan 2020 16:59:13 GMT):
Yes, that's just the clarification that I needed. Should we modify /contributing.md to remove the instruction to update the index?

TelegramSam (Mon, 13 Jan 2020 17:00:00 GMT):
Yes.

kdenhartog (Mon, 13 Jan 2020 23:47:23 GMT):
I'm a bit confused about the implications of this. Does this mean I'll need to update index.md each time we're merging a PR or is the actions handling that?

swcurran (Tue, 14 Jan 2020 00:13:39 GMT):
The actions are handling that. You never need to touch index.md again.

swcurran (Tue, 14 Jan 2020 00:14:02 GMT):
With each merge, the github action will regen and commit a new version of index.md.

kdenhartog (Tue, 14 Jan 2020 02:51:54 GMT):
ok, that's seriously cool! Thanks

kdenhartog (Tue, 14 Jan 2020 04:11:08 GMT):
FYI I added a label "Merge Ready" for when the author feels a PR is ready to be merged. What's peoples thoughts on using this so the author can indicate to maintainers that they'd like it to be merged? If people agree with this, I'll give a short announcement on the afternoon call about it this week.

swcurran (Tue, 14 Jan 2020 15:16:57 GMT):
I like it.

TelegramSam (Thu, 16 Jan 2020 19:00:47 GMT):
Ok, I think I have the index generation action fixed on the RFC repo. It should succeed even if the index had no changes as a result of the PR.

troyronda (Thu, 16 Jan 2020 21:03:28 GMT):
Posted the RFC 334 update: https://github.com/hyperledger/aries-rfcs/pull/383

troyronda (Thu, 16 Jan 2020 21:04:47 GMT):
I wrote a bit more than I had originally in the issue text - hopefully it helps.

swcurran (Thu, 16 Jan 2020 21:19:33 GMT):
Awesome - thanks!

TelegramSam (Thu, 16 Jan 2020 21:35:38 GMT):
So, does anybody here know when branch protection was turned on for the RFC repo?

TelegramSam (Thu, 16 Jan 2020 21:52:38 GMT):
I'm pretty sure the branch protection is what is breaking the auto building index.

rileyphughes (Thu, 16 Jan 2020 22:22:31 GMT):
Has joined the channel.

rjones (Thu, 16 Jan 2020 22:55:31 GMT):
it's usually turned on at repo creation time.

rjones (Thu, 16 Jan 2020 23:21:03 GMT):
@TelegramSam https://gist.github.com/ryjones/bc4cd71f2464c312b25f7a9540152283 shows branch protection was enabled in June 2019

rjones (Thu, 16 Jan 2020 23:21:03 GMT):
@TelegramSam https://gist.github.com/ryjones/bc4cd71f2464c312b25f7a9540152283 shows branch protection was last edited in June 2019

TelegramSam (Thu, 16 Jan 2020 23:40:05 GMT):
Hmm. I wonder why the push is failing then.

rjones (Fri, 17 Jan 2020 00:05:18 GMT):
Line 14 and 15 show it is being rejected. If I had to guess, what we would need to do is make a branch the bot can access

rjones (Fri, 17 Jan 2020 00:07:10 GMT):
Could the bot create a PR? I notice this repo has a bunch of stale branches that probably should have been PRs

TelegramSam (Fri, 17 Jan 2020 06:20:48 GMT):
those were PRs, but are protected branches now, and I can't delete them.

TelegramSam (Fri, 17 Jan 2020 06:21:14 GMT):
I don't really want to create PRs for these autogenerated files....

rjones (Fri, 17 Jan 2020 16:40:00 GMT):
I have another idea.

rjones (Fri, 17 Jan 2020 16:42:09 GMT):
I've applied branch protection to master, directly. You should be able to delete the other branches.

rjones (Fri, 17 Jan 2020 18:08:56 GMT):
In searching around, it looks like the PR pathway is the way to go. https://github.community/t5/GitHub-Actions/Allowing-github-actions-bot-to-push-to-protected-branch/m-p/34454#M1924

rjones (Fri, 17 Jan 2020 18:09:31 GMT):
We might be able to build on this: https://github.com/ridedott/dependabot-auto-merge-action

rjones (Tue, 21 Jan 2020 23:00:31 GMT):
@dbluhm would you be interested in adding `Hyperledger` as an owner to `aries-staticagent-python` on PyPi? I would then add a token and send a PR to update the GitHub action for new releases.

rjones (Tue, 21 Jan 2020 23:01:02 GMT):
https://pypi.org/user/hyperledger/

rjones (Tue, 21 Jan 2020 23:01:02 GMT):
https://pypi.org/user/hyperledger/ s/owner/whatever is appropriate to publish new releases

dbluhm (Tue, 21 Jan 2020 23:02:28 GMT):
Added as maintainer which should be able to publish new releases

rjones (Tue, 21 Jan 2020 23:05:19 GMT):
OK. I replaced the existing secret with the new one. I don't see a reason to rename it.

rjones (Tue, 21 Jan 2020 23:06:03 GMT):
Thank you, @dbluhm

TelegramSam (Wed, 22 Jan 2020 02:32:13 GMT):
unneeded update branches deleted.

TelegramSam (Wed, 22 Jan 2020 05:43:12 GMT):
I'm frustrated at the collission between GitHub Actions and branch protection.

TelegramSam (Wed, 22 Jan 2020 05:44:35 GMT):
For now, it seems that a 2 part strategy is in order: 1. Respond to merge by regenerating the index and pushing it as a PR. Then, 2. Auto merge that PR and deleting the branch it came from.

rjones (Wed, 22 Jan 2020 16:55:54 GMT):
Which is totally how it should be. 😂

TelegramSam (Wed, 22 Jan 2020 18:00:18 GMT):
I disagree for bots.

rjones (Wed, 22 Jan 2020 18:01:32 GMT):
which is why I added the laughing emoji

TelegramSam (Wed, 22 Jan 2020 18:02:37 GMT):
Considering an alternate strategy: have an `autogenerated` branch that isn't subject to the same branch protection rules. The autogeneration checks out that branch, merges in master, runs the generation script, commits the new autogenerated files, and pushes to the `autogenerated` branch. We remove the autogenerated file, and change the links to it to point to the autogenerated branch version.

TelegramSam (Wed, 22 Jan 2020 18:03:06 GMT):
this has slight inspiration from the `gh-pages` branch practice.

TelegramSam (Wed, 22 Jan 2020 18:03:29 GMT):
Thoughts?

rjones (Wed, 22 Jan 2020 18:04:39 GMT):
I think that's a reasonable work-around

TelegramSam (Wed, 22 Jan 2020 18:05:50 GMT):
@danielhardman thoughts?

danielhardman (Wed, 22 Jan 2020 18:06:48 GMT):
I would be okay with that.

TelegramSam (Wed, 22 Jan 2020 18:06:51 GMT):
@rjones what are the branch protection rules in place now? how many reviewers, etc?

rjones (Wed, 22 Jan 2020 18:07:31 GMT):
Branch protection is only applied to `master` at this point. You're free to noodle on other branches

TelegramSam (Wed, 22 Jan 2020 18:07:41 GMT):
right, but what does master have on it?

TelegramSam (Wed, 22 Jan 2020 18:08:04 GMT):
it's frustrating that I can't see a read only version even if I can't change it.

danielhardman (Wed, 22 Jan 2020 18:08:34 GMT):

Screen Shot 2020-01-22 at 11.08.09 AM.png

rjones (Wed, 22 Jan 2020 18:08:58 GMT):
`Require status checks to pass before merging, Require branches to be up to date before merging, DCO, Include administrators`

TelegramSam (Wed, 22 Jan 2020 18:09:28 GMT):
the benefit of maintaining a separate branch is that we avoid all the issues at once.

danielhardman (Wed, 22 Jan 2020 18:09:28 GMT):
Ry gave me permissions on this part, so I can facilitate to some extent.

rjones (Wed, 22 Jan 2020 18:09:45 GMT):
I turned off the `restrict` and re-enabled `DCO` since I only had those settings for trying to work around the bot issue

rjones (Wed, 22 Jan 2020 18:10:32 GMT):
Fabric had a similar issue - they created a GitHub user which they added to the "allow" block to work around it

TelegramSam (Wed, 22 Jan 2020 18:10:41 GMT):
It doesn't feel 'clean' but it feels cleaner than the other options.

TelegramSam (Wed, 22 Jan 2020 18:11:05 GMT):
I imagine there will be future movement around bots and GH Actions because of this conflict.

rjones (Wed, 22 Jan 2020 18:11:20 GMT):
agreed

rjones (Wed, 22 Jan 2020 23:56:12 GMT):
@TelegramSam `git commit --allow-empty -s -m "whatever"` might help your testing

TelegramSam (Thu, 23 Jan 2020 00:09:22 GMT):
argh.

TelegramSam (Thu, 23 Jan 2020 00:09:31 GMT):
bungled a merge and push.

TelegramSam (Thu, 23 Jan 2020 00:09:38 GMT):
this was supposed to stay on my fork for testing.

rjones (Thu, 23 Jan 2020 00:13:58 GMT):
yeah I kind of figured :)

rjones (Thu, 23 Jan 2020 00:14:18 GMT):
considering `GITHUB_TOKEN` isn't defined in `aries-rfcs`

rjones (Thu, 23 Jan 2020 00:55:25 GMT):
@TelegramSam do you want me to roll master back a little?

rjones (Thu, 23 Jan 2020 00:55:49 GMT):
I could do it, but I'm not sure if you would rather to a `git revert`

TelegramSam (Thu, 23 Jan 2020 01:27:03 GMT):
do roll back master.

TelegramSam (Thu, 23 Jan 2020 01:27:05 GMT):
that would help

rjones (Thu, 23 Jan 2020 01:41:33 GMT):
@TelegramSam what exact commit? https://github.com/hyperledger/aries-rfcs

rjones (Thu, 23 Jan 2020 01:41:57 GMT):
https://github.com/hyperledger/aries-rfcs/commit/9867421f46c3e6f174a4db01a49a7cb5dfe32f02 I assume?

rjones (Thu, 23 Jan 2020 01:45:36 GMT):
@TelegramSam done.

rjones (Thu, 23 Jan 2020 01:49:47 GMT):
@TelegramSam I've enabled "one code review required" on master to hopefully stop this from happening again :)

TelegramSam (Thu, 23 Jan 2020 03:01:28 GMT):
Thanks.

TelegramSam (Thu, 23 Jan 2020 03:01:45 GMT):
I was working on my fork, then didn't notice when it switched.

TelegramSam (Thu, 23 Jan 2020 15:29:40 GMT):
PR needs review and merge: this builds in the autogenerated branch bot modification discussed above: https://github.com/hyperledger/aries-rfcs/pull/392

rjones (Thu, 23 Jan 2020 15:31:09 GMT):
@TelegramSam I had one comment

TelegramSam (Thu, 23 Jan 2020 15:32:24 GMT):
facepalmed and fixed.

TelegramSam (Thu, 23 Jan 2020 15:34:33 GMT):
Related Thoughts: Actions need a button to manually run an action. (has been well requested of the actions team) also: Having a draft mode that allows testing of action changes prior to commit would be great.

rjones (Thu, 23 Jan 2020 15:35:15 GMT):
Agreed

TelegramSam (Thu, 23 Jan 2020 15:36:10 GMT):
I tested by mostly screwing up my forked copy of the repo. plan to refork after this works properly to clean up.

TelegramSam (Thu, 23 Jan 2020 15:36:34 GMT):
but forks are not a perfect solution, unless I replicate all the branch protection etc.

TelegramSam (Thu, 23 Jan 2020 17:30:21 GMT):
ARGH.

TelegramSam (Thu, 23 Jan 2020 17:30:24 GMT):
```Push to branch autogenerated remote: Permission to hyperledger/aries-rfcs.git denied to github-actions[bot]. fatal: unable to access 'https://github.com/hyperledger/aries-rfcs.git/': The requested URL returned error: 403```

TelegramSam (Thu, 23 Jan 2020 17:30:44 GMT):
what permissions are set up for the autogenerated branch?

TelegramSam (Thu, 23 Jan 2020 17:40:42 GMT):
@rjones ^

rjones (Thu, 23 Jan 2020 17:51:40 GMT):
None

rjones (Thu, 23 Jan 2020 17:52:24 GMT):
@TelegramSam https://zoom.us/j/2032622322

rjones (Thu, 23 Jan 2020 18:00:57 GMT):
https://help.github.com/en/actions/automating-your-workflow-with-github-actions/creating-and-using-encrypted-secrets

esplinr (Thu, 23 Jan 2020 19:43:19 GMT):
Who is attending the Hyperledger Global Forum? I grabbed us a 10 minute slot to present about the Aries Project. The goal is to "recruit contributors". If you want to present, let me know and I'll substitute your name for mine. https://wiki.hyperledger.org/display/HGF/Projects+Kiosk

BrianRichter (Thu, 23 Jan 2020 19:45:29 GMT):
Has joined the channel.

rjones (Fri, 24 Jan 2020 23:07:33 GMT):
@danielhardman this is the result of an error, @TelegramSam can explain

rjones (Fri, 24 Jan 2020 23:07:33 GMT):
@danielhardman this is the result of an error, @TelegramSam can explain https://github.com/hyperledger/aries-rfcs/pull/385#discussion_r370879736

rjones (Fri, 24 Jan 2020 23:11:26 GMT):
https://github.com/hyperledger/aries-rfcs/pull/385#issuecomment-578337550 is how to fix it

rjones (Fri, 24 Jan 2020 23:21:22 GMT):
broken DCO, as well.

TelegramSam (Tue, 28 Jan 2020 15:30:50 GMT):
I will not be attending. There will be folks from the Sovrin Foundation there.

jljordan_bcgov (Tue, 28 Jan 2020 20:04:03 GMT):
A few of us (BC Gov, ACA-Py) team will be there ... so I am sure we would be happy

esplinr (Tue, 28 Jan 2020 20:06:06 GMT):
Sounds great. We can either work together on the 10 minute presentation, or someone from your team can put your name on the sheet and I can focus on Indy and Ursa. Whichever you prefer.

sheldon.regular (Mon, 03 Feb 2020 18:05:39 GMT):
Has joined the channel.

esplinr (Tue, 25 Feb 2020 22:44:37 GMT):
@MALodder @cam-parra A couple of weeks ago we discussed having you discuss Aries-KMS during the Aries WG A call tomorrow morning. I forgot to remind you during our conversation today. Are you still planning on attending?

MALodder (Tue, 25 Feb 2020 22:44:37 GMT):
Has joined the channel.

esplinr (Tue, 25 Feb 2020 22:45:04 GMT):
I know that you don't have a formal architecture to discuss, but it would be great to discuss your current thinking at the same level as we did today.

esplinr (Tue, 25 Feb 2020 22:45:04 GMT):
I know that you don't have a formal architecture to discuss, but it would be great to discuss your current thinking in the public call at the same level as we did today.

MALodder (Tue, 25 Feb 2020 22:45:30 GMT):
I could but as I was saying today I’m not done yet but I could put something together

MALodder (Tue, 25 Feb 2020 22:47:04 GMT):
Would you want to present what have so far?

esplinr (Tue, 25 Feb 2020 22:47:33 GMT):
Actually, lets postpone to the future meeting (March 11). You'll have more time. But I think it would be great for you to give a couple of minutes update so people understand the direction of your thinking.

esplinr (Tue, 25 Feb 2020 22:50:37 GMT):
@andrew.whitehead We've been discussing how to implement Rich Schemas, and want to clarify how it relates to your work on indy-credx, and what @MALodder has been doing on aries-credx. I would like to make that the focus of our call tomorrow.

esplinr (Tue, 25 Feb 2020 22:52:16 GMT):
Will you be able to attend @andrew.whitehead ?

andrew.whitehead (Tue, 25 Feb 2020 22:54:18 GMT):
Sure, I can make it @esplinr

esplinr (Tue, 25 Feb 2020 22:54:30 GMT):
That will be great. I'm looking forward to the call.

swcurran (Tue, 25 Feb 2020 23:00:23 GMT):
Perhaps also how the Rich Schema work relates to indy-vdr? Updates to the transactions written to/retrieved from the ledger?

TelegramSam (Tue, 24 Mar 2020 19:23:39 GMT):
Can I get a merge on this one? https://github.com/hyperledger/aries-rfcs/pull/442

TelegramSam (Tue, 24 Mar 2020 19:24:40 GMT):
@danielhardman @swcurran ^

danielhardman (Tue, 24 Mar 2020 19:33:10 GMT):

1585078375593.aac

TelegramSam (Tue, 24 Mar 2020 19:33:39 GMT):
Thanks! (Stephen might beat you to it)

swcurran (Tue, 24 Mar 2020 19:33:46 GMT):
I did

TelegramSam (Tue, 24 Mar 2020 19:34:28 GMT):
:thumbsup: Thanks!

kumar89 (Wed, 25 Mar 2020 17:29:34 GMT):
Has joined the channel.

danielhardman (Tue, 31 Mar 2020 22:00:02 GMT):
@swcurran or @TelegramSam : could I get a merge of this PR? I have resolved Kyle's comments about it. https://github.com/hyperledger/aries-rfcs/pull/431 (@kdenhartog, could you change your review to an approved status?)

TelegramSam (Tue, 31 Mar 2020 22:11:54 GMT):
merged.

danielhardman (Tue, 31 Mar 2020 22:32:34 GMT):
Thanks, Sam!

kdenhartog (Wed, 01 Apr 2020 12:42:27 GMT):
Ahh does me requesting changes block the review? If it does, force push with a rebase and you can make all current reviews go stale. I saw yesterday that it got merged (which is when I got back to it). Thanks Sam

kdenhartog (Wed, 01 Apr 2020 12:44:46 GMT):
@swcurran @andrew.whitehead I've seen you guys mention difficulties occuring when ACKs are missing during implementations. Given this is a fundamental question that I always refer to as "reliability guarantees" could I get some of your time on a separate call to discuss this with you? Most recent mention of this was #3 in this comment https://github.com/decentralized-identity/didcomm-messaging/issues/38#issuecomment-606846036

swcurran (Thu, 02 Apr 2020 17:48:38 GMT):
@kdenhartog - yes glad to talk about it. Set up something for later this afternoon our time?

swcurran (Thu, 02 Apr 2020 18:33:20 GMT):
Hey I was looking at the Aries repos. Of the 30 repos, it looks like 13 were created and never used--created in anticipation of an evolution that never happened. I suggest that we delete (not archive) all of them and if and when they are needed in the future, they can be created. Any objections? The list is: - aries-sdk - aries-agent - aries-sdk-python - aries-sdk-go - aries-sdk-dotnet - aries-kms - aries-vdri - aries-core - aries-kms-postgres - aries-ams-sqlite Archived - aries-sdk-ios - indy-vdri-aries - aries-vdri-peer Archived

rjones (Thu, 02 Apr 2020 19:23:55 GMT):
@swcurran let me know when, and I'll do it

kdenhartog (Thu, 02 Apr 2020 20:57:44 GMT):
[ ](https://chat.hyperledger.org/channel/aries-maintainers?msg=H8Q4inMggrxyqwPTb) Just sent out a link

swcurran (Thu, 02 Apr 2020 20:58:59 GMT):
Can we use Zoom instead?

kdenhartog (Thu, 02 Apr 2020 20:59:29 GMT):
yeah preferably, I didn't have a link to include

swcurran (Thu, 02 Apr 2020 21:00:52 GMT):
OK _ i'll send new update

kdenhartog (Thu, 02 Apr 2020 21:01:29 GMT):
Also if @andrew.whitehead would like to join could you add him? I wasn't able to find his email

swcurran (Thu, 02 Apr 2020 21:02:11 GMT):
I'm adding him :-)

swcurran (Thu, 02 Apr 2020 21:02:18 GMT):
Just confirmed he can make it.

swcurran (Fri, 03 Apr 2020 18:48:18 GMT):
Last call on this - anyone care if we eliminate these repos? ``` Hey I was looking at the Aries repos. Of the 30 repos, it looks like 13 were created and never used--created in anticipation of an evolution that never happened. I suggest that we delete (not archive) all of them and if and when they are needed in the future, they can be created. Any objections? The list is: - aries-sdk - aries-agent - aries-sdk-python - aries-sdk-go - aries-sdk-dotnet - aries-kms - aries-vdri - aries-core - aries-kms-postgres - aries-ams-sqlite Archived - aries-sdk-ios - indy-vdri-aries - aries-vdri-peer Archived ```

rjones (Sat, 04 Apr 2020 12:42:07 GMT):
https://github.com/hyperledger/aries-rfcs/issues/460

rjones (Sat, 04 Apr 2020 15:24:48 GMT):
@swcurran one more approval please - there are two repos with non-zero code, but IIRC that code is just copied from elsewhere.

swcurran (Sat, 04 Apr 2020 15:56:21 GMT):
Saw that and will check in a bit. Thanks.

swcurran (Sat, 04 Apr 2020 22:05:04 GMT):
@andrew.whitehead @TelegramSam @dbluhm -- do you think we need the code in this repo? https://github.com/hyperledger/aries-sdk-python

andrew.whitehead (Sat, 04 Apr 2020 22:06:49 GMT):
I think it’s safe to say nobody’s using it

swcurran (Sat, 04 Apr 2020 22:08:10 GMT):
@cam-parra @mattatkiva - do we think we need the code in this repo? https://github.com/hyperledger/aries-kms/ Is this expected to continue to evolve?

mattatkiva (Sat, 04 Apr 2020 22:08:10 GMT):
Has joined the channel.

kdenhartog (Mon, 06 Apr 2020 08:17:06 GMT):
Is anyone else getting automated security notifications for aries packages? In particular I've gotten ones for Aries-framework-javascript, aries-toolbox, and aries-framework-go. Given I don't work in these codebases closely enough, I want to leave it to maintainers to merge PRs so I'm not breaking anything. I'm happy to assist with triaging them if maintainers can assist with merging PRs.

cam-parra (Mon, 06 Apr 2020 14:33:15 GMT):
i believe there is no code in there. Just some directories but yeah this is not expected to grow and can be done away with. But in my opinion this repo should serve as an MVP for a kms

rjones (Mon, 06 Apr 2020 14:52:01 GMT):
I can move it to the hyperledger-archives org if you like, @swcurran

TelegramSam (Mon, 06 Apr 2020 15:26:19 GMT):
There seems to be much more attention at the `*-framework-*` level of things in Aries than the language sdk levels.

TelegramSam (Mon, 06 Apr 2020 15:26:43 GMT):
under that flow, we likely don't need this repo around.

troyronda (Mon, 06 Apr 2020 15:31:46 GMT):
@kdenhartog I also noticed that Dependabot PRs have started. e.g., https://github.com/hyperledger/aries-framework-go/pull/1567

troyronda (Mon, 06 Apr 2020 15:32:16 GMT):
Seems that are okay to merge - https://chat.hyperledger.org/channel/tsc?msg=YMcvXNkCy58BT6Yzj

troyronda (Mon, 06 Apr 2020 15:32:16 GMT):
Seems they are okay to merge - https://chat.hyperledger.org/channel/tsc?msg=YMcvXNkCy58BT6Yzj

rjones (Mon, 06 Apr 2020 15:33:35 GMT):
If you really wanted, you could do a `git commit -s --amend ...` `git push --force-with-lease ...`

troyronda (Mon, 06 Apr 2020 15:33:57 GMT):
I was just going to push the merge button :P.

jramps9 (Tue, 07 Apr 2020 15:50:12 GMT):
Has joined the channel.

jramps9 (Tue, 07 Apr 2020 15:50:13 GMT):
Hello Aries maintainers! 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:

kdenhartog (Fri, 01 May 2020 01:45:20 GMT):
Who maintains the aries-toolbox? I have gotten more notifications about security vulnerabilities and would like to keep them updated. I can commit to handling the security concerns in that PR if no one feels capable of reviewing it who's already a maintainer. Also @swcurran are you guys using this in anyway while demoing ACA-py?

swcurran (Fri, 01 May 2020 01:46:16 GMT):
No, we're not using it to demo.

swcurran (Fri, 01 May 2020 01:50:21 GMT):
You might check with Robert Mitwiki. He's done some cool things with it.

swcurran (Fri, 01 May 2020 01:50:52 GMT):
@mtfk ^^^

mtfk (Fri, 01 May 2020 01:50:52 GMT):
Has joined the channel.

kdenhartog (Fri, 01 May 2020 02:21:34 GMT):
Thanks, I'll work with Sam and Robert then to see what we should do. I suspect at the least @rjones would need to add me to the contributor team on that project so I can merge the security PRs.

rjones (Fri, 01 May 2020 06:17:59 GMT):
@kdenhartog done

rjones (Fri, 01 May 2020 17:13:05 GMT):
@TelegramSam could you take a look at this? https://github.com/hyperledger/indy-agent/pull/132

mtfk (Mon, 04 May 2020 06:42:23 GMT):
hi, this what we did with aries-toolbox is to convert it to the web application for ease of use and use it for purpose of testing and demoing OCA, you can take a look here: https://github.com/thclab/aries if this would be any interest to merge into main repo we are more then happy to provide it. The idea is to continue converting aries-toolbox into more user friendly testing environment.

jramps9 (Wed, 13 May 2020 12:13:14 GMT):
Hello Aries maintainers! 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

george.aristy (Wed, 13 May 2020 20:43:00 GMT):
hello - can somebody help me out with this question? I think there's a distinct possibility I'm missing something obvious: https://github.com/hyperledger/aries-rfcs/issues/476

TelegramSam (Thu, 14 May 2020 21:14:53 GMT):
Is anybody interested in being a maintainer for the Aries Toolbox, and/or the ACA-py toolbox plugin? I have updates, and we have not adjusted maintainers to those still in the industry.

mattatkiva (Fri, 15 May 2020 13:44:36 GMT):
@TelegramSam I can help

TelegramSam (Fri, 15 May 2020 15:04:27 GMT):
@mattatkiva awesome! I'll see about getting you added.

ajayjadhav (Wed, 20 May 2020 15:02:51 GMT):
Hi @TelegramSam - I would also love to help..

rjones (Fri, 22 May 2020 16:57:30 GMT):
Hi - I had a request from Jakub Koci and Ajay Jadhav to be made maintainers of https://github.com/hyperledger/aries-framework-javascript as well as moderators of https://lists.hyperledger.org/g/aries , which would give the ability to schedule meetings and the like. I'd like some guidance from the broader community

rjones (Fri, 22 May 2020 17:02:36 GMT):
@TelegramSam @kdenhartog ^^

danielhardman (Fri, 22 May 2020 17:30:46 GMT):
I didn't even know that lists.hyperledger.org/g/aries existed; I went looking for such a mailing list once, and couldn't find it. So I doubt it's being used. Either that, or I'm woefully behind the times. :-) Re. being maintainers, I see that Jakub has been making contributions there consistently, but that Ajay has only made one, 6 months ago. I don't have any other insight into who would make a good maintainer of the project, so I defer to others who may know more. (Certainly we want people who are active to be maintainers, if they are active in healthy ways. I have no reason to doubt that's the case here. I'm just ignorant.)

ajayjadhav (Fri, 22 May 2020 18:14:49 GMT):
Thanks correct @danielhardman. @jakubkoci has been a major contributor to the repo, my contributions have been mainly on the project roadmap, technical discussions/decisions and reviewing/merging PRs. FYI - https://github.com/hyperledger/aries-framework-javascript/commits?author=jadhavajay

ajayjadhav (Fri, 22 May 2020 18:14:49 GMT):
Thanks correct @danielhardman @jakubkoci has been a major contributor to the repo, my contributions have been mainly on the project roadmap, technical discussions/decisions and reviewing/merging PRs. FYI - https://github.com/hyperledger/aries-framework-javascript/commits?author=jadhavajay

ajayjadhav (Fri, 22 May 2020 18:14:49 GMT):
That is correct @danielhardman @jakubkoci has been a major contributor to the repo, my contributions have been mainly on the project roadmap, technical discussions/decisions and reviewing/merging PRs. FYI - https://github.com/hyperledger/aries-framework-javascript/commits?author=jadhavajay

swcurran (Fri, 22 May 2020 19:44:18 GMT):
I'm good to have Jakub and Ajay onboard and contributing!

esplinr (Fri, 22 May 2020 20:49:51 GMT):
Ajay has also been active in organizing meetings and keeping things organized.

esplinr (Fri, 22 May 2020 20:49:51 GMT):
Ajay has also been active in providing updates in meetings and keeping things organized.

redongjun (Sun, 24 May 2020 06:19:19 GMT):
Has joined the channel.

TelegramSam (Tue, 26 May 2020 15:33:09 GMT):
Agree (late to the game. :)

StevenTCramer (Tue, 02 Jun 2020 14:55:02 GMT):
Has joined the channel.

jramps9 (Tue, 09 Jun 2020 15:53:03 GMT):
Hi Aries maintainers! 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

TelegramSam (Thu, 11 Jun 2020 14:32:59 GMT):
Help needed: We need to add release information to the Aries Quarterly Report: https://wiki.hyperledger.org/display/TSC/2020+Q2+Hyperledger+Aries

TelegramSam (Thu, 11 Jun 2020 14:34:07 GMT):
If you are a code maintainer with releases, please add some entries representing that.

TelegramSam (Thu, 11 Jun 2020 14:34:14 GMT):
examples are here: https://wiki.hyperledger.org/display/TSC/2020+Q2+Hyperledger+Aries

TelegramSam (Thu, 11 Jun 2020 14:34:14 GMT):
examples are here: https://wiki.hyperledger.org/display/TSC/2019+Q4+Hyperledger+Aries

TelegramSam (Thu, 11 Jun 2020 14:35:29 GMT):
@swcurran @troyronda @esplinr ^

swcurran (Thu, 11 Jun 2020 14:42:28 GMT):
When is this due?

TelegramSam (Thu, 11 Jun 2020 14:42:38 GMT):
like a month ago. :/

TelegramSam (Thu, 11 Jun 2020 14:42:53 GMT):
I dropped this particular ball by not getting started earlier.

swcurran (Thu, 11 Jun 2020 14:42:59 GMT):
Ah...I contributed a bunch to the Indy one, but thought this one was an SEP.

rjones (Thu, 11 Jun 2020 14:43:36 GMT):
we could combine them, no?

TelegramSam (Thu, 11 Jun 2020 14:43:42 GMT):
I've mostly managed to do these in the past.

rjones (Thu, 11 Jun 2020 14:43:45 GMT):
maybe "Aries, Indy" report

TelegramSam (Thu, 11 Jun 2020 14:44:31 GMT):
I think that might be bad optically @rjones, for those that are Aries folks but not Indy.

swcurran (Thu, 11 Jun 2020 14:44:32 GMT):
No - best to keep them separate. The division between the projects is become clearly, and is appropriate.

TelegramSam (Thu, 11 Jun 2020 14:45:20 GMT):
I just need to get better at getting it started before due, and asking for community help for update details.

troyronda (Thu, 11 Jun 2020 14:45:45 GMT):
Added aries-framework-go releases.

nage (Thu, 11 Jun 2020 14:46:03 GMT):
I’m not too worried. The employment changes disrupted this go round. We will do better next time.

TelegramSam (Thu, 11 Jun 2020 14:48:33 GMT):
@nage I couldn't find a Q1 report. Did we skip that one also?

nage (Thu, 11 Jun 2020 14:50:43 GMT):
There should be one somewhere...

nage (Thu, 11 Jun 2020 14:51:47 GMT):
https://wiki.hyperledger.org/display/TSC/2020+TSC+Project+Update+Calendar

troyronda (Thu, 18 Jun 2020 19:46:45 GMT):
fyi: mobile binding efforts for aries-framework-go is kicking off here: https://github.com/hyperledger/aries-framework-go/tree/master/cmd/aries-agent-mobile

george.aristy (Mon, 22 Jun 2020 19:40:00 GMT):
@TelegramSam @swcurran i've created the wiki page for the next B call and put the present-proof V2 on the agenda. I hope that's ok :)

george.aristy (Mon, 22 Jun 2020 19:40:14 GMT):
Not sure if we should add it to the "can we close this" game or what

george.aristy (Mon, 22 Jun 2020 19:40:30 GMT):
I'm interested in moving that along :)

swcurran (Tue, 23 Jun 2020 00:25:12 GMT):
Good stuff. Sam and I talked about that earlier today as well, so all good. Great minds... :-)

swcurran (Tue, 23 Jun 2020 00:25:42 GMT):
If you have the JSON-LD things, would really like to get the "registry" elements that parallel the indy ones added.

george.aristy (Tue, 23 Jun 2020 00:32:46 GMT):
We want to add dif's presentation-exchange format. Need to discuss a little more.

swcurran (Tue, 23 Jun 2020 02:46:36 GMT):
Where is that defined? Can you send a link? Have you looked at it vs. the Indy Presentation Request (which is quite rich/powerful).

swcurran (Tue, 23 Jun 2020 02:47:28 GMT):
Do you want to do a presentation (no pun intended) about that?

andrew.whitehead (Tue, 23 Jun 2020 02:48:13 GMT):
... is that a presentation request?

swcurran (Tue, 23 Jun 2020 02:48:21 GMT):
Ouch

tomislav (Tue, 23 Jun 2020 11:41:04 GMT):
I can't think of a pun to follow-up, but I can present a link at your request - https://identity.foundation/presentation-exchange/

swcurran (Tue, 23 Jun 2020 12:43:49 GMT):
Verified

george.aristy (Tue, 23 Jun 2020 13:17:32 GMT):
@swcurran I haven't looked at the Indy Presentation Request. Do you have a link?

george.aristy (Tue, 23 Jun 2020 13:47:10 GMT):
@swcurran just went through the Libindy API for the presentation attachment. My thoughts: * hard to read (it's docu for a rust API) * lacks examples * not clear what non_revoc_interval is * not clear how users can model n-of-m from group 1, n-of-m from group 2, etc., using WQL * a bit curious on the choice of mixing WQL (low layer) with an interoperable format for requesting and issuing presentations (present-proof)

george.aristy (Tue, 23 Jun 2020 13:47:10 GMT):
@swcurran just went through the Libindy API for the presentation attachment. My thoughts: * hard to read (it's docu for a rust API) * lacks examples for requests and their respective responses * not clear what non_revoc_interval is * not clear how users can model n-of-m from group 1, n-of-m from group 2, etc., using WQL * a bit curious on the choice of mixing WQL (low layer) with an interoperable format for requesting and issuing presentations (present-proof)

george.aristy (Tue, 23 Jun 2020 13:47:10 GMT):
@swcurran just went through the Libindy API for the presentation attachment. My thoughts: * hard to read (it's docu for a rust API) * lacks examples for requests and their respective responses * not clear what non_revoc_interval is * not clear how users can model n-of-m from group 1, n-of-m from group 2, etc., using WQL * a bit curious on the choice of mixing WQL (low layer) with an interoperable format for requesting and issuing presentations (semantic layer)

esplinr (Tue, 23 Jun 2020 13:59:45 GMT):
@danielhardman has been doing a lot of work on the Presentation Request format. Is there anything you want to add Daniel?

esplinr (Tue, 23 Jun 2020 14:04:32 GMT):
Any thoughts @sergey.minaev ?

danielhardman (Tue, 23 Jun 2020 16:41:17 GMT):
Actually, I haven't been looking at Presentation Requests (step 1 in proving) so much as at Presentations (step 2). However, @brentzundel has been engaged with DIF on this topic, and I did leave some feedback on DIF's presentation definition format. See https://github.com/decentralized-identity/presentation-exchange/pull/18.

esplinr (Tue, 23 Jun 2020 16:41:45 GMT):
Oh yeah. My mistake. Thanks for clarifying Daniel.

danielhardman (Tue, 23 Jun 2020 16:42:30 GMT):
(I do have opinions on the topic, and I would like people who talk about it to read my PR. It contains a lot of detailed comments about the spec that's taking shape.)

danielhardman (Tue, 23 Jun 2020 16:54:36 GMT):
Here is one other doc, now more than 3 years old, that represents some initial thinking on the topic. It is clearly dated in several ways, but notice its answer to @george.aristy 's answer about how to express boolean choices and m-of-n stuff, and also the way it allows both disclosure and predicates. https://docs.google.com/document/d/117cuMhMF_BLMniyCwnd0cu_Uj5H_45loZiqO1a3Ln7U/edit?usp=sharing

danielhardman (Tue, 23 Jun 2020 16:54:36 GMT):
Here is one other doc, now more than 3 years old, that represents some initial thinking on the topic. It is clearly dated in several ways, but notice its answer to @george.aristy 's question about how to express boolean choices and m-of-n stuff, and also the way it allows both disclosure and predicates. https://docs.google.com/document/d/117cuMhMF_BLMniyCwnd0cu_Uj5H_45loZiqO1a3Ln7U/edit?usp=sharing

swcurran (Tue, 23 Jun 2020 16:56:42 GMT):
Thanks George --- I agree. I've been wanting to get a document that covers all the features of the Indy Presentation Request. Answers to points: * hard to read (it's docu for a rust API) * Yup * lacks examples for requests and their respective responses * Yup * not clear what non_revoc_interval is * This is how the verifier specifies how recent the revocation registry check must be, allowing flexibility in asking for revocation time range. * not clear how users can model n-of-m from group 1, n-of-m from group 2, etc., using WQL * The "names" array allows for that. You can specify multiple names with a single restriction set, and the claims must from a single credential. * a bit curious on the choice of mixing WQL (low layer) with an interoperable format for requesting and issuing presentations (semantic layer) * The need for the prover to determine what credentials can be used to satisfy each claim (or claim set) requires a query of the agent's storage. This is one of the features that is very powerful in the Indy implementation. Something we don't want to lose.

swcurran (Tue, 23 Jun 2020 16:56:42 GMT):
Thanks George --- I agree. I've been wanting to get a document that covers all the features of the Indy Presentation Request. Answers to points: * hard to read (it's docu for a rust API) * *Yup* * lacks examples for requests and their respective responses * *Yup* * not clear what non_revoc_interval is * *This is how the verifier specifies how recent the revocation registry check must be, allowing flexibility in asking for revocation time range.* * not clear how users can model n-of-m from group 1, n-of-m from group 2, etc., using WQL * *The "names" array allows for that. You can specify multiple names with a single restriction set, and the claims must from a single credential. This was recently added (earlier this year)* * a bit curious on the choice of mixing WQL (low layer) with an interoperable format for requesting and issuing presentations (semantic layer) * *The need for the prover to determine what credentials can be used to satisfy each claim (or claim set) requires a query of the agent's storage. This is one of the features that is very powerful in the Indy implementation. Something we don't want to lose.*

swcurran (Tue, 23 Jun 2020 16:56:42 GMT):
Thanks George --- I agree. I've been wanting to get a document that covers all the features of the Indy Presentation Request. Answers to points: - hard to read (it's docu for a rust API) - *Yup* - lacks examples for requests and their respective responses - *Yup* - not clear what non_revoc_interval is - *This is how the verifier specifies how recent the revocation registry check must be, allowing flexibility in asking for revocation time range.* - not clear how users can model n-of-m from group 1, n-of-m from group 2, etc., using WQL - *The "names" array allows for that. You can specify multiple names with a single restriction set, and the claims must from a single credential. This was recently added (earlier this year)* - a bit curious on the choice of mixing WQL (low layer) with an interoperable format for requesting and issuing presentations (semantic layer) - *The need for the prover to determine what credentials can be used to satisfy each claim (or claim set) requires a query of the agent's storage. This is one of the features that is very powerful in the Indy implementation. Something we don't want to lose.*

danielhardman (Tue, 23 Jun 2020 16:57:30 GMT):
(Just to be clear; that last doc I shared is not something I now consider to be a good model. I just offered it because it has some interesting ideas as food for thought.)

danielhardman (Tue, 23 Jun 2020 17:00:55 GMT):
Also to be clear: I'm proud of Indy presentation requests. Despite their shortcomings, they've been solving real problems in a powerful way, for quite a while now. (The non-revoc-interval is a great example of a vital feature that many other attempts haven't tackled yet.) We should fix the flaws, and we should also converge upon / learn from / resemble the DIF work as much as it makes sense, on a timing that makes sense. But we shouldn't feel bad about our first cut.

swcurran (Tue, 23 Jun 2020 17:02:39 GMT):
I agree. The Indy team did an extremely good job on this and "it just works". I've been very nervous about the DIF and CCG work on this as I suspect they will lose key features.

george.aristy (Tue, 23 Jun 2020 17:42:57 GMT):
@danielhardman @swcurran @esplinr @andrew.whitehead @tomislav just in case: I apologize if my thoughts above on Libindy's API gives the impression that I am minimizing the quality of the work product. That was not my intention. I was evaluating it purely in the context as a proposed presentation format for an RFC that's in the works. The Indy project has pushed the boundaries in this space by leaps and bounds thanks to you guys, and i congratulate you and the rest of the team on the outstanding success!

george.aristy (Tue, 23 Jun 2020 17:43:10 GMT):
@swcurran curious - what key features are you worried about?

george.aristy (Tue, 23 Jun 2020 17:47:43 GMT):
@swcurran > - not clear how users can model n-of-m from group 1, n-of-m from group 2, etc., using WQL > - The "names" array allows for that. You can specify multiple names with a single restriction set, and the claims must from a single credential. This was recently added (earlier this year) Does it allow for multiple set memberships? Like, "N of group 1" AND "M of group 2" ?

rjones (Tue, 23 Jun 2020 17:51:37 GMT):
Has left the channel.

swcurran (Tue, 23 Jun 2020 17:54:43 GMT):
No worries George -- didn't interpret it that way. It's something I've been worried about. Specifically things like being able to flexibly convert a request to a credential search; predicates for ZKPs; a focus on proving claims from many credentials vs. proving one full credential (e.g. selective disclosure handling); self-attested claims. Things like that.

TelegramSam (Wed, 24 Jun 2020 14:19:18 GMT):
can I get an RFC merge on this? https://github.com/hyperledger/aries-rfcs/pull/495

danielhardman (Wed, 24 Jun 2020 15:26:49 GMT):
done

jakubkoci (Thu, 25 Jun 2020 15:59:39 GMT):
Hi all. Could we please add @TimoGlastra as a maintainer of the aries-framework-javascript? He actively participates in reviews and can help with merging PRs faster.

TimoGlastra (Thu, 25 Jun 2020 15:59:39 GMT):
Has joined the channel.

TelegramSam (Fri, 26 Jun 2020 19:46:32 GMT):
@rjones ^

rjones (Fri, 26 Jun 2020 19:46:32 GMT):
Has joined the channel.

TelegramSam (Fri, 26 Jun 2020 19:46:50 GMT):
also @rjones, can we turn on issues for https://github.com/hyperledger/aries-acapy-plugin-toolbox ? I don't have the permissions to set that.

rjones (Fri, 26 Jun 2020 22:25:05 GMT):
@TelegramSam https://github.com/hyperledger/aries-acapy-plugin-toolbox/pull/39

JelleFm (Fri, 10 Jul 2020 11:42:41 GMT):
Has joined the channel.

esplinr (Wed, 15 Jul 2020 16:32:27 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 as contributors.

esplinr (Wed, 15 Jul 2020 16:32:27 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 as contributors.

esplinr (Wed, 15 Jul 2020 16:33:44 GMT):
User User_1 added by esplinr.

esplinr (Wed, 15 Jul 2020 16:33:44 GMT):
User User_2 added by esplinr.

pfeairheller (Wed, 15 Jul 2020 17:11:30 GMT):
Hello everyone, nice to meet you. Thanks @esplinr

swcurran (Wed, 15 Jul 2020 17:45:12 GMT):
Very cool - interested in how the interfaces between different ledgers will live happily in an agent. Very helpful work!

george.aristy (Tue, 21 Jul 2020 15:58:29 GMT):
Can anyone here provide an example or two of the sorts of things an agent might send in a `propose-presentation` message?

swcurran (Tue, 21 Jul 2020 18:30:21 GMT):
Basically, it's the same as a presentation-request, but sent to initiate the delivery of a proof (which is a non-obvious use case), or more likely, sent as a reply to a presentation-request as a negotiation.

george.aristy (Tue, 21 Jul 2020 18:32:42 GMT):
@swcurran so the Prover could send a request inside a proposal ?

swcurran (Tue, 21 Jul 2020 18:38:35 GMT):
Yes - the Indy attachment in the 1.0 version is a variation, but in the 2.0 version, it's the same presentation request format.

danielhardman (Fri, 31 Jul 2020 23:06:58 GMT):
Can I get someone to review this PR? https://github.com/hyperledger/aries-rfcs/pull/482 I had in mind that I'd raised this PR 8 weeks ago, but when I mentioned it on a call, people were unfamiliar. I went and worked on it a bit today, and improved it -- but when I pushed, I saw that I actually had raised it back in May. So I guess I forgot to tell anybody about it, and it's just been sitting there this whole time. :-)

swcurran (Fri, 31 Jul 2020 23:20:27 GMT):
We'd like to move this Interop Testing repo into Hyperledger -- https://github.com/bcgov/aries-agent-test-harness `The Aries Agent Test Harness (AATH) is a BDD-based test execution engine and set of tests for evaluating the interoperability of Aries Agents and Agent Frameworks. ` The necessary structure and files are in the repo, and we believe the content is now sufficiently mature to try to attract more contributors and participants. We are actively developing test cases in the repo and have the vast majority of the Aries AIP 1.0 test cases in place. We are working to remove Indy-isms (e.g. focusing on the RFCs not the Indy details) in the test suite with the goal of broadening the applicability of the interop testing capabilities. Any objections to this contribution to Hyperledger?

rjones (Fri, 31 Jul 2020 23:21:01 GMT):
You know how to do it

danielhardman (Fri, 31 Jul 2020 23:25:55 GMT):
I continue to be uneasy about it because I don't like the need to implement an HTTP backchannel for mobile agents, and I don't like the lack of a reference agent to test against; I fear that acapy will become a default reference, and I don't think that default is correct. Moving it into Hyperledger makes it more canonical and makes my own unwillingness to invest in such a backchannel harder to explain. However, have expressed my discomfort, I acknowledge what I said in an earlier conversation on this subject, which is that this is a do-ocracy, and I won't stand in the way of the doers.

darrell.odonnell (Fri, 31 Jul 2020 23:37:57 GMT):
What is your alternative @danielhardman?

darrell.odonnell (Fri, 31 Jul 2020 23:39:24 GMT):
your bootstrap-an-attack-posing-as-a-test is an important vector to deal with. What is an alternate path?

swcurran (Sat, 01 Aug 2020 16:55:19 GMT):
@danielhardman I don't really understand some of what you are saying. Have you taken a look at the test harness recently? Since the discussion in Utah in December, both test approaches have settled on the need for a backchannel. I don't understand how one can do a test suite without a meta driver to manipulate the agents-under-test. I'm not sure why you particularly mentioned a mobile agent, but it's really not clear to me how you would do headless mobile testing without some sort of backchannel. We've not yet investigated it, but we're fairly confident that the path we're taking is more likely to be successful on that front. The purpose of the test harness is to test interoperability vs. conformance, so the concept of a reference agent is not really relevant. Ideally, each project will invest effort into making their framework (and agents) testable using the harness. We now have two more or less complete backchannel implementations with 3 runnable (acapy, aries-framework-dotnet, vcx) frameworks. In doing the second backchannel, we've neutralized the test cases and made sure they focus on the RFC, not on any implementation. As issues are found, we've debated the source - the RFC, the test case, the frameworks - and found satisfactory answers. We're pretty close to AIP 1.0 complete with the test harness, working now on the connectionless presentation request test cases. I am concerned that we are diluting effort with the two approaches and would rather see a focus on interoperability vs. conformance. As you say, it's a do-cracy and we're definitely try to demonstrate by doing.

danielhardman (Mon, 03 Aug 2020 15:32:26 GMT):
I'm not down on backchannels; the original RFC about a testing strategy includes that concept, and the older aries agent test suite includes that concept as well. What I'm down on is a *RESTful* backchannel modeled around acapy's preconceptions of what an agent's RESTful interface should be like, as a requirement for every agent under test. I know that's a natural fit for acapy, but not every agent has a goal of exposing a RESTful interface. Mobile agents are message processors, not web services. Same for most static agents. The least common denominator for agents is message processing and protocols. Therefore the backchannel should be a protocol, to avoid requiring every agent in the ecosystem to build and maintain a RESTful interface to be testable. Adapting the backchannel to an http transport would be a piece of cake; that can be done once, generically, for all agents. Instead we've introduced a new requirement on agents -- not just a requirement for a new feature (which is what support for a test backchannel protocol would be) -- but a requirement for an entirely different type of technology.

danielhardman (Mon, 03 Aug 2020 15:33:11 GMT):
If aries agent test harness proposed to test agents over a protocol, I would be a supporter.

danielhardman (Mon, 03 Aug 2020 15:37:50 GMT):
@darrell.odonnell : regarding an alternative, I wanted a compliance test suite, not a paired interop test harness. So the alternative I was most interested in was aries agent test suite, which predates the test harness that Stephen is now advocating. I do see the value in pairwise interop testing, and I could live with a shift to interop as the emphasis, but I strongly dislike the RESTfulness of the harness. For Connect.Me and similar agents, we have to artificially construct interfaces that have no rational relationship to the way the agent actually works. For Evernym's Verity, we actually do have a RESTful interface, but it has to be adapted pretty significantly to conform to the test harness. The net result is that we pay an ongoing, obnoxious tax to evaluate interop. If we modeled the backchannel as a protocol, the tax would be minor and result in simple, clean code that had little maintenance cost.

danielhardman (Mon, 03 Aug 2020 15:40:25 GMT):
The frustrating thing to me is that all the work BCGov is donating to this effort is not decreasing my ongoing tax, even one little bit. Rather, we are just building up a tech debt that Evernym has to pay off to make its code evaluatable as an interop target.

swcurran (Mon, 03 Aug 2020 18:50:27 GMT):
We (Ian) added a RESTful interface for VCX in a day. Getting it working was pretty easy. Extending it to cover all the test cases is more work. We did a bounty for aries-framework-dotnet for $25k CDN and we have a RESTful backchannel that covers all the cases through connection and issuing. Further, mobile agent's aside, if your framework does not have a REST mechanism, I'd guess that's it's not going to be very successful. I'm not understanding your "ongoing, obnoxious tax" comment. Testing is not free - you have to put effort in. Yes, you have to build some infrastructure (in this case and in every case), but once there, extending to cover more test cases is an incremental cost with a corresponding incremental benefit. To date, "interop testing" has been humans trying it out and sending a message on rocketchat. That approach is an "onging, obnoxious tax" as well. I'd rather have a test suite that I can integrate into our pipeline. So far, only IBM and BC Gov have seemed to have put any effort (based on open source commits) into interop testing in the Aries community. Pushing this repo to Hyperledger is a way to get

esplinr (Mon, 03 Aug 2020 22:02:41 GMT):
Evernym has contributed significantly to the Aries Protocol Test Suite.

esplinr (Mon, 03 Aug 2020 22:03:13 GMT):
As well as in real-world interop including submissions to other code basis to complete end-to-end interoperability.

esplinr (Mon, 03 Aug 2020 22:03:13 GMT):
As well as in real-world interop testing including submissions to other code basis to complete end-to-end interoperability.

esplinr (Mon, 03 Aug 2020 22:03:13 GMT):
As well as hands on interop testing including submissions to other code basis to complete end-to-end interoperability.

esplinr (Mon, 03 Aug 2020 22:04:07 GMT):
"mobile agent's aside" is the sticky part of this. That's a large part of the ecosystem that is being discounted in this approach.

swcurran (Mon, 03 Aug 2020 22:10:51 GMT):
@esplinr - there are no commits from anyone in Evernym to the APTS. Sounds like I missing where work is being done?

swcurran (Mon, 03 Aug 2020 22:31:48 GMT):
Agreed that mobile testing is still TBD. I have only the vaguest views of how mobile app testing works, but not guess that either approach is better.

swcurran (Mon, 03 Aug 2020 22:33:11 GMT):
Sounds like Evernym is not a fan of moving this repo to Hyperledger. Anyone else objecting to the idea?

danielhardman (Tue, 04 Aug 2020 00:22:45 GMT):
>"if your framework does not have a REST mechanism, I'd guess it's not going to be very successful" This statement reveals a very strong enterprise software assumption. Mobile app front ends don't have REST mechanisms -- and they count among their category some of the most successful pieces of software on the planet. >"We (Ian) added a RESTful interface for VCX in a day. Getting it working was pretty easy" Of course it was -- because you were calling VCX hosted on a server. A smart web dev like Ian can do a naive wrapper of nearly any functionality hosted on a server inside a RESTful interface in a day. That's not the challenge. The challenge is that every agent has to write and maintain their own adapter, and if the agent isn't natively RESTful, that means doing an entirely different type of development from the agent codebase's inherent paradigms. If this codebase becomes a standard tool, it will mean every agent developer in the Aries ecosystem not only has to do DIDComm, but also has to do REST, because their software can't be meaningfully evaluated for interop unless they also do RESTful. Of course ACAPY doesn't see this tax because it's oriented toward this style already. Interop shouldn't be a function of RESTful; it should be a function of DIDComm. It's DIDComm functionality, after all, that we're trying to evaluate here. The fact that acapy wants to expose a RESTful controller is great and natural. Evernym's Verity product does the same. But requiring all agents to do so is unreasonable. I am not at all opposed to evaluating interop through HTTP; it's just the notion of RESTful backchannel that I consider an obnoxious dependency.

darrell.odonnell (Tue, 04 Aug 2020 00:39:18 GMT):
When is the next Aries maintainer call? Wednesday 3-4:30 pm EDT is what I see. I can only make the first hour but this may be a good topic to discuss. Things are getting a bit heated here and I think there is a middle ground that can be found that is valuable. Both Stephen and Daniel are making good points but we clearly haven't landed.

swcurran (Tue, 04 Aug 2020 01:56:23 GMT):
Sorry I wasn't being clear. Testing a framework is different from testing a mobile app, and verifying the framework upon which the mobile app is made the first step in testing the mobile app.

swcurran (Tue, 04 Aug 2020 02:07:05 GMT):
> Interop shouldn't be a function of RESTful; it should be a function of DIDComm. It's DIDComm functionality, after all, that we're trying to evaluate here. The fact that acapy wants to expose a RESTful controller is great and natural. Evernym's Verity product does the same. But requiring all agents to do so is unreasonable. This statement seems to be missing the point of Aries Agent Test Harness. No framework or agent has to speak HTTP to be used with AATH. Neither VCX nor aries-framework-dotnet support HTTP and yet they work with AATH. What is needed is a wrapper around the "component under test" (whatever that is) that speaks HTTP to the test suite and translates commands to something the component under test can understand -- using whatever mechanism works. Success of the test cases is about the DIDComm protocols that are executed, not about the HTTP interface. As Darrell notes, we're not getting very far here. We appear to fundamentally disagree on what is the best approach to conducting interop testing. Happy to talk about this on the Aries WG call this week if others think it would be useful.

esplinr (Tue, 04 Aug 2020 13:09:49 GMT):
We do fundamentally disagree, and it is a valuable discussion. But as Daniel said earlier, Evernym is not going to "stand in the way of doers". We appreciate the efforts that the BC.gov team is putting into the project, and we do not oppose moving the repo to Hyperledger. But we need to be cautious about the confusion we create between the two test suites and we hope that we can resolve the different approaches.

esplinr (Tue, 04 Aug 2020 13:11:09 GMT):
Artem collaborated with Daniel and Adam on the design of the backchannel, which included this closed PR: https://github.com/hyperledger/aries-protocol-test-suite/pull/20/files

esplinr (Tue, 04 Aug 2020 13:13:39 GMT):
But we also contributed a PR to ACAPY to assist with interop: https://github.com/hyperledger/aries-cloudagent-python/commit/44ed4afb0eb6a68a193c4ac7b1b0d2030a779ce4

esplinr (Tue, 04 Aug 2020 13:13:46 GMT):
A small commit that took a lot of testing to figure out.

esplinr (Tue, 04 Aug 2020 13:14:14 GMT):
Our testing also led to a suggested change in Aries Framework Dot Net that we submitted directly to Tomislav.

esplinr (Tue, 04 Aug 2020 13:15:01 GMT):
We don't mind working in the background, but it means people sometimes forget that we are helping move the project forward toward our common goals.

danielhardman (Tue, 04 Aug 2020 16:11:17 GMT):
I don't think this is a profitable conversation to have in the community. We already had it at the last agent hackathon, and now we've re-had it over chat. Let's just move the repo and let Stephen and crew move ahead. My purpose in bringing up dissonance was not to stop that move -- just to note that today, I am not aligned with its philosophy and do not endorse it as the blessed interop testing strategy for the Aries community. That does not mean it can't be an Aries repo. If that's the narrow decision under discussion, there's no "no" vote. And even if there *were* a "no" vote the larger question of whether this should be the community's interop tool, one "no" vote doesn't decide an election. I'm perfectly willing to be outvoted.

danielhardman (Tue, 04 Aug 2020 16:11:17 GMT):
I don't think this is a profitable conversation to have in the community. We already had it at the last agent hackathon, and now we've re-had it over chat. Let's just move the repo and let Stephen and crew move ahead. My purpose in bringing up dissonance was not to stop that move -- just to note that today, I am not aligned with its philosophy and do not endorse it as the blessed interop testing strategy for the Aries community. That does not mean it can't be an Aries repo. If that's the narrow decision under discussion, there's no "no" vote. And even if there *were* a "no" vote for the larger question of whether this should be the community's interop tool, one "no" vote doesn't decide an election. I'm perfectly willing to be outvoted.

ianco (Tue, 04 Aug 2020 17:37:37 GMT):
Has joined the channel.

pknowles (Wed, 05 Aug 2020 07:37:43 GMT):
Has joined the channel.

george.aristy (Wed, 05 Aug 2020 18:58:58 GMT):
Is the LF new signin working for you folks?

rjones (Wed, 05 Aug 2020 19:00:02 GMT):
no, there is an outage right now

rjones (Wed, 05 Aug 2020 19:04:19 GMT):
@george.aristy https://status.linuxfoundation.org/

swcurran (Thu, 06 Aug 2020 16:51:50 GMT):
@rjones @WadeBarnes --- can the two of you add to your list to move the https://github.com/bcgov/aries-agent-test-harness and https://github.com/bcgov/indy-node-monitor repos to Hyperledger? @andrew.whitehead -- I know that indy-node-monitor is currently still based on a published BC Gov docker image. Is there an ETA on getting that moved ahead to remove the need for that? I think it is OK that happen in hyperledger vs. BC Gov, but wanted to be sure there was an awareness of the issue.

andrew.whitehead (Thu, 06 Aug 2020 16:55:07 GMT):
It just needs a published python (wheel) package, but that would require github actions to build it for a few platforms. I suppose it could be built manually and published for 'manylinux

WadeBarnes (Thu, 06 Aug 2020 16:55:31 GMT):
@swcurran, already on my list.

rjones (Thu, 06 Aug 2020 19:12:30 GMT):
OK, let me know when you want to do the transfer

rjones (Thu, 06 Aug 2020 19:13:45 GMT):
You guys close to BC should know that Wade is sitting on a cache of rare poker chips, when in person stuff starts back up

WadeBarnes (Thu, 06 Aug 2020 19:27:16 GMT):
That was supposed to be a surprise, only John knew. Lol. Cats’ out of the bag.

WadeBarnes (Thu, 06 Aug 2020 19:29:11 GMT):

IMG_8354.HEIC

swcurran (Thu, 06 Aug 2020 20:35:51 GMT):
Does anyone other than @TelegramSam have access to the Aries WG Recordings? I'd like to get the recording from yesterday posted. Thanks!

rjones (Thu, 06 Aug 2020 22:29:04 GMT):
@swcurran who recorded it?

esplinr (Thu, 06 Aug 2020 23:08:56 GMT):
I have access to the recordings for Aries WG A, but Robert has been really good at posting them. I do not have access to the recordings for Aries WG B.

WadeBarnes (Fri, 07 Aug 2020 16:55:37 GMT):
@rjones, [bcgov/indy-node-monitor](https://github.com/bcgov/indy-node-monitor) is ready for transfer. You've been added to the repo.

rjones (Fri, 07 Aug 2020 17:23:25 GMT):
done

swcurran (Fri, 07 Aug 2020 17:29:27 GMT):
It was automagically recorded - turned at the start of the meeting.

esplinr (Fri, 07 Aug 2020 20:38:49 GMT):
Is Sam's Zoom account still part of the Sovrin Foundation org? Maybe Kayla has access?

swcurran (Fri, 07 Aug 2020 22:03:27 GMT):
I'll try that. I had assumed a Hyperledger account was being used, but perhaps not.

swcurran (Fri, 07 Aug 2020 22:06:14 GMT):
Not on the Sovrin account.

swcurran (Fri, 07 Aug 2020 22:54:56 GMT):
Nice

esplinr (Sat, 08 Aug 2020 00:09:53 GMT):
Sorry, I'm out of ideas.

jakubkoci (Mon, 10 Aug 2020 12:09:24 GMT):
Hi. I have a question regarding test environment on CI server. I added some test to features using Indy pool into Aries JS framework. Is there any pool already running for the tests running on CI? We're using Azure DevOps pipelines, but it was set up by @rjones so I don't know much details about it. I'm not sure if it's good idea to run our own Indy pool via docker within the pipeline.

rjones (Mon, 10 Aug 2020 16:17:29 GMT):
Hi how can I help?

rjones (Mon, 10 Aug 2020 16:23:04 GMT):
There is no long term pool running.

rjones (Mon, 10 Aug 2020 16:23:27 GMT):
All CI infra is disposed of at the end of the run

swcurran (Mon, 10 Aug 2020 16:35:29 GMT):
What about using a ledger running else where in public -- e.g. one of the BCovrin sandbox ledgers? To work, the DIDs created would have to be random vs. fixed, which might be a problem.

andrew.whitehead (Mon, 10 Aug 2020 16:36:38 GMT):
indy-vdr has integration tests that run a test ledger using github actions, FYI

esplinr (Mon, 10 Aug 2020 17:28:29 GMT):
This purpose is why Sovrin BuilderNet exists.

rjones (Mon, 10 Aug 2020 17:56:48 GMT):
what can we (LF) do to help transition all of the CI/CD stuff to GitHub Actions or Azure?

TelegramSam (Mon, 10 Aug 2020 23:18:01 GMT):
I've posted it. Right now, the meeting is tied to my personal (paid) zoom account because that required the least amount of change.

TelegramSam (Mon, 10 Aug 2020 23:18:14 GMT):
I'm open to adjusting that if needed.

swcurran (Mon, 10 Aug 2020 23:51:45 GMT):
Nope -- all good. Thanks for posting.

jramps9 (Tue, 11 Aug 2020 00:07:33 GMT):
Hello Aries maintainers! 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

jakubkoci (Wed, 12 Aug 2020 20:04:19 GMT):
Thanks, Richard that's a good tip. I didn't think about BuilderNet in this way. I give it a try at least for now, not sure if it's good for the long term. Then it would be better something that Stephen suggested.

jakubkoci (Wed, 12 Aug 2020 20:09:55 GMT):
I'll look at it thanks :thumbsup:

kdenhartog (Mon, 17 Aug 2020 00:27:04 GMT):
Here's a good set of notes I found from Secure Scuttlebutt that goes in depth into many of their new design decisions they're making. Of note, they highlight the tradeoffs where groups have a hard time working with current cryptographic schemes with current best practices (perfect forward secrecy, post compromise security) https://github.com/ssbc/envelope-spec/pull/19/files @danielhardman I'd think you'd be interested in this to see if we want to take different tradeoffs to get groups working

TelegramSam (Mon, 17 Aug 2020 16:59:39 GMT):
I cross posted that to the DIF DIDComm WG as well.

TelegramSam (Tue, 18 Aug 2020 13:57:41 GMT):
I'm presenting on the status of Aries on the CCG today. Any particular points you wish me to mention.

brentzundel (Tue, 18 Aug 2020 14:09:09 GMT):
I think the work on the interop profiles will definitely be interesting to them.

danielhardman (Tue, 18 Aug 2020 14:52:34 GMT):
I agree on interop profiles. Also, you might talk about the recent work to combine DIF's presentation definitions with Aries RFC 0037.

swcurran (Tue, 18 Aug 2020 15:04:11 GMT):
It's actually with the v2 issue and presentation RFCs

troyronda (Mon, 31 Aug 2020 22:39:31 GMT):
We have pushed a new release for aries-framework-go (v0.1.4): https://github.com/hyperledger/aries-framework-go/releases/tag/v0.1.4

troyronda (Mon, 31 Aug 2020 22:39:31 GMT):
We have pushed a new release for aries-framework-go (v0.1.4). Release notes: https://github.com/hyperledger/aries-framework-go/releases/tag/v0.1.4

mtfk (Mon, 07 Sep 2020 11:22:50 GMT):
Hi guys, I am looking for high level Aries architecture which I think was once presented by @danielhardman and was discussed couple of times. The architecture which touched on the plug and play modules in aries ecosystem e.g. having diffrent did resolvers, different network resolvers etc..

mtfk (Mon, 07 Sep 2020 11:23:48 GMT):
We are planning to extend aries toolbox and aca-py with possibility to play nicely with different types of credentials e.g. w3c data model, not sure if there is already any work done towards that, maybe @swcurran you know about some efforts?

danielhardman (Mon, 07 Sep 2020 15:43:53 GMT):
@mtfk - you may be thinking of these slides? https://docs.google.com/presentation/d/1L5L4QcZOATrn9rj4bEMmlbvij9XWyqgQRoWO-HNiUGw/edit

mtfk (Mon, 07 Sep 2020 18:16:06 GMT):
exactly, thanks I lost it when I moved to new gmail account.

mtfk (Mon, 07 Sep 2020 18:16:16 GMT):
Is there any progress on that work?

swcurran (Mon, 07 Sep 2020 18:18:24 GMT):
@mtfk -- ACA-Py has some JSON-LD credentials code done by @TelegramSam for SICPA. The code does not use the RFCs 0036 and 0037 Credential Exchange (but should).

swcurran (Mon, 07 Sep 2020 18:19:15 GMT):
https://github.com/hyperledger/aries-cloudagent-python/pull/540

mtfk (Mon, 07 Sep 2020 18:42:56 GMT):
Is this implementation compatible with W3C Data model?

andrew.whitehead (Tue, 08 Sep 2020 01:07:59 GMT):
I believe it is, but it’s up to the controller to assemble and deliver the credential currently, aca-py just signs it, and it can’t be revoked

swcurran (Tue, 08 Sep 2020 02:15:13 GMT):
It was done as part of the DHS work and so yes w3c data model. No zkp or selective disclosure.

mtfk (Tue, 08 Sep 2020 11:22:59 GMT):
perfect thanks a lot for info. We would make the way with it to the aries toolbox

mtfk (Tue, 08 Sep 2020 11:22:59 GMT):
perfect thanks a lot for info. We would make the way with it to the aries toolbox if is not yet there

jramps9 (Mon, 14 Sep 2020 17:36:29 GMT):
Hello Aries Maintainers! 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

george.aristy (Wed, 16 Sep 2020 19:44:51 GMT):
@swcurran @TelegramSam sorry I cannot attend the call today - things are hectic around here

swcurran (Wed, 16 Sep 2020 19:55:03 GMT):
Join the club! :-)

TelegramSam (Thu, 17 Sep 2020 15:02:33 GMT):
Attendance was so oddly low that we deferred to next week.

rjones (Thu, 17 Sep 2020 15:27:20 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

troyronda (Wed, 30 Sep 2020 13:13:02 GMT):
We have been chatting about the repository structure for aries-framework-go. One of the topics that @pfeairheller brought up is where to place the pluggable add-ons/extensions such as the Indy VDR and additional storage backends that meet the aries-framework-go Golang interface.

troyronda (Wed, 30 Sep 2020 13:15:07 GMT):
https://chat.hyperledger.org/channel/aries-go?msg=WDaNydxJprZjoDn4D

troyronda (Wed, 30 Sep 2020 20:21:24 GMT):
https://chat.hyperledger.org/channel/aries-go?msg=tAFwjAzFYhMtBkiNj

troyronda (Thu, 01 Oct 2020 14:26:28 GMT):
https://chat.hyperledger.org/channel/aries-go?msg=3DjjiBkPTCpZx88zr

danielhardman (Tue, 06 Oct 2020 22:45:22 GMT):
Can I get someone to approve this minor editorial PR? I just fixed some broken hyperlinks in the protocol template at the root of the repo, and made sure that tag values on RFCs were also hyperlinks... https://github.com/hyperledger/aries-rfcs/pull/549

rjones (Tue, 06 Oct 2020 23:00:44 GMT):
if you want, you could enable `mergify` for your repos. it lets committers automate cherry picks, merges, and the like

rjones (Tue, 06 Oct 2020 23:02:29 GMT):
https://github.com/hyperledger/fabric/blob/master/.mergify.yml as an example

danielhardman (Wed, 07 Oct 2020 02:01:59 GMT):
Can I have a few minutes on Wednesday's B call to socialize this? https://github.com/hyperledger/aries-rfcs/pull/550

TelegramSam (Wed, 07 Oct 2020 12:55:12 GMT):
On the agenda.

troyronda (Wed, 07 Oct 2020 15:01:49 GMT):
@rjones could you please create the aries-framework-go-ext repository?

rjones (Wed, 07 Oct 2020 15:24:59 GMT):
what permissions and the like

m00sey (Wed, 07 Oct 2020 15:25:47 GMT):
sorry if I am late to go-ext discussion, what's the plans for build/test etc?

m00sey (Wed, 07 Oct 2020 15:26:19 GMT):
codecov and the like, ideally per sub "project"? or over arching?

troyronda (Wed, 07 Oct 2020 15:39:07 GMT):
@m00sey per module in the extension monorepo.

m00sey (Wed, 07 Oct 2020 15:39:22 GMT):
+1

m00sey (Wed, 07 Oct 2020 15:39:22 GMT):
+1, thanks

troyronda (Wed, 07 Oct 2020 15:40:59 GMT):
@pfeairheller ^^

rjones (Wed, 07 Oct 2020 15:42:07 GMT):
troy: I set up https://github.com/hyperledger/aries-framework-go-ext/ but I need a little more info from you

rjones (Wed, 07 Oct 2020 15:43:03 GMT):
This is the only person with a commit bit: https://github.com/orgs/hyperledger/teams/aries-sdk-go-committers/members

troyronda (Wed, 07 Oct 2020 15:43:42 GMT):
@rjones should be https://github.com/orgs/hyperledger/teams/aries-framework-go-committers/members

troyronda (Wed, 07 Oct 2020 15:44:00 GMT):
But ideally we could add additional people to this ext repo.

rjones (Wed, 07 Oct 2020 15:44:13 GMT):
sure. Do you want a new group?

troyronda (Wed, 07 Oct 2020 15:44:20 GMT):
that would be awesome, thanks.

rjones (Wed, 07 Oct 2020 15:48:38 GMT):
ok, you're a maintainer of https://github.com/orgs/hyperledger/teams/aries-framework-go-ext-committers/members , go for it

troyronda (Wed, 07 Oct 2020 15:49:06 GMT):
@rjones thanks much!

rjones (Wed, 07 Oct 2020 16:33:14 GMT):
Should I update aries-b call with the new Zoom information, to match aries-a call?

pfeairheller (Wed, 07 Oct 2020 16:56:43 GMT):
Thanks @troyronda . Just got back from lunch. I'll catch up in a few

troyronda (Fri, 09 Oct 2020 13:51:32 GMT):
FYI: discussions are going in #aries-go about the aries-framework-go BBS+ signature suite implementation.

rjones (Tue, 13 Oct 2020 15:00:50 GMT):
Hi, all. I've been asked by @PatrikStas to work on https://wiki.hyperledger.org/display/indy/2020-09-29+Indy+Contributors+Call the `aries-vcx-rs` part. Is this a new, blank repo I need to create?

PatrikStas (Tue, 13 Oct 2020 15:00:50 GMT):
Has joined the channel.

rjones (Tue, 13 Oct 2020 15:04:42 GMT):
@swcurran ?

esplinr (Tue, 13 Oct 2020 16:03:28 GMT):
@rjones I'm not sure whether it is better to start as a blank repo, or to migrate the repo currently being maintained by the Absa team. @PatrikStas what do you think?

rjones (Tue, 13 Oct 2020 16:26:02 GMT):
With a blank repo, there won't be any DCO issues :)

swcurran (Tue, 13 Oct 2020 16:27:35 GMT):
But all the contributions references are lost. I would only do that if there were unsolvable DCO issues.

swcurran (Tue, 13 Oct 2020 16:28:38 GMT):
I question the name. I was thinking this was going to be aries-framework-rs. Not the case?

rjones (Tue, 13 Oct 2020 16:39:54 GMT):
just let me know what you want :)

jramps9 (Wed, 14 Oct 2020 14:06:59 GMT):
Hello Aries Maintainers! 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

esplinr (Wed, 14 Oct 2020 18:26:27 GMT):
I'm fine with whatever name you and @PatrikStas and team agree.

esplinr (Wed, 14 Oct 2020 18:26:34 GMT):
@sergey.minaev Do you have any concerns with naming?

esplinr (Wed, 14 Oct 2020 18:26:34 GMT):
@sergey.minaev Do you have any concerns with the naming of the LibVCX repo?

PatrikStas (Thu, 15 Oct 2020 11:45:01 GMT):
@esplinr @rjones @swcurran I would like to port Absa's repo if possible. As for the name, I am fine with both `aries-framework-rs` or `aries-vcx-rs`, I don't have strong opinion. I see pros and cons for both - historically term `vcx` has been around for a while so it already sounds familiar, signalling that `aries-vcx-rs` is continuation of that, on the other hand `aries-framework-rs` is probably simply cleaner, easier to understand.

PatrikStas (Thu, 15 Oct 2020 12:13:52 GMT):
Discussing this with team, we'd rather go for `aries-framework-rs` - seems to be consistent with other hyperledger aries projects (`aries-framework-go/js/dotnet`), also it signals brand new start of the project as opposed to old libvcx which used to contain non-aries protocols.

rjones (Thu, 15 Oct 2020 17:15:07 GMT):
@PatrikStas OK, great: please transfer the repo to my github account (ryjones) and I will put it in place

rjones (Thu, 15 Oct 2020 21:41:06 GMT):
@PatrikStas @mirgee I disabled a bunch of the CI checks for https://github.com/hyperledger/aries-framework-rs/ because they need set up again after the repo move.

mirgee (Thu, 15 Oct 2020 21:41:06 GMT):
Has joined the channel.

rjones (Thu, 15 Oct 2020 21:42:12 GMT):
you both have the power to go here: https://github.com/hyperledger/aries-framework-rs/settings/branch_protection_rules/16958607 and change them once they're working again

danielhardman (Fri, 16 Oct 2020 00:53:39 GMT):
@TelegramSam @swcurran @george.aristy I've raised a PR with a proposed update to the Feature Discovery protocol that allows an agent to discover not just protocols, but goal codes, decorators, crypto suites, etc. Would love feedback: https://github.com/hyperledger/aries-rfcs/pull/557

PatrikStas (Fri, 16 Oct 2020 17:28:12 GMT):
Fyi for anyone interested in joining, we now have channel #aries-framework-rust

PatrikStas (Wed, 21 Oct 2020 13:07:34 GMT):
@rjones and others, we would like to suggest renaming `aries-framework-rs` to `aries-vcx` - it's almost revert to the originally considered option `aries-vcx-rs`, but without the `rs`. The reason is that as the library isn't necessarily rust-only but contains wrappers for java, ios, nodejs (and unmaintaned python). So we realized putting Rust language reference is misleading, it also makes naming of wrapper packages awkward (for example having NodeJS wrapper `aries-framework-rs` is bit weird). Removing the `rs` part from `aries-framework-rs` would make the name too general.

PatrikStas (Wed, 21 Oct 2020 13:08:57 GMT):
Sorry for changing thoughts on this, hopefully it's still early enough to make this change if community agrees.

troyronda (Wed, 21 Oct 2020 14:13:55 GMT):
FYI - aries-framework-go also contains bindings (go, mobile, wasm + js, rest).

troyronda (Wed, 21 Oct 2020 14:13:55 GMT):
FYI - aries-framework-go also contains wrappers/bindings (go, mobile, wasm + js, rest).

troyronda (Wed, 21 Oct 2020 14:14:48 GMT):
@PatrikStas

troyronda (Wed, 21 Oct 2020 14:16:40 GMT):
Also npm package: https://github.com/hyperledger/aries-framework-go/packages/123279 and docker image: https://github.com/hyperledger/aries-framework-go/packages/69982

PatrikStas (Wed, 21 Oct 2020 15:55:11 GMT):
Oh interesting didn't know that! However it doesn't change my mind, if possible I would still like to proceed with change to `aries-vcx`

rjones (Wed, 21 Oct 2020 16:10:49 GMT):
I don't have an opinion. Tell me what you want.

rjones (Wed, 21 Oct 2020 16:14:50 GMT):
@PatrikStas submit a PR and change this file: https://github.com/hyperledger/aries-framework-rs/blob/master/.github/settings.yml line 6 to what you want

PatrikStas (Thu, 22 Oct 2020 09:52:37 GMT):
Thanks, I did however my colleague happened to merged it already. So the repo name is now changed to `aries-vcx`. Could you please also update our rocketchat channel name to `aries-vcx`?

george.aristy (Wed, 28 Oct 2020 15:12:06 GMT):
@swcurran @TelegramSam I will likely miss today's weekly meeting due to a scheduling conflict

troyronda (Wed, 28 Oct 2020 15:18:49 GMT):
aries-framework-go has now merged BBS+ verifiable credential signing and verification. Example: https://github.com/hyperledger/aries-framework-go/blob/ac94a47/pkg/doc/verifiable/credential_ldp_test.go#L450

george.aristy (Wed, 28 Oct 2020 19:03:32 GMT):
Weekly B call happening now: https://zoom.us/j/5184947650?pwd=UE90WHhEaHRqOGEyMkV3cldKa2d2dz09

jramps9 (Thu, 29 Oct 2020 13:53:09 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

askolesov (Mon, 09 Nov 2020 10:43:36 GMT):
Has joined the channel.

jramps9 (Mon, 09 Nov 2020 18:13:35 GMT):
Hello Aries maintainers! 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

danielhardman (Tue, 10 Nov 2020 15:29:29 GMT):
Can I get this merged? https://github.com/hyperledger/aries-rfcs/pull/557

danielhardman (Wed, 11 Nov 2020 21:30:43 GMT):
Okay, I cleaned up this PR and got it back up-to-date. Please merge when you get a chance: https://github.com/hyperledger/aries-rfcs/pull/559

swcurran (Wed, 11 Nov 2020 21:38:05 GMT):
Done

danielhardman (Wed, 11 Nov 2020 21:38:18 GMT):
Thanks!

george.aristy (Thu, 19 Nov 2020 18:43:07 GMT):
What versions of `did:peer` are out there in the wild?

george.aristy (Thu, 19 Nov 2020 18:43:48 GMT):
aries-framework-go supports it, but the implementation is old and it could be lagging behind recent changes.

danielhardman (Thu, 19 Nov 2020 18:48:14 GMT):
I did a version in python. I believe Lohan Spies at DIDx did a version in python. I think Orie did an experimental version in JavaScript, but went off-spec to experiment with a different CRDT mechanism. I heard that someone else did a version in JavaScript, but I don't know who it was. I think there may be another 1 or 2 impls floating around that I haven't tracked. I think the aries-framework-go impl was the first one other than mine in python that aspired to production status, so it has the greatest gravitas. If you updated your impl, I think others would follow suit and you wouldn't feel a lot of interop pain.

george.aristy (Thu, 19 Nov 2020 18:49:13 GMT):
Should this be an AIP item?

danielhardman (Thu, 19 Nov 2020 18:49:35 GMT):
I would love it if we did that. I'd be curious to see how community would react to that.

george.aristy (Thu, 19 Nov 2020 18:50:05 GMT):
According to this comment, indy-sdk also implemented `did:peer`: https://github.com/hyperledger/aries-framework-go/pull/2159#issuecomment-730563589

pfeairheller (Thu, 19 Nov 2020 18:51:10 GMT):
I would definitely support it being an AIP item.

george.aristy (Thu, 19 Nov 2020 18:51:19 GMT):
+1

danielhardman (Thu, 19 Nov 2020 18:51:49 GMT):
Let's propose it.

george.aristy (Thu, 19 Nov 2020 18:52:34 GMT):
Yup

george.aristy (Thu, 19 Nov 2020 18:52:48 GMT):
You want to do the honors?

danielhardman (Thu, 19 Nov 2020 18:52:57 GMT):
Sure.

esplinr (Fri, 20 Nov 2020 22:56:53 GMT):
For each proposal for AIP 2.0, I'm really keen for it to include a description of the use case it enables (user story or customer benefit). That will help vendors like me to prioritize the work to support the new interop profile.

esplinr (Fri, 20 Nov 2020 22:57:29 GMT):
In other words, what use case will did:peer enable that isn't achievable with AIP 1.0?

tomislav (Fri, 20 Nov 2020 22:58:13 GMT):
I agree with @esplinr

TelegramSam (Tue, 24 Nov 2020 14:21:19 GMT):
Agree with benefit focused discussion. However: Interoperability is clearly the goal here. Adding interim steps to achieve the interop required for DIDComm v2 seems like a worthy goal to me. Stepping up did:peer to something real from it's currently hacky implementation fits that description for me.

esplinr (Wed, 25 Nov 2020 06:34:00 GMT):
Not every proposed AIP item will map to a user benefit, but whenever possible it will help to describe the items in those terms. "Interop is the goal" is too vague as we have some level of interop today. So it will help me to understand "improved interop while doing X because the current approach fails due to Y". I know that repeats some of the long RFC conversations, but the summary would be really useful.

george.aristy (Wed, 25 Nov 2020 14:19:34 GMT):
Fully agree @esplinr

troyronda (Wed, 25 Nov 2020 15:03:25 GMT):
I think Interop beyond the Indy community is a goal - we don't have this interop today.

troyronda (Wed, 25 Nov 2020 15:03:25 GMT):
I think Interop beyond the Indy community is a goal - we don't have this interop across projects today.

troyronda (Wed, 25 Nov 2020 15:51:07 GMT):
Having user stories (benefits) provides useful context (when applicable). Of course, with many roles in an ecosystem, there are stories beyond the "end user" role.

troyronda (Wed, 25 Nov 2020 15:51:17 GMT):
Although there is some level of interop based on the usage of Indy and Indy credentials, we also need to focus on AIP profile items that enable interop beyond the Indy projects.

troyronda (Wed, 25 Nov 2020 16:30:14 GMT):
And we should also note that there isn’t currently interop between all the Aries projects. As an example, aries-framework-go has focused on being DID method (and ledger) agnostic, enabling “JSON-LD” verifiable credentials / signature suites, and implementing the updated Aries protocols.

swcurran (Wed, 25 Nov 2020 21:29:57 GMT):
I've added PR to update the generated index to reflect recent changes. Can I get an approval and merge of that?

swcurran (Wed, 25 Nov 2020 21:29:59 GMT):
https://github.com/hyperledger/aries-rfcs/pull/567

swcurran (Fri, 27 Nov 2020 01:04:46 GMT):
I was given the assignment at the last Aries WG to generate a PR (or document) to start the discussion about what should be in AIP Next. I've done that initially as a Google Doc and plan on leading a discussion about the document and it's comments at the next US Afternoon Aries WG Call. For those that want to take a look ahead of that to prepare their "discussion points", the link to the document is below. Please read the initial section of the document so you have a bit of context of what's in the document and what I've already done. https://docs.google.com/document/d/1Gvv0VNEfnYjJXgscxYRJ38f_KRrojNKv5hrF2t-oESM/edit?usp=sharing Enjoy!

marc0olo (Mon, 30 Nov 2020 04:52:54 GMT):
Has joined the channel.

sebastian (Mon, 30 Nov 2020 11:34:58 GMT):
Has joined the channel.

jramps9 (Mon, 07 Dec 2020 18:00:31 GMT):
Hello Aries maintainers! 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

george.aristy (Fri, 11 Dec 2020 20:45:34 GMT):
Are there implementations out there that have adopted `RFC0360-use-did-key` ?

george.aristy (Fri, 11 Dec 2020 20:45:49 GMT):
Curious to share some thoughts on this.

george.aristy (Fri, 11 Dec 2020 20:46:18 GMT):
The `did:key` method is not very well documented: https://w3c-ccg.github.io/did-method-key

george.aristy (Fri, 11 Dec 2020 20:46:28 GMT):
But there is "enough" to get you started.

george.aristy (Fri, 11 Dec 2020 20:47:00 GMT):
But when you get down to the details, making it work the way we expected to in DIDComm doesn't look so smooth.

george.aristy (Fri, 11 Dec 2020 20:48:52 GMT):
Let's start with the attachments RFC which states: > may also use a DID URL to reference a key within a resolvable DIDDoc I think we should uniformly say usage of DID URL is a MUST.

george.aristy (Fri, 11 Dec 2020 20:49:42 GMT):
*and* we should say the DID URL MUST de-reference to the DID's `keyAgreement` verification method.

george.aristy (Fri, 11 Dec 2020 20:50:22 GMT):
Given the above, we arrive at `did:key`.

george.aristy (Fri, 11 Dec 2020 20:51:00 GMT):
`did:key` does not _really_ provide any metadata for the key aside from its technical parameters (curve, values).

george.aristy (Fri, 11 Dec 2020 20:51:10 GMT):
It does _not_ indicate its purpose.

george.aristy (Fri, 11 Dec 2020 20:52:38 GMT):
@kdenhartog correctly identifies an problem here - only some ECC algorithms have been shown to be secure when the same key is used for both signing and key agreement: https://github.com/w3c-ccg/did-method-key/issues/3#issue-547767482

george.aristy (Fri, 11 Dec 2020 20:54:02 GMT):
`did:key` does not provide a way for the controller (ie. the sender of the `did:key`) indicating the key's purpose. Hence the spec says that when you resolve a `did:key` you end up with _all_ purposes.

george.aristy (Fri, 11 Dec 2020 20:54:15 GMT):
keyAgreement, authentication, assertionMethod, capabilityDelegation, capabilityInvocation

pfeairheller (Fri, 11 Dec 2020 20:57:03 GMT):
So should the `did:key` method then be limited to those secure algorithms? Or are you proposing a way to indicate the purpose in the did?

swcurran (Fri, 11 Dec 2020 20:58:19 GMT):
The purpose of a did:key is to send a public key and it's type as a DID, and to provide away to text transform that into a DIDDoc. It's only content is the public key and type, and it's method specifies the transformation so you can resolve it. Are you expecting more than that?

swcurran (Fri, 11 Dec 2020 20:58:52 GMT):
It's used in DIDComm as a replacement for sending just a naked public key, so that it can be resolved.

swcurran (Fri, 11 Dec 2020 20:58:52 GMT):
It's used in DIDComm as a replacement for sending just a naked public key, so that it can be resolved/handled like a DID.

tarkochevamik (Fri, 11 Dec 2020 20:59:01 GMT):
Has joined the channel.

swcurran (Fri, 11 Dec 2020 20:59:25 GMT):
But it's still nothing more than a public key and a type.

george.aristy (Fri, 11 Dec 2020 22:13:53 GMT):
@swcurran I know that is the intention, and you can easily see it "work" with a casual glance, but what is actually in the Aries RFCs does not match quite right with did-core (and by extension, did:key)

george.aristy (Fri, 11 Dec 2020 22:14:03 GMT):
We should be reusing components here.

george.aristy (Fri, 11 Dec 2020 22:14:39 GMT):
Specifically, we should reuse our `did:key` resolver with a generic DID URL de-referencer on top

george.aristy (Fri, 11 Dec 2020 22:14:49 GMT):
For that to work we need to follow the rules in did-core.

george.aristy (Fri, 11 Dec 2020 22:15:57 GMT):
"purpose" has a specific meaning in DIDs.. and it's related to how the keys in those DIDs are to be used.

george.aristy (Fri, 11 Dec 2020 22:17:27 GMT):
I am still not clear why we didn't go the direct route of multibase(multicodec(key))

george.aristy (Fri, 11 Dec 2020 22:18:15 GMT):
Back to my first question.... are there implementations out there that are using did:key for DIDComm?

george.aristy (Fri, 11 Dec 2020 22:21:36 GMT):
I see ACA-Py did implement `did:key`...

george.aristy (Fri, 11 Dec 2020 22:22:04 GMT):
https://github.com/llorllale/aries-cloudagent-python/blob/a5205b80ec71646d0dbb60c6df261468c5508841/aries_cloudagent/messaging/decorators/attach_decorator.py#L348-L368

george.aristy (Fri, 11 Dec 2020 22:22:16 GMT):
https://github.com/llorllale/aries-cloudagent-python/blob/a5205b80ec71646d0dbb60c6df261468c5508841/aries_cloudagent/messaging/decorators/attach_decorator.py#L198-L206

george.aristy (Fri, 11 Dec 2020 22:24:38 GMT):
Here is where we have the gray area from a standards-perspective: using this example: ``` { "@context": "https://w3id.org/did/v1", "id": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH", "publicKey": [{ "id": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH#z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH", "type": "Ed25519VerificationKey2018", "controller": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH", "publicKeyBase58": "B12NYF8RrR3h41TDCTJojY59usg3mbtbjnFs7Eud1Y6u" }], "authentication": [ "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH#z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH" ], "assertionMethod": [ "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH#z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH" ], "capabilityDelegation": [ "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH#z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH" ], "capabilityInvocation": [ "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH#z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH" ], "keyAgreement": [{ "id": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH#zBzoR5sqFgi6q3iFia8JPNfENCpi7RNSTKF7XNXX96SBY4", "type": "X25519KeyAgreementKey2019", "controller": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH", "publicKeyBase58": "JhNWeSVLMYccCk7iopQW4guaSJTojqpMEELgSLhKwRr" }] } ```

george.aristy (Fri, 11 Dec 2020 22:25:32 GMT):
How does the receiver know which to pick - the `publicKey` or the `keyAgreement` key - when ACA-Py just sends this: `did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH` ?

george.aristy (Fri, 11 Dec 2020 22:26:26 GMT):
De-referencing `did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9jSwuBV8xRoAnwWsdvktH` would result in this whole DID document, not the key within.

george.aristy (Fri, 11 Dec 2020 22:26:52 GMT):
To reference a key we need a DID URL: https://www.w3.org/TR/did-core/#did-url-syntax

george.aristy (Fri, 11 Dec 2020 22:27:04 GMT):
Also specified in did-core is how to de-reference DID URLs: https://www.w3.org/TR/did-core/#did-url-dereferencing

george.aristy (Fri, 11 Dec 2020 22:27:47 GMT):
And finally, to support the case that these need to be `did:key` URLs and not just the DID, here's the section on signing attachments in the Aries RFC: https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0017-attachments/README.md#signing-attachments

george.aristy (Fri, 11 Dec 2020 22:28:00 GMT):
> It may also use a DID URL to reference a key within a resolvable DIDDoc

george.aristy (Fri, 11 Dec 2020 22:28:42 GMT):
The references should be uniformly represented, and the standards-compliant way is through DID URLs.

george.aristy (Fri, 11 Dec 2020 22:29:14 GMT):
If you are now convinced that we MUST use DID URLs, we can get on to discuss `did:key`...

george.aristy (Fri, 11 Dec 2020 22:31:13 GMT):
I agree with sending the naked key in explicit invitations. I agree they should be encoded with sufficient metadata such that the recipient can discern the curve.

george.aristy (Fri, 11 Dec 2020 22:31:27 GMT):
I'm not very convinced we need `did:key` though.

swcurran (Sat, 12 Dec 2020 20:08:25 GMT):
We had that debate when those PRs were done -- use of DID Key and the RFCs that were updated. Your points were raised and in the end, the majority (but, as I recall, not unanimous) decision was to go with `did:key` vs. multibase so that a DID resolver could be used if needed. There are three ways to get the public key from a did:key --- resolve to get the DIDDoc and extract, use a did URL (AFAIK -- that should work...) or recognize it as a `did:key` and use a multi-base handler to get the public key. Ugly, but up to the implementer.

george.aristy (Mon, 14 Dec 2020 20:10:20 GMT):
I just raised a PR that adds a new field to an OOB invitation such that the sender declares the JWE parameters it supports for encryption: https://github.com/hyperledger/aries-rfcs/pull/576

george.aristy (Mon, 14 Dec 2020 20:10:26 GMT):
Would like some feedback

george.aristy (Mon, 14 Dec 2020 20:20:36 GMT):
@swcurran > There are three ways to get the public key from a did:key --- resolve to get the DIDDoc and extract, use a did URL (AFAIK -- that should work...) or recognize it as a did:key and use a multi-base handler to get the public key. Ugly, but up to the implementer. This is what I want to clear up. There should be 1 way to resolve key agreement keys from `did:key`

andrew.whitehead (Mon, 14 Dec 2020 20:35:32 GMT):
We're not running it through a full DID resolver when the process of deriving the key is clear, what would be the point?

george.aristy (Mon, 14 Dec 2020 20:46:09 GMT):
Hi @andrew.whitehead - I believe the discrepancy will become more evident once we use curves other than Ed25519/X25519.

george.aristy (Mon, 14 Dec 2020 20:46:51 GMT):
For example, if I wanted to use P256, what sort of `did:key` reference would I send and how would the receiver process it?

george.aristy (Mon, 14 Dec 2020 20:47:04 GMT):
It is "obvious" - but different from Ed25519/X25519.

george.aristy (Mon, 14 Dec 2020 20:48:14 GMT):
My second concern is this is already a "did URL de-referencing" problem. There shouldn't be an "Aries DIDComm DID URL de-referencer" - we should be able to reuse components.

george.aristy (Mon, 14 Dec 2020 20:48:23 GMT):
These standards are meant to be composable.

andrew.whitehead (Mon, 14 Dec 2020 21:40:50 GMT):
I think the only real use case going forward are the routingKeys and recipientKeys fields in an out-of-band invitation, in which case the recipientKeys must contain a single ed25519 key. That's because it's used both for signing the DID Doc received in the DID exchange response, and its x25519 equivalent is used in encrypting the request. Perhaps another field could be added to indicate the signing key, in which case the recipient key could be another format (I think you can do key agreement with secp256k1 but it might not be well supported yet)

andrew.whitehead (Mon, 14 Dec 2020 21:50:11 GMT):
I admit it's not clear to me how you would resolve another type of DID URL there which didn't reference a specific key in the DID document. For signing purposes you would probably have to support the various authentication rules of the DID spec, and for encryption you would use.. all of the key agreement keys perhaps?

george.aristy (Thu, 17 Dec 2020 20:42:42 GMT):
@swcurran @TelegramSam any reason on why `handshake_protocols` should not be inside the `service` object in an OOB invitation?

george.aristy (Thu, 17 Dec 2020 20:45:50 GMT):
1 reason is - need only specify it once for all `service` entries.

george.aristy (Thu, 17 Dec 2020 20:46:20 GMT):
I guess the expectation is that most implicit invitations using public DIDs would be discovered via an OOB invitation.

george.aristy (Thu, 17 Dec 2020 20:47:15 GMT):
Because the `did-communication` service endpoint does not have this information.

george.aristy (Thu, 17 Dec 2020 20:50:33 GMT):
Is there as well an assumption that most OOB invitations will have several explicit `service` entries?

swcurran (Thu, 17 Dec 2020 21:07:55 GMT):
For now -- `handshake_protocols` is optional. Also, service objects may be just references to service objects in a resolvable DID.

swcurran (Thu, 17 Dec 2020 21:07:55 GMT):
For one -- `handshake_protocols` is optional. Also, service objects may be just references to service objects in a resolvable DID.

swcurran (Thu, 17 Dec 2020 21:08:39 GMT):
I think the expectation is that most OOB invitations will have just one service entry.

swcurran (Thu, 17 Dec 2020 21:09:01 GMT):
Can't see why there would be mutlitple.

andrew.whitehead (Thu, 17 Dec 2020 21:11:41 GMT):
Only if it's basically standing in for a DID document I think

andrew.whitehead (Thu, 17 Dec 2020 21:11:41 GMT):
Only if it's basically standing in for a DID document I think, it's hard to imagine an agent that has multiple endpoints but can't publish their DID doc though

george.aristy (Fri, 18 Dec 2020 18:32:55 GMT):
> service objects may be just references to service objects in a resolvable DID. That's a reason in favor of placing `handshake_protocols` inside the DID document as well

swcurran (Fri, 18 Dec 2020 18:55:25 GMT):
Ah...I see. This is for the implicit invitation use case. Interesting...

swcurran (Fri, 18 Dec 2020 18:55:49 GMT):
So you can tell the other party -- hey, use these protocols to connect with me...

george.aristy (Fri, 18 Dec 2020 18:56:32 GMT):
Yeah. If the DID is truly intended to be public, then anyone browsing the DID registry can connect to it using the appropriate protocols.

george.aristy (Fri, 18 Dec 2020 18:57:14 GMT):
So to make it uniform: both `service` objects in OOB invitations and in DID Docs should have `handshake_protocols`

george.aristy (Fri, 18 Dec 2020 18:57:41 GMT):
OOB invitations are smaller.

george.aristy (Fri, 18 Dec 2020 18:57:41 GMT):
OOB invitations using public DIDs are smaller.

andrew.whitehead (Fri, 18 Dec 2020 19:00:16 GMT):
An indy DID wouldn't have the handshake protocols in the synthesized DID doc, so it would still be useful to include handshake protocols in the OOB invitation in that case

andrew.whitehead (Fri, 18 Dec 2020 19:00:54 GMT):
We might want to just support it at both levels, let the service entry override the outer value if there is one

george.aristy (Fri, 18 Dec 2020 19:02:28 GMT):
@andrew.whitehead so the bigger point would be: checks support for custom `service` entries across DID methods

george.aristy (Fri, 18 Dec 2020 19:02:28 GMT):
@andrew.whitehead so the bigger point would be: check support for custom `service` entries across DID methods

george.aristy (Fri, 18 Dec 2020 19:03:46 GMT):
This rings a faint bell - reminds me of the changes done in V2 to make it work with `did:key`

andrew.whitehead (Fri, 18 Dec 2020 19:07:36 GMT):
So would this be the indy version, at least until there's a way to publish a custom DID doc? To support resolution for the keys and endpoint ```json { "@type": "https://didcomm.org/out-of-band/%VER/invitation", "@id": "..", "service": [ { "handshake_protocols": [ "https://didcomm.org/didexchange/1.0" ], "serviceEndpoint": "did:sov:LjgpST2rjsoxYegQDRm7EL#service" } ] } ```

george.aristy (Fri, 18 Dec 2020 22:58:04 GMT):
All: I just pushed a proposal to adjust the encoding of naked keys in some RFC - I'd love some feedback.

george.aristy (Fri, 18 Dec 2020 22:58:06 GMT):
https://github.com/hyperledger/aries-rfcs/pull/577

andrew.whitehead (Sun, 20 Dec 2020 04:52:03 GMT):
Looks promising, I'll have to think about it some more. In the context of the DIDComm DIDDoc it feels like agents should just be using an `authentication` block to provide that information, rather than `authnKeys` in the service block. It seems like the semantics of the `authnKeys` array are that any single key can be used for authentication (as opposed to say, all of them) so that might need to be made explicit

swcurran (Tue, 05 Jan 2021 01:33:15 GMT):
Folks: BC Gov wants to contribute the *aries-askar* (https://github.com/bcgov/aries-askar) repo to Hyperledger. The repo contains an Aries-level Rust implementation of agent storage/key management service that works with the already contributed indy-vdr (https://github.com/hyperledger/indy-vdr) and the also to be contributed indy-shared-rs (https://github.com/bcgov/indy-shared-rs) to enable the creation of Aries Agents without using the indy-sdk. Specifically, aries-askar provides the capability currently provided by the `indy-wallet` component of the indy-sdk. Our expectation is that the combination of new libraries will be more flexible, capable and performant, and will eliminate the need to use the indy-sdk at all. We hope to talk about this proposal briefly at the Aries WG call this week ( @TelegramSam ) Please let us know if you support or object to this contribution.

esplinr (Tue, 05 Jan 2021 13:41:17 GMT):
I support. Thank you for your leadership in contributing this work!

swcurran (Thu, 07 Jan 2021 19:06:59 GMT):
Following the feedback here (no objections) and the discussion on the Aries WG call, I think BC Gov can go forward with the contribution of the aries-askar (https://github.com/bcgov/aries-askar) repo to Hyperledger. @andrew.whitehead @WadeBarnes and @rjones --- please go ahead with that as appropriate. @alexgmetcalf -- you and I should work a bit on some more words in the readme.

alexgmetcalf (Thu, 07 Jan 2021 19:06:59 GMT):
Has joined the channel.

WadeBarnes (Fri, 08 Jan 2021 15:38:22 GMT):
The `bcgov/aries-askar` repository has been transferred to Hyperledger and is now [hyperledger/aries-askar](https://github.com/hyperledger/aries-askar).

danielhardman (Sun, 10 Jan 2021 02:10:59 GMT):
Great job, guys!

jramps9 (Mon, 11 Jan 2021 15:27:01 GMT):
Hello Aries maintainers! 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

george.aristy (Mon, 11 Jan 2021 15:59:43 GMT):
`authentication` block would work for invitations embedded inside DID Docs

george.aristy (Mon, 11 Jan 2021 16:00:04 GMT):
Thing is - it won't for explicit invitations

george.aristy (Wed, 13 Jan 2021 19:32:44 GMT):
@swcurran @TelegramSam Just want to confirm that talk about about moving away from did:key is in the agenda for today's B call?

rjones (Wed, 13 Jan 2021 20:23:17 GMT):
@dbluhm could you add Hyperledger as an owner of https://pypi.org/project/aries-staticagent/ please?

rjones (Wed, 13 Jan 2021 20:23:42 GMT):
Right now, I think it's maintain, not owner

dbluhm (Wed, 13 Jan 2021 21:08:43 GMT):
@rjones done

george.aristy (Thu, 14 Jan 2021 15:04:37 GMT):
@swcurran @TelegramSam as per your request from yesterday's call: If asked to stick strictly to NIST-approved crypto, and given the choice, the aries-framework-go team would default to the following: * key agreement: P-384 with ECDH-1PU+A256KW, encrypting the epk to the recipient with A256GCM * content encryption: A256GCM * authentication: ECDSA with P-384 The team recognizes the prevalence of P-256, however, and would default to that instead if it makes sense. Here is the complete list of curves and algorithms we aim to support for our next release (0.1.6): * *key agreement*: * crv: P-256, P-384, P-521, X25519 * alg: ECDH-ES+A256KW, ECDH-1PU+XC20PKW * enc: A256GCM, XC20P * *encryption*: A256GCM, XC20P * *authentication*: EdDSA with Ed25519, ES256, ES384, ES512

george.aristy (Thu, 14 Jan 2021 15:04:37 GMT):
@swcurran @TelegramSam as per your request from yesterday's call: If asked to stick strictly to NIST-approved crypto, and given the choice, the aries-framework-go team would default to the following: * key agreement: P-384 with ECDH-1PU+A256KW, encrypting the epk to the recipient with A256GCM * content encryption: A256GCM * authentication: ECDSA with P-384 The team recognizes the prevalence of P-256, however, and would default to that instead if it makes sense. Here is the complete list of curves and algorithms we aim to support for our next release (0.1.6): * key agreement: * crv: P-256, P-384, P-521, X25519 * alg: ECDH-ES+A256KW, ECDH-1PU+XC20PKW * enc: A256GCM, XC20P * encryption: A256GCM, XC20P * authentication: EdDSA with Ed25519, ES256, ES384, ES512

george.aristy (Thu, 14 Jan 2021 15:04:37 GMT):
@swcurran @TelegramSam as per your request from yesterday's call: If asked to stick strictly to NIST-approved crypto, and given the choice, the aries-framework-go team would default to the following: * key agreement: P-384 with ECDH-1PU+A256KW, encrypting the epk to the recipient with A256GCM * content encryption: A256GCM * authentication: ECDSA with P-384 The team recognizes the prevalence of P-256, however, and would default to that instead if it makes sense. Here is the complete list of curves and algorithms we aim to support for our next release (0.1.6): * key agreement: ----crv: P-256, P-384, P-521, X25519 ----alg: ECDH-ES+A256KW, ECDH-1PU+XC20PKW ----enc: A256GCM, XC20P * encryption: A256GCM, XC20P * authentication: EdDSA with Ed25519, ES256, ES384, ES512

george.aristy (Thu, 14 Jan 2021 15:12:53 GMT):
I posted a comment on the PR with the action items I recall from yesterday's call: https://github.com/hyperledger/aries-rfcs/pull/577#issuecomment-760259045

Baha-sk (Thu, 14 Jan 2021 15:22:03 GMT):
Has joined the channel.

troyronda (Fri, 15 Jan 2021 15:08:32 GMT):
https://chat.hyperledger.org/channel/aries-go?msg=Z8Af8tryGR9EHQ7sw

rjones (Fri, 15 Jan 2021 15:10:37 GMT):
@troyronda please remember to make this change in .github/settings.yml in 1) main 2) master, in that order

rjones (Fri, 15 Jan 2021 15:11:40 GMT):
which I see somehow you don't have.

troyronda (Fri, 15 Jan 2021 15:12:03 GMT):
@rjones hmmm.. yes - I was just going to ask about that :).

rjones (Fri, 15 Jan 2021 15:12:22 GMT):
Steal this one: https://github.com/hyperledger/fabric/blob/master/.github/settings.yml

rjones (Fri, 15 Jan 2021 15:12:27 GMT):
edit to suit

troyronda (Fri, 15 Jan 2021 15:12:46 GMT):
Ok cool. Shall I rename the branch first and then add this file?

rjones (Fri, 15 Jan 2021 15:13:16 GMT):
yes.

rjones (Fri, 15 Jan 2021 15:15:28 GMT):
Are you able to see https://github.com/hyperledger/aries-framework-go/security/dependabot ?

troyronda (Fri, 15 Jan 2021 15:16:34 GMT):
Yes. I keep meaning to look into not having alerts on local test scripts.

troyronda (Fri, 15 Jan 2021 21:11:04 GMT):
https://chat.hyperledger.org/channel/aries-go?msg=ryK5hL2Si9M7uzrA7

rjones (Fri, 15 Jan 2021 23:14:09 GMT):
Maybe add a note for next week's /dev/weekly?

swcurran (Mon, 18 Jan 2021 16:50:37 GMT):
@rjones -- can you please create a channel called "aries-bbs+" that we can use to, you know, talk about BBS+. And Aries.

rjones (Mon, 25 Jan 2021 18:36:44 GMT):
Hi, the following repos still use `master` as the default branch: `aries, aries-acapy-controllers, aries-acapy-plugin-toolbox, aries-agent-test-harness, aries-cloudagent-python, aries-framework-dotnet, aries-framework-javascript, aries-mobileagent-xamarin, aries-protocol-test-suite, aries-rfcs, aries-sdk-java, aries-staticagent-python, aries-toolbox, aries-vcx`. `main` [is the current guidance for naming](https://github.com/github/renaming).

TimoGlastra (Mon, 25 Jan 2021 18:52:03 GMT):
I'll bring it up during the aries-framework-javascript call this friday

dbluhm (Tue, 02 Feb 2021 14:18:07 GMT):
Switched over aries-staticagent-python and preparing to switch aries-toolbox and aries-acapy-plugin-toolbox

rjones (Tue, 02 Feb 2021 15:01:35 GMT):
Cool. If you need a hand, lmk. I found some repos aren't set up to allow easy branch renames.

jramps9 (Mon, 08 Feb 2021 15:15:30 GMT):
Hello Aries maintainers! 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

dbluhm (Wed, 10 Feb 2021 14:04:26 GMT):
On closer inspection, it looks like I don't have sufficient privileges to change the default branch for aries-acapy-plugin-toolbox

rjones (Wed, 10 Feb 2021 14:19:11 GMT):
OK, I fixed it.

troyronda (Wed, 10 Feb 2021 22:20:45 GMT):
@TelegramSam Posted the RFC that splits out Authcrypt JWE and added the line about using fresh DIDs: https://github.com/hyperledger/aries-rfcs/pull/587

swcurran (Thu, 18 Feb 2021 20:58:06 GMT):
@troyronda @andrew.whitehead and others -- questions from the CII Badge for Aries at Hyperledger (in prep for the "Exit Incubation" TSC assessment). Do either or both of ACA-Py or AF-Go do this: ``` The release notes MUST identify every publicly known run-time vulnerability fixed in this release that already had a CVE assignment or similar when the release was created. This criterion may be marked as not applicable (N/A) if users typically cannot practically update the software themselves (e.g., as is often true for kernel updates). This criterion applies only to the project results, not to its dependencies. If there are no release notes or there have been no publicly known vulnerabilities, choose N/A. [release_notes_vulns] This criterion helps users determine if a given update will fix a vulnerability that is publicly known, to help users make an informed decision about updating. If users typically cannot practically update the software themselves on their computers, but must instead depend on one or more intermediaries to perform the update (as is often the case for a kernel and low-level software that is intertwined with a kernel), the project may choose "not applicable" (N/A) instead, since this additional information will not be helpful to those users. Similarly, a project may choose N/A if all recipients only run the latest version (e.g., it is the code for a single website or internet service that is constantly updated via continuous delivery). This criterion only applies to the project results, not its dependencies. Listing the vulnerabilities of all transitive dependencies of a project becomes unwieldy as dependencies increase and vary, and is unnecessary since tools that examine and track dependencies can do this in a more scalable way. ```

swcurran (Thu, 18 Feb 2021 21:00:56 GMT):
Second question -- I'm assuming that none of the Aries frameworks, use any dynamic code analysis tools -- e.g. fuzzing. Is that correct?

andrew.whitehead (Thu, 18 Feb 2021 21:15:40 GMT):
We haven't had any CVEs created so I think that's an N/A. I'm not aware of any use of fuzzing (yet), why?

Helen_Garneau (Tue, 23 Feb 2021 18:25:19 GMT):
Has joined the channel.

troyronda (Thu, 25 Feb 2021 15:03:39 GMT):
https://chat.hyperledger.org/channel/aries-go?msg=zcudBwop9gyBbFPfq

troyronda (Fri, 26 Feb 2021 02:28:20 GMT):
PR to allow the OOB message to convey mime type preferences: https://github.com/hyperledger/aries-rfcs/pull/595/

troyronda (Fri, 26 Feb 2021 02:30:50 GMT):
I will add a clarification to PR 587 to indicate that its mime type is: "application/didcomm-encrypted+json". So with that clarification and the accept property in the OOB message, the acceptable envelope type(s) can be determined by the receiver of an OOB message.

troyronda (Fri, 26 Feb 2021 02:30:50 GMT):
I will also add a clarification to PR 587 to indicate that its mime type is: "application/didcomm-encrypted+json". So with that clarification and the accept property in the OOB message, the acceptable envelope type(s) can be determined by the receiver of an OOB message.

troyronda (Fri, 26 Feb 2021 02:49:15 GMT):
Updated PR 587.

kdenhartog (Wed, 03 Mar 2021 01:32:06 GMT):
I've not been made aware of any known CVEs in the project (all the dependabot stuff is normally just in sample code). I think I'm still on the hook for triaging those as well

kdenhartog (Wed, 03 Mar 2021 01:33:20 GMT):
I've not seen anyone using fuzzing yet either. Would be interesting to see what might come of it if anyone goes down that road

troyronda (Mon, 08 Mar 2021 21:39:14 GMT):
https://chat.hyperledger.org/channel/aries-go?msg=ANMmhnHmCNtmWPPZL

Helen_Garneau (Wed, 10 Mar 2021 12:59:52 GMT):
Hello Aries Maintainers: 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:56 GMT):
(Please note new zoom info!)

troyronda (Wed, 10 Mar 2021 21:40:02 GMT):
I updated https://github.com/hyperledger/aries-rfcs/pull/587 according to the discussion in the Aries call today.

danielhardman (Wed, 10 Mar 2021 21:46:56 GMT):
PR from today's Aries B call: minor tweak to RFC 0044 to say that the more specific mime type for plaintext, rather than the more generic mime type, is preferred. https://github.com/hyperledger/aries-rfcs/pull/606

george.aristy (Fri, 12 Mar 2021 01:56:38 GMT):
Hello - question+proposal to clarify DID doc resolution for RFC0023 ("did-exchange"): https://github.com/hyperledger/aries-rfcs/issues/609

george.aristy (Fri, 12 Mar 2021 01:56:49 GMT):
Solutions/feedback are welcome!

swcurran (Mon, 15 Mar 2021 16:35:13 GMT):
@troyronda @TelegramSam -- does 587 Encryption Envelope V2 replace 334 in AIP 2.0? I assume so, but wanted to confirm.

swcurran (Mon, 15 Mar 2021 16:45:29 GMT):
Hmmm...maybe it is replacing 0019?

troyronda (Mon, 15 Mar 2021 17:10:03 GMT):
@swcurran yes: 587 replaces 334 in AIP 2.0.

troyronda (Mon, 15 Mar 2021 17:12:03 GMT):
I would, of course, prefer to also replace 0019 if the community is able to do so. One issue that was brought up is that with 0019 in core and 587 in a sub-target, we should add some more description into AIP to cover those agents that can only do 587 (and not 19).

troyronda (Mon, 15 Mar 2021 17:12:03 GMT):
I would, of course, prefer to also replace 0019 if the community is able to do so. One issue that was brought up (in the Aries WG call) is that with 0019 in core and 587 in a sub-target, we should add some more description into AIP to cover those agents that can only do 587 (and not 19).

troyronda (Mon, 15 Mar 2021 17:12:03 GMT):
I would, of course, prefer to also replace 0019 if the community is able to do so.

troyronda (Mon, 15 Mar 2021 17:12:03 GMT):
I would, of course, prefer to also replace 0019 if the community is able to do so. (but that hasn't been the discussion so far).

troyronda (Mon, 15 Mar 2021 17:19:53 GMT):
One issue that was brought up (in the Aries WG call) is that with 0019 in core and 587 in a sub-target, we should add some more description into AIP to cover those agents that can only do 587 (and not 19).

swcurran (Thu, 15 Apr 2021 20:22:01 GMT):
@TelegramSam @danielhardman @george.aristy -- can one of you approve and merge this so that we eliminate the CI/CD error we're getting in aries-rfcs https://github.com/hyperledger/aries-rfcs/pull/637

rjones (Thu, 15 Apr 2021 20:31:59 GMT):
@swcurran do you want me to use superpowers to merge that?

swcurran (Thu, 15 Apr 2021 20:32:38 GMT):
Go for it.

rjones (Thu, 15 Apr 2021 20:33:49 GMT):
done

esplinr (Thu, 15 Apr 2021 20:46:05 GMT):
Is anyone working on an Aries RFC for BBS+ signatures? We want to make sure our implementation plan is targeting the right specification.

TimoGlastra (Thu, 15 Apr 2021 21:03:27 GMT):
I'm working on one at the moment. Should have an initial version ready by next week

TimoGlastra (Thu, 15 Apr 2021 21:03:57 GMT):
Are you looking for anything specific to be included in the RFC? Then I'll make sure to account for that

esplinr (Thu, 15 Apr 2021 21:06:16 GMT):
* I'm interested in seeing how the current proposal relates to previous work done in Indy Anoncreds 2 * I'm unclear what changes are needed in Ursa * I want to be able to tell my team: our products need to implement that.

esplinr (Thu, 15 Apr 2021 21:09:17 GMT):
I've been talking with @brentzundel . We can help contribute if you want. Is the document in HackMD or some other collaborative place?

esplinr (Thu, 15 Apr 2021 21:09:17 GMT):
I've been talking with @brentzundel . We can help contribute if you want. Is the document in HackMD or a GitHub PR or some other collaborative place?

TimoGlastra (Thu, 15 Apr 2021 21:14:20 GMT):
Yeah that would be appreciated. I don't know how Indy AnonCreds 2 works, so I can't make that comparison. For the implementation we did in ACA-Py we didn't need to make any changes to ursa, however we have only implemented the basic features at the moment.

esplinr (Thu, 15 Apr 2021 21:15:00 GMT):
My understanding is that Mattr's proposal doesn't support link secrets, which will be required for use in Indy.

TimoGlastra (Thu, 15 Apr 2021 21:15:10 GMT):
I'm currently mostly focussing on pointing to the correct specs, how to use BBS+ in credential exchange and providing some tutorial / implementers guide

esplinr (Thu, 15 Apr 2021 21:15:25 GMT):
That sounds like a valuable start.

TimoGlastra (Thu, 15 Apr 2021 21:15:26 GMT):
At the moment -- they're working on it I believe

esplinr (Thu, 15 Apr 2021 21:16:28 GMT):
@kdenhartog is your team making progress on link secrets in BBS+

esplinr (Thu, 15 Apr 2021 21:16:28 GMT):
@kdenhartog is your team making progress on link secrets in BBS+? That would be fantastic!

TimoGlastra (Thu, 15 Apr 2021 21:16:31 GMT):
Or bound signatures based on public keys, which is their way of doing link secretes If I understand correctly

esplinr (Thu, 15 Apr 2021 21:16:58 GMT):
Good to know. I'm not clear on the differences.

brentzundel (Thu, 15 Apr 2021 21:17:00 GMT):
that's what they are calling it, but it is the same mechanism as link secrets

TimoGlastra (Thu, 15 Apr 2021 21:17:13 GMT):
This is the response I got from Tobias two weeks ago: > Mike has been doing a bit of work on this, it is not quite ready yet though, the most complex aspect is actually getting the API’s as simple as possible

esplinr (Thu, 15 Apr 2021 21:17:28 GMT):
Thank you for that update.

esplinr (Thu, 15 Apr 2021 21:17:48 GMT):
We're seeing a lot of enthusiasm for BBS+ signatures, but I don't know how we can adopt them before that feature is clarified.

TimoGlastra (Thu, 15 Apr 2021 21:18:51 GMT):
For ACA-Py we went with the non-bound signatures for now, but I agree it's really needed

esplinr (Thu, 15 Apr 2021 21:19:25 GMT):
That makes sense as a POC, but we can't accept the privacy implications of that.

esplinr (Thu, 15 Apr 2021 21:19:57 GMT):
Thank you for the update @TimoGlastra . Let me know how we can help. If you have a draft RFC, we can collaborate with you.

brentzundel (Thu, 15 Apr 2021 21:20:16 GMT):
yes

TimoGlastra (Thu, 15 Apr 2021 21:20:40 GMT):
Sure. I'll share a draft document with you (probably tomorrow?) so we can work on it together

TimoGlastra (Thu, 15 Apr 2021 21:20:47 GMT):
Thanks for the help, much appreciated :)

brentzundel (Thu, 15 Apr 2021 21:20:52 GMT):
sounds great

brentzundel (Thu, 15 Apr 2021 21:21:21 GMT):
sounds great

esplinr (Thu, 15 Apr 2021 21:22:08 GMT):
Will you be attending IIW @TimoGlastra ?

TimoGlastra (Thu, 15 Apr 2021 21:22:17 GMT):
Yes

TimoGlastra (Thu, 15 Apr 2021 21:22:50 GMT):
We intend to host a session with lessons learned implementing BBS+ into ACA-Py

esplinr (Thu, 15 Apr 2021 21:23:05 GMT):
Excellent. That will be interesting.

brentzundel (Thu, 15 Apr 2021 21:23:27 GMT):
Drummond and I are planning to hold a 'next steps for BBS+' session

TimoGlastra (Thu, 15 Apr 2021 21:24:16 GMT):
Ah cool. I think they will fit great together

brentzundel (Fri, 16 Apr 2021 20:12:38 GMT):
I've got some free time this afternoon I was planning to put toward the BBS+ rfc. Is there a github repo or a hack.md doc I could look at?

TimoGlastra (Fri, 16 Apr 2021 21:31:03 GMT):
Some other work came in between so I didn’t get past creating the document sadly. If you want you can already have a go at it, but it’s not much yet: https://hackmd.io/@animo/B15BDxv8d

TimoGlastra (Fri, 16 Apr 2021 21:31:39 GMT):
You can also wait until it get’s a bit more shape

esplinr (Fri, 16 Apr 2021 21:31:53 GMT):
Sweet. Thank you.

TimoGlastra (Fri, 16 Apr 2021 21:31:58 GMT):
I’ll resume work later this weekend

esplinr (Fri, 16 Apr 2021 22:51:23 GMT):
@brentzundel and I completed most of the non-technical sections. Hopefully that's helpful.

esplinr (Fri, 16 Apr 2021 22:51:42 GMT):
We left your Spec notes at the beginning, even though we tried to fill in some of that information in the document.

esplinr (Fri, 16 Apr 2021 22:52:08 GMT):
We can work on it together more next week.

TimoGlastra (Sun, 18 Apr 2021 20:13:30 GMT):
Awesome! I really like the additions. I've done some more tinkering and will continue tomorrow

kdenhartog (Mon, 19 Apr 2021 03:26:01 GMT):
[ ](https://chat.hyperledger.org/channel/aries-maintainers?msg=qHPTsPArW89pyqwwA) Not at this point. Last I remember there needed to be some additions to signing with G1 keys before we could start building on that to add support for domain bound proof generation, but I'm uncertain where that landed. I'll check with Tobias and Mike to see what happened. I think it ended up just getting pushed down on our list of priorities as we had other things come up.

TimoGlastra (Mon, 19 Apr 2021 11:38:40 GMT):
I've added a lot more to the document. I've also added quite some TODOs at the top with questions, feel free to answer them in the TODO, or answer them somewhere else in the document

TimoGlastra (Mon, 19 Apr 2021 11:39:02 GMT):
Also feel free to move/add/remove things

esplinr (Mon, 19 Apr 2021 13:05:50 GMT):
Thank you!

brentzundel (Tue, 20 Apr 2021 15:24:37 GMT):
I'm planning to hold a session at IIW called "What's next for BBS+ LD-Proofs?" The goal is for it to be a planning session for community agreement on next steps moving forward. I am thinking it wuld be best to hold it day 3.. Thoughts?

drummondreed (Tue, 20 Apr 2021 15:25:01 GMT):
Day 3 sounds fine to me. Avoid the rush on Day 1.

cam-parra (Tue, 20 Apr 2021 15:25:04 GMT):
Sounds good to me

brentzundel (Tue, 20 Apr 2021 15:51:37 GMT):
Tobias said he's out day 3, so I'll do it tomorrow.

drummondreed (Tue, 20 Apr 2021 15:51:46 GMT):
Good

troyronda (Mon, 26 Apr 2021 20:19:32 GMT):
@swcurran @andrew.whitehead https://github.com/decentralized-identity/didcomm-messaging/pull/190

troyronda (Mon, 26 Apr 2021 20:19:32 GMT):
@swcurran @andrew.whitehead @TelegramSam https://github.com/decentralized-identity/didcomm-messaging/pull/190

troyronda (Mon, 26 Apr 2021 20:19:57 GMT):
With ecdh-es available again, I would like to update RFC 587 to use ecdh-es for anoncrypt.

troyronda (Mon, 26 Apr 2021 20:19:57 GMT):
With anoncrypt available again, I would like to update RFC 587 to use ecdh-es for anoncrypt.

troyronda (Mon, 26 Apr 2021 20:19:57 GMT):
With an anoncrypt capability available again, I would like to update RFC 587 to use ecdh-es for anoncrypt.

troyronda (Mon, 26 Apr 2021 20:42:09 GMT):
https://github.com/hyperledger/aries-rfcs/pull/643/files

swcurran (Thu, 29 Apr 2021 00:10:54 GMT):
@andrew.whitehead @tomislav @TimoGlastra @danielhardman -- I was tasked with a community update RFC to enable a transition from the "informal did:peer" we used in AIP 1.0 to the formal RFC 627 use of did:peer in AIP 2. > I started on that (and can continue on it), but it occurs to me that the transition should be made as part of moving from 0160 Connections to 0023 DID Exchange/0343 OOB. That is -- everyone using 0160 should continue to use the "old way", and everyone using 0023 should only use the "new way". Since we have no "official" users of AIP 2.0 and hence, no live uses of 0023, we don't need a transition. Implementations of 0023 just need to be updated to align with 0627. > Does that seem right to you?

andrew.whitehead (Thu, 29 Apr 2021 00:13:31 GMT):
Yes I've generally been avoiding any changes relating to the connections protocol, including the formatting of DID documents

TimoGlastra (Thu, 29 Apr 2021 08:06:54 GMT):
Sounds good! Would be useful to have a mention of that somewhere.

swcurran (Thu, 29 Apr 2021 15:36:46 GMT):
I agree -- an update to at least 0023/OOB seems right.

swcurran (Fri, 30 Apr 2021 16:17:25 GMT):
I've created the Quarterly Aries report to the TSC for Q2 -- https://wiki.hyperledger.org/display/TSC/2021+Q2+Hyperledger+Aries Let me know if you have any questions/comments/concerns. It's a Wiki page, so you can also update it if you want.

troyronda (Tue, 04 May 2021 18:10:47 GMT):
AIPv2 relevant discussion: https://github.com/decentralized-identity/didcomm-messaging/issues/191

troyronda (Tue, 04 May 2021 18:11:20 GMT):
Thanks for putting this report together!

swcurran (Tue, 04 May 2021 22:12:08 GMT):
@TelegramSam @tplooker -- pinging the two of you as the maintainers (only ones) for Aries Mobile Agent Xamarin. I've been talking to @nage about the challenge for his team to get PRs into Aries Mobile Agent Xamarin and we wondered about expanding the maintainers on the project to include a couple of people from Kiva -- @horacionunez and @nate.sulat . Any objections to that? To others in the Aries community -- anyone else interested in that project enough to become a maintainer?

nate.sulat (Tue, 04 May 2021 22:12:08 GMT):
Has joined the channel.

horacionunez (Tue, 04 May 2021 22:12:08 GMT):
Has joined the channel.

troyronda (Wed, 05 May 2021 19:41:45 GMT):
Created cross-link issue: https://github.com/hyperledger/aries-rfcs/issues/654

swcurran (Sun, 09 May 2021 19:35:55 GMT):
@rjones -- you please add github user `shaangill025` ( @shaanjot.gill ) to the list of Aries Contributors? I think he has to be added to the Hyperledger organization, which I don't think I can do? Shaanjot is an Aries Cloud Agent Python developer and I want to assign some tasks to him. Does that all need to happen to allow for that? Thanks.

shaanjot.gill (Sun, 09 May 2021 19:35:55 GMT):
Has joined the channel.

kdenhartog (Mon, 10 May 2021 03:12:54 GMT):
> Does that all need to happen to allow for that? You might be able to just have him comment on the issue and then you can assign it to him

rjones (Mon, 10 May 2021 11:56:58 GMT):
@swcurran done

swcurran (Mon, 10 May 2021 14:38:45 GMT):
Thanks!

swcurran (Mon, 10 May 2021 17:35:41 GMT):
@rjones -- Can you please take care of the request above about aries-mobileagent-xamarin and the Kiva folks ^^^ (May 4th).

rjones (Mon, 10 May 2021 17:38:56 GMT):
GitHub IDs?

rjones (Mon, 10 May 2021 17:41:34 GMT):
I found horationunez

rjones (Mon, 10 May 2021 17:45:03 GMT):
I sent an email invite to nates@nates.local - couldn't find GitHub ID

horacionunez (Mon, 10 May 2021 18:02:19 GMT):
@rjones thank you. nates email is nate.sulat@gmail.com

swcurran (Tue, 11 May 2021 03:00:51 GMT):
Thanks!

troyronda (Wed, 12 May 2021 20:23:38 GMT):
@andrew.whitehead @swcurran @TelegramSam opened https://github.com/hyperledger/aries-rfcs/pull/660 and https://github.com/decentralized-identity/didcomm-messaging/pull/194 (for ecdh-1pu draft 04).

swcurran (Thu, 20 May 2021 18:47:19 GMT):
@TelegramSam @troyronda @danielhardman @TimoGlastra @dbluhm @andrew.whitehead @tomislav @domwoe -- a late addition suggestion for DID Exchange -- to add "goal_code" to the "request" message for use in situations where an implicit invitation (aka service block of public DID) is used to establish the connection. I think it should be considered before we finalize AIP 2.0. https://github.com/hyperledger/aries-rfcs/pull/672 Thoughts?

domwoe (Thu, 20 May 2021 18:47:19 GMT):
Has joined the channel.

troyronda (Wed, 26 May 2021 14:31:08 GMT):
@TelegramSam @swcurran Just noticed that transport return route isn’t in the AIP 2.0 PR: https://github.com/hyperledger/aries-rfcs/pull/579/files#r639783112

swcurran (Wed, 26 May 2021 16:39:38 GMT):
I don't recall it ever being discussed. It wasn't in my initial work, and I don't think anyone proposed it.

troyronda (Wed, 26 May 2021 17:33:52 GMT):
Since mediator interop was a desire (e.g., mediator coordination), there would be value in enabling bi-directional websocket transport (transport return route).

troyronda (Wed, 26 May 2021 20:46:02 GMT):
@swcurran @TelegramSam @andrew.whitehead RFC510 fixes from the call: https://github.com/hyperledger/aries-rfcs/pull/677

troyronda (Wed, 26 May 2021 20:49:29 GMT):
@TimoGlastra @swcurran Also, in the merged https://github.com/hyperledger/aries-rfcs/pull/676, I added `BbsBlsSignatureProof2020` as an additional choice when using ldp_vc.

troyronda (Wed, 26 May 2021 20:50:24 GMT):
What would still be helpful in that RFC would be some clarification about using both ldp_vc and ldp_vp as you mention in https://github.com/hyperledger/aries-rfcs/issues/667

troyronda (Wed, 26 May 2021 20:50:24 GMT):
What would still be helpful in that RFC would be some clarification about using ldp_vc and ldp_vp as you mention in https://github.com/hyperledger/aries-rfcs/issues/667

troyronda (Wed, 26 May 2021 20:55:42 GMT):
(also you can see the example in https://identity.foundation/presentation-exchange/#presentation-definition)

troyronda (Wed, 26 May 2021 20:55:42 GMT):
(also you can see an example in https://identity.foundation/presentation-exchange/#presentation-definition)

Helen_Garneau (Tue, 13 Jul 2021 13:24:34 GMT):
Hello Aries maintainers! 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

swcurran (Wed, 14 Jul 2021 10:29:26 GMT):
@TelegramSam @smithbk -- I've raised a WIP PR for the multiple issue credentials minor version update. I've raised some issues that need to be understood (requirements of the VC formats for signing VCs), and corresponding issues with message ordering. See: https://github.com/hyperledger/aries-rfcs/pull/692 I'm likely to make the call tonight, but note that I'm in Europe and am not used to such late nights...

TimoGlastra (Wed, 14 Jul 2021 10:36:46 GMT):
What's the best approach for resolving wallet interop issues? I'm trying to test mobile wallets (lissi, lissi beta, Connect.Me, trinsic, eSatus) against Aries Framework JavaScript and I wasn't able to walk trough a full flow with any of them. We've tested for interop with ACA-Py and the .NET framework, and some steps work in some of the apps. How were these issues resolved in the past? Should I reach out to the different parties?

swcurran (Wed, 14 Jul 2021 10:45:26 GMT):
Are you able to use the Aries Agent Test Harness Mobile Backchannel? That works for most of the wallets (those that can use BCovrin Test). That would at least give you a pre-defined list of test cases. Last I tried it, it took about 7 minutes per run, which is not bad. For the tester, you are basically doing a series of scans of QR codes and responding on the phone to requests. https://github.com/hyperledger/aries-agent-test-harness/blob/main/MOBILE_AGENT_TESTING.md

TimoGlastra (Wed, 14 Jul 2021 10:47:51 GMT):
I forgot about that one. I'll run through the tests again using the mobile backchannel and report back. Thanks

dbluhm (Mon, 19 Jul 2021 20:50:27 GMT):
@rjones could we add @CharHowland (github handle cjhowland) to the aries-acapy-plugin-toolbox repo maintainers? We would like to enable her to approve PRs and such on that repo. Thanks in advance!

CharHowland (Mon, 19 Jul 2021 20:50:27 GMT):
Has joined the channel.

rjones (Mon, 19 Jul 2021 23:06:20 GMT):
@dbluhm invite sent!

dbluhm (Mon, 19 Jul 2021 23:07:03 GMT):
Thank you!

CharHowland (Mon, 19 Jul 2021 23:18:14 GMT):
Thank you, I appreciate it!

mattatkiva (Tue, 03 Aug 2021 17:13:39 GMT):
https://github.com/hyperledger/aries-rfcs/pull/695

mattatkiva (Tue, 03 Aug 2021 17:14:02 GMT):
let me know if there is a different process for this

swcurran (Tue, 10 Aug 2021 20:50:50 GMT):
FYI -- I'm going to rename the aries default branch to "main", per Hyperledger requirements.

swcurran (Tue, 10 Aug 2021 20:58:18 GMT):
The following Aries repos need to have their default branch changed to "main", per Hyperledger policy. Can those in charge (identified below) please make the change? The change is trivial -- https://github.com/github/renaming which says Go to Settings -> Branches and edit the name of the Default Branch. @tomislav - hyperledger/aries-framework-dotnet @horacionunez - hyperledger/aries-mobile-agent-xamarin @smithbk - hyperledger/aries-protocol-test-suite @PatrikStas - hyperledger/aries-vcx Thanks!

swcurran (Tue, 10 Aug 2021 20:58:18 GMT):
The following Aries repos need to have their default branch changed to "main", per Hyperledger policy. Can those in charge (identified below) please make the change? The change is trivial -- https://github.com/github/renaming which says Go to Settings -> Branches and edit the name of the Default Branch, but of course GHA and other CI/CD impacts need to be considered. @tomislav - hyperledger/aries-framework-dotnet @horacionunez - hyperledger/aries-mobile-agent-xamarin @smithbk - hyperledger/aries-protocol-test-suite @PatrikStas - hyperledger/aries-vcx Thanks!

swcurran (Tue, 10 Aug 2021 20:58:18 GMT):
The following Aries repos need to have their default branch changed to "main", per Hyperledger policy. Can those in charge (identified below) please make the change? The change is trivial -- https://github.com/github/renaming which says Go to Settings -> Branches and edit the name of the Default Branch, but GHA and other CI/CD impacts need to be considered. @tomislav - hyperledger/aries-framework-dotnet @horacionunez - hyperledger/aries-mobile-agent-xamarin @smithbk - hyperledger/aries-protocol-test-suite @PatrikStas - hyperledger/aries-vcx Thanks!

smithbk (Wed, 11 Aug 2021 15:27:23 GMT):
Branches is not visible for me under Settings for hyperledger/aries-protocol-test-suite. Is it visible for you Daniel @dbluhm ?

dbluhm (Wed, 11 Aug 2021 15:28:25 GMT):
Same

TimoGlastra (Wed, 11 Aug 2021 15:28:46 GMT):
It is visible for me. Do you want me to change it?

smithbk (Wed, 11 Aug 2021 15:29:09 GMT):
Yes pls

TimoGlastra (Wed, 11 Aug 2021 15:29:30 GMT):

Clipboard - August 11, 2021 5:29 PM

TimoGlastra (Wed, 11 Aug 2021 15:29:33 GMT):
??

TimoGlastra (Wed, 11 Aug 2021 15:29:54 GMT):
There is already a main

smithbk (Wed, 11 Aug 2021 15:30:11 GMT):
Yeh, I tried manually ... let me delete it first. Hold on

TimoGlastra (Wed, 11 Aug 2021 15:30:27 GMT):
Wait. I've just updated the default now

smithbk (Wed, 11 Aug 2021 15:33:41 GMT):
ok, i guess we're good then

smithbk (Wed, 11 Aug 2021 15:34:42 GMT):
thanks

TimoGlastra (Wed, 11 Aug 2021 15:34:48 GMT):
Shall I also delete the master branch?

smithbk (Wed, 11 Aug 2021 15:35:03 GMT):
Are others doing that also?

TimoGlastra (Wed, 11 Aug 2021 15:35:36 GMT):
I think most are doing a rename

WadeBarnes (Wed, 11 Aug 2021 15:35:41 GMT):
You're better off to us the rename feature rather than switch to a different branch.

smithbk (Wed, 11 Aug 2021 15:35:44 GMT):
ok, yes, pls delete master

TimoGlastra (Wed, 11 Aug 2021 15:36:14 GMT):
@WadeBarnes there was already a main. What's the proposed method in that case?

WadeBarnes (Wed, 11 Aug 2021 15:36:16 GMT):
The rename feature has some automation that will automatically re-target open PRs and such.

smithbk (Wed, 11 Aug 2021 15:36:38 GMT):
ah

smithbk (Wed, 11 Aug 2021 15:36:45 GMT):
ok, so let's do the following pls

smithbk (Wed, 11 Aug 2021 15:36:52 GMT):
set default back to master

WadeBarnes (Wed, 11 Aug 2021 15:36:56 GMT):
It sounded like @smithbk created it manually.

smithbk (Wed, 11 Aug 2021 15:37:00 GMT):
then delete main

smithbk (Wed, 11 Aug 2021 15:37:12 GMT):
then rename master to main

TimoGlastra (Wed, 11 Aug 2021 15:37:47 GMT):
Ok

TimoGlastra (Wed, 11 Aug 2021 15:38:25 GMT):

Clipboard - August 11, 2021 5:38 PM

smithbk (Wed, 11 Aug 2021 15:38:42 GMT):
thanks Timo

WadeBarnes (Wed, 11 Aug 2021 15:38:56 GMT):
:thumbsup:

tomislav (Sat, 21 Aug 2021 12:27:42 GMT):
I don

tomislav (Sat, 21 Aug 2021 12:27:42 GMT):
I don't seem to have the correct permission for this.

TimoGlastra (Sat, 21 Aug 2021 13:00:55 GMT):
Do you want me to do it for you?

tomislav (Sat, 21 Aug 2021 13:01:31 GMT):
Please

TimoGlastra (Sat, 21 Aug 2021 13:01:34 GMT):
Not sure if you first want to update the CI to use main or the other way around

tomislav (Sat, 21 Aug 2021 13:01:58 GMT):
Either way works.

TimoGlastra (Sat, 21 Aug 2021 13:02:34 GMT):
Ok, I have renamed master to main

tomislav (Sat, 21 Aug 2021 13:02:58 GMT):
Thanks Timo, I'll send out a PR

dbluhm (Tue, 12 Oct 2021 15:29:17 GMT):
Noticed that DCO checks on PRs are stuck in "Expected" state at the moment. Probot (DCO bot creators) seem to be experiencing an outage?

dbluhm (Tue, 12 Oct 2021 16:52:09 GMT):
@rjones https://github.com/probot/dco/issues/162#issuecomment-941149056

rjones (Tue, 12 Oct 2021 17:52:02 GMT):
@dbluhm I reached out thank you for the notice

dbluhm (Tue, 12 Oct 2021 20:51:27 GMT):
@rjones could we add @frostyfrog (github handle frostyfrog) to the aries-acapy-plugin-toolbox repo maintainers? Thanks again in advance!

frostyfrog (Tue, 12 Oct 2021 20:51:27 GMT):
Has joined the channel.

frostyfrog (Tue, 12 Oct 2021 21:23:06 GMT):
Verified that I got added to the hyperledger org on github. It also looks like I can now review PRs in the aries-acapy-plugin-toolbox repo. Thank you :)

rjones (Wed, 13 Oct 2021 22:06:31 GMT):
Hi, I'd like to nudge this group to using https://chat.lfx.linuxfoundation.org/#/room/#hyperledger-aries:chat.lfx.linuxfoundation.org

SriniGovindaswamy (Sat, 06 Nov 2021 14:12:24 GMT):
Has joined the channel.

SriniGovindaswamy (Sat, 06 Nov 2021 14:12:25 GMT):
Can any one help on Hyperledger Aries Roadmap for 2022..?

dbluhm (Mon, 06 Dec 2021 16:03:27 GMT):
@rjones: Indicio would like to contribute https://github.com/Indicio-tech/infra-mediator as a new repo under the Hyperledger Aries umbrella. The working name we've been using so far is `aries-mediator-service`. More discussion on this topic can be found here: https://github.com/Indicio-tech/infra-mediator/issues/9 Is this something we can arrange?

swcurran (Mon, 06 Dec 2021 16:09:19 GMT):
We'd love to see this happen!

rjones (Mon, 06 Dec 2021 18:09:45 GMT):
@dbluhm let's go

dbluhm (Mon, 06 Dec 2021 22:28:54 GMT):
Repo transfer initiated :slightly_smiling_face:

rjones (Mon, 06 Dec 2021 23:10:41 GMT):
https://github.com/hyperledger/aries-mediator-service

dbluhm (Mon, 06 Dec 2021 23:15:20 GMT):
Thank you!!

swcurran (Mon, 06 Dec 2021 23:51:37 GMT):
w00t!!

ianco (Tue, 07 Dec 2021 18:04:45 GMT):
@rjones I don't have access to some of the alerts on the new repo (for example https://github.com/hyperledger/aries-mediator-service/security/dependabot), can I be added to whatever group is required in this repo? (For example I have access in other hyperledger repo's). Thanks in advance

rjones (Tue, 07 Dec 2021 19:37:33 GMT):
@ianco let me create a team for that repo.

rjones (Tue, 07 Dec 2021 19:41:22 GMT):
@ianco take a look now.

ianco (Tue, 07 Dec 2021 19:44:44 GMT):
Hi @rjones thanks for the quick response! Looks good, I've got "team" access to this repo now. I don't have access to the above "dependabot" link though (which I got from My Curran), @swcurran do you have access to the above link (from your earlier email)?

rjones (Tue, 07 Dec 2021 19:57:12 GMT):
hmm give me a second

rjones (Tue, 07 Dec 2021 19:58:13 GMT):
@ianco I didn't realize I had to give specific access to that feature. enabled now

ianco (Tue, 07 Dec 2021 20:24:14 GMT):
Got it, thanks @rjones !!!

bruno.hivert (Wed, 05 Jan 2022 14:32:12 GMT):
Has joined the channel.

bruno.hivert (Wed, 05 Jan 2022 14:32:12 GMT):
Hello ! First, happy new year 2022 to all of you and your relatives, wishing your the best health. There is an aries working group supposedly scheduled today https://wiki.hyperledger.org/display/HYP/Calendar+of+Public+Meetings Is is still on ?

regiseloi (Wed, 05 Jan 2022 14:38:54 GMT):
Has joined the channel.

SeanBohan (Wed, 05 Jan 2022 14:43:38 GMT):
@bruno.hivert No Aries WG call this week. They restart next week

bruno.hivert (Wed, 05 Jan 2022 14:47:21 GMT):
Got my answer from TelegramSam: no working group this week https://chat.hyperledger.org/channel/aries?msg=8C7gkhqKmBsDEcRe6

sbohanlf (Tue, 25 Jan 2022 15:15:42 GMT):
Has joined the channel.

kdenhartog (Tue, 08 Feb 2022 05:09:49 GMT):
Hey @rjones can I have my github account - kdenhartog removed from Aries Admin role and all other additional permissions associated with Aries groups and this account? I've not been active in Aries WGs or RFC discussions for awhile now and I don't think I'm the best person suited for this role anymore. Looking at who's currently listed there I think the admin responsibilities are sufficiently covered at this point. I should have requested this awhile ago but it slipped my attention.

kdenhartog (Tue, 08 Feb 2022 05:09:49 GMT):
Hey @rjones can I have my github account `kdenhartog` removed from Aries Admin role and all other additional permissions associated with Aries groups and this account? I've not been active in Aries WGs or RFC discussions for awhile now and I don't think I'm the best person suited for this role anymore. Looking at who's currently listed there I think the admin responsibilities are sufficiently covered at this point. I should have requested this awhile ago but it slipped my attention.

rjones (Tue, 08 Feb 2022 08:10:08 GMT):

Screen Shot 2022-02-08 at 12.09.51 AM.png

rjones (Tue, 08 Feb 2022 08:10:21 GMT):
@kdenhartog you want removed from all of these groups?

kdenhartog (Tue, 08 Feb 2022 21:10:50 GMT):
@rjones yup all those look correct. From the looks of my account every repo except the aries-rfc has the permissions properly removed. I think only the Aries-RFC repo would need to have my permissions descalated still since I still have PR merge authorizations. I believe it's because I'm still apart of the admin group for Aries RFC Commiters as an admin in that group. It also has the maintainer label next to my name in there as well so that may need to be handed off to someone else. I'd think @swcurran or @TelegramSam would be a good option for that

kdenhartog (Tue, 08 Feb 2022 21:15:04 GMT):
I was able to properly remove myself now actually and no longer have any additional privileges from what I can tell. Can you double check if I removed myself properly in that repo?

rjones (Tue, 08 Feb 2022 22:42:52 GMT):
I think so. If you want me to remove you from any other groups, let me know, @kdenhartog

rjones (Fri, 11 Feb 2022 22:04:46 GMT):
this chat has moved to https://discord.gg/hyperledger

rjones (Wed, 23 Mar 2022 17:24:04 GMT):