Stephen Curran: Right welcome to the May thirtieth Ares Cottage about Asian python
Stephen Curran: user group meeting acupug. couple of things on the on the agenda. We're going to talk about it on cred's in Akupi and a a brief update from
Stephen Curran: I want to go through a few occupy Prs and see if we can do some. Let's Let's play. Can we merge this? See if we can get some of those off the off the list
Stephen Curran: and get the merged or push back for other things.
Stephen Curran: As there's time I want to do a I got a little presentation on converting from unqualified periods to did pier 3. And so I would like to push on that
Stephen Curran: We are recording the call, so I'll post after, perhaps with excerpts.
Stephen Curran: grabbed for specific topics. We'll see how how that's needed.
Stephen Curran: a reminder. This is a hyper Ledger Linux Foundation meeting the Linux Foundation and trust policy which is in front of you on the screen is in effect, as is the Hyper ledger code of conduct. Be good to one another.
Stephen Curran: if there are any, is there? If there is anyone new to the community, to the meeting and wants to introduce themselves and talk about what they're doing now would be the time as well. If you have any announcements
Stephen Curran: or want to suggest agenda items, please do so.
Stephen Curran: Grab the mic weighed barns
Wade Barnes: an announcement. so Hyper Ledger? they want to do a
contributor and Maintainer outreach
Wade Barnes: for Indian areas similar to what they do for the fabric teams.
Wade Barnes: So if anybody is interested, if you could contact Shawn Bohan, I'll put his email address in the chat.
Stephen Curran: What does that mean?
Wade Barnes: Don't really know what it means. I I think I I think they want to just get some more.
it's more excitement around the the projects and various things, and get feedback from the contributors and maintainers on
Wade Barnes: how the projects going and what they'd like to see change.
Stephen Curran: There is a
Stephen Curran: coming out of the open source Summit in Vancouver. There's 2 surveys that I've noted.
Stephen Curran: one on on Linux Foundation and open source in general, the state of open source. that's at the Linux Foundation level. And then there's also a hyper ledger survey
Stephen Curran: that
Stephen Curran: was sent out. that they're looking for understanding of
Stephen Curran: what Hyper Ledger is, and and and and how it's perceived.
Stephen Curran: So That might be one of the things that's that they're looking at
Stephen Curran: anyone else. Want to
Stephen Curran: grab the my right now.
Stephen Curran: All right.
Stephen Curran: A reminder that the acupy.org documentation site is up. There'll be more evolution on that. I've been away for a while, but I want to get back to adjusting some of that, so I'll spend some of my time
Stephen Curran: in the near future doing that, and would glad to introduce anyone else to what it takes. Basically, it is a
Stephen Curran: it grabs all of the Md files, organizes them and publishes them as a website. so if you're looking to use, see what's in it. you know, a mark down file in the acapug repo. It's it's a whole lot friendly, or a place to go rather than github
Stephen Curran: to try to navigate through the folders and find the repo, the the the readmes, and things like that. It's a much easier way to go. So encourage that to get used. we have, and a non-credit's workshop tomorrow, May thirty-first. The link to register is here. So Rudolpho, Miranda, Miranda,
Stephen Curran: Patrick St. Louis and myself are going to be presenting that
Stephen Curran: and we're gonna be playing with an on credits. hands on, but also going through some a lot of the background. And and what's coming with an on credits.
Stephen Curran: So we invite anyone to that.
Stephen Curran: With that I will turn over to Daniel to talk about
Stephen Curran: how how things are proceeding with an on cred, and it's good because I've got a dog now telling me he wants to go outside, so I need to
Stephen Curran: deal with that so over to you?
Stephen Curran: Do you want screen, Daniel?
Daniel Bluhm: I will be pretty quick I've linked to the document that I'll I'll be talking through, and there's just a few bullet points so it'll it'll be pretty quick. so I'll I'll not screen share this time around. But yeah, let's see. So as a brief update.
Daniel Bluhm: so
Daniel Bluhm: I've got a dock linked from the agenda you can go through. I've got links to a few things that are are relevant to our progress here.
Daniel Bluhm: but we've gone through and done a number of things lately. we've updated the non-creds. Rs build we're using. So we're now using ones that are actually being published from the non-critz Rs library, which was an early challenge that we had with the project where there was a lack of support. There. we've now gotten over that problem.
Daniel Bluhm: we've gone through and updated the tails file handling. We are now using the hash of the details. File as the file name that gets uploaded to a tail server. And then there were some associated changes to the in detailed survey implementation that we made to support that
Daniel Bluhm: we've currently left the original functionality that that's retained within our changes. there's a newly introduced and non-credit sales server
Daniel Bluhm: components within that that uses the new behavior. We haven't added the intelligence switching between the 2 based on a configuration or anything like that yet. So that'll
Daniel Bluhm: need to be further refined, I think. But we've gotten the sales file upload resolving the circular dependency that we're experiencing previously. so that's all in place and working well
at this point
Daniel Bluhm: we have basic checks on the tails file that gets uploaded just to make sure that
Daniel Bluhm: you know basically matches the hash But we're also investigating whether we can do any deeper validation on the
Daniel Bluhm: getting some feedback from you, Steven, I think, on the mic.
Daniel Bluhm: okay. And then.
Daniel Bluhm: further on, here we've got So our Mvp. For the revocation. We're we're nearly complete with that process. So when I say, Mvp, just getting the absolute basic steps down, we haven't gone through the automated flows just yet. but just getting the basics of being able to do all the setup for the non-credit objects. I've left that step off, I realize, but we can do issuance and presentation all the way through.
Daniel Bluhm: without revoking the credential. Because we're actually, that's what we're working on currently is the publishing of revocation updates.
Daniel Bluhm: So
Daniel Bluhm: that's our our focus for this week is is finishing that off as well as getting into the automated setup of revocation registries. and just in general, further, clean up of the implementation so far, and in a lot of cases, the existing implementation of revocation, just to get things where we need them to be. and we're also planning to start taking into updating tests and stuff as well. So
Daniel Bluhm: yeah. And then below that. I've got some links to our our current Pr, that we haven't updated that branch in a little bit since we've been working on a different branch which I also have linked there.
Stephen Curran: Good.
Stephen Curran: Thank you. Any questions from anyone
Stephen Curran: awesome.
Stephen Curran: Can't wait to have that available
Daniel Bluhm: in the
Stephen Curran: can't wait to be done with it.
Stephen Curran: Excellent. Okay, thank you.
Stephen Curran: All right.
Stephen Curran: I did. want to mention this. I left this. We're not going to have an update. we are continuing to make progress in the use of redis with acupy with the occupy based mediator. So those things are proceeding, and that's a good thing.
but I did get a message from the team at BC. Gov. They wanted to remind people don't ever use info logging in production.
Stephen Curran: You want to minimize the logging necessary.
Stephen Curran: fun story. We've got that He activated a dev instance of of occupy with logging and mediator and did a bit of load testing and
Stephen Curran: with info set it absolutely blew out a a logging system on our on our open shift, and we got calls from the
Stephen Curran: calls from the platform of operators to say, What do you do? And your your
Stephen Curran: sucking up this space? So
Wade Barnes: it was something like several 1 million
Wade Barnes: several 1 million logs per hour that they were.
Wade Barnes: they were looking at getting, and it was like it was just blowing up the elastic search database.
Stephen Curran: So make absolutely sure you are not using
Stephen Curran: logging in production or any sort of system like that, and be aware that, especially from what I hear especially ask, are, the logging is extremely high, and it probably should be adjusted and maybe will be adjusted. to change a lot of the info logging to be debug logging
Stephen Curran: to make that less likely to happen. But anyway.
Stephen Curran: worthy of a all caps reminder. Okay, can we merge this? I want to jump into a.
Stephen Curran: and see if we can get some feedback going on this.
Stephen Curran: this one came up today. So we want to drop python 360. Anyone
Stephen Curran: shocked, upset by that
Stephen Curran: with a comment on that idea. We've used 3 3, 6 since since the beginning, and never really changed it.
Stephen Curran: long overdue for that. Okay? So.
Stephen Curran: Daniel, you've you've created this You've just reported just before the meeting that some of the integration tests. are not working.
Stephen Curran: actually there. That's the second time. I think it's been cancelled after 360 min.
Daniel Bluhm: Yeah, there's a something's timing out on the the integration test right now. So I I need to take a look at
Daniel Bluhm: how the image changes I made are are impacting that I I suspect it might be just some quiet failures on on the container or something like that.
Daniel Bluhm: Okay, But yeah, I I only noticed that this morning, so I haven't had a chance to look too much at it yet. I I did also comment here. I've got a number of things going on at the moment. So if you happen to have some time and are feeling really motivated to look at this, contributions are welcome. So yeah.
Stephen Curran: Jason.
Jason Sherman: does this include changing all the demos.
Jason Sherman: the demo, a lot of the demo images are 3, 6,
Daniel Bluhm: right? so the integration tests are actually using the demo images. And and when I, the initial changes that I made, actually, I failed to include the demo images, and then that promptly caused the the integration test to fail. So this has adjusted that but it seems to be imperfectly adjusted at this point. So but yeah, those those images should be, okay, yeah, just just curious. Because I was just having some issues with the
Jason Sherman: trying to put in newer libraries into the demo images and what not. So just curious about that. So
Stephen Curran: I I will see if There's someone on our team that could take a look at that. I'm thinking. CSIRO, maybe you could take a look at that. Given you, we're looking at integration tests relatively recently.
Stephen Curran: maybe that's one. You could have a quick look at and see if you can help out. Daniel.
Jason Syrotuck: Yeah, I will. I can take a quick look at that suite.
Stephen Curran: Okay, good. Good.
Stephen Curran: And then any anything we can do to push this forward that would be useful, I think. getting this done sooner than later would be a good thing
Daniel Bluhm: agreed on that. Now I'll also call out that after we get this particular peer emerged, I think it will make sense to go through and do it. A number of updates on dependencies as well. we're we're kind of behind. Several of our our dependencies have been updated to drop python 3 6 ports. We're actually on older versions of those to keep that. So
Stephen Curran: okay.
Stephen Curran: thanks. Thanks for that reminder. I'm going to quickly write myself a note.
Stephen Curran: I want to get a an issue in on that.
Stephen Curran: Okay? Good.
Stephen Curran: This one, I think, should be ready to go. did a little looking at it yesterday. Basically, what this does is. we have a script
Stephen Curran: that
Stephen Curran: is available to update the open Api
Stephen Curran: to the latest the latest version. This adds,
Stephen Curran: I believe what it's doing is both generating a swagger, a open Api 2 and 3.0
and just adds the latest version of the generator from an older version. So, speaking of dependencies that we're old
Stephen Curran: I've looked at this, compared it. I think we're ready to go and approved it. Does anyone have any bots? Anyone particular that's used the open Api generator stuff? I just that's the only reason I was holding back on this was, I don't actually use it. so is anyone using it and and have any comments on this or concerns about merging this.
Stephen Curran: We also had a bit of a conversation here, and I'll probably put these things in about. We're getting way. Too many warnings and error messages from it
the
Stephen Curran: it works to use it. But It would be good to get this cleaned up. So
Stephen Curran: Marit. Maritz had a number of comments in there about what to do about that. So I'm I'm hoping to get that into an issue and and get that looked at. So we get some approval on or get some movement on that
I'm gonna go ahead and merge this. This will probably the last merge on the call, because now we'll have to
Stephen Curran: update all of the Pr's that we look at next. But anyway, we've got that one merge, so we at least merge one
Stephen Curran: Sherman comments on this one. I did notice that we had a integration test failure
Jason Sherman: on this.
Jason Sherman: Yeah, I'll take a look at that. That was, basically it was. It was all on the demo side, nothing in occupy. And that's that's why I was asking about the demo images, because, as
Jason Sherman: the library that was having the issue. I was trying to put in the the newest version of the library that they said they fixed the bug and and
Jason Sherman: couldn't easily do it. So I kind of fudged it, but it turned out that it didn't actually fix the bug in the spot. We had it regardless. But that's why my question was about the getting updated. So but I'll take a look at why, that test is failing.
Stephen Curran: Okay, you might want to wait till after we sort out the three-six and maybe look at this after the yeah. Good point.
Stephen Curran: Okay, I think this one's ready to go. It's been approved by several. I don't think team most here. But, Daniel, any comments on that. I know. You looked at it.
Daniel Bluhm: no, yeah, this one looked good. So I'm happy with it.
Stephen Curran: All right, I'll update the branch and get this merged.
Stephen Curran: so this is a
Stephen Curran: thinking about base wall at a non. Yeah, okay.
we had a few issues like that.
Stephen Curran: this is a bigger one.
Stephen Curran: comments on this one. This is from Darco. To add, 2, 5, 5, 1, 9, signature 2020 support.
Stephen Curran: this one is dependent on the 3 60,
Stephen Curran: so or 3.6, so we'll probably follow up with that. Any anyone with knowledge on this one and want to comment.
Stephen Curran: Andrew, I asked you to take a look at it if you could. given the nature of this type of change in your knowledge on signature, suite, so on.
Stephen Curran: so it'd be good if you could take a look at it as well, but, as I say, I think we'll wait till the 3 60 and get our 3.6 completion, and then get darko to
Stephen Curran: adjust the items based on using post.
Python. 3, 6.
Stephen Curran: Okay.
Stephen Curran: Daniel, you talked. You're ready to have this one done
Stephen Curran: interesting problem.
Stephen Curran: good catch on it. I think this looks easy and and ready to go comments. And our people fine with it anyone else? Take a look at it.
Stephen Curran: That's the change.
Daniel Bluhm: Yeah, to to summarize. there is cache inconsistencies between replicas during that exchange that caused
Daniel Bluhm: errors and other protocols.
Daniel Bluhm: to summarize some of the comments that I made in the description. since the connection target for
Daniel Bluhm: a connection changes throughout the did exchange protocol, anyways. there was actually some code that existed prior to my changes. That was just immediately clearing the cache on every connection record save
Daniel Bluhm: which would have occurred at each step of the did exchange protocol anyways, so rather than just having cache be storage. And then
Daniel Bluhm: the improperly cleared later on on a different replica, and and failing to be cleared on on the replica that was originally answering the the request.
Daniel Bluhm: I just adjusted it. So
Daniel Bluhm: caching of connection targets only occurs on completion of the did exchange.
Daniel Bluhm: so this kind of sidestep some of the issues that I I think we've experienced in other situations as well. I haven't tested any of those other scenarios, so I I don't know for sure.
Stephen Curran: but it makes sense.
Daniel Bluhm: Yeah. So it it?
Daniel Bluhm: This kind of maybe hints a little bit at like, how do we actually want to treat the cash going forward? Do we want it to be a shared state thing, or do we want it to be a a local state
Daniel Bluhm: thing only, and only for you know, ephemeral values, or whatever. Yeah. This goes further in the direction of supporting local only as opposed to a shared state mechanism.
Stephen Curran: And and what we really want is.
Stephen Curran: I think, one option we want to have available, and this has been done with with. Redis is, have a a reddit shared cash cross. and I and Dco Daniel, your team is put together. A
Stephen Curran: an instance of using red. As for this type of thing, I believe? Correct.
Stephen Curran: Yeah. So that
Daniel Bluhm: these changes are partially motivated. We were working with Sikh, but and they were wanting to avoid having to introduce the shared cash mechanism if they could. and it. This was the only problem that they were experiencing in that. in that setup. So yeah.
Stephen Curran: cool. Okay.
Stephen Curran: any developers anywhere? Have a I'm gonna I'm going to approve it. If anyone else has any concerns with it.
Stephen Curran: take a look. I won't merge it yet. We can't merge it yet till it gets updated, anyway. And so, Daniel, if you could update it from the the main branch and then gets re-tested.
Daniel Bluhm: Good.
Stephen Curran: All right. maybe I'll do one or 2 more. Let's see.
Stephen Curran: Yeah, again, this one looks pretty straightforward.
Stephen Curran: update the branch
Stephen Curran: and a pro and run. I just wanted a developer to take a look. So this is just a a tweet to how how the end rock endpoint gets extracted and used.
Stephen Curran: So a couple of tweaks to a a shell script.
Stephen Curran: so I assume this is fine. I did. I didn't have a chance to actually run it, so I was hoping that's why I put your name on it. Take a look at running it. but I think it should be fine, so
Stephen Curran: likely that will get
Jason Syrotuck: move forward. Yeah. I was going to spot check that this morning. But yeah, I don't see any concerns with the changes that are me to.
Stephen Curran: Good.
Stephen Curran: Thank you.
Stephen Curran: this is a depend upon change.
Stephen Curran: I'm
Stephen Curran: imagine.
Stephen Curran: Oh, this is in in the area you've got. Sherman looks like in the playground.
Stephen Curran: so probably get you to take a look at that.
Stephen Curran: or, or, you know, just merge it with a as you see fit, depending on how much you think it needs review.
Jason Sherman: Yeah, just a bump in the requirements. thing.
Stephen Curran: but I I can't do merging.
Stephen Curran: Maybe I'll take a look. Yeah.
Stephen Curran: you can put an approval on it, and then I can proxy your knowledge. Yeah, sounds good. You can communicate your approval.
Stephen Curran: All right. this is a a big change that Sherman, you did. for adding updating from an efk to an elk stack.
Stephen Curran: I think this is pretty clean, and I've run through it once, and it works great.
Stephen Curran: I I think this is ready to go, I would suspect. Do you have any reason to think it's not ready, Jason? Or
Jason Sherman: no, I mean I I I was using it a lot so to do. You know all the number testing with the redis and the mediator, etc., etc. And then all that debugging with the trace log stuff. so it worked for me. yeah, it's basically just an update. The Efk, one was so far out of date that this kind of updated and being a little bit more flexible to you, integrate into Run Demo and and all those situations. So
Jason Sherman: Someone else was able to follow the instructions and get to work. That's good. That certainly doesn't having it. There doesn't have any impact negative impact on any other chunks of code. There's no like hard dependency on it or anything. So
Jason Sherman: right, it's not a tool.
Stephen Curran: Cool.
Stephen Curran: All right. I'll get that one reviewed, as they say. I've run through it
Stephen Curran: on my own machine, and it worked great. So happy to get that one push forward. This one
Stephen Curran: T-mo has looked through it had some back and forth. looks like this is close to resolved
Stephen Curran: so we're lucky for an Update
Stephen Curran: to base.
Stephen Curran: I don't know if Sasha is on the call.
Stephen Curran: but if not, this is likely to get merge pretty soon. Looks like Daniel. You've you've been happy with that teamo is more or less happy with it, had some conversations. So we'll we'll see about that and then get it merged.
Daniel Bluhm: Yeah, I I think there might be some minor adjustments here and there, but and I can communicate back to Sasha on the sick. The team. where Sasha is from. Okay. Good. Yep, yep, excellent
Stephen Curran: good. Last one I wanted to hit on. This one was shan jot the one you've been working on on settings per per tenant basis as opposed to on the overall occupy instance, do you want to talk a bit about that? And and do you think this one's ready to go and we should get it finalized.
Shaanjot Gill: Yeah, it's it's ready to go. So it's basically like, right now, we are able to set up a startup like flags, the startup parameters. But we can't do it for at the sub sub wallet or the tenant level. So basically, this allows like, modifies the endpoints for supported creation and update so that we can specify those start up
Shaanjot Gill: settings for at the tenant level. So it that's pretty much it.
Stephen Curran: I don't see a single Md file. It's updated.
Shaanjot Gill: okay, I I'll I'll I'll work on that.
Stephen Curran: yeah, I would say, maybe add it to the multi-tenant one
Shaanjot Gill: Md file exists. So I think just adding a section to that. And then, when I highlighted in the change log, I think, between the 2 that will help.
Shaanjot Gill: I work on there. So it sounds good.
Stephen Curran: Okay.
Stephen Curran: I think that takes care of a lot.
are there any other ones down here?
Stephen Curran: this is an open Api demo. I think I just have to merge that. I think it's just documentation.
Stephen Curran: oh, auto! Remove flags for presentation request. Oh.
Stephen Curran: Jason! And comments on that! That's been out for a while, and we need to deal with that one.
Jason Sherman: Yes, I've got a refresh my brain here on that. It has been a while. yeah. So previously just had the
Jason Sherman: We were only saving one exchange the financial exchange. so so these
Jason Sherman: basically follows the same pattern. it's
Jason Sherman: seems to work out okay with impact. so I think the documentation goes through it pretty well of
Jason Sherman: what to do, and
Jason Sherman: we've added it. So a change to the financial exchange is that now you can pick which side.
Jason Sherman: So when we put in the presentation exchange, there's a configuration for each side of the conversation, and we added that in for the credential exchange as well. So the existing code works. It's just now there's an enhancement to the credential Exchange side as well. So preserve the all your side, or whatever you can do that
Stephen Curran: Shanghai, is this one of the settings that's
Stephen Curran: inherited downwards, and should be goes to the tenant level versus the acapug occupy level
Shaanjot Gill: the the auto.
Shaanjot Gill: Yeah, I think. So. This is one of them. Yes.
Stephen Curran: okay.
Stephen Curran: okay, You've got conflicts here, Jason, so you're going to deal with that.
Stephen Curran: Okay? that's good. this is one of the issues we're having is
Stephen Curran: you know, being consistent as maintainer in in getting these resolved. so that is going to be more of a focus in the next, while we're getting a lot of updates from a lot of different people, and we really need to
Stephen Curran: pay more attention to these and get them closed faster.
Stephen Curran: so we will be doing this more often in Acupug, and then I'm going to make an effort to try to bring the Maintainer together to make sure we're we're being timely and addressing these and and and working on them. Another note, I'm going to be updating the Maintainer's file. to make sure it's accurate. But if anyone
Stephen Curran: W. Wants to be a maintainer and has
Stephen Curran: met the qualifications which is at least 5 5 pull requests been merged, and
Stephen Curran: a knowledge and interest in being so absolutely welcome to do so. And we'd we'd love to have additional maintainers that that are willing to take the time and willing and able to take the time to
Stephen Curran: Stay on top of these pull requests as they come in and make sure they're getting merged in a timely way, and not only that, but feedback is given to the to the contributors. Making them, that's even, you know, just as important as as getting them nailed down. Getting them assessed is is getting feedback to those that are contributing and and making sure that they want to continue to make that contribution and update what they've done to meet the
Stephen Curran: the needs. So a pitch for anyone who, you know has a knowledge, but hadn't thought about it of of being an actual maintainer for the for the framework.
Stephen Curran: Okay.
Stephen Curran: that's that. looks like I am missing a topic in here, which is, I wanted to talk about before we go, and we have a few minutes. of pier 3.
Stephen Curran: that's great.
Stephen Curran: So
Stephen Curran: let me jump to that. basically, I have an overview of transitioning to Period 3. And I wanted to. make sure this is right. And then it's likely that one of the developers on the BC Cup team. CSIRO on the meeting is likely gonna take this next.
Stephen Curran: And so I wanted to solicit feedback and and get him some help as he started working on this.
So getting qualified.
Stephen Curran: so background, we have
Stephen Curran: 2 types of unqualified dids.
in Indy. That's not right.
Stephen Curran: So let me just fix that. I had that on my brain yesterday in Akupi. 2 types of unqualified Ds did sob, did. I? Don't know why that's underlined. But That our public dids on an Indie ledger.
Stephen Curran: so again they would not be qualified. And then we have periods. on a didcom messaging relationship between 2 parties. So you know, an issue or a holder might have a establish a connection. They exchange periods. Currently, most of those are unqualified periods.
Stephen Curran: pretty obvious from the context of where they get used. which which type it is. So there's not a need to get a unqualified didn't, and and try to look it up on a ledger when it's a peer did
Stephen Curran: So that's not really a big issue. But we want to update all Aries agents to use qualified dids, occupy agent occupy based agents and all other areas. So we want to use qualified dids.
Stephen Curran: It's pretty easy for public days. We just pre-pand did solve. I guess I need another colon in there. Once we do that, everything should continue to work we already support did soft so that should work. But unqualified periods are a little trickier. And we've talked about this on the areas working group calls. So some of this is repeat, but I thought it worthwhile to to lay the foundation
Stephen Curran: unqualified did is calculated in the same way as did solve. So select the first 16 Byte of a 256 bit verification key, or the hash of it, I believe. But anyway, the first 16 Byte of that becomes the unqualified did the
Stephen Curran: the identifier value. But that is not a standard did method. there's no prefix to use for it did Colon, whatever. So we did talk about in the areas community creating one did peer legacy or something like that.
Stephen Curran: but we had another idea.
Stephen Curran: So we'll talk about that. how it works during did exchange of using either connections or did exchange
Stephen Curran: Each party independently generates during their part of the did exchange generates a key pair
Stephen Curran: From that they generate, the namespace did identify, or the stuff after did Colon which is the unqualified part in this case.
Stephen Curran: they don't put a prefix on it it. They created
Stephen Curran: the
Stephen Curran: did, Doc.
Stephen Curran: and then they send the other party. The unqualified did. And the did, Doc. So they're sending 2 pieces of data in the various calls.
Stephen Curran: second background backgrounded. Wow! I did these quickly and without oversight.
Stephen Curran: did peer
Stephen Curran: works by having is is intended for exactly this purpose.
Stephen Curran: and it's specified that there there would be different types of did peers, and they would be numbered 0 one and 2 so far, and as of immersed that was done this morning, there is a
Stephen Curran: type 3 as well. So there's or overall did. Pier 0 is a is exactly equivalent to the did key protocol, and therefore should probably never be used and did. Key should always be used in its place, since many it is far more prevalent. So did Peer 0, and probably don't ever want to use it.
Stephen Curran: did. Pier. One is similar to one qualified period is but the did identifier. The the namespace identifier is derived from the hash of the did Doc, and not the public key.
Stephen Curran: So a different way to to to derive the public key?
Stephen Curran: worse or or a big problem with the appear one is that the canonicalization of the did. Doc is not really defined in the spec Ares framework Javascript, to find a way to do that but it's not really defined in the spec itself, which is not a good thing.
Stephen Curran: so that's a second issue, and and has led us to say we probably shouldn't use, did pier one? And so we're leaning away from it.
did, pier 2
Stephen Curran: the elements of the did Doc. Are extracted from the did dock itself and used to construct the names namespace identifier. So there's a set of rules for how you construct the the the identifier
Stephen Curran: following following the 2, the the part of it following the 2 in the in the did
Stephen Curran: The result of that is that the dids are very long, and those elements are all visible and all all interactions which is not ideal. It's it's a very long, it adds to every message being sent.
Stephen Curran: and in plain text, all of the details of the did, Doc are are shared.
Stephen Curran: But the the difference is, you just need to send a did. You don't need to send it, did Doc? Because the actual did. Dot can be derived from extracting the elements out of the did itself.
Stephen Curran: So that's good.
Stephen Curran: so did Pierre, is something new. I actually this is a link to the Pr. For it. But the pull request was approved this morning by Daniel. So it's actually now in the specification itself.
Stephen Curran: So did Pier 3. The idea of that is to get the benefit of Did pier 2. But eliminate the need to send the folded peer on every message. Basically
Stephen Curran: whoops derive and namespace identifier from did Pier 2
Stephen Curran: calculate the shot, 2 56 hash of the did pier 2 did.
Stephen Curran: and you now have did pier 3 did Colin peer Colon 3. And then the value of the identifier. That's the
Stephen Curran: Just the hash of the actual did pier 2. So after sending a did pier 2 once, we can then
Stephen Curran: there after send it the same did Pier 2 every time, or we can send it, did pier 3.
Stephen Curran: And if we send, did pier 3 much shorter
Stephen Curran: But of course this the recipient needs to understand. Did Pier 3? So that's a a complication in it.
Stephen Curran: Any questions or comments so far. Sam, am I getting this right?
Stephen Curran: nothing yet. You haven't yet explained the how, you know thing, but I'm guessing you're getting to that. So transitioning from unqualified dids part. One is adding an acupy support, for did pier 2 and 3.
Stephen Curran: So right now Shan Jot did a a pile of work to support. Did pier one matching afj I now would suggest that we retarget that work
Stephen Curran: to support did pier 2, and did pier 3 and a
Stephen Curran: in particular. And first thing it needs to do is support the receipt of both those did methods.
Stephen Curran: so suggesting that we sort of retarget that pr, that's in there for did pier one it's not been merged yet and eliminate.
Stephen Curran: replace the did peer. One element of that with support for using did Pier 2.
Stephen Curran: And that will enable us to use the transition to using. Did pier 2 and 3 we do that automatically. So
Stephen Curran: we if the other party sends one, we can handle it.
Stephen Curran: If the other party sends a did pier 2 before we've sent I did over to the other party we should use, did pier 2.
Stephen Curran: Otherwise. we have a flag that that we can activate when needed to initiate sending it. That's always the tricky part. When should we send it? And how do we know the other party is using it?
Stephen Curran: That comes as a community court and update, although there.
Stephen Curran: I'll I'll talk about that in a bit as well. There's another way that we can get partially through it without
Stephen Curran: using the flag W without only using the flag.
Stephen Curran: Actually, no, I don't think there is any other way. Okay, never mind
Stephen Curran: And then and then we need a community cord. They need to update transition unqualified bids to pier 3 across the community.
Stephen Curran: Oh, sorry. Part 2,
Stephen Curran: The community coordinated update is at this part that we we start to move to. Pierre did 2 and 3.
Stephen Curran: Andrew.
Andrew Whitehead: yeah, isn't this? Did peer 2 and 3 stuff only a concern when we switch to did come to
Andrew Whitehead: for wanting to do something in the old protocol. It's going to be required then. But we should. We should have done this a year ago.
Stephen Curran: Yeah.
Sam Curren (TelegramSam): so it's not just a concern. It's just a requirement there.
Andrew Whitehead: okay.
Andrew Whitehead: But
Andrew Whitehead: like in the connections and did exchange protocols, we're sending the whole. Did document.
Andrew Whitehead: I think we can just send a did string in there.
Andrew Whitehead: but
Andrew Whitehead: I don't know.
Andrew Whitehead: I think we can make it work. but it it seems a bit disruptive to update those 2,
Andrew Whitehead: those.
Andrew Whitehead: Sorry.
Stephen Curran: Sorry you you think, until we go to dip here, did come to. We don't need to do this.
Andrew Whitehead: Well. at the moment we are, we're switching to this. Did peer one support, and
Andrew Whitehead: did exchange. And I I think we're just targeting compatibility with with. So I guess it depends what they're doing.
Andrew Whitehead: They actually pioneered this.
Sam Curren (TelegramSam): They've already got mostly written code. it needs to be made a little bit more canonical. And then they've
Sam Curren (TelegramSam): They're going to document their approach. for the the transition. So it did peer. It is not canonicalized in the sense that it is
Sam Curren (TelegramSam): that it is, reliably created in order every time. And so you have to impose a little bit like it allows you to specify things in various orders, and so that the the the community coordinated update will specify the exact order that you that you use to construct it did peer to when when we're doing this transition. So this is definitely an approach that it's been pioneered by Aj.
Andrew Whitehead: okay.
Stephen Curran: okay?
Stephen Curran: transitioning unqualified kids to did pier 3, the goal is to convert
existing unqualified dids to be? Did pier 3 dids?
Stephen Curran: And I, I put a question which is kind of like Andrew was asking, you know, is it useful. Do we need to do this? Or do we just continue to support unqualified did when we get them, and eventually don't send any any more. But anyway.
Stephen Curran: if we did want to actually convert them from unqualified to qualified I believe what we can do is we already send a did Doc from acupy, so that would mean both parties have the did dock
Stephen Curran: Both parties would then be able to convert that into or to generate from that it did pier 2, because that is very formally defined. Exactly how you would do that.
Stephen Curran: And if that's true, then we can just derive it. Did pier 3 from the did pier 2.
Stephen Curran: So that's the idea for that.
Stephen Curran: And with that we would be able to convert all all unqualified did come here, did's to did. Pier 3.
Sam Curren (TelegramSam): I got a question. Stephen.
Sam Curren (TelegramSam): yeah. So in my mind, we have 2 options. We can either do the community cord and a coordinated update just to did pier 2.
Stephen Curran: Yeah, because that gets us out of the unqualified land that we really need to escape from
Sam Curren (TelegramSam): 3 is a nice optimization. I was unsure about whether we should community coordinated, update all the way to did pier 3 for for that, or whether we should stop at a 2 and then allow the existing mechanisms to detect support for 3,
Stephen Curran: since we need new code for 2. Anyway, I think we should just assume everyone is going to implement 2 and 3 together.
Stephen Curran: That would be my
Sam Curren (TelegramSam): my suggestion. This is this is a good conversation for the larger community call. But yeah, yeah, I mean, there's been an open thing in my mind is we don't technically have to go to 3. But do we want to like leverage? The effort, anyway, to make that happen. That was my thought is, we should
Stephen Curran: It does mean that we need some sort of within occupy or any framework. Some sort of idea of having a synonym
Stephen Curran: for did. So that if a did pier 2 comes in, we find the connection. If it did pier 3 comes in, we find the same connection. So we do have to have this idea that that
Stephen Curran: this concept that the dids used in a connection can have synonyms
Stephen Curran: and and resolved to the same one when searched for. So that's an interesting side issue that would have to be supported when we have.
Stephen Curran: And and but I think it's necessary as well, because if we want to support, you know unqualified dids. And you know they did pier 2 version of that
Stephen Curran: again, we've got a support synonym. So I think that's a concept we're going to have to have, anyway.
Stephen Curran: so with that,
Stephen Curran: BC, Gov, CSIRO is. Gonna take a look at this, take a look at the existing Pr, and look at what it would take to convert to that. Did pier 2 and 3.
Stephen Curran: And again, just for that same comment, Sam of.
Stephen Curran: we're going to do 2. Then we might as well do 3.
Stephen Curran: This idea of supporting synonym did so that when you get a message in and it's got a did different, it could have different dids pointing to the same connection. be able to support that.
Stephen Curran: And then.
Stephen Curran: if if my theory, which is still a theory, is that we can actually do a of a canonical conversion of it, unqualified bids to did peer they. I did pair 3.
Stephen Curran: So that's the work that we're planning on doing in the short while.
Stephen Curran: and then is there. There is still not a community cord in the update. Rfc, out there, Sam.
Sam Curren (TelegramSam): I don't believe so. The animal agreed to write that, given their experience with the with the code and the method, they pioneered. So I haven't checked yet. Today
Stephen Curran: I'll check on with them. And and it's possibility now that I've got the the vacation in the workshop past me that maybe I could do it right up on that. I don't think it would take long
Stephen Curran: comments, questions from anyone.
Daniel Bluhm: So a a quick second comment, I don't know how have deep. We need to go on this right now, but just thinking out that for a second I think it did come be one. We tend to rely more heavily on the vertex
Daniel Bluhm: of the dids, anyways, so in in supporting making that transition from unqualified did to period 2 and 3
Daniel Bluhm: like. When we look up connections, for instance, we're looking them up by the keys that encrypt all the messages that we received.
Daniel Bluhm: Okay, so there there might be, I'm sure there's going to be fun stuff to figure out in there still. But maybe that realization helps point us in the right direction. the other comment I had. And maybe this is a bit of a controversial take but
Daniel Bluhm: a. And this could just be my perception as well. I don't know but
Daniel Bluhm: I I get the feeling that a lot of our emphasis on backwards. Compatibility within occupy has encouraged the rest of the community to remain in a state where they're using unqualified dates and things like the connection, protocol and stuff. in this process of updating for a dear.
Daniel Bluhm: Well, here did 2 and 3,
Daniel Bluhm: should we?
Stephen Curran: I? I'm wondering if we should be a little bit more willing to break things
Daniel Bluhm: and kind of pulling
Daniel Bluhm: because of it. Still, to this day we're still very frequently using connections, I think, in the wild today. and that's what I'm using did solve blah blah blah, and you'll create it only one day. And provo
Stephen Curran: first.
Stephen Curran: you know, message prefix Http did come, I agreed.
Stephen Curran: so what I would suggest on that one is
Stephen Curran: proposing, you know, once we get to this, this Pr or this community
Stephen Curran: like we suggest, okay, what should the breaking change be? We change to 0 9 or 1.0 of acupy what do we
Stephen Curran: do for backwards compatibility? Are we willing to accept, but not generate unqualified dids? Was that sufficient?
Stephen Curran: Are we requiring that when you upgrade to one or to the next the breaking change that you must convert your existing ones to qualified
Stephen Curran: to participate.
Stephen Curran: I don't know. We'll have to think about that there's. So there's a there, there's the later phases of the community coordinated update, which are are are weak or or soft by design in the sense that
Sam Curren (TelegramSam): removing support for the old is something that is not necessarily co coordinated as a community. but But but everyone is, you know, required to to use the new. Which means that I think that Daniel suggestion can be applied by actually setting at least with an acupy, a deadline for the removing of the old, and that this might be a really good chance
Sam Curren (TelegramSam): to do a little bit of clean up there and force folks to to come up to to current. we're we're on a on a relatively quick pace, but if they don't, there's going to be significant problems anyway, and so doing it a little bit early is, I think, a good behavior as a community to avoid more problem. You know, problems that will pile up against the conversion to did comfy to and make that transition even harder.
Stephen Curran: Okay. any other comments?
Stephen Curran: All right. Well, thanks. Everyone for attending.
Stephen Curran: we will be. I will be trying to be
Stephen Curran: encouraging the Maintainer to be tracking these Pr that we talked about today. as they
Stephen Curran: come up for either re-approval or or just simple, simple merging.
Stephen Curran: So please be responsive to that. If if you get assigned to look at a a. A. Pr.
Stephen Curran: It would be appreciated if you could, and We'll try to get those done. The next call will probably go through another few of these.
Stephen Curran: and we'll see you in a couple of weeks.
Stephen Curran: Thanks all for attending.
Charles Lanahan: Thanks.
Emiliano Suñé: Thank you. Thanks.