 All right, welcome to the June 26th, the non-credits V2 working group meeting, a few topics to go over presentation data models and predicate types. So I wanted to talk about that. A reminder, this is a UNIX, sorry, a Linux Foundation Hyperledger meeting, so the Linux Foundation anti-trust policy is in effect, as is the Hyperledger Code of Conduct as well. And all the specification that we're creating coming out of these meetings is published under the community specification license, and all of those things are linked in the meeting agenda. So we'll just quickly jump to meeting discussions. I do have just jump into edit mode. I think we're getting something up already. So I will do that. I don't have any other announcements. So we'll just jump into it. Mike, you want to talk about, I think the thing we want, I wanted to go through was the presentation models and make sure that again, we did a pass through those and, and I want to see if there's new objects or things to be created or something like that. So I will stop sharing and turn it over to you. Oh, okay. All right. I guess I, yeah, probably better for you to call it up and then you can bounce around to where you want to be in that. Okay, give me a minute. Okay, I'm at the airport. So I'm just bringing it up. Well, I, I've got it up now. You know, if I start turning robot. Been known to happen when you're at the airport. Okay, so I'm going to scroll down just to the ticket starts here. Yeah. Okay. So if we look at it. Yep. I call them statements. Yeah, these are basically what you want to be proved in a presentation. The most basic one is a signature. This is basically saying. The data is signed. And selectively disclose the following information. So it's either a show, no show, or hide reveal for each claim. And that's all it is. And, oh, and the third, the third item is from which issuer. So I just put whatever that issuer object happens to look like, which could include the public key revocation information what the credential schema is that kind of stuff. So one of the things that you can do with an on credits today is you can say, well, I needed to come from this schema but I don't care what the issuer is. I don't care who the issuer is is that kind of. Are you foreseeing that kind of support. You could do that. I highly, I can't imagine a use case where they would say I don't care who signed it is then I could sign it. So, yeah, but the idea there is that instead of, instead of doing pre qualification of the issue where you're basically doing okay give me what you got and then I'll decide if that's acceptable. So you get a presentation. You can verify the cryptography but then you apply business rules so the, and the use case I can think of right off is. You know, a university, you know, an education credential, there's no way I can list all of the possible issuers I will accept it from so I'll accept it from any that is, you know, a degree, and then I'll decide if I trust that issuer. Yeah, so right here I mean we could rename this right the point is this is the information you need to know where it came from. Yeah. So, so similar, like we have restrictions today which as a list of I believe is eight things. Is there any reason not to go down that same eight list. I, can you tell me what the art. So schema. Schema publisher identifier schema. Schema name schema version. So those four all relate just to the schema. That should be compatible. So that shouldn't need to change. Okay, I'll do that here. Yep. You've got the two related to the credential, the issuer identifier and the issuer credit def, basically. And then the last to relate to specific attributes within the credential which is must contain this, this attribute name and must contain this attribute name with a value. So I mean you could apply that for me the only thing I've needed. And that doesn't mean it's every use case is disclosed, which is like must contain a claim with equals or, or even just contains a first name I don't care what that first name is but they have to disclose. Yeah, for example. Okay. Yeah, that's all disclosed is and everything else is assumed to be hidden. Okay, so I would say we just go with. Yeah, we go with that. The revocation information, I believe that's also in there. Yeah, that's that's what I put right here. Yeah, I mean, we can rename this but I mean it's schema information verification and cryptographic verification information and revocation information. If you don't put the revocation information in there, I don't know where else you would put it. Yeah. So, I mean one sort of assumption that I think we can make. Well I don't know the, you could just say, you know, anytime if the credential is revocable, you must include a revocation. You must include revocation. Yeah. And then I mean currently that the whole revocation interval is really complicated, like it's very confusing for everybody in an on credits one. What do you mean the interval, like how often it's updated or how fresh it is a in the request you can say, I will accept one in the range of from this time point to this time point. It's very confusing to people. Because what it's saying is, it's basically some sort of optimization around how fresh the revocation can be. That's really all it is yeah that's all you really care about revocation is, it has to be valid as of a certain period of time. Exactly and that rather than being saying, you know, it's as. I mean it's really only valid at the time point the publication of the data was made. You know what I mean. If the, if the issuer last published revocation data, you know, six weeks ago, you can't have it any fresher than that because by definition there is nothing fresher. It's confusing. Right, and that's part of like the trust model that's outside the scope for this right. Yeah, you might have some issuers that you know they are contractually obligated to update every 24 hours or something like that but you're right. Okay. So essentially this is going to be more or less the same as we had it. As we today. It really isn't that different. No. Okay. Yeah, that was that that was the goal I had because when I was designing this I tried to save as much as possible from the one. So it wasn't a completely new thing. The main thing I wanted to do was just disconnect the cryptography. So it could be swappable as needed. But this allows that. So we already had that for non crippling. Okay. So now I'm going to move on to the next one. This isn't much different than you have it in non creds one but we only did this for the link secret, but now I'm saying we can do it for anything. Okay. This is like where I'm going to prove that two claims are the same without revealing. That's all this does. Okay. And. So let's say you didn't want to use link secret let's say you wanted to use my first name to link across. Or my last name or some other unique identifier. You're not restricted to the link secret you could be anything. Maybe I want to prove multiple attributes or. That's what this would allow. Now, how does this relate to whether the schema, one of the attributes is in the same schema or not so one of the things that that got added. I think the answer was the names concept. And in an on credit one where you use names and you list a series of attributes those attributes almost come from the same credential. Are these intended to how is there any sort of way for the verifier to say, this must come from the same credential is that what statement ideas. They can come from the same credential but they can also come from a different one. So like for example, maybe like the credential itself is a medical record. And you've got, let's say that's one credential right. And so I'm trying to say all of my kid listed on there all have the same last name. Right, I could do that. I also say now I've also got four other credentials for each one that is the birth certificate. And I'm going to prove that the last name on the birth certificate also matches the last name on this credential. So I could do that too. So, they can be different credential schemas, but they can also be the same. This supports both. So the only thing is you just say, it's from this statement ID and it's from this claim. Well I put label but you called it name, but the same idea. Oh, I see. Sorry, and that's a list. I get it. I was thinking it was just two things. Okay. So, so the statement ID is the statement ID as in above. Yeah, it's linking. Yeah, this is like, from like a signature statement that's how you know the data is valid or certified. Okay, so these qualities these supplement a previous one, a previous previous statements. Correct. Okay, usually. So when I'm talking predicates they usually have to say hey the data that is input the predicate has been certified. Well the easiest way to do that is with a signature. Yeah, yeah. So assuming the signature is valid then you can do this. So this is just the quality statement identifier nothing new there, and this is saying, say this is one signature statement ID, and then you say, first name here and then you give another one. And it's the same here. So usually you'll have at least two items in this list. Right. Any questions with that. Okay, so the claim labels are signatures. No they're not claim labels are just name of their like kind of a tag or the name of the claim itself like first name or last name, age, address phone number, something like that, or ID. That's where the claim label is a signature is over a credential not over a claim. You sign one claim and that is your credentials is with one attribute. If we're not have any more questions on that one I'm going to move on to the membership members yet. Right. Keep in mind this was just the initial proposal it we can update it. So as you could do set membership or non membership with accumulators are with CS or some other way. There's many ways to do this accumulators are usually the past. But this is a way to say what type it is one of these two. Yeah. This is the signature statement or a reference of where the claim is going to get certified from that reference. Yeah, it references like say this one. This is the data is coming from here. There's the label claim label. So let's say it's revocation ID or zip code. And then the rest of this is kind of more like, what are we going to use to check it. Here's the accumulator here's the actual accumulator value. Maybe there's a public verification key maybe there's some other parameters, whatever the case maybe these next three are kind of subjective to whatever the system is using it. You can probably get away with these two parameters may or may not be optional but let's say you're doing bullet proofs, then you might need that. Okay, so what you're saying, I think is as a verifier, I am going to. So I want to, I want to, we've got a claim label that is state. And I want to know if you are in one of 10 states. So, so I take those 10 states, and I feed them into a function that produces an accumulator. And then I pass that to you. And what the presentation comes back with is it takes the state improves its inner or not in that state. Correct. So let's say the issuer said, All right, here's how I map the states to an accumulator. Anyone could say, Okay, I'll do the same thing like, like I was saying kind of last time disaster zone. The issuer for my driver's license says I map them just by, let's just say hashing it because that's the easiest. They're just going to hash the state. That's public information. So then FEMA comes out and says, Well, the hurricane just hit these coast. Yeah, we're going to say the following states in the US were hit and make an accumulator and use the same mapping as issuer a acne. Then anyone who lives in those states without changing any of their credentials can then prove that they're in the disaster zone or not. Okay. Yeah. Okay. And, and they can do that because they know it's in it. Well, they can do that. I know it's an enumerated set. They know it's an enumerated set and the verifier has said this is how I determine the entries in the enumerated set. And they can do that either fully explicitly they can list out here are the 50 states. And the other one takes that enumeration does the same calculation to come up with the accumulator of accepted ones and then membership or non membership can be proven. Okay, that's right. The other way you could do this is you could do it with an R1 CS circuit. It's a little more complicated, but you could use it to do the same thing. Right. All I'm saying is, regardless, there is a set out there, you're proving you're in or not in that set. And as we saw from the work. Richard did last week. These are not accumulator does not have to be made up of primes. For some reason. No. The elliptic curves, elliptic curves don't have to contain primes. Okay. They just have to contain valid, valid elements in the field. The only, the only accumulator that needs primes is an RSA based one. So, because in the one, you know uses the elliptic curve, they're just points. Okay, that's all they are. That's crazy to me. Like I thought that was the, you know, like as little cryptography as I know the map, the simple math was, oh, if the accumulator is made up a bunch of primes, then if the prime's missing, then you can tell that. But now you're telling me they're not even primes that seems crazy. Not for an elliptic curve. All right. I believe you. All right, so the security, though, the security of it comes from the fact that, you know, you've got to the 256 power possible values that could be in there. So it's impossible for someone to enumerate and try to check which ones we should first write it's just too large to find it. Okay. All right. Fascinating. Okay. Okay, so that's accumulator membership and then and and basically what happens is, depending on how it's signed. The accumulator is is done the same way but depending on whether it's PS or BBS plus or whatever, the calculation can be performed for presentation to present and to verify right. Yes. The signature actually doesn't matter. As long as it's compatible with the accumulator. So for example, see all signatures are also compatible, even though they're RSA based. Okay, it just because those three signature types. All our signatures over commitments. You know, just a regular value, and that's all like, for example, the lipstick curve accumulator or an RSA based accumulator require to do a purchase. Okay. And all that the create a presentation of this you're just sending over the signature of the value. And then on the other side, they're figuring out their. Oh, sorry, no, the, the verifier sends over the enumerator. Or sorry, the accumulator. And in creating the presentation, the holder can tell if they met that condition if they're in the accumulator. Yeah, the holder will know before they even do the presentation. Right. And if they're not like say the no fly list, then they could, you know, go, oh crap, I'm going to get dinged or whatever. But the, the verifier is not sending over the actual list it's only sending an accumulator right. That is correct. Okay, so it but it can still, but the holder can still do the calculation itself to figure out if their value is a holder can. Yeah, because they can prove and verify if they had to. But what I wanted to be sure they are now asking that was that the verifier isn't sending over the list of 22 states. It's sending over. No, they don't have to. Exactly. Okay, good. If they're doing say our one CS they might have to send over all the states but that's why I think the accumulator is the better option because you don't need to. Let's say it was, let's say if there was a billion items in that way. And all that over is going to be very bandwidth intensive. That's exactly what I was thinking that's where I was going by sending just the accumulator it's really simple to send it across then the verifier, the holder doesn't even really need to know it just needs to am I in it. That's right. Okay, good. Okay, a commitment. This is like one use cases for the domain proof idea. In the register you create something that's unique for that specific domain, and you want to prove that you are a return visitor versus brand new. That's one use case for this. That's one use case. The other is some other proofs require conversion to a commitment rather than a snore proof, which is how like CL, BBS plus and digital standards all work. Connect or like let's say you're doing ECB essay. Right, that's just a regular value. And let's say you want to link it to our one CS. And that requires a commitment. This is how you do it. You and I have talked about how like that's a bulletproof source bulletproof takes commitments, not snore proofs. So this is kind of one of one of those. If you wanted to say, yeah, domain proof, you could just stop here with this. The domain proof for a commitment is similar to what we've seen before, where what's the value that you're going to prove. Make sure it's signed. That's a distance for the reference of signature statement. What's the claim. And then, because we deal with blinded commitments, you need two generators. One is myself and the other is for what I call a randomizer. Another term is blinder. I'm not, I'm not entirely sold on the nomenclature for this yet. I like randomizer but blinder is also. I just think blinder confuses people whenever I say, Oh, it's the blinding factor. They're like, wait, what's that? So, yeah. I try randomizer because I think people understand what that is. And by presentation, they would understand it. Well, they should have. Okay, so from a business perspective, domain, domain name, sorry, a domain proof. Is there any other business perspective on that if you go the, you know, you mentioned there's two types, the domain. The second one is like, let's say you wanted to do bullet proofs or which arrange proof. Sometimes you have to link out to, to a different using a different crypto. And that's how you do it with it. But would a verifier have to know that. Yes, they would. Now you could, you could hide that, right? You could say, Hey, I will accept the range proof from bullet proofs or maybe some other thing. And so if you've got a seal signature, in order to get it to a bullet proof, you're going to have to do this. And that's fine. Okay, let me come back. Sorry, I want to revisit this. So a domain proof, the verifier gives a value, which is the claim generator. They give two values. Okay. They give both of these, right? They give both of them. It's the only thing that the verifier would have to get. Well, they'd say which one, which claim label they allow and two generator points as long as these aren't the same. Okay. And then what they get is a consistent signature, blinded, a consistent blinded signature, that as long as they pass the same plane generator and randomizer, they get the same string back. Right. Kind of. Think of it this way, I can, I can post this link because this is public. Okay. Here's what I call it. It's called a commitment when proof. You're basically saying I have two commitments. And I'm going to prove that they hide the same value. So in the domain proof, when you register, you're going to create one commit. That is going to store it. Then whenever you revisit, you're going to prove that, you know, the two values that were hidden. That's what this does. So that way the proof looks different each time, but you're still indicating which domain proof to check. This, this link is public if you want it. I'm still trying to translate this into language that I know, and that's why it's so hard. I know what I'm trying to get out of this is. I get that that the same credential was used. Or the same attribute value was pulled from the credential. Every time. I don't get to see what the value is at the attribute, presumably I don't disclose it, but I do know that. I've seen that one before. And so I can correlate it with one I've seen before. That's right. Okay, which basically gives you that ability to have a unique identifier, but not share that unique identifier but the, but the verifier knows when the same unique identifier comes back. Right. The great thing is, yeah, with the domain proof, I can use that same unique identifier across domains, but it won't look the same to anybody observing. Like acne bank, even though I did it versus the British Columbia government. Exactly. I might register the same ID, but because it's hidden behind the commitments. The parameter information these two things are specific to that domain. They can't tell. And as a holder, I could detect that Oh, this is the said they've used the same values as somebody else. Therefore they are able to collude if they want to. Right. The holder could look at these and say have I seen these two before. Exactly. Right. Yes, they could. Okay, good. Okay, yep. And that's the only. Is that the only use of this commitment. No, as I've been saying, like if you need to link out to other systems that may require something other than what he s bbs plus and field signatures require this. This also works. So range groups, range groups, you can't just take them as is from those three signatures. You have to do some translation and this is the way to do that. Okay. But you can't give me a use case where I would do that. Other than just to say range. Well, for example, there are no range groups supported by elliptic curves right now. So, so in order to do that, like bullet proofs is a way to do that. But bullet proofs takes a commitment, which is what this gives you. So I would have something signed by bbs plus. I would take that value and make a commitment proof and say the same value that was signed in the credential is in this commitment. And bullet proofs will go okay I can take that same commitment and I can also generate a range group over the same value to say, okay, let's say it's my age. So I make a commitment to my age bullet proofs then goes okay I can take that age commitment and prove it's greater than 80. Okay, so let me propose that we do this suppose, even though it's got the same values can we break this into two sections domain proof and bullet range proof. They already are. So range proof comes down down below right here. Okay, but it uses essentially the same technique you're saying. Yep. Okay. So this one we would rename to domain and then we've got range down below. Right well range like I said range takes as input a reference to this commitment statement. So it needs to know that because it can't take just the value from the signature. Okay, that's to do something else to it first. So it says this is the signature that is coming from so I know it's certified. But then I also need to know where's that commitment that took it from the signature to this value because that's what I have to use. Oh, I see what you're saying. In other words, I've got to have a commitment and then I do a range proof, and I reference back. That's right. But another way to do that would simply be to replace that reference to a commitment and simply say the same things that are in the commitment in here. Yep, you could do that too. Yeah, I think that would be easier. That's fine. Yeah, got it. Okay, that makes sense to me now. Thank you. Okay. Variable encryption verifiable encryption. Yeah, as I've talked about before this looks identical to a domain proof the differences instead of a randomizer generator you have an encryption key. And you're essentially proving that you've encrypted the value to this encryption key. So whoever owns the corresponding decryption key could decrypted. And to verify the proof they don't need that that decryption. They're just saying, Okay, I can check that you encrypted the value that was in your, in your credential claim you encrypted the claim. And so it's the same value in the credential and you encrypted it to this encryption key. Yeah, got it. And the use case there is somebody, an issuer or somebody else gives you a gives the verifier a public key. They pass the public key in this encryption key field. And the result is they get a an encrypted data value that only someone with a private key can be correct. That's right. So in this case is for this. Let's say that you wanted them to have some reporting system. Let's say I got a claim from BC gov, or a credential from BC gov. Yep, and I am anytime I use it. Part of that proof says, you need to send me a verifiable cipher text which is what this gives you. It says if I were to take that verifiable cipher text back to BC gov, they would be able to decrypt it to know who you are. Obviously I wouldn't know who you are, but they would. Yeah. So they could do that. So in that case BC gov is also supplying the verifiable encryption, even though they are the issuer. So there's no external third party. Yeah, but it's a way that if they needed to unmask you they could. Yeah, another thing that this should have is, it should either be an encryption key or a reference to an encryption key. So this could be a did a did with a hash key one, you know a hash to the key. I assume I assume all keys that I've listed here could also be dead. Yeah, good. So they're all going to just be resolved anyway. So, exactly. Yeah, yeah. But that way that there's no question where the key came from, you can say, you know, you're not, you're not accepting the key from the verifier you're accepting a resolvable identifier to get the key. And therefore you can tell, oh yeah, this is the BC gov. That's right. Yeah. Okay. Very cool. Okay. I did not list verifiable decryption, although that is something else we can also do. It's just not a very common use case for it. I've only seen it used in like more complicated protocols outside of a non cred. I have yet to see a use case for it inside a non cred. Okay. So I didn't add it, but we could just easily add it if we wanted. And that is that the issuer issues it encrypted. And yeah, yeah, so you can think of it as the issuer gives it gives you an encrypted value that only you can decrypt. Yeah. But both sides would know what the value is for the issuer goes this is the value I encrypted. And you get you decrypted and then you then you return a proof and say this is the value I decrypted. I got after I decrypted the issuer can say yes that's correct. Yeah, but like a way scenario that's weird. Exactly. That's why I didn't play it in here. I would agree. Okay, excellent. All right. There are other that we could do but I think this covers everything. Yeah. And then the range proof is the last one. And range is this, and the predicate we have today is also covered by range right. It should. It just works a little different and a little faster than. Yeah. It's actually done. This supports this. What I want is that this range could be the same one used in the current one, but could also be a newer one. Okay. So it's more flexible because right now the current one is restricted to CL signatures. This one should be anything. Groups could be our one CS could be anything. Okay, that makes sense. Yep. Yep. Okay. And then what have you got down presentation request statements. I've got a schema presentation request schema. It's just a list of statements that you want proof. That's it. That's literally all it is. Yeah. I did not put an ID and there could be an ID like, but I usually assume that let's say the presentation request schema is anchored somewhere. It could be anchored to a block hash. I don't really care. Yeah. Um, so originally I was thinking that when we had that, it would have to come from one credential, but by definition this could come from multiple credentials. Yep. Exactly. Yeah. Okay. And if that happens, you just have two statements with signatures. Right. Exactly. Okay. And then this is just the data that is returned. I call them proofs. Yeah, right. There's a signature proof inequality proof that's that membership proofs and then obviously I didn't carry on but there you have one for each one. Okay. Oh, that was huge help. I mean, there's other proofs that we could do like one is called set intersection. That one gets a little complicated. And I'm not sure it's needed yet. But I think we can cover just about everything else with what we've got. That should handle probably 98, maybe even 99% of use cases. That's awesome. All right, well, I got a lot out of that. I reach for hope that you did as well. Moving on to other things. I am really buried this week. I will try to I'm, I've got on my list to try to come up with a plan. I reach her for the work you're doing and, and moving on, I think we're ready for the, oh, I did want to have a discussion actually if you don't mind with the two of you. The idea of, Mike, did you follow the conversation about the the issuer or the holder providing the what we're now calling the entropy variable. Kind of. I was trying to figure out still exactly what the use for it. Because you said like it was partially there for legacy purposes. I need to go forward. What I know is that in Indy, there's this in the Indy implementation. So going back to, you know, in the SDK and and credits there's this value called issue or a holder did that the holder provides. And it makes no sense in a not in a non credits perspective because there's no such thing as it did. So we traced it along and it turns out that it is basically used to to provide entropy. And so why. Can you help with that. Can you help with that question. Well, is it coming from the verifier or the issuer. They're supplying it doesn't make it coming from the holder. It's coming from the holder. Yes, currently, currently the holder is providing so that's why I was thinking that the holder can provide anything like any random string or, or the DID so the thing is that maybe they're using the DID only as a random stream. That is what I guess from the code I saw. Are they like switching it or intruding it and like a transcript somewhere. Yeah, I think they got some hashtag one time. I don't remember actually but yeah they did something with that with the string. So, so the, the holder provides it in the credential request. And then as far as I know the issuer takes the value and hashes it and then add it to some other information they have and uses that in the signing. Yeah, that's not really needed. I wouldn't say it weakened security but it also doesn't enhance either just kind of there. So, so the two thoughts came from it one. So, so one. So what we did was we at least renamed it when we, when we did it, when we did the actual an on credit specification we renamed it because we thought it was inappropriate to call it. And that's what the holder did when that has no, no meaning, unless you're using, you know, did calm or something like that it has no meaning. We call that entropy for lack of a better name, but the question is, should we simply in the issuer ignore whatever value is put by the holder in there and simply generate a random number. Well, like I said, there's really no need for it. If it's going from holder to issuer. If it was holder to verify or I could see that being like self attested place. Now that's not a case here. Holder to issuer. Then to me there's no need for it. I say we get rid of it. It's just confusing, and it really doesn't add anything except complexity. So if, if we can, I'd love to drop it. Okay, so I will Richard, could you basically write up an issue that that captures the flow of that field and basically propose that presentation request can continue to have either of those values, but they will be ignored and we, we update the implementation to simply have the issuer do what it needs to do, and not involve the holder. Yeah, yeah, I can do that. Okay, well okay. Here's a thought I just have. Maybe the holder wants to say, this is a unique interaction request from me to the issuer. He wants some unique identifier for it, you know, for an interaction. That's about the only use case I could see for it. But again it has nothing to the security model. It's purely for like auditing purposes. So you can say hey here's the unique identifier I sent over to the issuer. The issuer honestly could do anything they want with it they could completely drop it. They could do anything. Yeah, yeah, exactly so that's why I think let's just get rid of it. Because I don't see how why the holder, the holder can do anything they want to track the fact that they got issued a credential for one thing they're going to have a credential they can track. Right, well and there's, there's two things you can't really hide, no matter how much encryption will deploy one is time, right. Both sides are going to be able to see it. And two is location. Right. Somehow the packets all have to route back to the source on both sides. So those are two things you can't really hide. Okay. Okay. Good. Okay. From there I'm going to look through. I would like to get Mike what's your schedule over the over July. Are you working or holidaying or. No, yeah, so this week I'm traveling. So this week I'm a little slammed, but next week. There's a US holiday on Tuesday. I might be out Monday as well. Yeah, otherwise I'm more I'm planning to work. Okay, so I'm going to set up a meeting for the three of us say a week Wednesday. I can do that. Can you make that. Maybe he went to bed. Fine. July 5th. Can you make that a meeting then. Hello. Yeah. Yeah, Steven, I suggest we go a little on the early side. Yeah, this time is fine. I was going to suggest two hours earlier if that's possible. Yeah, two hours earlier. Is that good for you? That would work for me. All right. Which time can we just repeat which time. July 5th. Yeah, July 5th two hours earlier than this time. Okay, yeah, fine for me. Okay, great. Okay, I'll set that up. I will. Have a plan for the rest of it and a proposal for. Meetings for the rest of the mentorship. Cool. Thanks, Steven. Fantastic work so far. That's for sure. Much appreciate it really. Great. Okay, thanks. Well, just real quick. Richard, do you have anything for Steven and I? Oh yeah, absolutely. Nothing I search for now. Okay. Anything. Yeah, exactly. That's right. Okay. Have fun in Montreal. I will. I'll eat tons of poutine for you. All right. Good. Take care. Okay. Okay.